| Oracle® Fusion Middlewareゼロ・ダウンタイム・パッチ適用ワークフローの管理 12c (12.2.1) E70053-01 |
|
 前 |
 次 |
この章では、作成できるワークフローのタイプ、パッチ適用ワークフローの処理方法、およびパッチ適用の回復方法を含む、ダウンタイムなしのパッチ適用の概要について説明します。
この章では次の項について説明します。
WebLogicダウンタイムなしのパッチ適用(ZDTパッチ適用)は、アプリケーションによるリクエストのサービスの続行を可能にしながら、ホーム外パッチ適用のロールアウトを自動化し、ドメイン間で更新します。パッチ適用手法を定義したら、WLSTまたはWebLogic Server管理コンソールのいずれかを使用して、ドメイン内の一部またはすべてのサーバー間で更新のロールアウトを編成できます。
WebLogic Serverはバージョン9.2からローリング・アップグレードをサポートしていますが、そのプロセスは常に手動でした。ZDTパッチ適用は、定義するワークフローを使用することによりこのプロセスを自動化します。ドメイン内の任意の数のノードを、ほとんどまたはまったく手動介入なしで、パッチ適用または更新できます。変更は一度に1つのノードにロールアウトされ、そのノードが更新されるまで、Oracle Traffic Directorのようなロード・バランサが受信トラフィックを残りのノードにリダイレクトすることができます。
ZDTパッチ適用では次のタスクがサポートされます。これらのタスクのいずれかを実行するワークフローを作成できます。Oracleホームの更新、Javaバージョンの更新およびアプリケーションの更新の任意の組合せを実行するワークフローを作成することもできます。
パッチが適用されたOracleホームへのサーバーの移動—ワークフローは管理サーバーまたはクラスタあるいはその両方をOPatchを使用してすでにパッチが適用された別のOracleホームに遷移します。
新しいJavaバージョンへの更新—新しくインストールされたJavaホームを使用するように、ワークフローは管理サーバーまたはクラスタあるいはその両方を更新します。
更新されたアプリケーションのデプロイ—ワークフローは更新されたアプリケーションを選択したクラスタにデプロイします。
サーバーのローリング再起動の実行—ワークフローは管理サーバーまたは選択したクラスタ内のサーバーあるいはその両方を安全に順次再起動し、それにはサーバーの正常なシャットダウンおよび再度の起動が含まれます。
パッチ適用ワークフローを作成する前に、各タスクに対し予備ステップをローリング再起動の例外を使用して完了する必要があります。詳細は、第2章「ダウンタイムなしのパッチ適用の準備」を参照してください。
ZDTパッチ適用ワークフローを使用して更新をロールアウトする場合、ロールアウトは、次のことを実行します。
該当する各ノードを介して体系的に順番に処理します
ロールアウトに含まれるノード上のサーバーを識別します
それらのサーバーを正常にシャットダウンします
パッチが適用されたOracleホームに切り替えるとき、次のことを実行します。
既存のOracleホームをバックアップ・ディレクトリにバックアップします
ノード・マネージャを呼び出して現在のOracleホームの内容を指定したOracleホームの内容に切り替えます。
新しいJavaバージョンに更新するとき、次のことを実行します。
Javaホームへの参照を含むドメインのOracleホームのすべてのスクリプトを、新しいJavaホームをポイントするように更新します
Javaホームへの参照を含むドメインのホーム・ディレクトリのすべてのスクリプトを、新しいJavaホームをポイントするように更新します。
新しいアプリケーション・バージョンに更新するとき、次のことを実行します。
各アプリケーションの現在のディレクトリを探します
各アプリケーションの現在のディレクトリをバックアップの場所に移動します
各アプリケーションの新しいバージョンのディレクトリをそれぞれ元のアプリケーションの場所に移動します。
更新がノードで完了したら各サーバーを再起動します。
ワークフローは順番に適切なステップを実行し、各ステップの成功を監視します。ステップが失敗すると、ワークフローは再試行しようとします。ステップが正常に完了できない場合、ワークフローはそれぞれ前のステップを順番に回復します。回復プロセスは、次の項で説明するように、自動的に実行するように構成することも、手動で起動するように構成することもできます。
ZDTパッチ適用はまた、プロセスのどの時点でも(完了後であっても)更新を回復することができます。更新は次のように回復できます。
自動—ワークフローの作成時に、障害がある場合に更新を自動的に回復することを選択できます。更新は失敗した時点からロールバックされ、正常に完了した最後のステップから開始します。
手動—ワークフローが進行している間は、どの時点でも停止および回復することができます。次に更新がロールバックされ、正常に完了した最後のステップから開始します。
ワークフローの完了後、実行された更新を回復するワークフローを作成することにより回復できます。これは、回復している更新に応じて若干異なります。以前のOracleホームに回復する場合、それがロールバックであることを指定するオプションが提供されます。Javaおよびアプリケーションの場合、Javaまたはアプリケーションの以前のバージョンを指すだけです。
更新の回復の詳細は、「停止したワークフローの実行、回復および再開」を参照してください。
この項では、パッチが適用されたHomeホームのドメイン内のすべてのノードへのロールアウト方法の高レベルな概要が提供されます。ロールアウトを実行する前に:
ドメインはすべてのノード間で分散されている必要があり、すべてのノード上で同じ場所に格納されている必要があります
既存のOracleホームはすべてのノード上で同じ場所にある必要があります
ノード・マネージャは、すべてのノードで実行している必要があります
ロールアウトに含まれるすべてのクラスタ内のすべての管理対象サーバーが実行している必要があります。
その他の要件および制限については、「ZDTパッチ適用の制限」を参照してください。この項の最後の図1-1に、ロールアウトの実行にOPatchAuto、WLSTまたは管理コンソールのどれを使用するかにかかわらず、各ノードのOracleホームのロールアウトに対して実行される操作を示します。
パッチが適用されたOracleホームをロールアウトするには、次の手順を実行します。
OPatchAutoを使用する場合:
パッチが適用されたOracleホームのアーカイブを作成します。
詳細は、「OPatchAutoを使用したパッチを適用するOracleホームのアーカイブの作成」を参照してください。
パッチを適用するOracleホームをロールアウトする先のすべてのノードにアーカイブを配布します。
詳細は、「OPatchAutoを使用したパッチを適用するアーカイブの各ノードへの配布」を参照してください。
パッチを適用するOracleを手動で作成および配布する場合:
copyBinaryコマンドを使用して既存のOracleホームのアーカイブを作成します。
このステップと次のステップの詳細は、「2番目のOracleホームの作成」を参照してください。
pasteBinaryコマンドを使用して、本番ドメインと似たドメイン・トポロジの開発またはテスト・システムでパッチを適用するOracleホームを作成します。これにより、本番システムと同じパッチレベルのOracleホームおよび製品が提供されます。
Oracle OPatchツールを使用して、必要なパッチを開発またはテスト・システムのOracleホームに提供します。
詳細は、「2つ目のOracleホームへのパッチ適用」および「OPatchによるパッチ適用」を参照してください。
パッチが適用されたOracleホームをテストおよび確認します。
Oracleホームが安定していて問題なければ、copyBinaryを使用してパッチを適用するOracleホームのアーカイブを作成します。
このステップと次のステップの詳細は、「アーカイブの作成および各ノードへの配布」を参照してください。
このアーカイブを本番システムのすべてのノードに配布します。
|
注意: 各ノードのアーカイブを展開するのにpasteBinaryを使用する必要はありません。ロールアウト・プロセスはアーカイブから各ノードに新しいOracleホームを作成します。 |
管理サーバーを起動するのにノード・マネージャを使用しなかった場合、管理サーバーをシャットダウンしてから、ノード・マネージャを使用して起動します。
詳細は、「ノード・マネージャを使用した管理サーバーの起動」を参照してください。
パッチが適用されたOracleホームを管理サーバーにロールアウトするためのZDTワークフローを作成します。次のいずれかの方法でこれをできます。
OPatchAutoを使用してロールアウトを起動し、ターゲットとして管理サーバーを指定します。
詳細は、「OPatchAutoを使用したロールアウトの起動」を参照してください。
WLST rolloutOracleHomeコマンドを使用し、ロールアウト・ターゲットとして管理サーバーを指定します。
詳細は、「新しいOracleホームのロールアウト」を参照してください。
管理コンソールから、「ZDT制御」>「サーバー」タブを選択し、管理サーバーを選択してから、ワークフローを開始および構成します。
詳細は、「ドメイン、クラスタまたはサーバー用の新しいワークフローの作成」を参照してください。
ワークフローを正常に完了した後、パッチが適用されたOracleホームをドメイン内のクラスタにロールアウトするための別のZDTワークフローを作成します。次のいずれかの方法でこれをできます。
OPatchAutoを使用してロールアウトを開始し、ロールアウト・ターゲットとしてクラスタまたはクラスタのカンマ区切りリストを指定します。
詳細は、「OPatchAutoを使用したロールアウトの起動」を参照してください。
WLST rolloutOracleHomeコマンドを使用し、ロールアウト・ターゲットとしてクラスタのカンマ区切りリストを指定します。
管理コンソールから、「ZDT制御」>「クラスタ」タブを選択し、Oracleホームをロールアウトする先のクラスタを選択してから、ワークフローを開始および構成します。
|
注意: opatchautoまたはrolloutOracleHomeコマンドでターゲットとしてドメインを指定するか、「ZDT制御」>「ドメイン」タブからワークフローを開始および構成することにより、最後の2つのステップを1つのワークフローに組み合せることができます。 |
この項では、新しいJavaバージョンのドメイン内のすべてのノードへのロールアウト方法の高レベルな概要が提供されます。ロールアウトを実行する前に:
ドメインはすべてのノード間で分散されている必要があり、すべてのノード上で同じ場所に格納されている必要があります
Oracleホームはすべてのノード上で同じ場所にある必要があります
ノード・マネージャは、すべてのノードで実行している必要があります
ロールアウトに含まれるすべてのクラスタ内のすべての管理対象サーバーが実行している必要があります。
その他の要件および制限については、「ZDTパッチ適用の制限」を参照してください。
新しいJavaバージョンをロールアウトするには、次の手順を実行します。
新しいバージョンのJavaをすべてのノードにインストールします。このJavaホームへのフル・パスは、すべてのノード上で同じである必要があります。
詳細は、「新しいJavaバージョンへのアップグレードの準備」を参照してください。
管理サーバーを起動するのにノード・マネージャを使用しなかった場合、管理サーバーをシャットダウンしてから、ノード・マネージャを使用して起動します。
詳細は、「ノード・マネージャを使用した管理サーバーの起動」を参照してください。
新しいJavaホームを管理サーバーにロールアウトするためのZDTワークフローを作成します。そのためには、次のいずれかを行います。
WLST rolloutJavaHomeコマンドを使用し、ロールアウト・ターゲットとして管理サーバーを指定します。
詳細は、「Javaバージョンの更新」を参照してください。
管理コンソールから、「ZDT制御」>「サーバー」タブを選択し、管理サーバーを選択してから、ワークフローを開始および構成します。
詳細は、「ドメイン、クラスタまたはサーバー用の新しいワークフローの作成」を参照してください。
ワークフローを正常に完了した後、新しいJavaホームをドメイン内のクラスタにロールアウトするための別のZDTワークフローを作成します。そのためには、次のいずれかを行います。
WLST rolloutJavaHomeコマンドを使用し、ロールアウト・ターゲットとしてクラスタのカンマ区切りリストを指定します。
管理コンソールから、「ZDT制御」>「クラスタ」タブを選択し、新しいJavaのバージョンをロールアウトする先のクラスタを選択してから、ワークフローを開始および構成します。
|
注意: rolloutJavaHomeコマンドでターゲットとしてドメインを指定するか、「ZDT制御」>「ドメイン」タブからワークフローを開始および構成することにより、最後の2つのステップを1つのワークフローに組み合せることができます。 |
この項では、新しいアプリケーション・バージョンのドメイン内のすべての管理対象サーバーへのロールアウト方法の高レベルな概要が提供されます。ロールアウトを実行する前に:
ドメインはすべてのノード間で分散されている必要があり、すべてのノード上で同じ場所に格納されている必要があります
Oracleホームはすべてのノード上で同じ場所にある必要があります
ノード・マネージャは、すべてのノードで実行している必要があります
ロールアウトに含まれるすべてのクラスタ内のすべての管理対象サーバーが実行している必要があります。
その他の要件および制限については、「ZDTパッチ適用の制限」を参照してください。この項の最後に、図(UNKNOWN STEP NUMBER)から(UNKNOWN STEP NUMBER)までで、ステージングされた、ステージングされていない、および外部ステージングされたアプリケーションを示します。パッチが適用されたアプリケーション・ソースは、ロールアウト中に、各ステージ・タイプに応じた適切なアプリケーション・ソースの場所に移動されます。
新しいアプリケーション・バージョンを管理対象サーバーにロールアウトするには、次の手順を実行します。
(ステージ・モード)各更新済アプリケーション・ディレクトリのコピーを、ドメインの管理サーバーに配置します。
(非ステージ・モードおよび外部ステージ・モード)各更新済アプリケーション・ディレクトリのコピーを、影響を受ける各ノードに配置します。ディレクトリは、すべてのノードで同じにする必要があります。
詳細は、「ステージング・モードの影響」を参照してください。
各アプリケーション名、各更新済アプリケーション・アーカイブのパスおよびファイル名および元のアプリケーション・アーカイブをバックアップする先のパスおよびファイルを定義するJSONファイルを作成します。
詳細は、「アプリケーションの更新用JSONファイルの作成」を参照してください。
管理サーバーを起動するのにノード・マネージャを使用しなかった場合、管理サーバーをシャットダウンしてから、ノード・マネージャを使用して起動します。
詳細は、「ノード・マネージャを使用した管理サーバーの起動」を参照してください。
新しいアプリケーション・バージョンをロールアウトするためのZDTワークフローを作成します。そのためには、次のいずれかを行います。
WLST rolloutApplicationsコマンドを使用し、ロールアウト・ターゲットとしてクラスタのカンマ区切りリストを指定します。
管理コンソールから、「ZDT制御」>「クラスタ」タブを選択し、アプリケーションをロールアウトする先のクラスタを選択してから、ワークフローを開始および構成します。
インメモリー・セッションのレプリケーションを使用するwebappの場合、インメモリー・セッションはフェイルオーバーを可能にするためにレプリケートまたは保存されません。その結果として、セッションなしでのリクエストのサーバーへのアクセスの原因となるサーバー・クラッシュまたはフロントエンドの宛先間違いにより、webappのセッション状態が失われる可能性があります。
ダウンタイムなしの(ZDT)ロールアウトに関しては、インメモリー・セッションを保持するサーバーをシャットダウンすると、サーバーはシャットダウンする前にそのセッションが完了するのを待機します。セッション・タイムアウトのデフォルト値が1時間のため、サーバーは1時間、またはセッションの使用や更新が続行された場合にはさらに長い時間、SUSPENDING状態になる可能性があります。webappに対するインメモリー・セッションはレプリケートされることも保存されることもないので、セッションがライフサイクルを完了するのを待機しなければその状態は失われます。
1時間またはそれ以上も待つことができない場合、shutdownTimeoutオプションの引数に、サーバーがシャットダウンする前の待機時間(秒)を設定します。shutdownTimeoutオプションの引数の使用の詳細は、「表3-1 WLSTロールアウト・コマンドの引数」を参照してください。
