| Oracle® Fusion Middleware WebLogic Server Multitenantの使用 12c (12.2.1.1.0) E77392-02 |
|
 前 |
 次 |
永続ストア(ファイルおよびJDBCストア)
JMSサーバー
ストア・アンド・フォワード(SAF)エージェント
パス・サービス
メッセージング・ブリッジ
JMSシステム・モジュールおよびJMSアプリケーション・モジュール
JMS接続プール
また、この章では、同じWebLogic Serverインスタンスまたはクラスタの他のパーティション、およびリモート・クライアントJVMまたはリモート・サーバーJVMから、パーティション化されたJMSリソースにアクセスする方法についても説明します。
この章の内容は次のとおりです。
マルチテナント環境でJMSを構成する前に、次について熟知し、それらをすでに作成していることを前提としています。
仮想ターゲット。詳細は、「仮想ターゲットの構成」を参照してください。
ドメイン・パーティション。詳細は、「ドメイン・パーティションの構成」を参照してください。
パーティションに固有のセキュリティ・レルム(必要な場合)。詳細は、セキュリティの構成を参照してください。
リソース・グループ・テンプレート(必要な場合)。詳細は、「リソース・グループ・テンプレートの構成」を参照してください。
リソース・グループ。詳細は、「リソース・グループの構成」を参照してください。
この章では、既存のWebLogic Serverメッセージング構成を熟知していることを前提としています。詳細は、次を参照してください。
Oracle WebLogic Server JMSリソースの管理
WebLogic永続ストアの管理
Oracle WebLogic Server WebLogicメッセージング・ブリッジの管理
Oracle WebLogic Serverストア・アンド・フォワード・サービスの管理
Oracle WebLogic ServerメッセージドリブンBeanの開発
非パーティション環境でWebLogic Serverを操作する場合、ドメイン・レベルでJMSアーティファクトを構成およびデプロイできます。JMSアーティファクトの例には、永続ストア(ファイルまたはJDBCストア)、JMSサーバー、ストア・アンド・フォワード・エージェント、パス・サービスおよびメッセージング・ブリッジが含まれ、これらは、PersistentStoreMBean、JMSServerMBean、SAFAgentMBean、PathServiceMBean、MessagingBridgeMBeanなどのJMX MBeanを使用して、WebLogic Serverドメインのconfig.xmlファイルで直接構成されます。
また、接続ファクトリや宛先などのJMSリソースは、JMSモジュールと呼ばれる外部ディスクリプタ・ファイルで構成されます。JMSモジュールは、最もよくJMSシステム・リソースとして構成されます(JMSSystemResourceMBeanを使用)。一般的ではありませんが、JMSモジュールは、デプロイ済アプリケーションに含まれるスタンドアロンまたはアプリケーション・スコープのXMLファイル(それぞれスタンドアロン・モジュールおよびアプリケーション・スコープのモジュールと呼ばれる)として、またはJava EE 7接続ファクトリおよび宛先注釈(アプリケーション・スコープのモジュールで定義された外部リソースと同じ基本的なセマンティクスを持つ)によって間接的に、組み込むことができます。
WebLogic Server MTで作業する場合、前述のすべてのJMSアーティファクトは、次のスコープで定義およびデプロイできます。
ドメイン・スコープ: 非パーティションWebLogic Server環境の場合とまったく同じ構成を使用
リソース・グループ・スコープ: パーティション・レベルまたはドメイン・レベルで作成されたリソース・グループの一部として
リソース・グループ・テンプレート・スコープ: ドメイン・レベルで作成されたリソース・グループ・テンプレートの一部として
リソース・グループは、オプションで、リソース・グループ・テンプレート・スコープのJMS構成を継承できます。パーティションにつき1つのリソース・グループのみが特定のリソース・グループ・テンプレートを参照でき、同様に、1つのドメイン・レベルのリソース・グループのみがリソース・グループ・テンプレートを参照できます。
まとめると、JMSメッセージング・アーティファクトのドメイン構成の構造は、次のとおりです。
ドメイン・レベルのJMS構成
JMS構成を含むドメイン・レベルのリソース・グループ
JMS構成を含むドメイン・レベルのリソース・グループ・テンプレート
リソース・グループ・テンプレートに基づいたドメイン・レベルのリソース・グループ
パーティション:
JMS構成を含むパーティション・レベルのリソース・グループ
リソース・グループ・テンプレートに基づいたパーティション・レベルのリソース・グループ
検証およびターゲット指定のルールによって、WebLogic Server MTのJMS構成の分離、自己完結性および管理の容易性が確実化されます。これらのルールは、次の目標を実現するのに役立ちます。
リソース・グループが、他のリソース・グループまたはドメイン・レベルのリソースで失敗の原因となることなく、独立して停止または移行できる。
リソース・グループ・テンプレートが、リソース・グループ、ドメイン構成または他のリソース・グループ・テンプレートに直接依存しない、完全にカプセル化され、独立した構成ユニットである。
リソース・グループが単一のサーバーをターゲットとしているか、クラスタをターゲットとしているか、ターゲットがないかに関係なく、同じ構成が有効である。
以前のリリースで有効だったドメイン・レベルの構成の動作に変更がない。たとえば、非リソース・グループまたはリソース・グループ・テンプレートのドメイン・レベルの動作は、下位互換性のために変更されません。
これらの目標の実現に役立つ基本的で高レベルのルールとして、JMS構成MBeanは、同じスコープにある別の構成MBeanのみを参照できるというものがあります。たとえば、リソース・グループ・テンプレートで定義されたJMSサーバーは、同じリソース・グループ・テンプレートで定義されたストアのみを参照できます。これらのルールは、構成検証チェック、および実行時に記録されるエラーと警告によって施行されます。
次の各項では、マルチテナント環境でJMSアーティファクトを構成する際の考慮事項について説明します。
JMSサーバー、SAFエージェントまたはパス・サービスを構成する前に、永続ストアを作成する手順が必要です。これは、リソース・グループおよびリソース・グループ・テンプレート・スコープのJMSサーバー、SAFエージェントおよびパス・サービスは、既存の永続ストアを参照する必要があるためです。
ドメインまたはパーティションにスコープされたリソース・グループ内のカスタム・ファイルまたはJDBC永続ストアの作成は、ドメイン・レベルの永続ストアの作成と似ています。ただし、追加の手順として、スコープを指定する必要があります。Oracle WebLogic Server管理コンソールおよびOracle Enterprise Manager Fusion Middleware Controlでは、作成プロセスの最初の手順に「スコープ」メニューがあり、永続ストアの作成に使用できるスコープがリストされます。WebLogic Scripting Tool (WLST)を使用して、親MBean (ドメイン、リソース・グループまたはリソース・グループ・テンプレートのMBean)でcreatePersistentStoreコマンドを使用することにより永続ストアを作成する必要があります。
次の分散ポリシーおよび移行ポリシー・ルールは、すべてのリソース・グループおよびリソース・グループ・テンプレート・スコープの永続ストアに適用されます。
JMSサーバー分散宛先またはSAFエージェント・インポート済宛先をホストするために使用されるリソース・グループまたはリソース・グループ・テンプレート・スコープのストアは、Distributed分散ポリシー(デフォルト)を指定する必要があります。この設定により、クラスタ内のWebLogic Serverインスタンスごとにストア・インスタンスがインスタンス化されます。さらに、Distributed分散ポリシーが指定されたリソース・グループまたはリソース・グループ・テンプレート・スコープのストアは、オプションで、On-failureまたはAlways移行ポリシーで構成できます。
パス・サービスによって使用される、またはJMSサーバー・スタンドアロン(非分散)宛先をホストするために使用される、リソース・グループまたはリソース・グループ・テンプレート・スコープのストアは、Singleton分散ポリシーを指定する必要があります。この設定により、クラスタ内の単一のストア・インスタンスがインスタンス化されます。さらに、Singleton分散ポリシーが指定されたリソース・グループまたはリソース・グループ・テンプレート・スコープのストアには、移行ポリシーとしてOffではなくOn-failureまたはAlwaysを指定する必要があります。デフォルトはOffです。
On-failureまたはAlways移行ポリシーが指定された、クラスタをターゲットとするストアでは、クラスタがデータベース・リーシングまたはクラスタ・リーシングのいずれかで構成される必要があり、この場合はデータベース・リーシングがベスト・プラクティスとして推奨されます。
これらのポリシーは、クラスタをターゲット指定するストアおよびJMSアーティファクトの分散および高可用性の動作を制御します。詳細は、『Oracle WebLogic Server JMSリソースの管理』の簡素化されたJMSクラスタおよび高可用性の構成に関する項を参照してください。
ファイルとJDBCストアの両方に施行された構成検証およびターゲット指定のルールを次に示します。
リソース・グループまたはリソース・グループ・テンプレート・レベルのJMSサーバー、SAFエージェントまたはパス・サービスは、構成されたストアを参照する必要があります。これらはnullを参照できません。
リソース・グループ・テンプレート・スコープのJMSサーバー、SAFエージェントまたはパス・サービスは、同じリソース・グループ・テンプレートで定義されたストアのみを参照できます。子リソース・グループ・レベルで定義されたストアを参照できません。
リソース・グループ・スコープのJMSサーバー、SAFエージェントまたはパス・サービスは、同じリソース・グループ、またはオプションでリソース・グループによって参照されるリソース・グループ・テンプレートで定義されたストアのみを参照できます。
ドメイン・レベルのJMSサーバー、SAFエージェントまたはパス・サービスは、ドメイン・スコープのストアのみを参照できます。
JDBCストアに固有の追加のルールを次に示します。
リソース・グループ・テンプレート・スコープのJDBCストアは、同じリソース・グループ・テンプレートにあるデータ・ソースのみを参照できます。
リソース・グループ・スコープのJDBCストアは、同じリソース・グループ、またはオプションでリソース・グループによって参照されるリソース・グループ・テンプレートにあるデータ・ソースのみを参照できます。
ドメイン・スコープのJDBCストアは、ドメイン・スコープのデータ・ソースのみを参照できます。
ドメイン・レベルのリソース・グループまたはパーティション内にスコープされたJMSサーバーの作成は、ドメイン・レベルでのJMSサーバーの作成と似ています。追加の手順は、スコープを指定することです。WebLogic Server管理コンソールおよびFusion Middleware Controlでは、作成プロセスの最初の手順に「スコープ」メニューがあり、JMSサーバーの作成に使用できるスコープがリストされます。WLSTを使用して、親MBean (ドメイン、リソース・グループまたはリソース・グループ・テンプレートのMBean)でcreateJMSServerコマンドを使用することによりJMSサーバーを作成する必要があります。
他に必要な手順は、JMSサーバーと同じスコープで構成された永続ストアを参照するように、JMSサーバーを構成することです。
最後に、JMSサーバーが分散宛先をホストするために使用される場合、そのストアはDistributed分散ポリシーで構成される必要があります。JMSサーバーがスタンドアロン(非分散)宛先をホストする場合、ストアはSingleton分散ポリシーで構成される必要があります。
ドメイン・レベルのリソース・グループまたはパーティション内にスコープされたストア・アンド・フォワード(SAF)エージェントの作成は、ドメイン・レベルでのSAFエージェントの作成と似ています。追加の手順は、スコープを指定することです。WebLogic Server管理コンソールおよびFusion Middleware Controlでは、作成プロセスの最初の手順に「スコープ」メニューがあり、SAFエージェントの作成に使用できるスコープがリストされます。WLSTを使用して、親MBean (ドメイン、リソース・グループまたはリソース・グループ・テンプレートのMBean)でcreateSAFAgentコマンドを使用することによりSAFエージェントを作成する必要があります。
他に必要な手順は、SAFエージェントと同じスコープで構成された永続ストアを参照するように、SAFエージェントを構成することです。このストアは、Distributed分散ポリシー(デフォルト)で構成される必要があります。
注意:
サービス・タイプがReceiving Onlyのリソース・グループまたはリソース・グループ・テンプレート・レベルのSAFエージェントは、許可されません。このような構成を設定しようとすると、例外がスローされるか、エラー・メッセージが記録されます。このモードは、古い形式のJAX-RPC Webサービスの信頼性のあるメッセージングに固有のものです。かわりに、JAX-WS RMを使用します。
リソース・グループまたはリソース・グループ・テンプレートが、順序単位(UOO)メッセージをホストするために使用される分散宛先も構成する場合、パス・サービスは、リソース・グループまたはリソース・グループ・テンプレートで構成する必要があります。また、ハッシュ・ベースのUOOルーティングがリソース・グループまたはリソース・グループ・テンプレート・スコープでサポートされていないため、このような分散宛先は、HashではなくPathServiceに設定された順序単位ルーティング・ポリシーで構成される必要があります。リソース・グループまたはリソース・グループ・テンプレート・スコープの分散宛先は、ルーティングUOOメッセージの同じリソース・グループまたはリソース・グループ・テンプレートで構成されたパス・サービスのみを使用します。PathService順序単位ルーティング・ポリシーを構成しないリソース・グループまたはリソース・グループ・テンプレート・スコープの分散宛先にメッセージを送信しようとすると、例外で失敗します。
ドメイン・レベルのリソース・グループまたはパーティション内にスコープされたパス・サービスの作成は、ドメイン・レベルでのパス・サービスの作成と似ています。追加の手順は、スコープを指定することです。WebLogic Server管理コンソールおよびFusion Middleware Controlでは、作成プロセスの最初の手順に「スコープ」メニューがあり、パス・サービスの作成に使用できるスコープがリストされます。WLSTを使用して、親MBean (ドメイン、リソース・グループまたはリソース・グループ・テンプレートのMBean)でcreatePathServiceコマンドを使用することによりパス・サービスを作成する必要があります。
他に必要な手順は、パス・サービスと同じスコープで構成された永続ストアを参照するように、パス・サービスを構成することです。このストアは、Singleton分散ポリシーおよびAlwaysまたはOn-Failure移行ポリシーで構成される必要があります。
ドメイン・レベルのリソース・グループまたはパーティション内にスコープされたメッセージング・ブリッジの作成は、ドメイン・レベルでのメッセージング・ブリッジの作成と似ています。追加の手順は、スコープを指定することです。WebLogic Server管理コンソールおよびFusion Middleware Controlでは、作成プロセスの最初の手順に「スコープ」メニューがあり、メッセージング・ブリッジの作成に使用できるスコープがリストされます。WLSTを使用して、親MBean (ドメイン、リソース・グループまたはリソース・グループ・テンプレートのMBean)でcreateMessagingBridgeコマンドを使用することによりメッセージング・ブリッジを作成する必要があります。
次の分散ポリシーおよび移行ポリシー・ルールは、すべてのリソース・グループまたはリソース・グループ・テンプレート・スコープのメッセージング・ブリッジに適用されます。
ブリッジでDistributed分散ポリシー(デフォルト)を指定して、クラスタをターゲットとするブリッジがクラスタ内のサーバーごとにインスタンスをデプロイするようにします。Distributed分散ポリシーが指定されたメッセージング・ブリッジは、オプションでOn-failure移行ポリシーを構成して、高可用性のサポートを追加することもできます。
ブリッジでSingleton分散ポリシーを指定して、クラスタをターゲットとするブリッジがクラスタごとに1つのインスタンスをデプロイするように制限します。Singleton分散ポリシーが指定されたメッセージング・ブリッジには、OffではなくOn-failure移行ポリシーを指定する必要があります。デフォルトはOffです。
On-failure移行ポリシーが指定された、クラスタをターゲットとするブリッジでは、クラスタがデータベース・リーシングまたはクラスタ・リーシングのいずれかで構成される必要があり、この場合はベスト・プラクティスとしてデータベース・リーシングが推奨されます。
これらのポリシーは、クラスタをターゲット指定するメッセージング・ブリッジの高可用性の動作および分散動作を制御します。分散および移行ポリシーの詳細は、『Oracle WebLogic Server JMSリソースの管理』の簡素化されたJMSクラスタおよび高可用性の構成に関する項を参照してください。
メッセージング・ブリッジに固有の構成検証ルールを次に示します。
リソース・グループ・テンプレート・スコープのメッセージング・ブリッジは、同じスコープのメッセージング・ブリッジ宛先のみを参照できます。
リソース・グループ・スコープのメッセージング・ブリッジは、同じリソース・グループ、またはオプションでリソース・グループによって参照されるリソース・グループ・テンプレートにあるメッセージング・ブリッジ宛先のみを参照できます。
ドメイン・スコープのメッセージング・ブリッジは、ドメイン・スコープのメッセージング・ブリッジ宛先のみを参照できます。
ドメイン・レベルのリソース・グループまたはパーティション内にスコープされたJMSシステム・リソースの作成は、ドメイン・レベルでのJMSシステム・リソースの作成と似ています。追加の手順は、スコープを指定することです。WebLogic Server管理コンソールおよびFusion Middleware Controlでは、作成プロセスの最初の手順に「スコープ」メニューがあり、JMSシステム・リソースの作成に使用できるスコープがリストされます。WLSTを使用して、親MBean (ドメイン、リソース・グループまたはリソース・グループ・テンプレートのMBean)でcreateJMSSystemResourceコマンドを使用することによりJMSシステム・リソースを作成する必要があります。
ドメイン・レベルのリソース・グループ・スコープを持つ、またはパーティション内にあるアプリケーション・スコープのJMSモジュールの作成は、ドメイン・レベルでの作成と似ています。アプリケーション・デプロイメントには、JMSモジュール・ファイル、またはJMSモジュール・ファイルを含むアプリケーションEARファイルを含めることができます。追加の手順は、リソース・グループまたはリソース・グループ・テンプレート・スコープを指定することです。詳細は、「アプリケーションのデプロイ」を参照してください。
注意:
同じ構成編集セッション内で、JMSサーバーを作成し、サブモジュール・ターゲットを指定するアプリケーションをこのJMSサーバーにデプロイする処理をすべて行う場合、デプロイメントは成功しない可能性があります。JMSサーバーを個別の編集セッションに構成することをお薦めします。
注意:
アプリケーション・リソース・モジュールに構成を組み込むのではなく、システム・リソース・モジュールを使用してJMSを構成することを強くお薦めします。アプリケーション・スコープの構成とは異なり、システム・リソース構成は、管理者または開発者が、WebLogic Server管理コンソール、WLSTまたはMBeanを使用して、動的に調整し、簡単にモニターできます。
リソース・グループまたはリソース・グループ・テンプレート・スコープのJMSモジュールに属するリソースに関連する、構成検証およびターゲット指定のルールを次に示します。
サブデプロイメントの定義
リソース・グループまたはリソース・グループ・テンプレート・スコープのサブデプロイメントのターゲットとしては、なし(null)、単一のJMSサーバー、または単一のSAFエージェントのみを指定できます。
リソース・グループ・テンプレート・スコープのサブデプロイメントは、同じリソース・グループ・テンプレートで定義されたJMSサーバーまたはSAFエージェントのみを参照できます。
リソース・グループ・スコープのサブデプロイメントは、同じリソース・グループ、またはオプションでリソース・グループによって参照されるリソース・グループ・テンプレートで定義されたJMSサーバーまたはSAFエージェントのみを参照できます。
JMSモジュールのリソース
次の表は、JMSモジュールのリソース・タイプのターゲット指定のルールを示しています。
| リソース・タイプ | サブデプロイメントの使用 | デフォルトのターゲット指定の使用 |
|---|---|---|
スタンドアロン(シングルトン)宛先 |
|
|
共通分散宛先* |
|
|
SAFインポート済宛先 |
SAFエージェントのターゲットを指定するサブデプロイメントに対してのみ、ターゲットを指定できます。 |
同じリソース・グループまたはリソース・グループ・テンプレート・スコープに構成された単一のSAFエージェントがある場合のみ、デプロイが行われます。スコープの外部(たとえば、ドメイン・レベルまたは別のリソース・グループまたはリソース・グループ・テンプレート)に定義されたSAFエージェントも無視されます。 |
接続ファクトリ |
サブデプロイメントをターゲット指定できます。 |
リソース・グループのターゲットに含まれているすべてのWebLogic Serverインスタンスにデプロイします。 |
外部サーバー |
|
リソース・グループのターゲットに含まれているすべてのWebLogic Serverインスタンスにデプロイします。 |
* 注意: リソース・グループまたはリソース・グループ・テンプレート・スコープの共通分散トピックではPartitioned転送ポリシーを指定する必要があります。たとえば、パーティション化された分散トピック(PDT)である必要があります。PDTの「パーティション化された」という単語は、WebLogic Server MTパーティションの「パーティション」という単語と同じ意味ではないことに注意してください。PDTとWebLogic Server MTのパーティションは、2つの独立した概念です。PDTの使用に対するトレードオフの詳細は、「メッセージングの構成: 制限事項」を参照してください。
リソース・グループ・テンプレート・スコープのJMS構成アーティファクトは、リソース・グループ・テンプレートを使用するパーティションに固有の値が不足しているか正しくないため、完全ではない可能性があります。各パーティションには、パーティション・ランタイムへの正しいデプロイメントのテンプレートから導出された値をカスタマイズするために指定された適切なオーバーライド値が必要な可能性があります。パーティション固有でリソース・グループ・スコープのJMS構成は、リソース・デプロイメント・プランまたはアプリケーション・デプロイメント・プランを使用してパーティションごとにカスタマイズできます。また、JMSシステム・モジュール内のJMS外部サーバー構成は、JMSSystemResourceOverrideMBeanを使用してカスタマイズできます。
リソース・オーバーライドによって、システム管理者は、JMSリソースおよびデータ・ソースなどの他のリソースをパーティション・レベルでカスタマイズできます。リソース・グループ・テンプレートを拡張するリソース・グループを含むパーティションを作成する場合は、そのリソース・グループ・テンプレートで定義されている特定のリソースの設定をオーバーライドできます。リソース・グループ・テンプレートを拡張しないリソース・グループをパーティション内に作成し、このリソース・グループ内にリソースを作成する場合、オーバーライドは不要で、これらのリソースにパーティション固有の値を設定します。
オーバーライドは、主にリソースに共通の定義が存在する場合に、リソースを使用する各パーティションがリモートに格納された状態を分離する必要がある、リソース・グループ・テンプレートなどで使用されます。たとえば、同じJMSサーバー、JDBCストア、データ・ソースおよびJMSモジュールの構成は、単一のリソース・グループ・テンプレートで構成し、リソース・グループ・テンプレートを参照する各パーティションでリソース・グループを構成することによって、同じクラスタ内の複数のパーティションにデプロイできます。その後、パーティション・リソース・グループをパーティションごとにオーバーライドして、それぞれのデータ・ソースが異なるデータベースまたは同じデータベース内の異なるスキーマに接続していることを確認できます。
システム管理者は、次の特定の手法を使用して、パーティションのリソース定義をオーバーライドできます。
リソース・オーバーライド構成MBean: 既存のリソース構成MBeanの属性のサブセットを公開する構成MBean。オーバーライド構成MBeanのインスタンス上の属性セットは、対応するリソース構成MBeanインスタンス内のその属性の値を置き換えます。JMSシステム・モジュールの外部JMSサーバーおよび関連する構成アーティファクトは、オーバーライドMBeanを使用して、ユーザー、パスワードおよびプロバイダURLの設定をオーバーライドできます。オーバーライドMBeanを使用する場合、対応する外部JMSサーバーおよび関連するデプロイメントMBeanごとに個別のオーバーライドMBeanを定義する必要があります。JMSモジュールがすでにデプロイされた後の実行時に行われたこれらの属性への構成変更は、パーティションまたはJVMを再起動して、変更を有効にする必要があります。
リソース・デプロイメント・プラン: パーティション内で構成された任意のリソースを識別し、それらのリソースの属性設定をオーバーライドするXMLファイル。永続ストア、JMSサーバー、SAFエージェント、メッセージング・ブリッジ、ブリッジ宛先およびパス・サービスは、リソース・デプロイメント・プランのconfig-resource-override要素を使用し、キュー、トピックおよび接続ファクトリなどのJMSシステム・モジュールのJMSリソースは、external-resource-override要素を使用します。
パーティション固有のアプリケーション・デプロイメント・プラン: 既存のアプリケーション・デプロイメント・プランに似たプラン。管理者は、パーティション内のアプリケーション・デプロイメントごとに、パーティション固有のアプリケーション・デプロイメント・プランを指定できます。パーティション固有のアプリケーション・デプロイメント・プランの詳細は、「パーティション固有のデプロイメント・プランの使用方法」を参照してください。
管理者は、これらのリソース・オーバーライド手法を任意に組み合せることができます。システムでは、次に示す昇順の優先度でこれらが適用されます。
パーティション固有のアプリケーション・デプロイメント・プランを含む、config.xmlファイルおよび外部ディスクリプタ
リソース・デプロイメント・プラン
オーバーライド構成MBean
属性がリソース・デプロイメント・プランおよびオーバーライド構成MBeanの両方で参照される場合、オーバーライド構成MBeanが優先されます。
オーバーライドの詳細は、「リソース・オーバーライドの構成」を参照してください。
パーティションのJMSリソースにアクセスするには、アプリケーションでは、まずパーティションへのJNDI初期コンテキストを確立する必要があります。パーティションのコンテキストを作成すると、コンテキスト・オブジェクトはパーティションのネームスペースに維持され、それ以降のJNDI操作はすべて、そのパーティションのスコープの中で行われます。java.naming.provider.urlプロパティを設定してコンテキストが作成されると、JNDIはパーティションを認識するためにパーティション情報をプロバイダURLの値の中で探します。次の4つの異なるURLタイプは、特定のパーティションにコンテキストを関連付けます。
URLを指定しない。
パーティションの仮想ホストまたはURIを指定するURLの使用。
パーティションの専用ポートを指定するURLの使用。
特別なlocal: URLの使用。「local: URLまたは修飾されたJNDI名を使用したローカル・クロス・パーティションのユースケース」を参照してください。
また、JNDI名の接頭辞として特別なスコープ文字列を付加することによって、既存のコンテキストを使用して別のパーティションのリソースを参照できます。
これらの各方法については、次の各項で説明します。
プロバイダURLを指定せずにローカル初期コンテキストを作成するだけで、WebLogic Serverインスタンス上のパーティションで実行中のアプリケーションは、独自のローカル・パーティションのJMSリソースにアクセスできます。この方法は、ローカルにスコープされたコンテキストを作成するためのベスト・プラクティスです。
コンテキストURLがパーティションに構成された仮想ホストURLまたはURIと一致する場合、JNDIはそのパーティションのコンテキストを作成し、コンテキストからのすべてのリクエストは、パーティションのJNDIネームスペースに委任されます。
したがって、JMSアプリケーションでは、次の形式のURLを指定することによって、t3またはHTTPプロトコルを使用する別のJVMまたはWebLogic Serverクラスタで実行されているWebLogic Server JMSリソースにアクセスできます。
t3://virtualhost:port
t3://host:port/URI
注意:
URIにスペルミスがあるかURIが存在しないと、コンテキストはドメイン・レベルにスコープされ、警告はありません。
特定のポートまたはアドレスをパーティション内のチャネル専用にすることが可能で、この場合、URL形式はt3://host:portになります。
これは、リリース12.2.1より前のクライアントをパーティション・スコープのリソースと相互運用するためにサポートされている唯一の方法です。
詳細は、「仮想ターゲットの構成」を参照してください。
注意:
この方法を以前のリリースとの相互運用性のために使用する場合、SSLは現在サポートされていません。
あるパーティションのアプリケーションは、前の項で説明したURLのいずれかを使用して、同じWebLogic Serverインスタンスまたは同じクラスタの別のパーティションにアクセスできます。
ただし、特定のホスト、ポートまたはURIを指定する必要なく、同じサーバーに存在するパーティション間のより効率的なアクセスをサポートするために、アプリケーションには次のオプションがあります。
local:プロトコルURLを指定したコンテキストを作成します。
local:// - コンテキストを現在のパーティション上に作成します(パーティションまたはドメインのいずれか)。
local://?partitionName=DOMAIN - コンテキストをドメイン上に作成します。
local://?partitionName=partition_name - コンテキストをパーティションpartition_name上に作成します。
URLを指定せずにコンテキストを作成し、JNDI名を指定する際に明示的なスコープを接頭辞として付けます。
domain:<JNDIName> - ドメイン・レベルのJNDIエントリをルックアップします。
partition:<partition_name>/<JNDIName> - 指定したパーティションのJNDIエントリをルックアップします。
次の各項では、様々なJMSパーティション関連付けについて説明します。
JMSクライアント接続およびJMSコンテキストは、その接続ファクトリが取得されたパーティションに永久に関連付けられ、現在のスレッドに関連付けられたパーティションに基づいてパーティションを変更しません。
JMSがメッセージまたは例外を非同期リスナーにプッシュするか、同様にイベントを宛先可用性リスナーまたは非同期送信完了リスナーにプッシュすると、リスナーのローカル・パーティションID (宛先のパーティションではない)がコールバック・スレッドに関連付けられます。ローカル・パーティションIDは、非同期リスナーを作成したスレッドに関連付けられたパーティションです。
接続ファクトリは、接続ファクトリと同じパーティションに定義された宛先とのみ相互作用できます。たとえば、QueueBrowser、MessageConsumer/JMSConsumer、TopicSubscriberまたはMessageProducer/JMSProducerクライアント・オブジェクトは、これらのクライアント・オブジェクトの作成に使用された接続ファクトリが宛先と同じパーティションに定義された場合にのみ、宛先と通信できます。さらに、接続ファクトリは、接続ファクトリと同じクラスタまたはサーバーJVMから取得された宛先とのみ相互作用できます。
12.2.1リリースより前は、JMSサーバーはドメイン・レベルでのみデプロイされ、一時宛先は、次の両方を満たすJMSサーバーによってのみホストされました。
Hosting Temporary Destinationsがtrue (デフォルト)に設定されている。
一時宛先の作成に使用された接続ファクトリと同じWebLogic Serverインスタンスまたは同じクラスタでホストされている。
WebLogic Server MTで一時宛先を作成する動作は、次のとおりです。
非MT WebLogic Serverの場合のように、Hosting Temporary Destinationsが有効で、一時宛先の作成に使用される接続ファクトリと同じWebLogic Serverインスタンスまたは同じクラスタでホストされるJMSサーバーによってのみ、一時宛先をホストできます。
リソース・グループまたはリソース・グループ・テンプレート・スコープ(ドメイン・リソース・グループなど)で構成された接続ファクトリを使用してJMS接続が作成された場合、一時宛先は、同じスコープで構成されたJMSサーバーによってのみホストされます。
非リソース・グループまたはリソース・グループ・テンプレート・スコープのパーティション・レベルの接続ファクトリを使用してJMS接続が作成された場合、接続ファクトリと同じパーティションのJMSサーバーで一時宛先を作成できます。非リソース・グループまたはリソース・グループ・テンプレート・スコープのパーティション・レベルの接続ファクトリは、単にデフォルトの接続ファクトリで、たとえばJNDI名がweblogic.jms.ConnectionFactoryやweblogic.jms.XAConnectionFactoryの接続ファクトリです。
非リソース・グループまたはリソース・グループ・テンプレート・スコープのドメイン・レベルの接続ファクトリを使用してJMS接続が作成された場合、ドメイン・レベルのJMSサーバー(ドメイン・レベルのリソース・グループにスコープされたJMSサーバーなど)で一時宛先を作成できます。
許可されたスコープ内に修飾されたJMSサーバーが見つからない場合、一時宛先を作成しようとすると、例外が返されます。
次の各項では、パーティション・スコープのメッセージングの特定の状況の管理について説明します。
既存のすべてのメッセージング・ランタイムMBeanは、パーティション・スコープのJMS構成およびデプロイメントのモニタリングおよび制御でサポートされ、JMXベースの管理クライアントからアクセスできます。パーティション・スコープのJMSランタイムMBeanは、対応するParititionRuntimeMBeanインスタンスの下にあります。
次に例を示します。
JMSServer、ConnectionおよびPooledConnectionランタイムMBeanは、serverRuntime/PartitionRuntimes/partition/JMSRuntimeの下のランタイムMBean階層にあります。
SAFランタイムMBeanは、serverRuntime/PartitionRuntimes/partition/SAFRuntimeMBeanの下のランタイムMBean階層にあります
メッセージング・ブリッジおよびパス・サービス・ランタイムMBeanは、serverRuntime/PartitionRuntimes/partitionの直下のランタイムMBean階層にあります
詳細は、「パーティションのモニタリングおよびデバッグ」を参照してください。
パーティション・メッセージング構成に関連するセキュリティ・ロールおよびポリシー定義は、WebLogic Serverシステム管理者が担当します。
WebLogic Server MTでは、従来のWebLogic Serverセキュリティ・サポートを次の2つの重要な方法で拡張しています。
複数のレルム: WebLogic Server MTでは、複数のアクティブなセキュリティ・レルムがサポートされており、各パーティションを異なるレルムで実行できます。
アイデンティティ・ドメイン: アイデンティティ・ドメインは、ユーザーおよびグループの論理ネームスペースであり、通常は、物理データ・ストア内のユーザーとグループの1つの個別セットを表します。アイデンティティ・ドメインを使用して、特定のパーティションに関連付けられているユーザーを識別します。
その他の点では、パーティション・スコープのメッセージングのセキュリティの構成は、ドメイン・レベルのメッセージングのセキュリティの設定と似ています。詳細は、セキュリティの構成を参照してください。
JVMのすべてのJTAトランザクションは、スコープに関係なく、単一のJTAトランザクション・マネージャによって処理されます。パーティション・スコープのXAリソース・マネージャ名は、パーティション名で自動的に修飾され、リソース・マネージャがトランザクション・マネージャに対して一意に識別され、独立して管理されるようにします。リソース・マネージャの1つの例として、永続ストアがあります。
トランザクション構成および制限の詳細は、「トランザクションの構成」を参照してください。
パーティションまたはリソース・グループに関連付けられたJMSアーティファクトは、そのパーティションまたはリソース・グループを起動および停止することによって起動および停止できます。これらの操作を実行する権限は、WebLogic Serverシステム管理者およびオペレータに自動的に提供されます。
メッセージング・コンポーネントは、診断イメージをパーティションにスコープする機能をサポートしていません。詳細は、「パーティション・スコープの診断イメージ・キャプチャの構成」を参照してください。
ドメイン・ログ・フォーマットが構成されていない場合、パーティション・スコープのJMSログ・メッセージは、パーティションIDと名前で修飾されます。ロギングの詳細は、「パーティションのモニタリングおよびデバッグ」を参照してください。
オプションで有効化されたJMSサーバーおよびSAFエージェント・メッセージ・ライフサイクル・ロギングは、これらのサービスがパーティションにスコープされた場合と異なる場所に配置されます。ロギング・ファイルは、そのパーティションのディレクトリにあります。さらに、クラスタをターゲットとするJMSサーバーまたはSAFエージェントの、異なるランタイムJMSサーバーおよびSAFエージェント・インスタンスのログ・ファイル名は、1つの解釈で置き換えられることが保証されます。
絶対パス、相対パスまたはデフォルトを構成する場合に予期される新しいログの場所を、次にまとめます。
| スコープ | 構成なし(デフォルト) | /<absolute-path>/<file> | /<relative-path>/<file> |
|---|---|---|---|
ドメイン・レベル |
|
|
|
パーティション |
|
|
|
* 注意: パーティション・スコープの構成は、絶対パスを相対パスとして処理します。
<domain-log> = <domain>/servers/<wl-server-name>
<partition-log> = <domain>/partitions/<partition-name>/system/servers/<wl-server-name>
<log-suffix> = logs/jmsservers/<configured-name> (JMSサーバーの場合)
<log-suffix> = logs/safagents/<configured-name> (SAFエージェントの場合)
<instance> =
<configured-name> (JMSサーバーまたはSAFエージェントが単一のサーバーをターゲットとする場合)
<configured-name>_<wl-server-name> (クラスタをターゲットとし、データ・ストアの分散ポリシーがDistributedの場合)
(あるWebLogic Serverインスタンスから別のWebLogic Serverインスタンスに移行しても、インスタンスは古い名前を保持することに注意してください。)
<configured-name>_01 (クラスタをターゲットとし、データ・ストアの分散ポリシーがSingletonの場合)
JMSリソースを構成およびモニターするためのヘルパー・メソッドを提供するJMS固有のJava管理プログラミング・ユーティリティが2つあります。
JMSModuleHelperユーティリティには、(モニターする) JMSランタイムMBeanを検索するヘルパー・メソッド、および特定のモジュールでJMSモジュール構成エンティティ(ディスクリプタBean)を管理(検索/作成/削除)するメソッドが含まれています。
JMSRuntimeHelperユーティリティは、接続、宛先、セッション、メッセージ・プロデューサまたはメッセージ・コンシューマなどのJMSオブジェクトが指定された、対応するJMXランタイムMBeanを取得するための便利なメソッドを提供します。
リリース12.2.1には、ドメイン・スコープのJMSリソースとリソース・グループまたはリソース・グループ・テンプレート・スコープのJMSリソースの両方を処理するための拡張バージョンのヘルパーが備えられています。
既存のJMSRuntimeHelperユーティリティは、パーティション対応になるように拡張されています。ランタイム・ヘルパー・メソッドを呼び出す際には、指定したJNDIコンテキストと指定したJMSオブジェクトが同じパーティションに属している必要があります(それ以外の場合、例外がスローされます)。
拡張されたJMSModuleHelperユーティリティは、スコープ対応で、次のインタフェースおよびクラスが含まれています。
weblogic.jms.extensions.IJMSModuleHelper - すべてのヘルパー・メソッドを定義するインタフェース。
weblogic.jms.extensions.JMSModuleHelper - リリース12.2.1より前のバージョンのJMSモジュール・ヘルパー。これはドメイン・レベルのJMSリソースのみを処理します。
weblogic.jms.extensions.JMSModuleHelperFactory - 管理サーバーへの初期コンテキスト、スコープ・タイプ(ドメイン、リソース・グループまたはリソース・グループ・テンプレート)、およびスコープの名前が指定された特定のスコープで機能するJMSモジュール・ヘルパーのインスタンスを作成するファクトリ。
次のコードは、3つの異なるスコープごとにJMSモジュール・ヘルパーを作成する方法を示しています。
Context ctx = getContext(); // get an initial JNDI context
JMSModuleHelperFactory factory = new JMSModuleHelperFactory();
// create a JMS module helper for domain level
IJMSModuleHelper domainHelper = factory.getHelper(ctx, IJMSModuleHelper.ScopeType.DOMAIN, null);
// create a JMS module helper for Resource Group "MyResourceGroup"
IJMSModuleHelper rgHelper = factory.getHelper(ctx, IJMSModuleHelper.ScopeType.RG, "MyResourceGroup");
// create a JMS module helper for Resource Group Template "MyResourceGroupTemplate"
IJMSModuleHelper rgtHelper = factory.getHelper(ctx, IJMSModuleHelper.ScopeType.RGT, "MyResourceGroupTemplate");
JMSモジュール・ヘルパー・インスタンスが作成されると、それを使用して、対応するスコープにスコープされたJMSリソースを作成できます。たとえば、次のコード例では、リソース・グループMyResourceGroupのJMSサーバーMyJMSServerにJMSキューを使用したJMSシステム・リソースを作成しています。(JMSサーバーおよびリソース・グループはすでに作成されていることを前提としています。)
String jmsServer = "MyJMSServer"; String jmsSystemModule = "MyJMSSystemModule"; String queue = "MyQueue"; String queueJNDI = "jms/myQueue"; rgHelper.createJMSSystemResource(jmsSystemModule, null); rgHelper.createQueue(jmsSystemModule, jmsServer, queue, queueJNDI, null);
永続ストアは、様々な目的のためにファイル・システムに多数のファイルを作成します。これらのファイルには、ファイル・ストア・データ・ファイル、ファイル・ストア・キャッシュ・ファイル(DirectWriteWithCache同期書込みポリシーが指定されたファイル・ストア用)、およびJMSサーバーとSAFエージェントのページング・ファイルがあります。
リリース12.2.1より前のファイルの場所の動作は、ドメイン・スコープの永続ストアの場合と同じままです。これにより、永続データがアップグレード後にリカバリされ、予期された場所に格納されます。パーティション・スコープの構成では、異なるパーティションの同じ名前のストア間のファイルの衝突を防ぐために、これらのファイルは、パーティション・ファイル・システム内の分離したディレクトリに配置されます。
次に、WebLogic Server MTのファイル・ストア・システムで使用される様々なファイルの場所のサマリーを示します。partitionStem = partitions/<partitionName>/systemです。
| ストア・タイプ | 構成されないストア・パス | 相対ストア・パス | 絶対ストア・パス | ファイル名 |
|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
次に、前述の各ストア・タイプがディレクトリの場所を構成する方法のサマリーを示します。
| ストア・タイプ | ディレクトリ構成 |
|---|---|
|
ファイル・ストアに構成されたディレクトリ。 |
|
|
|
WebLogic Serverデフォルト・ストアの構成に構成されたディレクトリ。(パーティションEJBタイマー・デフォルト・ストアは、デフォルト・ストアから構成をコピーします。) |
|
SAFエージェントまたはJMSサーバーに構成されたページング・ディレクトリ。 |
この項では、MT環境のJMS初級ユーザーとJMS上級ユーザーのためのアドバイスおよびベスト・プラクティスを示します。
MT関連の既知の問題については、『Oracle WebLogic Serverリリース・ノート』の構成の問題および回避策に関する項をすべてのユーザーが確認することをお薦めします。
なんらかの理由で、新しく作成または更新されたJMSリソースが、実行中のパーティションでアクセスできない場合は、WebLogic Serverログ・ファイルで警告およびエラー・ログ・メッセージがないか確認してください。サーバー・ログ・メッセージに役立つ情報がない場合、パーティションを再起動すると、問題が解決することがよくあります。新しく作成されたパーティションは、いずれかのリソースが外部的にアクセス可能になる前に、明示的に起動する必要があります。
次のルールは、リソース・グループおよびリソース・グループ・テンプレート・スコープで常に適用されます。
スタンドアロン宛先をホストするパス・サービスとJMSサーバーに対して、Distribution Policy=Singletonストアを使用します。
分散宛先をホストするSAFエージェントとJMSサーバーに対して、Distribution Policy=Distributedストアを使用します。
次のものを持つクラスタのクラスタ・リーシングを構成します。
Distribution Policy=Singletonのストアまたはブリッジ。
Migration Policy=On-FailureまたはAlwaysのストアまたはブリッジ。
JMSの使用に関連するより一般的なベスト・プラクティスは、『Oracle WebLogic Server JMSリソースの管理』のJMSの初級ユーザーおよび上級ユーザー向けのベスト・プラクティスに関する項を参照してください。
次のJMSの機能または関連コンポーネントは、WebLogic Server MTで現在サポートされていません。
パーティションへのクライアントSAF転送:
追加した場合の動作は不明です。
サーバー側のSAFエージェントのパーティションへの転送は、サポートされていません。
リソース・グループまたはリソース・グループ・テンプレート・スコープのJMSリソースへのCクライアント・アクセス。追加した場合の動作は不明です。
.NETクライアント。.NETクライアントがパーティションのJMSリソースにアクセスした場合、例外がスローされます。
レプリケートされた分散トピック(RDT):
レプリケートされた分散トピック(RDT)を含むリソース・グループまたはリソース・グループ・テンプレートへのJMSモジュールのデプロイメントは、例外で失敗します。
共通分散トピックのデフォルト・タイプは、Replicatedの転送ポリシーで構成されています。
回避策は次のとおりです。
スタンドアロン(シングルトン)トピックを構成します。
パーティション化された分散トピック(PDT)を構成します。
PDTは、転送ポリシーをPartitionedに設定することによって構成されます。
PDTの利点および制限事項は、『Oracle WebLogic Server JMSリソースの管理』のパーティション化された分散トピックの構成に関する項を参照してください。
PDTの「パーティション化された」という単語は、WebLogic Server MTパーティションの「パーティション」という単語と同じ意味ではないことに注意してください。PDTとWebLogic Server MTのパーティションは、2つの独立した概念です。
デフォルト・ストア
パーティションでのWebLogic Serverのデフォルト・ストアの使用は、許可されません。
リソース・グループまたはリソース・グループ・テンプレートのすべてのJMSサーバー、SAFエージェントおよびパス・サービスは、カスタム・ストアを参照する必要があります。
重み付けされた分散宛先(WDD)
WDDを含むリソース・グループまたはリソース・グループ・テンプレートへのJMSモジュールのデプロイメントは、例外で失敗します。
WDDは非推奨です。
接続コンシューマおよびサーバー・セッション・プール
パーティション・スコープの接続コンシューマまたはサーバー・セッション・プールを作成しようとすると、失敗します。
メッセージドリブンBean (MDB)は接続コンシューマまたはサーバー・セッション・プールと同様の目的を果たすため、MDBを使用することがベスト・プラクティスとなることに注意してください。
ロギング・ラスト・リソース(LLR)データ・ソース
トランザクション・システムは、パーティション・スコープのLLR機能をサポートしていません。
可能性のある回避策など、詳細は、「トランザクションの構成」を参照してください。
SSLを使用する専用パーティション・チャネルを使用したクライアント相互運用性
古いクライアントは、専用チャネルが構成されたパーティションとのみ相互運用できます。
この方法は、現在SSLをサポートしていません。
WebLogic Serverでは、「リソース・グループの移行: 主な手順およびWLSTの例」の説明に従って、別のサーバーまたはクラスタにリソース・グループを移行できます。リソース・グループ内のすべてのメッセージング構成およびデプロイメントをリソース・グループの移行の対象にできます。
メッセージング構成には、ファイル・ストア、JDBCストア、JMSサーバー、SAFエージェント、パス・サービス、JMSシステム・リソースおよびメッセージング・ブリッジが含まれます。
メッセージング関連のデプロイメントには、JMSモジュールを対象とするアプリケーション・デプロイメント、そしてJMSリソースを使用するEJBおよびMDBデプロイメントが含まれます。
メッセージング・リソース・グループの移行を実行する場合は、次の特別な考慮事項に注意してください。
WebLogicメッセージング・リソース・グループを移行する場合、移行を開始する前にソースの場所でリソース・グループを停止し、移行が完了した後で再開する必要があります。実行中のリソース・グループに含まれるメッセージング構成を対象として管理者が移行を開始しようとすると、検証例外がスローまたは表示され、移行を開始する前にリソース・グループを停止するよう指示するメッセージが表示されます。
リソース・グループの移行では、非永続メッセージング・アプリケーションおよびランタイム状態は維持されません。
非永続メッセージは失われます。
クライアントに例外が返され、移行中に再接続が必要になる場合があります。クライアントが一般的なJMS障害に対処できるように設計されている場合は、新しい場所に自動的にフェイルオーバーできることがあります。「リソース・グループの移行中のクライアント・フェイルオーバー」を参照してください。
永続メッセージングの状態データを移行する場合、追加の手順が必要になることがあります。
ソースの場所とターゲットの場所からアクセス可能な共有ストレージ(データベースまたはファイル)が必要です。
ほとんどの非クラスタ・ユースケースでは、追加の手順は必要ありません。
ほとんどのクラスタ・ユースケースでは、通常、正しく動作させるために、メッセージング固有の移行前手順が必要になります。
詳細は、「永続データを含むリソース・グループの移行」を参照してください。
トピックを操作するメッセージドリブンBeanを移行する場合、追加の手順が必要になることがあります。詳細は、「メッセージドリブンBean (MDB)の移行」を参照してください。
サード・パーティJMSプロバイダと統合されるアプリケーションを移行する場合、追加の手順が必要になることがあります。詳細は、「サード・パーティJMSとグローバル・トランザクションに関する考慮事項」を参照してください。
このドキュメントの残りの部分では、次の3つのタイプのメッセージング・サービスに言及しています。
非クラスタ・サービス: 非クラスタ(スタンドアロン)管理対象サーバーをターゲットとするサービス。
クラスタ・シングルトン・サービス: Singleton分散ポリシーが指定されたクラスタをターゲットとするサービス。
クラスタ分散サービス: Distributed分散ポリシーが指定されたクラスタをターゲットとするサービス。
JMSサービスの分散ポリシーはStoreMBeanまたはMessagingBridgeMBeanを使用して構成され、ストアを参照するメッセージング・サービス(JMSサーバー、SAFエージェント、パス・サービスなど)によりストアMBean構成からそのポリシーが継承されます。詳細は、『Oracle WebLogic Server JMSリソースの管理』の簡素化されたJMSクラスタおよび高可用性の構成に関する項を参照してください。
次の表に、サポートされているメッセージング・リソース・グループ移行シナリオのサマリーを示します。
| メッセージング・サービス | 非クラスタ | クラスタ・シングルトン | クラスタ分散 |
|---|---|---|---|
JMSサーバーおよび宛先 |
構成および永続データ |
構成および永続データ |
構成のみ |
SAFエージェントおよびインポート済宛先 |
構成のみ |
N/A |
構成のみ |
パス・サービス |
構成および永続データ |
構成のみ |
構成のみ |
メッセージング・ブリッジ |
はい |
はい |
はい。恒久トピックについては制限があります。詳細は、「クラスタ分散サービスの永続データの移行」を参照してください。 |
次の各項では、非クラスタ・サービス、クラスタ・シングルトン・サービスおよびクラスタ分散サービスの永続データの処理手順について説明します。
非クラスタ・メッセージングの永続状態(メッセージ、恒久サブスクリプション、SAFデータおよびUOOデータ)は、次に説明するわずかな例外はあるものの、ターゲットの場所に安全に移行して処理できます。
メッセージング・サービスを含むリソース・グループを非クラスタ管理対象サーバーからクラスタに、またはその逆に移行するには、追加の手順が必要になります。このような場合は、移行を開始する前に、すべてのメッセージを処理し、保留中のトランザクションをすべて完了し、リソース・グループを停止し、すべてのファイルおよびデータベース表を削除してください。
ストア・アンド・フォワード・エージェントを移行するときには、追加の手順が必要になります。詳細は、「ストア・アンド・フォワード・メッセージの移行」を参照してください。
ドメイン・レベルのリソース・グループにストア・パスが未定義のファイル・ストアが含まれている場合、移行後にパスが変更され、生成されるパスには現在のWebLogic Serverインスタンスの名前が組み込まれます。このようなストアについては、ソースの場所でリソース・グループを停止してからファイルを新しい場所に移動し、その後、そのターゲットの場所でリソース・グループを再開する必要があります。ファイル・ストアを構成する場合は常にストア・パスを指定することをお薦めします。
クラスタ・シングルトン・サービスの永続データを移行するときの考慮事項は、「非クラスタ・サービスの永続データの移行」で説明した非クラスタ・ユースケースと同じになりますが、1つの例外が追加されます。パス・サービスが構成されている場合は、すべての分散宛先メッセージを処理し、すべてのトランザクションを完了し、元の場所でリソース・グループを停止してから、ストア・ファイルまたは表を削除し、その後で新しい場所でリソース・グループを開始する必要があります。
分散宛先やインポート済宛先などの永続分散サービスが関与するリソース・グループ移行ユースケースでは、さらに注意が必要です。このようなサービスに関連付けられている永続データは、それをホストするリソース・グループを移行するときに、安全に移行できません。メッセージが失なわれないようにするには、移行を開始する前にすべてを処理し、分散宛先またはインポート済宛先にメッセージが残っていない状態にする必要があります。
また、すべての永続メッセージが消費され、確認応答された後でも、移行を開始する前に、このようなリソース・グループに関連付けられている永続ストア・ファイルや表をすべて削除することが重要です。たとえば、恒久サブスクリプションが破棄されても、完全にクリーン・アップしないと、ターゲットの場所でメッセージが蓄積され続け、サーバーでメモリー不足が発生する可能性があります。もう1つの例として、UOOメッセージが存在しない場所にルーティングされる可能性があります。
次に、クラスタ分散メッセージングの主なユースケースにおける考慮事項の詳細を示します。
インポート済宛先および分散宛先の永続メッセージは、ターゲットの場所で使用できなくなります。メッセージが失なわれないようにするには、移行を開始する前にすべてを処理し、分散宛先またはインポート済宛先にメッセージが残っていない状態にする必要があります。
クラスタをターゲットとし、分散ポリシーがDistributedに設定されたストアは、すべてのファイルを削除するか、JDBC表を削除しないかぎり、安全に移行できません。
ストア・アンド・フォワード・エージェントを移行するときには、追加の手順が必要になります。詳細は、「ストア・アンド・フォワード・メッセージの移行」を参照してください。
移行対象の分散宛先への転送を行うリモート・ストア・アンド・フォワード(SAF)エージェントがある場合は、リモート分散宛先を移行するとき、そのSAFエージェントに対する追加の手順が必要になります。 詳細は、「ストア・アンド・フォワード・メッセージの移行」を参照してください。
トピックからの転送に使用される分散恒久ブリッジを移行する場合は、注意が必要です。元の場所で生成された対応する恒久サブスクリプションは、新しい場所ではサブスクリプション名が異なるため、破棄される可能性があり、同様に、元のサブスクリプションによって、ソース・トピック上に引き続きメッセージが蓄積される可能性があります。管理者は、このようなブリッジによって生成され、元の場所で実行されているサブスクリプションが、移行中に確実に削除されるようにする必要があります。
永続UOOメッセージを処理する分散宛先では通常パス・サービスが使用されます。移行を開始する前に、パス・サービスのストア表またはファイルを削除し、新しい場所の新しいUOOメッセージが正しくルーティングされるようにする必要があります。
分散ストアでは、リソース・グループの移行前に開始された保留中のグローバル・トランザクションは、移行後に解決されない可能性があります。これは、移行後にストア・インスタンスのXAリソース名が変更されるためです。管理者は、クラスタでリソース・グループの移行を実行する前に、進行中のトランザクションが存在しないことを確認することをお薦めします。
ストア・アンド・フォワード・メッセージには、メッセージの格納と転送を行うSAFエージェントと最終的なWebLogic JMS宛先の2つのコンポーネントが関与します。多くの場合、これらは個別のWebLogic Serverインスタンス、クラスタまたはドメインにデプロイされるため、2つのコンポーネントを一緒に移行することも、それぞれ単独で移行することもできます。
必ず1回のQOSを使用して分散宛先への転送を行うリモートSAFエージェントがある場合は、リモート分散宛先を移行するとき、そのSAFエージェントに対する追加の手順が必要になります。これは、移行後、SAFメッセージが転送できなくなることにより、後続のメッセージの転送がブロックされる場合があるためです。この状況を回避するために、リモート分散宛先を移行する前に、次のことを実行してSAFキューを空にすることをお薦めします。
SAFエージェントでの新規メッセージの受信を一時停止します。詳細は、『Oracle WebLogic Server JMSリソースの管理』の宛先でのメッセージ処理の制御に関する項を参照してください。
保留中のメッセージがすべて正常に転送されるまで待ちます。
必ず1回の転送を処理するSAFエージェント自体を移行する場合は、非クラスタとクラスタのどちらかを問わず、同様の手順を実行することをお薦めします。このことは、SAFエージェントが非永続メッセージのみを処理する場合にも該当します。移行を開始する前に、SAFエージェントのインポート済宛先を空にするか(前述の説明を参照)、SAFエージェントに関連付けられているストア・ファイルまたはJDBC表をすべて削除することをお薦めします。
MDBのソース宛先がキューである場合は、MDBを安全に移行できます。同様に、MDBがトピックから消費し、かつ、そのsubscription-durabilityがNonDurableに設定されている場合も、MDBを安全に移行できます。
トピックを処理するMDBを移行するとき、そのsubscription-durabilityがDurableに設定されている場合は、MDBまたはトピックが、クラスタ・サーバーと非クラスタ・サーバーのどちらでホストされているかに関係なく、また、MDBのソース宛先が、MDB自体と同じクラスタでホストされているか、サーバーの場所でホストされているかに関係なく、さらに注意が必要です。
次に詳細を示します。
このような恒久サブスクリプション・トピックMDBを安全に移行できるのは、その構成でTopicMessagesDistributionMode=Compatibilityモードおよびgenerate-unique-client-id=falseが設定されているか、TopicMessagesDistributionMode=one-copy-per-applicationモードが設定されている場合のみです。詳細は、『Oracle WebLogic ServerメッセージドリブンBeanの開発』のMDB向けデプロイメント要素およびアノテーションに関する項を参照してください。
その他すべての恒久トピックMDBユースケース(TopicMessageDistributionMode=one-copy-per-server、またはTopicMessageDistributionMode=Compatibilityおよびgenerate-unique-client-id=true)では、MDBのサブスクリプション名にローカル・サーバーの名前が含まれ、このようなMDBを移行すると、元の恒久サブスクリプションが破棄されます。破棄された恒久サブスクリプションに関連付けられている未処理のメッセージが失われるだけでなく、破棄された恒久サブスクリプションによりメッセージが蓄積され続け、システム・メモリーの消費が増えて最終的にシステムが停止する可能性があります。このため、このような恒久MDBは、その接続先が非クラスタ、クラスタ・シングルトン、分散トピック、サード・パーティ・トピックのいずれであっても、より慎重に移行する必要があります。管理者は、このようなMDBによって生成され、元の場所で実行されているサブスクリプションが、移行中に確実に削除されるようにする必要があります。
MDBがリスニングする宛先が個別のリソース・グループまたはパーティションに存在する場合、リソース・グループを含むMDBのライブ移行を実行できますが、トピックMDBについての前述の考慮事項(破棄された恒久サブスクリプションに関する記述)は依然として該当します。
恒久MDBが分散トピックをリスニングしている場合は、MDBを移行しなくても、分散トピックを移行すると、関連付けられている恒久サブスクリプションが破棄される可能性があることに注意してください。移行を実行する前に、このような分散トピックの状態を削除する方法の詳細は、「クラスタ分散サービスの永続データの移行」を参照してください。
サード・パーティJMSプロバイダと統合されたJava EEアプリケーションを移行する場合は、保留中(インダウトとも呼ばれる)のすべてのトランザクションを事前に完了することが重要です。(この場合、サード・パーティJMSプロバイダとは、WL JMSおよびAQ JMS以外のプロバイダを指します)。
WebLogic ServerインスタンスまたはクラスタにデプロイされているJava EEアプリケーションにおいてサード・パーティJMSプロバイダがグローバル・トランザクションと統合される場合は、内部XAリソース名が作成され、その名前で外部XAリソースがWebLogicトランザクション・マネージャに登録されます。多くの場合、これらの名前には、ローカルのWebLogic Serverインスタンス名が含まれており、この名前は、このようなアプリケーションがリソース・グループの移行の一環として移行された後に変更される可能性があります。トランザクション・マネージャでは元の名前を使用して解決を試みるため、結果として、未決定のトランザクションが移行後に解決できなくなる可能性があります。
そこに含まれるリソース・グループとともに移行できるリモートJMSリソースをシームレスに操作するには、JMSクライアント・コードで既知のベスト・プラクティスに従って、JMS障害が発生したときに、すべてのJMSおよびJNDI接続を終了してから、JMSに再接続するようにする必要があります。詳細は、『Oracle WebLogic Server JMSリソースの管理』のJMSの初級ユーザーおよび上級ユーザー向けのベスト・プラクティスに関する項を参照してください。一部のコンテナおよびサービス(つまり、MDB、インバウンドSOA JMSアダプタおよびメッセージング・ブリッジ)では、クライアントのかわりにこの処理を自動的に実行できます。また、このようなJMSクライアントでは、再接続ロジックで使用されるURLが新しい場所に解決されるようにする必要があります。
リソース・グループの移行時にJMSリソースが移行される場合、例外リスナーのコールバックを介してクライアントに例外が返されるか、同期呼出しに対して例外が返される可能性があります。このとき、クライアントでは、リソースの新しい場所を指す新しいURLを使用するか、または移行中にアドレス再マッピング機能が使用される場合は元のURLを使用して、接続を再確立する必要があります。DNS再マッピングの例として、DNSマッピングの直接変更や、Oracle Traffic Director TCPプロキシを使用した変更をあげることができます。再確立時には、初期接続の確立時に使用した手順に再び従う必要があります。つまり、初期コンテキストの取得、宛先のルックアップ、接続ファクトリのルックアップ、接続の作成、セッションの作成、プロデューサの作成、コンシューマの作成の順に進める必要があります。
この後の各項で説明するJMSクライアント・フェイルオーバーの動作は、スタンドアロン・クライアントだけでなく、MDB、SOA JMSアダプタ、メッセージング・ブリッジなどのリモートまたはローカルJava EEアプリケーションにも該当します。
アドレス・マッピングが使用されない場合は、リソース・グループの移行が終了した後、それにアクセスするために元の場所に接続していたクライアントで次の手順を実行する必要があります。
既存の初期コンテキストおよびJMSオブジェクトを終了します。
新しい場所を指すようにURLを変更します。
新しいURLを使用して新しい初期コンテキストを再確立します。
初期コンテキストを使用してJMS宛先および接続ファクトリをルックアップします。
接続ファクトリおよび宛先を使用してJMSに接続します。
移行後にWebLogic Severインスタンスにのみ接続するクライアントでは、新しい場所を指すURLを使用する必要があります。
Oracle Traffic Director TCPプロキシ・メカニズムには、WebLogic Serverのホスティング・ホストおよびポートをOracle Traffic Directorプロキシのホストおよびポートとマップするための機能が備えられています。
Oracle Traffic Director機能を使用するには、移行対象のリソース・グループをホストするパーティションに対するOracle Traffic Directorマッピングを構成する必要がある以外に、Oracle Traffic Directorプロキシのホスト名を使用するようにパーティションの仮想ターゲットを構成するとともに、移行対象のリソース・グループ内のリソースに接続するときにOracle Traffic DirectorプロキシのURLを使用して初期コンテキストを確立するようにアプリケーションを構成することも必要となります。詳細は、『Oracle Traffic Director管理者ガイド』のTCPプロキシの作成に関する項を参照してください。
Oracle Traffic Directorプロキシと、Oracle Traffic Directorを使用するリソース・グループ仮想ターゲットを構成した後は、リソース・グループの移行後にアプリケーション・クライアントで次のいずれかを実行することによって、より少ない手動操作で、クライアントが新しい場所に再接続およびフェイルオーバーできるようになります。
新しい初期コンテキストを再確立します。
移行後に、移行前に取得した接続ファクトリ・スタブを使用して新しいJMS接続を作成します。
Oracle Traffic Directorサポートが存在するため、手動で実行する必要がある手順は、ターゲットURLをプロキシのURLに再マップし、移行後にプロキシ・インスタンスを再起動することのみです。古いサーバーに対する既存の接続がすべて破棄されるようにするために、再起動することが必要となります。再起動しないと、移行後に新規に接続するクライアントは新しい場所にルーティングされますが、移行前から接続していたクライアントは新しい場所にフェイルオーバーできない可能性があります。
