1. Oracle WebLogic Serverのアップグレード
  2. WebLogicドメインの再構成

3 WebLogicドメインの再構成

再構成ウィザードを使用して、Oracle WebLogic Server 10.3.1以降、またはOracle WebLogic Server 12.1.1以降を使用して作成されたWebLogic Serverドメインをアップグレードできます。

再構成ウィザードを実行して、WebLogic Serverドメインを再構成する場合は、ドメインのアプリケーションによって、次の項目が自動的に更新されます。

  • WLSコア・インフラストラクチャ

  • ドメイン・バージョン

ノート:

再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。アプリケーションのアップグレード方法の詳細は、「WebLogic Server 14.1.1.0.0の旧リリースとの互換性」を参照してください。

再構成ウィザードを使用してWebLogic Serverドメインを再構成する方法を学習します。

始める前に

再構成ウィザードを実行する前に、必要に応じて、ドメインがWebLogic Server 10.3.6のバージョンにアップグレードされていることを確認します。次に、CONFIG_JVM_ARGS環境変数の設定、ドメインのバックアップ、アップグレードしたドメインとともに使用するノード・マネージャの構成の選択など、追加のタスクを実行します。

WebLogic Server 10.3.0より前に作成されたドメインのアップグレード

WebLogic Serverバージョン10.3.0以降で作成されたドメインは、直接バージョン14.1.1.0.0にアップグレードできます。ただし、ドメインがWebLogic Server 10.3.0より前のバージョンで作成されている場合には、最初にWebLogic Server 10.3.6にアップグレードする必要があります。

WebLogic Server 10.3.6にアップグレードした後、ドメイン・アップグレード・ウィザードを実行して、http://docs.oracle.com/cd/E23943_01/web.1111/e13754/toc.htmドメインをアップグレードします。

WebLogic Server 10.3.6へのアップグレードおよびドメイン・アップグレード・ウィザードの実行の詳細は、『Oracle WebLogic Serverアップグレード・ガイド(10.3.6)』を参照してください。

UNIXおよびLinuxシステムでのCONFIG_JVM_ARGSの設定

再構成ウィザードを実行してUNIXまたはLinuxオペレーティング・システムのドメインを再構成する前に、オペレーティング・システムの乱数ジェネレータを使用するためにCONFIG_JVM_ARGS環境変数を次の値に設定します(まだ設定していない場合)。

-Djava.security.egd=file:/dev/./urandom

これにより、再構成ウィザードでドメインを再構成するのにかかる時間が短縮されます。

ドメインのバックアップ

再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。たとえば、C:\domains\mydomainをC:\domains\mydomain_backupにコピーします。

各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。

ドメインの再構成がなんらかの理由で失敗した場合は、再構成を実行する前に、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーしてドメインを完全に元の状態に戻す必要があります。

ノード・マネージャのアップグレード手順の決定

WebLogic Server 12.1.2より前では、デフォルト起動スクリプトおよびデフォルトのノード・マネージャ・ホームの場所を使用して、WebLogic Serverによってデフォルトのノード・マネージャ構成が指定されていました。デフォルトでは、そのマシン上で作成された新規ドメインは、デフォルトのノード・マネージャの場所でノード・マネージャに関連付けられていました。一般に、これはホストごとのノード・マネージャと呼ばれます。

WebLogic Server 12.1.2から、ノード・マネージャのデフォルト構成は、ドメインごとのノード・マネージャ構成になりました。つまり、ノード・マネージャ構成は特定のドメインに固有です。この構成により、指定されたマシン上の複数のドメインが、異なるノード・マネージャ構成を持つことができます。『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャのデフォルト構成に関する項を参照してください。

upgrade_dom.html#GUID-A6EDAE8B-72FE-44A0-9E4B-7882001D1E7C__CHDEDGFAは、WebLogic Serverを12.1.1以前のバージョンから現行バージョンにアップグレードする場合、または12.1.2以降のバージョンから現行バージョンにアップグレードする場合の、サポートされているノード・マネージャのアップグレード・パスを示しています。このコンテキストでホストごととは、ドメインごとのノード・マネージャ構成以外のノード・マネージャ構成を意味します。

表3-1 サポートされているノード・マネージャのアップグレード・パス

ノード・マネージャのアップグレード・パス WebLogic Server 12.1.1以前から WebLogic Server 12.1.2以降から

ドメインごとからドメインごとへ

使用不可

サポート対象

ドメインごとからホストごとへ

使用不可

サポート対象外

ホストごとからドメインごとへ

サポート対象

サポート対象

ホストごとからホストごとへ

手動構成

手動構成

upgrade_dom.html#GUID-A6EDAE8B-72FE-44A0-9E4B-7882001D1E7C__CHDIAEGAは、サポートされている各アップグレード・パスのノード・マネージャのアップグレードの詳細を示しています。

表3-2 ノード・マネージャのアップグレード詳細

ドメインごとからドメインごとへ ホストごとからドメインごとへ ホストごとからホストごとへ

これは、ドメインごとのノード・マネージャにすでに構成されているWebLogic Server 12.1.2以降のすべてのリリースでは、自動アップグレードです。環境は標準設定に更新され、後でカスタマイズできます。

ドメインをアップグレードするために再構成ウィザードまたはWLSTを使用しているかどうかに関係なく、アップグレードは自動で行われます。

この場合、再構成ウィザードでは、ドメインの再構成中に「ノード・マネージャ」画面が表示されます。この画面を使用して、再構成するドメインに使用するノード・マネージャ構成を選択します。結果として生成される構成は、「ノード・マネージャ・タイプ」および「ノード・マネージャ構成」で選択したオプションの組合せに応じて異なります。

WLSTを使用して、ドメインおよび必要なノード・マネージャ構成をアップグレードすることもできます。「WebLogic Scripting Toolを使用したWebLogicドメインの再構成」を参照してください。

複数のドメインごとのノード・マネージャが同じマシン上で実行する場合、「同じマシンでの複数のドメインごとのノード・マネージャの構成」を参照してください。

Fusion Middlewar再構成ウィザード・ウィンドウで画面の「ヘルプ」ボタンをクリックして、再構成ウィザードのコンテキスト依存ヘルプを表示します。

「ノード・マネージャ構成の完了」の説明に従って、ノード・マネージャ構成を手動で完了する必要があります

一部の11gドメインが14cにアップグレードされる場合のみ、14cドメインに2つ目のノード・マネージャの構成が必要になることがあります。再構成プロセスを開始する前に、「同じマシンでの2つのホストごとのノード・マネージャの実行」を参照してください。ドメインの再構成の後で、ノード・マネージャ構成の完了(2つのホストごとのノード・マネージャ)の説明に従って、ノード・マネージャ構成を完了します。

同じマシンでの複数のドメインごとのノード・マネージャの構成

ドメインごとのノード・マネージャ構成を使用して同じマシン上に複数のドメインがある場合、再構成ウィザードを実行する際、次を行います。

  • 11gドメインをアップグレードしている場合、「ノード・マネージャ」画面が表示されます。ドメインごとのデフォルトの場所またはドメインごとのカスタムの場所のいずれかを選択します。

  • 「拡張構成」画面で、管理対象サーバー、クラスタおよびCoherenceを選択して、14cノード・マネージャの既存のマシンを再構成します。

  • 「管理対象サーバー」および「クラスタ」画面では、変更する必要はありません。「マシン」画面が表示されたときは、各ドメインに一意のノード・マネージャ・ポートを使用していることを確認してください。たとえば、マシン上で実行中の3つのドメインごとのノード・マネージャがある場合、ドメイン1にはポート5556、ドメイン2にはポート5557、ドメイン3にはポート5558を使用します。

    Fusion Middlewar再構成ウィザード・ウィンドウの画面の「ヘルプ」ボタンをクリックして、再構成ウィザードのコンテキスト依存ヘルプを表示します。

同じマシンでの2つのホストごとのノード・マネージャの実行

次のすべての項目がアップグレード・シナリオに適用する場合、14cドメインに2つ目のノード・マネージャを作成するには、再構成プロセス中に追加のステップが必要です。

  • 11gまたは12cドメインの一部のみを14cにアップグレードします。

  • 14cドメインのホストごとのノード・マネージャの使用を続行します。

  • 11g/12cと14cの両方のホストごとのノード・マネージャが同じマシンで実行されます。

再構成ウィザードの実行時には、次のようになります。

  • 「ノード・マネージャ」画面で、「手動ノード・マネージャ・セットアップ」を選択します。このオプションにより、14cドメインのホストごとのノード・マネージャとしてのノード・マネージャ構成がアップグレードされている状態が維持されます。

  • 「拡張構成」画面で、管理対象サーバー、クラスタおよびCoherenceを選択して、14cノード・マネージャの既存のマシンを再構成します。また、「デプロイメントとサービス」を選択して、デプロイメントおよびサービスのマシンの割当てを確認します。

  • 「管理対象サーバー」および「クラスタ」画面では、変更する必要はありません。「マシン」画面が表示されたときは、各マシンの名前を、11gまたは12cドメインで使用されている名前以外に変更します。また、11gまたは12cノード・マネージャで使用されているノード・マネージャのポート番号とは異なるノード・マネージャのポート番号を入力します。このドメインの各14cマシンには同じポート番号を使用します。

  • デプロイメントおよびサービスが新しいマシン名に割り当てられていることを確認します。

WebLogicドメインの再構成

WebLogicドメインの構成には、グラフィカルFusion Middleware再構成ウィザードまたはWebLogic Scripting Tool (WLST)の2つのツールの選択肢があります。

注意:

ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードまたはWLSTを使用してドメインをアップグレードする前に、「ドメインのバックアップ」の説明に従ってドメインをバックアップしていることを確認してください。再構成プロセス中にエラーその他の中断が発生した場合は、バックアップの場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーして、ドメインをリストアする必要があります。この回避策は、再構成前にドメインを確実に元の状態に戻す唯一の方法です。

ドメインを再構成する場合:

  • ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンのメジャーおよびマイナー・バージョン番号(たとえば、14.1.1.0)に更新されます。

  • すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。

  • 起動スクリプトが更新されます。

  • 管理サーバーのドメインを再構成した後で、再構成されたドメインをドメイン内のすべてのリモート管理対象サーバーにポートする必要があります。リモート・マシンの管理対象サーバー・ドメインの更新を参照してください。

  • WLSTまたは再構成ウィザードのいずれかを使用してホストごとのノード・マネージャにドメインを再構成した後で、ノード・マネージャ構成を完了するための追加のステップを実行する必要があります。「ノード・マネージャ構成の完了」および「ノード・マネージャ構成の完了(2つのホストごとのノード・マネージャ)」を参照してください。

グラフィカル・モードでのWebLogicドメインの再構成

再構成ウィザードを使用してドメインを再構成するには、まずDOSコマンド・プロンプトまたはUNIXシェルからこれを起動し、表示される一連の画面に必要なアップグレードの詳細を入力します。

ノート:

GUIモードで再構成ウィザードを実行できない場合、WLSTスクリプトを使用してドメインを再構成することをお薦めします。「WebLogic Scripting Toolを使用したWebLogicドメインの再構成」を参照してください。

Windowsコマンド・プロンプトまたはUNIXシステムから、再構成ウィザードをグラフィカル・モードで起動するには:

  1. ドメインが存在するシステムにログインします。
  2. MS-DOSコマンド・プロンプト・ウィンドウ(Windows)またはコマンド・シェル(UNIX)を開きます。
  3. 次のディレクトリに移動します。ここでORACLE_HOMEは、Oracleホーム・ディレクトリです。

    Windowsの場合: ORACLE_HOME\oracle_common\common\bin

    UNIX:の場合: ORACLE_HOME/oracle_common/common/bin

  4. 次のコマンドを実行します。

    Windowsの場合: reconfig.cmd

    UNIXの場合: sh reconfig.sh

    ノート:

    reconfig.cmdまたはreconfig.shコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効である場合、次のエラー・メッセージが表示されます。

    *sys-package-mgr*: パッケージ・キャッシュ・ディレクトリを作成できません。

    コマンドに-Dpython.cachedir=valid_directoryオプションを含めることで、キャッシュ・ディレクトリを変更できます。

    再構成ウィザード・セッションのログ・ファイルを作成するには、コマンドに-log=reconfig.log -log_priority=debugパラメータを含めます。ログ・ファイルのファイル名(config_today.logなど)を指定できます。ログ・ファイルは、Oracleホーム・ディレクトリのlogsディレクトリに格納されます。log_priorityに有効な他の値は、OFF、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINESTおよびALLです。

    「ドメインの選択」画面が表示されます。

再構成ウィザードでは、一連の画面が upgrade_dom.html#GUID-CFC2432D-3792-4231-AA1C-2FCEB7F843A0__CEGDJJBJに示された順序で表示されます。

ノート:

ドメインおよび他の要因により、アプリケーションによって、次の表に表示される画面のほかに、追加の構成画面が表示されます。これらの画面の詳細は、画面で「ヘルプ」ボタンをクリックしてください。

再構成のプロセス中に「拡張構成」画面が表示される場合は、オプションを選択しないで、すべての拡張構成をスキップしてくだい。必要に応じて、後でWLST、構成ウィザードまたはWebLogic Server管理コンソールを使用して、サーバーおよびクラスタの追加やデプロイメント・ターゲット指定の変更などの拡張構成を実行できます。

表3-3 既存のWebLogicドメインの再構成

画面 画面がいつ表示されるか 次のアクションを実行

ドメインの選択

常時

ドメイン・ディレクトリへのフルパスを入力するか、「参照」をクリックして、ドメイン・ディレクトリに移動して選択します。

「次へ」をクリックして、続行します。

再構成セットアップの進行状況

常時

再構成テンプレートのアプリケーションの進行状況を表示します。

処理が終了したら、「次へ」をクリックして、続行します。

再構成のサマリー

常時

すべての再構成済テンプレートの再構成プロセスに関する情報が表示されます。

「次へ」をクリックして、続行します。

ドメイン・モードおよびJDK

常時

ドメイン・モードは変更できません。

ドメインで使用するJDKを選択するか、「参照」をクリックして使用するJDKに移動します。

「次へ」をクリックして、続行します。

この時点で追加のドメイン構成画面が表示される場合があります。

追加の画面はドメイン構成によって異なります。

画面の「ヘルプ」ボタンをクリックするか、または表示順に画面のすべてが説明されている再構成ウィザードの画面を参照してください。

拡張構成

常時

詳細構成タスクを実行する各カテゴリ(存在する場合)のチェック・ボックスを選択します。

使用可能なチェック・ボックスは、ドメイン構成によって異なります。

「次へ」をクリックして、続行します。

構成のサマリー

常時

構成を確認します。

構成を変更するには「戻る」ボタンをクリックし、ドメイン再構成プロセスを完了するには「再構成」ボタンをクリックします。

再構成に成功しました

常時

再構成プロセスの最終ステータスを表示します。

構成ウィザードを終了するには、「終了」をクリックします。

WebLogic Scripting Toolを使用したWebLogicドメインの再構成

WLSTを使用してドメインを再構成するには、readDomainForUpgradeコマンドを使用します。このコマンドを使用して、既存のホストごとのノード・マネージャ構成をドメインごとの構成へ移行します。

ノート:

元のドメインがドメインごとのノード・マネージャ構成を使用している場合、ノード・マネージャは自動的にアップグレードされ、追加のステップは必要ありません。

元のドメインがホストごとのノード・マネージャを使用していて、その構成の使用を続行する場合、「ノード・マネージャ構成の完了」の説明に従って、ノード・マネージャを手動で再構成する必要があります

例3-1は、オフラインでWLSTを使用してmy_domainというドメインを再構成する方法を示しています。

例3-2は、DOMAIN_HOME/nodemanagerにあるドメインごとの構成に、既存のホストごとのノード・マネージャ構成を移行する方法を示しています。

例3-3は、/Oracle/Middleware/custom/nodemanagerにあるドメインごとの構成に、/Oracle/Middleware/oracle_common/common/nodemanagerにある既存のホストごとの構成を移行する方法を示しています。

setOptionコマンドで使用可能なノード・マネージャ・オプションの詳細は、『WebLogic Server WLSTコマンド・リファレンス』のsetOptionに関する項を参照してください。使用可能なノード・マネージャのWLSTコマンドの詳細は、『WebLogic Server WLSTコマンド・リファレンス』のノード・マネージャ・コマンドに関する項を参照してください。

例3-1 WebLogicドメインの再構成

# Open the domain for upgrade.
wls:/offline> readDomainForUpgrade('c:/domains/my_domain')

# Save the updated domain.
wls:/offline/my_domain> updateDomain()

# Close the domain.
wls:/offline/my_domain> closeDomain()

既存のドメインがホストごとのノード・マネージャを使用していて、ドメインごとのノード・マネージャ構成に移動する場合、いくつかのオプションがあります。

  • 既存のホストごとの構成を移行して、デフォルトの場所(DOMAIN_HOME/nodemanager)でドメインごとの構成を作成します。

  • Oracle推奨のデフォルトに基づいた新しい構成を使用して、デフォルトの場所(DOMAIN_HOME/nodemanager)でドメインごとの構成を作成します。

  • 既存のホストごとの構成を移行して、カスタムの場所でドメインごとの構成を作成します。

  • Oracle推奨のデフォルトに基づいた新しい構成を使用して、カスタムの場所でドメインごとの構成を作成します。

例3-2 デフォルトの場所での新規ノード・マネージャ構成の作成

#Read domain for reconfiguration
readDomainForUpgrade('domains/mydomain')
 
#Set Node Manager username and password.
cd('/')
cd('SecurityConfiguration/mydomain')
cmo.setNodeManagerUsername('username')
cmo.setNodeManagerPasswordEncrypted('password')
 
#Browse Node Manager properties
cd('/')
cd('NMProperties')
 
# Create per domain Node Manager with new default configuration. Existing
# Node Manager properties will not be migrated in this case.
setOption('NodeManagerType','PerDomainNodeManager')
setOption('NodeManagerUpgradeType','New')
 
# Update the domain to commit the changes.
updateDomain()

例3-3 カスタムの場所への既存の構成の移行

#Read domain for reconfiguration
readDomainForUpgrade('/domains/mydomain')
 
#Set Node Manager username and password.
cd('/')
cd('SecurityConfiguration/mydomain')
cmo.setNodeManagerUsername('username')
cmo.setNodeManagerPasswordEncrypted('password')
 
#Browse node manager properties
cd('/')
cd('NMProperties')
 
# Create custom location Node Manager, migrating an existing Node Manager
# configuration with default values for Oracle-recommended default properties.
setOption('NodeManagerType','CustomLocationNodeManager')
setOption('NodeManagerHome','/Oracle/Middleware/custom/nodemanager/')
setOption('NodeManagerUpgradeType','Migrate')
setOption('OldNodeManagerHome','/Oracle/Middleware/Oracle_Home/oracle_common/
common/nodemanager')
setOption('NodeManagerUpgradeOverwriteDefault','true')
 
# Update the domain to commit the changes.
updateDomain()

ノード・マネージャ構成の完了

再構成したドメインがホストごとのノード・マネージャ構成を使用していて、そのドメインのホストごとのノード・マネージャの使用を続行する場合、ノード・マネージャの構成タスクのセットを実行する必要があります。

  1. 新しいWebLogic Serverのインストールでは、ORACLE_HOME/oracle_common/commonにnodemanagerを作成します。

  2. nodemanager.propertiesおよびnodemanager.domainsファイルを以前のWebLogic ServerインストールのWL_HOME/common/nodemanagerディレクトリから、ステップ1で作成したディレクトリにコピーします。

  3. 以前のインストールにnm_data.properties、SerializedSystemIni.dataまたはsecurity/SerializedSystemIni.datファイルが含まれている場合は、それをステップ1で作成したディレクトリにコピーします。SerializedSystemIni.datをコピーする場合は、nodemanagerディレクトリの下にsecurityディレクトリを作成して、そこにファイルを格納します。

  4. nodemanager.propertiesファイルに次の編集を行います。ORACLE_HOMEは、WebLogic Server インストールのOracleホーム・ディレクトリです。

    • DomainsFileをORACLE_HOME/oracle_common/common/nodemanager/nodemanager.domainsファイルを指すように更新します。

    • JavaHomeをWebLogic Serverに対して使用しているJDKのjreディレクトリを指すように更新します。ファイルにjavaHomeプロパティ設定(小文字のj)も含まれる場合、必要ではないため削除します。

    • NodeManagerHomeをORACLE_HOME/oracle_common/common/nodemanagerを指すように更新します。

    • LogFileをORACLE_HOME/oracle_common/common/nodemanager/nodemanager.logを指すように更新します。

  5. 独自のセキュリティ証明書を使用している場合は、これらの証明書の場所がnodemanager.propertiesで正しいことを確認します。証明書を別の場所に移動した場合はパスを更新する必要がある場合があります。

    以前のインストールでWebLogic Serverデモ証明書を使用していた場合は、CertGenを実行してこのインストールのデモ・キーストアを作成する必要があります。

    1. setWLSEnvを実行します。

      cd WL_HOME/server/bin

      . ./setWLSEnv.sh (UNIX)

      setWLSEnv.cmd (Windows)

      ノート:

      UNIXオペレーティング・システムでは、setWLSEnv.shコマンドはすべてのコマンド・シェルで環境変数を設定しません。Kornシェルまたはbashシェルを使用してこのコマンドを実行することをお薦めします。

    2. ORACLE_HOME/oracle_common/common/nodemanager/ディレクトリに変更し、存在しない場合はセキュリティ・ディレクトリを作成します。

    3. セキュリティ・ディレクトリに変更し、次のコマンドを入力します。

      java utils.CertGen -certfile democert -keyfile demokey -keyfilepass DemoIdentityPassPhrase

    4. DemoIdentity.jksファイルを生成するには、次のコマンドを実行します。

      java utils.ImportPrivateKey -certfile democert.pem -keyfile demokey.pem -keyfilepass DemoIdentityPassPhrase -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -alias demoidentity

  6. ORACLE_HOME/wlserver/server/binディレクトリから、startNodeManager.cmd (Windows)またはstartNodeManager.sh (UNIX)を実行します。

  7. ノード・マネージャを使用してサーバーを起動できることを確認します。『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。permgen設定がサーバーの起動に十分であることを確認するには、次の方法のいずれかを使用できます。

    • startManagedWebLogicスクリプトを使用して管理対象サーバーを起動します。

    • nodemanager.propertiesのStartScriptEnabled値をtrueに設定します。これにより、管理対象サーバーの起動時にStartManagedWebLogicスクリプトを起動できます。

    • permgen領域の設定の説明に従って、permgen領域を設定します。

    • サーバーを起動するためにsetUserOverridesスクリプトを使用してpermgen設定を指定します。『Oracle WebLogic Serverサーバーの起動と停止の管理』のドメイン全体のサーバー・パラメータのカスタマイズに関する項を参照してください。

ノード・マネージャ構成の完了(2つのホストごとのノード・マネージャ)

再構成したドメインがホストごとのノード・マネージャ構成を使用している場合は、11gまたは12cドメインのホストごとのノード・マネージャがすでにあるマシンで14cドメインのホストごとのノード・マネージャの使用を続行できます。

ドメイン内のマシンごとに次のステップを実行します。

ノート:

この項のステップを実行する前に、ドメイン内の各リモート・マシンにドメインを解凍したことを確認してください。コマンドに-nodemanager_type=ManualNodeManagerSetupパラメータおよび-overwrite_domain=trueパラメータを含めます。例: 

./unpack.sh -domain=domain_home -template=template_jar -nodemanager_type=ManualNodeManagerSetup -overwrite_domain=true

  1. 新しいWebLogic Serverのインストールでは、ORACLE_HOME/oracle_common/commonにnodemanagerディレクトリを作成します。

  2. nodemanager.domainsおよびnodemanager.propertiesファイルを、以前のWebLogic ServerインストールのWL_HOME/common/nodemanagerディレクトリから、ステップ1で作成したディレクトリにコピーします。11gまたは12cドメインがnodemanager.domainsファイルにリストされている場合、その行を削除またはコメント・アウトします。

  3. 各マシンでnodemanager.propertiesファイルを適切に編集します。具体的には、次のとおりです。

    • SecureListenerが、SSLノード・マネージャを使用している場合はtrueに設定され、プレーン・ノード・マネージャを使用している場合はfalseに設定されていることを確認してください。

    • DomainsFileをORACLE_HOME/oracle_common/common/nodemanager/nodemanager.domainsを指すように変更します。

    • PropertiesVersionを14.1.1.0.0に変更します。

    • NodeManagerHomeをORACLE_HOME/oracle_common/common/nodemanagerに変更します。

    • JavaHomeを、WebLogic Server 14.1.1.0.0で使用しているJavaインストールのjreディレクトリを指すように変更します。

    • javaHome行は、14cで必要ではないため削除します。

    • ListenPortを、構成ウィザードの「マシン」画面で指定した値に変更します。

    • LogFileを目的の場所およびファイル名に変更します。推奨値はORACLE_HOME/oracle_common/common/nodemanager/nodemanager.logです。

  4. 独自のセキュリティ証明書を使用している場合は、これらの証明書の場所がnodemanager.propertiesで正しいことを確認します。証明書を別の場所に移動した場合はパスを更新する必要がある場合があります。

    以前のインストールでWebLogic Serverデモ証明書を使用していた場合は、CertGenを実行してこのインストールのデモ・キーストアを作成する必要があります。

    1. setWLSEnvを実行します。

      cd WL_HOME/server/bin

      . ./setWLSEnv.sh (UNIX)

      setWLSEnv.cmd (Windows)

      ノート:

      UNIXオペレーティング・システムでは、setWLSEnv.shコマンドはすべてのコマンド・シェルで環境変数を設定しません。Kornシェルまたはbashシェルを使用してこのコマンドを実行することをお薦めします。

    2. ORACLE_HOME/oracle_common/common/nodemanager/ディレクトリに変更し、存在しない場合はセキュリティ・ディレクトリを作成します。

    3. セキュリティ・ディレクトリに変更し、次のコマンドを入力します。

      java utils.CertGen -certfile democert -keyfile demokey -keyfilepass DemoIdentityPassPhrase

    4. DemoIdentity.jksファイルを生成するには、次のコマンドを実行します。

      java utils.ImportPrivateKey -certfile democert.pem -keyfile demokey.pem -keyfilepass DemoIdentityPassPhrase -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -alias demoidentity

  5. ORACLE_HOME/wlserver/server/binディレクトリから、ノード・マネージャを起動します。

  6. 管理サーバーが実行中の場合、管理サーバーを再起動します。

  7. ノード・マネージャを使用してサーバーを起動できることを確認します。『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャを使用したサーバーの制御に関する項を参照してください。permgen設定がサーバーの起動に十分であることを確認するには、次の方法のいずれかを使用できます。

    • startManagedWebLogicスクリプトを使用して管理対象サーバーを起動します。

    • nodemanager.propertiesのStartScriptEnabled値をtrueに設定します。これにより、管理対象サーバーの起動時にStartManagedWebLogicスクリプトを起動できます。

    • permgen領域の設定の説明に従って、permgen領域を設定します。

    • サーバーを起動するためにsetUserOverridesスクリプトを使用してpermgen設定を指定します。『Oracle WebLogic Serverサーバーの起動と停止の管理』のドメイン全体のサーバー・パラメータのカスタマイズに関する項を参照してください。

リモート・マシンの管理対象サーバー・ドメインの更新

WebLogicドメインに複数の管理対象サーバーが含まれ、各管理対象サーバー・ドメイン・ディレクトリが管理サーバーのホスト・マシンのリモート・マシン上にある場合、そのリモート・マシン上のドメインを更新するには2つの方法のいずれかを使用できます。

  • packコマンドを使用して、ドメインのテンプレートJARを生成します。packコマンドでは必ず-managed=true引数を指定してください。JARをリモート・マシンに移動してから、リモート・マシンでunpackコマンドを使用して管理対象サーバー・ドメインを作成します。『PackおよびUnpackコマンドによるテンプレートとドメインの作成』を参照してください。

  • オンライン・モードでWLST writeTemplateコマンドを使用します。リモート・マシンから管理サーバーへの接続時にwriteTemplateコマンドを実行する場合は、管理サーバー上のドメインをテンプレートJARファイルを動的にパックして、そのテンプレートJARを指定されたディレクトリに転送します。

    次のサンプルのWLSTスクリプトは、writeTemplateを使用してリモート・マシン上で管理対象サーバー・ドメインを作成または更新する方法を示しています。ドメインの各リモート・マシン上でスクリプトを実行します。このスクリプト手順では、次のタスクが実行されます。

    • 管理サーバーへのログイン

    • 管理サーバー・ドメインをJARファイルにパックして、それをリモート・マシン上の指定されたテンプレート・ディレクトリに書き込む

    • 管理サーバーからの切断

    • テンプレートJARの読取り

    • リモート・マシン上でのドメインの作成

    import os
 
wlsHome = os.getenv('WL_HOME')
mwHome = os.path.join(wlsHome, '..')
 
#Substitute the administrator user name and password values below as needed
connect('adminuser','adminpassword','admin_server_url')
 
#Create the path on the local machine where the template will be stored, 
#The specified template JAR should not already exist. The timeout value 
#specifies the number of milliseconds to elapse before the connection between
#the Administration Server and remote machine times out (default is 120000).
templatePath = '/user_templates/myTemplate.jar'
timeout = '180000'
 
#get the packed template from the Administration Server
writeTemplate(templatePath, timeout)
 
#disconnect from online WLST connection to the Administration Server
disconnect()
 
#read the template that was downloaded from the Administration Server
readTemplate(templatePath)
 
#specify the domain directory where the domain needs to be created
domainPath = 'domains/myDomain')
 
#create the domain
writeDomain(domainPath)

ドメインのアップグレード・プロセスに関する重要なノート

WebLogic Serverアプリケーションのアンデプロイが必要かどうか、ドメイン・ディレクトリに存在しなければならない最小のファイルのセットなど、ドメインのアップグレード・プロセスに関するいくつかの主要な点に留意してください。

  • WebLogic Serverアプリケーションをアンデプロイする必要はありません。通常、WebLogic Serverアプリケーションは、修正を加えることなくWebLogic Server 14.1.1.0.0の新たなアプリケーション環境で動作します。実際の環境においてアプリケーションが機能変更の影響を受けるかどうかについては、「WebLogic Server 14.1.1.0.0の旧リリースとの互換性」で互換性情報を確認してください。アプリケーションで非推奨になったAPIまたは削除されたAPIが使用されている場合は、実行時に警告または例外が発生するおそれがあります。

  • 少なくとも、ドメイン・ディレクトリに次のファイルが含まれている必要があります:

    • config.xml

    • セキュリティ関連のファイル(SerializedSystemIni.dat、DefaultAuthenticatorInit.ldift、DefaultAuthorizerInit.ldift、DefaultRoleMapperInit.ldift)

      セキュリティ関連のファイルがないと、サーバーは起動されず、認証エラー・メッセージがログに記録されます。

    • ドメイン内にあるトランザクション・ログ・ファイル(..tlog)。Oracle WebLogic Server JTAアプリケーションの開発のトランザクション・ログ・ファイルを使用したトランザクションのリカバリを参照してください。

  • ターゲットのコンピュータ上のドメイン・ディレクトリに含まれるすべての内容がこのプロセスにおいて更新されます。

  • アプリケーション環境内のすべてのコンピュータのドメインをアップグレードする必要があります。

  • 再構成ウィザードでは、WebLogicドメインのアップグレード時に、ドメインに存在する可能性のある独自のアプリケーションはアップグレードされません。

  • WebLogic Liquid Data、またはAquaLogic Data Services Platformのリソースを含むドメインは、WebLogic Server 14.1.1.0.0にアップグレードできません。

  • リモートの管理対象サーバーのドメインをアップグレードするとき、参照されているアプリケーション・パスがシステムにないことを通知する次のようなメッセージが表示される場合があります。

    <Apr 12, 2009 6:42:06 PM EDT> <INFO> <Upgrade> <BEA-800000> <An invalid
path, 'C:\bea\wlserver_10.3\user_projects\mydomain\medrecEar.ear', was
specified for application, 'medrecEar'.>

    このメッセージは無視できます。

  • Solarisコンピュータ上(のみ)でAvitek Medical Recordアプリケーションを8.1から12.1.3にアップグレードした場合は、サーバーを起動する前に、setDomainEnv.shファイルを編集し、起動コマンドから-Xverify:noneを削除する必要があります。-Xverify:noneを削除するには、次の行の後でJAVA_OPTIONS=""を設定します。 

    . ${WL_HOME}/common/bin/commEnv.sh

    そうでない場合、JVMエラーのためサーバーの起動に失敗します。

  • 12.2.1.3.0から14.1.1.0.0へのローリング・アップグレード、または14.1.1.0.0から12.2.1.3.0へのダウングレードを実行する場合、古いプロトコルを一時的に許可するために、新しい14.1.1.0.0サーバーを明示的に設定する必要があります。詳細は、「WebLogic Serverクラスタのメッセージングについて」を参照してください。

アップグレード後のタスクの実行

アプリケーション環境のアップグレード後、起動スクリプトへのカスタマイズの再適用、ファイル権限の確認、およびリモート・サーバーの起動オプションなどのタスクの実行が必要な場合があります。

この項には次のトピックが含まれます:

必ずしもすべてのステップを実行する必要があるわけではありません。以下の説明に基づいて、アプリケーション環境に必要なステップを決定してください。互換性の問題が環境に適用されるかどうかについては、「WebLogic Server 14.1.1.0.0の旧リリースとの互換性」で互換性問題を確認してください。

起動スクリプトへのカスタマイズの再適用

アプリケーション環境の14.1.1.0.0へのアップグレードを完了するには、起動スクリプトへのカスタマイズの再適用が必要になる場合があります。次の節では、デフォルト起動スクリプトおよびカスタム起動スクリプトをカスタマイズする方法について説明します。

デフォルト起動スクリプト

再構成ウィザードによるアップグレード・プロセスでは、デフォルト起動スクリプトに対して行われたカスタマイズの内容(JAVA_OPTIONS環境変数の設定など)は保持されません。アップグレード・プロセスが完了した後に、デフォルト起動スクリプトを再びカスタマイズする必要があります。

カスタム起動スクリプト

カスタム起動スクリプトを更新するには:

  • JDKバージョンをWebLogic Serverで使用しているJDKに設定します。

  • 次のようにCLASSPATH変数を更新します。

    • WebLogic Server 14.1.1.0.0のクラスを変数の先頭に追加します。

    • バージョン10.3より前の未使用のすべてのWebLogicクラスを削除します。

ファイル権限の確認

次のようにファイル権限を確認します。

  • アップグレード・プロセスにおいてドメイン・ディレクトリのバックアップを行った場合、バックアップ・ファイルには機密情報が含まれている可能性があるため、バックアップ・ファイルを保護する必要があります。

  • アップグレード・プロセスでは、ファイル権限は保持されません。デフォルト以外のファイル権限がファイルに設定されている場合は、これらを確認し、リセットする必要があります。

  • UNIXシステムでは、アップグレード・プロセス中に作成される新しいファイルの所有権と権限は、アップグレードを実行するユーザーに割り当てられます。たとえば、アップグレードがrootにより実行される場合、新しいファイルの所有権はrootに割り当てられます。このため、後でドメイン内のこれらのファイルを更新するユーザーにはroot権限が必要となります。したがって、アップグレード・プロセス中に作成されたファイルに設定されている権限を確認または修正することをお薦めします。

リモート・サーバー起動オプションの確認

管理サーバーを起動したら、JAVA_HOME、BEA_HOME、CLASSPATHなどのリモート・サーバー起動オプションが、対象の管理対象サーバーにインストールされているWebLogic Server を参照していることを確認します。これはWebLogic Server管理コンソールを使用して行います。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの管理対象サーバーの起動引数の構成に関する項を参照してください。

ノート:

リモート・サーバー起動オプションが正しく設定されていないと、ノード・マネージャを使用して管理対象サーバーを起動するときに、次のようなメッセージがログ・ファイルに書き込まれることがあります。このメッセージは再帰的に送信されるため、最終的に使用可能なディスク容量がすべて消費されるおそれがあります。

No config.xml was found.

Would you like the server to create a default configuration and boot? (y/n): 
java.io.IOException: The handle is invalid

Windowsノード・マネージャ・サービスの再作成

Windowsシステムで、ノード・マネージャをドメインのWindowsサービスとして実行していて、引き続きこれを使用する場合、再構成する必要があります。

Windows用のノード・マネージャ・サービスの構成方法の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャのデフォルト構成に関する項を参照してください。

オプションで、uninstallNodeMgrSrv.cmdを実行して、インストールからノード・マネージャ・サービスを削除できます。『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャのデフォルト構成に関する項を参照してください。

アプリケーション環境の本番環境へのプロモート

アプリケーション環境を本番環境にプロモートする前に、標準的な品質保証およびパフォーマンス・チューニングを行います。テスト・アプリケーション環境でアプリケーション(外部クライアント・アプリケーションを含む)の動作をテストすることをお薦めします。非推奨となったAPIまたは削除されたAPIがアプリケーションで使用されている場合は、実行時に警告または例外が発生するおそれがあります。発生した場合は、アプリケーション環境を本番環境にプロモートする前に、必要な修正を行う必要があります。

すべてのテスト基準をクリアしていれば、「ステップ4: アップグレード計画の作成」で定義したアップグレード計画に従って、アプリケーション環境を本番環境にプロモートできます。

新しい14.1.1.0.0のアプリケーション環境が本番環境にデプロイされたら、既存の環境から新しい環境にリクエストをリダイレクトできるようになります。このようにして、最終的には、既存の環境を安全な停止状態にすることができます。これは、ロード・バランサなどを使用して行います。

スタンドアロンWebLogic Serverインストールでのエディションベース再定義の有効化(オプション)

エディションベース再定義(EBR)は、スタンドアロンのOracle WebLogic Serverユーザーに、中断のない可用性を備えたオンライン・アップグレード・サポートを提供します。

将来のスタンドアロン・リリースのOracle WebLogic Serverにアップグレードする際にダウンタイムなしのアップグレードを実行する場合、WebLogicドメインをインストールして構成した後、次のタスクを実行する必要があります。

ノート:

EBRを使用したオンライン・アプリケーションのアップグレードの実行の詳細は、EBRを使用したアプリケーションのアップグレードに関する項を参照してください。

開始する前に、次の前提条件および関連情報を確認してください。

  • Oracleデータベースは、EBRでサポートされる唯一のデータベースになります。
  • ダウンタイムなしのアップグレードのためにWeblogic ServerをEBR対応にするには、システム・スキーマの格納に次のデータベース表を使用する必要があります: 診断ログ、タイマー、リーシング表、サーブレット・セッション、永続ストア、WAN永続ストア、LLR表およびバッチ・データ表。
  • このガイドのステップは、Oracle WebLogic Serverスタンドアロン・インストールに適用されます。
  • Oracle WebLogic Server管理者が権限付きデータベース操作を実行できない場合、データベース管理者はSQL文を実行するか、Oracle WebLogic Server管理者が使用する環境を提供する必要があります。
  • Oracle WebLogic Server管理者またはデータベース管理者は、すべてのエディションを作成する必要があります。
  • EBRを有効化するには、初期設定時にダウンタイムが必要ですが、環境がEBR対応になると、ダウンタイムが増えることはほとんどありません。
WebLogic Serverドメインの停止

環境をEBR対応にする前に、まずWebLogic Serverドメインを停止する必要があります。

Oracle WebLogic Serverサーバーの起動と停止の管理のサーバーの起動と停止 を参照してください。
エディション対応ユーザーおよびエディションの作成

データベースにエディションを作成する前に、エディション対応ユーザーを作成します。

WebLogic Server管理者またはデータベース管理者は、次を完了する必要があります。
  1. SQL*Plusに接続し、次のコマンドを実行して、エディション対応ユーザーを作成します。
    $ sqlplus <sysdba-connection-string>
    SQL> CREATE USER <username> identified by <password>
    SQL> ALTER USER <username> ENABLE EDITIONS;
  2. SQL*Plusに接続したまま、次のコマンドを実行してエディションを作成します。
    SQL> CREATE EDITION sample_ed;
    SQL> GRANT USE ON sample_ed TO <username>;
  3. エディション対応ユーザーが表名を変更しビューを作成する場合、次の権限が付与されている必要があります。
    GRANT CREATE SESSION, CREATE TABLE, CREATE SEQUENCE, CREATE VIEW, CREATE PROCEDURE, CREATE TRIGGER TO <username>;
WebLogic Servicesアップグレード・スクリプトの実行

SQL*Plusを使用して、WebLogic Servicesディレクトリからパッケージ化されたEBRスクリプトを実行します。これらのスクリプトは、データベース内の既存のWebLogic Serverシステム表を非EBRからEBR対応にアップグレードします。

SQL*Plusを使用して接続し、次のコマンドを実行して、既存のWebLogic Serverデータベース表をアップグレードします。エディション対応ユーザーと接続していることを確認します。スクリプトは複数のディレクトリにあり、WebLogic Serverスタンドアロン・インストールの一部であることに注意してください。
  1. SQL*Plusに接続し、次のスクリプトを実行して、表を作成します。 
    $ sqlplus <user-connection-string>
    SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/oracle_ebr/upgrade_js_ddl.sql -- rename/cover WEBLOGIC_TIMERS
SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/diagnostics/oracle_ebr/upgrade_wls_events_ddl.sql -- rename/cover VIEW WLS_EVENTS
SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/diagnostics/oracle_ebr/upgrade_wls_hvst_ddl.sql -- rename/cover WLS_HVST
SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/oracle_ebr/upgrade_lstbs.sql -- rename/cover ACTIVE
SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/upgrade_checkpoint_data_ddl.sql -- rename/cover CHECKPOINTDATA
SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/upgrade_execution_instance_data_ddl.sql -- rename/cover EXECUTIONINSTANCEDATA
SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/upgrade_job_instance_data_ddl.sql -- rename/cover JOBINSTANCEDATA
SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/upgrade_job_status_ddl.sql -- rename/cover JOBSTATUS
SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/upgrade_step_execution_instance_data_ddl.sql -- rename/cover STEPEXECUTIONINSTANCEDATA
SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/upgrade_step_status_ddl.sql -- rename/cover STEPSTATUS
SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/servletsess/oracle_ebr/upgrade.sql -- rename/cover WL_SERVLET_SESSIONS
SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/wanpersist/oracle_ebr/upgrade.sql -- rename/cover WLS_WAN_PERSISTENCE_TABLE
  2. 次のステップに進む前に、すべての表がEBR対応であることを確認します。
表作成スクリプトの実行

SQL*Plusを使用して、WebLogic Servicesディレクトリからパッケージ化されたEBRスクリプトを実行します。これらのスクリプトによって必要な表が作成され、自動的にEBR対応になります。

WebLogic Server管理者またはデータベース管理者は、スクリプトを実行する必要があります。以前のリリースでこれらの表を作成した場合、スクリプトを再度実行して、最新の変更があることを確認します。これらのスクリプトは、既存の表の名前を変更したり、必要に応じてアンダースコアを含む新しい表を作成してから、エディショニング・ビューを作成します。
  1. SQL*Plusに接続し、次のコマンドを実行して、表を作成します。スクリプトは複数のディレクトリにあることに注意してください。
    エディション対応ユーザーとして接続していることを確認します。 

    $ sqlplus <user-connection-string> 
SQL> ALTER SESSION SET EDITION = sample_ed;
SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/oracle_ebr/crejstbs.sql -- creates WEBLOGIC_TIMERS
SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/oracle_ebr/crelstbs.sql -- creates ACTIVE
SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/batch/oracle_ebr/jbatch.sql -- creates JOBINSTANCEDATA, EXECUTIONINSTANCEDATA, STEPEXECUTIONINSTANCEDATA, JOBSTATUS, STEPSTATUS, CHECKPOINTDATA
SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/diagnostics/oracle_ebr/wls_events_ddl.sql -- creates WLS_EVENTS
SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/diagnostics/oracle_ebr/wls_hvst_ddl.sql -- creates WLS_HVST
SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/servletsess/oracle_ebr/create.sql -- creates WL_SERVLET_SESSIONS
SQL> @<WLS_HOME>/oracle_common/common/sql/wlsservices/wanpersist/oracle_ebr/create.sql -- creates WLS_WAN_PERSISTENCE_TABLE
  2. 次のステップに進む前に、すべての表が作成されていることを確認します。
新規エディションをデフォルトに設定

すべての表が作成され、新規エディションが想定どおりに動作することを確認したら、デフォルト・エディションとして設定します。

  1. その後、WLS管理者またはDBAは新規エディションをデフォルトにします。
    SQL> ALTER DATABASE DEFAULT EDITION = sample_ed;
  2. データ・ソースでエディションを明示的に指定する場合は、WLSTを使用して設定します。
    $ wlst
    wlst> readDomain('/path/to/domain')
wlst> cd('/JDBCSystemResource/my-ds/JdbcResource/my-ds/JDBCDriverParams/NO_NAME_0/Properties/NO_NAME_0/Property/oracle.jdbc.editionName')
wlst> cmo.setValue('SAMPLE_ED')
wlst> updateDomain()
WebLogic Serverドメインの再起動

システム表を作成したら、WebLogicドメインを再起動します。

Oracle WebLogic Serverサーバーの起動と停止の管理のサーバーの起動と停止 を参照してください。