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

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

  1. ノード A とノード B は、COMM_DOWN イベントの処理を開始します。ただし、全く同時とは限りません。

  2. 両方のノードは Quorum チェックを実行し、両方共自身が Quorum を持っていると判断します(ノード A とノード B の両方からノード W が見えているため、既知の3ノードのうちの2ノードと疎通があるため多数派にいると判断します)。

  3. 各ノードは、まだ通信可能な別のノードに対し、自ノードと通信できなくなったノードの状態について問い合わせ(Witness チェック)を行います。このシナリオでは、ノード A がノード B のステータスについてノード W に問い合わせ、ノード B がノード A のステータスについてノード W に問い合わせることになります。

  4. ノード A とノード B は共に ノード W への問い合わせによって他方のノードがまだ生存していると判断し、フェイルオーバー処理は発生しません。リソースはノード A でサービス状態のままになります。

シナリオ2

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

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

シナリオ3

ノード A に障害が発生してノード A が停止

この場合、ノード B は以下の動作をします。

  1. ノード A との COMM_DOWN イベントの処理を開始します。

  2. ノード W と通信が可能であるので、Quorum を持っていると判断します。

  3. ノード A が見えないことをノード W に確認した後、通常のフェイルオーバー処理を開始します。

  4. これにより保護対象のリソースはノード 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 は以下の動作をします。

  1. ノード B との COMM_DOWN イベント、の処理を開始します(ほぼ同時に、ノード W との COMM_DOWN イベントの処理も開始されます)。

  2. ノード B ともノード W とも通信ができないため、Quorum にを持っていないと判断します。

  3. 直ちに 強制停止します(QUORUM_LOSS_ACTION のデフォルト「 fastkill 」の振る舞い)。

また、ノード B は以下の動作をします。

  1. ノード A との COMM_DOWN イベントの処理を開始します。

  2. ノード W とまだ通信が可能であるため、Quorum を持っていると判断します。

  3. ノード A が見えないことをノード W に確認(Witness チェック)した後、通常のフェイルオーバー動作を開始します。

  4. これにより保護対象のリソースはノード B でサービス中になります。

リソースがノード B でサービス中に、ノード A の通信が回復

この場合、ノード B は、 COMM_UP イベントを処理し、Quorum を持っている(3ノードすべてが見える)ことと、サービス中のリソースを持っていることを判断します。ノード A は、COMM_UP イベントを処理し、Quorum を持っていることと、リソースが別のノードでサービス中であることを判断します。この時点では、ノード A はリソースを起動させません。

フィードバック

お役に立ちましたか?

はい いいえ
お役に立ちましたか
理由をお聞かせください
フィードバックありがとうございました

このトピックへフィードバック

送信