1. Oracle WebLogic Serverクラスタの管理
  2. 一般的な問題のトラブルシューティング

14 一般的な問題のトラブルシューティング

ガイドラインを学んで、Oracle WebLogic Serverクラスタの問題を防止し、発生した場合にトラブルシューティングします。

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の値が、クラスタ内のすべての管理対象サーバー間で一致していることを確認します。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にお問い合わせになる前に、診断情報を収集してください。最も重要な情報は、管理対象サーバーからの複数のスレッド・ダンプが出力されたログ・ファイルです。ログ・ファイルは特に、クラスタのフリーズやデッドロックを診断する場合に重要です。

ノート:

複数のスレッド・ダンプが出力されたログ・ファイルは、問題を診断するための前提条件です。
  1. サーバーを停止します。
  2. この時点でログ・ファイルがあればすべて削除するか、バックアップします。既存のログ・ファイルに追加書込みを行うよりも、サーバーを起動するたびに新しいログ・ファイルを作成することをお薦めします。
  3. 次のコマンドでサーバーを起動します - このコマンドは、詳細ガベージ・コレクションを有効化し、標準エラーと標準出力の両方をログ・ファイルにリダイレクトします。
    % 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

    標準エラーと標準出力の両方をリダイレクトすることにより、サーバーの通知メッセージとエラー・メッセージを含む、適切なコンテキストのスレッド・ダンプ情報が得られ、問題を解析しやすくなります。

  4. 問題が再発生するまで、クラスタの実行を継続します。
  5. サーバーがハングした場合は、kill -3コマンドまたは[Ctrl]-[Break]を使用して、問題を診断するために必要なスレッド・ダンプを作成します。デッドロックの診断を行うには、この作業を各サーバーに対して、約5 - 10秒間隔で何度か行うようにしてください。
  6. 次のUNIXユーティリティを使用するかWindowsユーティリティを使用して、ログ・ファイルを圧縮します。
    % tar czf logfile.tar logfile.txt
  7. Oracleサポートの担当者宛の電子メールに、圧縮したログ・ファイルを添付します。ログ・ファイルをメールの本文にコピー・アンド・ペーストしないでください。

親トピック: クラスタ起動後の作業

Oracle HotSpot VMスレッド・ダンプの取得

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パラメータ)を調整する必要があります。

親トピック: クラスタ起動後の作業

utils.MulticastTestの実行

管理対象サーバーの1つからutils.MulticastTestを実行して、マルチキャストが機能しているかどうかを確認できます。詳細は、『Oracle WebLogic Serverコマンド・リファレンス』の「Oracle WebLogic Server Javaユーティリティの使用」を参照してください。

親トピック: クラスタ起動後の作業