Netzwerkanforderungen

Google Cloud VMware Engine bietet eine private Cloud-Umgebung, auf die Nutzer und Anwendungen aus lokalen Umgebungen, von Unternehmen verwaltete Geräte undGoogle 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.

Hinweis

  • Melden Sie sich in Ihrem Google Cloud -Konto an. Wenn Sie mit Google Cloudnoch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit unserer Produkte in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.
  • In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  • If you're using an existing project for this guide, verify that you have the permissions required to complete this guide. If you created a new project, then you already have the required permissions.

  • Verify that billing is enabled for your Google Cloud project.

  • Enable the Cloud DNS and VMware Engine APIs.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the APIs

  • In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  • If you're using an existing project for this guide, verify that you have the permissions required to complete this guide. If you created a new project, then you already have the required permissions.

  • Verify that billing is enabled for your Google Cloud project.

  • Enable the Cloud DNS and VMware Engine APIs.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the APIs

  • Erforderliche Rollen

    Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle VMware Engine Viewer (roles/vmwareengine.vmwareengineViewer) für das Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Ausführen dieser Kurzanleitung benötigen. Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.

    Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.

    VMware Engine mit einer privaten Cloud verbinden

    Eine Übersicht über private Cloud-Netzwerke finden Sie unter Private Cloud-Netzwerke für VMware Engine.

    Die Verbindung von Ihrem VPC-Netzwerk zu einem VMware Engine-Standardnetzwerk verwendet VPC-Netzwerk-Peering.

    Globale Adressauflösung mit Cloud DNS

    Wenn Sie globale Adressauflösung mithilfe von Cloud DNS wünschen, müssen Sie die Cloud DNS-Einrichtung abschließen, bevor Sie Ihre private Cloud erstellen.

    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 CIDR-Bereichspräfix muss zwischen /24 und /20 liegen.

    Jeder Knoten in der privaten Cloud hat fünf VMkernel-Ports für die Verwendung durch das VMware-System: ESXi-Verwaltung, vMotion, vSAN, NSX-T und HCXIX. Jeder dieser VMkernel-Ports belegt eine IP-Adresse aus dem CIDR-Bereich der vSphere-/vSAN-Subnetze.

    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
    /24 10
    /23 20
    /22 40
    /21 90
    /20 200

    Berücksichtigen Sie bei der Auswahl des CIDR-Bereichspräfix das Knotenlimit für Ressourcen in einer privaten Cloud. Beispielsweise unterstützen CIDR-Bereichpräfixe von /24 und /23 nicht die maximale Anzahl an Knoten, die für eine private Cloud verfügbar sind. Alternativ unterstützen CIDR-Bereichpräfixe von /20 mehr als die aktuelle maximale Anzahl an Knoten, die für eine private Cloud verfügbar sind.

    Beispiel für die Aufteilung des CIDR-Bereichs des Verwaltungsnetzwerks

    Der von Ihnen angegebene CIDR-Bereich der vSphere-/vSAN-Subnetze wird in mehrere Subnetze unterteilt. Die folgende Tabelle zeigt ein Beispiel der Aufschlüsselung für zulässige Präfixe mit 10.0.0.0 als CIDR-Bereich.

    Funktion Subnetzmaske/-präfix
    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-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-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-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-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-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 Edge-Skalierung

    Angegebenes CIDR-Präfix für vSphere/vSAN-Subnetze Maximale Anzahl von HCX-Remotestandorten Maximale Anzahl von HCX Network Extension-Appliances Maximale Anzahl von NSX Edge-VMs
    /24 2 1 2
    /23 4 2 4
    /22 14 8 8
    /21 25 32 8
    /20 25 64 8

    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

    Weitere Informationen zum Einrichten des privaten Dienstzugriffs finden Sie unter Privaten Dienstzugriff einrichten.

    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 Auf regionaler Ebene erforderlich, wo optionale Edge-Dienste wie Internetzugriff und öffentliche IP-Adressen aktiviert sind. /26

    Auf private und 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 angekündigt, um den direkten Zugriff auf Google-Dienste zu unterstützen. Der private CIDR-Block 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 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 Privates Cloud-Verwaltungsnetzwerk Erforderlich für den Zugriff auf vCenter und NSX 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.