Хтось домігся справжньої диференціальної синхронізації з rsync в ESXi?

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

У мене працює бінарний rsync (v3.0.4), який я можу використовувати в ESXi 4.1U1. Я схильний використовувати rsync через cp при копіюванні VM або резервного копіювання з одного локального сховища даних в інший локальний сховище даних. Я використовував rsync для копіювання даних з одного вікна ESXi в інший, але це було лише для невеликих файлів.

Зараз я намагаюся зробити справжні диференціальні синхронізації резервних копій, зроблених через ghettoVCB між моєю основною машиною ESXi та вторинною. Але навіть коли я роблю це локально (один сховище даних в інший сховище даних на тій же машині ESXi), rsync, як видається, копіює файли в повному обсязі. У мене є два VMDK абсолютно 80GB в розмірі, і Rsync по- , як і раніше займає де -то між 1 і 2 години , але VMDK - й не ростуть , що багато щодня.

Нижче наведена команда rsync, яку я виконую. Я копіюю локально, оскільки в кінцевому рахунку ці файли будуть скопійовані в сховище даних, створене з LUN на віддаленій системі. Це не rsync, який буде обслуговуватися демоном rsync у віддаленій системі.

rsync -avPSI VMBACKUP_2011-06-10_02-27-56/* VMBACKUP_2011-06-01_06-37-11/ --stats --itemize-changes --existing --modify-window=2 --no-whole-file
sending incremental file list
>f..t...... VM-flat.vmdk
 42949672960 100%   15.06MB/s    0:45:20 (xfer#1, to-check=5/6)
>f..t...... VM.vmdk
         556 100%    4.24kB/s    0:00:00 (xfer#2, to-check=4/6)
>f..t...... VM.vmx
        3327 100%   25.19kB/s    0:00:00 (xfer#3, to-check=3/6)
>f..t...... VM_1-flat.vmdk
 42949672960 100%   12.19MB/s    0:56:01 (xfer#4, to-check=2/6)
>f..t...... VM_1.vmdk
         558 100%    2.51kB/s    0:00:00 (xfer#5, to-check=1/6)
>f..t...... STATUS.ok
          30 100%    0.02kB/s    0:00:01 (xfer#6, to-check=0/6)

Number of files: 6
Number of files transferred: 6
Total file size: 85899350391 bytes
Total transferred file size: 85899350391 bytes
Literal data: 2429682778 bytes
Matched data: 83469667613 bytes
File list size: 129
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 2432530094
Total bytes received: 5243054

sent 2432530094 bytes  received 5243054 bytes  295648.92 bytes/sec
total size is 85899350391  speedup is 35.24

Це тому, що ESXi сам вносить стільки змін у VMDK, що, що стосується rsync, весь файл повинен бути повторно переданий?

Хтось насправді досягнув фактичної синхронізації з ESXi?

Схоже, ви перевели лише 2 Гб додаткових змін. Пам'ятайте, що rsync все ще має читати в одному цілому файлі і контрольну суму, щоб він мав зчитувати 80 ГБ даних. Перевірте статистику вашого сервера під час rsync. Ви пов'язані процесором чи IO під час операції? З якою швидкістю ви можете прочитати файл з 80 Гб з диска? Це буде майже ваш мінімальний час переказу.

Також слід зазначити, що rsync робить копію файлу під час передачі, а потім переміщує остаточний файл на місце в атомній операції. Це можна побачити, побачивши подібне ім'я файлу з випадковим суфіксом під час передачі в каталозі призначення. Це означає, що вам потрібно прочитати 160 ГБ даних (по 80 ГБ для кожного джерела та місця призначення) та виписати 80 ГБ на стороні призначення. Ви переглянули варіант --inplace? Тут може бути вигідно.

Коротше кажучи, у вас може бути лише 2 ГБ змін, але rsync виконує багато роботи. Ви, мабуть, пов'язані IO, оскільки все, що читання і запис на одному диску може викликати багато суперечок і уповільнення.

Ця нитка дуже стара, але може комусь допомогти.

Оскільки ESX блокує файлову систему під час кожного запису нових блоків, продуктивність не така вже й велика, з Варіантом - замість цього ви можете отримати кращі результати, але будьте в курсі, якщо ви скасуєте синхронізацію, файл не буде відповідати жодному більше. Щодо узгодженості, rsync відкритого файлу може бути непослідовною у будь-якому випадку -> краще використовувати знімок перед rsync.

З найкращими побажаннями Марк

По зовнішньому вигляду ви робите локальну копію для локальної копії rsync. У такому випадку поведінка за замовчуванням - rsyncце вимкнути алгоритм передачі дельти та виконувати передачі "весь файл". Обґрунтуванням такої поведінки за замовчуванням полягає в тому, що передача місцевих даних на місцеві за допомогою алгоритму дельта-xfer зазвичай буде повільнішою, ніж просто копіювання цілих файлів, оскільки алгоритм дельти передбачає набагато більше стискання процесора, ніж просто копіювання цілих файлів.

Якщо ви вважаєте, що від використання алгоритму delta-xfer виграє місцева локальна копія, ви можете змусити rsyncїї використовувати, вказавши параметр --no-W(або --no-whole-file).