VMware NSX-T-Design
Einstellung des Vertriebs: Ab dem 31. Oktober 2025 stehen Neukunden keine neuen Bereitstellungen von „ VMware Solutions “-Angeboten mehr zur Verfügung. Bestehende Kunden können ihre aktiven „ VMware® “-Workloads weiterhin auf IBM Cloud® nutzen und erweitern. Weitere Informationen finden Sie unter Ende der Vermarktung für VMware auf IBM Cloud.
VMware NSX-T™ wurde für Anwendungs-Frameworks und Architekturen mit heterogenen Endpunkten und Technologie-Stacks entwickelt. Zusätzlich zur VMware vSphere® können diese Umgebungen andere Hypervisors, KVM, Container und Bare-Metal-Servers beinhalten. NSX-T ist darauf ausgelegt, eine softwaredefinierte Netzwerk- und Sicherheitsinfrastruktur über andere Plattformen als nur vSphere zu spannen. Obwohl es möglich ist, NSA-T-Komponenten ohne vSphere zu implementieren, konzentriert sich dieses Design auf NSX-T und seine Integration in erster Linie innerhalb einer automatisierten vCenter Server vSphere-Bereitstellung.
NSX-T Version 3 und höher kann auf dem vSphere virtual distributed switch (VDS) Version 7.0 laufen. Alle neuen Bereitstellungen von VMware NSX und vSphere verwenden NSX-T auf VDS (N-VDS wird nicht verwendet). Für NSX-T Version 2.4 und höher sind die Funktionen des Managers VM und des Controllers VM kombiniert. Als Ergebnis werden drei Controller- oder Manager-VMs bereitgestellt. Wenn sie in demselben Teilnetz verwendet werden, wird von ihnen eine interne Netzlastausgleichsfunktion verwendet. Wenn in verschiedenen Teilnetzen verwendet werden, ist eine externe Lastausgleichsfunktion erforderlich.
NSX-T bietet viele fortschrittliche Funktionen, wie z. B. Firewall-Richtlinien, die Einbeziehung von Gast-Introspektion in Firewall-Richtlinien und eine erweiterte Netzflussverfolgung. Das Beschreiben dieser Funktionen liegt außerhalb des Geltungsbereichs dieses Dokuments. In diesem Design wird die Managementinfrastruktur von NSX-T während der anfänglichen Bereitstellung des vCenter Server® Clusters implementiert. Weitere Informationen zu NSX-T finden Sie in der Dokumentation VMware NSX.
Ressourcenanforderungen
In diesem Design werden die NSX-T Controller Manager-VMs im Management-Cluster bereitgestellt. Außerdem wird jedem Controller-Manager eine VLAN-gestützte IP-Adresse aus dem privaten portablen Adressblock zugewiesen. Der Adressblock wird für Managementkomponenten bestimmt und mit den DNS- und NTP-Servern konfiguriert, die in Abschnitt 0 beschrieben werden. Eine Zusammenfassung der NSX Manager-Installation finden Sie in der folgenden Tabelle.
| Attribut | Spezifikation |
|---|---|
| NSX-Manager oder Controller | Drei virtuelle Appliances |
| Anzahl vCPUs | 6 |
| Speicher | 24 GB |
| Disk | 300 GB |
| Plattentyp | Thin Provisioning |
| NetworkPrivate A | Private A |
In der folgenden Abbildung wird die Anordnung der NSX Manager in Relation zu anderen Komponenten in dieser Architektur dargestellt.
Überlegungen zur Bereitstellung
Mit NSX-T v3.x auf vSphere VDS Switch Version 7.0 ist N-VDS auf den ESXi-Hosts nicht mehr erforderlich. Wenn sie als Transportknoten konfiguriert sind, können Sie nun V7 VDS verwenden, um einen konvergierten Cluster zu einem optimaleren Design zu machen.
Nach der Erstbereitstellung werden von der IBM Cloud®-Automatisierung drei virtuelle NSX-T Manager-Appliances im Management-Cluster bereitgestellt. Den Controllern wird eine VLAN-gestützte IP-Adresse aus dem tragbaren Subnetz Private A zugewiesen, das für Verwaltungskomponenten vorgesehen ist. Außerdem werden VM-VM-Anti-Affinitätsregeln erstellt, damit die Controller unter den Hosts im Cluster separiert werden.
Sie müssen den Management-Cluster mit mindestens drei Knoten implementieren, um eine hohe Verfügbarkeit für die Manager oder Controller sicherzustellen. Zusätzlich zu den Managern bereitet die IBM Cloud-Automatisierung den bereitgestellten Workload-Cluster als NSX-T-Transportknoten vor. Den ESXi-Transportknoten wird eine VLAN-gestützte IP-Adresse aus dem Bereich der portablen IP-Adressen Private A zugewiesen, die durch einen NSX-IP-Pool angegeben wird, der aus der VLAN- und Subnetzzusammenfassung abgeleitet wurde. Der Datenverkehr des Transportknotens befindet sich auf dem nicht getaggten VLAN und wird dem privaten NSX-T VDS zugewiesen.
Je nach der von Ihnen gewählten NSX-T-Topologie können Sie einen NSX-T-Gateway-Cluster entweder als VM-Paar oder als Software auf Bare-Metal-Cluster-Knoten bereitstellen. Die Bare-Metal-Edges werden von der IBM Cloud-Automation nicht unterstützt und müssen manuell implementiert und konfiguriert werden. Unabhängig davon, ob das Clusterpaar virtuell oder physisch virtuell ist, werden Uplinks für VDS-Switches sowohl für private als auch (falls vorhanden) öffentliche IBM Cloud-Netze konfiguriert.
In der folgenden Tabelle sind die Anforderungen für eine Umgebung mit mittlerer Größe zusammengefasst, was die empfohlene Startgröße für die Auslastung im Produktionsbetrieb darstellt.
| Ressourcen | Manager x3 | Cluster x4 für Edge-Service |
|---|---|---|
| Mittlere Größe | Virtuelle Appliance | Virtuelle Appliance |
| Anzahl vCPUs | 6 | 4 |
| Hauptspeicher | 24 GB | 8 GB |
| Platte | 300 GB vSAN oder Management-NFS | 200 GB vSAN oder Management-NFS |
| Plattentyp | Thin Provisioning | Thin Provisioning |
| Netz | Private A | Private A |
Design verteilter Switches
In dem Design wird eine minimale Anzahl von vDS-Switches verwendet. Die Hosts im Management-Cluster sind mit den privaten und (wahlweise) öffentlichen Netzen verbunden. Die Hosts werden mit zwei verteilten virtuellen Switches konfiguriert. Die Verwendung von zwei Switches basiert auf der Praxis im IBM Cloud-Netz, dass öffentliche und private Netze getrennt werden. Alle neuen Implementierungen von NSX und vSphere nutzen die Vorteile des vSphere VDS-Switches Version 7.0, der eine konvergente NSX-T-Architektur ermöglicht.
Wie in den vorherigen Diagrammen gezeigt, ist das öffentliche vDS *instancename*-*clustername*-public für die öffentliche Netzkonnektivität konfiguriert und die öffentliche vDS-Datei *instancename*-*clustername*-private ist für die private Netzkonnektivität konfiguriert. Die Trennung verschiedener Typen von Datenverkehr ist erforderlich, um Konkurrenzsituationen und Latenzzeiten zu verringern und die Sicherheit zu erhöhen.
VLANs werden zur Segmentierung physischer Netzfunktionen verwendet. In diesem Design werden drei VLANs verwendet: zwei für privaten Netzverkehr und eines für öffentlichen Netzverkehr. In der folgenden Tabelle wird die Trennung des Datenverkehrs dargestellt.
| VLAN | Bezeichnung | Datenverkehrstyp |
|---|---|---|
| VLAN 1 | Private A | ESXi-Verwaltung, Verwaltung, Edge-Uplinks |
| VLAN 2 | Private B | Genf (TEP), vSAN, NFS, und vMotion |
| VLAN 3 | Öffentliche | Für Internetzugriff verfügbar |
Für die optionalen zwei Host-Gateway-Cluster werden in diesem Design zwei VLANs verwendet: eines für den privaten Netzverkehr und eines für den öffentlichen Netzverkehr. Dieser Clustertyp verwendet lokale Platten als Datenspeicher. Aus diesem Grund benötigen Sie keinen separaten Speicherdatenverkehr. Außerdem wird gemäß dem Design der Datenverkehr von NSX-T Geneve (TEP) ausgelassen. In der folgenden Tabelle wird die Trennung des Datenverkehrs zwischen VLANs für diesen Clustertyp dargestellt.
| VLAN | Bezeichnung | Datenverkehrstyp |
|---|---|---|
| VLAN 1 | Private Transit | Privates Transit-VLAN, ESXi-Management und vMotion |
| VLAN 2 | Public Transit | VLAN mit öffentlichem Transit |
Namenskonventionen
Für die Bereitstellung werden die folgenden Namenskonventionen verwendet. Zur Lesbarkeit wird nur die spezifische Benennung verwendet. Beispiel: instancename-dcname-clustername-tz-edge-private wird als tz-edge-private bezeichnet.
| Beschreibung | Benennungsstandard |
|---|---|
| Management-VMs | instancename-nsxt-ctrlmgr0instancename-nsxt-ctrlmgr1instancename-nsxt-ctrlmgr2 |
| Uplink-Profile | instancename-esxi-private-profileinstancename-esxi-public-profileinstancename-edge-private-profileinstancename-edge-public-profileinstancename-edge-tep-profileinstancename-mgmt-edge-private-profileinstancename-mgmt-edge-public-profileinstancename-mgmt-edge-tep-profile |
| NIOC-Profile | instancename-clustername-nioc-private-profileinstancename-clustername-nioc-public-profile |
| Gateway-Cluster-Profile | instancename-dcname-clustername-service-edge-cluster-profileinstancename-dcname-clustername-service-edge-cluster-profile |
| Transportzonen | instancename-tz-esxi-privateinstancename-tz-esxi-publicinstancename-tz-vm-overlayinstancename-tz-edge-privateinstancename-tz-edge-public |
| Segmente | instancename-podname.dcname-customer-t0-172-16-16-0instancename-podname.dcname-customer-t1-192-168-0-0instancename-podname.dcname-customer-t1-192-168-1-0instancename-podname.dcname-customer-to-privateinstancename-podname.dcname-customer-to-publicinstancename-podname.dcname-service-to-privateinstancename-podname.dcname-service-to-publicinstancename-clustername-edge-teps |
| IP-Adresspools | instancename-clustername-tep-pool |
| Transportknotenprofile | instancename-podname.dcname-clustername-esxi-tpn-profile |
| Tier-0- und Tier-1-Gateways | instancename-podname.dcname-clustername-T0-function (function enthält services, workload, openshift)instancename-podname.dcname-clustername-T1-function |
Transportknoten
Transportknoten definieren die physischen Serverobjekte oder VMs, die an der virtuellen Netzstruktur beteiligt sind. Sehen Sie sich die folgende Tabelle an, um das Design zu verstehen.
| Typ des Transportknotens | Uplinkprofil | IP-Zuweisung |
|---|---|---|
| ESXi | esxi-private-profileesxi-public-profile |
tep-pool |
| Gateway-Cluster | edge-private-profileedge-public-profileedge-tep-profilemgmt-edge-private-profilemgmt-edge-public-profilemgmt-edge-tep-profile |
tep-pool |
Uplinkprofile und Teaming
Ein Uplink-Profil definiert Richtlinien für die Verbindungen von Hypervisor-Hosts zu logischen NSX-T-Switches oder von NSX Edge-Knoten zu TOR-Switches (Top-of-Rack).
| Uplinkprofilname | VLAN | Teaming-Richtlinie | Aktive Uplinks | Standby-Links | MTU |
|---|---|---|---|---|---|
esxi-private-profile |
Standard | Standard-Loadbalance-Quelle | uplink-1 uplink-2 |
Verwaltet von vCenter Server | |
esxi-private-profile |
Standard | TEP-Funktionsübernahme | uplink-1 | uplink-2 | Verwaltet von vCenter Server |
esxi-public-profile |
Standard | Standard-Loadbalance-Quelle | uplink-1 uplink-2 |
Verwaltet von vCenter Server | |
edge-private-profile |
Standard | uplink-1 | 9000 | ||
edge-public-profile |
Standard | uplink-1 | 1500 | ||
edge-tep-profile |
Standard | Failover-Reihenfolge | uplink-1 | 9000 | |
mgmt-edge-private-profile |
Standard | uplink-1 | 9000 | ||
mgmt-edge-public-profile |
Standard | uplink-1 | 1500 | ||
mgmt-edge-tep-profile |
Standard | Failover-Reihenfolge | uplink-1 | 9000 |
VNI-Pools
Virtuelle Netz-IDs (VNIs) ähneln VLANs in einem physischen Netz. Sie werden automatisch erstellt, wenn ein logischer Switch aus einem Pool oder einem Bereich von IDs erstellt wird. In diesem Design wird der standardmäßige VNI-Pool verwendet, der mit NSX-T bereitgestellt wird.
Segmente
Ein NSX-T-Segment reproduziert in einer virtuellen Umgebung, die von der zugrunde liegenden Hardware entkoppelt ist, Switchfunktionen und BUM-Datenverkehr (Broadcast, Unknown-Unicast, Multicast).
| Segmentname | VLAN | Transportzone | Uplink-Teaming-Richtlinie |
|---|---|---|---|
edge-teps |
Standard | tz-esxi-private |
TEP-Funktionsübernahme |
service-to-private |
Standard | tz-edge-private |
|
service-to-public |
Standard | tz-edge-public |
|
customer-to-private |
Standard | tz-edge-private |
|
customer-to-public |
Standard | tz-edge-public |
|
customer-t0-172-16-16-0 |
tz-vm-overlay |
||
customer-t1-192-168-0-0 |
tz-vm-overlay |
||
customer-t1-192-168-1-0 |
tz-vm-overlay |
Gateway-Cluster
In diesem Design werden zwei virtuelle Edge-Knoten-Cluster bereitgestellt, einer für das Management und die andere für Kundenworkloads. Es besteht eine Einschränkung von einem T0 pro Edge-Transportknoten, was bedeutet, dass ein einzelner Edge-Knotencluster ein T0-Gateway unterstützen kann (entweder in aktiv-standby oder aktiv-aktiv).
Die folgenden Abbildungen zeigen die funktionalen Komponenten eines NSX-T-Gateway-Clusters.
Logisches Tier-0-Gateway
Ein logisches NSX-Tier-0-Gateway stellt einen Gateway-Service zwischen dem logischen und dem physischen Netz (für Nord-Süd-Datenverkehr) bereit. Bei diesem Design werden zwei hochverfügbare T0 Gateways in zwei separaten NSX-T-Gateway-Clustern bereitgestellt, einer für Kunden und einer für Services oder Verwaltungsanforderungen. Weitere Dienste und Produkte sind optional für vom Kunden gewählte Topologien und sie nutzen die Dienste T0 für ihre ein- oder ausgehenden Konnektivitätsanforderungen. Jedes logische T0-Gateway ist mit zwei Uplinks für private und zwei für öffentliche Verbindungen konfiguriert. Zusätzlich werden VIPs sowohl öffentlichen als auch privaten Uplinks zugewiesen.
Logisches Tier-1-Gateway
Ein logisches Tier-1-NSX-T-Gateway verfügt über Downlink-Ports, um Verbindungen zu logischen NSX-T-Switches in Rechenzentren herzustellen, und über Uplink-Ports, um nur Verbindungen zu logischen Tier-0-NSX-T-Gateways in Rechenzentren herzustellen. Sie werden auf der Kernel-Ebene des Hypervisors ausgeführt, für den sie konfiguriert sind, und sind virtuelle Router-Instanzen (vrf) des NSX-T-Gateway-Clusters. In diesem Design können ein oder mehrere T1 logische Gateways für die Bedürfnisse der vom Kunden gewählten Topologien erstellt werden.
Routenmitteilung von Tier 1 bis Tier 0
Um Layer-3-Konnektivität zwischen VMs bereitzustellen, die mit logischen Switches verbunden sind, die an verschiedene logische Tier-1-Gateways angeschlossen sind, ist es notwendig, Tier-1-Routenanzeige in Richtung Tier-0 zu aktivieren. Es ist nicht erforderlich, ein Routing-Protokoll oder statische Routen zwischen den logischen Tier-1- und Tier-0-Routen zu konfigurieren. NSX-T erstellt statische Routen automatisch, wenn Sie die Routenmitteilung aktivieren. Bei diesem Design ist die Routenanzeige für alle durch IBM Cloud® for VMware Solutions-Automation erstellten T1-Gateways immer aktiviert.
Vorkonfigurierte Topologien
Arbeitslast an T1 an T0 gateway - virtueller Gateway-Cluster
Bei NSX-T ist keine dynamische Routing-Protokollkonfiguration zwischen T1 und T0 vorhanden. RFC-1891 Der IP-Adressraum wird für das Workload-Overlay-Netz und das Transit-Overlay-Netz verwendet. Dem Kunden wird ein privater und öffentlicher portabler IP-Bereich zugeordnet, der für den Kunden verwendet wird. Ein vom Kunden als bezeichneter privater und öffentlicher portierbarer IBM Cloud-IP-Bereich wird dem T0 zur Verwendung durch den Kunden zugewiesen.