Sun Cluster データサービスの障害モニター

この節では、データサービス障害モニターの一般的な事項について説明します。Sun が提供するデータサービスには、パッケージに組み込まれている障害モニターがあります。障害モニター (または障害検証機能) は、データサービスの状態を検証するプロセスです。

障害モニターの呼び出し

障害モニターは、リソースグループとそのリソースをオンラインにしたときに、RGM によって呼び出されます。この呼び出しによって、RGM はそのデータサービスの MONITOR_START メソッドの呼び出しを内部で行います。

障害モニターは、次の 2 つの機能を実行します。

• データサービスのサーバープロセスまたはプロセスの異常終了の監視

• データサービスの状態の検査

サーバープロセスの異常終了の監視

プロセスモニター (PMF : Process Monitor Facility) は、データサービスプロセスを監視します。

データサービスの障害検証は、無限ループで実行され、 Thorough_probe_interval リソースプロパティによって設定された調整可能な期間に休止状態 (スリープ) になります。休止している間に、検証機能は プロセスが終了したかどうかについて PMF により検査します。サーバープロセスが終了した場合は、その後、検証機能はデータサービスの状態を「Service daemon not running」で更新し、操作を実行します。実行する操作には、データサービスのローカルでの再起動、または二次クラスタノードへのデータサービスのフェイルオーバーなどが含まれます。検証機能は、そのデータサービスアプリケーションリソースの Retry_count および Retry_interval リソースプロパティで設定されている値を調べ、データサービスを再起動するか、またはフェイルオーバーするかを決定します。

データサービスの状態の検査

通常、検証機能とデータサービスとの間の通信は、専用のコマンドまたは指定したデータサービスポートとの正常な接続によって行われます。

検証機能は主に以下の操作を行います。

1. 休止します (Thorough_probe_interval)。

2. タイムアウトプロパティ Probe_timeout で状態検査を実行します。Probe_timeoutは、ユーザーが設定可能な各データサービスのリソース拡張プロパティです。

3. 手順 2 を実行し、サービスの状態に異常がなければ、正常/異常の履歴を更新します。Retry_interval リソースプロパティに設定されている値よりも古い履歴を消去 (パージ) することで、正常/異常の履歴を更新します。検証機能は、リソースの状態メッセージを「Service is online」に設定し、手順 1 に戻ります。

   手順 2 の結果、サービスの状態に異常があれば、検証機能は異常履歴を更新します。その後、状態検査に失敗した総数を計算します。

   状態検査の結果は、致命的な異常から正常までの範囲があります。結果の判断は、個々のデータサービスに依存します。たとえば、検証機能が正常にサーバーに接続でき、ハンドシェイクメッセージをサーバーに送信できるにも関わらず、この検証機能がタイムアウト前に一部の応答しか受け取ることができない場合を考えてみます。このケースは、システムの過負荷の結果として、最も発生する可能性があります。サービスの再起動など、操作を何か実行すると、クライアントはそのサービスに接続するため、さらにシステムの負荷が増大します。このような場合に、データサービスの障害モニターは、この「一部」の異常を致命的なものとして扱わないようにします。代わりに、モニターは、この異常をサービスの致命的ではない検証として追跡します。これらの一部の異常は、Retry_interval プロパティによって指定された期間、累積されます。

   ただし、検証機能がまったくサーバーに接続できない場合は、致命的な異常であると認識されます。一部の異常が、断片的な量によって異常カウントの増加につながります。致命的な異常、または一部の異常の累積のいずれかによって、異常カウントが 合計カウントに到達するたびに、検証機能はデータサービスの再起動またはフェイルオーバーによってこの状況を修正しようとします。

4. 手順 3 (履歴期間内での異常の数)での計算の結果、Retry_count リソースプロパティの値よりも少ない場合は、検証機能は、状況をローカルで修正しようとします (たとえば、サービスの再起動)。検証機能は、リソースの状態メッセージを「Service is degraded」に設定し、手順 1 に戻ります。

5. Retry_interval で指定した期間内で発生した異常の数が Retry_count の値を超える場合、検証機能は、scha_control を「giveover」オプション付きで呼び出します。このオプションは、サービスのフェイルオーバーを要求します。この要求によって異常が修正されると、このノードでの障害モニターが停止されます。検証機能は、リソースの状態メッセージを「Service has failed」に設定します。

6. さまざまな理由により、前の手順で発行された scha_control 要求が Sun Cluster フレームワークによって拒否されることがあります。この理由は、scha_control のリターンコードで識別できます。検証機能は、リターンコードを調べます。scha_control が拒否される場合、検証機能は異常/正常履歴をリセットし、新たに開始します。検証機能が履歴をリセットするのは、異常の数がすでに Retry_count を超えているため、障害モニターが各後続の繰り返しで scha_control を発行しようとするためです (ただし、再び拒否されます)。この要求は、システムの負荷をさらに高め、サービス障害がさらに生じる可能性が増大します。

   その後、検証機能は、手順 1 に戻ります。