| Oracle® Fusion Middlewareゼロ・ダウンタイム・パッチ適用ワークフローの管理 12c (12.2.1.1.0) E77312-01 |
|
 前 |
 次 |
この章の内容は次のとおりです。
ダウンタイムなしのパッチ適用(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ホームがすべてのノード上で同じ場所にある
ノード・マネージャがすべてのノードで実行されている
ロールアウトに含まれるすべてのクラスタ内のすべての管理対象サーバーが実行されている
その他の要件および制限については、ZDTパッチ適用の制限を参照してください。図1-1では、ロールアウトの実行にOPatchAuto、WLSTまたはWebLogic Server管理コンソールのどれを使用するかにかかわらず、各ノードのOracleホームのロールアウトに対して実行される操作を示します。
パッチが適用されたOracleホームをロールアウトするには、次の作業を行います。
パッチが適用されたOracleホームのアーカイブは、次のいずれかの方法で作成および配布します。
OPatchAutoを使用する
パッチが適用されたOracleホームのアーカイブを作成します。
詳細は、「OPatchAutoを使用したパッチを適用するOracleホームのアーカイブの作成」を参照してください
パッチを適用したOracleホームをロールアウトする先のすべてのノードにアーカイブを配布します。
詳細は、「OPatchAutoを使用したパッチを適用するアーカイブの各ノードへの配布」を参照してください
パッチが適用されたOracleホームのアーカイブを、次のように手動で作成および配布する
copyBinaryコマンドを使用して既存のOracleホームのアーカイブを作成します。
このステップと次のステップの詳細は、「2番目のOracleホームの作成」を参照してください
pasteBinaryコマンドを使用して、本番ドメインと似たドメイン・トポロジの開発システムまたはテスト・システムでパッチを適用するOracleホームを作成します。これにより、本番システムと同じパッチレベルのOracleホームおよび製品が提供されます。
OPatchを使用して、必要なパッチを開発システムまたはテスト・システムのOracleホームに適用します。
詳細は、2つ目のOracleホームへのパッチ適用およびOPatchによるパッチ適用を参照してください。
パッチが適用されたOracleホームをテストおよび確認します。
パッチが適用されたOracleホームが安定していて問題なければ、copyBinaryを使用して、パッチが適用されたOracleホームのアーカイブを作成します。
このステップと次のステップの詳細は、「アーカイブの作成および各ノードへの配布」を参照してください
このアーカイブを本番システムのすべてのノードに配布します。
注意:
各ノードでのアーカイブの作成にpasteBinaryを使用する必要はありません。ロールアウト・プロセスはアーカイブから各ノードに新しいOracleホームを作成します。
パッチが適用されたOracleホームを管理サーバーにロールアウトするためのZDTワークフローを作成します。次のいずれかの方法でこれをできます。
OPatchAutoを使用してロールアウトを起動し、ターゲットとして管理サーバーを指定します。
詳細は、「OPatchAutoを使用したロールアウトの起動」を参照してください
WLST rolloutOracleHomeコマンドを使用し、ロールアウト・ターゲットとして管理サーバーを指定します。
詳細は、「新しいOracleホームのロールアウト」を参照してください
WebLogic Server管理コンソールで、「ZDT制御」タブをクリックし、「サーバー」タブに移動します。「サーバー」タブで、管理サーバーを選択してから、ワークフローを開始および構成します。「ドメイン」タブをクリックし、ドメインを選択してワークフローを開始することもできます。
詳細は、ドメイン、クラスタまたはサーバー用の新しいワークフローの作成を参照してください。
ワークフローを正常に完了した後、パッチが適用されたOracleホームをドメイン内のクラスタにロールアウトするための別のZDTワークフローを作成します。次のいずれかの方法でこれをできます。
OPatchAutoを使用してロールアウトを開始し、ロールアウト・ターゲットとしてクラスタまたはクラスタのカンマ区切りリストを指定します。
詳細は、「OPatchAutoを使用したロールアウトの起動」を参照してください
WLST rolloutOracleHomeコマンドを使用し、ロールアウト・ターゲットとしてクラスタのカンマ区切りリストを指定します。
WebLogic Server管理コンソールから、「ZDT制御」>「クラスタ」タブを選択し、Oracleホームをロールアウトする先のクラスタを選択してから、ワークフローを開始および構成します。
注意:
opatchautoまたはrolloutOracleHomeコマンドでターゲットとしてドメインを指定するか、「ZDT制御」>「ドメイン」タブからワークフローを開始および構成することにより、最後の2つのステップを1つのワークフローに組み合せることができます。
図1-1 Oracleホームのロールアウト操作
この図では、ロールアウトの実行にOPatchAuto、WLSTまたはWebLogic Server管理コンソールのどれを使用するかにかかわらず、各ノードのOracleホームのロールアウトに対して実行される操作を示します。
この項では、新しいJavaバージョンをドメイン内のすべてのノードにロールアウトする方法の概要を示します。ロールアウトを実行する前に、次の条件を満たしていることを確認してください。
ドメインがすべてのノード間で分散されており、すべてのノード上で同じ場所に格納されている
Oracleホームがすべてのノード上で同じ場所にある必要がある
ノード・マネージャがすべてのノードで実行されている
ロールアウトに含まれるすべてのクラスタ内のすべての管理対象サーバーが実行されている
その他の要件および制限については、ZDTパッチ適用の制限を参照してください。
新しいJavaバージョンをロールアウトするには、次の手順を実行します。
この項では、新しいアプリケーション・バージョンをドメイン内の管理対象サーバー、パーティションまたはリソース・グループにロールアウトする方法の概要を示します。
現在、ZDTでは、アプリケーション・ロールアウト機能をパーティションとリソース・グループの両方に提供するWebLogic Serverマルチテナントがサポートされています。これは、リソース・グループ(パーティション・スコープまたはグローバル)または特定のパーティションにデプロイされたアプリケーションを、WebLogic Serverインスタンス内の他のリソース・グループまたはパーティションに影響を与えることなく更新できるようになったということです。WebLogic Server管理者は、多数のパーティションによって使用されるリソース・グループ・テンプレート内で定義されているアプリケーションを更新できます。単一パーティションにデプロイされたアプリケーションも更新できます。パーティション管理者は、それら固有のパーティション内で定義されているアプリケーションのみを更新できます。WebLogic Serverにおけるマルチテナンシの詳細は、WebLogic Serverマルチテナントの使用を参照してください。
ロールアウトを実行する前に、次の条件を満たしていることを確認してください。
更新されているドメインはすべてのノード間で分散されており、すべてのノード上で同じ場所に格納されている必要がある
Oracleホームがすべてのノード上で同じ場所にある
ノード・マネージャがすべてのノードで実行されている
ロールアウトに含まれるすべてのクラスタ内のすべての管理対象サーバーが実行されている
更新されているパーティションのインスタンスが、複数のクラスタで実行されている必要がある
その他の要件および制限については、ZDTパッチ適用の制限を参照してください。図1-2、図、および図1-4では、それぞれ、ステージングされた、ステージングされていない、および外部ステージングされたアプリケーションのパッチ適用のためのシナリオを示します。パッチが適用されたアプリケーション・ソースは、ロールアウト中に、各ステージ・タイプに応じた適切なアプリケーション・ソースの場所に移動されます。
新しいアプリケーション・バージョンを管理対象サーバーにロールアウトするには、次の手順を実行します。
インメモリー・セッションのレプリケーションを使用するWebアプリケーションの場合、インメモリー・セッションがレプリケートされるか維持されてフェイルオーバーが可能になることはありません。結果として、サーバーまたはフロントエンドの指示間違いによって突然障害が発生し、そのリクエストをサーバーがセッションなしで受信することにより、Webアプリケーションがセッション状態を失う場合があります。
ダウンタイムなしの(ZDT)ロールアウトに関しては、インメモリー・セッションを保持するサーバーをシャットダウンすると、サーバーはシャットダウンする前にそのセッションが完了するのを待機します。セッション・タイムアウトのデフォルト値が1時間のため、サーバーは1時間、またはセッションの使用や更新が続行された場合にはさらに長い時間、SUSPENDING状態になる可能性があります。Webアプリケーションに対するインメモリー・セッションはレプリケートされることも保存されることもないので、セッションがライフサイクルを完了するのを待機しなければその状態は失われます。
1時間以上も待機できない場合は、WLSTのrolloutコマンドで、shutdownTimeout引数にサーバーをシャットダウンするまでの待機時間(秒)を設定します。shutdownTimeout引数の使用の詳細は、表3-1を参照してください。
