majority モード

コミュニケーションパスを通じて疎通確認を行い、Quorum チェックを行います。クラスター内の過半数のノードと疎通ができることで、Quorum チェック成功と判断します。
本モードは３ノード以上のクラスターで動作可能です。２ノード構成の場合は、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 専用ノード）の３ノード構成のクラスターの振る舞いについて示します。

なお、ノード障害に関するリソースの状態を変更し得るイベントは以下の３つです。

COMM_DOWN イベント
ノード間のコミュニケーションパスが全て切断した時に呼び出されるイベント。

COMM_UP イベント
COMM_DOWN 状態からコミュニケーションパスが復旧した際に呼び出されるイベント。

LCM_AVAIL イベント
LCM の初期化が終わった時に呼び出されるイベントで、LifeKeeper 起動時に１度だけ呼び出される。起動時に他のノードとコミュニケーションパス通信ができる場合は、必ず COMM_UP イベントの処理より前に LCM_AVAIL イベントの処理が行われる。

シナリオ１

ノード A とノード B の間のコミュニケーションパス通信に障害が発生

この場合、以下のように動作します。

ノード A とノード B は、COMM_DOWN イベントの処理を開始します。ただし、全く同時とは限りません。
両方のノードは Quorum チェックを実行し、両方共自身が Quorum を持っていると判断します（ノード A とノード B の両方からノード W が見えているため、既知の３ノードのうちの２ノードと疎通があるため多数派にいると判断します）。
各ノードは、まだ通信可能な別のノードに対し、自ノードと通信できなくなったノードの状態について問い合わせ（Witness チェック）を行います。このシナリオでは、ノード A がノード B のステータスについてノード W に問い合わせ、ノード B がノード A のステータスについてノード W に問い合わせることになります。
ノード A とノード B は共にノード W への問い合わせによって他方のノードがまだ生存していると判断し、フェイルオーバー処理は発生しません。リソースはノード A でサービス状態のままになります。

シナリオ２

ノード A とノード W の間のコミュニケーションパス通信に障害が発生

Quorum/Witness パッケージがインストールされていると、すべてのノードが Witness ノードとして動作するため、このシナリオは前のシナリオと同じになります。この場合、ノード A とノード W は共にノード B へ問い合わせを行い、それにより他方のノードがまだ生存していると判断します。

シナリオ３

ノード 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 では２回発生する）。各ノードの COMM_UP イベントの処理では、Quorum を持っていると判断し、またノード B でリソースがサービス中のためリソースは起動させません。

リソースがノード B でサービス中に、他のノードと通信不能な状態でノード A のサーバーが電源ON

この場合、ノード A は LCM_AVAIL イベントを処理し、ノード B とノード W はノード A と通信できないので何もしません。ノード A は、３ノードのうちの１ノード（自分自身）としか通信できないため Quorum を持っていないと判断します。Quorum を持っていないため、ノード A はリソースを起動させません。

シナリオ４

ノード 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 を持っている（３ノードすべてが見える）ことと、サービス中のリソースを持っていることを判断します。ノード A は、COMM_UP イベントを処理し、Quorum を持っていることと、リソースが別のノードでサービス中であることを判断します。この時点では、ノード A はリソースを起動させません。

シナリオ５

3つのノードすべてが他のノードと通信不能