Migrate for Compute Engine の v5 と v4 の違いについてまとめてみた
Migrate for Compute Engine（以下、M4CE ）の ver 5.0 が東京リージョンでも使えるようになり ver 5.0 を使用して VMware vSphere 環境の仮想マシンを Google Cloud Compute Engine に移行する検証に関して Setaka-san が紹介していました。今回はこちらのブログの続編（？？）として、現在使用可能な M4CE の 2 つのバージョン（ver 4.x と ver 5.0） の違いについて比較し、「どんな時にどっちを使えばいいのか？」という疑問を解消していきたいと思います。
TL;DR
- Compute Engine への移行を行う際は、移行元となるシステムが稼働している環境に応じて ver 5 と ver 4 のどちらを使用するのか選択する必要がある
- 移行元のサーバが vSphere 環境上で稼働していて、ver 5 の利用条件を満たす場合、ver 5 を使用した方がシステムの停止時間が短くコストも安い
- M4CE の ver 5 はデータの増分レプリケーションを転送するようになり、Cloud VPN 経由でのデータ転送が不要になった
この記事では、以下の流れに沿って各バージョンの違いを少し深堀りして比較していきたいと思います。（詳細比較についてはこちらにもまとまっております。）
- アーキテクチャ概要
- ユースケース
- 移行する際の流れ
- 選択可能なマシンタイプ
- 対応している OS
アーキテクチャ概要
M4CE ver 4.x では移行元のサーバが稼働する VMware vSphere 環境、又は AWS や Azure クラウド環境上に M4CE Backend（又は M4CE Importer）を展開して利用します。移行元の環境でM4CE Backend（又は M4CE Importer）が vSphere （又は AWS や Azure ）のAPI を介して対象サーバのスナップショットを取得し、VPN 経由で Google Cloud の Cloud Storage にデータを転送します。また、移行中のVMへの iSCSI 経由でのデータ提供やデータ移行後に Cloud Storage のデータを永続ディスクへ書き出す、Cloud Extension の Edge Node が登場します。各コンポーネントの役割や移行の流れの詳細についてはこちらの記事をご覧ください。
上記に対し、M4CE ver 5.0 では移行元のサーバが稼働する VMware vSphere 環境に Migrate Connector と呼ばれる仮想アプライアンスを展開して利用します。Backend や Importer と名称は異なりますが、対象サーバのデータを vCenter Server と vSphere API で連携することで取得し、Google Cloud の Cloud API を介して Cloud Storage に格納する流れは同じになります。変更点としては、Google Cloud に Compute Engine を起動して Cloud Extension 経由でオンプレ環境のストレージを参照する「Run in Cloud」機能が無くなったため、移行時にデプロイするコンポーネントの種類が減ったことです。M4CE自体は無料で利用でき、移行時のサーバやストレージなどの必要リソースに対しては通常の料金がかかる仕組みとなっていましたが、ver 5.0 ではコンポーネントが減ったことによって更にコストを抑えた移行が可能となりました。（移行の流れ詳細については後述します。）
ユースケース
M4CE ver 4.x はオンプレミス等で稼働している vSphere 環境やAWS・Azure からの移行に対応しており（図1）、Google Cloudの全てのリージョンで利用が可能です。一方で M4CE ver 5.0 は移行元環境として 現時点（2021年12月時点）では vSphere 環境のみとなり、使用できるリージョンは東京リージョンを含めたこちらに記載のリージョンとなります。
上記のため、AWS や Azure からの VM 移行やM4CE ver 5.0 が利用出来ないリージョンについては引き続き M4CE ver 4.x の利用が必要となります。M4CE ver 5.0 の要件を満たすユースケースであれば移行の流れやデータ同期の仕組みが変わっていることを受けて、利用するメリットがあるのでこちらについて紹介していきたいと思います。
移行する際の流れ
M4CE ver 4.x と ver 5.0 の主な流れを以下に示します。
※各バージョンの詳しい手順についてはこちら（ver 4.x、ver 5.0）を参照ください。
移行する際の流れでは ver 4.x では必要になっていた準備パッケージのインストールが ver 5.0 では不要になりました。また、ver 4.x では「移行開始」の際に対象 VM を停止し、取得したスナップショットを元にクラウド環境上に VM を稼働させつつ移行元（オンプレ等）のストレージを参照する「Run in Cloud」の仕組みとストレージデータのストリーミング転送がありましたが、こちらも ver 5.0 では廃止されています。代わりに、ver 5.0 では新たにデータ転送方法としてスナップショットのレプリケーション技術が採用されており、これによって ver 4.x では移行開始する際の VM 停止が不要となりました。
（なお、カットオーバーの際の最終スナップショット取得時のみ VM 停止が必要です。また、上記の流れでは記載しておりませんが、どちらも省略可能なステップとして初回スナップショット取得後のテストクローン生成は可能です。）
まとめると、M4CE ver 5.0 では移行する際の事前準備が簡素化されたことや移行開始時のVM停止が不要になったことで従来よりも最小限の停止時間で VM の移行が可能となったことが主な違いとなります。
選択可能なマシンタイプ
ver 4.x を用いてクラウド移行を行う際、各VM の CPU やメモリ等のスペックや使用状況に応じて適切なマシンタイプを対応しているマシンタイプの中から選定する必要がありましたが、ver 5.0 からは事前に定義されたこちらのマシンタイプの中からの選択が可能です。
対応しているOS
対応しているOSについても、若干差異があるため移行元が vSphere 環境の場合はゲスト OS によって使用するバージョンを選択する必要があります。ver 4.x と ver 5.x で対応しているOSバージョンについてはこちら（ver 4.x、ver 5.0）を参照ください。
また、移行対象サーバがMigrate for Compute Engine に対応していない場合はこちらの記事に紹介されているように仮想ディスクや仮想アプライアンスをコマンドラインまたは手動でインポートする必要があります。
その他：Migrate Manager UI 変更
M4CE ver 4.x まではMigration Manager をデプロイし、Velostrata ベースの UI を操作する必要がありましたが、 ver 5.0 では Cloud Console 上から直接 Migration Manager を参照して操作することが可能となったため移行時の作業が多少楽になりました。
Apache Log4j 2 の脆弱性対策に関して
Ariga-san の記事でお話しがあったApache Log4j 2 の脆弱性について、 M4CE ver 4.11（またはそれ以下）でも Log4j 2 が使用されておりリモートコード実行（RCE）の脆弱性が確認されました。対策について、利用者に通知済みですが詳細については下記を参照ください。
なお、M4CE ver 5.0 以降を使用している場合、アクションは不要です。
まとめ
この記事では、オンプレ環境や他社クラウドから Google Cloud の Compute Engine へ移行する際に利用可能な移行ツール「Migrate for Compute Engine」について、現在提供されている 2 つのバージョンについて比較を行いました。移行元の環境次第では Migrate for Compute Engine ver 4.x を継続して使用する必要がありますが、Migrate for Compute Engine ver 5.0 は移行の流れが短縮されており、VM 停止時間も短くなっているので要件が合う場合はこちらの利用をご検討いただけると幸いです！
