2.10.2　一定数の同意によって確定するEADSサーバダウン

あらかじめ設定したタイムアウト時間（デフォルトは2秒）が経過してもハートビートを送信しないEADSサーバがある場合，クラスタ内のEADSサーバはそのEADSサーバに対して生存確認を行います。生存確認がタイムアウトすると，一定数（デフォルトは1）の同意によってEADSサーバダウンを判定します。ダウンが確定すると，そのEADSサーバはクラスタから削除されます。

EADSサーバ間のハートビートの送信によって常時クラスタを監視しているため，早期にEADSサーバダウンを検知できます。

EADSサーバダウンを検知するまでの流れを，次の図に示します。

図2‒29　EADSサーバダウンを検知するまでの流れ

1. EADSサーバ3からハートビートが送信されない場合，クラスタ内のEADSサーバはEADSサーバ3に対して生存確認を行います。

2. EADSサーバ3からハートビートが送信されないまま，生存確認がタイムアウトすると，クラスタ内のEADSサーバは，「EADSサーバ3が危険状態である」という情報を付与してハートビートを送信し合います。

3. 一定数（デフォルトは1）のEADSサーバがEADSサーバ3の状態が危険であることに同意すると，EADSサーバ3のダウンが確定します。

   クラスタ内のEADSサーバに対して，EADSサーバ3をクラスタから削除してよいか合意を取ります。クラスタ内で過半数の合意を得たら，EADSサーバ3はクラスタから削除されます。

   削除されたEADSサーバは強制的に縮退状態となります。縮退状態とは，EADSクライアントからのリクエストを受け付けない状態のことです。

注意事項

障害発生時にデータの多重度未満の数のEADSサーバがダウンしても，クラスタを継続できます。

例えば，データの多重度が3，EADSサーバ数が5つの場合，2つのEADSサーバがダウンしても，クラスタを継続して監視できます。

ページの先頭へ