| Oracle® Fusion Middlewareゼロ・ダウンタイム・パッチ適用ワークフローの管理 12c (12.2.1.1.0) E77312-01 |
|
 前 |
 次 |
この章の内容は次のとおりです。
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ファイルは、次の行で始まる必要があります。
{"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ホームのロールアウトを準備する方法は2つあります。
OPatchAutoツールを使用して、Oracleホームの自動的なクローン作成、パッチの適用、パッチを適用したOracleホームのアーカイブの作成を行うことができます。次に、OPatchAutoを使用して、パッチ適用済Oracleホームのアーカイブをドメイン内のノードに配布できます。より自動化されている、この手法の使用をお薦めします。詳細は、次の項を参照してください。
手動で2つ目のOracleホームを作成し、OPatchユーティリティを使用してそれにパッチを適用し、copyBinaryコマンドを使用してパッチ適用済Oracleホームのアーカイブを作成し、その後そのアーカイブをドメイン内のノードにコピーできます。詳細は、次の項を参照してください。
どちらの場合も、準備プロセスに管理対象サーバーのシャットダウンは必要ないので、アプリケーションの可用性に影響はありません。
注意:
ドメインにOracle WebLogic Server以外のOracle Fusion Middleware製品(Oracle SOA SuiteやOracle WebCenterなど)が含まれていて、Oracleホームのそれらのアプリケーションにパッチを適用済の場合、ロールアウトを実行中に現在のアクティブ・セッションを保持するには、パッチが適用されたバージョンがZDTパッチ適用と互換性があることを確認します。たとえば、適用されたパッチはセッション形状への変更に制限があり、ドメインで実行中の他のOracle Fusion Middleware製品と下位互換性を持つ必要があります。
この項では、既存の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コマンドにおけるパラメータを示します。
| パラメータ | 説明 |
|---|---|
|
適用するパッチが保存されているOPatch |
|
Oracleホーム・ディレクトリのイメージを作成することを示します。イメージには |
|
作成するイメージJARファイルのフルパスとファイル名を指定します。次に例を示します。
|
|
これがホーム外パッチ適用アーカイブであることを示します |
パッチが適用されたアーカイブを作成したら、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コマンドにおけるパラメータを示します。
| パラメータ | 説明 |
|---|---|
|
|
|
配布するイメージJARファイルのフルパスとファイル名を指定します。次に例を示します。
|
|
パッチが適用されたOracleホームのロールアウト先のドメインの、管理サーバーのホスト名とポート番号を指定します。アーカイブはこのノードに配布されます。 |
|
ロールアウトに含まれるクラスタまたはクラスタのカンマ区切りリストを指定します。アーカイブはこれらのクラスタが構成されるすべてのノードに配布されます。 |
|
ZDTロールアウトに含まれる各ノードに作成するアーカイブ・ファイルへのフルパス。これは、元のアーカイブと同じファイル名である必要はありません。次に例を示します。
|
|
|
|
必要な場合、指定したウォレットのパスワード。次に例を示します。
|
パッチを適用したアーカイブを配布したら、Oracleホームのパッチ適用を含むワークフローを作成する準備は完了です。ワークフローの構成と監視を参照してください。
注意:
同じパッチ適用ワークフローを使用してJavaバージョンまたはアプリケーションも更新する場合、ワークフローの作成前に、これらのアップグレードのための準備ステップを実行します。
パッチが適用された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ホームにパッチを適用するには、OPatchツールを使用して個別のパッチ、バンドル・パッチ、セキュリティ・パッチの更新、またはパッチ・セットの更新を、2つ目のオフラインのOracleホームへ適用します。特定のパッチまたはパッチのグループを適用する前に、すべての前提条件のパッチが適用済であることを確認します。
OPatchを使用したOracleホームへのパッチの適用および準備方法の詳細は、Opatchによるパッチ適用を参照してください。
パッチが適用されたOracleホームを作成したら、次のステップを使用してOracleホームのアーカイブを作成し、それをロールアウトに含まれる各ノードにコピーします。
これらのステップを完了したら、Oracleホームのパッチ適用を含むワークフローを作成する準備は完了です。ワークフローの構成と監視を参照してください。
注意:
同じパッチ適用ワークフローを使用してJavaバージョンまたはアプリケーションも更新する場合、ワークフローの作成前に、これらのアップグレードのための準備ステップを実行します。
Javaの新しいバージョンへのアップグレードの準備には、管理対象サーバーのシャットダウンは必要ありません。そのため、アプリケーションの可用性の妨げにはなりません。
新しいJavaバージョンにアップグレードするには、次の手順を実行します。
新しいJavaバージョンを各ノードへコピーしたら、新しいJavaホームへのアップグレードを含むワークフローを作成する準備は完了です。ワークフローの構成と監視を参照してください。
この項では、ZDTワークフローを使用して新しいアプリケーションにアップグレードするための準備方法について説明します。内容は次のとおりです。
管理対象サーバー、パーティションまたはリソース・グループにわたるデプロイされたアプリケーションは、stageモード、no-stageモードおよびexternal-stageモードという3つのステージング・モードのいずれかを使用してデプロイできます。選択したモードにより、アプリケーションをどのように配布し最新の状態に保つかを示します。
アプリケーションの更新ワークフローの準備方法は、アプリケーションをステージングしたときに使用されたモードによって異なります。
| ステージング・モード | 必要な準備と結果 |
|---|---|
ステージ |
各更新済アプリケーション・ディレクトリのコピーを、ドメインの管理サーバーに配置します。 結果: ワークフローでは、元のアプリケーション・ディレクトリを管理サーバーに配置し、WebLogic Serverがそれを各管理対象サーバーにコピーします。 |
非ステージ |
更新済アプリケーション・ディレクトリのコピーを、影響を受ける各ノードに配置します。このディレクトリは各ノード上で同じ場所にある必要があります。 結果: ワークフローは、既存のアプリケーション・ディレクトリを更新済アプリケーション・ディレクトリで置き換えることにより、各ノードを順次更新し、元のアプリケーション・ディレクトリを指定したバックアップの場所に移動します。 |
外部ステージ |
更新済アプリケーション・ディレクトリのコピーを、影響を受ける各ノードに配置します。このディレクトリは各ノード上で同じ場所にある必要があります。 結果: ワークフローはアプリケーションが外部ステージ・アプリケーションであることを検出し、ノード上の各管理対象サーバーのステージ・ディレクトリの正しいパスを特定し、更新済アプリケーションをその場所にコピーし、元のアプリケーションを指定したバックアップの場所に移動します。 |
様々なステージング・モードの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のステージング・モードの説明とベスト・プラクティスに関する項を参照してください。
単一のワークフローを使用して、ドメイン、パーティションまたはリソース・グループ内の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ファイルを作成したら、アプリケーションの更新を含むワークフローを作成する準備ができます。ワークフローの構成と監視を参照してください。
