このセクションでは、バージョン 2.1 からバージョン 6.0 へのマイグレーションを実行するためのさまざまな方法を説明します。
マイグレーション作業を実行する前に、以下の決定を行う必要があります。
- 製品コンポーネントをマイグレーションする方法を決定します。
- バージョン 6.0 の新機能について調べます。
これらの新規および変更された機能は、今後、マイグレーション済みのコンポーネントを使用する方法に影響を与える場合があります。
- 製品コンポーネントをマイグレーションする場所を決定します。同じコンピューターまたは 2 番目のコンピューターにコンポーネントをマイグレーションしてください。
例えば、コンポーネントを別の場所にマイグレーションして、マイグレーション中に可用性を維持することもできます。
- 製品コンポーネントをマイグレーションする時期を決定します。コード・レベル バージョン 2.1 で一部のコンポーネントを一時的に保存し、後でそれらをマイグレーションすることもできます。
- コンポーネントをマイグレーションする順序を決定します。
任意の順序でコンポーネントをマイグレーションできますが、特定の状況では、特定の順序でコンポーネントをマイグレーションする必要がある場合もあります。
バージョン 6.0 を同じコンピューター上でバージョン 2.1 と共存させる方法、およびバージョン 6.0 コンポーネントを バージョン 2.1 のコンポーネントと共に機能させる方法について詳しくは、以前のバージョンおよび他の製品との共存を参照してください。
- 既存のリソースを WebSphere
Message Broker バージョン 6.0 と共に使用する方法を決定します。
mqsimigratemsgflows コマンド およびmqsimigratemsgsets コマンドを使用して、バージョン 2.1 メッセージ・フロー、 メッセージ・セット、およびユーザー定義の拡張機能をマイグレーションします。
マイグレーションした バージョン 2.1 ユーザー定義の拡張機能のいずれかのツール部分は、バージョン 6.0 で再書き込みされる必要があります。
バージョン 6.0 で使用するユーザー定義の拡張機能を決定し、それらをバージョン 6.0 ツール内で再作成します。
バージョン 6.0 Message Brokers Toolkit でリソースの使用を開始した後、再びバージョン 5.0 またはバージョン 5.1 Message Brokers Toolkit でこれらの同じリソースを使用することについては制約があります。
詳しくは、以前のバージョンの Message Brokers Toolkit でのマイグレーション済みリソースの使用の条件を参照してください。
- マイグレーションが正常に行われることを確認するテストを実行する必要があるかどうか決定します。
実動ドメインをマイグレーションする前に開発ドメインおよびテスト・ドメインをマイグレーションすることによって、問題を識別し、さらに問題が生じた場合にそれに対処するための戦略を開発することができます。
- マイグレーションする準備ができたら、-c パラメーターを使用して mqsimigratecomponents コマンドを実行します。 これにより、マイグレーションが可能であることを確認するために、バージョン 2.1 コンポーネントに対するマイグレーション前のチェックが実行されます。
マイグレーション前のチェックによって、潜在的な問題を識別し、マイグレーションに進む前にそれらを訂正することができます。
保存するキュー・マネージャーの構成をマイグレーション中に変更する必要はありません。
このセクションの他のトピックでは、以下のさまざまなマイグレーション・シナリオに関する説明が提供されます。