一方のシステムには常にマスターコピーがあり、もう一方のシステムには常に最新のコピー(48時間未満)があると仮定して、UNIXボックス間のsshミラーリングよりもrsyncを改善するための最良の手法は何ですか?
また、これらの変更のプッシュを取得する数十台のマシンを処理するために、そのアプローチを拡張するには何をする必要がありますか?
場合:
find -ctime
またはfile -cnewer
を使用して、最後の実行以降に変更されたファイルのリストを作成し、変更されたファイルのみをコピーできます(単に栄光の差分プッシュ)。
これは、複数のホストに対して非常にうまく変換されました。ソースで差分tarを実行し、すべてのホストでuntarします。
それはあなたにそのような何かを与えます:
find -type f -cnewer /tmp/files_to_send.tar.gz > /tmp/files_to_send.txt
tar zcf /tmp/files_to_send.tar.gz --files-from /tmp/files_to_send.txt
for Host in Host1 Host2 Host3 ...
do
cat /tmp/files_to_send.tar.gz | ssh $Host "tar xpf -"
done
スクリプトは洗練されていますが、あなたはその考えを理解しています。
同期しているデータがまだ圧縮されていないことを前提として、圧縮(-z)をオンにすると、転送速度が向上する可能性がありますが、両端のCPUがいくらか犠牲になります。
rsyncにはdisconnectedコピーを実行する方法があります。言い換えれば、rsyncは(概念的に)diffディレクトリツリーを生成し、patchファイルを生成し、後でそれを任意の数のファイルにapplyできます。元のソースと同じです。
マスターでrsyncを呼び出し、--write-batch
でミラーリングする必要があります。ファイルを生成します。次に、このファイルを他の任意の数のターゲットに転送し、次にバッチを適用--read-batch
を使用してそれらの各ターゲットに転送します。
最後に同期された状態のローカルコピー(つまり、現在のミラーの外観のコピー)をマスターと同じマシンに保持している場合、ミラーに接続しなくても、マスターでこの「パッチ」を生成できます。
マスターについて:
rsync --write-batch=my-batch.rsync /master/data /current/mirror
他に必要なオプションを追加します。これは2つのことを行います:
/current/mirror
を反映するように/master/data
を変更しますmy-batch.rsync
と呼ばれ、後で使用します。my-batch.rsync
ファイルをマスターからすべてのミラーに転送してから、ミラー上でパッチを適用いわば:
rsync --read-batch=my-batch.rsync /local/mirror
このアプローチの利点:
--read-batch
はミラー自体にCPU/ioのみを集中させるため)多くの変更を加えた非常に大きなファイルを転送する場合は、-inplaceオプションと--whole-fileオプションを使用します。これらを2Gb VMイメージに使用すると、(主に) rsyncプロトコルは、これらのファイルでインクリメンタルデータを渡すことをあまり行っていなかったため)。ただし、ほとんどの場合、これらのオプションはお勧めしません。
--statsを使用して、rsyncインクリメンタルプロトコルを使用してファイルがどの程度適切に転送されているかを確認します。
もう1つの戦略は、sshとrsyncを高速化することです。信頼できるネットワーク(読み取り:プライベート)を経由する場合は、実際のペイロードを暗号化する必要はありません。 HPN ssh を使用できます。このバージョンのsshは、認証のみを暗号化します。また、rsyncバージョン3は、ファイルリストの作成中にファイルの転送を開始します。もちろん、これはrsyncバージョン2に比べて大幅な時間の節約になります。それがあなたが探していたものかどうかはわかりませんが、それがお役に立てば幸いです。また、rsyncは何らかの方法でマルチキャストをサポートしていますが、その方法を理解しているふりはしません。
バックアップ方法としてrsyncを実行している場合、発生する最大の問題は、バックアップするファイルが多数ある場合です。 Rsyncは大きなファイルを問題なく処理できますが、バックアップするファイルの数が多すぎると、rsyncが妥当な時間内に完了しないことに気付くでしょう。これが発生した場合は、バックアップを小さな部分に分割してから、それらの部分をループする必要があります。
find /home -mindepth 1 -maxdepth 1 -print0 | xargs -0 -n 1 -I {} -- rsync -a -e ssh {} backup@mybackupserver:/backup/
または、ファイルセットをタールダウンしてファイル数を減らします。
数十台のマシンがこれらの変更のミラーを取得することに関しては、バックアップがどれだけ新鮮である必要があるかによって異なります。 1つのアプローチは、プライマリサーバーからバックアップサーバーへの変更をミラーリングしてから、最初のバックアップサーバーのrsyncデーモンによって他のサーバーに変更をバックアップサーバーからプルさせ、他のサーバーをわずかにプルするようにスケジュールすることです。異なる時間に、またはスクリプトでパスワードなしのsshを使用して各サーバーに接続し、バックアップの新しいコピーをプルするように指示することで、最初のバックアップサーバーを圧倒するのを防ぐことができますが、それほど多くの問題が発生するかどうかは状況によって異なりますバックアップのコピーをプルしている他のマシンの数。