test

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

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 コマンドを実行して、手動で共有コンポーネントをコピーしてください。