Virtualisierung hat revolutionäre Veränderungen in der Art und Weise gebracht, wie Rechenzentren gebaut werden. Die Mehrheit der modernen Rechenzentren verwendet Hardware-Virtualisierung und setzt physische Server als Hypervisoren ein, um virtuelle Maschinen auf diesen Servern 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 werden in der IT-Branche hoch geschätzt. Der VMware ESXi Hypervisor und VMware vCenter sind weit verbreitete Komponenten der VMware vSphere Virtualisierungslösung.
Das Netzwerk ist eine entscheidende Komponente jedes Rechenzentrums, einschließlich virtualisierter Rechenzentren. Wenn Sie große Netzwerke und komplexe Netzwerkkonfigurationen für Ihr virtualisiertes Rechenzentrum benötigen, sollten Sie 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 Dienstleister schnell auf sich ändernde Geschäftsanforderungen reagieren können. VMware kümmert sich um seine Kunden und bietet die VMware NSX-Lösung für den Aufbau von softwaredefinierten Netzwerken an. Der heutige Blogbeitrag behandelt VMware NSX und untersucht den Unterschied zwischen VMware NSX-v und VMware NSX-T.
Was ist VMware NSX und wie kann es verwendet werden?
VMware NSX ist eine Netzwerkvirtualisierungslösung, die es ermöglicht, Software-definierte Netzwerke in virtualisierten Rechenzentren aufzubauen. Genau wie VMs von der physischen Serverhardware abstrahiert sind, werden virtuelle Netzwerke einschließlich Switches, Ports, Router, Firewalls usw. im virtuellen Raum konstruiert. Virtuelle Netzwerke werden unabhängig von der zugrunde liegenden Hardware bereitgestellt und verwaltet. Virtuelle Maschinen sind mit virtuellen Ports von virtuellen Switches verbunden; die Verbindung zwischen virtuellen Netzwerken erfolgt mit virtuellen Routern, und Zugriffsregeln werden auf virtuellen Firewalls konfiguriert. Alternativ steht auch die Netzwerklastverteilung zur Verfügung. VMware NSX ist ein Nachfolger von VMware vCloud Networking & Security (vCNS) und Nicira NVP, das 2012 von VMware übernommen wurde.
Mikrosegmentierung
Bei der Verwendung eines traditionellen Ansatzes zur Konfiguration des Zugriffs zwischen mehreren Netzwerken in einer virtuellen Umgebung wird in der Regel ein physischer Router oder ein Edge-Gateway, das auf einer VM ausgeführt wird, eingesetzt, obwohl dieser Ansatz nicht besonders schnell oder bequem ist. VMware hat das Konzept der Mikrosegmentierung in NSX umgesetzt, indem eine verteilte Firewall in das Herz des Hypervisors integriert wurde. Sicherheitsrichtlinien, Netzwerkinteraktionsparameter für IP-Adressen, MAC-Adressen, VMs, Anwendungen und andere Objekte werden alle in dieser verteilten Firewall festgelegt. Die Regeln können mithilfe solcher Objekte wie Active Directory-Benutzer und -Gruppen konfiguriert werden, wenn NSX innerhalb Ihres Unternehmens bereitgestellt wird, in dem ein Active Directory Domain Controller (ADDC) verwendet wird. Jedes Objekt kann als Mikrosegment in seinem eigenen Sicherheitsperimeter des entsprechenden Netzwerks betrachtet werden, das eine eigene DMZ (demilitarisierte Zone) hat.
Die verteilte Firewall ermöglicht es Ihnen, virtuelle Rechenzentrumseinheiten wie virtuelle Maschinen zu segmentieren. Die Segmentierung kann auf VM-Namen und -attributen, Benutzeridentität, vCenter-Objekten wie Rechenzentren und Hosts oder auf traditionellen Netzwerkattributen wie IP-Adressen, Portgruppen usw. basieren.
Das Edge Firewall-Komponente hilft Ihnen, wichtige Perimeter-Sicherheitsanforderungen zu erfüllen, wie z.B. das Erstellen von DMZs auf der Basis von IP/VLAN-Konstrukten, die Isolation von Mieter zu Mieter in mehrfach vermieteten virtuellen Rechenzentren, Network Address Translation (NAT), Partner (Extranet) VPNs und benutzerbasierte SSL VPNs.
Wenn eine VM von einem Host auf einen anderen migriert wird – von einem Subnetz in ein anderes – werden die Zugriffsregeln und Sicherheitsrichtlinien gemäß dem neuen Standort übernommen. Wenn ein Datenbankserver auf einer migrierten VM läuft, werden die Regeln, die für diese VM in der Firewall festgelegt wurden, auch nach der Migration auf einen anderen Host oder in ein anderes Netzwerk weiterhin für diese VM funktionieren, was es dem Datenbankserver ermöglicht, auf den Anwendungsserver zuzugreifen, der auf der VM läuft, die nicht migriert wurde. Dies ist ein Beispiel für verbesserte Flexibilität und Automatisierung in Aktion bei der Verwendung von VMware NSX. NSX kann insbesondere für Cloud-Anbieter und große virtuelle Infrastrukturen nützlich sein. VMware bietet zwei Arten der NSX-Software-definierten Netzwerkplattform – 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 spezifisch für vSphere-Hypervisorumgebungen und wurde vor NSX-T entwickelt.
NSX-T (NSX-Transformers) wurde für verschiedene Virtualisierungsplattformen und Multi-Hypervisor-Umgebungen entwickelt und kann auch in Fällen verwendet 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 den Netzwerkvirtualisierungs-Stack für KVM, Docker, Kubernetes und OpenStack sowie AWS-native Workloads. VMware NSX-T kann ohne einen vCenter Server bereitgestellt werden und wird für heterogene Computersysteme übernommen.
Die Hauptanwendungsszenarien für die Verwendung von NSX-v sind in der untenstehenden Tabelle aufgeführt. Die Tabelle ist in drei Zeilen unterteilt, von denen eine die Szenarienkategorie beschreibt. Szenarien für die Verwendung von NSX-T sind mit fett gedruckt.
| Sicherheit | Automatisierung | Anwendungsbeständigkeit |
| Mikrosegmentierung | IT-Automatisierung | Desasterwiederherstellung |
| Sicherer Endbenutzer | Entwickler-Cloud | Mehrrechenzentren-Pooling |
| DMZ überall | Mehrmandanten-Infrastruktur | Multi-Cloud |
NSX-Komponenten
Die Hauptkomponenten von VMware NSX sind der NSX-Manager, die NSX-Controller und die NSX-Edge-Gateways.
NSX-Manager ist eine zentrale Komponente von NSX, die zur Verwaltung von Netzwerken verwendet wird. NSX-Manager kann als VM auf einem der von vCenter verwalteten ESXi-Server bereitgestellt werden (aus einer OVA-Vorlage). In Fällen, in denen NSX-v verwendet wird, kann NSX-Manager nur mit einem vCenter-Server arbeiten, während NSX-Manager für NSX-T als ESXi-VM oder KVM-VM bereitgestellt werden kann und gleichzeitig mit mehreren vCenter-Servern arbeiten kann.
NSX-Manager für vSphere basiert auf dem Photon OS (ähnlich wie die vCenter Server Appliance).
NSX-T-Manager läuft auf dem Ubuntu-Betriebssystem.
NSX-Controller. Der NSX-Controller ist ein verteiltes State-Management-System, das zur Überlagerung von Transporttunneln und zur Steuerung virtueller Netzwerke verwendet wird und als VM auf ESXi- oder KVM-Hypervisoren bereitgestellt werden kann. Der NSX-Controller steuert alle logischen Schalter im Netzwerk und verarbeitet Informationen über VMs, Hosts, Schalter und VXLANs. Durch drei Controller-Knoten wird die Datenredundanz im Falle eines Ausfalls eines NSX-Controller-Knotens sichergestellt.
NSX Edge ist ein Gateway-Dienst, der Zugriff auf physische und virtuelle Netzwerke für VMs bietet. NSX Edge kann als verteilter virtueller Router oder als Services-Gateway installiert werden. Die folgenden Dienste können bereitgestellt werden: Dynamische Routen, Firewalls, Netzwerkadressübersetzung (NAT), Dynamisches Hostkonfigurationsprotokoll (DHCP), Virtuelles privates Netzwerk (VPN), Lastenausgleich und hohe Verfügbarkeit.
Bereitstellungsoptionen
Das Konzept der Bereitstellung ist für NSX-v und NSX-T recht ähnlich. Sie sollten die folgenden Schritte für die Bereitstellung von NSX durchführen:
- Deployen Sie NSX Manager als VM auf einem ESXi-Host mithilfe eines virtuellen Geräts. Stellen Sie sicher, dass NSX Manager auf vSphere vCenter registriert ist (für NSX-v). Wenn Sie NSX-T verwenden, kann NSX Manager als virtuelles Gerät auf einem KVM-Host bereitgestellt werden, da VMware NSX-T die Erstellung eines Clusters von NSX Managern ermöglicht.
- Deployen Sie drei NSX-Controller und erstellen Sie einen NSX-Controller-Cluster.
- Installieren Sie VIBs (Kernelmodule) auf ESXi-Hosts, um eine verteilte Firewall, vert
- Installieren Sie NSX Edge als VM auf ESXi (für NSX-v und NSX-T). Wenn Sie NSX-T verwenden und keine Möglichkeit besteht, Edge als virtuelle Maschine auf ESXi zu installieren, kann Edge auf einem physischen Server bereitgestellt werden. Die Installation 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 vorher die Hardwarekompatibilitätsliste (wichtig für CPUs und NICs).
NSX Common Capabilities
Es gibt eine Reihe von Fähigkeiten, die für beide NSX-Typen verfügbar sind.
Die gemeinsamen Fähigkeiten für NSX-v und NSX-T sind:
- Softwarebasierte Netzwerkvirtualisierung
- Softwarebasierte Überlagerung
- Verteiltes Routing
- Verteilte Firewall
- API-gesteuerte Automatisierung
- Detaillierte Überwachung und Statistiken
Beachten Sie, dass die APIs für NSX-v und NSX-T unterschiedlich sind.
Lizenzierung
Die Lizenzierung ist für beide NSX-Typen gleich, da sie Ihnen mehr Flexibilität und Universalität bietet. Sie können zum Beispiel eine Lizenz für die Verwendung von NSX für vSphere bestellen, und wenn Sie Änderungen in Ihrer Infrastruktur vornehmen und NSX-T bereitstellen müssen, können Sie die für ESXi-v erworbene Lizenz verwenden. NSX ist NSX – es gibt keine Unterscheidung von der Lizenzseite, da die Lizenzierungsausgaben ebenfalls gleich sind.
Überlagerungskapselung
Der VXLAN-Header besteht aus den folgenden Teilen.
8 Bits werden für Flags verwendet. Das I-Flag muss auf 1 gesetzt sein, um eine gültige VXLAN-Netzwerk-ID (VNI) zu erstellen. Die anderen 7 Bits sind reservierte R-Felder, die beim Senden auf Null gesetzt sein müssen. Die auf Null gesetzten R-Felder werden beim Empfang ignoriert.Die VXLAN Network Identifier (VNI), auch als VXLAN Segment ID bekannt, ist ein 24-Bit-Wert, der verwendet wird, um das individuelle Overlay-Netzwerk zu bestimmen, das für die Kommunikation von VMs untereinander verwendet wird.
Reservierte Felder (24 Bit und 8 Bit) müssen auf Null gesetzt und beim Empfang ignoriert werden.
GENEVE. Der GENEVE-Header ähnelt stark dem VXLAN und hat folgende Struktur:
Variable Längenoptionen sind verfügbar, um zukünftige Innovationen zu ermöglichen.
- Die Größe des GENEVE-Headers ist variabel.
NSX-T verwendet GENEVE ( GE nericN EtworkV irtualizationE ncapsulation) als Tunnelprotokoll, das traditionelle Offload-Fähigkeiten, die auf NICs (Network Interface Controllers) verfügbar sind, für die beste Leistung erhält. Zusätzliche Metadaten können zu Overlay-Headern hinzugefügt werden und ermöglichen die Verbesserung der Kontextunterscheidung zur Verarbeitung von Informationen wie End-to-End-Telemetrie, Datenverfolgung, Verschlüsselung, Sicherheit usw. auf der Datenübertragungsebene. Zusätzliche Informationen in den Metadaten werden TLV (Type, Length, Value) genannt. GENEVE wurde von VMware, Intel, Red Hat und Microsoft entwickelt. GENEVE basiert auf den besten Konzepten der VXLAN-, STT- und NVGRE-Encapsulation-Protokolle. - Die VXLAN Network Identifier (VNI), die auch als VXLAN Segment ID bekannt ist, ist ein 24-Bit-Wert, der verwendet wird, um das individuelle Overlay-Netzwerk zu bestimmen, das für die Kommunikation von VMs untereinander genutzt wird.
- Reservierte Felder (24-Bit und 8-Bit) müssen auf Null gesetzt und beim Empfang ignoriert werden.
A size of the VXLAN header is fixed and is equal to 8 bytes. Using Jumbo frames with MTU set to 1600 bytes or more is recommended for VXLAN.
GENEVE. Der GENEVE-Header ähnelt stark VXLAN und hat folgende Struktur:
- A compact tunnel header is encapsulated in UDP over IP.
- A small fixed tunnel header is used to provide control information, as well as a base level of functionality and interoperability.
- Variable Längenoptionen sind verfügbar, um zukünftige Innovationen zu ermöglichen.
Die Größe des GENEVE-Headers ist variabel.
NSX-T verwendet GENEVE (GEneric NEtwork Virtualization Encapsulation) als Tunnelprotokoll, das herkömmliche Offload-Fähigkeiten, die auf NICs (Network Interface Controllers) verfügbar sind, zur optimalen Leistung beibehält. Zusätzliche Metadaten können zu Overlay-Headern hinzugefügt werden und ermöglichen eine verbesserte Kontextdifferenzierung zur Verarbeitung von Informationen wie End-to-End-Telemetrie, Datennachverfolgung, Verschlüsselung, Sicherheit usw. auf der Datentransferebene. 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 VXLAN-, STT- und NVGRE-Encapsulation-Protokolle.
Der MTU-Wert für Jumbo-Frames muss bei der Verwendung der GENEVE-Encapsulation mindestens 1700 Bytes betragen, was durch das zusätzliche Metadatenfeld variabler Länge für GENEVE-Header verursacht wird (wie Sie sich erinnern, wird eine MTU von 1600 oder höher für VXLAN verwendet).
NSX-v und NSX-T sind aufgrund des in diesem Abschnitt erklärten Unterschieds in der Overlay-Encapsulation nicht kompatibel.
Layer-2 Networking
Nun wissen Sie, wie virtuelle Layer-2-Ethernet-Frames über IP-Netzwerke verpackt werden. Daher ist es an der Zeit, die Implementierung virtueller Layer-2-Netzwerke für NSX-v und NSX-T zu erkunden.
Transportknoten und virtuelle Switches
Transportknoten und virtuelle Switches stellen die NSX-Datentransferkomponenten dar.
Transportknoten (TN) ist das NSX-kompatible Gerät, das am Datenverkehr und am NSX-Netzwerk-Overlay teilnimmt. Ein Knoten muss einen Hostswitch enthalten, um als Transportknoten dienen zu können.
NSX-v erfordert die Verwendung des vSphere Distributed Virtual Switch (VDS) wie üblich in vSphere. Standard-Virtual-Switches können nicht für NSX-v verwendet werden.
NSX-T setzt voraus, dass Sie einen NSX-T Distributed Virtual Switch (N-VDS) bereitstellen. Open vSwitches (OVS) werden für KVM-Hosts verwendet, und VMware vSwitches werden für ESXi-Hosts verwendet, um diesen Zweck zu erfüllen.
N-VDS (virtual distributed switch that is previously known as a hostswitch) is a software NSX component on the transport node, that performs traffic transmission. N-VDS is the primary component of the transport nodes’ data plane that forwards traffic and owns at least one physical network interface controller (NIC). NSX Switches (N-VDS) of the different transport nodes are independent but can be grouped by assigning the same names for centralized management.
Auf ESXi-Hypervisoren wird N-VDS durch die Verwendung des VMware vSphere Distributed Switch über das NSX-vSwitch-Modul implementiert, das in den Kernel des Hypervisors geladen wird. Auf KVM-Hypervisoren wird der Hostswitch durch das Open-VSwitch- (OVS-)Modul implementiert.
Transportzonen sind sowohl für NSX-v als auch für NSX-T verfügbar. Transportzonen definieren die Grenzen der Verteilung von logischen Netzwerken. Jede Transportzone ist mit ihrem NSX Switch (N-VDS) verknüpft. Transportzonen für NSX-T sind nicht mit Clustern verknüpft.
Es gibt zwei Arten von Transportzonen für VMware NSX-T aufgrund der GENEVE-Verkapselung: Overlay oder VLAN. Was VMware NSX-v betrifft, so definiert eine Transportzone nur die Verteilungsgrenzen von VXLAN.
Logische Switch-Replikationsmodi
Wenn zwei virtuelle Maschinen auf verschiedenen Hosts direkt kommunizieren, wird der unicast-Verkehr im encapsulated-Modus zwischen zwei Endpunkt-IP-Adressen, die den Hypervisoren zugewiesen sind, ausgetauscht, ohne dass geflutet werden muss. Manchmal muss der Layer-2-Netzwerkverkehr, der von einer VM stammt, ähnlich wie der Layer-2-Verkehr in traditionellen physischen Netzwerken geflutet werden, zum Beispiel, wenn ein Sender die MAC-Adresse des Zielnetzwerkinterfaces nicht kennt. Das bedeutet, dass derselbe Verkehr (Broadcast, Unicast, Multicast) an alle VMs gesendet werden muss, die mit demselben logischen Switch verbunden sind. Wenn sich VMs auf verschiedenen Hosts befinden, muss der Verkehr auf diese Hosts repliziert werden. Broadcast-, Unicast- und Multicast-Verkehr wird auch als BUM-Verkehr bezeichnet.
Lassen Sie uns die Unterschiede zwischen den Replikationsmodi für NSX-v und NSX-T betrachten.
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, dasselbe wie bei NSX-v) und Head-Replikation (nicht optimiert).
ARP-Unterdrückung reduziert die Menge des ARP-Broadcast-Verkehrs, der über das Netzwerk gesendet wird, und ist für die Unicast- und Hybrid-Verkehrsreplikationsmodi 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 an eine VM2 sendet, um die MAC-Adresse von VM2 zu erfahren, wird die ARP-Anfrage vom logischen Switch abgefangen. Wenn der Switch bereits den ARP-Eintrag für das Zielnetzwerkschnittstelle von VM2 hat, wird die ARP-Antwort vom Switch an VM1 gesendet. Andernfalls sendet der Switch die ARP-Anfrage an einen NSX-Controller. Wenn der NSX-Controller Informationen über die VM-IP-zu-MAC-Bindung enthält, sendet der Controller eine Antwort mit dieser Bindung und dann sendet der logische Switch die ARP-Antwort an VM1. Wenn es auf dem NSX-Controller keinen ARP-Eintrag gibt, wird die ARP-Anfrage auf dem logischen Switch erneut ausgebreitet.
NSX Layer 2 Bridging
Layer 2 Bridging ist nützlich, um Workloads von Overlay-Netzwerken auf VLANs zu migrieren oder Subnetze über physische und virtuelle Workloads aufzuteilen.
NSX-v: Dieses Feature funktioniert auf Kernel-Ebene eines Hypervisors, auf dem eine Control-VM ausgeführt wird.
NSX-T: Ein separates NSX-Bridge-Knoten wird zu diesem Zweck erstellt. NSX-Bridge-Knoten können zu Clustern zusammengefasst werden, um die Fehlertoleranz der gesamten Lösung zu verbessern.
In der NSX-v Control VM wurde Redundanz durch Verwendung des Hochverfügbarkeits (HA) Schemas implementiert. Eine VM-Kopie ist aktiv, während die zweite VM-Kopie im Stand-by ist. Wenn die aktive VM ausfällt, kann es einige Zeit dauern, bis die VMs gewechselt und die Stand-by VM geladen werden, um sie aktiv zu machen. NSX-T hat diesen Nachteil nicht, da ein fehlertoleranter Cluster anstelle des Active/Stand-by-Schemas für HA verwendet wird.
Das Routingmodell
In Fällen, in denen Sie VMware NSX verwenden, werden die folgenden Begriffe verwendet:
Der Ost-West-Verkehr bezieht sich auf die Datenübertragung innerhalb des Rechenzentrums. Dieser Name wird für diese besondere Art von Verkehr verwendet, da horizontale Linien auf Diagrammen in der Regel den lokalen Bereichsnetzwerk (LAN)-Verkehr darstellen.
Der Nord-Süd-Verkehr bezieht sich auf den Client-Server-Verkehr oder den Verkehr, der zwischen einem Rechenzentrum und einem Ort außerhalb des Rechenzentrums (externen Netzwerken) stattfindet. Vertikale Linien auf Diagrammen beschreiben in der Regel diese Art von Netzwerkverkehr.
Ein verteilter logischer Router (DLR) ist ein virtueller Router, der statische Routen und dynamische Routing-Protokolle wie OSPF, IS-IS oder BGP verwenden kann.
Ein Mieter bezieht sich auf einen Kunden oder eine Organisation, die Zugang zu einer isolierten sicheren Umgebung erhält, die von einem Managed Service Provider (MSP) bereitgestellt wird. Eine große Organisation kann die Multi-Tenant-Architektur nutzen, indem sie jedes Abteilung als einen einzelnen Mieter betrachtet. VMware NSX kann besonders nützlich sein, um Infrastruktur als Dienstleistung (IaaS) bereitzustellen.
Routing in NSX-v
NSX für vSphere verwendet DLR (verteilter logischer Router) und zentrales Routing. Auf jedem Hypervisor befindet sich ein Routing-Kernelmodul, auf dem 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 eine Gruppe von drei Segmenten haben: VMs, die Datenbanken ausführen, VMs, die Anwendungsserver ausführen, und VMs, die Webserver ausführen. 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 Mietern arbeiten, können Sie eine mehrstufige NSX Edge-Konstruktion verwenden oder jeder Mieter kann über seinen eigenen dedizierten DLR und Controller-VM verfügen, wobei letztere im Edge-Cluster liegen. Das NSX Edge-Gateway verbindet isolierte Stub-Netzwerke mit gemeinsamen (Uplink)-Netzwerken, indem es gemeinsame Gateway-Dienste wie DHCP, VPN, NAT, dynamisches Routing und Lastausgleich bereitstellt. Zu den häufigen Bereitstellungen von NSX Edge gehören in der DMZ, VPN-Extranets und Multi-Tenant-Cloud-Umgebungen, in denen das NSX Edge virtuelle Grenzen für jeden Mieter schafft.
Wenn Sie den Datenverkehr von einer VM, die sich in Segment A des ersten Mieters befindet, auf Segment A des zweiten Mieters übertragen müssen, muss der Datenverkehr das NSX Edge-Gateway passieren. In diesem Fall gibt es kein verteiltes Routing, da der Datenverkehr den einzigen Punkt passieren muss, der das festgelegte NSX Edge-Gateway ist.
Sie können auch das Arbeitsprinzip im Schema sehen, in dem die Komponenten in Cluster unterteilt sind: Management-Cluster, Edge-Cluster und Compute-Cluster. In diesem Beispiel verwendet jeder Cluster 2 ESXi-Hosts. Wenn zwei VMs auf demselben ESXi-Host laufen, aber verschiedenen Netzwerksegmenten angehö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 Weg der Datenübertragung ist in diesem Fall nicht optimal. Die Vorteile, die für verteiltes Routing im Multi-Tenant-Modell mit Edge-Gateways zur Verfügung stehen, können nicht genutzt werden, was zu einer größeren Latenz für Ihren Netzwerkverkehr führt.
Routing in NSX-T
NSX-T verwendet ein Zwei-Tier-Verteilungsmodell zur Lösung der oben erklärten Probleme. Sowohl Tier0 als auch Tier1 werden auf den Transportknoten erstellt, wobei letzteres nicht erforderlich ist, aber zur Verbesserung der Skalierbarkeit vorgesehen ist.
Der Datenverkehr wird über den optimalsten Pfad übertragen, da das Routing dann auf dem ESXi- oder KVM-Hypervisor durchgeführt wird, auf dem die VMs ausgeführt werden. Der einzige Fall, in dem ein fester Routingpunkt verwendet werden muss, ist die Verbindung zu externen Netzwerken. Auf Servern, die Hypervisoren ausführen, sind 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 zur Verbesserung der Verfügbarkeit kombiniert werden können. Darüber hinaus bietet NSX-T auch eine schnellere Fehlererkennung. Einfach ausgedrückt ist das beste Mittel 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 IP-Adressierungsplan innerhalb der NSX-Segmente erstellen. Transit-Logische Switches, die DLRs und Edge-Gateways verbinden, müssen in diesem Fall ebenfalls hinzugefügt werden. Wenn Sie eine hohe Anzahl von Edge-Gateways verwenden, sollten Sie das IP-Adressierungsschema für Segmente erstellen, die von diesen Edge-Gateways verbunden sind.
NSX-T erfordert jedoch diese Operationen nicht. Alle Netzwerksegmente zwischen Tier0 und Tier1 erhalten automatisch IP-Adressen. Es werden keine dynamischen Routingprotokolle verwendet – stattdessen werden statische Routen verwendet und ein System verbindet die Komponenten automatisch, was die Konfiguration erleichtert. Sie müssen keine Zeit damit verbringen, die IP-Adressierung für Service- (Transit-)Netzwerkkomponenten zu planen.
Integration für Verkehrsinspektion
NSX-v bietet Integration in Dienste von Drittanbietern wie agentenlose Antivirensoftware, erweiterte Firewalleinrichtungen (Next Generation Firewalls), IDS (Intrusion Detection Systems), IPS (Intrusion Prevention Systems) und andere Arten von Verkehrsinspektionsdiensten. Die Integration in aufgeführte Arten von Verkehrsinspektion erfolgt auf der Hypervisor-Kernel-Ebene unter Verwendung eines geschützten VMCI-Busses (Virtual Machine Communication Interface).
NSX-T bietet diese Fähigkeiten derzeit nicht.
Sicherheit
Kernelfunktionen verteilter Firewalls können für NSX-v und NSX-T auf der Ebene virtueller VM-Adapter konfiguriert werden. Sicherheitsoptionen für Switches sind für beide NSX-Typen verfügbar, aber die Option „Broadcast- & Multicast-Verkehr begrenzen“ ist nur für NSX-T verfügbar.
NSX-T ermöglicht es Ihnen, Regeln in einer feineren Weise anzuwenden, wodurch die Auslastung von Transportknoten rationaler genutzt wird. Beispielsweise können Sie Regeln basierend auf den folgenden Objekten anwenden: logischer Switch, logischer Port, NSGroup. Diese Funktion kann verwendet werden, um die Regelsatzkonfiguration für Instanzen von logischen Switches, logischen Ports oder NSGroups zu reduzieren, um höhere Effizienz- und Optimierungsebenen zu erreichen. Sie können auch Speicherplatz für Skalierung und Regelsuchzyklen sparen, zusätzlich zu Host-Multi-Tenancy-Bereitstellungen, und den Mieter spezifischen Regeln (Regeln, die auf die Workloads des entsprechenden Mieters angewendet werden) anwenden.
Der Prozess der Erstellung und Anwendung der Regeln ist für NSX-v und NSX-T ziemlich ä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 den vShield Firewall-Daemon (VSFWD) übertragen werden.
NSX-v vs NSX-T – Vergleichstabelle
Jetzt, da Sie mit den interessantesten Fähigkeiten von VMware NSX vertraut sind, lassen Sie uns die Hauptmerkmale von NSX-v und NSX-T, die in diesem Blogbeitrag erkundet wurden, zusammenfassen und sie in der Tabelle vergleichen.
NSX-v ist die optimale Lösung, wenn Sie ausschließlich eine vSphere-Umgebung verwenden, während NSX-T nicht nur für vSphere, sondern auch für KVM, Docker, Kubernetes und OpenStack-Virtualisierungsplattformen im Rahmen des Aufbaus virtueller Netzwerke verwendet werden kann. Es gibt keine eindeutige Antwort darauf, welche Art von NSX besser ist. Ob Sie NSX-v oder NSX-T verwenden sollten, hängt von Ihren Bedürfnissen und den Funktionen ab, die jede NSX-Art bietet.
Die NSX-Lizenzpolitik ist benutzerfreundlich – Sie müssen nur eine NSX-Lizenz kaufen, unabhängig von der NSX-Art, die Sie verwenden möchten. Später können Sie NSX-T in einer NSX-v-Umgebung installieren oder umgekehrt, je nach Ihren Bedürfnissen, und weiterhin Ihre einzige NSX-Lizenz verwenden.
Sie können Ihr eigenes softwaredefiniertes Rechenzentrum mit VMware aufbauen, indem Sie die NSX-Lösung verwenden. VMware bietet Ihnen
, um Betriebskontinuität, hohe Verfügbarkeit und Fehlertoleranz sicherzustellen, jedoch wird die VM-Sicherung keine redundante Maßnahme sein. Erstellen Sie regelmäßig Sicherungskopien Ihrer Produktions-VMs, die mit verschiedenen Projekten zusammenhängen, sowie von VMs, die als Komponenten von VMware vSphere und VMware NSX (wie vCenter, NSX Manager, NSX Controller, NSX Edge) ausgeführt werden, um Ihre Daten zu schützen. NAKIVO Backup & Replication kann Ihnen helfen, das VMware-Backup auf zuverlässige und effiziente Weise zu erstellen, selbst wenn Sie Cluster verwenden.
Schlussfolgerung
NSX-v ist die optimalste Lösung, wenn Sie nur eine vSphere-Umgebung verwenden, während NSX-T nicht nur für vSphere, sondern auch für KVM, Docker, Kubernetes und OpenStack-Virtualisierungsplattformen im Rahmen des Aufbaus virtueller Netzwerke verwendet werden kann. Es gibt keine eindeutige Antwort darauf, welche Art von NSX besser ist. Ob Sie NSX-v oder NSX-T verwenden sollten, hängt von Ihren Anforderungen und den Funktionen ab, die jeder NSX-Typ bietet.
Die NSX-Lizenzpolitik ist benutzerfreundlich – Sie müssen nur eine NSX-Lizenz kaufen, unabhängig vom NSX-Typ, den Sie verwenden werden. Später können Sie NSX-T in einer NSX-v-Umgebung installieren oder umgekehrt, je nach Ihren Bedürfnissen, und Ihre einzelne NSX-Lizenz weiterhin verwenden.
Sie können Ihr eigenes softwaredefiniertes Rechenzentrum mit VMware mit der NSX-Lösung erstellen. VMware bietet Ihnen Clustering-Funktionen, um den Betrieb kontinuierlich, hochverfügbar und fehlertolerant zu gewährleisten, wobei die VM-Backup jedoch keine überflüssige Maßnahme darstellt.
Erstellen Sie regelmäßig Backups Ihrer Produktions-VMs, die mit verschiedenen Projekten zusammenhängen, und der VMs, die als Komponenten von VMware vSphere und VMware NSX ausgeführt werden (wie vCenter, NSX Manager, NSX Controller, NSX Edge), um Ihre Daten zu schützen. NAKIVO Backup & Replication kann Ihnen helfen, das VMware-Backup auf zuverlässige und effiziente Weise zu erstellen, auch wenn Sie Cluster verwenden.
Source:
https://www.nakivo.com/blog/nsx-v-vs-nsx-t-comprehensive-comparison/