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の仕組み
答え2
あなたの前提が間違っています。 NFSを介してファイルシステム比較を実行すると、大量のデータ（ファイルのメタデータ）が移動されます。大きなツリーの場合は、それぞれ遅延時間を持つ個々の要求がたくさんあります。
SSH接続を介してrsyncを使用すると、検証のためにリモート側のファイル名とメタデータストリームが送信されます。ファイルの数とメタデータの量は同じかもしれませんが、ストリーミングされるため、全体の待ち時間は非常に低くなります。
110ミリ秒のRTTを使用すると、8分ではなく15秒を簡単に取得できます。
ああ、そして起動時にフラグを（以上）または（十分）rsyncに置き換えてください。ファイルのタイムスタンプが含まれていない場合、接続の両端にあるファイルは最終的にお互いに比較して古いと見なされます。-r-a-rtrsync
答え3
以前はRHEL 7.9を使用し、現在（2023年2月）はRHEL 8.7を使用していますが、RHEL 7.9でNFS vers = 4.2を操作できなかったと言うことができます。 vers = 4.1のとき最大値に達します。そして、元のインストール状態で/etc/nfs/nfs.confファイルを変更しなかった場合にのみ可能です。/etc/sysconfig/nfs
この記事で述べたNFSv4とNFSv4.1のいくつかのレビューによれば、これらのバージョンには帯域幅とスケーラビリティが制限されており、ネットワークトラフィックが多いとNFSが遅くなる可能性があります。 NFSv4.2は帯域幅とスケーラビリティの問題を改善したことが知られています。 2022年4月に最終更新されました。
https://www.techtarget.com/searchenterprisedesktop/definition/Network-File-System
私は最近このような質問をしました。
4.2バージョンの代わりにNFS 3を使用する理由はありますか？
だから私の考えでは最近NFSをプレイした経験によると、NFSを入手してvers=4.2使用proto=rdmaできない場合おそらくnfs v3をUDPとして使用すると、最高のパフォーマンスを実現できます。特にnfsサーバーasyncに割り当てられます。/etc/exportfs네 말이 맞아, 넌 볼 수 없는 거야非同期nfsクライアントではマウントオプションと呼ばれており、これをテストした後、rsync -P test_60gb.tar /nfsmount 修正を使用するとすぐに/etc/exports50MB / secから100MB / secに変更されることが観察されましたexportfs -arv。持つproto=tcp そして syncNFSのパフォーマンスには確かに悪いです。
まだ試してみる機会がなかったしproto=udp、事実するのが大変です。