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

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

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

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