マイグレーションに関する考慮事項
WebSphere® Application Server バージョン 9.0 へのマイグレーション・プロセスを開始する前に、注意すべき考慮事項があります。

この項目では、プロファイル構成マイグレーションについて説明します。アプリケーションを最新バージョンにマイグレーションするには、WebSphere Application Server Migration Toolkit を使用します。詳しくは、WASdev の Migration Toolkit を参照してください。
sptcfgAIX®、HP-UX、 IBM® i、Linux、Solaris、および Windows オペレーティング・システムでの考慮事項
アプリケーション・サーバーをマイグレーションする前に、以下の情報について考慮してください。- マイグレーションを実行する前に、WebSphere Application Server
バージョン 9.0 では推奨されない項目を確認します。
詳しくは、 『非推奨のフィーチャー、安定化されたフィーチャー、置換されたフィーチャー、および除去されたフィーチャー』を参照してください。
- WebSphere Application Server バージョン 7.0 以降には HA マネージャー (HAM) とコア・グループ機能が含まれています。
バージョン 7.0 以降からバージョン 9.0 へのマイグレーションに影響する可能性がある、コア・グループ構成およびトポロジーに関する考慮事項については、『コア・グループのマイグレーションに関する考慮事項』を参照してください。
注: ほとんどの場合、コア・グループ内の推奨サーバー数は 50 を超えないようにする必要があります。マイグレーション・ツールが推奨上限数を超えるサーバーを追加すると、警告メッセージが表示されます。 - 構成マイグレーション・ツールは、アプリケーションの変換を行うことも、アプリケーションを新しい Java SDK レベルと互換にすることもしません。新しい Java SDK にマイグレーションする前に、
WebSphere Application Server Migration Toolkit を使用して、アプリケーションに変更を加える必要があるかどうかを評価し、必要な変更を行った後でアプリケーションをテストしてください。WASdev の Migration
Toolkit を参照してください。
詳しくは、『API および仕様のマイグレーション』を参照してください。
- マイグレーション・ツールは、古いバージョンの構成のバックアップ・コピーが入ったマイグレーション・バックアップ・ディレクトリーを作成します。
このディレクトリーの容量は、古いプロファイルの構成ディレクトリーおよびアプリケーションのサイズに、トレース・ファイルのサイズを加えたものです。さらに、
システムには、マイグレーション後にはソース・プロファイルと同じサイズになる、ターゲット・プロファイル用のスペースも必要です。
バックアップ・ディレクトリー用にシステムで必要となるストレージの量は、環境および使用するマイグレーション・ツールによって異なります。
- ロケーション: WASPreUpgrade コマンドおよび WASPostUpgrade コマンドのパラメーターとして指定されるバックアップ・ディレクトリー。
- 量: これらのコマンドを使用するときのストレージ所要量を見積もるには、以下の量を加算します。
- 以前の構成におけるすべてのプロファイルの、以下に挙げる項目のサイズ
- profile_root/installableApps ディレクトリー
- profile_root/installedApps ディレクトリー
- profile_root/config ディレクトリー
- profile_root/properties ディレクトリー
- libraries.xml 構成ファイルで参照される共有ライブラリー
- resources.xml 構成ファイルで参照されるリソース・アダプター・アーカイブ (RAR) ファイル
- トレースが有効にされる場合、トレース・ファイル用のスペースを十分に確保してください (構成のサイズと複雑さによって異なります)。
- 以前の構成におけるすべてのプロファイルの、以下に挙げる項目のサイズ
- 分離されたデータ・リポジトリーを使用し (特に、SIB および Apache Derby データベースのトランザクション・ログなどの非共有データ・リポジトリー)、以前のリリースからマイグレーションする場合は、WASPreUpgrade コマンドの実行時に既存のデータベースおよびトランザクション・ログは保存されます。WASPreUpgrade コマンドの実行後に行ったデータベースのすべての変更は、マイグレーション済み環境には反映されません。
- 主幹業務の情報がこのローカル・データ・リポジトリーに保存されている場合は、マイグレーションを行う前に、このリポジトリーと対話操作するすべてのサーバーを正常にシャットダウンする必要があります。このサーバーは、マイグレーションが正常に完了するかロールバックされるまで、オフラインのままにしておきます。
- 予期しないロールバックやフィックスの適用などで、マイグレーションを複数回行う場合は、WASPreUpgrade コマンドを再実行して、分離されたデータ・リポジトリーに対する変更がマイグレーション済み環境に反映されるようにします。
- SIB が 1 つまたはすべてのメッセージング・エンジンについてファイル・ストア・オプションを使用する場合には、アクティブ・サーバーがあるノードをマイグレーションしないでください。
アクティブなアプリケーション・サーバーでファイル・ストアをコピーしようとすると、WASPreUpgrade コマンドがファイル・ロック済み例外で失敗します。
WASPreUpgrade コマンドは、ロックされたファイルをコピーします。これによってデータの整合性が損なわれる可能性があります。
WASPreUpgrade コマンドを実行して、SIB ファイル・ストアを所有するノードおよびアプリケーション・サーバーがまだ実行中に、バージョン 6.1 からマイグレーションする場合、次のようなエラーが表示されることがあります。
アプリケーション・サーバーとノードをシャットダウンすると、WASPreUpgrade コマンドが完了します。C:¥was80A¥bin>WASPreUpgrade c:¥bkupWAS6.1.0.17June30B C:¥was61B MIGR0385I: プロファイル AppSrv01 の保存を開始します。(Starting to save profile AppSrv01.) MIGR0215W: マイグレーション関数で、ファイルをコピーし、宛先ファイルを開くことができません。(The migration function cannot copy the file and open the destination file) c:¥bkupWAS6.1.0.17June30B¥migrated¥C_¥FSJune19¥Log. MIGR0272E: マイグレーション機能がコマンドを完了できません。
- Apache Derby データベースをマイグレーションする前に、Apache Derby データベースを使用しているアプリケーションをホスティングするアプリケーション・サーバーが閉じていることを確認します。 閉じていない場合、Apache Derby のマイグレーションは失敗します。
- セキュリティー・ドメインのマイグレーションに関する、次の規則に留意してください。
- セル・レベル有効範囲のセキュリティー・ドメインを持つデプロイメント・マネージャーをマイグレーションする場合、マイグレーション・ツールで以下のアクションが行われます。
- マイグレーションで、新規構成に PassThroughToGlobalSecurity と呼ばれるドメインがまだ存在しない場合は、作成されます。
- マイグレーションで、旧の構成に存在するすべてのクラスターについてのクラスター・マッピングが新規構成に追加されます。
- マイグレーション前にバージョン 9.0 デプロイメント・マネージャー構成にのみ存在したクラスターは、PassThroughToGlobalSecurity に対するそのマッピングは変更されません。
- マイグレーション前に存在したバージョン 9.0 クラスターのマッピングは、マイグレーション後もそのまま存在します。
- マイグレーション前にバージョン 9.0 クラスターのマッピングが存在しない場合、このマッピングはマイグレーション後も存在しません。
- マイグレーション前に、前の構成とバージョン 9.0 構成の両方にクラスターが存在した場合、新規構成内のクラスターは PassThroughToGlobalSecurity ドメインに追加され、前のリリースのクラスターのように動作します。
- マイグレーション前にバージョン 9.0 デプロイメント・マネージャー構成にのみ存在したクラスターは、PassThroughToGlobalSecurity に対するそのマッピングは変更されません。
- マイグレーションにより、マイグレーションされたバージョン 6.1.x 構成に存在したすべてのバスのバス・マッピングが追加されます。
バス・マッピングは、クラスター・マッピングの場合と同じ規則に従って更新されます。
- 管理サーバー (デプロイメント・マネージャー) は、PassThroughToGlobalSecurity ドメインに追加されません。
- セル・レベル有効範囲のセキュリティー・ドメインを持つ統合ノードをマイグレーションする場合、マイグレーション・ツールで以下のアクションが行われます。
- マイグレーションで、新規構成に PassThroughToGlobalSecurity と呼ばれるドメインがまだ存在しない場合は、作成されます。
- マイグレーションにより、旧ノードの構成のすべての非クラスター化サーバーのサーバー・レベル・マッピングが PassThroughToGlobalSecurity ドメインに追加されます。
- クラスターに属している、マイグレーションされるノード上のサーバーは、PassThroughToGlobalSecurity ドメイン内のエントリーを受け取りません。これは、デプロイメント・マネージャーのマイグレーション中に、クラスター・マッピングを使用してアドレス指定されるからです。
このマッピングを除去していた場合、マイグレーションではこの動作を維持します。
- 管理サーバー (ノード・エージェント) は、PassThroughToGlobalSecurity ドメインに追加されません。
- クラスターに属している、マイグレーションされるノード上のサーバーは、PassThroughToGlobalSecurity ドメイン内のエントリーを受け取りません。これは、デプロイメント・マネージャーのマイグレーション中に、クラスター・マッピングを使用してアドレス指定されるからです。
詳しくは、『複数のセキュリティー・ドメイン』の『混合バージョン環境でのセキュリティー・ドメイン』のセクションを参照してください。
- セル・レベル有効範囲のセキュリティー・ドメインを持つデプロイメント・マネージャーをマイグレーションする場合、マイグレーション・ツールで以下のアクションが行われます。
- 資格認定のプロンプトを無効にするプロセスが変更されました。
バージョン 9.0 で資格認定のプロンプトを無効にするには、バージョン 6.1 から バージョン 9.0 にマイグレーションする前に、資格認定のプロンプトを無効にするように ipc.client.props を構成します。
- マイグレーション中にアプリケーション・メタデータのうちの一部がデフォルトにリセットされることが原因となって、アプリケーションが予想と異なる働きをする可能性があります。
「バイナリーからメタデータを使用する」を true に設定してアプリケーションを古い環境にインストールし、そのアプリケーションのインストール時またはその後の更新時にアプリケーションのメタデータ (例えば、JNDI リソース参照またはデータベース項目) に変更を加えた場合、マイグレーションを行ったときにその変更内容が失われることがあります。
「バイナリーからメタデータを使用する」が true に設定されている場合、管理コードはバイナリー EAR ファイル内のメタデータのみを更新します。 このオプションは混合セルではサポートされないため、マイグレーションの一環として自動的に false になります。その場合、構成ディレクトリー内の拡張されたメタデータが、バイナリー EAR ファイルの値に優先します。これにより、元の EAR ファイルのインストール済み環境の値が、ユーザーの行った更新に優先するようになります。
この問題を解決するには、以下のいずれかのアクションを実行します。- マイグレーションの前に、古い環境内のアプリケーションを更新して「バイナリーからメタデータを使用する」を false に設定します。この新規設定でアプリケーションが正常に機能することを確認してから、マイグレーションを実行します。
- マイグレーションの後で、必要に応じてアプリケーションの更新とメタデータの修正を行い、アプリケーションが適切に機能するようにします。
- マイグレーション・ツールを使用して WebSphere Application Server
バージョン 9.0 へのマイグレーションを行った後で、マイグレーション・ツールでは自動的に行われないアクションを実行しなければならない場合があります。
- WebSphere Application Server
バージョン 7.0 以降で使用した可能性のある Lightweight Third Party Authentication (LTPA) セキュリティー設定をすべて検査し、バージョン 9.0 のセキュリティーが適切に設定されていることを確認します。
詳しくは、『Lightweight Third Party Authentication』を参照してください。
- マイグレーション・ツールでマイグレーションされなかった JavaServer Pages (JSP) オブジェクトの詳細については、logs ディレクトリーにある WASPostUpgrade.log ファイルを調べてください。
JSP オブジェクトが構成されているレベルをバージョン 9.0 がサポートしていない場合、マイグレーション・ツールは出力中にそのオブジェクトを認識して、ログに記録します。
- Java™ 仮想マシン (JVM) の設定を調べて、始動パフォーマンスを向上させるために少なくとも 50 のヒープ・サイズを使用していることを確認します。
詳しくは、『Java 仮想マシン設定』を参照してください。
使用していたヒープ・サイズがこれより小さい場合は、デフォルトのヒープ・サイズ (50) を使用できます。
- Apache Derby データベースの自動マイグレーションの結果を検証して、ツールによって自動的にマイグレーションされなかった Apache Derby データベースを、すべて手動でマイグレーションします。
詳しくは、『Apache Derby データベースのマイグレーション』を参照してください。
- WebSphere Application Server
バージョン 7.0 以降で使用した可能性のある Lightweight Third Party Authentication (LTPA) セキュリティー設定をすべて検査し、バージョン 9.0 のセキュリティーが適切に設定されていることを確認します。


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-dist&topic=cmig_pre
ファイル名:cmig_pre.html