NSX-v vs. NSX-T: Umfassender Vergleich

Die Virtualisierung hat die Art und Weise, wie Rechenzentren aufgebaut sind, revolutionär verändert. Die meisten modernen Rechenzentren nutzen Hardware-Virtualisierung und stellen physische Server als Hypervisoren bereit, um auf diesen Servern Virtuelle Maschinen auszuführen. Dieser Ansatz verbessert die Skalierbarkeit, Flexibilität und Kosteneffizienz des Rechenzentrums. VMware ist einer der führenden Anbieter auf dem Virtualisierungsmarkt, und seine Produkte genießen in der IT-Branche hohes Ansehen. Der VMware ESXi-Hypervisor und VMware vCenter sind weithin bekannte Komponenten der Virtualisierungslösung VMware vSphere.

Das Netzwerk ist eine entscheidende Komponente jedes Rechenzentrums, auch von virtualisierten Rechenzentren. Wenn Sie für Ihr virtualisiertes Rechenzentrum große Netzwerke und komplexe Netzwerkkonfigurationen benötigen, sollten Sie den Einsatz von Software-Defined Networking (SDN) in Betracht ziehen. Software-Defined Networking ist eine Architektur, die darauf abzielt, Netzwerke agil und flexibel zu gestalten. Das Ziel von SDN ist es, die Netzwerksteuerung zu verbessern, indem Unternehmen und Dienstanbieter in die Lage versetzt werden, schnell auf sich ändernde Geschäftsanforderungen zu reagieren. VMware legt großen Wert auf seine Kunden und bietet die VMware NSX-Lösung zum Aufbau softwaredefinierter Netzwerke an. Der heutige Blogbeitrag befasst sich mit VMware NSX und beleuchtet die Unterschiede zwischen VMware NSX-v und VMware NSX-T.

NAKIVO für VMware vSphere-Backups

Umfassende Datensicherheit für VMware vSphere-VMs und Optionen für die sofortige Wiederherstellung. Sichere Backup-Ziele vor Ort, außerhalb des Standorts und in der Cloud. Anti-Ransomware-Funktionen.

ERKENNEN SIE DIE LÖSUNG

Was ist VMware NSX und wie lässt es sich einsetzen?

VMware NSX ist eine Lösung zur Netzwerkvirtualisierung, mit der Sie softwaredefinierte Netzwerke in virtualisierten Rechenzentren aufbauen können. Genauso wie virtuelle Maschinen (VMs) von der physischen Serverhardware abstrahiert werden, werden virtuelle Netzwerke – einschließlich Switches, Ports, Router, Firewalls usw. – im virtuellen Raum aufgebaut. Virtuelle Netzwerke werden unabhängig von der zugrunde liegenden Hardware bereitgestellt und verwaltet. Virtuelle Maschinen werden mit virtuellen Ports von virtuelle Switchesverbunden; die Verbindung zwischen virtuellen Netzwerken erfolgt über virtuelle Router, und Zugriffsregeln werden auf virtuellen Firewalls konfiguriert. Alternativ steht auch ein Netzwerk-Lastausgleich zur Verfügung. VMware NSX ist ein Nachfolger von VMware vCloud Networking & Security (vCNS)sowie von Nicira NVP, das 2012 von VMware übernommen wurde.

Mikrosegmentierung

Bei der Verwendung eines herkömmlichen Ansatzes zur Konfiguration des Zugriffs zwischen mehreren Netzwerken in einer virtuellen Umgebung wird in der Regel ein physischer Router oder ein Edge-Gateway bereitgestellt, das auf einer VM läuft, obwohl dieser Ansatz weder besonders schnell noch besonders komfortabel ist. VMware hat das Konzept der Mikrosegmentierung in NSX durch den Einsatz einer verteilten Firewall umgesetzt, die in den Kern des Hypervisors integriert ist. Sicherheitsrichtlinien sowie Parameter für die Netzwerkinteraktion in Bezug auf IP-Adressen, MAC-Adressen, VMs, Anwendungen und andere Objekte werden alle in dieser verteilten Firewall festgelegt. Die Regeln können unter Verwendung von Objekten wie Active-Directory-Benutzern und -Gruppen konfiguriert werden, sofern NSX in Ihrem Unternehmen eingesetzt wird, in dem ein Active-Directory-Domänencontroller (ADDC) verwendet wird. Jedes Objekt kann als Mikrosegment in seinem eigenen Sicherheitsperimeter des entsprechenden Netzwerks betrachtet werden, das über eine eigene DMZ (demilitarisierte Zone) verfügt.

Die verteilte Firewall ermöglicht es Ihnen, Einheiten des virtuellen Rechenzentrums wie Virtuelle Maschinen zu segmentieren. Die Segmentierung kann auf VM-Namen und -Attributen, der Benutzeridentität, vCenter-Objekten wie Rechenzentren und Hosts basieren oder auf traditionellen Netzwerkattributen wie IP-Adressen, Portgruppen usw.

Die Edge-Firewall-Komponente unterstützt Sie bei der Erfüllung wichtiger Anforderungen an die Perimetersicherheit, wie zum Beispiel die Einrichtung von DMZs auf Basis von IP-/VLAN-Konstrukten, die Isolierung zwischen Mandanten in mandantenfähigen virtuellen Rechenzentren, Network Address Translation (NAT), Partner-VPNs (Extranet) und benutzerbasierte SSL-VPNs.

Wird eine virtuelle Maschine von einem Host auf einen anderen – also von einem Subnetz in ein anderes – migriert, werden die Zugriffsregeln und Sicherheitsrichtlinien entsprechend dem neuen Standort übernommen. Wenn ein Datenbankserver auf einer migrierten VM läuft, bleiben die für diese VM in der Firewall festgelegten Regeln auch nach Abschluss der Migration auf einen anderen Host oder in ein anderes Netzwerk für diese VM weiterhin gültig, sodass der Datenbankserver auf den Anwendungsserver zugreifen kann, der auf der nicht migrierten VM läuft. Dies ist ein Beispiel für die verbesserte Flexibilität und Automatisierung, die sich bei der Nutzung von VMware NSX in der Praxis zeigt. NSX kann insbesondere für Cloud-Anbieter und große virtuelle Infrastrukturen von großem Nutzen sein. VMware bietet zwei Varianten der softwaredefinierten Netzwerkplattform NSX an – NSX-v und NSX-T.

NSX für vSphere (NSX-v) ist eng in VMware vSphere integriert und erfordert die Bereitstellung des VMware vCenter. VMware NSX-v ist speziell auf vSphere-Hypervisor-Umgebungen ausgelegt und wurde vor NSX-T entwickelt.

NSX-T (NSX-Transformers) wurde für verschiedene Virtualisierungsplattformen und Multi-Hypervisor-Umgebungen konzipiert und kann auch in Verwendungsfällen eingesetzt werden, in denen NSX-v nicht anwendbar ist. Während NSX-v SDN nur für VMware vSphere unterstützt, unterstützt NSX-T auch Netzwerkvirtualisierungs-Stacks für KVM, Docker, Kubernetes und OpenStack sowie AWS-native Workloads. VMware NSX-T kann ohne vCenter Server bereitgestellt werden und eignet sich für heterogene Rechensysteme.

Die wichtigsten Anwendungsszenarien für NSX-v sind in der folgenden Tabelle aufgeführt. Die Tabelle ist in drei Zeilen unterteilt, von denen eine die Szenariokategorie beschreibt. Szenarien für den Einsatz von NSX-T sind fett hervorgehoben.

NSX-Komponenten

Die Hauptkomponenten von VMware NSX sind der NSX Manager, NSX-Controller und NSX-Edge-Gateways.

NSX Manager ist eine zentralisierte Komponente von NSX, die zum Verwalten von Netzwerken dient. Der NSX Manager kann als VM auf einem der von vCenter verwalteten ESXi-Server (aus einer OVA-Vorlage) bereitgestellt werden. Bei Verwendung von NSX-v kann der NSX Manager nur mit einem einzigen vCenter-Server zusammenarbeiten, während der NSX Manager für NSX-T als ESXi-VM oder KVM-VM bereitgestellt werden kann und gleichzeitig mit mehreren vCenter-Servern zusammenarbeiten kann. Der NSX Manager für vSphere basiert auf dem Photon OS (ähnlich wie die vCenter Server Appliance).

Der NSX-T Manager läuft unter dem Betriebssystem Ubuntu.

NSX-Controller . Der NSX-Controller ist ein verteiltes Zustandsmanagementsystem, das zum Einrichten von Transporttunneln und zur Steuerung virtueller Netzwerke dient und als VM auf ESXi- oder KVM-Hypervisoren bereitgestellt werden kann. Der NSX-Controller steuert alle logischen Switches innerhalb des Netzwerks und verarbeitet Informationen zu VMs, Hosts, Switches und VXLANs. Durch den Einsatz von drei Controller-Knoten wird die Datenredundanz im Falle eines Ausfalls eines NSX-Controller-Knotens gewährleistet.

NSX Edge ist ein Gateway-Dienst, der VMs den Zugriff auf physische und virtuelle Netzwerke ermöglicht. NSX Edge kann als verteilter virtueller Router oder als Services-Gateway installiert werden. Folgende Dienste können bereitgestellt werden: Dynamisches Routing, Firewalls, Network Address Translation (NAT), Dynamic Host Configuration Protocol (DHCP), Virtual Private Network (VPN), Lastenausgleich und Hochverfügbarkeit.

Bereitstellungsoptionen

Das Konzept der Bereitstellung ist bei NSX-v und NSX-T sehr ähnlich. Führen Sie zur Bereitstellung von NSX die folgenden Schritte durch:

• Bereiten Sie den NSX Manager mithilfe einer Virtuellen Appliance als VM auf einem ESXi-Host vor. Achten Sie darauf, den NSX Manager in VMware vSphere vCenter zu registrieren (für NSX-v). Wenn Sie NSX-T verwenden, kann der NSX Manager als virtuelle Appliance auf einem KVM-Host bereitgestellt werden, da VMware NSX-T die Erstellung eines Clusters aus NSX-Managern ermöglicht.
• Bereitstellen Sie drei NSX-Controller und erstellen Sie einen NSX-Controller-Cluster.
• Installieren Sie „ VIBs “ (Kernel-Module) auf ESXi-Hosts, um eine verteilte Firewall, verteiltes Routing und VXLAN zu aktivieren, wenn Sie NSX-v verwenden. Wenn Sie NSX-T verwenden, müssen die Kernel-Module auch auf KVM-Hypervisoren installiert werden.
• Installieren Sie NSX Edge als VM auf ESXi (für NSX-v und NSX-T). Wenn Sie NSX-T verwenden und es keine Möglichkeit gibt, Edge als virtuelle Maschine auf ESXi zu installieren, kann Edge auf einem physischen Server bereitgestellt werden. Die Bereitstellung von Edge als VM auf KVM-Hypervisoren wird derzeit nicht unterstützt (für NSX-T v.2.3). Wenn Sie Edge auf einem physischen Server bereitstellen müssen, überprüfen Sie zuvor die Hardware-Kompatibilitätsliste (wichtig für CPUs und Netzwerkkarten).

Gemeinsame Funktionen von NSX

Es gibt eine Reihe von Funktionen, die für beide NSX-Typen verfügbar sind.

Die gemeinsamen Funktionen für NSX-v und NSX-T sind:

• Softwarebasierte Netzwerkvirtualisierung
• Softwarebasiertes Overlay
• Verteiltes Routing
• Verteilte Firewall-Funktionen
• API-gesteuerte Automatisierung
• Detaillierte Überwachung und Statistiken

Bitte beachten Sie, dass sich die APIs von NSX-v und NSX-T unterscheiden.

Lizenzierung

Die Lizenzierung ist für beide NSX-Typen identisch und bietet Ihnen mehr Flexibilität und Universalität. Sie können beispielsweise eine Lizenz für die Nutzung von NSX für vSphere bestellen. Wenn Sie anschließend Änderungen an Ihrer Infrastruktur vornehmen und NSX-T bereitstellen müssen, können Sie die für ESXi-v erworbene Lizenz verwenden. NSX ist NSX – aus Sicht der Lizenzierung gibt es keinen Unterschied, da auch die Editionen identisch sind.

Overlay-Kapselung

Die Overlay-Kapselung für virtuelle Netzwerke wird verwendet, um virtuelle Netzwerke zu abstrahieren, indem Layer-2-Informationen über Layer 3 übertragen werden. Ein logisches Layer-2-Netzwerk wird über bestehende Layer-3-Netzwerke (IP-Netzwerke) auf einer bestehenden physischen Infrastruktur erstellt. Dadurch können zwei VMs über das Netzwerk miteinander kommunizieren, selbst wenn der Pfad zwischen den VMs geroutet werden muss. Ein physisches Netzwerk kann als Underlay-Netzwerk bezeichnet werden.

VXLAN vs. GENEV

NSX-v verwendet das VXLAN-Kapselungsprotokoll, während NSX-T GENEVE verwendet, ein moderneres Protokoll.

VXLAN . Für VXLAN wird eine MAC-über-IP-Kapselung verwendet, und das Funktionsprinzip der Netzwerkisolierung unterscheidet sich von der VLAN-Technik. Herkömmliche VLANs haben eine begrenzte Anzahl von Netzwerken, nämlich 4094 gemäß dem 802.1q-Standard, und die Netzwerkisolierung erfolgt auf Schicht 2 eines physischen Netzwerks durch Hinzufügen von 4 Bytes zu den Ethernet-Frame-Headern. Die maximale Anzahl virtueller Netzwerke für VXLAN beträgt 2^24. In diesem Fall wird die VXLAN-Netzwerkkennung verwendet, um jedes Virtuelle Netzwerk zu kennzeichnen. Die Layer-2-Frames des Overlay-Netzwerks werden in UDP-Datagramme gekapselt, die über ein physisches Netzwerk übertragen werden. Die UDP-Portnummer lautet in diesem Fall 4789.

Der VXLAN-Header besteht aus den folgenden Teilen.

• 8 Bits werden für Flags verwendet. Das I-Flag muss auf 1 gesetzt sein, damit ein VXLAN Network ID (VNI) gültig ist. Die übrigen 7 Bits sind R-Felder, die reserviert sind und bei der Übertragung auf Null gesetzt werden müssen. Die auf Null gesetzten R-Felder werden beim Empfang ignoriert.
• VXLAN Network Identifier (VNI) – auch bekannt als VXLAN Segment ID – ist ein 24-Bit-Wert, der zur Bestimmung des jeweiligen Overlay-Netzwerks dient, das für die Kommunikation zwischen den VMs genutzt wird.
• Reservierte Felder (24-Bit und 8-Bit) müssen auf Null gesetzt und beim Empfang ignoriert werden.

Die Größe des VXLAN-Headers ist fest vorgegeben und beträgt 8 Byte. Für VXLAN wird die Verwendung von Jumbo-Frames mit einer MTU von 1600 Byte oder mehr empfohlen.

GENEVE. Der GENEVE -Header ähnelt stark dem VXLAN-Header und weist folgende Struktur auf:

• Ein kompakter Tunnel-Header wird in UDP über IP gekapselt.
• Ein kleiner, fester Tunnel-Header wird verwendet, um Steuerinformationen sowie ein Mindestmaß an Funktionalität und Interoperabilität bereitzustellen.
• Es stehen Optionen mit variabler Länge zur Verfügung, um die Implementierung zukünftiger Innovationen zu ermöglichen.

Die Größe des GENEVE Headers ist variabel.

NSX-T verwendet GENEVE (GEneric NEtwork Virtualization Encapsulation) als Tunneling-Protokoll, das die traditionellen Offload-Fähigkeiten der Netzwerkkarten (NICs) beibehält, um eine optimale Leistung zu gewährleisten. Den Overlay-Headern können zusätzliche Metadaten hinzugefügt werden, wodurch sich die Kontextunterscheidung für die Verarbeitung von Informationen wie End-to-End-Telemetrie, Datenverfolgung, Verschlüsselung, Sicherheit usw. auf der Datenübertragungsschicht verbessern lässt. Zusätzliche Informationen in den Metadaten werden als „ TLV “ (Typ, Länge, Wert) bezeichnet. „ GENEVE “ wurde von VMware, Intel, Red Hat und Microsoft entwickelt. „ GENEVE “ basiert auf den besten Konzepten der Kapselungsprotokolle „ VXLAN, STT “ und „ NVGRE “.

Der MTU-Wert für Jumbo-Frames muss bei Verwendung der GENEVE -Kapselung mindestens 1700 Byte betragen, was auf das zusätzliche Metadatenfeld variabler Länge für GENEVE -Header zurückzuführen ist (wie Sie sich erinnern, wird für VXLAN eine MTU von 1600 oder höher verwendet).

NSX-v und NSX-T sind aufgrund der in diesem Abschnitt erläuterten Unterschiede bei der Overlay-Kapselung nicht kompatibel.

Layer-2-Netzwerke

Nun wissen Sie, wie virtuelle Layer-2-Ethernet-Frames über IP-Netzwerke gekapselt werden; daher ist es an der Zeit, die Implementierung virtueller Layer-2-Netzwerke für NSX-v und NSX-T zu untersuchen.

Transportknoten und virtuelle Switches

Transportknoten und virtuelle Switches stellen die Komponenten für die Datenübertragung in NSX dar.

Ein Transportknoten (TN) ist ein NSX-kompatibles Gerät, das an der Datenübertragung und am NSX-Netzwerk-Overlay beteiligt ist. Ein Knoten muss einen Host-Switch enthalten, um als Transportknoten fungieren zu können. NSX-v erfordert wie in VMware vSphere üblich die Verwendung eines verteilten virtuellen Switches von vSphere (VDS). Standard-Switches können für NSX-v nicht verwendet werden.

NSX-T setzt voraus, dass Sie einen verteilten virtuellen Switch von NSX-T (N-VDS) bereitstellen. Open vSwitches (OVS) werden für KVM-Hosts verwendet, und VMware vSwitches, die für ESXi-Hosts vorgesehen sind, können für diesen Zweck genutzt werden.

N-VDS (der zuvor als Host-Switch bezeichnete verteilte virtuelle Switch) ist eine NSX-Softwarekomponente auf dem Transportknoten, die die Datenübertragung übernimmt. N-VDS ist die Hauptkomponente der Datenebene der Transportknoten, die den Datenverkehr weiterleitet und über mindestens einen physischen Netzwerk-Interface-Controller (NIC) verfügt. NSX Switches (N-VDS) der verschiedenen Transportknoten sind unabhängig voneinander, können jedoch durch die Vergabe gleicher Namen für ein zentralisiertes Management gruppiert werden.

Auf ESXi-Hypervisoren N-VDS wird der Hostswitch von VMware vSphere Distributed Switch über das Modul NSX-vSwitch implementiert, das in den Kernel des Hypervisors geladen wird. Auf KVM-Hypervisoren wird der Hostswitch von VMware vSphere Distributed Switch über das Modul Open-vSwitch (OVS) implementiert.

Transportzonen sind sowohl für NSX-v als auch für NSX-T verfügbar. Transportzonen definieren die Grenzen der Verteilung logischer Netzwerke. Jede Transportzone ist mit ihrem NSX-Switch (N-VDS) verbunden. Transportzonen für NSX-T sind nicht mit Clustern verknüpft.

Aufgrund der GENEVE-Kapselung gibt es bei VMware NSX-T zwei Arten von Transportzonen: Overlay oder VLAN. Bei VMware NSX-v definiert eine Transportzone hingegen ausschließlich die Verteilungsgrenzen von VXLAN.

Replikationsmodi für logische Switches

Wenn zwei Virtuelle Maschinen, die sich auf unterschiedlichen Hosts befinden, direkt miteinander kommunizieren, wird der Unicast-Verkehr im gekapselten Modus zwischen zwei den Hypervisoren zugewiesenen Endpunkt-IP-Adressen ausgetauscht, ohne dass ein Flooding erforderlich ist. Manchmal muss der von einer VM ausgehende Layer-2-Netzwerkverkehr ähnlich wie Layer-2-Verkehr in herkömmlichen physischen Netzwerken weitergeleitet werden, beispielsweise wenn ein Absender die MAC-Adresse der Zielnetzwerkschnittstelle nicht kennt. Das bedeutet, dass derselbe Datenverkehr (Broadcast, Unicast, Multicast) an alle VMs gesendet werden muss, die mit demselben logischen Switch verbunden sind. Befinden sich die VMs auf verschiedenen Hosts, muss der Datenverkehr auf diese Hosts repliziert werden. Broadcast-, Unicast- und Multicast-Datenverkehr wird auch als BUM-Verkehr bezeichnet.

Sehen wir uns den Unterschied zwischen den Replikationsmodi für NSX-v und NSX-T an.

NSX-v unterstützt den Unicast-Modus, den Multicast-Modus und den Hybrid-Modus.

NSX-T unterstützt den Unicast-Modus mit zwei Optionen: Hierarchische Zwei-Ebenen-Replikation (optimiert, wie bei NSX-v) und Head-Replikation (nicht optimiert).

ARP-Unterdrückung reduziert den über das Netzwerk gesendeten ARP-Broadcast-Verkehr und ist für die Replikationsmodi „Unicast“ und „Hybrid“ verfügbar. Somit ist die ARP-Unterdrückung sowohl für NSX-v als auch für NSX-T verfügbar.

Wenn eine VM1 eine ARP-Anfrage sendet, um die MAC-Adresse einer VM2 zu ermitteln, wird die ARP-Anfrage vom logischen Switch abgefangen. Verfügt der Switch bereits über den ARP-Eintrag für die Zielnetzwerkschnittstelle der VM2, sendet der Switch die ARP-Antwort an die VM1. Andernfalls leitet der Switch die ARP-Anfrage an einen NSX-Controller weiter. Enthält der NSX-Controller Informationen zur Zuordnung von VM-IP-Adressen zu MAC-Adressen, sendet der Controller die Antwort mit dieser Zuordnung, woraufhin der logische Switch die ARP-Antwort an VM1 weiterleitet. Ist auf dem NSX-Controller kein ARP-Eintrag vorhanden, wird die ARP-Anfrage vom logischen Switch erneut gesendet.

NSX-Layer-2-Bridging

Layer-2-Bridging ist nützlich für die Migration von Workloads aus Overlay-Netzwerken in VLANs oder für die Aufteilung von Subnetzen auf physische und virtuelle Workloads.

NSX-v: Diese Funktion arbeitet auf der Kernel-Ebene eines Hypervisors, auf dem eine Kontroll-VM läuft.

NSX-T : Zu diesem Zweck wird ein separater NSX-Bridge-Knoten erstellt. NSX-Bridge-Knoten können zu Clustern zusammengefasst werden, um die Fehlertoleranz der gesamten Lösung zu verbessern.

In der NSX-v-Steuerungs-VM wurde Redundanz mithilfe des High-Availability-Schemas (HA) implementiert. Eine VM-Kopie ist aktiv, während die zweite VM-Kopie im Standby-Modus ist. Wenn die aktive VM ausfällt, kann es einige Zeit dauern, bis die VMs umgeschaltet und die Standby-VM geladen und aktiviert wird. NSX-T weist diesen Nachteil nicht auf, da anstelle des Aktiv-/Standby-Schemas für HA ein fehlertoleranter Cluster verwendet wird.

Das Routing-Modell

Bei der Verwendung von VMware NSX werden die folgenden Begriffe verwendet:

Ost-West-Verkehr bezieht sich auf die Datenübertragung über das Netzwerk innerhalb des Rechenzentrums. Dieser Name wird für diese spezielle Art von Datenverkehr verwendet, da horizontale Linien in Diagrammen typischerweise den Datenverkehr im lokalen Netzwerk (LAN) darstellen.

Nord-Süd-Verkehr bezieht sich auf Client-Server-Verkehr oder auf Datenverkehr, der zwischen einem Rechenzentrum und einem Standort außerhalb des Rechenzentrums (externe Netzwerke) stattfindet. Vertikale Linien in den Diagrammen beschreiben in der Regel diese Art von Netzwerkverkehr. Der „Distributed Logical Router“ (DLR) ist ein virtueller Router, der statische Routen und dynamische Routing-Protokolle wie OSPF, IS-IS oder BGP nutzen kann.

Der Begriff „Mandant“ bezeichnet einen Kunden oder eine Organisation, die Zugriff auf eine isolierte, sichere Umgebung erhält, die von einem Managed Services Provider (MSP) bereitgestellt wird. Eine große Organisation kann eine Multi-Tenant-Architektur nutzen, von jeder Abteilung wird ein Mandant betrachtet. VMware NSX kann besonders nützlich sein, um Infrastruktur as a Service (IaaS) bereitzustellen.

Routing in NSX-v

NSX für VMware vSphere nutzt DLR (Distributed Logical Router) und zentralisiertes Routing. Auf jedem Hypervisor befindet sich ein Routing-Kernelmodul, über das das Routing zwischen logischen Schnittstellen (LIFs) auf dem verteilten Router durchgeführt wird.

Betrachten wir zum Beispiel das typische Routing-Schema für NSX-v, wenn Sie über drei Segmente verfügen: VMs, auf denen Datenbanken laufen, VMs, auf denen Anwendungsserver laufen, und VMs, auf denen Webserver laufen. Die VMs dieser Segmente (himmelblau, grün und tiefblau) sind mit einem verteilten logischen Router (DLR) verbunden, der wiederum über Edge-Gateways (NSX Edge) mit externen Netzwerken verbunden ist.

Wenn Sie mit mehreren Mandanten arbeiten, können Sie eine mehrstufige NSX-Edge-Architektur verwenden, oder jeder Mandant kann über einen eigenen dedizierten DLR und eine eigene Controller-VM verfügen, wobei sich Letztere im Edge-Cluster befindet. Das NSX-Edge-Gateway verbindet isolierte Stub-Netzwerke mit Netzwerken, die man teilt (Uplink), indem es gängige Gateway-Dienste wie DHCP, VPN, NAT, dynamisches Routing und Lastenausgleich bereitstellt. Zu den gängigen Bereitstellungen von NSX Edge gehören die DMZ, VPN-Extranets und mandantenfähige Cloud-Umgebungen, in denen NSX Edge für jeden Mandanten virtuelle Grenzen schafft.

Wenn Sie Datenverkehr von einer VM, die sich im Segment A (blau) des ersten Mandanten befindet, an das Segment A des zweiten Mandanten übertragen müssen, muss der Datenverkehr das NSX Edge-Gateway passieren. In diesem Fall findet kein verteiltes Routing statt, da der Datenverkehr den einzigen Knotenpunkt passieren muss, nämlich das festgelegte NSX Edge-Gateway.

Anhand des Schemas können Sie auch die Funktionsweise erkennen, nach der die Komponenten in Cluster unterteilt sind: Management-Cluster, Edge-Cluster und Compute-Cluster. In diesem Beispiel verwendet jeder Cluster zwei ESXi-Hosts. Wenn zwei VMs auf demselben ESXi-Host laufen, aber zu unterschiedlichen Netzwerksegmenten gehören, wird der Datenverkehr über das NSX Edge-Gateway geleitet, das sich auf einem anderen ESXi-Host des Edge-Clusters befindet. Nach dem Routing muss dieser Datenverkehr zurück an den ESXi-Host übertragen werden, auf dem die Quell- und Ziel-VMs ausgeführt werden.

Der Übertragungsweg des Datenverkehrs ist in diesem Fall nicht optimal. Die Vorteile des verteilten Routings im Multi-Tenant-Modell mit Edge-Gateways können nicht genutzt werden, was zu einer höheren Latenz Ihres Netzwerkverkehrs führt.

Routing in NSX-T

NSX-T verwendet ein zweistufiges verteiltes Routing-Modell, um die oben erläuterten Probleme zu lösen. Sowohl Tier0 als auch Tier1 werden auf den Transport-Knoten erstellt, wobei Letzteres nicht zwingend erforderlich ist, sondern der Verbesserung der Skalierbarkeit dient.

Der Datenverkehr wird über den optimalsten Pfad übertragen, da das Routing dann auf dem ESXi- oder KVM-Hypervisor erfolgt, auf dem die VMs laufen. Der einzige Verwendungsfall, in dem ein fester Routing-Punkt verwendet werden muss, ist das Verbinden mit externen Netzwerken. Auf Servern, auf denen Hypervisoren laufen, werden separate Edge-Knoten bereitgestellt.

Zusätzliche Dienste wie BGP, NAT und Edge-Firewall können auf Edge-Knoten aktiviert werden, die wiederum zu einem Cluster zusammengefasst werden können, um die Verfügbarkeit zu verbessern. Darüber hinaus bietet NSX-T auch eine schnellere Fehlererkennung. Einfach ausgedrückt ist die beste Methode zur Verteilung des Routings das Routing innerhalb der virtualisierten Infrastruktur.

IP-Adressierung für virtuelle Netzwerke

Bei der Konfiguration von NSX-v müssen Sie einen Plan für die IP-Adressierung innerhalb der NSX-Segmente erstellen. In diesem Fall müssen auch logische Transit-Switches hinzugefügt werden, die DLRs und Edge-Gateways verbinden. Wenn Sie eine große Anzahl von Edge-Gateways verwenden, sollten Sie das IP-Adressierungsschema für Segmente erstellen, die durch diese Edge-Gateways verbunden sind.

NSX-T erfordert diese Vorgänge jedoch nicht. Alle Netzwerksegmente zwischen Tier0 und Tier1 erhalten IP-Adressen automatisch. Es werden keine dynamischen Routing-Protokolle verwendet – stattdessen kommen statische Routen zum Einsatz, und das System verbindet die Komponenten automatisch, was die Konfiguration vereinfacht; Sie müssen nicht viel Zeit mit der Planung der IP-Adressierung für Komponenten des Service- (Transit-)Netzwerks aufwenden.

Integration für die Datenverkehrsprüfung

NSX-v bietet die Integration mit Diensten von Drittanbietern wie agentenlosen Antivirenprogrammen, fortschrittlichen Firewalls (Next-Generation-Firewalls), IDS (Intrusion Detection Systems), IPS (Intrusion Prevention Systems) und anderen Arten von Datenverkehrsprüfungsdiensten. Die Integration mit den aufgeführten Arten der Datenverkehrsprüfung erfolgt auf Hypervisor-Kernel-Ebene unter Verwendung eines geschützten „ VMCI “-Busses (Virtual Machine Communication Interface).

NSX-T bietet diese Funktionen derzeit nicht.

Sicherheit

Für NSX-v und NSX-T können verteilte Firewalls auf Kernel-Ebene konfiguriert werden, die auf der Ebene der virtuellen Adapter der VMs arbeiten. Switch-Sicherheitsoptionen sind für beide NSX-Typen verfügbar, die Option “Rate-limit Broadcast & Multicast traffic” ist jedoch nur für NSX-T verfügbar.

Mit NSX-T können Sie Regeln detaillierter anwenden, was zu einer rationelleren Auslastung der Transportknoten führt. Beispielsweise können Sie Regeln auf der Grundlage der folgenden Objekte anwenden: logischer Switch, logischer Port, NSGroup. Diese Funktion kann genutzt werden, um die Konfiguration von Regelsätzen auf den Instanzen des logischen Switches, des logischen Ports oder der NSGroup zu reduzieren und so ein höheres Maß an Effizienz und Optimierung zu erreichen. Sie können zudem Speicherplatz und Regelabfragezyklen einsparen sowie Multi-Tenancy-Bereitstellungen hosten und mandantenspezifische Regeln anwenden (Regeln, die auf die Workloads des jeweiligen Mandanten angewendet werden).

Der Prozess zum Erstellen und Anwenden der Regeln ist bei NSX-v und NSX-T sehr ähnlich. Der Unterschied besteht darin, dass die für NSX-T erstellten Richtlinien an alle Controller gesendet werden, wo die Regeln in IP-Adressen umgewandelt werden, während bei NSX-v die Richtlinien sofort an vShield Firewall Daemon (VSFWD)übertragen werden.

NSX-v vs. NSX-T – Vergleichstabelle

Nachdem Sie nun mit den interessantesten Funktionen von VMware NSX vertraut sind, fassen wir die wichtigsten Funktionen von NSX-v und NSX-T zusammen, die in diesem Blogbeitrag behandelt wurden, und vergleichen sie zusätzlich in der Tabelle.

Fazit

NSX-v ist die optimale Lösung, wenn Sie ausschließlich eine vSphere-Umgebung nutzen, während NSX-T nicht nur für vSphere, sondern auch für Virtualisierungsplattformen wie KVM, Docker, Kubernetes und OpenStack im Rahmen des Aufbaus von Virtuellen Netzwerken eingesetzt werden kann. Es gibt keine allgemeingültige Antwort darauf, welche NSX-Variante besser ist. Ob Sie NSX-v oder NSX-T einsetzen sollten, hängt von Ihren Anforderungen und den jeweiligen Funktionen der beiden NSX-Varianten ab.

Die NSX-Richtlinie ist benutzerfreundlich – Sie müssen nur eine einzige NSX-Lizenz erwerben, unabhängig davon, welche NSX-Variante Sie nutzen möchten. Später können Sie je nach Bedarf NSX-T in einer NSX-v-Umgebung installieren oder umgekehrt und dabei weiterhin Ihre einzige NSX-Lizenz nutzen.

Mit der NSX-Lösung können Sie Ihr eigenes softwaredefiniertes Rechenzentrum mit VMware aufbauen. VMware stellt Ihnen Clustering-Funktionen zur Verfügung, um Betriebskontinuität, Hochverfügbarkeit und Fehlertoleranz zu gewährleisten; dennoch ist eine VM-Sicherung keine überflüssige Maßnahme.

Sichern Sie regelmäßig Ihre Produktions-VMs aus verschiedenen Projekten sowie VMs, die als Komponenten von VMware vSphere und VMware NSX laufen (wie z. B. vCenter, NSX Manager, NSX Controller, NSX Edge), um Ihre Daten zu schützen. NAKIVO Backup & Replication kann Ihnen dabei helfen, die VMware-Backup zu erstellen – zuverlässig und effizient, selbst wenn Sie Cluster einsetzen.

Probieren Sie NAKIVO Backup & Replication aus

Nutzen Sie die kostenlose Testversion, um alle Funktionen der Datensicherheit der Lösung kennenzulernen. 15 Tage kostenlos. Keine Einschränkungen hinsichtlich Funktionen oder Kapazitäten. Keine Kreditkarte erforderlich.

Kostenlos testen