マイグレーション、共存、およびインターオペラビリティーの概要
WebSphere® Application Server の新しいバージョンにマイグレーションするには、 ご使用の製品エディション、プロファイル・タイプ、サーバー構成、およびアプリケーション・デプロイメントなどの要因を慎重に考慮する必要があります。この概要では、 製品を正常にマイグレーションするのに役立つよう、概念、用語、ツール、および戦略を説明します。
一般的なマイグレーション用語
- バージョン またはリリース: 重要な新機能を含む、製品に対する更新。
- エディション: 特定の機能セットを含む、バージョン内の製品パッケージ。例えば、Network Deployment です。
- プロファイル: デプロイメント・マネージャーやアプリケーション・サーバーなどのアプリケーション・サーバー・プロセス用のランタイム環境を定義する一連のファイル。プロファイルには、 アプリケーション・サーバーがどのように動作するのか、およびアプリケーションがどこにデプロイされるのかに関する構成が含まれます。
- ソース: データおよびオブジェクトのマイグレーション元 (ソース・プロファイル やソース・マシン など)。
- ターゲット: データおよびオブジェクトのマイグレーション先 (ターゲット・プロファイル やターゲット・マシン など)。
- ノード: 管理対象または非管理対象のサーバーまたはサーバー・クラスターのグループ。セルによって管理される各ノードはそれぞれ 1 つの固有の構成を持つことができます。
- セル: 1 つ以上のノードまたは構成を管理する 1 つのデプロイメント・マネージャーを含んでいるグループ。セル内のノードはデプロイメント・マネージャーに統合 されます。セル・レベルの構成は、すべてのノードに共通です。
- 混合セル環境: 少なくとも 1 つの統合ノードのリリースが、セルを管理するデプロイメント・マネージャーのリリースよりも古い場合。統合できるノードは、デプロイメント・マネージャーよりも 3 リリース前までです。
マイグレーションの基本的概念
デプロイメント・マネージャーおよび統合されたノードを含んでいるセルのマイグレーションには、 特別な注意が必要です。デプロイメント・マネージャーがセル内の構成を制御するので、 各ノードはマイグレーション時に新しいデプロイメント・マネージャーとの同期を取る必要があります。
混合セル環境
セルには、異なるバージョンの WebSphere Application Server からのノードを含めることができます。WebSphere Application Server バージョン 9.0 混合セルには、WebSphere Application Server バージョン 9.0 および バージョン 7.0 以降 をサポートするノードを含めることができます。混合セル環境では、セルのメンバーでバージョン 7.0 よりも古いものがある場合、 ツールはデプロイメント・マネージャーをマイグレーションできません。管理者は、該当するノードをバージョン 7.0 以上にマイグレーションするか、セルから削除する必要があります。
- 既存システムのインクリメンタル・ノード・マイグレーションを実行します。
- デプロイメント・マネージャーをバージョン 9.0 にマイグレーションします。デプロイメント・マネージャーは、ノードの最高バージョンのレベルでなければなりません。前バージョンのノードを持っている場合、このデプロイメント・マネージャーのマイグレーションによって、WebSphere Application Server の最高バージョンで混合セルが作成されます。
- 一度に 1 つのノードをこの新しい最高バージョンにマイグレーションする場合、そのセルは、WebSphere Application Server の最高バージョンのセルになります。注: このセルは、デプロイメント・マネージャーよりも高いバージョンにできません。
- バージョン 9.0 にデプロイメント・マネージャーをマイグレーションしてから、古いバージョンのノードを新しいバージョンのデプロイメント・マネージャーに統合します。このような形式のマイグレーションがサポートされるのは、
バージョン 7.0 以降 のノードのみです。
- まず、デプロイメント・マネージャーをバージョン 9.0 にマイグレーションします。デプロイメント・マネージャーは、ノードの最高バージョンのレベルでなければなりません。
- 次に、ノードを バージョン 7.0 以降 から新しい最新バージョンのデプロイメント・マネージャーに統合できます。
トラブルの回避 (Avoid trouble): インクリメンタル・マイグレーションのこの方法を実行すると、システムは混合セル環境になり、ノードはバージョン 9.0 のデプロイメント・マネージャーによって管理されます。マイグレーション計画には、最終的にすべてのノードのバージョン 9.0 レベルへのマイグレーションを含める必要があります。これによって一貫性のあるノードの管理ができるようになります。gotcha
既存の機能は、混合セル環境で引き続き使用できます。既存アプリケーション実行などの適切な操作や、addNode、混合クラスターの作成、システムの構成、Mbean の呼び出し、アプリケーションのデプロイなどの管理操作の実行ができます。混合セル環境の新機能サポートは、機能、優先度、および使用可能なリソースなどに基づいて個別に決まります。

クライアントがノード・エージェントと通信する際に問題が発生した場合、 あるいは新しいポート・データをクラスター・メンバーとノード・エージェントの間で伝搬する際に問題が発生した場合、 クライアントで要求が失敗する可能性があります。 これらの失敗は、一時的なものにすぎない場合もあります。 または、失敗を解決するために 1 つ以上のプロセスの再始動が必要になるケースもあります。
このような場合に発生する可能性があるクライアントのルーティング問題を回避するためには、 クラスター・メンバーで静的ポートを構成するようにします。 静的ポートを構成すると、 クライアント・プロセスがクラスター・メンバーに関する情報を取得する際にポート・データが変わることはありません。 クラスター・メンバーが再始動された場合や、 プロセス間で通信あるいはデータ伝搬の問題が発生した場合でも、クライアントが保持しているポート・データは引き続き有効です。 この回避策によって、 必ずしも通信やデータ伝搬の根本的な問題が解決されるわけではありませんが、 クライアントにより予期しないあるいは不規則なルーティングが決定される症状は回避されます。
gotchaWebSphere Application Server の旧バージョンのマイグレーションも共存も行わない場合は、以前のインストールを無視することになり、デフォルトのポート割り当てが競合しているために、一度に 1 つのバージョンのみを実行できます。一方のバージョンでデフォルト以外のポートを使用する場合には、両方のバージョンを競合させることなく同時に実行することができます。
FAQ (よくある質問)
WebSphere Application Server for z/OS® バージョン 9.0 の新しいデータ・セットを指すだけで、サーバーを再始動してもよいですか?
いいえ。WebSphere Application Server for z/OS バージョン 9.0 では、バージョン 7.0 以降 の構成を、バージョン 9.0 レベルにマイグレーションする必要があります。
マイグレーションは、ノードごとのアクティビティーですか?
はい。構成をマイグレーションするプロセスでは、構成内のノードごとに、 提供されているユーティリティーを実行します。
スタンドアロン・アプリケーション・サーバーの場合はノードが 1 つだけですが、そのノードもマイグレーションする必要があります。その手順は、デプロイメント・マネージャーが実行中である必要がないことを除けば、他のノードをマイグレーションする場合の手順と基本的に同じです。 スタンドアロン・アプリケーション・サーバー・ノードをマイグレーションするためのアクティビティーのチェックリストについては、z/OS スタンドアロン・アプリケーション・サーバーのマイグレーション: チェックリストを参照してください。
マイグレーション・ユーティリティーは何を行うのでしょうか?
マイグレーション・ユーティリティーは、以下の目的で使用します。
ユーティリティー | 目的 |
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 構成を含めるために既存のファイル・システムを使用する場合は、このジョブを実行しないで、マイグレーション定義の作成時に指定したマウント・ポイントを手動で作成し、そのファイル・システムがマウントされていることを確認する必要があります。いずれの場合も、マイグレーションを進める前に、構成ファイル・システムとマウント・ポイントを作成し、 ファイル・システムをマウントしておく必要があります。 |
スタンドアロン・アプリケーション・サーバー・マイグレーションの場合は以下のユーティリティー:
デプロイメント・マネージャー・マイグレーションの場合は以下のユーティリティー:
統合ノード・マイグレーションの場合は以下のユーティリティー:
|
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 以降 のノードと通信できますか?
マルチノード・マイグレーションを実行するには順序がありますか?
WebSphere Application Server for z/OS バージョン 9.0 のセルと、 バージョン 7.0 以降 のセルは共存できますか?