Позже ругайте меня за то, что я использую служебную консоль для чего-либо в ESXi ...
У меня есть рабочий двоичный файл rsync (v3.0.4), который я могу использовать в ESXi 4.1U1. Я обычно использую rsync over cp при копировании виртуальных машин или резервных копий из одного локального хранилища данных в другое локальное хранилище данных. Я использовал rsync для копирования данных из одного блока ESXi в другой, но это было только для небольших файлов.
В настоящее время пытается выполнить настоящую дифференциальную синхронизацию резервных копий, сделанных через гетто между моей основной машиной ESXi и дополнительной. Но даже когда я делаю это локально (одно хранилище данных в другое хранилище данных на той же машине ESXi), rsync, похоже, копирует файлы полностью. У меня есть два VMDK размером всего 80 ГБ, а 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. Вы связаны с процессором или вводом-выводом во время операции? Как быстро вы можете прочитать файл размером 80 ГБ с диска? Это будет около вашего минимального времени передачи.
Также следует отметить, что rsync делает копию файла при передаче, а затем перемещает окончательный файл на место в атомарной операции. Вы можете увидеть это, увидев похожее имя файла со случайным суффиксом во время передачи в целевом каталоге. Это означает, что вам необходимо прочитать 160 ГБ данных (по 80 ГБ для каждого источника и назначения) и записать 80 ГБ на стороне назначения. Вы смотрели на параметр --inplace? Здесь может быть полезно.
Короче говоря, у вас может быть только 2 ГБ изменений, но rsync выполняет ОЧЕНЬ много работы. Вероятно, вы привязаны к вводу-выводу, поскольку все это чтение и запись на одном диске может вызвать много конфликтов и замедлений.
Эта тема очень старая, но может она кому-нибудь поможет.
Поскольку ESX блокирует файловую систему при каждой записи новых блоков, производительность не так велика, с опцией --inplace вы можете получить лучшие результаты, но имейте в виду, что если вы отмените синхронизацию, файл не будет согласованным. Больше. Что касается согласованности, rsync открытого файла может быть несовместимым в любом случае -> лучше использовать снимок перед rsync.
С уважением, Марк
Судя по всему, вы делаете локальную копию с rsync. В этом случае поведение по умолчанию rsync заключается в отключении алгоритма дельта-передачи и выполнении передачи "всего файла". Обоснование этого поведения по умолчанию заключается в том, что передача от локального к локальному с использованием алгоритма дельта-xfer обычно будет медленнее, чем простое копирование целых файлов, поскольку дельта-алгоритм требует гораздо большей нагрузки на ЦП, чем просто копирование всего файла.
Если вы чувствуете, что для копирования с локального на локальное было бы полезно использовать алгоритм delta-xfer, вы можете принудительно rsync использовать его, указав --no-W (или --no-whole-file) вариант.