Google Cloud VMware Engine のプライベート クラウド ネットワーキング

初回公開日: 2021 年 1 月 25 日

このドキュメントでは、Google Cloud VMware Engine の概要について説明します。ネットワーキングのコンセプト、最も一般的なトラフィック フローの確認、VMware Engine を使用してアーキテクチャを設計する際に考慮すべき点について解説します。また、VMware Engine の仕組み、その機能、最適なアーキテクチャを決定する際に考慮すべき点についても説明します。

このドキュメントは、VMware でホスティングするアプリケーションのセキュリティ、接続、可用性の設計、維持、トラブルシューティングを担当するネットワーク エンジニア、クラウド エンジニア、アーキテクト、または運用担当者を対象としています。

このドキュメントでは、VMware Engine とその要件と機能について詳しく学ぶことができます。このテクノロジーを詳しく調べるだけでなく、試験運用を行う場合や本番環境にデプロイする際にも、VMware Engine の仕組みと、新規または既存の Google Cloud 環境に統合する方法を理解するのに役立ちます。このドキュメントでは、ネットワークに関するあらゆる側面を検討し、ユースケースに最適なソリューションの選び方を説明します。

VMware Engine ネットワーキングは、オンプレミス ネットワークや他の Google Cloud サービスとの間の Virtual Private Cloud(VPC)ネットワークと統合されます。VMware Engine は、高性能、信頼性、大容量のインフラストラクチャを基盤に構築され、費用対効果に優れた VMware エクスペリエンスを提供します。

概要

VMware Engine は、Google Cloud への VMware ワークロードの移行と実行を支援する Google 提供のサービスです。

VMware Engine は、VMware vSpherevCenter ServervSANNSX-T から構成されるフルマネージドの VMware ソフトウェア定義データセンター(SDDC)を提供します。VMware Engine では、企業の本番環境ワークロードをサポートするため、Google Cloud 上の専用の環境でクラウド移行用の HCX を提供しています。VMware Engine を使用すると、Google Cloud Console から専用の VMware 環境に直接接続して、オンプレミスのワークロードを Google Cloud に移行または拡張できます。これにより、アプリケーションのリファクタリングに伴う費用や複雑さに煩わされることなく、クラウドへの移行を行い、オンプレミス環境と一貫性のある方法でワークロードを実行し、管理できます。Google Cloud で VMware ワークロードを実行すると、スケーリングとアジリティの利点を生かしながら運用の負担を軽減し、既存のツール、ポリシー、プロセスを継続して使用できます。

VMware Engine は、Google Cloud の高性能でスケーラブルなインフラストラクチャ上に構築されています。完全に冗長な 100 Gbps の専用ネットワークを備え、VMware スタックの要件を満たすために最大 99.99% の可用性を提供します。Cloud InterconnectCloud VPN などのクラウド ネットワーキング サービスにより、オンプレミス環境からクラウドに簡単にアクセスできます。クラウド サービスとの接続では高帯域幅が使用され、コストと運用のオーバーヘッドを最小限に抑えながら、最適なパフォーマンスと柔軟性を提供します。エンドツーエンドのワンストップ サポートが統合され、このサービスと Google Cloud の機能全体でシームレスなエクスペリエンスが提供されます。

ワークロードを移行すると、BigQuery、Cloud Operations、Cloud Storage、Anthos、Cloud AI などの Google Cloud サービスにアクセスできます。Google Cloud では請求と Identity and Access Management が完全に統合されているため、他の Google Cloud プロダクトやサービスと統一されたエクスペリエンスが提供されます。

ユースケース

次の図は、Google Cloud サービスの利点を活かしつつ、VMware 環境を Google Cloud に移行または拡張する方法を示す代表的なリファレンス アーキテクチャです。VMware Engine は、次のユースケースのソリューションとなります。

VMware 環境を Google Cloud に移行または拡張する方法を示すリファレンス アーキテクチャ。

オンボーディング要件

Google Cloud に VMware Engine をデプロイする前に、オンボーディング要件を必ずお読みください。

システム コンポーネント

大まかにみると、VMware Engine には次のコンポーネントがあります。

  • Google Cloud:
    • VMware Engine:
      • NSX-T
      • HCX
      • vCenter
      • vSAN
    • Google Cloud の組織:
      • VPC ネットワークを持つ Google Cloud プロジェクト
      • Partner Interconnect または Dedicated Interconnect を使用する Cloud Interconnect、オンプレミス システムとの Cloud VPN 接続
      • VMware Engine リージョンへのプライベート サービス アクセス
    • プライベート サービス アクセス接続
    • Google マネージド サービスの統合
  • (省略可)オンプレミス リソース:
    • ネットワーキング
    • ストレージ
    • HCX(L2 接続では推奨。L2 ストレッチともいいます)
    • vCenter

プライベート クラウドは分離された VMware スタックで、ESXi ホスト、vCenter、vSAN、NSX-T、HCX から構成されます。これらのコンポーネントはまとめて Google Cloud VMware Engine コンポーネントと呼ばれ、クラウド管理者がプライベート クラウドを作成するときにデプロイされます。これにより、組織内のユーザーがプライベート サービス アクセス接続を確立し、VPC ネットワークから VMware Engine プライベート クラウドに非公開でアクセスできるようになります。次の図は、このアーキテクチャを示しています。

プライベート サービス アクセス。

プライベート サービス アクセスは、VPC ネットワークと Google またはサードパーティが所有するネットワークとのプライベート接続です。Google またはサードパーティ(サービスを提供しているエンティティ)は、サービス プロデューサーとも呼ばれます。

Google Cloud でプライベート サービス アクセス接続を作成するときに、VMware Engine に接続しているお客様の VPC ネットワークごとに 1 つのサービス プロデューサー VPC ネットワークが作成されます。このプロジェクトには、Cloud SQL や Memorystore などの他の Google Cloud サービスへの接続に使用できる共有 VPC ネットワークがあります。

オンプレミスで NSX-T を使用する必要はありません。また、どのユースケースでも HCX を使用する必要はありません。他の方法で、レイヤ 2(L2)の拡張とワークロードの移行を行うことができます。ただし、ワークロードの移行を効率的に行い、利便性を高めるために、HCX の使用をおすすめします。この機能は、プライベート クラウドの作成中に自動的にデプロイされます。つまり、使用するかどうかに関係なく、HCX はデプロイされます。

ネットワーク機能

以下に、VMware Engine のネットワーク機能の概要を示します。

  • サブネット: プライベート クラウドに管理用とワークロード用のサブネットを作成できます。
  • 動的ルーティング: NSX が管理する VMware Engine サブネットは、Border Gateway Protocol(BGP)により、他の Google ネットワークとオンプレミス ロケーションに自動的にアドバタイズされます。
  • パブリック IP サービスとインターネット ゲートウェイ(上りと下り、内向きと外向き): VMware Engine は、インターネット ゲートウェイの上り(内向き)と下り(外向き)用に独自のパブリック IP サービスを使用します。これはリージョン サービスです。
  • ファイアウォール ポリシー: VMware Engine では、NSX 分散ファイアウォール(East-West)と NSX ゲートウェイ ファイアウォール(North-South)を使用して、L4 / L7 ファイアウォール ポリシーを作成できます。たとえば、ウェブサーバーなどのパブリック IP アドレスでワークロードにアクセスする場合、きめ細かい制御を行うことができます。
  • East-West セキュリティのサービス チェーン: パートナー セキュリティ ソリューション(IDS、IPS、NGFW)を登録して、VM 間を移動する East-West トラフィックを検査できるようにネットワーク サービスを構成します。
  • NSX-T Distributed Intrusion Detection Service(IDS): VMware Engine で実行される NSX は、脅威の検出と報告を行う NSX Distributed IDS に対応しています。この機能を使用するには、VMware の追加ライセンスが必要です。詳細については、VMware NSX Distributed IDS/IPS をご覧ください。
  • エンドポイントの保護: サポートされているサードパーティとのパートナー統合により、VMware Engine を基盤とする VM をマルウェアやウイルスから保護できます。詳細については、VMware の公式ドキュメントをご覧ください。
  • 他の Google サービスとのプライベート アクセス: VMware Engine は、限定公開の Google アクセスとプライベート サービス アクセスを使用して、他の Google Cloud サービスと統合されます。サポートされているサービスの一覧については、サービスのプライベート アクセス オプションをご覧ください。
  • DNS プロファイル
    • 管理用の DNS: すべてのプライベート クラウドに対して、VMware Engine は自動的に DNS サーバーのペアをデプロイし、さまざまな管理コンポーネント(vCenter、NSX Manager など)を解決します。
    • ワークロード用の DNS: プライベート クラウドごとに最適な DNS 設定を判断します。NSX-T DNS サービスを使用すると、DNS クエリを特定の DNS サーバーに転送できます。また、VMware またはオンプレミスに DNS サーバーを構築することも、Cloud DNS を使用することもできます。
  • DHCP サーバー: NSX-T セグメントに対する DHCP サーバーのサポートが含まれます。
  • DHCP リレー: DHCP リレーを使用すると、オンプレミスの IP アドレス管理(IPAM)システムと統合できます。
  • ポイント対サイト VPN: ポイント対サイト VPN ゲートウェイを使用すると、リモートから VMware Engine ネットワークに接続し、クライアント コンピュータからプライベート クラウドに接続できます。コンピュータから VMware Engine に接続するには VPN クライアントが必要です。Windows の場合は OpenVPN クライアント、macOS の場合は Viscosity をダウンロードして使用できます。
  • サイト間 L2 VPN と L3 VPN: これらのサービスは、それぞれ L2VPN と IPsec VPN を使用して NSX で直接構成されます。
  • 負荷分散: NSX-T の組み込み負荷分散機能を使用します。これには、L4 と L7 のサポートやヘルスチェックが含まれます。
  • 部分的な IP マルチキャスト ルーティングのサポート: VMware のドキュメントに記載されているように、プロトコルに依存しないマルチキャスト(PIM)がサポートされます。
  • IPv6 の部分的なサポート: この機能を使用すると、NSX-T 3.0 設計ガイドに記載されているように、VMware Engine 対応アプリケーションで IPv6 を利用できます。
  • 長距離 VM 移行(vMotion): WAN 最適化、暗号化、レプリケーションを含むモビリティ機能が搭載されている VMware Engine では、オンプレミス / クラウド間またはクラウド間でライブ移行(アプリケーションを実行しながらの移行)とコールド移行(アプリケーションをパワーオフした状態での移行)の両方がサポートされています。これは、サービスに VMware HCX が含まれていることで実現されています。
  • 高度なネットワーク運用: 組み込みの NSX ツールとインストルメンテーション(ポート ミラーリング、トレースフロー、パケット キャプチャ、ポーリングとトラップを備えた SNMP v1/v2/v3 など)を使用できます。

ネットワークとアドレス範囲

Google Cloud VMware Engine は、VMware Engine サービスがデプロイされているリージョンごとにネットワークを作成します。ネットワークは単一の TCP レイヤ 3 アドレス空間で、デフォルトでルーティングが有効になっています。このリージョンに作成するすべてのプライベート クラウドとサブネットは追加構成なしで通信可能になります。ワークロードの仮想マシンに NSX-T を使用してネットワーク セグメント(サブネット)を作成できます。オンプレミス ネットワーク、プライベート クラウドの管理ネットワーク、または VPC サブネットと重複しない RFC 1918 アドレス範囲を構成できます。

デフォルトでは、すべてのサブネットが相互に通信できるため、プライベート クラウド間のルーティングの構成オーバーヘッドが削減されます。同じリージョン内のプライベート クラウド間で発生するデータ トラフィックは同じレイヤ 3 ネットワーク内にとどまり、リージョン内のローカル ネットワーク インフラストラクチャを介して転送されます。このため、プライベート クラウド間の通信に下り(外向き)は必要ありません。このアプローチにより、異なるプライベート クラウドに異なるワークロードをデプロイする際の WAN / 下り(外向き)のパフォーマンスの低下を防いでいます。

概念的には、プライベート クラウドは vCenter Server の管理下にある分離された VMware スタック(ESXi ホスト、vCenter、vSAN、NSX)環境として作成されます。管理コンポーネントは、vSphere / vSAN サブネットの CIDR 範囲用に選択されたネットワークにデプロイされます。ネットワークの CIDR 範囲は、デプロイ中に異なるサブネットに分割されます。

VMware Engine の管理サブネット

VMware Engine はいくつかの IP アドレス範囲を使用します。一部の IP アドレス範囲は必須であり、デプロイするサービスに依存します。IP アドレス空間は、オンプレミスのサブネット、VPC サブネット、計画したワークロード サブネットのいずれとも重複しないようにする必要があります。以降のセクションでは、アドレス範囲とそれを使用するサービスについて説明します。

次の図は、以降のセクションで説明するサービスの管理サブネットをまとめたものです。

管理サブネット。

vSphere / vSAN の CIDR

プライベート クラウドを初期化して作成するには、次の IP アドレス範囲が必要です。

名前 説明 アドレス範囲
vSphere / vSAN の CIDR VMware 管理ネットワークの場合は必須です。プライベート クラウドの作成時に指定する必要があります。vMotion でも必要です。 /21/22/23、または /24

プライベート クラウドを作成すると、複数の管理サブネットが自動的に作成されます。管理サブネットは、このドキュメントですでに説明している vSphere または vSAN の CIDR 割り当てを使用します。次に、この CIDR 範囲を使用して作成されるサブネットのアーキテクチャと例を示します。

  • システム管理: ESXi ホストの管理ネットワーク、DNS サーバー、vCenter Server の VLAN とサブネット。
  • vMotion: ESXi ホストの vMotion ネットワーク用の VLAN とサブネット。
  • vSAN: ESXi ホストの vSAN ネットワークの VLAN とサブネット。
  • NsxtEdgeUplink1: 外部ネットワークへの VLAN アップリンク用の VLAN とサブネット。
  • NsxtEdgeUplink2: 外部ネットワークへの VLAN アップリンク用の VLAN とサブネット。
  • NsxtEdgeTransport: NSX-T のレイヤ 2 ネットワークのリーチを制御するトランスポート ゾーン用の VLAN とサブネット。
  • NsxtHostTransport: ホスト トランスポート ゾーン用の VLAN とサブネット。

例:

指定した vSphere / vSAN サブネットの CIDR 範囲は複数のサブネットに分割されます。以下の表に、192.168.0.0 を CIDR 範囲とする有効なプリフィックス(/21 から /24 まで)の内訳を示します。

指定された vSphere / vSAN サブネット CIDR / プレフィックス 192.168.0.0/21 192.168.0.0/22 192.168.0.0/23 192.168.0.0/24
システム管理 192.168.0.0/24 192.168.0.0/24 192.168.0.0/25 192.168.0.0/26
vMotion 192.168.1.0/24 192.168.1.0/25 192.168.0.128/26 192.168.0.64/27
vSAN 192.168.2.0/24 192.168.1.128/25 192.168.0.192/26 192.168.0.96/27
NSX-T ホスト トランスポート 192.168.4.0/23 192.168.2.0/24 192.168.1.0/25 192.168.0.128/26
NSX-T Edge トランスポート 192.168.7.208/28 192.168.3.208/28 192.168.1.208/28 192.168.0.208/28
NSX-T Edge アップリンク 1 192.168.7.224/28 192.168.3.224/28 192.168.1.224/28 192.168.0.224/28
NSX-T Edge アップリンク 2 192.168.7.240/28 192.168.3.240/28 192.168.1.240/28 192.168.0.240/28

選択した CIDR 範囲によって、サブネットのサブネット マスクが変わります。たとえば、vSphere または vSAN の CIDR に /21 を選択すると、/24(システム管理サブネット)、/24(vMotion サブネット)、/24(vSAN サブネット)、/23(NSX-T ホスト トランスポート サブネット)/28(NSX-T Edge トランスポート サブネット)、/28(NSX-T Edge アップリンク 1)、/28(NSX-T Edge アップリンク 2)のサブネットが作成されます。

HCX デプロイの CIDR 範囲

プライベート クラウド上の HCX には、次の IP アドレス範囲が必要です。

名前 説明 アドレス範囲
HCX デプロイの CIDR 範囲 HCX ネットワークのデプロイでは必須です。プライベート クラウドの作成時は省略可能です。 /27 以上

割り当て済みアドレス範囲

VMware Service へのプライベート サービス アクセスには、次の IP アドレスが必要です。

名前 説明 アドレス範囲
割り当て済みアドレス範囲 VMware Engine などの Google Cloud サービスへのプライベート サービス接続に使用されるアドレス範囲。 /24 以上

Edge サービスとクライアント サブネット

VMware Engine が提供する Edge ネットワーク サービスを有効にするには、次の IP アドレス範囲が必要です。

名前 説明 アドレス範囲
Edge サービスの CIDR 範囲 ポイント対サイト VPN、インターネット アクセス、パブリック IP アドレスなどのオプションの Edge サービスが有効な場合は必須です。範囲はリージョンごとに決まります。 /26
クライアント サブネット ポイント対サイト VPN では必須です。クライアント サブネットからの VPN 接続には DHCP アドレスが提供されます。 /24

サービスの Google プライベート アクセス オプション

Google Cloud には、VMware Engine または Google Virtual Private Cloud ネットワークで実行されているワークロードに対して、いくつかのプライベート アクセス オプションが用意されています。プライベート サービス アクセスは、VPC ネットワークと VMware Engine サービス間のプライベート接続を提供します。限定公開の Google アクセスを使用すると、VMware ワークロードは Google Cloud ネットワークを離れることなく、他の Cloud APIs やサービスにアクセスできます。

プライベート サービス アクセス

VMware Engine は、プライベート サービス アクセスを使用して、プライベート IP アドレスを使用する Google 組織内のテナント フォルダのサービス プロデューサー VPC ネットワークに VPC ネットワークを接続します。

プライベート サービス アクセスの構成方法については、プライベート サービス アクセスの構成をご覧ください。プライベート サービス アクセスでは VPC ネットワーク ピアリング接続が作成されるため、ルートをインポートおよびエクスポートすることが重要です。

Google とサードパーティ(サービス プロデューサーとも呼ばれます)は、VPC ネットワークにホストされている内部 IP アドレスを使用してサービスを提供できます。プライベート サービス アクセスを使用すると、これらの内部 IP アドレスにアクセスできます。プライベート接続では、次の機能が有効になります。

  • VPC ネットワーク内の VM インスタンスと VMWare VM が内部 IP アドレスのみを使用して通信を行います。VM インスタンスは、インターネット アクセスまたは外部 IP アドレスがなくても、プライベート サービス アクセスを介してサービスにアクセスできます。

  • プライベート サービス アクセス対応の Google Cloud サポート サービスと VMware VM 間の内部 IP アドレスを使用した通信。

  • Cloud VPN または Cloud Interconnect を使用してオンプレミス ネットワークに接続している VPC ネットワークがある場合、既存のオンプレミス接続を使用して VMware Engine のプライベート クラウドに接続できます。

独自のプロジェクトで共有 VPC ネットワークを使用している場合は、サービス プロジェクトの VM インスタンスが環境と接続できるように、ホスト プロジェクトで IP 範囲の割り振りとプライベート接続を作成する必要があります。

プライベート サービス アクセスは、VMware Engine のプライベート クラウドの作成とは別に設定できます。また、VPC ネットワークに接続するプライベート クラウドを作成する前または後に、プライベート接続を作成することもできます。

したがって、プライベート サービス アクセスを構成する場合は、内部 IP アドレス範囲を割り振ってから、前のセクションで説明したようにプライベート接続を作成する必要があります。この割り当て範囲は、プライベート サービス アクセス接続に使用される予約済みの CIDR ブロックで、ローカルの VPC ネットワークでは使用できません。この範囲はサービス プロデューサー用に確保されており、VPC ネットワークとサービス プロデューサー VPC ネットワークの重複を防ぎます。プライベート サービス接続を作成する場合は、割り当てを指定する必要があります。サービス プロデューサー側の詳細については、プライベート サービス アクセスの有効化をご覧ください。

IP アドレスの重複を避けるため、プライベート サービス接続ですべての VMware Engine サブネットを割り振ることをおすすめします。次のスクリーンショットでは、VMware Engine の CIDR ブロックがプライベート サービス接続に使用されています。また、IP アドレスの重複を防ぐため、gcve-2 の CIDR ブロックが割り当てられています。

VMware Engine の CIDR ブロックがプライベート サービス接続に使用されています。

サービス ネットワーキングは、受信した動的ルートでアドレスの重複を確認しないため、プライベート サービス アクセスを VMware 以外のサービス用に予約されたプレフィックスに関連付ける必要があります。これにより、CIDR 範囲が予約され、VPC ネットワークで使用できなくなるため、IP アドレスの重複による問題が発生しなくなります。

プライベート サービス アクセスを構成する場合は、servicenetworking-googleapis-com プライベート接続ですべてのルートをインポートおよびエクスポートできるように、VPC ピアリング接続が正しく構成されている必要があります。また、VMware Engine でプライベート接続を設定するときに使用できるように、ピアリングされたプロジェクト ID をメモしておく必要があります。

サービス プロデューサーの VPC ネットワークは、プライベート クラウド(プライベート vCenter と単一の NSX-T)が存在する VMware Engine サービスに自動的に接続されます。

VMware Engine は、サービス プロデューサー VPC 内にプロビジョニングされ、プライベート サービス アクセスを使用する複数の Google Cloud サービス(Cloud SQL、Memorystore for Redis、Memorystore for Memcached、AI Platform Training、GKE 限定公開クラスタなど)に対して同じ接続を使用します。これらのサービスを使用する場合は、VMware Engine とのプライベート サービス接続の確立に使用した CIDR 範囲を選択できます。

VMware Engine サービス ポータルで、リージョンのステータスが接続済みになると、対応するリージョンのテナント プロジェクト ID を使用してプライベート接続を確認できます。プライベート接続の詳細には、VPC ピアリングで学習されたルートが表示されます。エクスポートされたルートには、リージョンから学習したプライベート クラウドと VPC ピアリングを介してエクスポートされたものが含まれます。

プライベート クラウドは、単一の vCenter と、最大 64 個のノードを持つ単一の NSX-T インストールで構成されます。複数のプライベート クラウドをデプロイできます。1 つのプライベート クラウドで 64 ノードの上限に達した場合は、別のプライベート クラウドを作成できます。つまり、2 つのプライベート クラウド、2 つの vCenter のインストール、2 つの NSX-T インストールを管理することになります。

ユースケースに応じて、単一のプライベート クラウドをデプロイするか、64 ノードの上限に達しなくても複数のプライベート クラウドをデプロイできます。たとえば、データベース ワークロード用に 1 つのプライベート クラウドをデプロイし、VDI 用に別のプライベート クラウドをデプロイできます。また、南北アメリカと EMEA のワークロードにそれぞれ別々のプライベート クラウドをデプロイすることもできます。ユースケースによっては、同じプライベート クラウドにある複数のクラスタにワークロードを分離することもできます。

限定公開の Google アクセス

限定公開の Google アクセスを使用すると、VMware Engine VM に外部 IP アドレスを割り当てずに、Google API とサービスに接続できます。限定公開の Google アクセスを構成した後、トラフィックはインターネット ゲートウェイに転送され、Google ネットワークから移動せずにリクエストされたサービスにルーティングされます。

詳細については、限定公開の Google アクセス: より詳しくをご覧ください。

主なトラフィック フロー

このセクションでは、いくつかの主なトラフィック フローを取り上げ、さまざまなネットワーク フローを網羅するアーキテクチャについて説明します。

以下の例では、VMware Engine の設計を行う際の考慮すべき事項について説明します。

VMware Engine オンプレミスとリモート ユーザー接続

以下では、オンプレミス データセンターまたはリモートから VMware Engine 環境にアクセスするためのオプションを示します。

VPN ゲートウェイは、オンプレミス、VPC ネットワーク、プライベート クラウドなどの複数のサイト間で安全な接続を実現します。この暗号化された VPN 接続はインターネットを経由し、VPN ゲートウェイで終了します。同じ VPN ゲートウェイに対して複数の接続を作成すると、すべての VPN トンネルが使用可能なゲートウェイ帯域幅を共有します。

ポイント対サイト VPN ゲートウェイにより、ユーザーはパソコンからリモートの VMware Engine に接続できます。1 つのリージョンに作成できるポイント対サイト VPN ゲートウェイは 1 つだけです。

ポイント対サイト VPN ゲートウェイは TCP 接続と UDP 接続を許可します。ユーザーは、パソコンから接続するときに、使用するプロトコルを選択できます。また、構成されたクライアント サブネットは TCP と UDP の両方のクライアントで使用され、CIDR ブロックで定義された範囲が 2 つのサブネットに分割されます(1 つは TCP 用、もう 1 つは UDP クライアント用)。

ポイント対サイト VPN は、VMware Engine リージョン ネットワークとクライアント コンピュータの間で暗号化されたトラフィックを送信します。ポイント対サイト VPN を使用すると、プライベート クラウド vCenter やワークロード VM などのプライベート クラウド ネットワークにアクセスできます。ポイント対サイト VPN の設定の詳細については、VMware Engine ネットワークへの VPN ゲートウェイの構成をご覧ください。

また、Cloud VPN を使用してサイト間の VPN 接続を行うことも、Cloud Interconnect を使用してオンプレミス ネットワークと VMware Engine プライベート クラウド間の接続を確立することもできます。VPC ネットワークには Cloud VPN と Cloud Interconnect をプロビジョニングします。詳細については、Cloud VPNCloud Interconnect のドキュメントをご覧ください。

VPN 接続のもう 1 つのオプションは NSX-T IPsec VPN、NSX-T L2 VPN、HCX L2 VPN です。たとえば、L2 ストレッチを構成することもできます。NSX-T IPsec VPN のユースケースは、VMware Private Cloud 内で VPN 終端を使用したエンドツーエンドの暗号化です。NSX-T VPN 機能の詳細については、VMware の Virtual Private Network のドキュメントをご覧ください。

プライベート サービス アクセスは、Cloud Router または Cloud VPN が配置されている VPC ネットワーク(Border Gateway Protocol が使用されている場合は VLAN アタッチメントも存在する VPC ネットワーク)内に構成することをおすすめします。それ以外の場合は、VPC ルートを構成する必要があります。アーキテクチャに複数の VPC ピアリング接続が含まれている場合、VPC ピアリングは推移的ではありません。

ルートのインポートとエクスポートが構成されている場合、相互接続または VPN 経由でアドバタイズされたオンプレミス ルートは、プライベート サービス アクセスを介して自動的に伝達されます。そのためには、VPC ピアリング接続のインポート ルートとエクスポート ルートを手動で編集する必要があります。

また、プライベート サービス アクセスを通じて取得したルートは、オンプレミス システムに自動的に伝達されません。これは、VPC ネットワーク ピアリングが推移的ルーティングをサポートしていないためです。他のネットワークからインポートされたルートには、VPC ネットワーク内の Cloud Router による自動的なアドバタイズが行われません。ただし、ピア ネットワーク内の宛先へのルートを共有するために、VPC ネットワーク内の Cloud Router からのカスタム IP 範囲のアドバタイズを使用することはできます。静的ルーティングを使用する Cloud VPN トンネルの場合は、ピア ネットワークの宛先範囲への静的ルートをオンプレミス ネットワーク内で構成する必要があります。

VMware Engine への上り(内向き)

このセクションでは、VMware Engine への 上り(内向き)に関する次のオプションについて説明します。

  • VMware Engine のパブリック IP サービスを使用する上り(内向き)
  • お客様の VPC からの上り(内向き)
  • オンプレミスのデータセンターからの上り(内向き)

選択するオプションは、Google Cloud インフラストラクチャをインターネットに接続する場所によって異なります。次の図は、これらの上り(内向き)オプションを示しています。

上り(内向き)オプション。

以降のセクションでは、これらのオプションについて詳しく説明します。

VMware Engine を使用した上り(内向き)

VMware Engine インターネット ゲートウェイを使用する場合、オンデマンド パブリック IP アドレスは、VMware Engine ポータルのプライベート クラウド内のリソースに対して作成および削除できます。このシナリオでは、各パブリック IP アドレスは、構成済みのプライベート クラウド IP アドレスに対応します。

パブリック上り(内向き)は、NAT にも依存するパブリック IP ゲートウェイを介して提供できます。このため、公共のインターネットからアクセスするユーザーは、Google のパブリック IP アドレスに接続します。Google のパブリック IP アドレスは、VMware Engine の仮想マシンのプライベート IP アドレスに変換されます(NSX-T セグメントによってバッキングされます)。

公開されているパブリック IP に対する外部からの受信接続を許可するファイアウォール ルールを作成する場合、ファイアウォール ルールはパブリック IP ゲートウェイに適用されます。このため、これらのファイアウォール ルールは VMware Engine ポータルでプロビジョニングする必要があります。

Tier 0 論理ルーターは、インターネットに接続している仮想マシンなどの North-South ルーティングに使用されます。Tier 1 論理ルーターは East-West ルーティングに使用され、Tier 1 に対して複数のサブネットを構成できます。

パブリック IP アドレスを使用すると、インターネット リソースは、プライベート クラウド リソースに対して、プライベート IP アドレスで受信の通信ができるようになります。プライベート IP アドレスは、プライベート クラウド vCenter の仮想マシンまたはソフトウェア ロードバランサです。パブリック IP アドレスを使用すると、プライベート クラウドで稼働しているサービスをインターネットに公開できます。

パブリック IP アドレスに関連付けられたリソースは、常にインターネット アクセスに該当するパブリック IP アドレスを使用します。デフォルトでは、パブリック IP アドレスでの送信インターネット アクセスのみが許可されます。パブリック IP アドレスでの受信トラフィックは拒否されます。受信トラフィックを許可するには、パブリック IP アドレスの特定のポートへのファイアウォール ルールを作成します。

組織内のユーザーは、VM ワークロードなどのプライベート クラウドの特定のノードにパブリック IP を公開して割り振ることができます。パブリック IP アドレスは、1 つのプライベート IP アドレスにのみ割り当てることができます。パブリック IP アドレスは、割り当てを解除するまでプライベート IP アドレス専用です。ESXi ホストや vCenter は公開しないようにしてください。

パブリック IP を割り振る場合は、名前、ロケーションまたはリージョン、接続済みのローカル アドレスを指定する必要があります。

お客様の VPC ネットワークを使用した上り(内向き)

Cloud Load Balancing を使用して、お客様の VPC ネットワークを介して VMware Engine への上り(内向き)を提供できます。必要な機能に応じてロードバランサを選択するときに、VPC ピアリング接続経由でトラフィックをプロキシするロードバランサのバックエンドとして、マネージド インスタンス グループ(MIG) または非マネージド インスタンス グループを作成できます。このシナリオでは、Google Cloud Marketplace からサードパーティの仮想ネットワーク アプライアンスを使用することもできます。
独自のパブリック IP スペースを Google に使用する場合は、Cloud Load Balancing と Bring Your Own IP(BYOIP)を組み合わせることができます。また、Google Cloud Armor を使用して、分散型サービス拒否攻撃(DDOS)やウェブ攻撃(SQL インジェクション、クロスサイト スクリプティングなど)からアプリケーションやウェブサイトを保護できます。

お客様のオンプレミスでの上り(内向き)

オンプレミスの上り(内向き)を提供するには、Cloud Interconnect を使用することをおすすめします。概念実証のためや、スループットが低くレイテンシ要件がない場合は Cloud VPN を使用できます。

VMware Engine からの下り(外向き)

VMware Engine の下り(外向き)には、次の複数のオプションがあります。

  • VMware Engine インターネット ゲートウェイ経由の下り(外向き)
  • お客様の VPC 経由の下り(外向き)
  • オンプレミスのデータセンター経由の下り(外向き)

次のアーキテクチャで VMware Engine の側から見ると、下り(外向き)フローに関するこれらのオプションを確認できます。

VMware Engine の観点から見た下り(外向き)フロー。

VMware Engine によるパブリック下り(外向き)

ワークロードのインターネット アクセスとパブリック IP サービスはリージョンごとに構成できます。Google Cloud のインターネット エッジまたはオンプレミス接続を使用して、VMware ワークロードからインターネットに向かうトラフィックを転送できます。

VMware Engine Private Cloud でホストされている仮想マシンからのトラフィックで、tier-0 ゲートウェイを介した公共インターネットの下り(外向き)に送信されます。tier-0 ゲートウェイは、インターネット ゲートウェイにトラフィックを転送します。インターネット ゲートウェイは送信元ポートのアドレス変換(PAT)を行います。インターネット サービスはリージョナルです。つまり、リージョン単位で有効にします。

VPC ネットワークを使用するパブリック下り(外向き)

また、VMware Engine サービス ポータルから、インターネット ネットワークとパブリック IP サービスを無効にし、お客様の VPC ネットワークからのパブリック下り(外向き)を提供することもできます。この場合、デフォルトの 0.0.0.0/0 ルートをアドバタイズすると、VPC ネットワークを介したインターネット アクセスが使用されます。このパケットフローを使用する場合は、VMware Engine リージョンのインターネット アクセスを無効にし、デフォルトの 0.0.0.0/0 ルートを挿入します。

また、VPC ネットワーク経由でトラフィックを送信する前に、割り振られているパブリック IP アドレスとポイント対サイト VPN ゲートウェイを削除する必要があります。

デフォルト ルートはお客様の VPC ネットワークで認識される必要があります。認識されると、VMware Engine に自動的に伝達されます。前提条件として、VPC と VMware Engine の間の VPC ピアリング接続で VPC Service Controls を有効にする必要があります。

ネットワーク アドレス変換(NAT)を実行するには、Compute Engine インスタンスをデプロイするか、内部ロードバランサを参照するデフォルト ルート 0.0.0.0/0 をサードパーティの集中管理仮想ネットワーク アプライアンス クラスタ(Cloud Marketplace で利用可能)とペアリングして、インスタンスで送信元 NAT を実行し、VPC ネットワークから公共のインターネットに下り(外向き)トラフィックを送信します。詳細については、VPC ネットワークでのルートの使用方法をご覧ください。

オンプレミスのデータセンターを使用したパブリック下り(外向き)

インターネットとパブリック IP サービスを無効にし、オンプレミスからのパブリック Egress を提供する場合、オンプレミスのデータセンターを経由して下り(外向き)を提供できます。この場合、インターネット アクセスは VPC ネットワークを経由して、Cloud VPN または Cloud Interconnect 経由してオンプレミスのデータセンターに到達します。

オンプレミスのデータセンター経由でパブリック下り(外向き)を実装するには、デフォルト ルートが正しくインポートされるように、デフォルトの 0.0.0.0/0 ルートをアドバタイズし、ピアリング接続で VPC Service Controls を有効にします(詳細はこちらを参照)。VPC Service Controls の詳細については、公式ドキュメントをご覧ください。

VPC Service ピアリング接続で VPC Service Controls が無効になっている場合、デフォルト ルート(0.0.0.0/0)が、VPC ピアリング接続でアドバタイズされ、伝達されていても、オンプレミス接続経由のインターネット アクセスも無効になります。

サービスの概要: プライベート クラウドからプライベート クラウド

プライベート クラウドは VMware Engine ポータルで管理されます。プライベート クラウドには、独自の管理ドメイン内に独自の vCenter Server が存在します。VMware スタックは、Google Cloud のロケーションにある専用の独立したベアメタル ハードウェア ノードで実行されます。プライベート クラウド環境は、単一障害点を排除するように設計されています。

次の図は、2 つのプライベート クラウドが相互に通信する際のアーキテクチャとトラフィック フローを示しています。

2 つのプライベート クラウドが相互に通信する際のトラフィック フロー。

VMware Engine サービス内の同じリージョン内にある 2 つのプライベート クラウド間の通信は直接接続です。同じリージョンに複数のプライベート クラウドをデプロイし、プライベート クラウド間の通信がローカルで実行されるようにすることもできます。

プライベート クラウドが異なるリージョンにある場合、サービス プロデューサー VPC ネットワーク経由で接続されます。このネットワークは Google が管理し、所有しています。

お客様はまずプライベート クラウドを使用し、必要に応じてノード数を変更できます。新しいノードは既存の vSphere クラスタに配置することも、新しいクラスタに作成することもできます(すべて同じプライベート クラウド内に存在します)。

サービスの概要: プライベート クラウドから VPC

このセクションでは、VPC ネットワークとプライベート クラウドの間の接続を確認します。VPC ネットワークは、プライベート サービス アクセス モデルを使用してサービス プロデューサー VPC ネットワークとピアリングし、VMware Engine リージョンに接続を拡張します。グローバル ルーティングは、サービス プロデューサー VPC ネットワークで有効になっています。VMware Engine サービス ポータルで作成したネットワークは、NSX-T の Tier-0 ルーターによって自動的にアドバタイズされます。ピアリング接続でインポート / エクスポートのフラグを有効にしてルートを交換し、VMware Engine と VPC 間の接続を確立します。

次の図は、この場合のトラフィック フローを示しています。

プライベート クラウドから VPC へのトラフィック フロー。

サービスの概要: プライベート クラウドから共有 VPC

共有 VPC ネットワークを使用する場合の接続は、プライベート クラウドを VPC ネットワークに接続する前の例と似ていますが、プライベート クラウドを共有 VPC ネットワークに接続すると、ワークロードがサービス プロジェクトに存在し、ホスト プロジェクトの共有 VPC ネットワーク内の IP アドレス空間が使用されるという点が異なります。このため、共有 VPC ネットワークと相互接続または VPN が構成されているホスト プロジェクトで、プライベート サービス アクセスを構成する必要があります。

たとえば、サービス プロジェクトにプライベート クラウド、IAM、請求を含める場合、ホスト プロジェクトの共有 VPC ネットワークでプライベート サービス アクセスの接続が確立されるようにします。

サービスの概要: プライベート クラウドからオンプレミス

プライベート クラウドからオンプレミスの場合、お客様のプロジェクトと組織に VPC ネットワークが存在し、接続はプライベート クラウドとオンプレミスのデータセンター間となります。

前述のように、お客様が VMware Engine を設定する場合は、プライベート サービス アクセス接続用のサブネットを割り振る必要があります(後で競合が発生するのを防止するため、理想的には VMware Engine Service のサブネットも割り振ります)。サブネットを割り振るだけでなく、プライベート クラウドが存在する VMware Engine リージョンに接続するサービス プロデューサー VPC ネットワークを作成します。

VPC ピアリング接続が作成されてプロビジョニングされると、サービス プロデューサー VPC ネットワークがお客様の VPC ネットワークに接続されます。これにより、プライベート VPC からお客様の VPC ネットワーク内のすべてのサブネットと IP アドレスに到達できるようになります。プライベート サービス アクセスを構成する場合は、VPC ピアリング接続でルートのインポートとエクスポートを有効にする必要があります。

次の図は、VMware Engine のプライベート クラウドとオンプレミス データセンター間のエンドツーエンド接続を示しています。

VMware Engine のプライベート クラウドとオンプレミス データセンター間のエンドツーエンド接続。

限定公開の Google アクセス: より詳しく

前述のように、限定公開の Google アクセスを使用すると、Google Cloud リソースの外部 IP アドレスを指定せずに Google API やサービスに接続できます。VMware Engine サービスは、この機能を利用してインターネット ゲートウェイから Google API にアクセスします。

内部 IP アドレスしかない VM インスタンスでは、限定公開の Google アクセスを利用して、Google API とサービスの外部 IP アドレスにアクセスできます。限定公開の Google アクセスが構成されると、トラフィックはインターネット ゲートウェイ経由でリクエストされたサービスに転送されます。

VMware Engine の限定公開の Google アクセスを有効にするには、プライベート仮想 IP アドレスを使用するように VMware Engine 環境の DNS サーバーを構成します。詳細については、オンプレミス ホスト用の限定公開の Google アクセスオンプレミス ホスト用の限定公開の Google アクセスの構成をご覧ください。ドメイン private.googleapis.com199.36.153.8/30 を使用します。

DNS 解決を管理する場合は、NSX-T で提供される DNS サービスを使用して、指定した DNS サーバーにリクエストを転送できます。DNS サーバーには、VMware Engine の VM、Cloud DNS、オンプレミスの DNS サーバーがあります。前のセクションで説明したように、インターネットへのアクセス方法に応じて、いずれかのオプションが使用されます。

限定公開の Google アクセスは、Cloud Storage、Cloud Spanner、BigQuery など、ほとんどの Google API とサービスをサポートしています。現在、限定公開の Google アクセスは App Engine、Memorystore、Filestore、Cloud SQL をサポートしていません。

VMware Engine と Google Cloud サービスは、次のような方法で使用できます。

  • データをエクスポートするため、または拡張ストレージ ターゲットとして、VMware VM から Cloud Storage にアクセスします。
  • Cloud Monitoring を使用して、すべてのパブリック、プライベート、ハイブリッド アプリケーションをモニタリングします。
  • データベースから BigQuery にデータをインポートして分析します。
  • Anthos をデプロイして、高パフォーマンスで非公開のコンテナ化されたアプリケーションをデプロイします。

次の図のように、限定公開の Google アクセス構成は、VMware Engine で有効にされたインターネット アクセスに依存しています。これは、VMware Engine サービス インターネット ゲートウェイ 1)か、サービス プロデューサー VPC ネットワークのインターネット ゲートウェイ 2)のいずれかで提供されます。

限定公開の Google アクセスの構成。

インターネット アクセスが VMware Engine を介して提供され、リージョンで有効になっている場合、限定公開の Google アクセスとインターネット アクセスでインターネット ゲートウェイが使用されます。

オンプレミスまたは VPC ネットワーク経由でインターネット アクセスを提供する場合は、VMware Engine パブリック IP サービスを無効にして、ピアリング接続で VPC Service Controls を構成します。これにより、Google 組織内のテナント VPC ネットワークからネクストホップ インターネット ゲートウェイを持つデフォルト ルート 0.0.0.0/0 が削除されます。この場合は、オンプレミスまたは VPC ネットワークからのデフォルト ルートは許可され、テナント VPC ネットワークのインターネット ゲートウェイを参照する制限付き仮想 IP アドレス 199.36.153.4/30 にルートが追加されます。

オプション 1: VMware Engine が提供するインターネット アクセスと限定公開の Google アクセス

リージョンに VMware Engine 経由でインターネット アクセスを提供している場合、限定公開の Google アクセスとインターネットは、インターネット ゲートウェイを使用して PAT を実行します。この場合、限定公開の Google アクセスの DNS 解決を除いて、構成を追加する必要はありません。

オプション 2: オンプレミスまたはお客様の VPC によって提供されるインターネット アクセスと限定公開の Google アクセス

オンプレミスまたは VPC ネットワーク経由でインターネット アクセスを提供している場合は、組織のテナント VPC ネットワークのインターネット ゲートウェイ経由でパケットを Google API に転送するように VMware Engine サービスを構成する必要があります。お客様の VPC ネットワークを経由する他のトラフィックのパケットが、VPN または Interconnect 経由、あるいはお客様の VPC ネットワーク経由でオンプレミスに到達できるように、VMware Engine サービスを構成する必要があります。すべてのトラフィックで VMware Engine リージョンのインターネット アクセスとパブリック IP サービスを無効にして、オンプレミス経由でデフォルトの 0.0.0.0/0 ルートを挿入する必要があります。

オンプレミスまたは VPC ネットワーク経由でインターネット アクセスを提供する場合は、パブリック IP サービスを無効にする前に、割り振られたパブリック IP アドレスとポイント対サイト VPN ゲートウェイを削除します。ルートがお客様の VPC ネットワークに認識され、テナント VPC ネットワークにルートがエクスポートされていることを確認します。

また、VPC と VMware Engine 間の VPC ピアリング接続で VPC Service Controls を有効にする必要があります。

また、Google API へのアクセスには、制限付きの仮想 IP アドレスを使用する必要があるため、DNS は必要な CNAME と A レコードに従って構成する必要があります。また、Google API へのアクセスはお客様の VPC ネットワーク経由ではなく、Google 組織経由とします。

プライベート クラウドからマネージド パートナー サービスへ

マネージド パートナー サービス(MPS)を使用すると、MPS コロケーション施設でホストしているハードウェアとソフトウェアから Google Cloud のお客様に、ミッション クリティカルな Software-as-a-Service(SaaS)サービスを提供できます。

プライベート クラウドと MPS 間のトラフィック フローでは、VPC ピアリングは推移的ではありません。この場合、VMware Engine の NSX-T Tier-0 と VPC ネットワーク内の Cloud VPN の間に VPN を設定する必要があります。ルートは Border Gateway Protocol(BGP)を使用して交換されます。また、VPC ピアリング モデルを使用する同じプライベート アクセス サービスが MPS との接続に適用されます。Cloud VPN と BGP を使用する場合は、これらのルートを NSX-T Tier-0 にアドバタイズして、エンドツーエンド接続になるように構成してください。この方法の例として NetApp Cloud Volumes Service for Google Cloud があります。このサービスでは、プライベート サービス アクセスを使用して、高スループットで低レイテンシのデータパス接続を作成します。ただし、マネージド サービス プロバイダのプライベート クラウドは、VMware ワークロードに保存されているデータで機能しません。

次の図は、VMware Engine と MPS のプライベート クラウド間のエンドツーエンド接続を表しています。

VMware Engine と MPS のプライベート クラウド間のエンドツーエンド接続

MPS を使用する必要があり、VMware Engine からのインターネット アクセスを無効にしていて、デフォルト ルートがサービス プロデューサー VPC からきている場合は、VPN 接続の RFC 1918 IP アドレスを設定できます。VPN 接続は、NSX-T とお客様の VPC ネットワーク内の仮想アプライアンス(Cloud Marketplace からの取得可能なサードパーティの仮想ネットワーク アプライアンスなど)間で動作します。

その他のリソース: VMware

VMware スタックの詳細については、VMware コンポーネントのバージョン公式の NSX 3.0 設計ガイドをご覧ください。