このトピックでは、WebSphere Application Server Network Deployment 製品のインストールのトラブルシューティングを説明します。
iSeries プラットフォームの WebSphere Application Server 製品のトラブルシューティング情報を 検索する場合は、iSeries インストール・トラブルシューティングのヒント を参照してください。 このトピックでは、i5/OS または OS/400 システムについては説明しません。
このトピックは、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
以下の例は、デプロイメント・マネージャー・プロファイルを 作成する際の -log パラメーターの使用方法を示しています。
ログ・ファイルの 名前と位置
以下の情報は、製品ディスク上のインストール可能なすべてのコンポーネントのログ・ファイルを示します。
IBM HTTP Server のログ・ファイル
Windows システムのログ・パス名 | AIX または Linux などの オペレーティング・システムのログ・パス名 |
---|---|
Application Client for WebSphere Application Server のログ・ファイル
Windows システムのログ・パス名 | AIX または Linux などのシステムの オペレーティング・システム・ログ・パス名 |
---|---|
ログ (Log) | 内容 | インディケーター |
---|---|---|
app_server_root /logs/install/log.txt | すべてのインストール・イベントを記録します。 |
|
user_data_root/profileRegistry/logs/manageprofiles/create.log |
|
|
app_server_root/logs/install/ installconfig.log |
|
|
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 サーバー・プラグインのログ・ファイル
app_server_root/logs/instconfig.log ファイルには、 製品の正常動作を妨げる可能性のある ANT 構成の問題が表示されています。 AIX または Linux などのシステムの場合、このログ・ファイルは存在しません。
IBM サポートはカスタマーのための作業をキューに入れ、テストまたはデバッグ修正を提供する場合があります。 修正用の共通ロケーションは、app_server_root/classes ディレクトリーです。
デフォルトでは、app_server_root/classes ディレクトリーが最初に WebSphere Application Server クラスパスで選択され、他のクラスをオーバーライドします。
このディレクトリーに修正を置くことにより、 ユーザーは、修正が問題を実際に解決するかどうかを検査できます。 修正が問題を解決することを検査したら、app_server_root/classes ディレクトリーから修正を削除して、システムを作業状態に戻します。
app_server_root/classes ディレクトリーからこのような修正を除去しない場合は、 エラーが発生することがあります。
Java プロセスが存在せず、メッセージも記述されていない場合は、 同じログでその他のエラーを検査します。 すべてのエラーを訂正し、再試行します。
Java プロセスが存在せず、メッセージも記述されていない場合は、 同じログでその他のエラーを検査します。 エラーを修正し、デプロイメント・マネージャーの始動を再試行します。
ご使用のアプリケーション・サーバーおよび Web サーバーを 開始し、IP アドレスとスヌープ・サーブレットを使用して、ご使用の環境をテストします。
2001 ページまたは STRTCPSVR SERVER(*HTTP) HTTPSVR(instance_name ) コマンドを使用して、IBM HTTP Server を始動します。
HTTP トランスポート・ポートはデフォルトで 9080 であり、 すべてのプロファイルで固有でなければなりません。このポートは、default_host という名前の仮想ホストと関連し、 その仮想ホストは、インストール済みの DefaultApplication およびインストール済みサンプルをホストするよう構成されています。 スヌープ・サーブレットは、DefaultApplication の一部です。ポートを変更して、 実際の HTTP トランスポート・ポートに一致させます。
どちらかの Web アドレスで 「Snoop Servlet - Request/Client Information」ページが表示されるはずです。
「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) の両方で動作します。
この手順の結果、インストール中に発生する可能性のあるエラーをデバッグします。