[WLS] ZDT Patching; A Simple Case – Rolling Restart

原文はこちら。
https://blogs.oracle.com/WebLogicServer/entry/zdt_patching_a_simple_case

---

ZDT（Zero Down Time）パッチ適用を理解するために、その最も単純な形であるローリング・リスタートを見てみましょう。この単純なユースケースは、Javaのバージョン、Oracleのパッチ、アプリケーションの更新といった類のロールアウトの基礎です。エンドユーザに対するサービスを停止させず、セッションデータを失わない状態を保証しながら、ローリング・リスタートを実行するには、ドメインやクラスタ内のすべての管理対象サーバの協調とコントロールされたシャットダウンが必要です。

管理者はローリング・リスタートを以下のWLSTコマンドを発行して開始することができます。

rollingRestart("Cluster1")

今回の場合、ローリング・リスタートは、「Cluster1」という名前のクラスタ内のすべての管理対象のサーバーに影響します。これはターゲットと呼ばれています。ターゲットは、単一のクラスタ、クラスタのリスト、またはドメイン名を取り得ます。

コマンドを入力すると、WebLogic管理サーバーがターゲットのトポロジーを分析し、動的にワークフローを作成します（ロールアウトとも呼ばれます）。これは、管理対象サーバ上のすべてのセッションが他の管理対象サーバで利用できるようにしながら、正常にシャットダウンし、クラスタ内の各管理対象サーバを再起動するためにとられるべき各ステップからなります。このワークフローは、次のノードに移動する前に、管理対象サーバ上で実行中のすべてのアプリケーションがエンドユーザからのリクエストを受け入れる準備が完全に整ったことも保証します。完全に一度クラスタ内のすべての管理対象サーバが再起動された場合には、ローリング・リスタートが完了しています。

以下は非常にシンプルなトポロジーでのこのプロセスを説明する図ですが、この図を見ると、ノードがオフライン（赤くなっている）になって、そのノードへ届くはずだったエンドユーザのリクエストが別のアクティブなノードへ再ルーティングされていることがわかります。オフラインノードのサーバが再起動され、アプリケーションが再度リクエストを受け入れる準備が整えば、このノードがアクティブなノードのプールに追加され、ローリング・リスタートは別のノードに移ります。

クラスタでのローリング・リスタート

ローリング・リスタートの機能はお客様からのフィードバックをもとに導入されました。管理対象サーバで動作するアプリケーションのメモリ使用量をリフレッシュすることを目的として、先回りして管理対象サーバを再起動する、というポリシーをお持ちのお客様がいらっしゃいます。この機能を使用して、エンドユーザーに影響を与えずに、手間と時間のかかるプロセスを非常に簡素化しています。

Zero Downtime Patchingを使ったローリング・リスタートに関する詳細情報は、以下のドキュメントをご覧ください。

Oracle® Fusion Middleware Administering Zero Downtime Patching Workflows 12c (12.2.1)
Initiating a Rolling Restart of Servers
http://docs.oracle.com/middleware/1221/wls/WLZDT/configuring_patching.htm#WLZDT170