ワークロード管理コンポーネントのトラブルシューティングのヒント
ワークロード管理コンポーネントによって、マルチノード構成されたサーバー間でワークロードが正しく分散されない場合は、以下のオプションを使用して問題を取り除いてください。
- ワークロードがクラスター・サーバーに分散されていることを確認します。
- マルチサーバー・デプロイメント・マネージャー環境のセットアップに関するすべての問題を解決します。
- 環境または構成の問題の除去
ログ・ファイルでの WLM エラーおよび CORBA マイナー・コードの参照
PMI データの分析
- 問題の解決または IBM サポートへの連絡
環境または構成の問題の除去
- クラスターのメンバーまたは管理サーバー (例えば、デプロイメント・マネージャーまたはノード・エージェント) にネットワーク接続に関する問題がありますか?
- 問題がある場合は、マシンに ping して、それらのマシンが正しくネットワークに接続されているかを確認してください。
- サーバーがインストールされているマシンで、
サーバーが要求を処理する能力に影響を及ぼすような、別のアクティビティーが実行されていますか?
例えば、タスク・マネージャー、プロセッサー ID、またはその他の外部ツールで計測される
プロセッサー使用状況をチェックして、以下について確認してください。
- プロセッサー使用状況が予想どおりではない、あるいは不規則で安定していない。
- 新規に追加、インストール、またはアップグレードされたクラスターのメンバーが使用されていないことを示している。
- 各ノードで始動したすべてのアプリケーション・サーバーが実行されているか、あるいは一部が停止していますか。
- アプリケーションがインストールされ、作動していますか。
- コンテナー管理パーシスタンス (CMP) または Bean 管理パーシスタンス (BMP) エンタープライズ Bean 間でのワークロードの分散に関する問題の場合、サポートする JDBC プロバイダーおよび JDBC データ・ソースを 各サーバー上で構成済みですか。
HTTP 要求に関連したワークロード管理問題が発生した場合 (HTTP 要求の処理が、クラスターの一部のメンバーでしか実行されないなど)、アフィニティーが確立されていなければ、HTTP プラグインによって、PrimaryServers リストに定義されているすべてのサーバーでロード・バランスが行われることに注意してください。 PrimaryServers リストを定義していない場合は、アフィニティーが確立されていなければ、プラグインによって、クラスターで定義されているすべてのサーバーに渡って、ロード・バランシングが行われます。 アフィニティーが確立されている場合、プラグインはすべての要求に対処するために直接そのサーバーに移動します。
- ウェイトが許容値に設定されているかを確かめます。
- 問題が発生しているクラスターについて、管理コンソールにログオンして、以下のことを行う。
- を選択する。
- リストからクラスターを選択する。
- 「クラスター・メンバー」を選択する。
- クラスター内のサーバーごとに server_name をクリックして、サーバーに割り当てられたウェイトに注目する。
- ウェイトの有効範囲が 0 から 20 までであることを確認してください。 サーバーのウェイトが 0 である場合、要求はそのサーバーにはルーティングされません。 20 より大きいウェイトは 0 として処理されます。
- 問題が発生しているクラスターについて、管理コンソールにログオンして、以下のことを行う。
これ以降は エンタープライズ Bean ワークロード・バランシングについてのみ説明します。 Web (HTTP) 要求の分散における問題の診断についての詳細は、『Web サーバー・プラグインのトラブルシューティングのヒント』および『Web リソースが表示されない』トピックを参照してください。
![[IBM i]](../images/iseries.gif)
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
ログ・ファイルでの WLM エラーおよび CORBA マイナー・コードの参照
- 複数回使用不能とマークされ、使用不能なままになっているサーバーがある。
- クラスター内のすべてのサーバーが不良とマークされ、使用不能なままになっている。
ロケーション・サービス・デーモン (LSD) が複数回使用不能とマークされ、使用不能なままになっている。
これを確認するには、Log and Trace Analyzer を使用して、影響を受けたサーバー上の保守ログ (activity.log) を開き、以下の項目を探します。
これを確認するには、影響を受けたサーバー上の保守ログを開き、以下の項目を探します。
- WWLM0061W: An error was encountered sending a request to cluster
member member and that member has been marked unusable for future requests
to the cluster cluster.注: サーバーが使用不能とマークされるのは、珍しいことではありません。 クライアントからサーバーへのロードが続いている間に、ripple 始動が実行されるなどの、 通常の操作上の理由から、サーバーに使用不能というタグが付けられる場合があります。 また、メンバーがほぼ同時に多くの WWLM0061W 警告メッセージを受け取るのもふつうのことです。通常、複数のスレッドに処理中の要求があります。そして、メンバーが使用不能とマークされた後、そのメンバーをターゲットとするスレッドはその警告メッセージを受け取る可能性が高くなります。
- WWLM0062W: An error was encountered sending a request to cluster member member that member has been marked unusable, for future requests to the cluster cluster two or more times.
- WWLM0063W: An error was encountered attempting to use the LSD LSD_name to resolve an object reference for the cluster cluster and has been marked unusable for future requests to that cluster.
- WWLM0064W: Errors have been encountered attempting to send a request to all members in the cluster cluster and all of the members have been marked unusable for future requests that cluster.
- WWLM0065W: An error was encountered attempting to update a cluster member server in cluster cluster, as it was not reachable from the デプロイメント・マネージャー.
- WWLM0067W: クライアントが、要求を再試行するように通知されています。例外 {0}
のため、サーバー要求を WLM により透過的に再試行できませんでした。
要求を処理しようと しましたが、WLM が、要求を透過的に再サブミットできないような状態を検出しました。原因となる 例外がキャッチされており、クライアントに対してマイナー・コード 0x49421042 (SERVER_SIGNAL_RETRY) の新規 CORBA.TRANSIENT がスローされています。
- 構成設定の変更などの、可能なユーザー応答。
- 本製品に障害が発生したことを示している可能性がある基本クラス例外。
WLM は CORBA (Common Object Request Broker Architecture) を使用してプロセス間の通信を行うため、 例外の名前の一部として「CORBA」と付けられている例外も表示される場合があります。 例外スタック内で、「 マイナー・コード」と明記されているステートメントを検索してください。これらのコードは、CORBA 呼び出しまたは応答が完了できなかった特定の 理由を示します。WLM マイナー・コードは、0x4921040 から 0x492104F の範囲になります。WLM に関連したマイナー・コードについては、『参照: 生成された API 資料』トピックで、パッケージおよびクラス com.ibm.websphere.wlm.WsCorbaMinorCodes の説明を参照してください。
![[IBM i]](../images/iseries.gif)
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
PMI データの分析
PMI データを分析する目的は、 クラスターの各メンバーに着信するワークロードを理解することです。 クラスターのあるメンバーのデータは、クラスターの全メンバーのデータのコンテキスト内でのみ有用です。
Tivoli® Performance Viewer を使用して、各サーバーが、クラスター・メンバーに割り当てられたウェイト (定常状態のウェイト) に基づき、正しい比率で要求を受け取っていることを検証します。
- ツリー・ビューで「データ収集」を選択します。PMI が使用可能になっていないサーバーは、ぼかし表示されます。
- データ収集をオンにしたいデータを保持する各サーバーごとに、「指定...」をクリックします。
- これで、メトリックが使用可能になります。「Performance Monitoring Setting」パネルで、モニター・レベルを「 low」に設定します。
- 「OK」をクリックします。
- 行った変更を保存するには、「適用」をクリックする必要があります。
WLM PMI メトリックは、サーバー上でサーバーごとに表示できます。 Tivoli Performance Viewer で、
を選択します。デフォルトでは、データは表内に未加工の形式で表示され、総数として 10 分間隔で収集されます。 また、データの差分や比率での表示、カラムの追加または除去、 バッファーのクリア、メトリックのゼロへのリセット、収集の比率やバッファー・サイズの変更などを行うこともできます。PMI データを取得したら、クラスターのメンバーごとに、クラスターの全メンバーの numIncomingRequests の合計に対する numIncomingRequests のパーセンテージを計算する必要があります。 このパーセンテージ値と、クラスターの各メンバーに送信されたウェイトのパーセンテージを比較することにより、クラスターの各メンバーに送信されたワークロードのバランスの初期状況が分かります。
numIncomingRequests のほかに、2 つのメトリック (numincomingStrongAffinityRequests と numIncomingNonWLMObjectRequests) によって、 クラスターのメンバー間における作業のバランスがどのように計られるかが示されます。 これらの 2 つのメトリックは、クラスターにおいて、クラスターにサービスを提供する唯一の特定メンバー に送信される要求の数を示しています。
- Server1 = 5
- Server2 = 3
- Server3 = 2
- Server1 にルーティングされる % = weight1 / (weight1+weight2+weight3) = 5/10 または 50%
- Server2 にルーティングされる % = weight2 / (weight1+weight2+weight3) = 3/10 または 30%
- Server3 にルーティングされる % = weight3 / (weight1+weight2+weight3) = 2/10 または 20%
ここで、強いアフィニティーや非 WLM オブジェクト要求を伴う着信要求がない場合について考えてみましょう。
- numIncomingRequestsServer1 = 390
- numIncomingRequestsServer2 = 237
- numIncomingRequestsServer3 = 157
したがって、クラスターに着信する要求の総数は、 numIncomingRequestsCluster = numIncomingRequestsServer1 + numIncomingRequestsServer2 + numIncomingRequestsServer3 = 784 となります。
numincomingStrongAffinityRequests = 0
numIncomingNonWLMObjectRequests = 0
- Server1 にルーティングされる % (実際の割合) = 390 / 784 = 49.8%
- Server2 にルーティングされる % (実際の割合) = 237 / 784 = 30.2%
- Server3 にルーティングされる % (実際の割合) = 157 / 784 = 20.0%
- Server1 = 5
- Server2 = 3
- Server3 = 2
- Server1 にルーティングされる % = weight1 / (weight1+weight2+weight3) = 要求の 5/15 または 1/3
- Server2 にルーティングされる % = weight2 / (weight1+weight2+weight3) = 要求の 5/15 または 1/3
- Server3 にルーティングされる % = weight3 / (weight1+weight2+weight3) = 要求の 5/15 または 1/3
- numIncomingRequestsServer1 = 1236
- numIncomingRequestsServer2 = 1225
- numIncomingRequestsServer3 = 1230
- numIncomingRequestsCluster = numIncomingRequestsServer1 + numIncomingRequestsServer2 + numIncomingRequestsServer3 = 3691
- numincomingStrongAffinityRequests = 445 であり、 445 の要求は、すべて Server1 に向けられます。
- numIncomingNonWLMObjectRequests = 0.
- Server1 にルーティングされる % (実際の割合) = 1236 / 3691= 33.49%
- Server2 にルーティングされる % (実際の割合) = 1225 / 3691= 33.19%
- Server3 にルーティングされる % (実際の割合) = 1230 / 3691= 33.32%
ただし、このデータの正しく解釈としては、Server1 には数百個の強いアフィニティーの要求があったため、要求のルーティングは、完全にはバランスが取れていないということになります。WLM は、新しい着信要求を、トランザクション・アフィニティーに参加していないサーバーに優先的に配布して、トランザクションに参加しているサーバーを補正することにより、1 つ以上のサーバーに送信された、強いアフィニティーの要求を補正しようとします。強いアフィニティーの着信要求および非 WLM オブジェクト要求の場合、分析はこのケースに類似します。
PMI データを分析して、トランザクション・アフィニティーと非 WLM オブジェクト要 求を計算し、クラスター内のサーバーへの実際の着信要求の割合が、割り当 てられたウェイトを反映していない場合は、要求が正しく平衡化されていないことを示します。 このような場合は、このステップを繰り返して環境および構成に関する問題を除去し、 ログ・ファイルを参照してから次の処理に進むことをお勧めします。
問題の解決または IBM サポートへの連絡
PMI データまたはクライアント・ログが WLM 内でエラーを示している場合は、以下の情報を収集した上で、IBM サポートに連絡してください。
クライアント・ログが WLM 内でエラーを示している場合は、以下の情報を収集した上で、IBM サポートに連絡してください。
- 環境についての詳細な説明。
- 症状の説明。
クラスター内の全サーバーの SystemOut.logs および SystemErr.logs ファイル。
クラスター内の全サーバーのログ・ファイル。
activity.log ファイル。
First Failure Data Capture ログ・ファイル。
PMI メトリック。
- クライアントが行おうとしていることについての説明、およびクライアントについての説明。 例えば、使用するスレッドは単一または複数であることや、サーブレットや J2EE クライアントについての説明などをお知らせください。
以上の方法で問題を解決できない場合は、『問題の診断および修正: 学習用リソース』トピック内のリンクを使用して、問題が既に特定され、文書化されているかどうかを調べてください。 類似した問題が見つからない場合、または提供されている情報では問題が解決されない場合は、 IBM サポートに連絡してください。
そこに問題がリストされていない場合は、IBM サポートに連絡してください。
IBM サポートから入手可能な既知の問題およびその解決法に関する最新の情報については、
IBM サポート・ページを参照してください。PMR を開く前にこのページも参照してください。問題を解決するのに必要な情報を収集する時間を節約できる資料が含まれています。
IBM サポートから入手可能な既知の問題およびその解決法に関する最新の情報については、IBMi ソフトウェア・ページを参照してください。
PMR を開く前にこのページも参照してください。
問題を解決するために収集して IBM に送信する必要のある文書の情報が
含まれています。