IPマルチキャスト構成の問題のトラブルシューティングについては、「マルチキャスト構成のトラブルシューティング」を参照してください。
この章には、次の項が含まれます。
クラスタを起動する前に、問題を防止するためにできることがいくつかあります。
安定した状態の操作では、クラスタ内のすべてのサーバーが同じメンテナンス・レベル(メジャーおよびマイナー・バージョン番号、パッチ・セット番号、パッチ・セット更新番号、および仮パッチ/個別パッチがすべて同じ)である必要があります。WebLogic Serverでは、次を目的としたローリング・アップグレード(クラスタ内のサーバーへの保守の順次適用)がサポートされています。
仮パッチ/個別パッチの適用
パッチ・セット更新(PSU)の適用
WebLogic Server 10.3.xパッチ・セットの適用(例: WebLogic Server 10.3.5から10.3.6へのローリング・アップグレード)
通常、クラスタの管理サーバーはクラスタ・メンバーとして構成されませんが、一般には管理対象サーバーと同じ保守レベルを実行する必要があります。場合によっては、管理サーバーが、単一ドメイン内の異なるメンテナンス・レベルの複数クラスタを管理していることがあります。この場合、管理サーバーは、ドメイン内の管理対象サーバーの最も高いメンテナンス・レベルにする必要があります。
マルチキャスト・アドレスに関する問題は、クラスタが起動しないか、またはサーバーがクラスタに参加できないことの最も一般的な理由の1つです。
マルチキャスト・アドレスはクラスタごとに必要です。マルチキャスト・アドレスには224.0.0.0から239.255.255.255までの範囲のIPアドレスか、またはその範囲内のIPアドレスを持つホスト名を使用できます。
WebLogic Server管理コンソールの「構成」→「マルチキャスト」ページで、クラスタのマルチキャスト・アドレスとポートを確認できます。
ネットワーク上の各クラスタで、マルチキャスト・アドレスとポートの組み合わせは一意でなければなりません。ネットワーク上の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にお問い合わせになる前に、診断情報を収集してください。最も重要な情報は、管理対象サーバーからの複数のスレッド・ダンプが出力されたログ・ファイルです。ログ・ファイルは特に、クラスタのフリーズやデッドロックを診断する場合に重要です。
複数のスレッド・ダンプが出力されたログ・ファイルは、問題を診断するための前提条件となります。
Oracle HotSpot VMを使用する場合は、次のいずれかの方法でスレッド・ダンプを生成します。
WLSTのthreadDUMP
コマンドを使用します。
jstack
ユーティリティを使用します。
LinuxでOracle HotSpot VMを使用している場合は、Kill -3
PIDを使用します。ここで、PIDは、プロセス・ツリーのルートです。
ルートPIDを取得するには、次を実行します。
ps -efHl | grep 'java' **. **
サーバー起動コマンドと一致するプロセス・スタックで見つかる文字列と同じgrep
引数を使用します。報告される最初のPIDはルート・プロセスです。その際、ps
コマンドは別のルーチンにパイプされていないものと見なされます。
Linuxにおいて、各実行スレッドはLinuxプロセス・スタックで独立したプロセスとして扱われます。LinuxでKill -3を使用する場合は、メインのWebLogic実行スレッドのPIDと一致させる必要があり、一致しない場合はスレッド・ダンプは生成されません。
WindowsでOracle HotSpot VMを使用している場合は、アプリケーション・コンソールで[Ctrl]-[Break]コマンドを使用して、スレッド・ダンプを生成できます。
クラスタで問題が発生している場合、管理対象サーバー上でガベージ・コレクションを確認することも必要です。ガベージ・コレクションに時間がかかりすぎる場合、サーバーが使用可能であることを他のクラスタ・メンバーに通知する定期的なハートビート・シグナルをサーバーから発行できなくなります。
ガベージ・コレクション(最初または2度目の生成)に10秒以上かかる場合、システム上のヒープ割当て(msmx
パラメータ)を調整する必要があります。