Open MQ4.1を使ってみよう！第8回 MQ4.1EE/MQ3.7EEでMQクラスタを構成する
Open MQとSun Java System Message QueueのEnterprise Editionではブローカをクラスタ構成にすることができます。クラスタ構成にする利点は以下です。
・複数のブローカが起動するので、特定のブローカが停止しても全体としてのサービスは停止しない
・クライアントが接続している先のブローカが異常終了した場合は、他の健全なブローカへ接続がフェイルオーバされる（サービスの継続）
・各ブローカの作業量の最適化。クラスタ全体としてスループットを向上させることができる（ベンチマークでは対シングルスレッド+40%スループット向上）
今回は、MQ3.7EEとMQ4.1EEが共通で持つ、「コンベンショナルクラスタ」の構成方法について説明します。
＃なぜコンベンショナルかと言いますと、MQ4.1EEでは「HAクラスタ」というクライアント側が接続先ブローカの障害を意識せずに透過的にフェイルオーバできる仕組みが導入されたためです。HAクラスタ機能が追加されたので、それまでのクラスタの機能を「コンベンショナルクラスタ」と呼んでいます。
以下の図を見てください。
この図では３つのブローカがクラスタ構成をとっています。クライアントから接続ファクトリを作成するときに、クラスタ中のブローカアドレスをリストにして呼び出す形になります。呼び出し先のブローカはデフォルトではランダムに選択される仕様です。クライアントから最初に要求が着信したブローカのことを「ホームブローカ」と呼んでいます。以後、そのクライアントからの送受信リクエストはそのホームブローカを通じて行われます。クラスタ中のブローカはお互いにメッセージの処理を協調して行う仕組みになっています。ホームブローカが他クライアントからの処理を処理していてビジー状態の場合は手すきのブローカへ内部的に送受信リクエストがルーティングされます。
尚、無駄なブローカ間の通信をなるべく減らすアルゴリズムが装備されており、いくつかのメッセージをまとめて送信するというような最適化が内部で行われます。送信クライアントと受信クライアントが別々のホームブローカに接続してしまった場合は、受信側がつないだホームブローカのデータストアには目的の宛先がないことがあります。
＃コンベンショナルクラスタでは各ブローカがデータストアを持っているためです
この場合のみクラスタ中の目的の宛先を持っているブローカと通信を行って目的の宛先データを自分のところにコピーします。（自動作成宛先の場合）このような最適化が、クラスタ構成だからといってそんなに大きなオーバヘッドがかからない理由です。
＃クラスタVSシングルのベンチマークでは、クラスタ処理オーバヘッド１リクエスト平均１５ミリ秒、スループット40%向上という結果が出ています。
MQ3.7/MQ4.1をブローカとして構成するための手順は以下になります。
１．ブローカをクラスタ（コンベンショナルクラスタ）メンバとして起動する（メンバの数だけ）
binディレクトリに移動します。
cd C:\software\MQ4.1\mq\bin
1番目のブローカの起動
imqbrokerd -tty -name broker1 -port 7676 -cluster localhost:7677,localhost:7678
2番目のブローカの起動
imqbrokerd -tty -name broker2 -port 7677 -cluster localhost:7676,localhost:7678
3番目のブローカの起動
imqbrokerd -tty -name broker3 -port 7678 -cluster localhost:7676,localhost:7677
ブローカの名前とポート番号はユニークになるようにしてください。
-clusterオプションには、自分以外のクラスタ中のブローカホスト名:ポート番号を指定します。
一番目のブローカログ
二番目のブローカログ
三番目のブローカログ
お互いにクラスタコネクションを張っているのがわかります。
２．クライアント中の接続ファクトリのオプションでブローカアドレスリストを指定する
InitialContext ctx = new InitialContext();
com.sun.messaging.ConnectionFactory conFactory
= new com.sun.messaging.ConnectionFactory();
conFactory.setProperty(ConnectionConfiguration.imqAddressList,
"localhost:7676,localhost:7677,localhost:7678");
この後、通常のJMSプログラミングで接続の作成→セッションの作成→宛先の作成→プロデューサまたはコンシュマの作成でOKです。
コンベンショナルクラスタを使用する上で注意すべき点
・クライアントの接続先として選択されたブローカと通信中に問題が発生した場合は「自動再配信」がONになっている場合のみクライアント側から自動的に再配信が行われる。
・再配信した先のブローカがダウンしている場合はクラスタ中の別ブローカへ接続がフェイルオーバーされる
・セッションがTransactedまたは、テンポラリキューを使用している場合には自動再配信がONになっていても自動では再配信されない。この場合は例外が送出されるので例外処理中にて手動で再接続・再配信を行う必要がある
・ブローカに障害が発生した場合、そのブローカが持っているキューやトピックに蓄積されている未消費のメッセージはロストする可能性がある
・MQ4.1のHAクラスタでは永続ストアを全ブローカが共有するので、データのロストがない
次回はMQ4.1のHAクラスタ構成方法について説明します。