再構成ウィザードを実行して、WebLogic Serverドメインを再構成する場合は、ドメインのアプリケーションによって、次の項目が自動的に更新されます。
WLSコア・インフラストラクチャ
ドメイン・バージョン
注意:
再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。独自のアプリケーションのアップグレード方法の詳細は、WebLogic Server 12.2.1.1.0の旧リリースとの互換性を参照してください。
この章の内容は次のとおりです。
アップグレード・プロセスを開始する前に、次の2つのセクションを参照してください。
ドメインがWebLogic Server 10.3.0より前に作成された場合は、最初にWebLogic Server 10.3.6にアップグレードする必要があります。WebLogic Server 10.3.6にアップグレードした後で、ドメイン・アップグレード・ウィザードを実行して、ドメインをアップグレードします。
WebLogic Server 10.3.6へのアップグレードおよびドメイン・アップグレード・ウィザードの実行の詳細は、次のURLにある『Oracle WebLogic Serverアップグレード・ガイド(10.3.6)』を参照してください。
再構成ウィザードを実行して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ノード・マネージャの管理のデフォルトのノード・マネージャの構成に関する項を参照してください。
表3-1に、WebLogic Serverを12.1.1以前のバージョンから現行バージョンにアップグレードする場合、または12.1.2以降のバージョンから現行バージョンにアップグレードする場合の、サポートされているノード・マネージャのアップグレード・パスを示します。このコンテキストでホストごととは、ドメインごとのノード・マネージャ構成以外のノード・マネージャ構成を意味します。
表3-1 サポートされているノード・マネージャのアップグレード・パス
ノード・マネージャのアップグレード・パス | WebLogic Server 12.1.1以前から | WebLogic Server 12.1.2以降から |
---|---|---|
ドメインごとからドメインごとへ |
使用不可 |
サポート対象 |
ドメインごとからホストごとへ |
使用不可 |
サポート対象外 |
ホストごとからドメインごとへ |
サポート対象 |
サポート対象 |
ホストごとからホストごとへ |
手動構成 |
手動構成 |
表3-2に、サポートされている各アップグレード・パスのノード・マネージャのアップグレード詳細を示します。
表3-2 ノード・マネージャのアップグレード詳細
ドメインごとからドメインごとへ | ホストごとからドメインごとへ | ホストごとからホストごとへ |
---|---|---|
これは、ドメインごとのノード・マネージャにすでに構成されているWebLogic Server 12.1.2以降のすべてのリリースでは、自動アップグレードです。環境は標準設定に更新され、後でカスタマイズできます。 ドメインをアップグレードするために再構成ウィザードまたはWLSTを使用しているかどうかに関係なく、アップグレードは自動で行われます。 |
この場合、再構成ウィザードでは、ドメインの再構成中に「ノード・マネージャ」画面が表示されます。指定できるアップグレード・オプションの詳細は、ノード・マネージャを参照してください。 WLSTを使用して、ドメインおよび必要なノード・マネージャ構成をアップグレードすることもできます。詳細および例は、「WebLogic Scripting Toolを使用したWebLogicドメインの再構成」を参照してください 複数のドメインごとのノード・マネージャが同じマシン上で実行される場合、「同じマシンでの複数のドメインごとのノード・マネージャの構成」を参照してください |
「ノード・マネージャ構成の完了」の説明に従って、ノード・マネージャ構成を手動で完了する必要があります 一部の11gドメインが12cにアップグレードされる場合のみ、12cドメインに2つ目のノード・マネージャの構成が必要になることがあります。再構成プロセスを開始する前に、同じマシンでの2つのホストごとのノード・マネージャの実行を参照してください。ドメインの再構成の後で、ノード・マネージャ構成の完了(2つのホストごとのノード・マネージャ)の説明に従って、ノード・マネージャ構成を完了します。 |
ドメインごとのノード・マネージャ構成を使用して同じマシン上に複数のドメインがある場合、再構成ウィザードを実行する際、次のようになります。
11gドメインをアップグレードしている場合、「ノード・マネージャ」画面が表示されます。ドメインごとのデフォルトの場所またはドメインごとのカスタムの場所のいずれかを選択します。
12cノード・マネージャの既存のマシンを再構成する必要があるため、「拡張構成」画面で、管理対象サーバー、クラスタおよびCoherenceを選択します。
「管理対象サーバー」および「クラスタ」画面では、変更する必要はありません。「マシン」画面が表示されたときは、各ドメインに一意のノード・マネージャ・ポートを使用していることを確認してください。たとえば、マシン上で実行中の3つのドメインごとのノード・マネージャがある場合、ドメイン1にはポート5556、ドメイン2にはポート5557、ドメイン3にはポート5558を使用します。
次のすべての項目がアップグレード・シナリオに適用する場合、12cドメインに2つ目のノード・マネージャを作成するには、再構成プロセス中に追加の手順が必要です。
11gドメインの一部のみを12cにアップグレードします。
12cドメインのホストごとのノード・マネージャの使用を続行します。
11gと12cの両方のホストごとのノード・マネージャが同じマシンで実行されます。
再構成ウィザードの実行時には、次のようになります。
「ノード・マネージャ」画面で、「手動ノード・マネージャ・セットアップ」を選択します。これにより、12cドメインのホストごとのノード・マネージャとしてのノード・マネージャ構成がアップグレードされている状態を維持します。
12cノード・マネージャの既存のマシンを再構成する必要があるため、「拡張構成」画面で、管理対象サーバー、クラスタおよびCoherenceを選択します。また、「デプロイメントとサービス」を選択して、デプロイメントおよびサービスのマシンの割当てを確認します。
「管理対象サーバー」および「クラスタ」画面では、変更する必要はありません。「マシン」画面が表示されたときは、各マシンの名前を、11gドメインで使用されている名前以外に変更します。また、11gノード・マネージャで使用されているノード・マネージャのポート番号とは異なるノード・マネージャのポート番号を入力します。このドメインの各12cマシンには同じポート番号を使用します。
デプロイメントおよびサービスが新しいマシン名に割り当てられていることを確認します。
WebLogicドメインは次のように再構成できます。
グラフィック・モードで、Fusion Middleware再構成ウィザードを実行します。
コマンド・ラインから、WebLogic Scripting Toolを使用します。
注意:
ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードまたはWLSTを使用してドメインをアップグレードする前に、ドメインのバックアップの説明に従ってドメインをバックアップしていることを確認してください。再構成プロセス中にエラーその他の中断が発生した場合は、バックアップの場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーして、ドメインをリストアする必要があります。これは、再構成前にドメインを確実に元の状態に戻す唯一の方法です。
ドメインを再構成する場合:
ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンのメジャーおよびマイナー・バージョン番号(たとえば、12.2.1.0)に更新されます。
すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。
起動スクリプトが更新されます。
ドメインを再構成する場合は次の項目に注意してください。
管理サーバーのドメインを再構成した後で、再構成されたドメインをドメイン内のすべてのリモート管理対象サーバーにポートする必要があります。詳細は、「リモート・マシンの管理対象サーバー・ドメインの更新」を参照してください
WLSTまたは再構成ウィザードのいずれかを使用してホストごとのノード・マネージャにドメインを再構成した後で、ノード・マネージャ構成を完了するための追加の手順を実行する必要があります。ノード・マネージャ構成の完了およびノード・マネージャ構成の完了(2つのホストごとのノード・マネージャ)を参照してください。
グラフィカル・モードで再構成ウィザードを使用してWebLogicドメインを再構成するには、次のようにウィザードを起動します。DOSコマンド・プロンプト・ウィンドウまたはUNIXシェルからのみ再構成ウィザードを起動できます。
注意:
GUIモードで再構成ウィザードを実行できない状況では、WLSTスクリプトを使用してドメインを再構成することをお薦めします。詳細は、「WebLogic Scripting Toolを使用したWebLogicドメインの再構成」を参照してください
Windowsコマンド・プロンプトまたはUNIXシステムから、再構成ウィザードをグラフィカル・モードで起動する手順は次のとおりです。
再構成ウィザードでは、表3-3にリストされる順序で一連の画面が表示されます。各画面の詳細は、再構成ウィザードの画面の関連項目を参照するか、または「画面」列のリンクをクリックします。
注意:
ドメインおよび他の要因により、アプリケーションによって、次の表に表示される画面のほかに、追加の構成画面が表示される場合もあります。これらの画面の詳細は、画面上の「ヘルプ」ボタンをクリックするか、再構成ウィザードの画面を参照してください。
再構成中に「拡張構成」画面が表示される場合は、オプションを選択しないで、すべての拡張構成をスキップしてくだい。必要に応じて、後でWLST、構成ウィザードまたはWebLogic Server管理コンソールを使用して、サーバーおよびクラスタの追加やデプロイメント・ターゲット指定の変更などの拡張構成を実行できます。
表3-3 既存のWebLogicドメインの再構成
画面 | 画面がいつ表示されるか | 次のアクションを実行 |
---|---|---|
常時 |
ドメイン・ディレクトリへのフルパスを入力するか、「参照」をクリックして、ドメイン・ディレクトリに移動して選択します。 「次へ」をクリックして、続行します。 |
|
常時 |
再構成テンプレートのアプリケーションの進行状況を表示します。 処理が終了したら、「次へ」をクリックして、続行します。 |
|
常時 |
ドメイン・モードは変更できません。 ドメインで使用するJDKを選択するか、「参照」をクリックして使用するJDKに移動します。 「次へ」をクリックして、続行します。 |
|
この時点で追加のドメイン構成画面が表示される場合があります。 |
追加の画面はドメイン構成によって異なります。 |
画面の「ヘルプ」ボタンをクリックするか、または表示順に画面のすべてが説明されている再構成ウィザードの画面を参照してください。 |
常時 |
詳細構成タスクを実行する各カテゴリ(存在する場合)のチェック・ボックスを選択します。 使用可能なチェック・ボックスは、ドメイン構成によって異なります。 「次へ」をクリックして、続行します。 |
|
この時点で追加のドメイン構成画面が表示される場合があります。 |
追加の画面は、選択した「拡張構成」オプションによって異なります。 |
画面の「ヘルプ」ボタンをクリックするか、または表示順に画面のすべてが説明されている再構成ウィザードの画面を参照してください。 |
常時 |
構成を確認します。 構成を変更するには「戻る」ボタンをクリックし、ドメイン再構成プロセスを完了するには「再構成」ボタンをクリックします。 |
|
常時 |
再構成プロセスの最終ステータスを表示します。 構成ウィザードを終了するには、「終了」をクリックします。 |
この項では、readDomainForUpgrade
コマンドを使用し、オフライン・モードでWebLogic Scripting Tool (WLST)を使用してドメインを再構成する方法について説明します。
注意:
元のドメインがドメインごとのノード・マネージャ構成を使用している場合、ノード・マネージャは自動的にアップグレードされ、追加の手順は必要ありません。
元のドメインがホストごとのノード・マネージャを使用していて、その構成の使用を続行する場合、「ノード・マネージャ構成の完了」の説明に従って、ノード・マネージャを手動で再構成する必要があります
例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()
再構成したドメインがホストごとのノード・マネージャ構成を使用していて、そのドメインのホストごとのノード・マネージャの使用を続行する場合、再構成の後で、次の手順を実行します。
新しいWebLogic Serverのインストールでは、ORACLE_HOME/oracle_common/commonにnodemanager
ディレクトリを作成します。
nodemanager.propertiesおよびnodemanager.domainsファイルを以前のWebLogic ServerインストールのWL_HOME/common/nodemanagerディレクトリから、手順1で作成したディレクトリにコピーします。
以前のインストールにnm_data.properties、SerializedSystemIni.dataまたはsecurity/SerializedSystemIni.datファイルが含まれている場合は、それを手順1で作成したディレクトリにコピーします。SerializedSystemIni.datをコピーする場合は、nodemanager
ディレクトリの下にsecurity
ディレクトリを作成して、そこにファイルを格納します。
nodemanager.propertiesファイルに次の編集を行います。ORACLE_HOMEは、WebLogic Server 12.2.1.1.0インストールのOracleホーム・ディレクトリです。
DomainsFile
をORACLE_HOME/oracle_common/common/nodemanager/nodemanager.domainsファイルを指すように更新します。
JavaHome
をWebLogic Server 12.2.1.1.0に対して使用しているJDKのjre
ディレクトリを指すように更新します。ファイルにjavaHome
プロパティ設定(小文字のj
)も含まれる場合、必要ではないため削除します。
NodeManagerHome
をORACLE_HOME/oracle_common/common/nodemanagerを指すように更新します。
LogFile
をORACLE_HOME/oracle_common/common/nodemanager/nodemanager.logを指すように更新します。
独自のセキュリティ証明書を使用している場合は、これらの証明書の場所がnodemanager.propertiesで正しいことを確認します。証明書を別の場所に移動した場合はパスを更新する必要がある場合があります。
以前のインストールでWebLogic Serverデモ証明書を使用していた場合は、CertGen
を実行してこのインストールのデモ・キーストアを作成する必要があります。
setWLSEnv
を実行します。
cd
WL_HOME
/server/bin
. ./setWLSEnv.sh
(UNIX)
setWLSEnv.cmd
(Windows)
注意:
UNIXオペレーティング・システムでは、setWLSEnv.sh
コマンドはすべてのコマンド・シェルで環境変数を設定しません。Kornシェルまたはbashシェルを使用してこのコマンドを実行することをお薦めします。
ORACLE_HOME/oracle_common/common/nodemanager/ディレクトリに変更し、存在しない場合はセキュリティ・ディレクトリを作成します。
セキュリティ・ディレクトリに変更し、次のコマンドを入力します。
java utils.CertGen -certfile democert -keyfile demokey -keyfilepass DemoIdentityPassPhrase
次のコマンドを入力して、DemoIdentity.jksファイルを生成します。
java utils.ImportPrivateKey -certfile democert.pem -keyfile demokey.pem -keyfilepass DemoIdentityPassPhrase -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -alias demoidentity
ORACLE_HOME/wlserver/server/bin directoryから、startNodeManager.cmd
(Windows)またはstartNodeManager.sh
(UNIX)を実行します。
ノード・マネージャを使用してサーバーを起動できることを確認します。詳細は、Oracle WebLogic Serverノード・マネージャの管理のノード・マネージャを使用したサーバーの制御に関する項を参照してください。permgen
設定がサーバーの起動に十分であることを確認するには、次の方法のいずれかを使用できます。
startManagedWebLogic
スクリプトを使用して管理対象サーバーを起動します。
nodemanager.properties
のStartScriptEnabled
値をtrue
に設定します。これにより、管理対象サーバーの起動時にStartManagedWebLogic
スクリプトを起動できます。
permgen領域の設定の説明に従って、permgen
領域を設定します。
サーバーを起動するためにsetUserOverrides
スクリプトを使用してpermgen
設定を指定します。詳細は、Oracle WebLogic Serverサーバーの起動と停止の管理のドメイン全体のサーバー・パラメータのカスタマイズに関する項を参照してください。
再構成したドメインがホストごとのノード・マネージャ構成を使用していて、11gドメインのホストごとのノード・マネージャがすでにあるマシンで12cドメインのホストごとのノード・マネージャの使用を続行する場合、再構成の後で、ドメイン内の各マシンで次の手順を実行します。
注意:
この項の手順を実行する前に、ドメイン内の各リモート・マシンにドメインを解凍したことを確認してください。コマンドに-nodemanager_type=ManualNodeManagerSetup
パラメータおよび-overwrite_domain=true
パラメータを含めます。例:
./unpack.sh -domain=domain_home -template=template_jar -nodemanager_type=ManualNodeManagerSetup -overwrite_domain=true
新しいWebLogic Serverのインストールでは、ORACLE_HOME/oracle_common/commonにnodemanager
ディレクトリを作成します。
nodemanager.domainsおよびnodemanager.propertiesファイルを、以前のWebLogic ServerインストールのWL_HOME/common/nodemanagerディレクトリから、手順1で作成したディレクトリにコピーします。11gドメインがnodemanager.domainsにリストされている場合、その行を削除またはコメント・アウトします。
各マシンでnodemanager.propertiesファイルを適切に編集します。具体的には、次のとおりです。
SecureListener
が、SSLノード・マネージャを使用している場合はtrue
に設定され、プレーン・ノード・マネージャを使用している場合はfalse
に設定されていることを確認してください。
DomainsFile
をORACLE_HOME/oracle_common/common/nodemanager/nodemanager.domainsを指すように変更します。
PropertiesVersion
を12.1
に変更します。
NodeManagerHome
をORACLE_HOME/oracle_common/common/nodemanagerに変更します。
JavaHome
を、WebLogic Server 12.2.1.1.0で使用しているJavaインストールのjreディレクトリを指すように変更します。
javaHome
行は、12cで必要ではないため削除します。
ListenPort
を、構成ウィザードの「マシン」画面で指定した値に変更します。
LogFile
を目的の場所およびファイル名に変更します。推奨値はORACLE_HOME/oracle_common/common/nodemanager/nodemanager.logです。
独自のセキュリティ証明書を使用している場合は、これらの証明書の場所がnodemanager.propertiesで正しいことを確認します。証明書を別の場所に移動した場合はパスを更新する必要がある場合があります。
以前のインストールでWebLogic Serverデモ証明書を使用していた場合は、CertGen
を実行してこのインストールのデモ・キーストアを作成する必要があります。
setWLSEnv
を実行します。
cd
WL_HOME
/server/bin
. ./setWLSEnv.sh
(UNIX)
setWLSEnv.cmd
(Windows)
注意:
UNIXオペレーティング・システムでは、setWLSEnv.sh
コマンドはすべてのコマンド・シェルで環境変数を設定しません。Kornシェルまたはbashシェルを使用してこのコマンドを実行することをお薦めします。
ORACLE_HOME/oracle_common/common/nodemanager/ディレクトリに変更し、存在しない場合はセキュリティ・ディレクトリを作成します。
セキュリティ・ディレクトリに変更し、次のコマンドを入力します。
java utils.CertGen -certfile democert -keyfile demokey -keyfilepass DemoIdentityPassPhrase
次のコマンドを入力して、DemoIdentity.jksファイルを生成します。
java utils.ImportPrivateKey -certfile democert.pem -keyfile demokey.pem -keyfilepass DemoIdentityPassPhrase -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -alias demoidentity
ORACLE_HOME/wlserver/server/binディレクトリから、ノード・マネージャを起動します。
管理サーバーが実行中の場合、管理サーバーを再起動します。
ノード・マネージャを使用してサーバーを起動できることを確認します。詳細は、Oracle WebLogic Serverノード・マネージャの管理のノード・マネージャを使用したサーバーの制御に関する項を参照してください。permgen
設定がサーバーの起動に十分であることを確認するには、次の方法のいずれかを使用できます。
startManagedWebLogic
スクリプトを使用して管理対象サーバーを起動します。
nodemanager.properties
のStartScriptEnabled
値をtrue
に設定します。これにより、管理対象サーバーの起動時にStartManagedWebLogic
スクリプトを起動できます。
permgen領域の設定の説明に従って、permgen
領域を設定します。
サーバーを起動するためにsetUserOverrides
スクリプトを使用してpermgen
設定を指定します。詳細は、Oracle WebLogic Serverサーバーの起動と停止の管理のドメイン全体のサーバー・パラメータのカスタマイズに関する項を参照してください。
WebLogicドメインに複数の管理対象サーバーが含まれ、各管理対象サーバー・ドメイン・ディレクトリが管理サーバーが存在しないリモート・マシン上にある場合、そのリモート・マシン上のドメインを更新するには次の方法のいずれかを使用できます。
pack
コマンドに-managed=true
引数が含まれていることを確認し、pack
を使用してドメイン・テンプレートJARを生成します。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 12.2.1.1.0のアプリケーション環境で動作します。実際の環境においてアプリケーションが機能変更の影響を受けるかどうかについては、WebLogic Server 12.2.1.1.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 12.2.1.1.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
を削除します。これを行うには、次の行の後でJAVA_OPTIONS=""
を設定します。
. ${WL_HOME}/common/bin/commEnv.sh
そうでない場合、JVMエラーのためサーバーの起動に失敗します。
アプリケーション環境をアップグレードした後で、次のタスクを実行する必要がある場合があります。
必ずしもすべての手順を実行する必要があるわけではありません。以下の説明に基づいて、アプリケーション環境に必要な手順を決定してください。互換性の問題が環境に適用されるかどうかについては、WebLogic Server 12.2.1.1.0の旧リリースとの互換性で互換性問題を確認してください。
アプリケーション環境の12.2.1.1.0へのアップグレードを完了するには、起動スクリプトへのカスタマイズの再適用が必要になる場合があります。次の節では、デフォルト起動スクリプトおよびカスタム起動スクリプトをカスタマイズする方法について説明します。
再構成ウィザードによるアップグレード・プロセスでは、デフォルト起動スクリプトに対して行われたカスタマイズの内容(JAVA_OPTIONS
環境変数の設定など)は保持されません。アップグレード・プロセスが完了した後に、デフォルト起動スクリプトを再びカスタマイズする必要があります。
ドメインを12.2.1.1.0にアップグレードすると同時にPointBaseを継続して使用する場合は、PointBaseのJARファイルをCLASSPATH環境変数定義の先頭に追加する必要があります。これを行うには、setDomainEnvファイル内のset CLASSPATH
文を変更します。
注意:
WebLogic Server 12.2.1.1.0ではPointBase 5.7がサポートされますが、PointBaseの任意のバージョンをWebLogic Server 10.3.3以上で使用するには、http://www.pointbase.com
で入手できるPointBaseのライセンスが必要です。
カスタム起動スクリプトを作成した場合は、次の手順に従って手動で更新する必要があります。
JDKバージョンをWebLogic Serverで使用しているJDKに設定します。
次のようにCLASSPATH変数を更新します。
WebLogic Server 12.2.1.1.0のクラスを変数の先頭に追加します。
使用されていない10.3より前のバージョンのWebLogicのクラスをすべて削除します。
PointBaseを継続して使用するには、PointBaseデータベースのJARをCLASSPATH環境変数定義の最初に追加します。
評価版データベースを使用するドメインのアップグレードの詳細は、「評価版データベースを使用するドメインのアップグレード」を参照してください
次のようにファイル権限を確認します。
アップグレード・プロセスにおいてドメイン・ディレクトリのバックアップを行った場合、バックアップ・ファイルには機密情報が含まれている可能性があるため、バックアップ・ファイルを保護する必要があります。
アップグレード・プロセスでは、ファイル権限は保持されません。デフォルト以外のファイル権限がファイルに設定されている場合は、これらを確認し、リセットする必要があります。
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用のノード・マネージャの構成方法の詳細は、Oracle WebLogic Serverノード・マネージャの管理のデフォルトのノード・マネージャの構成に関する項を参照してください。
オプションで、uninstallNodeMgrSrv.cmd
を実行して、インストールからノード・マネージャ・サービスを削除できます。Oracle WebLogic Serverノード・マネージャの管理のノード・マネージャのデフォルト構成に関する項を参照してください。
アプリケーション環境を本番環境にプロモートする前に、標準的な品質保証およびパフォーマンス・チューニングを行います。テスト・アプリケーション環境でアプリケーション(外部クライアント・アプリケーションを含む)の動作をテストすることをお薦めします。非推奨となったAPIまたは削除されたAPIがアプリケーションで使用されている場合は、実行時に警告または例外が発生するおそれがあります。発生した場合は、アプリケーション環境を本番環境にプロモートする前に、必要な修正を行う必要があります。
すべてのテスト基準をクリアしていれば、「ステップ4: アップグレード計画の作成」で定義したアップグレード計画に従って、アプリケーション環境を本番環境にプロモートできます。
新しい12.2.1.1.0のアプリケーション環境が本番環境にデプロイされたら、既存の環境から新しい環境にリクエストをリダイレクトできるようになります。このようにして、最終的には、既存の環境を安全な停止状態にすることができます。これは、ロード・バランサなどを使用して行います。
WebLogic 10.3.3以降、インストール・プログラムに含まれる評価版データベースが、PointBaseからDerbyに変更されています。評価版データベースは、サンプル・アプリケーションやコード例で使用されるため、またデモンストレーション・データベースとして使用するために提供されます。PointBaseを使用していたサンプルやデモのドメインをアップグレードする場合は、ドメインのPointBaseを引き続き使用するオプションがあります。
WebLogic 12.2.1.1.0にアップグレードするドメインでデータベースとして引き続きPointBaseを使用するには、次の手順を実行します。