JGroupsを利用したクラスタ関連 ～その参 障害検知の仕組み ～

障害検知（FD）
～ FD（FailureDetection）は、ハートビートメッセージを利用して、
障害が発生したメンバーを検出する為の仕組みです。
メンバーは、HEARTBEATを受信すると、HEARTBEAT ACKを返信する事で
これに応答し、正常に疎通出来ることを定期的に確認しています。
各メンバーは、A→B→C→Aのようにリング状に、メンバーリストにいる
自分の次のメンバーに対して監視するようになっています。
ここでは、メンバーAからの視点で記述しています。



メンバーAは、メンバーBに対して定期的にHEARTBEATメッセージを送信し、
メンバーBがこれに応答する HEARTBEAT ACKメッセージを返信する事で、
通信状態を確認しています。
同様に、メンバーBはメンバーCの障害を監視しており、メンバーCは
メンバーAの障害を監視しています。

メンバーBが通信不能な状態になると、メンバーBに対してHEARTBEATを
送信していたメンバーAは、一定時間以上、メンバーBからの応答がない為、
メンバーAの障害を検出します。（FDによる障害検知）

但し、この時点では障害が発生しているかもしれない（容疑者）の状況であり、
他メンバーから再確認させるの為の検証フェーズが開始されます。

メンバーAは、メンバーBの障害を検出した事を他メンバーに知らせる為に、
SUSPECTメッセージをマルチキャストで送信します。

メンバーA、メンバーCは、SUSPECTメッセージを受信し、メンバーBに障害が
検出された事を知る為、検証フェーズ（※１）が開始されます。

----------------------------------------------------------------
※１．VERIFY_SUSPECT
障害を検出した場合、本当にそのメンバーが通信不可能である事を
再確認する為に、「ARE YOU DEAD」メッセージによる再検証が行われます。
また、この検証する仕組みの事は「VERIFY_SUSPECT」と呼ばれ、
SUSPECTメッセージを受信すると開始されます。
「ARE YOU DEAD」メッセージの送信に対する「I AM NOT DEAD」
メッセージの応答によって障害を判定しています。
----------------------------------------------------------------

メンバーB、メンバーCは、メンバーAに対して、「ARE YOU DEAD」メッセージ
を送信後、「I AM NOT DEAD」メッセージの応答を待ちます。
この応答が一定時間返ってこない場合、メンバーAは障害が発生したと
判定されます。

また、メンバーAは、これまで監視していたメンバーBがいなくなった為、
自分の次のメンバーにあたるメンバーCの障害監視を始める事になります。

このようにFDは、ハートビートを送信する事で、相手の通信状態を確認する
為の仕組みを担っています。

----------------------------------------------------------------
※ポイント
障害監視していた自分の隣のメンバーが除外された場合、次は、
その隣のメンバーに対して障害監視を始めることになります。
----------------------------------------------------------------



障害検知（FD_SOCK）
～ FD_SOCKは、自分自身の障害を検知して、いつまでもメッセージを
送り続けないようにする仕組みです。
KEEP_ALIVE（トラフィックを2時間受信していないソケットにハートビート
を送信する）で、メンバーリストの隣のメンバーにソケット接続し、
LANを切断するなどしてコネクションが切断された場合に、障害を検出します。
また、FD_SOCKは、コネクションを閉じずにホスト (またはスイッチや
ルーター)がクラッシュすると、KEEP_ALIVEによるハートビートが送信される
2 時間後まで検出する事が出来ません。

各メンバーは、A→B→C→Aのようにリング状に、メンバーリストにいる自分
の次のメンバーに対して監視するようになっています。
ここでは、FDの処理と比較する為、メンバーBからの視点で記述しています。



メンバーBは、自分の次のメンバーにあたるメンバーCに対して監視（ソケット接続）
しています。
（VIEWメッセージの受信によりメンバーリストが更新されると、
その度に接続しなおしています。）

メンバーBのLANが切断されると、そのタイミングでコネクションが閉じられ、
メンバーCの障害を検出します。
また、次のメンバーAに接続しようとしますが、接続できない為、
メンバーAの障害も検出します。

これにより、メンバーBは、メンバーAとメンバーCを自分のメンバーリストから除外して、
いつまでもメッセージを送信し続けないようにしています。

FDとFD_SOCKの関連性
FDは、他メンバーの障害を検出するのに対し、
FD_SOCKは、自分の障害はすぐに検出できますが、他メンバーの障害は、
KEEP_ALIVEが行われる最大２時間後まで検出する事が出来ません。
（上記の例の場合、メンバーBのLANを切断してもメンバーAはFD_SOCK
だけでは即座に検知する事が出来ない）
FDとFD_SOCKを組み合わせる事により、安定した障害検出を行うことが
出来るようになります。

----------------------------------------------------------------
※ FDとFD_SOCKの特性
FD
・過負荷の状態にあるマシンは、are-you-alive 応答の送信時に
パフォーマンスが低下する恐れがある。
・メンバーは、デバッガ/プロファイラでサスペンドしたときでも疑われてしまう。
・タイムアウトを小さくすると、間違った疑いの可能性が大きくなり、
ネットワークトラフィックが増大する。
・タイムアウトが大きいと、クラッシュされたメンバが一定の時間検出されず、
破棄されない。
FD_SOCK
・デバッガでサスペンドしてもTCP接続はまだオープンなので問題がない。
・同様の理由により、高負荷の状況でも問題とはならない。
・メンバーのTCP接続が中断された場合にのみ疑われ、
ハングしたメンバ検出されない。
・スイッチがクラッシュした場合は、TCPタイムアウトになるまで検出されない。
----------------------------------------------------------------