Überprüfen Sie die Systemanforderungen zum Konfigurieren von vSphere IaaS control plane auf einem vSphere-Cluster mithilfe des NSX-Netzwerk-Stacks. Wenn Sie einen vSphere-Cluster als Supervisor aktivieren, wird automatisch eine vSphere-Zone für den Supervisor erstellt.

NSX-Bereitstellungsoptionen

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

Mindestberechnungsanforderungen für den 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
Dienst-Engine-VMs Pro Supervisor werden mindestens zwei Dienst-Engine-VMs bereitgestellt 1 2 GB Nicht verfügbar
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.

Angeben der Systemkapazität des Controllers

Sie können die Systemkapazität des Controllers während der Bereitstellung angeben. Die Systemkapazität basiert auf Zuteilungen von Systemressourcen wie CPU, RAM und Festplatte. Die Menge an Ressourcen, die Sie zuteilen, wirkt sich auf die Leistung des Controllers aus.

Bereitstellungstyp Knotenanzahl Empfohlene Zuteilungen – CPU Empfohlene Zuteilungen – Arbeitsspeicher Empfohlene Zuteilungen – Festplatte
Demo/Kundenbewertung 1 6 24 GB 128 GB
Bei Demobereitstellungen reicht ein einzelner Controller aus und wird für alle Aktivitäten und Workflows der Steuerungsebene sowie für Analysen verwendet.

In einer Produktionsbereitstellung wird ein Cluster mit drei Knoten empfohlen.

Weitere Informationen finden Sie unter NSX Advanced Load Balancer Controller-Größenanpassung.

Mindestberechnungsanforderungen für den Arbeitslastdomänencluster

System Mindestbereitstellungsgröße CPU Arbeitsspeicher Speicher
vSphere-Cluster
  • 1 vSphere-Cluster
  • Aktivierung von vSphere DRS und HA auf dem vSphere-Cluster. vSphere DRS muss im vollautomatisierten Modus ausgeführt werden.
 Nicht anwendbar Nicht anwendbar Nicht anwendbar
ESXi-Hosts 8
  • Ohne vSAN: 3 ESXi-Hosts mit 1 statischen IP-Adresse pro Host.
  • Mit vSAN: 4 ESXi-Hosts mit mindestens zwei 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
Physische Netzwerk-MTU 1700 Die MTU-Größe muss für jede vSphere Distributed Switch-Portgruppe mindestens 1700 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
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 Erforderliche Konfiguration
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.
Tabelle 6. Netzwerkanforderungen für den Lastausgleichsdienst
NTP- und DNS-Server 1 Die DNS-Server-IP ist erforderlich, damit der NSX Advanced Load Balancer-Controller die vCenter Server- und ESXi-Hostnamen korrekt auflösen kann. NTP ist optional, da öffentliche NTP-Server standardmäßig verwendet werden.
Datennetzwerksubnetz 1 Die Datenschnittstelle der NSX Advanced Load Balancer-Dienst-Engines, auch als Dienst-Engines bezeichnet, stellt eine Verbindung zu diesem Netzwerk her. Konfigurieren Sie einen Pool von IP-Adressen für die Dienst-Engines. Die virtuellen IPs (VIPs) des Lastausgleichsdiensts werden von diesem Netzwerk zugewiesen.
NSX Advanced Load Balancer-Controller-IPs 1 oder 4 Wenn Sie den NSX Advanced Load Balancer-Controller als einzelnen Knoten bereitstellen, ist eine statische IP-Adresse für seine Verwaltungsschnittstelle erforderlich.

Für einen Cluster mit 3 Knoten sind 4 IP-Adressen erforderlich. Eine für jede NSX Advanced Load Balancer-Controller-VM und eine für die Cluster-VIP. Diese IPs müssen aus dem Subnetz des Verwaltungsnetzwerks stammen.
VIP-IPAM-Bereich -

Ein privater CIDR-Bereich für die Zuweisung von IP-Adressen zu Kubernetes-Diensten. Die IPs müssen aus dem Subnetz des Datennetzwerks stammen. Sie müssen für jeden Supervisor-Cluster einen eindeutigen CIDR-Bereich für Kubernetes-Dienste angeben.

Ports und Protokolle

Diese Tabelle enthält die Protokolle und Ports, die für die Verwaltung der IP-Konnektivität zwischen dem NSX Advanced Load Balancer, vCenter und anderen vSphere IaaS control plane-Komponenten erforderlich sind.

Quelle Ziel Protokoll und Ports
NSX Advanced Load Balancer-Controller NSX Advanced Load Balancer-Controller (im Cluster)

TCP 22 (SSH)

TCP 443 (HTTPS)

TCP 8443 (HTTPS)
Dienst-Engine Dienst-Engine in HA

TCP 9001 für VMware, LSC und NSX-T Cloud
Dienst-Engine NSX Advanced Load Balancer-Controller

TCP 22 (SSH)

TCP 8443 (HTTPS)

UDP 123 (NTP)
AVI-Controller vCenter Server, ESXi, NSX-T Manager TCP 443 (HTTPS)
Supervisor-Steuerungsebenenknoten (AKO) NSX Advanced Load Balancer-Controller TCP 443 (HTTPS)

Weitere Informationen zu Ports und Protokollen für den NSX Advanced Load Balancer finden Sie unter https://ports.esp.vmware.com/home/NSX-Advanced-Load-Balancer.