Network File System ( NFS )ロックリカバリと Network Status Monitor の詳細について教えてください。
環境
Data ONTAP 7 以前
回答
Network Status Monitor(NSM;ネットワークステータスモニタ)の問題により、リブート後またはクラスタフェイルオーバー後にNFSサービスが開始されません。
Error message: [sm_recover]: no address for host [nfs_client1]
Error message: [sm_recover]: get RPC port for [host=unix1,prog=100024,ver=1,prot=17] failed
NFSロックのリカバリとネットワークステータスモニタ
NFSバージョン2および3は、ファイルロックにNetwork Lock Manager(NLM;ネットワークロックマネージャ)プロトコルに依存しています。ネットワークステータスモニタ(NSM)と呼ばれる別のRPCプロトコルは、サーバのリブートによってロック状態が失われたことをクライアントに通知するために使用されます。NFSサーバがクライアントにロックを許可すると、ロックを所有するクライアントのレコードを保持する必要があります。この情報はディスク上に保持されます。個 々 のロック状態自体は永続的ではありません。サーバがリブートすると、ロックは失われます。NFSサーバが再び使用可能になったときにロックを再確立できるように、クライアントに通知する必要があります。 ストレージシステムNSMは、情報をファイルとして /etc/sm
次の場所に保持します。
state
NSMの状態monitor
現在監視中のホストのリストnotify
リブート後に通知されるホストのリスト
リブートまたはクラスタ・テイクオーバー時に、Filerは /etc/sm/monitor
ファイルを読み取り、リブートまたはクラスタ・テイクオーバー前にNLMファイル・ロックを保持していたクライアントを判別します。通知されるクライアントは /etc/sm/notify
ファイルにコピーされるため、クライアントへの通知に使用されます。ストレージシステムはNSMを介してクライアントに、リブート後にすべてのロックが失われたことを通知します。NSMデーモン(rpc.statd/statd
)を実行しているクライアントは、 ストレージ・システム のリブート中に失われたロック状態を再構築するための問題ロック再要求を実行します。 ストレージシステム がリブートした場合、45秒のNLM猶予期間中、 ストレージシステムは 新しいロック要求を処理せず、再生要求だけを処理します。この猶予期間は、ロックを保持していたすべてのNFSクライアントに対して、ロックを再要求する機会を与えます。
クライアントまたはネットワークに問題があると、 ストレージシステム NSMから監視対象のすべてのクライアントに通知されない場合があります。接続できない各クライアントは、リブート後のNFSファイルサービスの起動に遅延が生じます。 NFSサービスが完全に開始される前に、notifyリスト内のすべてのクライアントへの接続が試行されます。各クライアントの最大タイムアウト値は10秒です。
ストレージシステム からクライアントへの通知を妨げる可能性のある問題は次のとおりです。
- クライアントが停止しているか、ネットワーク上で使用できなくなっています。
- クライアントはNSMデーモンを実行していません。Linuxではrpc.statd、Solarisではstatdです。
- ネットワークが接続されているか、ネットワーク機器が停止しています。
- ストレージシステムは 、DNSサービスまたはNISサービスにアクセスできないため、クライアントのホスト名を解決できません。
エラー メッセージ
Error message: [sm_recover]: no address for host [nfs_client1]
Error message: [sm_recover]: get RPC port for [host=unix1,prog=100024,ver=1,prot=17] failed
/etc/sm/monitor
フアイルテシヨウテキナイホストノカクニン
read_monitor.pl
次のPerlスクリプトを使用すると、モニタファイルにクライアントをリストできます。#!/usr/bin/perl
binmode (STDIN);$file=join "",<stdin>;
while ($file =~ /(..)(..)(.*?)\000/gs) {
$status=unpack("S", $1);
$namelen=unpack("S", $2);
print "$3\n" if $status==1;
}- これを使用するには、STDINからこのスクリプトにモニタファイルを送信します。
cat etc/sm/monitor | ./read_monitor.pl
in_use
が1に設定されているすべてのクライアントのリストが表示されます。 - クライアントのリストで次の項目を確認します。
- ping the host from the filer
- the client portmapper is functioning(rpcinfo -p hostname)
- the client rpc.statd/statd is running (rpcinfo -p hostname)クライアントが上記のチェックに失敗した場合は、問題を修正する必要があります。クライアントが永続的に使用できない場合は
sm_mon
、コマンドを使用してモニタファイルから削除できます。 -
sm_mon
監視リストからホストを削除するには、ストレージ・システムのアドバンス・モード・コマンドを使用します。
Enter priv set advanced
Enter sm_mon -u [client_name]
Enter priv set admin
vFiler
vFilerの設定は、Network Status Monitorクライアント通知プロセスに影響を与える可能性があります。各vFilerは、vfiler /etc/sm
ディレクトリの下に独自の情報ファイルセットを保持します。 ストレージ・システムのリブート後、各vFilerでNFSサービスが再開されます。各vFilerは、 /etc/sm/notify
ロックを再要求できるように、ファイル内のNFSクライアントに通知する必要があります。vfiler間で共有されている応答しないクライアントでは、vfilerごとに10秒のタイムアウトが発生します。複数のvFilerでロックを保持しているクライアントは、各vFilerからNSM経由で通知する必要があります。すべてのNFSファイルサービスが完全に動作するまでの全体的な起動時間に影響する可能性があります。
ストレージシステム クラスタ
ストレージシステム クラスタ構成では、パートナーのテイクオーバーまたはギブバック処理はクラスタパートナーのリブートと同じです。 影響を受ける ストレージシステムでロックを保持していたNFSクライアント には、上記のセクションで説明するように、Network Status Monitor(NSM;ネットワークステータスモニタ)経由で通知する必要があります。
クラスタのフェイルオーバー/テイクオーバーでは、各サービスの起動時間が5分に制限されるため、NLMクライアントへの接続が遅れると、障害が発生したFilerの起動がさらに複雑になり、クラスタ全体の可用性に影響が及ぶ可能性があります。
注: sm_mon
コマンドを実行すると、ロックが実際に解除されたことを確認できると便利です。lock
コマンドを確認します。すべてのプロトコル(NLM、Common Internet File System Protocol(CIFS)、NFSv4、fioなど)で保持されているロックが表示されます。Data ONTAPのバージョンに応じて 、lock statusというコマンドがあります。以前のバージョンのData ONTAPは lock
、の形式で利用できます lock_dump
。
追加情報
N/A