| Oracle® Fusion Middlewareゼロ・ダウンタイム・パッチ適用ワークフローの管理 12c (12.2.1) E70053-01 |
|
 前 |
この章では、管理対象サーバーをパッチが適用されたOracleホームに移動、管理対象サーバーのJavaバージョンを更新、管理対象サーバーのアプリケーションを更新、またはこれらの更新タスクを組み合せた、パッチ適用ワークフローの構成と監視方法について説明します。WebLogic Server管理コンソールまたはWLSTを使用して、ワークフローを作成および監視できます。
|
注意: 更新プロセスを開始する前に、第2章「ダウンタイムなしのパッチ適用の準備」に従って、実行中の更新のタイプに応じた適切な準備手順をすべて完了しておく必要があります。Windowsベースのドメインの場合、Oracleホームを更新するワークフローを開始する前に、各ノードで、更新されるOracleホームにロックされているディレクトリまたはファイルがないことを確認します。これがあるとOracleホームを指定したバックアップ・ディレクトリに移動できない可能性があるからです。ディレクトリはDOSコマンド・ウィンドウをそのディレクトリで開くという程度の簡単なことでロックできます。ファイルはそのファイルをアプリケーションで開くことによってロックできます。 |
この章の構成は、次のとおりです。
WLSTまたは管理コンソールのいずれかを使用して新しいOracleホームをロールアウトするときに、パッチが適用されたOracleホームは、最初に管理サーバーにロールアウトされる必要があります。これを行うには2つの方法があります。
1つのワークフローを使用してパッチが適用されたOracleホームを管理サーバーにロールアウトし、次に2つ目のワークフローを使用してパッチが適用されたOracleホームをクラスタにロールアウトします。この手法の使用をお薦めしますが、必須ではありません。
このシナリオでは、次のようになります。
WLSTを使用している場合、rolloutOracleHomeまたはrolloutUpdateコマンドのいずれかを実行し、ターゲットとしてAdminServerを指定します。次にrolloutOracleHomeまたはrolloutUpdateを再度実行し、クラスタ・ターゲットを指定します。
管理コンソールを使用している場合、「サーバー」タブから1つのワークフローを作成し、ターゲットとして管理サーバーを選択します。そのワークフローが完了したら、「クラスタ」タブから2つ目のワークフローを作成し、含めるクラスタを選択します。
1つのワークフローのみを使用してパッチが適用されたOracleホームをドメイン全体にロールアウトします。ワークフローは、パッチが適用されたOracleホームを、ターゲット・クラスタにロールアウトする前に、最初に自動的にロールアウトします。
このシナリオでは、次のようになります。
WLSTを使用している場合、rolloutOracleHomeまたはrolloutUpdateコマンドのいずれかを実行し、ターゲットとしてドメイン名を指定します。
管理コンソールを使用している場合、「ドメイン」タブから1つのワークフローを作成します。
管理サーバーがワークフローに含まれる場合、ワークフローを起動する前に、ノード・マネージャを使用して管理サーバーを起動する必要があります。
|
注意: 管理サーバーが現在実行中で、ノード・マネージャを使用して起動された場合、これらの手順を実行する必要はありません。 |
ノード・マネージャを使用して管理サーバーを起動する手順は次のとおりです。
管理サーバーが現在実行中で、ドメイン・ホームでstartWebLogicスクリプトを使用して起動された場合、stopWebLogicコマンドを使用してシャットダウンします。
UNIX
cd domain_home/bin
./stopWebLogic.sh
Windows
cd domain_home\bin
stopWebLogic.cmd
ノード・マネージャが管理サーバーで実行中であることを確認します。
WLSTを起動します。『WebLogic Scripting Toolの理解』のWLSTの呼出しに関する項を参照してください。
nmConnectコマンドを使用してノード・マネージャ・セッションを確立します。たとえば、SSLを使用して/domains/mydomainにあるmydomainドメインに接続するには、ノード・マネージャ・ポートが5556の場合、次のようになります。
wls:/myserver/serverConfig> nmConnect('username', 'password, 'localhost',
'5556', 'mydomain', '/domains/mydomain','ssl')
正常に接続されてから、nmStartコマンドを実行します。たとえば、管理サーバーがAdminServerでドメインが/domains/mydomainにある場合は、次のようになります。
nmStart('AdminServer', '/domains/mydomain')
詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャを使用した管理サーバーの起動に関する項を参照してください。
この項では、パッチが適用されたOracleホームをドメインのノードに適用する、ロールアウト・ワークフローの起動および監視方法について説明します。この手法は、パッチが適用されたOracleホームにワークフローが適用される場合にのみ使用できます。Javaバージョンの更新またはアプリケーションの更新をワークフローに含める場合、WLSTまたは管理コンソールを使用する必要があります。
次のコマンドを使用して、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
次の表に、このコマンド内のパラメータを示します。
| パラメータ | 説明 |
|---|---|
-plan |
opatchauto applyにより実行される操作のタイプを示します。ZDTのパッチが適用されたOracleホームのロールアウトでは、このパラメータの値としてwls-zdtを必ず指定します。 |
-image-location path |
ロールアウトに使用するパッチが適用されたOracleホームを含むイメージJARファイルのフルパスと名前を指定します。次に例を示します。
|
-wls-zdt-host adminserver:port |
パッチが適用されたOracleホームのロールアウト先のドメインの、管理サーバーのホスト名とポート番号を指定します。 |
-wls-zdt-target target |
targetには、ロールアウトのターゲットを指定します。これには次のものがあります。
アーカイブをロールアウトしている場合、ロールアウトに使用しているアーカイブを配布したときに指定したのと同じターゲットを指定する必要があります。 |
-wls-zdt-backup path |
既存のOracleホームをバックアップするのに使用するディレクトリおよびファイルへのフルパス。次に例を示します。
|
-wls-zdt-remote-image path |
ZDTロールアウトに含まれる各ノードに作成するアーカイブ・ファイルへのフルパス。これは、元のアーカイブと同じファイル名である必要はありません。次に例を示します。
|
-wallet path |
configWallet.shまたはconfigWallet.cmdを使用して作成されたウォレット・ディレクトリへのフルパス。次に例を示します。
|
-walletPassword password |
必要な場合、指定したウォレットのパスワード。次に例を示します。
|
OPatchAutoを使用して、完了したワークフローを回復させるだけでなく、失敗または停止したロールアウトを回復させることができます。ロールアウトが失敗または停止した場合、OPatchAutoは最後に正常に完了した手順から回復を開始します。ロールアウトが完了したら、OPatchAutoはロールアウトするOracleホームとしてバックアップされたOracleホームを使用して、新しいロールアウトを開始します。
次のコマンドを使用してロールアウトを回復します。
cd ORACLE_HOME/OPatch/auto/core/bin opatchauto.sh rollback -session workflow_id -walletPassword password
次の表に、このコマンド内のパラメータを示します。
| パラメータ | 説明 |
|---|---|
-session -workflow_id |
ロールバックするワークフローのワークフローIDを指定します。 |
-wallet path |
configWallet.shまたはconfigWallet.cmdを使用して作成されたウォレット・ディレクトリへのフルパス。次に例を示します。
|
-walletPassword password |
必要な場合、指定したウォレットのパスワード。次に例を示します。
|
Oracleホームのロールアウトに失敗して再開する場合、次のコマンドを使用します。
cd ORACLE_HOME/OPatch/auto/core/bin opatchauto.sh resume -session workflow_id -walletPassword password
次の表に、このコマンド内のパラメータを示します。
| パラメータ | 説明 |
|---|---|
-session -workflow_id |
ロールバックするワークフローのワークフローIDを指定します。 |
-wallet path |
configWallet.shまたはconfigWallet.cmdを使用して作成されたウォレット・ディレクトリへのフルパス。次に例を示します。
|
-walletPassword password |
必要な場合、指定したウォレットのパスワード。次に例を示します。
|
この項では、ワークフローを起動して管理対象サーバーを更新するのに使用できるWLSTコマンドについて説明し、様々なワークフロー(ロールアウト)シナリオを示すサンプルのWLSTスクリプトを提供します。
|
注意: WLSTrolloutOracleHomeまたは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つのノード上の管理対象サーバーを1つずつ正常にシャットダウンします。これには、現在ADMINまたはSTANDBYモードの管理対象サーバーは含まれません。migrationPropertiesオプションがロールアウト・コマンドに含まれている場合、これにはシングルトン・サービスの移行が含まれます。
Oracleホーム・ディレクトリの置換(必要な場合)
Javaホーム・ディレクトリの置換(必要な場合)
アプリケーション・ディレクトリの置換(必要な場合)
ノードでのノード・マネージャの再起動
ノードでの管理対象サーバーの再起動
表3-1 WLSTロールアウト・コマンドの引数
| 引数 | 説明 |
|---|---|
|
|
すべての 更新に含まれる管理対象サーバーを指定します。 domain_name—ドメイン内の管理サーバーおよびすべての管理対象サーバーを更新する場合に、ターゲットとしてドメイン名を指定します。 clusters—特定のクラスタ内のすべての管理対象サーバーを更新し、それ以外のクラスタの管理対象サーバーは更新しない場合、クラスタ名またはクラスタ名のカンマ区切りリストを指定します。 servers—該当する管理対象サーバーのみを更新する場合、サーバー名またはサーバー名のカンマ区切りリストを指定します。指定するサーバーはクラスタの一部である必要があります。クラスタ化されていないサーバーは指定できません。 注意: 通常、管理サーバーの更新時にのみ、サーバー・ターゲットを指定する必要があります。個々の管理対象サーバーの更新は、セッションが維持されずに、ユーザーの停止時間を回避できない可能性があるため、ほとんどの場合でお薦めできません。たとえば、安全に管理対象サーバー・ターゲットを指定できるような状況として、1つ以上の新しい管理対象サーバーを追加し、それらがその他の管理対象サーバーと同じJavaバージョンではない場合があります。 |
|
|
ロールアウトするOracleホームのアーカイブ(JARファイル)またはローカルのOracleホーム・ディレクトリを指定し、その結果、既存のOracleホームを置き換えます。 |
|
|
既存のOracleホームが移動する先のディレクトリのフルパスを指定します。これにより元のOracleホームの名前を効率的に変更します。たとえば、元のOracleホームが/u01/Oracle_Homeで、このパラメータに/u01/Oracle_Home_backupを指定すると、/u01/Oracle_Homeは/u01/Oracle_Home_backupに移動します(名前が変更されます)。 |
|
|
オプション。 |
|
|
使用する新しいJavaホームの場所を指定します。 |
|
|
1つ以上のアプリケーション名、アプリケーション・アーカイブの場所、およびアプリケーション・バックアップの場所を定義するJSONファイルへのフルパス。 |
|
|
次のオプションを
|
WLSTを使用してワークフローの進行状況を監視することもできます。詳細は、「ワークフローの進行状況の監視」を参照してください。
次のタスクのいずれかを実行するだけの場合は、rolloutOracleHomeコマンドを使用します。
パッチが適用されたOracleホームを使用するように管理サーバーを更新します。
パッチが適用されたOracleホームを使用するようにドメイン全体(管理サーバーおよびクラスタ化された管理対象サーバー)を更新します。
パッチが適用されたOracleホームを使用するようにクラスタ化された管理対象サーバーを更新します。
以前のパッチが未適用のOracleホームを使用するように管理サーバー、クラスタ化された管理対象サーバーまたはドメインを更新します。
rolloutOracleHomeの構文は次のとおりです。
rolloutOracleHome(target, rolloutOracleHome, backupOracleHome, [isRollback], [options])
このコマンドはisDryRun、autoRevertOnFailureおよびisSessionCompatibleオプションをサポートします。
例3-1に、新しいOracleホームをドメインmydomainにロールアウトする方法を示します。パッチが適用されたOracleホームのJARファイルは/net/wls/wls_patched.jarにあります。元のOracleホームは削除されて/u01/Oracle_Home_backupに名前が変更されます。このプロセスは失敗しても自動的に回復されません。
次のタスクのいずれかを実行するだけの場合は、rolloutJavaHomeコマンドを使用します。
新しいJavaバージョンを使用するように管理サーバーを更新します。
新しいJavaバージョンを使用するようにドメイン全体(管理サーバーおよび管理対象サーバー)を更新します。
新しいJavaバージョンを使用するように管理対象サーバーを更新します。
以前のJavaバージョンを使用するように管理サーバー、管理対象サーバーまたはドメインを回復します。
rolloutJavaHomeの構文は次のとおりです。
rolloutJavaHome(target, javaHome, [options])
このコマンドはisDryRunおよびautoRevertOnFailureオプションをサポートします。
例3-2に、新しいJavaホームをクラスタCluster1にロールアウトする方法を示します。新しいJavaホームは/u01/jdk1.8.0_50にあります。autoRevertOnFailureオプションは含まれていないので、ワークフローはプロセスが失敗すると自動的に回復します。
次のタスクのいずれかを実行するだけの場合は、rolloutUpdateコマンドを使用します。
パッチが適用されたOracleホームと新しいJavaバージョンの両方を使用するように管理サーバーを更新します。
パッチが適用されたOracleホームと新しいJavaバージョンの両方を使用するようにドメイン全体(管理サーバーおよびクラスタ化された管理対象サーバー)を更新します。
パッチが適用されたOracleホームと新しいJavaバージョンの両方を使用するように管理対象サーバーを更新します。
以前のOracleホームおよび以前のJavaバージョンを使用するように管理サーバー、管理対象サーバーまたはドメインを回復します。
rolloutUpdateの構文は次のとおりです。
rolloutUpdate(target, rolloutOracleHome, backupOracleHome, [isRollback], {javaHome], [options])
このコマンドはisDryRun、autoRevertOnFailureおよびisSessionCompatibleオプションをサポートします。
例3-3に、新しいOracleホームおよび新しいJavaホームを管理サーバーにロールアウトする方法を示します。パッチが適用されたOracleホームのJARファイルは/net/wls/wls_patched.jarにあります。元のOracleホームは削除されて/u01/Oracle_Home_backupに名前が変更されます。新しいJavaホームは/u01/jdk1.8.0_50にあります。autoRevertOnFailureオプションは含まれていないので、ワークフローはプロセスが失敗すると自動的に回復します。
次のタスクのいずれかを実行するだけの場合は、rolloutApplicationsコマンドを使用します。
1つ以上のアプリケーションの新しいバージョンを使用するように管理対象サーバーを更新します
1つ以上のアプリケーションの以前のバージョンを使用するように管理対象サーバーを回復します。
rolloutApplicationsの構文は次のとおりです。
rolloutApplications(target, applicationProperties, [options])
このコマンドはisDryRun、autoRevertOnFailureおよびisSessionCompatibleオプションをサポートします。
例3-4に、JSON形式のアプリケーション・プロパティ・ファイル/u01/scratch/app_update.jsonに定義されたアプリケーションをCluster1のすべてのサーバーにロールアウトする方法を示します。
ドメイン内のすべてのサーバー、または特定のクラスタ(1つまたは複数)内すべてのサーバーのローリング再起動を起動する場合、rollingRestartコマンドを使用します。
rollingRestartの構文は次のとおりです。
rolloutRestart(target, [options])
例3-5に、Cluster1およびCluster2のすべてのサーバーのローリング再起動を実行する方法を示します。
各ロールアウト・コマンドは、ワークフローの現在のステータスをポーリングするのに使用できるWorkFlowTaskRuntimeMBeanを返します。ロールアウトの進行状況を監視するには、ロールアウト・コマンドを次の形式で使用します。
progress=rollout_command
たとえば、新しいOracleホームのロールアウトの場合:
progress=rolloutOracleHome(DomainA, '/net/patched/wls1221p.jar', '/net/backups/wls1221', autoRevertOnFailure=FALSE)
次にWorkTaskRuntimeMBeanのメソッドを使用してワークフローに関する情報を返すことができます。詳細は、『Oracle WebLogic Server MBeanリファレンス』のBWorkTaskRuntimeMBeanに関する項を参照してください。いくつか例を挙げます。
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スクリプト・セグメントの例
次のPythonスクリプト・セグメントは、進行状況オブジェクトを使用して、ワークフローを監視し、ロールアウト・タスクの進行状況を出力する1つの方法を示します。スクリプト後のサンプルの出力を示します。
例3-6 ロールアウト・タスクの進行状況の監視および出力
# Print the starting information
rolloutName = progress.getName()
startTime = progress.getStartTime()
print "Started rollout task \"" + rolloutName + "\" at " + str(startTime)
# Check the state every 2 minutes
while not (progress.isComplete()):
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に設定されている
ワークフローが手動でキャンセルされた
回復操作中にリカバリ不能エラーが発生した。
ワークフローが停止した場合、手動でエラーを解決し、ワークフローの実行を継続または回復することができます。これを行うには、RolloutServiceで次のメソッドを使用します。
| メソッド | 説明 |
|---|---|
executeWorkflow(WorkflowTaskRuntimeMBean) |
再開できる進行状況オブジェクトを取得し、実行方向で再開します。ワークフローで最後の正常な操作が実行だった場合、実行は次の実行ステップから再開されます。ワークフローで最後の正常な操作が回復だった場合、実行はその回復ステップを実行することにより再開されます。 |
revertWorkflow(WorkflowTaskRuntimeMBean) |
再開できる進行状況オブジェクトを取得し、回復方向で再開します。ワークフローで最後の正常な操作が実行だった場合、回復はそのステップから再開されます。ワークフローで最後の正常な操作が回復だった場合、回復は回復シーケンスでその次のステップを回復することにより再開されます。 |
canResume(WorkflowTaskRuntimeMBean) |
ワークフローが完了する前に停止し、いずれの方向にも現在実行中ではない場合、trueを返します。この状態のワークフローは、実行または回復のいずれの方向にも再開できます。 |
この項では、役に立つ可能性のある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')
この項には、1つのサービス移行でcluster1という名前のクラスタ内のすべてのサーバーのローリング再起動を実行する方法を示すサンプルのWLSTスクリプトが含まれます。このスクリプトでは、次の引数が定義されています。
username—WebLogic Server管理者のユーザー名
password—WebLogic Server管理者のパスワード
adminURL—ドメインの管理サーバーのホスト名とポート番号
target—操作のターゲット。表3-1を参照してください。
options—操作のロールアウト・オプション。表3-1を参照してください
例3-7 ロールアウト操作のサンプル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"
この項では、パッチが適用されたOracleホーム、新しいJavaバージョン、新しいアプリケーション・バージョンをロールアウトする、またはこれらのタスクを組み合せた、パッチ適用ワークフローの作成と監視方法について説明します。内容は次のとおりです。
管理コンソールでZDTワークフロー機能へアクセスするには、次の手順を実行します。
管理コンソールで、「ドメイン構造」の下のドメイン名をクリックします。
「domain_nameの設定」ページで、「ZDT制御」タブを選択します。
これには4つのタブ(「ドメイン」、「クラスタ」、「サーバー」および「ワークフロー進行状況」)が表示され、ここからすべてのワークフロー関連のタスクを管理できます。
ワークフローを作成して、1つのドメイン内のすべてのサーバー、1つ以上のクラスタ内のすべてのサーバー、または選択したサーバーのみにロールアウトできます。ワークフローは、新しいJavaバージョンのロールアウト、新しいパッチ適用済Oracleホームのロールアウト、1つ以上の更新済アプリケーションのロールアウト、またはこれらの任意の組合せに対応しています。パッチ適用ワークフローを作成して、前のOracleホーム、Javaホーム、またはアプリケーション・バージョンにロールバックするか、ワークフローを作成して、サーバーのローリング再起動を実行することもできます。
この手順を実行する前に、「管理コンソールでのZDTワークフロー機能へのアクセス」で説明している「ZDT制御」タブにアクセスします。
新しいワークフローを作成するには、次の手順を実行します。
次のいずれかのタブを選択します。
ドメイン—管理サーバーおよびドメイン内のすべてのクラスタ化されたサーバー用のワークフローを作成する場合に、このタブを選択します。
クラスタ—特定のクラスタ内のサーバー用のワークフローのみを作成する場合、このタブを選択します。
サーバー—特定のサーバーのワークフローのみを作成する場合、このタブを選択します。通常、このオプションは、次のような状況でのみ選択します。
管理サーバーは、ワークフローに含まれるサーバーのみ。
管理対象サーバーが、すでに更新済のその他の管理対象サーバーと同期が取れていない状況が存在する。たとえば、新しいサーバーをクラスタに追加したものの、そのサーバーはクラスタ内の他の管理対象サーバーよりも古いバージョンのJavaを使用している場合があります。
|
注意: どうしても必要な場合以外には、「サーバー」タブを使用して個別の管理対象サーバーに更新を実行することはお薦めしません。個々の管理対象サーバーを更新する場合、セッションが維持されて停止時間が回避される保証はありません。 |
「クラスタ」タブを選択した場合、ワークフローに含めるクラスタを選択します。選択したクラスタ内のすべてのサーバーがワークフローに含まれます。
「サーバー」タブを選択した場合、ワークフローに含めるサーバーを選択します。
「パッチ」をクリックしてワークフロー・タスクを構成します。
実行するロールアウト(またはロールバック)のタイプを選択します。
Javaホーム—単に別のJavaバージョンに変更する場合に選択します。
Oracleホーム—単に新しいOracleホームをロールアウトするか、以前のOracleホームにロールバックする場合に選択します。
アプリケーション—単に1つ以上の更新済アプリケーションをロールアウトするか、1つ以上の以前のアプリケーション・バージョンにロールバックする場合に選択します。
すべての組合せ—Javaホーム、Oracleホームおよびアプリケーションの更新の任意の組合せをロールアウトまたはロールバックする場合に選択します。
ローリング再起動—選択したターゲットのローリング再起動を実行する場合に選択します。
「次」をクリックします。
表示されるフィールドとオプションは、実行するロールアウトまたはロールバックのタイプに応じて異なります。
Javaホームを変更する場合、「Javaホーム」フィールドに変更先のJavaホームへのフルパスを入力します。次に例を示します。
UNIX
/jdks/jdk1.8.0_50
Windows
C:\jdks\jdk1.8.0_50
新しいOracleホームをロールアウトするか、以前のOracleホームにロールバックする場合:
「Oracleホームのロールアウト」に、変更先のOracleホームが含まれるJARアーカイブまたはローカル・ディレクトリへのフルパスを入力します。
「Oracleホームのバックアップ」に、現在のOracleホームをバックアップするディレクトリへのフルパスを入力します。たとえば、元のOracleホームが/u01/Oracle_Homeで、このフィールドに/u01/Oracle_Home_backupを指定すると、/u01/Oracle_Homeは/u01/Oracle_Home_backupに移動します(名前が変更されます)。
以前のOracleホームにロールバックする場合、「ロールバック」チェック・ボックスを選択します。
1つ以上の新しいアプリケーション・バージョンをロールアウトする場合、「アプリケーション・プロパティ」フィールドに、アプリケーションをアップグレードするために必要な情報が含まれるJSON形式のテキスト・ファイルへのフルパスを入力します。このフィールドの作成の詳細は、「アプリケーションの更新用JSONファイルの作成」を参照してください。
パッチ適用ワークフローを実行する前にその評価のみを行う場合、「テスト実行」チェック・ボックスを選択します。
JTAまたはJMSなどのシングルトン・サービスを移行する場合は、ロールアウト時に、移行のプロパティ・フィールドに、移行情報を含むJSON形式のファイルのフルパスを入力します。このファイルの作成の詳細は、「シングルトン・サービスへの移行の準備」を参照してください。
デフォルトで、「失敗時の自動回復」チェック・ボックスが選択済です。これにより、ワークフローの実行中に障害が発生した場合、パッチ適用操作によってすべての処理が自動的に回復されます。このチェック・ボックスの選択を解除すると、障害が発生してもパッチ適用は自動的に回復されません(操作は停止し、ユーザーが再開または回復操作をするまで待機します)。
「セッション互換性」オプションは、クラスタで最後に更新されているサーバーが、そのサーバー上でセッションの完了を待機するかどうかを決定します。
選択されていない場合、クラスタ内の最後のサーバーはセッションの完了を待機します。これにより、まだ既存のバージョンで実行されている管理対象サーバーによって処理される必要のあるセッションは、クラスタ内の互換サーバーを使用して処理されることが保証されます。
選択されている場合は、既存バージョンと新規バージョンとの間でサーバーのセッション状態が完全に互換していることを示します。したがって、クラスタ内で更新順序が最後の管理対象サーバーは、既存のセッションがすべて完了するのを待機せずに停止します。
セッション状態が実質的に同一であることが保証されないかぎり、このオプションは選択しないことをお薦めします。これにより、セッション完了の待機が原因でロールアウトに時間がかかる可能性があります。デフォルトのセッション・タイムアウト値は1時間です。
|
注意: WebLogic Serverシリアライゼーション/デシリアライゼーションはJavaシリアライゼーション/デシリアライゼーションとは若干異なります。したがって、クラスにフィールドを追加すると、セッションが新しいバージョンのサーバーとの互換性を失い、既存バージョンのサーバーがクラスを処理する必要が生じる場合があります。たとえば、UserクラスにInformationなどのフィールドを追加すると、バージョン間でセッションの互換性が失われます。 |
「終了」をクリックしてパッチ適用ワークフローを開始します。
ワークフローが「ワークフロー進行状況」表に追加されます。
ワークフローが開始されると、「ワークフローの監視と管理」で説明されているように、「ワークフロー進行状況」ページからその進行状況を監視および管理できます。
この項では、すべての実行中および完了したワークフローの進行状況を監視および管理する方法について説明します。
この手順を実行する前に、まだ実行していなければ、「管理コンソールでの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)をクリックします。ページには、表3-2に示す情報が表示されます。
表3-2 ワークフローの進行状況の詳細フィールド
| フィールド | 説明 |
|---|---|
|
ワークフローID |
作成時に自動的に割り当てられたワークフロー。 |
|
タイプ |
ワークフローのタイプで、次のいずれかです。
|
|
ターゲット |
ワークフローがターゲット指定されるサーバーで、次のいずれかです。
|
|
ステータス |
ワークフローの現在のステータス。詳細は、「ワークフローのステータス」を参照してください。 |
|
再開可能 |
ワークフローが再開可能または回復可能かどうかを示します。falseの場合、ワークフローで「実行」または「回復」機能を使用できません。 |
|
# 完了コマンド |
現在完了しているワークフロー・コマンドの数。 |
|
# 合計コマンド |
ワークフローを完了するために実行が必要なワークフロー内のコマンドの合計数。 |
|
進行状況の文字列 |
次のような、ワークフローの進行状況の詳細メッセージ。 ワークフローwf0008は正常に終了しました。36ステップが完了しました。 |
|
次の実行ステップ |
ワークフローがアクティブなままで回復中でない場合、このフィールドには現在のコマンドが完了すると実行される次のコマンドが表示されます。 |
|
次の回復ステップ |
ワークフローがアクティブなままで回復中でない場合、このフィールドには現在のコマンドが完了すると回復プロセスで実行される次のコマンドが表示されます。 |
|
開始時刻 |
ワークフローが起動した時刻。 |
|
終了時刻 |
ワークフローが完了すると、このフィールドにはその完了時刻が表示されます。 |
|
例外 |
ワークフローが失敗すると、このフィールドには失敗したときに発生した例外が表示されます。 |
|
詳細 |
矢印をクリックして「詳細」セクションを展開します。ここには現在の時間までにワークフローで実行されたすべてのステップが表示されます。ワークフローが完了すると、このセクションにはワークフローにより完了したすべてのコマンドがリストされます。 |
アクティブなワークフローのステータスは、次の表に示すいずれかです。
表3-3 アクティブなワークフローのステータス
| ステータス | 説明 |
|---|---|
|
STARTED |
ワークフローは開始されて現在実行中です。 |
|
RETRY |
停止されたワークフローが再開されています。 |
|
REVERTING |
失敗または停止されたワークフローが回復中です。 |
|
FAIL |
ワークフローが完全に実行できませんでした。このステータスは、「失敗時の自動回復」オプションが開始時にワークフローに構成されていなかった場合にのみ現れます。 |
|
REVERTED |
自動または手動で回復されたワークフローが正常に回復プロセスを完了しました。 |
|
REVERT_FAIL |
自動または手動で回復されたワークフローが正常に回復できませんでした。 |
|
CANCELED |
ワークフローが取り消されました(一時停止しました)。 |
|
REVERT_CANCELED |
自動または手動で回復されたワークフローが取り消されました(一時停止しました)。 |
ロールアウトは一連のステップで構成されています。各ステップは、開始および終了時に、管理サーバー・ログにメッセージを記録します。ステップの回復、失敗または再試行の場合もメッセージが記録されます。管理サーバーのログの場所は次のとおりです。
domain_home/servers/AdminServer/logs
ワークフローIDが指定したワークフローに関連する各ログ・メッセージに含まれており、指定したワークフローに関連するメッセージに対し管理サーバーのログ・ファイルを簡単にフィルタリングできるようにしています。管理コンソールからワークフローを起動した場合、「ZDT制御」>「ワークフロー進行状況」タブからワークフローIDを取得できます。WLSTから、次のコマンドを使用してワークフローIDを取得できます。
progress.getWorkflowId()
ログ・ファイルをフィルタリングするには、次のコマンドを入力します。
fgrep domain_home/servers/AdminServer/logs/AdminServer.log
次の表に、ZDTパッチ適用のログ・メッセージの形式を示します。
表3-4 ZDTパッチ適用のログ・メッセージの形式
| メッセージ・タイプ | メッセージの形式 |
|---|---|
|
ステップが実行を開始 |
|
|
ステップが完了 |
|
|
ステップが回復中 |
|
|
ステップが正常に回復済 |
|
|
ステップが再試行中 |
|
|
ステップが正常に完了できなかった |
|
|
ステップが例外のため正常に完了できなかった |
|
|
ステップが正常に回復できなかった |
|
|
ステップが例外のため正常に回復できなかった |
|
