Network File System （ NFS ）ロックリカバリと Network Status Monitor の詳細について教えてください。

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 フアイルテシヨウテキナイホストノカクニン

1. 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;
}

2. これを使用するには、STDINからこのスクリプトにモニタファイルを送信します。

   cat etc/sm/monitor | ./read_monitor.pl

   in_use が1に設定されているすべてのクライアントのリストが表示されます。

3. クライアントのリストで次の項目を確認します。

   - 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 、コマンドを使用してモニタファイルから削除できます。

4.   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。