Cluster Server 7.4.3 管理者ガイド - Linux

認識されたメンバーシップの変更がある場合、メンバーシップアービトレーションは次のように動作します。

• GAB はシステムを DOWN としてマーク付けし、システムをクラスタメンバーシップから除外し、メンバーシップの変更（切り離されたシステムのリスト）をフェンシングモジュールに配信します。

• クラスタ内で最小の LLT システム ID を持つシステムがコーディネータディスクの制御権の獲得競争に参加します。

  • 最も一般的なケース（切り離されたシステムが実際に停止したか障害を起こしている場合）では、この競争の参加者は 1 システムだけです。

  • 2 つ以上のサブクラスタが形成されているスプリットブレインのシナリオでは、コーディネータディスク制御権の獲得競争は、サブクラスタの最小の LLT システム ID を持つシステムによって行われます。サブクラスタ内の他のすべてのシステムに代わって制御権の獲得競争に参加するシステムは RACER ノードと呼ばれ、サブクラスタ内の他のシステムは SPECTATOR ノードと呼ばれます。

• I/O フェンシング制御権獲得では、RACER ノードでパニックが発生するか、コーディネーションポイントに到達できない場合、VxFEN RACER ノードの再選択機能によって次に低いノード ID を持つサブクラスタ内の代替ノードが RACER ノードの役割を担います。

  RACER 再選択は、次の手順で行われます。

  • RACER ノードに予期しないパニックが発生した場合、VxFEN ドライバは RACER の再選択を開始します。

  • RACER ノードがコーディネーションポイントの過半数に到達していない場合、VxFEN モジュールはサブクラスタ内の他のノードに RELAY_RACE メッセージを送ります。 次に、VxFEN モジュールは次に低いノード ID を新しい RACER として再選します。

  • 再選が連続して行われ、サブクラスタに RACER ノードとして再選できるノードが残されていない場合、サブクラスタ内のすべてのノードにパニックが発生します。

• この競争では、GAB メンバーシップから除外された可能性のある各システムの各キーに対して獲得と中止コマンドが実行されます。

  獲得と中止コマンドは、有効なキーを持つ登録済みシステムだけに別のシステムのキーを削除することを許可します。したがって、他の削除を試みるシステムが複数あっても、各競争の勝者は 1 つだけになります。獲得と中止コマンドを実行する最初のシステムが勝者となり、他のシステムのキーを削除します。 獲得と中止コマンドを実行する 2 番目のシステムはキーの削除を実行できません。そのシステムは有効なキーを持つ登録済みのシステムではなくなっているためです。

  クラスタレベルの属性 PreferredFencingPolicy の値が System、Group、Site のいずれかの場合、競争時に VxFEN Racer ノードはローカルサブクラスタと残りのサブクラスタのすべてのノードの重みを集計します。残りのパーティションの（ノードの重みの）合計のほうが大きい場合、このパーティションの競合者はコーディネーションポイントに対する競合を遅らせます。 これにより、より重要なサブクラスタが効果的に優先され、制御権を獲得します。 クラスタレベルの属性 PreferredFencingPolicy の値が Disabled の場合は、遅延はノード数の合計に基づいて計算されます。

  優先フェンシングについてを参照してください。

• 獲得と中止コマンドから成功が返された場合、そのシステムはコーディネータディスクの制御権を獲得しています。

  各システムはすべてのコーディネータディスクに対してこの制御権獲得競争を繰り返します。 コーディネータディスクの過半数から他のシステムの登録キーを削除したシステムが競争の勝者（制御権の獲得者）になります。

• 制御権を獲得したシステムでは、vxfen モジュールが、このシステムに制御権獲得競争の代表を任せた他のすべてのシステムに、制御権を獲得したことおよびサブクラスタは依然として有効であることを通知します。

• 制御権を獲得できなかったシステムでは、vxfen モジュールがシステムパニックを引き起こします。このサブクラスタ内の他のシステムはパニックに気付き、コーディネータディスクの制御を失ったことを確認し、同様にパニックを引き起こして再起動します。

• 再起動時に、システムはクラスタへのシーディングを試みます。

  • 再起動されたシステムが、/etc/gabtab 内に定義された数のクラスタシステムとハートビートを交換できれば、そのシステムは自動的にシーディングされ、引き続きクラスタに参加します。コーディネータディスク上のそのシステムのキーは置き換えられます。この状況が発生するのは、メンバーシップ変更の本来の原因が再起動中に解決した場合のみです。

  • 再起動されたシステムが、/etc/gabtab 内に定義された数のクラスタシステムとハートビートを交換できなければ、そのシステムは自動的にシーディングされず、HAD は開始されません。これはスプリットブレイン状態の可能性があります。管理者の介入が必要です。

  • クラスタで I/O フェンシングを有効にし、I/O フェンシングにを使用して GAB の自動シーディング機能を設定した場合、GAB は一部のクラスタノードが使用不能であっても自動的にクラスタをシーディング処理します。

    I/O フェンシングによる GAB 自動シーディングパラメータを使用したクラスタのシーディングを参照してください。

  メモ:

  この時点で手動シーディングを強制すれば、クラスタはシーディングされます。 ただし、コーディネータディスク上にキーを持つシステムと GAB のメンバーシップをフェンシングモジュールが照合するときに不一致が発生します。vxfen はスプリットブレイン状態の可能性を検出し、警告を表示して、起動を停止します。同様に、HAD も開始されません。管理者の介入が必要です。

  クラスタの手動シーディングを参照してください。