0

セットアップは次のとおりです。Glassfishバージョン3.1.2.2-

  1. DASとinstance-1は同じマシンで実行され、instance-2は構成ノードと同じネットワーク内の別のマシンで実行されます。
  2. Glassfish高可用性ガイド（http://docs.oracle.com/cd/E18930_01/html/821-2416/gjjpy.html#gaxim ）に従って、共有ディレクトリにトランザクションログを設定しました。
  3. ネットワークでマルチキャストモードで実行されているネットワークロードバランサーがあるため、クラスター通信にユニキャスト構成を使用しています。
  4. 私たちのアプリケーション（複数の.warを含む.ear）には2つの永続的なタイマーがあります（クラスター内で一度にタイマーごとに1つのインスタンスしか必要ないため）。

インスタンス1（またはインスタンス2）が正常にシャットダウンされると、他のインスタンスは期待どおりにシャットダウンされたインスタンスからタイマーを回復します。instance-2がクラッシュするか、異常にオフラインになると、instance-1はタイマーを回復します（これも予想どおりです）。ただし、instance-1がクラッシュすると、instance-2は期待どおりにタイマーを回復しないようです。

ログからわかる限り、instance-2はinstance-1の適切なフェイルオーバーメッセージを受信して​​リカバリを開始しますが、障害が発生したインスタンスのトランザクションやタイマーをリカバリせずにリカバリを終了します。

誰かが問題が何であるかを教えてもらえますか？（これ以上の情報を提供する必要がありますか？）

4

1 に答える 1

0

2週間ほどの作業の後、ようやく問題を特定しました。

クラスタ内のインスタンスがダウンすると、リカバリインスタンスは、ダウンしたインスタンスの「node-host」：「admin-node-port」にアクセスしようとして、インスタンスがまだ稼働しているかどうかを確認しているようです。DASで標準で作成されたノードを使用している場合（以前のように）、node-hostは「localhost」に設定されます（たとえば、instance-1で行われたように）。

そのため、instance-2は、「instance-1-ip」ではなく「localhost」に接続しようとして、instance-1がダウンしているかどうかを確認しようとしていました。localhostに接続できたため、instance-1は誤って実行中としてマークされ、リカバリは続行されませんでした。

これを修正するには、ドメインconfig.xmlのnode-host for instance-1ノードを変更する必要がありました。これは、デフォルトのlocalhost-の構成をasadminまたはadminconsoleから変更できないためです。

于 2013-01-24T18:17:18.373 に答える