Як ви синхронізуєте величезні розріджені файли (зображення диска VM) між машинами?

Чи є така команда, як rsync, яка може синхронізувати величезні, розріджені файли з одного Linux-сервера на інший?

Дуже важливо, щоб файл призначення залишався рідким. Він може бути довшим (але не більшим), ніж накопичувач, який його містить. Лише змінені блоки повинні надсилатись через провід.

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

Якщо я напишу програму для цього, я просто винаходити колесо? http://www.finalcog.com/synchronise-block-devices

Спасибі,

Кріс.

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

Створення нових файлів у розрідженому режимі

Слідом за

rsync --inplace ...

Щоб оновити всі наявні файли (включаючи раніше створені розріджені) на місці.

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 Я залишаю точну поведінку для вас, щоб шукати на сторінці man.

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

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 

Погляньте на Zumastor Linux Storage Project, він реалізує резервну копію "знімка", використовуючи двійкову "rsync" через ddsnapінструмент.

З чоловічої сторінки:

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

lvmsync робить це.

Ось стенограма використання . Він створює знімок LVM на джерелі, передає логічний розділ. Ви можете переносити поступові оновлення змін після створення знімка так часто, як вам зручно.

Чи може тиражування всієї файлової системи бути рішенням? DRBD? http://www.drbd.org/

Можливо, трохи дивно тут, але нещодавно я дізнався, що NFS справляється із цим штрафом.

Отже, ви експортуєте каталог на одній машині, після чого змонтуєте його на іншому, і ви просто скопіюєте файли з базовими утилітами cp. (Деякі старі / стародавні утиліти можуть мати проблеми з розрідженими файлами.)

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

Для синхронізації величезних файлів або блокових пристроїв з низькими та помірними різницями ви можете зробити звичайну копію або використовувати bdsync , rsync абсолютно не підходить для цього конкретного випадку *.

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

bdsyncчитає файли з обох хостів та обміняє контрольні суми, щоб порівняти їх та виявити відмінності. Все це одночасно . Нарешті створюється стислий патч-файл на вихідному хості. Потім ви переміщаєте цей файл до цільового хосту і запускаєте bdsync вдруге, щоб виправити файл призначення.

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

*: rsync дуже неефективний з величезними файлами. Навіть з --inplace, він спочатку прочитає весь файл на хості призначення, AFTERWARDS починає читати файл на вихідному хості та, нарешті, переносить відмінності (просто запустіть dstat або подібне під час роботи rsync та спостерігайте). Результат полягає в тому, що навіть для файлів з невеликими різницями для читання файлу потрібно подвоїти час, який вам потрібно прочитати, щоб синхронізувати його.

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

Я не знаю про таку утиліту, лише про системні дзвінки, які можуть це впоратися, тому, якщо ви пишете таку утиліту, це може бути досить корисним.

що ви насправді можете зробити, це використовувати qemu-img converter для копіювання файлів, але це буде працювати лише в тому випадку, якщо FS призначення підтримує розріджені файли