Google Cloud Japan Advent Calendar 2024 16 日目の記事です！
TL;DR
- VMware Engine は Google Cloud ファーストパーティの IaaS として活用できます
- VMware Engine のアーキテクチャを理解する上では、Google Cloud サービスとしてどのようにデプロイされるか、vSphere クラスタとしてどのように構成されているか、の双方の視点で知ることが有効です
- Google Cloud と VMware ソリューションの組み合わせにより提供できるメリットがいくつかあります
はじめに
2020 年にリリースされた Google Cloud VMware Engine ですが、昨年ネットワーク、デプロイ方法が刷新され、より Google Cloud ライクな運用ができるようになりました。そして、今年大きなアップデートもいくつかあったため、改めて Google Cloud VMware Engine のメリットとアーキテクチャの概要について解説しようと思います。
Google Cloud VMware Engine とは
まずはじめに改めて Google Cloud VMware Engine （GCVE）とはどういったソリューションなのかを簡単におさらいしましょう。
- Google Cloud がファースト パーティとして提供する VMware as a Service であり、vSphere ベースの VM をイメージ変換をすることなく、Google Cloud 上に展開される vSphere クラスタに移行することができる
- vSphere クラスタを構成する ESXi ホストはお客様専用サーバ ハードウェアとして展開される
- Google Cloud の課金の仕組みによって支払いを完結できる（他の Google Cloud サービスと同様に請求先アカウントを通して一括で購入、支払いが可能）
- サポートについても、カスタマーケア、または認定パートナーが提供する Google Cloud サポートサービスを通して、一元的に提供される
VMware ベースの運用を維持しながら契約からデプロイ、運用までを一貫して Google Cloud の仕組みを通じて提供を受けることができる Google Cloud の IaaS サービスの一つということになります。
VMware Engine のコンポーネント
VMware Engine は、Google Cloud データセンター内に VMware vSphere をベースした Software-Defined Data Center（SDDC） を展開する形で提供されています。SDDC の展開と 外部との接続は Google Cloud Console 上から行うことが可能で、SDDC の展開後の vSphere クラスタでの運用は SDDC 展開時に払い出される vCenter 及び NSX Manager からオンプレミス環境と同様に行うことができます。
実際に構成の検討、設計及び構築を頂く上では、エンジニアのみなさんが「この設定はシステムにおいてどのコンポーネントに影響を与えるのか」ということを理解頂けることが非常に重要だと考えています。
そこで、上記のような GCVE の特性を考慮して、以下の 3 つの観点からアーキテクチャを解説していきます。
1）Google Cloud VMware Engine 全体フレームワーク
2) VMware Engine と他のサービス、オンプレミスとの接続
3）VMware Engine で展開される SDDC コンポーネント
Google Cloud VMware Engine 全体フレームワーク
VMware Engine は他の Google Cloud サービスと同様にコンピュート サービスの一つとして お客様のGoogle Cloud プロジェクト内に展開されます。プロジェクトはお客様が Google Cloud のすべてのサービスを利用する際に基礎となる管理単位です。
Google Cloud Console の VMware Engine セクションより VMware Engine Console にアクセスして、その中で展開する SDDC 環境を定義します。GCVE では展開される SDDC 環境をプライベート クラウドと呼んでいます。下の図の「VMware Engine Service」の部分が展開されるプライベート クラウド環境の範囲です。
VMware Engine と他のサービス、オンプレミスとの接続
実際に VMware Engine を活用する上では多くの場合、VMware Engine の vSphere クラスタ上の VM とオンプレミス環境、または他のパブリック クラウドとの相互接続、また、他の Google Cloud のサービスとの連携などが必要になるでしょう。
VMware Engine からの接続は、VMware Engine Network とお客様が作成する VPC を ピアリングすることで簡単に接続をすることができます。 VPC ピアリング時に Exchange custome routes セクションで import custome routes export custome routes のチェックボックスをいれることで VPC ピアリングを設定すると双方のネットワークが保持しているサブネット情報が交換されます。
Google Cloud では、オンプレミス環境との接続には、Cloud Interconnect または Cloud VPN を利用してハイブリッド接続を、AWS、Azureなどのパブリック クラウドとの直接接続をする場合には、Cross-Cloud Interconnect を利用します。VMware Engine 環境とのトラフィックも、特別なネットワークを新たに追加したり、ルーティングするためのコンポーネントを準備することなくこれらのハイブリッド接続を利用して、VPC ピアリング経由でシームレスに接続が可能です。（Cloud Interconnect や Cloud VPN を終端する Cloud Router にて VMware Engine Network が保持しているサブネット情報をカスタムルートで 接続先へルート広報をすることは必要）
シンプルなネットワークの構築ができることは、VMware Engine を活用いただく 1 つの大きなメリットになっています。
VMware Engine で展開される SDDC コンポーネント
プライベート クラウドを展開するとデプロイされる主要なコンポーネントを紹介していきましょう。
-
GCVE プライベート クラウド（Private Cloud）
VMware vSAN ストレージ クラスタ、VMware NSX による仮想ネットワークが展開された * VMware ESXi ホストクラスタを VMware Engine では プライベート クラウドと呼ぶ -
SDDC 管理コンポーネント群（Management Resources）
展開されたプライベート クラウドを管理するためにデプロイされた VMware vCenter Server 、NSX Manager などの管理系サービス -
VMware Engine Network（VEN）
VMware Engine クラスタから Google Cloud 各サービス、Google Cloud 外へのアクセスを確立するための VMware Engine 専用のVPC ネットワーク
プライベート クラウドでは、お客様が専有できる ハードウェア上に vSphere SDDC 環境として、VMware vSAN、VMware NSX、VCF Operations HCX（旧 VMware HCX、以下 VMware HCX と記載） が構成されます。
VMware Engine を展開する際にデプロイされる各ソリューションのバージョンは以下の通りです。（2024 年 12 月現在）
- VMware vSphere Enterprise Plus 7.0 u3
- VMware vSAN (vSAN)6.7U3
- VMware NSX Enterprise 3.2.3.1
- VMware HCX 4.6.2
詳細はプライベート クラウド VMware コンポーネント をご確認ください。
プライベート クラウドをデプロイする際に ESXi ホストとしてデプロイするノードタイプをve1 Node Type、ve2 Node Type から選択することが可能で、ve2 Node Type については必要なスペックに応じて CPU コア、メモリ、vSAN を構成する際に利用するストレージ容量を選択することができます。東京リージョンでは現状、ve1 Node Type (ve1-standard-72) のみの提供となります（2024 年 12 月現在）。
また、各ノードタイプには Storage Only Node というストレージ専用ノードをクラスタに追加することが可能です。Storage Only Node は通常のノード（区別するために HCI Node と呼んだりします）と同様にクラスタに追加することができますが、CPU、メモリは クラスタとして利用できないため、ストレージ領域を多く必要なケースに活用できます。Storage Only Node 用の価格も設定されているため、その分コストを最適化しながら vSAN ストレージの高いスループットを活用することが可能です。
そして、展開される ESXi ホストは、展開されたタイミングですでにストレージ及び NSX ネットワークの設定が完了した状態でデプロイされています。
- VMware vSAN ストレージ クラスタ
- VMware NSX オーバレイ ネットワーク （分散仮想スイッチ）
** vDefend Distributed Firewall による East-West ネットワーク セキュリティの提供 - VMware NSX Edge
** ルーティング、North-South ファイアウォールなどを担うネットワーク ゲートウェイ（T0、T1 Router を仮想ルータを提供するアプライアンス）
VMware Engine における vSphere クラスタのネットワーク アーキテクチャ
ここからは VMware Engine のプライベート クラウドにおける vSphere クラスタがどのような構成で展開がされるかをネットワークの観点から紐解いてみます。 vSphere クラスタの構成をサブネット構成を意識して記載してみると以下のようになります。（vSphere クラスタ間の通信で完結する vMotion、vSAN サブネットは割愛）
Management Networks
Management Networks には、SDDC 環境の運用、管理に必要となる以下のコンポーネントが自動的にデプロイされます。
- VMware vCenter Server Appliance
- VMware NSX Manager
- VMware HCX Manager
- VMware ESXi ホスト（管理 NIC ）
上記のように VMware Engine Console からそれぞれの管理コンポーネントの FQDN 及び管理 IP アドレスを確認することができます。vCenter Server、NSX Manager、HCX Manager へのアクセスはこちらのリンクからアクセスをすることが可能です。ただし、これらの FQDN にはセキュリティの観点からデフォルトではインターネット経由ではアクセスできません。Customer VPC と VPC ピアリングを行った後に IAP などを利用して 踏み台サーバ経由でアクセスするか、ハイブリッド接続を経由して Cloud Interconnect または Cloud VPN 経由でアクセスすることを推奨しています。
Service Networks
Service Networks はオプションで利用することができるアンダーレイ ネットワークです。デプロイ時に Service-[1-5] の5つのネットワークが利用可能となっており、主にバックアップや DR などのサードパーティ アプリケーション アプライアンスなどをデプロイする際に利用することができます。アプライアンス VM のインターフェースをオーバレイ ネットワークである Compute Networks とは別に Service Networks に接続することで、サービス サブネットを介した VM 通信は、VMware ESXi ホストから Google Cloud ネットワーキング インフラストラクチャに直接接続され、高速通信が可能になります。
Compute Networks
また、展開される ESXi ホストは、展開されたタイミングですでにストレージ及び NSX ネットワークの設定が完了した状態でデプロイされています。
- VMware vSAN ストレージ クラスタ
- VMware NSX オーバレイ ネットワーク （分散仮想スイッチ）
** vDefend Distributed Firewall による East-West ネットワーク セキュリティの提供 - VMware NSX Edge
** ルーティング、North-South ファイアウォールなどを担うネットワーク ゲートウェイ（T0、T1 Router を仮想ルータを提供するアプライアンス）
上記の図の Compute Networks は VMware NSX で構成されるオーバレイ ネットワークとなっており、ユーザが NSX Manager からセグメントとして自由にサブネットを設定することができます。このセグメント情報は、vCenter 上からも 分散仮想スイッチ上に自動的に連携され、VM をデプロイする際にそのセグメントを指定することが可能になります。
GCVE プライベート クラウドに展開される ESXi ホスト クラスタにおいて、VMware NSX が構成するオーバレイ ネットワーク（仮想論理ネットワーク）、アンダーレイ ネットワーク（物理ネットワーク）の観点で論理構成図を記載すると以下のようになります。
プライベート クラウドを展開した時点で、オーバレイ ネットワークを構成する 分散仮想スイッチ（VDS）がすでに構成されていますので、お客様は以下のような手順で VM を展開することが可能になります。
1）NSX Manager で NSX 分散仮想スイッチにアタッチするユーザ セグメントを定義して、任意のプライベート サブネットを割り当てる
2）vCenter Server で 割り当てたサブネットに vNIC をアタッチして VM をデプロイする
といった手順で VM を展開することが可能になります。
GCVE のネットワーキングのコンセプトや主要な通信フローなどについては、VMware Engine ネットワークについて に詳細が解説されておりますので、こちらもご参照ください。
VMware Engine を利用するメリット
最後にアーキテクチャの観点で触れることができなかった VMware Engine を活用することで得られるメリットを 3 つあげておきたいと思います。
- vCenter による運用を継続できる
- vCenter 管理者権限相当のアカウントが利用できる
- ボトルネックなしで Google Cloud サービスとシームレスに統合
以下でそれぞれのメリットについて解説をしていきたいと思います。
vCenter による運用を継続できる
この点は VMware Engine に限らず VMware as a Service 全般のメリットとなりますが、 既存の vSphere 環境においてクラスターの管理で利用してきた vCenter での運用をそのまま継続することが可能です。VMware Engine クラスタをデプロイしてしまえば、その後の VM の展開は vCenter を利用して行うことができます。また、VMware Cloud Foundation Operations HCX
（旧 VMware HCX ）を利用して VMDK（vSphere の仮想マシンディスク）ベースでそのまま VM を移行していくことも可能であり、学習コストを最低限に抑えながら、Google Cloud へのワークロードの移行、運用の継続が可能となります。
vCenter 管理者権限相当のアカウントが利用できる
この点は VMware Engine に限らず VMware as a Service 全般のメリットとなりますが、 VMware Engine では通常の vSphere クラスタの運用を行うための vCenter アカウント（Cloud Owner）の他に、vCenter 管理者権限を必要とする場合に利用することができるソリューション ユーザ アカウント（Solution User）が用意されています。
（VMware Engine の vCenter にビルトインされているアカウントのため、Google Cloud IAM での権限管理、Cloud Identity による ID 管理の仕組みとも別の仕組みとして提供されています。）
| アカウント | クラウド オーナー アカウント | ソリューション ユーザ アカウント |
|---|---|---|
| アカウント名 | CloudOwner@gve.local | Solution-user0[1-5]@gve.local |
| 利用用途 | 通常の プライベート クラウド（GCVE 上の クラスタ）の運用 Cloud-Owner-Role 以下の権限をユーザグループに対して適用可能 | VMware 各ソリューション、サード パーティ ツール、ソフトウェアなどの管理者権限を必要とする場合にのみ利用できる（Cloud-Owner-Role よりも強い権限を保持） |
| 留意点 | 禁止された操作を検出した場合には、環境保全のために禁止操作の修正、変更が行われます |
ソリューション ユーザを利用することにより、従来の VMware as a Service では連携ができなかった vCenter 管理者権限を必要とするサードパーティ ソリューションとの連携が可能となり、オンプレミス環境で利用していたエコシステムをそのまま Google Cloud 上でも利用できるようになることでハイブリッド クラウド での運用も容易になります。
なお、ソリューション ユーザは非常に強い権限を持っていることから、システム連携以外での通常の運用で利用することは推奨されていません。また、VMware Engine には 禁止されたオペレーション が定義されており、 Google Cloud サポートでもそのステータスを監視しています。
ボトルネックなしで Google Cloud サービスとシームレスに統合
VMware Engine は専有ホスト型の IaaS サービスである特性上、お客様の VPC とは別の Google Cloud が管理する環境に展開されますが、VPC ピアリングによる プライベート コネクションによりユーザが管理する VPC とシンプルに接続することで、100Gbps をベースとするボトルネックのない高速な通信が可能になります。また、VMware Engine Network では限定公開の Google アクセスが有効になっていますので、VMware Engine 上の VM から Google Cloud API サービス（Cloud Stroge や BigQuery など）へインターネットを介することなく Google のネットワーク内で通信を完結することも可能です。
また、Private Service Access を利用して、Cloud SQL や Filestore といった Google Managed VPC へアクセスをすることが可能です。
データ活用の推進、生成 AI の活用をいち早く推進したいお客様にとっては、大量のデータの移行を行いつつ、VM、アプリケーションの大きな改修ができない基幹システムなどをいち早くVMware Engine 並行し、その後、VM、アプリケーションのモダナイゼーションを進めて行くと行ったアプローチもしやすくなります。
まとめ
今回は、VMware Engine を構成するコンポーネント、ネットワークを含めたアーキテクチャを幾つかの角度から解説してきました。
冒頭にも解説したとおり、VMware Engine は Google Cloud の IaaS サービスとして展開をされ、Google Cloud の他のサービスを含めた外部との接続設定までを VMware Engine Console で設定します。一方、展開された プライベート クラウド環境はオンプレミスと同様、VMware vCenter、NSX Manager を活用した運用が可能となっています。
アーキテクチャの観点からVMware Engine をご理解頂くことによって、Google Cloud を今までご利用頂いたことがないユーザでも、新たにキャッチアップする必要があるポイントが比較的シンプルに理解することができると思います。そして、実際の VM の運用については使い慣れた vCenter Server、NSX Manager をオンプレミス環境と同様に利用することができるので学習コストはそれほど高くなく利用を開始することができます。
このブログを通して、Google Cloud のメリットと VMware ソリューションの双方のメリットを享受できる VMware Engine の活用に向けた検討の一助になればと思います。
Discussion