WebSphere Application Server Network Deployment for i5/OS, Version 6.1   
             オペレーティング・システム: i5/OS

             目次と検索結果のパーソナライズ化

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

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

どのような問題が発生しましたか?
これらの説明で問題が解決しない場合は、以下を行ってください。
  1. 以下のようにして、問題のデプロイメント・マネージャーおよびアプリケーション・サーバーの JVM ログを参照する。
    1. インフォメーション・センター・ナビゲーションの「Reference」ビューを選択し、 ナビゲーション・ツリーで「メッセージ」を展開して、エラー・メッセージを検索する。
    2. Log and Trace Analyzer のツールを使用して、デプロイメント・マネージャーおよび問題が発生しているノードの保守ログ (activity.log) を参照し、分析します。 app_server_root/logs および app_server_root/logs の両方の activity.log ファイルを参照します。
    3. デプロイメント・マネージャーおよび問題が発生しているノードの保守ログ (activity.log) を分析する。 profile_root/logsactivity.log ファイルを参照します。
    4. Java 例外がログ・ファイルに出力されている場合は、問題に直接関係している実際のサブコンポーネントを判別する。これを行うには、トレース・スタックを調べ、例外を作成したスタックの先頭近くで、WebSphere Application Server 関連のクラス (名前が com.ibm.websphere または com.ibm.ws で始まる) を探します。 必要に応じて、該当するサブコンポーネントのトラブルシューティングのステップを、 インフォメーション・センターの『WebSphere アプリケーションのトラブルシューティング』セクションで 確認します。

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

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

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

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

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

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

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

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

WebSphere Application Server でのワークロード管理は、サーバー間で要求をスプレイする加重プロポーショナル・スキームに基づいています。 このため、バランスは要求数によって決定され、その他の尺度では決定されません。 実際のバランスに関する問題は、クラスターの各メンバーが処理する要求数と、 それらのメンバーごとに設定されたウェイトを比較することによって判別されます。 これは、『ワークロード管理コンポーネントのトラブルシューティング』のステップに従って行います。

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

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

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

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

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

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

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

次の例のようなエラーを経験することがあります。
[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) キーをインポートする必要がある場合があります。

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




関連タスク
トラブルシューティング管理
JVM ログの表示
アプリケーションへのロギングおよびトレースの追加
関連資料
マルチサーバー環境のエラー
ワークロード管理コンポーネントのトラブルシューティングのヒント
ネーミング・サービスのトラブルシューティングのヒント
アプリケーション・アクセスの問題
サーブレット、JSP ファイル、スタンドアロン・プログラム、またはその他のクライアントから、エンタープライズ Bean にアクセスできない
SOAP 要求を送信するアプリケーション・クライアントがエラーを受け取る
Web モジュールまたはアプリケーション・サーバーが要求の処理を停止する
アプリケーション・デプロイメントの問題
Web サーバー・プラグインのトラブルシューティングのヒント
Web リソースが表示されない
セキュリティーを使用可能にした後のアクセス問題
参照トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 8:28:52 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.nd.iseries.doc/info/iseriesnd/ae/rtrb_wlmprobs.html