この章では、管理対象サーバーをパッチが適用されたOracleホームに移動、管理対象サーバーのJavaバージョンを更新、管理対象サーバーのアプリケーションを更新、またはこれらの更新タスクを組み合せた、パッチ適用ワークフローの構成と監視方法について説明します。
注意:
更新プロセスを開始する前に、ダウンタイムなしのパッチ適用の準備に従って、実行中の更新のタイプに応じた適切な準備手順をすべて完了しておく必要があります。
Windowsベースのドメインの場合、Oracleホームを更新するワークフローを開始する前に、各ノードで、更新されるOracleホームにロックされているディレクトリまたはファイルがないことを確認します。これがあると、指定したバックアップ・ディレクトリにOracleホームを移動できない可能性があるためです。ディレクトリはDOSコマンド・ウィンドウをそのディレクトリで開くという程度の簡単なことでロックできます。ファイルはそのファイルをアプリケーションで開くことによってロックできます。
ターゲット・クラスタにロールアウトする前に、パッチが適用されたOracleホームを最初に管理サーバーにロールアウトする必要があります。2つの順次ワークフローを使用して、または1つのワークフローを使用してこれを実行できます。
WLSTまたは管理コンソールのいずれかを使用して新しいOracleホームをロールアウトするときには、パッチが適用されたOracleホームが最初に管理サーバーにロールアウトされるようにする必要があります。これを行うには2つの方法があります。
1つのワークフローを使用してパッチ適用済Oracleホームを管理サーバーにロールアウトし、次に2つ目のワークフローを使用してパッチ適用済Oracleホームをクラスタにロールアウトします。この手法の使用をお薦めしますが、必須ではありません。
このシナリオでは、次のようになります。
WLSTを使用している場合、rolloutOracleHome
またはrolloutUpdate
コマンドのいずれかを実行し、ターゲットとして管理サーバー名を指定します。次にrolloutOracleHome
またはrolloutUpdate
を再度実行し、クラスタ・ターゲットを指定します。
WebLogic Server管理コンソールを使用している場合、「サーバー」タブから1つのワークフローを作成し、ターゲットとして管理サーバーを選択します。そのワークフローが完了したら、「クラスタ」タブから2つ目のワークフローを作成し、含めるクラスタを選択します。
1つのワークフローのみを使用してパッチ適用済Oracleホームをドメイン全体にロールアウトします。ワークフローは、パッチが適用されたOracleホームを、ターゲット・クラスタにロールアウトする前に最初に自動的にロールアウトします。
このシナリオでは、次のようになります。
WLSTを使用している場合、rolloutOracleHome
またはrolloutUpdate
コマンドのいずれかを実行し、ターゲットとしてドメイン名を指定します。
管理コンソールを使用している場合、「ドメイン」タブから1つのワークフローを作成します。
ロールアウト操作を開始する前に、ノード・マネージャを使用して管理サーバーを起動することが重要です。管理サーバーについて構成されたノード・マネージャがない場合は、startWebLogic
スクリプトを使用することで管理サーバーを起動できます。
管理サーバーがワークフローに含まれる場合、startWebLogic
スクリプトまたはノード・マネージャを使用して管理サーバーを起動できます。ロールアウトのために指定したターゲットがドメインである場合、管理サーバーは、ロールアウト操作の間に自動的に再起動されます。ただし、ロールアウト操作によって管理サーバーが再起動されるときに、WLSTまたは管理サーバーのどちらにも接続できないと、短いダウンタイムが発生する場合があります。回避策として、ロールアウト操作の進行状況に関して更新を受け取るために、管理サーバーがRUNNING状態に達したときに、待機してから再接続する必要があります。
ロールアウト操作を開始する前に管理サーバーを起動するには、次のいずれかの方法で管理サーバーを起動します。
startWebLogic
スクリプトの使用
管理サーバーについて構成されたノード・マネージャがない場合は、startWebLogic
スクリプトを使用することで管理サーバーを起動できます。このスクリプトを使用して管理サーバーを起動するには、『Oracle WebLogic Serverサーバーの起動と停止の管理』の起動スクリプトによる管理サーバーの起動を参照してください。
ノード・マネージャの使用
ノード・マネージャが管理サーバーのために構成されている場合は、ノード・マネージャを使用して管理サーバーを起動する必要があります。ノード・マネージャを使用して管理サーバーを起動するには、次の手順を実行します。
『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャを使用した管理サーバーの起動に関する項を参照してください。
OPatchAutoツールを使用して、パッチが適用されたOracleホームをドメインのノードに適用する、ロールアウト・ワークフローを自動化できます。OPatchAutoを使用して、ロールアウトを起動、回復および再開できます。
次の項では、パッチが適用されたOracleホームをドメインのノードに適用する、ロールアウト・ワークフローの起動および監視方法について説明します。この手法は、パッチが適用されたOracleホームにワークフローが適用される場合にのみ使用できます。Javaバージョンの更新またはアプリケーションの更新をワークフローに含める場合、WLSTまたは管理コンソールを使用する必要があります。
注意:
OPatchAutoを使用してワークフローを起動する場合、管理コンソールを使用してワークフローの進行状況を監視する必要があります。「ワークフローの監視と管理」を参照してください
次のコマンドを使用して、OPatchAutoを使用するワークフローを起動します。
cd ORACLE_HOME/OPatch/auto/core/bin opatchauto.sh apply -plan wls-zdt -image-location path -wls-admin-host adminserver:port -wls-target target -remote-image-location path -wallet path -walletPassword password
次の表に、opatchauto apply
コマンドにおけるパラメータを示します。
パラメータ | 説明 |
---|---|
|
|
|
ロールアウトに使用する、パッチ適用済Oracleホームを含むイメージJARファイルのフルパスと名前を指定します。次に例を示します。
|
|
パッチが適用されたOracleホームのロールアウト先のドメインの、管理サーバーのホスト名とポート番号を指定します。 |
|
アーカイブをロールアウトしている場合、ロールアウトに使用しているアーカイブを配布したときに指定したのと同じターゲットを指定する必要があります。 |
|
既存のOracleホームをバックアップするのに使用するディレクトリへのフルパス。次に例を示します。
|
|
ZDTロールアウトに含まれる各ノードに作成するアーカイブ・ファイルへのフルパス。これは、元のアーカイブと同じファイル名である必要はありません。次に例を示します。
|
|
|
|
必要な場合、指定したウォレットのパスワード。次に例を示します。
|
Oracleホームのロールアウトに失敗して再開する場合、次のコマンドを使用します。
cd ORACLE_HOME/OPatch/auto/core/bin opatchauto.sh resume -session workflow_id -walletPassword password
次の表に、opatchauto resume
コマンドにおけるパラメータを示します。
パラメータ | 説明 |
---|---|
|
ロールバックするワークフローのワークフローIDを指定します。 |
|
|
|
必要な場合、指定したウォレットのパスワード。次に例を示します。
|
OPatchAutoを使用して、完了したワークフローを回復させるだけでなく、失敗または停止したロールアウトを回復させることができます。ロールアウトが失敗または停止した場合、OPatchAutoは最後に正常に完了した手順から回復を開始します。ロールアウトが完了すると、OPatchAutoは、ロールアウトするOracleホームとしてバックアップ済Oracleホームを使用して、新しいロールアウトを開始します。
次のコマンドを使用してロールアウトを回復します。
cd ORACLE_HOME/OPatch/auto/core/bin opatchauto.sh rollback -session workflow_id -walletPassword password
次の表に、opatchauto rollback
コマンドにおけるパラメータを示します。
パラメータ | 説明 |
---|---|
|
ロールバックするワークフローのワークフローIDを指定します。 |
|
|
|
必要な場合、指定したウォレットのパスワード。次に例を示します。
|
WLSTには、パッチが適用されたOracleホーム、新しいJavaバージョンまたは両方の組合せ、あるいは新しいアプリケーション・バージョンをロールアウトするために使用できる一連のZDTパッチ適用コマンドが含まれます。
この項では、ワークフローを起動して管理対象サーバー、パーティションまたはリソース・グループを更新するのに使用できるWLSTコマンドについて説明し、様々なワークフロー(ロールアウト)シナリオを示すサンプルのWLSTスクリプトを提供します。
注意:
WLST rolloutOracleHome
または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つずつ正常にシャットダウン。これには、現在ADMINまたはSTANDBYモードの管理対象サーバーは含まれません。migrationProperties
オプションがロールアウト・コマンドに含まれている場合、これにはシングルトン・サービスの移行が含まれます。パーティションまたはリソース・グループへのアプリケーション更新のロールアウトでは、ADMINモードおよびSTANDBYモードはサポートされていません。
Oracleホーム・ディレクトリの置換(必要な場合)
Javaホーム・ディレクトリの置換(必要な場合)
アプリケーション・ディレクトリの置換(必要な場合)
ノードでのノード・マネージャの再起動
ノードでの管理対象サーバーの再起動
表3-1では、WLSTrollout
コマンドで使用可能なパラメータを示します。
表3-1 WLSTロールアウト・コマンドの引数
引数 | 説明 |
---|---|
|
すべての 更新に含める管理対象サーバー、パーティションまたはリソース・グループを指定します。
注意: 通常、管理サーバーの更新時にのみ、サーバー・ターゲットを指定する必要があります。個々の管理対象サーバーの更新は、セッションが維持されずに、ユーザーの停止時間を回避できない可能性があるため、ほとんどの場合でお薦めできません。ただし、安全に管理対象サーバー・ターゲットを指定できるような状況として、1つ以上の新しい管理対象サーバーを追加してあり、それらがその他の管理対象サーバーと同じJavaバージョンではない場合があります。 |
|
ロールアウトするOracleホームのアーカイブ(JARファイル)またはローカルのOracleホーム・ディレクトリを指定し、その結果、既存のOracleホームを置き換えます。 |
|
既存のOracleホームの移動先となるディレクトリのフルパスを指定します。これにより、元のOracleホームの名前が効率的に変更されます。たとえば、元のOracleホームが |
|
オプション。 |
|
使用する新しいJavaホームの場所を指定します。 |
|
1つ以上のアプリケーション名、アプリケーション・アーカイブの場所およびアプリケーション・バックアップの場所を定義するJSONファイルへのフルパスを指定します。 |
|
次のオプションを
|
WLSTを使用してワークフローの進行状況を監視することもできます。「ワークフローの進行状況の監視」を参照してください。
次のタスクのいずれかを実行するだけの場合は、rolloutOracleHome
コマンドを使用します。
パッチが適用されたOracleホームを使用するように管理サーバーを更新します。
パッチが適用されたOracleホームを使用するようにドメイン全体(管理サーバーおよびクラスタ化された管理対象サーバー)を更新します。
パッチが適用されたOracleホームを使用するように、クラスタ化された管理対象サーバーを更新します。
以前のパッチ未適用のOracleホームを使用するように管理サーバー、クラスタ化された管理対象サーバーまたはドメインの更新を取り消します。
rolloutOracleHome
の構文は次のとおりです。
rolloutOracleHome(target, rolloutOracleHome, backupOracleHome, [isRollback], [options])
このコマンドはisDryRun
、autoRevertOnFailure
およびisSessionCompatible
オプションをサポートします。これらのオプションの詳細は、WLSTを使用したワークフローの起動と監視を参照してください。
次の例では、新しいOracleホームをドメインmydomain
にロールアウトする方法を示します。パッチ適用済のOracleホームのJARファイルは、/net/wls/wls_patched.jar
にあります。元のOracleホームは/u01/Oracle_Home_backup
に移動(名前変更)されます。このプロセスは失敗しても自動的に回復されません。
connect('adminname', 'adminpassword', 't3://hostname:port') domain='/domains/mydomain' progress=rolloutOracleHome(domain, '/net/wls/wls_patched.jar', '/u01/Oracle_Home_backup', autoRevertOnFailure=FALSE)
注意:
新しいOracleホームのロールアウト時は、rolloutOracleHome
コマンドでのローカルOracleホーム・ディレクトリの指定はサポートされていません。「ZDTパッチ適用の制限」を参照してください。 次のタスクのいずれかを実行するだけの場合は、rolloutJavaHome
コマンドを使用します。
新しいJavaバージョンを使用するように管理サーバーを更新します。
新しいJavaバージョンを使用するようにドメイン全体(管理サーバーおよび管理対象サーバー)を更新します。
新しいJavaバージョンを使用するように管理対象サーバーを更新します。
以前のJavaバージョンを使用するように管理サーバー、管理対象サーバーまたはドメインを回復します。
rolloutJavaHome
の構文は次のとおりです。
rolloutJavaHome(target, javaHome, [options])
このコマンドはisDryRun
およびautoRevertOnFailure
オプションをサポートします。これらのオプションの詳細は、WLSTを使用したワークフローの起動と監視を参照してください。
次の例では、新しいJavaホームをクラスタCluster1
、Cluster2
、Cluster3
にロールアウトする方法を示します。新しいJavaホームの場所は/u01/jdk1.8.0_50
です。この例ではautoRevertOnFailure
オプションは含まれていないため、ワークフローはプロセスが失敗すると自動的に回復します。
connect('adminname', 'adminpassword', 't3://hostname:port') clusters='Cluster1,Cluster2,Cluster3' progress=rolloutJavaHome(clusters, '/u01/jdk1.8.0_50')
次のタスクのいずれかを実行するだけの場合は、rolloutUpdate
コマンドを使用します。
パッチが適用されたOracleホームと新しいJavaバージョンの両方を使用するように管理サーバーを更新します。
パッチが適用されたOracleホームと新しいJavaバージョンの両方を使用するようにドメイン全体(管理サーバーおよびクラスタ化された管理対象サーバー)を更新します。
パッチが適用されたOracleホームと新しいJavaバージョンの両方を使用するように管理対象サーバーを更新します。
以前のOracleホームおよび以前のJavaバージョンに管理サーバー、管理対象サーバーまたはドメインを回復します。
rolloutUpdate
の構文は次のとおりです。
rolloutUpdate(target, rolloutOracleHome, backupOracleHome, [isRollback], [javaHome], [options])
このコマンドはisDryRun
、autoRevertOnFailure
およびisSessionCompatible
オプションをサポートします。これらのオプションの詳細は、WLSTを使用したワークフローの起動と監視を参照してください。
次の例では、新しいOracleホームおよび新しいJavaホームを管理サーバーにロールアウトする方法を示します。パッチ適用済のOracleホームのJARファイルは、/net/wls/wls_patched.jar
にあります。元のOracleホームは/u01/Oracle_Home_backup
に移動(名前変更)されます。新しいJavaホームの場所は/u01/jdk1.8.0_50です。この例ではautoRevertOnFailure
オプションは含まれていないため、ワークフローはプロセスが失敗すると自動的に回復します。
connect('adminname', 'adminpassword', 't3://hostname:port') server='AdminServer' progress=rolloutUpdate(server, '/net/wls/wls_patched.jar', '/u01/Oracle_Home_backup', '/u01/jdk1.8.0_50')
次のタスクのいずれかを実行する場合は、rolloutApplications
コマンドを使用します。
1つ以上のアプリケーションの新しいバージョンを使用するように管理対象サーバーを更新します
1つ以上のアプリケーションについて以前のバージョンに管理対象サーバーを回復します。
1つ以上のアプリケーションの新しいバージョンを使用するようにパーティションを更新します。
1つ以上のアプリケーションの新しいバージョンを使用するようにリソース・グループを更新します
rolloutApplications
の構文は次のとおりです。
rolloutApplications(target, applicationProperties, [options])
このコマンドはisDryRun
、autoRevertOnFailure
およびisSessionCompatible
オプションをサポートします。これらのオプションの詳細は、WLSTを使用したワークフローの起動と監視を参照してください。
次の例では、JSON形式のアプリケーション・プロパティ・ファイル/u01/scratch/app_update.json
に定義されたアプリケーションをUNIXシステム上のすべてのクラスタCluster1
、Cluster2
、Cluster3
にロールアウトする方法を示します。
connect('adminname', 'adminpassword', 't3://hostname:port') clusters='Cluster1,Cluster2,Cluster3' progress=rolloutApplications(clusters, '/u01/scratch/app_update.json')
ロールアウトが正常に完了した後に、前のOracleホーム、Javaホームまたはアプリケーション・バージョンにロールバックする場合は、次の2つの手順を実行してロールバック操作を完了する必要があります。
rolloutUpdate
コマンドを使用して、前のOracleホームおよびJavaホームにロールバックします。ただし、rolloutUpdate
コマンドを実行してロールバックする前に、次の制限事項に留意する必要があります。
ロールアウトするOracleホーム・ディレクトリとしてバックアップ済Oracleホームを指定する必要があります。このディレクトリは、前のロールアウトからのバックアップ・ディレクトリである必要があります。
ロールバック先のOracleホーム・ディレクトリとしてバックアップ済Oracleホーム・ディレクトリを指定した後は、そのコマンドで新しいJavaホームを指定しないでください。Javaホームは、ロールバック先として指定した前のOracleホームで使用されていた、元のJavaホームに自動的にロールバックされます。
rolloutApplications
コマンドを使用して、jsonファイルで古いアプリケーション・アーカイブを指定することで、前のアプリケーション・バージョンにロールバックします。このコマンドの使用の詳細は、更新されたアプリケーションのロールアウトを参照してください
次の例では、前のOracleホーム、Javaホームおよびアプリケーションにロールバックする方法を示します。この例では、myDomain
はロールバック先となるドメインの名前、/pathto/unpatchedOracleHomeBackup/
は前のロールアウトからのバックアップOracleホーム・ディレクトリの場所、/pathto/unpatchedOracleHomeBackup1/
は既存Oracleホームの移動先となるディレクトリのパスです。ロールバック操作を可能にするには、例で示すように、isRollback
パラメータをtrue
に設定する必要があります。
rolloutUpdate('myDomain', '/pathto/unpatchedOracleHomeBackup/', '/pathto/unpatchedOracleHomeBackup1/', 'true')
次のタスクのいずれかを実行する場合は、rollingRestart
コマンドを使用します。
ドメイン内のすべてのサーバーのローリング再起動の開始
特定のクラスタ(1つまたは複数)内のすべてのサーバーのローリング再起動の開始
サーバー上のクラスタ内のすべてのパーティションのローリング再起動の開始
パーティションのローリング再起動では、各サーバー上のクラスタ内のパーティションが、そのクラスタまたはサーバーを超えてその他のパーティションに影響を与えることのない方法で、順次再起動されます。WebLogic Server管理者およびパーティション管理者の両者が、サーバー上のパーティションのローリング再起動を実行できます。
rollingRestart
の構文は次のとおりです。
rolloutRestart(target, [options])
次の例では、Cluster1
およびCluster2
内のすべてのサーバーのローリング再起動を実行する方法を示します。
connect('adminname', 'adminpassword', 't3://hostname:port') clusters='Cluster1,Cluster2' progress=rollingRestart(clusters)
各ロールアウト
・コマンドは、ワークフローの現在のステータスをポーリングするのに使用できるWorkFlowTaskRuntimeMBean
を返します。ロールアウトの進行状況を監視するには、rollout
コマンドを次の形式で使用します。
progress=rollout_command
たとえば、新しいOracleホームのロールアウトの場合は、このコマンドを使用します。
progress=rolloutOracleHome(DomainA, '/net/patched/wls1221p.jar', '/net/backups/wls1221', autoRevertOnFailure=FALSE)
次に、WorkflowTaskRuntimeMBean
のメソッドを使用してワークフローに関する情報を返すことができます。Oracle WebLogic Server MBeanリファレンスのWorkflowTaskRuntimeMBeanに関する項
を参照してください。いくつか例を挙げます。
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スクリプト・セグメントは、進行状況オブジェクトを使用して、ワークフローを監視し、ロールアウト・タスクの進行状況を出力する1つの方法を示します。スクリプト後のサンプルの出力を示します。
# Print the starting information
rolloutName = progress.getName()
startTime = progress.getStartTime()
print "Started rollout task \"" + rolloutName + "\" at " + str(startTime)
# Check the state every 2 minutes
domainRuntime()
cd('RolloutService/rollout-service/ActiveWorkflows')
cd(progress.getWorkflowId())
while(get('Running')==1):
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
に設定されている
ワークフローが手動でキャンセルされた
回復操作中にリカバリ不能エラーが発生した。
ワークフローが停止した場合は、手動でエラーを解決できます。その後、RolloutServiceRuntimeMBean
で次のメソッドを使用することで、実行または回復を続行するよう、ワークフローを設定できます。
メソッド | 説明 |
---|---|
|
再開できる進行状況オブジェクトを取得し、実行方向で再開します。ワークフローで最後の正常な操作が実行だった場合、実行は次の実行ステップから再開されます。ワークフローで最後の正常な操作が回復だった場合、実行はその回復ステップを実行することにより再開されます。 |
|
再開できる進行状況オブジェクトを取得し、回復方向で再開します。ワークフローで最後の正常な操作が実行だった場合、回復はそのステップから再開されます。ワークフローで最後の正常な操作が回復だった場合、回復は回復シーケンスでその次のステップを回復することにより再開されます。 |
|
ワークフローが完了する前に停止し、いずれの方向にも現在実行中ではない場合、 |
この項では、役に立つ可能性のある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を参照してください。
次の例では、ロールアウト操作のためのサンプル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バージョン、新しいアプリケーション・バージョンをロールアウトするパッチ適用ワークフロー、またはこれらのタスクを組み合せたパッチ適用ワークフローを作成および監視します。
この項では、次の項目について説明します。
ワークフローを作成して、1つのドメイン内のすべてのサーバー、1つ以上のクラスタ内のすべてのサーバー、または選択したサーバーのみにロールアウトできます。ワークフローは、新しいJavaバージョンのロールアウト、新しいパッチ適用済Oracleホームのロールアウト、1つ以上の更新済アプリケーションのロールアウト、またはこれらの任意の組合せに対応しています。パッチ適用ワークフローを作成して、前のOracleホーム、Javaホームまたはアプリケーション・バージョンにロールバックするか、ワークフローを作成して、サーバーのローリング再起動を実行することもできます。
この手順を実行する前に、WebLogic Server管理コンソールでの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ホームのロールアウト」に、JARアーカイブへのフルパスを入力します。前のOracleホームにロールバックしている場合のみ、ロールバック先となるOracleホームを含むローカル・ディレクトリへのパスを指定できます。前のOracleホームへのロールバックの詳細は、前のOracleホーム、Javaホームまたはアプリケーションへの回復を参照してください。
「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などのフィールドを追加すると、バージョン間でセッションの互換性が失われます。
「終了」をクリックしてパッチ適用ワークフローを開始します。
ワークフローが「ワークフロー進行状況」表に追加されます。
ワークフローが開始されると、ワークフローの監視と管理で説明されているように、「ワークフロー進行状況」ページからその進行状況を監視および管理できます。
この項では、すべての実行中および完了したワークフローの進行状況を監視および管理する方法について説明します。
この手順を実行する前に、まだ実行していなければ、WebLogic Server管理コンソールでの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)をクリックします。ページには、次の表に示す情報が表示されます。
フィールド | 説明 |
---|---|
ワークフローID |
作成時に自動的に割り当てられたワークフロー |
タイプ |
ワークフローのタイプで、次のいずれかです。
|
ターゲット |
ワークフローがターゲット指定されるサーバーで、次のいずれかです。
|
ステータス |
ワークフローの現在のステータス。「ワークフローのステータス」を参照してください。 |
再開可能 |
ワークフローが再開可能または回復可能かどうかを示します。falseの場合、ワークフローで「実行」または「回復」機能を使用できません。 |
# 完了コマンド |
現在完了しているワークフロー・コマンドの数 |
# 合計コマンド |
ワークフローを完了するために実行が必要なワークフロー内のコマンドの合計数 |
進行状況の文字列 |
次のような、ワークフローの進行状況の詳細メッセージ。 ワークフローwf0008は正常に終了しました。36ステップが完了しました。 |
次の実行ステップ |
ワークフローがアクティブなままで回復中でない場合、このフィールドには、現在のコマンドが完了すると実行される、次のコマンドが表示されます。 |
次の回復ステップ |
ワークフローがアクティブなままで回復中の場合、このフィールドには、現在のコマンドが完了すると回復プロセスで実行される、次のコマンドが表示されます。 |
開始時刻 |
ワークフローが起動した時刻 |
終了時刻 |
ワークフローが完了すると、このフィールドには、その完了時刻が表示されます。 |
例外 |
ワークフローが失敗すると、このフィールドには、失敗したときに発生した例外が表示されます。 |
詳細 |
矢印をクリックして「詳細」セクションを展開します。ここには現在の時間までにワークフローで実行されたすべてのステップが表示されます。ワークフローが完了すると、このセクションには、ワークフローにより完了したすべてのコマンドがリストされます。 |
「サーバー」ページから、ワークフローの実行前後およびワークフローが進行中のすべてのサーバーの現在のステータスを表示できます。「サーバー」タブをクリックすると、ドメイン内の各サーバーのワークフロー関連の情報を表示できます。「サーバー」表の列、および表に追加できる列の詳細は、管理コンソール・オンライン・ヘルプのサーバーのパッチ適用ステータスの表示を参照してください
ワークフローが実行中の場合、このページの情報を監視およびリフレッシュして、各サーバーの最新のステータスを取得できます。
アクティブなワークフローのステータスは、次のいずれかです。
ステータス | 説明 |
---|---|
STARTED |
ワークフローは開始されて現在実行中です。 |
RESUME |
停止されたワークフローが再開されています。 |
REVERTING |
失敗または停止されたワークフローが回復中です。 |
FAIL |
ワークフローが完全に実行できませんでした。このステータスは、「失敗時の自動回復」オプションが開始時にワークフローに構成されていなかった場合にのみ現れます。 |
REVERTED |
自動または手動で回復されたワークフローが正常に回復プロセスを完了しました。 |
REVERT_FAIL |
自動または手動で回復されたワークフローが正常に回復できませんでした。 |
CANCELED |
ワークフローが取り消されました(一時停止しました)。 |
REVERT_CANCELED |
自動または手動で回復されたワークフローが取り消されました(一時停止しました)。 |
ロールアウトは一連のステップで構成されています。各ステップは、開始および終了時に、管理サーバー・ログにメッセージを記録します。ステップの回復、失敗または再試行の場合もメッセージが記録されます。管理サーバーのログの場所は次のとおりです
domain_home
/servers/AdminServer/logs
ワークフローIDは、指定されたワークフローに関連するすべてのログ・メッセージに含まれています。指定されたワークフローに関連するメッセージで管理サーバーのログ・ファイルをフィルタするには、ワークフローIDを使用します。WebLogic Server管理コンソールからワークフローを起動した場合、「ZDT制御」>「ワークフロー進行状況」タブからワークフローIDを取得できます。WLSTから、次のコマンドを使用してワークフローIDを取得できます。
progress.getWorkflowId()
ログ・ファイルをフィルタリングするには、次のコマンドを入力します。
fgrep
wf0001
domain_home
/servers/AdminServer/logs/AdminServer.log
ZDTパッチ適用のログ・メッセージは、次のようにフォーマットされます。
メッセージ・タイプ | メッセージの形式 |
---|---|
ステップが実行を開始 |
|
ステップが完了 |
|
ステップが回復中 |
|
ステップが正常に回復済 |
|
ステップが再試行中 |
|
ステップが正常に完了できなかった |
|
ステップが例外のため正常に完了できなかった |
|
ステップが正常に回復できなかった |
|
ステップが例外のため正常に回復できなかった |
|