RMSはUDPハートビート信号を定期的に送信しています。最後のハートビート送信時からの応答時間が、設定された接続タイムアウト値を超えた場合に、RMSはノードとの接続が失われたと判断します ("HV_CONNECT_TIMEOUT" を参照)。RMSはここでノードのリカバリ期間に入ります。ノードのハートビートがリカバリ期間中に検出されれば、RMSはノードの機能が回復し、正常な状態に戻ったと判断します。しかし、リカバリ期間終了時までにノードからのハートビートを受信しなかった場合は、そのノードとの間で他の通信が可能な場合でも、RMSはノードがDOWN状態にあると判断します。
RMSはノードがDOWN状態にあると判断すると、アプリケーションとクラスタの整合性を保証するための処理を開始します。処理の最初に、ノードが本当に停止しているかを確認する必要があります。停止していなかった場合には、後にノードとノードのアプリケーションが予期せず回復し、競合やデータ破損が生じる恐れがあります。このような問題を避けるため、RMSはシャットダウン機構 (後述) を使用してノードの強制停止を行います。これは通常、ノードの再起動や電源切断によって行われますが、正確にはどのシャットダウンエージェントがそのノードに割り当てられているかによって決まります。ノードが強制停止されてはじめて、RMSはそのノードのアプリケーションをクラスタ内の別のノードで安全に再起動できるようになります。障害が発生しているノードから正常なノードにアプリケーションを自動的に切替える処理を、アプリケーションのフェイルオーバと呼びます。
アプリケーションの切替えはクラスタの性能に影響を与えるため、ノード停止の検出を誤らないようにリカバリ期間の設定を適切に行うことが重要です。最適なUDPリカバリ期間はクラスタの状態によって異なります。ノードやベースモニタの故障対応に重点を置くなら、リカバリ期間が短いほうが適しています。しかし、過負荷が生じたノードからの応答は遅くなることを考えると、リカバリ期間を長くしておいたほうが不必要なシャットダウンは避けられます。UDPを単独で使用すると、これらの相反する要求によって、大規模なクラスタや負荷の大きいクラスタでは、リカバリ期間の調整が困難になります。
UDPでは障害発生の原因となりうる場合が3つあるため、信頼性に欠けるので注意が必要です。1つめは、応答を要求する送信がリモートノードに到達しない場合です。この場合当然応答は返されません。2つめはリモートノードの負荷が大きい場合です。この場合はリカバリ時間内に応答できない可能性があります。応答時間が低い値に設定されている場合には、この危険はさらに大きくなります。3つめは応答パケットがリモートノードからネットワークに送り出されても、何らかの理由でローカルノードに到達しない場合です。上記いずれの場合でも、ローカルノードはリカバリ期間経過するまで処理ができなくなります。
クラスタの応答性を高めるために、RMSではマシンの状態と接続状況を確認する手段として、ELM (Enhanced Lock Manager) を使用します。ELMはポーリングを行いません。ELMは、CFがカーネルレベルで管理するロックを基に判定を行います。ノードは、クラスタに参入するとロックを作成し、ベースモニタの作動中はそのまま保持します。このロックは、ノードまたはベースモニタが停止した時点で解放されます。ロックの状態はCFによってバックグラウンドで保持されるため、各ノードのRMSはローカルにロックの状態を参照できます。
ELMはノードまたはベースモニタの障害検出を優先するよう設計されています。このため、リカバリ時間を比較的大きな値に設定して、UDPハートビートをノードの応答速度低下の検出に最適化させることができます。UDPハートビートはELMを補完します。CPUまたはネットワークインタフェースに過負荷のかかったノードは応答が遅くなりますが、CFはノードのロックの状態を保持し続けます。この状態が続くと、最終的にはUDPハートビートのリカバリ期間が経過し、RMSがノードの停止処理を開始します。ELMにより、RMSがノードの停止処理を開始する確率は非常に低くなります。
ELMの手動停止は、システムに詳しい専門家により、ローリングアップデートまたはデバッグの場合にのみ行ってください ("HV_USE_ELM" を参照)。この場合はさらに、RMSが起動してから、hvcm -h <timeout>を使用してUDPハートビートリカバリのタイムアウト時間をより小さな値に手動設定する必要があります。これは、ELMが停止している場合に、リモートのベースモニタとノードの停止を効率的に検出するために必要です。
