この章では、クラスタ指定の新しい拡張と、それによるJMS構成プロセスの簡略化について説明します。これらの拡張により、クラスタまたはWebLogic Serverマルチテナント環境で、広範囲な構成プロセスの必要なく、JMSサービスを、動的にスケーラブルで、可用性が高くなるようにできます。
この章の内容は次のとおりです。
WebLogicクラスタには、個別に構成されたサーバー、動的に生成されたサーバー、またはその両方が含まれます。WebLogic Serverには、次のクラスタ・タイプがあります。
構成済: 各メンバー・サーバーが個別に構成され、それぞれがそのクラスタにターゲット指定されています。クラスタ構成の「動的クラスタ・サイズ」属性の値は、0です。 WebLogic Server管理コンソール・オンライン・ヘルプのクラスタ: 構成: サーバーに関する項を参照してください。このタイプのクラスタは、静的クラスタとも言います。
動的: すべてのメンバー・サーバーがサーバー・テンプレートを使用して作成されるクラスタです。これらのサーバーは動的サーバーと呼ばれます。クラスタ構成の「クラスタ: 構成: サーバー」タブの「動的クラスタ・サイズ」属性の値は、0より大きくなります。
混在: 一部のメンバー・サーバーはサーバー・テンプレートを使用して作成され(動的サーバー)、残りのサーバーは手動で構成されます(構成済サーバー)。混在クラスタには動的サーバーが含まれるため、クラスタ構成の「クラスタ: 構成: サーバー」タブの「動的クラスタ・サイズ」属性の値は、0より大きくなります。
動的サーバーの使用方法の詳細は、次を参照してください。
Oracle WebLogic Serverクラスタの管理の動的クラスタを参照してください。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの動的クラスタの作成および動的なクラスタ化JMSの構成を参照してください
クラスタ化されたJMSサービスは、JMSサービス・アーティファクト(たとえばJMSサーバー、SAFエージェントおよびパス・サービス)と任意の関連する永続ストアに対して、同じクラスタをターゲットにすることができます。ストアを使用しないJMSアーティファクトであるメッセージング・ブリッジも、クラスタをターゲットにできます。(必須)ここに概要文を記入します。文には概念の定義と目的を含めます。
クラスタ上に分散されるように構成されたJMSサービス・アーティファクトの場合、分散ポリシーにより異なりますが、新しい各サーバーが起動すると、クラスタは各クラスタ・メンバー上でアーティファクト(および該当する場合は関連付けられたストア)の1つのインスタンスを自動的に起動し、そのメンバーはそのインスタンスの優先サーバーと呼ばれます。分散されないアーティファクトの場合、システムはクラスタ内のサーバーを選択し、そのアーティファクトの単一インスタンスを起動します。「簡略化されたJMS構成と高可用性の拡張機能」を参照してください。
動的または混在クラスタの場合、クラスタ・サイズが増大すると、インスタンス数は自動的に増加します。動的クラスタや混在クラスタ、または混在クラスタの動的サーバーのサイズを動的にスケールするには、クラスタ構成の 「クラスタ: 構成: サーバー」タブにある「サーバーの最大数」属性を調整します。
図5-1は、config.xml
ファイルにおけるJMSと動的クラスタ構成との関係を示しています。
クラスタをターゲットに指定されたJMSサービス・アーティファクトを持つカスタム永続ストアの使用
JMSサービス・アーティファクトによって使用されるカスタム永続ストアで、クラスタ拡張の利点を活用するには、適切な属性値を構成して、同じクラスタをターゲットとして指定する必要があります。ただし、クラスタをターゲットとして指定されたSAFエージェントおよびJMSサーバーは各クラスタ・メンバーが利用できるデフォルト・ストアを使用し続けることもできますが、その場合、この章で説明する新しい拡張機能は提供されません。「簡略化されたJMS構成と高可用性の拡張機能」を参照してください。
JMSのモジュール・リソースのターゲット指定
JMSシステム・モジュールは、引き続き2タイプのターゲット指定をサポートし、どちらを使用しても簡略化されたクラスタ化構成を利用できます。
モジュール内でターゲットがデフォルト指定されるJMSリソース(サブデプロイメントに関連付けられていないJMSリソース)は、その親モジュールのターゲット指定を継承します。親モジュールは任意のタイプのクラスタにターゲット指定できます。
モジュールsubdeploymentターゲットは、通常の宛先またはインポートされた宛先をホスティングするために、それぞれ、クラスタ化されたJMSサーバーまたはSAFエージェントを参照できます。クラスタをターゲットとして指定されたJMSサーバーまたはSAFエージェントをサブデプロイメントで使用すると、サブデプロイメントでJMSサーバーまたはSAFエージェントを個別に作成して、列挙する必要がなくなります。これは特に、共通分散宛先やインポートされた宛先のデプロイメントで便利です。
「ターゲット指定のベスト・プラクティス」を参照してください。
注意:
モジュールまたはそのサブデプロイメントを直接動的クラスタ・メンバー・サーバーにターゲット指定することはできません。クラスタのターゲットとして指定されたJMSサーバーに関連付けられた永続ストアは、同じクラスタにターゲット指定されたカスタム永続ストアである場合も、各クラスタ・メンバー上で使用可能なデフォルト・ストアである場合もあります。
JMSシステム・モジュールは、引き続き2タイプのターゲット指定をサポートし、どちらを使用しても簡略化されたクラスタ化構成を利用できます。
モジュール内でターゲットがデフォルトで指定されるJMSリソース(サブデプロイメントに関連付けられていないJMSリソース)は、その親モジュールのターゲット指定を継承します。親モジュールは任意のタイプのクラスタをターゲットにできます。
モジュールのサブデプロイメントのターゲットは、クラスタ化されたJMSサーバーを参照できます。サブデプロイメントでクラスタのターゲットとして指定されたJMSサーバーを使用すると、サブデプロイメント内の個々のJMSサーバーを個別に列挙する必要がなくなるため、共通分散宛先デプロイメントでは特に便利です。
「ターゲット指定のベスト・プラクティス」を参照してください
注意:
モジュールまたはそのサブデプロイメントを直接動的クラスタ・メンバーにターゲット指定することはできません。
WebLogic Serverは、クラスタにデプロイされたJMSサービス・アーティファクトで、高可用性をサポートします。サーバーおよびサービスの障害のシナリオは、アーティファクトのインスタンスを他の実行中サーバーに自動的に移行することによって処理されます。この過程で、システムは全体のサーバー負荷および可用性を評価し、それに応じてインスタンスを移動します。
WebLogic Serverのこのリリースの、クラスタをターゲットに指定する拡張により、以前のリリースに存在した制限の多くが不要になりました。
以前のリリースでは、JMSサーバー、永続ストア、およびSAFエージェント(部分的)だけがクラスタをターゲットに指定できました。このリリースでは、SAFエージェント、パス・サービス、メッセージング・ブリッジなど、すべてのJMSサービス・アーティファクトと、あらゆるタイプのクラスタ(構成済、混在、動的)にまでサポートが拡張されました。
このリリースでの拡張により、クラスタをターゲットにしたすべてのJMSサービス・アーティファクトで分散の動作やJMS高可用性(JMS自動サービス移行とも呼ばれます)の動作を容易に構成、制御できます。これらの構成はすべて単一の場所、つまり永続ストアに依存するすべてのアーティファクトの場合は永続ストア、ストアを使用しないものについてはメッセージング・ブリッジに集められました。これにより、以前のリリースで使用された移行可能ターゲットが不要になります。
論理JMSアーティファクトはクラスタをターゲットにしているため、システムはクラスタの結合時に、必要な「物理」インスタンスをクラスタ・メンバー上に自動的に作成します。これにより、クラスタ・サイズが増大するときに、JMSサービスが自動的にスケール・アップすることが可能になります。オプションの高可用性構成を使用すると、「物理」インスタンスは、サービス障害またはサーバーの障害や停止が生じた場合に再起動または移行できるため、最小構成でのJMSサービスの可用性が向上します。
スケーラビリティおよび高可用性の動作を制御するプライマリ属性は、分散ポリシーと移行ポリシーです。これらのポリシーに加えて、別の場所に移行する前のインスタンスのインプレース再起動(同一サーバー上)など、高可用性動作を微調整するために使用できる追加の属性がいくつかあります。次の各項では、これらのポリシーと属性について説明します。
カスタム永続ストアまたはメッセージング・ブリッジのための分散ポリシー設定は、関連付けられたJMSサービス・アーティファクト(JMSサーバー、SAFエージェントおよびパス・サービス)がクラスタに分散される方法を決定し、メッセージング・ブリッジ上の同じ設定がその分散動作を決定します。
注意:
分散ポリシーは、このポリシーのデフォルト値です。共通分散宛先(UDD)をホスティングする、クラスタをターゲットとして指定されたSAFエージェントとクラスタをターゲットとして指定されたJMSサーバーでも必須です。このオプションはデフォルト・ポリシーであり、共通分散宛先(UDD)をホスティングする、クラスタをターゲットとして指定されたSAFエージェントとクラスタをターゲットとして指定されたJMSサーバーでも必須です。
シングルトン: このモードでは、JMSサーバーまたはパス・サービスはクラスタごとに1つのインスタンスを持っています。
注意:
このオプションはパス・サービスで必須です。また、シングルトン宛先またはスタンドアロン(非分散)宛先をホストする、クラスタをターゲットにしたJMSサーバーでも必須です。分散ポリシーの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストア: HA構成に関する項を参照してください
移行ポリシーは、クラスタをターゲットとして指定されたJMSサービス・アーティファクト・インスタンスの移行および再起動動作を制御します。高可用性およびサービス移行については、関連付けられたストア上で、移行ポリシーを次のとおりに設定します。
オフ: このオプションは、インプレースの移行および再起動を無効にします。
常時: このオプションを使用すると、システムはすべての状況でインスタンスを自動的に移行できます。これには、ホスティング・サーバーまたはサブシステム・サービスの、管理上の停止、クラッシュまたは状態不良を含みます。このオプションはサービスの移行も有効化します。これは、現在のホスト・サーバー上の障害が発生したストアを自動的に再起動するか、インプレース再起動構成に基づいて別のサーバーに移行します。
注意:
クラスタをターゲットとして指定されている、移行ポリシーが「常時」または「失敗時」であるJMSサービス・アーティファクトのサポートを有効化するには、クラスタ・リーシングを構成する必要があります。詳細は、『Oracle WebLogic Serverクラスタの管理』のリースに関する項を参照してください。
JMSサービス移行とJTA移行は、その移行ポリシーに基づいて独立して動作します。動的クラスタとJTA移行ポリシーの詳細は、サービスの移行フレームワークの理解を参照してください。
コンセンサス・リーシングでなく、データベース・リーシングのオプションを使用するのがベスト・プラクティスです。
分散インスタンスが優先サーバーから移行される場合、優先サーバーが再起動されるときにフェイル・バックを試みます。
移行ポリシーの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストア: HA構成に関する項を参照してください
表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秒です。 |
これらのプロパティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストア: HA構成に関する項を参照してください。
次に示す制限事項とその他の動作では、動的クラスタとクラスタをターゲットにしたJMSサーバーを使用してアプリケーションを開発する前に考慮する必要のある制限事項とその他の動作に関する情報を提供します。
QOSレベルがExactly-OnceのSAFエージェント・インポート済宛先が、混在または動的クラスタでホストされる分散宛先にメッセージを転送する場合は、特別な考慮が必要です。「クラスタ化されたJMSサービスを使用する場合のベスト・プラクティス」を参照してください。
WLSTオフラインでは、JMSサーバーを動的クラスタにターゲット指定するassign
コマンドはサポートされません。get
およびset
コマンドを使用してください。
クラスタをターゲットとして指定されたJMSサーバーでは、重み設定された分散宛先(シングルトン宛先のグループで構成された非推奨の分散宛先タイプ)はサポートされません。
クラスタをターゲットにしたJMSサーバーでホストされているメンバー宛先が1つでもある場合は、複製された分散トピック(RDT)はサポートされません。
「シングルトン」分散ポリシーが設定されたカスタム永続ストアおよび「常時」(または「失敗時」)が設定された移行ポリシーが、クラスタをターゲットにしたJMSサーバーでスタンドアロン宛先を使用できるために必要です。
クラスタをターゲットとして指定されたJMSアーティファクトから生成されたサービス・インスタンスの移行またはフェイルバックを手動で(管理側から)強制することはサポートされていません。
順序単位(UOO)メッセージのホストに使用される、なんらかの分散またはインポート済宛先がある場合は、パス・サービスを構成する必要があります。さらに、ハッシュ・ベースのUOOルーティングは、クラスタをターゲットにしたJMSではサポートされないため、そのような宛先は、デフォルトのハッシュされたUOOルーティング・ポリシーでなく、パス・サービスUOOルーティング・ポリシーを使用して構成する必要があります。
クラスタをターゲットとして指定された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サーバーでホストされている宛先を削除し、その後でWebLogic Serverインスタンスを停止します。例:
本番用の個々の宛先を休止します。
アプリケーションで宛先を削除します。
サーバー・インスタンスを停止します。
クラスタをターゲットにしたJMSサーバーとSAFエージェント用のデフォルト・ストアのかわりに、クラスタをターゲットにしたストアを使用します。
高可用性を有効化した場合(つまり、ストア上の移行ポリシーが「失敗時」または「常時」のいずれかに設定されている場合)、クラスタ・リースが構成されていることを確認してください。コンセンサス・リースよりデータベース・リースがベスト・プラクティスになります。詳細は、『Oracle WebLogic Serverクラスタの管理』のリースに関する項を参照してください。
モジュールでの宛先の構成時に、デフォルトのターゲット指定を使用せずに特定のクラスタ化されたJMSサーバーまたはSAFエージェントをターゲットにするサブデプロイメントを使用します。これにより、宛先では、目的としている正確なJMSサーバー・インスタンス上にメンバーが作成されます。
QOSレベルがExactly-Once
のSAFエージェントやSAFクライアントを使用する場合、ベスト・プラクティスとして、SAFエージェントに関連付けられたストアが「常時」に設定された移行ポリシーで構成されていることを確認してください。
また、クラスタ・サイズが変更された場合(特に縮小された場合)、バッキング表(JDBCストアの場合)またはファイル(FILEストアの場合)をいずれかの利用できるクラスタ・メンバーに移行して、SAFサービスの連続的な可用性を確保できるように、それらが削除または破棄されていないことを確認してください。
クラスタ内に分散されJMSアーティファクト(永続ストア、JMSサーバー、SAFAgent、MessagingBridgeおよびPathServiceなど)のそれぞれに関連付けられている実行時MBeanは、分散ポリシーのセットに基づいて名前が付けられます。これはMBeanチェックによって強制されます。
分散完了 — インスタンスは、そのインスタンスのホームまたは優先されるWebLogic Serverの初回起動時に名前を指定することで、自動的に作成され一意の名前が付けられます。形式は<configured-name>@<server-name>
になります。
01
」を加えた名前が付けられます。形式は<configured-name>–01
になります。このインスタンス名にサーバー名は追加されません。次の項では、永続ストアのインスタンス名前付け構文について概説します。
クラスタをターゲットにしたファイル・ストア(.DATファイル)の場合、インスタンスのデータ・ファイルには、対応するストアのインスタンス名に基づいて一意の名前が付けられます。たとえば、分散完了モードでは、インスタンスのファイルには<Store name>@<Server instance name>
NNNNNN.DAT
という名前が付きます。<NNNNNN
>は000000~999999の範囲の数字になります。
注意:
1つのファイルのインスタンスが1つ以上の.DATファイルを作成する場合があります。クラスタをターゲットにした、レプリケートされたストアのインスタンスのリージョンは、対応するストアのインスタンス名に基づいて、一意の名前が付けられます。たとえば、分散完了モードでは、レプリケートされたストアのインスタンスには、構文<configured Replicated Store name>@<Server instance name>
NNNNNN.RGN
が含まれます。<NNNNNN
>は000000–999999
の範囲の数字になります。
表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 |
表5-3 非クラスタ(シングル・サーバー)をターゲットにした場合
デフォルト名 | 接頭辞名 | 分散ポリシー | インスタンス名 | ストアの表名 |
---|---|---|---|---|
該当なし |
該当なし | 該当なし | 該当なし | myPrefixWLStore |
該当なし |
該当なし | 該当なし | 該当なし | WLStore |