z/OS 統合ノードのマイグレーション

デプロイメント・マネージャーをマイグレーションして再始動すると、生成したジョブ制御言語 (JCL) ジョブを実行して、フェデレーテッド・アプリケーション・サーバー・ノードのマイグレーションを実際に行うことができます。 カスタム・マイグレーション・ジョブの生成時には、ジョブの生成に使用された CNTL データ・セットの BBOMMINS メンバーでマイグレーション・ジョブを準備し実行するような、カスタマイズされた指示も作成しています。 統合ノードを バージョン 9.0 にマイグレーションするプロセスを実行するために、これらのカスタマイズされた指示に従います。

始める前に

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

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

sptcfg
  • マイグレーション、共存、およびインターオペラビリティーの概要およびマイグレーションに関する考慮事項を参照してください。
  • JCL マイグレーション・ジョブを生成していない場合は、先へ進むことができません。
  • これらの指示で参照する BBOWMG1F、BBOWMG2F、および BBOWMG3F の各ジョブは、WebSphere Administrator ユーザー ID によって実行依頼する必要があります。

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

  • 他の MVS™ イメージの統合ノードをマイグレーションするには、必ずノード自体が常駐しているシステムと同じシステム上でジョブを実行します。
  • ヒント: マイグレーション後に以前の状態にロールバックできるようにする場合は、WebSphere Application Server バージョン 7.0 以降 の統合ノードをマイグレーションするときに、以下のアクションを実行する必要があります。
    1. backupConfig コマンドまたは設定済みのバックアップ・ユーティリティーを使用して、 既存の構成をバックアップします。
      • backupConfig コマンドまたは設定済みのユーティリティーを実行して、バージョン 9.0 のデプロイメント・マネージャー構成をバックアップします。
      • backupConfig コマンドまたは設定済みのユーティリティーを実行して、バージョン 7.0 以降 の統合ノード構成をバックアップします。
      重要: このバックアップ構成の正確な名前と位置を記録しておく必要があります。

      詳しくは、資料の『backupConfig コマンド』の項目を参照してください。

    2. 統合ノードをマイグレーションします。

    必要に応じて、マイグレーションした統合ノードをロールバックすることができます。詳しくは、統合ノードのロールバックを参照してください。

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

このタスクについて

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

手順

  1. マイグレーションされている統合ノードに対してアプリケーション・サーバーおよびノード・エージェントが停止されていることを確認します。

    先に進む前に、統合ノードを停止する必要があります。

  2. 新しくマイグレーションしたデプロイメント・マネージャーが稼働中であることを確認します。

    アプリケーション・サーバー・ノードを正しくマイグレーションするには、デプロイメント・マネージャーが実行されている必要があります。 このマイグレーションが機能するには、デプロイメント・マネージャーが稼働しており、 その SOAP ポートを listen している必要があります。

    表 1. デプロイメント・マネージャーが稼働中です. 完了したらチェック・マークを付けてください。
    チェック・オフ 項目
      WebSphere Application Server バージョン 9.0 デプロイメント・マネージャーの管理コンソールにアクセスします。 これにより、デプロイメント・マネージャーが稼働中であることを確認します。
    表 2. アプリケーション・サーバーが稼働中です. 完了したらチェック・マークを付けてください。
    チェック・オフ 項目
      コードの WebSphere Application Server バージョン 9.0 のコピーが稼働していることを確認します。バージョンは管理コンソールの「ようこそ」ペインにリストされます。
  3. 新規 バージョン 9.0 構成ファイル・システムの作成とマウント。

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

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

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

  4. BBOWMG1F および BBOWMG2F をサブミットします。
    注: XA コネクターを使用していない場合、 BBOWMG1F および BBOWMG2F の実行依頼はオプションです。 ただし、トランザクション・ログが確実にクリアされるようにするには、両方のジョブをサブミットする必要があります。

    BBOWMG1F により、マイグレーションするフェデレーテッド・アプリケーション・サーバー・ノード上のすべてのサーバーが「ピアの再始動およびリカバリー (PRR)」モードで開始できるようになります。 PRR 処理モードは、未解決のトランザクションをすべて解決し、トランザクション・ログをクリアし、サーバーを停止します。 BBOWMG2F は、PRR モードを使用不可にしてすべてのサーバーを通常の作動状態に戻します。

    以下のステップに従って、XA トランザクション・ログをクリアします。
    1. アプリケーション・サーバーを停止します。
    2. ジョブ BBOWMG1F をサブミットして、戻りコードの 0 を確認します。
    3. フェデレーテッド・アプリケーション・サーバーを再始動し、そのサーバーが PRR 処理を実行して自動的に停止するのを待機します。
      ヒント: トランザクションが解決されてサーバーが停止した後では、ゼロ以外の戻りコードが、予想される通常のコードです。 サーバー・プロセスから戻される、受け入れ可能な結果コードの例を次に示します。
      BBOO0035W TERMINATING THE CURRENT PROCESS, REASON=C9C218D5
    4. ジョブ BBOWMG2F をサブミットして、戻りコードの 0 を確認します。
  5. 生成済み JCL プロシージャーをコピーします。

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

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

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

  6. 新規プロシージャー名を指定する場合、コントローラーおよびデーモンの RACF® STARTED プロファイルを更新します。
    コントローラー・リージョンが使用する STARTED プロファイルは、 プロシージャー名および JOBNAME に基づいています。 適切な ID を開始済みタスクに割り当てるために、STARTED プロファイルを適用する必要があります。 バージョン 7.0 以降 のコントローラー JCL プロシージャー名が AZACR であり、バージョン 9.0 に AZ1ACR を指定した場合、次のように、その新規プロシージャー名の STARTED プロファイルを作成する必要があります。
                  new controller      same identity used in
                     JCL name         V7.0 or later configuration
                        |                    |
     RDEFINE STARTED AZ1ACR.* STDATA(USER(AZACRU) GROUP(AZCFG) TRACE(YES))
    注:
    • 異なるユーザー ID を使用して始動しないでください。 ユーザー ID には、他の事項も関連しており、ユーザー ID を変更すると、 それらの事項も変更する必要があります。
    • オリジナル STARTED プロファイルが汎用の場合 (STARTED AZ*.*... など) には、 新規 STARTED プロファイルを作成する必要はありません。
    • サーバント・リージョン STARTED プロファイルは、プロシージャー名ではなく、JOBNAME に基づいています。 このため、サーバントでは、別のプロシージャー名を使用しても問題ありません。
    • デーモンおよびノード・エージェントはコントローラーです。このためこれらのコントローラーに別のプロシージャー名を使用すると、新規 STARTED プロファイルが暗黙指定されます。
  7. 必要に応じて、ログ・ストリームを削除および再定義します。
    このステップは、 ログ・ストリームを使用するためにバージョン 7.0 以降 サーバーでトランザクション XA パートナー・ログまたは補正ログを以前に構成している場合に限り実行します。
    1. ノードが停止されていることを確認します。
    2. ログ・ストリームを削除および再定義します。

      最初にサーバーでログ・ストリームを使用するように構成している場合、 バージョン 7.0 以降 のカスタマイズ中に作成した BBOLOGSD ジョブおよび BBOLOGSA ジョブを使用することができます。

      以下の例で、これらのジョブの例を示します。
      //RLSP1A  JOB 'xxxx,yyy,?','USERID',MSGCLASS=H,
      //         CLASS=J,MSGLEVEL=(1,1),REGION=4M,NOTIFY=&SYSUID
      //STEP1   EXEC PGM=IXCMIAPU
      //STEPLIB  DD   DSN=SYS1.MIGLIB,DISP=SHR
      //SYSPRINT DD   SYSOUT=*
      //SYSIN    DD   *
      
      DATA TYPE(LOGR) REPORT(YES) /* Default to show output of job */
       DELETE LOGSTREAM NAME(P1ACEL6A.W51ASA2.D)
       DEFINE LOGSTREAM NAME(P1ACEL6A.W51ASA2.D)
              LOWOFFLOAD(20)
              HIGHOFFLOAD(79)
              STG_DUPLEX(YES)
              DUPLEXMODE(UNCOND)
              STG_DATACLAS(OPERLOG)
              STG_SIZE(5000)
              HLQ(Q10RRS)
              LS_SIZE(5000)
              LS_DATACLAS(OPERLOG)
              STRUCTNAME(WAS_LOGRLS)
      /*

    SYSPLEX でノードをマイグレーションする場合、マイグレーションする各統合ノードに対してこのプロシージャーに従ってください。

  8. 以下のいずれかのアクションを実行します。
    1. BBOWMG3F ジョブをサブミットします。
      重要: z/OS 環境で実行され、複数の TCP/IP スタックで構成されている場合は、 環境変数 _BPXK_SETIBMOPT_TRANSPORT を追加して、マイグレーション・ジョブを、使用するべき適切な TCP/IP スタックに誘導する必要があります。正しくないスタックを使用すると java.net.UnknownHostException が発生し、後にこれが原因となって wsadmin ログインが失敗します。
      適切なスタックを識別するには、JCL に export _BPXK_SETIBMOPT_TRANSPORT=<stack.name> ステートメントが必要です。JCL は次のようになります。
      //***************************************************************         
      //*                                                                       
      //* UPGRADE: Perform the migration to the new Profile                     
      //*                                                                       
      //***************************************************************         
      //*                                                                       
      //*                                                                       
      //UPGRADE EXEC PGM=IKJEFT01,REGION=0M,COND=(4,LE)                         
      //SYSTSPRT DD SYSOUT=*
      //STDENV DD * // _CEE_RUNOPTS=TRAP(ON,NOSPIE) //*                         
      //SYSTSIN    DD *
        BPXBATCH SH +                                                           
        export _BPXK_SETIBMOPT_TRANSPORT=TCP; +                                 
        /tmp/migrate/bbomigrt2.sh WASPostUpgrade +                              
            /tmp/migrate/28133744/_      +                                      
        1>> /tmp/migrate/28133744/BBOWMG3F.out +                                
        2>> /tmp/migrate/28133744/BBOWMG3F.err;                                 
      /*                         

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

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

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

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

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

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

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

  9. 古いデーモンが停止されていることを確認します。

    この LPAR 上の同じセル内のすべての統合ノードが停止されていることを確認します。

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

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

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

    注:
    • バージョン 6.1 から バージョン 9.0 にマイグレーションする場合、デーモンは、バージョン 6.1 SBBOLD2 および SBBOLPA データ・セットを含む STEPLIB を持つ必要があります。
    • バージョン 9.0 セル内のバージョン 9.0 サーバーが、バージョン 9.0 セルと同じシステムに存在するバージョン 6.1 セルのバージョン 6.1 サーバーと通信している場合は、バージョン 6.1 の SBBOLD2 および SBBOLPA データ・セットを バージョン 9.0 デーモンの STEPLIB に追加することも必要です。
  11. 新規フェデレーテッド・アプリケーション・サーバー・ノードを始動します。
    1. ノード・エージェントを始動します。
      次のメッセージがコンソール上および BBON001 のジョブ・ログ内に表示されます。
      BBOO0019I INITIALIZATION COMPLETE
      FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBON001
    2. フェデレーテッド・アプリケーション・サーバーを始動します。

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

      次のメッセージがコンソール上および BBOS001 のジョブ・ログ内に表示されます。
      BBOO0019I INITIALIZATION COMPLETE FOR WEBSPHERE FOR z/OS CONTROL PROCESS BBOS001
  12. 構成およびアプリケーションが正常にマイグレーションされたことを確認します。

    Compute Grid または Feature Pack for Modern Batch 用に、ジョブ・スケジューラーが正しくマイグレーションされたこと、および、バッチ・アプリケーションをホストしているサーバーにジョブをディスパッチできることを検証します。

    ジョブ・スケジューラーのマイグレーションを検証するには、デプロイメント・マネージャー再始動後に、Web ブラウザーを介してジョブ管理コンソールにアクセスします。

    バッチ・アプリケーションをホストしているサーバーが正しく機能していることを検証するには、次のようにします。
    1. マイグレーションされたサーバー上のバッチ・アプリケーションが開始されることを検証します。サーバー・ログで、エラーがないかどうか調べてください。
    2. マイグレーションされたジョブ・スケジューラー・サーバーからジョブをサブミットすることによって、マイグレーションされたサーバーにバッチ・ジョブをディスパッチできることを検証します。ジョブのサブミットは、 ジョブ管理コンソール、WSGrid ユーティリティー、EJB インターフェース、または Web サービス・インターフェースを使用して行うことができます。

次のタスク

バージョン 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_amn
ファイル名:tmig_z_amn.html