この記事では、意思決定者が計画、実行、使用停止の各フェーズなど、Azure VMware Solutionの移行戦略を定義するのに役立つガイダンスを提供します。
Azure VMware Solutionは、最小限のアプリケーション変更で VMware ベースのワークロードをAzureに移行するための構造化されたパスを提供します。 成功は、仮想マシンを移動する以上のものによって異なります。 組織には、リスクを軽減し、運用継続性を維持し、長期的なプラットフォーム目標をサポートする明確な移行ポリシー、ワークロード評価基準、検証基準、実行制御が必要です。
推奨事項:ワークロードをAzure VMware Solutionに移行する前に、移行戦略、ワークロード評価アプローチ、移行シーケンス、検証の要件を定義します。
1. 移行計画
何かを設計する前に、移行する内容、順序、理由を明確に把握します。 クラウド導入フレームワーク計画手法を使用して、資産を評価します。 Azure VMware Solutionは、最小限の中断が必要で、短期的な最新化が不要なリホスト アプローチに最適です。 それはすべてのアプリケーションに適した場所というわけではなく、計画フェーズで判断するものです。
1.1 検出とインベントリ
Azure Migrateは、オンプレミスの vSphere 環境をスキャンし、仮想マシン、リソースの使用、および依存関係のインベントリを構築します。 このデータは、サイズ設定 (ホストの数とホストの種類) とウェーブ計画 (ワークロードが一緒に移動する) の両方を通知します。 Azure Migrateでは、Azure VMware Solutionへの移動は実行されません。 プロジェクトのサイズと順序を示す証拠が提供されます。
1.2 移行戦略
Azure VMware Solutionは、主にリホスト アプローチをサポートしています。 リファクター処理または再設計処理を必要とするアプリケーションは、Azureネイティブ コンピューティングによって提供される方が適している場合があります。 計画が既定値ではなく意図的な選択を反映するように、これらの決定を記録します。 クラウド移行戦略の選択を参照してください。
1.3 ワークロード評価
すべてのワークロードが、Azure VMware Solutionに対して同じように適しているわけではありません。 ワークロードを移行ウェーブに割り当てる前に、その技術的要件、運用上の依存関係、プラットフォームの適合を評価します。 構造化された評価は、リスクを早期に特定し、適合性を検証し、移行計画に前提条件ではなくビジネスの優先順位が反映されるようにするのに役立ちます。
1.3.1 要件
ワークロードを移行ウェーブに割り当てる前に、Azure VMware Solutionでの成功に影響を与える技術的、運用上、ビジネス上の要件を評価します。 この評価は、プラットフォームの適合性を判断し、潜在的な移行の課題を特定し、サイズ設定、シーケンス処理、準備の決定に必要な情報を提供するのに役立ちます。 各ワークロードを評価するときは、次の点に重点を置く必要があります。
パフォーマンス要件: CPU、メモリ、ストレージ IOPS、ネットワーク スループットの要件について理解します。 これらの要件を、RAID 構成や許容障害 (FTT) 設定など、ホスト SKU と vSAN ストレージ ポリシーをAzure VMware Solutionにマップします。
アプリケーションの依存関係: 各ワークロードが通信するシステムを特定します。 依存関係によって、移行ウェーブ計画と、依存システムを一緒に移動する必要があるかどうかが決まります。
互換性の要件:ゲスト オペレーティング システムとサード パーティ製ソフトウェアがAzure VMware Solutionでサポートされていることを確認します。 オンプレミスの vSphere 上で実行されるほとんどのワークロードは、変更せずにAzure VMware Solutionで実行されますが、想定ではなく検証を行い、問題のある移行のロールバック アプローチをテストしていることを確認します。
ネットワーク要件: 各ワークロードで必要なネットワーク セグメント、IP アドレス、DNS 構成、ファイアウォール規則を文書化します。 待機時間の影響を受けやすいワークロードを特定し、要求をサポートするためにネットワーク アーキテクチャが最適化されていることを確認します。
1.3.2 ワークロードの処理
ワークロード評価では、ワークロードに必要なものを識別します。 ワークロードの処理によって、実行するアクションが決まります。 意思決定者は、各アプリケーションがAzure VMware Solutionに属しているかどうか、オンプレミスに残る必要があるかどうか、またはアプリケーションの一部がAzureネイティブ サービスによってより適切に処理されるかどうかを評価する必要があります。 ワークロードごとに、以下を決定します。
ワークロードがそこに属しているかどうか。 vSphere で既に適切に実行されているワークロードは自然な候補であり、特に短期的な最新化計画がないワークロードです。 廃止または SaaS の代替に向かうワークロードの場合は、移動によって価値が高まるかどうか、または有効期間が終了するまで維持する必要があるかどうかを検討します。
すべてのレベルがそこに属しているかどうか。 ワークロードには、多くの場合、Web フロントエンドやデータベースなど、複数の層があります。 Azure VMware Solutionでアプリケーション仮想マシンを実行し、Azure SQL DatabaseなどのAzureネイティブ データ サービスに接続できます。 この構成により、VMware ワークロードと共にマネージド データベースの利点が得られ、VMware ホストとライセンスのコストが削減されます。
1.4 移行の準備
運用環境での使用を承認する前に、すべてのワークロードが満たす必要がある最小限の運用、パフォーマンス、セキュリティ、ガバナンスの要件を定義します。
すべての移行ウェーブに一貫した検証フレームワークを適用します。 フレームワークでは、必要なチェック、承認基準を定義する必要があり、証拠チームはカットオーバー承認の前に提供する必要があります。 少なくとも、次の検証を行います。
HCX レプリケーションの正常性
NSX セグメントのルーティング可能性
ESXi ホストの健全性
ターゲット セグメントからの ID と認証の到達可能性
バックアップや監視などのサポート サービスの正常性
移行前に、チームがソース環境からベースライン パフォーマンス メトリックをキャプチャする必要があるかどうかを決定します。 これらの測定値は、移行後のパフォーマンスを検証し、回帰を識別するための参照ポイントを提供します。
カットオーバーの前に、外部 DNS レコード、ロード バランサーの構成、アプリケーション エンドポイント、またはその他の接続の依存関係に更新が必要かどうかをチームが判断する必要があります。 サービス中断のリスクを軽減するために、ウェーブ カットオーバー計画に必要なすべての変更を含めます。
1.5 Azure VMware Solution移行シーケンス
移行順序によって、どのワークロードを Azure VMware Solution に最初に、次に、というように移行するかが決まります。 優れたウェーブ計画により、リスクが軽減され、不要な中断が回避されます。
依存関係別のグループ化: 検出の依存関係データを使用して、アプリケーション サーバーとそのデータベースなど、密接に連携する仮想マシンのセットを見つけます。 1 つの部分がまだオンプレミスで待機しているときに、すべての要求に対してトラフィックがネットワークを通過しないように、それらを同じウェーブで移動します。
既存のルールをマップする: オンプレミス環境からアフィニティまたはアンチアフィニティルールを文書化し、それらを再現する方法を計画します。 Azure VMware Solution配置ポリシーでは、仮想マシンとホスト間のアフィニティが適用されます。これは、SQL Serverなどのライセンス制約や厳密なパフォーマンス ニーズに重要です。
リスク別のシーケンス: 非運用システムや依存関係の少ないアプリケーションなど、リスクの低いワークロードから始めます。 チームは、ビジネスクリティカルなアプリケーションを使用する前に、プロセスに自信を持って取り組みます。 エクスペリエンスの増加に合わせて、より複雑なワークロードに移行します。
ネットワーク拡張機能プランに合わせる: オンプレミスのネットワーク レイアウトに基づいてシーケンスを作成します。 複数のアプリケーションがネットワーク セグメントを共有する場合は、同じウェーブまたは連続するウェーブで移行します。 その後、セグメントをAzure VMware Solutionネイティブ ネットワークにすばやく切り取り、一時的な拡張機能を削除できます。
1.6 移行ツール
中断を最小限に抑えてワークロードをAzure VMware Solutionに移動するには、VMware HCX を使用します。 HCX Enterprise は追加コストなしで含まれ、既定ではインストールされます。これにより、レプリケーション支援 vMotion やモビリティ最適化ネットワークなどのオプションがロック解除されます。 HCX を使用する必要はありません。 また、パートナー移行ソリューションを使用して物理ワークロードを取り込むこともできます。
1.6.1 移行アプローチ
vMotion は、ダウンタイムなしで実行中のワークロードを移動します。第 2 世代では、一般的に一括メソッドよりも高速に実行されます。 現在、第 2 世代ではレプリケーション支援型と一括移行の実行速度が低下する可能性があるため、より長い期間を計画し、それに応じてウェーブをスケジュールします。 第 2 世代プライベート クラウドの設計に関する考慮事項Azure VMware Solution参照してください。
1.6.2 ネットワーク拡張機能のガバナンス
一部のチームでは、ネットワーク拡張機能を永続的な設計として扱います。 そうじゃありません。 拡張機能は、移行ウィンドウでのみ開いたままにしておきます。 HCX ネットワーク拡張機能は、オンプレミス ネットワークをレイヤー 2 のAzure VMware Solutionに拡張し、ワークロードが移動中に既存のアドレスを保持できるようにします。 この設計は、アプリケーションを事前に再構成することを回避し、意思決定者が管理する必要があるトレードオフを伴います。
オンプレミスの依存関係。 通常、拡張ネットワークではゲートウェイがオンプレミスに保持されるため、ワークロードは移行後もソース サイトに依存します。
非効率的なルーティング。 トラフィックはオンプレミスに戻り、戻ることができます。これは、待機時間と障害ポイントを追加するトロンボニングと呼ばれるパターンです。
強固なポリシーを設定します。 ワークロードがアドレスを変更できない場合にのみネットワークを拡張し、ワークロードが移動したらすべての拡張機能を削除します。 拡張機能が必要なセグメントと期間を把握できるように、まずオンプレミス ネットワークを評価します。 その評価結果は、ウェーブ計画と拡張スケジュールの両方に反映されます。 モビリティ最適化ネットワークは、特定のケースでトロンボニングを減らすことができます。そのため、有効にする前に、サポートされている構成を確認してください。 HCX ネットワーク拡張機能の構成を参照してください。
2. 移行の準備
次のデプロイ シーケンスは、ステージ間の依存関係を反映しています。 各手順では、前の手順が完了し、検証されていることを前提としています。
プラットフォーム ランディング ゾーン:必要なすべての一元化されたネットワーク、ID、セキュリティ、および監視サービスを、Azure VMware ワークロードと統合する準備ができていることを確認します。 コンプライアンス要件の達成に役立つ管理グループ階層に、Azure Policyを介してガバナンスとセキュリティ ベースラインを適用します。 第 2 世代は仮想ネットワークにデプロイされるため、ネットワーク セキュリティ グループまたはルート テーブルに厳密な規則を適用するポリシー ベースラインによってデプロイがブロックされる可能性があります。 デプロイする前に、プライベート クラウドの仮想ネットワークからこれらの特定のポリシーを削除してから、後で再適用します。 ガバナンスがロールアウトを停止しないように、この例外をベースラインに計画します。
ワークロードランディングゾーン: ワークロード ランディング ゾーン (サブスクリプション) を、オンラインまたは内部 ("Corp") の適切な管理グループの下に配置します。
IP アドレス範囲: プライベート クラウドの最小 /22 アドレス ブロックを予約します。 第 2 世代では、HCX 管理とアップリンク用に追加の /24 ブロックを 2 つ予約します。 これらの範囲がオンプレミス、Azure、またはその他のクラウド アドレス空間と重複していないことを確認します。 デプロイ後にこの条件を簡単に修正することはできません。 第 2 世代の設計上の考慮事項を参照してください。
クォータ要求: 割り当てには最大 5 営業日かかる可能性があるため、クォータを早期に要求します。 N+1 の冗長性など、増加とディザスター リカバリーのために十分な量を要求します。これは、ワークロードに必要な量を超える 1 つのホストです。 新しいデプロイに必要なポータブル VMware Cloud Foundation ライセンスを確認します。 ホスト クォータの要求に関するページを参照してください。
Azure VMware Solutionプライベート クラウドのデプロイ: 第 2 世代プライベート クラウドをAzure仮想ネットワークにプロビジョニングします。 第 2 世代プライベート クラウドの作成を参照してください。
ネットワークと ID の構成: プライベート クラウド ネットワークをハブにピアリングし、オンプレミスの接続を確立します。 管理者が共有の組み込み資格情報ではなくマネージド アカウントでサインインできるように、vCenter Server を外部 ID ソースに接続します。
監視と管理: ログ管理ソリューションにログを転送し、Service Health アラートを構成します。 Azure Arcを使用してゲスト仮想マシンをオンボードし、他の場所で使用するのと同じAzure ツールで管理できるようにします。
HCX インストール: 最初のウェーブを開始する前に、HCX をインストールし、サイト間接続をテストします。
3. 移行の実行
各ウェーブの前に "完了" とは何かを定義します。 ワークロードが検証され、ネットワーク拡張機能が削除され、アプリケーションが永続的な状態で正常な状態になると、ウェーブは完了します。
各ウェーブの前にロールバック条件を定義し、運用システムを移行する前にロールバック パスをテストします。 HCX では逆移行がサポートされており、正確なアプローチは使用した移行の種類によって異なります。 ウェーブの成功条件は次のとおりです。
ウェーブ内のすべての仮想マシンはAzure VMware Solutionで実行され、運用トラフィックのネットワーク拡張機能に依存しなくなりました。
すべてのアプリケーションは、そのユーザーとその依存システムによって到達可能です。
すべての仮想マシンは、警告やエラーなしで監視ツールに表示されます。
ロールバックは不要になり、正式に終了できます。
アプリケーションのパフォーマンスがベースラインと一致するか、または上回ります。
ワークロードは、セキュリティとコンプライアンスの要件を満たします。
ワークロードは、バックアップおよびディザスター リカバリー ソリューションに正常にオンボードされました。
4. 移行の評価と使用停止
ワークロードがAzure VMware Solutionで電源をオンにしても、移行は終了しません。 ワークロードが新しい環境で正しく動作することを検証し、一時的な移行の宿泊施設が削除されていることを確認し、ソース インフラストラクチャを正式に廃止します。 オンプレミスのインフラストラクチャを配置したままにしておくと、検出されていない依存関係と文書化されていない依存関係が発生する可能性があります。 規範的な評価と使用停止のプロセスにより、組織は不要な運用コストやリスクを伴うことなく、移行の期待される利点を実現できます。
カットオーバー後の生産準備
ワークロードが期待どおりに動作することを確認するカットオーバー後の条件を義務付けます。 ネットワークの到達可能性と名前解決を確認します。 アプリケーションの機能と依存システムとの通信を確認します。 各仮想マシンが移動した後、仮想マシンが起動し、そのリソースがプランと一致し、正しいストレージ ポリシーが適用されることを確認します。 パフォーマンスを移行前ベースラインと比較します。
パリティ ポリシーを決定します。 重要な決定は、移行されたワークロードを運用環境対応と呼ぶ前にオンプレミスの状態と完全に同等に達する必要があるかどうか、または一時的な逸脱を許可するかどうかです。 多くの組織は、顧客向けのシステムに対して即時のパフォーマンス パリティを要求しますが、修復期限が固定された短い安定化期間を内部アプリケーションに付与します。
4.2 接続の検証
Azure VMware Solution、Azure、オンプレミス、インターネット、および名前解決全体にわたって、エンドツーエンドの接続を検証します。 アプリケーション スモーク テストを実行して、ワークロードがその目的を果たすことを確認します。 外部名レコードまたはロード バランサーの設定で、カットオーバーの一部として更新が必要かどうかを確認します。
ディザスター リカバリー用にAzure VMware Solutionのセカンダリ インスタンスを構築した場合は、プライマリ インスタンスと、アクティブ化されている場合に接続する必要があるクライアントまたはサポート サービスの両方からアクセスできることを確認します。
4.3 ネットワーク拡張の解消
拡張セグメントのすべてのワークロードが移動したら、HCX レイヤー 2 拡張機能を削除し、Azure VMware Solutionネイティブ ゲートウェイが正しくルーティングされることを確認します。 拡張機能を移行に必要な期間を超えて残さないでください。
4.4 ソース環境の廃止
使用停止により、ソース容量、ライセンス、運用範囲が正式に解放されます。 クリーンアップ タスクではなく、管理されたハンドオフとして扱います。 廃止を行わないと、使われていないインフラにコストを払い続けることになり、セキュリティリスクも抱えることになります。 クラウドへの移行後にソース ワークロードの使用停止を使用して、操作の順序、ソース バックアップの保有期間、ソース システムの電源をオフにするために必要な承認、ライセンスとハードウェアを回収するための基準を設定します。
次のステップ
ワークロードの設計: