スタンドアロンのクラスター化されたJMSサーバーでクラスター化されたアプリケーションサーバーをホストします。アプリケーションサーバーはアクティブ/アクティブで負荷分散されていますが、JMSサーバーはアクティブ/パッシブ（共有ストレージ）であり、OSクラスタリングを使用しています。これは、クライアントの観点からは、それぞれに1つのエンドポイントしかないことを意味します。
現在、外部のJMSクラスター（アクティブ/パッシブ）に接続するタスクがありますが、JMSクライアントにフェイルオーバーを実装することを期待しているようです。つまり、可能であればプライマリに接続し、必要に応じてセカンダリにフェイルオーバーします。
無知に聞こえるリスクがありますが、私はそのような設定を見たことがありませんが、いくつかのグーグルは、これが多かれ少なかれJMSの標準的な方法であるように見えることを示しているようです。
私の質問は、従来の負荷分散や他のサーバー側のクラスタリング手法とは対照的に、JMSプロバイダーが「クライアント側のクラスタリング」を好むように見えるのはなぜですか。それは確かに業界標準ですか？
今のところ、MySQL Cluster で複数の Open MQ を実行しています。このリンク (http://mq.java.net/OpenMQ_MySQLCluster_Setup_Guide.html) を参照してください。
このサーバー トポロジの場合、EJB コンテナーで実行する場合、任意のノード (ブローカー 1、ブローカー 2) に接続できます (使用した中間層に応じて) いくつかのノードが停止したときにコンテナーによって自動切り替えされます。
私は、両方のサーバーがすべてのメッセージを取得する (同期を維持するために互いに通信する) JMS を使用したアクティブ/アクティブ クラスタリングのみを使用したことがあります。異なるデータセンターにあったため、ディスクサブシステムを共有していませんでした。クライアントは 2 つのサーバーで構成されていますが、一度に 1 つしか接続できません。(通常はローカル JMS サーバー) フェイルオーバーはクライアントに対して透過的です。
また、2 台のローカル サーバーと 1 台の非ローカル サーバーを使用する構成も確認しました。これにより、1 台のサーバーに障害が発生しても、WAN を介して別のデータ センターに接続する必要がなくなります。私は自分でそのような構成を設定していません。
共有ストレージの使用は、システム管理者にとってはクールに思えますが、ソフトウェアに対して透過的ではないという欠点があります。アプリケーションが独自のフェイルオーバーをサポートしている場合は、それが望ましいです。つまり、サービスにフェイルオーバーがない場合にのみ共有ストレージを使用します。