test

Sun Java System Application Server Enterprise Edition 8.2 アップグレードと移行

第 2 章 Application Server インストールのアップグレード

Application Server 8.2 に付属するアップグレードツールは、ターゲットインストールに以前にインストールされたサーバーの設定をレプリケートします。アップグレードツールは、Application Server の設定、アプリケーション、および認証データを以前のバージョンから Application Server 8.2 にアップグレードするのに役立ちます。アップグレードできる Application Server の旧バージョンの一覧については、表 2–1 を参照してください。

次の内容について説明します。

アップグレードの概要

次の表に、サポートされる Sun Java System Application Server のアップグレードを示します。この表では、PE は Platform Edition、EE は Enterprise Edition を表します。

表 2–1 サポートされるアップグレードパス

元のインストール 

8.2 Platform Edition 

8.2 Enterprise Edition 

7.X PE 

サポートされていない 

O 

7.XSE 

- 

O 

7.XEE 

- 

O 

8.0PE 

O 

O 

8.1PE 

O 

O 

8.1EE 

- 

O 

8.2PE 

- 

O 

注 –

8.1 SE から 8.2 EE へのアップグレードでは、HADB パッケージのインストールのみを行います。アップグレードツールを使用する必要はありません。

アップグレードツールを起動するには、asupgrade コマンドを発行するか、Application Server インストーラの「アップグレード」オプションを選択します。

アップグレードツールのインタフェース

このツールは、コマンド行インタフェース (CLI) または GUI を介して使用できます。

アップグレードツールを GUI モードで使用するには、オプションを付けずに asupgrade コマンドを発行します。

アップグレードツールを CLI モードで実行するには、--c/--console オプションを指定して asupgrade コマンドを起動します。アップグレード CLI は、対話型モードまたは非対話型モードで実行できます。コンソールで asupgrade を起動するときに必要な引数をすべて指定した場合は、非対話型モードでアップグレードが実行され、それ以上の入力は必要ありません。asupgrade のオプションの完全なリストについては、表 2–2 を参照してください。--c/--console オプションのみを指定してツールを起動すると、ツールは対話型 CLI モードになり、ユーザーは一連の入力を求められます。

アップグレードの用語

アップグレード処理に関する重要な用語を次に示します。

アップグレードツールの機能

アップグレードツールは、設定、配備されたアプリケーション、および認証データベースを Application Server の以前のバージョンから最新バージョンに移行します。アップグレードツールでは、Application Server のバイナリはアップグレードされません。バイナリのアップグレードはインストーラで実行します。データベースの移行や変換もこのアップグレード処理の範囲外です。

Sun Java System Web Server 固有の機能を使用しないインスタンスのみがシームレスにアップグレードされます。HTTP パス、CGI バイナリ、SHTML、および NSAPI プラグインに関する設定ファイルは、アップグレードされません。

注 –

アップグレード処理を開始する前に、ソースサーバー (アップグレードする元のサーバー) とターゲットサーバー (アップグレードする先のサーバー) の両方が停止していることを確認します。

配備されたアプリケーションの移行

Application Server 7.x/8.0 環境に配備されているアプリケーションアーカイブ (EAR ファイル) とコンポーネントアーカイブ (JAR ファイル、WAR ファイル、および RAR ファイル) は、何も変更せずに Application Server 8.2 上で実行できます。

ソースサーバーに配備されているアプリケーションとコンポーネントは、アップグレード時にターゲットサーバーに配備されます。ターゲットサーバーに正常に配備されないアプリケーションは、Migration Tool または asmigrate コマンドを使用して移行し、手動で再配備する必要があります。移行ツールを使用したアプリケーションの移行については、第 6 章「Application Server 6.x/7.x からの移行」を参照してください。

配備されているアプリケーションに関する情報がドメインに含まれており、インストール済みのアプリケーションコンポーネントがその設定情報と一致しない場合、不正な設定は再設定されずにそのまま移行されます。

クラスタのアップグレード

Application Server 7.x でクラスタを含む設定をアップグレードするときは、1 つ以上のクラスタファイルまたは clinstance.conf ファイルを指定します。Application Server 8.x では、クラスタが domain.xml ファイルで定義されるため、個々のクラスタを指定する必要はありません。もう 1 つの大きな違いとして、Application Server 8.x では、クラスタ内のすべてのインスタンスが同じドメイン内にあり、したがって同じ domain.xml ファイル内にあります。Application Server 7.x では、1 つのクラスタを形成するインスタンスが複数のドメインにまたがっている可能性があります。

証明書とレルムファイルの転送

アップグレードツールは、ソース証明書データベースからターゲットに証明書を転送します。このツールは、JKS 証明書から NSS 証明書への変換をサポートします。このツールは、セキュリティーポリシー、標準のファイルベースレルムのパスワードファイル、およびカスタムレルムクラスを転送します。認証データベースのパスワードを指定する際の具体的な要件については、「アップグレードの前に」を参照してください。

アップグレードログ

アップグレードログには、アップグレードのアクティビティーが記録されます。アップグレードログファイルは、upgrade.log という名前で、アップグレードが行われるドメインのルートに作成されます。

アップグレードのロールバック

実行中のアップグレードが取り消された場合は、アップグレード開始前の設定が復元されます。

アップグレードシナリオ

アップグレード実行の 3 つのシナリオを次に示します。

アップグレードの前に

次の各シナリオでは、アップグレードの前に次の手順を実行する必要があります。

注意 – 注意 –

キーストアや認証データベースのパスワードを変更していない場合は、アップグレードツールによる証明書転送処理が異常終了することがあります。

アップグレード後に、キーストアや認証データベースのパスワードの値を復元したい場合は、keytool ユーティリティーや certutil ユーティリティーを使用して手動で値を復元できます。

コマンド行からのアップグレード

アップグレードユーティリティーは、次の構文を使用してコマンド行から実行します。

asupgrade 
[--console ] 
[--version ] 
[--help ] 
[--source applicationserver_7.x/8.x_installation] 
[--target applicationserver_8.2_installation] 
[--domain domain_name]
[--adminuser admin_user]
[--adminpassword admin_password]
[--masterpassword master_password]
[--targetnsspwdfile targetNSS_password_filepath] 
[--nsspwdfile NSS_password_filepath] 
[--jkspwdfile JKS_password_filepath] 
[--capwdfile CA_password_filepath] 
[--clinstancefiles file1 [, file2, file3, ... filen]]

次の表に、コマンドオプションの詳細 (短い書式、長い書式、および説明) を示します。

表 2–2 asupgrade ユーティリティーのコマンドオプション

短い書式 

長い書式 

説明 

-c 

--console 

アップグレードコマンド行ユーティリティーを起動します。 

-V 

--version 

アップグレードツールのバージョン。 

-h or -? 

--help 

アップグレードユーティリティーを起動する際の引数を表示します。 

-t 

--target 

Application Server 8.2 EE インストールのドメインルートディレクトリ。 

-s 

--source 

ソースが Application Server 7.x の場合は、インストールディレクトリ。ソースが Application Server 8.x で、インプレースアップグレードが行われた場合は、ドメインルートディレクトリ。ソースが Application Server 8.x で、サイドバイサイドアップグレードが行われた場合は、ドメインディレクトリ domain-dir。

-d 

--domain 

移行する証明書のドメイン名。 

-a 

--adminuser 

管理者ユーザーのユーザー名 

-w 

--adminpassword 

管理者パスワード 

-m 

--masterpassword 

マスターパスワード 

-n 

--nsspwdfile 

NSS パスワードファイルへのパス。このファイルは、パスワードのみを格納するプレーンテキストファイルです。 

-e 

--targetnsspwdfile 

ターゲットの NSS パスワードファイルへのパス。このファイルは、パスワードのみを格納するプレーンテキストファイルです。 

-j 

--jkspwdfile 

JKS パスワードファイルへのパス。このファイルは、パスワードのみを格納するプレーンテキストファイルです。 

-p 

--capwdfile 

CA 証明書パスワードファイルへのパス。このファイルは、パスワードのみを格納するプレーンテキストファイルです。 

-i 

--clinstancefiles 

ソースインストールが Application Server 7.x の場合は、クラスタファイルへのパス。デフォルトのファイル名は $AS_INSTALL/conf/clinstance.conf です。

次の例は、asupgrade コマンド行ユーティリティーを使用して既存のアプリケーションサーバーインストールを Application Server 8.2 にアップグレードする方法を示しています。

例 1: 証明書移行の確認を含む Application Server 7 インストールの Application Server 8.2 EE へのアップグレード

この例は、Sun Java SystemApplication Server 7 インストールの Sun Java System Application Server 8.2 へのサイドバイサイドアップグレードの実行方法を示しています。このコマンドは、証明書を移行するかどうかをユーザーに確認します。移行しないことを選択した場合、証明書は移行されません。

asupgrade --source /home/sunas7 --target /home/sjsas8.2/domains

例 2: クラスタと NSS 証明書を含む Application Server 7.1 EE インストールの Application Server 8.2 EE へのアップグレード

この例は、クラスタを含む Sun Java System Application Server 7.1 EE インストールの Sun Java System Application Server 8.2 EE へのサイドバイサイドアップグレードの実行方法を示しています。NSS 証明書は、clinstance.conf クラスタファイルと同じように移行されます。

asupgrade --source /home/sjsas7.1 --target /home/sjsas8.2/domains --domain domain1 
--nsspwdfile /home/sjsas7.1/nsspassword.txt 
--targetnsspwdfile /home/sjsas8.2/nsspassword.txt 
--clinstancefiles /home/sjsas7.1/config/clinstance.conf

アップグレード後、すべてのリモートインスタンスのノードエージェントがターゲットの DAS 上に作成されます。これらのノードエージェントは、それぞれのホストシステムにコピーして起動する必要があります。詳細は、「Application Server 7.x EE からノードエージェントをアップグレードする」を参照してください。

例 3: クラスタと NSS 証明書を含む Application Server 8.1 EE インストールの Application Server 8.2 EE へのアップグレード (インプレース)

この例は、クラスタを含む Sun Java System Application Server 8.1 EE インストールの Sun Java System Application Server 8.2 EE へのインプレースアップグレードの実行方法を示しています。NSS 証明書は、clinstance.conf クラスタファイルと同じように移行されます。

asupgrade --source /home/sjsas8.1/domains 
--target /home/sjsas8.2/domains 
--domain domain1 
--nsspwdfile /home/sjsas8.1/nsspassword.txt 
--targetnsspwdfile /home/sjsas8.2/nsspassword.txt 
--clinstancefiles /home/sjsas8.1/config/clinstance.conf

アップグレード後、すべてのリモートインスタンスのノードエージェントがターゲットの DAS 上に作成されます。これらのノードエージェントは、それぞれのホストシステムにコピーして起動する必要があります。詳細は、「Application Server 8.1 EE からノードエージェントをアップグレードする」を参照してください。

例 4: クラスタと NSS 証明書を含む Application Server 8.1 EE インストールの Application Server 8.2 EE へのアップグレード (サイドバイサイド)

この例は、クラスタを含む Sun Java System Application Server 8.1 EE インストールの Sun Java System Application Server 8.2 EE へのサイドバイサイドアップグレードの実行方法を示しています。NSS 証明書は、clinstance.conf クラスタファイルと同じように移行されます。

asupgrade --source /home/sjsas8.1/domains/domain1 --target /home/sjsas8.2/domains 
--domain domain1 --nsspwdfile /home/sjsas8.1/nsspassword.txt 
--targetnsspwdfile /home/sjsas8.2/nsspassword.txt 
--clinstancefiles /home/sjsas8.1/config/clinstance.conf

ウィザードによるアップグレード

GUI モードのアップグレードウィザードは、コマンド行またはデスクトップから起動できます。

ウィザードを起動するには、次の手順に従います。

- UNIX では、<install_dir>/bin ディレクトリに移動し、asupgrade と入力します。

- Windows では、<install_dir>/bin ディレクトリの asupgrade アイコンをダブルクリックします。

Application Server のインストール時に「アップグレード」チェックボックスを選択した場合は、インストールの完了後に自動的にアップグレードウィザード画面が表示されます。

Procedureアップグレードウィザードを使用する

  1. 「ソースインストールディレクトリ」フィールドに、設定のインポート元となる既存のインストールの場所を入力します。

    「ソースインストールディレクトリ」フィールドには、Application Server の古いインストールのバージョンと実行するアップグレードのタイプに応じて適切な値を入力します。有効な値は次のとおりです。

    • Application Server 7.x からアップグレードする場合は、Application Server 7.x のインストールルートを入力します。たとえば、Solaris/Linux ユーザーの場合は /home/sunappserver7.1、Windows ユーザーの場合は C:\ProgramFiles\SunAppserver7.1 などです。Application Server 7.x からアップグレードする場合は、サイドバイサイドアップグレードのみを実行できます。

    • Application Server 8.x からのインプレースアップグレードを実行する場合は、ドメインルートを入力します。たとえば、Solaris/Linux ユーザーの場合は /home/sunappserver7.1/domains、Windows ユーザーの場合は C:\ProgramFiles\SunAppserver7.1\domains などです。

    • Application Server 8.x からのサイドバイサイドアップグレードを実行する場合は、ドメインディレクトリを入力します。たとえば、Solaris/Linux ユーザーの場合は /home/sunappserver7.1/domains/domain1、Windows ユーザーの場合は C:\ProgramFiles\SunAppserver7.1\domains\domain1 などです。

  2. 「ターゲットインストールディレクトリ」フィールドに、設定のインポート先となる Application Server インストールの場所を入力します。

    アップグレードウィザードをインストールから起動した (Application Server のインストール時に「旧バージョンからアップグレード」チェックボックスを選択した) 場合、このフィールドのデフォルト値は Application Server ソフトウェアをインストールしたディレクトリになります。アップグレードツールがインストーラ経由で起動されなかった場合や、Application server 7.x からアップグレードする場合は、Application Server 8.2 EE インストールのドメインルートをこのフィールドに入力する必要があります。たとえば、Solaris/Linux ユーザーの場合は /home/sunappserver8.2/domains、Windows ユーザーの場合は C:\ProgramFiles\SunAppserver8.2\domains などです。

  3. Application Server 7.x からアップグレードする場合は、Application Server 7.x のインストールで使用した管理者ユーザー名、管理パスワード、およびマスターパスワードを入力する必要があります。ターゲットサーバー (Application Server 8.2) のインストール時にドメインを作成した場合は、Application Server 7.x で使用したのと同じ管理者資格を使用していることが必要です。Application Server 7.x ドメインが複数ある場合は、すべてのドメインに同じ管理者資格が必要です。Application Server 8.x をアップグレードする場合は、管理ユーザー名として admin を、管理パスワードとして adminadmin を、マスターパスワードとして changeit をそれぞれ入力する必要があります。ほかの値を入力すると、アップグレードツールはそれらの値を無視し、管理者資格にデフォルト値を割り当てます。

    注 –

    アップグレードの前に必要な作業については、「アップグレードの前に」を参照してください。

  4. クラスタがあってセキュリティー証明書がない Application Server 7.x Enterprise Edition インストールをアップグレードする場合は、「次へ」ボタンをクリックして手順 10 に進み、クラスタファイルの情報を入力します。Application Server 8.x Enterprise Edition を Application Server 8.2 Enterprise Edition にアップグレードする場合は、「次へ」ボタンをクリックしてアップグレードを続行します。アップグレードツールがソースインストール内のクラスタを自動的に検出します。セキュリティー証明書を変換する必要がある場合は、手順 5 に進みます。

  5. ソースインストールに変換が必要なセキュリティー証明書がある場合は、「セキュリティー証明書を転送」チェックボックスを選択して「次へ」ボタンをクリックします。

    「セキュリティー証明書を転送」画面が表示されます。

  6. 「セキュリティー証明書を転送」画面で、「ドメインを追加」ボタンをクリックし、転送する証明書を含むドメインを追加します。

    「ドメインを追加」ダイアログが表示されます。

  7. 「ドメインを追加」ダイアログで、移行するセキュリティー証明書を含むドメイン名を選択し、適切なパスワードを入力します。

  8. 作業が完了したら、「了解」ボタンをクリックします。

    「セキュリティー証明書を転送」画面がもう一度表示されます。

  9. 手順 6 と 7 を繰り返して、転送する証明書があるドメインをすべて追加します。作業が完了したら、「次へ」ボタンをクリックします。

  10. クラスタがある Sun Java System Application Server 7.1 Enterprise Edition インストールを Sun Java System Application Server 8.2 Enterprise Edition にアップグレードする場合は、「クラスタ設定を転送」画面が表示されます。「クラスタを追加」ボタンをクリックします。

    「clinstance.conf ファイルの選択」ダイアログボックスが表示されます。clinstance.conf ファイルを選択し、「開く」ボタンをクリックします。clinstance.conf ファイルがリストに追加されます。

  11. 手順 10 を繰り返して、移行する必要があるクラスタ設定ファイルをすべて追加します。「次へ」ボタンをクリックします。

    この処理を繰り返して、移行する必要があるクラスタ設定ファイルをすべて追加し、「次へ」ボタンをクリックします。

  12. アップグレード操作のステータスを示す「アップグレードの結果」パネルが表示されます。

  13. アップグレード処理が完了したら、「完了」ボタンをクリックしてアップグレードツールを閉じます。

クラスタのアップグレード

Application Server のアップグレードツールは、クラスタの詳細情報をクラスタ設定ファイル clinstance.conf から取得します。Application Server 7.x に対して 2 つ以上のクラスタが定義されていた場合、アップグレード前に複数の .conf ファイルが存在している可能性があります。設定ファイルには任意の名前をつけることができますが、その拡張子は常に .conf になります。クラスタがアップグレードに含まれる場合、clinstance.conf ファイルの定義時に次の点を考慮してください。clinstance.conf ファイル内のインスタンス名は一意である必要があります。たとえば、Application Server 7.x において、マシン A 上に特定のクラスタに属する server1 と server2 が存在しているとします。また、マシン B 上にも、それと同じクラスタに属する server1 が存在しているとします。通常、clinstance.conf ファイルにはマシン A の server1 と server2、およびマシン B の server1 が含まれます。Application Server 8.1 では、クラスタ内のインスタンス名が一意である必要があります。このため、アップグレードする前に、clinstance.conf ファイル内のマシン B の名前 server1 を server3 や server1ofmachineB のような一意の名前に変更する必要があります。

注 –

マシン B 内の server1 インスタンス自体の名前を変更する必要はありません。変更する必要があるのは、clinstance.conf ファイル内のサーバー名だけです。

なお、クラスタ内のインスタンスは「同種」であることが期待されますが、それは、同種のリソースを備え、同一のアプリケーションが配備されている、という意味においてです。アップグレード処理を実行すると、マスターインスタンスとしてマークされたインスタンスが、設定転送用として選択されます。マスターインスタンスとしてマークされたインスタンスが存在しない場合は、インスタンスのうちの 1 つがランダムに選択され、それが設定転送用として使用されます。クラスタは、clinstance.conf ファイル内に定義されているインスタンスとともに、DAS 内で作成されます。このクラスタに属するインスタンスはすべて、cluster_name-config という名前の同一の設定を共有します。ここで、cluster_name は、最初のクラスタでは cluster_0、次のクラスタでは cluster_1、といった具合になります。クラスタ内の各インスタンスのシステムプロパティー内には、HTTP ポートと IIOP ポートが設定されます。HTTP ポートは、clinstance.conf ファイル内でインスタンスポートとして定義されていたポートになります。IIOP ポートは、server.xml ファイル内の iiop-cluster 設定から選択されます。

Application Server 8.x EE を Application Server 8.2 EE にアップグレードする場合は、アップグレードツールがソースインストール上のクラスタを (存在する場合は) 自動的に検出します。この場合、設定ファイルを指定する必要はありません。

ProcedureApplication Server 7.x EE からノードエージェントをアップグレードする

クラスタに属しているが、DAS が実行されていないマシン上で実行されるサーバーインスタンスは、<host-name>-<domain-name> と言う名前のノードエージェントを使用して作成されます。ここで、host-name は clinstance.conf ファイル内でその特定のインスタンス用に設定された名前であり、domain-name は、このクラスタが属するドメインの名前です。

DAS 上でのアップグレード処理が完了したら、クラスタ化されたインスタンスを実行する必要があるほかのマシン上に Application Server 8.2 をインストールします。

  1. install-dir/nodeagents/ の下にあるノードエージェントのディレクトリを、DAS マシンからクライアントマシンへコピーします。たとえば、DAS が HostA 上にインストールされており、クライアントマシンの名前が HostB である場合、アップグレード処理を実行すると、「HostB_ <domain_name>」という名前のノードエージェントが、HostB のノードエージェントとして作成されます。したがって、HostB_<domain_name> を HostA<AS82_install_dir>/nodeagents/HostB_<domain_name> ディレクトリから HostB<AS82_install_dir>/nodeagents にコピーします。コピーし終わったら、そのコピーしたノードエージェントのディレクトリを HostA から削除します。

  2. DAS を起動します。

  3. HostB 上の HostB_<domain_name> という名前のノードエージェントを起動します。DAS およびリモートインスタンスとのランデブーを行うノードエージェントが HostB に作成され、配備されたアプリケーションがコピーされます。

ProcedureApplication Server 8.1 EE からノードエージェントをアップグレードする

インプレースアップグレードを実行する場合は、ノードエージェントをアップグレードする必要はありません。更新されたバイナリでも、同じノードエージェントディレクトリを使用できます。サイドバイサイドアップグレードを実行する場合は、次の手順を実行します。

  1. Application Server 8.2 EE をデフォルトノードエージェントとともに Machine B の /opt/SUNWappserver8.2 にインストールします。

  2. Application Server 8.1 EE のインストール場所からサイドバイサイドアップグレードを実行します。

  3. machine A 上の DAS を参照するリモートインスタンスを含むノードエージェントがある Machine B 上に Application Server 8.2 EE をインストールします。Machine B にはノードエージェントのみをインストールしてください。

  4. アップグレード後、Machine A および Machine B の nodeagent.properties ファイルで、agent.adminPort プロパティーを確認します。このファイルには、domain.xml ファイルの該当する node-agent 要素内の jmx-connector ポートと同じ値を反映する必要があります。そうでない場合は、nodeagent.properties ファイルを適宜編集します。

  5. Machine A 上の DAS を起動します。

  6. Machine A 上のデフォルトノードエージェントを起動します。ノードエージェントが、instance1 というインスタンスとともに起動します。この手順のあとで、cluster1 クラスタが部分的に起動します。

  7. Machine B で、そのリモートインスタンスのデフォルトノードエージェントを起動します。

  8. asadmin のコマンド list-node-agents(1)、list-clusters(1)、list-instances(1) を実行することにより、アップグレードされた要素をチェックできます。

PE および EE のアップグレード時に発生する可能性がある問題の修正

この節では、Application Server 8.2 へのアップグレード時に発生する可能性がある次の各問題に対する解決方法を示します。

古いドメイン上での --domaindir オプションの実行

Application Server 8.2 と古い Application Server 8.1 が 2 つの異なる場所にインストールされている場合は、ドメインを実際には最新バージョンにアップグレードせずに、旧バージョンの Application Server で作成されたドメイン上で --domaindir オプションを使用することもできます。このシナリオでは、ドメインが必ず Application Server の最新のバイナリを使用するように、startserv スクリプトと stopserv スクリプトを更新する必要があります。最新の場所にある asenv.conf ファイルを指し示すようにスクリプトを変更してください。

Procedureソースサーバー上で定義された追加 HTTP リスナーをターゲット PE サーバーに移行する

PE ソースサーバーで追加の HTTP リスナーが定義されていた場合、アップグレード後にそれらのリスナーを PE ターゲットサーバーに追加する必要があります。

  1. 管理コンソールを起動します。

  2. 「設定」を展開します。

  3. 「HTTP サービス」を展開します。

  4. 「仮想サーバー」を展開します。

  5. <server> を選択します。

  6. 右側の区画で、追加の HTTP リスナー名を「HTTP リスナー」フィールドに追加します。

  7. 設定が完了したら「保存」をクリックします。

Procedureソースサーバー上で定義された追加 HTTP リスナーと IIOP リスナーをターゲット EE サーバーに移行する

ソースサーバーで追加の HTTP リスナーまたは IIOP リスナーが定義されていた場合、クラスタ化されたインスタンスを起動する前に、ターゲット EE サーバーの IIOP ポートを手動で更新しておく必要があります。たとえば、クラスタに属する server1 で、追加 HTTP リスナーとして MyHttpListener が定義されていたとします。その場合、クラスタ内のサーバーインスタンスは互いに対称的になっているため、クラスタ内のほかのインスタンスでも同じ HTTP リスナーが定義されています。ターゲットの <cluster_name>-config という名前の設定内で、このリスナーを追加し、そのポートを特定のシステムプロパティー {myHttpListener_HTTP_LISTENER_PORT} に設定する必要があります。ターゲットサーバーでは、この設定を使用するこのクラスタ内のサーバーインスタンスのそれぞれが、myHttpListener_HTTP_LISTENER_PORT という名前のシステムプロパティーを持つことになります。このプロパティーの値は、どのサーバーインスタンスの場合も、ソースサーバーである server1 のポート値に設定されます。サーバーを起動する前に、これらのサーバーインスタンスのシステムプロパティーの値を競合しないポート番号に手動で更新する必要があります。

ソースサーバーで追加の HTTP リスナーが定義されていた場合、アップグレード後にそれらのリスナーをターゲットサーバーに追加する必要があります。

  1. 管理コンソールを起動します。

  2. 「設定」を展開し、対象の <server>-config 設定を選択します。

  3. 「HTTP サービス」を展開します。

  4. 「仮想サーバー」を展開します。

  5. <server> を選択します。

  6. 右側の区画で、追加の HTTP リスナー名 (複数可) を「HTTP リスナー」フィールドに追加します。

  7. 設定が完了したら「保存」をクリックします。

ポートの競合問題の解消

ソースサーバーを Application Server 8.1 EE にアップグレードし終わったら、ドメインを起動します。ノードエージェントを起動します。すると、デフォルトでサーバーインスタンスが起動します。管理コンソールを起動し、これらのサーバーが起動されていることを確認します。実行されていないサーバーが見つかった場合、install_dir/nodeagents/node-agent-name/server_name/logs/server.log ファイル内で、ポートの競合によるエラーが発生していないか確認します。ポートの競合によるエラーが発生していた場合、管理コンソールを使って競合が解消されるようにポート番号を変更します。ノードエージェントとサーバーをいったん停止し、再起動します。

Application Server 7.x SE または EE からのアップグレード時に、7.x サーバー内のいずれかのインスタンスが Application Serve 8.2 インストールによって作成されたデフォルトドメインに割り当てられたデフォルトポートと同じである場合は、ポートの競合が発生します。Application Server 8.2 EE でドメインが作成された場合にデフォルトで割り当てられるポートの値については、次のリストを参照してください。このような場合は、アップグレード後に管理コンソールを起動し、server-config のリスナーのポートを競合しないポート番号に変更してください。

注 –

Application Server 8.2 EE のデフォルトポートは、次のとおりです。

単一ドメイン内に複数の証明書データベースパスワードが存在する場合に発生する問題の解消

アップグレードに証明書が含まれる場合、移行対象の証明書を格納するドメインごとに、ソース PKCS12 ファイルとターゲット JKS キーファイルに対するパスワードを入力します。Application Server 7 が使用する証明書ストア形式 (NSS) は Application Server 8 PE が使用する形式 (JSSE) とは異なるため、移行対象の鍵と証明書はその新しい形式に変換されます。1 つのドメインでサポートされる証明書データベースパスワードは、1 つだけです。単一ドメイン内で複数の証明書データベースパスワードが使用されている場合、アップグレードを開始する前に、それらのパスワードをすべて同一のものに変更します。アップグレードの終了後にパスワードをリセットします。

サイドバイサイドアップグレード時のロードバランサプラグインに関する問題の解決

ロードバランサプラグインがほかのアプリケーションサーバーコンポーネントと同じシステムに配置されている場合は、Application Server 7.1 EE から Application Server 8.2 EE へのアップグレードでサイドバイサイドアップグレードを実行中に、新しい 8.2 のロードバランサプラグインが古い 7.1 の Web サーバーインストールを指し示すことができません。Web サーバーを再インストールし、8.2 のロードバランサプラグインインストールが新しいインストールに属するインスタンスを指し示すように設定する必要があります。

サイドバイサイドアップグレード時の共有コンポーネントに関する問題の解決

MQ と HADB を含む Application Server 7.x から Application Server 8.2 EE へのサイドバイサイドアップグレードを実行した場合は、旧バージョン (Application Server 7.x) をアンインストールしないでください。アンインストール処理によって、JAF ライブラリ、JavaMail ライブラリ、MQ ライブラリなどの共有コンポーネントが削除されます。共有コンポーネントがないと、Application Server 8.2 EE インストールが正常に機能しません。Application Server 7.x をアンインストールする場合は、pkgrm コマンドを実行して Application Server 7.x に属する SUNWas* パッケージを削除し、アンインストールスクリプトは実行しないようにしてください。アンインストールスクリプトを使用して Application Server 7.x をすでに削除した場合は、pkgadd コマンドを実行して、手動で共有コンポーネントをコピーしてください。

バイナリとリモートアップグレード

このツールでは、サーバーの実行時バイナリはアップグレードされません。アップグレードツールは、以前にインストールされたサーバーの設定情報と配備されたアプリケーションをアップグレードします。サーバーのバイナリパッケージをインストールするには、Application Server インストーラを使用する必要があります。アップグレード処理では、最初にインストーラを使用してターゲットサーバーのバイナリをインストールします。

ソースサーバーとターゲットサーバーのファイルシステム (特に、ドメインルートのファイルシステム) に同じマシンからアクセスできない場合は、アップグレードを実行できません。現在、アップグレードの大部分はファイルベースで行われます。アップグレードを実行するには、アップグレードを実行するユーザーがソースディレクトリとターゲットディレクトリの読み取りアクセス権、およびターゲットディレクトリの書き込みアクセス権を持っている必要があります。