ハートビート機構: クラスタメンバーシップモニター

Sun Cluster は、ハートビート機構を使用します。ハートビート処理は、メモリーに固定される優先度の高いリアルタイムプロセスによって処理されます。つまり、ハートビート処理は、ページングに制約されません。この処理は、クラスタメンバーシップモニターと呼ばれます。クラスタメンバーシップモニターは、ps(1) による出力には clustd という名前で示されます。

各サーバーは、両方のプライベートリンクを介して約 2 秒に 1 度、稼動していること示すメッセージ (ハートビート) を送信します。そして、両方のプライベートリンク上で、ほかのサーバーからのハートビートメッセージを受信します。どちらかのプライベートリンク上でハートビートを受信していることは、ほかのサーバーの稼動を示す十分な証拠となります。一定の時間 (約 12 秒) ほかのサーバーからのハートビートメッセージがない場合、サーバーはそのサーバーがダウンしていると判断します。

障害の検出という視点から見ると、クラスタメンバーシップモニターのハートビート機構は防御の第一線に当たります。ハートビートが受信されないと、ハードウェアの障害とオペレーティングシステムの障害がすぐに検出されます。ハートビート機構は、すべての通信バッファーの漏出などのような顕著なオペレーティングシステム上の問題を検出することもあります。ハートビート機構は、Sun Cluster の最も高速な障害検証方法でもあります。クラスタメンバーシップモニターはリアルタイムに優先されて動作するとともに、メモリー内に固定されるため、比較的短時間のハートビートの欠如は認められます。逆に、ほかの障害検証方法では、サーバーの速度が単に非常に遅いためにそのサーバーがダウンしていると Sun Cluster で判断されることを避けなければなりません。それらの方法では、数分という比較的長時間のタイムアウトが使用され、複数の長時間タイムアウトが発生しないと Sun Cluster がテイクオーバーを行わないこともあります。

クラスタメンバーシップモニターがリアルタイムに優先されて動作し、かつメモリー内に固定されるという事実は、そのサーバーがデータサービスレベルで有用な作業を行なっていない場合でもメンバーシップモニターが活動する可能性があるという矛盾を生みます。「データサービス固有の障害検証」で説明しているように、データサービス固有の障害監視がこの問題を解決します。