分散されないワークロード

ワークロードの分散に関する問題が発生している場合は、この情報が問題の診断に役立つ場合があります。

注: このトピックでは、 1 つ以上のアプリケーション・サーバー・ログ・ファイルを参照します。推奨される代替案として、分散システムや IBM® i システムの SystemOut.logSystemErr.logtrace.logactivity.log ファイルではなく、High Performance Extensible Logging (HPEL) ログおよびトレース・インフラストラクチャーを使用するようにサーバーを構成できます。また HPEL は、ネイティブ z/OS® ロギング機能と連携させて使用することができます。HPEL を使用する場合、LogViewer コマンド・ライン・ツールを サーバー・プロファイルの bin ディレクトリーから使用して、すべてのログ・ファイルにアクセスし、 情報をトレースできます。HPEL の使用について詳しくは、HPEL を使用してのアプリケーションの トラブルシューティングに関する情報を参照してください。
これらの説明で問題が解決しない場合は、以下を行ってください。
  1. [AIX Solaris HP-UX Linux Windows][IBM i]以下のようにして、問題のデプロイメント・マネージャーおよびアプリケーション・サーバーの JVM ログを参照する。
    1. インフォメーション・センター・ナビゲーションの「Reference」ビューを選択し、 ナビゲーション・ツリーで「メッセージ」を展開して、エラー・メッセージを検索する。
    2. [AIX Solaris HP-UX Linux Windows][IBM i]Log and Trace Analyzer のツールを使用して、デプロイメント・マネージャーおよび問題が発生しているノードの保守ログ (activity.log) を参照し、分析します。 app_server_root/logs および app_server_root/logs の両方の activity.log ファイルを参照します。
    3. [IBM i]デプロイメント・マネージャーおよび問題が発生しているノードの保守ログ (activity.log) を分析する。 profile_root/logsactivity.log ファイルを参照します。
    4. Java™ 例外がログ・ファイルに出力されている場合は、問題に直接関係している実際のサブコンポーネントを判別します。これを行うには、トレース・スタックを調べ、例外を作成したスタックの先頭近くで、製品に関連したクラス (名前が com.ibm.websphere または com.ibm.ws で始まる) を探します。 必要に応じて、インフォメーション・センターの『WebSphere アプリケーションのトラブルシューティング』セクションで、該当するサブコンポーネントのトラブルシューティングの手順を参照してください。

      例えば、例外が com.ibm.websphere.naming パッケージ内の クラスによってスローされた可能性がある場合は、『ネーミング・サービス・コンポーネントの トラブルシューティングのヒント』トピックを参照してください。

  2. [z/OS]以下のようにして、問題のデプロイメント・マネージャーおよびアプリケーション・サーバーの JVM ログを参照する。
    1. インフォメーション・センター・ナビゲーションの「Reference」ビューを選択し、 ナビゲーション・ツリーで「メッセージ」を展開して、エラー・メッセージを検索する。
    2. Java 例外がログ・ファイルに出力されている場合は、問題に直接関係している実際のサブコンポーネントを判別します。これを行うには、トレース・スタックを調べ、例外を作成したスタックの先頭近くで、製品に関連したクラス (名前が com.ibm.websphere または com.ibm.ws で始まる) を探します。 必要に応じて、該当するサブコンポーネントのトラブルシューティングのステップを、 インフォメーション・センターの『WebSphere アプリケーションのトラブルシューティング』セクションで 確認します。

      例えば、例外が com.ibm.websphere.naming パッケージ内の クラスによってスローされた可能性がある場合は、『ネーミング・サービス・コンポーネントの トラブルシューティングのヒント』トピックを参照してください。

  3. 以下のように ping コマンドを実行して、構成に含まれるすべてのマシンが互いに TCP/IP で接続できることを確認する。
    1. 各物理サーバーからデプロイメント・マネージャーへ
    2. デプロイメント・マネージャーから各物理サーバーへ
  4. 問題がクラスター化環境で発生している場合でも、 実際の原因はクラスター化に間接的にしか関係していないか、無関係である可能性があります。 以下のような、関連するあらゆる可能性を調べてください。
    1. 1 つ以上のサーバー上のエンタープライズ Bean が要求を処理していない場合は、 『サーブレット、JSP、スタンドアロン・プログラム、またはその他のクライアントからエンタープライズ Bean にアクセスできない』トピックおよび『サーブレット、 JSP ファイル、またはその他のクライアントから、製品がホスティングするオブジェクトを検索できない』トピックを参照してください。
    2. セキュリティーを使用可能にした後に問題が発生したと思われる場合は、『セキュリティーを使用可能にした後のエラーまたはアクセス問題』のトピックを参照してください。
    3. アプリケーション・サーバーが要求に応答しなくなる場合、または自動的に終了する (アプリケーション・サーバーのプロセスがクローズする) 場合は、Web モジュールまたはアプリケーション・サーバーが終了またはハングする問題に関するトピックを参照してください。
    4. SOAP 要求が一部のサーバーまたはすべてのサーバーで処理されていない場合は、『SOAP 要求の送信時にクライアント戻されるエラー』のトピックを参照してください。
    5. [AIX Solaris HP-UX Linux Windows][IBM i]1 つ以上のノード上のサーバーにアプリケーションをインストールまたはデプロイする際に問題が発生する場合は、コードのデプロイメントおよびインストールにおける問題のトラブルシューティングに関するトピックを参照してください。
  5. [AIX Solaris HP-UX Linux Windows][IBM i]トポロジーが Windows ベースのデプロイメント・マネージャーおよびサポートされる UNIX システム・サーバーで構成されている場合は、サポートされる UNIX ベースのシステムで vi を使用して、最近更新された .xml および .policy ファイルを参照し、Control-M 文字が含まれていないか確認します。 将来この問題が起こらないようにするには、サポートされる UNIX ベースのシステムで vi を使用してファイルを編集し、これらの文字を挿入しないようにします。
  6. [AIX Solaris HP-UX Linux Windows][IBM i]ワークロード管理コンポーネントのトラブルシューティングのヒントを確認します。
  7. 『使用可能なオンライン・サポート (ヒント、 技術情報、およびフィックス)』を参照して、問題が特定され、文書化されているかどうかを確認してください。

HTTP 要求が一部のサーバーにしか分散されない

HTTP 要求が一部のサーバーにしか分散されない場合は、以下のようにします。
  • Primary Servers リストを確認します。 アフィニティーが確立されていない場合、 プラグインによって、Primary Servers リストに定義されているすべてのサーバーを対象にロード・バランシングが行われます。 Primary Servers リストを定義していない場合、 アフィニティーが確立されていなければ、プラグインによって、 クラスターで定義されているすべてのサーバーを対象にロード・バランシングが行われます。 アフィニティーが確立されている場合、 プラグインは、同じ HTTP セッション内のすべての要求について、 直接そのサーバーにアクセスするはずです。
  • 一部のサーバーのみが要求に対してサービスを提供している場合は、 問題のサーバーに直接アクセスして、 ワークロード管理問題とは別に、そのサーバーが作動するかどうか確認してください。 作動しない場合は、以下のようにしてください。
    • 管理コンソールを使用して、影響を受けたサーバーが稼働していることを確認してください。
    • 詳しくは、『Web リソースが表示されない』のトピックを参照してください。
  • 詳しくは、HTTP プラグイン・コンポーネントのトラブルシューティングについてのヒントに関するトピックを参照してください。
  • [AIX Solaris HP-UX Linux Windows][IBM i]『ワークロード管理コンポーネントのトラブルシューティング』のトピックで、ワークロード管理問題を診断する手順を確認してください。

エンタープライズ Bean 要求が一部のサーバーにしか分散されない

クライアントが、到達できるはずのクラスター内サーバーに到達できない場合は、 サーバーが使用不能とマークされているか、ダウンしている可能性があります。 これを検査するには、以下のようにします。
  • 管理コンソールを使用して、サーバーが始動済みであるか検査する。 始動を試行するか、始動済みである場合は停止して再始動してください。
  • 管理コンソールを参照し、問題が発生しているサーバーを実行中のノードが表示されることを確認する。表示されない場合は、以下を行ってください。
    • クラスターにノードを追加するためのステップを確認する。
    • 1 つ以上のノードが管理コンソールに表示されない』のセクションに記載されたステップを確認してください。
  • 可能であれば、問題のサーバー上のエンタープライズ Bean に直接アクセスして、TCP/IP の接続性、アプリケーション・サーバーの正常性に問題があるかどうか、あるいはワークロード管理とは関係のない、別の問題があるかどうかを調べてください。 エンタープライズ Bean に直接アクセスできない場合は、『サーブレット、JSP ファイル、スタンドアロン・プログラム、またはその他のクライアントから Enterprise Bean にアクセスできない』のトピックを参照してください。
  • [AIX Solaris HP-UX Linux Windows][IBM i]『ワークロード管理コンポーネントのトラブルシューティング』のトピックで、ワークロード管理問題を診断する手順を確認してください。
[AIX Solaris HP-UX Linux Windows][IBM i]

エンタープライズ Bean 要求が均等に分散されない

この振る舞いの理由として考えられるものがいくつかあります。 一般に、以下のカテゴリーのうちの 1 つ以上が、理由として当てはまります。
  • 構成が不適切
  • サーバーまたはアプリケーションの可用性など、環境に問題がある
  • トランザクション・アフィニティーを含む要求が大量に発生する、または
  • クライアントが少ない

[AIX Solaris HP-UX Linux Windows][IBM i]本製品でのワークロード管理は、サーバー間で要求を分散させる加重プロポーショナル・スキームに基づいています。 このため、バランスは要求数によって決定され、その他の尺度では決定されません。 実際のバランスに関する問題は、クラスターの各メンバーが処理する要求数と、 それらのメンバーごとに設定されたウェイトを比較することによって判別されます。 これは、『ワークロード管理コンポーネントのトラブルシューティング』のトピックに記述されている手順に従って行うことができます。

[z/OS]本製品でのワークロード管理は、ラウンドロビン方式の要求の分散に基づいています。 このため、バランスは要求数によって決定され、その他の尺度では決定されません。 実際のバランスに関する問題は、クラスターの各メンバーが処理する要求数と、 それらのメンバーごとに設定されたウェイトを比較することによって判別されます。

[z/OS]
  • クラスターの各メンバーに着信する要求のパーセンテージがウェイトと矛盾しなければ、 アプリケーションのその後の分析では、要求数のバランスが取れていても、 ワークロードが不均衡である原因を判別する必要になります。
  • numIncomingNonWLMObjectRequests の数がクラスターのメンバー間で不均衡であり、 かつ numIncomingRequests に対して大きい場合、不均衡になる理由は、分散不可能なコンポーネントがクラスターのメンバーにインストールされているためです。 構成を変更すれば、よりバランスの取れた環境になります。
  • numIncomingStrongAffinityRequests の数がクラスターのメンバー間で不均衡であり、 かつ numIncomingRequests に対して大きい場合、 不均衡になる理由は、トランザクション内で要求が呼び出されるためです。 これらの要求は、 同じクラスター内のトランザクションに含まれるオブジェクトをインストールすることによって削減できます。

障害のあるサーバーが依然としてエンタープライズ Bean 要求を受け取っている (フェイルオーバーが完了しない)

この問題の原因としては、以下のことが考えられます。
  • [AIX Solaris HP-UX Linux Windows][IBM i]クライアントが、ダウンしたサーバー上のエンタープライズ Bean でトランザクションを行っていた可能性がある。 問題のエンタープライズ Bean インスタンスをホスティングしているアプ リケーション・サーバーの JVM ログを確認してください。 要求が CORBA SystemException COMM_FAILURE org.omg.CORBA.completion_status.COMPLETED_MAYBE とともに戻される場合、 これは設計どおりに作動しています。 設計では、トランザクションが完了したため、 この特定の例外をクライアントにフローさせて戻すようになっています。 この要求を別のサーバーにフェイルオーバーすると、 この要求には 2 回サービスが提供されたことになります。
  • [z/OS]クライアントが、ダウンしたサーバー上のエンタープライズ Bean でトランザクションを行っていた可能性がある。 問題のエンタープライズ Bean インスタンスをホスティングしているアプ リケーション・サーバーの JVM ログを確認してください。 要求が CORBA SystemException COMM_FAILURE org.omg.CORBA.completion_status.COMPLETED_MAYBE とともに戻される場合、 これは設計どおりに作動しています。 設計では、トランザクションが完了したため、 この特定の例外をクライアントにフローさせて戻すようになっています。 この要求を別のサーバーにフェイルオーバーすると、 この要求には 2 回サービスが提供されたことになります。
  • [AIX Solaris HP-UX Linux Windows][IBM i]サーバーに送信された要求が、 常に別の例外を伴ってクライアントに戻される場合は、 使用できるサーバーがない可能性があります。 この場合は、『ワークロード管理コンポーネントのトラブルシューティング』のトピックに概略が説明されている解決手順に従ってください。
  • [z/OS]サーバーに送信された要求が、 常に別の例外を伴ってクライアントに戻される場合は、 使用できるサーバーがない可能性があります。
[z/OS]

停止またはハングしたサーバーがリストア後にワークロードを共有しない

このエラーは、以前は利用できなかったサーバーが、リストア後にワークロード管理コンポーネントで認識されない場合に発生します。 プロパティー com.ibm.websphere.wlm.unusable.interval によって 決定される使用不能 の間隔があり、その間、ワークロード・マネージャーは使用不能とマークされたサーバーへの送信を待ちます。 デフォルトでは、これは 5 分です。

これが問題であることを確認するには、ダウンしていたサーバーが、起動して要求を処理できる状態にあることを確認します。 次に、使用不能な間隔が経過するのを待ってから、フェイルオーバーが発生したかどうかを調べます。

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

バックアップ・クラスターに対しフェイルオーバーしないクラスター

次の例のようなエラーを経験することがあります。
[10/11/04 13:11:10:233 CDT] 00000036 SelectionMana A    WWLM0061W: An error was 
encountered sending a request to cluster member  {MEMBERNAME=FlorenceEJBServer1, 
NODENAME=fwwsaix1Node01} and that member has been  marked unusable for future 
requests to the cluster "", because of exception:  org.omg.CORBA.COMM_FAILURE: 
CONNECT_FAILURE_ON_SSL_CLIENT_SOCKET - JSSL0130E:  java.io.IOException: Signals 
that an I/O exception of some sort has occurred.   Reason:  Connection refused  
vmcid: 0x49421000  minor code: 70  completed: No" 
構成を修正するには、以下のステップを実行します。
  1. ご使用のデプロイメント・マネージャーで、各バックアップ・クラスター設定のホスト名とブートストラップ・ポートを確認します。
  2. コア・グループ・ブリッジのピア・ポートを調べ、ホスト名と分散および整合性サービス (DCS) ポートが正しく設定されているかを確認します。
  3. 1 次クラスター名およびバックアップ・クラスター名が一致しているかを確認します。
  4. アプリケーションが、バックアップ・クラスターへのセキュリティーを通過する場合、セキュリティーの構成を確認してください。シングル・サインオン (SSO) を使用して、バックアップ・セルに対して Lightweight Third Party Authentication (LTPA) キーをインポートする必要がある場合があります。

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



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