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

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

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

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

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

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

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

マイグレーション戦略

マイグレーションを計画する際に考慮する必要のあるマイグレーション戦略には以下のものがあります。
標準マイグレーションおよび複製マイグレーション
  • 標準: ソース構成は、ターゲット構成にマイグレーションされた後は使用不可になります。
  • 複製: ソース構成は、ターゲット構成にマイグレーションされた後も機能し続けます。
ローカル・マイグレーションおよびリモート・マイグレーション
  • ローカル: 構成は同じマシン上でマイグレーションされます。複製マイグレーションの場合は 2 つの環境が共存する結果になります。
  • リモート: 構成は新しいマシンにマイグレーションされます。

マイグレーション・ツール

製品構成をマイグレーションするために使用するツールは、 ターゲット・リリースの新規インストール済み環境から実行する必要があります。可能な場合は、マイグレーションを始める前に、新規インストール済み環境を更新して最新の使用可能なフィックスパックが適用された状態にしてください。 WebSphere Application Serverバージョン 9.0 マイグレーション・ツールでサポートされるのはバージョン 7.0 以降からのマイグレーションのみであり、同じリリース内でのマイグレーション (例えば、バージョン 9.0 からバージョン 9.0 へのマイグレーション) はサポートされません。同じバージョンまたはリリースのマシン間で構成を複製する場合は、 プロパティー・ベースの構成についての説明を参照するか、または、 AdminTask オブジェクトに対する ConfigArchiveOperations コマンド・グループの wsadmin スクリプト exportWasprofile コマンドを使用してください。

マイグレーションでは主に以下のコマンド・ライン・ツールが使用されます。
WASPreUpgrade
古いインストール済み環境からソース・プロファイルのスナップショットを作成し、それをバックアップ・ディレクトリーに入れます。リモート・マイグレーションの場合、WASPreUpgrade コマンドは追加の成果物を収集し、それらはバックアップ・ディレクトリー内の構成によって参照されます。
manageprofiles
ターゲット・プロファイルを作成します。ターゲット・プロファイルはソース・プロファイルと同じタイプでなければなりません。 例えば、デプロイメント・マネージャー・プロファイルをスタンドアロン・アプリケーション・サーバー・プロファイルにマイグレーションすることはできません。プロファイルのタイプに応じて、 ソース・プロファイルのセル名、ノード名、またはその両方を一致させることも必要です。
WASPostUpgrade
マイグレーション・バックアップ・ディレクトリー内のデータをターゲット・プロファイルにマージします。追加オプションを指定して、古い構成を使用不可にするかどうか、アプリケーションのインストールを延期するかどうかなどを制御できます。

構成マイグレーション管理ツール (マイグレーション・ウィザードとも呼ばれる) はグラフィカル・ユーザー・インターフェース (GUI) ツールであり、 これを順に操作していくと上記のコマンド・ライン・ツールを実行できるようになっています。

構成マイグレーション・ツールは、 ソース・プロファイルに存在していたとおりにアプリケーションをターゲット・プロファイルにデプロイします。構成をマイグレーションする前に、非実稼働 WebSphere Application Server バージョン 9.0 環境でアプリケーションをテストしてください。その後、 その環境で実行することを確実にするために必要な変更をアプリケーションに加えます。必要な変更を迅速に特定するために、 Migration Toolkit for Application Binaries および WebSphere Application Server Migration Toolkit を使用してアプリケーションをスキャンすることができます。詳しくは、WASdev の Migration Toolkit を参照してください。

WASPostUpgrade コマンドでインストールされなかったアプリケーションをインストールするために、WASMigrationAppInstaller コマンドを必要なだけ何度でも実行することができます。

リモート・マイグレーションの場合、createRemoteMigrJar コマンドを使用して .jar ファイルを作成することができ、そのファイルを使用すると、WebSphere Application Server がインストールされていないシステムで WASPreUpgrade コマンドを実行できます。

マイグレーション・ツールを使用して、製品構成のマイグレーションに説明されているように、 アプリケーションと構成情報を新規バージョンにマイグレーションします。 詳しくは、マイグレーション・ツールの使用を参照してください。

混合セル環境

セルには、異なるバージョンの 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 つのバージョンのみを実行できます。一方のバージョンでデフォルト以外のポートを使用する場合には、両方のバージョンを競合させることなく同時に実行することができます。

マイグレーションに関する潜在的な問題

マイグレーションまたは共存のシナリオでは、次の問題点を検討してください。
  • 同一の Web サーバーを共有しようとした場合の、コンテキスト・ルートの競合。

    Web サーバー構成のマイグレーションで説明されている手順に従って、WebSphere Application Server の複数のバージョンで Web サーバーを共有する場合の構成方法を習得してください。

  • デプロイメント・マネージャーがルート以外として実行するように構成された場合、 root 以外の構成から root へのマイグレーションの説明に従って、 WASPostUpgrade コマンドの実行後にデプロイメント・マネージャー・ディレクトリーの所有権とファイル許可を変更します。

    この作業は、WebSphere Application Serverバージョン 9.0 のデプロイメント・マネージャーを開始する前に完了する必要があります。

    詳しくは、WASPostUpgrade コマンドを参照してください。

  • ノード・エージェントまたはアプリケーション・サーバーがルート以外として実行するように構成された場合、 root 以外の構成から root へのマイグレーションの説明に従って、 WASPostUpgrade コマンドの実行後にノード・ディレクトリーの所有権とファイル許可を変更します。

    この作業は、WebSphere Application Server バージョン 9.0 のノード・エージェントまたはアプリケーション・サーバーを開始する前に完了する必要があります。

    詳しくは、WASPostUpgrade コマンドを参照してください。

その他の情報

WebSphere Application Server バージョン 9.0 は、バージョン 7.0 以降 との共存が可能です。WebSphere Application Server の前のバージョンによっては、解決しなければならないポート競合が存在する場合があります。 詳しくは、共存アプリケーション・サーバーの実行およびポート設定の構成を参照してください。

WebSphere Application Server のマイグレーションでは、既存の構成とアプリケーションを活用し、それらを変更して、WebSphere Application Server バージョン 9.0 環境と互換性を持つようにします。既存のアプリケーション・コンポーネントと構成設定は、マイグレーション・プロセス中にバージョン 9.0 環境に適用されます。

WebSphere Application Server の旧バージョンを使用している場合、システム管理者により、さまざまなアプリケーションおよびサーバーの設定が、環境に応じて細かく調整されている可能性があります。これらの設定を最も効率よくマイグレーションするように戦略を立てることが重要です。

マイグレーション・ツールを複数回実行し、実行するごとに異なるプロファイルのセットを指定することにより、WebSphere Application Server バージョン 7.0 以降 の構成のインクリメンタル・マイグレーションを実行することができます。WebSphere Application Server をインクリメンタル・マイグレーションする場合は通常、オペレーティング・システムを混合セル・リリース環境で稼働します。この環境でのマイグレーションでは、さまざまなタイミングでノード・マイグレーションが実行されるため、マイグレーションが完了するまで長時間混合セルが実行される場合があります。


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



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