MDBのデプロイ

宛先とMDB: 連結と非連結

リスニング元または個別のサーバー・インスタンス上のJMS宛先として、同一のサーバー・インスタンス上でMDBをデプロイできます。リスニング対象のJMS宛先と同じサーバー・インスタンスにMDBをデプロイする場合には連結と呼ばれ、別のサーバー・インスタンスにデプロイする場合には、非連結と呼ばれます。

連結された宛先/MDB

MDBとそのリスニング対象の宛先を連結すると、メッセージ・トラフィックが常にローカルになり、ネットワークの往復がなくなります。連結は、Oracle WebLogic Server JMSを使用し、メッセージ処理の待機時間とネットワーク・トラフィックを最小限に抑えたい場合に最適です。

MQ SeriesなどのOracle WebLogic Serverで動作できないサード・パーティJMSプロバイダを使用する場合は、MDBとJMS宛先を連結できません。

図4-1と図4-2は、関連付けられたJMS宛先をホストするサーバー・インスタンスにMDBアプリケーションがデプロイされるアーキテクチャを示しています。これらのアーキテクチャは、前者には分散宛先が含まれ、後者には含まれないという点で異なります。分散宛先を使用するアプリケーションでは、MDBは分散宛先セットのメンバーをホストする各サーバー・インスタンスにデプロイされます。分散宛先の詳細は、「JMS分散宛先」を参照してください図4-1に示されているように、メッセージ「M1」は分散宛先とMDB_Aがデプロイされている各サーバー・インスタンス上のMDB_Aのインスタンスに配信されます。図4-1は、One-Copy-Per-Serverトピック・メッセージ宛先モード・パターンを示しています。トピック・パターンは、topicMessagesDistributionModeの設定でさらに詳しく説明します。

図4-1 連結された宛先/MDB、分散トピック、One-Copy-Per-Serverパターン

「図4-1 連結された宛先/MDB、分散トピック、One-Copy-Per-Serverパターン」の説明

図4-2 連結された宛先とMDB、非分散宛先

「図4-2 連結された宛先とMDB、非分散宛先」の説明

連結されていない宛先/MDB

JMS宛先とは別のサーバー・インスタンスでMDBが動作する非連結宛先/MDBを調べます。サードパーティJMSプロバイダを使用するアプリケーション、またはJMSインフラストラクチャからアプリケーション・コード(MDB)を分離する場合に最適です。

図4-3は、リスニング対象のJMS宛先からの別のサーバー・インスタンスでMDBが動作するアーキテクチャを示しています。

図4-3 連結されていないアプリケーション、非分散宛先

「図4-3 連結されていないアプリケーション、非分散宛先」の説明

リスニング対象のJMS宛先とは別のサーバー・インスタンスでMDBを実行するのが適切なのは、以下の場合です。

アプリケーションでサード・パーティ製のJMSプロバイダ(MQ Seriesなど)が使用されます。
JMSのインフラストラクチャからアプリケーション・コード(MDB)を分離する必要があります。JMS宛先とMDBを別々のサーバー・インスタンスに配置することで、アプリケーションの問題(たとえばMDBが仮想マシンのメモリーをすべて消費するなど)でJMSインフラストラクチャの処理が妨げられるのが防止されます。
MDBアプリケーションが非常にCPUを消費します。別のマシンにあれば、アプリケーションはJMSインフラストラクチャの処理に影響を与えずにCPUパワーを100%使用することができます。
構成中の1つのマシンが、同じ構成の他のマシンよりも処理能力、ディスク領域やメモリーの点で優れています。

JMS宛先とMDBは、非クラスタ化サーバー、同じクラスタ内の複数のサーバー、または別々のクラスタのサーバーにもデプロイできます。

ノート:

WebLogic Serverでは、移行可能なターゲットに宛先をデプロイする場合、クラスタ内の連結されていない宛先およびMDBはサポートされていません。

JMS分散宛先

MDBアプリケーションがOracle WebLogic Serverクラスタで動作している場合は、複数の物理的宛先(キューまたはトピック)を、メッセージ・プロデューサやコンシューマからは1つの宛先に見える分散宛先として構成できます。

分散宛先を構成する場合、WebLogic JMSは、分散宛先の使用可能なメンバー全体に渡ってメッセージング・ロードを分散します。宛先のメンバーがサーバー障害によって使用できなくなる場合、メッセージ・トラフィックは、分散宛先セットにある他の使用可能な物理的な宛先にリダイレクトされます。weblogic-ejb-jar.xmlファイルのdistributed-destination-connection要素またはdistributedDestinationConnectionアノテーションを使用して、同一クラスタ内のWebLogic分散キューにアクセスするMDBが、すべての分散宛先メンバーから消費するか、または現在のOracle WebLogic Serverに対してローカルのメンバーのみから消費するかどうかを管理できます。同様に、JMSトピックを使用したMDBの構成とデプロイおよびトピック・デプロイメント・シナリオで説明されているように、この設定は一部のトピックMDBシナリオの動作を管理します。

MDBおよび関連する分散キューを同一のクラスタにデプロイする場合、Oracle WebLogic Serverは自動的に分散キュー・メンバーを列挙し、各メンバーが少なくとも1つのMDBプールによってサービスされることを保証します。分散キューについては、distributedDestinationConnectionがLocalOnly(デフォルト)のとき、各ローカル・メンバーに1つのMDBプールがあることになります。それ以外の場合、キューについては、distributedDestinationConnectionがEveryMemberに設定されているとき、各Oracle WebLogic Serverインスタンスは複数のローカルMDBプール(各ローカル・メンバーに1つ + 各リモート・メンバーに1つ)を作成します。

MDBおよびその関連付けられたキューを異なるクラスタにデプロイする場合、Oracle WebLogic Serverは自動的に分散キュー・メンバーを列挙し、各メンバーがMDBクラスタ内の各サーバー上にあるMDBプールによってサービスが提供されることを保証します。たとえば、分散キューに3つのメンバーが含まれる場合、MDBクラスタ内の各JVMは3つのMDBプールを作成します。

分散トピックの詳細は、JMSトピックを使用したMDBの構成とデプロイを参照してください。

ベスト・プラクティス

WebLogicクラスタリングおよびWebLogic JMS分散宛先は、拡張性と高可用性を増加します。拡張性と高可用性を増加するためのいくつかのベスト・プラクティスを調べます。

適切にロード・バランシングされたメッセージ処理を保証するために、クラスタをホストするマシンが同一または同程度の処理能力、ディスク容量、およびメモリーを持つことをお薦めします。同様に、特定のWebLogicクラスタ内のOracle WebLogic Serverインスタンスは、均一のJMS構成およびMDBデプロイメントを持つことをお薦めします。

例については、図4-1を参照してください。分散宛先の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』の分散宛先の使用に関する項を参照してください。