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

22

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

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

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

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

Благодарность,

Крис.

linux rsync kvm-virtualization

— fadedbee
источник

rsync крайне неэффективен с огромными файлами. Даже с параметром --inplace он сначала прочитает весь файл на целевом хосте, а затем начнет читать файл на локальном хосте и передаст различия (просто запустите dstat или аналогичный при запуске rsync и наблюдайте)

— ndemou

21

rsync --ignore-existing --sparse ...

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

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

rsync --inplace ...

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

— Стив П
источник

3

Обратитесь, чтобы иметь rsync --existing --inplaceи затем rsync --ignore-existing --sparseиметь ускорение синхронизации

— Майк

2

Кто-нибудь может объяснить комментарий Майка и как это должно ускорить синхронизацию?

— Preexo

Я думаю, что Майк подразумевает сначала изменение на месте, а затем добавляет новое, так что новые не должны быть на месте снова из-за разницы во времени между первым и вторым вызовом. Это верно только в том случае, если вы выполняете rsync непосредственно из хранилища данных и виртуальные машины работают. Разве он имеет в виду что-то еще?

— Юань

Я согласен с Юанем. Вторая команда Steves снова rsync новые файлы, вы можете сделать это с помощью последовательности команд Mikes.

— Фальстаф

rsync крайне неэффективен с огромными файлами. Смотрите мой комментарий по этому вопросу.

— Ндему

5

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 Я оставлю точное поведение для вас, чтобы посмотреть на странице руководства.

— reconbot
источник

1

«-S» - для разреженных файлов, а не «прерывает длинные строки». Со страницы man: -S, --sparse эффективно обрабатывает разреженные файлы. Я попробую, спасибо.

— Увядшая пчела

Спасибо, я исправил это - я ушел от того, что было сказано в ссылке, которую вы дали.

— перепроверять

Нет, к сожалению, это не решает проблему. Это делает синхронизацию файла, но получается разреженный файл на дальнем конце в не-разреженный файл. Я использую ssh / rsync, который поставляется с Ubuntu 9.04.

— Fadedbee

Мой комментарий выше был неверным. Проблема состояла в том, что rsync создает не разреженные файлы в своей первой копии. Rsync --inplace работает правильно, при условии, что целевой файл уже существует и имеет такую же длину (не большую), как исходный файл. Теперь у меня есть решение, но оно требует от меня проверить, существует ли каждый файл на целевом сервере. Если это так, я делаю --inplace, если нет, я использую --sparse. Это не идеально, но это работает.

— Fadedbee

rsync крайне неэффективен с огромными файлами. Смотрите мой комментарий на вопрос

— ndemou

4

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

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

— fadedbee
источник

4

TBH, указание времени, в которое вы можете синхронизировать, довольно бессмысленно, потому что оно, очевидно, зависит от количества измененных данных. Точнее сказать, что вашему программному обеспечению требуется 3 минуты, чтобы выяснить, какие блоки изменились, и даже эта скорость, вероятно, зависит от вашего дискового ввода-вывода и, возможно, циклов ЦП.

— Экстрактор реальности

6

Вы должны сообщить, что это коммерческое программное обеспечение, которое стоит 98 или более долларов за функциональность сети.

— Рейд

Спасибо, что указали нам на программное обеспечение, которое работало хорошо для вас, которое люди теперь могут рассматривать и использовать или не использовать по мере необходимости. Не спасибо за двух других людей за вклад ничего нового.

— Флориан Хейгл

3

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

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

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

— rkthkr
источник

2

lvmsync делает это.

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

— Tobu
источник

Я пробовал, но это не работает, и автор не хочет поддерживать

— user1007727

1

@ user1007727 не желает поддерживать или не хочет поддерживать бесплатно?

— Увядшая пчела

Я использовал lvmsync в прошлом, он работал, но это не программное обеспечение "prod grade" imo. :-)

— Флориан Хейгл

1

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

— Джеймс С
источник

Я не думаю, что drbd - это хорошее решение, но идея rsyncing - вместо целого fs, а не файлов образа диска, интересна. Я не уверен, позволяет ли rsync это сделать - я попробую и

— сообщу

1

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

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

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

— cstamas
источник

1

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

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

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

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

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

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

— ndemou
источник

0

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

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

— dyasny
источник