14 一般的な問題のトラブルシューティング

この章では、クラスタに関連する問題の発生を防ぎ、また問題が起きた場合にそれに対処するためのガイドラインを示します。

IPマルチキャスト構成の問題のトラブルシューティングについては、「マルチキャスト構成のトラブルシューティング」を参照してください。

この章には、次の項が含まれます。

クラスタを起動する前に

クラスタを起動する前に、問題を防止するためにできることがいくつかあります。

サーバーのバージョン番号のチェック

安定した状態の操作では、クラスタ内のすべてのサーバーが同じメンテナンス・レベル(メジャーおよびマイナー・バージョン番号、パッチ・セット番号、パッチ・セット更新番号、および仮パッチ/個別パッチがすべて同じ)である必要があります。WebLogic Serverでは、次を目的としたローリング・アップグレード(クラスタ内のサーバーへの保守の順次適用)がサポートされています。

仮パッチ/個別パッチの適用
パッチ・セット更新(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にお問い合わせになる前に、診断情報を収集してください。最も重要な情報は、管理対象サーバーからの複数のスレッド・ダンプが出力されたログ・ファイルです。ログ・ファイルは特に、クラスタのフリーズやデッドロックを診断する場合に重要です。

複数のスレッド・ダンプが出力されたログ・ファイルは、問題を診断するための前提条件となります。

サーバーを停止します。
この時点でログ・ファイルがあればすべて削除するか、バックアップします。既存のログ・ファイルに追加書込みを行うよりも、サーバーを起動するたびに新しいログ・ファイルを作成することをお薦めします。
次のコマンドでサーバーを起動します - このコマンドは、詳細ガベージ・コレクションを有効化し、標準エラーと標準出力の両方をログ・ファイルにリダイレクトします。
```
% java -ms64m -mx64m -verbose:gc -classpath $CLASSPATH
	-Dweblogic.domain=mydomain -Dweblogic.Name=clusterServer1
	-Djava.security.policy==$WL_HOME/lib/weblogic.policy
	-Dweblogic.admin.host=192.168.0.101:7001
	 weblogic.Server >> logfile.txt
```
標準エラーと標準出力の両方をリダイレクトすることにより、サーバーの通知メッセージとエラー・メッセージを含む、適切なコンテキストのスレッド・ダンプ情報が得られ、問題を解析しやすくなります。
問題が再発生するまで、クラスタの実行を継続します。
サーバーがハングした場合は、kill -3コマンドまたは[Ctrl]-[Break]を使用して、問題を診断するために必要なスレッド・ダンプを作成します。デッドロックの診断を行うには、この作業を各サーバーに対して、約5 - 10秒間隔で何度か行うようにしてください。
UNIXユーティリティを使用してログ・ファイルを圧縮します。
```
% tar czf logfile.tar logfile.txt
```
または、Windowsのzipユーティリティを使用して圧縮します。
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ユーティリティの使用に関する項を参照してください。