https://blogs.oracle.com/WebLogicServer/entry/zdt_technical_topic_how_are
ローリング方式でWebLogicドメインのアップデートをする上で、Zero Downtime Patchingが便利に自動化する方法を提供しており、その内容に関するドキュメントやこれまでのブログエントリをこれまでにご覧になっていることと思います。プロセスを自動化することで、Zero Downtime Patchingが大幅に時間を節約し、手順を繰り返し実施することで潜在的に有するヒューマンエラーを排除します。それに加えて、ロールアウトプロセス中の任意の時点において、エンドユーザーのセッションを確実に失わないようにするHTTPセッションレプリケーション関連で特別な機能があります。Zero Downtime Patching実行中のセッション状態の維持について、技術的な詳細を探ってみましょう。
WebLogic Serverのセッション管理コントラクト（session persistence contract）の複製に関する重要な側面の一つとして、サーバがクラッシュするというまれな場合でもクラスタ内でセッションを維持することができる、というものです。しかし、複数のサーバが短時間の間にダウンした場合、セッション管理コントラクトはセッションの維持を保証できません。これは、セッションは1個のコピーを持ち、そのコピーをクラスタ内のセカンダリサーバに複製しているからです。セッションはクライアントがセッションを更新するリクエストを送信した場合以下の場合にのみ複製され、クライアントのCookieがセカンダリサーバへの参照を格納することができます。そのため、プライマリサーバがダウンして、後続のクライアントからのリクエストがセッションをアップデートするまでにセカンダリサーバが落ちる場合、セッションが失われるでしょう。Zero Downtime Patchingのローリングの性質はこのパターンに適合しており、それゆえにセッション消失を防ぐよう細心の注意を取る必要があります。
クラスタで一度に1台のサーバを再起動すれば非常に簡単にセッションを消失できることは、管理者の方であればすでにご存知のことと思います。
Zero Downtime Patchingによる、セッション消失の問題を防ぐ方法についての技術的な詳細に入る前に、この方法論は全体として、ロードバランシング、動的検出、ヘルスチェック、およびセッションフェイルオーバー処理を担保するOracle Traffic Directorに依存していることに注意することが重要です。この設定に加えて、セッションの損失を防ぐため、Zero Downtime Patchingが直接3個の主要な機能を使っています。
1. Preemptive Session Replication
セッションデータは、正常なシャットダウン中、必要に応じて先んじてクラスタ内の別のサーバに伝播されます。より詳細に知りたい場合、ZDTロールアウトでHTTPセッションを保持しているサーバを停止し、続いて複製を保持するサーバを停止する、というシナリオを調べることができます。この場合、WebLogic Serverはシャットダウン中に、クラスタ内のバックアップ・コピーが存在しないため、セッションが失われることを検出することができます。そのため、ZDTロールアウトは、WebLogic Serverがクラスタ内の別のサーバにそのセッションを複製することを保証できるのです。下図は、セッションの1次コピーを保持しているサーバS1が、2次またはレプリカコピーを保持するサーバS2のシャットダウンに引き続いて、シャットダウンするという問題のシナリオを示したものです。ZDTオーケストレーションがs2が停止する前に任意の1個のセッションのコピーを複製する必要がありことを通知します。そのため、常にクラスタ内に利用可能なセッションのコピーが存在するのです。
2. Session State Query Protocol
WebLogic ServerがプライマリサーバとセカンダリサーバとのHTTPセッションの関連性に依存する方法が原因で、クラスタ内のどこかに、セッションを持つだけでは十分ではありません。クライアントのリクエストがクラスタ内の任意のサーバに到着すると、セッションを見つけることができる必要もあります。ZDTロールアウトを使うと、セッションのコピーを持っていない場合にクラスタ内の別のサーバに対し、特定のセッションを照会するためのWebLogic Serverの機能を有効にします。
上図は、セッションのないサーバーへの着信リクエストがクエリを呼び出すことができ、セッションがクラスタ内で発見される場合には、セッションを読み取り、リクエストをサーバs4に提供することができる様子を示しています。
3. Orphaned Session Cleanup
セッション・インスタンスを先んじて複製する機能と、クラスタ内からセッションを取得する機能を組み合わせた後に、読み取ったインスタンスを積極的にクリーンアップするアプローチを取る必要もあります。歴史的には、WebLogic Serverは、孤立したセッションについて多くを心配する必要はありませんでした。フロントエンドのロードバランサとWebサーバには、セッションのサーバ・アフィニティを尊重することが求められています。そして、リクエストがプライマリまたはセカンダリサーバのいずれでもないサーバに到着するというまれなケースでは、セッションを、プライマリサーバまたはセカンダリサーバから取得することになるでしょう。その上で、タイムアウトまたは他の定期的な間隔でクリーンアップされるべき孤立したセッションのコピーは忘れられることになるでしょう。これは、セッションへのポインタが変更されたために、実際に格納された参照が再度使われることがないことが想定されます。しかし、ZDTロールアウトでは、セッションをクラスタ内で発見し、セッションを保持しているサーバから読み取る必要がある、というシナリオを繰り返し提示します。セッション・インスタンスの数が急速に増殖する（すべてが同じセッションの様々なバージョンということもあり得ます）可能性があるだけでなく、クラスタからコピーを検索し、古くなったコピーを見つけてはならないのです。つまり、セッションの現時点での唯一のレプリカのみを見つける必要があります。
上図はs4がセッションデータを読み取って着信リクエストに応答した後のクリーンアップ・アクションを示しています。s3へのクリーンアップリクエストを発行し、確実にクラスタ内に古くなったデータを消去するようにしています。
Summary:
ZDT Patchingの間、server1を停止することができ、任意の孤立したセッションのコピーがクライアントの知らないうちにserver2に伝播されることが期待できます。クライアントが別のリクエストを送信した場合、WebLogic Serverは、そのリクエストを処理し、クラスタを照会してセッションデータを探すことができるようになります。データを読み取りリクエストを処理するサーバで利用されます。孤立したコピーがクリーンアップされ、リクエストを処理するサーバは、レプリカを格納するのに好ましいセカンダリサーバを選択するプロセスを通ります。Zero Downtime Patchingの詳細は、以下のドキュメントをご覧ください。
Oracle® Fusion Middleware Administering Zero Downtime Patching Workflows 12c (12.2.1)
Configuring and Monitoring Workflows
http://docs.oracle.com/middleware/1221/wls/WLZDT/configuring_patching.htm#WLZDT166
References
Oracle® Fusion Middleware Oracle WebLogic Serverクラスタの管理 12c (12.1.3)
HTTPセッション状態のレプリケーション
http://docs.oracle.com/cd/E57014_01/wls/CLUST/failover.htm#i1027876
Oracle® Fusion Middleware Administering Clusters for Oracle WebLogic Server 12c (12.2.1)
HTTP Session State Replication
http://docs.oracle.com/middleware/1221/wls/CLUST/failover.htm#CLUST206
0 件のコメント:
コメントを投稿