| Oracle Fusion Middleware Oracle WebLogic Server クラスタの使い方 11g リリース 1 (10.3.1) B55518-01 |
|
 戻る |
 次へ |
この章では、クラスタに関連する問題の発生を防ぎ、また問題が起きた場合にそれに対処するためのガイドラインを示します。
IP マルチキャスト コンフィグレーションの問題のトラブルシューティングについては、「マルチキャスト コンフィグレーションのトラブルシューティング」を参照してください。
クラスタ内のすべてのサーバは、メジャー バージョン番号が同じでなければなりません。ただし、マイナー バージョン番号とサービス パックは異なっていてもかまいません。
クラスタの管理サーバは通常クラスタ メンバーとしてコンフィグレーションされませんが、管理対象サーバで使用されるものと同じメジャー バージョン番号の 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 インタプリタ コマンドなどの入力間違いをチェックします。
クラスタ関連の問題について 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 サポート担当者宛の電子メールに、圧縮したログ ファイルを添付します。メールの本文にログ ファイルの内容を切り取って貼り付けないでください。
Linux で JRockit JVM を使用する場合は、以下のいずれかの方法でスレッド ダンプを生成します。
weblogic.admin THREAD_DUMP コマンドを使用する。
JVM の管理サーバが有効になっている場合は (-Xmanagement オプションで起動)、JRockit の管理コンソールでスレッド ダンプを生成できる。
Kill -3 PID を使用する。PID はプロセス ツリーのルートです。
ルート PID を取得するには、次のコマンドを実行します。
ps -efHl | grep 'java' **. **
サーバ起動コマンドと一致するプロセス スタックで見つかる文字列と同じ grep 引数を使用します。報告される最初の PID はルート プロセスです。その際、ps コマンドは別のルーチンにパイプされていないものと見なされます。
Linux において、各実行スレッドは Linux プロセス スタックで独立したプロセスとして扱われます。Linux で Kill -3 を使用する場合は、メインの WebLogic 実行スレッドの PID と一致させる必要があり、一致しない場合はスレッド ダンプは生成されません。
クラスタで問題が発生している場合、管理対象サーバ上でガベージ コレクションをチェックすることもお勧めします。ガベージ コレクションに時間がかかりすぎる場合、サーバが使用可能であることを他のクラスタ メンバーに通知する定期的なハートビート シグナルをサーバから出すことができなくなります。
ガベージ コレクション (最初または 2 番目の世代) が 10 秒以上かかる場合、システム上のヒープ割り当て (msmx パラメータ) を調整する必要があります。
マルチキャストが機能しているかどうかは、管理対象サーバの 1 つから utils.MulticastTest を実行することで検証できます。『Oracle Fusion Middleware Oracle WebLogic Server コマンド リファレンス』の「Oracle WebLogic Server Java ユーティリティの使い方」を参照してください。
