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