拡張JMSシステム・リソースの構成

WebLogic JMSクラスタリングの構成

WebLogic Serverのクラスタとはドメイン内で連携して動作するサーバーのグループであり、単一のサーバーよりもスケーラブルで信頼性のあるアプリケーション・プラットフォームを提供します。クラスタはそのクライアントからは単一のサーバーに見えますが、実は一体で機能するサーバー群です。

JMSクラスタリングの利点

JMSクラスタリングには、以下のメリットがあります。

クラスタ内の複数のサーバーにわたる宛先のロード・バランシング

管理者は、次のようにして、クラスタ内の複数のサーバーにわたって宛先のロード・バランシングを設定できます。
- 1つのJMSサーバーを構成し、1つのWebLogicクラスタをターゲットに指定します。「簡略化されたJMSクラスタと高可用性の構成」を参照してください
- 複数のJMSサーバーを構成し、構成済の複数のWebLogic Serverをターゲットに指定する。
- 複数のJMSサーバーを構成し、1つの移行可能なターゲットのセットをターゲットに指定する。
各JMSサーバーは、厳密に1つのWebLogic Serverインスタンスにデプロイされ、宛先の集合に対するリクエストを処理します。
宛先の高可用性
- 分散宛先: 分散宛先のキューおよびトピック・メンバーは通常、クラスタ内の複数のサーバーに分散され、各メンバーは個々のJMSサーバーに属します。分散宛先を使用するアプリケーションは、単純な宛先を使用するアプリケーションより可用性が高くなります。WebLogic JMSは、クラスタ内の分散宛先のメンバーのためのロード・バランシングとフェイルオーバーの機能を備えているからです。分散宛先の詳細については、「分散宛先リソースの構成」を参照してください
- ストア・アンド・フォワード: JMSモジュールはSAFサービスを使用して、ローカルのJMSメッセージ・プロデューサがリモートのキューまたはトピックに確実にメッセージを送信できるようにします。ネットワークの問題やシステム障害が原因で、メッセージの送信時に宛先が使用不能になっている場合、メッセージはローカルのサーバー・インスタンスに保存され、リモートの宛先が使用可能になった時点で転送されます。『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のストア・アンド・フォワード・サービスの理解に関する項を参照してください。
- 自動フェイルオーバーの場合、WebLogic Serverはサーバー・レベル(サーバー・インスタンス全体)での移行をサポートします。WebLogic Serverがホストするすべてのサービスを別のマシンに自動または手動で移行できます。Oracle WebLogic Serverクラスタの管理のサーバー全体の移行を参照してください。
  
  WebLogic Serverは、JMSのサービス・レベルの自動移行もサポートしており、障害が発生したサービス・インスタンスを現在のWebLogic Server JVMで再起動するか、同じクラスタ内にある別の実行中のJVMに移行できます。これは「サービス移行」と呼ばれ、JMSの構成方法とターゲット指定方法に応じて、2つの構成アプローチがあります。詳細は、「移行可能ターゲット」および「簡略化されたJMS構成と高可用性の拡張機能」を参照してください。新しい構成では、後者をお薦めします。
クラスタ内のあらゆるサーバーからの、宛先へのクラスタ全体で透過的なアクセス

管理者は、クラスタ内の各サーバー・インスタンスのデフォルト接続ファクトリを使用するか、1つまたは複数の接続ファクトリを構成してクラスタ内の1つまたは複数のサーバー・インスタンスまたはクラスタ全体をターゲットとすることで、クラスタ内のあらゆるサーバーから宛先へのクラスタ全体で透過的なアクセスを確立できます。これにより、各接続ファクトリを複数のWebLogic Serverインスタンスにデプロイできます。接続ファクトリについては、「接続ファクトリの構成」を参照してください
スケーラビリティ
- クラスタ内の複数のサーバーにわたる宛先のロード・バランシング。
- 接続ファクトリを通じた、複数のJMSサーバーでのアプリケーション負荷の分散。その結果として、個々のJMSサーバーでの負荷が削減され、かつ接続先を特定のサーバーに決めることでセッションの集中が可能となります。
JMSクライアントに対するサーバー・アフィニティ

クラスタ用に構成したロード・バランシング・アルゴリズム(ラウンドロビン・アフィニティ、重みベース・アフィニティ、またはランダム・アフィニティ)は、JMSクライアント接続のためのサーバー・アフィニティを提供します。JMSアプリケーションから指定したサーバー・インスタンスに接続できる場合、JMSは同じサーバー・インスタンスとの新しいJMS接続を確立しようとします。サーバー・アフィニティの詳細は、Oracle WebLogic Serverクラスタの管理のクラスタでのロード・バランシングを参照してください。

WebLogicクラスタの使用による機能と利点の詳細は、Oracle WebLogic Serverクラスタの管理のWebLogic Serverのクラスタリングの理解を参照してください。

JMSクラスタリングの仕組み

管理者は、クラスタ内の各サーバー・インスタンスのデフォルト接続ファクトリを使用するか、1つまたは複数の接続ファクトリを構成してクラスタ内の1つまたは複数のサーバー・インスタンスまたはクラスタ全体をターゲットとすることで、クラスタ内のあらゆるサーバーからJMS宛先へのクラスタ全体で透過的なアクセスを確立できます。これにより、各接続ファクトリを複数のWebLogic Serverにデプロイできます。接続ファクトリの構成とデプロイメントの詳細は、「接続ファクトリの構成パラメータ」を参照してください。

メッセージング・アプリケーションでは、Java Naming and Directory Interface (JNDI)を使用して接続ファクトリをルックアップし、その接続ファクトリを使用してクライアントからクラスタへの接続を作成します。クライアント・アプリケーションが接続ファクトリのクラスタの外にある場合は、クラスタ内の接続ファクトリのターゲットの1つであるサーバーに暗黙的に接続します(このサーバーは、JNDIコンテキスト自体が使用しているサーバーとは異なる場合があります)。アプリケーションがWebLogic Serverで実行しており、同じサーバーが接続ファクトリのターゲットの1つである場合、クライアント接続では単にローカルのWebLogic Serverに接続します。各JMSサーバーでは、複数の宛先に対するリクエストが処理されます。宛先へのリクエストが、JMSサーバーまたは宛先をホストしていないWebLogic Server接続ホストに送信される場合、または別のWebLogic Serverにロード・バランシングされる場合、リクエストは接続ホストによって、同じクラスタ内の、JMSサーバーとその宛先をホストしている適切なWebLogic Serverインスタンスに転送されます。

管理者は、クラスタ内の様々なサーバー上の複数のJMSサーバーに一意の名前が付けられているかぎり、それらのJMSサーバーを構成して、JMSキューまたはトピック・リソースを割り当てることができます。または、クラスタの1つのJMSサーバーをターゲットにして、そのクラスタの各サーバーにJMSサーバーのインスタンスが自動的に作成されるようにすることもできます。アプリケーションでは、Java Naming and Directory Interface (JNDI)を使用して接続ファクトリをルックアップし、JMSサーバーとの通信を確立するための接続を作成します。各JMSサーバーでは、複数の宛先に対するリクエストが処理されます。JMSサーバーで処理されない宛先へのリクエストは、適切なWebLogic Serverインスタンスに転送されます。JMSサーバーの構成とデプロイメントの詳細は、「JMSサーバーの構成」を参照してください。

JMSクラスタリングのネーミング要件

単一のWebLogicドメイン環境または複数ドメイン環境でJMSオブジェクトおよびリソース(JMSサーバー、JMSモジュール、JMSリソースなど)がクラスタ化された環境で動作するように構成する際には、いくつかの命名要件があります。「JMS構成のネーミング要件」を参照してください

クラスタ内での分散宛先

分散宛先リソースは、単一の論理的な宛先としてクライアントからアクセス可能な1つの宛先セット(キューまたはトピック)です(たとえば分散トピックは独自のJNDI名を持ちます)。この単位のメンバーは通常、クラスタ内の複数のサーバーに分散されており、各メンバーは個々のJMSサーバーに属しています。分散宛先を使用するアプリケーションは、単純な宛先を使用するアプリケーションより可用性が高くなります。WebLogic Serverは、クラスタ内の分散宛先のメンバーのためのロード・バランシングとフェイルオーバーの機能を備えているからです。「分散宛先リソースの構成」を参照してください

クラスタ内での移行可能なサービスとしてのJMSサービス

JMSサービスは、サーバー全体の移行(サーバーでホストされるすべてのサービスを別のマシンに移行する場合)だけでなく、シングルトン・サービスの移行フレームワークに組み込むこともできます。したがって、たとえばサーバーの障害に対処する場合や定期的な保守を実施する場合に、管理者はJMSサーバーとそのすべての宛先をクラスタ内の別のWebLogic Serverに移行することも可能です。これには、予定されている手動移行のほかに自動移行も含まれます。JMSサービスの移行の詳細は、「JMS関連サービスの移行」を参照してください。

JMSクラスタリングの構成のガイドライン

クラスタ環境でWebLogic JMSを使用する場合は、以下のガイドラインに従います。

クラスタ化環境を構成します。Oracle WebLogic Serverクラスタの管理のWebLogicクラスタの設定を参照してください。
WebLogic Server管理コンソールを使用して、ユーザー定義のJMS接続ファクトリのターゲットを指定します。接続ファクトリ用には、単一のサーバー、クラスタ、または移行可能なターゲットを指定できます。

接続ファクトリの構成属性の詳細は、「接続ファクトリの構成」を参照してください
必要に応じて、WebLogic Server管理コンソールを使用してJMSサービス用の移行可能なサーバー・ターゲットまたはクラスタ(JMSサーバーと永続ストア)を指定します。たとえば、JMSサーバーの場合は次のものを指定できます。:
- 1つの構成済のサーバー
- 1つのクラスタ。「簡略化されたJMSクラスタと高可用性の構成」を参照してください
- 移動可能なターゲット(クラスタ内にあるサーバー・インスタンスのセットで、クラスタ内で1台のサーバーに障害が発生した場合に、JMSのような「必ず1回」のサービスをホストできるもの)。移行可能なJMSサーバー・ターゲットの詳細は、「JMS関連サービスの移行」を参照してください
JMSサーバーの構成属性の詳細は、「JMSサーバーの構成」を参照してください
必要に応じて、クラスタ内に物理JMS宛先を仮想的な分散宛先セットの一部として構成できます。詳細については、「クラスタ内での分散宛先」を参照してくださいベスト・プラクティスは、常にサブデプロイメント・ターゲットを使用して宛先のターゲット指定を行うことです。サブデプロイメント・ターゲットにより、1つ以上の特定のSAFエージェント(インポート済宛先の場合)またはJMSサーバー(その他すべてのタイプの宛先の場合)が参照されます。

詳細は、「JMSビギナーおよび上級ユーザーのためのベスト・プラクティス」を参照してください。

フェイルオーバーの場合

ノート:

WebLogic JMS自動再接続機能は、非推奨になりました。この機能のためのJMS接続ファクトリ構成、javax.jms.extension.WLConnection APIおよびjavax.jms.extension.JMSContext APIは、将来のリリースでは削除または無視されます。『Oracle WebLogic Server JMSリソースの管理』のクライアント・レジリエンシのベスト・プラクティスに関する項で説明されているように、クライアント・アプリケーションが接続例外を処理することをお薦めします。

JMSシステムのレジリエンシは、基本的に2つのレベルで対処されます。1つ目は、この項および後続の項で説明するように、移行を介したJVMおよびサービス・レベルで、2つ目は、障害発生後にクライアントが確実に再接続および再試行できるようにするAPIレベルです。障害発生後のクライアントの再接続および再試行の詳細は、『Oracle WebLogic Server JMSリソースの管理』のクライアント・レジリエンシのベスト・プラクティスに関する項を参照してください。

さらに、サービスの自動移行機能を実装すると、JMSのような「必ず1回」のサービスによって、クラスタ内の依存するアプリケーションに対するシングル・ポイント障害が発生しなくなります。動的クラスタをターゲットとして指定されたJMSサーバーのフェイルオーバーでは、フェイルバックおよび再起動インプレース機能を利用できます。「JMS関連サービスの移行」を参照してくださいWebLogic Serverでは、サーバー・レベルの移行、つまり、サーバー・インスタンス全体の移行もサポートされています。また、サーバー・インスタンスがホストするすべてのサービスを自動または手動で別のマシンに移行できます。Oracle WebLogic Serverクラスタの管理のサーバー全体の移行を参照してください。

クラスタ化環境では、WebLogic Serverは分散宛先を構成することによって1つのサーバーで障害が発生した場合でもサービスを継続できます。分散宛先では、キューおよびトピック・メンバーは通常、クラスタ内の複数のサーバーに分散され、各メンバーは個々のJMSサーバーに属します。「クラスタ内での分散宛先」を参照してください

また、高可用性クラスタリング・ソフトウェアを実装することをお薦めします。これにより、WebLogic Serverベースのアプリケーションに、統合された使いやすいソリューションがもたらされます。

JMS関連サービスの移行

JMS関連サービスはシングルトン・サービスであるため、クラスタ内のすべてのサーバー・インスタンスでアクティブになるわけではありません。かわりに、サービスがクラスタ内の単一サーバーに固定され、データの一貫性を保持します。

シングルトンJMSサービスが原因で、クラスタ内の依存するアプリケーションに対するシングル・ポイント障害が発生しないようにするため、クラスタをターゲットとしたJMSまたは移行可能ターゲットJMSを使用して、JMS関連サービスを高可用性用に構成できます。「移行可能ターゲット」および「簡略化されたJMS構成と高可用性の拡張機能」を参照してください。新しい構成では、後者をお薦めします。また、定期的なサーバー・メンテナンスを実施する前に、JMSサービスを手動で移行することも可能です。

移行可能なJMS関連サービスには以下が含まれます:

JMSサーバー: ターゲット指定されているJMSモジュール内のキューおよびトピックの管理コンテナです。「JMSサーバーの構成」を参照してください
ストア・アンド・フォワード(SAF)サービス: メッセージが送信された時点でリモート・エンドポイントが使用できない場合でも、ローカルの送信エンドポイントとリモートの受信エンドポイントの間でメッセージをストア・アンド・フォワードするサービスです。JMS SAF(送信機能のみ)用に構成された送信SAFエージェントのみを移行できます。『Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理』のストア・アンド・フォワード・サービスの理解に関する項を参照してください。
パス・サービス: JMSメッセージ順序単位内のメッセージのグループからクラスタ内のメッセージ・リソースへのマッピングの保持に使用できる永続マップです。パス・サービスは、クラスタごとに1つずつ構成します。「WebLogicパス・サービスの使用」を参照してください
カスタム永続ストア: ユーザーが定義するディスク・ベースのファイル・ストアまたはJDBC対応データベースです。JMSメッセージやストア・アンド・フォワード・メッセージなどのサブシステム・データを格納するために使用します。『Oracle WebLogic Serverサーバー環境の管理』のWebLogic永続ストアの使用に関する項を参照してください。

Oracle WebLogic Serverクラスタの管理のサービスの移行フレームワークの理解を参照してください。

JMSサービスの自動移行

管理者は、ヘルス監視サブシステムを活用することで、障害が発生した現在のホスト・サーバーでホストされているJMSサービスが正常に動作しているサーバーに自動的に移行するよう、移行可能ターゲットを構成できます。JMS関連サービスの自動移行の構成の詳細は、Oracle WebLogic Serverクラスタの管理のJMS関連サービスの自動移行を構成するためのロードマップを参照してください。

JMSサービスの手動移行

ホスト・サーバーで障害が発生した場合や、サーバー・メンテナンスを実施する前には、JMS関連サービスを正常なサーバーに手動で移行できます。JMS関連サービスの手動移行の構成の詳細は、Oracle WebLogic Serverクラスタの管理のJMS関連サービスの手動移行を構成するためのロードマップを参照してください。

ノート:

手動での移行には移行可能ターゲットが必要なため、クラスタをターゲットとしたJMS構成で簡略化されたJMSクラスタと高可用性の構成を利用する場合には、手動での移行は選択肢になりません。「簡略化されたJMSクラスタと高可用性の構成」で自動フェイルバックがサポートされているため、このタイプの構成では、手動での移行の必要性が大幅に少なくなります。

永続ストアの高可用性

「フェイルオーバーの場合」で説明されているように、カスタム永続ストアを含むJMSサービスは、「サーバー全体」の移行機能の一部として移行したり、移行可能なJMS関連サービスをターゲットとした「サービス・レベル」の移行の一部として移行できます。

ファイル・ストアは、その実行場所に関係なく、存続期間全体にわたって同じファイルを使用する必要があります。つまり、移行されたファイル・ストアが移行前に更新したものと同じファイルにアクセスできるようにすることは、管理者の責任です。

移行可能なカスタム・ファイル・ストアは、クラスタ内の移行可能なターゲット・サーバーから使用できる共有ディスクに構成したり、移行可能なターゲットHA構成を使用している場合には、移行前/移行後スクリプトを使用してバックアップ・サーバー・ターゲットに移行したりできます。永続ストアの移行の詳細は、Oracle WebLogic Serverクラスタの管理のJMSサービスで使用できるカスタム・ストアを参照してください。『WebLogic永続ストアの管理』のファイルの場所に関する項を参照してください。

同様に、サーバー全体の移行またはJTA移行を設定する際には、デフォルトのファイル・ストアが共有ディレクトリの場所に配置されている必要があります。

最後に、移行されたJDBCストアは、移行後も元の場所と同じデータベースおよびスキーマにアクセスできる必要があります。

WebLogicパス・サービスの使用

WebLogic Serverパス・サービスは、JMSメッセージ順序単位内のメッセージのグループとクラスタ内のメッセージ・リソースの間のマッピングの保持に使用する永続マップです。

パス・サービスは、サーブレットをホストするクラスタのメンバー、分散キュー・メンバー、またはストア・アンド・フォワード・エージェントにメッセージを固定することによって、順序付けを実現します。パス・サービスは、クラスタごとに1つずつ構成します。メッセージ順序単位機能の詳細は、『Oracle WebLogic Server JMSアプリケーションの開発』のメッセージ順序単位の使用に関する項を参照してください。

クラスタにパス・サービスを構成する方法については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのパス・サービスの構成を参照してください。

パス・サービスによる高可用性

パス・サービスで高可用性を達成するには、様々な方法があります。

サーバー全体の移行を使用して、パス・サービスが実行されるWebLogic Serverを再起動できます。『Oracle Fusion Middlewareクラスタの管理』を参照してください。『Oracle WebLogic Serverクラスタの管理』のサーバー全体の移行に関する項を参照してください。
パス・サービスは、シングルトン分散ポリシーを使用して、クラスタをターゲットにしたストアを使用できます。「簡略化されたJMSクラスタと高可用性の構成」を参照してください
パス・サービスとそのストアを構成して、移行可能なターゲットを使用できます。ただし、移行可能なパス・サービスではデフォルト・ストアを使用できないため、カスタム・ストアを構成し、同じ移行可能ターゲットにターゲット指定する必要があります。さらに、ベスト・プラクティスとしては、その移行可能ターゲットのユーザーを、パス・サービスとそのカスタム・ストアに限定する必要があります。『Oracle WebLogic Serverクラスタの管理』のサービスの移行フレームワークの理解に関する項を参照してください。

メッセージUOOとパス・サービスの実装

メッセージ順序単位とパス・サービス・ベースのルーティングを実装する際には、次の点に留意してください。

各パス・サービス・マッピングは永続ストアに格納されます。パス・サービスを構成する場合、高可用性ソリューションを使用する永続ストアを選択します。「永続ストアの高可用性」を参照してください
複数のプロデューサが同じ順序単位名を使用してメッセージを送信する場合、すべてのメッセージは同じパス・エントリを共有し、同じメンバー・キュー宛先を持ちます。
順序単位名に必要なルートにアクセスできない場合、メッセージを送信したプロデューサはJMSOrderExceptionを送出します。この例外がスローされるのは、JMSメッセージ・システムが必要なサービス品質を満たすことができないからです。特定の順序単位名に対しては、1つの分散宛先メンバーのみがメッセージを消費できます。
パス・エントリは、最後のプロデューサと最後のメッセージ参照が削除されたときに自動的に削除されます。
システムによっては、パス・サービスを使用するとシステムのスループットが低下する場合があります。これは、パス・エントリを作成、読み取り、および削除するためのリモート・ディスク処理が原因で起こります。
分散キューとその個々のメンバーは、一意の宛先を表します。例:

DXQ1は、Q1とQ2というメンバーを持つ分散キューです。またDXQ1はFredという名前の順序単位を持ち、パス・サービスによってQ2メンバーにマップされています。
- メッセージM1がDXQ1に送信されると、パス・サービスによってQ2へのルートが定義されます。
- メッセージM1が直接Q2に送信されると、パス・サービスによるルーティングは行われません。これは、アプリケーションが直接Q2を選択し、分散宛先からメンバーを選択するよう要求されなかったからです。
- パス・サービスを使用する場合は、メッセージを分散宛先に送信します。使用しない場合は、直接メンバーに送信します。
- ある分散キューの中に、同じ順序単位名の宛先が複数存在してもかまわません。例:
  
  Fredという順序単位名のキューQ3が存在するとします。Q3がDXQ1に追加された場合は、分散キューの中に同じ順序単位名の宛先が2つ存在することになります。Q3とDXQ1は同じ順序単位名Fredを共有しますが、それぞれが一意のルートと宛先を持っており、これによりサーバーは宛先ごとに適切なメッセージ順序付けを提供し続けることができます。
分散キューからキューを削除する前や、分散キューにキューを追加する前には、キューを空にします。削除されたメンバーのパス・エントリはパス・サービスによって削除されますが、短い遷移期間が発生します。ここでは、キューが削除されているのにパス・エントリがまだ存在する場合に、生成されたメッセージによって例外JMSOrderExceptionがスローされる場合があります。

外部サーバー・リソースからサード・パーティJMSプロバイダへのアクセスの構成

WebLogic JMSでは、サード・パーティJMSプロバイダをローカルWebLogic Server JNDIツリー内で参照できます。JMSモジュール内で外部サーバー・リソースを使用することで、外部のJMSプロバイダを即座にマップして、関連付けられた接続ファクトリと宛先をローカルJMSオブジェクトのようにWebLogic JNDIツリーに表示できます。

また、別のクラスタまたはドメインにあるWebLogic Serverのリモート・インスタンスをローカルWebLogic JNDIツリー内で参照することもできます。リモートおよび外部JMSプロバイダの統合の詳細は、Oracle WebLogic Server JMSアプリケーションの開発のEJBとサーブレットにWebLogic JMSを使用するための拡張2EEサポートを参照してください。

以下の節では、外部サーバーの機能と、リモートMQSeries JNDIプロバイダにアクセスするためのサンプル構成について説明します。

WebLogic JMSから外部JMSプロバイダへのアクセス

外部JMSサーバーがデプロイされると、WebLogic Server JNDIにローカルの接続ファクトリと宛先のオブジェクトが作成されます。外部接続ファクトリまたは宛先のオブジェクトがローカル・サーバーでルックアップされると、そのオブジェクトはリモートJNDIディレクトリで実際のルックアップを実行し、そのディレクトリから外部オブジェクトが返されます。

この方法を使用すると、複数のWebLogicメッセージング・ブリッジ送り先の構成が簡単になります。外部サーバーが、JNDI初期コンテキスト・ファクトリおよび接続URLの構成の詳細をメッセージング・ブリッジ送り先の構成の外側に移すからです。外部接続ファクトリおよび宛先JNDI名をオブジェクトごとに指定するだけで済みます。

メッセージング・ブリッジの構成の詳細は、Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理で、メッセージング・ブリッジの構成と管理を参照してください。

また、この構成の簡素化は、WebLogic JMSでのWebLogicサーブレット、EJB、およびメッセージドリブンBean (MDB)の構成にも当てはまります。たとえば、MDBのweblogic-ejb-jar.xmlファイルではローカルJNDI名を指定でき、外部JMSサーバーを使用してMDBがメッセージを受け取る場所を制御できます。具体的には、あるJMS宛先およびサーバーと通信するためにある環境でMDBをデプロイし、同じweblogic-ejb-jar.xmlファイルを別のサーバーにデプロイして、それを別のJMS宛先と通信させることができます。その際、weblogic-ejb-jar.xmlファイルを復元して編集する必要はありません。

外部サーバー・リソースを作成する

外部サーバーには、ローカルWebLogic ServerインスタンスがリモートJNDIプロバイダにアクセスするための情報が保持されています。外部サーバーには、ローカルWebLogic ServerインスタンスがリモートJNDIプロバイダにアクセスするための情報が保持されています。これにより、1つのJNDIディレクトリに対して複数の外部接続ファクトリと宛先のオブジェクトを定義できます。

WebLogic Server管理コンソールを使用すると、システム・モジュール内の外部サーバー・リソースを構成、変更、ターゲット指定、および削除できます。外部サーバーのタスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの外部サーバーの構成を参照してください。

ノート:

エンタープライズ・アプリケーション内でのJMSアプリケーション・モジュールの構成およびデプロイについては、「JMSアプリケーション・モジュールのデプロイメントの構成」を参照してください。

一部の外部サーバー・オプションは、動的に構成できます。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべての外部サーバー・オプションのデフォルト値の詳細は、Oracle WebLogic Server MBeanリファレンスのForeignServerBeanを参照してください。

外部サーバーを定義したら、接続ファクトリおよび宛先のオブジェクトを構成できます。各外部サーバーに対して、1つまたは複数の接続ファクトリおよび宛先(キューまたはトピック)を構成できます。

外部接続ファクトリ・リソースを作成する

JMSモジュール内の外部接続ファクトリ・リソースには、リモートJNDIプロバイダの接続ファクトリのJNDI名、ローカルWebLogic Server JNDIツリー内でその接続ファクトリにマップされるJNDI名、およびユーザー名とパスワード(オプション)が定義されます。

外部接続ファクトリは、親の外部サーバーの割当て先となる各WebLogic Serverインスタンスに対してレプリケートされていないJNDIオブジェクトを作成します(クラスタ内の各ノードにJNDIオブジェクトを作成するには、クラスタに外部サーバーを割り当てます)。

外部宛先リソースを作成する

JMSモジュール内の「外部宛先です」リソースは、キューまたはトピックを表します。外部宛先には、外部JNDIプロバイダでルックアップされる宛先のJNDI名、およびローカルWebLogic Serverで宛先がマップされるJNDI名が保持されます。外部宛先がローカル・サーバーでルックアップされる場合、ルックアップはリモートJNDIディレクトリで実行され、そのディレクトリから宛先オブジェクトが返されます。

MQSeries JNDI用のサンプル構成

表4-1に、リモートMQSeries JNDIプロバイダにアクセスする場合のサンプル構成を示します。

表4-1 MQSeriesサンプル構成

外部JMSオブジェクトオプション名サンプル構成データ

外部JMSオブジェクト	オプション名	サンプル構成データ
外部サーバー	名前 JNDI初期コンテキスト・ファクトリ JNDI接続URL JNDIプロパティ	`MQJNDI` `com.sun.jndi.fscontext.RefFSContextFactory` `file:/MQJNDI/` (必要な場合、カンマ区切りのname=valueプロパティ・リストを入力します)。
外部接続ファクトリ	名前ローカルJNDI名リモートJNDI名ユーザー名パスワード	`MQ_QCF` `mqseries.QCF` `QCF` `weblogic_jms` `weblogic_jms`
外部宛先1	名前ローカルJNDI名リモートJNDI名	`MQ_QUEUE1` `mqseries.QUEUE1` `QUEUE_1`
外部宛先2	名前ローカルJNDI名リモートJNDI名	`MQ_QUEUE2` `mqseries.QUEUE2` `QUEUE_2`

外部サーバー

名前

JNDI初期コンテキスト・ファクトリ

JNDI接続URL

JNDIプロパティ

MQJNDI

com.sun.jndi.fscontext.RefFSContextFactory

file:/MQJNDI/

(必要な場合、カンマ区切りのname=valueプロパティ・リストを入力します)。

外部接続ファクトリ

名前

ローカルJNDI名

リモートJNDI名

ユーザー名

パスワード

MQ_QCF

mqseries.QCF

QCF

weblogic_jms

外部宛先1

名前

ローカルJNDI名

リモートJNDI名

MQ_QUEUE1

mqseries.QUEUE1

QUEUE_1

外部宛先2

名前

ローカルJNDI名

リモートJNDI名

MQ_QUEUE2

mqseries.QUEUE2

QUEUE_2

分散宛先リソースの構成

JMSモジュールの分散宛先リソースは、クライアントから単一の論理的な宛先としてアクセスできる宛先(キューまたはトピック)のセットを表しています。たとえば、分散トピックには独自のJNDI名があります。このセットのメンバーは通常、クラスタ内の複数のサーバーに分散されており、各メンバーは別々のJMSサーバーに属しています。

分散宛先を使用するアプリケーションは、スタンドアロンの宛先を使用するアプリケーションより可用性が高くなります。これは、WebLogic JMSに、クラスタ内の分散宛先メンバーのためのロード・バランシングおよびフェイルオーバー機能があるためです。

以降の節では、分散宛先の作成、モニター、およびロード・バランシングを行う方法について説明します。

共通分散宛先と重み設定された分散宛先

ノート:

重み設定された分散宛先は、WebLogic Server 10.3.4.0では非推奨です。共通分散宛先を使用することをお薦めします。『Oracle WebLogic Serverの新機能』の重み設定された分散宛先に関する項を参照してください。

WebLogic Server 9.x以降には、共通分散宛先と重み設定された分散宛先という2種類の分散宛先が用意されています。WebLogic Server 9.xより前のリリースでは、WebLogic管理者が、物理宛先を分散宛先のメンバーとして機能するように手動で頻繁に構成する必要がありました。この方法は、追加のメッセージ負荷または容量に対応するメンバーを作成できるという柔軟性を備えていました。しかし、このような重み設定された分散宛先はクラスタ内で一貫してデプロイされなかったため、管理上およびアプリケーション上の問題が発生することもよくありました。このタイプの分散宛先は、公式には「重み設定された分散宛先」(WDD)と呼ばれます。

共通分散宛先(UDD)は、分散宛先アプリケーションの管理と開発を大幅に簡略化します。共通分散宛先を使用すると、送り先のメンバーを作成したり指定する必要がなくなりますが、かわりにWebLogic Serverを使用して、必要なメンバーをJMSモジュールの対象となるJMSサーバー上に均等に作成することもできます。この機能によって、重み、セキュリティ、永続性、ページング、割り当てなどに関する分散宛先パラメータのすべてを一貫して構成できます。

分散宛先メンバーを手動で調整する場合は、従来の重み設定された分散宛先の機能も依然として使用できます。ただし、クラスタ内で一貫してデプロイされていない重み設定された分散宛先に起因して起こり得る管理上およびアプリケーションの問題を回避するため、共通分散宛先を構成することをお薦めします。

アプリケーションでの分散宛先の使用の詳細は、Oracle WebLogic Server JMSアプリケーションの開発の分散宛先の使用を参照してください。

共通分散宛先の作成

WebLogic Server管理コンソールを使用すると、次のJMSシステム・モジュールのUDDリソースを構成、変更、ターゲット指定および削除できます。

ノート:

UDDリソースをオプションのHA構成設定でホスティングするために、単一クラスタをターゲットとして指定されたJMSサーバーと、関連付けられた永続ストアを作成しておくことをお薦めします。これはUDD構成をシンプル、スケーラブルにし、可用性を高めます。「簡略化されたJMSクラスタと高可用性の構成」を参照してくださいレプリケートされた分散トピックは、クラスタをターゲットとして指定されたJMSサーバーによってサポートされません(かわりに、パーティション化された分散トピックを使用します)。

共通分散宛先のタスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。

共通分散宛先オプションの中には、動的に構成できるものもあります。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。すべての共通分散宛先オプションのデフォルト値については、Oracle WebLogic Server MBeanリファレンスの次の項目を参照してください。

次の項では、共通分散宛先の追加情報を説明します。

共通分散キューおよびトピックをターゲット指定する

特定の単一インスタンスのJMSサーバーのみをターゲットとして指定でき、その1つのインスタンスでのみ実行できる、モジュール内のスタンドアロンのキューおよびトピック・リソースとは異なり、UDDは同じサーバーまたはクラスタ内の複数のJMSサーバー・インスタンスを対象として指定できます。

UDDをターゲットとして指定する方法はいくつかありますが、Oracleでは、その中の1つの方法のみを強くお薦めします。つまり、UDDを構成して、システム・モジュール・サブデプロイメントをターゲットとして指定し、そのサブデプロイメントが1つ以上のJMSサーバーを直接参照する方法です。その他すべてのターゲット指定方法は使用しないことを強くお薦めします。たとえば、デフォルトのターゲット指定を使用した宛先のターゲット指定や、クラスタまたはサーバー名を参照するサブデプロメントのターゲット指定などはお薦めしません。このベスト・プラクティスに従わない場合、意図せずにメッセージを失う可能性があります。

たとえば、jmssysmod-jms.xmlという名前のシステム・モジュールが、3つのWebLogic Serverインスタンス(wlserver1、wlserver2およびwlserver3)を含むクラスタへのターゲット指定が行われていて、各サーバーは構成済のJMSサーバーjmsserver1、jmsserver2およびjmsserver3によってターゲットとして指定されているとします。同じクラスタで共通分散キューを設定する場合は、UDQをjmsservergroupという名前のサブデプロイメントにグループ化して、UDQを目的のJMSサーバー・インスタンスに常にリンクさせることができます。同じサブデプロイメントを接続ファクトリに対して使用することもできます。次に、servergroupサブデプロイメント・リソースをjmssysmod-jms.xmlでどのように指定するのかを示します。

<weblogic-jms xmlns="http://xmlns.oracle.com/weblogic/weblogic-jms">
  <connection-factory name="MyCF">
    <sub-deployment-name>jmsservergroup</sub-deployment-name>
    <jndi-name>jms/MyCF</jndi-name>
  </connection-factory>
  <uniform-distributed-queue name="MyUDQ">
    <sub-deployment-name>jmsservergroup</sub-deployment-name>
    <jndi-name>jms/MyUDQ</jndi-name>
  </uniform-distributed-queue>
</weblogic-jms>

次に、ドメインのconfig.xmlファイルで、対応するサブデプロイメントがシステム・モジュールの対応するスタンザでどのように構成されるかを示します。

  <jms-system-resource>
    <name>jmssysmod-jms</name>
    <target>cluster1,</target>
    <sub-deployment>
      <name>jmsservergroup</name>
      <target>jmsserver1,jmsserver2,jmsserver3</target>
    </sub-deployment> 
    <descriptor-file-name>jms/jmssysmod-jms.xml</descriptor-file-name>
  </jms-system-resource>

個別に構成されてターゲット指定されたJMSサーバーjmserver1、jmserver2およびjmserver3のかわりに、クラスタをターゲットとして指定されたMyClusteredJMSServerという名前のJMSサーバーを利用する、簡略化されたJMS構成を使用している場合は、前述のサブデプロメントのターゲットは次のように簡略化されます。

<target>MyClusteredJMSServer</target>

これは、次のかわりになります。

<target>jmsserver1,jmsserver2,jmsserver3</target>

ノート:

Oracleでは、宛先は常にサブデプロメントをターゲットとして指定するように構成し、サブデプロメントが目的とする宛先のJMSサーバーを正確に参照するようにすることを強くお薦めします。デフォルトのターゲット指定を含め、その他の宛先のターゲット指定アプローチは使用しないことを強くお薦めします。(デフォルトで接続ファクトリをターゲット指定するのは問題ありません。)
UDDのターゲットを変更すると、メンバー宛先が削除され、その結果としてメッセージが失われてしまうおそれがあります。
WebLogicコンソールを使用して新しいUDDを作成すると、サブデプロイメントはその「高度なターゲット指定」オプションを介してアクセスされます。システム・モジュール・サブデプロイメント・タブで、サブデプロイメントを編集したり、新規作成することもできます。

UDDメンバーに対するメッセージ処理を休止、再開する

共通分散宛先でのメッセージの生成、挿入、および消費処理は、プログラム的に(JMXと実行時MBean APIを使用)、または管理的に(WebLogic Server管理コンソールを使用)休止および再開できます。外部リソースに障害が発生したとき、JMSサブシステムがメッセージの受け付けと配信(および再配信)を継続すると、システムに過度の負荷がかかることがあります。しかし、メッセージ処理を休止(および再開)することで、外部リソースの障害発生時のJMSサブシステムの動作を制御できます。

「休止と再開」の機能の詳細は、「宛先でのメッセージ処理の制御」を参照してください

UDDメンバーをモニターする

共通分散宛先メンバーの実行時統計は、WebLogic Server管理コンソールを使用してモニターできます。「JMS統計のモニター」を参照してください

パーティション化された分散トピックの構成

ノート:

パーティション化された分散トピックは、クラスタをターゲットとして指定されたJMSサーバーを使用して、WebLogicマルチテナントRGまたはRGTにスコープ指定された構成、または動的クラスタでは、唯一の分散トピック・タイプです。これらの場合に複製された分散トピックを設定しようとすると、構成エラーが生成されます。複製された分散トピックをパーティション化された分散トピックに置換する必要がある場合は、『Oracle WebLogic Server JMSアプリケーションの開発』の複製された分散トピックの置換に関する項を参照してください。

共通分散トピック・メッセージのForwarding Policyは、送信済メッセージがすべてのメンバーに転送されるかどうかを指定します。

有効な値は以下のとおりです。

Replicated: デフォルトです。すべての物理トピック・メンバーは各送信済メッセージを受信します。メッセージが物理トピック・メンバーのいずれかに着信する場合、該当する共通分散トピックの他のメンバーにこのメッセージのコピーが転送されます。いずれかの特定のメンバー上のサブスクリプションは、共通分散トピックの論理名または特定の共通分散トピック・メンバーに送信されたメッセージのコピーを取得します。
Partitioned: メッセージ受信側の物理メンバーは、メッセージを認識する共通分散トピックの唯一のメンバーです。メッセージがパーティション化された共通分散トピックの論理名にパブリッシュされるとき、特定の1つの物理トピック・メンバー上にのみ着信します。メッセージが物理トピック・メンバー上に着信すると、メッセージは共通分散宛先の残りのメンバーには転送されず、他の物理トピック・メンバー上のサブスクライバは当該メッセージのコピーを取得しません。

大半の新しいアプリケーションでは、次のように構成される共通分散トピック上の論理サブスクリプション・トポロジと組み合せて、Partitioned転送ポリシーを使用します。

各物理メンバー上で直接作成された同一名の物理サブスクリプション。
UnrestrictedのクライアントIDポリシー。
Sharableのサブスクリプション共有ポリシー。

パーティション化された分散トピックの作成および使用の詳細は、次を参照してください。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのシステム・モジュールにおけるパーティション化された共通分散トピックの作成。
『Oracle WebLogic ServerメッセージドリブンBeanの開発』の分散トピックを使用したMDBの構成およびデプロイに関する項
『Oracle WebLogic Server JMSアプリケーションの開発』の高度なPub/Subアプリケーションの開発に関する項

パーティション化された分散トピックのロード・バランシング

パーティション化されたトピックのパブリッシャには、接続ファクトリのAffinityおよびLoad Balance属性をチューニングすることによって、複数のメンバー全体に渡るメッセージのロード・バランシング・オプションがあります。「順序単位」メッセージは、UOOルーティング・ポリシーおよびサブスクライバ・ステータスに基づいて適切なメンバーにルーティングされます。Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリのロード・バランシング・パラメータの構成に関する項を参照してください。

重み設定された分散宛先の作成

ノート:

重み設定された分散宛先(WDD)は、WebLogic Server 10.3.4.0では非推奨です。共通分散宛先を使用することを強くお薦めします。

WebLogic Server管理コンソールを使用すると、JMSシステム・モジュール内のWDDリソースを構成、変更、ターゲット指定、および削除できます。分散トピックまたはキューを構成する場合、「メンバーの均等割当て」チェック・ボックスをクリアすることによって、既存のキューとトピックを手動で選択して分散宛先に追加し、分散宛先メンバーの重みを調整できます。

重み設定された分散宛先のタスクの手順については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次のトピックを参照してください。

重み設定された分散宛先のオプションには、動的に構成できるものもあります。オプションが実行時に変更された場合、変更は新しく配信されるメッセージにのみ適用され、格納されているメッセージには影響しません。重み設定された分散宛先の、すべてのオプションのデフォルト値の詳細は、Oracle WebLogic Server MBeanリファレンスの次の項目を参照してください。

UDDとは異なり、WDDメンバーはWebLogic Server管理コンソールまたは実行時MBeanでモニターできません。また、WDDメンバーはドメイン内のJMSサーバーまたはWebLogic Serverインスタンスに均等に割り当てることはできません。かわりに、これらのインスタンス上で新しいWDDメンバーを手動で構成し、手動でWDDに追加する必要があります。

分散宛先でのメッセージのロード・バランシング

JMSは分散宛先を使用して、複数の宛先にメッセージの負荷を分散し、バランスを取ることができます。これによって、リソースがさらに効率的に利用され、レスポンス時間が改善されます。JMSのロード・バランシング・アルゴリズムでは、メッセージの送信先となる物理宛先に加えて、コンシューマの割当て先の物理宛先も決定されます。

ロード・バランシングのオプション

WebLogic JMSは、任意の分散宛先セットに含まれている複数の物理宛先間でメッセージのロード・バランシングを行うための2種類のアルゴリズムをサポートしています。これらのロード・バランシング・オプションのどちらかを選択するには、WebLogic Server管理コンソールで分散トピックまたは分散キューを構成します。

ラウンドロビン分散

ラウンドロビン・アルゴリズムでは、WebLogic JMSは分散宛先内の物理宛先の順序を管理します。メッセージの負荷は、WebLogic Server構成(config.xml)ファイルに定義されている順番で、一度に1つずつ物理宛先に分散されます。各WebLogic Serverは同一の順序を維持しますが、その順序内の位置は異なります。特定の分散宛先を使用して単一のサーバー内で複数のスレッドを実行すると、スレッドからメッセージが生成されるたびに、メンバーが割り当てられている物理宛先に関連して、これらのスレッドが互いに影響し合うことになります。ラウンドロビンはデフォルトのアルゴリズムで、構成の必要はありません。

重み設定された分散宛先のみの場合、セット内の物理宛先のいずれかに重みが割り当てられている場合、それらの物理宛先は順序内に複数回発生します。

ランダム分散

ランダム分散アルゴリズムでは、物理宛先に割り当てられている重みを使用して、一連の物理宛先の重み付き宛先を計算します。メッセージの負荷は、疑似ランダム的に宛先にアクセスすることで、物理宛先に分散されます。短期的には、負荷は重みには直接比例しません。長期的には、極限に近い分散が行われます。純粋なランダム分散は、重みすべてに同じ値を設定することで達成できます。この値は通常1です。

メンバーが追加または削除された(管理者が行うか、WebLogic Serverがシャットダウンまたは再起動した結果発生したもの)場合は、分散を再計算する必要があります。ただし、このようなイベントは頻繁に発生せず、計算は通常単純で、O(n)時間で実行されます。

コンシューマをロード・バランシングする

アプリケーションがコンシューマを作成するときは、宛先を指定する必要があります。その宛先が分散宛先を表す場合、WebLogic JMSではコンシューマのメッセージの受信元になる物理宛先を見つける必要があります。使用する宛先メンバーの選択には、ロード・バランシング・アルゴリズム(「ロード・バランシングのオプション」を参照)のいずれかが使用されます。この選択は、コンシューマの作成時に1度だけ行われます。その後、コンシューマはそのメンバーのみからメッセージを受信するようになります。

プロデューサをロード・バランシングする

プロデューサがメッセージを送信するとき、WebLogic JMSはメッセージが送信される宛先を確認します。宛先が分散宛先である場合は、メッセージの送信先がWebLogic JMSによって決定されます。つまり、プロデューサは「ロード・バランシングのオプション」で説明されているロード・バランシングのアルゴリズムのいずれかに従って、宛先のメンバーのいずれかに送信します。

プロデューサはメッセージを送信するたびにこのような決定を行います。ただし、コンシューマとプロデューサ間の序列の保証が脅かされることはありません。コンシューマのロード・バランシングがいったん行われると、コンシューマは単一の宛先メンバーに固定されるためです。

ノート:

プロデューサが永続メッセージを分散宛先に送信しようとする場合、永続ストアを利用している分散メンバーにまずメッセージが転送されるよう、あらゆる努力がなされます。ただし、分散メンバーがいずれも永続ストアを利用していない場合でも、メッセージは選択されているロード・バランシング・アルゴリズムに従って、メンバーのいずれかに送信されます。

ロード・バランシングのヒューリスティック

「ロード・バランシングのオプション」に説明されているアルゴリズムに加えて、WebLogic JMSでは、宛先のインスタンスを選択するときに次のヒューリスティックが使用されます。

トランザクション・アフィニティ

トランザクション・セッション内で複数のメッセージを作成するときは、作成されたメッセージすべてを同じWebLogic Serverに送信しようとします。つまり、セッションが単一の分散宛先に複数のメッセージを送信した場合は、すべてのメッセージが同じ物理宛先に転送されます。セッションによって複数のメッセージが複数の異なる分散宛先に送信された場合は、同じWebLogic Serverがサービスを提供する一連の物理宛先が選択されるようになります。

サーバー・アフィニティ

接続ファクトリの「サーバー・アフィニティの有効化」パラメータでは、分散宛先内にある複数のメンバー宛先の間でコンシューマまたはプロデューサをロード・バランシングしているWebLogic Serverが、同じWebLogic Server上で実行されている他のローカル宛先メンバーの間でロード・バランシングを最初に試みるかどうかを定義します。

ノート:

「サーバー・アフィニティの有効化」属性は、キュー・ブラウザには影響しません。したがって、「サーバー・アフィニティの有効化」が有効になっている場合でも、分散キューに作成されたキュー・ブラウザをリモート分散キュー・メンバーに固定できます。

接続ファクトリでサーバー・アフィニティを無効化するには:

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリのロード・バランシング・パラメータの構成の説明に従って、「JMSコネクション・ファクトリ」→「構成」→全般ページに移動します。
「サーバー・アフィニティの有効化」フィールドを次のように定義します。
- 「サーバー・アフィニティの有効化」チェック・ボックスを選択します(trueとします)。この場合、分散宛先セット内にある複数の物理宛先の間でコンシューマまたはプロデューサをロード・バランシングしているWebLogic Serverは、同じWebLogic Server上で実行されている他の物理宛先の間でロード・バランシングを最初に試みます。
- 「サーバー・アフィニティの有効化」チェック・ボックスを選択しない場合(False)、WebLogic Serverは、分散宛先セット内の複数の物理宛先にまたがるコンシューマまたはプロデューサのロード・バランシングを実行し、同じWebLogic Serverで実行されている他の物理宛先を無視します。
「保存」をクリックします。

「サーバー・アフィニティの有効化」の設定が分散宛先のメンバー間のロード・バランシングにどのように影響するかについては、「サーバー・アフィニティを有効化した場合の分散宛先ロード・バランシングへの影響」を参照してください

コンシューマのないキュー

複数のリモートの物理的キュー間でコンシューマのロード・バランシングを行う場合、1つまたは複数のキューにコンシューマがないとき、それらのキューだけがロード・バランシングの対象となります。セット内の物理的キューすべてに少なくとも1つのコンシューマが含まれるようになると、標準のアルゴリズムが適用されます。

また、プロデューサがメッセージを送信するとき、コンシューマのないキューはメッセージ生成の対象にはなりません。ただし、任意のキューのインスタンスのいずれにもコンシューマが含まれていない場合を除きます。

分散宛先メンバーの休止

分散宛先でメッセージの生成または挿入が休止された場合、それらはメッセージ生成の対象とは見なされません。同様に、分散宛先でメッセージの消費が休止された場合、それらはメッセージ生成の対象とは見なされません。

宛先でのメッセージ処理の休止については、「宛先でのメッセージ処理の制御」を参照してください

JVM単位のロード・バランシング

分散宛先に順序単位以外のメッセージを送信する場合や、必ず1回のQoS SAFインポート済宛先に対して送信する場合は、「メンバー単位」ロード・バランシングの動作のかわりに、「JVM単位」を選択できます。

メンバー単位(デフォルト): ロード・バランシング・アルゴリズムは、アフィニティまたは他のヒューリスティックを考慮して、分散宛先のすべてのアクティブなメンバーを候補として見なします。このオプションは、すべてのメンバー間でメッセージを均等に配信するのに役立ちますが、メンバーがフェイルオーバーまたは移行した後、これらのJVMが他のメンバーより多くのメンバーをホストしている場合に、一部のJVMが他のJVMより多くのメッセージを取得する可能性があります。
JVM単位: 各JVMでホストされるメンバーの数に関係なく、ロード・バランシング・アルゴリズムで、各WebLogicサーバーJVM上の分散宛先の1つのメンバーのみが考慮されます。このオプションは、クラスタ内のすべてのWebLogicサーバーJVM間でメッセージを均等に分散する場合に役立ち、JVM上で、フェイルオーバーされた追加メンバーからメッセージを送るのに役立ちます。負荷が減少したために縮小したクラスタ内のサーバー間でメッセージを均等に分散する場合に役立ちますが、フェイルオーバー・メンバーの古い未処理メッセージを回復するために、フェイルオーバーされたメンバーを維持する場合もあります。

JVM単位のヒューリスティックは次のとおりです。

クラスタをターゲットとして指定されたJMSサーバーでホストされている分散宛先のメンバー、またはその優先サーバーで実行されているSAFエージェント(フェイルオーバーまたは移行されていないメンバーなど)の中から選択します。
分散宛先メンバーが、クラスタをターゲットとして指定されたJMSサーバーまたはSAFエージェントにホストされていない場合に、同じJVM上で名前が辞書順で最後になるメンバー名を選択します。
(1)のメンバーは(2)のメンバーより優先されます(両方が存在する場合)。2つのメンバーが(1)に当てはまる場合は、辞書順がより後ろのメンバーが選択されます。
システムが安定しているかぎり、各JVMの同じメンバー候補が、新しいプロデューサまたは新しいロード・バランシング・メッセージに対して選択されます。候補者は、メンバーの移行後、メンバーの再起動後またはメンバーの停止後に変更できます。
各WebLogic Server JVMでDDのメンバーが1つのみホストされている場合は、メンバー単位と同じように動作します。

ノート:

「JVM単位」または「メンバー単位」ヒューリスティックは、メッセージの消費、スタンドアロンまたはシングルトン宛先へのメッセージの送信、すべてのタイプの宛先へのUOOメッセージの送信には適用されません。

非順序単位メッセージに対するJMSメッセージ・プロデューサのJVM単位/メンバー単位のロード・バランシングを制御するには、カスタム接続ファクトリ上でProducerLoadBalancingPolicyを構成するか、コマンドライン・システム・プロパティを使用して動作を有効にします。構成可能な属性とシステム・プロパティの両方については、「LoadBalancingParamsBean.ProducerLoadBalancingPolicy」を参照してください。

SAFエージェントまたはクライアントSAFによって転送される、「必ず1回」の非順序単位メッセージのJVM/メンバー単位のロード・バランシングを制御するには、SAFImportedDestinationBeanのExactlyOnceLoadBalancingPolicy属性を構成するか、コマンドライン・システム・プロパティを使用して動作を有効にします。構成可能な属性とシステム・プロパティの両方については、SAFImportedDestinationBean.ExactlyOnceLoadBalancingPolicy」を参照してください。

ロード・バランシングを回避する

アプリケーションは、個別の物理宛先に直接アクセスすることで、ロード・バランシングを回避できます。つまり、物理宛先にJNDI名がない場合でも、createQueue()メソッドまたはcreateTopic()メソッドを使用して参照することができます。

共通分散宛先や重み設定された分散宛先のメンバーに直接アクセスする方法については、Oracle WebLogic Server JMSアプリケーションの開発の分散宛先メンバーへのアクセスを参照してください。

接続ファクトリ

アプリケーションにおいて、分散宛先を使用して、複数の物理宛先間でプロデューサやコンシューマを分散、つまりバランスさせることは行っても、メッセージが作成されるたびにロード・バランシングの決定を行いたくない場合は、「ロード・バランシングの有効化」パラメータを無効化した状態で接続ファクトリを使用します。分散宛先においてメッセージの負荷が適正に分散されるようにするには、プロデューサによって使用される初期の物理宛先(キューまたはトピック)が、物理宛先メンバーによって常にランダムに選択される必要があります。

接続ファクトリでのロード・バランシングを無効化するには:

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリのロード・バランシング・パラメータの構成の説明に従って、「JMSコネクション・ファクトリ」→「構成」→全般ページに移動します。
次のガイドラインに従って、「ロード・バランシングの有効化」フィールドを設定します。
- ロード・バランシングを有効化 = True
  
  Queue.sender.send()メソッドでは、分散キュー・メンバー間での呼出しごとに、匿名でないプロデューサがロード・バランシングされます。
  
  TopicPublish.publish()メソッドでは、「ロード・バランシングの有効化」設定に関係なく、匿名でないプロデューサが呼出しごとに常に同じ物理的なトピックに固定されます。
- ロード・バランシングを有効化 = False
プロデューサは失敗するまで常に同じ物理宛先に対して生成します。失敗すると、新しい物理宛先が選択されます。
「保存」をクリックします。

ノート:

実装によっては、「サーバー・アフィニティの有効化」属性の設定が分散宛先のロード・バランシングのプリファレンスに影響することがあります。「サーバー・アフィニティを有効化した場合の分散宛先ロード・バランシング」を参照してください。

匿名プロデューサ(作成時に宛先を指定しないプロデューサ)は、宛先を切り替えるたびにロード・バランシングされます。同じ宛先を使用し続けると、匿名でないプロデューサと同じ法則(前述)が適用されます。

サーバー・アフィニティを有効化した場合の分散宛先ロード・バランシングへの影響

表4-2では、接続ファクトリの「サーバー・アフィニティの有効化」パラメータの設定が、分散宛先メンバーのロード・バランシングのプリファレンスに与える影響について説明します。プリファレンス順位は、操作のタイプ、および恒久サブスクリプションまたは永続メッセージが含まれているかどうかによって異なります。

分散宛先の「サーバー・アフィニティを有効化」パラメータは、ClusterMBeanの「デフォルトのロード・バランス・アルゴリズム」属性によって提供されるサーバー・アフィニティとは異なります。後者は、JMS接続ファクトリでクライアント接続用の初期コンテキスト・アフィニティを作成するためにも使用されます。

『Oracle WebLogic Serverクラスタの管理』のEJBとRMIオブジェクトのロード・バランシングに関する項とクライアント接続の初期コンテキスト・アフィニティとサーバー・アフィニティに関する項を参照してください。

表4-2 サーバー・アフィニティのロード・バランシングのプリファレンス

操作	「サーバー・アフィニティを有効化」の設定	ロード・バランシングのプリファレンス
キューの`createReceiver()` トピックの`createSubscriber()`	True	コンシューマを持たないローカル・メンバーローカル・メンバーコンシューマを持たないリモート・メンバーリモート・メンバー
キューの`createReceiver()`	False	コンシューマを持たないメンバーメンバー
トピックの`createSubscriber()` (ノート: 非永続サブスクライバ)	trueまたはfalse	コンシューマを持たないローカル・メンバーローカル・メンバー
キューの`createSender()` トピックの`createPublisher()`	trueまたはfalse	作成されたJMSプロデューサのロード・バランシング用の、独立した機能は存在しません。JMSプロデューサは、JMS接続のロード・バランシングまたは固定が行われるサーバーで作成されます。接続ファクトリを使用して作成されたJMS接続のロード・バランシングの詳細は、Oracle WebLogic Serverクラスタの管理のEJBとRMIオブジェクトのロード・バランシングとクライアント接続の初期コンテキスト・アフィニティとサーバー・アフィニティを参照してください。
`QueueSender.send()`を使用する永続メッセージ	True	コンシューマとストアを持つローカル・メンバーコンシューマとストアを持つリモート・メンバーストアを持つローカル・メンバーストアを持つリモート・メンバーコンシューマを持つローカル・メンバーコンシューマを持つリモート・メンバーローカル・メンバーリモート・メンバー
`QueueSender.send()`を使用する永続メッセージ	False	コンシューマとストアを持つメンバーストアを持つメンバーコンシューマを持つメンバーメンバー
`QueueSender.send()`を使用する非永続メッセージ	True	コンシューマを持つローカル・メンバーコンシューマを持つリモート・メンバーローカル・メンバーリモート・メンバー
非永続メッセージの場合: `QueueSender.send()` `TopicPublish.publish()`	False	コンシューマを持つメンバーメンバー
セッション・プール・キューおよびトピックの`createConnectionConsumer()`	trueまたはfalse	ローカル・メンバーのみノート: セッション・プールは現在ほとんど使用されていません。理由は、Java EE仕様の必須の部分ではないこと、JTAユーザー・トランザクションをサポートしていないこと、そして大部分がメッセージドリブンBean (MDB)に取ってかわられたことです。MDBの方が簡単で管理しやすく、高機能です。

分散宛先の移行

サービス移行機能を利用するクラスタ化されたJMS実装では、JMSサーバーとその分散宛先メンバーを、クラスタ内の別のWebLogic Serverインスタンスに移行できます。サービスの移行は、定期的なシステム保守の際や、クラスタ内のサーバーに障害が発生した際に実施できます。

ただし、移行先のWebLogic Serverに物理宛先すべてを持つJMSサーバーがすでにホストされている場合もあります。そのような場合には、同じWebLogic Serverインスタンスが単一の分散宛先について2つの物理宛先をホストするような状況が生じます。WebLogic Serverインスタンスでは、そのような分散宛先に対して複数の物理宛先をホストできるため、これは短期的に見れば許容できる状況です。ただし、こうした状況ではロード・バランシングの効率が低下します。

このような状況では、移行先のWebLogic Serverインスタンス上のJMSサーバーは独立して動作します。これは、2つの送り先インスタンスがマージされたり、両方の送り先で1つのインスタンスが無効化されることを回避するために必要です。このようなことが発生すると、メッセージが長時間使用できなくなる場合があります。ただし、長期的な目的は、移行されたJMSサーバーをクラスタ内のさらに別のWebLogic Serverインスタンスに最終的に再移行することにあります。

JMSの移行可能ターゲットの構成については、「JMS関連サービスの移行」を参照してください。

分散宛先のフェイルオーバー

JMSプロデューサおよびJMSコンシューマのJMS接続をホストしているサーバー・インスタンスに障害が発生した場合、これらの接続を使用しているすべてのプロデューサとコンシューマは閉じられ、クラスタ内の別のサーバー・インスタンスで再作成されません。また、JMS宛先をホストしているサーバー・インスタンスに障害が発生した場合、その宛先のすべてのJMSコンシューマが閉じられ、クラスタ内の別のサーバー・インスタンスでは再作成されません。

キュー・プロデューサが作成された分散キュー・メンバーに障害が発生したが、プロデューサのJMS接続が存在するWebLogic Serverインスタンスがまだ実行されている場合、プロデューサはアクティブな状態を維持し、WebLogic JMSはロード・バランシングのオプションが有効になっているかどうかに関係なく、別の分散キュー・メンバーにフェイルオーバーします。

WebLogic Serverの障害から回復する手順については、Oracle WebLogic Server JMSアプリケーションの開発のサーバー障害からの回復を参照してください。

無制限ClientIDの構成

クライアントIDポリシーは、1つ以上のJMS接続がクラスタ内で同一のクライアントIDを使用できるかどうかを指定します。

このポリシーの有効な値は次のとおりです。

RESTRICTED: これはデフォルトです。このポリシーを使用する接続で、特定のクライアントIDのクラスタ内に常時存在できるのは、1つのみです(所定のクライアントIDを使用した接続がすでに存在する場合、このポリシーを同じクライアントIDで使用して新しい接続を作成しようとしても、例外が発生して失敗します)。
UNRESTRICTED: このポリシーを使用して作成された接続は、他の制限/無制限接続がすでに同一クライアントIDを使用している場合でも、任意のクライアントIDを指定できます。恒久サブスクリプションが無制限クライアントIDを使用して作成されるとき、そのサブスクリプションはweblogic.jms.extensions.WLSession.unsubscribe(Topic topic, String name)を使用してのみクリーン・アップできます。『Oracle WebLogic Server JMSアプリケーションの開発』のサブスクリプションの管理に関する項を参照してください。

特にサブスクリプション(恒久/非恒久)を共有する場合は、新しいアプリケーションに対してクライアントIDポリシーをUnrestrictedを設定することをお薦めします(使用するアプリケーションのアーキテクチャに排他的クライアントIDが必要な場合を除く)。異なるクライアントIDポリシーを使用して作成されたサブスクリプションは、常に単独のサブスクリプションとして扱われます。Oracle WebLogic Server MBeanリファレンスのClientIdPolicyに関する項を参照してください。

WebLogicコンソールを使用した接続ファクトリ上でクライアントIDポリシーを設定する場合、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの同一クライアントIDを使用した複数接続の構成に関する項を参照してください。接続ファクトリ設定は、Oracle WebLogic Server Java APIリファレンスのWLConnectionインタフェースのsetClientIDPolicyメソッドを使用して、プログラム的にオーバーライドできます。

ノート:

JMS接続ランタイム・オブジェクト上のクライアントIDポリシーのプログラムによる変更(オーバーライド)は、該当する特定の接続インスタンスおよび当該接続の存続期間中のみ有効です。接続ランタイム・オブジェクトへのいかなる変更も、基礎となるJMSモジュール記述子で定義される対応するJMS接続ファクトリ構成によって保存/反映されません。

クライアントIDポリシーを使用する方法の詳細は、次を参照してください。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの同一クライアントIDを使用した複数接続の構成に関する項
『Oracle WebLogic Server JMSアプリケーションの開発』の高度なPub/Subアプリケーションの開発に関する項

共有サブスクリプションの構成

サブスクリプション共有ポリシーは、サブスクライバが同一接続上の他のサブスクライバとサブスクリプションを共有できるかどうかを指定します。

このポリシーの有効な値は次のとおりです。

Exclusive: これはデフォルトです。この接続ファクトリを使用して作成されるすべてのサブスクライバは、サブスクリプションを他のサブスクリプションと共有できません。
Sharable: この接続ファクトリを使用して作成されたサブスクライバは、サブスクライバが同一の接続ファクトリまたは異なる接続ファクトリのどちらを使用して作成されたかに関係なく、サブスクリプションを他のサブスクライバと共有できるようになります。コンシューマは、同一のクライアントIDおよびクライアントIDポリシーを持つ場合にのみ非永続サブスクリプションを共有できます。また、同一のクライアントID、クライアントIDポリシー、およびサブスクリプション名を持つ場合にのみ永続スクリプトを共有できます。

WebLogic JMSアプリケーションは、javax.jms.Connectionインスタンスをweblogic.jms.extension.WLConnectionにキャストしてsetSubscriptionSharingPolicy(String)を呼び出すことによって、接続ファクトリ構成上で指定されるサブスクリプション共有ポリシーをオーバーライドできます。

サブスクリプション共有ポリシーを使用するアプリケーションのほとんどは、無制限クライアントIDポリシーを使用して、同一クライアントIDを使用する複数の接続が存続できようにします。

同一クライアントIDおよびサブスクリプション名を持つ2つの恒久サブスクリプションは、異なるクライアントIDポリシーを持つ場合、2種類の独自のサブスクリプションとして扱われます。同様に、同一クライアントIDを持つ2つの共有可能な非恒久サブスクリプションは、異なるクライアントIDポリシーを持つ場合、2種類の独自のサブスクリプションとして扱われます。

サブスクリプション共有ポリシーを使用する方法の詳細は、以下を参照してください。

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの接続ファクトリ・サブスクリプション共有ポリシーの構成に関する項。
『Oracle WebLogic Server JMSアプリケーションの開発』の高度なPub/Subアプリケーションの開発に関する項