Sun Cluster HA for NFS の障害検証

検証側サーバーは、ほかのサーバーの NFS サービスに対して、2 種類の周期的な検証を行います。

1. 検証側サーバーは、NFS サービスを提供する必要がある、対象ノード上のすべてのデーモンプロセス (rpcbind、mountd、nfsd、lockd、statd) に NULL RPC を送信します。

2. 検証側サーバーは、ほかのノードから NFS ファイルシステムのマウントを試み、続いてそのファイルシステムに対してファイルの読み書きを試すことによって、終端間テストを行います。この終端間テストは、そのノードが現在共有しているファイルシステムごとに行われます。マウントは手間がかかるため、ほかの検証よりも行われる頻度は少なくなります。

これらの検証のどれかが失敗すると、検証側ノードはサービスを行なっているノードからのテイクオーバーを検討します。しかし、次のような理由によりテイクオーバーをただちに実施しないこともあります。

• ローカル再起動の停止期間 - テイクオーバーを行う前に、検証側ノードは次の目的のために短時間待機します。

  • 障害ノードに、それ自体の欠陥に気付き、そのデーモンをローカルに再起動することによって問題を解決する機会を与える

  • 障害ノードに、ビジー状態から抜ける機会を与える (単に負荷が過剰になっている場合)

  待機後、検証側ノードは検証を再度試み、障害が続くかぎりテイクオーバーを検討し続けます。一般に、速度の遅いサーバーでは、基本的な検証が完全に 2 度タイムアウトしてからテイクオーバーが行われます。

• 複数のパブリックネットワーク - ほかのノードが複数のパブリックネットワーク上に存在する場合、検証側ノードはそれらのネットワークの 2 つ以上で検証を試みます。

• ロック - 一部のバックアップユーティリティは、バックアップが未変更のファイルシステムのスナップショットがとれるように、ファイルシステム上の各種の更新をロックアウトする lockfs(1M) 機能を利用します。NFS では lockfs(1M) はファイルシステムを使用不可能のように見せます (NFS クライアントに NFS server not responding と表示される)。テイクオーバーを行う前に、検証側ノードはほかのノードの照会を行い、ファイルシステムが lockfs 状態かどうかを確認し、この状態であればテイクオーバーを行いません。これは、lockfs が、バックアップを行うための通常の意図された管理作業の一部であるためです。バックアップユーティリティのすべてが lockfs を使用するわけではありません。NFS サーバーの割り込み不可を認めるものもあります。

• デーモン - lockd と statd が応答しないことは、テイクオーバーの原因にはなりません。lockd と statd デーモンは、連携して NFS ファイルのネットワークロックを提供します。これらのデーモンが応答しない場合、状況が syslog に記録されるだけでテイクオーバーは発生しません。lockd と statd は、それらの通常の作業においては、ダウンまたはパーティション分割されたクライアントが長時間 lockd と statd をハングできるように、クライアントマシンに対して RPC を実行する必要があります。このため、欠陥のあるクライアントは、サーバー上の lockd と statd に問題が起きているかのように見せる場合があります。この場合、検証側サーバーによるテイクオーバーが発生することがあれば、検証側サーバーは欠陥クライアントによって同様にハングさせられます。現在のモデルでは、欠陥のあるクライアントが不正なテイクオーバーを起こすことはありません。

これらの Sun Cluster HA for NFS 固有のテストをパスした後、テイクオーバーを行うべきかどうかを検討するプロセスは、hactl(1M) を呼び出して継続します (「検証側ノードの妥当性検査」を参照)。

検証側サーバーは、それ自体の NFS サービスも検査します。ロジックはほかのサーバーの検証に似ていますが、テイクオーバーを行うのではなく、syslog にエラーメッセージを記録し、プロセスが存在しなくなったデーモンの再起動を試みます。つまり、デーモンプロセスの再起動は、デーモンプロセスが終了したかクラッシュした場合だけ行われます。デーモンプロセスがまだ存在するが応答していないという場合は、デーモンプロセスの再起動は行われません。これは、このような状況で再起動を行うと、デーモンがどのデータ構造を更新しているかを認識せずにデーモンを停止してしまうためです。また、この 1 時間以内にローカル再起動が試みられたばかりの場合も再起動は行われません。代わりに、ほかのサーバーにテイクオーバーの検討指示が出されます (そのサーバーがそれ自体の妥当性検査をパスしている場合)。rpcbind デーモンが再起動することはありません。これは、rpcbind に登録しているプロセスに、再登録が必要であることを知らせる方法がないためです。