test

Sun Cluster 3.0 データサービスのインストールと構成

第 10 章 データサービスの障害モニター

この章では、各 Sun Cluster データサービスと共に提供される障害モニターと、各モニターの動作について説明します。この章の内容は次のとおりです。

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

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

障害モニターの呼び出し

障害モニターは、リソースグループとそのリソースをオンラインにしたときに、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 に戻ります。

Sun Cluster HA for Apache の障害モニター

Sun Cluster HA for Apache の検証機能は、Apache サーバーの状態を照会する要求をサーバーに送信します。検証機能が実際に Apache サーバーを照会する前に、ネットワークリソースがこの Apache リソース用に構成されていることの確認が行われます。ネットワークリソースが構成されていない場合は、エラーメッセージ (No network resources found for resource.) が記録され、検証はエラーとなり終了します。

検証機能は、次のことを行います。

  1. Probe_timeout リソースプロパティで設定されたタイムアウト値を使用し、Apache サーバーを正常に検証するための試行時間を制限します。

  2. Apache サーバーに接続し、HTTP 要求を送信して応答を受信することで、HTTP 1.0 HEAD 検査を実行します。検証機能は、各 IP アドレスとポートの組み合わせで Apache サーバーに順番に接続します。

    この照会の結果は、異常か正常のどちらかになります。検証機能が Apache サーバーからの応答を正常に受信した場合、検証機能は無限ループに戻り、検証と休止の次のサイクルを開始します。

    照会は、ネットワークトラフィックの混雑、過剰なシステム負荷、不適切な構成など、さまざまな理由によって失敗します。不適切な構成は、検証される IP アドレスとポートのすべての組み合わせに対し、Apache サーバーが待機するように構成されていない場合に生じます。Apache サーバーは、このリソースに指定した各 IP アドレスに対し、それぞれポートを提供する必要があります。Probe_timeout で指定した制限内 (前の手順 1 で指定) に照会に対する応答を受信しない場合は、検証機能は、Apache データサービスの一部で異常が発生したと判断し、履歴に異常を記録します。Apache の検証異常は、致命的な異常、または一部の異常になります。

    致命的な異常とみなされる検証異常は、以下のとおりです。

    • サーバーへの接続に失敗した場合。Failed to connect to %s port %d というエラーメッセージによってフラグが付きます。ここで、%s は、ホスト名を示し、%d はポート番号を示します。

    • サーバーに接続しようとしてタイムアウト (Probe_timeout リソースプロパティのタイムアウト値を超過) した場合。

    • 検証文字列のサーバーへの送信に失敗した場合。Failed to communicate with server %s port %d: %s というエラーメッセージによってフラグが付きます。ここで、最初の %s は、ホスト名を示し、%d はポート番号を示し、2 番目の %s は、エラーの詳細を示します。

      モニターは、Retry_interval リソースプロパティで指定した期間内で、以下に示す 2 つの一部の異常を累積し、1 つの致命的な異常としてカウントします。部分的に異常とみなされる検証の障害は次のとおりです。

      • 検証機能による照会に対し、サーバーからの応答を読み取ろうとしてタイムアウト (Probe_timeout リソースプロパティのタイムアウト値を超過) した場合。

      • 他の理由により、サーバーからのデータの読み取りに失敗した場合。Failed to communicate with server %s port %d: %s というエラーメッセージによってフラグが付きます。ここで、最初の %s は、ホスト名を示し、%d はポート番号を示し、2 番目の %s は、エラーの詳細を示します。

  3. 異常履歴に基づいて、データサービスのローカルでの再起動、またはデータサービスのフェイルオーバーのいずれかを実行します。詳細は、「データサービスの状態の検査」を参照してください。

Sun Cluster HA for DNS の障害モニター

検証機能は、nslookup コマンドを使用して DNS の状態を照会します。検証機能が実際に DNS サーバーを照会する前に、ネットワークリソースが DNS データサービスと同じリソースグループ内で構成されていることの確認が行われます。ネットワークリソースが構成されていない場合は、エラーメッセージが記録され、検証はエラーとなり終了します。検証機能は、次のことを行います。

  1. Probe_timeout リソースプロパティで指定されたタイムアウト値を使用し、nslookup コマンドを実行します。

    この nslookup コマンドの実行結果は、異常か正常のどちらかになります。nslookup の照会に対して DNS が正常に応答した場合は、検証機能は無限ループに戻り、次の検証時間まで待機します。

    nslookup コマンドが正常に終了しなかった場合、検証機能は DNS データサービスで異常が発生したと判断し、履歴に異常を記録します。DNS 検証機能は、すべての異常を致命的な異常とみなします。

  2. 正常/異常履歴に基づいて、ローカルでの再起動、またはデータサービスのフェイルオーバーを実行します。詳細は、「データサービスの状態の検査」を参照してください。

Sun Cluster HA for NFS の障害モニター

Sun Cluster HA for NFS の障害モニターは、2 つの部分から成ります。1 つは、NFS システム障害モニターです。NFS デーモン (nfsd、mountd、statd、mountd) の監視と、問題が発生した場合の適切な処理を行います。もう 1 つは、各 NFS リソースに特有の機能です。各リソースの障害モニターは、リソースによってエクスポートされるファイルシステムを、各共有パスの状態を調べることで監視します。

障害モニターの起動

NFS システム障害モニターは、NFS リソースの起動メソッドによって起動されます。この起動メソッドは、最初に NFS システム障害モニター (nfs_daemons_probe) がプロセスモニター pmfadm 下ですでに実行されているかどうかを調べます。実行されていない場合は、起動メソッドは、プロセスモニターの制御下で nfs_daemons_probe プロセスを起動します。その後、同様に、プロセスモニターの制御下でリソース障害モニター (nfs_probe) を起動します。

障害モニターの停止

NFS リソースの Monitor_stop メソッドは、リソース障害モニターを停止します。また、ローカルノード上で他に NFS リソース障害モニターが実行されていない場合は、NFS システム障害モニターも停止します。

NFS システム障害モニタープロセス

システム障害モニターは、プロセスの存在および NULL rpc 呼び出しへの応答を調べることで、rpcbind、statd、lockd、nfsd、mountd を検証します。このモニターは、次の NFS 拡張プロパティを使用します。

Rpcbind_nullrpc_timeoutLockd_nullrpc_timeout
Nfsd_nullrpc_timeoutRpcbind_nullrpc_reboot
Mountd_nullrpc_timeoutNfsd_nullrpc_restart

Statd_nullrpc_timeout

Mountd_nullrpc_restart

これらのプロパティについては、第 7 章「Sun Cluster HA for Network File System (NFS) のインストールと構成」を参照してください。

各システム障害モニターの検証サイクルにおいて、次のことを行います。

  1. Cheap_probe_interval の間、休止します。

  2. rpcbind を検証します。

    プロセスが停止しており、Failover_mode=HARD の場合は、システムを再起動します。

    NULL rpc 呼び出しに失敗し、Rpcbind_nullrpc_reboot=True および Failover_mode=HARD の場合は、システムを再起動します。

  3. statd と lockd を検証します。

    いずれかのデーモンが停止している場合は、両方のデーモンを再起動します。

    NULL rpc 呼び出しに失敗した場合は、メッセージが syslog に記録されますが、再起動はしません。

  4. mountd と mountd を検証します。

    プロセスが停止している場合は、そのプロセスを再起動します。

    NULL rpc 呼び出しに失敗し、PXFS デバイスが利用可能で拡張プロパティ Mountd_nullrpc_restart=True の場合は、mountd を再起動します。

NFS デーモンのうち、いずれかのデーモンの再起動に失敗すると、すべてのオンライン NFS リソースの状態が FAULTED に設定されます。すべての NFS デーモンが再起動され、状態が正常の場合には、リソースの状態は再び ONLINE に設定されます。

NFS リソースモニタープロセス

リソースモニター検証を開始する前に、すべての共有パスが dfstab ファイルから読み取られ、メモリーに格納されます。各検証サイクルでは、パスの stat() を実行することで、各繰り返しですべての共有パスが検証されます。

各リソースモニターの障害検証において、次のことを行います。

  1. Thorough_probe_interval の間、休止します。

  2. 最後の読み取り以降に dfstab が変更されている場合は、メモリーをリフレッシュします。

  3. パスの stat() を実行することで、すべての共有パスを各繰り返しで検証します。

問題のあるパスが見つかると、リソースの状態は FAULTED に設定されます。すべてのパスが正常に動作すると、リソースの状態は再び ONLINE になります。

Sun Cluster HA for Oracle の障害モニター

Sun Cluster HA for Oracle には、サーバーモニターとリスナーモニターの 2 つの障害モニターがあります。

Oracle サーバーの障害モニター

Oracle サーバーの障害モニターは、サーバーの状態を照会する要求をサーバーに送信します。

サーバーの障害モニターは、障害モニターの主プロセスとデータベースクライアント障害検証の、2 つのプロセスから成ります。主プロセスは、エラー検索と scha_control アクションを実行します。データベースクライアント障害検証は、データベーストランザクションを実行します。

検証機能からデータベースへのすべての接続は、ユーザー Oracle で実行されます。障害モニターの主プロセスは、データベースがオンラインで、トランザクション中にエラーが返されていない場合に、操作が正常に終了したと判断します。

データベースのトランザクションに失敗した場合、主プロセスは、実行するアクションについて内部アクションテーブルを調べ、あらかじめ定義されているアクションを実行します。そのアクションが外部プログラムを実行する場合は、そのプログラムは別プロセスとしてバックグラウンドで処理されます。このとき実行されるアクションには、スイッチオーバー、サーバーの停止と再起動、リソースグループの停止と再起動があります。

検証機能は、Probe_timeout リソースプロパティで設定されるタイムアウト値を使用し、Oracle を正常に検証するための試行時間を判断します。

サーバーの障害モニターは、Oracle の alert_log_file を走査し、見つけたエラーに基づいてアクションを実行します。

サーバーの障害モニターは、高可用性にするために pmfadm によって開始されます。モニターが、何らかの理由により強制終了されても、pmf によって自動的に再開します。

Oracle リスナーの障害モニター

Oracle リスナーの障害モニターは、Oracle リスナーの状態を調べます。

リスナーが実行されている場合、Oracle リスナーの障害モニターは検証に成功したと判断します。障害モニターがエラーを検知すると、リスナーが再起動されます。

リスナー検証は、高可用性にするために pmfadm によって開始されます。リスナー検証が強制終了されても、pmf によって自動的に再開します。

検証中にリスナーで問題が発生した場合、検証機能はリスナーの再起動を試みます。再起動の試行最大回数は、Retry_count リソースプロパティで設定した値で決定されます。最大回数まで再起動を試みても検証が成功しない場合は、障害モニターを停止し、リソースグループのスイッチオーバーは行いません。

Sun Cluster HA for iPlanet Web Server の障害モニター

Sun Cluster HA for iPlanet Web Server (iWS) の検証機能は、サーバーの状態を照会する要求をサーバーに送信します。検証機能が実際にサーバーを照会する前に、ネットワークリソースがこの Web サーバーリソース用に構成されていることの確認が行われます。ネットワークリソースが構成されていない場合は、エラーメッセージ (No network resources found for resource.) が記録され、検証はエラーとなり終了します。

検証機能は、セキュアインスタンスと非セキュアインスタンスの 2 つの iWS 構成を扱える必要があります。Web サーバーがセキュアモードのときに、検証機能が構成ファイルからセキュアポートを取得できない場合は、エラーメッセージ (Unable to parse configuration file.) が記録され、検証はエラーとなり終了します。セキュアインスタンスと非セキュアインスタンスの検証の処理は同じです。

検証機能は、Probe_timeout リソースプロパティで設定されたタイムアウト値を使用し、iWS を正常に検証するための試行時間を制限します。このリソースプロパティについては、付録 A 「標準プロパティ」 を参照してください。

iWS リソースで設定されている Network_resources_used リソースプロパティは、Web サーバーが使用する IP アドレスセットを決定します。Port_list リソースプロパティの設定は、iWS で使用されるポート番号のリストを決定します。障害モニターは、Web サーバーが IP アドレスとポートのすべての組み合わせに対して待機することを想定しています。ポート 80 以外の別のポート番号で待機するように Web サーバー構成をカスタマイズしている場合は、構成ファイル (magnus.conf) が IP アドレスとポートのすべての組み合わせを含んでいることを確認してください。障害モニターは、このようなすべての組み合わせを検証しようとし、IP アドレスとポートの特定の組み合わせで Web サーバーが待機していない場合には、検証に失敗します。

検証機能は、次のことを行います。

  1. 検証機能は、指定した IP アドレスとポートの組み合わせを使用し、Web サーバーに接続します。正しく接続できない場合は、検証機能は致命的な異常が発生したと判断します。その後、検証機能はこの異常を記録し、適切な処理を行います。

  2. 検証機能が正しく接続した場合は、Web サーバーがセキュアモードで実行されているかどうかを調べます。セキュアモードで実行されている場合は、検証機能は Web サーバーとの接続を解除し、サーバーの状態が正常であると判断します。セキュア iWS サーバーに対しては、これ以上の検査は行われません。

    ただし、Web サーバーが非セキュアモードで実行されている場合は、検証機能は HTTP 1.0 HEAD 要求を Web サーバーに送信し、応答を待ちます。ネットワークトラフィックスの混雑、過剰なシステム負荷、不適切な構成など、さまざまな理由によって要求が正しく処理できないことがあります。

    不適切な構成は、検証される IP アドレスとポートのすべての組み合わせに対し、Web サーバーが待機するように構成されていない場合に生じます。Web サーバーは、このリソースに指定した各 IP アドレスに対し、それぞれポートを提供する必要があります。

    また、リソースの作成時に、Network_resources_used および Port_list リソースプロパティを正しく設定しないと、不適切な構成が生じます。

    Probe_timeout リソースプロパティの制限内に、照会に対する応答を受信しない場合は、検証機能は Sun Cluster HA for iPlanet Web Server で異常が発生したと判断します。この異常は、検証の履歴に記録されます。

    検証異常は、致命的な異常または一部の異常になります。致命的な異常とみなされる検証異常は、以下のとおりです。

    • サーバーへの接続に失敗した場合。Failed to connect to %s port %d というエラーメッセージによってフラグが付きます。ここで、%s は、ホスト名を示し、%d はポート番号を示します。

    • サーバーに接続しようとしてタイムアウト (Probe_timeout リソースプロパティのタイムアウト値を超過) した場合。

    • 検証文字列のサーバーへの送信に失敗した場合。Failed to communicate with server %s port %d: %s というエラーメッセージによってフラグが付きます。ここで、最初の %s は、ホスト名を示し、%d はポート番号を示し、2 番目の %s は、エラーの詳細を示します。

    モニターは、Retry_interval リソースプロパティで指定した期間内で、以下に示す 2 つの一部の異常を累積し、1 つの致命的な異常としてカウントします。部分的に異常とみなされる検証の障害は次のとおりです。

    • 検証機能による照会に対し、サーバーからの応答を読み取ろうとしてタイムアウト (Probe_timeout リソースプロパティのタイムアウト値を超過) した場合。

    • 他の理由により、サーバーからのデータの読み取りに失敗した場合。Failed to communicate with server %s port %d: %s というエラーメッセージによってフラグが付きます。ここで、最初の %s は、ホスト名を示し、%d はポート番号を示し、2 番目の %s は、エラーの詳細を示します。

  3. 異常履歴に基づいて、データサービスのローカルでの再起動、またはデータサービスのフェイルオーバーのいずれかを実行します。詳細は、「データサービスの状態の検査」を参照してください。

Sun Cluster HA for Netscape Directory Server の障害モニター

Sun Cluster HA for Netscape Directory Server の検証機能は、特定の IP アドレスとポート番号にアクセスします。IP アドレスは、Network_resources_used リソースプロパティにリストされているネットワークリソースから取得します。ポートは、Port_list リソースプロパティにリストされているポートです。これらのプロパティについては、付録 A 「標準プロパティ」 を参照してください。

障害モニターは、Sun Cluster HA for Netscape Directory Server インスタンスがセキュアか非セキュアかを判断します。セキュアディレクトリサーバーと非セキュアディレクトリサーバーでは、検証方法が異なります。キーワード security が構成ファイル (slapd.conf) にない場合、または security off に設定されている場合は、そのインスタンスは非セキュアと判断されます。これ以外の場合は、セキュアであると判断されます。

セキュアインスタンスの検証は、単純な TCP 接続で行われます。正しく接続されると、検証も正常と判断されます。接続の失敗またはタイムアウトは、致命的な異常と判断されます。

非セキュアインスタンスの検証は、Sun Cluster HA for Netscape Directory Server で提供される ldapsearch 実行可能ファイルの実行に依存します。使用される検索フィルタは、常に何かを見つけるように設計されています。検証機能は、一部の異常と致命的な異常を検知します。以下の状況は、一部の異常と判断されます。これ以外の状況は、致命的な異常と判断されます。