WebSphere Extended Deployment, Version 6.0.x     Operating Systems: AIX, HP-UX, Linux, Solaris, Windows, z/OS

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

このトピックでは、 ヘルス管理が機能しないか、または予期したとおりに機能しない場合に 確認するいくつかの問題について説明します。

権限ログの検索

ヘルス管理コントローラーは、 非デプロイメント・マネージャー・ノードのノード・エージェントの 一部として実行されます。 管理コンソールのランタイム・トポロジー機能を使用して、 アクティブなヘルス・コントローラー・インスタンスを探し出すことができます。 「Runtime Operations」>「Runtime Topology」をクリックし、 「Runtime Topology」パネルの赤十字アイコンを探し出します。 ノード・グループが構成されている場合は、 それらと、第 2 メニューからの未割り当てのノードを選択します。 ヘルス管理のログ・メッセージは、 赤十字アイコンがあるノードのノード・エージェント・ログに表示されます。

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

以下のリストには、 ヘルス・コントローラーの設定値の結果として発生する問題が含まれています。
ヘルス管理コントローラーが使用不可です。
動作ポリシー」>「Autonomic controllers」>「Health controller」をクリックして管理コンソールの設定を確認し、「構成」タブと「ランタイム」タブの 両方を選択します。 ヘルス管理コントローラーは、デフォルトでは有効です。
「Runtime Topology」パネルにヘルス・コントローラー・アイコンがありません。
wsadmin checkHmmLocation.jacl スクリプトの実行によって、 ヘルス管理コントローラーが稼働しているかどうかを判別します。 このスクリプトは、非デプロイメント・マネージャー・ノードの install_root/bin ディレクトリーにあります。 このスクリプトは、コントローラーが稼働していれば、その現在の位置を表示します。 詳しくは、 スクリプトによるヘルス管理コントローラーの位置決めを 参照してください。 また、ランタイム・トポロジー・ページの「Force Data Update」 オプションを試みて、ヘルス・コントローラー・アイコンを表示させてみてください。
現時点での再始動は禁止されています。
動作ポリシー」>「Autonomic controllers」>「Health controller」を クリックし、「Prohibited restart」フィールドを選択することによって、 管理コンソールの禁止された再始動時期を確認します。 デフォルトでは、禁止されている時期はありません。
前回の再始動後の再始動が早すぎます。
動作ポリシー」>「Autonomic controllers」>「Health controller」を クリックし、「Minimum Restart Interval」フィールドを 選択することによって、管理コンソールの最小再始動間隔を確認します。 デフォルトでは、定義された最小間隔はありません。
制御サイクルが長すぎます。
動作ポリシー」>「Autonomic controllers」>「Health controller」を 選択して管理コンソールの「Control cycle length」設定を確認し、 必要に応じて調整します。 ヘルス・コントローラーはポリシー違反を定期的に検査します。 その制御サイクルが長すぎる場合は、サーバーの再始動が遅れる可能性があります。
サーバーの再始動が X 回連続して行われており、 ヘルス状態が継続して違反しています。
この場合、X は、 ヘルス・コントローラーの最大連続再始動のパラメーターを示しています。 ヘルス管理コントローラーは、再始動で問題が解決せず、 サーバーの再始動を使用不可にしていると判断します。 次のメッセージがログに表示されます。

WXDH0011W: Server servername  exceeded max verification failures: disabling restarts.

ヘルス管理コントローラーは、サーバーのモニターを継続し、 ヘルス・ポリシーに違反している場合は、ログに次のメッセージを表示します。

WXDH0012W: Server servername with restarts disabled failed health check.

以下のアクションのいずれかを実行することにより、 サーバーの再始動を使用可能にできます。
  • ヘルス管理コントローラーを使用不可にした後、使用可能にします。
  • Maximum Consecutive Restarts」のコントローラー設定値を調整します。
  • プロンプトから次のコマンドを実行します。

    wsadmin -profile HmmControllerProcs.jacl enableServer servername

    このスクリプトは、非デプロイメント・マネージャー・ノードの <install_root>¥bin ディレクトリーに用意されています。 このスクリプトには実行中のデプロイメント・マネージャーが必要です。

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

ヘルス・ポリシーの設定値の結果として、以下の問題が発生します。
サーバーがヘルス・ポリシーの一部ではありません。
管理コンソールで、ヘルス・ポリシー・メンバーシップがサーバーに適用されているか、「動作ポリシー」>「ヘルス・ポリシー」を クリックして確認します。
サーバーを含むポリシーのリアクション・モードが監視されています。
Runtime Operations」>「Task Management」>「Runtime tasks」を クリックして管理コンソールを調べ、 監視モードのポリシーに対する再始動アクションの 承認要求を見つけます。リアクション・モードとして「自動」を設定すると、 サーバーは自動的に再始動します。次のメッセージが、 監視状態のログに書き込まれます。


WXDH0024I: Server server name has violated the health policy health condition, reaction mode is supervised.

サーバーが静的クラスターのメンバーで、実行中の唯一のクラスター・メンバーです。
ヘルス・ポリシーはクラスターのすべてのメンバーを同時に停止しません。 あるクラスターに 1 つのクラスター・メンバーが存在するか、または 1 つのクラスター・メンバーが実行中の場合は、そのクラスターは再始動しません。
サーバーが動的クラスターのメンバーで、実行中のインスタンスの数が最小値を超えずに、 配置コントローラーが使用不可の状態になっています。
管理コンソールで「サーバー」>「動的クラスター」をクリックして、動的クラスターの必要な最小インスタンス数を確認します。 この場合、ヘルス管理は、最小インスタンス数パラメーターを使用して、 動的クラスターを静的クラスターのように扱います。
ヘルス管理コントローラーがポリシーを受け取っていません。
ヘルス管理コントローラーは、 ヘルス・ポリシーが作成されるデプロイメント・マネージャー上で実行されません。 ヘルス管理コントローラーが始動した後にデプロイメント・マネージャーが再始動されると、ヘルス管理コントローラーは新規ポリシーを持っていない場合があります。
この問題は、以下を実行して緩和します。
  1. 管理コンソールの「 Enable Health Monitoring」チェック・ボックスを 使用して、ヘルス管理コントローラーを使用不可にします。
  2. 構成リポジトリーをバックエンド・ノードと同期させます。 管理コンソールで、「システム管理」>「ノード」をクリックして、 同期化するノードを選択し、「同期化」をクリックします。
  3. 管理コンソールの「Enable Health Monitoring」チェック・ボックスを 使用して、ヘルス管理コントローラーを再始動します。
  4. 構成リポジトリーをバックエンド・ノードと再度同期させます。

配置コントローラーの対話

以下のリストには、 ヘルス管理と配置コントローラーの対話の結果として発生する 問題が含まれています。
サーバーは動的クラスターのメンバーですが、 配置コントローラーにコンタクトできません。
動的クラスター・メンバーの場合、サーバーが再始動できるかどうかを 判定するために、ヘルス・モニターを行って配置コントローラーを確認します。 配置コントローラーが使用可能ではあるが、コンタクトできない場合は、 次のメッセージがログに表示されます。

WXDH1018E: Could not contact the placement controller: {0}

配置コントローラーが稼働していることを確認します。 配置コントローラーは、「Runtime Topology」パネルに表示される ノードの 1 つで見つけるか、または checkPlacementLocation.jacl スクリプトを使用して見つけることが出来ます。
サーバーが動的クラスターのメンバーで、配置コントローラーが稼働しており、 配置コントローラーがヘルス管理にサーバーを再始動させないように指示します。
配置コントローラーは、継続的に稼働するサーバー・インスタンスを必要とする場合があります。
サーバーが停止しますが、始動しません。
動的クラスターでは、次のいくつかの形式の 1 つを使用して再始動させることができます。
  • 同じ場所で再始動します (サーバーの停止、サーバーの始動)。
  • 別のノードでサーバー・インスタンスを開始し、 障害のあるものを停止します。
  • 障害のあるサーバーのみを停止します。ただし、残りのアプリケーション・ インスタンスがデマンドを満たすことが前提です。
配置コントローラーは、再始動の形式、および (必要に応じて) 新規インスタンスを開始する場所を決定します。 動的クラスターで再始動が実行された後、ヘルス管理は配置コントローラーに その配置を再計算するように要求を出します。

ノード・グループ・メンバーシップの設定値

以下のリストには、 ヘルス管理とノード・グループ・メンバーシップの設定値の結果として発生する 問題が含まれています。
サーバーが保守モードのノード上にあります。
ヘルス管理は、保守モードのノード上にあるサーバーを再始動しません。 「システム管理」>「ノード」>「ノードの 選択」>「Unset maintenance」をクリックして、保守モードを解除することができます。

センサー問題

以下のリストには、 ヘルス管理とノード・グループ・メンバーシップの設定値の結果として発生する 問題が含まれています。
センサー・データがサーバーから受信されていません。
ヘルス管理は、 ポリシーが必要とするセンサーからのデータを受信していない場合は、 ポリシー違反を検出することができません。 制御サイクル時にセンサー・データが受信されない場合、 ヘルス管理は次のログ・メッセージを出力します。

WXDH3001E: No sensor data received during control cycle from server servername for health class healthpolicy.

応答時間状態の場合、 ヘルス管理はオンデマンド・ルーター (ODR) からデータを受信します。 要求が ODR を介して送信されるまでは、これらの状態のデータは生成されません。



Related tasks
ヘルス管理の定義

Reference topic    

Terms of Use | Feedback Last updated: Mar 20, 2006 12:30:55 PM EST
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=?topic=/com.ibm.websphere.xd.doc/info/odoe_task/rodhealthfail.html

© Copyright IBM 2005, 2006. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)