Hitachi

高信頼化システム監視機能 HAモニタ AIX(R)編


3.3.4 マルチスタンバイ機能使用時の系のリセットの抑止

稼働する系の総数が三つ以上となる複数スタンバイ構成の場合,監視パス障害などで一つの系が残りの系の系障害を検知すると,次の図の例のように,残りのすべての系をリセットして一つの系に系切り替えをすることがあります。この場合,一定数以上の系が稼働している必要があるシステムでは,業務が停止してしまいます。

図3‒15 複数スタンバイ構成で,残りのすべての系をリセットして一つの系に系切り替えをする場合の例

[図データ]

この例は,メモリ容量などの理由によって一つの系で実行サーバを3台以上稼働させられないシステムとしています。このシステムでは,系1で実行サーバが5台稼働しようとすると,システムが動作できないため,業務が停止してしまいます。

HAモニタでは,このような一定数以上の系が稼働している必要があるシステムで系がリセットされるのを抑止し,業務が停止するのを防止できます。システムが業務を継続するために必要な系の数のことを,最少稼働ホスト数と呼びます。ここでは,系のリセット抑止時の動作や環境設定などについて説明します。

〈この項の構成〉

(1) 系のリセット抑止時の動作

次に示す場合別に,系のリセット抑止時のHAモニタの動作について説明します。

ここでは,最少稼働ホスト数が3で,かつ一つの系で稼働できる実行サーバの数が2台までの場合を例に説明します。

(a) 一つの系で系障害が発生して系をリセットし,業務が継続する場合

一つの系で系障害が発生して系をリセットし,業務が継続する場合の動作について,次の図に示します。

図3‒16 一つの系で系障害が発生して系をリセットし,業務が継続する場合の動作

[図データ]

次に,図に示した流れの詳細について説明します。番号は,図中の番号と対応しています。

  1. 系4で系障害が発生し,aliveメッセージが途絶します。aliveメッセージの途絶によって,系1〜系3,および系5は系4の障害を検出します。

  2. 系1〜系3,および系5は,障害検知通知を送受信し合います。

  3. 系1〜系3,および系5は,それぞれ受信した障害検知通知の数をカウントし,最少稼働ホスト数以上の系が稼働していることを確認します。このため,最もリセット優先度が高い系1が,系4をリセットします。

  4. 系4で稼働していた実行サーバが系切り替えをします。この図では,系5の待機サーバに系切り替えをする場合を例にしています。

この例の場合,系切り替え後もすべての実行サーバが稼働していて,かつ一つの系で実行サーバが最大で2台しか稼働していないため,業務が継続します。

(b) 一つの系で監視パス障害が発生して系のリセットを抑止し,業務が継続する場合

一つの系で監視パス障害が発生して系のリセットを抑止し,業務が継続する場合の動作について,次の図に示します。

図3‒17 一つの系で監視パス障害が発生して系のリセットを抑止し,業務が継続する場合の動作

[図データ]

次に,図に示した流れの詳細について説明します。番号は,図中の番号と対応しています。

  1. 系1で監視パス障害が発生し,aliveメッセージが途絶します。aliveメッセージの途絶によって孤立した系1は,系2〜系5の障害を検出します。一方,系2〜系5は,系1の障害を検出します。

  2. 系1は監視パス障害で障害検知通知を送信できないため,受信待ちとなります。一方,系2〜系5は,障害検知通知を送受信し合います。

  3. 系1は障害検知通知を受信できないため,最少稼働ホスト数以上の系が稼働していることを確認できません。このため,系2〜系5のリセットを抑止します。

  4. 系2〜系5は,それぞれ受信した障害検知通知の数をカウントし,最少稼働ホスト数を満たしていることを確認します。このため,リセット優先度の高い系2が,10秒後に系1をリセットします。

  5. 系1で稼働していた実行サーバが系切り替えをします。この図では,系2の待機サーバに系切り替えをする場合を例にしています。

この例の場合,系切り替え後も最少稼働ホスト数を満たしていて,かつ一つの系で実行サーバが最大で2台しか稼働していないため,業務が継続します。

(c) 三つの系での縮退運用中に系障害が発生してリセットを抑止し,業務が停止する場合

三つの系での縮退運用中に系障害が発生してリセットを抑止し,業務が停止する場合の動作について,次の図に示します。

図3‒18 三つの系での縮退運用中に系障害が発生してリセットを抑止し,業務が停止する場合の動作

[図データ]

次に,図に示した流れの詳細について説明します。番号は,図中の番号と対応しています。

  1. 系3で系障害が発生し,aliveメッセージが途絶します。aliveメッセージの途絶によって,系1および系2は系3の障害を検出します。

  2. 系1および系2は,障害検知通知を送受信し合います。

  3. 系1および系2は,受信した障害検知通知の数が最少稼働ホスト数を満たしていないため,系3のリセットを抑止します。

  4. すべての系でリセットが抑止されると,系1および系2では系3の状態を確認できなくなります。実行サーバが複数起動することを防止するため,次のようにサーバが状態遷移します。

    • 系3上の待機サーバよりもサーバ優先度が低い待機サーバ:停止します("SBY"→"停止")。

      系1または系2に障害が発生した場合に,系3上の待機サーバの状態が変化することがあるためです。

    • 系間で最もサーバ優先度の高い待機サーバ:系切り替え待ち状態になります("SBY"→"ONL??")。

      系3上で実行サーバが稼働し続けている可能性があるためです。

    注※

    すべての系でリセットが抑止されるまでの時間は,「10(機種によって異なる)×グループを構成する系の総数」で求められます。例えば,系の数が32の場合,次の計算式のようになります。

    10×32=320秒=5分20秒

この例の場合,系3で稼働していた実行サーバがなくなり,最少稼働ホスト数である3を満たさなくなるため,業務が停止します。

なお,他系に系切り替えできる待機サーバの有無によって,待ち状態のサーバ起動コマンド(monactコマンド)の実行などの操作が必要です。詳細については,サーバが停止した場合は「7.2.1 起動する」を,サーバが系切り替え待ち状態(ONL??)になった場合は「7.4.1 待ち状態のサーバを起動して業務を再開する」を参照してください。

(2) 系のリセットを抑止できる障害

系のリセットを抑止できるのは,aliveメッセージの途絶によって検出できる系障害の場合だけです。

他系のHAモニタからペアダウンを通知された場合や,系切り替え時に共有ディスクの切り離しに失敗した場合は,他系からの障害検知通知を待たないで他系をリセットして系切り替えをします。また,ハードウェアから障害通知を受信した場合,他系のOSパニックを検知した場合,およびサーバ障害が発生した場合は,障害検知通知を待たないで系切り替えをします。

(3) 系のリセットを抑止するための条件と例

次の条件をすべて満たす場合にだけ,系のリセットを抑止できます。

系のリセットを抑止できる例とできない例を,それぞれ次の図に示します。

図3‒19 系のリセットを抑止できる例

[図データ]

この例では,系のリセットを抑止するためのすべての条件を満たしています。

図3‒20 系のリセットを抑止できない例

[図データ]

この例では,系1〜系3上に,系4および系5上のサーバとペアになる待機サーバが存在しません。そのため,系のリセットを抑止するための条件を満たしていません。

メモ

最少稼働ホスト数として,接続する系の総数の半数以下の値を設定してしまうと,ネットワークの分断(スプリットブレイン)が発生するとき,分断された構成内で最少稼働ホスト数を超えてしまい,リセットし合ってしまうおそれがあります。このため,最少稼働ホスト数には,接続する系の総数の半数よりも大きな値を設定してください。

(4) 必要な環境設定

系のリセットを抑止するには,HAモニタの環境設定のsuppress_resetオペランドを指定します。