Netzwerkanforderungen
Google Cloud VMware Engine bietet eine private Cloud-Umgebung, auf die Nutzer und Anwendungen aus lokalen Umgebungen, vom Unternehmen verwaltete Geräte und Google Cloud-Dienste wie Virtual Private Cloud (VPC) zugreifen können. Zum Herstellen einer Verbindung zwischen privaten VMware Engine-Clouds und anderen Netzwerken verwenden Sie Netzwerkdienste wie Cloud VPN und Cloud Interconnect.
Einige Netzwerkdienste erfordern zur Aktivierung der Funktion vom Nutzer angegebene Adressbereiche. Damit Sie Ihre Bereitstellung besser planen können, werden auf dieser Seite die Netzwerkanforderungen und zugehörigen Features aufgeführt.
VMware Engine mit einer privaten Cloud verbinden
Die Verbindung von Ihrem VPC-Netzwerk zu einer VMware Engine unterscheidet sich je nachdem, ob Sie Standard- oder Legacy-Netzwerke verwenden.
VMware Engine-Standardnetzwerke
Für die Verbindung von Ihrem VPC-Netzwerk zu einem VMware Engine-Standardnetzwerk wird VPC-Netzwerk-Peering verwendet.
Legacy-VMware Engine-Netzwerke
Die Verbindung von Ihrem VPC-Netzwerk zu einem Legacy-VMware Engine-Netzwerk verwendet den Zugriff auf private Dienste. Für den Zugriff auf Ihre virtuellen Arbeitslastmaschinen von einem lokalen Netzwerk oder von Ihrem VPC-Netzwerk aus richten Sie den Zugriff auf private Dienste von Ihrem VPC-Netzwerk auf Ihr VMware Engine-Netzwerk ein.
Globale Adressauflösung mit Cloud DNS
Wenn Sie die globale Adressauflösung mit Cloud DNS verwenden möchten, aktivieren Sie die Cloud DNS API. Sie müssen die Cloud DNS-Einrichtung abschließen, bevor Sie Ihre private Cloud erstellen können.
CIDR-Anforderungen und -Einschränkungen
VMware Engine verwendet festgelegte Adressbereiche für Dienste wie Hosting-Management-Appliances und das Bereitstellen von HCX-Netzwerken. Einige Adressbereiche sind obligatorisch, andere werden je nach den bereitzustellenden Diensten erforderlich.
Sie müssen Adressbereiche so reservieren, dass sie sich nicht mit Ihren lokalen Subnetzen, VPC-Netzwerk-Subnetzen oder geplanten Arbeitslast-Subnetzen überschneiden.
Außerdem dürfen sich die Arbeitslast-VMs und der CIDR-Bereich des vSphere-/vSAN-Subnetzes nicht mit IP-Adressen in den folgenden Bereichen überschneiden:
- 127.0.0.0/8
- 224.0.0.0/4
- 0.0.0.0/8
- 169.254.0.0/16
- 198.18.0.0/15
- 240.0.0.0/4
CIDR-Bereich der vSphere/vSAN-Subnetze
VMware Engine stellt Verwaltungskomponenten einer privaten Cloud in dem CIDR-Bereich der vSphere/vSAN-Subnetze bereit, den Sie während der Erstellung der privaten Cloud bereitstellen. IP-Adressen in diesem Bereich sind für private Cloud-Infrastrukturen reserviert und können nicht für Arbeitslast-VMs verwendet werden. Das Präfix des CIDR-Bereichs muss zwischen /24 und /20 liegen.
Versionen der CIDR-Bereichsaufteilung von Subnetzen
Private Clouds, die nach November 2022 erstellt werden, entsprechen den Subnetzzuweisungen des IP-Adresslayouts (IP-Plan) der Version 2.0. Fast alle privaten Clouds, die vor November 2022 erstellt wurden, entsprechen den Subnetzzuweisungen des IP Plan Version 1.0.
Führen Sie die folgenden Schritte aus, um herauszufinden, welche Version Ihre private Cloud unterstützt:
- Rufen Sie die Google Cloud Console auf.
- Klicken Sie im Hauptmenü auf Private Clouds.
- Klicken Sie auf die private Cloud, die Sie prüfen möchten.
- Suchen Sie nach Version des IP-Tarifs, um herauszufinden, welche Version diese private Cloud verwendet.
Die Versionsnummer wird unter Version des IP-Tarifs angezeigt.
CIDR-Bereichsgröße von vSphere/vSAN-Subnetzen
Die Größe des CIDR-Bereichs von vSphere/vSAN-Subnetzen wirkt sich auf die maximale Größe Ihrer privaten Cloud aus. Die folgende Tabelle zeigt die maximale Anzahl an Knoten, die je nach Größe des CIDR-Bereichs der vSphere-/vSAN-Subnetze verfügbar sind.
| Angegebenes CIDR-Präfix für vSphere/vSAN-Subnetze | Maximale Anzahl von Knoten (IP Plan Version 1.0) | Maximale Anzahl von Knoten (IP Plan Version 2.0) |
|---|---|---|
| /24 | 26 | 10 |
| /23 | 58 | 20 |
| /22 | 118 | 40 |
| /21 | 220 | 90 |
| /20 | – | 200 |
Berücksichtigen Sie bei der Auswahl des CIDR-Bereichspräfix das Knotenlimit für Ressourcen in einer privaten Cloud. Die CIDR-Bereichspräfixe /24 und /23 unterstützen beispielsweise nicht die maximale Anzahl von Knoten, die für eine private Cloud verfügbar sind. Alternativ unterstützen die CIDR-Bereichspräfixe von /20 mehr als die aktuelle maximale Anzahl von Knoten, die für eine private Cloud verfügbar sind.
Beispiel für die Aufteilung des CIDR-Bereichs eines Verwaltungsnetzwerks
Der von Ihnen angegebene CIDR-Bereich der vSphere-/vSAN-Subnetze wird in mehrere Subnetze unterteilt. Die folgenden Tabellen enthalten Beispiele für die Aufschlüsselung zulässiger Präfixe. Die erste Gruppe von Beispielen verwendet 192.168.0.0 als CIDR-Bereich für die IP-Plan-Version 1.0 und die zweite 10.0.0.0 für die IP-Plan-Version 2.0.
| Funktion | Subnetzmaske/-präfix (IP-Tarifversion 1.0) | |||
|---|---|---|---|---|
| CIDR-Bereich der 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 |
| Funktion | Subnetzmaske/-präfix (IP-Tarifversion 2.0) | |||||
|---|---|---|---|---|---|---|
| CIDR-Bereich der vSphere/vSAN-Subnetze | 10.0.0.0/20 | 10.0.0.0/21 | 10.0.0.0/22 | 10.0.0.0/23 | 10.0.0.0/24 | |
| Systemverwaltung | 10.0.0.0/22 | 10.0.0.0/23 | 10.0.0.0/24 | 10.0.0.0/25 | 10.0.0.0/26 | |
| vMotion | 10.0.4.0/24 | 10.0.2.0/25 | 10.0.1.0/26 | 10.0.0.128/27 | 10.0.0.64/28 | |
| vSAN | 10.0.5.0/24 | 10.0.2.128/25 | 10.0.1.64/26 | 10.0.0.160/27 | 10.0.0.80/28 | |
| NSX-T-Transport | 10.0.6.0/23 | 10.0.3.0/24 | 10.0.1.128/25 | 10.0.0.192/26 | 10.0.0.128/27 | |
| HCX-Uplink | 10.0.11.128/25 | 10.0.6.0/26 | 10.0.3.32/27 | 10.0.1.144/28 | 10.0.0.216/29 | |
| NSX-T-Edge-Uplink1 | 10.0.8.0/28 | 10.0.4.0/28 | 10.0.2.0/28 | 10.0.1.0/28 | 10.0.0.160/29 | |
| NSX-T-Edge-Uplink2 | 10.0.8.16/28 | 10.0.4.16/28 | 10.0.2.16/28 | 10.0.1.16/28 | 10.0.0.168/29 | |
| NSX-T-Edge-Uplink3 | 10.0.8.32/28 | 10.0.4.32/28 | 10.0.2.32/28 | 10.0.1.32/28 | 10.0.0.176/29 | |
| NSX-T-Edge-Uplink4 | 10.0.8.48/28 | 10.0.4.48/28 | 10.0.2.48/28 | 10.0.1.48/28 | 10.0.0.184/29 | |
HCX- und NSX-T-Edge-Skalierung (nur IP-Plan-Version 2.0)
| Angegebenes CIDR-Präfix für vSphere/vSAN-Subnetze | Maximale Anzahl Remote-HCX-Websites | Maximale HCX Network Extension-Appliances | Maximale NSX-T-Edge-VMs |
|---|---|---|---|
| /24 | 2 | 1 | 2 |
| /23 | 4 | 2 | 4 |
| /22 | 14 | 8 | 8 |
| /21 | 25 | 32 | 8 |
| /20 | 25 | 64 | 8 |
CIDR-Bereich des HCX-Bereitstellungsnetzwerks (nur IP-Planversion 1.0)
In der IP-Planversion 1.0 war HCX nicht in den CIDR-Bereich der vSphere/vSAN-Subnetze eingebunden. Beim Erstellen einer privaten Cloud können Sie optional VMware Engine HCX in der privaten Cloud installieren lassen. Dazu geben Sie einen Netzwerk-CIDR-Bereich zur Verwendung durch HCX-Komponenten an. Das CIDR-Bereichspräfix war /26 oder /27.
Die VMware Engine hat das von Ihnen bereitgestellte Netzwerk in drei Subnetze unterteilt:
- HCX-Verwaltung: Wird für die Installation von HCX Manager verwendet.
- HCX vMotion: Wird für vMotion von VMs zwischen Ihrer lokalen Umgebung und der privaten Cloud von VMware Engine verwendet.
- HCX WANUplink: Wird zum Einrichten des Tunnels zwischen Ihrer lokalen Umgebung und der privaten Cloud in VMware Engine verwendet.
Beispiel für eine HCX-CIDR-Bereichsaufschlüsselung
Der von Ihnen angegebene CIDR-Bereich der HCX-Bereitstellung wird in mehrere Subnetze unterteilt. Die folgende Tabelle zeigt Beispiele der Aufschlüsselung für zulässige Präfixe. In den Beispielen wird 192.168.1.0 als CIDR-Bereich verwendet.
| Funktion | Subnetzmaske/-präfix | |||
|---|---|---|---|---|
| CIDR-Bereich des HCX-Bereitstellungsnetzwerks | 192.168.1.0/26 | 192.168.1.64/26 | 192.168.1.0/27 | 192.168.1.32/27 |
| HCX-Manager | 192.168.1.13 | 192.168.1.77 | 192.168.1.13 | 192.168.1.45 |
Zugriff auf private Dienste auf VMware Engine
In der folgenden Tabelle werden die Anforderungen an den Adressbereich für die private Verbindung zu Google Cloud-Diensten beschrieben.
| Name/Zweck | Beschreibung | CIDR-Präfix |
|---|---|---|
| Zugewiesener Adressbereich | Adressbereich, der für die private Verbindung zu Google Cloud-Diensten wie VMware Engine verwendet werden soll. | /24 oder größer |
Von VMware Engine bereitgestellte Edge-Netzwerkdienste
In der folgenden Tabelle wird die Adressbereichsanforderung für Edge-Netzwerkdienste beschrieben, die von VMware Engine bereitgestellt werden.
| Name/Zweck | Beschreibung | CIDR-Präfix |
|---|---|---|
| Edge-Dienst-CIDR | Erforderlich, wenn optionale Edge-Dienste wie Internetzugriff und öffentliche IP-Adressen für einzelne Regionen aktiviert sind. | /26 |
Auf private/eingeschränkte Google APIs zugreifen
Standardmäßig werden sowohl private 199.36.153.8/30- als auch eingeschränkte 199.36.153.4/30-CIDRs im VMware Engine-Netzwerk beworben, um den direkten Zugriff auf Google-Dienste zu unterstützen. Das private CIDR 199.36.153.8/30 kann bei der Konfiguration von VPC Service Controls zurückgezogen werden.
Anforderungen an Firewallports
Sie können eine Verbindung von Ihrem lokalen Netzwerk zur privaten Cloud über ein Site-to-Site-VPN oder eine Dedicated Interconnect-Verbindung herstellen. Über diese Verbindung können Sie auf VMware vCenter und alle in der privaten Cloud ausgeführten Arbeitslasten zugreifen.
Mit einer Firewall in Ihrem lokalen Netzwerk können Sie steuern, welche Ports bei der Verbindung geöffnet werden sollen. In diesem Abschnitt werden die allgemeinen Anforderungen beschrieben, die Anwendungsports erfüllen müssen. Informationen zu den Portanforderungen für andere Anwendungen finden Sie in der Dokumentation zur jeweiligen Anwendung.
Weitere Informationen zu Ports, die für VMware-Komponenten verwendet werden, finden Sie unter VMware-Ports und -Protokolle.
Für den Zugriff auf vCenter erforderliche Ports
Öffnen Sie in der lokalen Firewall folgende Ports, um Zugriff auf vCenter Server und NSX-T Manager in der privaten Cloud zu gewähren:
| Port | Quelle | Ziel | Zweck |
|---|---|---|---|
| 53 (UDP) | Lokale DNS-Server | DNS-Server der privaten Cloud | Erforderlich für die Weiterleitung des DNS-Lookups von gve.goog an die DNS-Server der privaten Cloud aus einem lokalen Netzwerk. |
| 53 (UDP) | DNS-Server der privaten Cloud | Lokale DNS-Server | Erforderlich für die Weiterleitung des DNS-Lookups lokaler Domainnamen von Private Cloud vCenter an die lokalen DNS-Server. |
| 80 (TCP) | Lokales Netzwerk | Verwaltungsnetzwerk der privaten Cloud | Erforderlich für die Weiterleitung der vCenter-URL von HTTP zu HTTPS. |
| 443 (TCP) | Lokales Netzwerk | Verwaltungsnetzwerk der privaten Cloud | Erforderlich für den Zugriff auf vCenter und NSX-T-Manager aus einem lokalen Netzwerk. |
| 8000 (TCP) | Lokales Netzwerk | Verwaltungsnetzwerk der privaten Cloud | Erforderlich für vMotion virtueller Maschinen (VMs) von der lokalen Umgebung zur privaten Cloud. |
| 8000 (TCP) | Privates Cloud-Verwaltungsnetzwerk | Lokales Netzwerk | Erforderlich für vMotion virtueller Maschinen (VMs) von der privaten Cloud in die lokale Umgebung. |
Für den Zugriff auf Arbeitslast-VMs häufig benötigte Ports
Für den Zugriff auf Arbeitslast-VMs, die in Ihrer privaten Cloud ausgeführt werden, müssen Sie Ports in Ihrer lokalen Firewall öffnen. In der folgenden Tabelle sind gängige Ports aufgeführt. Informationen zu anwendungsspezifischen Portanforderungen finden Sie in der jeweiligen Anwendungsdokumentation.
| Port | Quelle | Ziel | Zweck |
|---|---|---|---|
| 22 (TCP) | Lokales Netzwerk | Arbeitslastnetzwerk der privaten Cloud | Sicherer Shell-Zugriff Linux-VMs, die in der privaten Cloud ausgeführt werden. |
| 3389 (TCP) | Lokales Netzwerk | Arbeitslastnetzwerk der privaten Cloud | Remote Desktop-Verbindung mit Windows Server-VMs, die in der privaten Cloud ausgeführt werden. |
| 80 (TCP) | Lokales Netzwerk | Arbeitslastnetzwerk der privaten Cloud | Zugriff auf alle Webserver mit Bereitstellung auf VMs, die in der privaten Cloud ausgeführt werden. |
| 443 (TCP) | Lokales Netzwerk | Arbeitslastnetzwerk der privaten Cloud | Zugriff auf alle sicheren Webserver mit Bereitstellung auf VMs, die in der privaten Cloud ausgeführt werden. |
| 389 (TCP/UDP) | Privates Cloud-Arbeitslastnetzwerk | Lokales Active Directory-Netzwerk | Verbindung der Windows Server-Arbeitslast-VMs mit der lokalen Active Directory-Domain. |
| 53 (UDP) | Arbeitslastnetzwerk der privaten Cloud | Lokales Active Directory-Netzwerk | DNS-Dienstzugriff für Arbeitslast-VMs auf lokale DNS-Server. |
Ports, die für die Verwendung des lokalen Active Directory als Identitätsquelle erforderlich sind
Eine Liste der Ports, die zum Konfigurieren des lokalen Active Directory als Identitätsquelle im privaten Cloud vCenter erforderlich sind, finden Sie unter Authentifizierung mit Active Directory konfigurieren.