jBroker MQのクラスタリング

クラスタリングはjBroker MQ 2.0で導入されました。クラスタリングを使用すると、プロデューサアプリケーションからコンシューマアプリケーションへのメッセージの取得に複数のjBroker MQサーバを使用できます。 また、クラスタリング機能を使用すると、よりスケーラブルで、部分的なシステム障害にも強いアプリケーションを簡単に作成できます。 この章では、jBroker MQのクラスタリングについて説明します。

はじめに

メッセージングミドルウェアを使用する主な目的は、システムコンポーネントが使用できないときに発生する複雑なエラー状況から、アプリケーションおよびアプリケーションプログラマを保護することです。 すべてのメッセージングを中間段階の宛先に保存することで、送信側アプリケーションは、受信側アプリケーションと独立して実行できます。 ただし、この利点が実現されるのは、メッセージングミドルウェアがいつでも使用できる場合だけです。

ところが、ソフトウェア障害、ハードウェア障害、またはメンテナンスのために、すべての個々のソフトウェアコンポーネントは中断される可能性があります。 したがって、高い可用性が要求されるコンポーネントでは、通常、パラレルで実行されるいくつかのコンポーネントとして構成します。 いくつかのコンポーネントを実行して、シングルポイントの障害を回避する構成をクラスタと呼びます。 クラスタの長所として、次の点が挙げられます。

クラスタリングの最終的な目的は、これまでに説明したクラスタの利点をアプリケーション開発者にできる限り透過的に提供することです。 ミドルウェアのタイプによっては、クラスタリングが完全に透過的になります。つまり、アプリケーションプログラマは、単一のサーバを使用しているかのようにプログラムを作成できます。つまり、部分的な障害が発生したときに必要なフェイルオーバまたは負荷分散アルゴリズムの開発は、ミドルウェアにより自動的に行われます。

メッセージングシステムのクラスタリングは、通常、他のタイプのミドルウェアのクラスタリングとは異なります。 たとえば、2つのサーバでキューを複製するとします。 この場合、このサーバのいずれかに接続しているコンシューマだけが、キューに送信されたメッセージを受信することが重要です。 したがって、通常選択されるのは、スループット機能が削減されたクラスタ化メッセージングサーバではなく、より現実的なクラスタリングです。

jBroker MQのクラスタリング

jBroker MQでは、クラスタのサーバ間で宛先およびセキュリティ状態を同期化することでクラスタリングがサポートされます。 したがって、すべての宛先をクラスタの全サーバで使用できます。 また、クラスタの各jBroker MQサーバにより他のクラスタメンバーにメッセージを転送することもできます。 メッセージ転送は、キューやトピックにより異なります。

  1. トピックは論理上すべての場所に存在するため、トピックメッセージはデフォルトでは常に転送されます。 つまり、アプリケーションは、クラスタの任意のサーバを使用して、トピックからメッセージを送信または受信できます。
  2. キューメッセージが転送されるのは、特定の宛先のキュー受信者がクラスタの別のサーバに接続された場合です。 つまり、キューはクラスタ規模ではなく、クラスタの任意のサーバからアクセスできます。

このような機能により、単一サーバシステムと同じキューおよびトピックのセマンティックが提供されます。 トピックサブスクライバは、最初のサブスクライブ後にトピックに送信されるすべてのメッセージを受信します。 キュー受信者は、未処理メッセージをキューからラウンドロビン方式で受信します。 唯一異なる点は、コンシューマが、メッセージの本来の送信先ではないサーバからでもメッセージを受信できるという点です。

図1: jBroker MQでのクラスタリングの概念

部分的なクラスタ障害は、コンシューマアプリケーションには透過的にはなりません。これは、メッセージをコンシューマに送信したのと同じサーバでメッセージを確認する必要があるからです。 ただし、コンシューマが障害のあるメッセージを確認すると、クラスタの別のサーバに接続して、そこからメッセージを続行することができます。 キュー受信者は、常に、パフォーマンス上の理由で、キューのあるサーバに接続します。

クラスタリングの別の例を次の図2に示します。 ブローカに接続されているコンシューマは、別のブローカに接続されているコンシューマとはメッセージの受け取り順序が異なります。これは、メッセージがクラスタのブローカ間で非同期に交換されるからです。 順序が重視されるアプリケーションは、クラスタを使用する場合、メッセージタイムスタンプに依存します。 また、メッセージは、障害の発生したブローカが再起動されるまで遅延する可能性があります。

図2: メッセージ順序は、クラスタリングの使用時に影響あります。

プロデューサアプリケーションの場合、通常、クラスタリングは完全に透過的です。 クラスタのいずれかのサーバで障害が発生した場合、jBroker MQは、クラスタの他の使用可能なサーバにプロデューサを自動的に再接続し、そのサーバにメッセージの送信を続けて行います。 特別な例として、常に1つのサーバだけを使用して実行する必要のある分散トランザクションがあります。 透過的なフェイルオーバは、プロデューサの接続のどのセッションにもコンシューマが存在しない場合だけ有効になります。

負荷バランス

接続ファクトリには、クラスタに含まれるすべてのjBroker MQサーバのアドレス情報が含まれます。 クライアントアプリケーションは、クラスタリングが構成されている管理オブジェクトでブートされる場合、自動的にクラスタ対応モードで実行されます。 また、クライアントアプリケーションは、ブートプロセスでも障害対策が必要な場合、明示的にクラスタリングを構成することもできます。

宛先ファクトリは、通常、次の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を使用して、jBroker MQは、キュー接続ファクトリを解決して、これを両方のサーバのアドレス情報により構成します。 リストの最初のサーバは、プライマリサーバで、リストの残りのサーバはセカンダリサーバです。 プロデューサアプリケーションごとに異なるプライマリホストを使用する場合、負荷分散が発生します。 JNDIを使用しないアプリケーションは、JMQServerInfoデータ構造を使用して、接続ファクトリをインスタンス化し、セカンダリサーバを設定できます。

クラスタ管理

jBroker MQクラスタは、弱連結のjBroker MQサーバのセットで構成されます。このサーバは、状態を共有し、メッセージ処理において併用されます。 クラスタには任意の数のサーバを設定できますが、クラスタサイズはアプリケーションの可用性に関する要件に合わせる必要があります。 クラスタメンバーは、宛先またはセキュリティ情報が同時に修正されない限り、動的に追加および削除できます。

jBroker MQクラスタの主な利点は、共有データベースに依存しないということです。 その代わり、持続メッセージおよび宛先情報は、クラスタの各サーバに対して別々のデータベースに保存できます。 つまり、jBroker MQサーバは、jBroker ORBのデュアルホームネットワークサービスを利用するため、jBroker MQクラスタにはシングルポイント障害はありません。 可用性の高いデータベースが存在する場合、そのデータベース(テーブルではありません)を共有するようにクラスタのすべてのサーバを構成できます。

jBroker MQクラスタ構成は、JMQMessageServiceインタフェースから次のプロパティを使用して、指定されます。

これらのプロパティは、jBroker MQサーバプログラムjmqservで使用されるmsgsvc.propertiesファイルの一部です。

Copyright © 1998-2003, Novell, Inc. All rights reserved.