製品構成のマイグレーション時の構成マッピング

製品構成のマイグレーション時には、さまざまな構成がマップされます。

サポートされる構成 サポートされる構成:

この項目では、プロファイル構成マイグレーションについて説明します。アプリケーションを最新バージョンにマイグレーションするには、WebSphere® Application Server Migration Toolkit を使用します。詳しくは、WASdev の Migration Toolkit を参照してください。

sptcfg

マイグレーションでは、常に単一のプロファイルを、 同一マシン上または別のマシン上の別の単一プロファイルにマイグレーションします。 例えば、WebSphere Application Server バージョン 7.0 のデプロイメント・マネージャーを、バージョン 9.0 のデプロイメント・マネージャーにマイグレーションして、バージョン 7.0 のアプリケーション・サーバーを、バージョン 9.0 のスタンドアロン・アプリケーション・サーバーにマイグレーションします。

多くのマイグレーション・シナリオが考えられます。 マイグレーション・ツールによって、マイグレーション元のバージョン内に存在するオブジェクトと属性を、バージョン 9.0 環境内の対応するオブジェクトと属性にマップします。

ブートストラップ・ポート

マイグレーション・ツールによって、古いリリースの値をバージョン 9.0 環境に取り込みます。

ただし、WASPostUpgrade の呼び出し時に -setPorts パラメーターが generateNew またはポート値に設定された場合は、そのポート値が、 バージョン 9.0 にマイグレーションされる各アプリケーション・サーバーに渡されます。

コマンド行パラメーター

マイグレーション・ツールは、該当するコマンド行パラメーターを、サーバー・プロセス定義の Java™ 仮想マシン (JVM) 設定に変換します。 ほとんどの設定は、直接マップされます。 一部の設定は、マイグレーションされません。これは、それらのロールが WebSphere Application Server バージョン 9.0 の構成内に存在しないか、バージョン 8.0 では意味が異なるか、または有効範囲が異なるためです。

プロセス定義設定の変更方法については、 『プロセス定義設定』を参照してください。JVM 設定の変更方法については、『Java 仮想マシン設定』を参照してください。

汎用サーバー
バージョン 7.0 以降では、汎用サーバーには GENERIC_SERVER と呼ばれる独自のタイプを持ちます。マイグレーションによりこの変換が実行されますが、 汎用サーバーが参照する外部リソースは正確にマイグレーションされません。 汎用サーバー設定のマイグレーションが完了後、追加のタスクを実行する必要があります。 汎用サーバーが管理している古いリソースが古い WebSphere Application Server インストールにある場合は、以下のタスクを実行します。
  1. 関連したファイルを新規インストールにコピーします。
  2. 必要なセットアップを実行して、外部アプリケーションを有効な作動状態に戻します。

    このリソースを新規 WebSphere Application Server ディレクトリーに再インストールすることが最善の方法です。いずれを選択し実行した場合でも、最終ステップでは、アプリケーションの新規ロケーションへの参照をリセットします。

汎用サーバーが管理している古いリソースが、古い WebSphere Application Server インストール済み環境にインストールされていない場合は、その他に必要なことはありません。

EAR ファイルのマイグレーションに必要な Java ヒープ・サイズ

wsadmin ツールを使用して、WebSphere Application Server バージョン 7.0 以降の EAR ファイルをすべてバージョン 9.0 にマイグレーションする場合、WASPostUpgrade ツールは Java の最大ヒープ・サイズのデフォルト値 64 MB を使用して、EAR ファイルをインストールします。

Java ヒープ・サイズの大きさが不十分なために、バージョン 7.0 以降の EAR ファイルのインストールがマイグレーション中に失敗すると、次のようなメッセージが表示されます。
java.lang.OutOfMemoryError JVMXE006:OutOfMemoryError 

Java の最大ヒープ・サイズを増やし、例に従ってアプリケーションをインストールしてください。

WebSphere Application Server バージョン 9.0 へのアプリケーションのインストールの例

以下のことを前提とします。
インストール・ルート
C:¥WebSphere¥AppServer
EAR_file_name
EAR ファイルの名前
app_name
アプリケーションの名前
server_name
EAR ファイルをインストールするサーバーの名前
node_name
サーバーを構成するノードの名前
コマンドは、 わかりやすくするために複数の行に分けて表示しています。
wsadmin -conntype NONE
        -c "$AdminApp install 
               C:¥¥WebSphere¥¥AppServer¥¥installableApps¥¥
                  EAR_file_name
        {-nodeployejb 
         -appname app_name
         -server server_name
         -node node_name}"

WebSphere Application Server Network Deployment バージョン 9.0 へのアプリケーションのインストールの例

以下のことを前提とします。
インストール・ルート
C:¥WebSphere¥ Manager
EAR_file_name
EAR ファイルの名前
app_name
アプリケーションの名前
cluster_name
EAR ファイルをインストールしなければならないクラスターの名前
コマンドは、 わかりやすくするために複数の行に分けて表示しています。
wsadmin -conntype NONE
        -c "$AdminApp install 
            C:¥¥WebSphere¥¥ Manager¥¥installableApps¥¥
                   EAR_file_name> 
        {-nodeployejb 
         -appname app_name 
         -cluster cluster_name}"
バージョン 7.0 以降のノードのバージョン 9.0 ノードへのマイグレーション

セルに所属する WebSphere Application Server バージョン 7.0 以降のノードを、セルからノードを除去せずにマイグレーションできます。

最初にデプロイメント・マネージャーをマイグレーションしてから、 セル内の他の基本ノードをマイグレーションします。

重要: WebSphere Application Server Network Deploymentバージョン 7.0 以降からバージョン 9.0 にマイグレーションする場合は、同じセル名を使用してください。別のセル名を使用すると、統合ノードが WebSphere Application Server Network Deployment バージョン 9.0 セルに正常にマイグレーションされません。

セル内にある WebSphere Application Server の基本ノードをバージョン 9.0 にマイグレーションすると、 ノード・エージェントもバージョン 9.0 にマイグレーションされます。 セル内で、バージョン 9.0 ノードが存在し、同時にバージョン 7.0 以降のレベルの別のノードが存在してもかまいません。

ポリシー・ファイル
WebSphere Application Server バージョン 9.0 では、バージョン 9.0 のポリシー・ファイルに設定をマージすることにより、バージョン 7.0 以降にインストールされたすべてのポリシー・ファイルがマイグレーションされます。これには、以下のような特徴があります。
  • バージョン 9.0 のポリシー・ファイルにあるコメントは保持されます。バージョン 7.0 以降のポリシー・ファイルにあるコメントは、バージョン 9.0 ファイルには組み込まれません。
  • マイグレーションでは、許可または認可はマージされません。 厳密には、追加タイプのマイグレーションです。 許可または認可がバージョン 9.0 のファイルにない場合は、マイグレーションにより引き渡されます。
  • セキュリティーは重要なコンポーネントです。このため、マイグレーションにより、コメント「MIGR0372I: マイグレーション済みの権限は次のとおりです。」の直後の元の .policy ファイルの最後に追加が行われます。 これによって、マイグレーションによって行われたポリシー・ファイルの変更を、管理者が確認しやすくなります。
プロパティー・ディレクトリー

マイグレーションによって、旧バージョンのディレクトリーから WebSphere Application Server バージョン 9.0 構成に、ファイルがコピーされます。

プロパティー・ファイル

WebSphere Application Server バージョン 9.0 では、バージョン 9.0 プロパティー・ファイルに設定をマージすることにより、バージョン 7.0 以降でインストールされたすべてのプロパティー・ファイルがマイグレーションされます。

J2C リソースによって参照されるリソース・アダプター・アーカイブ (RAR)

J2C リソースによって参照される RAR が古い WebSphere Application Server インストールにある場合、これらの RAR はマイグレーションされます。この場合、RAR は、新しい WebSphere Application Server インストールの対応するロケーションにコピーされます。関係リソース・アダプター RAR はマイグレーションされません。

クラスター・レベルのリソースのマイグレーション:
WebSphere Application Server バージョン 6.0 では、クラスター・レベルのリソースの概念が導入されました。これらのリソースは、クラスター・ディレクトリーの下の resourcexxx.xml ファイルに構成されます。 以下に例を示します。
<resources.j2c:J2CResourceAdapter xmi:id="J2CResourceAdapter_1112808424172" 
  name="ims" archivePath="${WAS_INSTALL_ROOT}¥installedConnectors¥x2.rar">
  ...
</resources.j2c:J2CResourceAdapter>

クラスター・レベルのリソースがある場合、 このリソースは、各クラスター・メンバー (ノード) 上の同じ場所に置く必要があります。 したがって、前述の例を使用すると、各クラスター・メンバーは、${WAS_INSTALL_ROOT}¥installedConnectors¥x2.rar の場所に RAR ファイルをインストールする必要があります。${WAS_INSTALL_ROOT} は、正確な場所を得るために各クラスター・メンバーで解決されます。

デプロイメント・マネージャーのマイグレーションでは、 ツールによって、resourcexxx.xml ファイルなど、デプロイメント・ マネージャー上のクラスター・ファイルがマイグレーションされます。

統合ノードのマイグレーションでは、ツールによって各 J2C アダプターが処理されます。

バージョン 7.0 からバージョン 9.0 へのマイグレーションでの RAR ファイル。

バージョン 7.0 からバージョン 9.0 へのマイグレーションによって、RAR ファイルなどのファイルが、WAS_INSTALL_ROOT から WAS_INSTALL_ROOT に、USER_INSTALL_ROOT から USER_INSTALL_ROOT に、それぞれコピーされます。

例えば、バージョン 7.0 の WAS_INSTALL_ROOT に RAR ファイルがある時には、マイグレーション・ツールによって WAS_INSTALL_ROOT から USER_INSTALL_ROOT に、ファイルが自動的にコピーされることはありません。これにより、クラスター・レベルの J2C リソースの保全性が保たれます。

しかし、バージョン 7.0 の RAR ファイルへのパス (例えば archivePath="C:/WAS/installedConnectors/x2.rar") をハードコーディングした場合、バージョン 9.0 のマイグレーション・ツールでは、この内容を反映するように archivePath 属性を変更することはできません。その変更を行うことで、マイグレーションされていない他のクラスター・メンバーのすべてが壊れてしまうためです。
サンプル

旧バージョンからのサンプルのマイグレーションはありません。 WebSphere Application Server バージョン 9.0 の同等のサンプルをインストールできます。

セキュリティー

WebSphere Application Server バージョン 9.0 でセキュリティーを使用可能にすると、デフォルトで Java 2 セキュリティーが有効になります。Java 2 セキュリティーでは、セキュリティー許可を明示的に付与する必要があります。

バージョン 9.0 でさまざまなレベルの Java 2 セキュリティーを定義する場合に、使用できる技法がいくつかあります。1 つは、was.policy ファイルをアプリケーションの一部として作成し、 すべてのセキュリティー許可を使用可能にすることです。 マイグレーション・ツールは、マイグレーション中に wsadmin コマンドを 呼び出して、バージョン 9.0properties ディレクトリーにある 既存の was.policy ファイルを、エンタープライズ・アプリケーションに追加します。

WebSphere Application Server バージョン 9.0 にマイグレーションする際に、スクリプトの互換性をサポートするマイグレーションを行うかどうかの選択により、結果も以下の 2 つのいずれかになります。
  • スクリプトの互換性をサポートするマイグレーションを行うよう選択すると、セキュリティー構成は変更されずに、バージョン 9.0 に引き継がれます。

    これはデフォルトです。

  • スクリプトの互換性をサポートするマイグレーションをしないよう選択すると、セキュリティー構成は、WebSphere Application Server バージョン 9.0 のデフォルト構成に変換されます。バージョン 7.0 以降のデフォルトのセキュリティー構成は、前のバージョンとほぼ同じように機能しますが、変更されている点もあります。

    例えば、既存の鍵ファイルとトラスト・ファイルは、SSLConfig レパートリーから移動され、 新しい鍵ストアおよびトラストストア・オブジェクトが作成されます。

バージョン 9.0 へのセキュリティー構成のマイグレーションについて詳しくは、資料の『マイグレーション、共存、および相互運用 - セキュリティーに関する考慮事項』の項目を参照してください。

Stdin、stdout、stderr、passivation、および作業ディレクトリー

通常、これらのディレクトリーは、 前のバージョンのインストール・ディレクトリーにあります。 デフォルトでは、stdinstdout、および stderr は、WebSphere Application Server バージョン 9.0 のインストール・ルートの logs ディレクトリーにあります。

マイグレーション・ツールは、既存の passivation ディレクトリーと作業デ ィレクトリーのマイグレーションを試行します。 うまくいかなかった場合には、該当するバージョン 9.0 のデフォルトが使用されます。

トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): 共存シナリオでは、バージョン間で共通のディレクトリーを使用すると、問題が生じる可能性があります。gotcha
Web モジュール

WebSphere Application Server Version 7.0 で実装される Java Platform, Enterprise Edition (Java EE) の仕様レベルでは、コンテンツ・タイプを設定する場合、Web コンテナーの振る舞いの変更が必要でした。デフォルト・サーブレットの書き込み機能によってコンテンツ・タイプが設定されない場合、Web コンテナーのデフォルトがその値にデフォルト設定されなくなるばかりでなく、Web コンテナーは呼び出しを「ヌル」として戻します。この場合、一部のブラウザーで、Web コンテナーのタグが正しく表示されないことがあります。この問題を回避するため、エンタープライズ・アプリケーションをマイグレーションする際に、autoResponseEncoding IBM® 拡張が Web モジュールに対して「true」に設定されます。


トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-dist&topic=cmig_configmap
ファイル名:cmig_configmap.html