ページの先頭です

ページ内を移動するためのリンク
本文へ (c)

ここから本文です。

Migrate to Virtual Machinesを使ったGoogle Cloudへの仮想マシンの移行

ライター:三木 亮弘
ITインフラ技術のSEに従事して二十年以上になります。
現在は、クラウドアプリケーションの技術支援を担当しています。

目次

クラウドの活用が一般的になり、オンプレミス環境で実行されているワークロードをクラウドに移行するニーズが高まっています。クラウドサービスを展開するクラウドベンダー各社は自社クラウドへの移行ツールを提供しています。今回は、Google Cloudへの移行ツールであるGoogle Cloud Migrate to Virtual Machinesを使って、オンプレミスデータセンターのVMware基盤からGoogle Cloud Compute Engineに移行する手順について紹介します。

構成図

今回移行検証を実施した構成イメージ図となります。

利用ステップ

大凡の利用の流れは以下の通りとなります。

(1) Google Cloud側の準備

Google Cloudコンソールにログインして、Migrate to Virtual Machines のダッシュボードにアクセスします。初めて利用する場合には、VM Migration APIの有効化が必要になります。移行先となるProjectVPC、サブネットを決めておきます。新規に作成する場合は予め作成しておきます。

(2) Migration Connectorの構築

Migration Connectorはオンプレミスの仮想化基盤があるデータセンター側に構築します。Migration ConnectorGoogle CloudからOVAファイルで提供されているため、デプロイそのものはステップに従って、比較的容易に行うことが可能です。

Migration Connectorは、移行元の対象となるvCenterへのアクセス権限と、Google Cloud APIsへのアクセス権限を設定します。その為に、vCenter側では予め必要となるロールをもつ管理ユーザを作成しておきます。Google Cloud側のサービスアカウントは、既に設定されているService Accountを利用することもできますし、Migration Connectorの設定画面を通じて新しいService Accountを作成して利用することも可能です。

(3) 移行VMのデータ同期

構成が完了するとMigrate to Virtual MachinesのダッシュボードからvCenter上で移行対象にできる仮想マシンのインベントリを確認できるようになります。

移行対象として指定する仮想マシンには、移行対象に指定する操作を実施します。「移行を追加」をクリックします。

移行対象リストに追加されると仮想マシンのデータをGoogle Cloud側にコピーすることが可能になります。

レプリケーションによりデータのコピーが行われます。レプリケーション処理は前処理、データの転送、後処理によって構成されます。

(4) Compute Engineへの移行

データのレプリケーションが完了した仮想マシンは、Google Compute Engineとしてのデプロイが可能となります。テストクローンモードは、仮想化基盤側の移行対象元仮想マシンに影響を与えることなく、Google Cloud側に複製した仮想マシンをCompute EngineVMインスタンスとして起動することが可能です。

テストクローンが完了し、Compute EngineVMインスタンス欄に、指定した名前のコンピュートが表示されるため、あとは通常の利用方法と同じとなります。

カットオーバーモードは、VMware基盤側の仮想マシンを停止し、最後のデータ転送アップデートを完了した状態で、移行するための方式となります。

カットオーバーのタスクは、ソースVMシャットダウン、最終同期、VMディスク準備、移行したVMのインスタンス化によって構成され、完了するとCompute EngineVMインスタンスが起動されます。

起動したVMインスタンスは、通常通りの利用が可能です。

移行時間の考察

以下にWindows Server CentOSDebianUbuntuでの移行時間を計測した結果を示します。

仮想マシンのOSタイプによって、移行時間に大きな差が出るということは無いと言えそうです。ディスクサイズと回線帯域による転送時間の想定と、後処理の時間20分程度を見込んでおけばよい形となります。テストクローンの場合は、レプリケーションの転送時間と後処理時間で換算することができます。カットオーバーの場合は、最初のレプリケーションは完了している状態から、最終差分データの最終同期時間とVMインスタンス化のための後処理時間で換算することができます。

移行先マシンでの追加モジュール

移行先の仮想マシンを起動し、Google Cloudで動作するためにインストールされたモジュールを確認してみます。

移行したCompute Engineを起動し、インストール済みモジュールの履歴を確認するとgoogle-cloud-sdkなど、VMware基盤で稼働していた際にはインストールされていなかったモジュールが、自動的にインストールされていることが判ります。以下、CentOSにてrpm -qa --lastコマンドによる最新インストール済みモジュールの確認結果を表示しています。

移行前(VMware基盤で稼働)のモジュール構成:

移行後(Google Cloudで稼働)のモジュール構成:

移行対象マシン

異なるクラウド間では、サポートされるOS種別に差異があるため、移行可能な仮想マシンタイプであるかどうかの精査は必要です。VMware仮想基盤でサポートされているゲストOSと、Google Cloud Compute Engineで利用可能なOSには差異があります。また、Migrate to Virtual Machinesで移行対象としてサポートされているOSにもサポート一覧があり、ここに合致している必要があります。

Migrate to Virtual Machinesは、マシンイメージインポートより多くのOSタイプをサポートしています。例としてCentOS Stream 8は、マシンイメージインポートではサポートされていませんが、Migrate to Virtual Machinesではサポートされています。

Migrate to Virtual Machinesは移行対象OSのサポート範囲が広がったことで、マルチクラウドな移行の実現性を高めたと言えそうです。

まとめ

今回は、Google Cloud Migrate to Virtual Machinesによる仮想マシンの移行をご紹介しました。

仮想マシンの完全な移行だけでなく、開発やテストを一時的にクラウド上で実行するという場合にも利用することが可能です。

マルチクラウドでの運用が一般化してくると利用が増えてくるソリューションと言えます。Google Cloud利活用のご参考になれば幸いです。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。

RECOMMEND