[AIX Solaris HP-UX Linux Windows][z/OS]

Intelligent Management: ヘルス管理のトラブルシューティング

ヘルス管理が機能しない場合、またはその動作が期待通りでない場合は、以下の問題を調べることができます。

正しいログの検索

ヘルス・コントローラーは、HA マネージャーによって管理される分散リソースです。HA マネージャーはすべてのノード・エージェント・プロセスおよびデプロイメント・マネージャー・プロセス内に存在しており、 これらのプロセスの 1 つでアクティブになっています。プロセスが失敗した場合、ヘルス・コントローラーは別のノード・エージェントまたはデプロイメント・マネージャーのプロセスでアクティブになります。

ヘルス・コントローラーが実行されている場所を判別するには、管理コンソールで「ランタイム操作」 > 「コンポーネントの安定度 (Component stability)」 > 「コア・コンポーネント」をクリックします。ヘルス・コントローラーのロケーションと安定度状況が表示されます。

パフォーマンス・アドバイザーが定義済みのメモリー・リーク・ヘルス・ポリシーで有効にされる

定義済みのメモリー・リーク・ヘルス・ポリシーではパフォーマンス・アドバイザーの機能が使用されるので、このポリシーがメンバーを割り当てるときに、パフォーマンス・アドバイザーが使用可能になります。パフォーマンス・アドバイザーを使用不可にするには、このヘルス・ポリシーを除去するか、このヘルス・ポリシーのメンバーシップを限定します。将来の使用 のためにこのヘルス・ポリシーを保持するには、メモリー・リーク・ポリシーは保持し、すべての メンバーを削除してください。メンバーを変更するには、「動作ポリシー」 > 「ヘルス・ポリシー」 > 「memory_leak_policy」とクリックします。特定のメンバーを追加および除去することで、ヘルス・ポリシーのメンバーシップを編集できます。

ヘルス・コントローラーの設定値

以下のリストには、 ヘルス・コントローラーの設定値の結果として発生する問題が含まれています。
ヘルス・コントローラーが使用不可です。
管理コンソールで設定を検証するには、「動作ポリシー」 > 「オートノミック・マネージャー」 > 「ヘルス・コントローラー」とクリックし、 「構成」タブと「ランタイム」タブの両方を選択します。 ヘルス・コントローラーは、デフォルトでは有効です。
現時点での再始動は禁止されています。
管理コンソールで、禁止された再始動時間を検証するには、 「動作ポリシー」 > 「オートノミック・マネージャー」 > 「ヘルス・コントローラー」とクリックし、「禁止された再始動」フィールドを選択します。 デフォルトでは、禁止された時間値はありません。
前回の再始動後の再始動が早すぎます。
管理コンソールの最小再始動間隔を確認するには、「動作ポリシー」 > 「オートノミック・マネージャー」 > 「ヘルス・コントローラー」をクリックし、「Minimum restart interval」フィールドを変更します。デフォルトでは、定義された最小間隔はありません。
制御サイクルが長過ぎます。
管理コンソールの制御サイクルの長さを確認するには、「動作ポリシー」 > 「オートノミック・マネージャー」 > 「ヘルス・コントローラー」をクリックし、必要に応じてその値を調整します。ヘルス・コントローラーはポリシー違反を定期的に検査します。 その制御サイクルが長過ぎる場合は、サーバーの再始動が遅れる可能性があります。
サーバーの再始動が X 回連続して行われており、ヘルス状態が継続して違反しています。
この場合、X は、 ヘルス・コントローラーの最大連続再始動のパラメーターを示しています。 ヘルス・コントローラーは、再始動では問題が解決しないと判断し、サーバーの再始動を無効にします。 次のメッセージがログに表示されます。
WXDH0011W: Server servername  exceeded maximum verification failures: disabling restarts.
ヘルス・コントローラーは、サーバーのモニターを継続し、ヘルス・ポリシーに違反している場合は、ログに次のメッセージを表示します。
WXDH0012W: Server servername with restarts disabled failed health check.
以下のアクションのいずれかを実行することにより、 サーバーの再始動を使用可能にできます。
  • ヘルス・コントローラーを無効にしてから有効にします。
  • 「Maximum Consecutive Restarts」のコントローラー設定値を調整します。
  • プロンプトから次のコマンドを実行します。
    wsadmin -profile HmmControllerProcs.jacl enableServer servername
    このスクリプトは、ノード・エージェントまたはデプロイメント・マネージャーのノードの <app_server_root>¥bin ディレクトリーに用意されています。このスクリプトには実行中のデプロイメント・マネージャーが必要です。

ヘルス・ポリシーの設定値

ヘルス・ポリシーの設定値の結果として、以下の問題が発生します。
サーバーがヘルス・ポリシーの一部ではありません。
管理コンソールで、ヘルス・ポリシー・メンバーシップがサーバーに適用されることを検証するには、 「動作ポリシー」 > 「ヘルス・ポリシー」をクリックします。
サーバーを含むポリシーのリアクション・モードは監視モードです。
管理コンソールをチェックするため、「システム管理」 > 「タスク管理」 > 「ランタイム・タスク」とクリックします。「監視」モード のポリシーに対する再始動アクションの承認要求を見つけます。 リアクション・モードを「自動」に設定すると、サーバーは自動的に再始動します。次のメッセージが、 監視状態のログに書き込まれます。
WXDH0024I: Server server name has violated the health policy health condition, 
reaction mode is supervised.
サーバーが静的クラスターのメンバーで、実行中の唯一のクラスター・メンバーです。
ヘルス・ポリシーはクラスターのすべてのメンバーを同時に停止しません。 あるクラスターに 1 つのクラスター・メンバーが存在するか、または 1 つのクラスター・メンバーが実行中の場合は、そのクラスターは再始動しません。
サーバーは動的クラスターのメンバーです。実行中のインスタンスの数が最小値を超えずに、 配置コントローラーが使用不可の状態になっています。
動的クラスターの「必要な最小インスタンス数」をチェック するため、管理コンソールで「サーバー」 > 「クラスター」 > 「動的クラスター」とクリックします。この場合、ヘルス管理は、最小インスタンス数パラメーターを使用して、 動的クラスターを静的クラスターのように扱います。
ヘルス・コントローラーがポリシーを受け取っていません。
ヘルス・コントローラーは、ヘルス・ポリシーが作成されるデプロイメント・マネージャー上では実行されません。 ヘルス・コントローラーが始動した後にデプロイメント・マネージャーが再始動されると、ヘルス・コントローラーは新規ポリシーを持たないことがあります。
この問題を解決するには、以下の手順を実行します。
  1. ヘルス・コントローラーを無効にします。管理コンソールで、「動作ポリシー」 > 「オートノミック・マネージャー」 > 「ヘルス・コントローラー」とクリックします。
  2. 構成リポジトリーをバックエンド・ノードと同期させます。管理コンソールで、「システム管理」 > 「ノード」とクリックします。同期化するノードを選択し、「同期化」をクリックします。
  3. ヘルス・コントローラーを再始動します。管理コンソールで、「動作ポリシー」 > 「オートノミック・マネージャー」 > 「ヘルス・コントローラー」とクリックします。
  4. 構成リポジトリーをバックエンド・ノードと同期させます。管理コンソールで、「システム管理」 > 「ノード」とクリックします。同期化するノードを選択し、「同期化」をクリックします。

アプリケーション配置コントローラーの対話

以下のリストに、 ヘルス管理とアプリケーション配置コントローラーの対話からトリガーされる問題 を示します。

サーバーは動的クラスターのメンバーですが、 配置コントローラーにコンタクトできません。
動的クラスター・メンバーの場合、サーバーが再始動できるかどうかを 判定するために、ヘルス・モニターを行ってアプリケーション配置コントローラーを確認します。アプリケーション配置コントローラーが使用可能ではあるが、コンタクトできない場合は、 次のメッセージがログに表示されます。
WXDH1018E: Could not contact the placement controller
配置コントローラーが稼働していることを確認します。 ヘルス・コントローラーが実行されている場所を判別するには、管理コンソールで「ランタイム操作」 > 「コンポーネントの安定度 (Component stability)」 > 「コア・コンポーネント」をクリックします。ヘルス・コントローラーのロケーションと安定度状況が表示されます。ヘルス・コントローラーは、現在のロケーションで示される特定のノード・エージェントまたはデプロイメント・マネージャーへのメッセージをログに記録します。
サーバーが停止しますが、始動しません。
動的クラスターでは、次のいくつかの形式の 1 つを使用して再始動させることができます。
  • 同じ場所で再始動します (サーバーの停止、サーバーの始動)。
    注: 動的クラスターが手動モードの場合、 必ず発生します。
  • 別のノードでサーバー・インスタンスを開始し、 障害のあるものを停止します。
  • 障害のあるサーバーのみを停止します。ただし、残りのアプリケーション・ インスタンスがデマンドを満たすことが前提です。

センサー問題

以下のリストに、 ヘルス管理とノード・グループ・メンバーシップ設定に関連する問題を示します。

センサー・データがサーバーから受信されていません。
ヘルス管理は、 ポリシーが必要とするセンサーからのデータを受信していない場合は、 ポリシー違反を検出することができません。 制御サイクル時にセンサー・データが受信されない場合、 ヘルス管理は次のログ・メッセージを出力します。
WXDH3001E: No sensor data received during control cycle from server server_name for 
health class healthpolicy.
応答時間状態の場合、 ヘルス管理はオンデマンド・ルーター (ODR) からデータを受信します。 要求が ODR を介して送信されるまでは、これらの状態のデータは生成されません。

タスク管理状況

「再始動アクション (Restart action)」「失敗」または「不明」状態で終了します。 このシナリオは、サーバーがデフォルトで割り振られる期間に停止しないか、またはタスクがタイムアウトになる場合に起こります。セル・レベルのプロパティー HMM.StopServerTimeout を使用し、環境に合わせてタイムアウトを調整します。 値はミリ秒単位で指定され、デフォルト値は 10000 です。 このプロパティーによって、ヘルス管理でオンデマンド構成から受信されるサーバー停止通知の待機時間の延長が可能になります。

使用している環境でタイムアウトを増やすには、「動作ポリシー」 > 「オートノミック・マネージャー」 > 「ヘルス・コントローラー」 > 「再始動タイムアウト」に移動します。デフォルト値は 5 分です。再始動タスクは、指定された 2 倍の時間待機してから開始し、サーバーが停止して開始できるようにします。


トピックのタイプを示すアイコン 参照トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rwve_odhealthfail
ファイル名:rwve_odhealthfail.html