test

Sun Cluster 2.2 のシステム管理

障害追跡の概要

Sun Cluster の基本的なアーキテクチャの説明で述べたように、1 台のサーバーがダウンした場合、ほかのサーバーがテイクオーバーします。ここでは、「あるサーバーがダウンしたことを別のサーバーはどのようにして認識するのか」を説明します。

Sun Cluster は、3 つの障害検証方法を使用します。

2 つ目と 3 つ目の方法では、1 台のサーバーがほかのサーバーの応答を検証します。明らかな問題が検出されると、検証側サーバーは、ほかのサーバーからのテイクオーバーを強行する前に、それ自体の妥当性検査を多数行います。これらの妥当性検査では、ほかのサーバーから応答がない実際の原因が検証側サーバーにないことを確認します。これらの妥当性検査は、Sun Cluster のベースフレームワークの一部であるライブラリサブルーチン hactl(1M) によって提供されます。そのため、データサービス固有の障害検証コードは、検証側サーバーの妥当性検査を行う場合 hactl(1M) を呼び出すだけですみます。詳細は、hactl(1M) のマニュアルページを参照してください。

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

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

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

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

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

検証側ノードの妥当性検査

ネットワーク障害の検証とデータサービス固有の障害検証では、各ノードは別のノードの応答を検証する必要があります。テイクオーバーを行う前に、検証側ノードは自身の基本的な妥当性検査を多数行います。これらの検査は、障害の原因が実際に検証側ノードにないことを確認するとともに、障害があると思われるサーバーからのテイクオーバーによって状況が実際に改善されるかどうかを確認します。これらの妥当性検査が行われないと、誤ったテイクオーバーが発生する可能性があります。つまり、欠陥のあるノードに、ほかのノードが応答しないことによって、その欠陥のあるノードが誤って問題のないそのサーバーをテイクオーバーすることがあります。

検証側ノードは、別のノードをテイクオーバーする前に、自身に対して次の妥当性検査を行います。