☰

有人在 ESXi 中使用 rsync 实现真正的差异同步吗？

tag-icon • tag-icon vmware-esxi vmware-esx rsync
有人在 ESXi 中使用 rsync 实现真正的差异同步吗？

稍后再责骂我，因为我使用服务控制台在 ESXi 中执行任何操作......

我有一个可以在 ESXi 4.1U1 中使用的可运行的 rsync 二进制文件 (v3.0.4)。在将虚拟机或备份从一个本地数据存储复制到另一个本地数据存储时，我倾向于使用 rsync 而不是 cp。我曾使用 rsync 将数据从一个 ESXi 盒复制到另一个，但那只是针对小文件。

现在尝试对通过以下方式获取的备份进行真正的差异同步贫民窟VCB在我的主 ESXi 机器和辅助 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 的实际差异同步吗？

答案1

看起来您只传输了 2GB 的增量更改。请记住，rsync 仍必须读取整个文件并对其进行校验和，因此它必须读取 80GB 的数据。在 rsync 期间检查您的服务器统计数据。操作期间您是否受到 CPU 或 IO 限制？您能多快从磁盘读取 80GB 文件？这将接近您的绝对最短传输时间。

还要注意的是，rsync 在传输时会复制文件，然后以原子操作将最终文件移动到位。您可以通过在目标目录中传输过程中看到带有随机后缀的类似文件名来了解这一点。这意味着您必须读取 160GB 的数据（每个源和目标各 80GB）并在目标端写出 80GB。您看过 --inplace 选项了吗？它可能在这里很有用。

简而言之，您可能只有 2GB 的更改，但 rsync 正在做大量工作。您可能受到 IO 限制，因为在同一磁盘上进行所有读取和写入可能会导致大量争用和速度减慢。

答案2

这个帖子很老了，但希望它能对某些人有所帮助。

由于 ESX 在每次写入新块时都会锁定文件系统，因此性能不是很好，使用选项 --inplace 可能会获得更好的结果，但请注意，如果取消同步，文件将不再一致。关于一致性，打开文件的 rsync 无论如何都可能不一致 -> 最好在 rsync 之前使用快照。

马克

答案3

从表面上看，您正在使用 进行本地到本地的复制rsync。在这种情况下， 的默认行为rsync是关闭增量传输算法，并进行“整个文件”传输。这种默认行为的理由是，使用增量传输算法的本地到本地传输通常比简单地复制整个文件要慢，因为增量算法涉及的 CPU 运算比仅仅进行整个文件复制要多得多。

如果您认为使用 delta-xfer 算法对本地到本地的复制有益，则可以通过指定(或) 选项强制rsync使用它。--no-W--no-whole-file

相关内容