![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
コマンド行ツールを使用した新しいホスト・マシンへのセルのマイグレーション
始める前に

この項目では、プロファイル構成マイグレーションについて説明します。アプリケーションを最新バージョンにマイグレーションするには、WebSphere® Application Server Migration Toolkit を使用します。詳しくは、WASdev の Migration Toolkit を参照してください。
sptcfgマイグレーション計画情報を再度確認します。『ナレッジ・コレクション: WebSphere Application Server のマイグレーション計画』を参照してください。
この情報は、セルを異なるマシンにマイグレーションする方法を説明します。 同一マシン上でセルをマイグレーションする方法については、『コマンド行ツールを使用したセルのマイグレーション』を参照してください。
このタスクについて
このタスクでは、前のバージョンの WebSphere Application Server から、別のマシンにホストされた WebSphere Application Server バージョン 9.0 にセル構成内の各プロファイルをマイグレーションする方法について説明します。セル構成は、1 つ以上のノードを含むデプロイメント・マネージャー、Web サーバー、およびアプリケーション・クライアントで構成されます。すべてのポートは、新しい構成にマイグレーションされます。ソースとターゲットのホスト・マシンは、同じオペレーティング・システムを実行する必要はありません。
WebSphere Application Server バージョン 9.0 がソース・ホスト・マシンにインストールされていない場合、ソース・マシンのオペレーティング・システムに一致するターゲット・ホスト・マシンにリモート・マイグレーション .jar ファイルを生成する必要があります。リモート・マイグレーション .jar ファイルは、ソース・ホストに バージョン 9.0 WASPreUpgrade ツールを提供します。このツールを使用して、プロファイルのマイグレーション・バックアップ・ディレクトリーを作成します。
- オプション 1: ソース・マシンにターゲット製品バージョンをインストールします。
- オプション 2: リモート・マイグレーション .jar ファイルを作成します (このファイルは、実際には、WASPreUpgrade コマンドと、ターゲットのインストール済み環境から収集された、Java など、実行のサポートに必要なファイルです)。
複数のソース・マシンのすべてでオペレーティング・システム・アーキテクチャーが同じであるが、ターゲット・マシンとは異なる場合、1 つのみのソース・マシンには、ターゲットのリリースがインストールされる必要があります。その 1 つのソース・マシンから、リモート・マイグレーション jar を作成して、他のソース・マシンで使用できます。
この手順では、前の構成が稼働中であること、および、すべてのプロファイルを別のホスト・マシンにマイグレーションしようとしていることを想定しています。


手順
- デプロイメント・マネージャーおよびすべての古いノードをバックアップします。 マイグレーション時の失敗に備え、現行のデプロイメント・マネージャーおよびノードの構成をファイルに保存して、後でリカバリー目的で使用できるようにします。
- deployment_manager_profile_root/bin ディレクトリーに変更します。
- 適切なパラメーターを指定して backupConfig コマンドを実行し、現行のプロファイル構成をファイルに保存します。 以下に例を示します。
previous_version_app_server_root\v70dmgr01\bin\ backupConfig.bat ¥mybackup_old_host¥v70dmgr01backupBeforeV90migration.zip -username myuser -password mypass -nostop
ここで、mybackup_old_host は、構成の復元ポイントが保管されているロケーションです。previous_version_app_server_root/v70dmgr01/bin/backupConfig.sh /mybackup_old_host/v70dmgr01backupBeforeV90migration.zip -username myuser -password mypass -nostop
- この構成に含まれるノードごとに、node_profile_root/bin ディレクトリーに移動します。
- 適切なパラメーターを指定して backupConfig コマンドを実行し、現行のプロファイル構成をファイルに保存します。 以下に例を示します。
previous_version_app_server_root\v70node01\bin\backupConfig.bat ¥mybackup_old_host¥v70node01backupBeforeV90migration.zip -username myuser -password mypass -nostop
previous_version_app_server_root/v70node01 /bin/backupConfig.sh /mybackup_old_host/v70node01rbackupBeforeV90migration.zip -username myuser -password mypass -nostop
- WebSphere Application Server Network Deployment
バージョン 9.0 を、各ターゲット・ホストの新規ディレクトリーにインストールします。
詳しくは、インストール資料を参照してください。
- リモート・マイグレーション .jar ファイルを作成します。 この .jar ファイルには、WebSphere Application Server
バージョン 9.0 がインストールされていないシステムで WASPreUpgrade コマンドを実行するために必要なファイルが含まれています。
トラブルの回避 (Avoid trouble): ソースがインストールされているのと同じオペレーティング・システムおよびアーキテクチャー上でリモート・マイグレーション .jar ファイルを作成する必要があります。生成されるアーカイブにはオペレーティング・システム固有のコードが含まれているため、アーカイブは当該アーキテクチャーでのみ実行されます。gotcha
- ソース・プロファイルのオペレーティング・システムおよびアーキテクチャーを判別します。 ソース・プロファイルのオペレーティング・システムおよびアーキテクチャーがターゲット・プロファイルのオペレーティング・システムおよびアーキテクチャーと異なる場合は、リモート・マイグレーション jar を作成する前に、ソース・プロファイルと一致するシステムで WebSphere Application Server バージョン 9.0 をインストールする必要があります。リモート・マイグレーション jar を生成すると、それはオペレーティング・システムおよびアーキテクチャーと一致するどのシステムでも機能します。
- リモート・マイグレーション .jar を作成します。
- コマンド・プロンプトで、cd $WAS_HOME/bin/migration/bin と入力します。
- .jar ファイルを作成するため、createRemoteMigrJar.bat(sh) -targetDir <dir for the remote migration jar> を実行します。これによって、 ファイル WAS_V90_OS.arch_RemoteMigrSupport.jar が作成されます。 例えば、WAS_V90_windows.amd64_RemoteMigrSupport.jar です。
- WasPreUpgrade コマンドを行う、リモート・システムを準備します。
- ソース・プロファイルのあるシステムに .jar ファイルを送信します。
- ファイルを一時ロケーションに抽出します。
- 一時ロケーションの bin ディレクトリーに移動します。
ソース・プロファイルに対して WASPreUpgrade コマンドを実行する準備ができています。ただし、後のステップでこのコマンドを発行するように指示されるまで、このコマンドは発行しないでください。
- ターゲットのデプロイメント・マネージャー・プロファイルを作成します。 ターゲットのデプロイメント・マネージャー・プロファイルは、マイグレーション・ターゲットになる新しいデプロイメント・マネージャー・プロファイルです。
トラブルの回避 (Avoid trouble): バージョン 9.0 におけるセル名とノード名は、 以前の構成におけるセル名およびノード名と一致している必要があります。新しいセル名およびノード名でセルとノードを作成すると、マイグレーションは失敗します。gotcha
デプロイメント・マネージャー・プロファイルを作成するには、適切なパラメーターを指定して manageprofiles コマンドを実行します。
以下に例を示します。version_9_install_root\bin\manageprofiles.bat -create -profileName v70toV90dmgr01 -templatePath ¥opt¥WebSphereV90¥profileTemplates¥ management -serverType DEPLOYMENT_MANAGER -nodeName currentDmgrNodeName -cellName currentCellName -hostName mydmgrhost.company.com
version_9_install_root/bin/manageprofiles.sh -create -profileName v70toV90dmgr01 -templatePath /opt/WebSphereV90/profileTemplates/ management -serverType DEPLOYMENT_MANAGER -nodeName currentDmgrNodeName -cellName currentCellName -hostName mydmgrhost.company.com
- 現行のデプロイメント・マネージャー構成を、マイグレーション・バックアップ・ディレクトリーに保存します。 現行のデプロイメント・マネージャー構成を、マイグレーション・バックアップ・ディレクトリーに保存するには、WASPreUpgrade コマンドを実行します。WASPreUpgrade コマンドによって、古い構成は変更されません。
- -machineChange true パラメーターを指定して WASPreUpgrade コマンドを実行して、現在のデプロイメント・マネージャー構成をマイグレーション・バックアップ・ディレクトリーに保存します。 例:
<path to remote migration jar>\migration\bin\WASPreUpgrade.bat \mybackup_old_host\v70toV90dmgr01 \opt\WebSphereV70 -oldProfile 70dmgr01 -machineChange true
ここで、mybackup_old_host は、 新しいホストへのマイグレーションの準備のためにプロファイル構成ファイルをコピーする先のディレクトリーです。<path to remote migration jar>/migration/bin/WASPreUpgrade.sh /mybackup_old_host/v70toV90dmgr01 /opt/WebSphereV70 -oldProfile 70dmgr01 -machineChange true
バージョン 8.0 からバージョン 9.0 にマイグレーションする際に、プロファイルがデプロイメント・マネージャーである場合、WASPreUpgrade の実行時にバージョン 8.0 プロファイルは停止されます。 コマンド行で -keepDmgrEnabled true を指定するか、マイグレーション・ウィザードでそれに対応するオプションを指定した場合にのみ、WASPreUpgrade が完了する前にデプロイメント・マネージャーが開始されます。
トラブルの回避 (Avoid trouble): -machineChange true を指定する場合は、マイグレーション後にバージョン 8.0 デプロイメント・マネージャーのジョブ管理機能によって管理されるすべてのリソース (他のデプロイメント・マネージャーまたはアプリケーション・サーバーなど) のジョブ・マネージャー URL を更新する必要があります。gotcha
- コンソール出力および WASPreUpgrade ログで警告またはエラーを確認します。 WASPreUpgrade コマンドが完了したら、コンソール出力で「失敗してエラーが発生しました」または「警告を伴って完了しました」というメッセージがないかを確認します。
次に、以下のログ・ファイルで警告またはエラーがないかを確認します。
- mybackup_old_host/v70toV90dmgr01/logs/WASPreMigrationSummary.log
- mybackup_old_host/v70toV90dmgr01/logs/WASPreUpgrade.timestamp.log
- mybackup_old_host/v70toV90dmgr01/logs/WASPreUpgrade.trace
エラーがあった場合は、エラーを修正し、WASPreUpgrade コマンドを再度実行します。警告が バージョン 9.0 での他のマイグレーションやランタイムのアクティビティーに影響するかどうかを確認します。
コマンドが正常に完了した場合は、エラーや警告がないかログを確認する必要はありません。
- -machineChange true パラメーターを指定して WASPreUpgrade コマンドを実行して、現在のデプロイメント・マネージャー構成をマイグレーション・バックアップ・ディレクトリーに保存します。 例:
- WASPreUpgrade コマンドによって作成されたバックアップ・ディレクトリーをアーカイブします。
トラブルの回避 (Avoid trouble): Windows アーカイブ・ツールは、WebSphere Application Server マイグレーションと互換性がないため、使用しないでください。gotcha
- 選択したアーカイブ・ツールを使用して、バックアップ・ディレクトリーの圧縮ファイルを作成します。 以下に例を示します。
cd /mybackup_old_host /opt/WebSphereV70/java/bin/jar -cf v70toV90dmgr01.jar v70toV90dmgr01/
- アーカイブされたファイルをターゲット・マシンに移動します。
- ターゲット・マシン上にディレクトリーを作成して、その新しいディレクトリーにアーカイブされたファイルを解凍します。 例:
ここで、mybackup_new_host は、ファイルのマイグレーション先のディレクトリーです。mkdir /mybackup_new_host cd /mybackup_new_host /opt/WebSphereV90/java/bin/jar -xf v70toV90dmgr01.jar
- 選択したアーカイブ・ツールを使用して、バックアップ・ディレクトリーの圧縮ファイルを作成します。 以下に例を示します。
- 前のデプロイメント・マネージャー構成をリストアします。
WASPostUpgrade コマンドを新規デプロイメント・マネージャー・プロファイルの bin ディレクトリーから実行して、マイグレーション・バックアップ・ディレクトリーに保存した以前のデプロイメント・マネージャー構成をリストアします。例に示すオプションを使用すると、すべてのポートが持ち越されて、すべてのアプリケーションがインストールされます。
- WASPostUpgrade コマンドを実行して、保存したデプロイメント・マネージャー構成を、新しい バージョン 9.0 デプロイメント・マネージャー・プロファイルにリストアします。 例:
version_9_install_root\bin\WASPostUpgrade.bat \ mybackup_new_host\v70toV90dmgr01 -profileName v70toV90dmgr01 -oldProfile 70dmgr01 -resolvePortConflicts incrementCurrent -backupConfig TRUE -keepDmgrEnabled TRUE -username myuser -password mypass
ここで、mybackup_new_host は、ソース・プロファイル構成ファイルのマイグレーション元のディレクトリーです。version_9_install_root/bin/WASPostUpgrade.sh / mybackup_new_host/v70toV90dmgr01 -profileName v70toV90dmgr01 -oldProfile 70dmgr01 -resolvePortConflicts incrementCurrent -backupConfig TRUE -keepDmgrEnabled TRUE -username myuser -password mypass
古いプロファイルをマイグレーション後も使用し続けたい場合、 -clone TRUE パラメーターを指定します。デプロイメント・マネージャーの複製マイグレーションを指定する場合は、 デプロイメント・マネージャーの統合ノードもすべて複製する必要があります。
- コンソール出力および WASPostUpgrade ログで警告またはエラーを確認します。 WASPostUpgrade コマンドが完了したら、コンソール出力で「失敗してエラーが発生しました」または「警告を伴って完了しました」というメッセージがないかを確認します。
次に、以下のログ・ファイルで警告またはエラーがないかを確認します。
- mybackup_new_host/v70toV90dmgr01/logs/WASPostMigrationSummary.log
- mybackup_new_host/v70toV90dmgr01/logs/WASPostUpgrade.target profile name.timestamp.log
- mybackup_new_host/v70toV90dmgr01/logs/WASPostUpgrade.target profile name.trace
エラーがあった場合は、エラーを修正し、WASPostUpgrade コマンドを再度実行します。警告が バージョン 9.0 での他のマイグレーションやランタイムのアクティビティーに影響するかどうかを確認します。
構成は正しくマイグレーションされたが、インストールされなかったアプリケーションがある場合、WASMigrationAppInstaller コマンドを実行して、マイグレーションされなかったアプリケーションのみをインストールできます。詳しくは、WASMigrationAppInstaller コマンドを参照してください。
コマンドが正常に完了した場合は、エラーや警告がないかログを確認する必要はありません。
トラブルの回避 (Avoid trouble): WASPostUpgrade コマンドが正常終了した後も、新しいデプロイメント・マネージャーを始動しないでください。 新しいデプロイメント・マネージャーを始動する前に、あと少し手順を実行する必要があります。gotcha
- WASPostUpgrade コマンドを実行して、保存したデプロイメント・マネージャー構成を、新しい バージョン 9.0 デプロイメント・マネージャー・プロファイルにリストアします。 例:
- バージョン 9.0 デプロイメント・マネージャーに対して backupConfig コマンドを実行することによって、バージョン 9.0 のマイグレーションされたデプロイメント・マネージャー構成をファイルに保存します。
トラブルの回避 (Avoid trouble): ノード・マイグレーションが失敗した場合、セル構成を失敗前のポイントに復元することができます。 修正アクションを適用し、ノード・マイグレーションを再試行できます。gotcha
- deployment_manager_profile_root/bin ディレクトリーに変更します。
- 適切なパラメーターを指定して backupConfig コマンドを実行し、
バージョン 9.0 のプロファイル構成をファイルに保存します。 以下に例を示します。
version_9_profile_root\profiles\v70toV90dmgr01\ bin¥backupConfig.bat ¥mybackup_new_host¥v70toV90dmgr01backupMigratedDmgrOnly.zip -username myuser -password mypass
ここで、mybackup_new_host は、構成の復元ポイントが保管されているロケーションです。version_9_profile_root/profiles/v70toV90dmgr01/bin/backupConfig.sh / mybackup_new_host/v70toV90dmgr01backupMigratedDmgrOnly.zip -username myuser -password mypass
- 以前のホスト上のデプロイメント・マネージャーを停止して使用不可にします。
- 以前のホスト上のデプロイメント・マネージャーを停止します。
- 以前のホスト上のデプロイメント・マネージャーを使用不可にします。 このデプロイメント・マネージャーを使用不可にするには、以下に示すように、関連の serverindex.xml ファイルの名前を変更する必要があります。
- 以前の名前
- $PROFILE_ROOT/config/cells/cell_name/nodes/deployment_manager_node_name/serverindex.xml
- 新規の名前
- $PROFILE_ROOT/config/cells/cell_name/nodes/deployment_manager_node_name/serverindex.xml_disabled
- 新しいホスト上でバージョン 9.0 のデプロイメント・マネージャーを開始します。
- 新しい バージョン 9.0 deployment_manager_profile_root/bin ディレクトリーに移動します。
- startManager コマンドを実行します。
- デプロイメント・マネージャーの稼働中に、警告またはエラーがないか SystemOut.log ファイルを確認します。 注: このトピックでは、 1 つ以上のアプリケーション・サーバー・ログ・ファイルを参照します。推奨される代替案として、分散システムや IBM i システムの SystemOut.log、SystemErr.log、trace.log、activity.log ファイルではなく、High Performance Extensible Logging (HPEL) ログおよびトレース・インフラストラクチャーを使用するようにサーバーを構成できます。また HPEL は、ネイティブ z/OS® ロギング機能と連携させて使用することができます。HPEL を使用する場合、LogViewer コマンド・ライン・ツールを サーバー・プロファイルの bin ディレクトリーから使用して、すべてのログ・ファイルにアクセスし、 情報をトレースできます。HPEL の使用について詳しくは、HPEL を使用してのアプリケーションの トラブルシューティングに関する情報を参照してください。バージョン 9.0 のデプロイメント・マネージャーの始動時に、 ノード・マイグレーションまたはランタイム・アクティビティーに影響を与える警告がないかを確認します。
- バージョン 9.0 のデプロイメント・マネージャーが正常に開始することを確認します。
- 以前のノードを新規のバージョン 9.0 のデプロイメント・マネージャーに手動で同期化します。
新規ホスト上で、 バージョン 9.0 のデプロイメント・マネージャーが稼働していることを確認します。以前のノードが含まれるマシンにログインして、syncNode コマンドを実行する必要があります。
- ノード・エージェントを停止します。
- デプロイメント・マネージャーのホストおよびポート番号を取得して、 node_agent_profile_root/properties/wsadmin.properties ファイルを更新します。 com.ibm.ws.scripting.host の値を新規ホストに変更します。 com.ibm.ws.scripting.port の値を新規ポートに変更します。
- bin ディレクトリーから syncNode コマンドを実行します。 以下に例を示します。
node_agent_install_root\bin\syncNode.bat myV90DmgrHost.mycompany.com 8879 -username myuser -password mypass
node_agent_install_root/bin/syncNode.sh myV90DmgrHost.mycompany.com 8879 -username myuser -password mypass
- 同期が正常に完了したら、ノード・エージェントを始動します。
- Web サーバーのプラグインをマイグレーションします。
- バージョン 9.0 のデプロイメント・マネージャーが稼働中であることを確認します。
- セルで使用されている Web サーバー・プラグインのバージョンをアップグレードします。
- ご使用の Web サーバーのタイプとバージョンに適用可能なサポート情報を参照します。
- アプリケーション・クライアント・インストール済み環境をマイグレーションします。
ソースの WebSphere Application Client がバージョン 7.0 の場合は、WASPreUpgrade コマンドおよび WASPostUpgrade コマンドを実行して、既存のセキュリティー設定をマイグレーションする必要もあります。
- マイグレーションする必要のあるクライアント・ホストをすべて特定します。
- WebSphere バージョン 9.0 Application Client をインストールします。
- バージョン 9.0
WASPreUpgrade コマンドを実行して、アプリケーション・クライアントのセキュリティー設定をマイグレーション・バックアップ・ディレクトリーに保存します。 例:
/opt/AppClientV90/bin/WASPreUpgrade.sh /mybackup_client/v70clientToV90 /opt/AppClientV70
- バージョン 9.0
WASPostUpgrade コマンドを実行して、アプリケーション・クライアントのセキュリティー設定を、新しいバージョン 9.0 のクライアントにリストアします。 例:
/opt/AppClientV90/bin/WASPostUpgrade.sh /mybackup_client/v70clientToV90
- ノードをマイグレーションします。 重要: 以下のステップは、クロス・マシン・マイグレーションにのみ適用されます。ノードのクロス・マシン・マイグレーションを実行しない場合は、コマンド行ツールを使用したセルのマイグレーションのノードのマイグレーションに関する情報を参照してください。バージョン 9.0 のデプロイメント・マネージャーが稼働中であることを確認します。バージョン 9.0 にマイグレーションしようと予定しているノードごとに、以下のステップを実行します。
トラブルの回避 (Avoid trouble): マイグレーションが正常に行われるためには、 バージョン 9.0 以降へマイグレーションする各ノードに、同じソース・ノード名を使用する必要がありますが、一時セル名は異なるものを使用する必要があります。gotcha
- WebSphere Application Server バージョン 9.0 を各ターゲット・ホストにインストールします。 詳しくは、アプリケーション・サービス提供環境のインストールに関する資料を参照してください。
- ターゲットのノード・プロファイルを作成します。適切なパラメーターを指定して manageprofiles コマンドを実行し、新しい管理対象プロファイルを作成します。 以下に例を示します。
version_9_install_root\bin\manageprofiles.bat -create -profileName node1 -templatePath ¥opt¥ WebSphereV90¥profileTemplates¥managed -nodeName currentNode1Name -cellName currentCellName -hostName mynode1host.company.com
version_9_install_root/bin/manageprofiles.sh -create -profileName node1 -templatePath /opt/WebSphereV90/profileTemplates/managed -nodeName currentNode1Name -cellName currentCellName -hostName mynode1host.company.com
- デプロイメント・マネージャーをマイグレーションするために作成したリモート・マイグレーション .jar ファイルを使用して、現在のノード・マシンで WASPreUpgrade コマンドを使用できるようにします。 注: このステップを実行する必要があるのは、ソース・ノードとデプロイメント・マネージャーが同じマシン上にない場合のみであり、このステップを実行できるのは、マシン・アーキテクチャーが同じである場合のみです。詳しくは、このシナリオのステップ 3 (『リモート・マイグレーション .jar ファイルを作成します』) を参照してください。
- -machineChange true パラメーターを指定して WASPreUpgrade コマンドを実行して、
現行のノード構成をマイグレーション・バックアップ・ディレクトリーに保存します。バックアップ・ファイルのための新しいディレクトリーを選択します。 以下に例を示します。
<path to remote migration jar>\migration\bin\WASPreUpgrade.bat \mybackup_old_host\v70toV90node1 \opt\WebSphereV70 -oldProfile 70node1 -machineChange true
<path to remote migration jar>/migration/bin/WASPreUpgrade.sh /mybackup_old_host/v70toV90node1 /opt/WebSphereV70 -oldProfile 70node1 -machineChange true
- WASPreUpgrade のコンソール出力にエラー・メッセージと警告メッセージがないか確認します。 「失敗してエラーが発生しました」または「警告を伴って完了しました」などのメッセージが表示される可能性があります。
また、次のログ・ファイルでもエラー・メッセージあるいは警告メッセージがないかを確認してください。
- myback_old_host/v70toV90node1/logs/WASPreMigrationSummary.log
- myback_old_host/v70toV90node1/logs/WASPreUpgrade.timestamp.log
- myback_old_host/v70toV90node1/logs/WASPreUpgrade.trace
WASPreUpgrade コマンドが正常に実行された場合は、ログ・ファイルでエラー・メッセージあるいは警告メッセージを確認する必要はありません。
- 選択したアーカイブ・ツールを使用して、WASPreUpgrade コマンドによって作成されたバックアップ・ディレクトリーの圧縮ファイルを作成します。 以下に例を示します。
cd /mybackup_old_host /opt/WebSphereV70/java/bin/jar -cf v70toV90node1.jar v70toV90node1/
- アーカイブされたファイルをターゲット・マシンに移動します。
- ターゲット・マシン上にディレクトリーを作成して、その新しいディレクトリーにアーカイブされたファイルを解凍します。 例:
ここで、mybackup_new_host は、プロファイル構成ファイルのマイグレーション元のディレクトリーです。mkdir /mybackup_new_host cd /mybackup_new_host /opt/WebSphereV90/java/bin/jar -xf v70toV90dmgr01.jar
- 以前のノード上のアプリケーション・サーバーを停止してから、以前のノードのノード・エージェントを停止します。
- 以前のホスト上のノードを停止して使用不可にします。 以前のホスト上のノードは使用しないようにしてください。
ノードを使用不可にするには、以下に示すように、関連の serverindex.xml ファイルの名前を変更する必要があります。
- 以前の名前
- $PROFILE_ROOT/config/cells/cell_name/nodes/node_name/serverindex.xml
- 新規の名前
- $PROFILE_ROOT/config/cells/cell_name/nodes/node_name/serverindex.xml_disabled
- WASPostUpgrade コマンドを実行して、保存したノード構成を、新しい バージョン 9.0 管理対象プロファイルにリストアします。 以下に例を示します。
version_9_install_root\bin\WASPostUpgrade.bat \ mybackup_new_host\v70toV90node1 -profileName v70toV90node1 -oldProfile 70node1 -resolvePortConflicts incrementCurrent -backupConfig TRUE -includeApps TRUE -username myuser -password mypass
version_9_install_root/bin/WASPostUpgrade.sh / mybackup_new_host/v70toV90node1 -profileName v70toV90node1 -oldProfile 70node1 -resolvePortConflicts incrementCurrent -backupConfig TRUE -includeApps TRUE -username myuser -password mypass
デプロイメント・マネージャーを複製した場合は、統合ノードもすべて複製する必要があります。 -clone TRUE パラメーターを指定し、新しいデプロイメント・マネージャーのホスト名と、 SOAP ポートまたは RMI ポートを指定してください。デプロイメント・マネージャーが複製されたのではない場合は、統合ノードを複製しないでください。
version_9_install_root\bin\WASPostUpgrade.bat \ mybackup_new_host\v70toV90node1 -profileName v70toV90node1 -oldProfile 70node1 -resolvePortConflicts incrementCurrent -backupConfig TRUE -includeApps TRUE -username myuser -password mypass -clone TRUE -newDmgrHostName myV90DmgrHost.mycompany.com -newDmgrSoapPort 8879
version_9_install_root/bin/WASPostUpgrade.sh / mybackup_new_host/v70toV90node1 -profileName v70toV90node1 -oldProfile 70node1 -resolvePortConflicts incrementCurrent -backupConfig TRUE -includeApps TRUE -username myuser -password mypass -clone TRUE -newDmgrHostName myV90DmgrHost.mycompany.com -newDmgrSoapPort 8879
- WASPostUpgrade コンソール出力に以下のメッセージがないかを確認します。 「失敗してエラーが発生しました」または「警告を伴って完了しました」などのメッセージが表示される可能性があります。
また、次のログ・ファイルでもエラー・メッセージあるいは警告メッセージがないかを確認してください。
- mybackup_new_host/v70toV90node1/logs/WASPostMigrationSummary.log
- mybackup_new_host/v70toV90node1/logs/WASPostUpgrade.target_profile_name.timestamp.log
- mybackup_new_host/v70toV90node1/logs/WASPostUpgrade.target_profile_name.trace
注: WASPostUpgrade コマンドが失敗した場合、 バックアップ構成ファイルからバージョン 9.0 のデプロイメント・マネージャーを復元する必要が生じる可能性があります。WASPostUpgrade コマンドの処理によって syncNode コマンドが実行された場合、 デプロイメント・マネージャーはノードがマイグレーションされたことを認識しています。デプロイメント・マネージャーがノードのマイグレーション前の状態にリストアされない限り、ノードを再びマイグレーションすることはできません。構成は正しくマイグレーションされたが、インストールされなかったアプリケーションがある場合、WASMigrationAppInstaller コマンドを実行して、マイグレーションされなかったアプリケーションのみをインストールできます。詳しくは、WASMigrationAppInstaller コマンドを参照してください。
- バージョン 9.0 のデプロイメント・マネージャーの SystemOut.log ファイルで
エラー・メッセージあるいは警告メッセージがないか確認します。 注: このトピックでは、 1 つ以上のアプリケーション・サーバー・ログ・ファイルを参照します。推奨される代替案として、分散システムや IBM i システムの SystemOut.log、SystemErr.log、trace.log、activity.log ファイルではなく、High Performance Extensible Logging (HPEL) ログおよびトレース・インフラストラクチャーを使用するようにサーバーを構成できます。また HPEL は、ネイティブ z/OS ロギング機能と連携させて使用することができます。HPEL を使用する場合、LogViewer コマンド・ライン・ツールを サーバー・プロファイルの bin ディレクトリーから使用して、すべてのログ・ファイルにアクセスし、 情報をトレースできます。HPEL の使用について詳しくは、HPEL を使用してのアプリケーションの トラブルシューティングに関する情報を参照してください。
- マイグレーションされた バージョン 9.0 ノード・エージェントを始動します。
- エラー・メッセージまたは警告メッセージがないか バージョン 9.0 デプロイメント・マネージャーおよびノードの SystemOut.log を確認します。
- オプション: 自動同期化処理が使用可能になっていない場合は、セルを同期化します。
- マイグレーションされたバージョン 9.0 ノード上の該当のアプリケーション・サーバーを始動します。
- backupConfig コマンドを実行し、バージョン 9.0 プロファイル構成をファイルに保存します。 以下に例を示します。
version_9_profile_root\v70toV90node1\bin\backupConfig.bat ¥mybackup_new_host¥v70toV90node1.zip -username myuser -password mypass -nostop
特定のノードで backupConfig コマンドを実行するたびに、新しいバックアップ・ファイル名を使用してください。version_9_profile_root/v70toV90node1/bin/backupConfig.sh /mybackup_new_host/v70toV90node1.zip -username myuser -password mypass -nostop
- backupConfig コマンドを使用して、デプロイメント・マネージャー構成を保存します。 バージョン 9.0 の
デプロイメント・マネージャー・ホストで、deployment_manager_profile_root/bin ディレクトリーに移動します。
backupConfig コマンドを実行し、バージョン 9.0 プロファイル構成をファイルに保存します。 例:
version_9_profile_root\v70toV90dmgr01\bin\backupConfig.bat ¥mybackup_new_host¥v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip -username myuser -password mypass
version_9_profile_root/v70toV90dmgr01/bin/backupConfig.sh /mybackup_new_host/v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip -username myuser -password mypass
注: マイグレーションするノードごとに、バージョン 9.0 のデプロイメント・マネージャー構成を新しいバックアップ・ファイルにバックアップします。 - 他のノードについても、ここまでのステップを繰り返します。
タスクの結果
マイグレーション・ツールを使用して、以前のバージョンの WebSphere Application Server のセル構成を、WebSphere Application Server バージョン 9.0 を実行している新規ホスト・マシンにマイグレーションしました。


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