Go to main content

Oracle® Solaris Cluster 4.4 データサービスの計画と管理

印刷ビューの終了

更新: 2018 年 8 月
 
 

Oracle Solaris Cluster データサービスの障害モニターの調整

Oracle Solaris Cluster 製品に付属する各データサービスには障害モニターが組み込まれています。障害モニターは、次の機能を実行します。

  • データサービスサーバーのプロセスの予期しない終了を検出する

  • データサービスの健全性をチェックする

障害モニターは、データサービスが記述された対象のアプリケーションを表すリソースに含まれています。このリソースは、データサービスを登録および構成するときに作成します。詳細は、データサービスに関するドキュメントを参照してください。

このリソースの標準プロパティーと拡張プロパティーによって、障害モニターの動作が制御されます。これらのプロパティーのデフォルト値によって、障害モニターの事前設定された動作が決定されます。事前設定された動作は、ほとんどの Oracle Solaris Cluster のインストールに適しているはずです。したがって、障害モニターの調整は、この事前設定された動作を変更する必要がある場合のみにしてください。

障害モニターを調整するには、次のタスクを実行します。

これらのタスクは、データサービスを登録および構成するときに実行します。詳細は、データサービスに関するドキュメントを参照してください。


注 -  リソースの障害モニターは、そのリソースを含むリソースグループをオンラインにしたときに起動されます。障害モニターを明示的に起動する必要はありません。

障害モニターの検証間隔を設定する

リソースが正しく動作しているかどうかを確認するために、障害モニターは、このリソースを定期的に検証します。障害モニターの検証間隔は、リソースの可用性やシステムのパフォーマンスに次のような影響を与えます。

  • 障害モニターの検証間隔は、障害を検出したり、障害に対応したりするために必要な時間の長さに影響を与えます。そのため、障害モニターの検証間隔を短くすると、障害を検出したり、障害に対応したりするために必要な時間も短くなります。この短縮によって、リソースの可用性が向上します。

  • 障害モニターの各検証によって、プロセッササイクルやメモリーなどのシステムリソースが消費されます。そのため、障害モニターの検証間隔を短くすると、システムのパフォーマンスが低下します。

障害モニターの最適な検証間隔はまた、リソース内の障害に対応するために必要な時間によっても異なります。この時間は、リソースの複雑さが、そのリソースの再起動などの操作に必要な時間にどのような影響を与えるかによって異なります。

障害モニターの検証間隔を設定するには、リソースの Thorough_probe_interval 標準プロパティーを必要な間隔 (秒単位) に設定します。

障害モニターの検証タイムアウトを設定する

障害モニターの検証タイムアウトは、その障害モニターが、検証に対するリソースからの応答を待機する時間の長さを指定します。障害モニターは、このタイムアウト内に応答を受信しなかった場合、そのリソースを障害があるとして処理します。リソースが障害モニターの検証に応答するために必要な時間は、その障害モニターがリソースを検証するために実行する操作によって異なります。データサービスの障害モニターがリソースを検証するために実行する操作については、そのデータサービスに関するドキュメントを参照してください。

リソースが応答するために必要な時間はまた、次に示すような、障害モニターやアプリケーションには関連のない要素によっても異なります。

  • システム構成

  • クラスタ構成

  • システム負荷

  • ネットワークトラフィックの量

障害モニターの検証タイムアウトを設定するには、リソースの Probe_timeout 拡張プロパティーを必要なタイムアウト (秒単位) に設定します。

ほとんどのリソースタイプの障害モニターの検証では、検証の実行時間がタイムアウト制限に近づいたときに通知を送信するように Timeout_threshold プロパティーを構成することもできます。そのような通知は、偽のフェイルオーバーを引き起こす可能性がある、設定が低すぎる検証タイムアウトを特定するために役立ちます。Timeout_threshold プロパティーの詳細は、r_properties(7) のマニュアルページを参照してください。

継続的な障害とみなす基準を定義する

リソース内の一時的な障害によって発生する中断を最小限に抑えるために、障害モニターは、このような障害に対応してそのリソースを再起動します。継続的な障害に対しては、リソースの再起動より根本的なアクションが必要になります。

  • フェイルオーバーリソースの場合、障害モニターは、そのリソースを別のノードにフェイルオーバーします。

  • スケーラブルリソースの場合、障害モニターは、そのリソースをオフラインにします。

リソースの完全な障害の数が、Retry_count 標準プロパティーで指定された再試行回数を超えると、障害モニターは障害を継続的として処理します。継続的な障害とみなす基準の定義により、クラスタのパフォーマンス特性や可用性の要件に対応するための再試行回数と再試行間隔を設定できるようになります。

このセクションの内容は次のとおりです。

リソースの完全な障害と部分的な障害

障害モニターは、一部の障害をリソースの完全な障害として処理します。完全な障害によって、通常、サービスは完全に失われます。完全な障害の例を次に示します。

  • データサービスサーバーのプロセスの予期しない終了

  • 障害モニターがデータサービスサーバーに接続できない

完全な障害を検出すると、障害モニターは、その再試行間隔内の完全な障害のカウントを 1 増やします。

障害モニターは、その他の障害をリソースの部分的な障害として処理します。部分的な障害は完全な障害に比べて重大性が低く、通常はサービスが低下しますが、サービスが完全に失われることはありません。部分的な障害の例として、障害モニターの検証がタイムアウトする前のデータサービスサーバーからの不完全な応答があります。

部分的な障害を検出すると、障害モニターは、その再試行間隔内の完全な障害のカウントを分数の量だけ増やします。部分的な障害は、その再試行間隔にわたって引き続き累積されます。

部分的な障害の次の特性は、データサービスによって異なります。

  • 障害モニターが部分的な障害として処理する障害のタイプ

  • 部分的な各障害によって完全な障害のカウントに追加される分数の量

データサービスの障害モニターが検出する障害については、そのデータサービスに関するドキュメントを参照してください。

再試行回数と再試行間隔のその他のプロパティーに対する依存関係

障害のあるリソースの 1 回の再起動に必要な最大時間は、次のプロパティーの値の合計値です。

  • Thorough_probe_interval システムプロパティー

  • Probe_timeout 拡張プロパティー

再試行間隔内に再試行回数に達するための十分な時間が確保されるようにするには、次の式を使用して再試行間隔の値と再試行回数値を計算します。

retry_interval >= 2 x retry_count × (thorough_probe_interval + probe_timeout)

2 の係数は、リソースのフェイルオーバーやオフライン化をただちに引き起こすわけではない部分的な検証障害を考慮しています。

再試行回数と再試行間隔を設定するための標準プロパティー

再試行回数と再試行間隔を設定するには、リソースの次の標準プロパティーを設定します。

  • 再試行回数を設定するには、Retry_count 標準プロパティーを完全な障害の許可される最大数に設定します。

  • 再試行間隔を設定するには、Retry_interval 標準プロパティーを必要な間隔 (秒単位) に設定します。

リソースのフェイルオーバー動作を指定する

リソースのフェイルオーバー動作によって、次の障害への RGM の対応方法が決定されます。

  • リソースの起動の失敗

  • リソースの停止の失敗

  • リソースの障害モニターの停止の失敗

リソースのフェイルオーバー動作を指定するには、そのリソースの Failover_mode 標準プロパティーを設定します。このプロパティーの指定可能な値については、r_properties(7) のマニュアルページにある Failover_mode 標準プロパティーの説明を参照してください。