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

WebSphere® Application Server の新しいバージョンにマイグレーションするには、 ご使用の製品エディション、プロファイル・タイプ、サーバー構成、およびアプリケーション・デプロイメントなどの要因を慎重に考慮する必要があります。この概要では、 製品を正常にマイグレーションするのに役立つよう、概念、用語、ツール、および戦略を説明します。

一般的なマイグレーション用語

以下の用語は、マイグレーションに関して頻繁に使用される用語です。
  • バージョン またはリリース: 重要な新機能を含む、製品に対する更新。
  • エディション: 特定の機能セットを含む、バージョン内の製品パッケージ。例えば、Network Deployment です。
  • プロファイル: デプロイメント・マネージャーやアプリケーション・サーバーなどのアプリケーション・サーバー・プロセス用のランタイム環境を定義する一連のファイル。プロファイルには、 アプリケーション・サーバーがどのように動作するのか、およびアプリケーションがどこにデプロイされるのかに関する構成が含まれます。
  • ソース: データおよびオブジェクトのマイグレーション元 (ソース・プロファイルソース・マシン など)。
  • ターゲット: データおよびオブジェクトのマイグレーション先 (ターゲット・プロファイルターゲット・マシン など)。
  • ノード: 管理対象または非管理対象のサーバーまたはサーバー・クラスターのグループ。セルによって管理される各ノードはそれぞれ 1 つの固有の構成を持つことができます。
  • セル: 1 つ以上のノードまたは構成を管理する 1 つのデプロイメント・マネージャーを含んでいるグループ。セル内のノードはデプロイメント・マネージャーに統合 されます。セル・レベルの構成は、すべてのノードに共通です。
  • 混合セル環境: 少なくとも 1 つの統合ノードのリリースが、セルを管理するデプロイメント・マネージャーのリリースよりも古い場合。統合できるノードは、デプロイメント・マネージャーよりも 3 リリース前までです。

マイグレーションの基本的概念

マイグレーション は、構成を古いリリースから新しいリリースに (新しい構成が古い構成にできるだけ近い動作を行うように) 移す処理です。 マイグレーションの主要単位はプロファイル であり、これは次の基本的な 3 ステップでマイグレーションされます。
  1. 古いインストール済み環境からソース・プロファイルのスナップショットを作成します。
  2. 互換性のあるターゲット・プロファイルを新しいインストール済み環境に作成します。
  3. スナップショットのデータをターゲット・プロファイルにマージします。

デプロイメント・マネージャーおよび統合されたノードを含んでいるセルのマイグレーションには、 特別な注意が必要です。デプロイメント・マネージャーがセル内の構成を制御するので、 各ノードはマイグレーション時に新しいデプロイメント・マネージャーとの同期を取る必要があります。

混合セル環境

セルには、異なるバージョンの WebSphere Application Server からのノードを含めることができます。WebSphere Application Server バージョン 9.0 混合セルには、WebSphere Application Server バージョン 9.0 および バージョン 7.0 以降 をサポートするノードを含めることができます。混合セル環境では、セルのメンバーでバージョン 7.0 よりも古いものがある場合、 ツールはデプロイメント・マネージャーをマイグレーションできません。管理者は、該当するノードをバージョン 7.0 以上にマイグレーションするか、セルから削除する必要があります。

混合セル環境を実現するには、次の 2 つの方法があります。
  1. 既存システムのインクリメンタル・ノード・マイグレーションを実行します。
    1. デプロイメント・マネージャーをバージョン 9.0 にマイグレーションします。デプロイメント・マネージャーは、ノードの最高バージョンのレベルでなければなりません。前バージョンのノードを持っている場合、このデプロイメント・マネージャーのマイグレーションによって、WebSphere Application Server の最高バージョンで混合セルが作成されます。
    2. 一度に 1 つのノードをこの新しい最高バージョンにマイグレーションする場合、そのセルは、WebSphere Application Server の最高バージョンのセルになります。
      注: このセルは、デプロイメント・マネージャーよりも高いバージョンにできません
  2. バージョン 9.0 にデプロイメント・マネージャーをマイグレーションしてから、古いバージョンのノードを新しいバージョンのデプロイメント・マネージャーに統合します。このような形式のマイグレーションがサポートされるのは、 バージョン 7.0 以降 のノードのみです。
    1. まず、デプロイメント・マネージャーをバージョン 9.0 にマイグレーションします。デプロイメント・マネージャーは、ノードの最高バージョンのレベルでなければなりません。
    2. 次に、ノードを バージョン 7.0 以降 から新しい最新バージョンのデプロイメント・マネージャーに統合できます。
    トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): インクリメンタル・マイグレーションのこの方法を実行すると、システムは混合セル環境になり、ノードはバージョン 9.0 のデプロイメント・マネージャーによって管理されます。マイグレーション計画には、最終的にすべてのノードのバージョン 9.0 レベルへのマイグレーションを含める必要があります。これによって一貫性のあるノードの管理ができるようになります。gotcha

既存の機能は、混合セル環境で引き続き使用できます。既存アプリケーション実行などの適切な操作や、addNode、混合クラスターの作成、システムの構成、Mbean の呼び出し、アプリケーションのデプロイなどの管理操作の実行ができます。混合セル環境の新機能サポートは、機能、優先度、および使用可能なリソースなどに基づいて個別に決まります。

トラブルの回避 (Avoid trouble) トラブルの回避 (Avoid trouble): 混合セル環境で実行中のクライアントで、ターゲット・クラスターのクラスター・メンバーに関するポート情報が失効してしまう状況が突然発生することがあります。この状況が最もよく起こるのは、すべてのクラスター・メンバーのポートが動的ポートで、要求が送信されていない期間中にそれらのすべてのクラスター・メンバーが再始動された場合です。 このような場合、クライアント・プロセスは、結果的に、 ノード・エージェントにルーティングしてクラスター・メンバーの新しいポート・データを受信し、 その新しいポート・データを使用してクラスター・メンバーにルーティングしようとします。

クライアントがノード・エージェントと通信する際に問題が発生した場合、 あるいは新しいポート・データをクラスター・メンバーとノード・エージェントの間で伝搬する際に問題が発生した場合、 クライアントで要求が失敗する可能性があります。 これらの失敗は、一時的なものにすぎない場合もあります。 または、失敗を解決するために 1 つ以上のプロセスの再始動が必要になるケースもあります。

このような場合に発生する可能性があるクライアントのルーティング問題を回避するためには、 クラスター・メンバーで静的ポートを構成するようにします。 静的ポートを構成すると、 クライアント・プロセスがクラスター・メンバーに関する情報を取得する際にポート・データが変わることはありません。 クラスター・メンバーが再始動された場合や、 プロセス間で通信あるいはデータ伝搬の問題が発生した場合でも、クライアントが保持しているポート・データは引き続き有効です。 この回避策によって、 必ずしも通信やデータ伝搬の根本的な問題が解決されるわけではありませんが、 クライアントにより予期しないあるいは不規則なルーティングが決定される症状は回避されます。

gotcha

WebSphere Application Server の旧バージョンのマイグレーションも共存も行わない場合は、以前のインストールを無視することになり、デフォルトのポート割り当てが競合しているために、一度に 1 つのバージョンのみを実行できます。一方のバージョンでデフォルト以外のポートを使用する場合には、両方のバージョンを競合させることなく同時に実行することができます。

FAQ (よくある質問)

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

いいえ。WebSphere Application Server for z/OS バージョン 9.0 では、バージョン 7.0 以降 の構成を、バージョン 9.0 レベルにマイグレーションする必要があります。

バージョン 9.0 にマイグレーションする際は、以下の点に注意してください。
  • WebSphere Application Server 以外のアプリケーションまたは製品に属する変数は、マイグレーションされないで、そのまま新しい環境に持ち込まれます。したがって、マイグレーションする前にその他の製品アップグレードがないかチェックして、これらの変数がすべてマイグレーション後も引き続き正確であることを確認してください。
  • バージョン 7.0 以降 からバージョン 9.0 へのマイグレーションを実行する前に、領域の制約 (IEFUSI 制限など) がないことを判断してください。このような制約があると、予期しない Java™ 仮想マシン (JVM) エラーが発生することがあります。
基本的なマイグレーション・プロセスとはどのようなものですか?
  1. WebSphere Application Server for z/OS バージョン 9.0 用の SMP/E コードをインストールします。
    • SMP/E コードには、Installation Manager が含まれています。SMP/E コードをインストールすると、WebSphere リポジトリーを取得し、WebSphere 製品コードをシステム上でビルドするライセンスが与えられます。
  2. z/OS マイグレーション管理ツールまたは zmmt コマンドを使用して、マイグレーションの実行に必要なマイグレーション・ユーティリティーを作成します。
  3. これらのジョブを実行します。

    既存の バージョン 7.0 以降 の構成とは別に、新しい バージョン 9.0 構成がバージョン 7.0 以降 の構成情報に基づいて作成されます。

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

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

構成内のノードごとに、提供されているユーティリティーが実行されることを示す図です

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

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

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

表 1. マイグレーション・ユーティリティーとその目的. この表では、さまざまなマイグレーション・ユーティリティーとその目的をリストします。
ユーティリティー 目的
BBOWMG1B (スタンドアロン・アプリケーション・サーバー・マイグレーション)

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

マイグレーションするノード上のすべてのサーバーを、ピアの再始動およびリカバリー (PRR) モードで開始するように構成できます。

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

このジョブは、XA アダプターを使用していて、XA ログをマイグレーションする必要がある場合にのみ必要です。 バージョン 7.0 以降 の管理コンソールで、「リソース」>「JDBC プロバイダー」とクリックして、リソース・プロバイダーを確認します。 DB2®、Apache Derby などの XA プロバイダーを選択しているかどうかを調べます。

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

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

PRR モードを使用不可にして、すべてのサーバーを通常の作動状態に戻します。

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

このジョブは、XA アダプターを使用していて、XA ログをマイグレーションする必要がある場合にのみ必要です。 バージョン 7.0 以降 の管理コンソールで、「リソース」>「JDBC プロバイダー」とクリックして、リソース・プロバイダーを確認します。 DB2、Apache Derby などの XA プロバイダーを選択しているかどうかを調べます。

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

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

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

オプション: バージョン 9.0 構成ルート用にファイル・システムとマウント・ポイントを作成し、そのファイル・システムをマウントします。

バージョン 9.0 構成を含めるために既存のファイル・システムを使用する場合は、このジョブを実行しないで、マイグレーション定義の作成時に指定したマウント・ポイントを手動で作成し、そのファイル・システムがマウントされていることを確認する必要があります。いずれの場合も、マイグレーションを進める前に、構成ファイル・システムとマウント・ポイントを作成し、 ファイル・システムをマウントしておく必要があります。

スタンドアロン・アプリケーション・サーバー・マイグレーションの場合は以下のユーティリティー:
  • BBOWMG3B
  • BBOWBPRO
  • BBOWBPRE
  • BBOWBPOS
デプロイメント・マネージャー・マイグレーションの場合は以下のユーティリティー:
  • BBOWMG3D
  • BBOWDPRO
  • BBOWDPRE
  • BBOWDPOS
統合ノード・マイグレーションの場合は以下のユーティリティー:
  • BBOWMG3F
  • BBOWMPRO
  • BBOWMPRE
  • BBOWMPOS

BBOWMG3x は、バージョン 7.0 以降 から バージョン 9.0 へのノードの完全マイグレーションを実行します。

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

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

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

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

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

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

サーバーを開始する生成済みのジョブ制御言語 (JCL) プロシージャーを、指定されたプロシージャー・ライブラリーにコピーします。

バージョン 9.0 構成が別の JCL 開始プロシージャー名を使用するように選択すると、このユーティリティーは、新しい バージョン 9.0 構成を更新して、元の バージョン 7.0 以降 の構成に存在していた名前の代わりに新しい JCL 名を使用します。

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

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

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

マイグレーション・ユーティリティーは、WebSphere Application Server バージョン 7.0 以降 の現在の構成ファイル・システムの内容を変換して、バージョン 9.0 の新しい別の構成ファイル・システムにマージします。

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

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

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

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

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

はい。マルチノード構成では、 他のノードを稼働中のままにしておくことが可能です。 ただし、マイグレーションするノードは、そのノードのサーバーを停止しておく必要があります。

WebSphere Application Server Network Deployment 構成の一部であるアプリケーション・サーバー・ノードをマイグレーションする場合は、そのセルに以前マイグレーションしたバージョン 9.0 のデプロイメント・マネージャーが稼働している必要があります。これは、マイグレーションの一部で、wsadmin スクリプト機能を使用して、新規にマイグレーションされたアプリケーション・サーバー・ノードとデプロイメント・マネージャーを同期するためです。 この同期化を実行するためには、デプロイメント・マネージャーが稼働中でなければなりません。

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

はい。可能です。WebSphere Application Server バージョン 7.0 以降 は、同じセル内および同じ論理区画 (LPAR) 上でバージョン 9.0 と共存できます。

新しくマイグレーションした WebSphere Application Server for z/OS バージョン 9.0 のデプロイメント・マネージャーは、これまでどおり バージョン 7.0 以降 のノードと通信できますか?

はい。バージョン 9.0 レベルのコードにマイグレーションされたデプロイメント・マネージャーは、バージョン 7.0 以降 のノードを管理できます。管理コンソールによって行われた変更は、そのノードに適用されます。 以下の点を忘れないようにしてください。
  • デプロイメント・マネージャーがバージョン 9.0 にマイグレーションされると、バージョン 9.0 の新しい基本構成が作成されます。バージョン 7.0 以降 の基本構成は引き続き存在します。ただし、バージョン 9.0 デプロイメント・マネージャーが構成を変更すると、その変更がバージョン 9.0 の新しい基本構成に対しても行われます。引き続き バージョン 7.0 以降 のコードを使用できますが、以前のコードが復元されたとき、バージョン 9.0 で行われた変更を確認できません。
  • バージョン 7.0 以降 のデプロイメント・マネージャーには、バージョン 9.0 のノードを管理する機能はありません。

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

はい。次の順序に従ってマイグレーションします。
  1. 常にデプロイメント・マネージャーを最初にマイグレーションします。
  2. 次に、デプロイメント・マネージャーと同じシステムまたは多重仮想記憶 (MVS™) イメージに存在するアプリケーション・サーバー・ノードをマイグレーションできます。

WebSphere Application Server for z/OS バージョン 9.0 のセルと、 バージョン 7.0 以降 のセルは共存できますか?

はい。シスプレックスまたは与えられた MVS イメージについて、WebSphere Application Server for z/OS バージョン 9.0 のセルを バージョン 7.0 以降 のセルと共存させることができます。以下の制限があります。
  • 同じセル内に バージョン 7.0 以降 のレベルでサーバーを含めることができます。
  • 同じセル内に z/OS ノードと z/OS 以外のノードを含めることができます。ただし、デプロイメント・マネージャーのバージョンはセル内で最高レベルでなければなりません。また、デプロイメント・マネージャーが置かれているプラットフォーム以外のプラットフォーム上のノードは バージョン 7.0 以降 である必要があります。
  • z/OS ノード上のサーバーは、z/OS 以外のノードにあるサーバーと一緒にクラスター化することはできません。
  • LPAR には、同じセルからの複数のノードを含めることができます。
  • 各 LPAR には、その LPAR 上のサーバーを伴うデーモンが、 多くてもセル当たり 1 つしかありません。 これは、その LPAR 用に構成されている、 当該セルのノードの数とは関係がありません。
  • 指定された LPAR では、 ノードとは関係なく、デーモンは、 そのセル内にある LPAR 上の すべてのサーバーのバージョン・レベル以上である必要があります。
  • 同一ノード内のすべてのサーバーは、同一のバージョン・レベルでなければなりません。
  • デプロイメント・マネージャーは、 セル内のサーバーのバージョン・レベル以上でなければなりません。
  • コントローラーとそのサーバントは、同一のバージョン・レベルでなければなりません。
  • 同一のセル・ショート・ネームを持つ 2 つのセルは存在しません。
  • 以上のほかにも、個別のセルに関して、コードのバージョンの相違にかかわらない考慮事項があります。 例えば、別々の構成ファイル・システムのマウント・ポイントおよび別々の JCL プロシージャーが必要です。

トピックのタイプを示すアイコン 概念トピック



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