誰かがESXiのrsyncで真の差分同期を達成しましたか?


11

ESXiで何かをするためにサービスコンソールを使用しているという事実について、後で私を苦しめます...

ESXi 4.1U1で使用できる作業用のrsyncバイナリ(v3.0.4)があります。あるローカルデータストアから別のローカルデータストアにVMまたはバックアップをコピーするときに、cpでrsyncを使用する傾向があります。rsyncを使用してデータを1つのESXiボックスから別のESXiボックスにコピーしましたが、これは小さなファイル用です。

現在、プライマリESXiマシンとセカンダリマシンの間でghettoVCBを介して取得したバックアップの真の差分同期を実行しようとしています。ただし、これをローカルで(同じESXiマシン上の1つのデータストアから別のデータストアに)実行しても、rsyncはファイル全体をコピーするように見えます。サイズが80GBのVMDKが2つあり、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との実際の差分同期を達成しましたか?


rsynceはデフォルトで増分です。信じがたいですが、本当です。ESXiで動作するrsynceのダウンロード先を知りたいです。ESXi 4.1を使用しています

回答:


6

2GBの増分変更のみを転送したようです。rsyncは1つのファイル全体を読み取ってチェックサムする必要があるため、80GBのデータを読み取る必要があることに注意してください。rsync中にサーバーの統計を確認してください。操作中にCPUまたはIOにバインドされていますか?ディスクから80GBのファイルをどれだけ速く読み取ることができますか?それはあなたの絶対最小転送時間に近いでしょう。

また、rsyncは転送中にファイルのコピーを作成し、アトミック操作で最終ファイルを所定の場所に移動します。これは、宛先ディレクトリでの転送中にランダムな接尾辞を持つ類似のファイル名を表示することで確認できます。つまり、160GBのデータ(各ソースと宛先ごとに80GB)を読み取り、宛先側で80GBを書き出す必要があります。--inplaceオプションを見ましたか?ここで役に立つかもしれません。

要するに、2GBの変更しかできないかもしれませんが、rsyncは多くの作業を行っています。同じディスク上で読み取りと書き込みを行うと、多くの競合とスローダウンが発生する可能性があるため、おそらくIOにバインドされています。


bot403にご連絡いただきありがとうございます。転送されたバイト数が大幅に少ないことに気付きましたが、まだ30〜45分以上の待機時間を見ていました。同様に、ファイル全体を再送信することもできます。ここにはIOのボトルネックが存在する可能性がありますが、それはESXi内にあり、ハードウェアにはあまりないと思います。LUNに移動してテストします。どうもありがとう。
JuliusPIV

4

このスレッドは非常に古いですが、誰かの助けになるかもしれません。

ESXは新しいブロックの書き込みごとにファイルシステムをロックするため、パフォーマンスはそれほど優れていません。オプションを使用すると、より良い結果が得られる場合がありますが、同期をキャンセルすると、ファイルの一貫性が失われることに注意してくださいもっと。一貫性については、開いているファイルのrsyncが何らかの方法で矛盾する可能性があります-> rsyncの前にスナップショットを使用する方が適切です。

よろしくマーク


2

見た目では、あなたはローカルからローカルへのコピーをしていrsyncます。その場合、のデフォルトの動作はrsync、デルタ転送アルゴリズムをオフにし、「ファイル全体」の転送を行います。このデフォルトの動作の理論的根拠は、delta-xferアルゴリズムを使用したローカルからローカルへの転送は、単にファイル全体をコピーするよりも遅くなることです。

ローカルからローカルへのコピーがdelta-xferアルゴリズムrsyncを使用することでメリットがあると思う場合は、--no-W(または--no-whole-file)オプションを指定して強制的に使用できます。


スティーブン!正しい:私は純粋にテスト目的でローカルコピーを行っています(別名、実際に差分同期を行うことを確認するため)。最終的に、ファイルはローカルデータストア(リモートマシンにある公開済みのLUN)にコピーされます。実際には、rsync-to-rsyncデーモンタイプの同期ではありません。その価値のため--no-whole-fileに、rsyncコマンドの一部としてオプションを使用しています。その画面のビューを超えています。
JuliusPIV

@Julius:おっと、その水平スクロールバーを見逃した!まあ、時間を無駄にしてすみません。
スティーブン月曜日
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.