Sind alle für NSX-T benötigten Komponenten vorhanden, geht es daran, sie zu konfigurieren, um zum Beispiel eine Mikrosegmentierung durchzuführen. Im System-Hauptmenü findet der Administrator unter dem Punkt Quick-Start drei Assistenten, die ihn bei der Einrichtung von NSX-Clustern, Transport Nodes und der VDS-Migration unterstützen. Den NSX-Cluster hatten wir ja bereits installiert, es fehlten aber noch die Netzkonfigurationen für die Transport Nodes. Wir starteten deshalb den Wizard, um die ESXi-Hosts und den Edge Node mit der Overlay-Transport-Zone zu verbinden. Über diese Zone läuft der Management-Verkehr zwischen den am SDDC beteiligten Systemen. Damit über den Edge Node auch eine Kommunikation mit externen Systemen möglich ist, fügten wir diesem die VLAN-Transport-Zone hinzu. Der Wizard installierte nun die NSX-Komponenten auf den zwei ESXi-Hosts und dem Edge Node und richtete auf dem Edge-Knoten die VLAN-Zone ein.
Für die LAN-Kommunikation verwendet NSX-T sogenannte Segmente, also logische Switches, über die VMs auf Layer 2 kommunizieren. Dies funktioniert auch über Transport Nodes hinweg. Jedes Segment ist durch einen VNI (Virtual Network Identifier), der einer VLAN-ID ähnelt, eindeutig gekennzeichnet. Der Datenverkehr läuft über Tunnel-Endpunkte (TEPs), die auf jedem Transport Node vorhanden sind und die Pakete per Geneve-Tunnel (Generic Network Virtualiziation Encapsulation) weiterleiten. Dieser kann dann auf Layer 2 und 3 operieren.
Wir erstellten in der NSX-Konsole ein neues LAN-Segment, das vCenter dann als zusätzliches Netzwerk anzeigte. Damit eine VM dieses Netz verwenden kann, muss es der Administrator in den VM-NIC-Settings hinzufügen. In der NSX-Konsole erzeugten wir zudem ein Tier-1- und ein Tier-0-Gateway und verknüpften diese miteinander.
Wenn zwei VMs aus unterschiedlichen IP-Subnetzen auf demselben Host laufen, erfolgt das Routing zwischen ihnen direkt im Kernel des Hosts. So müssen die Datenpakete nicht erst über das Netz zum Default-Gateway und von dort wieder zurücklaufen. Da sämtliche Switching- und Routing-Funktionen per Software implementiert sind, kann eine IT-Organisation die Netzwerkinfrastruktur, die das Unternehmen benötigt, passgenau abbilden. Um ein mit NSX-T aufgebautes SDDC mit Systemen in der Cloud zu verbinden, bringt die Software den NSX Cloud Service Manager mit. Wir importierten diese VM per OVA-File in unser vCenter.
Cloud-Integration
Ist das Setup abgeschlossen, stellt der Administrator über die Web-Konsole der Cloud-Service-Appliance zunächst eine Verbindung zum NSX Manager her. Die GUI stellt Menüs für AWS und Azure bereit, über die sich NSX-T mit der jeweiligen Cloud-Umgebung verheiraten lässt. Auf der Seite des Cloud-Providers muss man die für die Kommunikation mit dem eigenen RZ erforderlichen Netzwerke und Gateways konfigurieren. Sind alle Voraussetzungen geschaffen, stellt man die Verbindung per Cloud Service Manager her.
Eine sehr weitreichende Integration der VMware-Infrastruktur im eigenen RZ mit Workloads in der Cloud lässt sich erreichen, wenn ein Unternehmen in der Cloud dieselbe Virtualisierungsplattform einsetzt. Dies ist zum Bespiel mit VMware Cloud on AWS möglich, von Microsoft gibt es mit Azure VMware Solution eine ähnliche Lösung.
Leistungsfähige SDDC-Lösung für die hybride Cloud
VMwares Netzwerkvirtualisierungs- und Security-Plattform NSX-T Data Center glänzt mit einem großen Funktionsumfang. Mit ihr lassen sich die mit vSphere betriebenen Ressourcen im eigenen RZ wie auch Workloads in der Cloud von zentraler Stelle aus übergreifend verwalten. Aufgrund der Softwarearchitektur ist es relativ einfach möglich, eine Mikrosegmentierung mit Firewall-Abschottung zu implementieren. Für zusätzliche Sicherheit sorgen zahlreiche integrierte Funktionen wie Malware-Schutz, URL-Filter oder IDS/IPS. Durch die mehrschichtige Netzarchitektur aus LAN-Segmenten, Routing-Services sowie Tier-0- und Tier-1-Gateways lässt sich NSX-T flexibel an unternehmensspezifische Anforderungen anpassen.