Как синхронизировать огромные разреженные файлы (образы дисков ВМ) между компьютерами?

Существует ли такая команда, как rsync, которая может синхронизировать огромные, редкие файлы с одного сервера Linux на другой?

Очень важно, чтобы файл назначения оставался разреженным. Он может быть длиннее (но не больше), чем диск, на котором он находится. Только измененные блоки должны быть отправлены по проводам.

Я пробовал rsync, но не получил радости. https://groups.google.com/forum/

Если я пишу программу для этого, я просто заново изобретаю колесо? http://www.finalcog.com/synchronise-block-devices

Спасибо,

Крис.

9 ответов

Решение

Я закончил писать программное обеспечение для этого:

http://www.virtsync.com/

Это коммерческое программное обеспечение стоимостью 49 долларов за физический сервер.

Теперь я могу реплицировать разреженный файл размером 50 ГБ (с 3 ГБ контента) менее чем за 3 минуты по широкополосной сети.

chris@server:~$ time virtsync -v /var/lib/libvirt/images/vsws.img backup.barricane.com:/home/chris/
syncing /var/lib/libvirt/images/vsws.img to backup.barricane.com:/home/chris/vsws.img (dot = 1 GiB)
[........>.........................................]
done - 53687091200 bytes compared, 4096 bytes transferred.

real    2m47.201s
user    0m48.821s
sys     0m43.915s 
rsync --ignore-existing --sparse ...

Для создания новых файлов в разреженном режиме

С последующим

rsync --inplace ...

Обновить все существующие файлы (включая ранее созданные разреженные) на месте.

Чтобы синхронизировать огромные файлы или блочные устройства с низкой или средней разницей, вы можете либо сделать простое копирование, либо использовать bdsync, rsync совершенно не подходит для этого конкретного случая *.

bdsync работал для меня, кажется достаточно зрелым, его история ошибок внушает оптимизм (небольшие проблемы, быстрое решение). В моих тестах скорость была близка к теоретическому максимуму, который вы могли получить ** (то есть вы можете синхронизировать время, необходимое для чтения файла). Наконец, это с открытым исходным кодом и ничего не стоит.

bdsync читает файлы с хостов и обменивается контрольными суммами, чтобы сравнить их и обнаружить различия. Все это одновременно. Наконец, он создает сжатый файл патча на исходном хосте. Затем вы перемещаете этот файл на хост назначения и запускаете bdsync второй раз, чтобы исправить файл назначения.

При использовании его по довольно быстрой ссылке (например, 100 Мбит Ethernet) и для файлов с небольшими различиями (как это чаще всего имеет место на дисках ВМ) это сокращает время синхронизации до времени, необходимого для чтения файла. По медленной ссылке вам нужно немного больше времени, потому что вам нужно скопировать сжатые изменения с одного хоста на другой (кажется, вы можете сэкономить время, используя хороший трюк, но не протестировали).


*: rsync очень неэффективен с огромными файлами. Даже с параметром --inplace он сначала прочитает весь файл на целевом хосте, ПОСЛЕ ТОГО, КАК он начинает читать файл на исходном хосте и, наконец, передает различия (просто запустите dstat или аналогичный при запуске rsync и наблюдайте). В результате даже для файлов с небольшими различиями требуется примерно вдвое больше времени, чтобы прочитать файл для его синхронизации.

**: при условии, что у вас нет другого способа узнать, какие части файлов изменились. Снимки LVM используют растровые изображения для записи измененных блоков, поэтому они могут быть чрезвычайно быстрыми (readme из lvmsync содержит больше информации).

Rsync передает только изменения в каждый файл, а с помощью --inplace следует только перезаписывать блоки, которые были изменены, без повторного создания файла. Со страницы их особенностей.

rsync - это программа для передачи файлов для систем Unix. rsync использует "алгоритм rsync", который обеспечивает очень быстрый способ синхронизации удаленных файлов. Он делает это, отправляя только различия в файлах по ссылке, не требуя, чтобы оба набора файлов присутствовали на одном из концов ссылки заранее.

Использование --inplace должно работать для вас. Это покажет вам прогресс, сожмет передачу (на уровне сжатия по умолчанию), рекурсивно перенесет содержимое каталога локального хранилища (что имеет значение в начале косой черты), внесет изменения в файлы на месте и будет использовать ssh для транспорта.

rsync -v -z -r --inplace --progress -e ssh /path/to/local/storage/ \
user@remote.machine:/path/to/remote/storage/ 

Я также часто использую флаг -a, который делает еще несколько вещей. Это эквивалентно -rlptgoD Я оставлю точное поведение для вас, чтобы посмотреть на странице руководства.

Взгляните на Zumastor Linux Storage Project, в котором реализовано резервное копирование "моментальных снимков" с помощью двоичного "rsync" через ddsnap инструмент.

С man-страницы:

ddsnap обеспечивает репликацию блочных устройств с возможностью создания моментальных снимков на уровне блоков, способных эффективно удерживать несколько одновременных снимков. ddsnap может сгенерировать список фрагментов снимков, которые отличаются между двумя снимками, а затем отправить это различие по проводам. На нижестоящем сервере запишите обновленные данные на блочное устройство со снимком.

lvmsync делает это.

Вот расшифровка стенограммы. Создает на исходном снимке LVM, передает логический раздел. Вы можете передавать инкрементные обновления изменений с момента создания снимка так часто, как вам нравится.

Может ли репликация всей файловой системы быть решением? DRBD? http://www.drbd.org/

Может быть, немного странно, но недавно я узнал, что NFS справляется с этим нормально.

Таким образом, вы экспортируете каталог на один компьютер, затем монтируете его на другом и просто копируете файлы с помощью основных утилит, таких как cp, (Некоторые старые / древние утилиты могут иметь проблемы с редкими файлами.)

я нашел rsync особенно неэффективно при передаче разреженных файлов.

Я не знаю о такой утилите, только о системных вызовах, которые могут ее обработать, поэтому, если вы напишите такую ​​утилиту, она может быть довольно полезной.

на самом деле вы можете использовать qemu-img convert для копирования файлов, но это будет работать только в том случае, если конечная FS поддерживает разреженные файлы

Другие вопросы по тегам