[AIX Solaris HP-UX Linux Windows]

コマンド行ツールを使用した新しいホスト・マシンへのセルのマイグレーション

始める前に

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

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

sptcfg

マイグレーション計画情報を再度確認します。『ナレッジ・コレクション: WebSphere Application Server のマイグレーション計画』を参照してください。

ヒント: マイグレーション・コマンドに個々のパラメーターを指定するのではなく、-properties file_name.properties パラメーターを指定することでプロパティー・ファイルを入力できます。詳しくは、プロパティーによるマイグレーションの定義を参照してください。

この情報は、セルを異なるマシンにマイグレーションする方法を説明します。 同一マシン上でセルをマイグレーションする方法については、『コマンド行ツールを使用したセルのマイグレーション』を参照してください。

このタスクについて

このタスクでは、前のバージョンの WebSphere Application Server から、別のマシンにホストされた WebSphere Application Server バージョン 9.0 にセル構成内の各プロファイルをマイグレーションする方法について説明します。セル構成は、1 つ以上のノードを含むデプロイメント・マネージャー、Web サーバー、およびアプリケーション・クライアントで構成されます。すべてのポートは、新しい構成にマイグレーションされます。ソースとターゲットのホスト・マシンは、同じオペレーティング・システムを実行する必要はありません。

WebSphere Application Server バージョン 9.0 がソース・ホスト・マシンにインストールされていない場合、ソース・マシンのオペレーティング・システムに一致するターゲット・ホスト・マシンにリモート・マイグレーション .jar ファイルを生成する必要があります。リモート・マイグレーション .jar ファイルは、ソース・ホストに バージョン 9.0 WASPreUpgrade ツールを提供します。このツールを使用して、プロファイルのマイグレーション・バックアップ・ディレクトリーを作成します。

WASPreUpgrade コマンドは、ターゲットの WebSphere Application Server リリースから実行する必要があります。ソース・マシンには、新しいバージョンの WASPreUpgrade コマンドはありません。以下のいずれかのアクションを行ってください。
  • オプション 1: ソース・マシンにターゲット製品バージョンをインストールします。
  • オプション 2: リモート・マイグレーション .jar ファイルを作成します (このファイルは、実際には、WASPreUpgrade コマンドと、ターゲットのインストール済み環境から収集された、Java など、実行のサポートに必要なファイルです)。
リモート・マイグレーション .jar ファイルをいったん作成すれば、それ以降はソース・マシン上でそれを実行できます。
注: フルインストールが不要であるため、このオプション 2 の方が簡単です。アーカイブの作成後は、多くのソース・マシンでそのアーカイブを使用できます。 ただし、リモート・マイグレーション・アーカイブはオペレーティング・システム・アーキテクチャー固有であるため、ターゲット・マシンとソース・マシンが異なるオペレーティング・システム・アーキテクチャーである場合はオプション 1 を使用する必要があります。

複数のソース・マシンのすべてでオペレーティング・システム・アーキテクチャーが同じであるが、ターゲット・マシンとは異なる場合、1 つのみのソース・マシンには、ターゲットのリリースがインストールされる必要があります。その 1 つのソース・マシンから、リモート・マイグレーション jar を作成して、他のソース・マシンで使用できます。

この手順では、前の構成が稼働中であること、および、すべてのプロファイルを別のホスト・マシンにマイグレーションしようとしていることを想定しています。

トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): オープン・ファイルの最大数の設定を必ず 10000 以上にしてください。 オープン・ファイルの数が少なすぎると、マイグレーションでさまざまな障害が発生する可能性があります。gotcha
移行ユーザーの方へ 移行ユーザーの方へ: WebSphere Virtual Enterprise および Intelligent Management では、以前は別々のマイグレーション・ツールが必要でしたが、標準マイグレーション手順の一環としてマイグレーションされるようになりました。trns
制約事項: IBM® i または z/OS からのリモート・マイグレーションはサポートされません。

手順

  1. デプロイメント・マネージャーおよびすべての古いノードをバックアップします。 マイグレーション時の失敗に備え、現行のデプロイメント・マネージャーおよびノードの構成をファイルに保存して、後でリカバリー目的で使用できるようにします。
    1. deployment_manager_profile_root/bin ディレクトリーに変更します。
    2. 適切なパラメーターを指定して backupConfig コマンドを実行し、現行のプロファイル構成をファイルに保存します。 以下に例を示します。
      [Windows]
      previous_version_app_server_root\v70dmgr01\bin\
      backupConfig.bat ¥mybackup_old_host¥v70dmgr01backupBeforeV90migration.zip
      -username myuser -password mypass -nostop
      [AIX][HP-UX][Linux][Solaris]
      previous_version_app_server_root/v70dmgr01/bin/backupConfig.sh 
      /mybackup_old_host/v70dmgr01backupBeforeV90migration.zip -username 
      myuser -password mypass -nostop
      ここで、mybackup_old_host は、構成の復元ポイントが保管されているロケーションです。
    3. この構成に含まれるノードごとに、node_profile_root/bin ディレクトリーに移動します。
    4. 適切なパラメーターを指定して backupConfig コマンドを実行し、現行のプロファイル構成をファイルに保存します。 以下に例を示します。
      [Windows]
      previous_version_app_server_root\v70node01\bin\backupConfig.bat 
      ¥mybackup_old_host¥v70node01backupBeforeV90migration.zip -username
       myuser -password mypass -nostop
      [AIX][HP-UX][Linux][Solaris]
      previous_version_app_server_root/v70node01
      /bin/backupConfig.sh /mybackup_old_host/v70node01rbackupBeforeV90migration.zip 
      -username myuser -password mypass -nostop
  2. WebSphere Application Server Network Deployment バージョン 9.0 を、各ターゲット・ホストの新規ディレクトリーにインストールします。

    詳しくは、インストール資料を参照してください。

  3. リモート・マイグレーション .jar ファイルを作成します。 この .jar ファイルには、WebSphere Application Server バージョン 9.0 がインストールされていないシステムで WASPreUpgrade コマンドを実行するために必要なファイルが含まれています。
    トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): ソースがインストールされているのと同じオペレーティング・システムおよびアーキテクチャー上でリモート・マイグレーション .jar ファイルを作成する必要があります。生成されるアーカイブにはオペレーティング・システム固有のコードが含まれているため、アーカイブは当該アーキテクチャーでのみ実行されます。gotcha
    1. ソース・プロファイルのオペレーティング・システムおよびアーキテクチャーを判別します。 ソース・プロファイルのオペレーティング・システムおよびアーキテクチャーがターゲット・プロファイルのオペレーティング・システムおよびアーキテクチャーと異なる場合は、リモート・マイグレーション jar を作成する前に、ソース・プロファイルと一致するシステムで WebSphere Application Server バージョン 9.0 をインストールする必要があります。リモート・マイグレーション jar を生成すると、それはオペレーティング・システムおよびアーキテクチャーと一致するどのシステムでも機能します。
    2. リモート・マイグレーション .jar を作成します。
      1. コマンド・プロンプトで、cd $WAS_HOME/bin/migration/bin と入力します。
      2. .jar ファイルを作成するため、createRemoteMigrJar.bat(sh) -targetDir <dir for the remote migration jar> を実行します。これによって、 ファイル WAS_V90_OS.arch_RemoteMigrSupport.jar が作成されます。 例えば、WAS_V90_windows.amd64_RemoteMigrSupport.jar です。
    3. WasPreUpgrade コマンドを行う、リモート・システムを準備します。
      1. ソース・プロファイルのあるシステムに .jar ファイルを送信します。
      2. ファイルを一時ロケーションに抽出します。
      3. 一時ロケーションの bin ディレクトリーに移動します。

      ソース・プロファイルに対して WASPreUpgrade コマンドを実行する準備ができています。ただし、後のステップでこのコマンドを発行するように指示されるまで、このコマンドは発行しないでください。

  4. ターゲットのデプロイメント・マネージャー・プロファイルを作成します。 ターゲットのデプロイメント・マネージャー・プロファイルは、マイグレーション・ターゲットになる新しいデプロイメント・マネージャー・プロファイルです。
    トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): バージョン 9.0 におけるセル名とノード名は、 以前の構成におけるセル名およびノード名と一致している必要があります。新しいセル名およびノード名でセルとノードを作成すると、マイグレーションは失敗します。gotcha

    デプロイメント・マネージャー・プロファイルを作成するには、適切なパラメーターを指定して manageprofiles コマンドを実行します。

    以下に例を示します。
    [Windows]
    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
    [AIX][HP-UX][Linux][Solaris]
    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
  5. 現行のデプロイメント・マネージャー構成を、マイグレーション・バックアップ・ディレクトリーに保存します。 現行のデプロイメント・マネージャー構成を、マイグレーション・バックアップ・ディレクトリーに保存するには、WASPreUpgrade コマンドを実行します。WASPreUpgrade コマンドによって、古い構成は変更されません。
    1. -machineChange true パラメーターを指定して WASPreUpgrade コマンドを実行して、現在のデプロイメント・マネージャー構成をマイグレーション・バックアップ・ディレクトリーに保存します。 例:
      [Windows]
      <path to remote migration jar>\migration\bin\WASPreUpgrade.bat \mybackup_old_host\v70toV90dmgr01 
      \opt\WebSphereV70 -oldProfile 70dmgr01 -machineChange true
      [AIX][HP-UX][Linux][Solaris]
      <path to remote migration jar>/migration/bin/WASPreUpgrade.sh /mybackup_old_host/v70toV90dmgr01 
      /opt/WebSphereV70 -oldProfile 70dmgr01 -machineChange true
      ここで、mybackup_old_host は、 新しいホストへのマイグレーションの準備のためにプロファイル構成ファイルをコピーする先のディレクトリーです。

      バージョン 8.0 からバージョン 9.0 にマイグレーションする際に、プロファイルがデプロイメント・マネージャーである場合、WASPreUpgrade の実行時にバージョン 8.0 プロファイルは停止されます。 コマンド行で -keepDmgrEnabled true を指定するか、マイグレーション・ウィザードでそれに対応するオプションを指定した場合にのみ、WASPreUpgrade が完了する前にデプロイメント・マネージャーが開始されます。

      トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): -machineChange true を指定する場合は、マイグレーション後にバージョン 8.0 デプロイメント・マネージャーのジョブ管理機能によって管理されるすべてのリソース (他のデプロイメント・マネージャーまたはアプリケーション・サーバーなど) のジョブ・マネージャー URL を更新する必要があります。gotcha
    2. コンソール出力および 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 での他のマイグレーションやランタイムのアクティビティーに影響するかどうかを確認します。

      コマンドが正常に完了した場合は、エラーや警告がないかログを確認する必要はありません。

  6. WASPreUpgrade コマンドによって作成されたバックアップ・ディレクトリーをアーカイブします。
    トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): Windows アーカイブ・ツールは、WebSphere Application Server マイグレーションと互換性がないため、使用しないでください。gotcha
    1. 選択したアーカイブ・ツールを使用して、バックアップ・ディレクトリーの圧縮ファイルを作成します。 以下に例を示します。
      cd /mybackup_old_host
      /opt/WebSphereV70/java/bin/jar -cf v70toV90dmgr01.jar v70toV90dmgr01/
    2. アーカイブされたファイルをターゲット・マシンに移動します。
    3. ターゲット・マシン上にディレクトリーを作成して、その新しいディレクトリーにアーカイブされたファイルを解凍します。 例:
      mkdir /mybackup_new_host
      cd /mybackup_new_host
      /opt/WebSphereV90/java/bin/jar -xf v70toV90dmgr01.jar
      ここで、mybackup_new_host は、ファイルのマイグレーション先のディレクトリーです。
  7. 前のデプロイメント・マネージャー構成をリストアします。

    WASPostUpgrade コマンドを新規デプロイメント・マネージャー・プロファイルの bin ディレクトリーから実行して、マイグレーション・バックアップ・ディレクトリーに保存した以前のデプロイメント・マネージャー構成をリストアします。例に示すオプションを使用すると、すべてのポートが持ち越されて、すべてのアプリケーションがインストールされます。

    1. WASPostUpgrade コマンドを実行して、保存したデプロイメント・マネージャー構成を、新しい バージョン 9.0 デプロイメント・マネージャー・プロファイルにリストアします。 例:
      [Windows]
      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
      [AIX][HP-UX][Linux][Solaris]
      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
      ここで、mybackup_new_host は、ソース・プロファイル構成ファイルのマイグレーション元のディレクトリーです。

      [AIX Solaris HP-UX Linux Windows]古いプロファイルをマイグレーション後も使用し続けたい場合、 -clone TRUE パラメーターを指定します。デプロイメント・マネージャーの複製マイグレーションを指定する場合は、 デプロイメント・マネージャーの統合ノードもすべて複製する必要があります。

    2. コンソール出力および 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) トラブルの回避 (Avoid trouble): WASPostUpgrade コマンドが正常終了した後も、新しいデプロイメント・マネージャーを始動しないでください。 新しいデプロイメント・マネージャーを始動する前に、あと少し手順を実行する必要があります。gotcha
  8. バージョン 9.0 デプロイメント・マネージャーに対して backupConfig コマンドを実行することによって、バージョン 9.0 のマイグレーションされたデプロイメント・マネージャー構成をファイルに保存します。
    トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): ノード・マイグレーションが失敗した場合、セル構成を失敗前のポイントに復元することができます。 修正アクションを適用し、ノード・マイグレーションを再試行できます。gotcha
    1. deployment_manager_profile_root/bin ディレクトリーに変更します。
    2. 適切なパラメーターを指定して backupConfig コマンドを実行し、 バージョン 9.0 のプロファイル構成をファイルに保存します。 以下に例を示します。
      [Windows]
      version_9_profile_root\profiles\v70toV90dmgr01\
      bin¥backupConfig.bat ¥mybackup_new_host¥v70toV90dmgr01backupMigratedDmgrOnly.zip
      -username myuser -password mypass
      [AIX][HP-UX][Linux][Solaris]
      version_9_profile_root/profiles/v70toV90dmgr01/bin/backupConfig.sh /
      mybackup_new_host/v70toV90dmgr01backupMigratedDmgrOnly.zip -username 
      myuser -password mypass
      ここで、mybackup_new_host は、構成の復元ポイントが保管されているロケーションです。
  9. 以前のホスト上のデプロイメント・マネージャーを停止して使用不可にします。
    1. 以前のホスト上のデプロイメント・マネージャーを停止します。
    2. 以前のホスト上のデプロイメント・マネージャーを使用不可にします。 このデプロイメント・マネージャーを使用不可にするには、以下に示すように、関連の 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
  10. 新しいホスト上でバージョン 9.0 のデプロイメント・マネージャーを開始します。
    1. 新しい バージョン 9.0 deployment_manager_profile_root/bin ディレクトリーに移動します。
    2. startManager コマンドを実行します。
    3. デプロイメント・マネージャーの稼働中に、警告またはエラーがないか SystemOut.log ファイルを確認します。
      注: このトピックでは、 1 つ以上のアプリケーション・サーバー・ログ・ファイルを参照します。推奨される代替案として、分散システムや IBM i システムの SystemOut.logSystemErr.logtrace.logactivity.log ファイルではなく、High Performance Extensible Logging (HPEL) ログおよびトレース・インフラストラクチャーを使用するようにサーバーを構成できます。また HPEL は、ネイティブ z/OS® ロギング機能と連携させて使用することができます。HPEL を使用する場合、LogViewer コマンド・ライン・ツールを サーバー・プロファイルの bin ディレクトリーから使用して、すべてのログ・ファイルにアクセスし、 情報をトレースできます。HPEL の使用について詳しくは、HPEL を使用してのアプリケーションの トラブルシューティングに関する情報を参照してください。
      バージョン 9.0 のデプロイメント・マネージャーの始動時に、 ノード・マイグレーションまたはランタイム・アクティビティーに影響を与える警告がないかを確認します。
    4. バージョン 9.0 のデプロイメント・マネージャーが正常に開始することを確認します。
  11. 以前のノードを新規のバージョン 9.0 のデプロイメント・マネージャーに手動で同期化します。

    新規ホスト上で、 バージョン 9.0 のデプロイメント・マネージャーが稼働していることを確認します。以前のノードが含まれるマシンにログインして、syncNode コマンドを実行する必要があります。

    1. ノード・エージェントを停止します。
    2. デプロイメント・マネージャーのホストおよびポート番号を取得して、 node_agent_profile_root/properties/wsadmin.properties ファイルを更新します。 com.ibm.ws.scripting.host の値を新規ホストに変更します。 com.ibm.ws.scripting.port の値を新規ポートに変更します。
    3. bin ディレクトリーから syncNode コマンドを実行します。 以下に例を示します。
      [Windows]
      node_agent_install_root\bin\syncNode.bat myV90DmgrHost.mycompany.com 8879 -username myuser -password mypass
      [AIX][HP-UX][Linux][Solaris]
      node_agent_install_root/bin/syncNode.sh myV90DmgrHost.mycompany.com 8879 -username myuser -password mypass
    4. 同期が正常に完了したら、ノード・エージェントを始動します。
  12. Web サーバーのプラグインをマイグレーションします。
    1. バージョン 9.0 のデプロイメント・マネージャーが稼働中であることを確認します。
    2. セルで使用されている Web サーバー・プラグインのバージョンをアップグレードします。
    3. ご使用の Web サーバーのタイプとバージョンに適用可能なサポート情報を参照します。
  13. アプリケーション・クライアント・インストール済み環境をマイグレーションします。

    ソースの WebSphere Application Client がバージョン 7.0 の場合は、WASPreUpgrade コマンドおよび WASPostUpgrade コマンドを実行して、既存のセキュリティー設定をマイグレーションする必要もあります。

    1. マイグレーションする必要のあるクライアント・ホストをすべて特定します。
    2. WebSphere バージョン 9.0 Application Client をインストールします。
    3. バージョン 9.0 WASPreUpgrade コマンドを実行して、アプリケーション・クライアントのセキュリティー設定をマイグレーション・バックアップ・ディレクトリーに保存します。 例:
      /opt/AppClientV90/bin/WASPreUpgrade.sh /mybackup_client/v70clientToV90 /opt/AppClientV70
    4. バージョン 9.0 WASPostUpgrade コマンドを実行して、アプリケーション・クライアントのセキュリティー設定を、新しいバージョン 9.0 のクライアントにリストアします。 例:
      /opt/AppClientV90/bin/WASPostUpgrade.sh /mybackup_client/v70clientToV90 
  14. ノードをマイグレーションします。
    重要: 以下のステップは、クロス・マシン・マイグレーションにのみ適用されます。ノードのクロス・マシン・マイグレーションを実行しない場合は、コマンド行ツールを使用したセルのマイグレーションのノードのマイグレーションに関する情報を参照してください。バージョン 9.0 のデプロイメント・マネージャーが稼働中であることを確認します。バージョン 9.0 にマイグレーションしようと予定しているノードごとに、以下のステップを実行します。
    トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): マイグレーションが正常に行われるためには、 バージョン 9.0 以降へマイグレーションする各ノードに、同じソース・ノード名を使用する必要がありますが、一時セル名は異なるものを使用する必要があります。gotcha
    1. WebSphere Application Server バージョン 9.0 を各ターゲット・ホストにインストールします。 詳しくは、アプリケーション・サービス提供環境のインストールに関する資料を参照してください。
    2. ターゲットのノード・プロファイルを作成します。適切なパラメーターを指定して manageprofiles コマンドを実行し、新しい管理対象プロファイルを作成します。 以下に例を示します。
      [Windows]
      version_9_install_root\bin\manageprofiles.bat 
      -create -profileName node1 -templatePath ¥opt¥
      WebSphereV90¥profileTemplates¥managed -nodeName currentNode1Name
      -cellName currentCellName -hostName mynode1host.company.com
      [AIX][HP-UX][Linux][Solaris]
      version_9_install_root/bin/manageprofiles.sh 
      -create -profileName node1 -templatePath 
      /opt/WebSphereV90/profileTemplates/managed -nodeName currentNode1Name 
      -cellName currentCellName -hostName mynode1host.company.com
    3. デプロイメント・マネージャーをマイグレーションするために作成したリモート・マイグレーション .jar ファイルを使用して、現在のノード・マシンで WASPreUpgrade コマンドを使用できるようにします。
      注: このステップを実行する必要があるのは、ソース・ノードとデプロイメント・マネージャーが同じマシン上にない場合のみであり、このステップを実行できるのは、マシン・アーキテクチャーが同じである場合のみです。
      詳しくは、このシナリオのステップ 3 (『リモート・マイグレーション .jar ファイルを作成します』) を参照してください。
    4. -machineChange true パラメーターを指定して WASPreUpgrade コマンドを実行して、 現行のノード構成をマイグレーション・バックアップ・ディレクトリーに保存します。バックアップ・ファイルのための新しいディレクトリーを選択します。 以下に例を示します。
      [Windows]
      <path to remote migration jar>\migration\bin\WASPreUpgrade.bat \mybackup_old_host\v70toV90node1 
      \opt\WebSphereV70 -oldProfile 70node1 -machineChange true
      [AIX][HP-UX][Linux][Solaris]
      <path to remote migration jar>/migration/bin/WASPreUpgrade.sh /mybackup_old_host/v70toV90node1 
      /opt/WebSphereV70 -oldProfile 70node1 -machineChange true
    5. WASPreUpgrade のコンソール出力にエラー・メッセージと警告メッセージがないか確認します。 「失敗してエラーが発生しました」または「警告を伴って完了しました」などのメッセージが表示される可能性があります。 また、次のログ・ファイルでもエラー・メッセージあるいは警告メッセージがないかを確認してください。
      • myback_old_host/v70toV90node1/logs/WASPreMigrationSummary.log
      • myback_old_host/v70toV90node1/logs/WASPreUpgrade.timestamp.log
      • myback_old_host/v70toV90node1/logs/WASPreUpgrade.trace

      WASPreUpgrade コマンドが正常に実行された場合は、ログ・ファイルでエラー・メッセージあるいは警告メッセージを確認する必要はありません。

    6. 選択したアーカイブ・ツールを使用して、WASPreUpgrade コマンドによって作成されたバックアップ・ディレクトリーの圧縮ファイルを作成します。 以下に例を示します。
      [AIX Solaris HP-UX Linux Windows]
      cd /mybackup_old_host
      /opt/WebSphereV70/java/bin/jar -cf v70toV90node1.jar v70toV90node1/
    7. アーカイブされたファイルをターゲット・マシンに移動します。
    8. ターゲット・マシン上にディレクトリーを作成して、その新しいディレクトリーにアーカイブされたファイルを解凍します。 例:
      mkdir /mybackup_new_host
      cd /mybackup_new_host
      /opt/WebSphereV90/java/bin/jar -xf v70toV90dmgr01.jar
      ここで、mybackup_new_host は、プロファイル構成ファイルのマイグレーション元のディレクトリーです。
    9. 以前のノード上のアプリケーション・サーバーを停止してから、以前のノードのノード・エージェントを停止します。
    10. 以前のホスト上のノードを停止して使用不可にします。 以前のホスト上のノードは使用しないようにしてください。 ノードを使用不可にするには、以下に示すように、関連の 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
    11. WASPostUpgrade コマンドを実行して、保存したノード構成を、新しい バージョン 9.0 管理対象プロファイルにリストアします。 以下に例を示します。
      [Windows]
      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
      [AIX][HP-UX][Linux][Solaris]
      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

      [AIX Solaris HP-UX Linux Windows]デプロイメント・マネージャーを複製した場合は、統合ノードもすべて複製する必要があります。 -clone TRUE パラメーターを指定し、新しいデプロイメント・マネージャーのホスト名と、 SOAP ポートまたは RMI ポートを指定してください。デプロイメント・マネージャーが複製されたのではない場合は、統合ノードを複製しないでください。

      [Windows]
      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
      [AIX][HP-UX][Linux][Solaris]
      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
    12. 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 コマンドを参照してください。

    13. バージョン 9.0 のデプロイメント・マネージャーの SystemOut.log ファイルで エラー・メッセージあるいは警告メッセージがないか確認します。
      注: このトピックでは、 1 つ以上のアプリケーション・サーバー・ログ・ファイルを参照します。推奨される代替案として、分散システムや IBM i システムの SystemOut.logSystemErr.logtrace.logactivity.log ファイルではなく、High Performance Extensible Logging (HPEL) ログおよびトレース・インフラストラクチャーを使用するようにサーバーを構成できます。また HPEL は、ネイティブ z/OS ロギング機能と連携させて使用することができます。HPEL を使用する場合、LogViewer コマンド・ライン・ツールを サーバー・プロファイルの bin ディレクトリーから使用して、すべてのログ・ファイルにアクセスし、 情報をトレースできます。HPEL の使用について詳しくは、HPEL を使用してのアプリケーションの トラブルシューティングに関する情報を参照してください。
    14. マイグレーションされた バージョン 9.0 ノード・エージェントを始動します。
    15. エラー・メッセージまたは警告メッセージがないか バージョン 9.0 デプロイメント・マネージャーおよびノードの SystemOut.log を確認します。
    16. オプション: 自動同期化処理が使用可能になっていない場合は、セルを同期化します。
    17. マイグレーションされたバージョン 9.0 ノード上の該当のアプリケーション・サーバーを始動します。
    18. backupConfig コマンドを実行し、バージョン 9.0 プロファイル構成をファイルに保存します。 以下に例を示します。
      [Windows]
      version_9_profile_root\v70toV90node1\bin\backupConfig.bat 
      ¥mybackup_new_host¥v70toV90node1.zip -username myuser
      -password mypass -nostop
      [AIX][HP-UX][Linux][Solaris]
      version_9_profile_root/v70toV90node1/bin/backupConfig.sh 
      /mybackup_new_host/v70toV90node1.zip -username myuser 
      -password mypass -nostop
      特定のノードで backupConfig コマンドを実行するたびに、新しいバックアップ・ファイル名を使用してください。
    19. backupConfig コマンドを使用して、デプロイメント・マネージャー構成を保存します。 バージョン 9.0 の デプロイメント・マネージャー・ホストで、deployment_manager_profile_root/bin ディレクトリーに移動します。 backupConfig コマンドを実行し、バージョン 9.0 プロファイル構成をファイルに保存します。 例:
      [Windows]
      version_9_profile_root\v70toV90dmgr01\bin\backupConfig.bat 
      ¥mybackup_new_host¥v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip
      -username myuser -password mypass
      [AIX][HP-UX][Linux][Solaris]
      version_9_profile_root/v70toV90dmgr01/bin/backupConfig.sh 
      /mybackup_new_host/v70toV90dmgr01backupMigratedDmgrPlusNodeX.zip 
      -username myuser -password mypass
      注: マイグレーションするノードごとに、バージョン 9.0 のデプロイメント・マネージャー構成を新しいバックアップ・ファイルにバックアップします。
    20. 他のノードについても、ここまでのステップを繰り返します。

タスクの結果

マイグレーション・ツールを使用して、以前のバージョンの WebSphere Application Server のセル構成を、WebSphere Application Server バージョン 9.0 を実行している新規ホスト・マシンにマイグレーションしました。


トピックのタイプを示すアイコン タスク・トピック



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