メッセージドリブンBean

メッセージドリブンBean

メッセージドリブンBeanではロードバランス／フェイルオーバーはサポートされていません。しかし、クラスタ内のHA-JMS（後述）に対して、 各クラスタノードのMDBがメッセージを処理する場合、それはMDBに期待されるロードバランスといってもよいでしょう。

スマートプロキシ

これまで述べてきたロードバランス／フェイルオーバーはEJBクライアントにより判断、実行されます。このプロキシ機能はEJBクライアントのスタブクラスがメソッドを実行した際、リモートアクセスが起こる前に処理をインターセプトして適切なサーバを決定します。

図2：スマートプロキシ

HA-JNDI

EJBをクラスタリングしていても、JNDIのルックアップに失敗した時にフェイルオーバーができないようでは意味がありません。

JBossではHA（High Availability）-JNDIがサポートされ、ルックアップのフェイルオーバーが可能になっています。クライアントが通常の1099番のかわりに、1100番ポートにアクセスすることでHA-JNDIを使うことができます。HA-JNDIにアクセスした場合、JBossは以下のような順序で検索処理を行います。

図3：HA-JNDIにアクセスした場合のJBossの処理の流れ

ところでクライアントがルックアップを行う際、1つのJNDIサーバのURLしか知らなければ、そのサーバが落ちていたときにフェイルオーバーがで きません。この問題に対処するために、"java.naming.provier.url"プロパティには複数のURLを記述することができます。
 

   "InitiaiContext"は1つ目のサーバへのアクセスに失敗すれば、リストされた次のサーバへと順にフェイルオーバーします。

サーバ側でルックアップを行う場合（例えばサーブレットがEJBを使うケース）は、"new InitialContext()"と引数なしのコンストラクタを呼べばローカルJNDIを検索します。これで別ノードに接続して無用なパフォーマンス劣化を起こす事態を防ぐことができます。

HA-JMS

JBossではHA-JMSがサポートされています。HA-JMSは可用性の向上、つまりフェイルオーバーのみを実現しておりロードバランスは含まれません。

"default"サーバ設定と違い、"all"サーバ設定ではJMS機能が"deploy-hasingleton"ディレクトリに配置されています。ここにデプロイされることにより、JMSはただ1つのクラスタノードだけで有効になります（シングルトン）。

JMSクライアントはHA-JNDI（ポート1100）を通してHA-JMSをルックアップします。HA-JNDIはクラスタワイドJNDIに登録されたJMSを発見し、シングルトンとして起動しているノードのJMSを返します。HA-JNDIは常に同じノードのJMSを返しますが、そのノードがダウンしていた場合、別のノードのJMSが有効になり、そのノードが次からシングルトンのJMSサーバとして機能します。このようにしてJMSのフェイル オーバーが達成されます。

図4：JMSのフェイルオーバー

フェイルオーバーはHA-JNDIを通じて行われますので、JMSクライアントは接続に失敗したときにはHA-JNDIからコネクションを取得しなおす必要があります（EJBクライアントのようなスマートプロキシではありません）。

HA-JMSの信頼性はJMSメッセージをストアするデータベースに依存します。デフォルトではJBossのJMSがメッセージをストアするデータベースは各JBossインスタンスに組み込まれたHSQLDBなので、JMSストアをクラスタノード共通の1つのデータベースに差し替えないと意味があり ません。

いずれにせよ本番稼動ではJMSストアにHSQLDBを使用することは好ましくないため、"hsqldb-jdbc2-service.xml"および"hsqldb-jdbc-state-service.xml"を修正／リプレースし、任意のデータベースにつなげてください。