5 簡略化されたJMSクラスタと高可用性の構成

この章では、クラスタ指定の新しい拡張と、それによるJMS構成プロセスの簡略化について説明します。これらの拡張により、クラスタまたはWebLogic Serverマルチテナント環境で、広範囲な構成プロセスの必要なく、JMSサービスを、動的にスケーラブルで、可用性が高くなるようにできます。

この章の内容は次のとおりです。

JMSのWebLogicクラスタリング・オプションとは

WebLogicクラスタには、個別に構成されたサーバー、動的に生成されたサーバー、またはその両方が含まれます。WebLogic Serverには、次のクラスタ・タイプがあります。

構成済: 各メンバー・サーバーが個別に構成され、それぞれがそのクラスタにターゲット指定されています。クラスタ構成の「動的クラスタ・サイズ」属性の値は、0です。「クラスタ: 構成: サーバー」を参照してください。このタイプのクラスタは、静的クラスタとも言います。
動的: すべてのメンバー・サーバーがサーバー・テンプレートを使用して作成されるクラスタです。これらのサーバーは動的サーバーと呼ばれます。クラスタ構成の「クラスタ: 構成: サーバー」タブの「動的クラスタ・サイズ」属性の値は、0より大きくなります。
混在: 一部のメンバー・サーバーはサーバー・テンプレートを使用して作成され(動的サーバー)、残りのサーバーは手動で構成されます(構成済サーバー)。混在クラスタには動的サーバーが含まれるため、クラスタ構成の「クラスタ: 構成: サーバー」タブの「動的クラスタ・サイズ」属性の値は0より大きくなります。

動的サーバーの使用方法の詳細は、次を参照してください。

『Oracle WebLogic Serverクラスタの管理』の動的クラスタに関する項を参照してください。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの動的クラスタの作成に関する項および動的なクラスタ化JMSの構成に関する項を参照してください。

簡略化されたJMSクラスタ構成の理解

クラスタ化されたJMSサービスは、JMSサービス・アーティファクト(たとえばJMSサーバー、SAFエージェントおよびパス・サービス)と任意の関連する永続ストアに対して、同じクラスタをターゲットにすることができます。ストアを使用しないJMSアーティファクトであるメッセージング・ブリッジも、クラスタをターゲットにできます。(必須)ここに概要文を記入します。文には概念の定義と目的を含めます。

クラスタ上に分散されるように構成されたJMSサービス・アーティファクトの場合、分散ポリシーにより異なりますが、新しい各サーバーが起動すると、クラスタは各クラスタ・メンバー上でアーティファクト(および該当する場合は関連付けられたストア)の1つのインスタンスを自動的に起動し、そのメンバーはそのインスタンスの優先サーバーと呼ばれます。分散されないアーティファクトの場合、システムはクラスタ内のサーバーを選択し、そのアーティファクトの単一インスタンスを起動します。「簡略化されたJMS構成と高可用性の拡張機能」を参照してください。

動的または混在クラスタの場合、クラスタ・サイズが増大すると、インスタンス数は自動的に増加します。動的クラスタや混在クラスタ、または混在クラスタの動的サーバーのサイズを動的にスケールするには、クラスタ構成の「クラスタ: 構成: サーバー」タブにある「サーバーの最大数」属性を調整します。

図5-1は、config.xmlファイルにおけるJMSと動的クラスタ構成との関係を示しています。

図5-1 動的なクラスタ化JMS

「図5-1 動的なクラスタ化JMS」の説明

クラスタをターゲットに指定されたJMSサービス・アーティファクトを持つカスタム永続ストアの使用

JMSサービス・アーティファクトによって使用されるカスタム永続ストアで、クラスタ拡張の利点を活用するには、適切な属性値を構成して、同じクラスタをターゲットとして指定する必要があります。ただし、クラスタをターゲットとして指定されたSAFエージェントおよびJMSサーバーは各クラスタ・メンバーが利用できるデフォルト・ストアを使用し続けることもできますが、その場合、この章で説明する新しい拡張機能は提供されません。「簡略化されたJMS構成と高可用性の拡張機能」を参照してください。

JMSのモジュール・リソースのターゲット指定

JMSシステム・モジュールは、引き続き2タイプのターゲット指定をサポートし、どちらを使用しても簡略化されたクラスタ化構成を利用できます。

モジュール内でターゲットがデフォルト指定されるJMSリソース(サブデプロイメントに関連付けられていないJMSリソース)は、その親モジュールのターゲット指定を継承します。親モジュールは任意のタイプのクラスタにターゲット指定できます。
モジュールsubdeploymentターゲットは、通常の宛先またはインポートされた宛先をホスティングするために、それぞれ、クラスタ化されたJMSサーバーまたはSAFエージェントを参照できます。クラスタをターゲットとして指定されたJMSサーバーまたはSAFエージェントをサブデプロイメントで使用すると、サブデプロイメントでJMSサーバーまたはSAFエージェントを個別に作成して、列挙する必要がなくなります。これは特に、共通分散宛先やインポートされた宛先のデプロイメントで便利です。

「ターゲット指定のベスト・プラクティス」を参照してください。

注意:

モジュールまたはそのサブデプロイメントを直接動的クラスタ・メンバー・サーバーにターゲット指定することはできません。

クラスタのターゲットとして指定されたJMSサーバーと永続ストアの併用

クラスタのターゲットとして指定されたJMSサーバーに関連付けられた永続ストアは、同じクラスタにターゲット指定されたカスタム永続ストアである場合も、各クラスタ・メンバー上で使用可能なデフォルト・ストアである場合もあります。

JMSのモジュール・リソースのターゲット指定

JMSシステム・モジュールは、引き続き2タイプのターゲット指定をサポートし、どちらを使用しても簡略化されたクラスタ化構成を利用できます。

モジュール内でターゲットがデフォルトで指定されるJMSリソース(サブデプロイメントに関連付けられていないJMSリソース)は、その親モジュールのターゲット指定を継承します。親モジュールは任意のタイプのクラスタをターゲットにできます。
モジュールのサブデプロイメントのターゲットは、クラスタ化されたJMSサーバーを参照できます。サブデプロイメントでクラスタのターゲットとして指定されたJMSサーバーを使用すると、サブデプロイメント内の個々のJMSサーバーを個別に列挙する必要がなくなるため、共通分散宛先デプロイメントでは特に便利です。

「ターゲット指定のベスト・プラクティス」を参照してください

注意:

モジュールまたはそのサブデプロイメントを直接動的クラスタ・メンバーにターゲット指定することはできません。

簡略化されたJMS構成と高可用性の拡張機能

WebLogic Serverは、クラスタにデプロイされたJMSサービス・アーティファクトで、高可用性をサポートします。サーバーおよびサービスの障害のシナリオは、アーティファクトのインスタンスを他の実行中サーバーに自動的に移行することによって処理されます。この過程で、システムは全体のサーバー負荷および可用性を評価し、それに応じてインスタンスを移動します。

WebLogic Serverのこのリリースの、クラスタをターゲットに指定する拡張により、以前のリリースに存在した制限の多くが不要になりました。

以前のリリースでは、JMSサーバー、永続ストア、およびSAFエージェント(部分的)だけがクラスタをターゲットに指定できました。このリリースでは、SAFエージェント、パス・サービス、メッセージング・ブリッジなど、すべてのJMSサービス・アーティファクトと、あらゆるタイプのクラスタ(構成済、混在、動的)にまでサポートが拡張されました。
このリリースでの拡張により、クラスタをターゲットにしたすべてのJMSサービス・アーティファクトで分散の動作やJMS高可用性(JMS自動サービス移行とも呼ばれます)の動作を容易に構成、制御できます。これらの構成はすべて単一の場所、つまり永続ストアに依存するすべてのアーティファクトの場合は永続ストア、ストアを使用しないものについてはメッセージング・ブリッジに集められました。これにより、以前のリリースで使用された移行可能ターゲットが不要になります。
論理JMSアーティファクトはクラスタをターゲットにしているため、システムはクラスタの結合時に、必要な「物理」インスタンスをクラスタ・メンバー上に自動的に作成します。これにより、クラスタ・サイズが増大するときに、JMSサービスが自動的にスケール・アップすることが可能になります。オプションの高可用性構成を使用すると、「物理」インスタンスは、サービス障害またはサーバーの障害や停止が生じた場合に再起動または移行できるため、最小構成でのJMSサービスの可用性が向上します。

スケーラビリティおよび高可用性の動作を制御するプライマリ属性は、分散ポリシーと移行ポリシーです。これらのポリシーに加えて、別の場所に移行する前のインスタンスのインプレース再起動(同一サーバー上)など、高可用性動作を微調整するために使用できる追加の属性がいくつかあります。次の各項では、これらのポリシーと属性について説明します。

JMSサービスのための分散ポリシーの定義

カスタム永続ストアまたはメッセージング・ブリッジのための分散ポリシー設定は、関連付けられたJMSサービス・アーティファクト(JMSサーバー、SAFエージェントおよびパス・サービス)がクラスタに分散される方法を決定し、メッセージング・ブリッジ上の同じ設定がその分散動作を決定します。

次に、JMSサービス・アーティファクトの分散動作を制御するオプションを示します。

分散完了: このモードでは、クラスタは自動的に、サーバーごとに最低1つのインスタンスを確保します。クラスタが起動すると、システムはすべてのメッセージング・サービス・インスタンスを稼働状態にします(可能な場合)。また、該当する場合は、インスタンスの均一分散を試みます。また、すべてのインスタンスは、自動的にまずホームまたは優先サーバー上での起動を試みます。移行ポリシーによって、インスタンスは自動的に移行することも、場合によってフェイルバックを行い、クラスタ全体での高可用性と均一なロード・バランシングを確実にすることもできます。
注意:
分散ポリシーは、このポリシーのデフォルト値です。共通分散宛先(UDD)をホスティングする、クラスタをターゲットとして指定されたSAFエージェントとクラスタをターゲットとして指定されたJMSサーバーでも必須です。
このオプションはデフォルト・ポリシーであり、共通分散宛先(UDD)をホスティングする、クラスタをターゲットとして指定されたSAFエージェントとクラスタをターゲットとして指定されたJMSサーバーでも必須です。
シングルトン: このモードでは、JMSサーバーまたはパス・サービスはクラスタごとに1つのインスタンスを持っています。

注意:
このオプションはパス・サービスで必須です。また、シングルトン宛先またはスタンドアロン(非分散)宛先をホストする、クラスタをターゲットにしたJMSサーバーでも必須です。
分散ポリシーの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストア: HA構成に関する項を参照してください

JMSサービスのための追加の構成オプション

表6-1は、JMSサービスの自動移行と高可用性に利用できる、追加のストア構成オプションを示しています。次の設定は、JMSアーティファクトがターゲットとしてクラスタを指定されていて、移行ポリシーが「失敗時」または「常時」に設定されている場合に適用されます。

表5-1 JMSサービス移行のための構成プロパティ

プロパティ	デフォルト値	説明
再起動準備完了	True	正常なWebLogic Server内で、システムがJMSサービス障害にどのように応答するかを定義します。サービスが失敗した場合に、このプロパティが有効にされると、まずシステムはそのストアと、同じサーバー上の関連するサービス・アーティファクトの再起動を試行し、その後で別のサーバーに移行します。注意: この属性は、サーバー全体に障害が発生したときには適用されません。
再起動間隔	30	Restart In Placeが有効の場合、このプロパティは同じサーバー上での再起動と再起動の間の遅延を秒単位で指定します。
再起動回数	6	Restart In Placeが有効の場合、この数は別のサーバーへのアーティファクト・インスタンス移行を試行する前に、システムが行う再起動試行回数を決定します。
初期起動遅延(秒)	60	最初のインスタンスが起動された後、後続の高速インスタンスがサーバー上でどのように起動されるかを制御します。これにより、システムが起動時に過負荷になるのを防止できます。値0は、システムが待機する必要はないことを示しますが、これは過負荷状況に導く場合があります。システムのデフォルト値は60秒です。
フェイルバック遅延(秒)	-1	アーティファクトのインスタンスを優先サーバーにフェイルバックする前に待機する時間を指定します。 0より大きい値は、JMSアーティファクトを優先サーバーにフェイルバックする前に、遅延させる時間を秒数で指定します。値に0を指定した場合、インスタンスはフェイルバックしません。値に-1を指定した場合、遅延は発生せず、インスタンスはただちにフェイルバックします。
部分クラスタ安定遅延	240	部分的に起動されたクラスタが、「常時」または「失敗時」の移行ポリシーで構成された、クラスタをターゲットとして指定されたすべてのJMSアーティファクト・インスタンスを開始する前に、遅延させる時間を秒数で指定します。この遅延によって、サーバーが順次起動される場合でも、サービスがクラスタ全体で分散されます。 > 0の値は、部分的に開始されたクラスタが動的に構成されたサービスを開始する前に、遅延させる時間を秒数で指定します。値0は、利用できるサーバー上でのすべてのインスタンスを遅延なしで起動することを指定します。遅延のデフォルト値は240秒です。

これらのプロパティの詳細は、JDBCストア: HA構成に関する項を参照してください

クラスタ化されたJMSの考慮事項と制限事項

次に示す制限事項とその他の動作では、動的クラスタとクラスタをターゲットにしたJMSサーバーを使用してアプリケーションを開発する前に考慮する必要のある制限事項とその他の動作に関する情報を提供します。

QOSレベルがExactly-OnceのSAFエージェント・インポート済宛先が、混在または動的クラスタでホストされる分散宛先にメッセージを転送する場合は、特別な考慮が必要です。「クラスタ化されたJMSサービスを使用する場合のベスト・プラクティス」を参照してください。
WLSTオフラインでは、JMSサーバーを動的クラスタにターゲット指定するassignコマンドはサポートされません。getおよびsetコマンドを使用してください。
クラスタをターゲットとして指定されたJMSサーバーでは、重み設定された分散宛先(シングルトン宛先のグループで構成された非推奨の分散宛先タイプ)はサポートされません。
クラスタをターゲットにしたJMSサーバーでホストされているメンバー宛先が1つでもある場合は、複製された分散トピック(RDT)はサポートされません。
クラスタをターゲットとして指定されたJMSアーティファクトから生成されたサービス・インスタンスの移行またはフェイルバックを手動で(管理側から)強制することはサポートされていません。
順序単位(UOO)メッセージのホストに使用される、なんらかの分散またはインポート済宛先がある場合は、パス・サービスを構成する必要があります。さらに、ハッシュ・ベースのUOOルーティングは、クラスタをターゲットにしたJMSではサポートされないため、そのような宛先は、デフォルトのハッシュされたUOOルーティング・ポリシーでなく、パス・サービスUOOルーティング・ポリシーを使用して構成する必要があります。

クラスタをターゲットとして指定されたJMSサービス上でホスティングされている、分散またはインポートされた宛先にメッセージを送信しようとすると、失敗して例外が発生します。

シングルトン分散ポリシーと常時移行ポリシーを持つストアを参照するには、クラスタをターゲットにしたパス・サービスを構成する必要があります。

クラスタのターゲットとして指定されたJMSサーバーの相互運用性とアップグレードに関する考慮事項

次の項では、クラスタをターゲットにしたJMSサーバーを使用する場合の相互運用性とアップグレードの考慮事項について説明します。

以前のリリースのJMSクライアント、ブリッジ、MDB、SAFクライアント、およびSAFエージェントは、クラスタのターゲットとして指定されたJMSサーバーと通信できます。
QOSレベルがExactly-OnceのSAFエージェント・インポート済宛先が、混在または動的クラスタでホストされる分散宛先にメッセージを転送する場合は、特別な考慮が必要です。「クラスタ化されたJMSサービスを使用する場合のベスト・プラクティス」を参照してください
データ(メッセージ)を移動するための変換パスはなく、クラスタのターゲットとして指定されていないJMSサーバーからクラスタのターゲットとして指定されたJMSサーバーへの構成やその逆の構成もできません。

移行可能ターゲット・ベースのJMSサービスのサービス移行は、構成済クラスタでサポートされています。

たとえば、JMSサーバーと永続ストアのメッセージング構成では、1つの手動で構成されたWebLogic Serverまたは1つの移行可能なターゲットをターゲットに指定できます。同様に、SAFエージェントは、1つの手動で構成されたWebLogic Server、移行可能なターゲット、またはクラスタをターゲットにできます。

「JMSサービスの自動移行」を参照してください

クラスタ化されたJMSサービスを使用する場合のベスト・プラクティス

次の項では、ベスト・プラクティスとデザイン・パターンに関する情報を提供します。

動的クラスタのサイズを縮小したり、混在クラスタ内の動的クラスタ・メンバー数を削減する前に、クラスタをターゲットにしたJMSサーバーでホストされている宛先を削除し、その後でWebLogic Serverインスタンスを停止します。例:
1. 本番用の個々の宛先を休止します。
2. アプリケーションで宛先を削除します。
3. サーバー・インスタンスを停止します。
クラスタをターゲットにしたJMSサーバーとSAFエージェント用のデフォルト・ストアのかわりに、クラスタをターゲットにしたストアを使用します。
高可用性を有効化した場合(つまり、ストア上の移行ポリシーが「失敗時」または「常時」のいずれかに設定されている場合)、クラスタ・リースが構成されていることを確認してください。コンセンサス・リースよりデータベース・リースがベスト・プラクティスになります。詳細は、『Oracle WebLogic Serverクラスタの管理』のリースに関する項を参照してください。
モジュールでの宛先の構成時に、デフォルトのターゲット指定を使用せずに特定のクラスタ化されたJMSサーバーまたはSAFエージェントをターゲットにするサブデプロイメントを使用します。これにより、宛先では、目的としている正確なJMSサーバー・インスタンス上にメンバーが作成されます。
QOSレベルがExactly-OnceのSAFエージェントやSAFクライアントを使用する場合、ベスト・プラクティスとして、SAFエージェントに関連付けられたストアが「常時」に設定された移行ポリシーで構成されていることを確認してください。

また、クラスタ・サイズが変更された場合(特に縮小された場合)、バッキング表(JDBCストアの場合)またはファイル(FILEストアの場合)をいずれかの利用できるクラスタ・メンバーに移行して、SAFサービスの連続的な可用性を確保できるように、それらが削除または破棄されていないことを確認してください。

実行時MBeanインスタンスの名前付け構文

クラスタ内に分散されJMSアーティファクト(永続ストア、JMSサーバー、SAFAgent、MessagingBridgeおよびPathServiceなど)のそれぞれに関連付けられている実行時MBeanは、分散ポリシーのセットに基づいて名前が付けられます。これはMBeanチェックによって強制されます。

分散ポリシーのタイプには、次のものがあります。

分散完了 — インスタンスは、そのインスタンスのホームまたは優先されるWebLogic Serverの初回起動時に名前を指定することで、自動的に作成され一意の名前が付けられます。形式は<configured-name>@<server-name>になります。

シングルトン — インスタンスには、構成された名前に「01」を加えた名前が付けられます。形式は<configured-name>–01になります。このインスタンス名にサーバー名は追加されません。

次の項では、永続ストアのインスタンス名前付け構文について概説します。

.DATファイルのインスタンスの名前付け構文

クラスタをターゲットにしたファイル・ストア(.DATファイル)の場合、インスタンスのデータ・ファイルには、対応するストアのインスタンス名に基づいて一意の名前が付けられます。たとえば、分散完了モードでは、インスタンスのファイルには<Store name>@<Server instance name>NNNNNN.DATという名前が付きます。<NNNNNN>は000000～999999の範囲の数字になります。

注意:

1つのファイルのインスタンスが1つ以上の.DATファイルを作成する場合があります。

.RGNファイルのインスタンスの名前付け構文

クラスタをターゲットにした、レプリケートされたストアのインスタンスのリージョンは、対応するストアのインスタンス名に基づいて、一意の名前が付けられます。たとえば、分散完了モードでは、レプリケートされたストアのインスタンスには、構文<configured Replicated Store name>@<Server instance name>NNNNNN.RGNが含まれます。<NNNNNN>は000000–999999の範囲の数字になります。

JDBCストアの表名の構文

JDBCストアのデータベースの表名は、デフォルトではWLStoreです。表名は、JDBCストアのPrefixName設定を使用して頻繁に変更し、異なるJDBCストアが別の表を使用できるようにする必要があります。JDBCストアの2つの異なるインスタンスは、同じバックアップ表を共有できません。分散ポリシーの設定によって、データベースの表名が生成されます。表5-2を参照してください

表5-2 クラスタをターゲットにした場合のJDBCストアの表名の構文

デフォルト名	prefixName	分散ポリシー	インスタンス名	ストアの表名
WLStore	myPrefix	分散	myServer	myPrefix_myServer_WLStore
	myPrefix('.'で終わる)	分散	myServer	myPrefix._myServer_WLStore
	なし	分散	myServer	myServer_WLStore
	myPrefix	シングルトン	01	myPrefix_01_WLStore
	myPrefix	シングルトン	01	myPrefix.S_01_WLStore
	なし	シングルトン	01	S_01_WLStore
クラスタをターゲットにしない場合(単一サーバー)
WLStore	myPrefix	なし	なし	myPrefixWLStore
	なし	なし	なし	WLStore

JMSサービスのための移行ポリシーの定義

移行ポリシーは、クラスタをターゲットとして指定されたJMSサービス・アーティファクト・インスタンスの移行および再起動動作を制御します。高可用性およびサービス移行については、関連付けられたストア上で、移行ポリシーを次のとおりに設定します。

オフ: このオプションは、インプレースの移行および再起動を無効にします。

常時: このオプションを使用すると、システムはすべての状況でインスタンスを自動的に移行できます。これには、ホスティング・サーバーまたはサブシステム・サービスの、管理上の停止、クラッシュまたは状態不良を含みます。このオプションはサービスの移行も有効化します。これは、現在のホスト・サーバー上の障害が発生したストアを自動的に再起動するか、インプレース再起動構成に基づいて別のサーバーに移行します。

失敗時: このオプションを使用すると、システムは、ホスティング・サーバーの障害またはクラッシュ(状態不良)が生じた場合のみ、インスタンスを自動的に移行できます。管理上の停止があった場合、インスタンスは移行せず、そのかわりに、サーバーが再起動されたときに再起動します。このオプションはサービスの移行も有効化します。これは、同じホスト・サーバー上の障害が発生したストアを自動的に再起動するか、インプレース再起動構成に基づいて別のサーバーに移行します。

注意:

クラスタをターゲットとして指定されている、移行ポリシーが「常時」または「失敗時」であるJMSサービス・アーティファクトのサポートを有効化するには、クラスタ・リーシングを構成する必要があります。詳細は、『Oracle WebLogic Serverクラスタの管理』のリースに関する項を参照してください。
コンセンサス・リーシングでなく、データベース・リーシングのオプションを使用するのがベスト・プラクティスです。
分散インスタンスが優先サーバーから移行される場合、優先サーバーが再起動されるときにフェイルバックを試みます。

移行ポリシーの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストア: HA構成に関する項を参照してください