Sun Cluster データサービスフォルトモニター

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

フォルトモニターの呼び出し

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

フォルトモニターは、次の 2 つの機能を実行します。

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

• データサービスの健全性の検査

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

プロセスモニタファシリティ(PMF) は、データサービスプロセスを監視します。

データサービスの障害検証は、無限ループで実行され、 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 に戻ります。