原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/zdt_rollouts_and_singletons
WebLogic Serverは、エンタープライズグレードのアプリケーションを容易に構築するため、メッセージング、トランザクション、その他のシステムサービスを提供しています。通常、サービスは、クラスタ化またはシングルトンのいずれかです。クラスタ化されたサービスは、クラスタ内の各サーバーにデプロイされ、拡張されたスケーラビリティと信頼性を提供します。あるクラスタのメンバー・サーバのセッション状態は、クラスタ内の別のサーバーに複製されます。対照的に、シングルトンサービスは、任意の時点でクラスタ内の1台のサーバだけで実行され、特定のサービス品質（QoS）を提供しますが、最も重要なのは、データの一貫性を維持するためです。シングルトンサービスは、JMS関連のサービスや、JTA関連のサービスの場合があります（もちろん、ユーザー定義サービスの場合もあります）。高可用性構成（HA）環境では、すべてのサービスが起動し、パッチのアップグレード中にあっても実行されていることが重要です。
WebLogic Serverのこの新しいZero Downtime Patching （ZDT patchingとしても知られています）機能は、完全に自動化されたローリングアップグレードソリューションで。デプロイされたアプリケーションをアップグレードしながらも当該アプリケーションが機能し続け、エンドユーザーにとってはアップグレードプロセスの間も利用できるようにします。
ZDTロールアウトがシングルトンを取り扱う方法にはいくつかハイライトがあります。
JTAに関しては、サーバが正常にシャットダウンされた場合、アプリケーションは、その特定のサーバーの任意の新しいトランザクションリクエストを生成しません。 EJB/ RMIパスでは、クラスタに対応するスタブがサーバー接続障害を検出し、セカンダリサーバにリクエストをリダイレクトします。アプリケーションはトランザクション中の例外を処理するように設計されている前提です。
サーバ移行（WSM）を環境で構成している場合、サーバインスタンス全体を新しいハードウェア上で起動する必要があるため、通常はサービスが利用可能になるまで（サービス移行と比較して）より長い時間を必要とすることに注意する必要があります。
注意：一般に、サーバ全体の移行は、その相対的にシンプルであるが故に基本的な用途では好ましいのですが、フェイルオーバーに要する時間がより短く、かつサービス移行での高度な制御を所望されている場合、自動サービス移行は魅力的でしょう。
WebLogic JMSでは、メッセージは、宛先のホストJMSサーバが実行されている場合にのみ使用可能です。メッセージが中央の永続ストアにある場合、メッセージにアクセスできる唯一のJMSサーバは、元々メッセージが保存されているサーバです。HA（高可用性構成）は通常、次のいずれかまたは全てのいずれかを使用して実現しています。
サービス移行は、クラスタ内の1個の物理サーバ上でのみホストされているサービスのグループとして機能する、論理的に移行可能なターゲットが制御します。特定の固定サービスをターゲットとする場合は、サーバーまたはクラスタの代わりに移行可能な対象を選択することができます。移行フレームワークは、ターゲットの設定および移行のためのツールとインフラストラクチャを提供します。自動サービス移行の場合には、移行可能なターゲットがホストするサービスの状態を監視するためのWebLogic Serverの状態監視サブシステムを活用します。
次表は、さまざまな移行オプションをまとめたものです。
同様に、ユーザーがサービスを手動で移行するよう設定した場合、そのようなサービスはロールアウト時に、管理者に成り代わって自動的に移行されます。 ZDTロールアウトは、JMSおよびJTAサービスの移行の両方を扱うことができます。
警告
管理者は、ロールアウトコマンドにオプションとして移行プロパティ・ファイルを渡すことで、サーバ単位での正確な移行アクションを指定することができます。移行プロパティファイルで指定された移行オプションは、システムで構成されているものに対して検証されます。プロパティファイルに従ってダウンタイムを軽減するために必要とされる移行を呼び出します。最適化として、パッチ適用済みサーバと未適用のサーバ間での不要な移行を防ぐため、ワークフローがサーバ全体でロールアウトをする順番を生成します。
サーバをサーバ全体の移行（WSM）をするよう構成している場合、ZDTロールアウトはWSMもサポートします。
下表はすべての移行オプションのリストです。
これらの移行オプションはWLSTのmigrateコマンドオプションと非常に似ていることがわかると思います。
![]()
以下は移行プロパティファイルの例です。
サンプルのmigrationProperties.json ファイルは以下のようです。
https://blogs.oracle.com/WebLogicServer/entry/zdt_rollouts_and_singletons
WebLogic Serverは、エンタープライズグレードのアプリケーションを容易に構築するため、メッセージング、トランザクション、その他のシステムサービスを提供しています。通常、サービスは、クラスタ化またはシングルトンのいずれかです。クラスタ化されたサービスは、クラスタ内の各サーバーにデプロイされ、拡張されたスケーラビリティと信頼性を提供します。あるクラスタのメンバー・サーバのセッション状態は、クラスタ内の別のサーバーに複製されます。対照的に、シングルトンサービスは、任意の時点でクラスタ内の1台のサーバだけで実行され、特定のサービス品質（QoS）を提供しますが、最も重要なのは、データの一貫性を維持するためです。シングルトンサービスは、JMS関連のサービスや、JTA関連のサービスの場合があります（もちろん、ユーザー定義サービスの場合もあります）。高可用性構成（HA）環境では、すべてのサービスが起動し、パッチのアップグレード中にあっても実行されていることが重要です。
WebLogic Serverのこの新しいZero Downtime Patching （ZDT patchingとしても知られています）機能は、完全に自動化されたローリングアップグレードソリューションで。デプロイされたアプリケーションをアップグレードしながらも当該アプリケーションが機能し続け、エンドユーザーにとってはアップグレードプロセスの間も利用できるようにします。
Zero Downtime Patching Released!ZDT patchingはOracle_Home、Java_Homeのロールアウトやアプリケーションのアップデートもサポートします。ZDTに関する詳細は、以下のエントリをご覧になるか、ドキュメントをご覧ください。
https://blogs.oracle.com/WebLogicServer/entry/zero_downtime_patching_released
http://orablogs-jp.blogspot.jp/2015/11/zero-downtime-patching-released.html
ZDT Technical Topic: How are Those Sessions Kept Alive Anyway?
https://blogs.oracle.com/WebLogicServer/tags/zdt
http://orablogs-jp.blogspot.jp/2016/01/zdt-technical-topic-how-are-those.html
Oracle® Fusion Middleware Administering Zero Downtime Patching Workflows 12c (12.2.1)ZDTロールアウト時は、サーバーはローリング方式で再起動されます。サーバを落とすとシングルトンサービスも落とすことになるので、結果としてサービスの中断に至り、サーバが再起動されるまでサービスが利用できなくなるでしょう。実際のダウンタイムはサーバの立ち上げ時間とデプロイされているアプリケーションの種類によって変わります。このため、シングルトンサービスがクラスタにある依存アプリケーションに対する単一障害点とならないようにするため、ZDTロールアウトプロセスが自動的に移行を実行します。
Using OPatchAuto to Initiate, Revert, and Resume Rollouts
http://docs.oracle.com/middleware/1221/wls/WLZDT/configuring_patching.htm#WLZDT166
ZDTロールアウトがシングルトンを取り扱う方法にはいくつかハイライトがあります。
- すべての種類のロールアウトに適用できる（rolloutOracleHome、rolloutJavaHome、rollingRestart、rolloutUpdateなど）
- ロールアウト中にきめ細かくサービス移行を制御するためにJSONファイルベースの移行オプションを使うことができる（WLSTまたはコンソールで指定可能）
- サービス移行（JMSやJTA）だけでなく、サーバ移行（WSM）もサポート
- 必要に応じて自動フェイルバック
Terms, Acronyms and Abbreviations
| 用語 | 意味 |
|---|---|
| シングルトン（Singletons） | クラスタの1個のサーバでのみホストされるサービス |
| 移行可能なターゲット (MT) | まとめて移行すべきサービスをグループ化する方法を提供する特別なターゲット。これには当該タイミングでアクティブなただ1個のサーバと移行対象候補のサーバのリストが含まれる。 |
| ソース（移行元）サーバ | サービス移行元のサーバインスタンス |
| 移行先サーバ | サービス移行先のサーバインスタンス |
| 自動サービス移行 (ASM) | 影響を受けたサブシステムのサービスをあるサーバインスタンスから別の実行中のサーバインスタンスへ移動するプロセス |
| サーバ移行 (WSM) | ある物理マシンから別の物理マシンへサーバインスタンス全体を移動するプロセス |
| フェールバック（切り戻し） | フェールバックは、サービスを元のホストサーバもしくは「ホーム」サーバへ移転するという意味。 |
Assumptions
ZDTロールアウトの間、サーバを正規の手順でシャットダウンしてから立ち上げ直します。ZDTロールアウトを開始するにあたり、管理者は管理対象サーバの再起動による影響を十分に認識する必要があります。任意のアプリケーションはサービス移行が構成されている、いないに関わらず、再起動に対して寛容であったりなかったりする可能性があります。- 非永続状態を持っている可能性がある
- ランタイムクライアントの例外に対して寛容であったりなかったりする可能性がある
- 再起動に要する時間が影響を及ぼすことがある
JTAに関しては、サーバが正常にシャットダウンされた場合、アプリケーションは、その特定のサーバーの任意の新しいトランザクションリクエストを生成しません。 EJB/ RMIパスでは、クラスタに対応するスタブがサーバー接続障害を検出し、セカンダリサーバにリクエストをリダイレクトします。アプリケーションはトランザクション中の例外を処理するように設計されている前提です。
サーバ移行（WSM）を環境で構成している場合、サーバインスタンス全体を新しいハードウェア上で起動する必要があるため、通常はサービスが利用可能になるまで（サービス移行と比較して）より長い時間を必要とすることに注意する必要があります。
注意：一般に、サーバ全体の移行は、その相対的にシンプルであるが故に基本的な用途では好ましいのですが、フェイルオーバーに要する時間がより短く、かつサービス移行での高度な制御を所望されている場合、自動サービス移行は魅力的でしょう。
JMS
WebLogic JMSサブシステムは堅牢で高パフォーマンスであり、エンタープライズアプリケーションを構築するための他のAPIと接続して使われることが多々あります。アプリケーションがスムーズに機能するためにはアプリケーションの設計（フォールトトレランス、特定のパターンや機能の利用）が大いに関わっており、管理サーバでのJMSサブシステムの調整方法にも関わっています。WebLogic JMSでは、メッセージは、宛先のホストJMSサーバが実行されている場合にのみ使用可能です。メッセージが中央の永続ストアにある場合、メッセージにアクセスできる唯一のJMSサーバは、元々メッセージが保存されているサーバです。HA（高可用性構成）は通常、次のいずれかまたは全てのいずれかを使用して実現しています。
- 分散送り先：分散送り先のキューおよびトピックメンバーは、通常クラスター内の複数のサーバに分散されており、各メンバーは別々のJMSサーバに属しています。分散送り先を使うアプリケーションは、単純な送り先を使用するアプリケーションよりも可用性が増していますが、それはWebLogic JMSが、クラスタ内の分散送り先に含まれる宛先のためのロードバランシングとフェイルオーバーを提供するためです。
- ストアアンドフォワード：JMSモジュールは、SAFサービスを利用して、確実にリモート・キューまたはトピックにメッセージを送信するためにローカルJMSメッセージプロデューサを有効にします。メッセージ送信のタイミングで（ネットワークの問題やシステムの障害で）宛先が利用できない場合、メッセージはローカルサーバインスタンスに保存され、宛先が利用可能になったら、リモートの宛先に転送されます。
- HAサーバ/サービス：JMSサーバを自動的に再起動したり、サーバー全体の移行やサービスの自動移行のいずれかを使用して移行したりすることができます。
JTA
高可用性のために設計された本番環境はほとんどの場合JTAサービス（だけでなく他のサービスも）が単一障害点（Single Point of Failure）にならないようになっています。WebLogic虎ザクションマネージャは最小限の人手による介入でシステム障害から回復するように設計されています。トランザクションマネージャは、複数のクラッシュや回復中のクラッシュがあった後でも、リソースマネージャがコミットやロールバックでPrepareしたトランザクションブランチを解決するためにあらゆる努力をします。また、不完全なトランザクションに関するすべてのトランザクション・ログの記録を解析し、それらを完了することによって、システムの起動時にトランザクションを回復しようとします。しかし、ZDTロールアウトなどのメンテナンスの類いの操作の準備のために、JTAサービスを移行するように構成することができます。実行中のトランザクションが基礎となるリソースのロックを保持することができるので、JTAの移行を必要とします。トランザクションマネージャがこれらのトランザクションを回復するために使用できない場合は、保留中のトランザクションがコミット/ロールバックを使用して解決されず、新しいトランザクションにエラーが発生し、アプリケーションが正しく機能することが難しい場合に限り、リソースがこれらのロックを保持することができます。More on Service Migrations
WebLogic Serverにおけるサービスレベルの移行は、あるサーバインスタンスから固定サービスをクラスタ内で利用可能な別のサーバーインスタンスに移動するプロセスです。サービス移行は、クラスタ内の1個の物理サーバ上でのみホストされているサービスのグループとして機能する、論理的に移行可能なターゲットが制御します。特定の固定サービスをターゲットとする場合は、サーバーまたはクラスタの代わりに移行可能な対象を選択することができます。移行フレームワークは、ターゲットの設定および移行のためのツールとインフラストラクチャを提供します。自動サービス移行の場合には、移行可能なターゲットがホストするサービスの状態を監視するためのWebLogic Serverの状態監視サブシステムを活用します。
次表は、さまざまな移行オプションをまとめたものです。
| ポリシータイプ | 説明 |
|---|---|
| Manual Only (default) | このターゲットへの自動サービス移行は無効 |
| Failure Recovery | このターゲットにデプロイされた固定サービスは
|
| Exactly Once | このターゲットにデプロイされた固定サービスは
|
ZDT Migration Strategy and Options
移行サブシステムは“exactly-once”タイプのサービスを自動的に取り扱うため、ZDTロールアウトでは考慮する必要はありません。主として考慮しなければならないのは、failure-recoveryタイプのサービスです。これらのサービスはサーバが正常終了すれば移行されません。再起動の時間間隔はまちまちなので、これらのサービスを移行して、エンドユーザーに影響が及ばないようにする必要があります。同様に、ユーザーがサービスを手動で移行するよう設定した場合、そのようなサービスはロールアウト時に、管理者に成り代わって自動的に移行されます。 ZDTロールアウトは、JMSおよびJTAサービスの移行の両方を扱うことができます。
警告
- トランザクションマネージャは他の固定サービスのように移行ターゲットに割り当てられません。JTA ASM（自動サービス移行）はサーバ毎の設定です。これはJMSのようなサービスと対比すると、トランザクションマネージャが直接別の固定リソースに依存しないためです。
- ユーザー定義のシングルトンサービスの場合、自動的に”exactly-once”に構成されるため、ZDTロールアウトは特定のアクションを実行する必要はありません。
管理者は、ロールアウトコマンドにオプションとして移行プロパティ・ファイルを渡すことで、サーバ単位での正確な移行アクションを指定することができます。移行プロパティファイルで指定された移行オプションは、システムで構成されているものに対して検証されます。プロパティファイルに従ってダウンタイムを軽減するために必要とされる移行を呼び出します。最適化として、パッチ適用済みサーバと未適用のサーバ間での不要な移行を防ぐため、ワークフローがサーバ全体でロールアウトをする順番を生成します。
サーバをサーバ全体の移行（WSM）をするよう構成している場合、ZDTロールアウトはWSMもサポートします。
下表はすべての移行オプションのリストです。
| 移行タイプ | 説明 |
|---|---|
| jms | 現在ホストしているサーバ上で実行中のすべてのJMS関連のサービスを宛先のサーバに移行する |
| jta | JTAサービスを現在ホストしているサーバから宛先のサーバに移行する |
| all | 現在ホストしているサーバのJMSサービスとJTAサービスの両方を宛先のサーバに移行する |
| server | サーバインスタンス全体を宛先のマシンに移行する |
| none | 現在のサーバで実行中のシングルトンサービスのための移行は実施しない |
これらの移行オプションはWLSTのmigrateコマンドオプションと非常に似ていることがわかると思います。
Sample Migration Sequence
下図は、サービス移行の典型的なロールアウト・シーケンスです。ここで、JMSおよびJTAシングルトンサービスは、各サーバー用に構成済みの2種類の移行ターゲットとして表現されています。永続ストアおよびTLOGは、クラスタ内のすべてのサーバーからアクセスできる必要があります。管理者は、クラスタ内のサーバー間での移行方法を指定して管理します。次章では、ロールアウト時の移行をきめ細かく管理・制御するための設定を説明します。
ZDT Migration Properties
ロールアウトでの移行方法はロールアウトのコマンドにオプションを渡す移行プロパティファイルに指定します。移行プロパティ亜フィルはJSONファイルで、4個の主要なプロパティから構成されています。| 移行プロパティ | 説明 |
|---|---|
| source | 移行元サーバ（名）。つまり現在シングルトンをホストしているサーバ |
| destination | シングルトンサービスの移行先サーバ（名）。サーバ移行の場合はマシン名を指定 |
| migrationType | 前章に記載の通り、"jms"、"jta"、"all"、"server"、"none"を指定 |
| failback | サービスを元々ホストしているサーバに自動フェールバックする必要があるか否かを指定 |
{"migrations":[
# Migrate all JMS migratable targets on server1 to server2. Perform a fail back
# if the operation fails.
{
"source":"server1",
"destination":"server2",
"migrationType":"jms",
"failback":"true"
},
# Migrate only JTA services from server1 to server3. Note that JTA migration
# does not support the failback option, as it is not needed.
{
"source":"server1",
"destination":"server3",
"migrationType":"jta"
},
# Disable all migrations from server2
{
"source":"server2",
"migrationType":"none"
},
{
# Migrate all services (for example, JTA and JMS) from server 3 to server1 with
# no failback
"source":"server3",
"destination":"server1",
"migrationType":"all"
},
# Use Whole Server Migration to migrate server4 to the node named machine 5 with
# no failback
{
"source":"server4",
"destination":"machine5",
"migrationType":"server"
}
]}- migrationTypeが"None"の場合、このサーバで実行しているサービスは移行されません。フェールバックも不要であることを意味します。
- シングルトンサービスが見つかり、管理者が移行プロパティファイルに記載しなかった場合、rollout コマンドは失敗します。移行が不要な場合、管理者は明示的にサーバの各々に対し、移行プロパティ（つまり、migrationType=”None”）と明示する必要があります。
- migrationType が"server"の場合、宛先はノードマネージャのマシン名を指定する必要があります。そうすると、そのサーバインスタンスに対してWSM（サーバ全体移行）が呼び出されます。
- failbackのデフォルト値はfalseです（オプションを指定しない場合、フェールバックしません）。
- サーバに対し、ASMもしくはWSMを適用できますが、両方は適用できません。
- JTAサブシステムはJTAインスタンスの自動フェールバックをサポートしていますので、failback はJTAサービスのオプションでは使えません。
ロールアウト前に事前要件チェックの一環で 上記の検証チェックの各々が発生します。
ZDT Rollout Examples
以下は移行プロパティオプションの利用例です。サンプルのmigrationProperties.json ファイルは以下のようです。
{"migrations":[ {
"source":"m1",
"destination":"m2",
"migrationType":"jms",
"failback":"true"
} ]}Passing migration options to rolloutOracleHome
rolloutOracleHome('myDomain', '/pathto/patchedOracleHome.jar', '/pathto/unpatchedOracleHomeBackup/', options='migrationProperties=/pathto/migrationProperties.json')Passing migration options to rolloutApplications
rolloutApplications('myDomain', applicationProperties='/pathto/applicationProperties.json', options='migrationProperties=/pathto/migrationProperties.json')Passing migration options to rolloutJavaHome
rolloutJavaHome('myDomain', javaHome='/pathto/JavaHome1.8.0_60', options='migrationProperties=/pathto/migrationProperties.json')Passing migration options to rolloutUpdate
rolloutUpdate('myDomain', '/pathto/patchedOracleHome.jar', '/pathto/unpatchedOracleHomeBackup/', false, options='migrationProperties=/pathto/migrationProperties.json')Passing migration options to rollingRestart
rollingRestart('myDomain', options='migrationProperties=/pathto/migrationProperties.json')References
- Oracle® Fusion Middleware Administering Zero Downtime Patching Workflows 12c (12.2.1)
Preparing to Migrate Singleton Services
http://docs.oracle.com/middleware/1221/wls/WLZDT/preparing.htm#WLZDT180 - Oracle® Fusion Middleware Administering JMS Resources for Oracle WebLogic Server 12c (12.2.1)
Best Practices for JMS Beginners and Advanced Users
https://docs.oracle.com/middleware/1221/wls/JMSAD/best_practice.htm#JMSAD455 - Automatic Service Migration in WebLogic Server（かなり古いですがよい参考資料です）
http://www.oracle.com/technetwork/middleware/weblogic/messaging/wlasm-1853193.pdf