Кто-нибудь достиг истинной дифференциальной синхронизации с rsync в ESXi?

Позже ругайте меня за то, что я использую сервисную консоль, чтобы делать что-нибудь в ESXi ...

У меня есть рабочий бинарный файл rsync (v3.0.4), который я могу использовать в ESXi 4.1U1. Я склонен использовать rsync поверх cp при копировании ВМ или резервных копий из одного локального хранилища данных в другое локальное хранилище данных. Я использовал 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 во время операции? Как быстро вы можете прочитать файл 80GB с диска? Это будет около вашего абсолютного минимального времени передачи.

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

Короче говоря, у вас может быть только 2 ГБ изменений, но rsync выполняет МНОГО работы. Вы, вероятно, связаны с вводом-выводом, поскольку чтение и запись на одном и том же диске могут вызвать много споров и замедлений.

Эта тема очень старая, но может кому-то она поможет.

Поскольку ESX блокирует файловую систему при каждой записи новых блоков, производительность не так уж велика, с опцией - на месте вы можете получить лучшие результаты, но имейте в виду, что если вы отмените синхронизацию, файл не будет согласованным Больше. Что касается согласованности, rsync открытого файла может быть непоследовательным -> лучше использовать снимок перед rsync.

С наилучшими пожеланиями Марк

Судя по всему, вы делаете локальную копию с rsync. В этом случае стандартным поведением rsyncявляется отключение алгоритма дельта-передачи и выполнение передач «всего файла». Обоснование этого поведения по умолчанию состоит в том, что локальные передачи с использованием алгоритма delta-xfer обычно выполняются медленнее, чем простое копирование файлов целиком, поскольку алгоритм delta включает в себя гораздо больше перегрузок ЦП, чем просто копирование всего файла.

Если вы чувствуете, что локальное копирование выиграет от использования алгоритма delta-xfer, вы можете принудительно rsyncиспользовать его, указав --no-W(или --no-whole-file) параметр.