Javaアプリケーションサーバのクラスタリング機能比較第3回

メッセージドリブン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は以下のような順序で検索処理を行います。

クラスタワイドJNDI（後述のHA-JMSのように、特別にデプロイしたもの）を検索
1で見つからなければ、自身のローカルJNDIを検索
2で見つからなければ、全クラスタノードのローカルJNDI（通常使っているJNDIのこと）を検索

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

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

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

java.naming.provier.url=jboss1:1100,jboss2:1100,jboss3:1100,jboss4:1100

"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"を修正／リプレースし、任意のデータベースにつなげてください。