Software-defined networking with VMware NSX – Part 03 – Load balancing with Edge Services Gateway

This entry is part 3 of 3 in the series Software-defined networking with VMware NSX

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

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 ersten Teil der „Software-defined networking with VMware NSX“ Blogserie haben wir bereits die NSX Infrastrukturkomponenten implementiert. Im 2. Teil der Serie haben wir zudem ein hochverfügbares Edge Services Gateway und dessen NAT-Funktionalität konfiguriert. Auf Basis dessen möchte ich euch in diesem Artikel zeigen, wie man die Load Balancing Funktion einsetzen kann.

Wo stehen wir? Nach Realisierung der Schritte aus den ersten beiden Blogartikeln der Serie, sieht unsere Umgebung so aus:

01. Ausgangssituation

NSX-Konzept-002417

02. Konfiguration von Load-Balancing im Edge Services Gateway

In diesem Blogartikel erweitern wir das bereits implementierte Edge Services Gateway um die Loadbalancer Funktionalität von NSX.

NSX-Konzept-002418

  • wir klicken doppelt auf unser angelegtes Edge-Services-Gateway
  • im Reiter „Verwalten“- “ Lastausgleichsdienst“ – „Globale Konfiguration“ klicken wir auf „Bearbeiten“,…

NSX-Loadbalancer-001930

  • …aktivieren das Loadbalancing über „Lastenausgleich aktivieren“ und Bestätigen mit „OK“

NSX-Loadbalancer-001931

NSX-Loadbalancer-001932

  • im nächsten Schritt fügen wir über „Anwendungsprofile“ – „+“ ein Anwendungsprofil hinzu

NSX-Loadbalancer-001933

  • in dieser Beispielkonfiguration legen wir uns ein RDP-Profil an (Mögliche Konfigurationen können im NSX Documentation Center unter Create an Application Profile eingesehen werden)

NSX-Loadbalancer-001934

NSX-Loadbalancer-001935

  • im nächsten Schritt legen wir uns über „Dienstüberwachung“ einen Service Monitor an. Dieser überwacht die späteren Server-Member innerhalb des Pools an Hand der eingestellten und definierten Parameter (Einstellungsmöglichkeiten sind im NSX Documentation Center unter Create a Service Monitor einsehbar)

NSX-Loadbalancer-001936

NSX-Loadbalancer-001937

NSX-Loadbalancer-001938

  • im nächsten Schritt legen wir einen Pool an, in dem wir die virtuellen Maschinen angeben, auf die die Last verteilt werden soll und mit welchem Service Monitor der Zustand der Systeme geprüft werden soll
  • unter „Pools“ – „+“ legen wir einen neuen Pool an

NSX-Loadbalancer-001939

  • wir vergeben einen Namen für den Pool, geben den Loadbalancing Algorithmus an und weisen den angelegten Service Monitor zu

NSX-Loadbalancer-001940

  • über „+“ können wir die virtuellen Maschinen hinzufügen, auf die die Last verteilt werden soll

NSX-Loadbalancer-001941

  • wir aktivieren das Mitglied und fügen über „Auswählen“ den demolin06 als 1. Member hinzu

NSX-Loadbalancer-001942

NSX-Loadbalancer-001943

NSX-Loadbalancer-001944

  • da wir beispielhaft RDP-Traffic zwischen demolin06 und demolin05 verteilen wollen, geben wir den Port 3389 an, sowie eine entsprechende Gewichtung, maximale Anzahl, sowie Mindestanzahl an Verbindungen (in diesem Beispiel sehr gering, da ich der einzige Testuser bin 😉 )

NSX-Loadbalancer-001945

  • über „+“ nehmen wir die VM demolin05 als 2. Member mit den entsprechenden identischen Einstellungen in den Pool mit auf

NSX-Loadbalancer-001946

NSX-Loadbalancer-001947

  • mit „OK“ schließen wir die Poolkonfiguration ab

NSX-Loadbalancer-001955

NSX-Loadbalancer-001956

  • in den kommenden Schritten legen wir den virtuellen Server mit der IP an, über die das Loadbalancing funktionieren soll und verknüpfen diesen mit dem angelegten Anwendungsprofil und dem Server-Pool
  • unter „Virtuelle Server“ – „+“ starten wir die Anlage des virtuellen Servers

NSX-Loadbalancer-001957

  • wir weisen unser angelegtes Anwendungsprofil zu und geben über „IP-Adresse auswählen“ an, dass der Loadbalancer „hinter“ der virtuellen IP-Adresse unseres Edge-Services-Gateway im NAT-Network auf die Member des Server-Pools Traffic verteilen soll

NSX-Loadbalancer-001958

NSX-Loadbalancer-001977

  • wir geben den Port 3389 für RDP an und weisen den angelegten RDP_Pool (und die damit verbunden Server-Member, auf die die Last verteilt werden soll) zu

NSX-Loadbalancer-001978

  • unter „Verwalten“ und „NAT“ sehen wir, dass der Loadbalancer automatisch eine DNAT Rule für die IP des Edge Services Gateway angelegt hat (Nr. 1)
  • ein Loadbalancing innerhalb des NAT-Network funktioniert nun: ein Aufbau einer RDP-Verbindung auf die IP des Edge Services Gateway (10.10.10.254) wird im Round-Robin-Verfahren im Wechsel auf demolin05 und demolin05 verteilt

NSX-Loadbalancer-001979

03. Anpassen der vorhandenen DNAT-Rule im Edge Services Gateway auf Loadbalancer Adresse

Um das Loadbalancing von „außen“ nutzen zu können, konfigurieren wir die im 2. Teil der Serie konfigurierte NAT-Rule um, so dass externe Zugriffe nicht direkt auf den demolin06 „übersetzt“ werden, sondern auf die virtuelle IP des Edge-Services Gateway, welches anschließend auf den demolin05 und demolin06 loadbalanced.

NSX-Konzept-002419

  • wir editieren die NAT-Rule Nr. 2 über das „Stift“-Symbol…

NSX-Loadbalancer-001980

  • …und ändern die IP-Adresse des demolin06 auf die IP-Adresse des virtuellen Servers

NSX-Loadbalancer-001981

  • über „Änderungen veröffentlichen“ schalten wir die Konfiguration „scharf“

NSX-Loadbalancer-001982

NSX-Loadbalancer-001983

  • im Reiter „Lastenausgleichsdienst“ – „Pools“ – „Poolstatistik anzeigen“ sehen wir, dass beide Member „up“ sind

NSX-Loadbalancer-001984

NSX-Loadbalancer-001985

  • wir testen die Verbindung von „außen“…

NSX-Loadbalancer-001986

  • …und sehen, dass die RDP-Verbindung erfolgreich auf demolin05 aufgebaut wurde

NSX-Loadbalancer-001987

NSX-Loadbalancer-001988

  • um das Loadbalancing und die Checks zu überprüfen, trennen wir die RDP-Verbindung und fahren die VM demolin05 herunter

NSX-Loadbalancer-001989

  • im Reiter „Lastenausgleichsdienst“ – „Pools“ – „Poolstatistik anzeigen“ sehen wir nun, dass nur noch demolin06 „up“ ist

NSX-Loadbalancer-001990

  • wir testen erneut eine RDP-Verbindung…

NSX-Loadbalancer-001991

  • …und sehen, dass die RDP-Verbindung erfolgreich auf den verbleibenden Member des Server-Pools demolin06 aufgebaut wurde

NSX-Loadbalancer-001992

NSX-Loadbalancer-001993

04. Überwachung der Zugriffe per Flow Monitoring

Wie bereits im 2. Teil der Serie erwähnt, ist in VMware NSX ein Flow Monitoring integriert. Den Traffic der soeben aufgebauten Verbindung würde ich gerne ansehen.

  • im Reiter “Live-Flow” über vNIC “Durchsuchen” unseren demolin06 anwählen, den Live-Monitor “Starten”…

NSX-Loadbalancer-001994

NSX-Loadbalancer-001995

NSX-Loadbalancer-001996

  • …und schon ist auch hier der RDP-Traffic in Richtung demolin06 zu sehen (in unserer derzeitigen Konfiguration von der virtuellen Serveradresse des Edge Services Gateway aus)

NSX-Loadbalancer-001997

  • setzen wir im Pool des Lastausgleichsdienstes den Haken bei „Transparent“…

NSX-Loadbalancer-001998

NSX-Loadbalancer-001999

  • …und starten erneut den Flow Monitor,…

NSX-Loadbalancer-002000

  • …sehen wir die Verbindung der externen IP-Adresse von „außen“ auf unseren demolin06

NSX-Loadbalancer-002001

And that’s it. Ich hoffe, ich konnte euch die Funktionalitäten und Möglichkeiten von VMware NSX in meiner Blogserie etwas näher bringen. Das Produkt bietet noch viele Möglichkeiten und Funktionalitäten mehr. Dies war nur ein kurzer erster Einblick. Interesse? Fragen? Ich stehe jederzeit gerne persönlich zur Verfügung 🙂

 

– 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

Benjamin Ulsamer

Benjamin Ulsamer ist seit Januar 2011 für die Firma teamix GmbH tätig. Seine Kernthemen sind VMware, sowie NetApp (bis 2015). Seit 2005 ist er in sämtlichen Projektgrößen und -komplexitätsstufen als Consultant, Systems Engineer & Trainer unterwegs. Seit 2014 gehören auch Datacenter Produkte rund um die Hersteller Trend Micro & Citrix zu seinem Aufgabengebiet. In den Jahren 2015 & 2016 wurde er für seine Blog-Aktivitäten zum VMware vExpert ernannt.

 
Kommentare

Noch keine Kommentare vorhanden.

Hinterlassen Sie einen Kommentar