このトピックでは、WebSphere Application Server Network Deployment 製品のインストールのトラブルシューティングを説明します。
WebSphere Application Server の Web サーバー・プラグインのトラブルシューティング情報を 検索する場合は、Web サーバー・プラグインのインストールおよび除去のトラブルシューティング を参照してください。このトピックでは、プラグインについては説明しません。
このトピックは、WebSphere Application Server 製品のインストール後に使用します。
インストールが正常に行われなかった場合は、このトラブルシューティング情報を使用して 問題を訂正してください。
インストールが正常に行われなかったとき、このトピックを使用してログ・ファイルを解釈し、考えられる問題を診断する助けとします。
詳しくは、インストール済みファイルのチェックサムの検査 を参照してください。
installver コマンドからの出力を、次のステップで説明されるインストール・ログ・ファイルと比較します。
インストールおよびプロファイル作成状況は、app_server_root/logs/install/log.txt ファイル、app_server_root/logs/manageprofiles/profile_name_create.log ファイル、および profile_root/logs/pctLog.txt ファイルに 記録されます。
インストールの初期にエラーが発生した場合は、システム一時領域の log.txt ファイルを探します。 インストール・プログラムは、インストールの最後に一時領域から logs ディレクトリーにログをコピーします。
インストール中、app_server_root/logs/install/log.txt ファイルの単一エントリーが、 一時ログ・ファイル (Windows プラットフォームの場合は %TEMP%¥log.txt、AIX または Linux などの プラットフォームの場合は /tmp/log.txt) を指します。 インストール・プログラムは、インストールの最後に、 このファイルを一時ディレクトリーから app_server_root/logs/install/log.txt ロケーションにコピーします。
インストールが失敗し、log.txt ファイルに 一時ディレクトリーに対するこの 1 つのポインターしかない場合は、 一時ディレクトリーの log.txt ファイルを開きます。 このログに、インストールの失敗についての手掛かりが含まれる場合があります。
アンインストールによって、app_server_root/logs/uninstall/log.txt ファイルが作成されます。
InstallShield MultiPlatform (ISMP) によって インストール・ウィザードが開始されない場合は、ログに情報が記録されます。
install -options fully_qualified_options_response_file_name -silent -log # !fully_qualified_log_file_name @ALL
install -options "/usr/IBM/WebSphere/silentFiles/myresponsefile.txt" -silent -log # !/usr/IBM/WebSphere/myOptionFiles/log.txt @ALL
install -options "/opt/IBM/WebSphere/silentFiles/myresponsefile.txt" -silent -log # !/opt/IBM/WebSphere/myOptionFiles/log.txt @ALL
install.exe -options "C:¥IBM¥WebSphere¥silentFiles¥myresponsefile.txt" -silent -log # !C:¥IBM¥WebSphere¥silentFiles¥log.txt @ALL
以下の例は、デプロイメント・マネージャー・プロファイルを 作成する際の -log パラメーターの使用方法を示しています。
./pctAIX.bin -options /usr/IBM/WebSphere/silentFiles/responsefile.pct.NDstandAloneProfile.txt -silent -log !/usr/IBM/WebSphere/silentFiles/pctlog.txt @ALL
./pctLinux.bin -options /opt/IBM/WebSphere/silentFiles/responsefile.pct.NDstandAloneProfile.txt -silent -log # !/opt/IBM/WebSphere/silentFiles/log.txt @ALL
pctWindows.exe -options "C:¥IBM¥WebSphere¥silentFiles¥responsefile.pct.NDstandAloneProfile.txt" -silent -log # !C:¥IBM¥WebSphere¥silentFiles¥log.txt @ALL
ログ・ファイルの 名前と位置
以下の情報は、製品ディスク上のインストール可能なすべてのコンポーネントのログ・ファイルを示します。
IBM HTTP Server のログ・ファイル
Windows システムのログ・パス名 | AIX または Linux などの オペレーティング・システムのログ・パス名 |
---|---|
|
|
Application Client for WebSphere Application Server のログ・ファイル
Windows システムのログ・パス名 | AIX または Linux などのシステムの オペレーティング・システム・ログ・パス名 |
---|---|
|
|
ログ (Log) | 内容 | インディケーター |
---|---|---|
app_server_root /logs/install/log.txt | すべてのインストール・イベントを記録します。 |
|
app_server_root/logs/wasprofiles/wasprofile_create_profile_name.log |
|
|
app_server_root/logs/install/ installconfig.log.gz |
|
|
profile_name_create.log ファイルの説明
profile_name_create.log ファイルは、 最後のプロファイルの作成時に発生するイベントのレコードが含まれる XML ファイルです。
<record> <date>2004-09-08T11:51:39</date> <millis>1094658699225</millis> <sequence>0</sequence> <logger>com.ibm.ws.profile.WSProfile</logger> <level>INFO</level> <class>com.ibm.ws.profile.WSProfile</class> <method>getRegistryFile</method> <thread>10</thread> <message>Returning registry file at: C:¥IBM¥WebSphere¥AppServer¥properties¥profileRegistry.xml </message> </record>
アプリケーション・サーバー・プロファイルの作成時に作成されるログ・ファイル
コア・プロダクト・ファイル内で作成されるログに加えて、 次のログが profile_root/logs ディレクトリーに作成されます。
アプリケーション・サーバー・プロファイルを作成するときに、 プロファイル管理ツール および manageprofiles コマンドの両方によって、 ログが作成されます。
このログは、 manageprofiles コマンドを直接使用する場合には 作成されません。
このログは、製品のインストール時には作成されません。
WebSphere Application Server の Web サーバー・プラグインのログ・ファイル
ログ・ファイルの説明およびその他のトラブルシューティング情報については、Web サーバー・プラグインのインストールおよび除去のトラブルシューティング を参照してください。
app_server_root/logs/instconfig.log ファイルには、 製品の正常動作を妨げる可能性のある ANT 構成の問題が表示されています。 AIX または Linux などのシステムの場合、このログ・ファイルは存在しません。
ANT スクリプトの問題を手動で診断し、修正する方法については、 失敗した ANT 構成スクリプトの診断 を参照してください。
IBM サポートはカスタマーのための作業をキューに入れ、テストまたはデバッグ修正を提供する場合があります。 修正用の共通ロケーションは、app_server_root/classes ディレクトリーです。
デフォルトでは、app_server_root/classes ディレクトリーが最初に WebSphere Application Server クラスパスで選択され、他のクラスをオーバーライドします。
このディレクトリーに修正を置くことにより、 ユーザーは、修正が問題を実際に解決するかどうかを検査できます。 修正が問題を解決することを検査したら、app_server_root/classes ディレクトリーから修正を削除して、システムを作業状態に戻します。
app_server_root/classes ディレクトリーからこのような修正を除去しない場合は、 エラーが発生することがあります。
install -is:javaconsole
install -is:javaconsole > captureFileName.txt 2>&1
install.exe -is:javaconsole
install -is:javaconsole > drive:¥captureFileName.txt
install -W Setup.product.install.logAllEvents="true"
install -W Setup.product.install.logAllEvents="true"
Java プロセスが存在せず、メッセージも記述されていない場合は、 同じログでその他のエラーを検査します。 すべてのエラーを訂正し、再試行します。
「Ctrl+Alt+Delete」 を押し、「T」 を入力して、タスク・マネージャーを開きます。「プロセス」タブおよび
「イメージ名」列見出しをクリックして、イメージ名でソートします。
java.exe という名前のプロセスを探します。
ps -ef | grep java
Java プロセスが存在せず、メッセージも記述されていない場合は、 同じログでその他のエラーを検査します。 エラーを修正し、デプロイメント・マネージャーの始動を再試行します。
ご使用のアプリケーション・サーバーおよび Web サーバーを 開始し、IP アドレスとスヌープ・サーブレットを使用して、ご使用の環境をテストします。
コマンド・ウィンドウを使用して、IBM HTTP Server のインストール済みイメージ、 またはユーザーの Web サーバーのインストール済みイメージに移動します。 IBM HTTP Server に適切なコマンドを実行して、Web サーバーを始動します。 コマンドの例を以下に示します。
IBM HTTP Server をコマンド行から始動する方法は、以下のとおりです。
HTTP トランスポート・ポートはデフォルトで 9080 であり、 すべてのプロファイルで固有でなければなりません。このポートは、default_host という名前の仮想ホストと関連し、 その仮想ホストは、インストール済みの DefaultApplication およびインストール済みサンプルをホストするよう構成されています。 スヌープ・サーブレットは、DefaultApplication の一部です。ポートを変更して、 実際の HTTP トランスポート・ポートに一致させます。
どちらかの Web アドレスで 「Snoop Servlet - Request/Client Information」ページが表示されるはずです。
以下のステップを使用することによって、 自動伝搬機能がリモート IBM HTTP Server に対して動作することを確認します。 この手順は、ローカル Web サーバーでは必須ではありません。
「Could not connect to IHS Administration server error」
HTTP Admin ポートはデフォルトで 9060 であり、各スタンドアロン・アプリケーション・サーバーの管理コンソールに対して 固有でなければなりません。このポートは、admin_host という名前の仮想ホストと関連し、 その仮想ホストは、システム・アプリケーションとしてデフォルトでインストールされる 管理コンソールをホストするよう構成されています。 このポートを、実際の HTTP Admin ポートと一致するように変更します。
インストール後、 管理コンソールにアクセスする際に問題が発生した場合は、installAdminConsole.log ファイルで障害の原因を確認してください。 システムの一時ディレクトリーをクリーンアップし、wsadmin スクリプト機能を 使用して管理コンソールを再インストールします。
サーバーが始動します。管理コンソールが始動します。管理コンソールには、 ブラウザーを介してアクセスできます。 管理コンソールがログインを受け入れます。
「システム管理」 >「ノード」>「ノードの追加」 をクリックして、ウィザードに従います。アプリケーション・サーバーの デフォルトの SOAP ポートは 8880 です。アプリケーション・サーバーが同一マシン上にある場合は、 「ホスト名」フィールドの値として localhost を使用することができます。
ツール情報はファイルに記録されています。 profile_root¥logs¥addNode.log localhost:8879 で、ノード AppServer01 とデプロイメント・マネージャーの統合を開始します。 デプロイメント・マネージャー・サーバー localhost に正常に接続しました: 8879 構成でサーバーが検出されました: サーバー名: server1 ノード AppServer01 のすべてのサーバー・プロセスを停止します ノードの Node Agent 構成を作成します: AppServer01 次のノード・エージェント・プロセスの構成を読み取ります: nodeagent ノード AppServer01 構成を次のセルに追加します: AdvancedDeploymentCell Performing configuration synchronization between node and cell. ノードに対して Node Agent プロセスを立ち上げます: AppServer01 ノード・エージェントが立ち上げられました。初期化状況を待ちます。 ノード・エージェントの初期化は正常に完了しました。プロセス ID: 3012 ノード AppServer01 は正常に統合されました。最後のメッセージは、正常終了の標識です。 2 番目の Java プロセスが実行中で、それはノード・エージェント・プロセスです。 node_name ディレクトリーの stdout.log ファイル および stderr.log ファイルには、 それぞれ関連のあるメッセージが含まれています。
デフォルトでは、 Java 2 SDK がドメイン・ネーム・サービス (DNS) ネーミング・ルックアップ用の IP アドレスをキャッシュに入れます。 ホスト名が正常に解決されると、IP アドレスはキャッシュにとどまります。 デフォルトでは、キャッシュ・エントリーはいつまでも残ります。
このデフォルトの IP キャッシング・メカニズムが、以下の問題シナリオが示すように、 問題を引き起こす場合があります。
問題例 1
host1.ibm.com のアプリケーション・サーバーの初期 IP アドレスが 1.2.3.4 であるとします。 host2.ibm.com のクライアントが host1.ibm.com の DNS ルックアップを実施すると、 クライアントがアドレス 1.2.3.4 をキャッシュに保管します。それ以後の DNS 名ルックアップでは、キャッシュされた値である 1.2.3.4 が戻されます。
キャッシュされた値は、host1.ibm.com の IP アドレスが、例えば 5.6.7.8 に変更されるまでは、問題とはなりません。 host2.ibm.com のクライアントは現在の IP アドレスを取得するのではなく、 常に、キャッシュに入っている以前のアドレスを取得します。
そうなると、クライアント・プロセスを停止して再始動するまでは、クライアントは host1.ibm.com に到達できません。
問題例 2
host1.ibm.com のアプリケーション・サーバーの初期 IP アドレスが 1.2.4.5 であるとします。アプリケーション・サーバーの IP アドレスが変わらなくても、ネットワークの障害により、キャッシュ内の IP アドレスとして例外コードが記録されることがあります。この例外コードは、クライアントが稼働中のネットワーク上で再始動するまで、キャッシュ内にとどまります。
例えば、host2.ibm.com のクライアントがケーブルが抜けたためにネットワークから切り離された場合、 host1.ibm.com のアプリケーション・サーバーの切断ルックアップは失敗します。 この失敗により、IBM Developer Kit が、IP アドレス・キャッシュに特別な例外コード・ エントリーを書き込みます。
それ以後の DNS 名ルックアップでは、例外コード java.net.UnknownHostException が戻されます。
IP アドレス・キャッシングと WebSphere Application Server プロセスの ディスカバリー
統合された WebSphere Application Server ノード の IP アドレスを変更した場合、他のノードで実行中のプロセスは、 いったん停止して再始動するまでは、変更したノードに接続できません。
接続を切断したノード上でデプロイメント・マネージャー・プロセスを始動する場合、そのデプロイメント・マネージャー・プロセスは、停止して再始動するまではセル・メンバー・プロセスと通信できません。 例えば、ネットワーク・ケーブルが抜けた場合、それをもう一度接続しても、デプロイメント・マネージャー・プロセスを再始動するまでは、IP キャッシュに適切なアドレスが復元されることはありません。
IP アドレス・キャッシュ設定の使用
デプロイメント・マネージャー・プロセスは、いつでも停止および再始動して、その IP アドレスのキャッシュを更新することができます。 ただし、このプロセスは場合によっては不経済で不適切です。
networkaddress.cache.ttl (public、JDK1.4) パラメーターおよび sun.net.inetaddr.ttl (private、JDK1.3) パラメーターは、IP キャッシングを制御します。この値は、IP アドレスをキャッシュに入れておく秒数を指定する整数です。 デフォルト値の -1 は、キャッシュを永続的に保持することを意味します。 値ゼロ (0) は、キャッシュに入れないという指定です。
値ゼロ (0) の使用は、通常の運用ではお勧めしません。 ネットワーク障害の兆候がなく、IP アドレス変更の予定もない場合は、キャッシュを永続的に保持する設定を使用してください。 キャッシング設定をまったく使用しないと、DNS スプーフィング・アタックを受ける恐れがあります。
Java 2 SDK の詳細
Java 2 Platform Standard Edition (J2SE) 1.4.2 の Web サイト および Java 2 Platform Standard Edition (J2SE) 1.5 の Web サイト で説明されている private sun.net.inetaddr.ttl プロパティー は、J2SE 1.4.2 (WebSphere Application Server バージョン 5.1 および バージョン 6.0) および J2SE 1.5 (WebSphere Application Server バージョン 6.1) の両方で動作します。
インストール・ウィザードの prereqChecker プログラムは、そのファイルを使用し、オペレーティング・システムのバージョンを確認します。 オリジナル・バージョンを復元できない場合は、サポートされていないオ ペレーティング・システムに関するオペレーティング・システム・レベル・チェックのメッセージを無視してください。 警告が表示されても、インストールは正常に継続されます。
この手順の結果、インストール中に発生する可能性のあるエラーをデバッグします。
デバッグおよびレポートについての説明の詳細は、インストールの問題 を参照してください。 インストールのトラブルシューティングについての詳細は、インストール・コンポーネントのトラブルシューティングのヒント を参照してください。
IBM サポートから入手可能な既知の問題およびその解決法に関する最新の情報については、IBM サポート・ページを参照してください。
IBM サポートが提供する資料を参照すれば、 問題を解決するために必要な情報を集める時間を短縮することができます。 PMR を開く前に、IBM サポート・ページを参照してください。