https://blogs.oracle.com/WebLogicServer/entry/12_2_1_weblogic_jms
Introduction
WebLogic Server 12.2.1はすばらしくシンプルな、簡単に利用できるJMS構成および管理モデルを特徴としています。このシンプルなモデルは、JMS構成が簡単で可搬性があるため、シームレスにクラスタとMulti-Tenant/クラウド環境の両方で動作します。12.1.2で追加されたJMSクラスタターゲット機能の初期バージョンにあった主な制限を、古い管理モデルでは利用できない機能拡張を付け加えることで基本的にクリアしています。- 全てのタイプのJMSサービスアーティファクトが動的クラスタ環境をフル活用でき、自動的にスケールアップするだけでなく、クラスタのサイズ変更に合わせて負荷をクラスタ間で均等に分散します。言い換えると、クラスタの成長または変化に応答して、JMSアーティファクトを各クラスタメンバに個別に構成、デプロイする必要はありません。
- 高可用性構成（フェールオーバ、フェールバック、インプレース再起動）を簡単に構成でき、個別のターゲットを使うことで、以前は一部しかサポートしていなかった機能が使えるようになっています。
- 12.2.1では、シンプルな構成モデルで、クラスタのシングルトン宛先を構成できるようになっています。
Configuration Changes
このモデルを使うと、動的にスケールし、高可用性を持つJMSを一カ所（永続データを扱うすべてのJMSアーティファクトのためのカスタムストアもしくはメッセージング・ブリッジ）で簡単に構成、管理することができます。このモデルで導入されたこの新しい構成パラメータは総称して「高可用性」ポリシーとして知られています。これらは、管理コンソール（WebLogic管理コンソール、Fusion Middleware Control (FMWC)）だけでなく、WLSTスクリプトやJava Mbean APIを通じてユーザーに公開されています。ストア上にJMSを設定している場合、このストアを参照するJMSサービスのアーティファクトは、シンプルにこうした設定をストアから継承し、それに従った動作します。 |
| Figure 1. Configuration Inheritance |
distribution-policyを構成済みのアーティファクトに”distributed”と設定した場合、デプロイ時に、システムが自動的にインスタンスを各クラスタメンバ上で作成します。"singleton"に設定すると、システムは、クラスタ全体で単一のインスタンスを作成します。
ホストのWebLogic Serverにちなんで分散インスタンスは一意に命名されています（構成した名称にはサーバ名が後ろにつく）。ここでホストのWebLogic Serverは、実行時の監視と位置の追跡のために最初に作成され、開始しています。このサーバは、それにちなんで命名されている分散インスタンスのホームまたは優先サーバーと呼ばれています。シングルトン・インスタンスは、サーバ名で装飾されず、そのかわりに単に「-01」が後ろについています。システムはインスタンスをホストするクラスタ内で管理対象サーバの1個を選択します。
distribution-policyは、migration-policyと呼ばれる新しい高可用性オプションと協調し、予期せぬサービス障害やサーバクラッシュ、あるいはサーバの計画停止に対してさえもインスタンスが停止しないことを保証します。このポリシーは使用可能なクラスタメンバーにインスタンスを自動的に移行することでこれを実現します。
migration-policy用に、3個の選択肢から1個選ぶことができます。
- on-failure：インスタンスの移行は予期しないサービス障害やサーバクラッシュ時のみ
- always：インスタンスの移行は計画的な管理されたサーバ停止をも含めて実施
- off ：サービスレベルの移行を無効化（必要であれば）
 |
| Figure 2. Console screenshot: HA Configuration |
この機能のおかげで、レイテンシや過負荷が原因でデータベースが停止したりネットワークやI/Oリクエストに対する応答がないといった一時的な不調時に、システムが不必要な移行をしなくてすみます。障害発生後（定期的に再接続しようとします）、すでに自動的に再起動しているため、ブリッジはrestart-in-place設定を無視します。
高可用性の強化は、障害発生時のサービス・アーティファクトのフェールオーバだけでなく、ホームサーバがクラッシュやシャットダウン後に再起動された際の分散インスタンスの自動的なフェールバックも提供する、ということにご注意ください。これらは以前のリリースではご利用いただけませんでした。この機能のおかげで、アプリケーションが可能ならいつでも高いレベルのサーバや設定の親和性を実現することができます。以前のリリースとは異なり、起動中、フェールオーバ中のいずれであっても、インスタンスがクラスタメンバ間で均等に分散されていることをシステムが保証しようとします。そのため、クラスタのあるサーバが突発的に過負荷になることを避けています。
下表は新しい分散、移行、restart-in-place設定をまとめたものです。
| 属性名 | 説明 | オプション | デフォルト |
|---|---|---|---|
| distribution-policy | JMSサービスインスタンスの個数と名前を管理する | [Distributed | Singleton] | Distributed |
| migration-policy | 高可用性構成時に挙動を制御する | [Off | On-Failure | Always] | Off |
| restart-in-place | 正常なWebLogic Serverでの停止したストアインスタンスの自動再起動を有効にする | [true | false ] | true |
| seconds-between-restarts | 停止したサービスのrestart-in-placeの試行の時間間隔（秒） | [1 … {Max Integer}] | 30 |
| number-of-restart-attempts | 停止したサービスの移行前に再起動を試行する回数 | [-1,0 … {Max Long}] | 6 |
| initial-boot-delay-seconds | サーバでアーティファクトのインスタンスを起動するまでに待機する時間（秒） | [-1,0 … {Max Long}] | 60 |
| failback-delay-seconds | 優先サーバへアーティファクトがフェールバックするまでに待機する時間（秒） | [-1,0 … {Max Long}] | 30 |
| partial-cluster-stability-seconds | クラスタが「定常状態」であると認識するまでの待機時間。その時間に達するまでは、いくつかのリソースだけクラスタ内で開始することができる。この設定により、クラスタにはゆっくり立ち上がったり、停止したりする時間が与えられる。 | [-1,0 … {Max Long}] | 240 |
Runtime Monitoring
前述の通り、クラスタを対象にした場合、システムは自動的に1個（シングルトン）もしくは複数（分散）のインスタンスを1個の構成済みアーティファクトから生成します。これらのインスタンスは、一意に命名された、適切なランタイムMBeanが背後にあります。適切に有効範囲を設定されたサーバ（マルチテナント環境の場合はパーティション）のランタイムMBeanツリーの下で、アクセスしたり監視したりすることができます。 |
| Figure 3. Console screenshot: Runtime Monitoring |
Validation and Legal Checks
ユーザーがこれらの新しいパラメータの無効な組み合わせを設定できないようにするための法的チェックと検証ルールがあります。次の2つの表は、これら2個の新しいポリシーがそれぞれリソースタイプとサービスの種類によってサポートする組み合わせを示したものです。| サービス・アーティファクト | 分散ポリシー | 移行ポリシー | ||
|---|---|---|---|---|
| Off | Always | On-Failure | ||
| 永続ストア | Distributed | ✓ | ✓ | ✓ |
| Singleton | ✓ | ✓ | ||
| JMSサーバ | Distributed | ✓ | ✓ | ✓ |
| Singleton | ✓ | ✓ | ||
| SAF エージェント | Distributed | ✓ | ✓ | ✓ |
| パス・サービス | Singleton | ✓ | ||
| メッセージング・ブリッジ | Distributed | ✓ | ✓ | |
| Singleton | ✓ | |||
上記の表では、適法な組み合わせは、JMSサービスの種類に基づいて記載されています。たとえば、パス・サービス（順序単位や作業単位と呼ばれる、人気のあるWebLogic Serverの順序付け拡張を活用する、メッセージのルーティング情報を永続化、保持するメッセージングサービス）は、サービスやサーバの障害があってもクラスタ内で高可用性を保つ必要があるシングルトンサービスです。そのため、唯一の有効かつ適法な組み合わせは以下の通りです。
- distribution-policy：singleton
- migration-policy：always
アプリケーションで使用されているリソースのタイプに基づいて導出されるルールがあります。たとえば、同一の分散送り先をホストするJMSサーバや常にインポート済み送り先をホストするSAFエージェントのルールの場合、distribution-policyにsingletonを指定しても意味がありませんし、許可されていません。
| リソース・タイプ | Singleton | Distributed |
|---|---|---|
| JMSサーバ（分散送り先をホスト） | ✓ | |
| SAFエージェント（インポート済み送り先をホスト） | ✓ | |
| JMSサーバ（ シングルトン宛先をホスト） | ✓ | |
| パス・サービス | ✓ | |
| ブリッジ | ✓ | ✓ |
Best Practices
改善された機能を十分に活用するには、最初に慎重にスケーラビリティと可用性の要件だけでなく、デプロイメント環境を確認して、あなたのJMSアプリケーションを設計してください。たとえば、アプリケーションをクラスタにデプロイするのか、マルチテナント環境にデプロイするのか、均一な分散送り先またはスタンドアロン（非分散）の宛先なのか、またはその両方を使用するかどうかを確認します。上記の要件を確認してから、カスタム永続ストアを定義し、適切なJMSサービスの成果物と関連付けてください。この新しいHAパラメータが要件に応じて明示的に設定されていて（ガイダンスとして上記の表を使用してください）、JMSサービスのアーティファクトと、それに対応するストアの両方が同様に（同じクラスタ、マルチテナント環境の場合は同じリソースグループ、リソースグループ・テンプレートを）ターゲットにしていることを確認してください。
JMSの高可用性機構がWebLogic Serverのヘルス・モニタおよびシングルトン・サービスに依存していること、そしてクラスタ・リースと呼ばれる機構に依存していることを覚えておいてください。そのため、migration-policyがon-failureもしくはalwaysに設定されている場合、もしくはJMSアーティファクトのシングルトンインスタンスを作成したい場合は特に、有効なクラスタリーシング構成を設定する必要があります。WebLogic Serverは2個のリース方法（コンセンサス・リースとデータベース・リース）を用意していますが、ベストプラクティスとしてデータベース・リースを利用することを強く推奨します。
また、JMSアプリケーションは、多くの場合、直接トランザクションを使いますし、JMSの内部は暗黙的にトランザクションを使っているので、WebLogicのトランザクションシステムの可用性高めるように構成することを強く推奨します。WebLogicトランザクションの高可用性を担保するためには、デフォルト設定のままではなく、すべての管理対象サーバに明示的にリスニングアドレスとリスニングポート番号が構成されている必要があります。そうでなければ完全なトランザクションのHAサポートを得ることはできません。動的クラスタ構成の場合には、動的サーバテンプレート定義の一部として、これらの設定を構成することができます。
最後に、NodeManagerを使ってクラスタメンバのすべての管理対象サーバを起動することを推奨します。
WebLogic JMSに関する詳細情報は以下のドキュメントをご覧ください。
Oracle® Fusion Middleware Administering JMS Resources for Oracle WebLogic Server 12c (12.2.1)その他のOracle WebLogic Server 12.2.1の新しい改善点は、以下のリンクのWhat's Newの章をご覧ください。
http://docs.oracle.com/middleware/1221/wls/JMSAD/title.htm
Oracle® Fusion Middleware What's New in Oracle WebLogic Server 12.2.1 12c (12.2.1)
What's New in Oracle WebLogic Server 12.2.1
http://docs.oracle.com/middleware/1221/wls/NOTES/whatsnew.htm#NOTES107
0 件のコメント:
コメントを投稿