NFS サーバーの再起動後の NFS 古くなったファイルハンドル: なぜこのようなことが起こるのか、また業界ではどのように対処しているのか?

Question 1

NFS バージョン 3 を使用していますが、ポート 2049 のメイン NFS サービスに加えて、いくつかのヘルパーサービスが必要です。これらの 1 つはでrpc.statd、再起動の検出と再起動後の NFS ロックの回復/クリアに重要な役割を果たします。

これらのヘルパーサービスはランダムなポートに配置され、RPC ポートマッパー (通常、rpcbind最近の Linux ではプロセス名が付けられています) に接続することで検出されます。ファイアウォールを備えた最近のネットワークでは、このような動作によって状況が複雑になることがあります。再起動後には確定的なポートにヘルパーサービスが配置されているように見えても、NFS サービスを再起動すると、まったく異なるポート番号に割り当てられる場合があります。

幸いなことに、多くの最近の Unix 系システムでは、NFS ロックマネージャー (歴史的にはrpc.lockd、現在では通常カーネル内に実装されています)のポート番号をロックダウンできます。これrpc.statdはrpc.mountd、NFSv3 を何らかの信頼性でファイアウォールに通過させたい場合に不可欠です。

RHEL および関連ディストリビューションの場合、次の行を追加することで NFS ヘルパーポート番号をロックダウンできます/etc/sysconfig/network。

LOCKD_TCPPORT=4045
LOCKD_UDPPORT=4045
STATD_PORT=4046
MOUNTD_PORT=4047

Debian および関連ディストリビューションの場合は、次の行を追加します/etc/modprobe.d/nfs.conf。

options lockd nlm_udpport=4045 nlm_tcpport=4045

...そして次の行/etc/default/nfs-common:

STATDOPTS="-p 4046"

...そして次の行/etc/default/nfs-kernel-server:

RPCMOUNTDOPTS="-p 4047" # you may want to add a --manage-gids option here

(必要に応じて別のポート番号を使用することもできますが、Solaris の NFSv3 ロックマネージャーのデフォルトポートは 4045 であり、HP-UX 11.31 でも同様にハードコードされています。)

しかし、NFSv3 プロトコルには別の落とし穴があります。IP アドレスだけを使用して NFS 共有をマウントすることはできますが、NFSv3 ロックプロトコルは内部的にホスト名を使用します。クライアントとサーバーの両方が正しい名前で互いを認識している必要があります。そうしないと、再起動後の NFS ファイルロックとロック回復が機能しません。各システムの「正しい名前」は、によって報告される名前ですuname -n。

したがって、サーバーとクライアントでそれぞれがuname -n返される場合は、それらの正確な名前が、ホストが NFS に使用する必要のある IP アドレスに解決されることを確認する必要があります。言い換えると、サーバーは名前を使用してクライアントに接続でき、その逆も同様である必要があります。server.exampleclient.examplerpc.statdclient.example

そうしないと、最初はすべて正常に動作しているように見えるかもしれませんが、どちらかの側が再起動すると、Stale file handleエラーが発生する可能性があります。

Answer