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

この節では、クラスタに関連する問題の発生を防ぎ、問題に対処するためのガイドラインを示します。

• クラスタを起動する前に

• クラスタ起動後の作業

 

---

クラスタを起動する前に

クラスタを起動する前に、問題を避けるためのいくつかの確認を行うことができます。

クラスタ ライセンスのチェック

WebLogic Server のライセンスにクラスタ化機能が含まれている必要があります。クラスタ化ライセンスがない状態でクラスタを起動しようとすると、「Unable to find a license for clustering」というエラー メッセージが表示されます。

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

クラスタ内のすべての管理対象サーバとクラスタの管理サーバは、WebLogic Server の同じバージョンで実行する必要があります。 メジャーおよびマイナー バージョン番号 (6.1 など)、サービス パック、および適用されたパッチのレベルがクラスタ全体で同じでなければなりません。

マルチキャスト アドレスのチェック

マルチキャスト アドレスに関する問題は、クラスタが起動しないか、またはサーバがクラスタに参加できないことの最も一般的な理由の 1 つです。

マルチキャスト アドレスはクラスタごとに必要です。マルチキャスト アドレスには 224.0.0.0 〜 239.255.255.255 の範囲の IP アドレスか、またはその範囲内の IP アドレスを持つホスト名を使用できます。

クラスタのマルチキャスト アドレスとポートは、WebLogic Server コンソールを使用してチェックできます。

ネットワーク上の各クラスタで、マルチキャスト アドレスとポートの組み合わせはユニークでなければなりません。ネットワーク上の 2 つのクラスタで同じマルチキャスト アドレスを使用する場合、それぞれのクラスタのポートは異なっている必要があります。複数のクラスタでマルチキャスト アドレスが異なっていれば、それらのクラスタで同じポートまたはデフォルトの 7001 番ポートを使用できます。

クラスタを起動する前に、クラスタのマルチキャスト アドレスとポートが正しいことと、ネットワーク上の他のクラスタとの間でマルチキャスト アドレスとポートの組み合わせが重複していないことを確認してください。

マルチキャスト アドレスが不正な場合に最も起こりやすいエラーには、以下のものがあります。

• クラスタ化のためのマルチキャスト ソケットを作成できない

• マルチキャスト ソケットの送信エラー

• マルチキャスト ソケットの受信エラー

CLASSPATH の値のチェック

CLASSPATH の値が、クラスタ内のすべての管理対象サーバ間で一致していることを確認します。CLASSPATH は setEnv スクリプトによって設定されます。このスクリプトは、startManagedWebLogic を実行して管理対象サーバを起動する前に実行します。

デフォルトでは、setEnv は CLASSPATH の値を次のように設定します (Windows システム上での表現形式)。

set WL_HOME=C:¥bea¥weblogic700
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 の設定内容を変更する場合、クラスタ内のすべての管理対象サーバで同じ変更を行う必要があります。

スレッド カウントのチェック

クラスタ内の各サーバには実行スレッド カウントが割り当てられます。 このカウントは Administration Console からチェックできます ([サーバ｜ (対象のサーバ名) ｜モニタ｜すべてのアクティブなキューのモニタ｜Execute Queue のコンフィグレーション] をクリックし、次にサーバ リスト内の default をクリックします)。

管理対象サーバを起動する前に、そのスレッド カウント属性をチェックします。デフォルト値は 15 であり、最小値は 5 です。スレッド カウントの値が 5 未満の場合、管理対象サーバが起動時にハングしないように値を 5 以上に変更します。

 

---

クラスタ起動後の作業

この節では、クラスタを起動する際に問題が発生した場合に、最初に実行するトラブルシューティングの手順について説明します。

コマンドのチェック

クラスタが起動できないかまたはサーバがクラスタに参加できない場合は、まず最初に、startManagedWebLogic コマンドや java インタプリタ コマンドなどの入力間違いをチェックします。

このリリースでは、システム名とパスワードに weblogic を使用してサーバが起動する点に注意してください。

ログ ファイルの生成

クラスタ関連の問題について BEA テクニカル サポートにお問い合わせになる前に、いくつかの診断情報を収集する必要があります。最も必要な情報は、管理対象サーバからの複数のスレッド ダンプが出力されたログ ファイルです。ログ ファイルは特に、クラスタのフリーズやデッドロックの問題に対処する場合に重要です。

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

ログ ファイルを作成するには、管理サーバまたは管理対象サーバ上で次の手順に従います。

1. サーバを停止します。

2. この時点でログ ファイルがあればすべて削除するか、バックアップします。既存のログ ファイルに追加書き込みを行うよりも、サーバを起動するたびに新しいログ ファイルを作成することをお勧めします。

3. 次のコマンドでサーバを起動します。 このコマンドでは冗長ガベージ コレクションを有効にし、標準エラーと標準出力の両方をログ ファイルにリダイレクトします。

   % 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 2>&1

注意: 構文は、UNIX と NT の両方で似ています。このコマンドでは、logfile.txt が上書きされます。上書きではなく追加にするには、最初の「>」を「>>」に変えます。

標準エラーと標準出力の両方をリダイレクトすることにより、サーバの通知メッセージとエラー メッセージを含む、適切なコンテキストのスレッド ダンプ情報が得られ、問題を解析しやすくなります。

4. 問題が再発生するまで、クラスタの実行を継続します。

5. サーバがハングした場合は、kill -3 コマンドまたは <Ctrl>-<Break> を使用して、問題を診断するために必要なスレッド ダンプを作成します。デッドロックの診断を行うには、この作業を各サーバに対して、約 5 〜 10 秒間隔で何度か行うようにしてください。

注意: Linux 環境で JRockit JVM を実行している場合は、Linux 環境での JRockit スレッド ダンプの取得を参照してください。

6. UNIX ユーティリティを使用してログ ファイルを圧縮します。

   % tar czf logfile.tar logfile.txt

   または、Windows の zip ユーティリティを使用して圧縮します。

7. BEA テクニカル サポート担当者宛の電子メールに、圧縮したログ ファイルを添付します。メールの本文にログ ファイルの内容を切り取って貼り付けないでください。

8. 圧縮してもログ ファイルのサイズがまだ大きすぎる場合、BEA カスタマ サポート FTP サイトを使用できます。

Linux 環境での JRockit スレッド ダンプの取得

Linux 環境で JRockit JVM を使用する場合、以下のいずれかの方法でスレッド ダンプを生成できます。

• weblogic.admin THREAD_DUMP コマンドを使用する。 手順と制限については、『管理者ガイド』の「THREAD_DUMP」を参照してください。

• -Xmanagement オプションで JVM を起動して JVM の管理サーバが有効になっている場合、JRockit Management Console を使用してスレッド ダンプを生成できる。

• Kill -3 PID を使用する。PID はプロセス ツリーのルートです。

  ルート PID を取得するには、次のコマンドを実行します。

  ps -efHl | grep 'java' **. **

  grep の文字列引数には、プロセス スタック内でサーバの起動コマンドと一致する文字列を使用します。 ps コマンドを別のルーチンにパイプしていなければ、出力された最初の PID がルート プロセスとなります。

  Linux 環境では、各実行スレッドが Linux プロセス スタック下の独立したプロセスとして表示されます。 Linux 上で Kill -3 を使用する場合、指定する PID が、WebLogic のメイン実行スレッドの PID と一致しなければなりません。一致していないと、スレッド ダンプは生成されません。

ガベージ コレクションのチェック

クラスタで問題が発生している場合、管理対象サーバ上でガベージ コレクションをチェックすることもお勧めします。ガベージ コレクションに時間がかかりすぎる場合、サーバが使用可能であることを他のクラスタ メンバーに通知する定期的なハートビート シグナルをサーバから出すことができなくなります。

ガベージ コレクション (最初または 2 番目の世代) が 10 秒以上かかる場合、システム上のヒープ割り当て (msmx パラメータ) を調整する必要があります。

utils.MulticastTest の実行

いずれかの管理対象サーバから utils.MulticastTest を実行することにより、マルチキャストが機能していることを検証できます。