図1:Novell exteNd Messaging Platform JMSでのクラスタリングの概要
クラスタリングはバージョン2.0から利用可能になりました。クラスタリングを使用すると、プロデューサアプリケーションからコンシューマアプリケーションへのメッセージの取得に複数のJMSサーバを使用できます。クラスタ機能を使用すると、よりスケーラブルで、部分的なシステム障害にも強いアプリケーションを簡単に作成できます。 この章ではNovell exteNd Messaging Platform JMSの高レベルのクラスタリングを説明します。
メッセージングミドルウェアを使用する主な目的は、システムコンポーネントが使用できないときに発生する複雑なエラー状況から、アプリケーションおよびアプリケーションプログラマを保護することです。すべてのメッセージングを中間段階の宛先に保存することで、送信側アプリケーションは、受信側アプリケーションと独立して実行できます。ただし、この利点が実現されるのは、メッセージングミドルウェアがいつでも使用できる場合だけです。
ところが、ソフトウェア障害、ハードウェア障害、またはメンテナンスのために、すべての個々のソフトウェアコンポーネントは中断される可能性があります。したがって、高い可用性が要求されるコンポーネントでは、通常、パラレルで実行されるいくつかのコンポーネントとして構成します。いくつかのコンポーネントを実行して、シングルポイントの障害を回避する構成をクラスタと呼びます。クラスタの長所として、次の点が挙げられます。
クラスタリングの最終的な目的は、これまでに説明したクラスタの利点をアプリケーション開発者にできる限り透過的に提供することです。ミドルウェアのタイプによっては、クラスタリングが完全に透過的になります。つまり、アプリケーションプログラマは、単一のサーバを使用しているかのようにプログラムを作成できます。つまり、部分的な障害が発生したときに必要なフェールオーバーまたは負荷分散アルゴリズムの開発は、ミドルウェアにより自動的に行われます。
メッセージングシステムのクラスタリングは、通常、他のタイプのミドルウェアのクラスタリングとは異なります。たとえば、2つのサーバでキューを複製するとします。この場合、このサーバのいずれかに接続しているコンシューマだけが、キューに送信されたメッセージを受信することが重要です。したがって、通常選択されるのは、スループット機能が削減されたクラスタ化メッセージングサーバではなく、より現実的なクラスタリングです。
JMSサーバは、クラスタのサーバ間で宛先およびセキュリティ状態を同期化することでクラスタリングをサポートします。したがって、すべての宛先をクラスタの全サーバで使用できます。 また、クラスタの各JMSサーバにより他のクラスタメンバーにメッセージを転送することもできます。メッセージ転送は、キューやトピックにより異なります。
このような機能により、単一サーバシステムと同じキューおよびトピックのセマンティックが提供されます。トピックサブスクライバは、最初のサブスクライブ後にトピックに送信されるすべてのメッセージを受信します。キュー受信者は、未処理メッセージをキューからラウンドロビン方式で受信します。唯一異なる点は、コンシューマが、メッセージの本来の送信先ではないサーバからでもメッセージを受信できるという点です。
図1:Novell exteNd Messaging Platform JMSでのクラスタリングの概要
部分的なクラスタ障害は、コンシューマアプリケーションには透過的にはなりません。これは、メッセージをコンシューマに送信したのと同じサーバでメッセージを確認する必要があるからです。ただし、コンシューマが障害のあるメッセージを確認すると、クラスタの別のサーバに接続して、そこからメッセージを続行することができます。キュー受信者は、常に、パフォーマンス上の理由で、キューのあるサーバに接続します。
クラスタリングの別の例を次の図2に示します。ブローカに接続されているコンシューマは、別のブローカに接続されているコンシューマとはメッセージの受け取り順序が異なります。これは、メッセージがクラスタのブローカ間で非同期に交換されるからです。順序が重視されるアプリケーションは、クラスタを使用する場合、メッセージタイムスタンプに依存します。また、メッセージは、障害の発生したブローカが再起動されるまで遅延する可能性があります。
図2: メッセージ順序は、クラスタリングの使用時に影響されます。
プロデューサアプリケーションの場合、通常、クラスタリングは完全に透過的です。 クラスタのいずれかのサーバで障害が発生した場合、プロデューサはクラスタの使用可能な他のサーバに自動的に再接続され、そのサーバに継続してメッセージを送信します。特別な例として、常に1つのサーバだけを使用して実行する必要のある分散トランザクションがあります。透過的なフェールオーバーは、プロデューサの接続のどのセッションにもコンシューマが存在しない場合だけ有効になります。
接続ファクトリには、クラスタに含まれるすべてのJMSサーバのアドレス情報が含まれます。クライアントアプリケーションは、クラスタリングが構成されている管理オブジェクトでブートされる場合、自動的にクラスタ対応モードで実行されます。また、クライアントアプリケーションは、ブートプロセスでも障害対策が必要な場合、明示的にクラスタリングを構成することもできます。
宛先ファクトリは、通常、次のURLを使用してJNDIから解決されます。
queue://[h:p][,h:p]*/connectionFactory queue://[h:p][,h:p]*/xaConnectionFactory topic://[h:p][,h:p]*/connectionFactory topic://[h:p][,h:p]*/xaConnectionFactory
たとえば、クライアントは、キュー接続ファクトリを次のように解決できます。
queue://jms1:3506,jms2:3506/connectionFactory
このURLを使用して、キュー接続ファクトリが解決され、両方のサーバのアドレス情報で構成されます。リストの最初のサーバは、プライマリサーバで、リストの残りのサーバはセカンダリサーバです。プロデューサアプリケーションごとに異なるプライマリホストを使用する場合、負荷分散が発生します。 JNDIを使用しないアプリケーションは、JMQServerInfoデータ構造を使用して、接続ファクトリをインスタンス化し、セカンダリサーバを設定できます。
JMSクラスタは、弱連結のJMSサーバのセットで構成されます。このサーバは状態を共有し、メッセージ処理において連携します。クラスタには任意の数のサーバを設定できますが、クラスタサイズはアプリケーションの可用性に関する要件に合わせる必要があります。クラスタメンバーは、宛先またはセキュリティ情報が同時に修正されない限り、動的に追加および削除できます。
JMSクラスタの主な利点は、共有データベースに依存しないということです。その代わり、持続メッセージおよび宛先情報は、クラスタの各サーバに対して別々のデータベースに保存できます。 つまり、JMSサーバは、ORBのデュアルホームネットワークサポートを利用するため、JMSクラスタにはシングルポイント障害はありません。可用性の高いデータベースが存在する場合、そのデータベース(テーブルではありません)を共有するようにクラスタのすべてのサーバを構成できます。
JMSクラスタ設定はJMQMessageServiceインタフェースから次のプロパティを使用するよう定義されています。
msgsvc.cluster.members - JMSクラスタの他のブローカのURLリスト。
msgsvc.cluster.topics - クラスタで転送されるメッセージのトピックのカンマ区切りリスト。デフォルトでは、このプロパティは指定されません。つまり、すべてのトピックがクラスタ規模で転送されます。
これらのプロパティは、 JMSサーバプログラム、jmqservで使用されるmsgsvc.propertiesファイルの一部です。