26.1.3　スタンバイレス型系切り替え機能

(a)　前提条件

1：1スタンバイレス型系切り替え機能を使用する場合は次に示す前提条件をすべて満たす必要があります。

• HiRDB Advanced High Availabilityを導入している

• Hitachi HA Toolkit Extensionを導入している

• 系切り替え機能をサーバモードで運用している

(b)　スタンバイ型系切り替え機能と比較して優れている点

1：1スタンバイレス型系切り替え機能はスタンバイ型系切り替え機能に比べて次に示す点が優れています。

• 待機系ユニットを準備する必要がないため，システムリソースを効率的に使用できます。ただし，系が切り替わると代替BESではその分の負荷が大きくなるため，処理性能に影響を与えることがあります。

• サーバプロセス及びシステムサーバをあらかじめ起動しておくため，系の切り替え時間を高速系切り替え機能使用時と同じくらいに短縮できます。高速系切り替え機能については，「系の切り替え時間の短縮（ユーザサーバホットスタンバイ，高速系切り替え機能）」を参照してください。

待機系ユニットの待機時の所要リソースと系切り替え後の所要リソースを次の表に示します。

表26‒5　待機系ユニットの待機時の所要リソースと系切り替え後の所要リソース

項目			HiRDBシステムサーバプロセス	HiRDBサーバプロセス	ユニットコントローラ用共用メモリ	排他制御用プール用共用メモリ	グローバルバッファ用共用メモリ
サーバモード	1：1スタンバイレス型系切り替え機能		●※１	−※２※３	●※４	●	−※５
	影響分散スタンバイレス型系切り替え機能		△※６※７	−※３※８	●※９	●	−※１０
	スタンバイ型系切り替え機能	ユーザサーバホットスタンバイ	○	●	●	○	○
		高速系切り替え機能	●	●	●	●	●
		それ以外	○	○	●	○	○
モニタモード			○	○	○	○	○

（凡例）

●：待機完了までに確保して，系の切り替え後も使用します。

○：系の切り替え後，実行系になった時点で確保して使用します。

△：一部のリソースを系切り替え後に実行系となった時点で確保し，使用します。

−：確保しません。

注※1

システムサーバプロセスのうち，幾つかのプロセスは待機時点でプロセスを生成します。それ以外のシステムサーバは代替BESユニットのシステムサーバプロセスを共有するため，代替部専用の所要リソースはありません。

注※2

バックエンドサーバプロセスの上限値は，代替中及び非代替中の合計が代替BESのpd_max_bes_processの値になります。そのため，系の切り替え後に接続ユーザ数が制限されることがあります。

注※3

pd_process_countの値（常駐プロセス数）＜pd_max_bes_processの値でかつ，系切り替え発生時点で起動済みのバックエンドサーバプロセス数がpd_max_bes_processの値に満たない場合は，バックエンドサーバプロセスの追加起動が発生します。そのため，系切り替え発生後にOSのプロセス数，仮想メモリ，ポートなどが不足しないように環境設定をしてください。また，バックエンドサーバプロセスの追加起動によって，系切り替え発生直後の性能が一時的に低下することがあります。

注※4

代替BESユニットの開始時に代替部の共用メモリが確保されます。

注※5

代替BESが使用しているグローバルバッファを代替中に共用します。そのため，系切り替え後には確保しません。代替中のグローバルバッファの割り当て方式については，「グローバルバッファの定義（1：1スタンバイレス型系切り替え機能限定）」を参照してください。

注※6

ユニット単位のシステムサーバプロセスを受け入れユニットと共用するため，ゲスト用領域専用としての所要リソースはありません。

注※7

バックエンドサーバ対応のシステムサーバプロセスは，実行系となった時点でプロセスを生成します。

注※8

系切り替え後のユニット内のサーバプロセス数の上限値については，通常バックエンドサーバ用プロセス数とゲストBES用プロセス数の合計値として定義できます（pd_ha_max_server_process）。

注※9

受け入れユニット起動時，ゲスト用領域分の共用メモリが確保されます。

注※10

受け入れユニットに対して通常バックエンドサーバが使用しているグローバルバッファを共用する場合に共用します。そのため，系切り替え後には確保しません。共用時のグローバルバッファの共用については，「グローバルバッファの定義（影響分散スタンバイレス型系切り替え機能限定）」を参照してください。

影響分散スタンバイレス型系切り替え機能適用時のバックエンドサーバのリソース使用状況については，「影響分散スタンバイレス型系切り替え機能」を参照してください。

(c)　正規BESユニット及び代替BESユニット定義時の規則

正規BESユニット及び代替BESユニット定義時の規則を次に示します。

• 正規BESユニット及び代替BESユニット内にはバックエンドサーバだけを定義できます。バックエンドサーバ以外のサーバがある場合はそのユニットにスタンバイレス型系切り替え機能を適用できません。

• 正規BESユニットと代替BESユニットは1対1の関係にしてください。

• 正規BESと代替BESは1対1の関係にしてください。

• 正規BESユニット内に複数の正規BESを定義できます。この場合，代替BESユニット内にも同数の代替BESを定義してください。

正規BESユニット及び代替BESユニットの正しい構成例を次の図に，間違った構成例を図「正規BESユニット及び代替BESユニットの間違った構成例」に示します。

図26‒6　正規BESユニット及び代替BESユニットの正しい構成例

代替BESはpdstartオペランドの-cオプションで定義します。上記の図の例1及び例2のpdstartオペランドの指定例を次に示します。

例1

pdstart -t BES -s bes11 -u UNT1 -c bes21
pdstart -t BES -s bes21 -u UNT2

〔説明〕

-s bes11：正規BESを指定します。

-c bes21：代替BESを指定します。

例2

pdstart -t BES -s bes11 -u UNT1 -c bes21
pdstart -t BES -s bes12 -u UNT1 -c bes22
pdstart -t BES -s bes21 -u UNT2
pdstart -t BES -s bes22 -u UNT2

〔説明〕

-s bes11，-s bes12：正規BESを指定します。

-c bes21，-c bes22：代替BESを指定します。

図26‒7　正規BESユニット及び代替BESユニットの間違った構成例

(a)　機能概要

障害発生時に障害ユニット内のバックエンドサーバへの処理要求を，複数の稼働中ユニットに分散して実行させる機能を影響分散スタンバイレス型系切り替え機能といいます。影響分散スタンバイレス型系切り替え機能では，待機用サーバマシン，又は待機ユニットを準備する必要はなく，システムリソースを効率的に利用できます。障害発生後，障害ノードのサーバ処理を代行するユニットでは処理負荷が増えるため，トランザクション処理性能に影響を及ぼすことがあります。ただし，複数のユニットが障害ユニット内サーバへの処理要求を分担して実行することで，ユニット当たりの負荷上昇を抑え，システムの性能劣化を軽減します。

また，影響分散スタンバイレス型系切り替え機能では，バックエンドサーバを分散して切り替えられます。切り替え先を複数のユニットに分散させることもできます。さらに，障害発生によって切り替えた先のユニットで更に障害が発生しても，別の稼働中ユニットに更に切り替わることで処理を継続できます（以降，多段系切り替えといいます）。なお，1：1スタンバイレス型系切り替えの場合は多段系切り替えができないため，切り替え先で障害が発生すると障害ユニットの代行処理は継続できなくなります。

影響分散スタンバイレス型系切り替え機能は，通常時からシステムリソースを有効に利用することを重視し，しかも，障害発生時の性能劣化を最小限に抑える必要があるシステムに対して適用してください。

なお，影響分散スタンバイレス型系切り替え機能では，そのユニットに定義してあるバックエンドサーバをホストBESといい，定義してあるユニットとは別のユニットに受け入れてもらっているバックエンドサーバをゲストBESといいます。ホストBESのユニットを正規ユニットといい，ゲストBESのユニットを受け入れユニットといいます。受け入れユニットのすべてはHAグループとして定義しておく必要があります。また，ゲストBESに対応付けられるバックエンドサーバ用のリソースをゲスト用領域といいます。

影響分散スタンバイレス型系切り替え機能の概要（分散代行，多段系切り替え）を次の図に示します。

図26‒8　影響分散スタンバイレス型系切り替え機能の概要（分散代行，多段系切り替え）

(b)　前提条件

影響分散スタンバイレス型系切り替え機能を使用する場合は次に示す前提条件をすべて満たす必要があります。

• HiRDB Advanced High Availabilityを導入していることが必要です。

• Hitachi HA Toolkit Extensionを導入していることが必要です。

• 系切り替え機能をサーバモードで運用していることが必要です。

• 影響分散スタンバイレス型系切り替え機能は，バックエンドサーバだけから構成されるバックエンドサーバ専用ユニットだけを対象としています。

• 影響分散スタンバイレス型系切り替え機能を適用するユニットは，一つ以上の現用系のバックエンドサーバから構成される必要があります。受け入れ専用のユニットには適用できません。

(c)　リソース使用状況

影響分散スタンバイレス型系切り替え機能適用時のバックエンドサーバのリソース使用状況を次の表に示します。

表26‒6　影響分散スタンバイレス型系切り替え機能適用時のバックエンドサーバのリソース使用状況

バックエンドサーバの種別	バックエンドサーバの状態	リソース使用状況
ホストBES	受け入れ可能状態	各バックエンドサーバの定義に従ったサイズで領域を作成します。
	稼働中	各バックエンドサーバの定義に従ったサイズ分領域を使用します。
ゲストBES	受け入れ可能状態	リソースごとにゲストサーバ中最大リソースサイズでゲスト用領域を作成します。
	稼働中	用意したゲスト用領域のうち各バックエンドサーバの定義に従った領域を使用します。

(d)　影響分散スタンバイレス型系切り替え機能の動作

影響分散スタンバイレス型系切り替え機能では，正規ユニットに障害が発生した場合，現用BESはそれぞれ自動的に別々の受け入れユニットに移動してゲストBESとして処理を実行します。また，障害が発生したユニットでゲストBESが稼働している場合には，そのゲストBESも自動的に受け入れユニットに移動し，移動先のゲストBESとして処理を実行します。スタンバイ型系切り替え機能と同じく，HiRDB管理者の操作は不要です。

影響分散スタンバイレス型系切り替えでの障害要因と系切り替えの有無を次の表に示します。

表26‒7　影響分散スタンバイレス型系切り替えでの障害要因と系切り替えの有無

ユニット又はサーバの状態	開始／停止中	稼働中
		開始／停止中	稼働中
スローダウンの検知	非該当	ユニット異常終了 系切り替えあり	ユニット異常終了 系切り替えあり
システムログの満杯	非該当	ユニット異常終了 系切り替えなし ※	ユニット異常終了 系切り替えなし ※
データベースのパス障害	非該当	ユニット異常終了 系切り替えあり（1回目だけ）	ユニット異常終了 系切り替えあり（1回目だけ）
バックエンドサーバの強制停止	バックエンドサーバの異常終了 系切り替えなし	バックエンドサーバの異常終了 系切り替えなし	バックエンドサーバの異常終了 系切り替えなし
システム強制停止	ユニット異常終了 系切り替えなし	ユニット異常終了 系切り替えなし	ユニット異常終了 系切り替えなし
システム障害	ユニット異常終了 系切り替えなし	ユニット異常終了 系切り替えなし	ユニット異常終了 系切り替えあり

注※

システムログが満杯になった場合，ユニットは異常終了します。このとき，系切り替えはしません。

系切り替えでは，ユニットで稼働中のホストBES及びゲストBESを別のユニットに切り替えます。切り替え先は，バックエンドサーバごとに異なります。

また，影響分散スタンバイレス型系切り替え機能では，多重障害時にも自動的に系を切り替えます。正規ユニット障害後に受け入れユニットで障害が発生した場合，該当の受け入れユニットで稼働していた現用系のバックエンドサーバ及びゲストBESは残りの稼働中ユニットに移動してゲストBESとして処理を実行します。このとき，HiRDB管理者の操作は不要です。なお，各バックエンドサーバの移動先は，クラスタソフトウェアの定義によって決まります。

影響分散スタンバイレス型系切り替え機能では，ユニット内に空きゲスト用領域がなくなるとすべての稼働していないゲストBESの受け入れ可能状態を解除します。ゲスト用領域の受け入れ可能状態は，ホストBESの動作の影響を受けません。ゲスト用領域の空き状態による受け入れ可能状態の自動解除・再設定を次の表に示します。

受け入れ可能状態に自動再設定をする場合，HAグループ内の他ユニットで実行系となっている全サーバを受け入れて可能状態にします。このとき，それ以前に受け入れ可能状態をコマンド（monsbystp，pdstop -q -s バックエンドサーバ名）で意図的に停止していた場合も受け入れ可能状態となります。また，HAグループ内の受け入れ可能数を超えて縮退していた場合も停止中のサーバは，受け入れ可能状態の対象となりません。

表26‒8　ゲスト用領域の空き状態による受け入れ可能状態の自動解除・再設定

ユニット内未使用ゲスト用領域	ゲストBES受け入れ可能状態
	他ユニットで稼働中のゲストBES	他ユニットで非稼働中のゲストBES
消滅	自動解除	変化なし（解除中）
発生	自動再設定	変化なし

注

monsbystpコマンド，又はpdstopコマンド（pdstop -u 受け入れユニットID -s サーバID）などで意図的に受け入れ可能状態を解除した場合を除きます。

(e)　影響分散スタンバイレス型系切り替え機能の系切り替えの例

●通常時の系切り替えの例

通常時の系切り替えの例を次の図に示します。

hostAで障害が発生すると，BES1はunt2に移動してゲストBESとして処理を実行し，BES2はunt3に移動してゲストBESとして処理を実行します。

図26‒9　通常時の系切り替えの例

●受け入れ中の系切り替えの例

受け入れ中の系切り替えの例を次の図に示します。この例は，サーバマシンの障害復旧後に，切り戻し実行前の状態で別のサーバマシンに障害が発生した場合に該当します。

unt1でBES5がゲストBESとして処理を実行している状態で，hostAで障害が発生すると，各バックエンドサーバは次のように動作します。

• BES1はunt2に移動してゲストBESとして処理を実行します。

• BES2はunt3に移動してゲストBESとして処理を実行します。

• BES5はunt3に戻ってホストBESとして処理を実行します。

  図26‒10　受け入れ中の系切り替えの例

ユニット負荷の不均衡

系切り替え発生後にユニット負荷が不均衡になるかどうかはクラスタソフトウェアの定義の待機系の優先度付けに依存します。待機系の優先度を適切に設定すれば，任意の組み合わせで複数ユニットが異常終了した後も負荷を均衡させることができます。

ただし，ユニットが障害から回復した後，ユニット障害後の他ユニット障害による系切り替え後などは，負荷が均衡していない状態になることがあるため，系切り替え後のサーバ配置を確認する必要があります。サーバの配置はpdls -d ha又はpdls -d svrコマンドで確認できます。

サーバの配置が不均衡な場合には計画系切り替えによってサーバの配置を変更することを推奨します。

また，ユニットの障害が復旧した場合はできるだけ早く各BESを定義されたユニットに切り戻すことで，サーバの配置が不均衡になるのを回避できます。受け入れ中の系切り替えの例では，hostAで障害が発生する前にBES5，BES6をunt3に切り戻しておけば，hostAで障害が発生しても不均衡なサーバ配置にはなりません。

●多重障害時の系切り替え（全バックエンドサーバが受け入れ可能な場合）

多重障害時の系切り替えの例を次の図に示します。

図26‒11　多重障害時の系切り替えの例

〔説明〕

hostAで障害が発生すると，BES1はunt2に移動してゲストBESとして処理を実行します。このとき，unt2及びunt3の受け入れ数の上限は4のため，それぞれ，さらに3サーバを受け入れられます。したがって，他ユニットで稼働しているバックエンドサーバをすべて受け入れ可能な状態です。

hostAに続いてhostBで障害が発生すると，unt2で稼働しているBES1，BES3，BES4はunt3に移動してゲストBESとして処理を実行します。停止するバックエンドサーバはありません。

●多重障害時の系切り替え（受け入れ数が不足する場合）

多重障害時の系切り替えで受け入れ数が不足する場合の例を次の図に示します。

図26‒12　多重障害時の系切り替えで受け入れ数が不足する場合の例

〔説明〕

hostAで障害が発生すると，BES1はunt2に移動してゲストBESとして処理を実行します。このとき，unt2及びunt3の受け入れ数の上限は2のため，それぞれ，さらに1サーバを受け入れられます。したがって，他ユニットで稼働しているバックエンドサーバの一部しか受け入れられない状態です。

hostAに続いてhostBで障害が発生すると，unt2で稼働しているBES3だけがunt3に移動してゲストBESとして処理を実行します。BES1及びBES4は停止します。

多重障害発生時にも全バックエンドサーバの処理を続行させる必要がある場合には，受け入れ数上限を大きく設定しておく必要があります。

受け入れ数が不足したときの切り替え

障害発生ユニット中のバックエンドサーバを切り替えるかどうかは，各バックエンドサーバの系切り替えの発生順序で決まります。切り替えの発生順序は，クラスタソフトウェアの動作によって決まります。

この例では，BES3だけが移動する場合を記載していますが，クラスタソフトウェアの動作によっては，BES1，又はBES4が移動することもあります。

●受け入れ数が不足した状態で障害が発生した場合の対処方法の例

受け入れ数が不足した状態で障害が発生した場合の対処方法の例を次の図に示します。

図26‒13　受け入れ数が不足した状態で障害が発生した場合の対処方法の例

〔説明〕

hostBの障害を回復し，unt2を起動します。その結果，unt2でBES4が実行系として起動し，BES1が受け入れ可能状態になります。

次に，unt2でBES1に対してmonactコマンドを入力すると，ゲストBESとしてBES1の処理が開始されます（Hitachi HA Toolkit Extension使用時は，クラスタソフトウェアのオンラインコマンドを使用します）。

●受け入れ数の不足を回避する方法の例

受け入れ数を大きく設定できない場合は，受け入れ数不足によるサーバ停止を回避するためにできるだけ早く障害を回復する必要があります。

受け入れ数の不足を回避する方法の例を次の図に示します。

図26‒14　受け入れ数の不足を回避する方法の例

〔説明〕

hostAの障害を回復し，unt1を起動します。その結果，unt1でBES1とBES2が待機系として起動し，BES3，BES4，BES5，BES6が受け入れ可能状態になります。したがって，hostBで障害が発生しても，BES1とBES4はhostAで処理を継続し，BES3はhostCで処理を継続できます。

●多重障害時の系切り替え（受け入れできなくなる場合）の例

多重障害時に系切り替えができなくなる場合の例を次の図に示します。

図26‒15　多重障害時に系切り替えができなくなる場合の例

〔説明〕

hostAで障害が発生すると，BES1はunt2に移動してゲストBESとして処理を実行します。このとき，unt2及びunt3の受け入れ数上限は1のため，両ユニットともこれ以上サーバを受け入れられません。

hostAに続いてhostBで障害が発生すると，BES1，BES3及びBES4は停止します。

多重障害発生時も全バックエンドサーバの処理を続行させる必要がある場合には，受け入れ数の上限を大きく設定しておく必要があります。受け入れできなくなる場合の対処方法，及びサーバ停止の回避方法は，受け入れ数の不足の場合と同じです。