MQ は、ブローカクラスタと呼ばれる、複数の相互接続されたブローカインスタンスの使用をサポートしています。ブローカクラスタによって、クライアント接続はクラスタ内のすべてのブローカに分散されます。クラスタ化することで、水平方向のスケーラビリティーが提供され、可用性が向上します。
1 つのメッセージブローカは約 8 個の CPU まで拡大縮小し、標準的なアプリケーションのための十分なスループットを提供します。ブローカプロセスが異常終了した場合、そのプロセスは自動的に再起動されます。ただし、ブローカーに接続するクライアントの数や配信されるメッセージの数が増えると、ブローカーは最終的に、ファイル記述子の数やメモリーなどの制限を超えてしまいます。
クラスタ内に 1 つのブローカではなく複数のブローカを配置すると、次のことが可能になります。
1 台のマシンでハードウェア障害が発生した場合でもメッセージングサービスを提供する。
システム保守を実行している間の停止時間を最小限に抑える。
異なるユーザーリポジトリを持つワークグループを格納する。
ファイアウォールの制限に対応する。
ただし、複数のブローカを配置しても、ブローカ障害の時点で進行中であったトランザクションが代替ブローカに引き継がれることは保証されません。MQ は、失敗した接続をクラスタ内の別のブローカを使用して再確立しますが、トランザクションメッセージングを失い、進行中のトランザクションをロールバックします。完了できなかったトランザクションを除き、ユーザーアプリケーションは影響されません。接続は引き続き使用可能であるため、サービスのフェイルオーバーは保証されます。
そのため、MQ はクラスタ内の高可用性持続メッセージをサポートしていません。障害のあとにブローカを再起動すると、ブローカは自動的に回復し、持続メッセージの配信を完了します。持続メッセージはデータベース内か、またはファイルシステムに格納される可能性があります。ただし、ブローカをホストしているマシンがハード障害から回復しない場合は、メッセージが失われる可能性があります。
Sun Cluster Data Service for Sun Message Queue を備えた Solaris プラットフォームは、持続メッセージの透過的なフェイルオーバーをサポートしています。この構成は、真の高可用性を実現するために Sun Cluster のグローバルファイルシステムと IP フェイルオーバーを利用しており、また Java Enterprise System にも含まれています。
マルチブローカ構成では、各送信先がクラスタ内のすべてのブローカにレプリケートされます。各ブローカは、ほかのすべてのブローカ上の送信先として登録されているメッセージコンシューマを認識しています。そのため、各ブローカは、自身に直接接続されているメッセージプロデューサから遠隔メッセージコンシューマにメッセージを経路指定したり、遠隔プロデューサから自身に直接接続されているコンシューマにメッセージを配信したりすることができます。
クラスタ構成では、各メッセージプロデューサが直接接続されているブローカが、そのプロデューサから送信されるメッセージの経路指定を実行します。そのため、持続メッセージの格納と経路指定の両方を、そのメッセージのホームブローカが実行します。
管理者がブローカ上の送信先を作成または破棄した場合は常に、この情報がクラスタ内のほかのすべてのブローカに自動的に伝播されます。同様に、メッセージコンシューマがホームブローカに登録された場合、またはコンシューマがホームブローカから切り離された (明示的か、クライアントまたはネットワークの障害のためか、ホームブローカがダウンしたためかにかかわらず) 場合は常に、そのコンシューマに関連する情報がクラスタ全体にわたって伝播されます。同様の方法で、持続性サブスクリプションに関する情報もクラスタ内のすべてのブローカに伝播されます。