Informieren Sie sich über die Voraussetzungen für das Aktivieren eines Supervisors auf drei vSphere-Clustern, die vSphere-Zonen zugeordnet sind, unter Verwendung des NSX-Netzwerk-Stacks.

Neben diesen Anforderungen finden Sie im Leitfaden zum NSX-Referenz-Design weitere Informationen zu den Best Practices für die Bereitstellung von NSX.

Platzierung von vSphere-Zonen über physische Sites hinweg

Sie können vSphere-Zonen auf verschiedene physische Sites verteilen, solange die Latenz zwischen den Sites 100 ms nicht überschreitet. Sie können beispielsweise die vSphere-Zonen auf zwei physische Sites verteilen: eine vSphere-Zone auf der ersten Site und zwei vSphere-Zonen auf der zweiten Site.

Mindestberechnungsanforderungen für ein Verwaltungs- und Edge-Cluster

System Mindestbereitstellungsgröße CPU Arbeitsspeicher Speicher
vCenter Server 8 Klein 2 21 GB 290 GB
ESXi-Hosts 8 2 ESXi-Hosts 8 64 GB pro Host Nicht anwendbar
NSX Manager Mittel 6 24 GB 300 GB
NSX Edge 1 Groß 8 32 GB 200 GB
NSX Edge 2 Groß 8 32 GB 200 GB
Hinweis: Stellen Sie sicher, dass alle ESXi-Hosts, die an dem vSphere-Cluster teilnehmen, auf dem Sie vSphere IaaS control plane konfigurieren möchten, als NSX-Transportknoten vorbereitet sind. Weitere Informationen finden Sie unter https://kb.vmware.com/s/article/95820 und Vorbereiten von ESXi-Hosts als Transportknoten in der Dokumentation zu NSX.

Mindestberechnungsanforderungen für Arbeitslastdomänencluster

System Mindestbereitstellungsgröße CPU Arbeitsspeicher Speicher
vSphere-Cluster
  • 3 vSphere-Cluster
  • Aktivierung von vSphere DRS und HA auf jedem vSphere-Cluster. vSphere DRS muss im vollautomatisierten Modus ausgeführt werden.
  • Unabhängige Speicher- und Netzwerkkonfiguration für jeden vSphere-Cluster.
 Nicht anwendbar Nicht anwendbar Nicht anwendbar
ESXi-Hosts 8
Bei jedem vSphere-Cluster:
  • Ohne vSAN: 3 ESXi-Hosts mit 1 statischen IP-Adresse pro Host.
  • Mit vSAN: 4 ESXi-Hosts pro Cluster mit mindestens 2 physischen Netzwerkkarten.
Hinweis: Achten Sie darauf, dass die Namen der Hosts, die den Clustern beitreten, in Kleinbuchstaben geschrieben sind. Andernfalls tritt bei der Aktivierung des Supervisors eventuell ein Fehler auf.
8 64 GB pro Host Nicht anwendbar
Kubernetes-Steuerungsebenen-VMs 3 4 16 GB 16 GB

Netzwerkanforderungen

Hinweis: Sie können weder IPv6-Cluster mit einem vSphere 8- Supervisor erstellen noch IPv6-Cluster mit Tanzu Mission Control registrieren.

Überprüfen Sie in der VMware-Produkt-Interoperabilitätstabelle, welche NSX-Versionen unterstützt werden.

Tabelle 1. Anforderungen an das physische Netzwerk
Komponente Mindestanzahl Erforderliche Konfiguration
Layer-2-Gerät 1 Das Verwaltungsnetzwerk, das den Supervisor-Datenverkehr verarbeitet, muss sich auf demselben Layer-2-Gerät befinden. Pro Host muss mindestens eine physische Netzwerkkarte, die den Verwaltungsdatenverkehr verarbeitet, mit demselben Layer-2-Gerät verbunden sein.
Physische Netzwerk-MTU 1500 Die MTU-Größe muss für jede vSphere Distributed Switch-Portgruppe mindestens 1500 betragen.
Physische Netzwerkkarte Mindestens 2 physische Netzwerkkarten pro Host, wenn vSAN verwendet wird Um Antrea-CNI zu verwenden und eine optimale NSX-Leistung zu erzielen, muss jede physische Netzwerkkarte auf jedem teilnehmenden ESXi-Host die GENEVE-Kapselung unterstützen und diese aktivieren.
Tabelle 2. Allgemeine Netzwerkanforderungen
Komponente Mindestanzahl Erforderliche Konfiguration
Latenz 100 ms Die maximal empfohlene Latenz zwischen jedem Cluster, der Teil einer vSphere-Zone ist, die in einem Supervisor verbunden ist.
NTP- und DNS-Server 1 Ein DNS-Server und ein NTP-Server, die in Verbindung mit vCenter Server verwendet werden können.
Hinweis: Konfigurieren Sie NTP auf allen ESXi-Hosts und in vCenter Server.
DHCP-Server 1 Optional. Konfigurieren Sie einen DHCP-Server, um automatisch IP-Adressen für die Verwaltungs- und Arbeitslastnetzwerke sowie Floating-IP-Adressen abzurufen. Der DHCP-Server muss Clientbezeichner unterstützen und kompatible DNS-Server, DNS-Suchdomänen und einen NTP-Server bereitstellen.

Für das Verwaltungsnetzwerk werden alle IP-Adressen, wie IP-Adressen von Steuerungsebenen-VMs, eine Floating-IP-Adresse, DNS-Server, DNS, Suchdomänen und NTP-Server, automatisch vom DHCP-Server erfasst.

Die DHCP-Konfiguration wird vom Supervisor verwendet. Lastausgleichsdienste benötigen möglicherweise statische IP-Adressen für die Verwaltung. DHCP-Bereiche sollten sich nicht mit diesen statischen IPs überlappen. DHCP wird nicht für virtuelle IPs verwendet. (VIPs)
Image-Registrierung 1 Zugriff auf eine Registrierung für den Dienst.
Tabelle 3. Anforderungen an das Verwaltungsnetzwerk
Komponente Mindestanzahl Erforderliche Konfiguration
Statische IPs für Kubernetes Control Plane-VMs Block mit 5 Ein Block mit 5 aufeinanderfolgenden statischen IP-Adressen, die vom Verwaltungsnetzwerk den Kubernetes-Steuerungsebenen-VMs im Supervisor zugewiesen werden.
Verwaltungsdatenverkehr-Netzwerk 1 Ein Verwaltungsnetzwerk, das zu den ESXi-Hosts, vCenter Server, dem Supervisor und einem Lastausgleichsdienst geroutet werden kann.
Verwaltungsnetzwerk-Subnetz 1
Das Subnetz, das für den Verwaltungsdatenverkehr zwischen ESXi-Hosts und vCenter Server, NSX-Appliances und der Kubernetes-Steuerungsebene verwendet wird. Das Subnetz muss folgende Größe haben:
  • 1 IP-Adresse pro VMkernel-Adapter eines Hosts.
  • 1 IP-Adresse für die vCenter Server-Appliance.
  • 1 oder 4 IP-Adressen für NSX Manager. 4 IP-Adressen bei NSX Manager-Clustering von 3 Knoten und 1 virtuellen IP (VIP).
  • 5 IP-Adressen für die Kubernetes-Steuerungsebene. 1 für jeden der 3 Knoten, 1 für virtuelle IP, 1 für fortlaufendes Cluster-Upgrade.
Hinweis: Das Verwaltungsnetzwerk und das Arbeitslastnetzwerk müssen sich in unterschiedlichen Subnetzen befinden. Das Zuweisen desselben Subnetzes zu den Verwaltungs- und Arbeitslastnetzwerken wird nicht unterstützt und kann zu Systemfehlern und Problemen führen.
Verwaltungsnetzwerk-VLAN 1 VLAN-ID des Verwaltungsnetzwerk-Subnetzes.
Tabelle 4. Anforderungen an das Arbeitslastnetzwerk
Komponente Mindestanzahl Erforderliche Konfiguration
CIDR-Bereich für vSphere Pods /23 private IP-Adressen Ein privater-CIDR-Bereich, der IP-Adressen für vSphere-Pods bereitstellt. Diese Adressen werden auch für die Tanzu Kubernetes Grid-Clusterknoten verwendet.
Sie müssen einen eindeutigen vSphere Pod-CIDR-Bereich für jeden Cluster angeben.
Hinweis: Der CIDR-Bereich für vSphere Pods und der CIDR-Bereich für die Kubernetes-Dienstadressen dürfen sich nicht überlappen.
CIDR-Bereich für Kubernetes-Dienste /16 private IP-Adressen Ein privater CIDR-Bereich für die Zuweisung von IP-Adressen zu Kubernetes-Diensten. Sie müssen für jeden Supervisor einen eindeutigen CIDR-Bereich für Kubernetes-Dienste angeben.
Egress-CIDR-Bereich /27 statische IP-Adressen Eine CIDR-Anmerkung zur Ermittlung der Egress-IP für Kubernetes-Dienste. Für jeden Namespace im Supervisor wird nur eine Egress-IP-Adresse zugewiesen. Die Egress-IP ist die Adresse, die externe Entitäten für die Kommunikation mit den Diensten im Namespace verwenden. Die Anzahl der Egress-IP-Adressen beschränkt die Anzahl der Egress-Richtlinien, die der Supervisor haben kann.
Die Mindestanzahl ist ein CIDR von/27 oder mehr. Beispielsweise 10.174.4.96/27
Hinweis: Egress-IP-Adressen und Ingress-IP-Adressen dürfen sich nicht überlappen.
Ingress-CIDR /27 statische IP-Adressen Ein privater CIDR-Bereich, der für Ingress-IP-Adressen verwendet wird. Mit Ingress können Sie Datenverkehrsrichtlinien auf Anforderungen anwenden, die in den Supervisor von externen Netzwerken eingehen. Die Anzahl der Ingress-IP-Adressen beschränkt die Anzahl der Ingresses, die der Cluster haben kann.
Die Mindestanzahl ist ein CIDR von/27 oder mehr.
Hinweis: Egress-IP-Adressen und Ingress-IP-Adressen dürfen sich nicht überlappen.
Namespace-Netzwerkbereich 1 Ein oder mehrere IP-CIDRs zum Erstellen von Subnetzen/Segmenten sowie zum Zuweisen von IP-Adressen an Arbeitslasten.
Namespace-Subnetzpräfix 1 Das Subnetzpräfix, das die Größe des für Namespace-Segmente reservierten Subnetzes angibt. Der Standardwert ist „28“.
Tabelle 5. NSX-Anforderungen
Komponente Mindestanzahl V
VLANs 3 Diese VLAN-IPs sind die IP-Adressen für die Tunnel-Endpoints (TEP). Die TEPs des ESXi-Hosts und die Edge-TEPs müssen routingfähig sein.
VLAN-IP-Adressen sind für Folgendes erforderlich:
  • ESXi-Host-VTEP
  • Edge-VTEP mit statischer IP-Adresse
  • Tier-0-Gateway und Uplink für Transportknoten.
Hinweis: Der ESXi-Host-VTEP und der Edge-VTEP müssen eine MTU-Größe von mehr als 1600 aufweisen.

ESXi-Hosts und NSX-T-Edge-Knoten fungieren als Tunnel-Endpoints, und jedem Host sowie jedem Edge-Knoten wird eine TEP-IP zugewiesen.

Da die TEP-IPs für ESXi-Hosts einen Overlay-Tunnel mit TEP-IPs auf den Edge-Knoten erstellen, müssen die VLAN-IPs routingfähig sein.

Ein zusätzliches VLAN ist erforderlich, um Nord-Süd-Konnektivität zum Tier-0-Gateway zu bieten.

IP-Pools können über Cluster hinweg gemeinsam genutzt werden. Der Host-Overlay-IP-Pool/VLAN darf jedoch nicht mit einem Edge-Overlay-IP-Pool/VLAN gemeinsam genutzt werden.

Hinweis: Wenn Host-TEP und Edge-TEP verschiedene physische Netzwerkkarten verwenden, können sie dasselbe VLAN verwenden.
Tier-0-Uplink-IP /24 private IP-Adressen Das IP-Subnetz, das für den Tier-0-Uplink verwendet wird. Für die IP-Adresse des Tier-0-Uplinks gelten folgende Anforderungen:
  • 1 IP, wenn Sie keine Edge-Redundanz verwenden.
  • 4 IPs, wenn Sie BGP und Edge-Redundanz verwenden – 2 IP-Adressen pro Edge.
  • 3 IPs, wenn Sie statische Routen und Edge-Redundanz verwenden.

Die IP, das Subnetz und das Gateway für die Edge-Verwaltung und die IP, das Subnetz und das Gateway für Uplink müssen eindeutig sein.