WebSphere Application Server Network Deployment, Version 6.0.x   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows

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

コア・グループのマイグレーションに関する考慮事項

HA マネージャーとコア・グループ機能は、WebSphere Application Server バージョン 6 以降に搭載されています。 このトピックでは、 この機能を持たない WebSphere Application Server の バージョン (バージョン 5.1 など) からマイグレーションする場合に、 マイグレーションに影響を与えるコア・グループの構成、 およびトポロジーに関する考慮事項について説明します。

この項目をお読みになる前に、 以下のトピックに記載されている、 基本的なコア・グループの概念を理解する必要があります。

HA マネージャーのない WebSphere Application Server の バージョンから、HA マネージャーのある バージョンへのマイグレーションを行う場合、 特別な計画とマイグレーションの活動が、 ご使用の環境に対して必要になるため、 あらかじめ以下の疑問に対する回答を認識しておく必要があります。

デフォルト・コア・グループに関連する、マイグレーション・アクティビティー

コア・グループ関連のアクティビティーは、 マイグレーション・プロセスにおいて自動的に実行されるので、 比較的単純で簡単です。 バージョン 5.x 環境から バージョン 6.x 環境へマイグレーションする場合は、 以下のアクションが指定された順序で発生します。
  1. デプロイメント・マネージャーが、バージョン 6.x にマイグレーションされます。
  2. マイグレーション・プロセスにおいて、 バージョン 6.x デプロイメント・マネージャー・プロファイル と、DefaultCoreGroup という名前のコア・グループが作成されます。
  3. 新規デプロイメント・マネージャー・プロセスが、DefaultCoreGroup に追加されます。
  4. バージョン 5.x ノードが、1 つずつ バージョン 6.x へマイグレーションされます。 各ノードがマイグレーションされる際に、 マイグレーションするノード上のノード・エージェントと アプリケーション・サーバーが、DefaultCoreGroup に追加されます。

マイグレーションが終了すると、 バージョン 5.x セル内のすべてのプロセスが、 バージョン 6.x DefaultCoreGroup のメンバーになります。 DefaultCoreGroup は、 すべての設定に対してデフォルト値を持つように構成されるため、 マイグレーション・プロセスでは、 優先コーディネーター・サーバーが構成されず、 コーディネーターが複数のサーバー間で、 パーティションで区切られることはありません。 マイグレーション・プロセスでは、新規 HA ポリシーは作成されません。 また、カスタム・プロパティー構成のオーバーライドも行われません。

コア・グループ・トポロジーの計画

ほとんどのバージョン 5.x トポロジーが、 デフォルト・マイグレーションによって、 適切かつ実用的なバージョン 6.x コア・グループ・トポロジーになります。 場合によっては、 デフォルト以外のトランスポートの設定や、 複製用のコア・グループの構成などの小規模な変更を、 トポロジーに対して行う必要があります。 バージョン 5.x セルが、 バージョン 6.x トポロジーで 複数のコア・グループを必要とするくらいの大きさであれば、 マイグレーション・プロセスを開始する前に、 コア・グループ構成の変更時に アプリケーションの障害が発生しないよう、 さらに計画を練る必要があります。

大規模なバージョン 5.x セルを バージョン 6.x へマイグレーションするには、 複数のコア・グループが必要になるため、 複雑なタスクになる可能性があります。 バージョン 6.x トポロジーで 複数のコア・グループが必要な場合は、 セルをパーティションで区切って、 複数のコア・グループにする方法と時期に関して、 いろいろなオプションを使用できます。 使用する方法については、 セル内のプロセスの数や、 アプリケーションの連続可用性の要件などの要素に 基づいて決める必要があります。 例えば、コア・グループを約 50 のメンバーに保つことを、 通常は推奨されますが、 実用的な限度は 50 を少し超える程度になります。 ハイエンド・マシン (高性能の CPU と大容量のメモリーを持つもの) に、 小数のアプリケーションがインストールされているトポロジーの場合は、 最大で 200 までのメンバーを含むコア・グループを持つことができます。 セル内に 150 のプロセスがあり、 アプリケーションの可用性に問題がない場合は、 オプションを 1 つ使うだけで、 セル全体をバージョン 6.x にマイグレーションして、 追加のコア・グループを作成することができます。 アプリケーションの可用性に問題がある場合は、 マイグレーション・プロセス中に 追加のコア・グループを作成する必要があります。 これにより、マイグレーション・プロセスの完了後に、 コア・グループ・メンバーを停止して、再始動する必要がなくなります。

コア・グループのサイズ
計画における最も重要な考慮事項は、コア・グループのサイズです。 デフォルトでは通常、セル当たり 1 つのコア・グループがあります。 コア・グループのサイズを大きくすることはできないため、 バージョン 5.x セルが大規模である場合は、 使用するバージョン 6.x トポロジー用に、 追加のコア・グループを作成する必要があります。 これらの複数のコア・グループが互いに通信する必要がある場合は、 コア・グループ・ブリッジをセットアップすることも必要です。
コア・グループ・トランスポート
コア・グループ・トランスポート構成に変更を加える場合は、 すべてのコア・グループ・メンバーを再始動してから、 変更を有効にする必要があります。 したがって、トランスポート変更の効果を最小化するための計画が必要です。 DefaultCoreGroup のトランスポートを変更する場合、 変更を行う最適な時期は、デプロイメント・マネージャーのマイグレーション直後です。 その時点であれば、デプロイメント・マネージャーだけを再始動すればよいからです。 他のコア・グループを作成する場合は、 コア・グループの新規作成時に、 トランスポートを適宜構成する必要があります。
カスタム・プロパティー構成のオーバーライド
複数のコア・グループ構成パラメーターを、 カスタム・プロパティーのオーバーライドによって変更できます。 使用可能なカスタム・プロパティーのオーバーライドについては、 このセクションの他のインフォメーション・センターの項目に記載されています。

カスタム・プロパティーのオーバーライドが追加、除去または変更されるたびに、 すべてのコア・グループ・メンバーを再始動して、変更を選出する必要があります。 したがって、カスタム・プロパティー変更の影響を最小化するための計画が必要です。 DefaultCoreGroup のカスタム・プロパティーを変更する場合、 変更を行う最適な時期は、デプロイメント・マネージャーのマイグレーション直後です。 他のコア・グループを作成する場合は、 コア・グループの新規作成時に カスタム・プロパティーを変更する必要があります。

コア・グループ・コーディネーター
優先コーディネーター・サーバーを構成することが、 ベスト・プラクティスになります。 HA マネージャーは、コア・グループ・コーディネーター構成の変更を、 動的に再読み取りして適用できるため、 この変更を選出するために、 必ずしもすべてのコア・グループ・メンバーを再始動する必要はありません。

例: 大規模なセルのマイグレーション

大規模なバージョン 5.x セルからバージョン 6.x へのマイグレーション (複数の コア・グループが必要) を計画する際にたどるべき思考プロセスを、次の例で紹介します。 この例では、ご使用のバージョン 5.x セルに、 以下のようなトポロジー上の特性があることを前提とします。

バージョン 6.x コア・グループ・トポロジーの計画において 最初に考慮すべきことは、このセルに 325 のプロセスを組み込むということと、 アプリケーションの連続可用性が要件であるということです。 これらの要素があるために、 単純にセル全体をマイグレーションしてから、 コア・グループを再構成するというわけにはいきません。 セルに含まれているプロセスを、 マイグレーション・プロセスの一部として、 複数のコア・グループ間に分散させる必要があります。

V5.x セル・プロセスを 新規コア・グループ間に分散させる方法を決定するには、 以下のコア・グループに関するルールに、 各コア・グループが従っていることを確認してください。

このルールに従った場合、この例では、次のようになります。
  • 少なくとも、このコア・グループの いずれかに、2 つのクラスターが含まれている必要があります。 最大で 9 つのコア・グループにしか セルは分割できないのに対して、V5.x セルには 10 の クラスターがあるからです。
  • 複数のクラスターが含まれている コア・グループのいずれかが、50 を超えるメンバーを持つことになります。 各クラスターに、28 または 32 の アプリケーション・サーバーが含まれているからです。

少なくとも 1 つのコア・グループ内のメンバーの数が、 推奨される限度を超えてしまいますが、 メンバーの数は実用的な限度に十分収まっていますので、 問題は生じないはずです。

この例におけるアプリケーションは、 セルに含まれているクラスターごとに WLM ルーティング情報を必要とするため、 コア・グループ・ブリッジをセットアップして、 すべてのコア・グループ間で通信を可能にする必要があります。 (コア・グループ・ブリッジのセットアップ方法の詳細については、 コア・グループ・ブリッジのトピックを参照してください。) この例における適切なコア・グループ・ブリッジのトポロジーは、次のとおりです。

コア・グループ・ブリッジ・インターフェース用の セットアップも決まりましたので、 これで 8 つのコア・グループ間で、10 のクラスター、8 つの ノード・エージェント、8 つのスタンドアロン・ブリッジ・インターフェース・サーバー、 およびデプロイメント・マネージャーを分散させる方法を決定する準備ができました。 8 つのコア・グループ間で、 できるだけ均等にプロセスを分散させる必要があります。 次のトポロジーは、V5.x セルに含まれているプロセスを、 均等に分散させる方法の良い例です。

  • 最初のコア・グループ DefaultCoreGroup には、 デプロイメント・マネージャー、Node1 の ノード・エージェント、Node 2 のブリッジ・サーバー、 および Cluster1 が含まれています。
  • コア・グループ 2 には、Node2 の ノード・エージェント、Node3 のブリッジ・サーバー、 および Cluster2 が含まれています。
  • コア・グループ 3 には、Node3 の ノード・エージェント、Node4 のブリッジ・サーバー、 および Cluster3 が含まれています。

この例のデフォルト・トランスポートは、変更する必要はありません。

この例は、コア・グループごとに 複数のコーディネーターを必要とするとは説明していないので、 コーディネーターの設定はデフォルト値 1 のままでかまいません。 しかし、各コア・グループに含まれる スタンドアロン・ブリッジ・インターフェース・サーバー、 すなわち、そのコア・グループ用の優先コーディネーター・サーバーを 作成する必要があります。 この指定により、まずコーディネーターが必要とするワークロードが、 アプリケーションを実行する クラスター化アプリケーション・サーバーから分離されます。

使用するマイグレーション計画

前述の例を検討し、 マイグレーションするセルの初期計画プロセスを完了した後で、 デフォルトのマイグレーション・フローが、 目標とするバージョン 6.x トポロジーに適さないと判断した場合は、 実際のマイグレーション・プロセス用に、 計画またはロードマップの開発を行います。 この計画には、バージョン 5.x からバージョン 6.x への マイグレーション手順に関連した、 すべての必要な追加コア・グループと、 以下の疑問に対する回答が含まれている必要があります。

新規コア・グループを作成するのはいつか?
新規コア・グループを作成するのに最適な時期は、 デプロイメント・マネージャーのマイグレーションが完了した直後です。 新規コア・グループの作成時に、 前述のカスタム・プロパティーを構成してください。 管理コンソールまたは createCoreGroup wsadmin コマンドの いずれかを使用して、新規コア・グループを作成できます。 ただし、カスタム・プロパティーを構成する場合は、 管理コンソールを使用する必要があります。
ノードをマイグレーションする際に、行うべきことは何か?
ノードをマイグレーションする際には、以下のことを行う必要があります。
  • コア・グループ・ブリッジ・インターフェースの 1 つとして使用する、 新規スタンドアロン・アプリケーション・サーバーを作成します。
  • ノード上のすべてのプロセスにおける、 トランスポート・バッファー・サイズを調整します。 このアクションを実行するのに最適なオプションは、スクリプトです。
  • ノード・エージェントとスタンドアロン・サーバーのヒープ・サイズを調整し、 これらのプロセスの冗長 GC をオンにします。
マイグレーション済みノードを再始動する前に、 これらの変更をすべて完了する必要があります。 管理コンソールを使用すると、 これらの変更を行い、ノード構成を手動で同期化してから、 ノード・エージェントとアプリケーション・サーバーを再始動することができます。
いつ、どのようにプロセスを新規コア・グループに移動するのか?
デフォルトでは、マイグレーション・プロセスによって、 すべてのプロセスが DefaultCoreGroup という名前の コア・グループに入れられます。 ある時点で、このコア・グループに含まれるメンバーの数が サイズ制限を超えると、 プロセスを他のコア・グループに再配分する必要があります。 プロセスを移動する前に、 そのプロセスを停止しておく必要がありますので、気をつけてください。 アプリケーションを連続して使用する必要がある場合は、 プロセスを異なるコア・グループに移動する順序を、 慎重に計画する必要があります。

管理コンソールまたは moveServerToCoreGroup wsadmin コマンドの いずれかを使用して、デプロイメント・マネージャー、ノード・エージェント、 およびスタンドアロン・アプリケーション・サーバーを移動することができます。

クラスター化アプリケーション・サーバーの移動は、より複雑になります。 通常の環境であれば、管理コンソール または moveServerToCoreGroup wsadmin コマンドのいずれかを使用して、 クラスターを移動します。 しかし、マイグレーション・プロセス中は、 移動するクラスターにバージョン 6.x と バージョン 5.x の両方のメンバーが含まれているため、 通常のコマンドは失敗します。 これは、バージョン 5.x のクラスター・メンバーが、 まだいずれのコア・グループのメンバーにもなっていないためです。 混合クラスターを新規コア・グループに 移動するには、moveClusterToCoreGroup wsadmin コマンドに、 オプションの checkConfig パラメーターを指定して使用する必要があります。

重要: このパラメーターは、バージョン 6.0.2.9 Service Pack で追加されました。 したがって、マイグレーション・プロセスを開始する前に、 この Service Pack がバージョン 6.0.x システムに インストールされていることを確認する必要があります。
例えば、クラスター・メンバー A、B、C、D が、Cluster0 にいるとします。 メンバー A は、バージョン 6.x にマイグレーション済みの ノード上にあり、DefaultCoreGroup のメンバーです。 一方、B、C、D は、まだバージョン 5.x ノード上にあります。 Cluster0 をコア・グループ CG1 に移動するには、次のコマンドを使用してください。
$AdminTask moveClusterToCoreGroup {-source CoreGroup1 –target CG1 –clusterName Cluster0 –checkConfig false}

マイグレーション・ユーティリティーは、 バージョン 6.0.2.9 Service Pack において、 より簡単にクラスターの移動が行えるよう変更されました。 クラスター化アプリケーション・サーバーがマイグレーションされると、 マイグレーションによって、他のクラスター・メンバーが すでにマイグレーション済みであるかどうかが判別され、 マイグレーションするメンバーが 他のクラスター・メンバーと同じコア・グループに入れられます。

前述の例では、メンバー A がコア・グループ CG1 に移動されました。 B、C、D を含むノードがマイグレーションされると、 マイグレーションによってこれらのクラスター・メンバーが、DefaultCoreGroup では なく CG1 に入れられます。 したがって、moveClusterToCoreGroup コマンドは、 各クラスターに対して一度だけ実行することが必要です。

コア・グループ・ブリッジは、いつ構成する必要があるか?
複数のコア・グループにプロセスを移動するときまでに、 コア・グループ・ブリッジを構成し、実行する必要があります。 つまり、バージョン 6.x のターゲット・トポロジーで、 ブリッジ・インターフェースとして使用するプロセスが、 バージョン 5.x ノードからマイグレーションされていないため、 最初に必要なときに使用できない、ということです。 したがって、アプリケーションを連続して使用できるようするには、 一部のクラスター化アプリケーション・サーバーを、 マイグレーション中に使うブリッジ・インターフェースとして、 一時的に構成する必要があります。 すべてのプロセスがバージョン 6.x にマイグレーションされた後に、 必要なバージョン 6.x トポロジーに合わせて、 コア・グループ・ブリッジ構成を調整することができます。

計画に関するその他の考慮事項

ターゲットのバージョン 6.x 構成で、 複数のコア・グループ・ブリッジが必要な場合は、 バージョン 6.0.2.9 Service Pack が システムにインストールされていることを確認する必要があります。 この Service Pack には、 スケーリングの改善が組み込まれており、IBM_CS_WIRE_FORMAT_VERSION という コア・グループのカスタム・プロパティーを使用して、 インプリメントすることができます。

また、すべてのコア・グループがまとめてブリッジされ、 ルーティングによって情報が互いに共用される場合、 コア・グループ・メンバー間で共用されるデータの量は、 通常よりはるかに多くなります。 したがって、データをさらに効率よく転送するために、 以下の設定を使用して、 コア・グループのメモリー設定を増やす必要があります。

ブリッジ・インターフェースとして使用する ノード・エージェントまたはアプリケーション・サーバー、 およびコーディネーターとして使用するスタンドアロン・サーバーの、JVM ヒープ・ サイズなどの要素を調整することも考慮する必要があります。 ヒープ・サイズを 512 メガバイトに増やすことから始めることを、お勧めします。 また、これらのヒープ・サイズを長期間詳細に調整できるように、 これらのプロセスに対して冗長 GC モニターをオンにすることもできます。

可能なマイグレーション・フロー

正常なマイグレーションを行うために 実装できるマイグレーション・フローは、数多くあります。 デプロイメント・マネージャーのマイグレーションが完了し、 コア・グループも作成されたが、 その後のアクションがまだ実行されていない、 というよくある状況から、 以下のフローを開始することにします。

マイグレーション・フロー 1
このフローでは、以下のルールを厳守してください。 このフローは、いくつかの理由から不十分なものとなっています。 各ノードがマイグレーションされる際に、クラスターを移動する必要があります。 この場合、すべてのクラスター・メンバーを停止する必要があります。 これにより、アプリケーションが使用できなくなることがあります。 さらに、各ステップでブリッジを再構成する必要があります。
  • Node1 をマイグレーションします。 DefaultCoreGroup には、 デプロイメント・マネージャーと Node1 からのすべてのノードが含まれています。 DefaultCoreGroup に含まれているメンバーは 50 未満であるため、 これ以上のアクションは必要ありません。
  • Node2 をマイグレーションします。 現在、DefaultCoreGroup には、 推奨される数を超えるプロセスが含まれています。 クラスターの半分と Node2 のノード・エージェントを、CoreGroup2 に 移動することにより、2 つのコア・グループ間で プロセスのバランスを取ります。 現在、複数のコア・グループが使用されているため、 コア・グループ・ブリッジを構成する必要があります。 ノード Node1 と Node2 に、 ブリッジ・インターフェース・サーバーを作成します。 コア・グループ・ブリッジを構成して、2 つのコア・グループを一緒にブリッジします。
  • Node3 をマイグレーションします。 DefaultCoreGroup と CoreGroup2 から CoreGroup3 に、 一部のクラスターを移動することにより、3 つの コア・グループ間でプロセスのバランスを取ります。 Node3 のノード・エージェントを、CoreGroup3 に移動します。 ブリッジ・インターフェース・サーバーを、Node3 に作成します。 コア・グループ・ブリッジを再構成して、3 つのコア・グループを一緒にブリッジします。
  • マイグレーションが完了するまで、ノードのマイグレーションを続行します。 各ノードをマイグレーションする際に、 コア・グループ・ブリッジのバランスの取り直しや再構成が、 ある程度必要になる場合があります。
マイグレーション・フロー 2
このフローでは、ルールに違反したことを一時的に行います。 このフローでは、異なるコア・グループに移動する際に、 実行中のアプリケーション・サーバーを停止する必要がないため、 より良い結果になります。 マイグレーションの進行中、 一部のコア・グループに、 ある期間管理プロセスが含まれなくなります。 これは、技術的にはルール違反となりますが、 マイグレーションの進行中にコア・グループ構成が変更されない限りは、 許容されます。
  • Node1 をマイグレーションします。 Node1 には、Cluster10 を除く、 すべてのクラスターのメンバーが含まれています。
  • 移動可能なすべてのクラスターを、 最終ターゲット・トポロジー内の 識別されたコア・グループに移動します。 デプロイメント・マネージャー、Node1 の ノード・エージェント、および Cluster1 は、 すでに DefaultCoreGroup 内にあるため、 それ以上のアクションは不要です。 Cluster2 を CoreGroup2 に、Cluster3 を CoreGroup3 に、 というように、それぞれ移動します。 Node1 のブリッジ・サーバーを作成し、 それを CoreGroup2 に配置します。
  • コア・グループ・ブリッジを構成して、8 つの コア・グループすべてを一緒にブリッジします。 わかりやすくするために、アクセス・ポイントごとに、 単一のブリッジ・インターフェースを一時的に構成します。 (これにより、マイグレーションの進行中に、Single Point of Failure が導入されます。) 最終的なトポロジーのブリッジ・インターフェースのほとんどが、 まだバージョン 5.x であるため、8 つのコア・グループの うち 6 つで、アプリケーション・サーバーを 一時的にブリッジ・インターフェースとして使用する必要があります。 この場合、選択したアプリケーション・サーバーのヒープ・サイズを、 一時的に増やす必要があります。
  • Node2 をマイグレーションします。 マイグレーションによって、Node2 の クラスター化アプリケーション・サーバーが、 適切なコア・グループに自動的に移動します。 Cluster10 は、Node1 上に アプリケーション・サーバーを持たないため、 手動で Cluster10 を CoreGroup8 に移動します。 Node2 のノード・エージェントを、CoreGroup2 に移動します。 ブリッジ・サーバーを、Node2 に作成します。 オプションで、 一時的なブリッジ・インターフェース・サーバーを Node2 上に配置して、 両方のノード間でロードを拡散できるように、 コア・グループ・ブリッジを再構成することができます。
  • すべてのノードがマイグレーションされるまで、 同じパターンを使用してノードのマイグレーションを続行します。
  • すべてのノードがマイグレーションされたら、 優先コーディネーター・サーバーを構成します。 最終的なターゲット・トポロジー (アクセス・ポイントごとに 2 つの ブリッジ・インターフェース・サーバーを持つトポロジー) に合わせて、 ブリッジ・インターフェースを再構成します。 一時的にブリッジ・インターフェースとして機能するサーバーを停止して、 再始動します。 新規ブリッジ・インターフェース・サーバーを再始動します。
マイグレーション・フロー 3
このフローは、フロー 2 の変形になります。 このフローは、フロー 2 の変形であることに注意してください。 利点として、初期ブリッジのロードが、1 つの ノードではなく、3 つのノード間で分散されるすることが挙げられます。 ただし、Node3 のマイグレーション後に、 コア・グループへのクラスターの初期再配分が行われてしまう、 という欠点があります。 この場合、移動を行うために、ノード Node1 と Node2 上で 稼働しているサーバーを停止する必要があります。 これにより、アプリケーションの可用性が影響を受ける場合があります。
  • Node1 をマイグレーションします。 このステップが完了すると、DefaultCoreGroup に 38 の プロセス (限度内の値です) が組み込まれます。
  • Node2 をマイグレーションします。 このステップが完了すると、DefaultCoreGroup に 79 のプロセスが組み込まれます。 これは、推奨されるサイズを超えていますが、まだ実用的な限度内に収まっています。
  • Node3 をマイグレーションします。 すべてのクラスターを、最終トポロジー内の識別されたコア・グループに移動します。 Cluster2 を CoreGroup2 に、Cluster3 を CoreGroup3 に、 というように、それぞれ移動します。 3 つのノード・エージェントを、適切なコア・グループに移動します。 3 つのブリッジ・インターフェース・サーバーを作成して、 それらを適切なコア・グループに移動します。
  • 指定のブリッジ・インターフェースがまだ含まれていない コア・グループに対して、一時的なブリッジとして機能させる、 クラスター化アプリケーション・サーバーを選択します。 これらのサーバーのヒープ・サイズを、一時的に調整します。 コア・グループ・ブリッジを構成して、8 つの コア・グループすべてを一緒にブリッジします。
  • すべてのノードがマイグレーションされるまで、 ノードのマイグレーションを続行します。
  • すべてのノードがマイグレーションされたら、 優先コーディネーターを構成します。 最終的なターゲット・トポロジーに合わせて、 ブリッジ・インターフェースを再構成します。 必要に応じて、プロセスを停止してから再始動します。



関連概念
HA マネージャー
HA マネージャーを使用する時期
コア・グループ・コーディネーター
コア・グループ・トランスポート
コア・グループ管理についての考慮事項
コア・グループのスケーリングについての考慮事項
コア・グループ View Synchrony Protocol
コア・グループ (高可用性ドメイン)
関連タスク
新規コア・グループ (高可用性ドメイン) の作成
コア・グループ・コーディネーター数の変更
コア・グループ優先コーディネーターの構成
HA マネージャーの使用不可化と使用可能化
コア・グループ・メンバーの移動
概念トピック    

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

最終更新: Jan 21, 2008 10:13:28 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/crun_ha_cgmigration.html