マイグレーションの計画

マイグレーション計画と準備は、マイグレーション・プロジェクトを成功させるためのキーとなります。タイム・スケール、必要なツール、スキル、および知識を利用できるように、マイグレーションの複雑さを完全に理解することが不可欠です。

次の図は、移行の流れの概要を示している：

移行の複雑さの分類

初期段階では、マイグレーションの複雑さが推定されます。この複雑さの 1 つの側面は、ソース環境に基づいています。したがって、現在の NSX-V 環境の検討を行い、以下の詳細を理解するために文書化する必要があります。

論理ネットワーク・トポロジー - 外部ネットワーキングと内部ネットワーキングを文書化する一連のダイアグラム。
論理ネットワーキング構成およびセキュリティー構成 - NSX-V ネットワークおよびセキュリティーの構成で使用される詳細なパラメーター。論理スイッチ、ルーティング、分散ファイアウォール、エッジ・ファイアウォール、NAT、VPN、およびロード・バランシングが含まれます。
クラスターとホスト - クラスターとそのホストに関する情報。
ワークロード仮想マシン - VM の配置と、それらの相互関係。
統合 - Veeam®、 VMware Aria® Operations™ Manager、 VMware Aria® Automation™、カスタムスクリプト、その他のツールなど、 vCenter または NSX-V Manager と統合する外部ツール。

マイグレーションの複雑さには、以下の要因が影響します。

プロジェクト・ベースの要因 - スタッフが配置されているプロジェクトの状況など。
アーキテクチャー・ファクター - デプロイメント以降の既存の NSX-V 環境の変更など。
マイクロ・セグメンテーション・ファクター - 分散ファイアウォール・ルールの使用や、これらのルールでのタグ付けの使用など。
統合要因 - マイグレーションでこれらの両方のコンポーネントが置き換えられるため、どのシステムが NSX-V Manager および vCenter と統合されるか。統合システムには、 VMware Aria Automation、 VMware Aria Operations、 VMware Aria Orchestrator、SEIMまたはセキュリティツール、バックアップとリカバリ、レプリケーション、 F5、 vSRX, FortiGate,、その他のサードパーティ製ネットワークアプリケーションが含まれる。

詳しくは、移行の複雑さの評価を参照してください。

移行の複雑さを分類または評価することで、移行期間、必要なツール、スキル、知識を見積もることができ、最善の方法で準備するための指針が得られます。

必要なスキル

複雑さを評価する際は、スキルとリソースの可用性に重点を置く必要があります。以下を評価する必要があります。

既存のリソースが既存の職務を遂行している間に、マイグレーション・アクティビティーに参加する時間がある場合。
既存のリソースに、必要なタスクを正常に実行するために必要なスキル、知識、経験がある場合。

社内のスキルを補う必要があると考えられる場合は、できるだけ早くマイグレーション・サービス・プロバイダーに依頼することをお勧めします。

さらに、2 日目の運用を確実に成功させるために、利用可能な VMware Learning for NSX-T 教育を利用して、 VMware NSX-T™ のコアスキルを向上させてください。

マイグレーション・サービス・プロバイダーの関与

IBM カタログを通じて、PrimaryIO の経験豊富なプロフェッショナル・サービス・チームを引き付けることができます。詳細については、VMware クラウド移行サービスを参照してください。

PrimaryIO’s Fasttrack Migration Service は、NSX-V から NSX-T への移行を最適化するもので、クリティカルパスの目標に集中することで、継続的に進捗を促進する短期間のエンゲージメントを提供します。

ソース環境の複雑さのパターン

移行の複雑さの評価ステップの出力は、低、中、または高の複雑さのステータスです。

このステータスは、以下のように選択に役立てることができます。

ターゲット・プラットフォーム。
構成マイグレーション・パターン。
ワークロード・マイグレーション・パターン。
ネットワーク L2 拡張パターン。

複数のバリエーションがあるため、すべてのソース環境をきちんと分類することはできません。また、クライアント要件は、ルールのセットまたはパラメーターの定義済みセットによって、これらの 3 つのカテゴリーのいずれかになります。そのため、チーム全体で得られたコンセンサスを使用して分析アプローチを行う必要があります。

ターゲット・プラットフォーム

ソース環境の複雑さに基づいて、以下のターゲット・プラットフォームを考慮する必要があります。

単一サイト VMware VCF for Classic - Automated® インスタンス - 定義されたパターンでハードウェアとソフトウェアを展開する自動プロビジョニング機能。初期導入後、必要に応じて多くの自動ワークフローに容量と追加サービスを追加する必要がある。詳細は、VCF for Classic - Automated 概要を参照してください。 VCF for Classic - Automatedインスタンスのタイプには以下のものがあります：
- Regulated Workloads。詳しくは、VMware Regulated Workloads の概要を参照してください。
- セキュリティとコンプライアンスの準備バンドル。詳しくは、Security and Compliance Readiness Bundle の概要を参照してください。
マルチサイトまたはロケーション VCF for Classic - Automated インスタンス - VCF for Classic - Automated オファリングを複数のロケーションに配置して、マルチサイトまたはロケーション VCF for Classic - Automated インスタンスを作成できます。 VCF for Classic - Automated マルチサイト展開パターンとは、2つ以上のインスタンスを共通のルートドメインとシングル・サインオン・ドメインに展開し、 vCenters、Enhanced Link Modeを使用するものである。各サイトまたはロケーションには、独自の NSX-T インスタンスがあります。詳細は、VCF for Classic - Automatedインスタンスのマルチサイト設定を参照してください。

VCF for Classic - Automatedマルチゾーン提供は、現在非推奨です。詳細は、VCF for Classic - AutomatedマルチゾーンBOM を参照してください。

選択を有効にするために使用可能な以前のオファリングの比較について詳しくは、IBM Cloud のターゲット・プラットフォームを参照してください。

構成のマイグレーション

構成マイグレーションでは、NSX-V 環境の類似機能を提供するために NSX-T 環境に転送する必要があるすべての NSX-V 設定とパラメーターが対象となります。構成は、以下のいずれかの方法で適用できます。

手動またはスクリプト
VMware マイグレーション・コーディネーター
サード・パーティー・ツール

構成が単純な場合、またはルールまたは定義が多すぎない場合は、通常、手動またはスクリプトを使用して構成をマイグレーションするのが最も簡単な方法です。この方法に従うことの利点は、ターゲットがどのように構成されているかについての理解を深めることにもあります。設定が複雑な場合やファイアウォールルールが多い場合は、サードパーティツールの利用を検討し、重複する手作業を軽減する。

ワークロード・マイグレーション

構成マイグレーションの後、NSX-V 環境でマイグレーションを待機しているワークロード VM 間のレイヤー 3 接続またはレイヤー 2 接続を使用して、ワークロード VM をマイグレーションできます。また、NSX-T 環境にマイグレーションしたワークロード VM。ワークロードを NSX-V から NSX-T 環境にマイグレーションするには、以下のステップを考慮してください。

NSX-T オーバーレイと NSX-V オーバーレイをブリッジし、使用可能な L2 拡張メソッドを使用します。これにより、VM の個々のバッチまたは小さなバッチを段階的にマイグレーションできます。
任意のマイグレーション方法またはツールを使用してサブネット上のすべての VM をマイグレーションし、デフォルト・ゲートウェイを NSX-T に移動します。

考慮事項には、以下の質問が含まれます。

ダウン時間が制限されているかどうかにかかわらず、ワークロード VM を移動する必要がありますか。
ワークロード VM を個別に移動する必要がありますか、それとも小さなバッチで移動する必要がありますが、一度に 1 つのサブネットを移動することはできませんか。
既存の環境と新しい環境（ VCF for Classic - Automated ）の間にレイヤー2を拡張する必要がありますか？
- 一度にいくつのネットワークを拡張する必要がありますか。
- 高可用性が必要ですか。
- L2 ブリッジ・エッジ VM 用に必要な数の NSX-T エッジ・ノード VM をデプロイするために、NSX-V 準備済みホスト上にどのくらいの予備容量がありますか。

ワークロード・マイグレーションの以下のマイグレーション・パターンを考慮する必要があります。

HCX™ - VMware HCX アプリケーションのマイグレーションにより、何千もの VM のスケジューリングとマイグレーションが可能になります。詳細については、VMware HCX 移行の種類を参照してください。
Advanced vCenter vMotion- vSphere 7.0 Update 1c (Patch 02)より、 vCenter、同じSSOドメインに属さない別の VCF for Classic - Automated からのVMのインポートをサポート。ソース VCF for Classic - Automated のバージョンは 6.5 以降でなければならない。詳細については、高度なクロス vCenter サーバー vMotion 機能の紹介を参照してください。
Zerto または Veeam® - Zerto または Veeam が NAX-V 環境にインストールされていて、それらの使用に適する場合があります。これらの製品を使用して、VM をソース・データ・ストアからターゲット・データ・ストアに複製し、フェイルオーバーを開始することができます。また、ソース・クラスターからターゲット・クラスター上のリカバリーにバックアップを複製することもできます。

ネットワーク L2 拡張

ネットワークの観点からは、マイグレーション中のレイヤー 3 およびレイヤー 2 接続の要件を理解する必要があります。 L2 拡張機能により、NSX-T 論理スイッチを NSX-T セグメントにブリッジングすることができます。 NSX-V 環境と NSX-T 環境の間でワークロードを移動できますが、デフォルト・ゲートウェイは NSX-V 上に保持することも、新しい NSX-T に移動することもできます。このアクションにより、よりスムーズなネットワーク・マイグレーションが可能になります。ただし、ご使用の環境がダウン時間を許容できる場合は、必須ではありません。

レイヤー 3 ネットワーク・マイグレーションについては、以下の詳細を考慮してください。

VM by VM マイグレーション - このアプローチでは、VM を 1 台ずつ移動し、そのホストの /32 ルートを NSX-T 環境に注入します。したがって、特定のルートがこの IP アドレスから NSX-T 環境に定義され、サブネット内の他のすべての IP アドレスは引き続き NSX-V 環境にルーティングされます。
サブネットごとのマイグレーション - この方法では、サブネット上のすべての VM を一度に移動します。サブネットは NSX-T 環境から通知され、NSX-V 環境からは通知されません。
Big-bang - すべてのサブネットとそれらに接続されている VM が移動され、NSX-T 環境からすべてのサブネットが通知されます。

マイグレーション時のレイヤー 2 ネットワーク拡張については、以下の詳細を考慮してください。

NSX-T L2 ブリッジ - このアプローチでは、NSX-T Edge VM (できれば NSX-T Edge VM のペア) が NSX-V 準備済みホストにデプロイされます。これらの Edge VM は NSX-T Manager に登録され、必要な NSX-V VXLAN（仮想配線）を NSX-T セグメントに接続するために L2 Bridge が設定されます。詳しくは、vMotion またはサード・パーティー・ツールと NSX-T L2 ブリッジを使用するマイグレーションを参照してください。
VMware HCX - VMware HCX は、主に環境間でワークロードをマイグレーションするために使用されるソリューションであり、ワークロード・モビリティーを実現するためのいくつかのサービスで構成されています。 HCX は NSX-V と NSX-T の両方に統合されます。HCX Network Extension (NCX-NE) では、複数のネットワークを同時にブリッジングできます。このソリューションは、アプリケーションが複数のセグメントに分散しており、マイグレーション中に長期間にわたってアプリケーション間接続を必要とする場合に役立ちます。 HCX を使用すると、HCX-NE ペアごとに一度に 8 つのセグメントをブリッジングできます。このアクションは、ワークロードが複数のセグメントにまたがる場合に特に役立ちます。詳しくは、HCX を使用したワークロード・マイグレーションを参照してください。

3 番目のレイヤー 2 アプローチは、NSX-T L2VPNを使用することです。この方法では、NSX-V 環境が L2VPN クライアントとして機能し、NSX-T 環境が L2VPN サーバーとして機能します。 L2 VPN 接続は、L2 VPN サーバーと L2 VPN クライアントの間の経路ベースの IPsec トンネルによって保護されます。この方法は、NSX-T L2 Bridge の方がパフォーマンスが良いため、 V2T 移行用の 2 つの VCF for Classic - Automated インスタンス間 IBM Cloud では推奨されません。また、IBM Cloud プライベート・ネットワークは大きな MTU (ジャンボ・フレーム) をサポートするためです。