ワークロード管理コンポーネントのトラブルシューティングのヒント

ワークロード管理コンポーネントによって、マルチノード構成されたサーバー間でワークロードが正しく分散されない場合は、以下のオプションを使用して問題を取り除いてください。

注: このトピックでは、 1 つ以上のアプリケーション・サーバー・ログ・ファイルを参照します。推奨される代替案として、分散システムや IBM® i システムの SystemOut.logSystemErr.logtrace.logactivity.log ファイルではなく、High Performance Extensible Logging (HPEL) ログおよびトレース・インフラストラクチャーを使用するようにサーバーを構成できます。また HPEL は、ネイティブ z/OS® ロギング機能と連携させて使用することができます。HPEL を使用する場合、LogViewer コマンド・ライン・ツールを サーバー・プロファイルの bin ディレクトリーから使用して、すべてのログ・ファイルにアクセスし、 情報をトレースできます。HPEL の使用について詳しくは、HPEL を使用してのアプリケーションの トラブルシューティングに関する情報を参照してください。

環境または構成の問題の除去

サーバーがアプリケーションに対して使用可能になっている場合に、サーバーからアプリケーションにサービスが提供されているかどうかを判別します。 問題のあるクラスターを確認します。
  • クラスターのメンバーまたは管理サーバー (例えば、デプロイメント・マネージャーまたはノード・エージェント) にネットワーク接続に関する問題がありますか?
    • 問題がある場合は、マシンに ping して、それらのマシンが正しくネットワークに接続されているかを確認してください。
  • サーバーがインストールされているマシンで、 サーバーが要求を処理する能力に影響を及ぼすような、別のアクティビティーが実行されていますか? 例えば、タスク・マネージャー、プロセッサー ID、またはその他の外部ツールで計測される プロセッサー使用状況をチェックして、以下について確認してください。
    • プロセッサー使用状況が予想どおりではない、あるいは不規則で安定していない。
    • 新規に追加、インストール、またはアップグレードされたクラスターのメンバーが使用されていないことを示している。
  • 各ノードで始動したすべてのアプリケーション・サーバーが実行されているか、あるいは一部が停止していますか。
  • アプリケーションがインストールされ、作動していますか。
  • コンテナー管理パーシスタンス (CMP) または Bean 管理パーシスタンス (BMP) エンタープライズ Bean 間でのワークロードの分散に関する問題の場合、サポートする JDBC プロバイダーおよび JDBC データ・ソースを 各サーバー上で構成済みですか。

HTTP 要求に関連したワークロード管理問題が発生した場合 (HTTP 要求の処理が、クラスターの一部のメンバーでしか実行されないなど)、アフィニティーが確立されていなければ、HTTP プラグインによって、PrimaryServers リストに定義されているすべてのサーバーでロード・バランスが行われることに注意してください。 PrimaryServers リストを定義していない場合は、アフィニティーが確立されていなければ、プラグインによって、クラスターで定義されているすべてのサーバーに渡って、ロード・バランシングが行われます。 アフィニティーが確立されている場合、プラグインはすべての要求に対処するために直接そのサーバーに移動します。

クラスターの一部のメンバーでのみ エンタープライズ Bean 要求が処理されるなどの、エンタープライズ Bean 要求に関連する ワークロード管理問題が発生している場合、以下を行ってください。
  • ウェイトが許容値に設定されているかを確かめます。
    • 問題が発生しているクラスターについて、管理コンソールにログオンして、以下のことを行う。
      1. 「サーバー」 > 「クラスター」 > 「WebSphere Application Server クラスター (WebSphere application server clusters)」を選択する。
      2. リストからクラスターを選択する。
      3. クラスター・メンバー」を選択する。
      4. クラスター内のサーバーごとに server_name をクリックして、サーバーに割り当てられたウェイトに注目する。
    • ウェイトの有効範囲が 0 から 20 までであることを確認してください。 サーバーのウェイトが 0 である場合、要求はそのサーバーにはルーティングされません。 20 より大きいウェイトは 0 として処理されます。

これ以降は エンタープライズ Bean ワークロード・バランシングについてのみ説明します。 Web (HTTP) 要求の分散における問題の診断についての詳細は、『Web サーバー・プラグインのトラブルシューティングのヒント』および『Web リソースが表示されない』トピックを参照してください。

[IBM i][AIX Solaris HP-UX Linux Windows]

ログ・ファイルでの WLM エラーおよび CORBA マイナー・コードの参照

エンタープライズ Bean ワークロード管理に関する 問題が解消されない場合は、次のステップとして、アクティビティー・ログを調べて、 以下に示す項目が記述されているかどうか確認します。
  • 複数回使用不能とマークされ、使用不能なままになっているサーバーがある。
  • クラスター内のすべてのサーバーが不良とマークされ、使用不能なままになっている。
  • [z/OS]ロケーション・サービス・デーモン (LSD) が複数回使用不能とマークされ、使用不能なままになっている。

[IBM i][AIX Solaris HP-UX Linux Windows]これを確認するには、Log and Trace Analyzer を使用して、影響を受けたサーバー上の保守ログ (activity.log) を開き、以下の項目を探します。

[z/OS]これを確認するには、影響を受けたサーバー上の保守ログを開き、以下の項目を探します。

  • 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 がスローされています。

これらの警告のいずれかが表示された場合は、ログで指定されているユーザー応答に従ってください。 ユーザー応答に従った後も、警告が引き続き発生する場合は、 影響を受けたサーバーで Log and Trace Analyzer 内のその他のエラーと警告を参照して、以下を探してください。
  • 構成設定の変更などの、可能なユーザー応答。
  • 本製品に障害が発生したことを示している可能性がある基本クラス例外。

WLM は CORBA (Common Object Request Broker Architecture) を使用してプロセス間の通信を行うため、 例外の名前の一部として「CORBA」と付けられている例外も表示される場合があります。 例外スタック内で、「 マイナー・コード」と明記されているステートメントを検索してください。これらのコードは、CORBA 呼び出しまたは応答が完了できなかった特定の 理由を示します。WLM マイナー・コードは、0x4921040 から 0x492104F の範囲になります。WLM に関連したマイナー・コードについては、『参照: 生成された API 資料』トピックで、パッケージおよびクラス com.ibm.websphere.wlm.WsCorbaMinorCodes の説明を参照してください。

[IBM i][AIX Solaris HP-UX Linux Windows]

PMI データの分析

PMI データを分析する目的は、 クラスターの各メンバーに着信するワークロードを理解することです。 クラスターのあるメンバーのデータは、クラスターの全メンバーのデータのコンテキスト内でのみ有用です。

Tivoli® Performance Viewer を使用して、各サーバーが、クラスター・メンバーに割り当てられたウェイト (定常状態のウェイト) に基づき、正しい比率で要求を受け取っていることを検証します。

Tivoli Performance Viewer を使用して PMI メトリックを収集するには、Tivoli Performance Viewer 製品のナビゲーションで以下のアクションを実行します。
  1. ツリー・ビューで「データ収集」を選択します。PMI が使用可能になっていないサーバーは、ぼかし表示されます。
  2. データ収集をオンにしたいデータを保持する各サーバーごとに、「指定...」をクリックします。
  3. これで、メトリックが使用可能になります。「Performance Monitoring Setting」パネルで、モニター・レベルを「 low」に設定します。
  4. OK」をクリックします。
  5. 行った変更を保存するには、「適用」をクリックする必要があります。

WLM PMI メトリックは、サーバー上でサーバーごとに表示できます。 Tivoli Performance Viewer で、「ノード」 > 「サーバー」 > 「ワークロード管理」 > 「Server/Client」を選択します。デフォルトでは、データは表内に未加工の形式で表示され、総数として 10 分間隔で収集されます。 また、データの差分や比率での表示、カラムの追加または除去、 バッファーのクリア、メトリックのゼロへのリセット、収集の比率やバッファー・サイズの変更などを行うこともできます。

PMI データを取得したら、クラスターのメンバーごとに、クラスターの全メンバーの numIncomingRequests の合計に対する numIncomingRequests のパーセンテージを計算する必要があります。 このパーセンテージ値と、クラスターの各メンバーに送信されたウェイトのパーセンテージを比較することにより、クラスターの各メンバーに送信されたワークロードのバランスの初期状況が分かります。

numIncomingRequests のほかに、2 つのメトリック (numincomingStrongAffinityRequests と numIncomingNonWLMObjectRequests) によって、 クラスターのメンバー間における作業のバランスがどのように計られるかが示されます。 これらの 2 つのメトリックは、クラスターにおいて、クラスターにサービスを提供する唯一の特定メンバー に送信される要求の数を示しています。

例えば、3 つのサーバーを保持するクラスターがあるとします。 これら 3 つのサーバーに、それぞれ以下のウェイトを割り当てました。
  • 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 オブジェクト要求を伴う着信要求がない場合について考えてみましょう。

このシナリオでは、収集された PMI メトリックが示すサーバーごとの着信要求数は、 以下のとおりであると想定します。
  • numIncomingRequestsServer1 = 390
  • numIncomingRequestsServer2 = 237
  • numIncomingRequestsServer3 = 157

したがって、クラスターに着信する要求の総数は、 numIncomingRequestsCluster = numIncomingRequestsServer1 + numIncomingRequestsServer2 + numIncomingRequestsServer3 = 784 となります。

numincomingStrongAffinityRequests = 0

numIncomingNonWLMObjectRequests = 0

WLM がクラスター内のサーバー間で着信要求を正しくバランシングしているかどうかを、 このデータに基づいて判別することができるでしょうか? 強いアフィニティーを持つ要求がないため、問題は、予想される割合に含まれる要求が、割り当てられたウェイトに基づいているかということです。その問いに答えるための計算方法は、以下のとおり簡単です。
  • Server1 にルーティングされる % (実際の割合) = 390 / 784 = 49.8%
  • Server2 にルーティングされる % (実際の割合) = 237 / 784 = 30.2%
  • Server3 にルーティングされる % (実際の割合) = 157 / 784 = 20.0%
したがって、WLM は、データが完全に予想どおりであるため、 サーバーに割り当てられたウェイトに基づいて、設計どおりに振る舞います。
例えば、3 つのサーバーを保持するクラスターがあるとします。 これら 3 つのサーバーに、それぞれ以下のウェイトを割り当てました。
  • Server1 = 5
  • Server2 = 3
  • Server3 = 2
これらのサーバーのクラスターが要求を処理できるようにして、 システムが安定した状態 (つまり、クラスターへの着信要求数がサーバーからの応答数に等しくなっている状態) になるまで待機します。 このような状態では、Server1 から 3 へルーティングされる要求の予想パーセンテージは、以下のとおりです。
  • 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
このシナリオでは、収集された PMI メトリックが示すサーバーごとの着信要求数は、 以下のとおりであると想定します。
  • numIncomingRequestsServer1 = 1236
  • numIncomingRequestsServer2 = 1225
  • numIncomingRequestsServer3 = 1230
したがって、クラスターに着信する要求の総数は、次のようになります。
  • numIncomingRequestsCluster = numIncomingRequestsServer1 + numIncomingRequestsServer2 + numIncomingRequestsServer3 = 3691
  • numincomingStrongAffinityRequests = 445 であり、 445 の要求は、すべて Server1 に向けられます。
  • numIncomingNonWLMObjectRequests = 0.
この場合、要求数は、予想通り 3 つのサーバー間で均等に分散されませんでした。代わりに、 分配は次のようになります。
  • Server1 にルーティングされる % (実際の割合) = 1236 / 3691= 33.49%
  • Server2 にルーティングされる % (実際の割合) = 1225 / 3691= 33.19%
  • Server3 にルーティングされる % (実際の割合) = 1230 / 3691= 33.32%

ただし、このデータの正しく解釈としては、Server1 には数百個の強いアフィニティーの要求があったため、要求のルーティングは、完全にはバランスが取れていないということになります。WLM は、新しい着信要求を、トランザクション・アフィニティーに参加していないサーバーに優先的に配布して、トランザクションに参加しているサーバーを補正することにより、1 つ以上のサーバーに送信された、強いアフィニティーの要求を補正しようとします。強いアフィニティーの着信要求および非 WLM オブジェクト要求の場合、分析はこのケースに類似します。

PMI データを分析して、トランザクション・アフィニティーと非 WLM オブジェクト要 求を計算し、クラスター内のサーバーへの実際の着信要求の割合が、割り当 てられたウェイトを反映していない場合は、要求が正しく平衡化されていないことを示します。 このような場合は、このステップを繰り返して環境および構成に関する問題を除去し、 ログ・ファイルを参照してから次の処理に進むことをお勧めします。

問題の解決または IBM サポートへの連絡

[IBM i][AIX Solaris HP-UX Linux Windows]PMI データまたはクライアント・ログが WLM 内でエラーを示している場合は、以下の情報を収集した上で、IBM サポートに連絡してください。

クライアント・ログが WLM 内でエラーを示している場合は、以下の情報を収集した上で、IBM サポートに連絡してください。

  • 環境についての詳細な説明。
  • 症状の説明。
  • [IBM i][AIX Solaris HP-UX Linux Windows]クラスター内の全サーバーの SystemOut.logs および SystemErr.logs ファイル。
  • [z/OS]クラスター内の全サーバーのログ・ファイル。
  • [IBM i][AIX Solaris HP-UX Linux Windows]activity.log ファイル。
  • [IBM i][AIX Solaris HP-UX Linux Windows]First Failure Data Capture ログ・ファイル。
  • [IBM i][AIX Solaris HP-UX Linux Windows]PMI メトリック。
  • クライアントが行おうとしていることについての説明、およびクライアントについての説明。 例えば、使用するスレッドは単一または複数であることや、サーブレットや J2EE クライアントについての説明などをお知らせください。

以上の方法で問題を解決できない場合は、『問題の診断および修正: 学習用リソース』トピック内のリンクを使用して、問題が既に特定され、文書化されているかどうかを調べてください。 類似した問題が見つからない場合、または提供されている情報では問題が解決されない場合は、 IBM サポートに連絡してください。

[AIX Solaris HP-UX Linux Windows][z/OS]そこに問題がリストされていない場合は、IBM サポートに連絡してください。

[AIX Solaris HP-UX Linux Windows]IBM サポートから入手可能な既知の問題およびその解決法に関する最新の情報については、 IBM サポート・ページを参照してください。PMR を開く前にこのページも参照してください。問題を解決するのに必要な情報を収集する時間を節約できる資料が含まれています。

[IBM i]IBM サポートから入手可能な既知の問題およびその解決法に関する最新の情報については、IBMi ソフトウェア・ページを参照してください。 PMR を開く前にこのページも参照してください。 問題を解決するために収集して IBM に送信する必要のある文書の情報が 含まれています。


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



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