メインコンテンツまでスキップ

NetApp_Insight_2020.png 

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

Views:
27
Visibility:
Public
Votes:
0
Category:
data-ontap-7
Specialty:
core
Last Updated:

すべてのとおり  

に適用されます

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 )プロトコルに依存します。Network Status Monitor ( NSM )と呼ばれる別の RPC プロトコルを使用して、サーバのリブートによりロック状態が失われたことをクライアントに通知します。NFS サーバがクライアントにロックを付与する場合、ロックを所有するクライアントのレコードを保持する必要があります。この情報はディスク上に保持されます。個々のロック状態自体は永続的ではありません。サーバがリブートすると、ロックは失われます。NFS サーバが再び使用可能になったときにロックを再確立できるように、クライアントに通知する必要があります。  ストレージシステムの NSM では、次の場所にファイルとして情報が保持/etc/smされます。 :

state        現在
monitor監視されているホストの NSM リストの状態
notify。再起動後に通知されるホストのリスト

リブート時/etc/sm/monitorまたはクラスタテイクオーバー時に、 Filer はファイルを読み取り、リブートまたはクラスタテイクオーバーの前に NLM ファイルロックを保持していたクライアントを判別します。通知さ/etc/sm/notifyれるクライアントがファイルにコピーされ、クライアントへの通知に使用されます。ストレージシステムは、リブートしてすべてのロックが失われたことを nsm 経由でクライアントに通知します。NSM デーモン(rpc.statd/statd)を実行しているクライアントは、ストレージシステムのリブート中に失われたロック状態を再構築するために、ロック再要求を発行します。  ストレージシステムがリブートすると、ストレージシステムが新しいロック要求を受け付けない NLM の猶予期間が 45 秒になります。この期間は、再要求要求のみを保持します。猶予期間を指定すると、ロックを保持していたすべての NFS クライアントに、ロックを再要求する機会が与えられます。

クライアントまたはネットワークに問題があると、ストレージシステムの nsm が監視対象のすべてのクライアントに通知できなくなる場合があります。接続できない各クライアントは、リブート後に NFS ファイルサービスの起動を遅延させます。  ストレージシステムは、 NFS サービスが完全に開始される前に、通知リスト内のすべてのクライアントとの通信を試みます。各クライアントの最大タイムアウト値は 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. storage system advanced mode コマンドを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 のバージョンに応じ[1]て、 lock status というコマンドがあります。Data ONTAP の旧バージョンlocklock_dumpは、の形式で入手できます。

追加情報

N/A