☰

背景

tag-icon • tag-icon linux backup nas rsync
背景

背景

仮想マシンをホストするサーバーが 1 台あり、それらの仮想マシンのバックアップ ターゲットとして古い NAS Synology DS1512+ が 1 台あります。サーバーは ZFS を使用してスナップショットを作成し、スナップショットのファイルを NAS に転送します。NAS は圧縮を有効にした BTRFS を使用し、スナップショットもサポートしています。最終的な目標は、サーバーが RSYNC を使用して DELTA のみを送信し、NAS が受信する変更データの量を最小限に抑え、NAS 上のスナップショットも効率的に使用することです。

問題

ただし、私のケースではRSYNCをDELTAと一緒に使用してもうまくいきません。データの転送には時間が多すぎる。RSYNC を で使用すると--inplace --whole-file、データの転送に約 2 時間かかります。DELTA--whole-fileを利用するために削除すると、同じバックアップ プロセスにさらに長い時間がかかり、12 時間以上実行した後にプロセスを強制終了することがよくありました。歴史的な理由から、さまざまなバックアップをはるかに短い時間枠に収める必要があります。

唯一意味のあるボトルネックとなるのは NAS です。サーバーの方がはるかに強力で、ほとんどの時間アイドル状態になっているためです。一方、NAS はバックアップ中に CPU と I/O にかなり高い負荷をかけます。ただし、数値はそれほど悪くはなく、 を使用したときよりも悪いだけです--whole-file。そのため、NAS は単純に ~100+ MiB/s で書き込みますが、DELTA を使用するとほとんどの場合読み取り速度が遅くなり、~50～100 MiB/s になります。DELTA のために書き込まれないデータの量は、NAS が遅いという事実を簡単に上回ると思いましたが、そうではないようです。また、VM 上の変更されたデータ量はほとんどそれほど多くありません。

観察

NAS で私が認識したのは、RSYNC が 2 つのファイルをある時点で同時に処理しているように見えることです。これは、先読みまたはそれに類似した動作のように見えます。

root@amds1512-01:~# lsof | grep [d]asi_
rsync   6883   root  cwd    DIR   0,33        290   259 /volume1/[...]
rsync   6883   root    0r   REG   0,33 2142633984   580 /volume1/[...]/[...]-s024.vmdk
rsync   6884   root  cwd    DIR   0,33        290   259 /volume1/[...]
rsync   6884   root    1r   REG   0,33 2143748096   579 /volume1/[...]/[...]-s023.vmdk
rsync   6884   root    3w   REG   0,33 2143748096   579 /volume1/[...]/[...]-s023.vmdk

HTOP は、RSYNC の両方のインスタンスが読み取りを行っていることを明確に示しています。他の RSYNC プロセスは無視してください。それらは無関係であり、1 つのバックアップが排他的に実行されても問題は解決しません。

スクリーンショット HTOP

質問

では、バックアップ ターゲット上の異なるファイルで 2 つの RSYNC を実行する目的は何でしょうか? RSYNC に、ファイルを 1 つずつ処理するように指示する方法はありますか?

これにより、同時負荷が少なくなり、全体的な処理時間が長くなる可能性があります。マニュアル ページには、read ahead やそれに類似するものは見つかりませんでした。違いがある場合は、次のオプションが使用されます。

--owner \
--numeric-ids \
--compress-level=0 \
--group \
--perms \
--rsh=rsh \
--devices \
--hard-links \
--inplace \
--links \
--recursive \
--times \
--delete \
--delete-during \
--delete-excluded \
--rsync-path=[...] \
--specials

ありがとう！

答え1

を見てみましょうRsyncの仕組み具体的には、パイプラインとして動作するジェネレータ プロセスと送信プロセスがあります。送信プロセスは、リモートに送信するファイルを読み取ります。ジェネレータは、送信するファイルのリストを生成する役割を担い、また「基本ファイルのブロック チェックサムを作成し、ファイルのインデックス番号の直後に送信プロセスに送信します。」

--inplaceこれは、複数の大きなファイルを送信するために使用する場合、ファイルシステムのスラッシングを引き起こす可能性があるようです。カーネルが2つの連続したファイルをキャッシュに保持するのに十分なRAMがありません。

テストとして、個々のファイルを で転送してみてrsync --inpace、パフォーマンスが大幅に向上するかどうかを確認できます。( のような形式ですfor i in *.vmdk; do rsync [...]; done。) これにより、2 つの個別のリーダーが実際にパフォーマンスの問題の原因となっているかどうかを判断するのに役立ちます。

複数の読者がいる場合はパフォーマンスの問題の原因となっている場合は、ホスト カーネルで使用できる RAM を増やすか、個々の vmdk ファイルを小さくして、カーネルの読み取りキャッシュ機能を改善することが 1 つの解決策となります。

残念ながら、rsyncのジェネレータ/センダーパイプラインの動作を変更する明白な方法は、各ファイルごとにrsyncを呼び出す独自のスクリプトを書く以外には見当たりません。これについては、rsync メーリングリスト。

関連情報