Oracle® Fusion Middleware

ゼロ・ダウンタイム・パッチ適用ワークフローの管理

12c (12.2.1.1.0)

E77312-01(原本部品番号:E69724-01)

2016年6月

このドキュメントは、既存のOracleホームからパッチが適用されたOracleホームへドメインを移動する方法、新しいJavaバージョンへ更新する方法、ドメイン内のアプリケーションを更新する方法、またはサービスが失われることなくローリング再起動を実行する方法について説明します。

Oracle Fusion Middlewareゼロ・ダウンタイム・パッチ適用ワークフローの管理, 12c (12.2.1.1.0)

E77312-01

Copyright ©2016, 2016, Oracle and/or its affiliates All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

- このドキュメントの手引き

1 ダウンタイムなしのパッチ適用の概要

- ダウンタイムなしのパッチ適用とは

- パッチ適用ワークフローのタイプ

- パッチ適用ワークフローのプロセス

- 更新の回復

- パッチが適用されたOracleホームのロールアウト: 概要

- 新しいJavaバージョンのロールアウト: 概要

- 更新されたアプリケーションのロールアウト: 概要

- ZDTロールアウトのインメモリー・セッションのレプリケーション

2 ダウンタイムなしのパッチ適用の準備

- ZDTパッチ適用の制限

- シングルトン・サービスの移行の準備

- シングルトン・サービスの移行のためのJSONファイルの作成

- パッチが適用されたOracleホームのロールアウトの準備

- OPatchAutoを使用したパッチを適用するOracleホームのアーカイブの作成

- OPatchAutoを使用したパッチを適用するアーカイブの各ノードへの配布

- 2つ目のOracleホームの作成

- 2つ目のOracleホームへのパッチの適用

- アーカイブの作成および各ノードへの配布

- 新しいJavaバージョンへのアップグレードの準備

- 新しいアプリケーション・バージョンへの更新の準備

- ステージング・モードの影響

- アプリケーションの更新用JSONファイルの作成

3 ワークフローの構成と監視

- パッチが適用されたOracleホームのロールアウトの手法

- 管理サーバーの起動

- OPatchAutoを使用したロールアウトの起動、回復および再開

- OPatchAutoを使用したロールアウトの起動

- OPatchAutoを使用した失敗したロールアウトの再開

- OPatchAutoを使用したロールアウトの回復

- WLSTを使用したワークフローの起動と監視

- 新しいOracleホームのロールアウト

- Javaバージョンの更新

- OracleホームおよびJavaバージョンの両方の更新

- 更新されたアプリケーションのロールアウト

- 前のOracleホーム、Javaホームまたはアプリケーションへの回復

- サーバーまたはパーティションのローリング再起動の開始

- ワークフローの進行状況の監視

- 停止したワークフローの実行、回復および再開

- ワークフローに役立つWLSTコマンド

- サンプルのWLSTスクリプト

- WebLogic Server管理コンソールを使用したワークフローの作成と監視

- WebLogic Server管理コンソールでのZDTワークフロー機能へのアクセス

- ドメイン、クラスタまたはサーバー用の新しいワークフローの作成

- ワークフローの監視と管理

- ワークフロー詳細の表示

- サーバーのステータスの表示

- クラスタのステータスの表示

- ワークフローのステータス

- ワークフローのロギング

- ログ・ファイルのフィルタリング

- ログ・メッセージのフォーマット

はじめに

このドキュメント『ゼロ・ダウンタイム・パッチ適用ワークフローの管理』は、既存のOracleホームからパッチ適用済Oracleホームへドメインを移動する方法、新しいJavaバージョンへ更新する方法、またはサービスが失われることなくドメイン内のアプリケーションを更新する方法について説明します。ドメインを使用可能にしたままで、ドメイン内のサーバーに変更を系統的に適用するワークフローを作成する方法について説明します。また、ワークフローのタスクの進行状況を監視する方法や、前の状態にドメインを回復する方法についても説明します。

対象読者

このドキュメントは、Oracleホーム、新しいJavaバージョンまたはアプリケーション更新へのOracleパッチなど、ドメインへの更新の適用を担当する、WebLogic Serverの管理者およびオペレータを対象としています。読者は、WebLogic Server管理コンソール、WebLogic Scripting Tool (WLST)、およびOracle WebLogic Serverがインストールされているオペレーティング・システムとプラットフォームをよく理解していることが前提となっています。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

詳細は、次のOracle Fusion Middlewareドキュメントを参照してください。

- Opatchによるパッチ適用

- Oracle WebLogic Serverノード・マネージャの管理

- WebLogic Scripting Toolの理解

- WebLogic Server WLSTコマンド・リファレンス

- Oracle WebLogic Serverへのアプリケーションのデプロイ

- Oracle WebLogic Server MBeanリファレンス

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

このドキュメントの構成

このドキュメントは次のように編成されています。

- ダウンタイムなしのパッチ適用の概要では、作成できるパッチ適用ワークフローのタイプ、パッチ適用ワークフローの処理方法、およびパッチ適用の回復方法を含む、ダウンタイムなしのパッチ適用の概要について説明します。

- ダウンタイムなしのパッチ適用の準備では、パッチ適用ワークフローを構成する前に完了しておく必要がある事前ステップについて説明します。

- ワークフローの構成と監視では、ドメインをパッチが適用されたOracleホームに移動、ドメインのJavaバージョンを更新、ドメインのアプリケーションを更新、またはこれら3つすべてを行う、パッチ適用ワークフローの構成方法について説明します。

1 ダウンタイムなしのパッチ適用の概要

この章では、作成できるワークフローのタイプ、パッチ適用ワークフローの処理方法、およびパッチ適用の回復方法を含む、ダウンタイムなしのパッチ適用の概要について説明します。

この章の内容は次のとおりです。

- ダウンタイムなしのパッチ適用とは

- パッチ適用ワークフローのタイプ

- パッチ適用ワークフローのプロセス

- 更新の回復

- パッチが適用されたOracleホームのロールアウト: 概要

- 新しいJavaバージョンのロールアウト: 概要

- 更新されたアプリケーションのロールアウト: 概要

- ZDTロールアウトのインメモリー・セッションのレプリケーション

ダウンタイムなしのパッチ適用とは

ダウンタイムなしのパッチ適用(ZDTパッチ適用)では、アプリケーションがサービス提供リクエストを続行したまま、ホーム外パッチのロールアウトや、ドメイン全体の更新が自動化されます。パッチ適用手法を定義したら、WebLogic Scripting Tool (WLST)またはWebLogic Server管理コンソールのいずれかを使用して、ドメイン内の一部またはすべてのサーバー間で更新のロールアウトを編成できます。

WebLogic Serverはバージョン9.2からローリング・アップグレードをサポートしていますが、そのプロセスは常に手動でした。ZDTパッチ適用は、定義するワークフローを使用することによりこのプロセスを自動化します。ドメイン内の任意の数のノードを、ほとんどまたはまったく手動介入なしで、パッチ適用または更新できます。変更は一度に1つのノードにロールアウトされ、そのノードが更新されるまで、Oracle Traffic Directorのようなロード・バランサが受信トラフィックを残りのノードにリダイレクトすることができます。

パッチ適用ワークフローのタイプ

ZDTパッチ適用では次のタスクがサポートされます。これらのタスクのいずれかを実行するワークフローを作成できます。Oracleホームの更新、Javaバージョンの更新およびアプリケーションの更新の任意の組合せを実行するワークフローを作成することもできます。

- パッチが適用されたOracleホームへのサーバーの移動: ワークフローは管理サーバーまたはクラスタあるいはその両方を、OPatchユーティリティを使用してすでにパッチが適用された別のOracleホームに移行します。

- 新しいJavaバージョンへの更新: 新しくインストールされたJavaホームを使用するように、ワークフローは管理サーバーまたはクラスタあるいはその両方を更新します。

- 更新されたアプリケーションのデプロイ: ワークフローは選択したクラスタに更新済アプリケーションをデプロイします。

- サーバーのローリング再起動の実行: ワークフローは管理サーバー、または選択したクラスタ内のサーバーあるいはその両方を安全に順次再起動し、それにはサーバーの正常なシャットダウンおよび再度の起動が含まれます。

- パーティションのローリング再起動の実行: ワークフローは、クラスタ内または指定されたリソース・グループ内のパーティションを順次再起動します。その際には、各パーティションを1つずつ正常にシャットダウンし、それらを再度起動します。

パッチ適用ワークフローを作成する前に、各タスクに対し予備ステップをローリング再起動の例外を使用して完了する必要があります。詳細は、ダウンタイムなしのパッチ適用の準備,に関する項を参照してください。

パッチ適用ワークフローのプロセス

ZDTパッチ適用ワークフローを使用して更新をロールアウトする場合、ロールアウトは、次のことを実行します。

- 該当する各ノードを介して体系的に順番に処理します

- ロールアウトに含まれるノード上のサーバーを識別します

- それらのサーバーを正常にシャットダウンします

- パッチが適用されたOracleホームに切り替えるとき、次のことを実行します。

- 既存のOracleホームをバックアップ・ディレクトリにバックアップします

- ノード・マネージャを呼び出して、現在のOracleホームの内容を、指定したOracleホームの内容に切り替えます

- 新しいJavaバージョンに更新するとき、次のことを実行します。

- Javaホームへの参照を含むドメインのOracleホームのすべてのスクリプトを、新しいJavaホームをポイントするように更新します

- Javaホームへの参照を含むドメインのホーム・ディレクトリのすべてのスクリプトを、新しいJavaホームをポイントするように更新します

- 新しいアプリケーション・バージョンに更新するとき、次のことを実行します。

- 各アプリケーションの現在のディレクトリを探します

- 各アプリケーションの現在のディレクトリをバックアップの場所に移動します

- 各アプリケーションの新しいバージョンのディレクトリをそれぞれ元のアプリケーションの場所に移動します

- 更新がノードで完了したら各サーバーを再起動します

ワークフローは順番に適切なステップを実行し、各ステップの成功を監視します。ステップが失敗すると、ワークフローは再試行しようとします。ステップが正常に完了できない場合、ワークフローはそれぞれ前のステップを順番に回復します。回復プロセスは、更新の回復で説明するように、自動的に実行するように構成することも、手動で起動することもできます。

更新の回復

ZDTパッチ適用はまた、プロセスのどの時点でも(完了後であっても)更新を回復できます。更新は次のように回復できます。

- 自動—ワークフローの作成時に、障害がある場合に更新を自動的に回復することを選択できます。更新は失敗した時点からロールバックされ、正常に完了した最後のステップから開始します。

- 手動—ワークフローの進行中にそれを停止し、プロセスを任意の時点に回復できます。次に更新がロールバックされ、正常に完了した最後のステップから開始します。
ワークフローの完了後、実行された更新を回復するワークフローを作成できます。回復プロセスは、更新に応じて若干異なります。以前のOracleホームに回復する場合、プロセスがロールバックであることを指定するオプションが提供されます。Javaおよびアプリケーションの場合、回復するには、Javaまたはアプリケーションの以前のバージョンを指します。

更新の回復の詳細は、停止したワークフローの実行、回復および再開を参照してください。

パッチが適用されたOracleホームのロールアウト: 概要

この項では、パッチが適用されたOracleホームをドメイン内のすべてのノードにロールアウトする方法の概要を示します。ロールアウトを実行する前に、次の条件を満たしていることを確認してください。

- ドメインがすべてのノード間で分散されており、すべてのノード上で同じ場所に格納されている

- 既存のOracleホームがすべてのノード上で同じ場所にある

- ノード・マネージャがすべてのノードで実行されている

- ロールアウトに含まれるすべてのクラスタ内のすべての管理対象サーバーが実行されている

その他の要件および制限については、ZDTパッチ適用の制限を参照してください。図1-1では、ロールアウトの実行にOPatchAuto、WLSTまたはWebLogic Server管理コンソールのどれを使用するかにかかわらず、各ノードのOracleホームのロールアウトに対して実行される操作を示します。

パッチが適用されたOracleホームをロールアウトするには、次の作業を行います。

1. パッチが適用されたOracleホームのアーカイブは、次のいずれかの方法で作成および配布します。

- OPatchAutoを使用する

a. パッチが適用されたOracleホームのアーカイブを作成します。
詳細は、「OPatchAutoを使用したパッチを適用するOracleホームのアーカイブの作成」を参照してください

b. パッチを適用したOracleホームをロールアウトする先のすべてのノードにアーカイブを配布します。
詳細は、「OPatchAutoを使用したパッチを適用するアーカイブの各ノードへの配布」を参照してください

- パッチが適用されたOracleホームのアーカイブを、次のように手動で作成および配布する

a. copyBinaryコマンドを使用して既存のOracleホームのアーカイブを作成します。
このステップと次のステップの詳細は、「2番目のOracleホームの作成」を参照してください

b. pasteBinaryコマンドを使用して、本番ドメインと似たドメイン・トポロジの開発システムまたはテスト・システムでパッチを適用するOracleホームを作成します。これにより、本番システムと同じパッチレベルのOracleホームおよび製品が提供されます。

c. OPatchを使用して、必要なパッチを開発システムまたはテスト・システムのOracleホームに適用します。
詳細は、2つ目のOracleホームへのパッチ適用およびOPatchによるパッチ適用を参照してください。

d. パッチが適用されたOracleホームをテストおよび確認します。

e. パッチが適用されたOracleホームが安定していて問題なければ、copyBinaryを使用して、パッチが適用されたOracleホームのアーカイブを作成します。
このステップと次のステップの詳細は、「アーカイブの作成および各ノードへの配布」を参照してください

f. このアーカイブを本番システムのすべてのノードに配布します。

注意:

各ノードでのアーカイブの作成にpasteBinaryを使用する必要はありません。ロールアウト・プロセスはアーカイブから各ノードに新しいOracleホームを作成します。

2. パッチが適用されたOracleホームを管理サーバーにロールアウトするためのZDTワークフローを作成します。次のいずれかの方法でこれをできます。

- OPatchAutoを使用してロールアウトを起動し、ターゲットとして管理サーバーを指定します。
詳細は、「OPatchAutoを使用したロールアウトの起動」を参照してください

- WLST rolloutOracleHomeコマンドを使用し、ロールアウト・ターゲットとして管理サーバーを指定します。
詳細は、「新しいOracleホームのロールアウト」を参照してください

- WebLogic Server管理コンソールで、「ZDT制御」タブをクリックし、「サーバー」タブに移動します。「サーバー」タブで、管理サーバーを選択してから、ワークフローを開始および構成します。「ドメイン」タブをクリックし、ドメインを選択してワークフローを開始することもできます。
詳細は、ドメイン、クラスタまたはサーバー用の新しいワークフローの作成を参照してください。

3. ワークフローを正常に完了した後、パッチが適用されたOracleホームをドメイン内のクラスタにロールアウトするための別のZDTワークフローを作成します。次のいずれかの方法でこれをできます。

- OPatchAutoを使用してロールアウトを開始し、ロールアウト・ターゲットとしてクラスタまたはクラスタのカンマ区切りリストを指定します。
詳細は、「OPatchAutoを使用したロールアウトの起動」を参照してください

- WLST rolloutOracleHomeコマンドを使用し、ロールアウト・ターゲットとしてクラスタのカンマ区切りリストを指定します。

- WebLogic Server管理コンソールから、「ZDT制御」>「クラスタ」タブを選択し、Oracleホームをロールアウトする先のクラスタを選択してから、ワークフローを開始および構成します。

注意:

opatchautoまたはrolloutOracleHomeコマンドでターゲットとしてドメインを指定するか、「ZDT制御」>「ドメイン」タブからワークフローを開始および構成することにより、最後の2つのステップを1つのワークフローに組み合せることができます。

図1-1 Oracleホームのロールアウト操作

この図では、ロールアウトの実行にOPatchAuto、WLSTまたはWebLogic Server管理コンソールのどれを使用するかにかかわらず、各ノードのOracleホームのロールアウトに対して実行される操作を示します。

新しいJavaバージョンのロールアウト: 概要

この項では、新しいJavaバージョンをドメイン内のすべてのノードにロールアウトする方法の概要を示します。ロールアウトを実行する前に、次の条件を満たしていることを確認してください。

- ドメインがすべてのノード間で分散されており、すべてのノード上で同じ場所に格納されている

- Oracleホームがすべてのノード上で同じ場所にある必要がある

- ノード・マネージャがすべてのノードで実行されている

- ロールアウトに含まれるすべてのクラスタ内のすべての管理対象サーバーが実行されている

その他の要件および制限については、ZDTパッチ適用の制限を参照してください。

新しいJavaバージョンをロールアウトするには、次の手順を実行します。

1. 新しいバージョンのJavaをすべてのノードにインストールします。このJavaホームへのフル・パスは、すべてのノード上で同じである必要があります。

詳細は、「新しいJavaバージョンへのアップグレードの準備」を参照してください

2. 新しいJavaホームを管理サーバーにロールアウトするためのZDTワークフローを作成します。これは、次のいずれかの方法で行うことができます。

- WLST rolloutJavaHomeコマンドを使用し、ロールアウト・ターゲットとして管理サーバーを指定します。
詳細は、「Javaバージョンの更新」を参照してください

- WebLogic Server管理コンソールから、「ZDT制御」>「サーバー」タブを選択し、管理サーバーを選択してから、ワークフローを開始および構成します。
詳細は、ドメイン、クラスタまたはサーバー用の新しいワークフローの作成を参照してください。

3. ワークフローを正常に完了した後、新しいJavaホームをドメイン内のクラスタにロールアウトするための別のZDTワークフローを作成します。そのためには、次のいずれかを行います。

- WLST rolloutJavaHomeコマンドを使用し、ロールアウト・ターゲットとしてクラスタのカンマ区切りリストを指定します。

- WebLogic Server管理コンソールから、「ZDT制御」>「クラスタ」タブを選択し、新しいJavaバージョンをロールアウトする先のクラスタを選択してから、ワークフローを開始および構成します。

注意:

rolloutJavaHomeコマンドでターゲットとしてドメインを指定するか、「ZDT制御」>「ドメイン」タブからワークフローを開始および構成することにより、最後の2つのステップを1つのワークフローに組み合せることができます。

更新されたアプリケーションのロールアウト: 概要

この項では、新しいアプリケーション・バージョンをドメイン内の管理対象サーバー、パーティションまたはリソース・グループにロールアウトする方法の概要を示します。

現在、ZDTでは、アプリケーション・ロールアウト機能をパーティションとリソース・グループの両方に提供するWebLogic Serverマルチテナントがサポートされています。これは、リソース・グループ(パーティション・スコープまたはグローバル)または特定のパーティションにデプロイされたアプリケーションを、WebLogic Serverインスタンス内の他のリソース・グループまたはパーティションに影響を与えることなく更新できるようになったということです。WebLogic Server管理者は、多数のパーティションによって使用されるリソース・グループ・テンプレート内で定義されているアプリケーションを更新できます。単一パーティションにデプロイされたアプリケーションも更新できます。パーティション管理者は、それら固有のパーティション内で定義されているアプリケーションのみを更新できます。WebLogic Serverにおけるマルチテナンシの詳細は、WebLogic Serverマルチテナントの使用を参照してください。

ロールアウトを実行する前に、次の条件を満たしていることを確認してください。

- 更新されているドメインはすべてのノード間で分散されており、すべてのノード上で同じ場所に格納されている必要がある

- Oracleホームがすべてのノード上で同じ場所にある

- ノード・マネージャがすべてのノードで実行されている

- ロールアウトに含まれるすべてのクラスタ内のすべての管理対象サーバーが実行されている

- 更新されているパーティションのインスタンスが、複数のクラスタで実行されている必要がある

その他の要件および制限については、ZDTパッチ適用の制限を参照してください。図1-2、図、および図1-4では、それぞれ、ステージングされた、ステージングされていない、および外部ステージングされたアプリケーションのパッチ適用のためのシナリオを示します。パッチが適用されたアプリケーション・ソースは、ロールアウト中に、各ステージ・タイプに応じた適切なアプリケーション・ソースの場所に移動されます。

新しいアプリケーション・バージョンを管理対象サーバーにロールアウトするには、次の手順を実行します。

1. 更新済アプリケーション・ディレクトリのコピーを次のように配置します。

- (ステージ・モード)各更新済アプリケーション・ディレクトリのコピーを、ドメインの管理サーバーに配置します。

- (非ステージ・モードおよび外部ステージ・モード)各更新済アプリケーション・ディレクトリのコピーを、影響を受ける各ノードに配置します。ディレクトリは、すべてのノードで同じにする必要があります。

詳細は、「ステージング・モードの影響」を参照してください。

2. 各アプリケーション名、パーティション名(該当する場合)、リソース・グループ・テンプレート名(該当する場合)、各更新済アプリケーション・アーカイブのパスおよびファイル名、および元のアプリケーション・アーカイブをバックアップする先のパスおよびファイルを定義するJavaScript Object Notation (JSON)ファイルを作成します。

詳細は、「アプリケーションの更新用JSONファイルの作成」を参照してください

3. 新しいアプリケーション・バージョンをロールアウトするためのZDTワークフローを作成します。そのためには、次のいずれかを行います。

- WLST rolloutApplicationsコマンドを使用し、ロールアウト・ターゲットとしてクラスタのカンマ区切りリストを指定します。

- 管理コンソールから、「ZDT制御」>「クラスタ」タブを選択し、アプリケーションをロールアウトする先のクラスタを選択してから、ワークフローを開始および構成します。

図1-2 ステージングされたアプリケーションのパッチ適用

図1-3 非ステージ・アプリケーションのパッチ適用

図1-4 外部ステージングされたアプリケーションのパッチ適用

ZDTロールアウトのインメモリー・セッションのレプリケーション

インメモリー・セッションのレプリケーションを使用するWebアプリケーションの場合、インメモリー・セッションがレプリケートされるか維持されてフェイルオーバーが可能になることはありません。結果として、サーバーまたはフロントエンドの指示間違いによって突然障害が発生し、そのリクエストをサーバーがセッションなしで受信することにより、Webアプリケーションがセッション状態を失う場合があります。

ダウンタイムなしの(ZDT)ロールアウトに関しては、インメモリー・セッションを保持するサーバーをシャットダウンすると、サーバーはシャットダウンする前にそのセッションが完了するのを待機します。セッション・タイムアウトのデフォルト値が1時間のため、サーバーは1時間、またはセッションの使用や更新が続行された場合にはさらに長い時間、SUSPENDING状態になる可能性があります。Webアプリケーションに対するインメモリー・セッションはレプリケートされることも保存されることもないので、セッションがライフサイクルを完了するのを待機しなければその状態は失われます。

1時間以上も待機できない場合は、WLSTのrolloutコマンドで、shutdownTimeout引数にサーバーをシャットダウンするまでの待機時間(秒)を設定します。shutdownTimeout引数の使用の詳細は、表3-1を参照してください。

2 ダウンタイムなしのパッチ適用の準備

パッチ適用ワークフローを構成する前に、準備の手順を完了する必要があります。これらの手順には、新しいOracleホームのインストールおよびパッチ適用、新しいJavaバージョンのインストール、または各ノードへの更新済アプリケーションのインストールが含まれています。ZDTパッチ適用ワークフローを準備および作成する前に、覚えておく必要がある制限事項があります。

この章の内容は次のとおりです。

- ZDTパッチ適用の制限

- シングルトン・サービスの移行の準備

- パッチが適用されたOracleホームのロールアウトの準備

- 新しいJavaバージョンへのアップグレードの準備

- 新しいアプリケーション・バージョンへの更新の準備

ZDTパッチ適用の制限

ZDTパッチ適用ワークフローを準備および作成する前に、次の制限事項を確認してください。

- ワークフローに含まれる管理対象サーバーは、クラスタの一部である必要があり、そのクラスタは2つ以上のノードにまたがる必要があります。

- 管理サーバーをターゲット指定および更新せずに管理対象サーバーへの更新をロールアウトする場合は、更新されている管理対象サーバーとは異なるノード上に管理サーバーがあることを確認してください。

- パッチが適用されたOracleホームへと更新している場合、現在のOracleホームは、ワークフローに含まれる各ノードにローカルにインストールされる必要があります。必須ではありませんが、各ノードでOracleホームを同じ場所にすることもお薦めします。

- WLSTコマンドを使用して新しいOracleホームをロールアウトしている場合は、ロールアウトするOracleホームを含んだJARアーカイブへのパスを指定する必要があります。新しいOracleホームのロールアウト時は、ローカル・ディレクトリの指定はサポートされていません。前のOracleホームにロールバックしている場合のみ、ロールバック先となる、前のロールアウトからのバックアップOracleホーム・ディレクトリである、ローカル・ディレクトリへのパスを指定できます。

- ノード上の複数の管理対象サーバーが様々なクラスタに属しており、それらのクラスタが同一Oracleホームを共有する場合に、それらのクラスタのいずれかをワークフローに含める場合は、他のクラスタもそのワークフローに含める必要があります。たとえば、Node 1のCluster 1にManaged Server 1があり、Cluster 2にManaged Server 2があり、Cluster 1とCluster 2の両方が同じOracleホームを共有している場合、ワークフローにCluster 1が含まれていれば、Cluster 2も含める必要があります。これはJavaホーム、Oracleホームおよびアプリケーションの更新のロールアウトに適用されます。

- ドメイン・ディレクトリは、Oracleホームのディレクトリの外部に配置する必要があります。

- (Windowsのみ) WebLogic Scripting Tool (WLST)を使用して、新しいOracleホームのロールアウトを起動する場合、ワークフローの一部として更新されるOracleホームからWLSTを実行することはできません。かわりに、次のいずれかのオプションを使用します。

- ワークフローに含まれていないノードのOracleホームからWLSTを実行します。このOracleホームは他のノードの更新されているOracleホームと同じバージョンである必要があります。

- 更新されているドメインの一部ではない別のOracleホームからWLSTを実行します。このOracleホームは更新されているOracleホームと同じバージョンである必要があります。これは更新されているドメインの管理サーバー・ノードを含む、任意のノードに配置できます。

- WebLogic Server管理コンソールを使用して、ワークフローを起動します。

- (Windowsのみ) ZDTロールアウト操作中、Windowsファイルのロックは問題を引き起こす可能性があります。ロールアウトの失敗を避けるため、Windowsでロールアウトを実行する前に、これらの共通のファイル・ハンドルのロックの問題の修正を試みる必要があります。

- 管理コンソールを使用することでアプリケーションをデプロイしている場合、管理サーバーはアプリケーションのソース・ファイルでロックを保持できます。このロックが解放されないと、後続のアプリケーション・ロールアウトが適切に機能しない可能性があります。ロックを解放するには、アプリケーションのデプロイ後でロールアウトの起動前の任意の時点で、管理コンソールをログアウトする必要があります。

- 管理サーバーでWLSTクライアントを使用すると、Oracleホーム・ディレクトリのロックを引き起こします。これはそのノードのロールアウト(ドメインのロールアウトを含む)が失敗する原因になります。これを避けるには、ロールアウトのターゲットではないノードにインストールされたWLSTクライアントを使用するか、または管理コンソールを使用したロールアウトを起動します。

- Oracleホームの下の任意のディレクトリに存在する、コマンド・ターミナルまたはアプリケーションを開くことで、ファイルのロックが発生する可能性があります。結果として、特定のOracleホームを更新できなくなります。

- アプリケーション・ソース・ファイルまたはJARファイルを参照するコマンド・ターミナルまたはアプリケーションは、ファイル・ロックを引き起こす可能性があり、それにより特定のアプリケーションを更新できなくなります。

シングルトン・サービスの移行の準備

すべてのZDTロールアウトでは、ロールアウトに含まれるサーバーの再起動が必要です。ロールアウトの機能の1つは、Java Transaction API (JTA)およびJava Messaging Service (JMS)などのシングルトン・サービスの検出および処理です。ロールアウト操作中にこれらのシングルトン・サービスの可用性を高めるには、ZDTパッチ適用で、WebLogic Serverによってサポートされているサービス移行メカニズムを利用します。環境内のシングルトン・サービスの場合は、次のいずれかの方法でサービス移行を構成できます。

- 移行可能ターゲットを使用して構成されるシングルトン・サービスの移行の場合、サービス移行は、Oracle WebLogic Serverクラスタの管理のサービスの移行で説明されているとおりに構成されます。サービスが移行可能ターゲットを使用して構成されており、移行ポリシーがexactly-onceに設定されている場合、サービスはサーバーの正常なシャットダウン中に自動的に移行されます。しかし、サービスの移行ポリシーがmanualまたはfailure-recoveryの場合、サーバーのシャットダウン中にサービスが安全に移行されたことを確認するために、措置を講じる必要があります。これを実現するには、シングルトン・サービスの移行のためのJSONファイルの作成で説明されているように、JSONファイル内で移行プロパティを定義する必要があります。
移行可能ターゲットを使用して構成されるシングルトン・サービスの移行時には、次の問題の制限事項に留意する必要があります。

- JMSサーバーのデータ・ストアは、メッセージが失われることのない、クラスタのメンバーによって使用される共有の場所に配置する必要があります。詳細は、Oracle Fusion Middleware高可用性ガイドの共有ストレージの使用を参照してください。

- ClusterMBeanは、setServiceActivationRequestResponseTimeoutメソッドを使用して構成する必要があり、その値は、移行を正常に完了するためにかかる時間に応じて設定する必要があります。

- JNDI NameNotFoundExceptionは、JMS接続ファクトリおよび接続先のルックアップ中に返されます。これは既知の制限です。この制限事項およびその回避策の詳細は、My Oracle Supportで注意1556832.1を参照してください。

- ロールアウト中にサービスが移行されると、JMS接続ファクトリおよび接続先のJNDIルックアップが失敗します。そのようにサーバーに障害が発生する場合、JMSアプリケーションでは、移行が正常に完了するまで、非決定性の回数、利用可能な別のサーバーへの再接続を試みます。この機能の詳細は、Oracle WebLogic Server JMSアプリケーションの開発のサーバー障害からの回復を参照してください。

- JMSクラスタ構成を使用して構成されるシングルトン・サービスの移行の場合、サービスの移行は、Oracle WebLogic Server JMSリソースの管理の簡素化されたJMSクラスタおよび高可用性の構成で説明されているように構成されます(クラスタ・タイプによって異なる)。JMSクラスタ構成を使用してサービスが構成されている場合は、サーバーを正常にシャットダウンしている間にサービスを自動移行できるよう、移行ポリシーをAlwaysに設定する必要があります。移行ポリシーがOn-FailureまたはOffの場合は、サーバーのシャットダウン中にサービスが安全に移行されたことを確認するために、措置を講じる必要があります。この簡素化されたHAサービス移行モデルを使用している場合は、自動restart-in-placeオプションが明示的に無効になっていることを確認する必要もあります。

注意:

ZDTロールアウトでは、パッチ適用中にシャットダウンの前にシングルトン・サービスを移行する必要があるかどうかを指定できます。ただし、ロールアウト操作中は、同じマシン上のサーバーの移行は指定できません。それは、1つのマシン上のすべてのサーバーがロールアウト中にシャットダウンすることにより、ユーザーに回避できない停止時間が発生する可能性があるからです。ロールアウトが失敗する可能性がない場合は、必ず異なるマシン上のサーバーへのサービス移行を指定するようにしてください。

サービス移行は、ロールアウトされている1台目のサーバー上の1つ以上のシングルトン・サービスのシャットダウンを伴います。これは、サービスは、ロールアウトの進行中に2台目のサーバーで使用可能になるということです。ロールアウトが正常に完了すると、新しくパッチ適用された1台目のサーバーにサービスが移行されます。このプロセスはシングルトン・サービスの再起動を伴うため、サービスが1台目のサーバー上でシャットダウンされ、2台目のサーバー上で完全に起動されていないときに、サービスが短時間停止することが予想されます。これにより、サービスを利用できなくなり、アプリケーションが短時間稼働停止になる可能性があります。サービス停止期間は、JMSの場合はハードウェア(マシンおよびネットワークの両方)パフォーマンス、クラスタ・サイズ、サーバー起動時間、および永続メッセージ・バックログなどの要因によって異なる可能性があります。

シングルトン・サービスの移行のためのJSONファイルの作成

サーバーのシャットダウン中にシングルトン・サービスが必ず安全に移行されるようにするには、次のタスクを実行する必要があります。

- この項での説明に従って、このようなサービス用の移行プロパティを定義するJSONファイルを作成します

- ワークフローの構成と監視の説明に従って、JSONファイルを使用するロールアウトを構成します。

JSONファイルは、次の行で始まる必要があります。

{"migrations":[

移行する必要のある各シングルトン・サービスの移行は、次の表で説明しているパラメータを使用して定義されます。

パラメータ

説明

source

サービスが移行される元のソース・サーバーの名前。このパラメータは必須です。

destination

migrationTypeがjms、jtaまたはallの場合、サービスが移行される先のサーバーの名前。

migrationTypeがserverの場合、ノード・マネージャが実行しているドメイン内の別のマシン(ノード)の名前。

migrationTypeがjms、jta、serverまたはallの場合、このパラメータは必須です。

migrationType

移行のタイプ。次のタイプのいずれかです。

- jms — すべてのJMS移行可能ターゲットをソース・サーバーから移行先サーバーへ移行します。

- jta — すべてのJTAサービスをソース・サーバーから移行先サーバーへ移行します。

- server — サーバーの移行を実行するサーバー全体の移行を起動します。移行先はノード・マネージャが実行しているマシン(ノード)である必要があります。

- all — すべてのサービス(JTAやJMSなど)をソース・サーバーから移行先サーバーへ移行します。

- none — ソース・サーバーからのサービスの移行を無効にします。このタイプを指定する場合、failbackおよびdestinationは必要ありません。

failback

trueに設定されている場合は、フェイルバック操作が実行されます。フェイルバックは、サービスを元のホスティング・サーバー(ロールアウト前にサービスが実行されていたサーバー)にリストアします。

デフォルト値はfalseです(フェイルバックなし)。

注意: JTAサービスは移行用に起動されたときに自動的にフェイルバックされます。したがって、JTAサービスには適用されないため、failbackオプションを使用しないでください。failbackオプションを指定した場合は、ロールアウトは失敗します。

次のサンプルJSONファイルに、様々な移行シナリオの定義方法を示します。

{"migrations":[

# Migrate all JMS migratable targets on server1 to server2. Perform a failback
{
"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"
}

]}

パッチが適用されたOracleホームのロールアウトの準備

管理対象サーバーへのパッチ適用済Oracleホームのロールアウトを準備する方法は2つあります。

- OPatchAutoツールを使用して、Oracleホームの自動的なクローン作成、パッチの適用、パッチを適用したOracleホームのアーカイブの作成を行うことができます。次に、OPatchAutoを使用して、パッチ適用済Oracleホームのアーカイブをドメイン内のノードに配布できます。より自動化されている、この手法の使用をお薦めします。詳細は、次の項を参照してください。

- OPatchAutoを使用したパッチを適用するOracleホームのアーカイブの作成

- OPatchAutoを使用したパッチを適用するアーカイブの各ノードへの配布

- 手動で2つ目のOracleホームを作成し、OPatchユーティリティを使用してそれにパッチを適用し、copyBinaryコマンドを使用してパッチ適用済Oracleホームのアーカイブを作成し、その後そのアーカイブをドメイン内のノードにコピーできます。詳細は、次の項を参照してください。

- 2つ目のOracleホームの作成

- 2つ目のOracleホームへのパッチの適用

- アーカイブの作成および各ノードへの配布

どちらの場合も、準備プロセスに管理対象サーバーのシャットダウンは必要ないので、アプリケーションの可用性に影響はありません。

注意:

ドメインにOracle WebLogic Server以外のOracle Fusion Middleware製品(Oracle SOA SuiteやOracle WebCenterなど)が含まれていて、Oracleホームのそれらのアプリケーションにパッチを適用済の場合、ロールアウトを実行中に現在のアクティブ・セッションを保持するには、パッチが適用されたバージョンがZDTパッチ適用と互換性があることを確認します。たとえば、適用されたパッチはセッション形状への変更に制限があり、ドメインで実行中の他のOracle Fusion Middleware製品と下位互換性を持つ必要があります。

OPatchAutoを使用したパッチを適用するOracleホームのアーカイブの作成

この項では、既存のOracleホームのクローンを作成し、それにパッチを適用し、OPatchAutoツールを使用してパッチ適用済Oracleホームのアーカイブを作成する方法を説明します。パッチを適用する前に、まずOPatchを使用してpatch_homeディレクトリにそれらをダウンロードする必要があります。

パッチが適用されたOracleホームのアーカイブを作成するには、次のコマンドを入力します。イメージを作成する元のORACLE_HOMEからopatchauto applyコマンドを実行する必要があります。このコマンドは、パッチ未適用のOracleホームのクローンを作成し、指定したpatch_homeディレクトリのパッチを適用してから、パッチが適用されたアーカイブを作成します。

cd ORACLE_HOME/OPatch/auto/core/bin
opatchauto.sh apply patch_home -create-image -image-location path -oop

次の表に、opatchauto applyコマンドにおけるパラメータを示します。

パラメータ

説明

patch_home

適用するパッチが保存されているOPatch $PATCH_HOMEディレクトリ

-create-image

Oracleホーム・ディレクトリのイメージを作成することを示します。イメージにはpatch_homeのパッチが含まれます。

-image-location path

作成するイメージJARファイルのフルパスとファイル名を指定します。次に例を示します。

-image-location /u01/images/OH-patch1.jar

-oop

これがホーム外パッチ適用アーカイブであることを示します

パッチが適用されたアーカイブのOPatchAutoを使用した各ノードへの配布

パッチが適用されたアーカイブを作成したら、OPatchAutoを使用して、そのアーカイブをOracleホームのパッチ適用ワークフローに含まれる各ノードに配布します。

アーカイブを配布するには次のコマンドを使用します。

cd ORACLE_HOME/OPatch/auto/core/bin
opatchauto.sh apply -plan wls-zdt-push-image -image-location path
-wls-zdt-host adminserver:port -wls-zdt-target target
-wls-zdt-remote-image path -wallet path -walletPassword password

次の表に、opatchauto applyコマンドにおけるパラメータを示します。

パラメータ

説明

-plan

opatchauto applyにより実行される操作のタイプを示します。ZDTのパッチ適用済Oracleホームの配布では、このパラメータの値としてwls-zdt-push-imageを必ず指定します。

-image-location path

配布するイメージJARファイルのフルパスとファイル名を指定します。次に例を示します。

-image-location /u01/images/OH-patch1.jar

-wls-zdt-host adminserver:port

パッチが適用されたOracleホームのロールアウト先のドメインの、管理サーバーのホスト名とポート番号を指定します。アーカイブはこのノードに配布されます。

-wls-zdt-target target

ロールアウトに含まれるクラスタまたはクラスタのカンマ区切りリストを指定します。アーカイブはこれらのクラスタが構成されるすべてのノードに配布されます。

-wls-zdt-remote-image path

ZDTロールアウトに含まれる各ノードに作成するアーカイブ・ファイルへのフルパス。これは、元のアーカイブと同じファイル名である必要はありません。次に例を示します。

-wls-zdt-remote-image /u01/images/rollout-OH-image.jar

-wallet path

configWallet.shまたはconfigWallet.cmdを使用して作成されたウォレット・ディレクトリへのフルパス。次に例を示します。

-wallet $HOME/wallet

-walletPassword password

必要な場合、指定したウォレットのパスワード。次に例を示します。

-walletPassword mypassword

パッチを適用したアーカイブを配布したら、Oracleホームのパッチ適用を含むワークフローを作成する準備は完了です。ワークフローの構成と監視を参照してください。

注意:

同じパッチ適用ワークフローを使用してJavaバージョンまたはアプリケーションも更新する場合、ワークフローの作成前に、これらのアップグレードのための準備ステップを実行します。

2つ目のOracleホームの作成

パッチが適用されたOracleホームを手動で作成するには、最初にcopyBinaryおよびpasteBinaryコマンドを使用することで既存のOracleホームのコピーを作成する必要があります。これらのコマンドの使用時には、指定したオプションの値にスペースを含まないようにすることを覚えておいてください。たとえば、Windowsでは、-javaHomeオプションの値として次のような文字列を渡すことはできません。

C:\Program Files\jdk

注意:

適用するパッチをテストできるように、本番マシン以外に2つ目のOracleホームを作成してパッチを適用することをお薦めしますが、必須ではありません。ただし、新しいOracleホームにパッチを適用するノード上で、次のステップを実行する必要があります。そのノードのOracleホームは、本番ドメインで使用しているOracleホームと同じである必要があります。

パッチを適用する2つ目のOracleホームを作成するには、次の手順を実行します。

1. 次のディレクトリに移動します。ここでORACLE_HOMEはパッチを適用するOracleホームです。

cd ORACLE_HOME/oracle_common/bin

2. 次のコマンドを実行します。ここで、archiveは作成するアーカイブ・ファイルのフルパスおよびファイル名で、oracle_homeは既存のOracleホームへのフルパスです。JAVA_HOMEはOracleホームのインストールに使用されたJavaホームとして定義される必要があることに留意してください。

UNIX

./copyBinary.sh -javaHome $JAVA_HOME -archiveLoc archive -sourceOracleHomeLoc oracle_home

Windows

copyBinary.cmd -javaHome %JAVA_HOME% -archiveLoc archive -sourceOracleHomeLoc oracle_home

たとえば、次のコマンドは、/u01/oraclehomes/wls1221にあるOracleホームを使用して、Oracleホーム・アーカイブwls1221.jarをネットワークの場所/net/oraclehomes/に作成します。

./copyBinary.sh -javaHome $JAVA_HOME -archiveLoc /net/oraclehomes/wls1221.jar -sourceOracleHomeLoc /u01/oraclehomes/wls1221

3. 次のコマンドを実行して、2つ目のOracleホームを作成します。ここで、archiveは作成するアーカイブ・ファイルのフルパスおよびファイル名で、patch_homeはパッチを適用する新しいOracleホームへのフルパスです。JAVA_HOMEは元のOracleホームのインストールに使用されたJavaホームとして定義される必要があることに留意してください。

UNIX

./pasteBinary.sh -javaHome $JAVA_HOME -archiveLoc archive -targetOracleHomeLoc patch_home

Windows

pasteBinary.cmd -javaHome %JAVA_HOME% -archiveLoc archive -targetOracleHomeLoc patch_home

たとえば、次のコマンドは、アーカイブ/net/oraclehomes/wls1221.jarを使用して、Oracleホームwls1221_patchedを/u01/oraclehomes/に作成します。

./pasteBinary.sh -javaHome $JAVA_HOME -archiveLoc /net/oraclehomes/wls1221.jar -targetOracleHomeLoc /u01/oraclehomes/wls1221_patched

2つ目のOracleホームへのパッチの適用

2つ目のOracleホームにパッチを適用するには、OPatchツールを使用して個別のパッチ、バンドル・パッチ、セキュリティ・パッチの更新、またはパッチ・セットの更新を、2つ目のオフラインのOracleホームへ適用します。特定のパッチまたはパッチのグループを適用する前に、すべての前提条件のパッチが適用済であることを確認します。

OPatchを使用したOracleホームへのパッチの適用および準備方法の詳細は、Opatchによるパッチ適用を参照してください。

アーカイブの作成および各ノードへの配布

パッチが適用されたOracleホームを作成したら、次のステップを使用してOracleホームのアーカイブを作成し、それをロールアウトに含まれる各ノードにコピーします。

1. 次のディレクトリに移動します。ここでORACLE_HOMEは作成したパッチ適用済Oracleホームです。

cd ORACLE_HOME/oracle_common/bin

2. 次のコマンドを実行します。ここで、archiveは作成するアーカイブ・ファイルのフルパスおよびファイル名で、oracle_homeは作成したパッチ適用済Oracleホームへのフルパスです。JAVA_HOMEは現在のOracleホームのインストールに使用されたJavaホームとして定義される必要があることに留意してください。

UNIX

./copyBinary.sh -javaHome $JAVA_HOME -archiveLoc archive -sourceOracleHomeLoc patched_home

Windows

copyBinary.cmd -javaHome %JAVA_HOME% -archiveLoc archive -sourceOracleHomeLoc patched_home

たとえば、次のコマンドは、/01/oraclehomes/wls1221_patchedにあるパッチ適用済Oracleホームを使用して、Oracleホーム・アーカイブwls1221.11.jarをネットワークの場所/net/oraclehomes/に作成します。

./copyBinary.sh -javaHome $JAVA_HOME -archiveLoc /net/oraclehomes/wls_1221.11.jar -sourceOracleHomeLoc /u01/oraclehomes/wls1221_patched

3. パッチ適用ワークフローに含まれる各ノードで、置き換えるOracleホームの親フォルダにアーカイブ・ファイルをコピーします。たとえば、アーカイブがネットワークの場所/net/oraclehomes/wls_1221.11.jarにあり、置き換えられるOracleホームは/u01/oraclehomes/wls1221にある場合:

cp /net/oraclehomes/wls1221.11.jar /u01/oraclehomes/

多数のノードにコピーしている場合、このステップを実行するのにサードパーティ製ソフトウェアの配布アプリケーションを使用することができます。

これらのステップを完了したら、Oracleホームのパッチ適用を含むワークフローを作成する準備は完了です。ワークフローの構成と監視を参照してください。

注意:

同じパッチ適用ワークフローを使用してJavaバージョンまたはアプリケーションも更新する場合、ワークフローの作成前に、これらのアップグレードのための準備ステップを実行します。

新しいJavaバージョンへのアップグレードの準備

Javaの新しいバージョンへのアップグレードの準備には、管理対象サーバーのシャットダウンは必要ありません。そのため、アプリケーションの可用性の妨げにはなりません。

新しいJavaバージョンにアップグレードするには、次の手順を実行します。

1. 新しいJavaバージョンをインストールする前に、ノード・マネージャと管理対象サーバーが、新しいバージョンをインストール予定のすべてのノードで実行していることを確認します。これにより、Javaインストーラが既存のJavaホームのパスを変更するのを防ぎます。ただし、ノード・マネージャを、管理サーバーが実行されているノード上で実行する必要はありません。

2. アップグレードに含まれる各ノードで、新しいJavaバージョンを各ノードの同じパスにインストールします。新しいJavaバージョンへのフル・パスは、アップグレードが正常に行われるために、各ノード上で同じである必要があります。

新しいJavaバージョンを各ノードへコピーしたら、新しいJavaホームへのアップグレードを含むワークフローを作成する準備は完了です。ワークフローの構成と監視を参照してください。

新しいアプリケーション・バージョンへの更新の準備

この項では、ZDTワークフローを使用して新しいアプリケーションにアップグレードするための準備方法について説明します。内容は次のとおりです。

- ステージング・モードの影響

- アプリケーションの更新用JSONファイルの作成

ステージング・モードの影響

管理対象サーバー、パーティションまたはリソース・グループにわたるデプロイされたアプリケーションは、stageモード、no-stageモードおよびexternal-stageモードという3つのステージング・モードのいずれかを使用してデプロイできます。選択したモードにより、アプリケーションをどのように配布し最新の状態に保つかを示します。

アプリケーションの更新ワークフローの準備方法は、アプリケーションをステージングしたときに使用されたモードによって異なります。

ステージング・モード

必要な準備と結果

ステージ

各更新済アプリケーション・ディレクトリのコピーを、ドメインの管理サーバーに配置します。

結果: ワークフローでは、元のアプリケーション・ディレクトリを管理サーバーに配置し、WebLogic Serverがそれを各管理対象サーバーにコピーします。

非ステージ

更新済アプリケーション・ディレクトリのコピーを、影響を受ける各ノードに配置します。このディレクトリは各ノード上で同じ場所にある必要があります。

結果: ワークフローは、既存のアプリケーション・ディレクトリを更新済アプリケーション・ディレクトリで置き換えることにより、各ノードを順次更新し、元のアプリケーション・ディレクトリを指定したバックアップの場所に移動します。

外部ステージ

更新済アプリケーション・ディレクトリのコピーを、影響を受ける各ノードに配置します。このディレクトリは各ノード上で同じ場所にある必要があります。

結果: ワークフローはアプリケーションが外部ステージ・アプリケーションであることを検出し、ノード上の各管理対象サーバーのステージ・ディレクトリの正しいパスを特定し、更新済アプリケーションをその場所にコピーし、元のアプリケーションを指定したバックアップの場所に移動します。

様々なステージング・モードの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のステージング・モードの説明とベスト・プラクティスに関する項を参照してください。

アプリケーションの更新用JSONファイルの作成

単一のワークフローを使用して、ドメイン、パーティションまたはリソース・グループ内の1つ以上のアプリケーションを更新できます。アプリケーションの更新は、各アプリケーションに対して次のことを定義する、JSONファイルを作成することで実行されます。

- アプリケーション名(applicationName)

- 更新されたアプリケーション・アーカイブに対するパスおよびファイル名(patchedLocation)

- 元のアプリケーション・アーカイブをバックアップする先のパスおよびファイル(backupLocation)

- パーティション名。これは、パーティションにデプロイされたアプリケーションを更新している場合のみに当てはまります。

- リソース・グループ・テンプレート名。これは、リソース・グループにデプロイされたアプリケーションを更新している場合のみに当てはまります。

注意:
JSONファイル内でパスを指定する際には、バックスラッシュ(Windows)を使用しないようにすることをお薦めします。これは、これらのパスがJavaによって解釈され、バックスラッシュによって異なる文字表現がトリガーされる場合があるためです。

WLSTまたはWebLogic Server管理コンソールのいずれかを使用してワークフローを構成する場合、更新に使用するJSONファイルのファイル名を指定します。

次の例に、2つのアプリケーションMyAppおよびAnotherAppを新しいバージョンに更新することを意図するJSONファイルの構造を示します。1つのJSONファイルを使用して必要な数のアプリケーションを更新できます。

{"applications":[
{
"applicationName":"MyApp",
"patchedLocation":"/u01/applications/MyAppv2.war",
"backupLocation": "/u01/applications/MyAppv1.war"
},
{
"applicationName":"AnotherApp",
"patchedLocation":"/u01/applications/AnotherAppv2.war",
"backupLocation": "/u01/applications/AnotherAppv1.war"
}
]}

更新済アプリケーションを必要な場所すべてにコピーし、JSONファイルを作成したら、アプリケーションの更新を含むワークフローを作成する準備ができます。ワークフローの構成と監視を参照してください。

3 ワークフローの構成と監視

パッチが適用されたOracleホームへの管理対象サーバーの移動、管理対象サーバーのJavaバージョンの更新、管理対象サーバーのアプリケーションの更新、またはこれらの更新タスクの組合せのパッチ適用ワークフローを構成および監視します。WebLogic Server管理コンソールまたはWebLogic Scripting Tool (WLST)を使用して、ワークフローを作成および監視できます。

注意:

更新プロセスを開始する前に、ダウンタイムなしのパッチ適用の準備に従って、実行中の更新のタイプに応じた適切な準備手順をすべて完了しておく必要があります。

Windowsベースのドメインの場合、Oracleホームを更新するワークフローを開始する前に、各ノードで、更新されるOracleホームにロックされているディレクトリまたはファイルがないことを確認します。これがあると、指定したバックアップ・ディレクトリにOracleホームを移動できない可能性があるためです。ディレクトリはDOSコマンド・ウィンドウをそのディレクトリで開くという程度の簡単なことでロックできます。ファイルはそのファイルをアプリケーションで開くことによってロックできます。

この章の内容は次のとおりです。

- パッチが適用されたOracleホームのロールアウトの手法

- 管理サーバーの起動

- OPatchAutoを使用したロールアウトの起動、回復および再開

- WLSTを使用したワークフローの起動と監視

- WebLogic Server管理コンソールを使用したワークフローの作成と監視

パッチが適用されたOracleホームのロールアウトの手法

WLSTまたは管理コンソールのいずれかを使用して新しいOracleホームをロールアウトするときには、パッチが適用されたOracleホームが最初に管理サーバーにロールアウトされるようにする必要があります。これを行うには2つの方法があります。

- 1つのワークフローを使用してパッチ適用済Oracleホームを管理サーバーにロールアウトし、次に2つ目のワークフローを使用してパッチ適用済Oracleホームをクラスタにロールアウトします。この手法の使用をお薦めしますが、必須ではありません。
このシナリオでは、次のようになります。

- WLSTを使用している場合、rolloutOracleHomeまたはrolloutUpdateコマンドのいずれかを実行し、ターゲットとして管理サーバー名を指定します。次にrolloutOracleHomeまたはrolloutUpdateを再度実行し、クラスタ・ターゲットを指定します。

- WebLogic Server管理コンソールを使用している場合、「サーバー」タブから1つのワークフローを作成し、ターゲットとして管理サーバーを選択します。そのワークフローが完了したら、「クラスタ」タブから2つ目のワークフローを作成し、含めるクラスタを選択します。

- 1つのワークフローのみを使用してパッチ適用済Oracleホームをドメイン全体にロールアウトします。ワークフローは、パッチが適用されたOracleホームを、ターゲット・クラスタにロールアウトする前に最初に自動的にロールアウトします。
このシナリオでは、次のようになります。

- WLSTを使用している場合、rolloutOracleHomeまたはrolloutUpdateコマンドのいずれかを実行し、ターゲットとしてドメイン名を指定します。

- 管理コンソールを使用している場合、「ドメイン」タブから1つのワークフローを作成します。

管理サーバーの起動に関する項

管理サーバーがワークフローに含まれる場合、startWebLogicスクリプトまたはノード・マネージャを使用して管理サーバーを起動できます。ロールアウトのために指定したターゲットがドメインである場合、管理サーバーは、ロールアウト操作の間に自動的に再起動されます。ただし、ロールアウト操作によって管理サーバーが再起動されるときに、WLSTまたは管理サーバーのどちらにも接続できないと、短いダウンタイムが発生する場合があります。回避策として、ロールアウト操作の進行状況に関して更新を受け取るために、管理サーバーがRUNNING状態に達したときに、待機してから再接続する必要があります。

ロールアウト操作を開始する前に管理サーバーを起動するには、次のいずれかの方法で管理サーバーを起動します。

- startWebLogicスクリプトの使用
管理サーバーについて構成されたノード・マネージャがない場合は、startWebLogicスクリプトを使用することで管理サーバーを起動できます。このスクリプトを使用して管理サーバーを起動するには、Oracle WebLogic Serverサーバーの起動と停止の管理の起動スクリプトによる管理サーバーの起動を参照してください。

- ノード・マネージャの使用
ノード・マネージャが管理サーバーのために構成されている場合は、ノード・マネージャを使用して管理サーバーを起動する必要があります。ノード・マネージャを使用して管理サーバーを起動するには、次の手順を実行します。

1. 管理サーバーが現在実行中で、ドメイン・ホームでstartWebLogicスクリプトを使用して起動された場合、stopWebLogicコマンドを使用してシャットダウンします。

UNIX

cd domain_home/bin
./stopWebLogic.sh

Windows

cd domain_home\bin
stopWebLogic.cmd

2. ノード・マネージャがホストで実行中であることを確認します。

3. WLSTを起動します。WebLogic Scripting Toolの理解のWLSTの呼出しを参照してください。

4. nmConnectコマンドを使用してノード・マネージャ・セッションを確立します。たとえば、SSLを使用して、/domains/mydomainにあるドメインmydomainに接続するには、次のコマンドを使用します。ここでは、ノード・マネージャ・ポートは5556です。

wls:/myserver/serverConfig> nmConnect('username', 'password, 'localhost',
'5556', 'mydomain', '/domains/mydomain','ssl')

5. 正常に接続されてから、nmStartコマンドを実行します。たとえば、管理サーバーがAdminServerであり、ドメインが/domains/mydomainにある場合は、次のコマンドを使用します。

nmStart('AdminServer', '/domains/mydomain')

詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャを使用した管理サーバーの起動に関する項を参照してください。

OPatchAutoを使用したロールアウトの起動、回復および再開

この項では、パッチが適用されたOracleホームをドメインのノードに適用する、ロールアウト・ワークフローの起動および監視方法について説明します。この手法は、パッチが適用されたOracleホームにワークフローが適用される場合にのみ使用できます。Javaバージョンの更新またはアプリケーションの更新をワークフローに含める場合、WLSTまたは管理コンソールを使用する必要があります。

この項では、次の項目について説明します。

- OPatchAutoを使用したロールアウトの起動

- OPatchAutoを使用したロールアウトの回復

- OPatchAutoを使用した失敗したロールアウトの再開

注意:

OPatchAutoを使用してワークフローを起動する場合、管理コンソールを使用してワークフローの進行状況を監視する必要があります。「ワークフローの監視と管理」を参照してください

OPatchAutoを使用したロールアウトの起動

次のコマンドを使用して、OPatchAutoを使用するワークフローを起動します。

cd ORACLE_HOME/OPatch/auto/core/bin
opatchauto.sh apply -plan wls-zdt -image-location path
-wls-zdt-host adminserver:port -wls-zdt-target target
-wls-zdt-remote-image path -wallet path -walletPassword password

次の表に、opatchauto applyコマンドにおけるパラメータを示します。

パラメータ

説明

-plan

opatchauto applyにより実行される操作のタイプを示します。ZDTのパッチ適用済Oracleホームのロールアウトでは、このパラメータの値としてwls-zdtを必ず指定します。

-image-location path

ロールアウトに使用する、パッチ適用済Oracleホームを含むイメージJARファイルのフルパスと名前を指定します。次に例を示します。

-image-location /u01/images/rollout-OH-image.jar

-wls-zdt-host adminserver:port

パッチが適用されたOracleホームのロールアウト先のドメインの、管理サーバーのホスト名とポート番号を指定します。

-wls-zdt-target target

targetには、ロールアウトのターゲットを指定します。これには次のものがあります。

- ドメイン名

- クラスタ名

- クラスタのカンマ区切りリスト

アーカイブをロールアウトしている場合、ロールアウトに使用しているアーカイブを配布したときに指定したのと同じターゲットを指定する必要があります。

-wls-zdt-backup path

既存のOracleホームをバックアップするのに使用するディレクトリへのフルパス。次に例を示します。

-wls-zdt-backup /u01/images/rollout-OH-image.jar

-wls-zdt-remote-image path

ZDTロールアウトに含まれる各ノードに作成するアーカイブ・ファイルへのフルパス。これは、元のアーカイブと同じファイル名である必要はありません。次に例を示します。

-wls-zdt-remote-image /u01/images/rollout-OH-backup

-wallet path

configWallet.shまたはconfigWallet.cmdを使用して作成されたウォレット・ディレクトリへのフルパス。次に例を示します。

-wallet $HOME/wallet

-walletPassword password

必要な場合、指定したウォレットのパスワード。次に例を示します。

-walletPassword mypassword

OPatchAutoを使用した失敗したロールアウトの再開

Oracleホームのロールアウトに失敗して再開する場合、次のコマンドを使用します。

cd ORACLE_HOME/OPatch/auto/core/bin
opatchauto.sh resume -session workflow_id -walletPassword password

次の表に、opatchauto resumeコマンドにおけるパラメータを示します。

パラメータ

説明

-session -workflow_id

ロールバックするワークフローのワークフローIDを指定します。

-wallet path

configWallet.shまたはconfigWallet.cmdを使用して作成されたウォレット・ディレクトリへのフルパス。次に例を示します。

-wallet $HOME/wallet

-walletPassword password

必要な場合、指定したウォレットのパスワード。次に例を示します。

-walletPassword mypassword

OPatchAutoを使用したロールアウトの回復

OPatchAutoを使用して、完了したワークフローを回復させるだけでなく、失敗または停止したロールアウトを回復させることができます。ロールアウトが失敗または停止した場合、OPatchAutoは最後に正常に完了した手順から回復を開始します。ロールアウトが完了すると、OPatchAutoは、ロールアウトするOracleホームとしてバックアップ済Oracleホームを使用して、新しいロールアウトを開始します。

次のコマンドを使用してロールアウトを回復します。

cd ORACLE_HOME/OPatch/auto/core/bin
opatchauto.sh rollback -session workflow_id -walletPassword password

次の表に、opatchauto rollbackコマンドにおけるパラメータを示します。

パラメータ

説明

-session -workflow_id

ロールバックするワークフローのワークフローIDを指定します。

-wallet path

configWallet.shまたはconfigWallet.cmdを使用して作成されたウォレット・ディレクトリへのフルパス。次に例を示します。

-wallet $HOME/wallet

-walletPassword password

必要な場合、指定したウォレットのパスワード。次に例を示します。

-walletPassword mypassword

WLSTを使用したワークフローの起動と監視

この項では、ワークフローを起動して管理対象サーバー、パーティションまたはリソース・グループを更新するのに使用できるWLSTコマンドについて説明し、様々なワークフロー(ロールアウト)シナリオを示すサンプルのWLSTスクリプトを提供します。

注意:

WLST rolloutOracleHomeまたはrolloutUpdateコマンドを使用して、Windowsベースのドメインの新しいOracleホームのロールアウトを起動する場合、ワークフローの一部として更新されるOracleホームからWLSTを実行することはできません。詳細は、「ZDTパッチ適用の制限」を参照してください

次のWLSTコマンドを使用して、サーバーの自動ローリング更新を実行します。これらのコマンドは、ターゲット・ドメインの管理サーバーから実行する必要があります。

- rolloutOracleHome — パッチが適用されたOracleホームを管理対象サーバーにロールアウトするか、管理対象サーバーを前のOracleホームに回復します。このコマンドで使用するパッチ適用済Oracleホームのアーカイブは、opatchauto、またはcopyBinaryおよびpasteBinaryコマンドのいずれかを使用して作成されたものである可能性があります。

- rolloutJavaHome — 新しいJavaバージョンを使用するように管理サーバーを更新します。

- rolloutUpdate — パッチが適用されたOracleホームと新しいJavaバージョンを使用するように管理サーバーを更新します。このコマンドで使用するパッチ適用済Oracleホームのアーカイブは、opatchauto、またはcopyBinaryおよびpasteBinaryコマンドのいずれかを使用して作成されたものである可能性があります。

- rolloutApplications — 管理対象サーバー、パーティションまたはリソース・グループで実行されている、指定されたアプリケーションを更新します。

注意:

ロールアウトのコマンドでWindowsのパスを指定する場合、スラッシュのかわりにバックスラッシュを使用する必要があります。不要なエラーを避けるため、必ずバックスラッシュをエスケープするようにしてください。(たとえば、C:\\myhome\\files\\apps.json)。詳細は、『WebLogic Scripting Toolの理解』のWLSTコマンドの構文に関する項を参照してください。

これらのいずれかのWLSTコマンドを実行するときには、コマンドによって、更新する必要のあるサーバー、およびその順序が決定され、それらを安全に更新するパッチ適用ワークフローが作成されます。このワークフローには、次のことが含まれます。

- 管理対象サーバー、パーティションまたはリソース・グループを1つずつ正常にシャットダウン。これには、現在ADMINまたはSTANDBYモードの管理対象サーバーは含まれません。migrationPropertiesオプションがロールアウト・コマンドに含まれている場合、これにはシングルトン・サービスの移行が含まれます。パーティションまたはリソース・グループへのアプリケーション更新のロールアウトでは、ADMINモードおよびSTANDBYモードはサポートされていません。

- Oracleホーム・ディレクトリの置換(必要な場合)

- Javaホーム・ディレクトリの置換(必要な場合)

- アプリケーション・ディレクトリの置換(必要な場合)

- ノードでのノード・マネージャの再起動

- ノードでの管理対象サーバーの再起動

表3-1では、WLSTrolloutコマンドで使用可能なパラメータを示します。

表3-1 WLSTロールアウト・コマンドの引数

引数

説明

target

すべてのロールアウト・コマンドに必須です。

更新に含める管理対象サーバー、パーティションまたはリソース・グループを指定します。targetは次のいずれかです。

partition_name — 特定のパーティションへのアプリケーション更新をロールアウトする場合は、rolloutApplicationsコマンドにおいて、パーティション名、またはパーティション名のカンマ区切りリストを指定します。ターゲットとして指定するパーティションはアプリケーション更新JSONファイル内で指定したのと同じパーティションである必要があることに注意してください。

domain_name — ドメイン内の管理サーバーおよびすべての管理対象サーバーを更新する場合に、ターゲットとしてドメイン名を指定します。リソース・グループへのアプリケーション更新をロールアウトする場合は、rolloutApplicationsコマンドにおいて、ターゲットとしてドメイン名を指定する必要もあります。また、リソース・グループへのアプリケーション更新をロールアウトする場合は、アプリケーション更新JSONファイルでリソース・グループ・テンプレート名を指定する必要もあります。

clusters — 特定のクラスタ内のすべての管理対象サーバーを更新し、それ以外のクラスタの管理対象サーバーは更新しない場合、クラスタ名、またはクラスタ名のカンマ区切りリストを指定します。

servers — 該当する管理対象サーバーのみを更新する場合、サーバー名、またはサーバー名のカンマ区切りリストを指定します。指定するサーバーはクラスタの一部である必要があります。クラスタ化されていないサーバーは指定できません。

注意: 通常、管理サーバーの更新時にのみ、サーバー・ターゲットを指定する必要があります。個々の管理対象サーバーの更新は、セッションが維持されずに、ユーザーの停止時間を回避できない可能性があるため、ほとんどの場合でお薦めできません。ただし、安全に管理対象サーバー・ターゲットを指定できるような状況として、1つ以上の新しい管理対象サーバーを追加してあり、それらがその他の管理対象サーバーと同じJavaバージョンではない場合があります。

rolloutOracleHome

rolloutOracleHomeコマンドに対してのみ適用され、必須です。

ロールアウトするOracleホームのアーカイブ(JARファイル)またはローカルのOracleホーム・ディレクトリを指定し、その結果、既存のOracleホームを置き換えます。

backupOracleHome

rolloutOracleHomeコマンドに対してのみ適用され、必須です。

既存のOracleホームの移動先となるディレクトリのフルパスを指定します。これにより、元のOracleホームの名前が効率的に変更されます。たとえば、元のOracleホームが/u01/Oracle_Homeであり、このパラメータに/u01/Oracle_Home_backupを指定すると、/u01/Oracle_Homeは/u01/Oracle_Home_backupに移動(名前変更)されます。

isRollback

オプション。rolloutOracleHomeおよびrolloutUpdateコマンドにのみ適用されます。

javaHome

rolloutJavaHomeコマンドには必須であり、このコマンドに対して適用されます。オプションで、この引数がrolloutUpdateコマンドに必要な場合があります。

使用する新しいJavaホームの場所を指定します。

applicationProperties

rolloutApplicationsコマンドには必須であり、このコマンド対して適用されます。オプションで、この引数がrolloutUpdateコマンドに必要な場合があります。

1つ以上のアプリケーション名、アプリケーション・アーカイブの場所およびアプリケーション・バックアップの場所を定義するJSONファイルへのフルパスを指定します。

options

次のオプションをロールアウト・コマンドに含めることができます。

- isDryRun — TRUEの場合、ワークフロー操作は評価されますが実行されません。デフォルトはFALSEです。

- autoRevertOnFailure — TRUEの場合、ワークフロー操作は失敗時に自動的に回復されます。FALSEの場合、ワークフロー操作は失敗時に停止し、ユーザーが再開または回復できます。デフォルトはTRUEです。

- isSessionCompatible — このオプションは、ロールアウトがセッション処理に影響を与えるかどうかにかかわらず、ロールアウト時間に影響するため、すべてのrolloutコマンドに適用されます。
デフォルトはFALSEで、クラスタ内で最後に更新されるサーバーは、すべての既存のセッションの完了を待機することを意味します。これにより、まだ既存のバージョンで実行されている管理対象サーバーによって処理される必要のあるセッションは、クラスタ内の互換サーバーを使用して処理されることが保証されます。

TRUEに設定されている場合は、既存バージョンと新規バージョンとの間でサーバーのセッション状態が完全に互換していることを示します。したがって、クラスタ内で更新順序が最後の管理対象サーバーは、既存のセッションがすべて完了するのを待機せずに停止します。

セッション状態が同一であることが保証されないかぎり、これをFALSEに設定することをお薦めします。これにより、セッション完了の待機が原因でロールアウトに時間がかかる可能性があります。

注意: WebLogic Serverにおけるシリアライゼーションおよびデシリアライゼーションは、Javaのシリアライゼーションおよびデシリアライゼーションとは若干異なります。したがって、クラスにフィールドを追加すると、セッションが新しいバージョンのサーバーとの互換性を失い、既存バージョンのサーバーがクラスを処理する必要が生じる場合があります。たとえば、UserクラスにInformationなどのフィールドを追加すると、バージョン間でセッションの互換性が失われます。

- migrationProperties — ロールアウト中に実行されるシングルトン・サービス移行を定義するJSONファイルへのフルパス。このファイルおよびサービス移行の作成の詳細は、「シングルトン・サービスへの移行の準備」を参照してください

- shutdownTimeout — WLSTがサーバーの強制的なシャットダウンの前に、正常なシャットダウンを待機する時間(秒)。サーバーの強制的なシャットダウンは、セッション・データや処理中のトランザクションが失われるなどの、好ましくない結果を引き起こす可能性があります。1秒よりも小さい値は無視されます。
isSessionCompatibleがTRUEに設定されている場合、shutdownTimeoutオプションはデフォルトでゼロに設定され、WLSTはサーバーが正常にシャットダウンするのを無期限に待機します。

isSessionCompatibleがFALSEに設定されている場合、ユーザーはshutdownTimeoutオプションの値を指定する必要があります。代表的なアプリケーションに完了のために多くの時間を与える値を指定することをお薦めします。アプリケーションによって動作は様々であるため、この値はユーザーが決定する必要があります。

- DelayBetweenNodes — このオプションを使用して、あるノードでサーバーがシャットダウンされてからワークフロー内の次のノードでサーバーがシャットダウンされるまでの間の待機秒数を指定します。この遅延によって、次のことが可能になります。

- 最初のノードのサーバーを再起動してクラスタに参加させる

- ロード・バランサによりトラフィックを均等に分散する

- 次のノードでのサーバーのシャットダウンが開始する前に、遅い(遅延)ステートフル・セッションBeanクライアントにリクエストの作成を継続させる

指定しない場合、この値は60秒にデフォルト設定されます。遅延ステートフル・セッションBeanクライアントについて考慮しなければ、このオプションを含めて、より低い値に設定することができます。

- coherenceServiceHATarget — サーバーのシャットダウン前に達する必要がある、管理対象Coherenceサーバー上のCoherenceサービスの高可用性(HA)ステータスを指定するには、このオプションを使用します。ZDTワークフローでは、指定したステータスにすべてのCoherenceサービスが達するまで確認および待機します。ロールアウト・ワークフローでは、HAステータスに達するまで待機することで、キャッシュ・データの損失を回避できます。有効な値は、none、machine-safeおよびnode-safeです。通常は値machine-safeをお薦めします。これは、ロールアウト・プロセスの間のマシン損失によってデータ損失がもたらされないようにします。値node-safeは、単一Coherenceノードに対する損失によってデータ損失がもたらされないようにします。

- coherenceServiceHAWaitTimeout — ワークフローでのCoherence HAステータスのタスクを待機する時間を指定するには、このオプションを使用します。指定時間内にHAステータスに達した場合、タスクはタイムアウトになります。指定時間内にHAステータスに達するとすぐに、タスクが完了し、管理対象Coherenceサーバーがシャットダウンされます。デフォルト値は60秒です。

WLSTを使用してワークフローの進行状況を監視することもできます。詳細は、「ワークフローの進行状況の監視」を参照してください

新しいOracleホームのロールアウト

次のタスクのいずれかを実行するだけの場合は、rolloutOracleHomeコマンドを使用します。

- パッチが適用されたOracleホームを使用するように管理サーバーを更新します。

- パッチが適用されたOracleホームを使用するようにドメイン全体(管理サーバーおよびクラスタ化された管理対象サーバー)を更新します。

- パッチが適用されたOracleホームを使用するように、クラスタ化された管理対象サーバーを更新します。

- 以前のパッチ未適用のOracleホームを使用するように管理サーバー、クラスタ化された管理対象サーバーまたはドメインの更新を取り消します。

rolloutOracleHomeの構文は次のとおりです。

rolloutOracleHome(target, rolloutOracleHome, backupOracleHome, [isRollback], [options])

このコマンドはisDryRun、autoRevertOnFailureおよびisSessionCompatibleオプションをサポートします。これらのオプションの詳細は、WLSTを使用したワークフローの起動と監視を参照してください。

次の例では、新しいOracleホームをドメインmydomainにロールアウトする方法を示します。パッチ適用済のOracleホームのJARファイルは、/net/wls/wls_patched.jarにあります。元のOracleホームは/u01/Oracle_Home_backupに移動(名前変更)されます。このプロセスは失敗しても自動的に回復されません。

connect('adminname', 'adminpassword', 't3://hostname:port')
domain='/domains/mydomain'
progress=rolloutOracleHome(domain, '/net/wls/wls_patched.jar',
'/u01/Oracle_Home_backup', autoRevertOnFailure=FALSE)

注意:
新しいOracleホームのロールアウト時は、rolloutOracleHomeコマンドでのローカルOracleホーム・ディレクトリの指定はサポートされていません。詳細は、「ZDTパッチ適用の制限」を参照してください

Javaバージョンの更新

次のタスクのいずれかを実行するだけの場合は、rolloutJavaHomeコマンドを使用します。

- 新しいJavaバージョンを使用するように管理サーバーを更新します。

- 新しいJavaバージョンを使用するようにドメイン全体(管理サーバーおよび管理対象サーバー)を更新します。

- 新しいJavaバージョンを使用するように管理対象サーバーを更新します。

- 以前のJavaバージョンを使用するように管理サーバー、管理対象サーバーまたはドメインを回復します。

rolloutJavaHomeの構文は次のとおりです。

rolloutJavaHome(target, javaHome, [options])

このコマンドはisDryRunおよびautoRevertOnFailureオプションをサポートします。これらのオプションの詳細は、WLSTを使用したワークフローの起動と監視を参照してください。

次の例では、新しいJavaホームをクラスタCluster1、Cluster2、Cluster3にロールアウトする方法を示します。新しいJavaホームの場所は/u01/jdk1.8.0_50です。この例ではautoRevertOnFailureオプションは含まれていないため、ワークフローはプロセスが失敗すると自動的に回復します。

connect('adminname', 'adminpassword', 't3://hostname:port')
clusters='Cluster1,Cluster2,Cluster3'
progress=rolloutJavaHome(clusters, '/u01/jdk1.8.0_50')

OracleホームおよびJavaバージョンの両方の更新

次のタスクのいずれかを実行するだけの場合は、rolloutUpdateコマンドを使用します。

- パッチが適用されたOracleホームと新しいJavaバージョンの両方を使用するように管理サーバーを更新します。

- パッチが適用されたOracleホームと新しいJavaバージョンの両方を使用するようにドメイン全体(管理サーバーおよびクラスタ化された管理対象サーバー)を更新します。

- パッチが適用されたOracleホームと新しいJavaバージョンの両方を使用するように管理対象サーバーを更新します。

- 以前のOracleホームおよび以前のJavaバージョンに管理サーバー、管理対象サーバーまたはドメインを回復します。

rolloutUpdateの構文は次のとおりです。

rolloutUpdate(target, rolloutOracleHome, backupOracleHome, [isRollback], [javaHome], [options])

このコマンドはisDryRun、autoRevertOnFailureおよびisSessionCompatibleオプションをサポートします。これらのオプションの詳細は、WLSTを使用したワークフローの起動と監視を参照してください。

次の例では、新しいOracleホームおよび新しいJavaホームを管理サーバーにロールアウトする方法を示します。パッチ適用済のOracleホームのJARファイルは、/net/wls/wls_patched.jarにあります。元のOracleホームは/u01/Oracle_Home_backupに移動(名前変更)されます。新しいJavaホームの場所は/u01/jdk1.8.0_50です。この例ではautoRevertOnFailureオプションは含まれていないため、ワークフローはプロセスが失敗すると自動的に回復します。

connect('adminname', 'adminpassword', 't3://hostname:port')
server='AdminServer'
progress=rolloutUpdate(server, '/net/wls/wls_patched.jar',
'/u01/Oracle_Home_backup', '/u01/jdk1.8.0_50')

更新されたアプリケーションのロールアウト

次のタスクのいずれかを実行する場合は、rolloutApplicationsコマンドを使用します。

- 1つ以上のアプリケーションの新しいバージョンを使用するように管理対象サーバーを更新します

- 1つ以上のアプリケーションについて以前のバージョンに管理対象サーバーを回復します。

- 1つ以上のアプリケーションの新しいバージョンを使用するようにパーティションを更新します。

- 1つ以上のアプリケーションの新しいバージョンを使用するようにリソース・グループを更新します

rolloutApplicationsの構文は次のとおりです。

rolloutApplications(target, applicationProperties, [options])

このコマンドはisDryRun、autoRevertOnFailureおよびisSessionCompatibleオプションをサポートします。これらのオプションの詳細は、WLSTを使用したワークフローの起動と監視を参照してください。

次の例では、JSON形式のアプリケーション・プロパティ・ファイル/u01/scratch/app_update.jsonに定義されたアプリケーションをUNIXシステム上のすべてのクラスタCluster1、Cluster2、Cluster3にロールアウトする方法を示します。

connect('adminname', 'adminpassword', 't3://hostname:port')
clusters='Cluster1,Cluster2,Cluster3'
progress=rolloutApplications(clusters, '/u01/scratch/app_update.json')

前のOracleホーム、Javaホームまたはアプリケーションへの回復

ロールアウトが正常に完了した後に、前のOracleホーム、Javaホームまたはアプリケーション・バージョンにロールバックする場合は、次の2つの手順を実行してロールバック操作を完了する必要があります。

- rolloutUpdateコマンドを使用して、前のOracleホームおよびJavaホームにロールバックします。ただし、rolloutUpdateコマンドを実行してロールバックする前に、次の制限事項に留意する必要があります。

- ロールアウトするOracleホーム・ディレクトリとしてバックアップ済Oracleホームを指定する必要があります。このディレクトリは、前のロールアウトからのバックアップ・ディレクトリである必要があります。

- ロールバック先のOracleホーム・ディレクトリとしてバックアップ済Oracleホーム・ディレクトリを指定した後は、そのコマンドで新しいJavaホームを指定しないでください。Javaホームは、ロールバック先として指定した前のOracleホームで使用されていた、元のJavaホームに自動的にロールバックされます。

- rolloutApplicationsコマンドを使用して、jsonファイルで古いアプリケーション・アーカイブを指定することで、前のアプリケーション・バージョンにロールバックします。このコマンドの使用の詳細は、更新されたアプリケーションのロールアウトを参照してください 。

次の例では、前のOracleホーム、Javaホームおよびアプリケーションにロールバックする方法を示します。この例では、myDomainはロールバック先となるドメインの名前、/pathto/unpatchedOracleHomeBackup/は前のロールアウトからのバックアップOracleホーム・ディレクトリの場所、/pathto/unpatchedOracleHomeBackup1/は既存Oracleホームの移動先となるディレクトリのパスです。ロールバック操作を可能にするには、例で示すように、isRollbackパラメータをtrueに設定する必要があります。

rolloutUpdate('myDomain', '/pathto/unpatchedOracleHomeBackup/', '/pathto/unpatchedOracleHomeBackup1/', 'true')

サーバーまたはパーティションのローリング再起動の開始

次のタスクのいずれかを実行する場合は、rollingRestartコマンドを使用します。

- ドメイン内のすべてのサーバーのローリング再起動の開始

- 特定のクラスタ(1つまたは複数)内のすべてのサーバーのローリング再起動の開始

- サーバー上のクラスタ内のすべてのパーティションのローリング再起動の開始

パーティションのローリング再起動では、各サーバー上のクラスタ内のパーティションが、そのクラスタまたはサーバーを超えてその他のパーティションに影響を与えることのない方法で、順次再起動されます。WebLogic Server管理者およびパーティション管理者の両者が、サーバー上のパーティションのローリング再起動を実行できます。

rollingRestartの構文は次のとおりです。

rolloutRestart(target, [options])

次の例では、Cluster1およびCluster2内のすべてのサーバーのローリング再起動を実行する方法を示します。

connect('adminname', 'adminpassword', 't3://hostname:port')
clusters='Cluster1,Cluster2'
progress=rollingRestart(clusters)

ワークフローの進行状況の監視

各ロールアウト・コマンドは、ワークフローの現在のステータスをポーリングするのに使用できるWorkFlowTaskRuntimeMBeanを返します。ロールアウトの進行状況を監視するには、rolloutコマンドを次の形式で使用します。

progress=rollout_command

たとえば、新しいOracleホームのロールアウトの場合は、このコマンドを使用します。

progress=rolloutOracleHome(DomainA, '/net/patched/wls1221p.jar',
'/net/backups/wls1221', autoRevertOnFailure=FALSE)

次に、WorkflowTaskRuntimeMBeanのメソッドを使用してワークフローに関する情報を返すことができます。詳細は、Oracle WebLogic Server MBeanリファレンスのWorkflowTaskRuntimeMBeanを参照してください。いくつか例を挙げます。

progress.getWorkflowId()

ワークフローのIDを返します。

progress.getProgressString()
'Workflow wf0011 Running: 13/36'

現在のワークフローの進行状況に関する情報を含む判読可能なメッセージを返します。この例では、ワークフローwf0011が現在実行中であり、36個のワークフロー・コマンドのうち13個が完了しています。

progress.getStatus()
STARTED

ワークフローの現在のステータスを返します。これはSTARTED、SUCCESS、RETRY、REVERTING、FAIL、REVERTED、REVERT_FAIL、CANCELEDまたはREVERT_CANCELEDのいずれかです。

次のPythonスクリプト・セグメントは、進行状況オブジェクトを使用して、ワークフローを監視し、ロールアウト・タスクの進行状況を出力する1つの方法を示します。スクリプト後のサンプルの出力を示します。

# Print the starting information
rolloutName = progress.getName()
startTime = progress.getStartTime()
print "Started rollout task \"" + rolloutName + "\" at " + str(startTime)

# Check the state every 2 minutes
domainRuntime()
cd('RolloutService/rollout-service/ActiveWorkflows')
cd(progress.getWorkflowId())
while(get('Running')==1):
progressString = progress.getProgressString()
print progressString
time.sleep(120)

# Print the ending information
endTime = progress.getEndTime()
state = progress.getState()
print "rollout \"" + rolloutName + "\" finished with state

Output
Started rollout task "Domain1Rollout" at 2014-07-22 07:29:06.528971
Running step 1 of 9
Running step 2 of 9
Running step 3 of 9
Running step 4 of 9
Running step 5 of 9
Running step 6 of 9
Running step 7 of 9
Running step 8 of 9
Running step 9 of 9
rollout "Domain1Rollout" finished with state "SUCCESS" at
2014-07-22 07:47:15.538299

停止したワークフローの実行、回復および再開

ワークフローは次の理由で実行または回復のどちらの方向でも停止することができます。

- ワークフローが実行中に失敗し、autoRevertOnFailureオプションがFALSEに設定されている

- ワークフローが手動でキャンセルされた

- 回復操作中にリカバリ不能エラーが発生した。

ワークフローが停止した場合は、手動でエラーを解決できます。その後、RolloutServiceRuntimeMBeanで次のメソッドを使用することで、実行または回復を続行するよう、ワークフローを設定できます。

メソッド

説明

executeWorkflow(WorkflowTaskRuntimeMBean)

再開できる進行状況オブジェクトを取得し、実行方向で再開します。ワークフローで最後の正常な操作が実行だった場合、実行は次の実行ステップから再開されます。ワークフローで最後の正常な操作が回復だった場合、実行はその回復ステップを実行することにより再開されます。

revertWorkflow(WorkflowTaskRuntimeMBean)

再開できる進行状況オブジェクトを取得し、回復方向で再開します。ワークフローで最後の正常な操作が実行だった場合、回復はそのステップから再開されます。ワークフローで最後の正常な操作が回復だった場合、回復は回復シーケンスでその次のステップを回復することにより再開されます。

canResume(WorkflowTaskRuntimeMBean)

ワークフローが完了する前に停止し、いずれの方向にも現在実行中ではない場合、trueを返します。この状態のワークフローは、実行または回復のいずれの方向にも再開できます。

ワークフローに役立つWLSTコマンド

この項では、役に立つ可能性のあるWLSTコマンドをいくつか説明します。

- 完了したワークフローのリストを取得するには:

wls:/domain_name/domainRuntime/RolloutService/rollout-service> completeWfs=
cmo.getCompleteWorkflows()

- アクティブなワークフローのリストを取得するには:

wls:/domain_name/domainRuntime/RolloutService/rollout-service> activeWfs =
cmo.getActiveWorkflows()

- IDでワークフローを検索しその状態を取得するには:

wls:/domain_name/domainRuntime/RolloutService/rollout-service>
progress=cmo.getWorkflowTask('workflow_id')
wls:/Domain1221/domainRuntime/RolloutService/rollout-service> progress.getStatus()

- 実行中のワークフローを取り消すには:

wls:/domain_name/domainRuntime/RolloutService/rollout-service>
progress=cmo.getWorkflowTask('workflow_id')
wls:/domain_name/domainRuntime/RolloutService/rollout-service> progress.cancel()

- 完了したワークフローを削除するには:

wls:/domain_name/domainRuntime/RolloutService/rollout-service> cmo.deleteWorkflow('workflow_id')

サンプルのWLSTスクリプト

この項には、1つのサービス移行でcluster1という名前のクラスタ内のすべてのサーバーのローリング再起動を実行する方法を示すサンプルのWLSTスクリプトが含まれます。このスクリプトでは、次の引数が定義されています。

- username — WebLogic Server管理者のユーザー名

- password — WebLogic Server管理者のパスワード

- adminURL — ドメインの管理サーバーのホスト名とポート番号。

- target — 操作のターゲット。表3-1を参照してください。

- options — 操作のロールアウト・オプション。表3-1を参照してください。

次の例では、ロールアウト操作のためのサンプルWLSTスクリプトを示します。

import sys, socket
import os
import time
from java.util import Date
from java.text import SimpleDateFormat

argUsername = sys.argv[1]
argPassword = sys.argv[2]
argAdminURL = sys.argv[3]
argTarget = sys.argv[4]
argTarget = sys.argv[5]

try:
connect(argUsername, argPassword, argAdminURL)
progress = rollingRestart(argTarget, argTarget)
lastProgressString = ""

progressString=progress.getProgressString()
# for testing progressString="12 / 12"
steps=progressString.split('/')

while not (steps[0].strip() == steps[1].strip()):
if not (progressString == lastProgressString):
print "Completed step " + steps[0].strip() + " of " + steps[1].strip()
lastProgressString = progressString

java.lang.Thread.sleep(1000)

progressString=progress.getProgressString()
steps=progressString.split('/')
if(len(steps) == 1):
print steps[0]
break;

if(len(steps) == 2):
print "Completed step " + steps[0].strip() + " of " + steps[1].strip()

t = Date()
endTime=SimpleDateFormat("hh:mm:ss").format(t)

print ""
print "RolloutDirectory task finished at " + endTime
print ""

state = progress.getStatus()
error = progress.getError()

stateString = '%s' % state
if stateString != 'SUCCESS':
#msg = 'State is %s and error is: %s' % (state,error)
msg = "State is: " + state
raise(msg)
elif error is not None:
msg = "Error not null for state: " + state
print msg
#raise("Error not null for state: %s and error is: %s" + (state,error))
raise(error)
except Exception, e:
e.printStackTrace()
dumpStack()
raise("Rollout failed")

exit()

このスクリプトを実行するには、Python (.py)ファイルとして保存してから、これと同様にコマンドを入力します。WindowsでWLSTを実行している場合は、WindowsでのWLSTの使用に関する重要な情報について、ZDTパッチ適用の制限を参照してください。

$ORACLE_HOME/oracle_common/common/bin/wlst.sh
/u01/scripts/rollout/RollingRestart.py username password
t3://hostname:port cluster1 "migrationProperties=/u01/json/mig.txt"

WebLogic Server管理コンソールを使用したワークフローの作成と監視

この項では、パッチが適用されたOracleホーム、新しいJavaバージョン、新しいアプリケーション・バージョンをロールアウトするパッチ適用ワークフロー、またはこれらのタスクを組み合せたパッチ適用ワークフローの作成と監視の方法について説明します。内容は次のとおりです。

- WebLogic Server管理コンソールでのZDTワークフロー機能へのアクセス

- ドメイン、クラスタまたはサーバー用の新しいワークフローの作成

- ワークフローの監視と管理

- ワークフローのステータス

- ワークフローのロギング

WebLogic Server管理コンソールでのZDTワークフロー機能へのアクセス

WebLogic Server管理コンソールでZDTワークフロー機能へアクセスするには、次の手順を実行します。

1. WebLogic Server管理コンソールで、「ドメイン構造」の下のドメイン名をクリックします。

2. 「domain_nameの設定」ページで、「ZDT制御」タブを選択します。

これには4つのタブ(「ドメイン」、「クラスタ」、「サーバー」および「ワークフロー進行状況」)が表示され、ここからすべてのワークフロー関連のタスクを管理できます。

ドメイン、クラスタまたはサーバー用の新しいワークフローの作成

ワークフローを作成して、1つのドメイン内のすべてのサーバー、1つ以上のクラスタ内のすべてのサーバー、または選択したサーバーのみにロールアウトできます。ワークフローは、新しいJavaバージョンのロールアウト、新しいパッチ適用済Oracleホームのロールアウト、1つ以上の更新済アプリケーションのロールアウト、またはこれらの任意の組合せに対応しています。パッチ適用ワークフローを作成して、前のOracleホーム、Javaホームまたはアプリケーション・バージョンにロールバックするか、ワークフローを作成して、サーバーのローリング再起動を実行することもできます。

この手順を実行する前に、WebLogic Server管理コンソールでのZDTワークフロー機能へのアクセスで説明している「ZDT制御」タブにアクセスします。

新しいワークフローを作成するには、次の手順を実行します。

1. 次のいずれかのタブを選択します。

- ドメイン: 管理サーバー、およびドメイン内のすべてのクラスタ化されたサーバー用のワークフローを作成する場合に、このタブを選択します。

- クラスタ: 特定のクラスタ内のサーバー用のワークフローのみを作成する場合、このタブを選択します。

- サーバー: 特定のサーバーのワークフローのみを作成する場合、このタブを選択します。通常、このオプションは、次のような状況でのみ選択します。

- 管理サーバーは、ワークフローに含まれるサーバーのみ。

- 管理対象サーバーが、すでに更新済のその他の管理対象サーバーと同期が取れていない状況が存在する。たとえば、新しいサーバーをクラスタに追加したものの、そのサーバーはクラスタ内の他の管理対象サーバーよりも古いバージョンのJavaを使用している場合があります。

注意:

どうしても必要な場合以外には、「サーバー」タブを使用して個別の管理対象サーバーに更新を実行することはお薦めしません。個々の管理対象サーバーを更新する場合、セッションが維持されて停止時間が回避される保証はありません。

2. 「クラスタ」タブを選択した場合、ワークフローに含めるクラスタを選択します。選択したクラスタ内のすべてのサーバーがワークフローに含まれます。
「サーバー」タブを選択した場合、ワークフローに含めるサーバーを選択します。

3. 「パッチ」をクリックしてワークフロー・タスクを構成します。

4. 実行するロールアウト(またはロールバック)のタイプを選択します。

- Javaホーム: 単に別のJavaバージョンに変更する場合に選択します。

- Oracleホーム: 単に新しいOracleホームをロールアウトするか、以前のOracleホームにロールバックする場合に選択します。

- アプリケーション: 単に1つ以上の更新済アプリケーションをロールアウトするか、1つ以上の以前のアプリケーション・バージョンにロールバックする場合に選択します。

- すべての組合せ: Javaホーム、Oracleホームおよびアプリケーションの更新の任意の組合せをロールアウトまたはロールバックする場合に選択します。

- ローリング再起動: 選択したターゲットのローリング再起動を実行する場合に選択します。

5. 「次」をクリックします。
表示されるフィールドとオプションは、実行するロールアウトまたはロールバックのタイプに応じて異なります。

6. Javaホームを変更する場合、「Javaホーム」フィールドに変更先のJavaホームへのフルパスを入力します。次に例を示します。
UNIX

/jdks/jdk1.8.0_50

Windows

C:\jdks\jdk1.8.0_50

7. 新しいOracleホームをロールアウトするか、以前のOracleホームにロールバックする場合:

a. 「Oracleホームのロールアウト」に、JARアーカイブへのフルパスを入力します。前のOracleホームにロールバックしている場合のみ、ロールバック先となるOracleホームを含むローカル・ディレクトリへのパスを指定できます。前のOracleホームへのロールバックの詳細は、前のOracleホーム、Javaホームまたはアプリケーションへの回復を参照してください。

b. 「Oracleホームのバックアップ」に、現在のOracleホームをバックアップするディレクトリへのフルパスを入力します。たとえば、元のOracleホームが/u01/Oracle_Homeで、このフィールドに/u01/Oracle_Home_backupを指定すると、/u01/Oracle_Homeは/u01/Oracle_Home_backupに移動します(名前が変更されます)。

c. 以前のOracleホームにロールバックする場合、「ロールバック」チェック・ボックスを選択します。

8. 1つ以上の新しいアプリケーション・バージョンをロールアウトする場合、「アプリケーション・プロパティ」フィールドに、アプリケーションをアップグレードするために必要な情報が含まれるJSON形式のテキスト・ファイルへのフルパスを入力します。このフィールドの作成の詳細は、「アプリケーションの更新用JSONファイルの作成」を参照してください

9. パッチ適用ワークフローを実行する前にその評価のみを行う場合、「テスト実行」チェック・ボックスを選択します。

10. JTAまたはJMSなどのシングルトン・サービスを移行する場合は、ロールアウト時に、「移行プロパティ」フィールドに、移行情報を含むJSON形式のファイルのフルパスを入力します。このファイルの作成の詳細は、「シングルトン・サービスへの移行の準備」を参照してください

11. デフォルトで、「失敗時の自動回復」チェック・ボックスが選択済です。これにより、ワークフローの実行中に障害が発生した場合、パッチ適用操作によってすべての処理が自動的に回復されます。このチェック・ボックスの選択を解除すると、障害が発生してもパッチ適用は自動的に回復されません(操作は停止し、ユーザーが再開または回復操作をするまで待機します)。

12. 「セッション互換性」オプションは、クラスタで最後に更新されているサーバーが、そのサーバー上でセッションの完了を待機するかどうかを決定します。

- 選択されていない場合、クラスタ内の最後のサーバーはセッションの完了を待機します。これにより、まだ既存のバージョンで実行されている管理対象サーバーによって処理される必要のあるセッションは、クラスタ内の互換サーバーを使用して処理されることが保証されます。

- 選択されている場合は、既存バージョンと新規バージョンとの間でサーバーのセッション状態が完全に互換していることを示します。したがって、クラスタ内で更新順序が最後の管理対象サーバーは、既存のセッションがすべて完了するのを待機せずに停止します。

セッション状態が同一であることが保証されないかぎり、このオプションは選択しないことをお薦めします。これにより、セッション完了の待機が原因でロールアウトに時間がかかる可能性があります。デフォルトのセッション・タイムアウト値は1時間です。

注意:

WebLogic Serverにおけるシリアライゼーションおよびデシリアライゼーションは、Javaのシリアライゼーションおよびデシリアライゼーションとは若干異なります。したがって、クラスにフィールドを追加すると、セッションが新しいバージョンのサーバーとの互換性を失い、既存バージョンのサーバーがクラスを処理する必要が生じる場合があります。たとえば、UserクラスにInformationなどのフィールドを追加すると、バージョン間でセッションの互換性が失われます。

13. 「終了」をクリックしてパッチ適用ワークフローを開始します。
ワークフローが「ワークフロー進行状況」表に追加されます。

ワークフローが開始されると、ワークフローの監視と管理で説明されているように、「ワークフロー進行状況」ページからその進行状況を監視および管理できます。

ワークフローの監視と管理

この項では、すべての実行中および完了したワークフローの進行状況を監視および管理する方法について説明します。

この手順を実行する前に、まだ実行していなければ、WebLogic Server管理コンソールでのZDTワークフロー機能へのアクセスで説明している、ZDTパッチ適用タブにアクセスします。

ワークフローを監視および管理するには、「ワークフロー進行状況」タブを選択します。このページには、次の2つの表があります。

- 「進行中ワークフロー」表に、まだ完了していない(アクティブな)すべてのワークフロー(つまり実行、回復、停止、取消、または失敗状態にある)が表示されます。そのステータスに応じて、アクティブなワークフローに様々なアクションを実行できます。

- 「取消」によって、STARTED、REVERTINGまたはRETRY状態のワークフローを取り消すことができます。
1つ以上のワークフローを取り消すには、取り消すワークフローのチェック・ボックスを選択して「取消」をクリックします。次に、「回復」をクリックしてワークフローを回復する、または「実行」をクリックして再開することができます。

- 「実行」によって、CANCELED、REVERT_CANCELED、FAILまたはREVERT_FAIL状態のワークフローを実行できます。
1つ以上の停止した(取り消された)ワークフローを実行するには、再開するワークフローのチェック・ボックスを選択して「実行」をクリックします。ワークフローは、正常に完了した最後のステップの後のステップから実行を継続します。

- 「回復」によって、CANCELED、REVERT_CANCELED、FAILまたはREVERT_FAIL状態のワークフローを回復できます。
1つ以上の停止した(取り消された)ワークフローを回復するには、回復するワークフローのチェック・ボックスを選択して「回復」をクリックします。ワークフローは回復し、正常に完了した最後のステップから開始します。

- 「削除」によって、CANCELED、REVERT_CANCELED、FAILまたはREVERT_FAIL状態のワークフローを削除できます。一度に削除できるのはワークフロー1つのみです。
ワークフローを削除するには、削除するワークフローのチェック・ボックスを選択して「削除」をクリックします。

- 「完了済ワークフロー」表に、完了したすべてのワークフローが表示されます。この表は、ワークフローが完了した時点に基づいてソートされ、表の一番上に最近完了したワークフローが表示されます。
完了したワークフローを削除するには、1つ以上のワークフローを選択して「削除」をクリックします。

これらの表から、ワークフローのステータスの詳細を表示することもできます。これを行うには、「ワークフローID」列のワークフローIDをクリックします。詳細は、ワークフローの詳細の表示を参照してください。ワークフロー・ステータスの詳細は、ワークフローのステータスを参照してください。

ワークフローの詳細の表示

この項では、アクティブなまたは完了したワークフローの詳細の表示方法について説明し、ワークフローに対して表示される情報についても説明します。

ワークフローの詳細を表示するには、「ワークフロー進行状況」ページの「進行中ワークフロー」または「完了済ワークフロー」表のいずれかの「ワークフローID」列のワークフローID (たとえばwf00071)をクリックします。ページには、次の表に示す情報が表示されます。

フィールド

説明

ワークフローID

作成時に自動的に割り当てられたワークフロー

タイプ

ワークフローのタイプで、次のいずれかです。

- rolloutJavaHome: 異なるJavaホーム・バージョンにロールアウトまたはロールバックしています。

- rolloutOracleHome: 異なるOracleホーム・バージョンにロールアウトまたはロールバックしています。

- rolloutApplications: 1つ以上の新しいアプリケーション・バージョンをロールアウトしているか、1つ以上の以前のアプリケーション・バージョンにロールバックしています。

- rolloutUpdate: Javaホーム、Oracleホームおよびアプリケーション・バージョンの任意の組合せをロールアウトまたはロールバックしています。

ターゲット

ワークフローがターゲット指定されるサーバーで、次のいずれかです。

- Domain: ワークフローは管理サーバーを含む、ドメイン内のすべての適格なサーバーにターゲット指定されています。

- クラスタ名のカンマ区切りリスト: ワークフローはリストされたクラスタ内のすべての適格なサーバーにターゲット指定されています。

- サーバーのカンマ区切りリスト: ワークフローはリストされたサーバーにのみターゲット指定されています。

ステータス

ワークフローの現在のステータス。詳細は、ワークフローのステータスを参照してください。

再開可能

ワークフローが再開可能または回復可能かどうかを示します。falseの場合、ワークフローで「実行」または「回復」機能を使用できません。

# 完了コマンド

現在完了しているワークフロー・コマンドの数

# 合計コマンド

ワークフローを完了するために実行が必要なワークフロー内のコマンドの合計数

進行状況の文字列

次のような、ワークフローの進行状況の詳細メッセージ。

ワークフローwf0008は正常に終了しました。36ステップが完了しました。

次の実行ステップ

ワークフローがアクティブなままで回復中でない場合、このフィールドには、現在のコマンドが完了すると実行される、次のコマンドが表示されます。

次の回復ステップ

ワークフローがアクティブなままで回復中の場合、このフィールドには、現在のコマンドが完了すると回復プロセスで実行される、次のコマンドが表示されます。

開始時刻

ワークフローが起動した時刻

終了時刻

ワークフローが完了すると、このフィールドには、その完了時刻が表示されます。

例外

ワークフローが失敗すると、このフィールドには、失敗したときに発生した例外が表示されます。

詳細

矢印をクリックして「詳細」セクションを展開します。ここには現在の時間までにワークフローで実行されたすべてのステップが表示されます。ワークフローが完了すると、このセクションには、ワークフローにより完了したすべてのコマンドがリストされます。

サーバーのステータスの表示

「サーバー」ページから、ワークフローの実行前後およびワークフローが進行中のすべてのサーバーの現在のステータスを表示できます。「サーバー」タブをクリックすると、ドメイン内の各サーバーのワークフロー関連の情報を表示できます。「サーバー」表の列、および表に追加できる列の詳細は、管理コンソール・オンライン・ヘルプのサーバーのパッチ適用ステータスの表示を参照してください

ワークフローが実行中の場合、このページの情報を監視およびリフレッシュして、各サーバーの最新のステータスを取得できます。

クラスタのステータスの表示

「クラスタ」ページから、ワークフローの実行前後およびワークフローが進行中のドメイン内のすべてのクラスタの情報を表示できます。「クラスタ」表の列、および表に追加できる列の詳細は、管理コンソール・オンライン・ヘルプのクラスタのパッチ適用ステータスの表示を参照してください

ワークフローが実行中の場合、このページの情報を監視およびリフレッシュして、各クラスタの最新の情報を取得できます。

ワークフローのステータス

アクティブなワークフローのステータスは、次のいずれかです。

ステータス

説明

STARTED

ワークフローは開始されて現在実行中です。

RESUME

停止されたワークフローが再開されています。

REVERTING

失敗または停止されたワークフローが回復中です。

FAIL

ワークフローが完全に実行できませんでした。このステータスは、「失敗時の自動回復」オプションが開始時にワークフローに構成されていなかった場合にのみ現れます。

REVERTED

自動または手動で回復されたワークフローが正常に回復プロセスを完了しました。

REVERT_FAIL

自動または手動で回復されたワークフローが正常に回復できませんでした。

CANCELED

ワークフローが取り消されました(一時停止しました)。

REVERT_CANCELED

自動または手動で回復されたワークフローが取り消されました(一時停止しました)。

ワークフローのロギング

ロールアウトは一連のステップで構成されています。各ステップは、開始および終了時に、管理サーバー・ログにメッセージを記録します。ステップの回復、失敗または再試行の場合もメッセージが記録されます。管理サーバーのログの場所は次のとおりです

domain_home/servers/AdminServer/logs

ログ・ファイルのフィルタリング

ワークフローIDは、指定されたワークフローに関連するすべてのログ・メッセージに含まれています。指定されたワークフローに関連するメッセージで管理サーバーのログ・ファイルをフィルタするには、ワークフローIDを使用します。WebLogic Server管理コンソールからワークフローを起動した場合、「ZDT制御」>「ワークフロー進行状況」タブからワークフローIDを取得できます。WLSTから、次のコマンドを使用してワークフローIDを取得できます。

progress.getWorkflowId()

ログ・ファイルをフィルタリングするには、次のコマンドを入力します。

fgrep wf0001 domain_home/servers/AdminServer/logs/AdminServer.log

ログ・メッセージのフォーマット

ZDTパッチ適用のログ・メッセージは、次のようにフォーマットされます。

メッセージ・タイプ

メッセージの形式

ステップが実行を開始

Workflow workflowId is executing step name on target.

ステップが完了

Workflow workflowId successfully completed step name on target.

ステップが回復中

Workflow workflowId is reverting step name on target.

ステップが正常に回復済

Workflow workflowId successfully completed revert of step name on target.

ステップが再試行中

Workflow workflowId is retrying step name on target.

ステップが正常に完了できなかった

Workflow workflowId failed to complete step name on target.

ステップが例外のため正常に完了できなかった

Workflow workflowId failed to complete step name on target due to error exception.

ステップが正常に回復できなかった

Workflow workflowId failed to revert step name on target.

ステップが例外のため正常に回復できなかった

Workflow workflowId failed to revert step name on target due to error exception.

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。