GCPのマイグレーション方法についてまとめてみた
この記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 8番目の記事です。
今回は既存の環境(オンプレミス/クラウド)で動かしている仮想マシンを、ツールなどを用いて丸ごとクラウド移行する方法について解説していきます。
なお本記事では、マイグレーション方法のコンセプトに関して説明をし、補足記事で実際の移行作業を試していきたいと思います。
GCPへの移行手段の概要
GCPには、既存の仮想マシン内部の状態をそのままに保ったまま、丸ごとGoogle Compute Engine (GCE)に移行するための手段が幾つか用意されています。まずは移行手段の概要について一つずつみていきましょう。
インポート機能を利用した移行
- 仮想ディスクインポート (インポートツール)
既存の環境で仮想ディスクを取得し、それをGCPへインポートしてイメージを作成、それを元にGCE上にインスタンスを立ち上げるやり方です。VMDK、VHD、RAWなどに対応しています。
2. 仮想ディスクインポート(手動)
仮想ディスクのインポートには、上述のインポートツールを使用することが推奨されていますが、ツールがサポートしているOSでないと、インポートツールが正しく動作しません。その場合、手動インポートを使用することで移行できることがあります。
この移行方法では、Boot loaderなど諸々設定の変更を手動で行なったのち、以下のコマンドでdisk.rawファイルを生成、そしてそれを元に手動でイメージを作成し、GCEインスタンスを起動する流れとなります。
sudo dd if=/dev/sda of=/tmp/disk.raw bs=4M conv=sparse3. OVF/OVAのインポート
OVF/OVAファイルをインポートし、GCEインスタンスを起動することができます。上記の仮想ディスクインポートでは、ディスク単位のインポートなりますが、これを使うと仮想マシンにアタッチされている複数のディスクをまとめてインポートできます。
なお、OVF/OVAの説明は以下の通りです。
- OVFパッケージ は、仮想マシンを定義するファイルエレメントとメタデータ、およびそのパッケージ内のアプリケーションの配備および動作に必要な追加情報で構成されます。ファイル拡張子は .ovf です。
- OVA（Open Virtual Appliance） は単一のファイルアーカイブにまとめられたOVFパッケージで、拡張子は .ova です。
移行ツールを利用した移行
GCPでは、仮想マシンを効率的かつ短時間で移行する為の移行ツールを2つ提供しています。
- Migrate for Compute Engine (旧名: Velostrata)
Migrate for Compute Engine (以下M4CE)は、基本的には仮想マシンから仮想マシンへの(V2V)の移行ツールですが、物理サーバにも利用が可能です。
このツールには以下のような特徴があります。
- 仮想マシンデータの転送を始める前に、移行対象のワークロードがGCEインスタンスで正しく起動するかどうかをチェックすることが可能(Run in Cloud)。これにより「時間をかけて移行したがインスタンスが起動しない！」というリスクを事前に排除することが可能
- データ転送におけるトラフィックは暗号化される為、セキュアなデータ転送が可能
- データ転送時、パケットが自動的に圧縮されるため、ツールを使わずにデータを転送するよりも転送時間を短縮できる
- 複数の移行元環境をサポート (vSphere/AWS/Azure)
- 仮想マシンの構成情報を元に、GCEインスタンスの最適なサイズを自動で推奨してくれる
- Runbookを用いて、複数の仮想マシンの移行の自動化が可能
2. Migrate for Anthos
Migrate for Anthosは、仮想マシンで動いているワークロードを、Google Kubernetes Engine (GKE)へ移行するツールです。以下のような特徴があります。
- 仮想マシンのユーザー領域をコンテナ化し、GKE上にデプロイする
- 複数の移行元環境をサポート(GCE/vSphere/Azure/AWS)
その他の移行方法
公式な移行方法は上記の通りですが、他にもサードパーティー製の移行ツールを使うなど、移行手段は用意されています。
また、先日のTaigaさんの記事にあったNested VMなどを使うことで、サポート範囲外のOS等を持ち込むこともできます。
この場合は、GCE上に立てるHypervisorがサポートするイメージ形式で持ち込みを行うこととなります。例えば、先日の記事のようにkvmを用いてGCE上で仮想化を行った場合は、qcow2など、kvmからみてインポート可能なファイルで仮想マシンを持ち込むことができます。
ただし、これはイレギュラーな移行方法ですし、構成も複雑化します。問題が起きたときの切り分けを簡易化するためにも、よほどの理由がない限り、正攻法で仮想マシンを移行することを推奨します。
Migrate for Compute Engine詳細
上記で概要を説明した移行ツール、Migrate for Compute Engine(M4CE)について、もう少し詳細を説明していきます。まずは、構成の概要図を載せておきます。ここから一つずつみていきましょう。
NW要件
移行元と移行先のGCPプロジェクトは、専用線またはVPNで接続されている必要があります。また、NW要件がいくつかあり、満たしていないと移行過程でこけてしまうので、確実に確認しておきましょう。
登場人物
上の図で出てきている、M4CE用の各コンポーネント(赤色のアイコン)について、一つずつ役割を説明していきます。
- Migrate for Compute Engine Manager
GCPの移行先プロジェクトに立てるManagerです。vCenter1台につき、1台のマネージャが必要となります。このマネージャーは移行先のGCPプロジェクトにMarket Placeからデプロイを行います。移行元とのコネクション管理など、M4CE全体の管理を行ってくれます。
- Migrate for Compute Engine Backend
vSphere側(移行元)に立てます。GoogleのウェブサイトからダウンロードできるOVAを使ってデプロイを行います。デプロイしたBackendは、vCenter, ESXiとコミュニケーションを取りながら、GCPへのデータ転送の役割を担います。なお、M4CEが正しく動作するために、BackendはESXiホストへの名前解決ができる必要があります。
・Migrate for Compute Engine Cloud Extension (edge)
GCPの移行先プロジェクトにデプロイします。Backendは、このCloud Extensionとコミュニケーションを取りながら移行処理を進めます。なお、Cloud Extensionは移行処理が一定期間、移行処理が行われないと自動的に停止するようになっています
移行の流れ
移行の流れ(Online Migration)は以下の通りです。
- Run in Cloud
vSphere上の仮想マシンのVMDKを、GCEインスタンスに対してiSCSIで接続し、インスタンスを起動します。これにより、仮想ハードディスクはvSphere上にあるが、NIC, CPU, MemoryなどのリソースはGCPの物を利用している状態になります。この過程で、GuestOSがGCP上で正常に起動するかどうかを、データを転送することなく事前に確認することが可能です。
2. Data Migration
次に仮想マシンデータ(VMDK)をデータ転送を開始します。この時、VMDKデータはGCSに転送されます。Run in Cloudの際に立ち上げたインスタンスは、このData Migrationの実施中も引き続き利用することができます。
3. Prepare for Detach
データ転送がある程度完了すると、vSphere上の仮想マシンとGCPのインスタンスを切り離すための準備の操作を行います。このタイミング初めて、移行後のGCEインスタンスでどの永続ディスク(Persistent Disk: PD)を使うかの選択します(HDD or SDD)。一部推察も入りますが、このタイミングで、GCSに転送したデータをPDへ転送し始めるものと思われます。
4. Detach
vSphere上の仮想マシンとGCPのインスタンスの切り離しを行います。この過程では、仮想マシンデータの最終転送や、GCE用のモジュールをGuestOSに組み込む作業などが行われます。
5. Clean Up
M4CEで移行を実行している間、vSphere上の仮想マシンはM4CEによって制御されている状態となります。この状態では、仮想マシン操作はvSphere Web ClientのM4CE拡張機能から行う必要があります。
Clean Upを行うと、制御下から外れ、vSphere上の仮想マシンとして操作を行うことが可能になります。
移行オプション
- Online Migration / Offline Migration
Onlineマイグレーションでも、移行のはじめと移行の終わりのタイミングで移行元インスタンスが数回再起動されるのでご注意ください。また、古いOSなどはOffline Migrationしかサポートしていないので、サポートされているOSをご確認ください。
- Migration Waveを使った自動化
Migration Waveを設定し、上の各工程を複数台に対して自動実行することができます。
移行にあたり意外と気になるTIPS
- WindowsOS等を利用している場合、ライセンスはどうなるの？
自動的にGoogleのSPLA(従量課金モデル)に自動変換されます。詳しくはこちらをご確認ください。
また、BYOLをしたい場合は、ライセンスの規約の確認をして下さい。多くの場合は、Sole Tenant Node上にInstanceを作成する必要があります。詳しくはこちらをご確認ください。
- Windows Server 2012など、GCPのOSイメージで提供されていないOSは動かせますか？
動かせます。例えばM4CEではWindows Server 2003まで、移行できます。ただし、サポート切れのOSは、クラウド移行を機にバージョンアップすることを推奨しています。
- Amazon Linux等は流石に無理だよね
可能です。少し特別な設定は必要ですが、M4CEを使うことで、実現できます。詳しくはサポートOSページを確認下さい。
著者
※このブログに記載している内容は、Google Cloud公式のものではなく、個人的見解です※このブログに記載している内容は、執筆時点(2019/12)での公式ドキュメントや、その他公開されている情報に基づいています次の記事(9番目)はJinさんのGKE で GCE Ingress + gRPC アプリケーションのヘルスチェックをどうにかするです！お楽しみにー！
