test

Sun Java System Application Server 9.1 配備計画ガイド

Message Queue ブローカの配備の計画

Java Message Service (JMS) API は、Java EE アプリケーションおよびコンポーネントに対して、メッセージの作成、送信、受信、および読み取りを可能にするメッセージング標準です。この API によって、緩やかに結合され、信頼性が高く、非同期の分散通信が可能となります。Sun Java System Message Queue は JMS を実装し、Application Server と統合されているため、MQ を使用してメッセージ駆動型 Beans (MDB) などのコンポーネントを作成できます。

Sun Java System Message Queue (MQ) は、J2EE コネクタアーキテクチャー仕様 (JCA) 1.5 で規定されているように、コネクタモジュール (リソースアダプタともいう) を使用して Application Server に統合されています。コネクタモジュールは、Application Server に機能を追加するための標準化された方法です。Application Server に配備された Java EE コンポーネントは、コネクタモジュールによって統合された JMS プロバイダを使用して JMS メッセージを交換します。この JMS プロバイダは、デフォルトでは Sun Java System Message Queue ですが、JCA 1.5 が実装されているかぎり、必要に応じて別の JMS プロバイダを使用できます。

Application Server で JMS リソースを作成すると、バックグラウンドでコネクタリソースが作成されます。そのようにして、JMS 操作のたびにコネクタランタイムが呼び出され、バックグラウンドで MQ リソースアダプタが使用されます。

リソースアダプタ API の使用に加えて、Application Server は、MQ とのより緊密な統合を実現するために MQ API を使用します。この緊密な統合によって、コネクタのフェイルオーバー、アウトバウンド接続の負荷分散、MDB へのインバウンドメッセージの負荷分散などの機能が可能になります。これらの機能を使用すると、メッセージングトラフィックの耐障害性や高可用性を実現できます。

マルチブローカクラスタ

MQ Enterprise Edition は、ブローカクラスタと呼ばれる、複数の相互接続されたブローカインスタンスの使用をサポートしています。ブローカクラスタによって、クライアント接続はクラスタ内のすべてのブローカに分散されます。クラスタ化することで、水平方向のスケーラビリティーが提供され、可用性が向上します。

1 つのメッセージブローカは約 8 個の CPU まで拡大縮小し、標準的なアプリケーションのための十分なスループットを提供します。ブローカプロセスが異常終了した場合、そのプロセスは自動的に再起動されます。ただし、ブローカーに接続するクライアントの数や配信されるメッセージの数が増えると、ブローカーは最終的に、ファイル記述子の数やメモリーなどの制限を超えてしまいます。

クラスタ内に 1 つのブローカではなく複数のブローカを配置すると、次のことが可能になります。

ただし、複数のブローカを配置しても、ブローカ障害の時点で進行中であったトランザクションが代替ブローカに引き継がれることは保証されません。MQ は、失敗した接続をクラスタ内の別のブローカを使用して再確立しますが、トランザクションメッセージングを失い、進行中のトランザクションをロールバックします。完了できなかったトランザクションを除き、ユーザーアプリケーションは影響されません。接続は引き続き使用可能であるため、サービスのフェイルオーバーは保証されます。

そのため、MQ はクラスタ内の高可用性持続メッセージをサポートしていません。障害のあとにブローカを再起動すると、ブローカは自動的に回復し、持続メッセージの配信を完了します。持続メッセージはデータベース内か、またはファイルシステムに格納される可能性があります。ただし、ブローカをホストしているマシンがハード障害から回復しない場合は、メッセージが失われる可能性があります。

Sun Cluster Data Service for Sun Message Queue を備えた Solaris プラットフォームは、持続メッセージの透過的なフェイルオーバーをサポートしています。この構成は、真の高可用性を実現するために Sun Cluster のグローバルファイルシステムと IP フェイルオーバーを利用しており、また Java Enterprise System にも含まれています。

マスターブローカとクライアントの同期

マルチブローカ構成では、各送信先がクラスタ内のすべてのブローカにレプリケートされます。各ブローカは、ほかのすべてのブローカ上の送信先として登録されているメッセージコンシューマを認識しています。そのため、各ブローカは、自身に直接接続されているメッセージプロデューサから遠隔メッセージコンシューマにメッセージを経路指定したり、遠隔プロデューサから自身に直接接続されているコンシューマにメッセージを配信したりすることができます。

クラスタ構成では、各メッセージプロデューサが直接接続されているブローカが、そのプロデューサから送信されるメッセージの経路指定を実行します。そのため、持続メッセージの格納と経路指定の両方を、そのメッセージのホームブローカが実行します。

管理者がブローカ上の送信先を作成または破棄した場合は常に、この情報がクラスタ内のほかのすべてのブローカに自動的に伝播されます。同様に、メッセージコンシューマがホームブローカに登録された場合、またはコンシューマがホームブローカから切り離された (明示的か、クライアントまたはネットワークの障害のためか、ホームブローカがダウンしたためかにかかわらず) 場合は常に、そのコンシューマに関連する情報がクラスタ全体にわたって伝播されます。同様の方法で、持続性サブスクリプションに関する情報もクラスタ内のすべてのブローカに伝播されます。

Message Queue ブローカを使用するための Application Server の設定

Application Server の Java Message Service は、Message Queue のコネクタモジュール (リソースアダプタ) を表します。Java Message Service は、管理コンソールまたは asadmin コマンド行ユーティリティーから管理することができます。

MQ ブローカ (JMS ホスト) は、Application Server プロセスとは別の JVM で動作します。これにより、複数の Application Server インスタンスまたはクラスタが MQ ブローカの同じセットを共有できます。

Application Server では、JMS ホストは MQ ブローカを指します。Application Server の Java Message Service 設定には、使用されるすべての JMS ホストを含む JMS ホストリスト (AddressList とも呼ばれる) が含まれています。

管理コンソールを使用した JMS の管理

管理コンソールでは、特定の構成の「Java メッセージサービス」ノードを使用して JMS プロパティーを設定できます。「再接続間隔」や「再接続試行」などのプロパティーを設定できます。詳細は、『Sun Java System Application Server 9.1 管理ガイド』の第 4 章「Java Message Service (JMS) リソースの設定」を参照してください。

「Java メッセージサービス」ノードの下の「JMS ホスト」ノードには、JMS ホストのリストが含まれています。リストにホストを追加することも、リストからホストを削除することもできます。ホストごとに、ホスト名、ポート番号、および管理ユーザーの名前とパスワードを設定できます。JMS ホストリストには、デフォルトで、Application Server に統合されたローカルの MQ ブローカを表す、"default_JMS_host" という 1 つの MQ ブローカが含まれています。

JMS ホストリストを、クラスタ内のすべての MQ ブローカを含むように設定します。たとえば、3 つの MQ ブローカを含むクラスタを設定するには、それぞれに対して Java Message Service 内に 1 つの JMS ホストを追加します。Message Queue クライアントは、Java Message Service 内の設定情報を使用して MQ ブローカと通信します。

asadmin を使用した JMS の管理

管理コンソールに加えて、asadmin コマンド行ユーティリティーでも Java Message Service と JMS ホストを管理できます。次の asadmin コマンドを使用します。

Java Message Service タイプ

Application Server と MQ ブローカの間の統合には、ローカルとリモートの 2 つのタイプがあります。このタイプ属性は、管理コンソールの「Java メッセージサービス」ページで設定できます。

ローカルの Java Message Service

「タイプ」属性が LOCAL の場合は、Application Server が MQ ブローカを起動および停止します。Application Server は起動時に、デフォルト JMS ホストとして指定されている MQ ブローカを起動します。同様に、Application Server インスタンスは停止時に、MQ ブローカを停止します。LOCAL タイプはスタンドアロンの Application Server インスタンスに最適です。

LOCAL タイプでは、「起動引数」属性を使用して MQ ブローカの起動パラメータを指定します。

リモートの Java Message Service

「タイプ」属性が REMOTE の場合、Application Server は、外部に設定されているブローカまたはブローカクラスタを使用します。この場合、MQ ブローカの起動と停止は Application Server とは別個に行い、MQ ツールを使用してブローカまたはブローカクラスタを設定および調整する必要があります。REMOTE タイプは Application Server クラスタに最適です。

REMOTE タイプでは、MQ ツールを使用して MQ ブローカ起動パラメータを指定する必要があります。「起動引数」属性は無視されます。

デフォルト JMS ホスト

デフォルト JMS ホストは、管理コンソールの「Java メッセージサービス」ページで指定できます。Java Message Service タイプが LOCAL の場合、Application Server は、Application Server インスタンスが起動したときにデフォルト JMS ホストを起動します。

MQ ブローカクラスタを使用するには、デフォルト JMS ホストを削除したあと、クラスタ内のすべての MQ ブローカを JMS ホストとして追加します。この場合、デフォルト JMS ホストは JMS ホストリスト内の最初の JMS ホストになります。

また、デフォルト JMS ホストを、いずれかの JMS ホストに明示的に設定することもできます。Application Server が Message Queue クラスタを使用する場合、デフォルト JMS ホストは MQ 固有のコマンドを実行します。たとえば、MQ ブローカクラスタの物理送信先が作成される場合、デフォルト JMS ホストはその物理送信先を作成するためにコマンドを実行しますが、クラスタ内のすべてのブローカがその物理送信先を使用します。

配備シナリオの例

メッセージングのニーズに対応するには、Java Message Service と JMS ホストリストを、配備、パフォーマンス、および可用性のニーズを満たすように変更します。以降の節では、いくつかの標準的なシナリオについて説明します。

メッセージングのニーズの考慮対象が Application Server のみでない場合は、最高の可用性を得られるように、MQ ブローカと Application Server を別のマシンに配備します。別のオプションとして、十分なメッセージング容量が存在するようになるまで、Application Server インスタンスと MQ ブローカインスタンスを各マシンで実行する方法があります。

デフォルト配備

Application Server をインストールすると、ドメイン管理サーバー (DAS) が自動的に作成されます。デフォルトでは、DAS の Java Message Service タイプは LOCAL です。そのため、DAS を起動すると、そのデフォルト MQ ブローカも起動されます。

新しいドメインを作成すると、新しいブローカも作成されます。デフォルトでは、ドメインにスタンドアロンのサーバーインスタンスまたはクラスタを追加すると、その Java Message Service は REMOTE として設定され、デフォルト JMS ホストは DAS によって起動されるブローカになります。

「デフォルト配備」は、3 つのインスタンスを含む Application Server クラスタが含まれたデフォルト配備の例を示しています。

Application Server クラスタでの MQ ブローカクラスタの使用

MQ ブローカクラスタを使用するように Application Server クラスタを設定するには、Application Server の Java Message Service で、すべての MQ ブローカを JMS ホストとして追加します。それにより、作成された JMS 接続ファクトリや、配備された MDB はすべて、指定された JMS 設定を使用するようになります。

次の図は、ブローカクラスタ内に 3 つの MQ ブローカが含まれ、クラスタ内に 3 つの Application Server インスタンスが含まれる配備の例を示しています。

アプリケーション固有の MQ ブローカクラスタの指定

場合によっては、アプリケーションが、Application Server クラスタで使用されているものとは別の MQ ブローカクラスタを使用しなければならないことがあります。「アプリケーション固有の MQ ブローカクラスタの指定」は、このようなシナリオの例を示しています。これを行うには、JMS 接続ファクトリの AddressList プロパティー、または MDB 配備記述子内の activation-config 要素を使用して MQ ブローカクラスタを指定します。

接続ファクトリの設定の詳細については、『Sun Java System Application Server 9.1 管理ガイド』の「JMS 接続ファクトリ」を参照してください。MDB の詳細については、『Sun Java System Application Server 9.1 Developer’s Guide』の「Using Message-Driven Beans」を参照してください。

アプリケーションクライアント

アプリケーションクライアントまたはスタンドアロンのアプリケーションが、JMS 管理によるオブジェクトにはじめてアクセスすると、クライアント JVM はサーバーから Java Message Service 設定を取得します。JMS サービスへのそれ以上の変更は、JMS サービスが再開されるまで、クライアント JVM には使用できません。