Last reviewed 2023-03-01 UTC

Private Cloud-Netzwerke für VMware Engine

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 Infrastruktur mit hoher Kapazität, um Ihnen eine optimale und kostengünstige VMware-Erfahrung zu bieten.

Überblick

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 in 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 ermöglichen Ihnen den Zugriff von 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. Der umfassende End-to-End-Support bietet eine integrierte, nahtlose Erfahrung für diesen Dienst und den Rest von Google Cloud.

Nach dem Verschieben von Arbeitslasten haben Sie sofort Zugriff auf Google Cloud-Dienste wie BigQuery, Cloud Operations, Cloud Storage, Anthos und Cloud AI. 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.

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 Layer-2-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.

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

Für jedes Ihrer mit VMware Engine verbundenen VPC-Netzwerke gibt es ein Dienstersteller-VPC-Netzwerk, das erstellt wird, wenn Sie eine Verbindung für den Zugriff auf private Dienste in Google Cloud erstellen. Ihr Google Cloud-Projekt enthält ein freigegebenes VPC-Netzwerk, über das eine Verbindung zu anderen Google Cloud-Diensten wie Memorystore und Cloud SQL hergestellt werden kann. Beispielsweise können Sie Ihre lokalen MySQL- oder PostgreSQL-VMs per Lift-and-Shift nach VMware Engine verschieben und dann mit dem in Google Cloud eingebetteten Database Migration Service nach Cloud SQL migrieren. Ihre VMware Engine-Arbeitslasten können dabei weiterhin auf diese Datenbanken zugreifen.

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, wenn Sie diese Option auswählen.

Wichtig: Bevor Sie eine private Cloud bereitstellen, sollten Sie die unter Netzwerkanforderungen beschriebenen Anforderungen hinsichtlich Bereitschaft und Onboarding prüfen.

Netzwerkfunktionen

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

• Multi-VPC-Konnektivität: Mit VMware Engine können Sie dieselbe private Cloud mit mehreren VPC-Netzwerken verbinden (insgesamt bis zu drei oder zwei bei Verwendung des regionalen Internetdienstes). Diese VPC-Netzwerke können Nutzer-VPC-Netzwerke oder Managed Partner Services (MPS) sein.
• 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.
• Regionale und globale Routingfunktionen: Sie können festlegen, ob die freigegebenen VPC-Netzwerke des Diensterstellers, die Ihre privaten Clouds verbinden, Traffic nur innerhalb einer Region oder global weiterleiten können.
• 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.
• 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-Funktionen
  • DNS für den Zugriff auf Management Appliances: Mit der globalen Adressauflösung von VMware Engine-Management-Appliances (wie vCenter und NSX Manager) mit Cloud DNS können Sie ohne Nutzereingriff auf die Appliances zugreifen.
  • 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, den DNS-Server in VMware Engine oder lokal erstellen oder Cloud DNS oder Compute Engine 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.
• Site-to-Site-Layer-2-VPN und Layer-3-VPN: Diese Dienste sind in NSX direkt mit Layer-2-VPN 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 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. Privat verwendete öffentliche IP-Adressen (Privately Used Public IP, PUPI) werden ebenfalls unterstützt.

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 Tabellen werden die Adressbereiche und die zugehörigen Dienste beschrieben, die diese Bereiche verwenden.

Wichtig: Es ist möglich, dass sich die Subnetze in VMware Engine überschneiden und NAT-Einträge in den NSX-Routern erstellt werden, um eine Verbindung zur restlichen Welt herzustellen. Diese Konfiguration ermöglicht einige Anwendungsfälle, in denen dieselben CIDR-Bereiche in zwei oder mehr Umgebungen benötigt werden, z. B. beim Simulieren von Produktions- und Nicht-Produktionsumgebungen in derselben privaten Cloud. Konfigurieren Sie Routing und NAT sorgfältig, um Konflikte zu vermeiden, die sich aus der Implementierung überlappender IP-Adressbereiche ableiten.

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

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

Hinweis: Sie können den CIDR-Bereich später nicht mehr ändern. Legen Sie ihn also bei der Bereitstellung der privaten Cloud richtig fest.

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.

Example:

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-Subnetzsubnetz, ein /28 NSX-T Edge-Transport-Subnetz, ein /28 NSX-T Edge uplink1 und ein /28 NSX-T Edge uplink2.

Hinweis: Der einzige erforderliche CIDR-Bereich zum Erstellen einer privaten Cloudinfrastruktur ist der vSphere-/vSAN-CIDR-Bereich. Zusätzliche CIDR-Bereiche sind nur erforderlich, wenn Sie zusätzliche Features wie HCX für die VM-Migration oder Edge Services für den öffentlichen Internetzugang hinzufügen möchten. Beachten Sie, dass CIDR-Bereiche für Arbeitslast-Subnetze direkt in NSX konfiguriert sind.

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
CIDR-Bereich für Edge-Dienste	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 Ihre Arbeitslasten, die in VMware Engine oder in Ihren Google VPC-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 Google 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 verfügbare Dienste über den Zugriff auf private Dienste zu erreichen.

• 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, müssen der zugewiesene IP-Adressbereich 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 Überschneidungen von IP-Adressen zu verhindern:

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 importieren und exportieren zu können. 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 for Redis, Memorystore for Memcached, AI Platform Training und private GKE-Cluster. Wenn Sie diese Dienste nutzen möchten, können Sie den CIDR-Bereich auswählen, den Sie zum Herstellen der privaten Dienstverbindung mit VMware verwendet 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-Netzwerk-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:

• Remote-Nutzerverbindung:
  • VPN-Gateway (Point-to-Site-VPN)
• Lokale Verbindung:
  • Cloud VPN
    • Klassisch (wird verworfen, es wird vom klassischen VPN zu HA VPN gewechselt)
    • HA
  • Cloud Interconnect
    • Partner Interconnect
    • Dedicated Interconnect
  • NSX-T IPSec-VPN
  • NSX-T Layer 2 VPN
  • HCX-Layer-2-VPN

Wichtig: Alle VPN-Optionen in VMware Engine (mit NSX oder HCX) verursachen einen zusätzlichen Datenkapselungsaufwand. Als Best Practice sollten Sie dafür sorgen, dass Ihre VPC-Netzwerke und Interconnect-Verbindungen für 1.500-Byte-MTUs konfiguriert sind, um den Fragmentierungsbedarf zu minimieren.

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.

Hinweis: Google hat einige klassisches VPN-Funktionen eingestellt. Weitere Informationen finden Sie auf der Seite Teilweise Einstellung des klassischen VPN.

Optionen für die VPN-Konnektivität sind NSX-T IPse-VPN, NSX-T-Layer-2-VPN und HCX-Layer-2-VPN – beispielsweise zum Konfigurieren einer Layer-2-Erweiterung. 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 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, beachten Sie, 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 Advertising 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 Ihrem VPC-Netzwerk
• 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.

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.

Wichtig: Der öffentliche IP-Adressdienst von VMware Engine unterstützt keine Verwendung Ihrer eigenen IP-Adresse (BYOIP). Öffentliche IP-Adressen werden in jeder Region aus einem von Google verwalteten Bereich zugewiesen. Wenn BYOIP erforderlich ist, prüfen Sie die Verwendung des Nutzer-VPC-Netzwerks als Ingress-Punkt.

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 Ihr VPC-Netzwerk

Mithilfe von Cloud Load Balancing können Sie eingehenden Traffic zu VMware Engine über Ihr VPC-Netzwerk 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 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 über Ihr lokales Netzwerk

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.

Wichtig: HCX-Layer-2-Erweiterungen über Cloud VPN werden nicht offiziell unterstützt.

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 Ihr VPC-Netzwerk
• 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.

Ö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.

Hinweis: Derzeit unterstützt Google Cloud kein ICMP für den internen Load-Balancer. Verwenden Sie zum Testen der Konnektivität tcp ping.

Ö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 über Ihr VPC-Netzwerk 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 in Ihrem VPC-Netzwerk sichtbar sein und wird anschließend automatisch an VMware Engine weitergegeben. Voraussetzung ist, VPC Service Controls für die VPC-Peering-Verbindung zwischen Ihrem VPC-Netzwerk und VMware Engine 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 in Cloud Marketplace) gepaart ist. Sie können dann Source-NAT auf der Instanz durchführen, um ausgehenden Traffic von Ihrem VPC-Netzwerk in das öffentliche Internet ermöglichen. 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 Dokumentation zu VPC Service Controls.

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 Cloud-Umgebung ist so konzipiert, dass Single Points of Failure beseitigt werden.

Das folgende Diagramm zeigt zwei Netzwerkpfade für die Kommunikation zwischen privaten Clouds in VMware Engine. Der Pfad hängt davon ab, ob sich die privaten Clouds in derselben Region oder in verschiedenen Regionen befinden:

1. 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.
2. 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. Dies ist der Fall, wenn der Routingmodus auf "global" festgelegt ist.

Dienstübersicht: Private Cloud zu VPC

In diesem Abschnitt wird die Konnektivität zwischen Ihrem VPC-Netzwerk und der privaten Cloud beschrieben. Das 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. Achten Sie darauf, 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.

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 beim Verbinden einer privaten Cloud mit dem freigegebenen VPC-Netzwerk die Arbeitslasten im Service-Projekt ausgeführt werden und den IP-Adressraum im freigegebenen VPC-Netzwerk des Hostprojekts 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 einer lokalen Umgebung haben Sie ein VPC-Netzwerk in Ihrem Projekt und Ihrer Organisation. Die Verbindung erfolgt zwischen der privaten Cloud und dem lokalen Rechenzentrum.

Wie bereits erwähnt, müssen Sie beim Einrichten von VMware Engine ein Subnetz (und idealerweise auch die Subnetze für VMware Engine, um zukünftige Konflikte zu vermeiden) für die Verbindung für privaten Zugriff auf Dienste zuweisen. Während der Zuweisung des Subnetzes erstellen Sie ein Dienstersteller-VPC-Netzwerk, um eine Verbindung zur VMware Engine-Region herzustellen, in der sich die private Cloud befindet.

Nachdem die VPC-Peering-Verbindung erstellt und bereitgestellt wurde, ist das VPC-Netzwerk des Diensterstellers mit Ihrem VPC-Netzwerk verbunden. Dadurch können alle Subnetze und IP-Adressen innerhalb Ihres VPC-Netzwerks von der privaten Cloud aus erreichbar sein. 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.

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. Der private Google-Zugriff unterstützt App Engine, Memorystore oder Filestore nicht. Weitere Informationen zu privaten Zugriffsoptionen finden Sie unter Private Zugriffsoptionen für Dienste.

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.

Das folgende Diagramm zeigt zwei Netzwerkpfade für die Kommunikation mit Google APIs und Diensten. Die Konfiguration des privaten Google-Zugriffs hängt von dem für VMware Engine aktivierten Internetzugriff ab:

1. Wenn Internetzugriff über die VMware Engine bereitgestellt und für die Region aktiviert wird, verwenden der private Google-Zugriff und der Internetzugriff das Internet-Gateway.
2. Wenn Sie Internetzugang (durch Advertising einer 0.0.0.0/0-Route) vom lokalen Netzwerk oder über Ihr VPC-Netzwerk bereitstellen, verwendet die Kommunikation das Internet-Gateway des VPC-Netzwerks des Diensterstellers. Der Zugriff über den VMware Engine-Internetdienst wird ignoriert.

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 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 Ihr VPC-Netzwerk weitergeleitet werden, um lokale Netzwerke über VPN oder Interconnect oder über Ihr VPC-Netzwerk zu erreichen.

Deaktivieren Sie für den gesamten Traffic den Internetzugriff und die öffentlichen IP-Dienste für die VMware-Region und fügen Sie lokale die Standardroute 0.0.0.0/0 ein.

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 in Ihrem VPC-Netzwerk sichtbar ist und in das Mandanten-VPC-Netzwerk exportiert wird.

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

Der Zugriff auf Google APIs verwendet die eingeschränkte virtuelle IP-Adresse. Daher muss DNS entsprechend mit den erforderlichen CNAME- und A-Einträgen konfiguriert werden. Der Zugriff auf Google APIs erfolgt über die Google-Organisation, nicht über das VPC-Netzwerk.

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 verwendet VMware Engine Multi-VPC-Verbindungen. Mit dieser Funktion können Sie nicht nur Verbindungen zu zusätzlichen Nutzer-VPC-Netzwerken herstellen, sondern auch zum MPS von Google. Das folgende Diagramm ist eine vereinfachte Version der Konnektivität zwischen einer privaten Cloud und MPS sowie zusätzlichen VPC-Netzwerken von Nutzern.

Zusätzliche Ressourcen: VMware

Weitere Informationen zum VMware-Stack finden Sie unter Versionen von VMware-Komponenten und im Designleitfaden zu NSX 3.0.