みなさん、こんにちは。
Google Cloud でインフラ周りを担当する Customer Enginner をしている Takao です。
このBlogは、 vExpert Advent Calendar 2022 の12/5分の2つ目として公開しています。 Google Cloud Japan としての Advent Calendar の投稿に混ざり込んでスミマセン。
11/15-16に開催されたVMwareさんの年次イベント VMware Explore Japan で行わせていただいた、このBlogと同タイトルのセッションについて、オトナの事情でイベントサイト内で資料を公開できていないため、ほぼ同じ内容をこちらで公開してしまおいうという投稿となります…。
アカウントの登録が必要となりますが、イベントの動画はVMware Explore Japanのウェブサイトで2022/12/23まで公開されています。
Google Cloud VMware Engine (GCVE) は Google Cloud のサービスの中で唯一、オンプレミスで同等の仕組みを構成頂くことができるサービスです。…というか、逆に、オンプレミスでご利用頂いているVMware vSphere環境と同じ構成を「Google Cloudの中で」ご利用頂くことができるようにしたサービスです。
そんなわけで、オンプレミスでVMware vSphereに親しんできた人にとってはGCVEはオンプレミスで培った経験やノウハウ、ナレッジを活かせるソリューションとなるのですが、利用者にとってオンプレミスとの最大の違いは物理的なサーバに触ることもできなければ見ることすらできない、という点ではないでしょうか。
Google Cloudの他のサービスは、そもそもGoogle Cloudでしか利用できないものなので、提供された構成を「そういうものだ」と受け入れることができるでしょうが、GCVEの場合はオンプレミスでもVMware vSphereを利用してきただけに、下図のようになっていますと説明されても、従来オンプレミスでの利用時に設計・管理してきた物理サーバの構成図や、物理・論理のネットワーク構成図、VMware vSphereのパラメータシートなどとはだいぶ異なっているために「えっ？」と戸惑われる方も多いのではないかと思っています。
VMware Engine > Documentation > Guides > About VMware Engine Networks より借用
そこで、このBlogでは、2022/11に開催された VMware Explore Japan 2022 でのGoogle Cloudによる同タイトルのセッションをベースに、GCVEのネットワーク周りについてまとめてご紹介したいと思います。項目ごとにまとめてトグル化しておきますので、気になる部分だけを参照頂いても問題ありません。
GCVE のネットワーク
Private Cloud の初期展開
GCVEを初めて使用する場合、まず最初に行うことはPrivate Cloudの作成です。GCVEにおいて、Private Cloudとは、vCenter ServerおよびNSX Managerの管理範囲を示します。
あえて複数のPrivate Cloudを展開することも可能ですが、一般的には、多くのお客様は1つのPrivate Cloudを利用されています。ただし、Private Cloudが管理可能な範囲はリージョンに限定されるため、複数リージョンでGCVEを利用したい場合には、それぞれのリージョンでPrivate Cloudを展開する必要があります。
下図で赤枠で囲った範囲が、1つのPrivate Cloudです。Private Cloud毎に、vCenter Server、 ESXiホスト、NSX Manager、DNS Serverが必ず展開されます（HCXについては、使用しない場合は展開しないことが可能です）。
各Private Cloudには、<guid>.<region>.gve.goog 形式で一意のプライベートDNSゾーンが設定されます。Private Cloud内に展開される全てのマネージドリソースはこのドメインに紐付けられます。
なお、Private Cloudを展開すると、同時にNSXを利用するオーバーレイネットワークも構成され、Tier-0 GWと、１つ目のTier-1 GWが構成済の状態から利用を開始できます。
下図のスクリーンショットが、Private Cloudを展開する際のパラメータの全てです。基本的には以下の５項目の指定だけでPrivate Cloudを展開できます。
- Private Cloud名
- ロケーション
- ESXi ホスト台数
- 管理用ネットワークSubnet Prefix (/21〜/24)
- HCX用ネットワークSubnet Prefix (/26〜/27) ※オプション
ESXiホストで展開可能な台数が3〜8台となっている理由は、シングルノードクラスタ利用の場合を除きサポートされるクラスタサイズが最低3台からであるためと、この環境においてGCVEリソースの割り当て（Quota)上限が8となっているためです。
パラメータの中で指定した管理用ネットワークSubnet PrefixのCIDR範囲は、そのまま使用されるのではなく、実際には複数のSubnetに分割されて利用されます。下図は 10.1.0.0/22 を指定した場合の例となります。特に初期構築後に拡張の可能性がある場合には、指定するCIDRサイズに注意してください。
なお、2022/11にこのセッションを提供した後、2022/11/17にGCVE向けのIPプランバージョン2が発表され、CIDR指定におけるサイジング設計上の考慮点に多少の変更がありましたので、こちらを合わせて確認ください。
VPC との接続
Private Cloudの展開時には同時に最初のClusterの展開も行っているため、GCVEとしての基本展開は既に完了しています。次に行うことは、お客様のVPCとの接続です。GCVEに対する管理通信はもちろん、GCVE環境のVMからGoogle Cloudの他のサービスやオンプレミスとの通信などのためにもVPCとの接続は必要となるため、基本的にVPCとの接続は必須事項です。
GCVEのPrivate CloudとVPCを接続するためには、プライベートサービス接続（もしくはプライベートサービスアクセス、PSA）という仕組みを利用します。プライベートサービス接続は、お客様自身が管理するVPCとGoogle Cloudが管理するVPC間の接続の場合に利用される仕組みです。GCVEのPrivate Cloudは、お客様から認識可能にはなっていませんが実体としてはGoogle Cloudが管理するVPCを経由してお客様のVPCと接続する実装となっているため、プライベートサービス接続が用いられます。
プライベートサービス接続を利用する場合でも、通信要件としてはお客様管理のVPC同士を接続するVPC Peeringの場合と同等となります。つまり、VPCとGCVE Private Cloudの間はIP重複ができず、必ずL3での接続となります。
プライベートサービス接続としてGCVEをVPCに接続した場合でも、接続に関するパラメータとしてはVPC Peeringとして構成が行われます（対向のVPCは自動的に"servicenetworking-googleapis-com"という名称になります）。
このプライベートサービス接続の構成に伴って自動的に作成されたVPC Peeringのパラメータにおいて、「カスタムルートのインポート」および「カスタムルートのエクスポート」を有効化することで、GCVEのPrivate Cloud側のSubnet情報がVPC側にインポートされ、VPC側のSubnet情報やVPCに紐づくCloud Routerが動的に学習したオンプレミス側などのルート情報がGCVEのPrivate Cloud側にエクスポートされるようになります。この設定は一度行ってしまえば、それ以降に追加で構成されたSubnet情報などは自動的に相互に伝えられるため、Subnetの追加のたびにこの操作を行う必要性はありません。
この図では、オンプレミスも含めたプライベートIPアドレス空間全体のアドレス構成がどのようになるのかについての概念図を示しています。この図に示したように、オンプレミス側、VPC、プライベートサービス接続、Private Cloudの４つの領域は、それぞれ重複のないSubnet範囲であることが必要であり、事実上これら４つの領域間はL3ルーティングでの接続となります。唯一の例外はGCVEとオンプレミスの間でL2延伸を構成した場合ですが、こちらは別途ご説明します。このように、GCVEのPrivate Cloudに対しては、他の領域で利用されていないSubnet範囲の利用が必要となります。
プライベートサービス接続を利用する場合、お客様指定のプライベートIP空間を利用しつつもGoogle Cloud側によって管理される範囲があります。下図は、GCVE利用の場合における、Google Cloud側が管理する範囲を示しています。
この青枠で囲われた範囲については、利用するIPアドレス範囲についてはお客様が指定可能ですが、リソース自体についてはお客様側での管理操作はできません。逆に言えば、この青枠の範囲のリソースについては、Google Cloud側が責任を持って面倒を見てくれるともいえます。
オンプレミスとの接続
GCVE自体にはオンプレミスとの接続のための機能はありません。
え？と思われた方、ご安心を。一つ前の"VPCとの接続"において詳細を説明していますが、GCVEのPrivate Cloudはお客様のVPCと接続できるため、VPCとオンプレミスとの間が専用線サービスであるCloud InterconnectもしくはVPN接続サービスであるCloud VPNなどで接続されていれば、その接続をGCVEに対しても利用できるので、GCVE自体にはオンプレミスとの接続の機能は必要ないのです。
このように、GCVEはVPCとオンプレミスの間の接続を利用しますので、概念的にはオンプレミス側から見るとGCVEはお客様のVPCのさらに向う側にあるようなイメージになります。
GCVEを利用する場合に１つだけ対応が必要な点が、VPCに紐付けられたCloud Routerにおいて、カスタムルートとしてGCVEで利用しているSubnet範囲を設定する必要があります。これにより、Cloud Routerは対向のオンプレミス側のルータに対してGCVEのSubnet範囲もアドバタイズするため、結果的にオンプレミス側のネットワークからGCVE宛の通信もCloud Routerに送信されることとなり、オンプレミス・VPC・GCVE Private Cloudの間の通信が成立します。
オンプレミス側からはネットワーク的にGCVEもGoogle Cloudの一部として認識されることとなるため、管理面においても通信の流れとしてもシンプルに利用頂けると思います。
Internet との接続
Internetの利用には、内→外と外→内がありますので、それぞれにわけて説明します。
まず、GCVE上に展開されたVMなどからのInternetへの外向き通信についてです。こちらについては、構成するルーティングの構成次第で下図の赤・黃・緑の３パターンがあります。
GCVEにおいて、Internet Gatewayというパラメータを有効化した場合には、赤の経路が利用されます。この場合、Internet GatewayにはNAT（PAT）機能が備わっているため、プライベートIPしか設定されていないGCVE上のVMからのInternet通信は自動的にInternet Gatewayで外部アドレスに変換されて通信が行われます。
黄は、GCVEのPrivate Cloudと接続されたVPC側のInternet接続経路であるDefault Internet Gatewayを利用するパターンです。この場合、VPC用として用意されているCloud NATはGCVE VMに対しては直接利用できないため、Google Compute Engine (GCE）インスタンスを用いてProxyを構成するなどの対応が必要となります。
緑は、オンプレミス側のInternet接続経路をGCVE VMからも利用するパターンです。この場合、オンプレミス側から0.0.0.0/0のデフォルトルートをVPCを通じてGCVE Private Cloudにアドバタイズする構成が必要となります。このパターンは、GCVE VMからの通信に対してもオンプレミス側のファイアウォールなどを経由させる必要性がある場合や、オンプレミス側のProxyを利用する場合などに利用します。
つづいて、Internet側からGCVE VMへのアクセスを受け付ける内向き通信についてです。この場合も、下図のように赤・黃・緑の３つのパターンがあります。
赤は、Internet Gatewayに付随して利用可能なPublic IP Serviceを有効化した場合の経路です。この場合、Public IP Serviceにおいて確保した特定の外部IPアドレス宛の通信を、GCVE範囲の特定のIPアドレス宛に転送することでInternetからの通信を受け付けます。GCVE上に配置した仮想アプライアンスのロードバランサなどに転送することも可能です。
黃は、VPCを経由するパターンです。この利用ケースとしては、別途ロードバランスの項目で説明するTraffic Directorを経由した通信の場合などが該当します。
緑は、オンプレミス側を経由してInternetからの通信を受け付ける場合です。この場合、オンプレミス側でのセキュリティ確保などの対応に加えて、外向き通信の場合と同様にオンプレミス側からGoogle CloudのVPCへのデフォルトルートのアドバタイズが必要です。
Google Cloud サービスとの接続
Google Cloudには、非常に多くのサービスがあり、ユーザから見るとInternetを経由して利用するようなサービスの場合であっても、GCVEにとってはそうではありません。なぜならば、GCVEもGoogle Cloudの中にあるからです。Google Cloudの他のサービスに対してInternetを経由することなく接続ができる点は、GCVEをご利用頂くメリットの１つと言えます。
まずは、プライベートなIPアドレスで接続が可能なサービスとの接続から見ていきましょう（すでに説明済みのVPC内のリソースとの接続は除きます）。
Google Cloudにおいて、Cloud SQLやCloud Filestoreなど内部IPアドレスで利用可能なマネージドサービスは基本的にGCVEと同じ様にプライベートサービス接続を利用してVPCと接続されています。よって、GCVEがプライベートサービス接続で接続しているVPCと同じVPCにこれらのマネージドサービスも同じプライベートサービス接続で接続頂くことで、GCVE VMからもCloud SQLやCloud Filestoreなどへのプライベート接続が可能となります。
続いて、外部IPアドレスでのみアクセスが可能なサービスとの接続についてです。下図では、その代表例として、データウェアハウスサービスであるBigQueryとCloud Spannerを例としています。これらのサービスはVPCの外部に存在しますが、Google Cloudの内部に存在しますのでGoogle CloudからはInternetを経由することなく接続できます。
下図で赤のInternet Gatewayを経由する経路を利用している場合には、自動的に「限定公開のGoogleアクセス」が機能しており、GCVE VMからの接続はGoogle Cloud内部通信として接続されます。黃のVPC側Default Internet Gatewayを経由する場合には、ProxyとなるGCEインスタンスの接続するSubnetにおいて限定公開のGoogleアクセスが有効になっていることで、同じくGoogle Cloud内部通信としての接続が可能となります。
セキュリティ
GCVEが備えているセキュリティの１つ目は、GCVEとして備えているファイアウォール機能についてです。
まずは、NSXのFirewall機能です。NSXには、Tier-0 GWおよびTier-1 GWのゲートウェイで適用されるゲートウェイファイアウォールと、ESXiホスト側で分散して適用される分散ファイアウォールが提供されていますが、GCVEにおいてもこれらをもちろん利用してセキュリティをNSXとして構成頂けます。
また、GCVE VMに対してInternetからの接続を構成するPublic IP ServiceにはGCVEとしてステートフルなファイアウォールが提供されており、L4のポート番号制御が構成可能です。
続いてセキュリティのために利用できる構成パターンについてです。
下図の左側は、NSXのTier-1 GWを分離することで通信を区分する構成です。GCVEでは、ユーザが自由にTier-1 GWを作成できるので、Tier-1 GWをネットワーク境界として利用する構成が可能です。右側は、Tier-1 GWの配下にVMware vSphere環境での利用をサポートするVMベースの仮想ファイアウォールアプライアンスを利用する構成です。使い慣れたファイアウォールが仮想アプライアンスとして提供されている場合には、このような構成を取ることももちろん可能です。
最後は「この様な構成もやろうと思えばできる」的な紹介です。下図では、VPC側のインスタンスでファイアウォールアプライアンスを実行し、GCVE側のTier-1 GWなどとの間でIPsec VPNを構成することで、複数のGCVE Private CloudおよびGCVE以外のVPC側Subnetなどを含む環境に対して一元的なファイアウォールを提供する構成例です。
Private Cloud単位で適切に構成を行うことで同等の結果を得ることはできますので、このような構成が必要なケースは限られるかと思いますが、柔軟性を示す一例として紹介させて頂きました。
ロードバランス
最初のパターンは、NSX Advanced Load Balancer (ALB）の利用パターンです。
ALBは残念ながらNSXの標準機能ではありませんので、GCVEとして提供しているNSXにALBは含まれていませんが、お客様が購入されたALBをGCVEでご利用頂くことは可能です。
２番めのバターンは、Google Cloudが提供するTraffic DirectorとCloud Load Balancingの利用パターンです。
２０２２/１１時点ではGoogle Cloudが提供するフルマネージドなロードバランシングサービスであるCloud Load Balancingのバックエンドとして直接GCVE VMを紐付ける構成はサポートされていないのですが、Traffic Directorと呼ばれるアプリケーションの通信制御を行うService Meshの仕組みのコントロールプレーン部分をマネージドサービス化したサービスを組み合わせることで、ロードバランシングを構成頂くことが可能です。
Traffic Directorはコントロールプレーン部分がマネージドサービスとなっており、実際のトラフィック制御を行うリソースとしては、Envoyを導入したGCEインスタンスなどを利用します。ただし、これらのリソースもコマンドオプション１つで展開が可能です。Traffic Directorによって制御される通信制御用のリソースをService Proxyと呼びます。Service Proxy自体には構成ファイルなどのパラメータは保持されず、全ての構成はTraffic Directorから適用されます。そのため、Service Proxy用のインスタンスは負荷や可用性の要件に基づいて簡単にノード数を増減させることが可能です（実際には、GCEのマネージドインスタンスグループという仕組みが利用されます）。
しかし、Service Proxyのノード数が増減したりすると、ユーザからのアクセス先はどう１つに維持すればよいのでしょうか？そこで、Service Proxyの前段にCloud Load Balancingを配置します。これによって、ユーザからの接続先IPアドレスは１つのVIPに集約されますし、Service Proxyの台数の増減にも自動的に対応することが可能です。VIP宛に届いたトラフィックはService Proxyに振り分けられ、Service Proxyはさらに実際のサービス提供の実体であるGCVE VMなどのリソースにトラフィックを振り分けるという二段階構成です。
このような構成とすることで、Cloud Load BalancingもしくはTraffic Directorの段階でGCVE VM以外のリソース（Google Cloudの他のサービスや、オンプレミスのサーバ、外部のサービスなど）を組み合わせてロードバランス先のバックエンドとして構成することが可能となるため、GCVEとそれ以外とを組み合わせたサービスを社内外に対して提供する仕組みを構成できます。
ここで紹介した構成は、紙芝居方式ではありますが、VMwareさんのHands-on Lab (HOL)でお試し頂けます。また、Medium Blogにおいてももう少し詳細を解説したBlogを書いていますので、合わせて参照ください。
オンプレミスとのL2接続
GCVEにはHCX Enterpriseが標準で含まれているため、GCVE環境とお客様のオンプレミス側のVMware vSphere環境との間でL2延伸を構成したり、VM移行のための接続を行ったりすることが可能です。
この際にオンプレミス側にもHCXを展開する必要性がありますが、GCVEとの間でHCXによる接続を行うオンプレミス側のHCXについてもGCVEの提供範囲に含まれるため、別途オンプレミス用のライセンスをご用意頂く必要性はありません。
GCVEで提供されるHCXは以前はAdvancedであったため、VM移行およびL2延伸の基本機能のみが利用可能でしたが、Enterpriseが利用できるようになったことで、多数のVM移行時に役立つReplication Assisted vMotion (RAV)や、L2延伸構成時におけるL3通信経路を最適化するMobility Optimized Networking (MON)などの最適化のための機能を含め、HCXの全機能を活用いただけます。
また、何らかの理由でHCXを利用できない場合には、NSXのAutonomous Edge仮想アプライアンスを用いたL2VPN接続の構成もご利用いただけます。
DNSとしての接続
最初にGCVEに対する管理接続において必要となるDNS接続について説明します。
GCVEのPrivate Cloudではサービスの一部としてDNSサーバが含まれており、GCVEのサービスリソース(vCenter Server, ESXi Host, NSX Manager, HCX, DNS)は全て<guid>.<region>.gve.googというプライベートDNSゾーンで名前管理されます。
そのため、VPCやオンプレミス側からvCenter ServerやNSX Managerの管理画面に接続するためには、GCVEのDNSサーバを通じた名前解決が利用できる必要性があります。
Cloud DNSが構成済のVPCとの間でGCVEのPrivate Cloudをプライベートサービス接続した場合には、自動的にDNS Peeringが構成され、Cloud DNSを利用するVPC内のGCEインスタンスなどのリソースからGCVE Private Cloud内のリソースに対する名前解決が可能となります。
一方、オンプレミス環境などに別途DNSサーバがある場合には、GCVEのプライベートDNSゾーンに対する条件付きフォワーダを設定頂く等により、GCVE Private Cloudの<guid>.<region>.gve.googゾーンが名前解決されるように構成する必要があります。
つづいて、GCVE VMにおけるDNS設定について説明します。
GCVE VMにおいては、お客様が利用されている既存のDNSサーバやVPC内にGCEで構成したDNSサーバなどを直接参照するように構成頂くことが推奨となります（上図の緑、青、黒の矢印のパターン）。注意点としては、GCVE上のVMからはVPCに紐づくCloud DNSの直接的な参照はできない点です（プライベートサービス接続によって構成されるVPC Peering経由では、受信サーバポリシーを構成してもCloud DNSによるインバウンド転送は利用できない仕様のためです。ただし、上述の通りCloud DNSではなくVPC側にVMインスタンスとして構成したDNSサーバ等のGCVE VMからの参照利用は可能です）。
また、GCVEの一部として提供されているDNSサーバは、送信DNSルールとして条件付きフォワーダを設定できるため、GCVE VMからの名前解決用のDNSサーバとして利用頂くことも可能ですが、ユーザによるゾーン管理などはできないため、GCVEの管理リソース用のDNSサーバとしてのみ利用されることをおすすめします。
Private Cloud 範囲を超えた接続
GCVEでは同一リージョンに複数のPrivate Cloudを展開することも可能です。たとえば、同じリージョンを利用するが、何かしらの理由により管理するvCenter Serverを分離したい場合などです。この場合、Private Cloud間の通信は同一リージョン内通信となるため、高帯域低遅延な接続を無料でご利用いただけます。また、同一リージョン内のGCEインスタンスなどとの通信についても無料です。
続いて、異なるリージョンにそれぞれGCVEのPrivate Cloudを展開した場合です。この場合、Private Cloud間の通信はリージョン間通信となりますが、2022/11時点では課金対象となっていません。ただし、これは将来において変更される可能性があります。また、Private Cloud間以外のGoogle Cloudの別リージョンのリソースに対する通信に対しては、Google Cloudにおいて共通で設定されているリージョン間通信の料金が適用されます。
先に料金の話になってしまいましたが、いちばん重要なポイントはGoogle Cloudにおいてはリージョン間通信はVPC間通信ではない、という点です。
つまり、VPCがリージョンに閉じている他のPublic Cloudとは異なり、Google CloudのVPCはグローバルリソースであるため、そのVPCにプライベートサービス接続で接続するGCVEにおいてもそのメリットは同じ様に活かすことができ、複数のRegionにGCVEを展開した場合でも追加の構成など行うことなく１つのプライベートネットワークとして利用いただけます。
フルマネージドクラウドストレージサービスとの接続
2022/11時点で、パートナーとの協業に基づくフルマネージドクラウドストレージサービスとしては、NetApp Cloud Volumes Service (CVS)と、Dell Cloud PowerScaleの２つが提供されています。これらのサービスの接続形態は"Google Cloudサービスとの接続"におけるプライベート接続可能なパターンと同様に、プライベートサービス接続を利用して接続する構成のため、同様にGCVE VMからも利用(作成したボリュームのマウント利用)が可能です。
なお、2022/11時点でNetApp CVSは東京リージョンでの提供が開始されていますが、Dell Cloud PowerScaleについては未提供です。
複数VPCとの接続
Google CloudのVPCはグローバルリソースであるため、多くのケースにおいて分ける必要性はないのですが、何らかの理由でVPCが別れている構成において、GCVEはIPアドレスの重複がないことを条件として複数のVPCとの接続が可能です（2022/11時点では基本的に３つまでのVPCと接続が可能です）。
以上を踏まえて、以下の公式のガイドをお読みいただくと、より理解が進むかと思いますので、ぜひ以下も合わせて参考ください。よりGCVEのネットワーク周りについての理解が進むかと思います。
- Google Cloud VMware Engine のプライベート クラウド ネットワーキング
- アーキテクチャ: 一元管理されたアプライアンスを使用した VMware Engine ネットワーク セキュリティ
まとめ
GCVEに関して、ネットワークの観点から１２のトピックを見てきました。Google Cloudの中で提供されるVMware vSphere仮想化基盤であるGCVEが、どのようにGoogle Cloudの中でネットワーク的に接続され、Google Cloudの他のサービスや、オンプレミスなどと接続しているのか、少しでもこのBlogが皆様のGCVEに対する理解を深めて頂く助けになれば幸いです。
GCVEを利用するメリットは、マネージドサービスであることや、利用開始後も継続的に進化し続けることなど、様々な側面がありますが、なんと行ってもGCVEならではの特徴と言える点は、GCVEがネットワーク的にGoogle Cloudの中にある、という点だと思います。これによって、GCVE VMからGoogle Cloudのサービスを利用したり、組み合わせて利用したり、アプリケーションによってはよりクラウドネイティブな仕組みへと移行していくステップとしてGCVEを活用するなど、単なるVMware vSphere仮想化基盤に留まらない様々な使い方ができます。
ここに書いた内容も、今後、改善されたり新しい機能が提供されたりすることによって変化していくはずです。必ず合わせて最新の情報を確認してください。
Discussion