WebLogic Server クラスタ ユーザーズ ガイド
![]() |
![]() |
![]() |
![]() |
この章では、クラスタに関連する問題の発生を防ぎ、また問題が起きた場合にそれに対処するためのガイドラインを示します。
クラスタを起動する前に、問題を避けるためのいくつかの確認を行うことができます。
WebLogic Server のライセンスにクラスタ化機能が含まれている必要があります。クラスタ化ライセンスがない状態でクラスタを起動しようとすると、「Unable to find a license for clustering」というエラー メッセージが表示されます。
クラスタ内のすべての管理対象サーバとクラスタの管理サーバは、同じバージョンの WebLogic Server で実行される必要があります。メジャーならびにマイナー バージョン番号 (例 : 6.1)、サービス パック、およびアタッチされたパッチ レベルがクラスタ全体で同じでなければなりません。
マルチキャスト アドレスに関する問題は、クラスタが起動しないか、またはサーバがクラスタに参加できないことの最も一般的な理由の 1 つです。
マルチキャスト アドレスはクラスタごとに必要です。マルチキャスト アドレスには 224.0.0.0 ~ 239.255.255.255 の範囲の IP アドレスか、またはその範囲内の IP アドレスを持つホスト名を使用できます。
クラスタのマルチキャスト アドレスとポートは、Administration Console の [コンフィグレーション|マルチキャスト] タブで確認できます。
ネットワーク上の各クラスタで、マルチキャスト アドレスとポートの組み合わせはユニークでなければなりません。ネットワーク上の 2 つのクラスタで同じマルチキャスト アドレスを使用する場合、それぞれのクラスタのポートは異なっている必要があります。複数のクラスタでマルチキャスト アドレスが異なっていれば、それらのクラスタで同じポートまたはデフォルトの 7001 番ポートを使用できます。
クラスタを起動する前に、クラスタのマルチキャスト アドレスとポートが正しいことと、ネットワーク上の他のクラスタとの間でマルチキャスト アドレスとポートの組み合わせが重複していないことを確認してください。
マルチキャスト アドレスが不正な場合に最も起こりやすいエラーには、以下のものがあります。
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
の設定内容を変更する場合、クラスタ内のすべての管理対象サーバで同じ変更を行う必要があります。
クラスタ内の各サーバ インスタンスには、固定数の実行スレッドでコンフィグレーションされたデフォルトの実行キューがあります。デフォルト実行キューのスレッド カウントを参照するには、サーバの [コンフィグレーション|全般] タブの [詳細オプション] 部分で [実行キューのコンフィグレーション] コマンドを選択します。デフォルト キューのデフォルト スレッド カウントは 15 であり、最小値は 5 です。スレッド カウントの値が 5 未満の場合、管理対象サーバが起動時にハングしないように値を 5 以上に変更します。
この節では、クラスタを起動しようとして問題が発生した場合に実行すべき、最初のトラブルシューティング手順について説明します。
クラスタが起動できないかまたはサーバがクラスタに参加できない場合は、まず最初に、startManagedWebLogic
のコマンドや java
インタプリタ コマンドなどの入力間違いをチェックします。
クラスタ関連の問題について BEA テクニカル サポートにお問い合わせになる前に、診断情報を収集してください。最も重要な情報は、管理対象サーバからの複数のスレッド ダンプが出力されたログ ファイルです。ログ ファイルは特に、クラスタのフリーズやデッドロックを診断する場合に重要です。
複数のスレッド ダンプが出力されたログ ファイルは、問題を診断するための前提条件となります。
% 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
注意 : Linux で JRockit JVM を実行している場合は、「Linux 上で JRockit スレッド ダンプを取得する」を参照してください。
Linux で JRockit JVM を使用する場合は、以下のいずれかの方法でスレッド ダンプを生成します。
weblogic.admin THREAD_DUMP
コマンドを使用する。手順と制限については、『WebLogic Server コマンド リファレンス』の「THREAD_DUMP」を参照してください。 -Xmanagement
オプションで起動)、JRockit の管理コンソールでスレッド ダンプを生成できる。 Kill -3
PID
を使用する。PID
はプロセス ツリーのルートです。 クラスタで問題が発生している場合、管理対象サーバ上でガベージ コレクションをチェックすることもお勧めします。ガベージ コレクションに時間がかかりすぎる場合、サーバが使用可能であることを他のクラスタ メンバーに通知する定期的なハートビート シグナルをサーバから出すことができなくなります。
ガベージ コレクション (最初または 2 番目の世代) が 10 秒以上かかる場合、システム上のヒープ割り当て (msmx
パラメータ) を調整する必要があります。
マルチキャストが機能しているかどうかは、管理対象サーバの 1 つから utils.MulticastTest
を実行することで検証できます。『WebLogic Server コマンド リファレンス』の「WebLogic Server Java ユーティリティの使い方」を参照してください。
![]() ![]() |
![]() |
![]() |