GCPへのマイグレーションを試してみた (vSphere to GCP)

Shohei Okada

Published in

google-cloud-jp

20 min readDec 26, 2019

この記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 8番目の記事の補足記事です。

本記事では、前回の記事で紹介したマイグレーション方法のうち、VMDKインポート, OVFインポート, Migrate for Compute Engine(M4CE)の三種類の移行方法を試してみました。

動作確認環境

以下の環境から、仮想マシンをGCEインスタンスに丸ごと持ってくることを想定して、動作の確認をしていきます。

vSphere6.5
CentOS 7.2
Disk1: boot ディスク (8GB)
Disk2: data ディスク (10GB)
vSphere環境 — 移行対象GCPプロジェクトはVPNで接続

動作確認

VMDKによるインポート(*)

STEP1. VMDK(OVF)取得

VMWareの環境から、VMDKとOVFをまとめて取得します。各ディスク分のVMDKファイル, isoファイル, mf, ovfファイルが生成されます。

STEP2. Google Cloud Storageへのアップロード

取得したファイルをGoogle Cloud Storage (GCS)へアップロードします。今回はisoは不要ですが、フォルダごとアップロードしました。

これで前準備完了です。

STEP3. bootディスクイメージの作成

GCPのコンソールで“Compute Engine > イメージ”を開き、“[+] イメージを作成” をクリックして、以下のようにVMDKファイルを指定し、作成を行います

STEP4. Buildを待つ (Boot ディスク)

Buildを待ちます。ワクワクしますね。ビルドには30–40分程度かかるので、気長に待ちましょう。CloudBuildからログを確認することができます。

Build完了しました。

STEP5. dataディスクイメージの作成

Step6と同様の手順で、今度は2つ目のVMDKファイルをインポートします。今回はDataディスクなので、”オペレーティングシステムなし”を選択します。

STEP6. Buildを待つ (Dataディスク)

Buildを待ちます。ウキウキしますね。

今回も無事完了しました。Dataディスクなので、OS有りのディスクの時よりも早く終わっています。

STEP7. Dataディスクの作成

“Compute Engine > ディスク”の画面を開き、”ディスクの作成”画面を開きます。先ほど作成したイメージを元に、Dataディスクを作成します。

Dataディスクも無事完成しました。

STEP8. GCEインスタンスの作成

VMDKのイメージ化/ディスク化ができたので、インスタンスを作成していきます。(“Compute Engine > VMインスタンス”の”インスタンス作成”)

まずは、ブートディスクに、先ほど作成したBootディスクイメージを指定します。なお、GCPのブートディスクは10GB以上である必要があるので、元のディスクは8GBでしたが、今回は10GBとしました。

ちなみに、Created by Daisyと記載ありますが、これはオープンソースのワークフローToolの名前です。裏ではこれが動いているようです。

続けて、Diskの設定画面で、”既存のディスクを接続”を選択し、先ほど作成したDataディスクを追加し、インスタンスを作成します。

あとはお好みの設定を加えて、作成ボタンを押します。

インスタンスが出来上がりました。

STEP9. GCEインスタンスの確認

コンソール画面のsshボタンをクリックしてログインしてみます。ログインができるまでに時間がかかることがあるので、失敗したら何度かリトライしてみてください。

Importの過程を経て、いくつかGCP用のdaemonが起動していることがわかります。

[root@centos72-vmdk-import ~]# ps -ef|grep google|grep -v greproot 2921 1 0 20:21 ? 00:00:00 /usr/bin/python /usr/bin/google_network_daemonroot 2923 1 0 20:21 ? 00:00:00 /usr/bin/python /usr/bin/google_clock_skew_daemonroot 2925 1 0 20:21 ? 00:00:00 /usr/bin/python /usr/bin/google_accounts_daemon

もちろんIPも変わっています。

[root@centos72-vmdk-import ~]# ifconfig |head -2eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460inet 10.146.0.45 netmask 255.255.255.255 broadcast 10.146.0.45

Dataディスクに保存していたデータも無事移行されてきています。

[root@centos72-vmdk-import ~]# mount /dev/sdb1 /mnt/sdb1/
[root@centos72-vmdk-import ~]# ll /mnt/sdb1/disk.raw 
-rw-r--r--. 1 root root 8589934592 Dec  4 22:39 /mnt/sdb1/disk.raw
[root@centos72-vmdk-import ~]#

OVFによるインポート(*)

STEP1, 2はVMDKインポートと同じなので(というか同じになるようにしました)、STEP3から試していきます。

STEP3. Importコマンドを走らせる

OVFインポートはCloud Shellを開いてコマンドラインで行います。

— source-uriオプション(必須): OVFファイルのパス、またはOVFを保存しているディレクトリーのパスを指定します。
— osオプション: 指定した方が無難(時間がかかるのでこけた時のリトライがだるい)なので、Image familyをみて適切なものを選びます。今回は “centos-7” を指定しました
— zoneオプション: デフォルトのゾーンを設定していないと以下のように怒られるので無難に今回は明示的に指定しておきましょう(asia-northeast1-c)。

You may set it for your current workspace by running:$ gcloud config set compute/zone VALUEor it can be set temporarily by the environment variable [CLOUDSDK_COMPUTE_ZONE]

ということで、実行します。(※ディレクトリは正しいものに置き換えてください)

gcloud compute instances import centos72-ovf-import \
--source-uri=gs://$bucket_name/$dir_name/  \
--os=centos-7 \
--zone=asia-northeast1-c

STEP4. Buildを待つ

Buildを待ちます。ドキドキしますね。以下のように、40分かかるそうなので、気長に待ちます。VMDKの時と同様、Buildの進捗はCloud Buildから確認することができます。

WARNING: Importing OVF. This may take 40 minutes for smaller OVFs and up to a couple of hours for larger OVFs.

Build完了すると、GCEインスタンスが立ち上がります。

STEP5. GCEインスタンスの確認

VMDK単体でのインポートの時とは違い、ブートディスク + 追加ディスク(Dataディスク)の両方が同時にインポートされています。

もちろんdata ディスクに保管していたデータの中身も無事移行されていますね。

[root@centos72-vmdk-import ~]# mount /dev/sdb1 /mnt/sdb1/
[root@centos72-vmdk-import ~]# ll /mnt/sdb1/disk.raw 
-rw-r--r--. 1 root root 8589934592 Dec  4 22:39 /mnt/sdb1/disk.raw
[root@centos72-vmdk-import ~]#

Migrate for Compute Engineによるインポート(*)

最後に、移行ツール、Migrate for Compute Engine(M4CE)を使った移行を試してみましょう。

なお、ここでは以下の条件を満たしている状態からスタートするものとします。

移行先となるGCPプロジェクトのセットアップができている
移行元のVMware環境と移行先GCPプロジェクトがInterconnect or VPNで接続されている
通信要件を満たしている

STEP1. サービスアカウントの設定

GCP側のコンポーネント (Manager, Cloud Extension)に使うサービスアカウントを作成します。細かい手順は公式ドキュメントを参照いただければと思いますが、Cloud Shellを使ってコマンドラインから適切なサービスアカウントを作ることができます。

$ cd /google/migrate/gce
$ python3 velostrata_sa_roles.py -p project-ID -d deployment-name [-o organization]

STEP2. Managerのデプロイ/ログイン

Market PlaceでMigrate for Compute Engineを開きます。

推定費用 $99.97/月とありますが、ツール自体は無料です。コンポーネントをデプロイするGCEインスタンスやNW, Storage料金などは発生します。

開いたら必要項目を入力してデプロイします。

API password, encryption passwordは、デプロイしたあとGCPコンソールから見えてしまうので、他で使っているようなPWは用いないことをお勧めします。
“Comma separated network tags” は、デプロイするManagerにアタッチされるネットワークタグです。NW要件を満たすよう事前にネットワークタグを作っておきましょう

デプロイが完了したら、GCEインスタンスが立ち上がります。

ブラウザを開き、インスタンスの外部IPにhttps接続します。ユーザ名とPWを聞かれるので、以下のように入力します。

ユーザ名: apiuser (固定)
PW: 先ほど設定したもの

初回ログイン時は、ログイン後、ログの保存等に関して問われますので、Yes/Noを選択します。あとでも変更は可能です。そうすると、ManagerのHome画面にたどり着きます。ここまできたら、一旦Manager側の作業は終了です。

STEP3. Backendのデプロイ/起動

こちらのページからBackendのOVAファイルをダウンロードし、vSphere環境にデプロイしていきます。

途中でTokenを聞かれるので、そこまできたらManagerの画面に戻ります。

Managerの”SYSTEM SETTINGS”の画面から、Create Tokenを押してTokenを取得し、貼ってください。

なおTokenの有効期限は90minとありますが、これはTokenを入力するまでではなく、Tokenが実際に使われるまでです。TokenはBackendを立ち上げたタイミングで使われるので、90min以内にDeployを完了し、Backendを立ち上げるところまで進める必要があります。仮想マシン deploy後のToken変更はできず、仮想マシンを再作成する必要が出てくるのでご注意ください。

5分ぐらいでデプロイ完了します。出来上がったので起動します。

STEP4. Backend-Managerの疎通確認

ManagerのSYSTEM SETTINGに戻ると、BackendとManagerが繋がっていることが確認できます。

この時点で繋がっていない場合は、オンプレ/GCP間でうまく疎通ができていない可能性があるので、NW設定を確認し直してください。Backendにはadminというユーザでログインできるので、ログインしてtelnet等で確認するのも有効かと思います。

STEP5. vCenter Pluginの登録

Managerの画面から、vCenter Pluginを登録します。Security Waringが出ますが、確認の上Connectをクリックし、登録を完了します。

STEP6. vCenter Pluginの登録確認

vCenterに戻って、一度ログアウトして入り直します。するとM4CEのプラグインが登録されており、Migrate for GCE Operationsを選択できるようになっていることが確認できます。(Datacenterのところで右クリック)

STEP7. Cloud Extensionの登録

上の画像の通り、”Add Cloud Extension”を選択し、必要項目を入力してCloud Extensionをデプロイしていきます。

“Edge Network Tags”は、Cloud Extensionのネットワークタグです。通信要件を満たすタグをアタッチするようにしてください。
Service Account for Cloud Edgeは、最初に作成したCloud Extension用のServiceアカウントを入力してください (プルダウンで表示されるものは少し表記が異なる可能性があるので、近いものを選択してください)
Edgeは2つデプロイされますが、可用性担保のため異なるZoneにデプロイします

デプロイが完了すると、DatacenterのSummaryのMigrate for GCE Cloud Extensionのところから状態を確認することができます。

Cloud ExtensionはGCP上にデプロイされるコンポーネントなので、GCP上でデプロイされていることも確認できます。

また、同様の作業はManagerの画面でも行えますし、Cloud ExtensionのStatusの確認も行うことができます。

STEP8. 必要パッケージのインストール実施(Linuxの場合のみ)

今回は対象OSがCentOS7.2なので、こちらの手順にしたがってパッケージのインストールをする必要があります。今回はM4CE4.8.1なので、以下のコマンドで実施しました。

$ yum install https://storage.googleapis.com/velostrata-release/4.8.1/migrate-for-gce-prep-4.8.1-0.redhat.x86_64.rpm

前準備はここまでで終わりです。ここから実際の以降作業を行なっていきます。

STEP9. Run in Cloud の実施

vCenterで、移行したい仮想マシンを右クリックし、Migration for GCE Operations > Run In Cloud を実行します。

必要項目を入力し、スタートします。この過程で、vSphere側の仮想マシンはShutdownされます。

仮想マシンのサイズやNWの状態にもよるのでなんとも言えませんが、今回のケースだとRun in Cloudが終わるまでに7分かかりました。

終了すると、対象の仮想マシンのSummary画面のCloud Instance Informationに、この仮想マシンの状態が表示されます。

繰り返しになりますが、今の状態は、仮想マシンデータはオンプレにあるが、仮想マシンのコンピュート部分はGCEインスタンスとして稼働してる状態です。前回の記事の図の再掲ですが、以下の状態です。

また、GCP側を見ても、対象の仮想マシンがGCP側に立ち上げられていることが確認できます。

STEP10. Data Migrationの実施

仮想マシンの実際のデータをGCP側に転送します。

データ以降の進捗は仮想マシンのSummary画面のCloud Instance Informationから確認できます。

終わりました。

今回の場合は、18GBのサイズの仮想マシンのData Migrationに8分かかりました。18GB分フルフルで仮想マシンが使っているわけではないので、実質のデータ量でいうと10GBぐらいですかね。

STEP11. Prepare to Detachの実施

Prepare to Detachを実施します。

実際にディスクをGCE側にセットする準備です。このタイミングでDisk Typeを選択します。

進捗はおなじみの場所で確認できます。今回は9分で終わりました。

STEP12. Detachの実施

では、Detachします。このタイミングで一度GCEインスタンスは再起動します。

同じく進捗はここから確認できます。今回は5分で終わりました。

STEP13. Clean upの実施

移行対象の仮想マシンはM4CEの管理下にあるため、アイコンも他と少し変わっています。最後にClean upをすることで、この仮想マシンをM4CEの管理下から外してやります。

4分で終了しました。おかえり！

すでに移行が完了している仮想マシンなので、煮るなり焼くなりしてもいいですし、検証用として残してもいいかと思います。

なお今回は解説のために一工程ずつ行いましたが、Runbookを使って自動化することで移行の手間を軽減することもできます。

気をつけたいポイント

移行作業の中で、ハマりやすいポイントを書いておきます。

移行後、OSは立ち上がっているようだけど、コンソール画面からssh接続ができない

GCP側のFWに問題がない場合、OS側のFWが弾いている可能性があります。インポート前にOS側のFWを確認することをお勧めします。プライベートIP接続のみを許可している場合、オンプレ側からプライベート接続を試してみるのも良いかと思います。

M4CEの設定中に、BackendやManagerを作り直したところ、手順通り進めなくなった。どうしたらいいですか？

作り直しが必要となります。手順に従い、1から再作成してください。VMware側に既にPluginを追加してしまった場合、こちらの手順に従いPluginを削除し、vCenterを再起動する必要があります。 (僕は何度かハマりました)

M4CEのRun in Cloudが途中で止まります。どうやって確認したらいいですか。

Stackdriverからログを確認します。また、BackendやManagerに直接ログインをしてログ(/var/log/velostrata/ など)を確認するのも参考になるかと思います。

うまくいかない原因で多いのは、NW接続です。マイグレーション系は一つ一つが時間がかかるので、NW疎通は事前に確実に確認しておくようにしましょう。

著者

(左) Shohei Okada (Google Cloud, Customer Engineer, Infrastructure Modernization Specialist), (右) Ren Nikuma (Google Cloud, Professional Services, Cloud Consultant)

※このブログに記載している内容は、Google Cloud公式のものではなく、個人的見解です
※このブログに記載している内容は、執筆時点(2019/12)での公式ドキュメントや、その他公開されている情報に基づいています