|
|
この章では、クラスタに関連する問題の発生を防ぎ、また問題が起きた場合にそれに対処するためのガイドラインを示します。
クラスタを起動する前に、問題を避けるためのいくつかの確認を行うことができます。
WebLogic Server のライセンスにクラスタ化機能が含まれている必要があります。クラスタ化ライセンスがない状態でクラスタを起動しようとすると、「Unable to find a license for clustering」というエラー メッセージが表示されます。
クラスタ内のすべてのサーバは、メジャー バージョン番号が同じでなければなりません。ただし、マイナー バージョン番号とサービス パックは異なっていてもかまいません。
クラスタの管理サーバは通常クラスタ メンバーとしてコンフィグレーションされませんが、管理対象サーバで使用されるものと同じメジャー バージョン番号の WebLogic Server を実行する必要があります。
マルチキャスト アドレスに関する問題は、クラスタが起動しないか、またはサーバがクラスタに参加できないことの最も一般的な理由の 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\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 の設定内容を変更する場合、クラスタ内のすべての管理対象サーバで同じ変更を行う必要があります。
クラスタ内の各サーバ インスタンスには、固定数の実行スレッドでコンフィグレーションされたデフォルトの実行キューがあります。デフォルト実行キューのスレッド カウントを参照するには、サーバの [コンフィグレーション｜全般] タブの [詳細] オプション部分で [Configure Execute Queue] コマンドを選択します。デフォルト キューのデフォルト スレッド カウントは 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
標準エラーと標準出力の両方をリダイレクトすることにより、サーバの通知メッセージとエラー メッセージを含む、適切なコンテキストのスレッド ダンプ情報が得られ、問題を解析しやすくなります。
kill -3 コマンドまたは〔Ctrl〕-〔Break〕を使用して、問題を診断するために必要なスレッド ダンプを作成します。デッドロックの診断を行うには、この作業を各サーバに対して、約 5 ～ 10 秒間隔で何度か行うようにしてください。| 注意 : | Linux で JRockit JVM を実行している場合は、「Linux 上で JRockit スレッド ダンプを取得する」を参照してください。 |
% tar czf logfile.tar logfile.txt
または、Windows の zip ユーティリティを使用して圧縮します。
Linux で JRockit JVM を使用する場合は、以下のいずれかの方法でスレッド ダンプを生成します。
weblogic.admin THREAD_DUMP コマンドを使用する。-Xmanagement オプションで起動)、JRockit の管理コンソールでスレッド ダンプを生成できる。 Kill -3 PID を使用する。PID はプロセス ツリーのルートです。
サーバ起動コマンドと一致するプロセス スタックで見つかる文字列と同じ grep 引数を使用します。報告される最初の PID はルート プロセスです。その際、ps コマンドは別のルーチンにパイプされていないものと見なされます。
Linux において、各実行スレッドは Linux プロセス スタックで独立したプロセスとして扱われます。Linux で Kill -3 を使用する場合は、メインの WebLogic 実行スレッドの PID と一致させる必要があり、一致しない場合はスレッド ダンプは生成されません。
クラスタで問題が発生している場合、管理対象サーバ上でガベージ コレクションをチェックすることもお勧めします。ガベージ コレクションに時間がかかりすぎる場合、サーバが使用可能であることを他のクラスタ メンバーに通知する定期的なハートビート シグナルをサーバから出すことができなくなります。
ガベージ コレクション (最初または 2 番目の世代) が 10 秒以上かかる場合、システム上のヒープ割り当て (msmx パラメータ) を調整する必要があります。
マルチキャストが機能しているかどうかは、管理対象サーバの 1 つから utils.MulticastTest を実行することで検証できます。『WebLogic Server コマンド リファレンス』の「WebLogic Server Java ユーティリティの使い方」を参照してください。
マルチキャストの実行に問題がある場合は、「マルチキャストのデバッグ」を参照してください。
クラスタ内のマルチキャストに関するトラブルシューティングの詳細については、「マルチキャスト コンフィグレーションのトラブルシューティング」を参照してください。
  
|
