VMware Engine のプライベート クラウド ネットワーキング
このドキュメントでは、Google Cloud VMware Engine の概要について説明します。ネットワーキングのコンセプト、最も一般的なトラフィック フローの確認、VMware Engine を使用してアーキテクチャを設計する際に考慮すべき点について解説します。また、VMware Engine の仕組み、その機能、最適なアーキテクチャを決定する際に考慮すべき点についても説明します。
このドキュメントは、Google Cloud にホスティングされ、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 vSphere、vCenter Server、vSAN、NSX-T から構成されるフルマネージドの VMware ソフトウェア定義データセンター（SDDC）を提供します。VMware Engine では、企業の本番環境ワークロードをサポートするため、Google Cloud 上の専用の環境でクラウド移行用の HCX を提供しています。VMware Engine を使用すると、Google Cloud コンソールから専用の VMware 環境に直接接続して、オンプレミスのワークロードを Google Cloud に移行または拡張できます。これにより、アプリケーションのリファクタリングに伴う費用や複雑さに煩わされることなく、クラウドへの移行を行い、オンプレミス環境と一貫性のある方法でワークロードを実行し、管理できます。Google Cloud で VMware ワークロードを実行すると、スケーリングとアジリティの利点を生かしながら運用の負担を軽減し、既存のツール、ポリシー、プロセスを継続して使用できます。
VMware Engine は、Google Cloud の高性能でスケーラブルなインフラストラクチャ上に構築されています。完全に冗長な 100 Gbps の専用ネットワークを備え、VMware スタックの要件を満たすために最大 99.99% の可用性を提供します。Cloud Interconnect や Cloud 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 は、次のユースケースのソリューションとなります。
オンボーディング要件
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 マネージド サービスの統合
- VMware Engine:
- （省略可）オンプレミス リソース:
- ネットワーキング
- ストレージ
- HCX（レイヤ 2 接続用に推奨。L2 ストレッチとも呼ばれます）
- vCenter
プライベート クラウドは分離された VMware スタックで、ESXi ホスト、vCenter、vSAN、NSX-T、HCX から構成されます。これらのコンポーネントはまとめて Google Cloud VMware Engine コンポーネントと呼ばれ、クラウド管理者がプライベート クラウドを作成するときにデプロイされます。これにより、組織内のユーザーがプライベート サービス アクセス接続を確立し、VPC ネットワークから VMware Engine プライベート クラウドに非公開でアクセスできるようになります。次の図は、このアーキテクチャを示しています。
プライベート サービス アクセスは、VPC ネットワークと Google またはサードパーティが所有するネットワークとのプライベート接続です。Google またはサードパーティ（サービスを提供しているエンティティ）は、サービス プロデューサーとも呼ばれます。
VMware Engine に接続されている各 VPC ネットワークに応じて、サービス プロデューサー VPC ネットワークがあります。これは Google Cloud でプライベート サービス アクセス接続を作成するときに作成されます。Google Cloud プロジェクトには、他の Google Cloud サービス（Memorystore や Cloud SQL など）への接続に使用できる共有 VPC ネットワークが含まれています。たとえば、オンプレミスの MySQL や PostgreSQL VM を VMware Engine にリフト＆シフトした後、VMware Engine ワークロードで引き続きこれらのデータベースにアクセスしながら、Google Cloud の組み込み Database Migration Service を使用して Cloud SQL に移行できます。
オンプレミスで NSX-T を使用する必要はありません。また、どのユースケースでも HCX を使用する必要はありません。他の方法で、レイヤ 2（L2）の拡張とワークロードの移行を行うことができます。ただし、このオプションを選択した場合は、プライベート クラウドの作成時にこの機能が自動的にデプロイされるため、ワークロードを効率的に移行できて使いやすい HCX の使用をおすすめします。
ネットワーク機能
以下に、VMware Engine のネットワーク機能の概要を示します。
- マルチ VPC 接続: VMware Engine では、同じプライベート クラウドを複数の VPC ネットワーク（合計 3 つ。リージョン インターネット サービスを使用する場合は 2 つ）に接続できます。これらの VPC ネットワークは、コンシューマ VPC ネットワークまたはマネージド Partner Services（MPS）です。
- サブネット: プライベート クラウドに管理用とワークロード用のサブネットを作成できます。
- 動的ルーティング: NSX が管理する VMware Engine サブネットは、Border Gateway Protocol（BGP）により、他の Google ネットワークとオンプレミス ロケーションに自動的にアドバタイズされます。
- リージョンとグローバルのルーティング機能: プライベート クラウドを接続するサービス プロデューサーの共有 VPC ネットワークが、リージョン内でのみルーティングできるのか、あるいはグローバルにルーティングできるのかを制御できます。
- パブリック IP サービスとインターネット ゲートウェイ（上りと下り、内向きと外向き）: VMware Engine は、インターネット ゲートウェイの上り（内向き）と下り（外向き）用に独自のパブリック IP サービスを使用します。これはリージョン サービスです。
- ファイアウォール ポリシー: VMware Engine では、NSX 分散ファイアウォール（East-West）と NSX ゲートウェイ ファイアウォール（North-South）を使用して、L4 / L7 ファイアウォール ポリシーを作成できます。たとえば、ウェブサーバーなどのパブリック IP アドレスでワークロードにアクセスする場合、きめ細かい制御を行うことができます。
- East-West セキュリティのサービス チェーン: パートナー セキュリティ ソリューション（IDS、IPS、NGFW）を登録して、VM 間を移動する East-West トラフィックを検査できるようにネットワーク サービスを構成します。
- エンドポイントの保護: サポートされているサードパーティとのパートナー統合により、VMware Engine を基盤とする VM をマルウェアやウイルスから保護できます。詳細については、VMware の公式ドキュメントをご覧ください。
- 他の Google サービスとのプライベート アクセス: VMware Engine は、限定公開の Google アクセスとプライベート サービス アクセスを使用して、他の Google Cloud サービスと統合されます。サポートされているサービスの一覧については、サービスのプライベート アクセス オプションをご覧ください。
- DNS 機能
- 管理用アプライアンスへのアクセス用の DNS: Cloud DNS を使用して、VMware Engine 管理用アプライアンス（vCenter や NSX Manager など）のグローバル アドレス解決を行うことで、ユーザーの介入なしにアプライアンスにアクセスできます。
- ワークロード用の DNS: プライベート クラウドごとに最適な DNS 設定を判断します。NSX-T DNS サービスを使用すると、DNS クエリを特定の DNS サーバーに転送したり、VMware Engine またはオンプレミスで DNS サーバーを作成できます。また、Cloud DNS や Compute Engine を使用することもできます。
- DHCP サーバー: NSX-T セグメントに対する DHCP サーバーのサポートが含まれます。
- DHCP リレー: DHCP リレーを使用すると、オンプレミスの IP アドレス管理（IPAM）システムと統合できます。
- サイト間レイヤ 2 VPN とレイヤ 3 VPN: これらのサービスは、それぞれレイヤ 2 VPN と 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 サービスがデプロイされているリージョンごとにネットワークを作成します。ネットワークは単一のレイヤ 3 アドレス空間で、デフォルトでルーティングが有効になっています。このリージョンに作成するすべてのプライベート クラウドとサブネットは追加構成なしで通信可能になります。ワークロードの仮想マシンに NSX-T を使用してネットワーク セグメント（サブネット）を作成できます。オンプレミス ネットワーク、プライベート クラウドの管理ネットワーク、または VPC サブネットと重複しない RFC 1918 アドレス範囲を構成できます。プライベートで使用されるパブリック IP（PUPI）アドレスもサポートされます。
デフォルトでは、すべてのサブネットが相互に通信できるため、プライベート クラウド間のルーティングの構成オーバーヘッドが削減されます。同じリージョン内のプライベート クラウド間で発生するデータ トラフィックは同じレイヤ 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 Engine へのプライベート サービス アクセスには、次の 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 VPC ネットワークで実行されているワークロードに対して複数のプライベート アクセス オプションがあります。プライベート サービス アクセスは、VPC ネットワークと VMware Engine サービス間のプライベート接続を提供します。限定公開の Google アクセスを使用すると、VMware ワークロードは Google Cloud ネットワークを離れることなく、他の Google 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 以外のサービス用に予約されたプレフィックスに関連付ける必要があります。これにより、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 VPN と Cloud Interconnect のドキュメントをご覧ください。
レイヤ 2 ストレッチなどを構成する場合の VPN 接続の選択肢は、NSX-T IPsec VPN、NSX-T レイヤ 2 VPN、HCX レイヤ 2 VPN です。NSX-T IPsec VPN のユースケースは、VMware Engine のプライベート クラウド内で 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 ネットワークを使用した上り（内向き）
VMware Engine への上り（内向き）は、Cloud Load Balancing を使用して VPC ネットワーク経由で提供できます。必要な機能に応じてロードバランサを選択するときに、VPC ピアリング接続経由でトラフィックをプロキシするロードバランサのバックエンドとして、マネージド インスタンス グループ（MIG） または非マネージド インスタンス グループを作成できます。このシナリオでは、Google Cloud Marketplace からサードパーティの仮想ネットワーク アプライアンスを使用することもできます。
独自のパブリック IP 空間を Google に使用する場合は、Cloud Load Balancing とお客様所有 IP アドレスの使用（BYOIP）を組み合わせることができます。また、Google Cloud Armor を使用して、分散型サービス拒否攻撃（DDOS）やウェブ攻撃（SQL インジェクション、クロスサイト スクリプティングなど）からアプリケーションやウェブサイトを保護できます。
オンプレミス ネットワークを使用した上り（内向き）
オンプレミスの上り（内向き）を提供するには、Cloud Interconnect を使用することをおすすめします。概念実証のためや、スループットが低くレイテンシ要件がない場合は Cloud VPN を使用できます。
VMware Engine からの下り（外向き）
VMware Engine の下り（外向き）には、次の複数のオプションがあります。
- VMware Engine インターネット ゲートウェイ経由の下り（外向き）
- VPC ネットワーク経由の下り（外向き）
- オンプレミスのデータセンター経由の下り（外向き）
次のアーキテクチャで 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 Controls のドキュメントをご覧ください。
VPC Service ピアリング接続で VPC Service Controls が無効になっている場合、デフォルト ルート（0.0.0.0/0）が、VPC ピアリング接続でアドバタイズされ、伝達されていても、オンプレミス接続経由のインターネット アクセスも無効になります。
サービスの概要: プライベート クラウドからプライベート クラウド
プライベート クラウドは VMware Engine ポータルで管理されます。プライベート クラウドには、独自の管理ドメイン内に独自の vCenter Server が存在します。VMware スタックは、Google Cloud のロケーションにある専用の独立したベアメタル ハードウェア ノードで実行されます。プライベート クラウド環境は、単一障害点を排除するように設計されています。
次の図では、VMware Engine のプライベート クラウド間通信用の 2 つのネットワーク パスを示します。パスは、プライベート クラウドが同じリージョンにあるか、異なるリージョンにあるかによって変わります。
- VMware Engine サービス内の同じリージョン内にある 2 つのプライベート クラウド間の通信は直接接続です。同じリージョンに複数のプライベート クラウドをデプロイし、プライベート クラウド間の通信がローカルで実行されるようにすることもできます。
- プライベート クラウドが異なるリージョンにある場合、サービス プロデューサー VPC ネットワーク経由で接続されます。このネットワークは Google が管理し、所有しています。ルーティング モードがグローバルに設定されていると、このようになります。
サービスの概要: プライベート クラウドから VPC
このセクションでは、VPC ネットワークとプライベート クラウドの間の接続を確認します。VPC ネットワークは、プライベート サービス アクセス モデルを使用してサービス プロデューサー VPC ネットワークとピアリングし、VMware Engine リージョンに接続を拡張します。グローバル ルーティングは、サービス プロデューサー VPC ネットワークで有効になっています。VMware Engine サービス ポータルで作成したネットワークは、NSX-T の Tier-0 ルーターによって自動的にアドバタイズされます。ピアリング接続でインポート / エクスポートのフラグを有効にしてルートを交換し、VMware Engine と VPC 間の接続を確立します。
次の図は、この場合のトラフィック フローを示しています。
サービスの概要: プライベート クラウドから共有 VPC
共有 VPC ネットワークを使用する場合の接続は、プライベート クラウドを VPC ネットワークに接続する前の例と似ていますが、プライベート クラウドを共有 VPC ネットワークに接続すると、ワークロードがサービス プロジェクトに存在し、ホスト プロジェクトの共有 VPC ネットワーク内の IP アドレス空間が使用されるという点が異なります。このため、共有 VPC ネットワークと相互接続または VPN が構成されているホスト プロジェクトで、プライベート サービス アクセスを構成する必要があります。
たとえば、サービス プロジェクトにプライベート クラウド、IAM、請求を含める場合、ホスト プロジェクトの共有 VPC ネットワークでプライベート サービス アクセスの接続が確立されるようにします。
サービスの概要: プライベート クラウドからオンプレミス
プライベート クラウドからオンプレミスの場合、VPC ネットワークがプロジェクトと組織にあり、接続がプライベート クラウドとオンプレミス データセンター間にあります。
前述のように、VMware Engine を設定するときは、プライベート サービス アクセス接続用のサブネットを割り当てる必要があります（理想的には、今後の競合を回避するために VMware Engine のサブネット）。サブネットを割り振るだけでなく、プライベート クラウドが存在する VMware Engine リージョンに接続するサービス プロデューサー VPC ネットワークを作成します。
サービス プロデューサーの VPC ネットワークは、VPC ピアリング接続が作成されてプロビジョニングされた後、VPC ネットワークに接続されます。これにより、VPC ネットワーク内のすべてのサブネットと IP アドレスはプライベート クラウドからアクセスできるようになります。プライベート サービス アクセスを構成する場合は、VPC ピアリング接続でルートのインポートとエクスポートを有効にする必要があります。
次の図は、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.com は 199.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 をサポートしていません。プライベート アクセス オプションの詳細については、サービスのプライベート アクセス オプションをご覧ください。
VMware Engine と Google Cloud サービスは、次のような方法で使用できます。
- データをエクスポートするため、または拡張ストレージ ターゲットとして、VMware VM から Cloud Storage にアクセスします。
- Cloud Monitoring を使用して、すべてのパブリック、プライベート、ハイブリッド アプリケーションをモニタリングします。
- データベースから BigQuery にデータをインポートして分析します。
- Anthos をデプロイして、高パフォーマンスで非公開のコンテナ化されたアプリケーションをデプロイします。
次の図は、Google API と通信するための 2 つのネットワーク パスを示しています。限定公開の Google アクセスの構成は、VMware Engine で有効になっているインターネット アクセスによって異なります。
- インターネット アクセスが VMware Engine を介して提供され、リージョンで有効になっている場合、限定公開の Google アクセスとインターネット アクセスでインターネット ゲートウェイが使用されます。
- オンプレミスまたは VPC ネットワークを介して（
0.0.0.0/0ルートをアドバタイズして）インターネット アクセスを提供する場合、通信でサービス プロデューサーの VPC ネットワークのインターネット ゲートウェイが使用されます。VMware Engine インターネット サービスを介したアクセスは無視されます。
オプション 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 間のトラフィック フローの場合、VMware Engine はマルチ VPC 接続を使用します。この機能を使用すると、追加のコンシューマ VPC ネットワークだけでなく、Google の MPS にも接続を確立できます。次の図は、プライベート クラウドと MPS の間の接続と、追加のコンシューマ VPC ネットワークの間の接続を簡単に示しています。
その他のリソース: VMware
VMware スタックの詳細については、VMware コンポーネントのバージョンと NSX 3.0 設計ガイドをご覧ください。