rsync を使用して、2 つの NFS サーバー間のデータを同期します。 NFS サーバー 1 つは東海岸にあり、もう 1 つは西海岸にあります。 RTTは約110msです。
East Coast NFSサーバーにWest Coast NFSサーバーのマウントポイントをインストールしました。
<server>:/home/backups on /mnt/backups type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=krb5,clientaddr=x.x.x.x,local_lock=none,addr=y.y.y.y)。
データは、データを確認するために（たとえば、フォルダの同期や変更が不要な場合など）、すでに両方のサーバーに存在します。 7 GB フォルダーを持つ東海岸サーバーが西海岸サーバーと同じであることを確認するのにかかる時間は、次のとおりです。
次の操作は、7GB以上のデータで完了するのに約8分かかります。
rsync -r -vvvv --info=progress2 --size-only /<local_path>/ /<remote_path>/
次へ（NFSマウントを無効にする）は、7 GBを超えるデータを完了するのに約15秒かかります（同じ）。
rsync -r -vvvv --info=progress2 --size-only /<local_path>/ <user>@<west_cost_NFS>:/<remote_path>/
繰り返しますが、フォルダはすでに同期されているため、上記の方法はデータを移動せずにファイルサイズに基づいてデータが同じであることを確認します。
-o asyncクライアントとサーバーの両方で使用しようとしましたが、クライアントで "mount"を実行すると、クライアントは/etc/exports asyncまったく表示されません。async私はasyncそれがデフォルトだと思います。 rsize、wsizeも大きな値に変更してみましたが、パフォーマンスは良くありませんでした。 NFSでより良いパフォーマンスを得ることはできますか？
ベストアンサー1
私の考えでは、rsyncを使用しようとする試みが間違っていました。 Rsyncのプロトコルは、2つの別々のサーバーで大容量ファイルシステムを比較/同期する正確なシナリオ用に設計されています。可能な限りローカルで実行されます。両方中間で比較される前のローカルおよびリモートシステム。
このプロトコルは、あるシステムのrsyncエージェントが別のシステムのrsyncエージェントと通信するように設計されており、プロトコルはタスクを完了するために必要な往復回数（および総データ）を大幅に減らすように設計されています。
rsync は以下のために設計されています。
[fast] [slow SSH] [fast]
File system <----> rsync <----------> rsync <----> File system
Rsyncは2つのエージェント間のネットワークパフォーマンスに最適化されていますが、ディスクアクセスに使用されるプロトコルを制御することはできません。したがって、リモートNFSファイルシステムをマウントすると、ネットワークアクセスプロファイルが変更されます。
[fast] [fast] [slow NFS]
File system <----> rsync <------> rsync <---------> File system
RsyncはNFSプロトコルをまったく制御できないため、これについて何もできません。
ここでの1つの具体的な違いは、NFSの場合、各ファイルは次のようにする必要があることです。個別に頼む。含まれているファイルツリーを参照するには、[wait]を要求し、[wait]を要求し、[wait]を要求し、最後にを要求する必要があります/foo/bar/baz。要求ごとの待ち時間は110msです。つまり、待ち時間は330msで、ファイルは1つだけインポートされます。//foo/foo/bar/foo/bar/baz
ブローカ間の Rsync プロトコルにはこの制限はありません。リモートシステムで実行されているエージェントは、同期しているリモートファイルシステム上のすべてのファイルとディレクトリのリストを一生懸命コンパイルしてすべてを送信します。完全なファイルツリーの要求は単一です！
バラよりrsyncの仕組み