☰

サーバーが再起動すると、NFSクライアントは回復されません。

tag-icon • tag-icon mount nfs
サーバーが再起動すると、NFSクライアントは回復されません。

2つのマシンがあります。 (a) は NFS サーバー、(b) は NFS クライアントです。
コンピュータ（a）が再起動したら、再起動せずにコンピュータ（b）からNFSクライアントを回復する方法はありますか？

答え1

その言葉がどういう意味なのかは分かりませんが、そのrecover意味ならremount簡単ですsudo mount -a。

答え2

あなたは試すことができますumount -f mountpoint

Windows NFSサーバーに接続されているRHEL 7システムでこの現象が頻繁に発生します。 umount コマンドは失敗しますが、クライアントの実行を妨げるすべてのエントリを解放します。

答え3

少なくとも3つの可能な問題点があります。

  • rpc.statdおよび対応するポート割り当て
  • NFSプロトコルで内部的に使用されるホスト名
  • fsidサーバー側の非永続的に割り当てられたファイルシステムID

rpc.statd

NFS共有がハードマウントされている場合、共有にアクセスするすべてのプロセスはNFSサーバーの再起動中に中断されますが、NFSサーバーが完全に起動して再実行されると自動的に再開されます。もしそうならないなら、何か間違っています。

NFSバージョン4のすべてのリカバリ機能は同じネットワークポート（通常は2049 / TCP）を使用しますが、以前のバージョンのプロトコルには通常と呼ばれる別のサービスとしてネットワークヘルスモニタサブプロトコルがありますrpc.statd。このプロセスはクライアントで実行する必要があります。そしてrpc.statdNFSクライアントとサーバーの両方が互いにネットワークに接続できる必要があります。そうしないと、2 つのシステムのいずれかを再起動した後に NFS 接続が正しく回復しないことがあります。 （望むよりman sm-notify詳細が必要な場合。NSM OPERATION IN DETAIL;はsm-notify、再起動通知を事前に送信するコンポーネントですrpc.statd。という段落を見つけてください。 )

歴史的にrpc.statd動的に割り当てられたポート番号がある場合は、まずportmapper/rpcbindサービス（常にポート111、UDP、およびTCP）に現在使用されているポート番号を照会する必要がありますrpc.statd。

このように動的に割り当てられたポートは、最新のファイアウォールネットワークでは望ましくありません。ベストプラクティスは、必要最小限のポート数でのみトラフィックを許可するためです。したがって、NFSv2 / v3サーバーとそのクライアントの間にファイアウォールがある場合は、rpc.statdNFSv2 / v3サブプロトコルと他のNFSv2 / v3サブプロトコルに固定ポート番号を使用させることは、NFSの信頼性を向上させる重要なステップです。

正確なプロセスは、オペレーティングシステムとそのバージョンによって異なります。結局のところ、プロセスにオプションとポート番号を追加するという問題で終わりますが、rpc.statd多くのオペレーティングシステムとLinuxディストリビューションにはいくつかの機能が含まれているため、コメントを外すことができます。起動設定ファイルの設定またはスクリプトのシェル変数rpc.statd。

NFSv3サーバーでは、および/rpc.mountdのポート番号も固定値でロックする必要があります。クライアントは気にします（NFSでファイルロックを使用することもできます）。lockdnlockmgrrpc.statdlockd

RHEL 7以下では、最後に次の行を追加することでこれを達成できます/etc/sysconfig/network。

LOCKD_TCPPORT=4045
LOCKD_UDPPORT=4045
STATD_PORT=4046
MOUNTD_PORT=4047
# PCNFSD_PORT=4048
RQUOTAD_PORT=4049

RHEL 8以降には、.txtファイルにコメントされた行の例があります/etc/nfs.conf。行をコメントアウトして編集して、次のように生成します。

[lockd]
port=4045
udp-port=4045

[mountd]
port=4047

[statd]
port=4046

Debianと関連ディストリビューションで必要な設定は他のファイルにあります。

  • STATDOPTS="-p 4046"存在する/etc/default/nfs-common
  • RPCMOUNTDOPTS="-p 4047"存在する/etc/default/nfs-kernel-server
  • options lockd nlm_udpport=4045 nlm_tcpport=4045in /etc/modprobe.d/nfs-options.conf（存在しない場合は作成）。

これらの設定を追加して適切なNFSサービスを再起動（または再起動）した後、rpcinfo -pNFSv3サブプロトコルが固定ポート番号を取得することを確認できます。

(上記のポート番号図NetApp NASデバイス用のNFSv3サービスデフォルトでは使用されますが、NetApp はrpc.mountdポート 635 に配置されます。 )

CPU名

プロトコルはrpc.statdIP アドレスではなくホスト名を使用します。クライアントとサーバーの両方がIPアドレスに標準のホスト名を見つけることができる必要があります。これが不可能な場合、sm-notify有効な再起動通知をNFS接続の反対側に送信できず、再起動後に回復が失敗する可能性があります。

NFSプロトコルには非対称性があります。 NFSサーバーはクライアントのホスト名（caller_nameNFSプロトコルではsと呼ばれます）を自動的に学習してサーバーに提供しますrpc.statdが、クライアントにサーバーのホスト名を知らせる同等の対話はありません。したがってmount、IPアドレッシングコマンドを使用し、クライアントがそのIPアドレスをホスト名にリバースマップできない場合、クライアントはNFSサーバーに再起動通知を送信したときにNFSサーバーが自分で呼び出す名前を知ることはできません。顧客rpc.statd。

mountこれは、成功したサーバーの再起動からNFSマウントを自動的に回復したい場合は、コマンドにIPアドレスを使用するのが悪いことを意味します。また、クライアントmountコマンドで使用されている名前がNFSサーバーで実際に使用されている名前と一致することを確認する必要があります。

非fsid継続的

最新のLinux NFSサーバーは、可能であれば自動的にNFS用のファイルシステムUUIDを使用しますfsid。基本的に、これらfsidは永続的でなければなりません。

ただし、以前のUnixおよびその他のNFS実装では、まだ古いスタイルの小さな整数を使用できfsid、一部は他に設定しない限り、非永続的な方法でランダムに割り当てることができます。その場合、NFSサーバーが再起動した後、クライアントは、共有がアンマウントstale file handleされてから再マウントされるまで、マウントされたNFS共有にアクセスしようとするとエラーメッセージを生成します。この問題に対する解決策は、fsidこれらのエントリがNFSサーバーに継続的に割り当てられるようにすることです。

（フォールトトレラントNFSサーバーとして機能するフェールオーバークラスター（HP ServiceGuard）として実行されている3つのHP-UXシステムでこれが発生していることがわかりました。これらがfsidNFSエクスポート/共有構成で明示的に定義されていない場合、クライアントはフェールオーバークラスタリングの目的を無効にする一方のノードから別のノードへのNFSサービスのため、フェイルオーバーはfsid期待どおりに機能し始めました。

関連情報