コミュニケーションパスを通じて疎通確認を行い、Quorum チェックを行います。クラスター内の過半数のノードと疎通ができることで、Quorumチェック成功と判断します。
本モードは3ノード以上のクラスターで動作可能です。2ノード構成の場合は、Witness 専用のノードを追加する必要があります。
quorumを使用してクラスターを停止する:
- ターゲットを停止
- ソースを停止
- witness を停止
quorumを使用してクラスターを起動する:
- witness を起動
- ターゲットを起動
- ソースを起動
majorityモードの設定
/etc/default/LifeKeeper 設定ファイルで QUORUM_MODE の設定を majority に設定してください。本モードでは、他の設定はありません。
majorityモードで使用可能なWitnessモード
本モードでは以下の Witness モードを使用できます。各モードの詳細は「使用可能な Witness モード 」を参照してください。
- remote_verify
- none/off
majorityモードの期待される動作(標準の設定を仮定)
ノードA(リソースはサービス状態)、ノードB(リソースは待機状態)、そしてノードW(保護対象のリソースを持っていない Witness 専用ノード)の3ノード構成のクラスターの振る舞いについて示します。
なお、ノード障害に関するリソースの状態を変更し得るイベントは以下の3つです。
- COMM_DOWN イベント
ノード間のコミュニケーションパスが全て切断した時に呼び出されるイベント。
- COMM_UP イベント
COMM_DOWN 状態からコミュニケーションパスが復旧した際に呼び出されるイベント。
- LCM_AVAIL イベント
LCM の初期化が終わった時に呼び出されるイベントで、LifeKeeper 起動時に1度だけ呼び出される。起動時に他のノードとコミュニケーションパス通信ができる場合は、必ず COMM_UPイベントの処理より前にLCM_AVAILイベントの処理が行われる。
シナリオ1
ノードAとノードBの間のコミュニケーションパス通信に障害が発生
この場合、以下のように動作します。
ノードAとノードBは、COMM_DOWN イベントの処理を開始します。ただし、全く同時とは限りません。
両方のノードは Quorum チェックを実行し、両方共自身が Quorum を持っていると判断します(ノードAとノードBの両方からノードWが見えているため、既知の3ノードのうちの2ノードと疎通があるため多数派にいると判断します)。
各ノードは、まだ通信可能な別のノードに対し、自ノードと通信できなくなったノードの状態について問い合わせ(Witness チェック)を行います。このシナリオでは、ノードAがノードBのステータスについてノードWに問い合わせ、ノードBがノードAのステータスについてノードWに問い合わせることになります。
ノードAとノードBは共に ノードWへの問い合わせによって他方のノードがまだ生存していると判断し、フェイルオーバー処理は発生しません。リソースはノードAでサービス状態のままになります。
シナリオ2
ノードAとノードWの間のコミュニケーションパス通信に障害が発生
Quorum/Witness パッケージがインストールされていると、すべてのノードが Witness ノードとして動作するため、このシナリオは前のシナリオと同じになります。この場合、ノードAとノードWは共にノードBへ問い合わせを行い、それにより他方のノードがまだ生存していると判断します。
シナリオ3
ノードAに障害が発生してノードAが停止
この場合、ノードBは以下の動作をします。
ノードAとの COMM_DOWN イベントの処理を開始します。
ノードWと通信が可能であるので、Quorum を持っていると判断します。
ノードAが見えないことをノードWに確認した後、通常のフェイルオーバー処理を開始します。
これにより保護対象のリソースはノードBでサービス中になります。
リソースがノードBでサービス中に、他のノードと通信可能な状態でノードAのサーバーが電源 ON
この場合、ノードAは LCM_AVAIL イベントを処理します。ノードAは、Quorum を持っていると判断し、ノードBでリソースがサービス中のためリソースを起動させません。
また、その直後に、ノードAとノードB、ノードAとノードWとの COMM_UP イベントが各ノードで発生しします(ノードAでは2回発生する)。各ノードの COMM_UP イベントの処理では、Quorum を持っていると判断し、またノードBでリソースがサービス中のためリソースは起動させません。
リソースがノードBでサービス中に、他のノードと通信不能な状態でノードAのサーバーが電源ON
この場合、ノードAは LCM_AVAIL イベントを処理し、ノードBとノードWはノードAと通信できないので何もしません。ノードAは、3ノードのうちの1ノード(自分自身)としか通信できないため Quorum を持っていないと判断します。Quorum を持っていないため、ノードAはリソースを起動させません。
シナリオ4
ノードAのネットワークに障害が発生(ノードAは稼働しているが、他のノードと通信不能)
この場合、ノードAは以下の動作をします。
ノードBとの COMM_DOWN イベントの処理を開始します(ほぼ同時に、ノードWとの COMM_DOWN イベントの処理も開始されます)。
ノードBともノードWとも通信ができないため、Quorum を持っていないと判断します。
LifeKeeper に設定されている QUORUM_LOSS_ACTION パラメータの設定に基づいてノードの強制再起動や強制停止などを行います。QUORUM_LOSS_ACTION のデフォルトは「fastkill」に設定されています。詳細は Quorum/Witness を参照してください。
また、ノードBは以下の動作をします。
ノードAとの COMM_DOWN イベントの処理を開始します。
ノードWとまだ通信が可能であるため、Quorum を持っていると判断します。
ノードAが見えないことをノードWに確認(Witness チェック)した後、通常のフェイルオーバー動作を開始します。
これにより保護対象のリソースはノードBでサービス中になります。
リソースがノードBでサービス中に、ノードAの通信が回復
この場合、ノードBは、 COMM_UP イベントを処理し、Quorum を持っている(3ノードすべてが見える)ことと、サービス中のリソースを持っていることを判断します。ノードAは、COMM_UP イベントを処理し、Quorum を持っていることと、リソースが別のノードでサービス中であることを判断します。この時点では、ノードAはリソースを起動させません。
シナリオ5
3つのノードすべてが他のノードと通信不能
この場合、ノードAは以下の動作をします。
- ノードBとの COMM_DOWN イベントの処理を開始します(ほぼ同時に、ノードWとの COMM_DOWN イベントの処理も開始されます)。
- ノードBともノードWとも通信ができないため、Quorum を持っていないと判断します。
- LifeKeeper に設定されている QUORUM_LOSS_ACTION パラメータの設定に基づいてノードの強制再起動や強制停止などを行います。QUORUM_LOSS_ACTION のデフォルトは「fastkill」に設定されています。詳細は Quorum/Witness を参照してください。
また、ノードBは以下の動作をします。
- ノードAとの COMM_DOWN イベントの処理を開始します。
- ノードAともノードWとも通信ができないため、Quorum を持っていないと判断します。
- サービス状態のリソースがないので、強制停止はしません。
コミュニケーションパスが復旧した場合、ノードA上でリソースが起動します。なお、本動作となるためには、以下の 2条件を満たす必要があります。
- ノードAのリソースに設定された初期化設定値が AUTORES_ISP であること。
- リソースにセットされた優先度がノードAで最も高い値であること。
このトピックへフィードバック