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

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

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

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

図2‒24　 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サーバがダウンしても，クラスタを継続して監視できます。

ページの先頭へ