ワークロード管理コンポーネントによって、マルチノード構成されたサーバー間でワークロードが正しく分散されない場合は、以下のオプションを使用して問題を取り除いてください。
環境または構成の問題の除去
サーバーがアプリケーションに対して使用可能になっている場合に、サーバーからアプリケーションにサービスが提供されているかどうかを判別します。
問題のあるクラスターを確認します。
- クラスターのメンバーまたは管理サーバー (例えば、デプロイメント・マネージャーまたはノード・エージェント) にネットワーク接続に関する問題がありますか?
- 問題がある場合は、マシンに ping して、それらのマシンが正しくネットワークに接続されているか確認してください。
- サーバーがインストールされているマシンで、
サーバーが要求を処理する能力に影響を及ぼすような、別のアクティビティーが実行されていますか?
例えば、タスク・マネージャー、プロセッサー ID、またはその他の外部ツールで計測される
プロセッサー使用状況をチェックして、以下について確認してください。
- プロセッサー使用状況が予想どおりではない、あるいは不規則で安定していない。
- 新規に追加、インストール、またはアップグレードされたクラスターのメンバーが使用されていないことを示している。
- 各ノードで始動したすべてのアプリケーション・サーバーが実行されているか、あるいは一部が停止していますか。
- アプリケーションがインストールされ、作動していますか。
- コンテナー管理パーシスタンス (CMP) または Bean 管理パーシスタンス (BMP) エンタープライズ Bean
間でのワークロードの分散に関する問題の場合、サポートする JDBC プロバイダーおよび JDBC データ・ソースを
各サーバー上で構成済みですか。
HTTP 要求に関連したワークロード管理問題が発生した場合 (HTTP 要求の処理が、クラスターの一部のメンバーでしか実行されないなど)、類縁性が確立されていなければ、HTTP プラグインによって、PrimaryServers リストに定義されているすべてのサーバーでロード・バランスが行われることに注意してください。
PrimaryServers リストを定義していない場合は、類縁性が確立されていなければ、プラグインによって、クラスターで定義されているすべてのサーバーに渡って、ロード・バランシングが行われます。
類縁性が確立されている場合、プラグインはすべての要求に対処するために直接そのサーバーに移動します。
クラスターの一部のメンバーでのみ Enterprise Bean 要求が処理されるなどの、Enterprise Bean 要求に関連する
ワークロード管理問題が発生している場合、以下を行ってください。
- ウェイトが許容値に設定されているかを確かめます。
- 問題が発生しているクラスターについて、管理コンソールにログオンして、以下のことを行う。
- 「サーバー」>「クラスター」を選択する。
- リストからクラスターを選択する。
- 「クラスター・メンバー」を選択する。
- クラスター内のサーバーごとに server_name をクリックして、サーバーに割り当てられたウェイトに注目する。
- ウェイトの有効範囲が 0 から 20 までであることを確認してください。
サーバーのウェイトが 0 である場合、要求はそのサーバーにはルーティングされません。
20 より大きいウェイトは 0 として処理されます。
これ以降は Enterprise Bean ワークロード・バランシングについてのみ説明します。
Web (HTTP) 要求の分散における問題の診断についての詳細は、『Web
サーバー・プラグインのトラブルシューティングのヒント』および『Web
リソースが表示されない』のトピックを参照してください。
ログ・ファイルでの WLM エラーおよび CORBA マイナー・コードの参照
Enterprise Bean ワークロード管理に関する
問題が解消されない場合は、次のステップとして、アクティビティー・ログを調べて、
以下に示す項目が記述されているかどうか確認します。
- 複数回使用不能とマークされ、使用不能なままになっているサーバーがある。
- クラスター内のすべてのサーバーが不良とマークされ、使用不能なままになっている。
- ロケーション・サービス・デーモン (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 始動が実行されるなどの、
通常の操作上の理由から、サーバーに使用不能というタグが付けられる場合があります。
- 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 deployment manager.
- WWLM0067W: クライアントが、要求を再試行するように通知されています。例外 {0}
のため、サーバー要求を WLM により透過的に再試行できませんでした。
要求を処理しようと
しましたが、WLM が要求を透過的に再実行依頼できないような状態を検出しました。原因となる
例外がキャッチされており、クライアントに対してマイナー・コード 0x49421042 (SERVER_SIGNAL_RETRY)
の新規 CORBA.TRANSIENT がスローされています。
これらの警告のいずれかが表示された場合は、ログで指定されているユーザー応答に従ってください。
ユーザー応答に従った後も、警告が引き続き発生する場合は、
影響を受けたサーバーで Log and Trace Analyzer 内のその他のエラーと警告を参照して、以下を探してください。
- 構成設定の変更などの、可能なユーザー応答。
- WebSphere Application Server の障害を示している可能性がある基本クラス例外。
WLM は CORBA (Common Object Request Broker Architecture) を使用してプロセス間の通信を行うため、
例外の名前の一部として「CORBA」と付けられている例外も表示される場合があります。 例外スタック内で、「
マイナー・コード」と明記されているステートメントを検索してください。これらのコードは、CORBA 呼び出しまたは応答が完了できなかった特定の
理由を示します。WLM マイナー・コードは、0x4921040 から 0x492104F の範囲になります。WLM
に関連したマイナー・コードについては、『参照: 生成された API
資料』のトピックで、パッケージおよびクラス com.ibm.websphere.wlm.WsCorbaMinorCodes の説明を参照してください。
PMI データの分析
PMI データを分析する目的は、
クラスターの各メンバーに着信するワークロードを理解することです。
クラスターのあるメンバーのデータは、クラスターの全メンバーのデータのコンテキスト内でのみ有用です。
Tivoli Performance Viewer を使用して、
各サーバーが、クラスター・メンバーに割り当てられたウェイト (定常状態のウェイト) に基づき、
正しい比率で要求を受け取っているか検証します。
Tivoli Performance Viewer を使用して PMI メトリックをオンにする方法は、次のとおりです。
- ツリー・ビューで「データ収集」を選択します。PMI が使用可能になっていないサーバーは、
ぼかし表示されます。
- データ収集をオンにしたいデータを保持する各サーバーごとに、「指定...」をクリックします。
- これで、メトリックが使用可能になります。「Performance Monitoring Setting」パネルで、モニター・レベルを「
low」に設定します。
- 「OK」をクリックします。
- 行った変更を保管するには、「適用」をクリックする必要があります。
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 オブジェクト要
求を計算し、クラスター内のサーバーへの実際の着信要求の割合が、割り当
てられたウェイトを反映していない場合は、要求が正しく平衡化されていないことを示します。
このような場合は、上記のステップを繰り返して環境および構成に関する問題を除去し、
処理を進める前にログ・ファイルを参照することをお勧めします。