Voraussetzungen für zonalen Supervisor mit NSX und NSX Advanced Load Balancer

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.

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

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 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 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 Server 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)
NSX Advanced Load Balancer-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.