WebSphere Application Server for z/OS, Version 6.1   
             オペレーティング・システム: z/OS

             目次と検索結果のパーソナライズ化

マイグレーション、共存、およびインターオペラビリティーの概要

マイグレーションの目的は、 WebSphere Application Server の旧バージョンをバージョン 6.1 とほぼ同じ環境に再構成することです。 共存の目的は、競合しない混合バージョン環境を作成し、 すべてのバージョンのノードを同時に始動および実行できるようにすることです。 もう 1 つの目的は、ロールバックを容易にし、両方のバージョンを一度に実行できる環境を作成するこ とです。 相互運用とは、2 つの共存する製品のインストール間または異なるシステム上の製品間で、データを交換することです。

FAQ (よくある質問)

新しい WebSphere Application Server for z/OS バージョン 6.1 のデータ・セット を指すだけで、サーバーを再始動できますか?

サポートしません。WebSphere Application Server for z/OS バージョン 6.1 では、 バージョン 5.x または 6.0.x 構成をバージョン 6.1 レベルまでマイグレーションする必要があります。

バージョン 6.1 にマイグレーションする際は、以下の問題に注意してください。
  • WebSphere Application Server 以外のアプリケーションまたは製品に属する変数は、マイグレーションされませんが、 そのままです。 したがって、マイグレーションする前にその他の製品アップグレードがないかチェックして、 これらの変数がすべてマイグレーション後も引き続き正確であることを確認してください。
    WebSphere Application Server バージョン 6.1 が SDK 1.5 を使用するのに対し、WebSphere Application Server バージョン 5.02 は SDK 1.3 を使用します。 例えば、以下の Java SDK z/OS 環境変数の変更は SDK 1.3 および SDK 1.4 間で行われました。
    • IBM_JAVA_ZOS_TDUMP_PATTERN は、JAVA_DUMP_TDUMP_PATTERN に変更されました。
    • IBM_JAVA_ZOS_TDUMP は前に移植されませんでした。
      JVM シグナル・ハンドラーが IEATDUMP を呼び出してトランザクション・ダンプを作成することを回避するために、IBM_JAVA_ZOS_TDUMP=No または JAVA_DUMP_TDUMP=No をコード化することはできません。 これを回避するためには、JAVA_DUMP_OPTS 環境変数を使用することができます。以下に例を示します。
      JAVA_DUMP_OPTS="ONDUMP(NONE),ONOUTOFMEMORY(NONE),ONERROR(NONE),ONEXCEPTION(NONE)"
      上記の例は、シグナル・ハンドラーによって処理されるどの条件についても、なにも診断アクションを取りません。

      JAVA_DUMP_OPTS 環境変数の使用について詳しくは、「IBM Developer Kit Diagnostics Guide」を参照してください。

  • バージョン 5.x または 6.0.x からバージョン 6.1 へのマイグレーションを実行する前に、 領域の制約 (IEFUSI 制限など) がないことを確認してください。 これらの制約があると、予期しない JVM エラーが発生することがあります。
基本的なマイグレーション・プロセスとはどのようなものですか?
  1. WebSphere Application Server for z/OS バージョン 6.1 の SMP/E コードをインストールします。
  2. カスタマイズ・ダイアログの指示に従って、 マイグレーションの実行に必要なマイグレーション・ユーティリティーを作成します。
  3. これらのジョブを実行します。

    新しいバージョン 6.1 構成が、既存のバージョン 5.x または 6.0.x 構成とは別に作成されます。 この新しい構成は、そのバージョン 5.x または 6.0.x の構成情報に基づいています。

マイグレーションは、ノードごとのアクティビティーですか?

はい。構成をマイグレーションするプロセスでは、構成内のノードごとに、 提供されているユーティリティーを実行します。

スタンドアロン・アプリケーション・サーバーに存在する ノードは 1 つだけですが、そのノードもマイグレーションする必要があります。 これらのステップは、他のノードに対して実行する場合と基本的に同じです。 ただし、デプロイメント・マネージャーを実行する必要はありません。 スタンドアロン・アプリケーション・サーバー・ノードをマイグレーションするためのアクティビティーの チェックリストについては、スタンドアロン・アプリケーション・サーバーのマイグレーション: チェックリスト を参照してください。

マイグレーション・ユーティリティーは何を行うのでしょうか?

マイグレーション・ユーティリティーは、以下の目的で使用します。

ユーティリティー 目的
BBOWMG1B (スタンドアロン・アプリケーション・サーバー・マイグレーション)

BBOWMG1F (統合ノード・マイグレーション)

マイグレーションするノード上のすべてのサーバーが PRR 処理モードで開始できるように構成されます。 このジョブを完了した後、マイグレーションするノード上のすべてのサーバーを開始し、 それらのサーバーが終了するのを待機する必要があります。 PRR 処理モードは、未解決のトランザクションをすべて解決し、 トランザクション・ログをクリアし、サーバーを終了します。 このジョブは、デプロイメント・マネージャーのマイグレーションには必要でなく、 XA コネクターを使用しない構成ではオプションです。

このジョブは、XA アダプターを使用していて、XA ログをマイグレーションする必要がある場合にのみ必要です。 バージョン 5.x または 6.0.x 管理コンソールで、リソース・プロバイダーを確認してください。 これを行うには、 「リソース」>「JDBC プロバイダー」とクリックし、 DB2、Cloudscape などの XA プロバイダーが選択されているかを確認します。

BBOWMG2B (スタンドアロン・アプリケーション・サーバー・マイグレーション)

BBOWMG2F (統合ノード・マイグレーション)

PRR モードを使用不可にしてすべてのサーバーを通常の作動状態に戻します。 このジョブを完了した後、すべてのサーバーを開始する必要はありません。 このジョブは、デプロイメント・マネージャーのマイグレーションには必要でなく、 XA コネクターを使用しない構成ではオプションです。

このジョブは、XA アダプターを使用していて、XA ログをマイグレーションする必要がある場合にのみ必要です。 バージョン 5.x または 6.0.x 管理コンソールで、リソース・プロバイダーを確 認してください。これを行うには、 「リソース」>「JDBC プロバイダー」とクリックし、 DB2、Cloudscape などの XA プロバイダーが選択されているかを確認します。

BBOMBHFS または BBOMBZFS (スタンドアロン・アプリケーション・サーバー・マイグレーション)

BBOMDHFS または BBOMDZFS (デプロイメント・マネージャー・マイグレーション)

BBOMMHFS または BBOMMZFS (統合ノード・マイグレーション)

オプション: バージョン 6.1 構成ルート用のファイル・システムとマウント・ポイントを作成し、 そのファイル・システムをマウントします。 バージョン 6.1 構成を含めるために既存のファイル・システムを使用する場合は、 このジョブを実行しないで、カスタマイズ・ダイアログで指定したマウント・ポイントを手動で作成し、 そのファイル・システムがマウントされていることを確認する必要があります。 いずれの場合も、マイグレーションを進める前に、構成ファイル・システムとマウント・ポイントを作成し、 ファイル・システムをマウントしておく必要があります。
BBOWMG3B (スタンドアロン・アプリケーション・サーバー・マイグレーション)

BBOWMG3D (デプロイメント・マネージャー・マイグレーション)

BBOWMG3F (統合ノード・マイグレーション)

バージョン 5.x または 6.0.x からバージョン 6.1 へ、 ノードのマイグレーションを実行します。
BBOMBCP (スタンドアロン・アプリケーション・サーバー・マイグレーション)

BBOMDCP (デプロイメント・マネージャー・マイグレーション)

BBOMMCP (統合ノード・マイグレーション)

生成済み JCL プロシージャーをコピーして、 指定されたプロシージャー・ライブラリーに対してサーバーを開始します。 バージョン 6.1 構成で異なる JCL 開始プロシージャー名を使用する場合には、 このユーティリティーは、元のバージョン 5.x または 6.0.x 構成内に存在した名前の代わりに新規 JCL 名を用いて、 新規バージョン 6.1 構成を更新します。

マイグレーションはどこで実行するのでしょうか?

マイグレーションするノードが常駐しているシステムと同じシステムでジョブを実行します。

ノードがマイグレーションされるとどうなるのでしょうか?

マイグレーション・ユーティリティーは、 現在の WebSphere Application Server バージョン 5.x または 6.0.x 構成ファイル・システムの内容を変換し、 新しい別のバージョン 6.1 構成ファイルにマージします。

マイグレーション中に既存構成は失われますか?

マイグレーション時に、 元の WebSphere Application Server バージョン 5.x または 6.0.x 構成ツリーは影響を受けません。 何らかの理由で完了前にマイグレーションが失敗した場合は、今までの構成はまだ残ったままです。

自分のノードに複数のアプリケーション・サーバーが存在する場合は、それらすべてをマイグレーションする必要はありますか?

はい。ユーティリティーは、 ノード・エージェントを含むすべてのサーバーを検出し、すべてをマイグレーションします。 ノードに対するマイグレーション・ユーティリティーの 1 回の起動で、そのノード内のすべてのサーバーが処理されます。

ノード内のサーバーは、マイグレーションを実行するために停止する必要はありますか?

はい。マルチノード構成では、 他のノードを稼働中のままにしておくことが可能です。 ただし、マイグレーションするノードは、そのノードのサーバーを停止しておく必要があります。
注: Network Deployment 構成の一部であるアプリケーション・サーバー・ノードをマイグレーションする場合は、 そのセルの以前にマイグレーションしたバージョン 6.1 デプロイメント・マネージャーを実行している 必要があります。 これは、マイグレーションの一部で、wsadmin スクリプト機能を使用して、 新規にマイグレーションされたアプリケーション・サーバー・ノードとデプロイメント・マネージャーを同期するためです。 デプロイメント・マネージャーは、 この同期化を実行するために稼働中になっている必要があります。

1 つのセルで、 マイグレーションしたノードの一部を作動させ、一部のノードを作動させないことは可能ですか?

はい。可能です。WebSphere Application Server バージョン 5.1 は、同じセル内、および同じ LPAR 上でバージョン 6.1 と共存できます。 ただし、バージョン 5.0.x からマイグレーションする場合、 デプロイメント・マネージャー・ノードおよび他のアプリケーション・サーバー・ノードは、 同じ MVS イメージ上に順次、あるいは実質的には同時にマイグレーションする必要があります。 バージョン 5.0.x とバージョン 6.1 のノードは、 同一の LPAR 上の同一のセル内に存在できません。

新しくマイグレーションした WebSphere Application Server for z/OS バージョン 6.1 デプロイメント・マネージャーは、 これまでどおりバージョン 5.x または 6.0.x ノードと「話をする」ことができますか?

はい。バージョン 6.1 レベルのコードにマイグレーションされたデプロイメント・マネージャーは、 バージョン 5.x または 6.0.x ノードを管理できます。 管理コンソールによって行われた変更は、そのノードに適用されます。 以下の事柄について、確認してください。
  • デプロイメント・マネージャーがバージョン 6.1 にマイグレーションされると、 新しいバージョン 6.1 の「マスター構成」が作成されます。 バージョン 5.x または 6.0.x のマスター構成は、引き続き存在します。 しかし、バージョン 6.1 デプロイメント・マネージャーが構成を変更する場合には、 新規バージョン 6.1 のマスター構成を変更します。 バージョン 5.x または 6.0.x のコードが使用可能な場合に、 以前のコードが復元されると、バージョン 6.1 に対して行ったすべての変更は確認できなくなります。
  • バージョン 5.x または 6.0.x デプロイメント・マネージャーには、 バージョン 6.1 ノードを管理する機能はありません。
  • WebSphere Application Server バージョン 6.1 デプロイメント・セルには、 バージョン 5.x または 6.0.x ノードの混合リリースを含むことができますが、 バージョン 6.0.1.x 用の混合ノード管理サポートはありません。
    バージョン 6.1 マイグレーション・ツールは、 これまでどおり、デプロイメント・マネージャーのマイグレーション時にこれらのノードをマイグレーションしますが、 バージョン 6.1 デプロイメント・マネージャーではノードを管理できないという警告メッセージが表示されます。 必要に応じて、以下のいずれかを実行できます。
    • すべてのバージョン 6.0.1.x ノードを、少なくともバージョン 6.0.2 にアップグレードします。 これにより、それらのノードをバージョン 6.1 デプロイメント・マネージャーで管理できるようになります。
    • 即時にこれらのノードをバージョン 6.1 にマイグレーションします。

マルチノード・マイグレーションを実行するには順序がありますか?

はい、あります。
  1. 常にデプロイメント・マネージャーを最初にマイグレーションします。
  2. デプロイメント・マネージャーと同じノードに存在する WebSphere Application Server for z/OS バージョン 5.0.x アプリケーション・サーバーを、次にマイグレーションする必要があります。 バージョン 5.1 とバージョン 6.1 のノードは、同一のセル内、および同一の LPAR 上に共存できるため、 どのバージョン 5.1 ノードも、即時にマイグレーションする必要はありません。 共存について詳しくは、共存サポート を参照してください。
  3. デプロイメント・マネージャーと同じシステム上の、 またはその他の MVS イメージ上のアプリケーション・サーバー・ノードを、 次にマイグレーションできます。

WebSphere Application Server for z/OS バージョン 6.1 のセルと、 バージョン 5.x または 6.0.x のその他のセルは共存できますか?

はい、共存できます。SYSPLEX または任意の所定の MVS イメージの場合には可能です。 この場合には、以下のようないくつかの制約事項があります。 ほとんどの制約事項は、以前のバージョンにも存在します。
  • バージョン 5.0.x、5.1.x、6.0.x、および 6.1.x のサーバーを、セルに含めることができます。
  • z/OS および z/OS 以外のノードを、セルに含めることができます。 ただし、デプロイメント・マネージャーのバージョンが、 セル内で最高レベルでなければなりません。 デプロイメント・マネージャーが置かれている プラットフォーム以外のプラットフォーム上のノードが、 バージョン 6.0 以降である必要があります。
  • z/OS ノード上のサーバーは、z/OS ノード以外にある サーバーと一緒にクラスター化することはできません。
  • LPAR には、同じセルからの複数のノードを含めることができます。
  • 各 LPAR には、その LPAR 上のサーバーを伴うデーモンが、 多くてもセル当たり 1 つしかありません。 これは、その LPAR 用に構成されている、 当該セルのノードの数とは関係がありません。
  • 指定された LPAR では、 ノードとは関係なく、デーモンは、 そのセル内にある LPAR 上の すべてのサーバーのバージョン・レベル以上である必要があります。
  • 同一ノード内のすべてのサーバーは、同一のバージョン・レベルでなければなりません。
  • デプロイメント・マネージャーは、 セル内のサーバーのバージョン・レベル以上でなければなりません。
  • コントローラーとそのサーバントは、同一のバージョン・レベルでなければなりません。
  • 同一のセル・ショート・ネームを持つ 2 つのセルは存在しません。
  • バージョン 5.0.x は、同一の LPAR 上の同一のセル内にあるバージョン 6.1 と共存できません。 同一の LPAR 上に複数のバージョン 5.0.x ノードが存在している場合は、 すべてのノードを同時にバージョン 6.1 にマイグレーションする必要があります。
  • LPA/LNKLST 内に存在できるのは、1 つのバージョンのコードだけです。 他のバージョンは STEPLIB に組み込む必要があります。

    リンク・パック域、リンク・リスト、および STEPLIB を参照してください。

  • 別々のセルについては、コードのバージョンが異なるかどうかとは関係なく、その他の考慮事項があります。 例えば、別々の構成ファイル・システムのマウント・ポイントおよび別々の JCL プロシージャーが必要です。



関連タスク
製品構成のマイグレーション
マイグレーションと共存
スタンドアロン・アプリケーション・サーバーのマイグレーションの準備
Network Deployment 構成のマイグレーションの準備
スタンドアロン・アプリケーション・サーバーのマイグレーション: チェックリスト
デプロイメント・マネージャーのマイグレーション: チェックリスト
スタンドアロン・アプリケーション・サーバーのマイグレーション: カスタマイズ・ダイアログのウォークスルー
デプロイメント・マネージャーのマイグレーション: カスタマイズ・ダイアログのウォークスルー
統合ノードのマイグレーション: カスタマイズ・ダイアログのウォークスルー
スタンドアロン・アプリケーション・サーバーのマイグレーション
デプロイメント・マネージャーのマイグレーション
統合ノードのマイグレーション
概念トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 9:12:22 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/cmig_overview.html