Software-defined networking with VMware NSX – Part 01 – Deployment of a NSX infrastructure

In meiner 3-teiligen Blogserie „Software-defined networking with VMware NSX“ möchte ich euch zeigen, wie man technisch

• VMware NSX in eine vorhandene VMware vSphere Infrastruktur deploy’t
• mittels VMware NSX ein logisches auf VXLAN basierendes isoliertes VM-Netzwerk erstellt
• per VMware NSX ein hochverfügbares virtuelles Edge Services Gateway mit NAT- und Loadbalancer-Funktionalität bereitstellt und konfiguriert

(Wer noch nie etwas mit Software-defined networking zu tun hatte, findet hier eine Erläuterung, was ein sogenanntes „SDN“ ist.)

Zusätzlich zum technischen Deployment dieser Funktionen werde ich die einzelnen Basis“rollen“ und -funktionen der beteiligten NSX-Komponenten in jedem Kapitel beim entsprechenden Schritt erläutern. Wer weiterführende Informationen zu den einzelnen Komponenten und möglichen Konzepten benötigt, wird im VMware® NSX for vSphere (NSX-V) Network Virtualization Design Guide fündig.

Im 1. Teil der Serie möchte ich euch das Deployment der VMware NSX for vSphere Infrastrukturkomponenten näher bringen:

01. Ausgangssituation

„Ich hab da mal was vorbereitet“ würden unsere allseits beliebten Fernsehköche sagen. Damit wir VMware NSX implementieren können, sollten einige Voraussetzungen erfüllt sein bzw. sich ein passendes Design überlegt werden. Ich werde an Hand meines Demosetups aufzeigen, auf welcher Basis wir NSX deployen und was im Setup nicht unbedingt den „Best Practices“ entspricht.

Lt. Best Practice sollten die einzelnen Rollen des Eco-Systems in unterschiedliche vSphere Cluster aufgeteilt werden:

• Compute Cluster: Auf diesem ESXi-Cluster werden die virtuellen Maschinen betrieben
• Auf dem Management Cluster sollten alle benötigten Managementkomponenten (NSX, vCenter etc.) platziert werden. Stand NSX 6.1: nur 3-Node-Cluster supportet, da die 3 benötigten NSX-Controller auf 3 unterschiedlichen Hosts laufen müssen, damit 1 Hostfailure „abgefedert“ werden kann
• Auf dem Edge-Cluster sollten später alle Systeme per NSX ausgerollt werden, die „Logical Routing“ bzw. „NSX Edges“ (quasi die Verbindung zu WAN/Internet) darstellen. Auch wird nach Best-Practice mindestens ein 3-Node-Cluster benötigt. Warum? Die Edge Services Gateway’s können als virtuelle Maschinen ausfallsicher im Active/Standby-Modus deployed werden. Sollte ein ESXi-Host ausfallen, wird gewährleistet, dass auf dem 3. Host sofort wieder VM-Redundanz wiederhergestellt werden kann

VMware NSX vSwitches basieren auf VMware Distributed vSwitches und erweitern diese um entsprechende Funktionen.

Da mir in meinem Demo-Lab nicht die Ressourcen lt. Best-Practices zur Verfügung standen, habe ich folgenden Basissetup gebaut, an Hand dessen ich euch das Deployment von NSX näher bringen möchte (Auf das Bild klicken, um zu vergrößern):

• 1x vCenter Appliance demovc01 für die Verwaltung aller ESXi-Hosts
• 1x Compute Cluster, bestehend aus demoesx01 und demoesx02
• 1x Management & Edge Cluster, bestehend aus demoesx03 und demoesx04 (keine getrennten Cluster, keine 3-Nodes, alle Funktionen möchte ich auf diesem Cluster laufen lassen)
• 1x Disitributed vSwitch „Compute-Office“, über den die ESXi’s des Compute-Clusters mit vCenter und Managementkomponenten sprechen können
• 1x Distributed vSwitch „Management-Office“, über den die ESXi-Hosts des Mgmt/Edge-Clusters mit vCenter und Managementkomponenten sprechen können
• 1x Disitributed vSwitch „Compute“ bzw. „Mgmt-Edge“ auf denen später meine „logischen“ virtuellen Netze ausgerollt werden und laufen sollen
• Hinweis: Das „Management/Office“ Netz werde ich später auch für einen beispielhaften Zugriff über das WAN auf die virtuellen Netzwerke verwenden (über den „Admin-PC“). Sprich: Dieses Netz stellt in meinem Setup sowohl Verwaltungsnetz, sowie später auch das „Internetz“ 😉 dar

Und es kann losgehen…

02. Implementierung des NSX Managers (NSX Management Plane)

Nach dem erfolgreichen Download der VMware NSX Komponenten von der Website, müssen wir im ersten Schritt den NSX Manager auf unser Management (/Edge) Cluster deployen.

Erläuterung – NSX Manager: Virtuelle Appliance für das Management der NSX-Infrastruktur. Der NSX Manager wird am vCenter registriert und die NSX Funktionen können dann über ein vSphere Web Client PlugIn konfiguriert und genutzt werden.

• Download der NSX-Manager-OVA von der VMware Website
• über den WebClient – OVF-Vorlage bereitstellen

• OVA auswählen

• „Zusätzliche Konfigurationsoptionen akzeptieren“

• EULA akzeptieren

• Namen für die NSX-Manager VM vergeben (System im DNS registrieren!)

• Datastore für NSX-Manager auswählen (in meinem Setup habe ich in meinem Mgmt/Edge-Cluster leider nur lokale Datastores, in der Praxis bitte immer auf ein zentrales Storage legen, damit HA die VM schützen kann und per vMotion migriert werden kann)

• Netz angeben, in dem der NSX-Manager mit dem vCenter kommunizieren kann (in meinem Fall „Mgmt-Office“

• Komplexe Kennwörter für den CLI-„localadmin“ und CLI „Privilege-Modus“ vergeben

• Hostname, IP-Adresse, SN und Gateway vergeben

• DNS Server und Search Domain angeben

• Zeitserver angeben und für Notfälle SSH-Zugriff auf den NSX-Manager aktivieren

• alle Einstellungen prüfen – „Nach der Bereitstellung einschalten“ – „Beenden“

• nach erfolgreichem Deployment startet die Appliance an und führt die Grundkonfiguration durch

• nach erfolgreichem Rollout können wir uns per IP-Adress bzw. Hostname (https://NSXMANAGERNAME) auf den NSX-Manager verbinden. Logon: admin und das im Wizard vergebene Kennwort

• über „Manage vCenter Registration“ wechseln wir in das „Manage“ Menü des NSX-Managers

• Über „General“ – „Time Settings“ – „Edit“ können wir einen Zeitserver angeben, Zeitzone und genaue Uhrzeit/Datum anpassen

• über den Menüpunkt „Backups & Restore“ können wir ein Backup der Daten des NSX-Managers konfigurieren (SFTP oder FTP)

• über „NSX Management Service“ – Lookup Service – „Edit“ registrieren wir unseren NSX Management Service am SSO-Dienst des vCenters

• über „NSX Management Service“ – vCenter Server – „Edit“ registrieren wir unseren NSX Management Service am vCenter selbst (in meinem Beispiel verwende ich eine vCenter 5.5 Appliance, somit ist der Logon: root)

• unser „Lookup Service“ und „vCenter Server“ sollten nach erfolgreicher Konfiguration nun im Status „Connected“ stehen

• wir verbinden uns per vSphere WebClient wie gewohnt auf unseren registrierten vCenter (https://VCENTERNAME:9443/vsphere-client)…

• …und finden nun im WebClient einen neuen Reiter „Networking & Security“ über den wir die weitere Konfiguration vornehmen können

03. Rollout des NSX Controller Clusters (NSX Control Plane)

Nach dem erfolgreichen Deployment und der Integration des NSX Managers in den vCenter, können wir über das WebClient PlugIn „Networking & Security“ im nächsten Schritt die NSX Controller auf unser Management Cluster ausrollen.

Erläuterung – NSX Controller: Ein Controller Cluster, bestehend aus 3 aktiven virtuellen Appliances, die für das Management der Switch- („Logical Switching“) und Routingmodule („Logical Routing“) in den Hypervisorn verantwortlich sind.

• über „Networking & Security“ – „Installation“ – „Management“ – NSX Controller-Knoten – „Plus“

• IP-Adresse des NSX Managers, Datacenter, Mgmt-Cluster, Datastore, Host & Ordner angeben, sowie das virtuelle Netz, in das der 1. NSX-Controller deployed werden soll („Mgmt-Office“, da der NSX Controller mit den Management-Komponenten kommunizieren können soll)
• Da wir insgesamt 3 NSX Controller ausrollen müssen, können wir über den Menüpunkt „IP-Pool“ einen neuen IP-Pool festlegen, aus dem beim Deployment der NSX-Controller Appliances automatisch jeweils freie IP-Adressen zugeordnet werden können

• wir legen einen Pool mit statischen IP-Adressen aus dem Management Netz an (sollte bei einem Deployment von 3 NSX Controllern 3 mögliche IP-Adressen beinhalten)

• wir wählen nach erfolgreicher Anlage für unseren 1. Controller den soeben angelegten IP-Pool für die automatische IP-Vergabe aus,…

• …vergeben ein SEHR komplexes Kennwort für einen evtl. benötigten Zugriff auf die NSX-Controller Appliance und starten das Deployment mit „OK“

• die 1. Controller Appliance wird nach unseren Vorgaben ausgerollt und erhält automatisch eine IP-Adresse aus dem angelegten IP-Pool

• sobald die 1. NSX Controller Appliance erfolgreich bereitgestellt wurde, führen wir den gleichen Schritt ein 2. Mal durch, um die 2. NSX Controller Appliance auszurollen (Best Practice: auf den 2. ESXi Host des Mgmt Clusters)

• in diesem Schritt können wir auf den bereits angelegten IP-Pool zurückgreifen

• sobald auch die 2. NSX Controller Appliance erfolgreich bereitgestellt wurde, wiederholen wir das Ganze für den Rollout des 3. NSX Controllers (normalerweise auf einen 3. Host. Da ich in meinem Lab aber nur 2 Hosts besitze, rolle ich noch einmal auf dem gleichen ESXi Host des Mgmt-Clusters aus) und schließen damit die Implementierung der „Control Plane“ von NSX ab

04. Vorbereitung der ESXi Cluster für die Netzwerkvirtualisierung (NSX Data Plane)

Wir haben jetzt unsere Managementoberfläche mit dem NSX Manager und unsere „Intelligenz“ mit den NSX Controllern integriert. Damit unsere ESXi Hosts die „Netzwerkvirtualisierungsfunktionen“ nutzen können, müssen 3 zusätzliche vSphere Installation Bundles (VIB) in den Hypervisor installiert werden.

Erläuterung – Clustervorbereitung: Auf allen Hosts der Cluster werden die VIB’s für „VXLAN“, „Distributed Firewall“ und „Logical Routing“ installiert und registriert. Dies ermöglicht den Hosts, SDN-Funktionen „sprechen“ bzw. verarbeiten zu können.

•  über „Installation“ – „Hostvorbereitung“ – „Installieren“ auf allen Clustern die Hosts für die Netzwerkvirtualisierung vorbereiten

05. Basiskonfiguration des VXLAN Netzwerks

Im letzten Schritt unseres NSX Infrastruktur-Deployments konfigurieren wir die „Rahmenkriterien“ für unsere Netzwerkvirtualisierung, innerhalb derer wir unsere virtuellen Switches, Router, Firewalls, Loadbalancer etc. später ausrollen möchten. Hierfür müssen wir unser VXLAN Netzwerk inkl. VTEP’s, Segment-ID’s und Transport Zone definieren:

 Erläuterung – VXLAN: „L2 over L3 (L2oL3) encapsulation technology“. VXLAN wurde entwickelt, um VLANs zu erweitern. Für diesen Zweck wurde ein Segment mit 24 Bit hinzugefügt, der sogenannte VXLAN Network Identifier (VNI). Somit können an Stelle von maximal 4096 VLAN Netzwerk-IDs beim Einsatz von VXLAN 16 Millionen Netzwerk-IDs verwendet werden. Weitere Informationen siehe z.B.: http://www.searchnetworking.de/definition/Virtual-Extensible-LAN-VXLAN)

Erläuterung – VTEP: Die Quell- und Ziel-IP-Adresse, die im „Outer IP header“ verwendet wird, identifiziert eindeutig welcher ESXi Host die „VXLAN encapsulation“ des Frames erzeugt hat und an welchem ESXi Host diese „encapsulation“ wieder terminiert wird. Diese „Punkte“ werden VXLAN Tunnel EndPoints
(VTEPs) genannt.

Erläuterung – Segment-ID: Ein logisches Netzwerksegment basierend auf einem eindeutigen VXLAN Network Identifier (VNI). Bis zu 16 Millionen logische Netzwerksegmente mit VXLAN möglich („Netzwerksegment“ = „VXLAN Segment“ = „Virtual Network“ = „Logical Switch“). VNI ist vergleichbar mit einer VLAN-ID im VLAN-Networking.

Erläuterung – Transport-Zone: Eine Transportzone definiert, welche ESXi Hosts alle miteinander über eine physikalische Netzwerkinfrastruktur „sprechen“ können. Ein „Logical Switch“ (=“VXLAN Segment“) ist immer Teil einer Transport-Zone. Die Transport-Zone legt somit fest, über welche ESXi-Cluster bzw. Distributed vSwitches sich die „VXLAN Segmente“  (=“Segment-ID’s“) erstrecken können.

•  über den Reiter „Hostvorbereitung“ – VXLAN – „konfigurieren“ können wir unser VXLAN einrichten (1. Schritt – Mgmt Cluster)

• wir wählen im Management / Edge-Cluster den Distributed vSwitch aus, auf dem später die „logischen“ VXLAN Segmente laufen sollen
• wir definieren eine MTU Size von 1600 (Durch die „Kapselung“ des Ethernetframes ist diese Erhöhung empfohlen. Ebenso sollten alle beteiligten physikalischen Interfaces, die sich um das Frame „kümmern“ werden, ebenfalls eine MTU Size von 1600 verwenden)
• wir legen einen neuen IP-Pool an, aus dem unsere ESXi Hosts ihre VTEP-Adresse erhalten sollen (Jeder Host des Clusters bekommt automatisch einen neuen VMkernel mit einer IP-Adresse „verpasst“)

• Netzsegment angeben, dass die Hosts für die Kommunikation untereinander verwenden sollen, inkl. möglicher IP-Adressen

• NIC-Failover-Policy für die VTEP-vmkernel PortGruppe bei Bedarf anpassen (in meinem Fall bleibt „Failover“, da ich in meinem Demo-Lab nur 1 physikalischen Uplink am Distributed vSwitch habe – im Screenshot unter „VTEP: 1“ zu erkennen)

• nach Bestätigung mit „OK“ wird im Hintergrund für jeden Host des ausgewählten Clusters automatisch ein VMkernel deployed und mit einer IP-Adresse aus dem IP-Pool versehen

• über den Reiter „Hostvorbereitung“ – VXLAN – „konfigurieren“ können wir unser VXLAN jetzt auch für unser Compute Cluster einrichten und verwenden den im vorherigen Schritt angelegten IP-Pool (VTEP-Pool)

• im Reiter „Vorbereitung des logischen Netzwerks“ sehen wir unter „VXLAN-Transport“ unsere erstellte Konfiguration

 

• (optional) über die ESX-CLI (per SSH auf einen ESXi-Host) kann per vmkping ++netstack=vxlan IPADRESSE-ANDERER-HOST -s 1572 geprüft werden, ob sich alle Hosts auch mit erhöhter MTU-Size sauber untereinander erreichen können

• im Reiter „Segment-ID“ legen wir über „Bearbeiten“ fest, welche Segment-IDs auf unserer VXLAN-Struktur verwendet werden sollen

• jeder „Logical Switch“ bzw. jedes logische VXLAN-Segment / Netz erhält eine Segment-ID (vergleichbar: jedes logische / isolierte Netzsegment erhält eine VLAN-ID im „klassischen“ Netzwerkmodell). In meinem Lab-Setup reichen mir „vorerst“ 4999 logisch voneinander getrennte Netze aus und es dürfen somit automatisch ID’s aus einem Pool von 5000 bis 9999 vergeben werden 🙂

• über den Reiter „Transportzonen“ legen wir eine neue Transportzone mit Namen Global-Transport-Zone an und legen fest, dass sich unsere geplanten logischen Switches (=logischen Netze = Segment-ID’s) über unser Mgmt/Edge- und über Compute-Cluster erstrecken können

•  …und trotz lauter neuer Begrifflichkeiten und Technologien, vergessen wir nicht, unserem NSX for vSphere über den WebClient im „Licensing“ noch einen entsprechenden Lizenzkey zu verpassen 😉

And that’s it…

 

Im 2. Teil der „Software-defined networking with VMware NSX“ Blogserie möchte ich euch näher bringen, wie einfach es nun ist, auf unserer implementierten Infrastruktur ein neues logisches Netzwerk für virtuelle Maschinen zu erstellen, wie man ein hochverfügbares Edge Services Gateway ausrollt und deren NAT-Funktion nutzen kann.

 

– I wish I could be a Virtual Machine –

Benjamin Ulsamer

Senior Consultant & Trainer

teamix GmbH

 

PS: Wer selbst erste technische Erfahrungen mit VMware NSX machen möchte, aber nicht die Zeit hat, sich eine eigene Lab-Umgebung zu bauen, der kann dies kostenfrei in den VMware Hands-On-Labs tun. Die entsprechenden Labs sind:

• HOL-SDC-1403 – VMware NSX Introduction (Component Overview, Logical Switching, Logical Routing, Distributed Firewall, Edge Services Gateway)
• HOL-SDC-1425 – VMware NSX Advanced (DHCP Relay, Scale Out L3, L2VPN, Trend Micro Integration, Riverbed Integration)

 

Series Navigation

Software-defined networking with VMware NSX – Part 02 – Logical switching and NAT with Edge Services Gateway >>