ワークロードのマイグレーション
本節では、VM インスタンスのマイグレーション パターンについて解説します。なお、コンテナライズされたアプリケーションではなく、物理サーバーや 仮想化プラットフォーム の環境に構築されたワークロードをマイグレーションする前提で説明します。
Embedded Files
Google Cloud VMware Engine への マイグレーション
Google Cloud VMware Engine への マイグレーション
Google Cloud VMware Engine（GCVE） は、Google Cloud がマネージド サービスとして、Google Cloud データセンター内に、VMware vSphere をベースとした Software-Defined Data Center （SDDC）クラスタを展開し、提供する IaaS 基盤です。GCVE は利用するお客様毎に vSphere 環境が払い出される物理サーバー リソース占有型のサービスで、払い出される環境を プライベート クラウドと呼びます。プライベート クラウドを構成する vSphere 、vSAN、NSX に関するメンテナンスやバージョン アップなどは Google Cloud がマネージド サービスとして実施するため、お客様は vSphere クラスタに展開する VM の運用管理に注力することができます。
エンタープライズのお客様が、GCVE を利用する際には、新規に VM を GCVE 環境に構築することももちろん可能ですが、オンプレミス環境と接続をしてハイブリッド クラウド環境を構築するケースが多くあります。
本節では、GCVE プライベート クラウド をオンプレミス環境とハイブリッド クラウドとして構成する場合のポイント、そして、オンプレミス環境から GCVE へ VM を移行する場合の手法について解説します。
解決する課題・使い所
GCVE を利用してハイブリッド クラウドを構成する場合であっても、オンプレミス環境と Google Cloud の接続は、他の Google Cloud のサービスを利用する場合と同様、プロジェクト、VPCの作成、Cloud VPN または Cloud Interconnect によるハイブリッド 接続が必要となります。設計の段階から検討しておくべき点を整理して、環境の構築、VM の移行をスムーズに進めるためのポイントを紹介します。
設計前に検討しておくべきポイント
移行対象となる vSphere クラスタの決定
移行対象 VM のリソース、アプリケーション・利用ツールの整理
キャパシティ プランニングにあたって重要
オンプレミス環境のクラスタ構成、VMware 製品コンポーネントのバージョン
運用ツールの継続利用の要否
GCVE を展開するプロジェクトの設計
プロジェクトとは、ユーザの組織において Google Cloud のリソース（VM、ディスク、ネットワーク、BigQuery のデータセットなど）が紐づくリソースの論理グループ
組織、プロジェクト、請求先アカウントなどの設計
リソースへのアクセス ポリシーの決定
Cloud Identity
Identity and Access Management（IAM）
Google Cloud VPC 設計
オンプレミス環境との接続は、Cloud Router をゲートウェイとして、Cloud VPN または Cloud Interconnect を利用するため、GCVE のみを利用する場合であっても VPC の設計、および Private Service Access を用いた GCVE プライベート クラウドとの接続の構成は必須
ネットワーク トポロジーの整理
オンプレミス側 vSphere の仮想スイッチの構成
ハイブリッド クラウド構成になった場合のサブネット設計
オンプレミス環境から GCVE プライベート クラウドのセグメント、Google Cloud VPC のサブネットに対するルーティング、アクセス制御
オンプレミス環境と Google Cloud VPC との接続方法
Cloud Interconnect によるキャリア 閉域網による専用線接続
Cloud VPN を活用した インターネット経由での IPSec VPN 接続
移行方法の決定
移行に要する時間、ダウンタイム
ネットワーク アドレスの変更の有無
Google Cloud のプロジェクトの設計部分を除くと、従来のオンプレミス環境における vSphere 環境のデータセンター移行で検討するべき内容と大きくは変わりません。
設計時に留意しておくべきポイント
1) 共有 VPC の活用とカスタム サブネットの利用
GCVE の利用に限らず、Google Cloud において ネットワーク サービスを利用する場合、VPC の作成が必要となります。多くのお客様では、クラウドの活用を徐々に拡大していくことから、その過程で 複数のプロジェクトを跨いだネットワークが必要になるケースも多くあります。その際にネットワークの追加設定をなるべく減らし、ネットワーク ポリシーの管理を簡素化するために利用することができるのが共有 VPC です。
GCVE プライベート クラウドは 同一プロジェクト内の Google Cloud VPC に紐付けられた Cloud Router によってオンプレミス環境との間でルーティングを確立することができます。今後、Google Cloud の各サービスとの相互接続も含めたクラウドの拡張を見据えて、オンプレミス環境との接続、および、GCVE プライベート クラウドからプライベート コネクションする VPC は共有 VPC として構成をしておくことも一つの選択肢です。（PoC などの一時利用の際にはその限りではありません。）
その場合には、GCVE プライベート クラウドは、共有 VPC でホストプロジェクトとして指定したプロジェクトに展開してください。詳細は GCVE における 共有 VPC に関するガイドをご確認ください。
また、オンプレミス環境との接続を行う VPC においては、VPC 作成時に作成される 「default」 として作成される 自動 サブネットではなく、カスタム サブネットを新たに作成することを推奨しています。これにより、既存のオンプレミス側で利用しているサブネットとの重複を防ぎ、お客様が意図したサブネットを指定することが可能になります。
2) オンプレミス環境と Google Cloud VPC との接続について
オンプレミス環境と Google Cloud VPC とのプライベート アドレスによる接続にあたっては、以下の選択肢があります。
・Cloud Interconnect
各サービスとも Cloud Router を介して BGP によるルート交換を行います。
各サービスの詳細や SLA を踏まえた接続構成については、各サービスのガイドを参照してください。
3) DNS による名前解決とドメインを意識したネットワーク設計
GCVE プライベート クラウドを展開すると vSphere SSO ドメインとして *.[ZONE].gve.goog (* 部分はシステムにてランダムに払い出し）が設定されます。このドメインは、プライベート クラウドのデプロイごとにランダムに生成されるため、プライベート クラウドの削除や再デプロイを行った場合には変更されることになります。（あくまで GCVE プライベート クラウドの vCenter などの管理サーバー群に付与されたドメインであるため、展開する VM が参照するドメインには直接影響することはありません。）
GCVE では、プライベート クラウドを立ち上げると、*.[ZONE].gve.goog を管理する DNS サービスがデプロイされます。オンプレミス側のリソースとの名前解決を実現するためにオンプレミス側 DNS サーバーと相互にフォワーダーの設定を行うことも可能です。詳細については Google Cloud VMware Engine で Cloud DNS を使用したグローバル アドレス解決を活用する方法 も参考にして最適な構成を検討してください。
4) Google Cloud VPC と GCVE プライベート クラウドとの プライベート コネクション
お客様の Google Cloud VPC と GCVE プライベート クラウドを接続する場合、プライベート サービス接続（Private Service Access）を利用します。
Private Service Access は、お客様が管理するVPCとGoogle Cloudが管理するVPC（マネージド サービスが配置されるネットワーク）の間を接続する仕組みで、設定することにより VPC ピアリングが構成されます。（VPC 側では[servicenetworking-googleapis-com] という名称のピアリングが生成されます。
GCVE から VPC へ接続できるピアリングの数はデフォルトでは 3 ピアまでとなっています（展開する ESXi ホストが 3 ノードの場合。ノードが増えると上限が変動。）。また、GCVE からの直接のインターネット接続を有効にした場合には、ピアリングを1つ消費するため、2 つの VPC までの接続が許可されることになります。
GCVE プライベート クラウド側でもプライベート コネクションを設定し、VPC 側で設定した Private Service Access との接続を行うことで、相互の通信が可能となります。その際には、双方で自身のネットワークが保持しているルート情報の交換（Exported Routes / Imported Routes ）を許可する必要があります。また、オンプレミス側に GCVE への経路を Cloud Router を通じてアドバタイズするためにはカスタムルートの構成が必要となります。
GCVE プライベート クラウドへの VM 移行のシナリオ
実際に VM をGCVE へ移行するための手法としてどのような方法があるかを解説します。
OVF ファイルによるエクスポート / インポート
バックアップ / 移行ツールによる移行
サードパーティ ソリューションの活用
VMware ソリューションを活用した移行
Site Recovery Manager、 vSphere Replication
VMware HCX
VM の移行にあたっては、事前に以下の点を確認をした上で要件を満たすことが出来る移行手法を選択することを推奨します。
VM 停止の可否
許容できる移行の時間
オンプレミス側の vSphere バージョン
オンプレミス側の VM ハードウェア バージョン
それぞれの移行方法の選択のポイントについては、以下の表を参照してください。
VMware HCX のセットアップ
実際に VMware HCX を利用するためのセットアップについて簡単に解説します。
詳細な手順は VMware HCX を使用した VMware VM の移行 に記載がありますので、参照してください。
GCVE では、プライベート クラウドをデプロイする際にオプションで VMware HCX を合わせて展開するかどうかを選択することができます。VMware HCX の展開を選択しておくとプライベート クラウドのデプロイ時に合わせて、GCVE側の VMware HCX 環境が展開されるため、オンプレミス側での HCX Manager を始めとするコンポーネントを展開するだけで、VM の移行を行うことが可能です。
VMware HCX の各コンポーネントはオンプレミスの環境での構築の場合と同様 VMware Customer Connect からダウンロードします。VMware HCX のインストール時に必要となるアクティベーション キーについては GCVE コンソールから取得することが可能です。
具体的な設定の流れについては、VMware HCX を使用した VMware VM の移行をご参照ください。
また、VMware HCX による L2 延伸を行うことで、オンプレミス側の vSphere 環境と GCVE プライベート クラウド上のセグメント（オーバレイ ネットワーク）を同一セグメントで接続することも可能となります。（お客様 VPC サブネットは経路上のアンダーレイとなるため、VPC サブネットと同一サブネットにすることはできません。）
利点
GCVE を利用する場合でも、オンプレミス環境と Google Cloud の接続はCloud VPN または Cloud Interconnect を利用してハイブリッド接続することには変わりなく、Private Service Access を経由してシンプルにネットワークを構築することができます。
VMware HCX を利用することで、VM の移行を容易に行うことができるとともに、必要に応じて、VMware HCX による L2 延伸を活用して、オンプレミス側とGCVE プライベート クラウド側を同一サブネットで構成することで、GCVE プライベート クラウドへ移行する VM の IP アドレスを変更することなくサブネットの変更なく VM の移行を行うことが可能です。
注意事項
GCVE への移行を検討する際には、移行をスムーズに行い、移行後にオンプレミス環境との相互接続も適切にできるようなネットワーク構成を意識した設計をする必要があります。
VM の移行にあたっては、移行元 VMware vSphere 環境と移行先となる GCVE プライベート クラウドの VM ハードウェア バージョン、各種ドライバの互換性などを予め把握しておく必要がありますGCVE の各コンポーネントの最新バージョンはサービスに関するお知らせを確認してください。また、GCVE プライベート クラウドにおける VM などとの互換性の確認には、VMware が提供する VMware Compatibility Guide 及び Product Interoperability Matrix を参照してください。
GCVE プライベート クラウドを展開すると、VMware HCX アップリンク プロファイルのデフォルトの MTU 設定は 1,440 となっています。オンプレミス環境と接続する場合には、パケットの断片化によるパフォーマンスの低下を防ぐために、オンプレミス側の HCX 、Google Cloud VPC 及び Cloud Interconnect で設定されているMTU サイズを 1,500 に統一するなどの考慮が必要です。おすすめの MTU 設定も参考に検討してください。
参照文献
仮想マシンの Google Compute Engine（GCE）への移行
仮想マシンの Google Compute Engine（GCE）への移行
解決する課題・使い所
既存のワークロードを異なる環境に移行する場合、インスタンス イメージの変換、ドライバのインストール、整合性の確保など、移行先の環境に合わせた変更作業が必要となります。Google Cloud では、もとの環境から Compute Engine にワークロードを移行をする場合、Compute Engine に必要なイメージの変換をしたり、パッケージが自動的にインストールされたりなど、いくつかの移行方法を提供しています。
クラウド移行時のリスクと作業工数を最小化するためには、移行方法の選択肢を正しく理解し、適切に選択することが重要です。本節では、ワークロードの性質や要件に合わせてどのような移行方法が存在するのか、また選定するうえでどのようなポイントがあるのかについて紹介します。
Google Cloud への移行方法
GCE への VM 移行方法には大きく分けると 3 種類の方法があります。
1. Migrate to Virtual Michines（M2VM）などの移行ツールを用いた移行
移行ツールを用いて Compute Engine 側にインスタンスをインポートする方法です。Google Cloud では M2VM を提供していますが、ほかのサードパーティ ソリューションでも Compute Engine への移行をサポートしていることがあります。
現時点でM2VM は、VMware vSphere / AWS / Azure などの環境からの移行をサポートしています。
VMware vSphere からの移行 ：M2VM version 5
AWS についてはプレビュー（2022 年 11 月現在）
物理環境、AWS、Azure からの移行 ：M4CE version 4
ここでは、VMware vSphere 環境から M2VM version 5 を利用した場合を前提に解説します。
コンポーネントとしては、移行元の VMware vSphere 環境に導入される Migrate Connector が必要です。Google Cloud コンソールから、Migrate Connector 経由で VMware vCenter に対して移行対象の VM に対するスナップショットの取得を指示し、Migrate Connector でデータを Google Cloud プロジェクトに同期します。このデータを利用して、vSphere VM を Compute Engine インスタンスに容易にコンバートすることができます。
M2VM を利用するメリットとしては、Migrate Connectorで HTTPS（TCP 443）によるインターネットへのアクセスを許可するだけで、セキュアなデータ転送が可能なことで、必ずしも Cloud Interconnect や Cloud VPN によるハイブリッド接続を必要としません。また、移行のプロセスについても、ダウンタイムを最大限少なくするために、スナップショットの取得後にテストクローンによる 移行先インスタンスの単体稼働確認が可能となっており、基本的にはその段階での移行元 VM へのシステムへの影響はありません。
2. OVF / OVAファイル、仮想ディスクを用いた移行
既存の環境から、OVF / OVA ファイルや、仮想ディスク（vmdk、vhd など）をエクスポートし、Google Cloud 側にデータを転送したあと、 Compute Engine 側にインポートする方法です。1. の方法と比べ、作業を手動で行う必要があり（スクリプトなどを組むことで自動化は可能）、ダウンタイムが長くなりますが、ツールなどをセットアップする必要はなく、直感的にもわかりやすいので、オペレーションはシンプルに実現できます。なお、Compute Engine へのインポートのときに、Compute Engine に必要なパッケージがインストールされる仕組みになっています。
3. OS より上のレイヤーの機能を用いた移行
1. や 2. とは取得する範囲が異なりますが、Compute Engine 側にインスタンスを立てて、OS の中身の機能でデータを移行する方法です。この場合、データ移行部分以外は再構築になるため、作業やテストが多くなる可能性がありますが、1. や 2. と違い、もとの環境の専用ドライバなども移行してしまい、不要なモジュールが残ってしまうことはないので、よりクリーンな環境でワークロードをスタートさせることができます。なお、インスタンス を立てるタイミングで、Compute Engine に必要なパッケージはプリ インストールされています。
M2VM アーキテクチャ / 移行のステップ
次に M2VM version 5 を利用した、オンプレミスの VMware vSphere 環境からの移行を前提とした、移行環境の準備、および実際のインスタンスの移行手順について説明します。
移行環境の準備
1. Google Cloud 環境の準備
移行先となるプロジェクト作成、VPC の展開を行います。また、M2VM を利用するうえで必要となる API サービスの有効化、 Identity and Access Management（IAM）ロール割り当てを行います。
2. 展開前の事前準備
移行元の vSphere 環境に VM として展開する Migrate Connector がアクセスするための vCenter アカウントの作成、権限の付与を行うとともに、ネットワーク接続性の確保、Migrate Connector へアクセスするための SSH 公開鍵 / 秘密鍵のペアを作成します。
Migrate Connector に付与するための vCenter アカウントは、管理者権限（Google Cloud VMware Engine の場合には、ソリューション ユーザーアカウント）が必要になります。
3. Migrate Connector の展開
移行元の VMware vSphere 環境に、Migrate Connector を OVF デプロイで展開します。デプロイのあと、Migrate Connector に SSH でアクセスし、Google Cloud プロジェクトと連携するためのサービス アカウントの設定、移行元となる vCenter へのアクセス設定を行います。
VM 移行の流れ
1. VM オンボーディング
移行先となる プロジェクトを指定して、Compute Engine への移行に必要な権限を設定します。複数のプロジェクトへの移行を管理したい場合、M2VM がセットアップされたホスト プロジェクトのほかに、ターゲット プロジェクトを指定することで対応します。
2. レプリケーション
移行するインスタンス（複数の場合はグループとして指定することも可能）を選択して、Migrate Connector を経由して、VMware vSphere 環境で移行対象のインスタンスのスナップショットを取得します。取得したスナップショット データは、同時に Google Cloud ホスト プロジェクトの M2VM へ同期されます。以降、指定した間隔（デフォルトでは 2 時間ごと）で、データ更新があった部分のスナップショットを M2VM に転送します。
3. VM ターゲットの構成
移行するインスタンスのマシンタイプ、リソース設定、ネットワーク設定、サービス アカウント、OS ライセンスの種類など、Compute Engine インスタンスを構成するときに必要なパラメータを設定します。
4. テストクローン
VM ターゲットに構成したパラメータに基づいて、レプリケーション実行時のスナップショットをベースに Compute Engine インスタンスがデプロイされます。このとき、移行元の VM の稼働に影響はありません。この段階で、OS、アプリケーション レベルで問題なくインスタンスが移行できているかどうかを確認します。なお、テストクローンの実行はあくまで任意のため、スキップすることは可能ですが、テストクローンを実行することにより移行に問題があった場合、Google Cloud Console 上からエラー詳細を確認することが可能なので、できる限りテストクローンを実行することを推奨しています。
5. カットオーバー
カットオーバーすると、vSphere の 移行元 VM はシャットダウンされ、最後のレプリケーションを実行して、これまでのスナップショットを 1 つの永続ディスクとして書き出し、新規の Compute Engine にマウントすることで、最終的な移行が完了します。移行元 VM がシャットダウンされた段階では、システムの停止を伴うので、あらかじめメンテナンス ウィンドウを設けて作業を実施することを推奨します。
6. ファイナライズ
移行先の インスタンスが問題ないことを確認できた段階で、ファイナライズ処理を行い、移行処理を終了させます。ファイナライズをする前であれば、改めてレプリケーションを実行し直すことで、カットオーバーの再実行が可能です。ファイナライズ処理を行わない場合、M2VM が内部的に保持しているレプリケーション データ（お客様プロジェクト内の M2VM 用のマネージド Google Cloud Storage バケットに格納：ユーザーからは確認できません）のデータ課金が継続されるため注意が必要です。
インフラ レイヤの移行について、大きな流れは上記のとおりですが、移行元の環境、移行するインスタンスによって移行手順が異なります。一般的には、このあとアプリケーション レイヤの稼働確認へと続きます。また、プロダクト アップデートなどで必要な作業に変更が出る可能性もあるので、公式ドキュメントの最新情報を必ず確認してください。
利点
ドライバのインストールや、OS ライセンスの変換などが、ツールの中で自動的に行われるため、より少ない手間で移行を実現することができます。
レプリケーションからテストクローンまでの手順により、データを移行する前からワークロードを稼働させて確認が行えるので、実際の切り替えにあたっては、カットオーバー処理に要するわずかな時間のみで、クラウド側でワークロードの稼働を開始することができます。
予想外の事態が発生したときには、数クリックでステートフルなロールバックを行うことができます。
注意事項
M2VM を利用する前に、対応している OS、プラットフォームを確認しておく必要があります。
移行元のプラットフォームに応じて移行に利用する M2VM （version 4 は旧名称の Migrate for Comupte Engine : M4CE）バージョンが異なります。
VMware vSphere からの移行 ：M2VM version 5
AWS についてはプレビュー（2022 年 11 月現在）
物理環境、AWS、Azureからの移行 ：M4CE version 4
参照文献
Page updated
Report abuse