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

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

マルチサーバー環境のエラー

この情報を使用して、マルチサーバー環境のセットアップに関する問題をトラブルシューティングします。

どのような問題が発生しましたか?
これらの説明で問題が解決しない場合は、以下を行ってください。
  1. 問題のデプロイメント・マネージャーおよびアプリケーション・サーバーのログを参照する。
    1. インフォメーション・センター・ナビゲーションの「Reference」ビューを選択し、 ナビゲーション・ツリーで「メッセージ」を展開して、エラー・メッセージを検索する。
    2. Java 例外がログ・ファイルに表示されている場合は、問題に直接関係している実際のサブコンポーネントを判別する。 これを行うには、トレース・スタックの先頭近くで、例外を作成した WebSphere Application Server 関連のクラス (名前が com.ibm.websphere または com.ibm.ws で始まる) を探します。

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

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

クラスターを作成して始動した後、 クラスターが始動せず、 そのクラスター内にサーバーが見つからないとログに表示される。

このエラーは、デプロイメント・マネージャーとノード間で構成の同期がとられていない場合に発生することがあります。自動同期 が使用可能になっている場合は、同期が実行されるまで待機してください。 手動で同期を取る場合には、クラスター上の各ノードに対して同期を明示的に要求します。

同期が取られたかどうかを判別するには、管理コンソールを使用してノード・マシン上の構成を調べ、新しいクラスター・メンバーが各ノードに定義されているか確認します。

1 つ以上のノードが管理コンソールに表示されない

この問題は、トポロジー内のデプロイメント・マネージャー・サーバーとその他のサーバー間に基本的な接続性の問題がある場合に発生することがあります。 デプロイメント・マネージャーのディレクトリー構造で serverindex.xml ファイルを探してください。
  • 問題のノードがリストに表示されない場合は、ノードをクラスターに追加するステップを参照してください。
  • 問題のノードがリストに表示される場合は、以下を行います。
    • デプロイメント・マネージャー・サーバーから、リストに表示されるサーバー名に対して ping を実行する。 ping コマンドで通信が示されない場合は、リストにあるホスト名が正しいかを確認し、必要なら訂正してから、デプロイメント・マネージャーを再始動します。
    • リストに表示される名前がショート・ネームである場合は、完全修飾のネットワーク名に対して ping を実行する。 訂正した名前で処理が正常に行われた場合は、リストを更新してデプロイメント・マネージャーを再始動します。
    • 問題のサーバーが動的ホスト構成プロトコル (DHCP) を使用している場合は、論理ホスト名を IP アドレスに置換し、デプロイメント・マネージャーを再始動する。この処置で問題が解決した場合、 問題のサーバーのアドレスが変わるごとに (おそらく問題のマシンをリブートするごとに)、 serverindex.xml ファイルを変更する必要があることに注意してください。 この問題が起こらないようにするには、サーバーに静的 IP アドレスを割り当てることを検討してください。
  • それでもサーバー間の通信を確立できない場合は、ネットワーク管理者に問題の解決を依頼し、問題を訂正した後にデプロイメント・マネージャーを再始動してください。

addNode コマンドが失敗する

このエラーは、 デプロイメント・マネージャーのドメイン・ネーム・サーバー (DNS) 構成が適切にセットアップされていない場合に、発生することがあります。 Linux システムにおけるデフォルトのインストールでは、ループバック・アドレス (127.0.0.1) をデフォルトのホスト・アドレスとして使用します。 この問題を検査するには、疑いのあるマシンのホスト名を照会します。 照会によってローカル・ホスト 127.0.0.1 が戻された場合、またはノードでのファイル転送トレースに、ノードが 127.0.0.1 を含む Web アドレスにファイルをアップロードしようとしていることが示されている場合は、ノードの DNS 構成が正しくありません。

この問題を訂正するには、 /etc/hosts ファイルまたはネーム・サービス構成ファイル /etc/nsswitch.conf を、 ドメイン・ネーム・サーバーまたは Network Information Server (NIS) に照会してからホストを検索するように更新します。

アプリケーション・ファイルが一部のノードにしか存在しない。

WebSphere Application Server Network Deployment 環境では、 アプリケーション・バイナリー・ファイルは、 アプリケーションがノードの同期操作の一部としてサポートされている個別のノードに転送されます。 ノードの同期の際、アプリケーション・ファイルは、 デプロイメント記述子で enableDistribution=true が指定されている場合に限って伝搬されます。 このフラグはアプリケーション・インストール手順の一部として管理コンソールで指定され、 プロパティーとして app_server_root/config/cells/cell_name/applications/application_name/deployment.xml ファイルに保管されます。

この問題を確認するには、enableDistribution フラグが設定されているかどうかを確認します。 既に true に設定されている場合は、自動ファイル同期を実行するようにターゲット・ノードを構成します。

これらの設定が両方とも正しいにも関わらず問題が解決しない場合は、同期を手動で実行してください。 それでもアプリケーション・ファイルがインストール・ディレクトリーに表示されない場合は、 EARExpander ツール (app_server_root/bin ディレクトリーにある) を使用して、EAR ファイルをリポジトリーからインストール先に展開します。 リモート・ノードで、リポジトリーが config/cells/cell_name/applications/application_name.ear/ ディレクトリーに表示されます。

システムに Network Deployment プラグインをダウンロードした後、サーバーが始動しない

この状態が起きた場合、原因として最も可能性が高いのは、 プラグイン内のトランスポート・パスをユーザーの環境で動作するように変更する必要があるということです。 これらの設定を変更する方法については、 例: server.xml ファイルの転送設定を手動で編集するのトピックを参照してください。

クラスター環境で、 デバッグ・モードを使用可能にしたサーバーが始動しない

この問題は、 以下の 3 つの条件が該当する場合に発生します。
  • 複数のサーバー・プロセスが同一ノード上で実行されるように構成されている
  • 複数のサーバーでデバッグ・モードが使用可能になっている
  • 複数のサーバーでデバッグ引数がデフォルト値のままになっているため、 ノード内の複数のサーバーが同じデバッグ・ポート (ポート番号 7777) を使用しようとする

サーバーが始動しないのは、 同一の物理ホスト・マシン上でデバッグを使用可能にして実行する複数のプロセスで、 同じデバッグ・ポートを使用することはできないためです。

この問題を解決するには、各サーバーごとに次の手順を実行します。
  1. 管理コンソールで、「サーバー」>「アプリケーション・サーバー」>「server_name」>「Java およびプロセス管理」>「プロセス定義」>「Java 仮想マシン」と選択します。
  2. デバッグ引数を更新して、デバッグ・ポートのアドレス (address=port number) がサーバー・プロセスごとに固有であるようにします。



関連タスク
トラブルシューティング管理
関連資料
分散されないワークロード
ワークロード管理コンポーネントのトラブルシューティングのヒント
参照トピック    

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

最終更新: Jan 21, 2008 9:12:22 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/rtrb_multprobs.html