[WLS, Java, FMW] 12.2.1 WebLogic JMS: Dynamic Scalability and High Availability Made Simple

原文はこちら。
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では、シンプルな構成モデルで、クラスタのシングルトン宛先を構成できるようになっています。

これらの機能はすべてのWebLogic Serverクラスタのタイプ、つまり、個々にWebLogic Serverを構成したものを組み合わせた旧来の静的なクラスタ、複数のインスタンスに伸長できる動的な1個のWebLogic Serverを組み合わせた動的クラスタ、そしてその両方を組み合わせたクラスタといったすべてのタイプに当てはまります。

Configuration Changes

このモデルを使うと、動的にスケールし、高可用性を持つJMSを一カ所（永続データを扱うすべてのJMSアーティファクトのためのカスタムストアもしくはメッセージング・ブリッジ）で簡単に構成、管理することができます。このモデルで導入されたこの新しい構成パラメータは総称して「高可用性」ポリシーとして知られています。これらは、管理コンソール（WebLogic管理コンソール、Fusion Middleware Control (FMWC)）だけでなく、WLSTスクリプトやJava Mbean APIを通じてユーザーに公開されています。ストア上にJMSを設定している場合、このストアを参照するJMSサービスのアーティファクトは、シンプルにこうした設定をストアから継承し、それに従った動作します。

Figure 1. Configuration Inheritance

最も重要な設定パラメータはdistribution-policy（分散ポリシー）とmigration-policy（移行ポリシー）です。これらはそれぞれ、関連するサービス・アーティファクトの動的な拡張性と可用性を制御します。
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

migration-policyに加え、この新しいモデルでは、restart-in-place（インプレース再起動）と呼ばれる、ストアのための別の高可用性の概念を提供しています。これを有効にすると、システムはまず、クラスタ内の別のサーバーにフェールオーバーする前に、現在のサーバー上で失敗したストアインスタンスを再起動しようとします。このオプションを調整し、試行回数と各試行間の時間間隔を制限することができます。
この機能のおかげで、レイテンシや過負荷が原因でデータベースが停止したりネットワークや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

上図はクラスタに向けられたSAFエージェントのランタイムインスタンスがクラスタメンバーのサーバ名で一意になるよう装飾されているところを示すスクリーンショットです。

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

リソース・タイプ	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)
http://docs.oracle.com/middleware/1221/wls/JMSAD/title.htm

その他のOracle WebLogic Server 12.2.1の新しい改善点は、以下のリンクのWhat's Newの章をご覧ください。

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

Conclusion

WebLogic JMSのこうした新しい拡張機能を使用して、一般的にはWebLogic JMSの構成、管理に関わる時間やコストを大幅に削減しつつ、拡張性や高可用性を向上し、結果として投資利益を向上しながら使いやすくなるというメリットを享受することができます。