14 一般的な問題のトラブルシューティング
ガイドラインを学んで、Oracle WebLogic Serverクラスタの問題を防止し、発生した場合にトラブルシューティングします。
IPマルチキャスト構成の問題をトラブルシューティングする方法の詳細、「マルチキャスト構成のトラブルシューティング」を参照してください。
この章の内容は次のとおりです。
- クラスタを起動する前に
クラスタを起動する前に、問題を回避するために次のチェックを行います。 - クラスタ起動後の作業
クラスタの起動後は、次の方法を使用して問題をトラブルシューティングできます。
クラスタを起動する前に
クラスタを起動する前に、問題を回避するために次のチェックを行います。
サーバーのバージョン番号のチェック
- メジャー・バージョン番号とマイナー・バージョン番号が同じ
- パッチ・セット番号が同じ
- パッチ・セット更新番号が同じ
- 暫定/個別パッチが同じ
- 暫定/個別パッチ
- パッチ・セット更新(PSU)
- WebLogic Server 10.3.xパッチ・セット。たとえば、WebLogic Server 10.3.5から10.3.6へのローリング・アップグレードを実行します。
通常、クラスタの管理サーバーはクラスタ・メンバーとして構成されませんが、一般には管理対象サーバーと同じ保守レベルを実行する必要があります。場合によっては、管理サーバーが、単一ドメイン内の異なるメンテナンス・レベルの複数クラスタを管理していることがあります。この場合、管理サーバーは、ドメイン内の管理対象サーバーの最も高いメンテナンス・レベルにする必要があります。
親トピック: クラスタを起動する前に
マルチキャスト・アドレスのチェック
マルチキャスト・アドレスに関する問題は、クラスタが起動しないか、またはサーバーがクラスタに参加できないことの最も一般的な理由の1つです。
マルチキャスト・アドレスはクラスタごとに必要です。マルチキャスト・アドレスには224.0.0.0から239.255.255.255までの範囲のIPアドレスか、またはその範囲内のIPアドレスを持つホスト名を使用できます。
WebLogic Server管理コンソールの「構成」→「マルチキャスト」ページで、クラスタのマルチキャスト・アドレスおよびポートを確認します。
ネットワーク上の各クラスタで、マルチキャスト・アドレスとポートの組み合わせは一意でなければなりません。ネットワーク上の2つのクラスタで同じマルチキャスト・アドレスを使用する場合、それぞれのクラスタのポートは異なっている必要があります。クラスタのマルチキャスト・アドレスが異なる場合は、同じポートを使用するか、またはデフォルトのポート(7001
)をそのまま使用することもできます。
クラスタを起動する前に、クラスタのマルチキャスト・アドレスとポートが正しいことと、ネットワーク上の他のクラスタとの間でマルチキャスト・アドレスとポートの組合せが重複していないことを確認してください。
マルチキャスト・アドレスが不正な場合に最も起こりやすいエラーには、次のものがあります。
Unable to create a multicast socket for clustering Multicast socket send error Multicast socket receive error
親トピック: クラスタを起動する前に
CLASSPATHの値のチェック
CLASSPATH
の値が、クラスタ内のすべての管理対象サーバー間で一致していることを確認します。CLASSPATH
はsetEnv
スクリプトによって設定されます。このスクリプトは、管理対象サーバーを起動するstartManagedWebLogic
スクリプトの前に実行します。
デフォルトでは、setEnv
はCLASSPATH
の値を次のように設定します(Windowsシステム上での表現形式)。
set WL_HOME=C:\bea\wlserver_10.00 set JAVA_HOME=C:\bea\jdk131 . . set CLASSPATH=%JAVA_HOME%\lib\tools.jar; %WL_HOME%\server\lib\weblogic_sp.jar; %WL_HOME%\server\lib\weblogic.jar; %CLASSPATH%
ある管理対象サーバーでCLASSPATH
の値を変更するか、またはsetEnv
によるCLASSPATH
の設定内容を変更する場合、クラスタ内のすべての管理対象サーバーで同じ変更を行う必要があります。
親トピック: クラスタを起動する前に
クラスタ起動後の作業
クラスタの起動後は、次の方法を使用して問題をトラブルシューティングできます。
コマンドのチェック
クラスタが起動できないかまたはサーバーがクラスタに参加できない場合は、最初のステップは、startManagedWebLogic
のコマンドやjava
インタプリタ・コマンドなどの入力間違いをチェックします。
親トピック: クラスタ起動後の作業
ログ・ファイルの生成
クラスタ関連の問題についてOracleにお問い合わせになる前に、診断情報を収集してください。最も重要な情報は、管理対象サーバーからの複数のスレッド・ダンプが出力されたログ・ファイルです。ログ・ファイルは特に、クラスタのフリーズやデッドロックを診断する場合に重要です。
ノート:
複数のスレッド・ダンプが出力されたログ・ファイルは、問題を診断するための前提条件です。Oracle HotSpot VMスレッド・ダンプの取得
Oracle HotSpot VMを使用する場合は、次のいずれかの方法でスレッド・ダンプを生成します。
-
WLSTの
threadDUMP
コマンドを使用します。 -
jstack
ユーティリティを使用します。 -
LinuxでOracle HotSpot VMを使用している場合は、
Kill -3
PIDを使用します。ここで、PIDは、プロセス・ツリーのルートです。ルートPIDを取得するには、次のコマンドを実行します。
ps -efHl | grep 'java' **. **
grep
の引数として、サーバーの起動コマンドと一致するプロセス・スタック内で見つかる文字列を使用します。報告される最初のPIDはルート・プロセスです。その際、ps
コマンドは別のルーチンにパイプされていないものと見なされます。Linuxでは、各実行スレッドはLinuxプロセス・スタックで独立したプロセスとして扱われます。Linuxで
Kill -3
を使用する場合は、メインのWebLogic実行スレッドのPIDと一致させる必要があります。一致しない場合、スレッド・ダンプは生成されません。 -
WindowsでOracle HotSpot VMを使用している場合は、アプリケーション・コンソールで
Ctrl-Break
コマンドを使用して、スレッド・ダンプを生成できます。
親トピック: ログ・ファイルの生成
ガベージ・コレクションのチェック
クラスタで問題が発生している場合、管理対象サーバー上でガベージ・コレクションを確認することも必要です。ガベージ・コレクションに時間がかかりすぎる場合、サーバーが使用可能であることを他のクラスタ・メンバーに通知する定期的なハートビート・シグナルをサーバーから発行できなくなります。
ガベージ・コレクション(最初または2度目の生成)に10秒以上かかる場合、システム上のヒープ割当て(msmx
パラメータ)を調整する必要があります。
親トピック: クラスタ起動後の作業
utils.MulticastTestの実行
管理対象サーバーの1つからutils.MulticastTest
を実行して、マルチキャストが機能しているかどうかを確認できます。詳細は、『Oracle WebLogic Serverコマンド・リファレンス』の「Oracle WebLogic Server Javaユーティリティの使用」を参照してください。
親トピック: クラスタ起動後の作業