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

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

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

この項目では、プロファイル構成マイグレーションについて説明します。アプリケーションを最新バージョンにマイグレーションするには、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 インストールにある場合は、以下のタスクを実行します。
  1. 関連したファイルを新規インストールにコピーします。
  2. 必要なセットアップを実行して、外部アプリケーションを有効な作動状態に戻します。

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

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

バージョン 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 セキュリティーでは、セキュリティー許可を明示的に付与する必要があります。

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

    これはデフォルトです。

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

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

    System Secure Sockets Layer (SSSL) タイプの SSL 構成レパートリーは、デーモンに属するものを除き、すべて Java Secure Socket Extension (JSSE) タイプに変換されます。

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

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

WebSphere Application Server for z/OS® では、stdinstdout、および stderr の出力は、デフォルトで SYSOUT に送信されます。これらの出力が前のバージョンの構成ディレクトリーにリダイレクトされた場合は、それをバージョン 9.0 の JCL で変更する必要があります。

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

WebSphere Application Server for z/OS のユーザー ID のホーム・ディレクトリーが、前のバージョンの構成ディレクトリー内にある場合は、マイグレーションする前に、それらを更新して別の場所に置く必要があります。

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

マイグレーション・ツールは、すべてのポートをマイグレーションします。 サーバーを同時に実行する前に、ポートの競合を解決する必要があります。

注: マイグレーション対象の構成でポートが既に定義されている場合、マイグレーション・ツールはバージョン 9.0 の構成にあるポート競合を修正し、変更をログに記録して検証に備えます。

各ポートの仮想ホスト別名項目を、手動で追加する必要があります。 詳しくは、資料の『仮想ホストの構成』の項目を参照してください。

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-zos&topic=cmig_configmap
ファイル名:cmig_configmap.html