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

この項目では、プロファイル構成マイグレーションについて説明します。アプリケーションを最新バージョンにマイグレーションするには、WebSphere® Application Server Migration Toolkit を使用します。詳しくは、WASdev の Migration Toolkit を参照してください。
sptcfgマイグレーションでは、WebSphere Application Server の旧リリースから新リリースに構成がコピーされます。
多くのマイグレーション・シナリオが考えられます。 マイグレーション・ツールによって、マイグレーション元のバージョン内に存在するオブジェクトと属性を、バージョン 9.0 環境内の対応するオブジェクトと属性にマップします。
マイグレーション・ツールによって、古いリリースの値をバージョン 9.0 環境に取り込みます。
マイグレーション・ツールは、該当するコマンド行パラメーターを、サーバー・プロセス定義の Java™ 仮想マシン (JVM) 設定に変換します。 ほとんどの設定は、直接マップされます。 一部の設定は、マイグレーションされません。これは、それらのロールが WebSphere Application Server バージョン 9.0 の構成内に存在しないか、バージョン 8.0 では意味が異なるか、または有効範囲が異なるためです。
プロセス定義設定の変更方法については、 『プロセス定義設定』を参照してください。JVM 設定の変更方法については、『Java 仮想マシン設定』を参照してください。
- バージョン 7.0 以降では、汎用サーバーには GENERIC_SERVER と呼ばれる独自のタイプを持ちます。マイグレーションによりこの変換が実行されますが、 汎用サーバーが参照する外部リソースは正確にマイグレーションされません。 汎用サーバー設定のマイグレーションが完了後、追加のタスクを実行する必要があります。 汎用サーバーが管理している古いリソースが古い WebSphere Application Server インストールにある場合は、以下のタスクを実行します。
汎用サーバーが管理している古いリソースが、古い WebSphere Application Server インストール済み環境にインストールされていない場合は、その他に必要なことはありません。
セルに所属する 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 以降にインストールされたすべてのポリシー・ファイルがマイグレーションされます。これには、以下のような特徴があります。
マイグレーションによって、旧バージョンのディレクトリーから WebSphere Application Server バージョン 9.0 構成に、ファイルがコピーされます。
WebSphere Application Server バージョン 9.0 では、バージョン 9.0 プロパティー・ファイルに設定をマージすることにより、バージョン 7.0 以降でインストールされたすべてのプロパティー・ファイルがマイグレーションされます。
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 セキュリティーでは、セキュリティー許可を明示的に付与する必要があります。
WebSphere Application Server バージョン 9.0 にマイグレーションする際に、スクリプトの互換性をサポートするマイグレーションを行うかどうかの選択により、結果も以下の 2 つのいずれかになります。バージョン 9.0 へのセキュリティー構成のマイグレーションについて詳しくは、資料の『マイグレーション、共存、および相互運用 - セキュリティーに関する考慮事項』の項目を参照してください。
WebSphere Application Server for z/OS® では、stdin、stdout、および stderr の出力は、デフォルトで SYSOUT に送信されます。これらの出力が前のバージョンの構成ディレクトリーにリダイレクトされた場合は、それをバージョン 9.0 の JCL で変更する必要があります。
マイグレーション・ツールは、既存の passivation ディレクトリーと作業デ ィレクトリーのマイグレーションを試行します。 うまくいかなかった場合には、該当するバージョン 9.0 のデフォルトが使用されます。
WebSphere Application Server for z/OS のユーザー ID のホーム・ディレクトリーが、前のバージョンの構成ディレクトリー内にある場合は、マイグレーションする前に、それらを更新して別の場所に置く必要があります。
トラブルの回避 (Avoid trouble): 共存シナリオでは、バージョン間で共通のディレクトリーを使用すると、問題が生じる可能性があります。gotcha
マイグレーション・ツールは、すべてのポートをマイグレーションします。 サーバーを同時に実行する前に、ポートの競合を解決する必要があります。
注: マイグレーション対象の構成でポートが既に定義されている場合、マイグレーション・ツールはバージョン 9.0 の構成にあるポート競合を修正し、変更をログに記録して検証に備えます。各ポートの仮想ホスト別名項目を、手動で追加する必要があります。 詳しくは、資料の『仮想ホストの構成』の項目を参照してください。
WebSphere Application Server Version 7.0 で実装される Java Platform, Enterprise Edition (Java EE) の仕様レベルでは、コンテンツ・タイプを設定する場合、Web コンテナーの振る舞いの変更が必要でした。デフォルト・サーブレットの書き込み機能によってコンテンツ・タイプが設定されない場合、Web コンテナーのデフォルトがその値にデフォルト設定されなくなるばかりでなく、Web コンテナーは呼び出しを「ヌル」として戻します。この場合、一部のブラウザーで、Web コンテナーのタグが正しく表示されないことがあります。この問題を回避するため、エンタープライズ・アプリケーションをマイグレーションする際に、autoResponseEncoding IBM® 拡張が Web モジュールに対して「true」に設定されます。