2 ダウンタイムなしのパッチ適用の準備
パッチ適用ワークフローを構成する前に、新しいOracleホームのインストールおよびパッチ適用、新しいJavaバージョンのインストールまたは各ノードに対する更新されたアプリケーションのインストールなど、必要な事前ステップを実行してください。Oracle WebLogic ServerでZDTパッチ適用ワークフローを準備および作成する前に、既知の制限事項を考慮する必要があります。
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パッチ適用ロールアウトは、WebLogic Serverのサービス移行機能を使用して、JMSおよびJTAなどのシングルトン・サービスの移行を提供します。ロールアウト中に、サービス移行を制御しやすくするために、ZDTがサポートするJSONファイル・ベース移行オプションも使用できます。
すべてのZDTロールアウトでは、ロールアウトに含まれるサーバーの再起動が必要です。ロールアウトの機能の1つは、Java Transaction API (JTA)およびJava Messaging Service (JMS)などのシングルトン・サービスの検出および処理です。ロールアウト操作中にこれらのシングルトン・サービスの可用性を高めるには、ZDTパッチ適用で、WebLogic Serverによってサポートされているサービス移行メカニズムを利用します。環境内のシングルトン・サービスの場合は、次のいずれかの方法でサービス移行を構成できます。
-
移行可能ターゲットを使用して構成されるシングルトン・サービスの移行の場合、サービス移行は、Oracle WebLogic Serverクラスタの管理のサービスの移行で説明されているとおりに構成されます。サービスが移行可能ターゲットを使用して構成されており、移行ポリシーが
exactly-once
に設定されている場合、サービスはサーバーの正常なシャットダウン中に自動的に移行されます。しかし、サービスの移行ポリシーがmanual
またはfailure-recovery
の場合、サーバーのシャットダウン中にサービスが安全に移行されたことを確認するために、ステップをとる必要があります。これを実現するには、シングルトン・サービスの移行のためのJSONファイルの作成で説明されているように、JSONファイル内で移行プロパティを定義する必要があります。移行可能ターゲットを使用して構成されるシングルトン・サービスの移行時には、次の問題の制限事項に留意する必要があります。
-
JMSサーバーのデータ・ストアは、メッセージが失われることのない、クラスタのメンバーによって使用される共有の場所に配置する必要があります。
-
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":[
移行する必要のある各シングルトン・サービスの移行は、次の表で説明しているパラメータを使用して定義されます。
パラメータ | 説明 |
---|---|
|
サービスが移行される元のソース・サーバーの名前。このパラメータは必須です。 |
|
|
|
移行のタイプ。次のタイプのいずれかです。
|
|
デフォルト値は ノート: JTAサービスは移行用に起動されたときに自動的にフェイルバックされます。したがって、JTAサービスには適用されないため、 |
次のサンプル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ホームを管理対象サーバーにロールアウトする前に、Oracleホームのアーカイブを作成して、各ノードに配布する必要があります。
手動で2つ目のOracleホームを作成し、OPatchユーティリティを使用してそれにパッチを適用し、copyBinary
コマンドを使用してパッチ適用済Oracleホームのアーカイブを作成し、その後そのアーカイブをドメイン内のノードにコピーできます。詳細は、次の項を参照してください。
準備プロセスに管理対象サーバーのシャットダウンは必要ないので、アプリケーションの可用性に影響はありません。
2つ目のOracleホームの作成
パッチが適用されたOracleホームを手動で作成するには、最初にcopyBinary
およびpasteBinary
コマンドを使用することで既存のOracleホームのコピーを作成する必要があります。これらのコマンドの使用時には、指定したオプションの値にスペースを含まないようにすることを覚えておいてください。たとえば、Windowsでは、-javaHome
オプションの値として次のような文字列を渡すことはできません。
C:\Program Files\jdk
ノート:
適用するパッチをテストできるように、本番マシン以外に2つ目のOracleホームを作成してパッチを適用することをお薦めしますが、必須ではありません。ただし、新しいOracleホームにパッチを適用するノード上で、次のステップを実行する必要があります。そのノードのOracleホームは、本番ドメインで使用しているOracleホームと同じである必要があります。
パッチを適用する2つ目のOracleホームを作成するには:
たとえば、次のコマンドは、アーカイブ/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によるパッチ適用』の「OPatchを使用した環境へのパッチ適用」を参照してください。
アーカイブの作成および各ノードへの配布
パッチが適用されたOracleホームを作成したら、次のステップを使用してOracleホームのアーカイブを作成し、それをロールアウトに含まれる各ノードにコピーします。
これらのステップを完了したら、Oracleホームのパッチ適用を含むワークフローを作成する準備は完了です。ワークフローの構成と監視を参照してください。
ノート:
同じパッチ適用ワークフローを使用してJavaバージョンまたはアプリケーションも更新する場合、ワークフローの作成前に、これらのアップグレードのための準備ステップを実行します。
新しいJavaバージョンへのアップグレードの準備
新しいJavaバージョンにアップグレードする前に、新しいJavaバージョンをアップグレードに含める各ノードにコピーする必要があります。新しいJavaバージョンをインストールする前に、特定の条件を満たす必要があります。
Javaの新しいバージョンへのアップグレードの準備には、管理対象サーバーのシャットダウンは必要ありません。そのため、アプリケーションの可用性の妨げにはなりません。
新しいJavaバージョンにアップグレードするには:
- 新しいJavaバージョンをインストールする前に、ノード・マネージャと管理対象サーバーが、新しいバージョンをインストール予定のすべてのノードで実行していることを確認します。これにより、Javaインストーラが既存のJavaホームのパスを変更するのを防ぎます。ただし、ノード・マネージャを、管理サーバーが実行されているノード上で実行する必要はありません。
- アップグレードに含まれる各ノードで、新しいJavaバージョンを各ノードの同じパスにインストールします。新しいJavaバージョンへのフル・パスは、アップグレードが正常に行われるために、各ノード上で同じである必要があります。
新しいJavaバージョンを各ノードへコピーしたら、新しいJavaホームへのアップグレードを含むワークフローを作成する準備は完了です。ワークフローの構成と監視を参照してください。
新しいアプリケーション・バージョンへの更新の準備
アプリケーション更新をロールアウトする前に、アプリケーションをステージングしたときに使用したステージング・モードに応じて、新しいアプリケーション・バージョンがすべての影響を受けたノードに配布されます。JSONファイルを作成して、更新が必要なアプリケーションのプロパティを指定する必要があります。
この項では、ZDTワークフローを使用して新しいアプリケーションにアップグレードするための準備方法について説明します。内容は次のとおりです。
ステージング・モードの影響
管理対象サーバーにわたるデプロイされたアプリケーションは、stageモード、no-stageモードおよびexternal-stageモードという3つのステージング・モードのいずれかを使用してデプロイできます。選択したモードにより、アプリケーションをどのように配布し最新の状態に保つかを示します。
アプリケーションの更新ワークフローの準備方法は、アプリケーションをステージングしたときに使用されたモードによって異なります。
ステージング・モード | 必要な準備と結果 |
---|---|
ステージ |
各更新済アプリケーション・ディレクトリのコピーを、ドメインの管理サーバーに配置します。 結果: ワークフローでは、元のアプリケーション・ディレクトリを管理サーバーに配置し、WebLogic Serverがそれを各管理対象サーバーにコピーします。 |
非ステージ |
更新済アプリケーション・ディレクトリのコピーを、影響を受ける各ノードに配置します。このディレクトリは各ノード上で同じ場所にある必要があります。 結果: ワークフローは、既存のアプリケーション・ディレクトリを更新済アプリケーション・ディレクトリで置き換えることにより、各ノードを順次更新し、元のアプリケーション・ディレクトリを指定したバックアップの場所に移動します。 |
外部ステージ |
更新済アプリケーション・ディレクトリのコピーを、影響を受ける各ノードに配置します。このディレクトリは各ノード上で同じ場所にある必要があります。 結果: ワークフローはアプリケーションが外部ステージ・アプリケーションであることを検出し、ノード上の各管理対象サーバーのステージ・ディレクトリの正しいパスを特定し、更新済アプリケーションをその場所にコピーし、元のアプリケーションを指定したバックアップの場所に移動します。 |
様々なステージング・モードの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のステージング・モードの説明とベスト・プラクティスに関する項を参照してください。
アプリケーションの更新用JSONファイルの作成
1つのワークフローでドメイン内の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ファイルを作成したら、アプリケーションの更新を含むワークフローを作成する準備ができます。ワークフローの構成と監視を参照してください。