障害モニターの呼び出し

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

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

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

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

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

プロセスモニター (PMF: Process Monitor Facility) は、データサービスプロセスを監視します。異常終了が発生したとき、PMF は、データサービスによって提供されるアクションスクリプトを呼び出し、その障害をデータサービス障害モニターに伝えます。

PMF アクションスクリプトと検証機能との間の通信は、UNIX ドメインソケットを経由して行われます。通信が UNIX ドメインソケットを経由して行われるのは、データサービスが異常終了したことを、アクションスクリプトによって PMF が検証機能に通知するときのみです。このような状況は、データサービスに致命的な異常が発生していることを示しています。

データサービスの障害検証は、無限ループで実行され、Thorough_probe_interval リソースプロパティによって設定された調整可能な期間に休止状態 (スリープ) になります。休止している間は、検証機能は PMF アクションスクリプトからメッセージを検出します。この休止期間中に、サーバープロセスが異常終了した場合は、PMF アクションスクリプトが検証機能に通知します。

その後、検証機能はデータサービスの状態を「Service daemon not running」で更新し、操作を実行します。実行する操作には、データサービスをローカルで再起動する、または二次クラスタノードにデータサービスをフェイルオーバーするなどが含まれます。検証機能は、そのデータサービスアプリケーションリソースの Retry_count および Retry_interval リソースプロパティで設定されている値を調べ、データサービスを再起動するか、フェイルオーバーするかを決定します。

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

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

制御ソケット上でメッセージが何も受信されていない場合は、Thorough_probe_interval で指定した休止時間の後で、検証機能がデータサービスの状態を検査します。検証機能は以下のことを行います。

1. 休止します (Thorough_probe_interval)。

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

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

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

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

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

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 に戻ります。