| Oracle® Fusion Middleware Oracle WebLogic Server JMSリソースの管理 12c (12.2.1.3.0) E90330-04 |
|
 前 |
 次 |
クラスタ指定の新しい拡張と、それによるJMS構成の簡略化について学習します。これらの拡張により、クラスタまたはWebLogic Serverマルチテナント環境で、広範囲な構成プロセスの必要なく、JMSサービスを、動的にスケーラブルで、可用性が高くなるようにできます。
この章の内容は次のとおりです。
WebLogicクラスタには、個別に構成されたサーバー、動的に生成されたサーバー、またはその両方を含めることができます。
WebLogic Serverには、次のクラスタ・タイプがあります。
構成済: 各メンバー・サーバーが個別に構成され、それぞれがそのクラスタにターゲット指定されています。クラスタ構成の「動的クラスタ・サイズ」属性の値は、0です。 WebLogic Server管理コンソール・オンライン・ヘルプのクラスタ: 構成: サーバーに関する項を参照してください。このタイプのクラスタは、静的クラスタとも言います。
動的: すべてのメンバー・サーバーがサーバー・テンプレートを使用して作成されるクラスタです。これらのサーバーは動的サーバーと呼ばれます。クラスタ構成の「クラスタ: 構成: サーバー」タブの「動的クラスタ・サイズ」属性の値は、0より大きくなります。
混在: 一部のメンバー・サーバーはサーバー・テンプレートを使用して作成され(動的サーバー)、残りのサーバーは手動で構成されます(構成済サーバー)。混在クラスタには動的サーバーが含まれるため、クラスタ構成の「クラスタ: 構成: サーバー」タブの「動的クラスタ・サイズ」属性の値は、0より大きくなります。
動的サーバーの使用方法の詳細は、次を参照してください。
Oracle WebLogic Serverクラスタの管理の動的クラスタを参照してください。
Oracle WebLogic Server管理コンソール・オンライン・ヘルプの動的クラスタの作成および動的なクラスタ化JMSの構成を参照してください
クラスタのターゲットとして指定されたJMSサービス構成は、JMSサーバー、SAFエージェントまたはパス・サービスおよびその関連する永続ストアなどのJMSサービス・アーティファクトを同じクラスタに直接ターゲット指定します。メッセージング・ブリッジも、クラスタをターゲットとして指定できるJMSアーティファクトです。クラスタ内の各WebLogicサーバーのJMSアーティファクトを個々に構成およびターゲット指定するよりも、クラスタ・ターゲティングJMSアーティファクトの方が簡単で、多くのHA機能を提供します。
クラスタのターゲットとして指定されたJMSサービス・アーティファクトは、構成されている分散ポリシーに応じてクラスタまたはシングルトンに配布できます。配布されると、クラスタはアーティファクト(および該当する場合は関連付けられたストア)の新規インスタンスを各新規クラスタ・メンバーで自動的に起動し、そのメンバーはそのインスタンスの優先サーバーになります。分散されないアーティファクトの場合(シングルトン分散ポリシーを持つなど)、システムはクラスタ内の単一サーバーを選択し、そのアーティファクトの単一インスタンスを起動します。「簡略化された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リソース(サブデプロイメントに関連付けられていないJMSリソース)は、その親モジュールのターゲット指定を継承します。親モジュールは任意のタイプのクラスタをターゲットにできます。宛先に対して、デフォルト・ターゲッティングではなくサブデプロイメント・ターゲッティングを使用することをお薦めします。
モジュールのサブデプロイメントのターゲットは、クラスタ化されたJMSサーバーを参照できます。サブデプロイメントでクラスタのターゲットとして指定されたJMSサーバーを使用すると、サブデプロイメント内の個々のJMSサーバーを個別に列挙する必要がなくなるため、共通分散宛先デプロイメントでは特に便利です。
「ターゲット指定のベスト・プラクティス」を参照してください
注意:
モジュールまたはそのサブデプロイメントを直接動的クラスタ・メンバーにターゲット指定することはできません。
WebLogic Serverは、クラスタにデプロイされたJMSサービス・アーティファクトで、高可用性をサポートします。サーバーおよびサービスの障害のシナリオは、アーティファクトのインスタンスを他の実行中サーバーに自動的に移行することによって処理されます。この過程で、システムは全体のサーバー負荷および可用性を評価し、それに応じてインスタンスを移動します。
WebLogic Serverのこのリリースでクラスタをターゲットに指定する拡張により、以前のリリースに存在した制限の多くが不要になりました。
12.2.1.0より前のリリースでは、JMSサーバー、永続ストア、およびSAFエージェント(一部)のみがクラスタをターゲットに指定できました。12.2.1.0以降では、SAFエージェント、パス・サービス、メッセージング・ブリッジなど、すべてのJMSサービス・アーティファクト、およびあらゆるタイプのクラスタ(構成済、混在、動的)までサポートが拡張されています。
12.2.1.0以降での拡張により、クラスタをターゲットとしたすべてのJMSサービス・アーティファクトで分散の動作やJMS高可用性(JMS自動サービス移行とも呼ばれます)の動作を容易に構成、制御できます。これらの構成はすべて単一の場所、つまり永続ストアに依存するすべてのアーティファクトの場合は永続ストア、ストアを使用しないものについてはメッセージング・ブリッジに集められました。これにより、以前のリリースで使用された移行可能ターゲットが不要になります。
論理JMSアーティファクトはクラスタをターゲットにしているため、システムはクラスタの結合時に、必要な「物理」インスタンスをクラスタ・メンバー上に自動的に作成します。これにより、クラスタ・サイズが増大するときに、JMSサービスが自動的にスケール・アップすることが可能になります。オプションの高可用性構成を使用すると、「物理」インスタンスは、サービス障害またはサーバーの障害や停止が生じた場合に再起動または移行できるため、最小構成でのJMSサービスの可用性が向上します。
クラスタのターゲットとして指定されたJMSサービスのスケーラビリティおよび高可用性の動作を制御するプライマリ属性は、分散ポリシーと移行ポリシーです。これらのポリシーに加えて、別の場所に移行する前のインスタンスのインプレース再起動(同一サーバー上)など、高可用性動作を微調整するために使用できる追加の属性がいくつかあります。次の各項では、これらのポリシーと属性について説明します。
カスタム永続ストアまたはメッセージング・ブリッジのための分散ポリシー設定は、関連付けられたJMSサービス・アーティファクト(JMSサーバー、SAFエージェントおよびパス・サービス)がクラスタに分散される方法を決定し、メッセージング・ブリッジ上の同じ設定がその分散動作を決定します。
注意:
ストアの分散ポリシー属性のデフォルト値は、「分散完了」です。「分散完了」は、SAFエージェントでは必須の値であり、共通分散宛先をホストする、クラスタをターゲットとして指定されたJMSサーバーでも必須です。シングルトン: このモードでは、JMSサーバーまたはパス・サービスはクラスタごとに1つのインスタンスを持っています。
注意:
このオプションは、パス・サービスで必須であり、シングルトン宛先またはスタンドアロン(非分散)宛先をホストする、クラスタをターゲットとしたJMSサーバーでも必須です。分散ポリシーの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストア: HA構成に関する項を参照してください
ストアの「移行ポリシー」設定は、クラスタをターゲットとして指定されたJMSサービス・アーティファクト・インスタンスの移行および再起動動作を制御します。高可用性およびサービス移行については、関連付けられたストア上で、移行ポリシーを次のとおりに設定します。
オフ: このオプションは移行を無効にします。デフォルトでは、「移行ポリシー」が「オフ」の場合は「再起動準備完了」も無効になります。
常時: このオプションを使用すると、システムはすべての状況でインスタンスを自動的に移行できます。これには、ホスティング・サーバーまたはサブシステム・サービスの、管理上の停止、クラッシュまたは状態不良を含みます。このオプションは、サービスの再起動準備完了も有効化します。これは、現在のホスト・サーバーJVM上の障害が発生したストアを同じクラスタ内の別のサーバーJVMに移行する前に、そのストアの再起動が自動的に試行されます。
注意:
WebLogicサーバーは、ターゲット指定タイプ、デプロイメント・スコープおよび移行ポリシー設定に関係なく、JMSサービスの再起動準備完了を完全にサポートしています。『WebLogic永続ストアの管理』のサービスの再起動準備完了に関する項を参照してください。
JMSサービス移行とJTA移行は、それぞれの移行ポリシー設定に基づいて独立して動作し、個別に構成されます。動的クラスタとJTA移行ポリシーの詳細は、サービスの移行フレームワークの理解を参照してください。
クラスタをターゲットとして指定されている、移行ポリシーが「常時」または「失敗時」であるJMSサービス・アーティファクトのサポートを有効化するには、クラスタ・リーシングを構成する必要があります。Oracle WebLogic Serverクラスタの管理のリースを参照してください。
クラスタ・リーシングの構成時には、コンセンサス・リーシングでなく、データベース・リーシングのオプションを使用するのがベスト・プラクティスです。
分散インスタンスが優先サーバーから移行される場合、優先サーバーが再起動されるときにフェイル・バックを試みます。
ストアの「移行ポリシー」属性の詳細は、『Oracle WebLogic Server Administration Consoleオンラインヘルプ』のJDBCストア: HA構成に関する項を参照してください。
「失敗時」または「常時」に設定されている場合、または「移行ポリシー」が「オフ」で「再起動準備完了」が明示的に「True」に構成されている場合に適用されます。次の表に、JMSサービス移行の様々な構成プロパティを示します。表5-1 JMSサービス移行のための構成プロパティ
| プロパティ | デフォルト値 | 説明 |
|---|---|---|
再起動準備完了 |
「移行ポリシー」が「オフ」の場合はFalse、それ以外の場合はTrue |
正常なWebLogic Server内で、システムがJMSサービス障害にどのように応答するかを定義します。サービスが失敗した場合に、このプロパティが有効にされると、まずシステムはそのストアと、同じサーバー上の関連するサービス・アーティファクトの再起動を試行し、その後で別のサーバーに移行します。 注意: この属性は、サーバー全体に障害が発生したときには適用されません。 『WebLogic永続ストアの管理』のサービスの再起動準備完了に関する項を参照してください。 |
再起動間隔 |
30 |
「再起動準備完了」が有効の場合、このプロパティは同じサーバー上での再起動と再起動の間の遅延を秒単位で指定します。 |
再起動回数 |
6 |
Restart In Placeが有効の場合、この数は別のサーバーへのアーティファクト・インスタンス移行を試行する前に、システムが行う再起動試行回数を決定します。 |
初期起動遅延(秒) |
60 |
最初のインスタンスが起動された後、後続の高速インスタンスがサーバー上でどのように起動されるかを制御します。これにより、システムが起動中に過負荷になるのを防止できます。 値0は、システムが待機する必要はないことを示しますが、これは過負荷状況に導く場合があります。システムのデフォルト値は60秒です。 |
フェイルバック遅延(秒) |
-1 |
アーティファクトのインスタンスを優先サーバーにフェイルバックする前に待機する時間を指定します。 0より大きい値は、JMSアーティファクトを優先サーバーにフェイルバックする前に、遅延させる時間を秒数で指定します。 値に0を指定した場合、インスタンスはフェイルバックしません。 値に-1を指定した場合、遅延は発生せず、インスタンスはただちにフェイルバックします。 |
部分クラスタ安定遅延 |
240 |
部分的に起動されたクラスタが、「常時」または「失敗時」の移行ポリシーで構成された、クラスタをターゲットとして指定されたすべてのJMSアーティファクト・インスタンスを開始する前に、遅延させる時間を秒数で指定します。 この遅延によって、サーバーが順次起動される場合でも、サービスがクラスタ全体で分散されます。 > 0の値は、部分的に開始されたクラスタが動的に構成されたサービスを開始する前に、遅延させる時間を秒数で指定します。 値0は、利用できるサーバー上でのすべてのインスタンスを遅延なしで起動することを指定します。 遅延のデフォルト値は240秒です。 |
これらのプロパティの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのJDBCストア: HA構成に関する項を参照してください。
動的クラスタとクラスタをターゲットとして指定されたJMSサーバーを使用してアプリケーションを開発する前に、クラスタ化されたJMSによる制限事項について考慮する必要があります。
次に、考慮すべき制限事項とその他の動作を示します。
QOSレベルがExactly-OnceのSAFエージェント・インポート済宛先が、混在または動的クラスタでホストされる分散宛先にメッセージを転送する場合は、特別な考慮が必要です。「クラスタ化されたJMSサービスを使用する場合のベスト・プラクティス」を参照してください
WLSTオフラインでは、JMSサーバーを動的クラスタにターゲット指定するassignコマンドはサポートされません。getおよびsetコマンドを使用してください。
クラスタをターゲットとして指定されたJMSサーバーでは、重み設定された分散宛先(シングルトン宛先のグループで構成された非推奨の分散宛先タイプ)はサポートされません。
クラスタをターゲットにしたJMSサーバーでホストされているメンバー宛先が1つでもある場合は、複製された分散トピック(RDT)はサポートされません。かわりに、パーティション化された分散トピック(PDT)またはシングルトン・トピックを構成してください。RDTがすでに構成されている構成を変換している場合は『Oracle WebLogic Server JMSアプリケーションの開発』のPDTによるRDTの置換に関する項を参照してください。
「シングルトン」分散ポリシーが設定されたカスタム永続ストア、および「常時」(または「失敗時」)が設定された移行ポリシーが、クラスタをターゲットとして指定されたJMSサーバーでスタンドアロン宛先を使用できるようにするために必要です。
クラスタをターゲットとして指定されたJMSアーティファクトから生成されたサービス・インスタンスの移行またはフェイルバックを手動で(管理側から)強制することはサポートされていません。
順序単位(UOO)メッセージのホストに使用される、なんらかの分散またはインポート済宛先がある場合は、パス・サービスを構成する必要があります。さらに、ハッシュ・ベースのUOOルーティングは、クラスタをターゲットにしたJMSではサポートされないため、そのような宛先は、デフォルトのハッシュされたUOOルーティング・ポリシーでなく、パス・サービスUOOルーティング・ポリシーを使用して構成する必要があります。パス・サービス・ルーティング・ポリシーが構成されていない、クラスタをターゲットとしたJMSサービス上でホストされている分散宛先またはインポートされた宛先にUOOメッセージを送信しようとすると、失敗して例外が発生します。
シングルトン分散ポリシーと常時移行ポリシーを持つストアを参照するには、クラスタをターゲットにしたパス・サービスを構成する必要があります。
次の項では、クラスタをターゲットにした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インスタンスを停止します。例:
本番稼働のリタイアする宛先インスタンスを休止します。
コンシューマ・アプリケーションで、休止された宛先の残りのメッセージを処理します。
サーバー・インスタンスを停止します。
リタイアされたインスタンスに関連付けられている永続ストアのファイルまたはデータベース表をすべて削除します。
あるいは、これよりはるかに単純な解決方法は、リタイア済サーバー上の宛先を残りのサーバーに自動的に移行するようにシステムを設定することです。
移行ポリシーが「失敗時」または「常時」になるように、ストアを構成します。
動的クラスタの構成済の動的クラスタ・サイズを削減したり、構成済/混在クラスタから構成済サーバーを削除しないでください。かわりに、単にリタイア済のサーバーを起動しないでください。「失敗時」または「常時」のストアは、実行中のサーバーに移行します。WLSTのscaleDownコマンドは、updateConfigurationオプションが無効な場合のみ使用してください。そうでない場合、クラスタの動的クラスタ・サイズ設定が縮小されます。
クラスタをターゲットにした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 | 分散ポリシー | インスタンス名 | ストアの表名 |
|---|---|---|---|
| myPrefix | 分散 | myStore@myServer | myPrefix_myServer_WLStore |
| myPrefix('.'で終わる) | 分散 | myStore@myServer | myPrefix._myServer_WLStore |
| 未設定 | 分散 | myStore@myServer | myServer_WLStore |
| myPrefix | シングルトン | myStore-01 | myPrefix_01_WLStore |
| myPrefix | シングルトン | myStore-01 | myPrefix.S_01_WLStore |
| 未設定 | シングルトン | myStore-01 | S_01_WLStore |
表5-3 クラスタをターゲットにしない場合(単一サーバー)
| 接頭辞名 | 分散ポリシー | インスタンス名 | ストアの表名 |
|---|---|---|---|
| myPrefix | 該当なし | myStore | myPrefixWLStore |
| 該当なし | 該当なし | myStore | WLStore |
