コミュニケーションパスを通じて疎通確認を行い、Quorum チェックを行います。クラスター内の過半数のノードと疎通ができることで、Quorumチェック成功と判断します。
本モードは3ノード以上のクラスターで動作可能です。2ノード構成の場合は、Witness 専用のノードを追加する必要があります。


quorumを使用してクラスターを停止する:

  1. ターゲットを停止
  2. ソースを停止
  3. witness を停止

quorumを使用してクラスターを起動する:

  1. witness を起動
  2. ターゲットを起動
  3. ソースを起動

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. LifeKeeper に設定されている QUORUM_LOSS_ACTION パラメータの設定に基づいてノードの強制再起動や強制停止などを行います。QUORUM_LOSS_ACTION のデフォルトは「fastkill」に設定されています。詳細は Quorum/Witness を参照してください。

また、ノード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はリソースを起動させません。


シナリオ5

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

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

  1. ノードBとの COMM_DOWN イベントの処理を開始します(ほぼ同時に、ノードWとの COMM_DOWN イベントの処理も開始されます)。
  1. ノードBともノードWとも通信ができないため、Quorum を持っていないと判断します。
  1. LifeKeeper に設定されている QUORUM_LOSS_ACTION パラメータの設定に基づいてノードの強制再起動や強制停止などを行います。QUORUM_LOSS_ACTION のデフォルトは「fastkill」に設定されています。詳細は Quorum/Witness を参照してください。

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

  1. ノードAとの COMM_DOWN イベントの処理を開始します。
  1. ノードAともノードWとも通信ができないため、Quorum を持っていないと判断します。
  1. サービス状態のリソースがないので、強制停止はしません。

コミュニケーションパスが復旧した場合、ノードA上でリソースが起動します。なお、本動作となるためには、以下の 2条件を満たす必要があります。

  • ノードAのリソースに設定された初期化設定値が AUTORES_ISP であること。
  • リソースにセットされた優先度がノードAで最も高い値であること。

フィードバック

お役に立ちましたか?

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

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

送信