storageモード

!リソースを作成および拡張する前に、Quorumが正しく設定されていることを確認してください。Quorumの構成が誤っていると、サーバーが誤って停止する可能性があります。

クラスター内のすべてのノードからアクセスできる共有ストレージを用いた合意システムで、共有ストレージを介してノードの情報交換を行います。各ノードは自ノード情報を定期的に共有ストレージに書き込み、また定期的に他ノードが書き込んだノード情報を読み込みます。この共有ストレージに書き込まれたノード情報をQWKオブジェクトと呼びます。QWKオブジェクトはクラスターを構成するノード数だけ必要です。
Quorumチェックでは、共有ストレージにアクセスできることでQuorumチェック成功と判断します。また、Witnessチェックでは、障害が疑われるノードのQWKオブジェクトを確認し、一定期間内に更新されていると障害なし、更新が止まっていれば障害が発生していると判断します。なお、実装上は、Quorumチェック時にWitnessチェックも実施しています。
なお、Quorumモードにstorageを選んだ場合、後述のWitnessモードもstorageを選択しなければなりません。
本モードは2ノードのクラスターから動作可能で、最大4ノードまで対応しています。別途、クラスターを構成するノード数分のQWKオブジェクトを格納するための共有ストレージが必要です。なお共有ストレージにアクセスできなくなると、リソースの起動に影響します。すべてのノードから常時アクセス可能な共有ストレージを選定してください。

*注意 ：共有ストレージは各ノードからアクセス可能なストレージのことです。この共有ストレージはQuorum/Witness機能専用であり、LifeKeeperがリソースとして保護することはできません。

*注意 ：本モードを利用するには、設定後に初期化が必要です（後述の「storageモードの使用手順」 参照）。また、初期化後にクラスター内のノードの追加・削除や設定の変更を行う場合は、再初期化が必要です。

*注意 ：クラスター内に”-”と”.”だけ異なるホスト名のノードが存在する場合（例：lifekeeper-siosとlifekeeper.sios）、本モードを利用することができません。本モードを利用する場合はホスト名を変更してください。

利用可能な共有ストレージ

Quorum/Witness機能の目的であるスプリットブレイン回避を確実なものにするために、Quorum分割（例：ノードAのQWKオブジェクトにアクセス可能であるが、ノードBのQWKオブジェクトにアクセス不能）が発生しない構成としなければなりません。そのため、クラスター内のすべてのQWKオブジェクトが同一共有ストレージ上の同一種のブロックデバイス・レギュラーファイル・EFSまたはS3オブジェクトに配置されていることを条件とします。

利用可能な共有ストレージは以下の通りです。/etc/default/LifeKeeper設定ファイルの QWK_STORAGE_TYPE で指定します。

*1 blockタイプを使用する場合、以下の要件を満たす必要があります。

共有ストレージ環境での要件

• 共有ストレージは、両方のノードが同じストレージにアクセスできるように構成する必要があります。
• ネットワーク分断時に、各ノードがストレージの一貫性が維持されていない異なるレプリカに同時にアクセスできる構成はサポートされません。
  • たとえば、Amazon FSx for NetApp ONTAPのように、各AZに同期レプリカを内部的に保持する仮想共有ストレージ構成は使用できません。これは、AZ分断時に一貫性が維持できなくなった各レプリカに同時にアクセスできる可能性があり、Quorumオブジェクトの一貫性を保証できなくなるためです。

仮想環境での要件

• Nutanix AHV、KVM、およびOracle VM Server for x86上の仮想ディスクファイルはサポートされません。Hyper-Vでは、パススルーディスクまたは仮想ファイバーチャネルを使用して、物理ストレージに直接アクセスする必要があります。
  

1 QWKオブジェクトのサイズは4096バイトです。

自ノードQWK オブジェクトに対してはread / writeを行います。他ノードのQWKオブジェクトに対してはreadのみ行います。適切にアクセス権限を設定してください（Persistent Reservation などのアクセス権制限を伴う場合は要注意）。

*注意 ：vSphereの4KネイティブディスクはQWKオブジェクトの共有ストレージとして利用することはできません。

storageモードの設定

/etc/default/LifeKeeper 設定ファイルでQUORUM_MODEとWITNESS_MODEの設定をstorageに設定してください。また、他に以下の設定があります。詳細は「Quorumパラメータ一覧 」を参照してください。

• QWK_STORAGE_TYPE

• QWK_STORAGE_HBEATTIME

• QWK_STORAGE_NUMHBEATS

• QWK_STORAGE_OBJECT_<ホスト名>

• HTTP_PROXY, HTTPS_PROXY, NO_PROXY

storageモードの使用手順

本モードで使用する場合は、初期化が必要です。以下の手順に従って初期化してください。

1. クラスターを構成するすべてのサーバーをセットアップして、他のサーバーとネットワーク通信ができることを確認します。

2. クラスターを構成するすべてのサーバーに LifeKeeper をインストールします。その際、setup コマンドで「Use Quorum / Witness functions」を有効にして、Quorum/Witness パッケージもインストールしてください。

3. すべてのノード間にコミュニケーションパスを作成します。

4. すべてのノードで /etc/default/LifeKeeper 設定ファイルを編集し、storage モードの設定を行います。

5. すべてのノードで qwk_storage_init コマンドを実行します。このコマンドは、すべてのノードでQWKオブジェクトの初期化が終わるまで待ち状態になります。このコマンドがすべてのノードで終了すると、storageモードとしてQuorum/Witness機能が利用できる状態となります。

!qwk_storage_init を実行する 前 に、すべてのコミュニケーションパスが稼働していてAliveであることを確認してください。

初期化後にクラスターを構成するノードの追加・削除をする、または /etc/default/LifeKeeper 設定ファイルのパラメーターを変更する場合、再初期化が必要です。以下の手順に従って再初期化してください。

1. すべてのノードで qwk_storage_exit コマンドを実行します。

2. ノードを削除する場合、削除するノードと他すべてのノード間のコミュニケーションパスを削除します。
   ノードを追加する場合、追加するノードと他すべてのノード間にコミュニケーションパスを作成します。

3. すべてのノードで /etc/default/LifeKeeper 設定ファイルを再設定します。

4. すべてのノードで qwk_storage_init コマンドを実行します。

storageモードの期待される動作（標準の設定を仮定）

ノードA（リソースはサービス状態）、ノードB（リソースは待機状態）の2ノード構成のクラスターの振る舞いについて示します。

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

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

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

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

シナリオ1

ノードAとノードBの間のコミュニケーションパス通信に障害が発生（ノードAとノードBとも共有ストレージにアクセス可能）

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

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

2. 両方のノードはQuorumチェックを実行し、両方共自身がQuorumを持っていると判断します（共有ストレージアクセスが可能であるため）。

3. 各ノードは、通信できなくなったノードのQWKオブジェクトの更新を確認します（Witness チェック）。ノードAとノードBは共に稼働しているため定期的にQWKオブジェクトを更新され、Witnessチェックでその更新を確認します。

4. Witnessチェックの結果、他方のノードがまだ生存しているためフェイルオーバー処理は発生しません。リソースはノードAでサービス状態のままになります。

シナリオ2

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

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

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

2. 共有ストレージにアクセス可能であるので、Quorumを持っていると判断します。

3. ノードAのQWKオブジェクトの更新が停止していることを確認します（Witnessチェック）。

4. Witnessチェックの結果、ノードAで障害が発生していると判断したため通常のフェイルオーバー処理を開始します。これにより保護対象のリソースはノードBでサービス中になります。

リソースがノードBでサービス中に、通信可能かつ共有ストレージにアクセス可能な状態でノードAのサーバーが電源ON

この場合、ノードAは LCM_AVAILイベントを処理します。ノードAは、Quorumを持っていると判断し、ノードBでリソースがサービス中のためリソースを起動させません。
また、その直後に、COMM_UPイベントが各ノードで発生しします。各ノードのCOMM_UPイベントの処理では、Quoru を持っていると判断し、またノードBでリソースがサービス中のためリソースは起動させません。

リソースがノードBでサービス中に、通信不能かつ共有ストレージにアクセス可能な状態でノードAのサーバーが電源ON

この場合、ノードAはLCM_AVAILイベントを処理します。ノードAは、Quorumを持っていると判断し、通信できないノードBに障害が発生しているか確認するためノードBのQWKオブジェクトの更新を確認します。ノードBは稼働しているため、QWKオブジェクトは定期的に更新されます。ノードAではQWKオブジェクトの更新を確認し、ノードBが生存しているが通信できないためにリソースは起動させません。
ノードBはノードAと通信できないので何もしません。

シナリオ3

ノードAのネットワークに障害が発生（ノードAは稼働しているが、他のノードや共有ストレージにアクセス不能）

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

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

2. 共有ストレージにアクセス不能であるため、Quorumを持っていないと判断します。

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

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

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

2. 共有ストレージにアクセス可能であるため、Quorumを持っていると判断します。

3. ノードAのQWKオブジェクトの更新が停止していることを確認します（Witnessチェック）。

4. Witnessチェックの結果、ノードAで障害が発生していると判断したため通常のフェイルオーバー処理を開始します。これにより保護対象のリソースはノードBでサービス中になります。

リソースがノードBでサービス中に、共有ストレージにアクセス可能な状態でノードAのサーバーが電源ON

シナリオ2と同じです。

リソースがノードBでサービス中に、共有ストレージにアクセス不能な状態でノードAのサーバーが電源 ON

この場合、ノードAはLCM_AVAILイベントを処理します。ノードAは、Quorumを持っていないと判断し、リソースを起動させません。
ノードBとのコミュニケーションパス通信が可能であれば、その後にCOMM_UPイベントが発生します。しかし、Quorumを持っていないので、ノードAではリソースを起動させません。