ワークロードのマイグレーション   

本節では、VM インスタンスのマイグレーション パターンについて解説します。なお、コンテナライズされたアプリケーションではなく、物理サーバーや 仮想化プラットフォーム の環境に構築されたワークロードをマイグレーションする前提で説明します。

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 の移行をスムーズに進めるためのポイントを紹介します。

設計前に検討しておくべきポイント

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

　　- Dedicate Interconnect

　　- Partner Interconnect

　　　・Cloud VPN

各サービスとも 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 へ移行するための手法としてどのような方法があるかを解説します。

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 サブネットと同一サブネットにすることはできません。）


利点


注意事項

参照文献

仮想マシンの 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 を利用した場合を前提に解説します。

コンポーネントとしては、移行元の 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 バケットに格納：ユーザーからは確認できません）のデータ課金が継続されるため注意が必要です。

インフラ レイヤの移行について、大きな流れは上記のとおりですが、移行元の環境、移行するインスタンスによって移行手順が異なります。一般的には、このあとアプリケーション レイヤの稼働確認へと続きます。また、プロダクト アップデートなどで必要な作業に変更が出る可能性もあるので、公式ドキュメントの最新情報を必ず確認してください。


利点


注意事項



参照文献