Privates Cloud-Netzwerk für Google Cloud VMware Engine

Erstveröffentlichung: 25. Januar 2021

Dieses Dokument bietet einen Überblick über Google Cloud VMware Engine, beschreibt Netzwerkkonzepte, betrachtet die typischen Traffic-Abläufe und bietet einige Überlegungen zur Verwendung von VMware Engine beim Entwerfen einer Architektur. Im Dokument wird die Funktionsweise von VMware Engine, seine Funktionen und was bei der Auswahl der besten Architektur zu beachten ist erklärt.

Dieses Dokument ist relevant für Network Engineers, Cloud Engineers, Architekten und Operatoren, die für das Entwerfen, Warten und Problembeheben der Sicherheit, Konnektivität und Verfügbarkeit von VMware-gestützten Anwendungen zuständig sind, die in Google Cloud gehostet werden.

In diesem Dokument erhalten Sie außerdem weitere Informationen zu VMware Engine und seinen Anforderungen und Funktionen. Wenn Sie tiefer in die Technologie eintauchen oder sie in der Produktion einführen oder bereitstellen, hilft Ihnen dieses Dokument zu verstehen, wie VMware Engine funktioniert und wie Sie sie in eine neue oder bestehende Google Cloud-Umgebung integrieren. In diesem Dokument werden alle Netzwerkaspekte beschrieben, damit Sie die beste Lösung für Ihren jeweiligen Anwendungsfall finden können.

Das VMware Engine-Netzwerk lässt sich in VPC-Netzwerke (Virtual Private Cloud) mit bestehenden Verbindungen mit lokalen Netzwerken und auch in andere Google Cloud-Dienste integrieren. VMware Engine basiert auf einer leistungsstarken, zuverlässigen und hoher Kapazität Infrastruktur, um Kunden eine optimale, kostengünstige VMware-Erfahrung zu bieten.

Übersicht

VMware Engine ist ein von Google bereitgestellter Dienst, mit dem Sie Ihre VMware-Arbeitslasten in Google Cloud migrieren und ausführen können.

VMware Engine bietet ein vollständig verwaltetes VMware-SDDC (softwarebasiertes Rechenzentrum), das aus den folgenden Komponenten besteht: VMware vSphere, vCenter Server, vSAN und NSX-T. VMware Engine umfasst HCX für die Cloud-Migration in einer dedizierten Umgebung in Google Cloud, um Produktionsarbeitslasten für Unternehmen zu unterstützen. Sie können VMware Engine verwenden, um Ihre lokalen Arbeitslasten zu Google Cloud zu migrieren oder zu erweitern. Stellen Sie dazu über die Google Cloud Console eine direkte Verbindung zu einer dedizierten VMware-Umgebung her. Diese Funktion ermöglicht die Migration zur Cloud ohne Kosten und Komplexität der Refaktorierung von Anwendungen. Außerdem können Sie Arbeitslasten konsistent mit Ihrer lokalen Umgebung ausführen und verwalten. Wenn Sie Ihre VMware-Arbeitslasten in Google Cloud ausführen, reduzieren Sie die operative Last, profitieren aber von Skalierbarkeit und Flexibilität und können die vorhandenen Tools, Richtlinien und Prozesse weiter nutzen.

VMware Engine basiert auf der hochperformanten, skalierbaren Infrastruktur von Google Cloud mit vollständig redundantem und dediziertem 100 Gbit/s-Netzwerk, das eine Verfügbarkeit von bis zu 99,99 % bietet, um die Anforderungen Ihres VMware-Stacks zu erfüllen. Cloud-Netzwerkdienste wie Cloud Interconnect und Cloud VPN erleichtern den Zugriff aus Ihren lokalen Umgebungen auf die Cloud. Die hohe Bandbreite dieser Verbindungen zu Cloud-Diensten ist für Leistung und Flexibilität optimiert, während Kosten und operativer Aufwand minimiert werden. End-to-End-Support bietet umfassende Unterstützung für eine nahtlose Nutzung dieses Dienstes und des Rests von Google Cloud.

Nachdem Sie Arbeitslasten verschoben haben, können Sie auf Google Cloud-Dienste wie BigQuery, Cloud Operations, Cloud Storage, Anthos und Cloud AI zugreifen. Google Cloud bietet außerdem eine vollständig integrierte Abrechnung und Identitätsverwaltung und Zugriffssteuerung, um Ihre Erfahrung mit anderen Google Cloud-Produkten und -Diensten zu vereinheitlichen.

Anwendungsfälle

Das folgende Diagramm ist eine repräsentative Referenzarchitektur, die zeigt, wie Sie Ihre VMware-Umgebung zu Google Cloud migrieren oder erweitern können, während Sie gleichzeitig von Google Cloud-Diensten profitieren. VMware Engine bietet Lösungen für die folgenden Anwendungsfälle.

Referenzarchitektur, die zeigt, wie Sie Ihre VMware-Umgebung zu Google Cloud migrieren oder erweitern.

Teilnahmevoraussetzungen

Lesen Sie vor dem Bereitstellen der VMware Engine in Google Cloud die Voraussetzungen für die Teilnahme.

Systemkomponenten

Auf einer übergeordneter Ebene sind die VMware Engine-Komponenten Folgende:

  • Google Cloud:
    • VMware Engine:
      • NSX-T
      • HCX
      • vCenter
      • vSAN
    • Ihre Google Cloud-Organisation
      • Ihr Google Cloud-Projekt mit einem VPC-Netzwerk
      • Cloud Interconnect, das verwendet Partner Interconnect, Dedicated Interconnect oder Cloud VPN-Verbindung zu lokalen Systemen
      • Zugriff auf private Dienste-Verbindung mit der VMware Engine-Region.
    • Verbindung für den Zugriff auf private Dienste
    • Von Google verwaltete Dienste-Integration
  • (Optional) Lokale Ressourcen:
    • Netzwerk
    • Speicher
    • HCX (empfohlen für L2-Verbindungen, auch als L2-Stretch bezeichnet)
    • vCenter

Eine private Cloud ist ein isolierter VMware-Stack, der aus ESXi-Hosts, vCenter, vSAN, NSX-T und HCX besteht. Diese Komponenten werden allgemein als die Google Cloud VMware Engine-Komponenten bezeichnet und beim Erstellen einer privaten Cloud durch den Cloudadministrator bereitgestellt. Nutzer in Ihrer Organisation können dann über ihre VPC-Netzwerke privat auf private VMware Engine-Clouds zugreifen, indem sie eine Verbindung für den Zugriff auf private Dienste einrichten. Das folgende Diagramm zeigt diese Architektur.

Zugriff auf private Dienste

Der Zugriff auf private Dienste ist eine private Verbindung zwischen Ihrem VPC-Netzwerk und einem Netzwerk von Google oder einem Drittanbieter. Google oder der Drittanbieter – Entitäten, die Dienste anbieten – werden auch als Dienstersteller bezeichnet.

Für jedes VPC-Netzwerk des Kunden, das mit VMware Engine verbunden ist, gibt es ein Dienstersteller-VPC-Netzwerk, das erstellt wird, wenn Kunden eine Verbindung zu privaten Diensten in Google Cloud erstellen. Dieses Projekt enthält ein freigegebenes VPC-Netzwerk, mit dem eine Verbindung zu anderen Google Cloud-Diensten wie Cloud SQL und Memorystore hergestellt werden kann.

Für VMware ist es nicht erforderlich, NSX-T lokal zu verwenden. Die Verwendung von HCX ist in keinem der Anwendungsfälle obligatorisch. Dies liegt daran, dass Sie andere Mechanismen verwenden können, um Layer 2 (L2) Stretch und Arbeitslast-Migration zu erreichen. Wir empfehlen aber HCX für eine effiziente Migration und Benutzerfreundlichkeit, da dieses Feature beim Erstellen einer privaten Cloud automatisch bereitgestellt wird. HCX wird also unabhängig davon bereitgestellt, ob Sie es verwenden oder nicht.

Netzwerkfunktionen

Im Folgenden finden Sie eine Zusammenfassung der Netzwerkfunktionen in VMware Engine:

  • Subnetze: Sie können Verwaltungs- und Arbeitslast-Subnetze in Ihren privaten Clouds erstellen.
  • Dynamisches Routing: Von NSX verwaltete VMware Engine-Subnetze werden automatisch für den Rest des Google-Netzwerks sowie für Ihre lokalen Standorte über das Border Gateway Protocol (BGP) beworben.
  • Public-IP-Service und Internet-Gateway (eingehender und ausgehender Traffic): VMware Engine verfügt über einen eigenen Public-IP-Service für eingehenden und ausgehenden Traffic am Internet-Gateway. Das ist ein regionaler Dienst.
  • Firewall-Richtlinien: Mit VMware Engine können Sie L4- und L7-Firewallrichtlinien mit der verteilten NSX-Firewall (Ost-West) und der NSX-Gateway-Firewall (Nord-Süd) erstellen. Sie können beispielsweise detaillierte Kontrollmöglichkeiten für den Zugriff auf Arbeitslasten mit öffentlichen IP-Adressen wie Webservern erzwingen.
  • Dienstverkettung für Ost-West-Sicherheit: Ermöglicht die Registrierung einer Partnersicherheitslösung (IDS, IPS oder NGFW), um Netzwerkdienste zu konfigurieren, dass sie Ost-West-Traffic, der sich bewegt zwischen den VMS, zu untersuchen.
  • NSX-T Distributed Intrusion Detection Service (IDS): Die Version von NSX, die in VMware Engine ausgeführt wird, unterstützt NSX Distributed IDs für Bedrohungserkennung und Berichterstellung. Für diese Funktion ist eine zusätzliche Lizenz von VMware erforderlich. Weitere Informationen finden Sie unter VMware NSX Distributed IDS/IPS.
  • Endpunktschutz: Mit VMware Engine gesicherte VMs können über die Partnerintegration mit unterstützten Drittanbietern vor Malware und Viren geschützt werden. Weitere Informationen finden Sie in der offiziellen VMware-Dokumentation.
  • Privater Zugriff auf andere Google-Dienste: VMware Engine kann über den privaten Google-Zugriff und den Zugriff auf private Dienste in andere Google Cloud-Dienste eingebunden werden. Eine vollständige Liste der unterstützten Dienste finden Sie unter Optionen für den Zugriff auf private Dienste.
  • DNS-Profile
    • DNS für die Verwaltung: VMware Engine stellt für jede private Cloud automatisch ein Paar von DNS-Servern bereit, um die verschiedenen Verwaltungskomponenten (vCenter, NSX Manager usw.) aufzulösen.
    • DNS für Arbeitslasten: Für jede private Cloud entscheiden Sie, welche DNS-Einrichtung für Sie am besten geeignet ist. Mit dem DNS-Dienst NSX-T können Sie DNS-Abfragen an bestimmte DNS-Server weiterleiten. Außerdem können Sie den DNS-Server in VMware Engine oder lokal erstellen oder Cloud DNS verwenden.
  • DHCP-Server: DHCP-Serverunterstützung für NSX-T-Segmente ist enthalten.
  • DHCP-Relay: Mit dem DHCP-Relay können Organisationen beispielsweise ein lokales IPAM-System zur IP-Adressenverwaltung integrieren.
  • Point-to-Site-VPN: Mit dem Point-to-Site-VPN-Gateway können Sie von einem Clientcomputer zur privaten Cloud eine Remote-Verbindung zu Ihrem VMware Engine-Netzwerk herstellen. Sie benötigen einen VPN-Client, um von Ihrem Computer aus eine Verbindung zu VMware Engine herzustellen. Sie können den OpenVPN-Client für Windows oder Viscosity für macOS herunterladen.
  • Site-to-Site-L2-VPN und -L3-VPN: Diese Dienste sind in NSX direkt mit L2VPN bzw. IPsec VPN konfiguriert.
  • Load-Balancing: Dieser Dienst verwendet die integrierten Load-Balancing-Funktionen von NSX-T, die L4- und L7-Unterstützung sowie Systemdiagnosen enthalten.
  • Teilweise Unterstützung für IP-Multicast-Routing: Protocol Independent Multicast (PIM) wird unterstützt, wie in der VMware-Dokumentation beschrieben.
  • Teilweise IPv6-Unterstützung Mit diesem Feature können Organisationen IPv6 für ihre VMware Engine-gestützten Anwendungen verwenden, wie in denNSX-T 3.0 Designanleitung beschrieben.
  • Langstrecken-VM-Migration (vMotion): Sowohl Live-Migrationen (Anwendungen werden weiterhin ausgeführt) als auch kalte Migrationen (Anwendungen sind ausgeschaltet) werden zwischen lokalen und Cloud-Umgebungen oder von Cloud zu Cloud innerhalb der VMware Engine unterstützt, mit eingebetteter WAN-Optimierung, Verschlüsselung und Mobilität mit Replikationsunterstützung. Dies ist aufgrund von VMware HCX möglich, was im Service enthalten ist.
  • Erweiterte Netzwerkvorgänge: Sie können integrierte NSX-Tools und -Instrumentierung verwenden, z. B. Portspiegelung, Traceflow, Paketerfassung und SNMP v1/v2/v3 mit Abfragen und Traps, unter anderem.

Netzwerke und Adressbereiche

Google Cloud VMware Engine erstellt ein Netzwerk für jede Region, in der Ihr VMware Engine-Dienst bereitgestellt wird. Das Netzwerk ist ein einzelner TCP-Layer-3-Adressbereich mit standardmäßig aktiviertem Routing. Alle privaten Clouds und Subnetze, die Sie in dieser Region erstellen, können ohne zusätzliche Konfiguration miteinander kommunizieren. Sie können mit NSX-T Netzwerksegmente (Subnetze) für Ihre Arbeitslast-VMs erstellen. Sie können einen beliebigen RFC 1918-Adressbereich konfigurieren, der sich nicht mit lokalen Netzwerken, dem Verwaltungsnetzwerk Ihrer privaten Cloud oder VPC-Subnetzen überschneidet.

Standardmäßig können alle Subnetze miteinander kommunizieren, wodurch der Konfigurationsaufwand für das Routing zwischen den privaten Clouds reduziert wird. Der Traffic zwischen privaten Clouds in derselben Region bleibt im selben Layer-3-Netzwerk und wird über die lokale Netzwerkinfrastruktur innerhalb der Region übertragen. Daher ist für die Kommunikation zwischen diesen privaten Clouds kein Ausgangstraffic erforderlich. Bei diesem Ansatz kommt es zu keiner Verschlechterung des WANs oder des ausgehenden Traffics, wenn Sie verschiedene Arbeitslasten in verschiedenen privaten Clouds bereitstellen.

Eine private Cloud wird konzeptionell als eine isolierte VMware-Stack-Umgebung (ESXi-Hosts, vCenter, vSAN und NSX) erstellt, die von einem vCenter-Server verwaltet wird. Die Verwaltungskomponenten werden im Netzwerk bereitgestellt, das für den CIDR-Bereich für vSphere/vSAN-Subnetze ausgewählt wurde. Der Netzwerk-CIDR-Bereich wird während der Bereitstellung in verschiedene Subnetze unterteilt.

Verwaltungs-Subnetze in VMware Engine

VMware Engine verwendet mehrere IP-Adressbereiche. Einige IP-Adressbereiche sind obligatorisch und andere hängen von den Diensten ab, die Sie bereitstellen möchten. Der IP-Adressbereich darf keine Überschneidungen mit lokalen Subnetzen, VPC-Subnetzen oder geplanten Arbeitslast-Subnetzen haben. In den folgenden Abschnitten werden die Adressbereiche und die zugehörigen Dienste beschrieben, die diese Bereiche verwenden.

Das folgende Diagramm gibt einen Überblick über die Verwaltungssubnetze für die Dienste, die in den folgenden Abschnitten erläutert werden:

Verwaltungs-Subnetze

vSphere/vSAN CIDR

Die folgenden IP-Adressbereiche sind für die Initialisierung und die Erstellung einer privaten Cloud erforderlich:

Name Beschreibung Adressbereich
vSphere/vSAN CIDR Erforderlich für VMware Management-Netzwerke. Muss während der Erstellung der privaten Cloud angegeben werden. Auch bei VMotion erforderlich. /21, /22, /23 oder /24

Wenn Sie eine private Cloud erstellen, werden mehrere Verwaltungssubnetze automatisch erstellt. Die Verwaltungssubnetze verwenden die erforderliche vSphere/vSAN-CIDR-Zuordnung, die weiter oben in diesem Dokument beschrieben ist. Im Folgenden finden Sie eine Beispielarchitektur und Beschreibung der verschiedenen Subnetze, die mit diesem CIDR-Bereich erstellt wurden:

  • Systemverwaltung: VLAN und Subnetz für das Verwaltungsnetzwerk, den DNS-Server und den vCenter-Server der ESXi-Hosts.
  • VMotion: VLAN und Subnetz für das vMotion-Netzwerk von ESXi-Hosts
  • VSAN: VLAN und Subnetz für das vSAN-Netzwerk von ESXi-Hosts
  • NsxtEdgeUplink1: VLAN und Subnetz für VLAN-Uplinks zu einem externen Netzwerk.
  • NsxtEdgeUplink2: VLAN und Subnetz für VLAN-Uplinks zu einem externen Netzwerk.
  • NsxtEdgeTransport: VLAN und Subnetz für Transportzonen steuern die Reichweite von Ebene-2-Netzwerken in NSX-T.
  • NsxtHostTransport: VLAN und Subnetz für die Transportzone des Hosts.

Beispiel:

Der angegebene CIDR-Bereich von vSphere/vSAN-Subnetzen ist in mehrere Subnetze unterteilt. In der folgenden Tabelle finden Sie ein Beispiel der Aufschlüsselung zulässiger Präfixe (von /21 bis /24) mithilfe von 192.168.0.0 als CIDR-Bereich.

Angegebenes CIDR/Präfix für vSphere/vSAN-Subnetze 192.168.0.0/21 192.168.0.0/22 192.168.0.0/23 192.168.0.0/24
Systemverwaltung 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
Host-Transport in 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-Transport 192.168.7.208/28 192.168.3.208/28 192.168.1.208/28 192.168.0.208/28
NSX-T-Edge-Uplink1 192.168.7.224/28 192.168.3.224/28 192.168.1.224/28 192.168.0.224/28
NSX-T-Edge-Uplink2 192.168.7.240/28 192.168.3.240/28 192.168.1.240/28 192.168.0.240/28

Je nach ausgewähltem CIDR-Bereich ändert sich die Subnetzmaske für jedes Subnetz. Wenn Sie beispielsweise ein vSphere/vSAN CIDR von /21 wählen, werden folgende Subnetze erstellt: ein /24 Systemverwaltungssubnetz, ein /24 vMotion-Subnetz, ein /24 vSAN-Subnetz, ein /23 NSX-T Host-Transport-Subnetz, ein /28 NSX-T Edge-Transport-Subnetz, ein /28 NSX-T Edge uplink1 und ein /28 NSX-T Edge uplink2.

CIDR-Bereich für HCX-Bereitstellung

Die folgenden IP-Adressbereiche sind für HCX in Ihrer privaten Cloud erforderlich:

Name Beschreibung Adressbereich
CIDR-Bereich für HCX-Bereitstellung Erforderlich für die Bereitstellung von HCX-Netzwerken. Kann während der Erstellung der privaten Cloud optional angegeben werden. /27 oder größer

Zugewiesener Adressbereich

Für den Zugriff auf private Dienste auf VMware Engine sind die folgenden IP-Adressen erforderlich:

Name Beschreibung Adressbereich
Zugewiesener Adressbereich Adressbereich, der für die private Dienstverbindung zu Google Cloud-Diensten einschließlich VMware Engine verwendet werden soll. /24 oder größer

Edge-Dienste und Client-Subnetz

Die folgenden IP-Adressbereiche sind für die Aktivierung von Edge-Netzwerkdiensten erforderlich, die von VMware Engine bereitgestellt werden:

Name Beschreibung Adressbereich
Edge Dienste-CIDR-Bereich Erforderlich, wenn optionale Edge-Dienste wie Point-to-Site-VPN, Internetzugriff und öffentliche IP-Adresse aktiviert sind. Bereiche werden pro Region festgelegt. /26
Clientsubnetz Erforderlich für Point-to-Site-VPN. DHCP-Adressen werden der VPN-Verbindung aus dem Client-Subnetz bereitgestellt. /24

Google-Optionen für den privaten Zugriff auf Dienste

Google Cloud bietet mehrere private Zugriffsoptionen für Arbeitslasten, die in VMware Engine oder in Ihren Google Virtual Private Cloud-Netzwerken ausgeführt werden. Der Zugriff auf private Dienste stellt eine private Verbindung zwischen Ihrem VPC-Netzwerk und dem VMware Engine-Dienst her. Wenn Sie den privaten Google-Zugriff verwenden, können Ihre VMware-Arbeitslasten auf andere Cloud APIs und -Dienste zugreifen, ohne das Google Cloud-Netzwerk zu verlassen.

Zugriff auf private Dienste

VMware Engine verwendet den Zugriff auf private Dienste, um Ihr VPC-Netzwerk über eine private IP-Adressierung mit einem Dienstersteller-VPC-Netzwerk in einem Mandantenordner in Ihrer Google-Organisation zu verbinden.

Informationen zum Konfigurieren des Zugriffs auf private Dienste finden Sie unter Zugriff auf private Dienste konfigurieren. Durch den Zugriff auf private Dienste wird eine VPC-Netzwerk-Peering-Verbindung erstellt, daher ist es wichtig, Routen zu importieren und zu exportieren.

Google und Drittanbieter (zusammen als Dienstersteller bezeichnet) können Dienste mit internen IP-Adressen anbieten, die in einem VPC-Netzwerk gehostet werden. Mit dem Zugriff auf private Dienste können Sie diese internen IP-Adressen erreichen. Die private Verbindung ermöglicht folgende Funktionen:

  • VM-Instanzen in Ihrem VPC-Netzwerk und die VMware-VMs kommunizieren ausschließlich über interne IP-Adressen. VM-Instanzen erfordern keinen Internetzugang oder externe IP-Adressen, um Dienste zu erreichen, die über den Zugriff auf private Dienste erreichbar sind.

  • Kommunikation zwischen VMware-VMs und den von Google Cloud unterstützten Diensten, die den Zugriff auf private Dienste über interne IP-Adressen unterstützen.

  • Wenn Sie über Cloud VPN oder Cloud Interconnect eine lokale Verbindung zu Ihrem VPC-Netzwerk herstellen, können Sie vorhandene lokale Verbindungen verwenden, um eine Verbindung zu Ihrer privaten VMware Engine-Cloud herzustellen.

Wenn Sie in Ihrem eigenen Projekt ein freigegebenes VPC-Netzwerk verwenden, muss der zugewiesene IP-Bereich und die private Verbindung im Hostprojekt erstellt werden, damit VM-Instanzen in Dienstprojekten eine Verbindung mit der Umgebung herstellen können.

Sie können private Dienstzugriffe unabhängig von der Erstellung der privaten Cloud in VMware Engine einrichten. Sie können vor oder nach der Erstellung der privaten Cloud, die Sie mit dem VPC-Netzwerk verbinden möchten, auch eine private Verbindung erstellen.

Wenn Sie den Zugriff auf private Dienste konfigurieren, müssen Sie daher einen internen IP-Adressbereich zuweisen und dann eine private Verbindung erstellen, wie im vorherigen Abschnitt beschrieben. Dieser zugewiesene Bereich ist ein reservierter CIDR-Block, der für die Verbindung für den Zugriff auf private Dienste verwendet wird und nicht in Ihrem lokalen VPC-Netzwerk verwendet werden kann. Dieser Bereich wird nur für Dienstersteller reserviert und verhindert Überschneidungen zwischen Ihrem VPC-Netzwerk und dem VPC-Netzwerk des Diensterstellers. Wenn Sie eine private Dienstverbindung erstellen, müssen Sie eine Zuweisung angeben. Weitere Informationen zur Diensterstellerseite finden Sie unter Zugriff auf private Dienste aktivieren.

Um IP-Adressüberschneidungen zu vermeiden, empfehlen wir, alle VMware Engine-Subnetze in der privaten Dienstverbindung zuzuordnen. Im folgenden Screenshot wird der CIDR-Block von VMware Engine für die private Dienstverbindung und der CIDR-Block gcve-2 zugewiesen, um IP-Adressüberschneidungen zu verhindern:

Der VMware Engine-CIDR-Block wird für die private Dienstverbindung verwendet.

Service Networking prüft nicht auf überlappende Adressen bei empfangenen dynamischen Routen, daher müssen Sie den Zugriff auf private Dienste mit Präfixen verknüpfen, die für Nicht-VMware-Dienste reserviert sind. Dadurch werden Probleme verhindert, die durch sich überschneidende IP-Adressen entstehen, da Sie CIDR-Bereiche reservieren und diese in Ihrem VPC-Netzwerk nicht verwenden können.

Wenn Sie den Zugriff auf private Dienste konfigurieren, muss die VPC-Peering-Verbindung richtig konfiguriert sein, um auf der privaten Verbindung servicenetworking-googleapis-com alle Routen zu importieren und zu exportieren. Notieren Sie sich auch die Peering-Projekt-ID, damit Sie sie beim Einrichten einer privaten Verbindung in VMware Engine verwenden können.

Das VPC-Netzwerk des Diensterstellers wird automatisch mit dem VMware Engine-Dienst verbunden, der Ihre private Cloud enthält (eine private vCenter- und einzelne NSX-T-Installation).

VMware Engine verwendet dieselbe Verbindung zu mehreren Google Cloud-Diensten, die innerhalb der Service-Producer-VPC bereitgestellt werden und den Zugriff auf private Dienste nutzen, wie z. B. Cloud SQL, Memorystore für Redis, Memorystore für Memcached, AI Platform Training und private GKE-Cluster. Wenn Sie diese Dienste nutzen möchten, können Sie den CIDR-Bereich auswählen, mit dem Sie die private Dienstverbindung mit VMware hergestellt haben.

Wenn der Status der Region im VMware Engine-Dienstportal verbunden ist, können Sie die private Verbindung über die Mandanten-Projekt-ID der entsprechenden Region prüfen. In den Details der privaten Verbindung werden die über VPC-Peering erlernten Routen angezeigt. Die exportierten Routen zeigen private Clouds, die aus der Region abgerufen und über VPC-Peering exportiert wurden.

Eine private Cloud stellt eine einzelne vCenter- und eine NSX-T-Installation mit maximal 64 Knoten dar. Sie können mehrere private Clouds bereitstellen. Wenn Sie das Limit von 64 Knoten für eine private Cloud erreichen, können Sie eine weitere private Cloud erstellen. Das bedeutet, dass Sie zwei private Clouds, zwei vCenter-Installationen und zwei NSX-T-Installationen verwalten.

Je nach Anwendungsfall können Sie eine einzelne private Cloud oder mehrere private Clouds bereitstellen, ohne das Limit von 64 Knoten zu erreichen. Sie können beispielsweise eine private Cloud mit Datenbankarbeitslasten und eine separate private Cloud für einen VDI-Anwendungsfall oder eine private Cloud für Arbeitslasten in Amerika und eine andere private Cloud für Arbeitslasten in der EMEA-Region bereitstellen. Alternativ können Sie Arbeitslasten je nach Anwendungsfall in mehreren Clustern innerhalb derselben privaten Cloud trennen.

Privater Google-Zugriff

Mit privatem Google-Zugriff können Sie eine Verbindung zu Google APIs und Google-Diensten herstellen, ohne Ihren VMware Engine-VMs externe IP-Adressen zuzuweisen. Nach der Konfiguration des privaten Google-Zugriffs wird der Traffic an das Internet-Gateway und dann an den angefragten Dienst weitergeleitet, ohne das Google-Netzwerk zu verlassen.

Weitere Informationen finden Sie unter Privater Google-Zugriff: Details.

Wichtige Trafficflüsse

In diesem Abschnitt werden einige wichtige Traffic-Flüsse beschrieben und die Architektur beschrieben, mit der alle verschiedenen Netzwerkflüsse abgedeckt wird.

Im Folgenden finden Sie Beispiele, was Sie berücksichtigen sollten, wenn Sie ein Design für VMware Engine erstellen.

VMware Engine lokale und Remote-Nutzerverbindung

Im Folgenden sind die Optionen aufgeführt, mit denen Sie von einem lokalen Rechenzentrum oder von einem Remotestandort aus auf die VMware Engine-Umgebung zugreifen können:

VPN-Gateways bieten eine sichere Verbindung zwischen mehreren Standorten, z. B. lokale, VPC-Netzwerk- und private Clouds. Diese verschlüsselten VPN-Verbindungen werden über das Internet übertragen und in einem VPN-Gateway beendet. Wenn Sie mehrere Verbindungen zu demselben VPN-Gateway erstellen, nutzen alle VPN-Tunnel die verfügbare Gateway-Bandbreite.

Mit Point-to-Site-VPN-Gateways können Nutzer von ihren Computern aus eine Verbindung zu VMware Engine herstellen. Beachten Sie, dass Sie nur ein Point-to-Site-VPN-Gateway pro Region erstellen können.

Das Point-to-Site-VPN-Gateway ermöglicht TCP- und UDP-Verbindungen und Sie können das Protokoll auswählen, das beim Herstellen einer Verbindung von Ihrem Computer aus verwendet werden soll. Darüber hinaus wird das konfigurierte Client-Subnetz für TCP- und UDP-Clients verwendet und der durch den CIDR-Block definierte Bereich wird in zwei Subnetze aufgeteilt, eine für TCP- und eine für UDP-Clients.

Das Point-to-Site-VPN sendet verschlüsselten Traffic zwischen einem regionalen VMware Engine-Netzwerk und einem Client-Computer. Sie können das Point-to-Site-VPN verwenden, um auf Ihr privates Cloud-Netzwerk zuzugreifen, einschließlich Ihrer privaten Cloud vCenter- und Arbeitslast-VMs. Informationen zur Einrichtung eines Point-to-Site-VPN-Gateways finden Sie unter VPN-Gateways im VMware Engine-Netzwerk konfigurieren.

Sie können Cloud VPN auch für standortübergreifende VPN-Verbindungen oder Cloud Interconnect zum Herstellen von Verbindungen zwischen Ihrem lokalen Netzwerk und Ihrer privaten VMware Engine-Cloud verwenden. Sie stellen Cloud VPN und Cloud Interconnect in Ihrem VPC-Netzwerk bereit. Weitere Informationen finden Sie in der Dokumentation zu Cloud VPN und Cloud Interconnect.

Eine weitere Option für die VPN-Konnektivität ist NSX-T IPsec VPN, NSX-T L2 VPN und HCX L2 VPN – zum Beispiel, um einen L2-Stretch zu konfigurieren. Ein Anwendungsfall für das NSX-T IPsec-VPN ist die Ende-zu-Ende-Verschlüsselung mit VPN-Beendigung direkt in der privaten VMware Engine-Cloud. Weitere Informationen zu den NSX-T VPN-Funktionen finden Sie in der VMware-Dokumentation zu Virtuelles Privates Netzwerk.

Wir empfehlen, den Zugriff auf private Dienste in dem VPC-Netzwerk zu konfigurieren, in dem sich der Cloud Router oder Cloud VPN befindet (und in dem die VLAN-Anhänge eingesetzt werden, wenn das Border Gateway Protocol verwendet wird). Andernfalls müssen VPC-Routen konfiguriert werden. Wenn die Architektur mehrere VPC-Peering-Verbindungen enthält, müssen Sie beachten, dass VPC-Peering nicht transitiv ist.

Die lokal über Interconnect oder VPN beworbenen Routen werden automatisch über den Zugriff auf private Dienste übertragen, wenn der Import und der Export von Routen konfiguriert ist. Dies erfordert, dass Sie Import- und Exportrouten manuell in der VPC-Peering-Verbindung bearbeiten.

Beachten Sie außerdem, dass die durch den Zugriff auf private Dienste erlernten Routen nicht automatisch an lokale Systeme weitergegeben werden, da VPC-Netzwerk-Peering kein transitives Routing unterstützt. Importierte Routen aus anderen Netzwerken werden von Cloud Routern in Ihrem VPC-Netzwerk nicht automatisch beworben. Sie können jedoch das Bewerben benutzerdefinierter IP-Bereiche durch Cloud Router in Ihrem VPC-Netzwerk dazu verwenden, Routen zu Zielen im Peering-Netzwerk freizugeben. Für Cloud VPN-Tunnel, die statisches Routing verwenden, müssen Sie in Ihrem lokalen Netzwerk statische Routen zu den Zielbereichen des Peering-Netzwerks konfigurieren.

Eingehender Traffic zu VMware Engine

In diesem Abschnitt werden die folgenden Optionen für eingehenden Traffic zu VMware Engine beschrieben:

  • Eingehender Traffic mithilfe dem öffentlichen IP-Dienst von VMware Engine
  • Eingehender Traffic aus der VPC des Kunden
  • Eingehender Traffic aus einem lokalen Rechenzentrum

Welche Option Sie auswählen, hängt davon ab, wo Sie Ihre Google Cloud-Infrastruktur mit dem Internet verbinden möchten. Das folgende Diagramm zeigt diese Optionen für eingehenden Traffic.

Eingehender Traffic-Optionen.

Die folgenden Abschnitte behandeln ausführlich jede dieser Optionen.

Eingehender Traffic mithilfe VMware Engine

Wenn Sie das Internet-Gateway der VMware Engine verwenden, können on demand IP-Adressen für Ressourcen in der privaten Cloud des VMware Engine-Portals erstellt und gelöscht werden. In diesem Szenario entspricht jede öffentliche IP-Adresse einer eindeutigen konfigurierten privaten Cloud-IP-Adresse.

Öffentlicher Eingehender Traffic kann über das öffentliche IP-Gateway bereitgestellt werden, das ebenfalls für NAT verantwortlich ist, sodass Nutzer, die aus dem öffentlichen Internet zugreifen, eine Verbindung zur öffentlichen Google-IP-Adresse herstellen. Die öffentliche Google-IP-Adresse wird in eine private VM-IP-Adresse in VMware Engine übersetzt, die von NSX-T-Segmenten unterstützt wird.

Wenn Sie Firewallregeln erstellen, um eingehende Verbindungen von außerhalb zu einer freigegebenen öffentlichen IP-Adresse zuzulassen, werden Firewallregeln auf ein öffentliches IP-Gateway angewendet und diese Firewallregeln müssen im VMware Engine-Portal bereitgestellt werden.

Ein logischer Ebene-0-Router wird in der Regel für das Routing von Nord-Süd verwendet, zum Beispiel eine virtuelle Maschine, die eine Verbindung zum Internet herstellt. Für das Ost-West-Routing wird ein logischer Ebene-1-Router verwendet. Sie können mehrere Subnetze für Ebene 1 konfigurieren.

Über eine öffentliche IP-Adresse können Internetressourcen eingehende Daten an private Cloud-Ressourcen über eine private IP-Adresse kommunizieren. Die private IP-Adresse ist eine virtuelle Maschine oder einen Software-Load-Balancer in Ihrem Private Cloud-vCenter. Mithilfe der öffentlichen IP-Adresse können Sie Dienste, die in Ihrer privaten Cloud ausgeführt werden, im Internet verfügbar machen.

Eine Ressource, die einer öffentlichen IP-Adresse zugeordnet ist, verwendet immer die öffentliche IP-Adresse für den Internetzugriff. Standardmäßig ist in einer öffentlichen IP-Adresse nur der ausgehende Internetzugriff zulässig und eingehender Traffic über die öffentliche IP-Adresse wird verweigert. Erstellen Sie eine Firewallregel für die öffentliche IP-Adresse mit dem jeweiligen Port, um eingehenden Traffic zuzulassen.

Nutzer in Ihrem Unternehmen können öffentliche IPs für bestimmte Knoten in ihrer privaten Cloud, z. B. für VM-Arbeitslasten, freigeben und zuweisen. Die öffentliche IP-Adresse kann nur einer privaten IP-Adresse zugewiesen werden. Die öffentliche IP-Adresse ist dieser privaten IP-Adresse zugewiesen, bis Sie die Zuweisung aufheben. Wir empfehlen, keine ESXi-Hosts oder vCenter bereitzustellen.

Wenn Sie eine öffentliche IP-Adresse zuweisen möchten, müssen Sie einen Namen, einen Standort oder eine Region und die angehängte lokale Adresse angeben.

Eingehender Traffic über ein VPC-Netzwerk des Kunden

Sie können eingehenden Traffic für VMware Engine über das Cloud-VPC-Netzwerk des Kunden bereitstellen. Wenn Sie den Load-Balancer Ihrer Wahl je nach den erforderlichen Funktionen auswählen, können Sie eine verwaltete Instanzgruppe (MIG) oder eine nicht verwaltete Instanzgruppe als Back-End für diesen Load-Balancer erstellen, um den Traffic über die VPC-Peering-Verbindung zu projizieren. In diesem Szenario können Sie auch eine virtuelle Netzwerk-Appliance eines Drittanbieters von Google Cloud Marketplace verwenden.
Sie können Cloud Load Balancing mit Bring Your Own IP (BYOIP) kombinieren, für den Fall, dass Sie Ihren eigenen öffentlichen IP-Bereich für Google nutzen möchten, sowie mit Google Cloud Armor, um Ihre Anwendungen und Websites vor Distributed Denial of Service (DDOS) und Webangriffen wie SQL-Injection oder Cross-Site Scripting zu schützen.

Eingehender Traffic mithilfe von lokalen Kundenumgebungen

Zum Bereitstellen eines lokalen eingehenden Traffic empfehlen wir die Verwendung von Cloud Interconnect. Für den Proof of Concept oder wenn Sie einen niedrigen Durchsatz und keine Latenzanforderungen haben, können Sie stattdessen Cloud VPN verwenden.

Ausgehender Traffic von VMware Engine

Es gibt mehrere Optionen für ausgehenden Traffic von VMware Engine:

  • Ausgehender Traffic über das Internet-Gateway von VMware Engine
  • Ausgehender Traffic über die VPC des Kunden
  • Ausgehender Traffic über ein lokales Rechenzentrum

In der folgenden Architektur können Sie diese Optionen für ausgehenden Traffic-Fluss aus der VMware Engine-Perspektive sehen.

Ausgehender Traffic-Fluss aus VMware Engine-Perspektive

Öffentlicher ausgehender Traffic mithilfe VMware Engine

Sie können den Internetzugriff und die öffentlichen IP-Dienste für Ihre Arbeitslasten separat für jede Region konfigurieren. Sie können Internettraffic von Ihren VMware-Arbeitslasten mithilfe der Internet-Edge von Google Cloud oder einer lokalen Verbindung leiten.

Der Traffic von einer virtuellen Maschine, die in einer privaten VMware Engine-Cloud gehostet wird und über das Gateway „tier-0“ für ausgehenden Internettraffic zuständig ist. Das Gateway „tier-0“ leitet Traffic an das Internet-Gateway weiter. Das Internet-Gateway führt eine PAT (Source Port Address Translation) durch. Der Internetdienst ist regional, d. h., er ist für jede Region einzeln aktiviert.

Öffentlicher ausgehender Traffic mithilfe Ihres VPC-Netzwerk

Alternativ können Sie über das VMware Engine-Dienstportal Internet- und öffentliche IP-Dienste deaktivieren und öffentlichen ausgehenden Traffic vom VPC-Netzwerk des Kunden ermöglichen. In diesem Fall erfolgt der Internetzugriff über Ihr VPC-Netzwerk, wenn Sie die Standardroute 0.0.0.0/0 beworben haben. Wenn Sie diesen Paketfluss verwenden möchten, deaktivieren Sie den Internetzugriff für die VMware Engine-Region und fügen Sie die Standardroute 0.0.0.0/0 ein.

Sie müssen außerdem alle zugewiesenen öffentlichen IP-Adressen und Point-to-Site-VPN-Gateways entfernen, bevor Sie Traffic über Ihr VPC-Netzwerk nach draußen senden können.

Die Standardroute muss im VPC-Netzwerk des Kunden sichtbar sein und wird anschließend automatisch an VMware Engine weitergegeben. Voraussetzung ist, VPC Service Controls für die VPC-Peering-Verbindung zwischen Ihrer VPC und VMware zu aktivieren.

Um Network Address Translation (NAT) durchzuführen, können Sie eine Compute Engine-Instanz bereitstellen oder die Standardroute 0.0.0.0/0 haben, die auf einen internen Load-Balancer verweist, der mit einem zentralisierten virtuellen Netzwerk-Appliance-Cluster eines Drittanbieters (verfügbar auf Cloud Marketplace) gepaart ist, und Source-NAT in der Instanz durchführen, um aus Ihrem VPC-Netzwerk in das öffentliche Internet zu gelangen. Weitere Informationen finden Sie unter Routen in Ihrem VPC-Netzwerk verwenden.

Öffentlicher ausgehender Traffic über ein lokales Rechenzentrum

Sie können ausgehenden Traffic über Ihr lokales Rechenzentrum leiten, wenn Sie Internet- und öffentliche IP-Dienste deaktivieren und öffentlichen ausgehenden Traffic von lokalen Umgebungen zulassen. In diesem Fall fließt der Internetzugriff durch Ihr VPC-Netzwerk, bevor er das lokale Rechenzentrum über Cloud VPN oder Cloud Interconnect erreicht.

Wenn Sie öffentlichen ausgehenden Traffic über Ihr lokales Rechenzentrum implementieren möchten, bewerben Sie eine standardmäßige 0.0.0.0/0-Route und aktivieren dann VPC Service Controls für die Peering-Verbindung, damit die Standardroute ordnungsgemäß importiert wird, wie hier beschrieben. Weitere Informationen zu VPC Service Controls finden Sie in der offiziellen Dokumentation.

Wenn VPC Service Controls für die VPC-Peering-Verbindung deaktiviert ist, wird der Internetzugriff über eine lokale Verbindung ebenfalls deaktiviert, selbst wenn eine Standardroute (0.0.0.0/0) beworben und über die VPC-Peering-Verbindung weitergegeben wird.

Dienstübersicht: Private Cloud zu privater Cloud

Private Clouds werden über das VMware Engine-Serviceportal verwaltet. Private Clouds haben einen eigenen vCenter-Server, der sich in einer eigenen Verwaltungsdomain befindet. Der VMware-Stack wird auf dedizierten, isolierten Bare-Metal-Hardware-Knoten an Google Cloud-Standorten ausgeführt. Die private Cloudumgebung ist so konzipiert, dass Single Points of Failure beseitigt werden.

Das folgende Diagramm zeigt die Architektur und den Trafficfluss, wenn zwei private Clouds miteinander kommunizieren.

Trafficfluss, wenn zwei private Clouds miteinander kommunizieren.

Die Kommunikation zwischen zwei privaten Clouds in derselben Region innerhalb des VMware Engine-Dienstes erfolgt über direkte Verbindungen. Sie können mehrere private Clouds in derselben Region bereitstellen, sodass die Kommunikation zwischen diesen privaten Clouds lokal erfolgt.

Wenn sich private Clouds in verschiedenen Regionen befinden, erfolgt die Verbindung durch das VPC-Netzwerk des Diensterstellers, das von Google verwaltet wird und sich im Besitz von Google befindet.

Kunden beginnen mit einer privaten Cloud und können on demand Knoten erweitern oder erhöhen (und verkleinern) und die neuen Knoten entweder in einem vorhandenen vSphere-Cluster platzieren oder in einem neuen Cluster erstellen (alles in der selben privaten Cloud).

Dienstübersicht: Private Cloud zu VPC

In diesem Abschnitt wird die Konnektivität zwischen Ihrem VPC-Netzwerk und der privaten Cloud beschrieben. Ihr VPC-Netzwerk verwendet das Zugriffsmodell für private Dienste, um mit dem Peering-VPC-Netzwerk eine Peering-Verbindung herzustellen, und erweitert dann die Verbindung zur VMware Engine-Region. Globales Routing ist im VPC-Netzwerk des Diensterstellers aktiviert. Alle im Netzwerk des VMware Engine-Serviceportals erstellten Netzwerke werden vom Tier-0-Router in NSX-T automatisch beworben. Stellen Sie sicher, dass für die Peering-Verbindung das Import- und Export-Flag aktiviert ist, um Routen auszutauschen und eine Verbindung zwischen VMware Engine und Ihrer VPC herzustellen.

Das folgende Diagramm zeigt den Trafficfluss in diesem Fall.

Private Cloud zu VPC: Trafficfluss.

Dienstübersicht: Private Cloud zu freigegebener VPC

Wenn Sie ein freigegebenes VPC-Netzwerk verwenden, ähnelt die Verbindung dem obigen Beispiel zum Verbinden einer privaten Cloud mit einem VPC-Netzwerk. Der Unterschied besteht darin, dass, wenn Sie eine private Cloud mit dem freigegebenen VPC-Netzwerk verbinden, die Arbeitslasten im Service-Projekt ausgeführt werden und den IP-Adressraum im freigegebenen VPC-Netzwerk des Host-Projekts verwenden. Aus diesem Grund müssen Sie den Zugriff auf private Dienste im Hostprojekt konfigurieren, in dem das freigegebene VPC-Netzwerk und die Interconnect-Verbindung oder das VPN konfiguriert sind.

Wenn Sie beispielsweise die private Cloud, IAM und die Abrechnung in einem Dienstprojekt haben möchten, müssen Sie darauf achten, dass die Verbindung für den Zugriff auf private Dienste im freigegebenen VPC-Netzwerk des Hostprojekts hergestellt wird.

Dienstübersicht: Private Cloud zu lokaler Umgebung

Im Fall einer privaten Cloud zu einem lokalen Umgebung hat der Kunde ein VPC-Netzwerk in seinem Projekt und seiner Organisation. Die Verbindung erfolgt zwischen der privaten Cloud und dem lokalen Rechenzentrum.

Wie bereits erwähnt, muss der Kunde bei der Einrichtung von VMware Engine ein Subnetz (und idealerweise auch die Subnetze für den VMware Engine-Dienst, um zukünftige Konflikte zu vermeiden) für die Verbindung für den Zugriff auf private Dienste zuweisen. Während der Zuweisung des Subnetzes muss er ein Dienstanbieter-VPC-Netzwerk erstellen, das eine Verbindung zwischen ihm und der VMware Engine-Region herstellt, in der sich die private Cloud befindet.

Nachdem die VPC-Peering-Verbindung erstellt und bereitgestellt wurde, ist das VPC-Netzwerk des Diensterstellers mit dem VPC-Netzwerk des Kunden verbunden. Dadurch können alle Subnetze und IP-Adressen innerhalb des VPC-Netzwerks des Kunden von der privaten Cloud aus erreicht werden. Achten Sie darauf, den Import und Export von Routen in der VPC-Peering-Verbindung zu aktivieren, wenn Sie den Zugriff auf private Dienste konfigurieren.

Das folgende Diagramm zeigt die End-to-End-Konnektivität zwischen einer privaten Cloud in VMware Engine und einem lokalen Rechenzentrum.

End-to-End-Konnektivität zwischen einer privaten Cloud in VMware Engine und einem lokalen Rechenzentrum.

Privater Google-Zugriff: genauerer Blick

Wie bereits erwähnt, können Sie mit dem privaten Google-Zugriff eine Verbindung zu Google APIs und Google-Diensten herstellen, ohne Ihren Google Cloud-Ressourcen externe IP-Adressen zuzuweisen, sodass der VMware Engine-Dienst davon profitieren und das Internet-Gateway nutzen kann, um Google APIs zu erreichen.

VM-Instanzen, die nur interne IP-Adressen haben, können den privaten Google-Zugriff nutzen, um die externen IP-Adressen von Google APIs und Diensten zu erreichen. Wenn der private Google-Zugriff konfiguriert ist, wird der Traffic an das Internet-Gateway und dann an den angeforderten Dienst weitergeleitet.

Für die Aktivierung des privaten Google-Zugriffs für VMware Engine konfigurieren Sie den DNS-Server in Ihrer VMware Engine-Umgebung so, dass die private virtuelle IP-Adresse verwendet wird. Weitere Informationen finden Sie unter Privater Google-Zugriff für lokale Hosts und Privaten Google-Zugriff für lokale Hosts konfigurieren. In der Domain private.googleapis.com wird 199.36.153.8/30 verwendet.

Zur Verwaltung der DNS-Auflösung können Sie den in NSX-T bereitgestellten DNS-Dienst verwenden, um Anfragen an einen bestimmten DNS-Server weiterzuleiten. Der DNS-Server kann eine VM in VMware Engine, Cloud DNS oder ein lokaler DNS-Server sein. Je nachdem, wie Sie auf das Internet zugreifen, wie in einem früheren Abschnitt beschrieben, wird eine dieser Optionen verwendet.

Der private Google-Zugriff unterstützt die meisten Google APIs und Dienste wie Cloud Storage, Cloud Spanner und BigQuery. Derzeit unterstützt der private Google-Zugriff nicht App Engine, Memorystore, Filestore oder Cloud SQL.

Im Folgenden finden Sie Beispiele für die Verwendung von VMware Engine mit Google Cloud-Diensten:

  • Greifen Sie von VMware-VMs auf Cloud Storage zu, um Daten zu exportieren oder als erweitertes Speicherziel.
  • Überwachen Sie alle Ihre öffentlichen, privaten und hybriden Anwendungen mit Cloud Monitoring.
  • Importieren Sie Daten zur Analyse aus Datenbanken in BigQuery.
  • Stellen Sie Anthos für leistungsstarke und private, containerisierte Anwendungsbereitstellungen bereit.

Die Konfiguration des privaten Google-Zugriffs hängt vom Internetzugriff ab, der für VMware Engine aktiviert ist. Das wird im folgenden Diagramm dargestellt. Er kann entweder über das Dienst-Internetgateway von VMware Engine oder (2) über das Internetgateway des VPC-Netzwerks des Diensterstellers bereitgestellt werden.

Privaten Google-Zugriff konfigurieren

Wenn Internetzugriff über die VMware Engine bereitgestellt wird und für die Region aktiviert ist, verwenden der private Google-Zugriff und der Internetzugriff das Internet-Gateway.

Wenn Sie den Internetzugriff lokal oder über Ihr VPC-Netzwerk bereitstellen, deaktivieren Sie den öffentlichen IP-Dienst von VMware Engine und konfigurieren Sie VPC Service Controls in der Peering-Verbindung. Dadurch wird die Standardroute 0.0.0.0/0 mit dem Internetgateway am nächsten Hop aus dem Mandanten-VPC-Netzwerk in der Google-Organisation entfernt. In diesem Fall wird die Standardroute aus dem lokalen oder Ihrem VPC-Netzwerk akzeptiert, und der eingeschränkten virtuellen IP-Adresse 199.36.153.4/30 wird eine Route hinzugefügt, die auf das Internetgateway im VPC-Netzwerk des Mandanten verweist.

Option 1: Privater Google-Zugriff mit Internetzugriff bereitgestellt von VMware Engine

Wenn Sie Internetzugriff für eine Region über VMware Engine bereitstellen, nutzt der private Google-Zugriff und das Internet das Internet-Gateway und führt PAT aus. In diesem Fall benötigen Sie keine zusätzliche Konfiguration, nur die DNS-Auflösung für den privaten Google-Zugriff.

Option 2: Privater Google-Zugriff mit Internetzugriff bereitgestellt von lokaler oder Kunden-VPC

Wenn Sie Internetzugang mithilfe lokal oder über Ihr VPC-Netzwerk bereitstellen, müssen Sie den VMware Engine-Dienst so konfigurieren, dass Pakete an Google APIs über das Internet-Gateway im Mandanten-VPC-Netzwerk der Organisation weitergeleitet werden. Sie müssen den VMware Engine-Dienst so konfigurieren, dass Pakete für anderen Traffic über das VPC-Netzwerk des Kunden weitergeleitet werden, um lokale Netzwerke über VPN oder Interconnect oder über das VPC-Netzwerk des Kunden zu erreichen. Für den gesamten Traffic sollten Internetzugriff und öffentliche IP-Dienste für die VMware-Region deaktiviert werden. Außerdem sollte eine standardmäßige 0.0.0.0/0-Route über lokale eingefügt werden.

Wenn Sie Internetzugriff lokal oder über Ihr VPC-Netzwerk bereitstellen, entfernen Sie alle zugewiesenen öffentlichen IP-Adressen und Punkt-zu-Standort-VPN-Gateways, bevor Sie den öffentlichen IP-Dienst deaktivieren. Achten Sie darauf, dass die Route im VPC-Netzwerk des Kunden sichtbar ist und die Route in das Mandanten-VPC-Netzwerk exportiert wird.

Außerdem müssen Sie VPC Service Controls auf der VPC-Peering-Verbindung zwischen Ihrer VPC und VMware Engine aktivieren.

Schließlich muss der Zugriff auf Google APIs die eingeschränkte virtuelle IP-Adresse verwenden, sodass DNS entsprechend konfiguriert werden muss mit dem erforderlichen CNAME- und A-Einträgen. Der Zugriff auf Google APIs erfolgt über die Google-Organisation, nicht durch das VPC-Netzwerk des Kunden.

Private Cloud zu verwalteten Partnerdiensten

Mit Managed Partner Services (MPS) können Sie für Google Cloud-Kunden geschäftskritische SaaS-Angebote (Software as a Service) über Hardware und Software bereitstellen, die Sie in einer MPS-Colocations-Einrichtung bereitstellen.

Für den Trafficfluss zwischen einer privaten Cloud und MPS ist VPC-Peering nicht transitiv. In diesem Fall müssen Sie ein VPN zwischen NSX-T Ebene-0 in VMware Engine und Cloud VPN in Ihrem VPC-Netzwerk einrichten. Routen werden mit dem Border Gateway Protocol (BGP) ausgetauscht und dieselben privaten Zugriffsdienste, die das VPC-Peering-Modell verwenden, gelten für das Herstellen einer Verbindung mit MPS. Wenn Sie Cloud VPN und BGP verwenden, müssen Sie benutzerdefinierte Route Advertisements konfigurieren, damit diese Routen gegenüber NSX-T Ebene-0 beworben werden und es gibt eine End-to-End-Konnektivität. Ein Beispiel für diesen Ansatz ist der NetApp Cloud Volumes-Dienst für Google Cloud. Er nutzt den Zugriff auf private Dienste, um eine Datenpfad-Verbindung mit hohem Durchsatz und niedriger Latenz zu erstellen. Die private Cloud zu verwaltete Dienstanbieter funktioniert jedoch nicht mit Daten, die für VMware-Arbeitslasten gespeichert sind.

Das folgende Diagramm zeigt eine End-to-End-Konnektivität zwischen einer privaten Cloud in VMware Engine und MPS.

End-to-End-Konnektivität zwischen einer privaten Cloud in VMware Engine und MPS.

Wenn Sie einen MPS verwenden müssen und den Internetzugriff von VMware deaktiviert haben, und wenn Ihre Standardroute von der Dienstersteller-VPC stammt, können Sie RFC-1918-IP-Adressen für die VPN-Verbindung einrichten. Die VPN-Verbindung funktioniert zwischen NSX-T und einer virtuellen Appliance im VPC-Netzwerk des Kunden, z. B. einer virtuellen Netzwerk-Appliance eines Drittanbieters von Cloud Marketplace.

Zusätzliche Ressourcen: VMware

Weitere Informationen zum VMware-Stack finden Sie unter Versionen der VMware-Komponenten und im offiziellen Design-Leitfaden zu NSX 3.0.