RHEL6 NFSv4 クライアントは NFSv3 のように動作しますか?

RHEL6 NFSv4 クライアントは NFSv3 のように動作しますか?

私の理解では、NFSv4 クライアントは、rpcbind ポートマッパーと mountd サービスのやり取りを完全にスキップして、サーバー上の NFSv4 サービスにすぐに接続する必要がありますが、RHEL6 クライアントは常に最初に rpcbind サービスに接続して mountd ポートを取得し、mountd からエクスポートのリストを取得してから、最終的に NFSv4 サービスに接続していることがわかります。tcpdump を使用して確認しました。

すべての表示 (マウント コマンドの出力と TCP の検査) によると、マウント操作が完了すると、クライアントとサーバーは NFSv4 を使用します。

これは、クライアント上で NFSv4 のみを強制するために私が試したすべてのことを行った場合でも発生します。例:

  • /etc/nfsmount.conf で Nfsvers=4 を設定する
  • vers=4 オプションで明示的にマウントする
  • NFS ポートを明示的に設定します。(マウント コマンドおよび nfsmount.conf 経由)

私の考えは完全に的外れでしょうか、それとも何かがおかしいのでしょうか? これは私にとって問題です。NFS クライアントは、NFSv4 エクスポートをマウントする前に、UDP 経由でサーバー上の rpcbind にアクセスできることを要求し、不可解な UDP パケット損失 (はい、私はこの件でネットワーク担当者と協力しています) が発生し、マウントが時々完全に失敗したり、完了するまでに長い時間がかかったりするからです。

libtirpc のソースを調べたところ、RPC ポートマッパーに接続するために常に UDP が使用されることがわかりましたが、ポートマッパーと mountd サービスを完全に排除したいと考えています。

「rpcinfo -d」を使用して NFS サーバー上の UDP ポートマッパー サービスの登録を解除しようとしましたが、その結果、そのサーバーをターゲットとするすべての NFS マウントが失敗しました (この場合も、クライアントは、サーバーが rpcbind を UDP ポート 111 でリッスンするように要求します)。また、/etc/netconfig をいじってみましたが、うまくいきませんでした。

この動作に遭遇した人、または NFSv4 について十分な知識があり、私が非現実的な期待を抱いていると言える人はいますか?

答え1

私はこれを autofs までさかのぼって調べました。これは、showmount コマンドを使用してエクスポートのリストを取得するために /etc/auto.net を使用するように設定されていました。showmount コマンドは、NFS マウントが行われる前に rpcbind と mountd へのアクセスを担当していたため、マウント オプションを変更しようとしても効果がありませんでした。

/etc/auto.net を修正したら問題は解決しました。

補足: さまざまな場所で見たように、auto.master で「-hosts」オプションを使用すると、rpcbind および mountd アクセスも発生しました。最終的には、auto.net ですべての NFSv4 サーバーのルートをマウントするだけになりましたが、すべてのホストが NFSv4 であると仮定すれば、これで問題ないと思います。

関連情報