障害への応答

ノード障害発生時のシステムリセット

Serviceguard クラスタ内で発生した障害に対する最も顕著な応答は、HP-UX の TOC または INIT です。これは、ユーザーに対する猶予付きのシャットダウン手順を実行せずにシステムをリセットするものです (本書では通常、システムリセットと呼びます)。システムリセットにより、パッケージはすぐに別のノードに移動し、データの完全性が保護されます。

システムリセットは、クラスタノードが、一定の時間クラスタメンバーの多くと通信できなくなると発生します。また、カーネルのハングや、クラスタデーモン (cmcld) の障害などの状況でも発生します。

このケースについては、「ノードがタイムアウトしたときの動作」でさらに詳しく説明しています。また、「クラスタデーモン: cmcld」も参照してください。

システムリセットは、特殊な状況で、Serviceguard 自身によっても引き起こされます。「パッケージ障害とサービス障害への応答」を参照してください。

ノードがタイムアウトしたときの動作

各ノードは、ハートビートメッセージをクラスタコーディネータに、HEARTBEAT_INTERVAL マイクロ秒ごとに送信します (クラスタ構成ファイルで指定します)。クラスタコーディネータは、各ノードから受信したこのメッセージを確認し、NODE_TIMEOUT マイクロ秒以内に受信しないと、ハートビートメッセージを送信していないノードを除いてクラスタが再編成されます。(これらのパラメータを設定する上での推奨事項については、「クラスタ構成のパラメータ」の HEARTBEAT_INTERVAL と NODE_TIMEOUT のエントリーを参照してください。)

クラスタコーディネータでないノードでノードタイムアウトが発生すると (つまり、NODE_TIMEOUT 秒以内にハートビートメッセージが到着しない場合)、以下のイベントシーケンスが発生します。

1. ノードはクラスタの再編成を試みます。

2. ノードがクォーラムを取得できないと (クラスタロックを取得できないと)、

3. ノードは停止 (システムリセット) します。

例

状況: 2 台のノードからなるクラスタを考えます。Package1 が SystemA で動作しており、Package2 が SystemB で動作しています。ボリュームグループ vg01 が、SystemA 上で排他的にアクティブ化されています。ボリュームグループ vg02 は、SystemB で排他的にアクティブ化されています。パッケージの IP アドレスは、SystemA と SystemB にそれぞれ割り当てられています。

障害: ハートビート用とデータトラフィック用に、1 つの LAN だけが構成されていました。運用中に大量のアプリケーショントラフィックでネットワークの帯域幅が独占され、ハートビートパケットが送受信できなくなりました。

SystemA は SystemB からのハートビートメッセージを受信できないため、SystemA は、1 ノードのクラスタとして再編成しようとします。同様に、SystemB は SystemA からのハートビートメッセージを受信できないため、SystemB も 1 ノードのクラスタとして再編成しようとします。選出プロトコルで各ノードは自分自身に投票し、 それぞれのノードに投票の 50 パーセントが割り当てられます。両方のノードが投票の 50 パーセントを得ているため、両方のノードがクラスタロックを獲得しようとします。ロックを取得できるのは 1 台のノードだけです。

結果: SystemA がクラスタロックを取得したとします。SystemA は 1 ノードクラスタとして再編成します。再編成の後、SystemA は、既存のクラスタノードで動作するように構成されていたすべてのアプリケーションが動作していることを確認します。SystemA が、クラスタで Package2 が動作していないことを検出すると、Package2 が SystemA で動作するように構成されていれば、Package2 を起動します。

SystemB は、クラスタロックの取得に失敗したことを認識するため、クラスタを再編成することができません。 Package2 に関連するすべてのリソース (ボリュームグループ vg02 への排他的なアクセスや、Package2 の IP アドレス) をできるだけ早く解放するために、SystemB は停止 (システムリセット) します。

	注記: /etc/rc.config.d/cmcluster ($SGAUTOSTART) 内のAUTOSTART_CMCLD にゼロを設定すると、ノードが復帰しても、そのノードはクラスタに参加しなくなります。

クラスタのフェイルオーバーについての詳細は、ホワイトペーパー『 Optimizing Failover Time in a Serviceguard Environment』 を参照してください。このホワイトペーパーは、http://docs.hp.com->[High Availability]->[Serviceguard]->[White Papers] にあります。

ハードウェア障害への応答

SPU 回路のパニックまたは物理的破壊など、システムに重大な問題が発生した場合、Serviceguard はノード障害を認識し、そのノードで現在動作しているフェイルオーバーパッケージをクラスタ内の別の引き継ぎノードへ移行します。(システムマルチノードパッケージとマルチノードパッケージはフェイルオーバーしません。)

各フェイルオーバーパッケージの移行後の位置は、そのパッケージの構成ファイルによって決定されます。この構成ファイルには、パッケージの一次ノードとその代替ノードが記述されています。パッケージを別のノードへ移行しても、プログラムカウンターは引き継がれません。移行したパッケージのプロセスは最初から再起動します。障害発生後にアプリケーションを迅速に再起動させるには、そのアプリケーションがクラッシュの影響を受けにくい性質 (crash-tolerant) を備えていなければなりません。つまり、パッケージのすべてのプロセスは、このような場合の再起動を検出できるように作成されていることが必要です。これは、通常のシステムクラッシュ後の再起動に要求されるアプリケーション設計と同じです。

LAN インタフェース障害が発生した場合は、待機 LAN インタフェースがあれば、そのインタフェースへローカル切り替えが行われます。ハートビート LAN インタフェースに障害が発生した場合、待機ハートビートまたは冗長ハートビートが構成されていなければ、ノードはシステムリセットにより異常終了します。監視データ LAN インタフェースで障害が発生した場合は、待機 LAN インタフェースが構成されていなければ、パッケージで NODE_FAILFAST_ENABLED が YES に設定されている場合に限り、ノードはシステムリセットにより異常終了します (詳しくは、「パッケージ構成のプランニング」を参照してください)。それ以外の場合には、その LAN インタフェースを使っていたパッケージは停止され、可能なら別のノードに移行されます。

ディスク保護を行うには、LVM の Mirrordisk/UX や、VxVM の Veritas ミラーリング、および関連製品など、個別の製品を使います。また、別製品の EMS ディスクモニターを使うと、ロックディスクの障害など特定の障害の発生をオペレータに通知できます。詳しくは、『High Availability Monitors ユーザーガイド』 (B5736-90071) を参照してください。このマニュアルは、http://docs.hp.com/ja->[ハイ アベイラビリティ]->[Event Monitoring Service & HA Monitors] にあります。

Serviceguard は電源異常には直接応答しません。ただし Serviceguard では、各クラスタ構成要素の電源障害はその構成要素自体の障害とみなされるため、結果的には適切な切り替え動作が行われます。電源保護は、HP PowerTrust など HP がサポートする無停電電源装置 (UPS) によって行います。

パッケージ障害とサービス障害への応答

フェイルオーバーパッケージやパッケージ内のサービスが障害になった場合、デフォルトでは'stop'パラメータを使って制御スクリプトを実行することによりパッケージがシャットダウンされ、代替ノード上でパッケージが再起動されます。パッケージに他のパッケージへの依存関係が定義されていて、そのパッケージで障害が発生した場合には、依存している側のパッケージも障害状態になります。構成されているリソース依存関係が満たされていないことを示す EMS (Event Monitoring Service) イベントの通知をパッケージマネージャが受け取ると、パッケージは異常終了して代替ノードでの再起動が試みられます。

このデフォルト動作は、必要に応じて変更できます。つまり、パッケージの移行が実行される前に、ノードが停止 (システムリセット) するように指定できます。それには、パッケージ構成ファイル内の failfast パラメータを設定します。

パッケージのシャットダウンでハングして、ノードの状態が不明になる可能性がある場合は、この failfast オプションにより迅速なフェイルオーバーが可能となります。また、ノードはリブートによってクリーンアップされます。ただし、システムリセットでは、ノードのすべてのパッケージが突然停止されることに注意してください。

パッケージ構成ファイル内の failfast パラメータの設定によって、パッケージまたはリソースが障害になったときのパッケージとノードの動作が決まります。

	注記: システムリセットが指定されている場合でも、Serviceguard がシステムリセットの前にシステムのリブートを試みることがまれにあります。バッファーキャッシュ中のバッファーをフラッシュする時間がある場合は、リブートが成功し、システムリセットは実行されません。どちらの場合にも、システムは事前に設定された時間 (秒数) の間に停止することが保証されます。

「パッケージ構成ファイルのパラメータ」で、適切なフェイルオーバー動作を選択する上での推奨事項を説明しています。

サービスの再起動

障害発生後に、サービスをローカルシステムで再起動できます。これを行うには、パッケージ制御スクリプトで各サービスの再起動回数を指定します。サービスの起動時に、このサービスの環境で変数 RESTART_COUNT が設定されます。サービスは、実行中にこの変数を調べて、障害発生後に再起動されたかどうかをチェックします。再起動されている場合は、クリーンアップなどの適切な処理を行います。

ネットワーク通信障害

クラスタの重要な要素として、ネットワークの状態が挙げられます。各ノードはクラスタを継続的に監視しながら、他のノードから送られてくるハートビートメッセージをチェックして、すべてのノードが互いに通信できることを確認します。設定時間内にノードがこのようなメッセージを受信しなかった場合、ノードのタイムアウトが発生し、クラスタの再編成が行われます。その後ハートビートメッセージを受信しなかった場合はシステムリセットが実行されます。