[WLS, Java] ZDT Rollouts and Singletons

原文はこちら。
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!
https://blogs.oracle.com/WebLogicServer/entry/zero_downtime_patching_released
http://orablogs-jp.blogspot.jp/2015/11/zero-downtime-patching-released.html 
ZDT patchingはOracle_Home、Java_Homeのロールアウトやアプリケーションのアップデートもサポートします。ZDTに関する詳細は、以下のエントリをご覧になるか、ドキュメントをご覧ください。
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)
Using OPatchAuto to Initiate, Revert, and Resume Rollouts
http://docs.oracle.com/middleware/1221/wls/WLZDT/configuring_patching.htm#WLZDT166
ZDTロールアウト時は、サーバーはローリング方式で再起動されます。サーバを落とすとシングルトンサービスも落とすことになるので、結果としてサービスの中断に至り、サーバが再起動されるまでサービスが利用できなくなるでしょう。実際のダウンタイムはサーバの立ち上げ時間とデプロイされているアプリケーションの種類によって変わります。このため、シングルトンサービスがクラスタにある依存アプリケーションに対する単一障害点とならないようにするため、ZDTロールアウトプロセスが自動的に移行を実行します。

ZDTロールアウトがシングルトンを取り扱う方法にはいくつかハイライトがあります。
  • すべての種類のロールアウトに適用できる（rolloutOracleHome、rolloutJavaHome、rollingRestart、rolloutUpdateなど）
  • ロールアウト中にきめ細かくサービス移行を制御するためにJSONファイルベースの移行オプションを使うことができる（WLSTまたはコンソールで指定可能）
  • サービス移行（JMSやJTA）だけでなく、サーバ移行（WSM）もサポート
  • 必要に応じて自動フェイルバック

Terms, Acronyms and Abbreviations

用語 意味
シングルトン（Singletons） クラスタの1個のサーバでのみホストされるサービス
移行可能なターゲット (MT) まとめて移行すべきサービスをグループ化する方法を提供する特別なターゲット。これには当該タイミングでアクティブなただ1個のサーバと移行対象候補のサーバのリストが含まれる。
ソース（移行元）サーバ サービス移行元のサーバインスタンス
移行先サーバ サービス移行先のサーバインスタンス
自動サービス移行 (ASM) 影響を受けたサブシステムのサービスをあるサーバインスタンスから別の実行中のサーバインスタンスへ移動するプロセス
サーバ移行 (WSM) ある物理マシンから別の物理マシンへサーバインスタンス全体を移動するプロセス
フェールバック（切り戻し） フェールバックは、サービスを元のホストサーバもしくは「ホーム」サーバへ移転するという意味。

Assumptions

ZDTロールアウトの間、サーバを正規の手順でシャットダウンしてから立ち上げ直します。ZDTロールアウトを開始するにあたり、管理者は管理対象サーバの再起動による影響を十分に認識する必要があります。任意のアプリケーションはサービス移行が構成されている、いないに関わらず、再起動に対して寛容であったりなかったりする可能性があります。
  • 非永続状態を持っている可能性がある
  • ランタイムクライアントの例外に対して寛容であったりなかったりする可能性がある
  • 再起動に要する時間が影響を及ぼすことがある
サーバが正常にシャットダウンされた場合、クライアント接続は、クライアントは閉じられるため、結果的にクライアントは例外を取得します。JMSサーバは、ロードバランシングとJMSメッセージのルーティングの決定のための候補リストから削除されます。ほとんどの場合、このようなクライアントの例外は一時的なもので、再試行すると異なるJMSサーバ、もしくは移行後の元のJMSサーバへリダイレクトされます。しかし、例外の中には一時的ではないものがあり、特定のJMSサーバインスタンスが復旧するまで、各クライアントの再試行に対し例外をスローし続けることがあります。サーバーがシャットダウン中にいくつかのレベルの静止を行いますが、これでJMSクライアントまたは他の場所でのすべてのエラーを防ぐことはできません。

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サービスの移行の両方を扱うことができます。

警告
  1. トランザクションマネージャは他の固定サービスのように移行ターゲットに割り当てられません。JTA ASM（自動サービス移行）はサーバ毎の設定です。これはJMSのようなサービスと対比すると、トランザクションマネージャが直接別の固定リソースに依存しないためです。
  2. ユーザー定義のシングルトンサービスの場合、自動的に”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

-
カテゴリ

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)