WebSphere Application Server Version 6.1 Feature Pack for Web Services   
             オペレーティング・システム: AIX , HP-UX, i5/OS, Linux, Solaris, Windows, Windows Vista, z/OS

             目次と検索結果のパーソナライズ化
             New or updated topic for this feature pack

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

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

マイグレーションおよび共存のためのフィーチャー・パックのルールと制限: WebSphere Application Server バージョン 6.1 フィーチャー・パックをインストール済みの場合、マイグレーションおよび共存のために以下のルールと制限が適用されます。

概要 [AIX HP-UX Linux Solaris Windows] [i5/OS]

WebSphere Application Server バージョン 6.1 は、 バージョン 5.x およびバージョン 6.0.x と共存できます。 WebSphere Application Server の前のバージョンによっては、 解決すべきポートの競合が存在する場合があります。 詳しくは、共存サポート およびポートの構成 を参照してください。

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

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

マイグレーション・ツールを複数回呼び出し、 呼び出すごとに異なるインスタンスまたはプロファイルのセットを指定することにより、 WebSphere Application Server バージョン 5.x または 6.0.x 構成のインクリメンタル・マイグレーションを実行することができます。

マイグレーションの主なステップは、以下のとおりです。
  1. WebSphere Application Server バージョン 6.1 の非実稼働環境でアプリケーションをテストし、 アプリケーションに必要な変更を加え、その環境で動作することを確認します。
  2. それらのアプリケーションと使用する構成を、バージョン 6.1 にマイグレーションします。

    このステップは、製品と同梱のマイグレーション・ツールを使用して実行できます。

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

[AIX HP-UX Linux Solaris Windows] マイグレーション・ウィザードは、 マイグレーション・ツールにグラフィカル・ユーザー・インターフェースを提供します。 マイグレーション・ウィザードでマイグレーション・ツールを呼び出すか、 マイグレーション・ツールを直接実行することができます。 マイグレーション・ウィザードを使用して製品構成をマイグレーションする を参照してください。

WebSphere Application Server バージョン 5.x または 6.0.x からバージョン 6.1 へのマイグレーションは、 かなり機械的に行われます。 このマイグレーションの重要な参照項目には、以下のようなものがあります。

WebSphere Application Server の旧バージョンのマイグレーションも共存も行わない場合は、 以前のインストールを無視することになり、デフォルトのポート割り当てが競合しているために、一度に 1 つのバージョン のみを実行できます。 旧バージョンでデフォルト以外のポートを使用する場合には、 両方のバージョンを競合させることなく同時に実行することができます。WebSphere Application Server バージョン 5.x または 6.0.x との共存をセットアップするには、 バージョン 6.1 インストールのプロファイル作成時に固有のポートを選択してください。 既存のバージョン 6.1 のインストールとの共存をセットアップするには、 インストール時に「Install a new copy of the V61 Application Server product」と示すラジオ・ボタンを選択します。

プロファイル作成時に共存のためにポート割り当てを指定するか、 wsadmin スクリプトを使用するか、 または管理コンソール・ページの「サーバー」>「アプリケーション・サーバー」>「server1」> 「ポート」を使用して、競合するポート割り当てを解決し、旧バージョンとともに WebSphere Application Server バージョン 6.1 を稼働できるようにすることが可能です。

Wsadmin ツール を参照してください。

共存処理により、次の構成ファイルが変更されます。
  • virtualhosts.xml
    • HTTP トランスポート・ポート
    • IBM HTTP Server ポート
    • HTTPS トランスポート・ポート
    • HTTP 管理コンソール・ポート
    • HTTPS 管理コンソール・セキュア・ポート
  • serverindex.xml
    • ブートストラップ・アドレス
    • SOAP コネクター・アドレス
    • DRS クライアント・アドレス
    • [この情報が適用されるのはバージョン 6.0.x と、バージョン 6.1 セルに統合された以前のサーバーだけです。] SAS SSL ServerAuth リスナー・アドレス
    • CSIV2 SSL ServerAuth リスナー・アドレス
    • CSIV2 SSL MutualAuth リスナー・アドレス
    • WC adminhost
    • WC defaulthost
    • DCS ユニキャスト・アドレス
    • WC adminhost secure
    • WC default secure
    • SIB エンドポイント・アドレス
    • SIB エンドポイント・セキュア・アドレス
    • SIB MQ エンドポイント・アドレス
    • SIB MQ エンドポイント・セキュア・アドレス

詳しくは、WebSphere Application Server バージョンにおけるポート番号設定 を参照してください。

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

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

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

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

    これは、WebSphere Application Server バージョン 6.1 デプロイメント・マネージャーを開始する前に行う必要があります。

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

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

    これは、WebSphere Application Server バージョン 6.1 ノード・エージェントまたはアプリケーション・サーバーを開始する前に行う必要があります。

  • WebSphere Application Server バージョン 6.1 デプロイメント・セルには、 バージョン 5.x または 6.0.x ノードの混合リリースを含むことができますが、 バージョン 6.0.0.x およびバージョン 6.0.1.x 用の混合ノード管理サポートはありません。
    バージョン 6.1 マイグレーション・ツールは、 これまでどおり、デプロイメント・マネージャーのマイグレーション時にこれらのノードをマイグレーションしますが、 バージョン 6.1 デプロイメント・マネージャーではノードを管理できないという警告メッセージが表示されます。 必要に応じて、以下のいずれかを実行できます。
    • すべてのバージョン 6.0.0.x およびバージョン 6.0.1.x ノードを、少なくともバージョン 6.0.2 にアップグレ ードします。 これにより、それらのノードをバージョン 6.1 デプロイメント・マネージャーで管理できるようになります。
    • 即時にこれらのノードをバージョン 6.1 にマイグレーションします。

FAQ (よくある質問) [z/OS]

新しい 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 プロシージャーが必要です。



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

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

最終更新: Jan 21, 2008 4:10:06 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.wsfep.multiplatform.doc/info/ae/ae/cmig_overview.html