z/OS デプロイメント・マネージャーのマイグレーション

デプロイメント・マネージャーを WebSphere® Application Server for z/OS® バージョン 9.0 に マイグレーションするための JCL ジョブを生成したら、これらのジョブを実行して実際のマイグレーションを行うことができます。 カスタム・マイグレーション・ジョブの生成時には、ジョブの生成に使用された CNTL データ・セットの BBOMDINS メンバーでマイグレーション・ジョブを準備し実行するような、カスタマイズされた指示も作成しています。 デプロイメント・マネージャーを バージョン 9.0 にマイグレーションするプロセスを実行するために、これらのカスタマイズされた指示に従います。

始める前に

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

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

sptcfg
  • マイグレーション、共存、およびインターオペラビリティーの概要およびマイグレーションに関する考慮事項を参照してください。
  • ジョブ制御言語 (JCL) マイグレーション・ジョブを生成していない場合は、先へ進むことができません。
  • 必ずデプロイメント・マネージャー・ノードを最初にマイグレーションします。
  • ご使用のシステムに適用できる共存の要件を確認してください。
  • これらの指示で参照する BBOWMG3D ジョブは、WebSphere Administrator ユーザー ID によって実行依頼する必要があります。

    他のすべてのジョブは、ファイル・システムを制御できるユーザー ID によって実行依頼する必要があります。

  • バージョン 7.0 以降 から バージョン 9.0 へのマイグレーション中に高可用性を維持することに関するメモ

    デプロイメント・マネージャーをバージョン 7.0 以降 から バージョン 9.0 にマイグレーションすると、 デプロイメント・マネージャーの再始動時にすべてのアプリケーション・バイナリーが再デプロイされます。 このアクションにより、デプロイメント・マネージャーは、SYSPLEX 中のすべてのアプリケーションをリサイクルします。同期設定が無効になっていない場合、高可用性のために設定された SYSPLEX 内で障害が発生することがあります。

    マイグレーション中に高可用性を維持するには、デプロイメント・マネージャーを再始動する前に、SYSPLEX 内のすべてのノード・エージェントのすべての同期オプションをオフにします。
    1. 管理コンソールを開きます。
    2. 「システム管理」 > 「ノード・エージェント」と進みます。
    3. シスプレックス内の各ノード・エージェントについて、node_agent_server_name > 「ファイル同期化サービス」と進み、すべての同期処理を使用不可にします。
  • ヒント: マイグレーション後に構成を以前の状態にリストアできるようにする場合は、WebSphere Application Server バージョン 7.0 以降 デプロイメント・マネージャーをマイグレーションする前に、backupConfig コマンドまたは設定済みのバックアップ・ユーティリティーを使用して既存の構成をバックアップしてください。詳しくは、 backupConfig コマンド を参照してください。このバックアップ構成の正確な名前と位置を記録しておく必要があります。

ヘルプについては、マイグレーションのトラブルシューティングを参照してください。

このタスクについて

移行ユーザーの方へ 移行ユーザーの方へ: 以下の製品では、以前は別々のマイグレーション・ツールが必要でしたが、標準マイグレーション・プロシージャーの一部としてマイグレーションされるようになりました。
  • WebSphere Extended Deployment Compute Grid または Feature Pack for Modern Batch
  • WebSphere Virtual Enterprise または Intelligent Management
これらの変更点について詳しくは、マイグレーションの新機能を参照してください。trns

手順

  1. 新規 バージョン 9.0 構成ファイル・システムの作成とマウント。

    マイグレーションを実行するには、事前に バージョン 9.0 に、新規構成用の構成ファイル・システムが存在している必要があります。新規構成ファイル・システムの作成およびマウントは、BBOMDHFS または BBOMDZFS を実行して行うことができますが、 手動でマウントすることもできます。 いずれにしても、構成ファイル・システムを バージョン 9.0 構成用に作成およびマウントしてから、 先へ進む必要があります。この構成ファイル・システムはマイグレーションのターゲットで、バージョン 7.0 以降 構成ファイル・システムはソースです。

    BBOMDHFS または BBOMDZFS は、マウント・ポイント・ディレクトリーを作成し、 構成のファイル・システムを割り振り、マイグレーション・ジョブの生成時にマウント・ポイントに 指定した値でファイル・システムをマウントします。

    先に進む前に、構成ファイル・システム・データ・セットの割り振り、作成、およびマウントを手動または BBOMDHFS や BBOMDZFS を使用して行ったことを確認してください。マウント・ポイントは、WebSphere Admin ID に所有され、 755 以上の許可を持っていなければなりません。 新規構成ファイル・システム構造を BPXPARM に含めて、 次の IPL でマウントされるようにします。

  2. 生成済み JCL プロシージャーをコピーします。

    マイグレーション・ユーティリティー BBOMDCP は、 生成済み JCL プロシージャーをコピーして、 指定されたプロシージャー・ライブラリーに対してサーバーを開始します。 バージョン 9.0 の構成では、バージョン 7.0 以降 の構成で使用したものとは別の JCL プロシージャーを使用する必要があります。このユーティリティーは、 元の バージョン 7.0 以降 構成内の JCL 名を新規 JCL 名で置き換えて、 新規 バージョン 9.0 構成を更新します。

    注意: このユーティリティーは、 生成した JCL をプロシージャー・ライブラリーにコピーします。マイグレーション・ジョブの 生成時に バージョン 7.0 以降 構成で使用したのと同じ名前を指定した場合、 このユーティリティーは既存のプロシージャーをオーバーレイします。同じ名前を使用している場合、後でロールバックする必要があるときに、このユーティリティーを実行する前に既存の バージョン 7.0 以降 プロシージャーを必ずバックアップしてください。

    BBOMDCP をサブミットして、戻りコードの 0 を確認します。

  3. 新規プロシージャー名を指定する場合、コントローラーおよびデーモンの RACF® STARTED プロファイルを更新します。
    コントローラー・リージョンが使用する STARTED プロファイルは、 プロシージャー名および JOBNAME に基づいています。 適切な ID を開始済みタスクに割り当てるために、STARTED プロファイルを適用する必要があります。 例えば、バージョン 7.0 以降 デプロイメント・マネージャーのコントローラー JCL プロシージャー名が AZDCR であり、バージョン 9.0 用に AZ1DCR を指定した場合、次のようにその新規プロシージャー名の STARTED プロファイルを作成する必要があります。
                  new controller      same identity used in
                     JCL name         V7.0 or later configuration
                        |                    |
     RDEFINE STARTED AZ1DCR.* STDATA(USER(AZDCRU) GROUP(AZCFG) TRACE(YES))
    注:
    • 異なるユーザー ID を使用して始動しないでください。 ユーザー ID には、他の事項も関連しており、ユーザー ID を変更すると、 それらの事項も変更する必要があります。
    • オリジナル STARTED プロファイルが汎用の場合 (STARTED AZ*.*... など) には、 新規 STARTED プロファイルを作成する必要はありません。
    • サーバント・リージョン STARTED プロファイルは、プロシージャー名ではなく、JOBNAME に基づいています。 このため、サーバントでは、別のプロシージャー名を使用しても問題ありません。
    • デーモンおよびノード・エージェントはコントローラーです。このためこれらのコントローラーに別のプロシージャー名を使用すると、新規 STARTED プロファイルが暗黙指定されます。
  4. 以下のいずれかのアクションを実行します。
    1. BBOWMG3D ジョブをサブミットします。

      デプロイメント・マネージャーのマイグレーションでは、スタンドアロン・アプリケーション・サーバーおよび統合ノードのマイグレーションの場合とは異なり、ノードを「ピアの再始動およびリカバリー (PRR)」モードに入れたり出したりする必要はありません。したがって、デプロイメント・マネージャーのマイグレーションのサブミットでは、 ジョブが 2 つ少なくなり、 物理マイグレーションを実行する準備が整います。

      BBOWMG3D は、ユーザーがマイグレーション・ジョブの生成時に入力した情報に基づいて、 バージョン 7.0 以降 デプロイメント・マネージャーからバージョン 9.0 への 物理マイグレーションを実行するジョブです。 BBOWMG3D をサブミットします。 戻りコードの 0 を受け取ることを確認し、構成ファイル・システム上のマイグレーションの一時ディレクトリーにあるログ・ファイルを調べてください。マイグレーション一時ディレクトリーは temporary_directory_location/nnnnn であり、 ここで、temporary_directory_location は一時ディレクトリー・ロケーションに指定したディレクトリー、 nnnnn はマイグレーション・ジョブの生成時にマイグレーション ID 用に 生成した数値です。デフォルトの一時ディレクトリー・ロケーションは /tmp/migrate です。

    2. 次の 3 つのジョブをサブミットします。
      1. BBOWDPRO ジョブをサブミットします。

        BBOWDPRO は、WebSphere Application Server のホームおよびデフォルト・プロファイルを作成します。

      2. BBOWDPRE ジョブをサブミットします。

        BBOWDPRE は、マイグレーション事前アップグレード・プロセスを実行します。

      3. BBOWDPOS ジョブをサブミットします。

        BBOWDPOS は、マイグレーション事後アップグレードおよび完了 (ファイル・アクセス権限の変更) プロセスを実行します。

  5. マイグレーションを行う前にトレース制御の設定を検査します。

    WebSphere Application Server をマイグレーションするには、特定の構成設定を手動で変更する必要があります。 管理コンソールを使用して、以下のように環境変数のリストを検査します。

    1. 「環境」 > 「WebSphere 変数の管理 (Manage WebSphere Variables)」とクリックします。
    2. 「構成」タブで、ras_trace_outputlocation 変数が存在するかどうかを確認し、存在する場合はその設定を書き留めます。

      ras_trace_outputlocationTRCFILE が設定されている場合は、新しい WebSphere Application Server の開始プロシージャーを手動で変更して、TRCFILE DD ステートメントを含める必要があります。

    トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): 開始プロシージャーの手動変更は、新しい WebSphere Application Server および関連するデーモンを始動する前に行う必要があります。gotcha
  6. 旧アプリケーション・サーバーおよびデーモンをシャットダウンします。

    同じセル内の デプロイメント・マネージャーの LPAR 上のすべてのノードがシャットダウンされていることを 確認してください。

  7. 必要に応じて、デーモン JCL プロシージャーを更新します。

    WebSphere Application Server for z/OS バージョン 9.0 では、デーモン・プロセスは、同一の LPAR 上で管理するサーバーの最高レベルのコードになっている必要があります。デプロイメント・マネージャーの開始時には、 レベルは バージョン 9.0 になります。

    すべてのノードを バージョン 9.0 にマイグレーションした後で、かつ以前のバージョンのライブラリーをシステムから除去する前に、デーモン JCL プロシージャーを更新する必要があります。これを実行しない場合、デーモン始動で障害が発生します。

    注:
    • バージョン 7.0 以降 から バージョン 9.0 にマイグレーションする場合、デーモンは、最新バージョンの SBBOLD2 および SBBOLPA データ・セットを含む STEPLIB を持つ必要があります。
    • バージョン 9.0 セル内のバージョン 9.0 サーバーが、バージョン 7.0 以降 セルと同じシステムに存在する バージョン 7.0 以降 セルのバージョン 7.0 以降 サーバーと通信している場合は、バージョン 7.0 の SBBOLD2 および SBBOLPA データ・セットをバージョン 9.0 デーモンの STEPLIB に追加することも必要です。
  8. 新規デプロイメント・マネージャーを開始します。

    バージョン 7.0 以降 アプリケーション・サーバーの開始に使用する既存のコマンドと同じものを使用しますが、RACF STARTED プロシージャー名は、マイグレーション・ジョブの生成時にデプロイメント・マネージャー・パネルでコントローラー・プロシージャー名として入力した値に置き換えます。このコマンドにより バージョン 9.0 デプロイメント・マネージャーを開始します。 サーバーが初期化を終了するまで待機してから、先に進みます。

    次のメッセージがコンソール上および BBODMGR のジョブ・ログ内に表示されます。
    BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBODMGR

次のタスク

バージョン 9.0 への正常なマイグレーションを確認し、 マイグレーション済み構成を正常に実行した後、以下の項目を削除する必要があります。
  • ソース構成のファイル・システム内にあるすべてのもの
  • ターゲット構成の temporary_directory_location/nnnnn ディレクトリー内にあるすべてのもの。ここで、temporary_directory_location は 一時ディレクトリー・ロケーションに指定したディレクトリー (デフォルトで /tmp/migrate) であり、 nnnnn はマイグレーション・ジョブの作成時にマイグレーション ID 用に生成した 数値です。
  • bbomigrt2.sh ファイル

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



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