既存のJNDI HornetQサービスをHAにする手順
TL; DR
HornetQセットアップでHA-JNDIサービスを設定する手順は何ですか？ドキュメントは少しばらばらになっていると思います。私はドキュメントを読みました here ですが、詳しく説明していないようです。
長いバージョン：
そのため、JNDIとともにHornetQ JMSをセットアップしています。 5つのサーバーがあり、それぞれがJNDIサービスを使用してHornetQ JMSマスターインスタンスを実行しています。これら5つのサーバーのそれぞれで、他のHornetQマスター用に実行されているスレーブもあります。
説明する：
Server A - HornetQa_master, JNDI, HornetQb_slave
Server B - HornetQb_master, JNDI, HornetQc_slave
Server C - HornetQc_master, JNDI, HornetQd_slave
Server D - HornetQd_master, JNDI, HornetQe_slave
Server E - HornetQe_master, JNDI, HornetQa_slave
これらのHornetQサーバーはそれぞれ、さまざまなバックエンドのニーズに対するミドルウェアとして機能するため、5台のサーバー、5台のHornetQマスターインスタンス、5台のHornetQスレーブインスタンス、5台のJNDIサーバーを意味します。ただし、このセットアップの問題は、サーバーホスト（プロセスだけでなくホスト自体）がダウンした場合、理想的には、サービスは、AのHornetQスレーブをホストするサーバーEで実行されているHornetQにフォールバックする必要があることです。ただし、HornetQマスターとして再開するには、HornetQa_slaveがサーバーAで実行されているJNDIプロセスと通信する必要があります（メッセージを複製すると仮定します）。ホストA自体がダウンしているため、Eで実行されているHornetQa_slaveはAのJNDIと通信する方法がないため、マスタープロセスとして再開できません。
JNDIサービスの可用性が高い場合、スレーブHornetQプロセスは期待どおりにマスターとして再開できます。既存のセットアップをHA-JNDIに変換する方法を簡単に説明したり、簡単な手順で説明したりできますか？価値のあることについては、複数の sources を読みましたが、HA-JNDIの構成を始める方法について詳しく説明していないようです。現在の設定に関する詳細が必要な場合はお知らせください。
説明したアーキテクチャでは、実際にはスレーブをマスターとして再構成する必要があり、特定の停止が発生するため、私には難しいようです。
HornetQ HAはライブバックアップペアを介して提供され、負荷分散はクラスターを介して提供されます。
HAと負荷分散の両方が必要な場合は、2つのライブバックアップペアをクラスター化する必要があります。
ホスト名ではなく、仮想IPアドレスを使用してマスターを参照できるため、マスターがダウンした場合にスレーブの1つを再構成できますマスターとして、仮想IPを起動して、残りのスレーブを再構成する必要がないようにします。 （マスターがダウンしている場合でもHAを保持するには、2つのスレーブを用意し、そのうちの1つをマスターとして再起動し、1つを実行します）。
同じ結果を達成する別の方法は、1つのホストがダウンした場合に別のIPを指すように再構成できる、マスター固有のDNSホスト名を使用することです。 DNSはキャッシュされているため、このエントリは「hosts」ファイルに保存する方が適切です。
HAドメインごとに3つのホストのハードウェアが多すぎる場合、追加のハードウェアを購入する必要なく、仮想サーバーでこれを簡単に実現できます。