| Oracle® Fusion Middleware Oracle WebLogic Serverクラスタの使用 11g リリース1(10.3.6) B60992-04 |
|
 前 |
 次 |
この章では、クラスタに関連する問題の発生を防ぎ、また問題が起きた場合にそれに対処するためのガイドラインを示します。
IPマルチキャスト構成の問題のトラブルシューティングについては、第13章「マルチキャスト構成のトラブルシューティング」を参照してください。
クラスタを起動する前に、問題を防止するためにできることがいくつかあります。
クラスタ内のすべてのサーバーは、メジャー・バージョン番号が同じでなければなりません。ただし、マイナー・バージョン番号とサービス・パックは異なっていてもかまいません。
クラスタの管理サーバーは通常クラスタ・メンバーとして構成されませんが、管理対象サーバーで使用されるものと同じメジャー・バージョン番号のWebLogic Serverを実行する必要があります。
マルチキャスト・アドレスに関する問題は、クラスタが起動しないか、またはサーバーがクラスタに参加できないことの最も一般的な理由の1つです。
マルチキャスト・アドレスはクラスタごとに必要です。マルチキャスト・アドレスには224.0.0.0から239.255.255.255までの範囲のIPアドレスか、またはその範囲内のIPアドレスを持つホスト名を使用できます。
管理コンソールの「構成」>「マルチキャスト」ページでクラスタのマルチキャスト・アドレスとポートを確認できます。
ネットワーク上の各クラスタで、マルチキャスト・アドレスとポートの組み合わせは一意でなければなりません。ネットワーク上の2つのクラスタで同じマルチキャスト・アドレスを使用する場合、それぞれのクラスタのポートは異なっている必要があります。複数のクラスタでマルチキャスト・アドレスが異なっていれば、それらのクラスタで同じポートまたはデフォルトの7001番ポートを使用できます。
クラスタを起動する前に、クラスタのマルチキャスト・アドレスとポートが正しいことと、ネットワーク上の他のクラスタとの間でマルチキャスト・アドレスとポートの組み合わせが重複していないことを確認してください。
マルチキャスト・アドレスが不正な場合に最も起こりやすいエラーには、次のものがあります。
Unable to create a multicast socket for clustering Multicast socket send error Multicast socket receive error
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サポートの担当者宛の電子メールに、圧縮したログ・ファイルを添付します。ログ・ファイルをメールの本文にコピー・アンド・ペーストしないでください。
LinuxでJRockit JVMを使用する場合は、次のいずれかの方法でスレッド・ダンプを生成します。
WLSTのthreadDUMPコマンドを使用します。
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パラメータ)を調整する必要があります。
