NSX-T und NSX-V im Vergleich

Für VMware vSphere Network NSX (NSX-V) überprüfen Sie die folgenden NSX-T-Objekte mit ähnlichen Funktionen wie ihre NSX-V-Gegenstücke. Einschränkungen und Unterschiede innerhalb einer vSphere-Umgebung werden ebenfalls besprochen.

Die folgende Tabelle zeigt die typischen entsprechenden Funktionen zwischen NSX-T und NSX-V.

Mit NSX-T verfügen Sie über Tier-0-Gateways (T0-Gateways) und Tier-1-Gateways (T1-Gateways). Während sie im vorherigen Abschnitt als Äquivalent zu einem NSX-V Edge Services Gateway (ESG) und einem Distributed Logical Router (DLR) dargestellt wurden, ist dies nicht ganz korrekt.

Für NSX-T werden zwei neue Konzepte eingeführt: Distributed Router (DR) und Service-Router (SR).

Einige wichtige NSX-T-Konzepte entsprechen nicht den NSX-V-Funktionen. Sie müssen die folgenden Konzepte überprüfen, damit Sie die Implementierung des NSX-T-Designs verstehen können.

• Ein Gateway-Cluster besteht aus einer oder mehreren VMs oder physischen Maschinen, die an einer virtuellen NSX-T-Struktur teilnehmen. Sie sind Endpunkte für die Overlay-Netztransportzonen und VLAN-gestützten Transportzonen. Ein Gateway-Cluster kann eine einzelne T0-Gateway-Instanz unterstützen.
• Ein T0-Gateway ist eine virtuelle Routerkomponente, aber keine VM. Mehrere T0-Gateway-Instanzen können innerhalb eines Gateway-Clusters ausgeführt werden, wobei jede über eine eigene Routingtabelle und eigene Funktionen verfügt. Ein Gateway-Cluster muss vorhanden sein, bevor Sie eine T0-Routerinstanz erstellen können.
• Eine Transportzone kann Endpunkte über verschiedene Plattformen hinweg und mehrere vSphere vCenter-Instanzen umfassen. Es ist kein Cross-vCenter-verknüpftes NSX erforderlich. Transportzonen können von bestimmten Endpunkten ausgeschlossen werden.
• Die Uplink-Failover-Reihenfolge wird unabhängig von einem bestimmten logischen Switch erstellt, da sie in Profilen als "Uplink Profiles" erstellt und auf einen bestimmten logischen Switch angewendet werden, der auf VLAN basiert. Es kann sein, dass ein abweichendes Failover oder ein abweichender Lastausgleich für physische Uplinks für dasselbe VLAN erforderlich wird. Daher kann das Uplink-Profil für ein bestimmtes VLAN mehrere Einträge für "Teaming" mit einer anderen Failover-Reihenfolge und Lastverteilung enthalten. Wenn Sie das Uplink-Profil einem logischen Switch zuordnen, wird das bestimmte Teaming-Profil ausgewählt.
• Die Manager-VM- und die Controller-VM-Funktion wurden kombiniert, was zur Folge hat, dass drei NSX-T-Manager-VMs bereitgestellt werden. 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.

Ressourcenanforderungen

In diesem Design werden die NSX-T Controller Manager-VMs im Management-Cluster bereitgestellt. Außerdem ist jeder Controller Manager-Instanz eine VLAN–gestützte IP-Adresse aus dem privaten portierbaren Adressblock zugeordnet. 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 ist in der folgenden Tabelle dargestellt.

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. Jedem der Controller wird eine VLAN-gestützte IP-Adresse aus dem portierbaren Teilnetz "Privat A" zugeordnet, das für Managementkomponenten 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-gesicherte IP-Adresse aus dem portablen IP-Adressbereich Private A zugewiesen, der durch einen aus der VLAN- und Teilnetzzusammenfassung abgeleiteten NSX-IP-Pool-Bereich festgelegt ist. Der Verkehr des Verkehrsknotenpunkts befindet sich im nicht gekennzeichneten 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 ein Paar von VMs oder als Software bereitstellen, die auf Bare-Metal-Clusterknoten bereitgestellt wird. 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.

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.

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.

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.

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.

Uplinkprofile und Teaming

Ein Uplinkprofil definiert Richtlinien für die Links von Hypervisor-Hosts zu logischen NSX-T-Switches oder von NSX Edge-Knoten zu Top-of-Rack-Switches.

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

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 Funktionskomponenten 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 Entwurf werden zwei hochverfügbare T0-Gateways in zwei separaten NSX-T-Gateway-Clustern eingesetzt, einer für Kunden und einer für Service- oder Verwaltungsanforderungen. Weitere Dienstleistungen und Produkte sind für vom Kunden gewählte Topologien optional und sie nutzen die Dienste T0 für ihre eingehenden 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 Entwurf können ein oder mehrere T1 logische Gateways für die Anforderungen 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

Workload zu T1 zu T0 Gateway – virtueller Gateway-Cluster

Topologie 1 ist im Wesentlichen die gleiche Topologie, die mit den NSX-V-DLR- und Edge-Gateways bereitgestellt wird. 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.

---

1. Ein T0-Gateway ähnelt einer ESG. Es bietet Nord-Süd-Konnektivität zwischen physischen und logischen Netzen, unterstützt dynamisches Routing (BGP), ECMP und statusabhängige Services wie eine Firewall, NAT oder einen Lastausgleich. Er stellt außerdem verteilte Services für Ost-West-Routing zur Verfügung. ↩︎

2. Ein T1-Gateway ist wie ein T0-Gateway, enthält jedoch normalerweise keine Uplinks für die Verbindung zu einem physischen Netzwerk. Sein Uplink stellt eine Verbindung zu einem automatisch angeschlossenen Overlay-Segment mit dem T0-Gateway her. Von einem T1-Gateway werden statische Routen, NAT, Lastenausgleich und IPSec-VPNs unterstützt. ↩︎