Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 3
Allgemeines
Dieser Blogpost ist der dritte von insgesamt fünf Teilen, die in den folgenden Wochen veröffentlicht werden. Grundlage für die Beiträge ist ein Whitepaper, welches ich als Nachlese geschrieben habe zu meinem Vortrag auf der CDC 2018, den ich zusammen mit Petra Lipp gehalten habe. Das Whitepaper steht exklusiv für Newsletter-Abonnenten zur Verfügung. Sie können das vollständige Whitepaper als PDF erhalten, wenn Sie sich für unseren Newsletter anmelden. Nach kurzer Zeit taucht ein Overlay auf, in dem Sie sich registrieren können.
Alle fünf Teile
Im folgenden finden Sie Links zu den fünf Beiträgen. Sollte ein Link noch nicht vorhanden sein, liegt es daran, dass er noch nicht veröffentlicht wurde.
Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 1– Architektur und Netzwerk Topologie
Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 2– SDN Deployment und eine Lab-Umgebung mit dem Netzwerk Controller
Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 3– Software Load Balancing
Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 4– RRAS Gateways
Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 5– Zusammenfassung
Software Load Balancing
Im Teil 2 dieser Blogpost Serie haben wir uns mit dem Aufbau einer SDN Lab-Umgebung beschäftigt, dabei als Basiskomponenten einige Netzwerk Controller Instanzen erzeugt und einige Testszenarien zur Netzwerkisolation mit dem VXLAN-Protokoll durchgespielt. Als Deployment Werkzeug haben wir den System Center Virtual Machine Manager (SCVMM) 2016 verwendet und damit PowerShell Skripte ausgeführt, die Microsoft hierfür im SDN Repository auf Github bereitgestellt hat.
In diesem Beitrag wollen wir nun die SDN-Basisinstallation um Software Load Balancer Komponenten erweitern, um unsere Tenant Testsysteme von außen erreichbar zu machen.
Ich gehe im Folgenden davon aus, dass Sie die im Teil 2 beschriebenen Installationsschritte einschließlich der Testszenarien erfolgreich durchgeführt haben.
Die Tools zum Ausrollen der SLB-Komponenten bleiben die gleichen wie für das Deployment der Netzwerk Controller Instanzen, also das PowerShell Skript VMMExpress.ps1 und die dazu passende Konfigurationsdatendatei Fabricconfig.psd1, die wir in einer PowerShell ISE Sitzung mit Administratorrechten auf unserem SCVMM-System SDN-VMM01 nutzen werden.
Service Templates und Skripte für das SLB Deployment
Wie schon die Netzwerk Controller Instanzen werden auch die SLB-Komponenten als Netzwerk Service im VMM erzeugt. Die dafür erforderlichen Service Templates finden wir im aus Github heruntergeladenen Unterverzeichnis VMM\Templates\SLB:
Hier finden wir jetzt nur 2 Production Versionen, eine für Gen1 und eine für Gen2 VMs. Wir werden mit der Version für Gen2 VMs arbeiten.
Ähnlich wie bereits beim Netzwerk Controller können wir diese Template Dateien an unsere Bedürfnisse anpassen. Öffnen Sie die jeweilige XML-Datei (hier: SLB Production Generation 2 VM.xml) in einem XML-Editor (z.B. PowerShell ISE). So können Sie z.B. die Werte für die Anzahl der SLB-Instanzen (VMs), den RAM-Wert, Anzahl virtueller CPUs und die TimeZone ändern:
Für unsere Lab-Umgebung lasse ich die Anzahl der SLB VMs wie vorgegeben auf 3, reduziere aber den RAM-Wert auf 4096, die Anzahl der CPUs je VM auf 2 und setze die Zeitzone auf den Wert 110 (W. Europe Standard Time). Anm.: Eine Tabelle mit den Indexwerten für Zeitzonen finden Sie z.B. hier.
Um die Location Einstellungen der VMs (wie z.B. Tastatur Layout und Datum / Uhrzeit Anzeige in Deutsch) anzupassen, verwende ich wieder die gleiche Unattend.xml Datei wie beim Netzwerk Controller, die ich während des Deployments der Service Templates dem SCVMM „unterjuble“. Die Datei sollte noch in der VMM-Library vom NC-Deployment vorhanden sein.
Nachdem wir das gewünschte Service Templates gegebenenfalls angepasst haben, können wir uns dem eigentlichen Deployment der SLB-VMs zuwenden.
Dazu wechseln wir in das Unterverzeichnis VMM SDN Express und laden die Dateien VMMExpress.ps1 und Fabricconfig.psd1 (in der gleichen Fassung wie für das NC-Deployment – also z.B. Fabricconfig-SDNcloud-Production.psd1) in eine PowerShell ISE Sitzung mit Administratorrechten.
Nun müssen wir die Ablaufsteuerungsschalter in der Fabricconfig.psd1 Datei so anpassen n, dass nur das SLB-Deployment ausgeführt wird (die Schalter finden Sie am Ende der Datei):
################################## # Deoloyment Control Switches ################################## # Do you want to deploy NC DeployNC = $false # DeployNC = $true #Do you want to create NC managed HNVPA and Transit networks. #These are required if SLB and GW needs to be deployed createNCManagedNetworks = $false # createNCManagedNetworks = $true #Do you want to Deploy SLB. Values are $true , $false DeploySLB = $true # DeploySLB = $false #Do you want to deploy GW. Values are $true , $false # DeployGW = $true DeployGW = $false
Speichern Sie die Datei, bevor Sie das Skript VMMExpress.ps1 starten. Falls Sie im Debug Modus arbeiten wollen, setzen Sie zuvor an geeigneten Stellen Breakpoints, um den Ablauf genauer mit zu verfolgen und eventuell eingreifen zu können. Tipps für geeignete Breakpoints finden Sie nachstehend.
.\VMMExpress.ps1 -ConfigurationDataFile .\Fabricconfig-SDNcloud-Production.psd1
Funktion ImportSLBServiceTemplate Zeile 878:
Dies wäre eine geeignete Stelle, um über den Service Designer in das importierte SLB Service Template noch eine eigene Unattend.xml einzubringen. Achtung: Der VMM erzeugt selbst eine Unattend.xml Datei und mischt sie mit der angegebenen benutzerspezifischen Variante später beim Kreieren der VMs zusammen. Wenn es hier zu Konflikten kommt, kann es sein, dass das gesamte Deployment hängen bleibt.
Funktion ConfigureAndDeploySLBService Zeile 917:
if($ServiceUpdate.deploymenterrorlist -ne $null)
Überprüfen Sie, ob die Variable wirklich $null enthält. Nur dann war die Verteilung der SLB VMs auf die Hyper-V Hosts erfolgreich und das Skript kann weiterlaufen. Korrigieren Sie gegebenenfalls das Placement der VMs über den Service Designer in der VMM-Konsole und weisen anschließend der Variablen den Wert $null zu.
Funktion ConfigureAndDeploySLBService Zeile 937:
Hier können Sie im Service Designer der VMM-Konsole nochmals alle Parameter zum Erzeugen der SLB VMs überprüfen.
Post SLB Deployment Schritte
Wenn Sie das Skript VMMExpress.ps1 erfolgreich für die Software Load Balancer (SLBs) ausgeführt haben, finden Sie nun neben den Netzwerk Controller (NC) Komponenten auch die SLB Komponenten als virtuelle Maschinen und Services im VMM:
Notieren Sie sich die IP-Adressen der einzelnen SLBMUX VMs, die sie im logischen Netzwerk Transit beim Deployment erhalten haben (in unserer Lab-Umgebung 10.10.20.xxx). Wir werden diese Informationen später für das Definieren des BGP Peering benötigen.
SLB Service VMs für BGP konfigurieren
Wechseln Sie in der VMM-Konsole in den Fabric Arbeitsbereich und markieren Sie die Kategorie Network Service. Klicken Sie mit der rechten Maustaste auf den Eintrag Network Controller und rufen die Properties auf.
Wechseln Sie in den Network Controller Properties auf die Registerkarte Services und markieren die Load Balancer Role.
Im Feld Associated Service wählen Sie über die Browse… Schaltfläche unseren Software Load Balancer Service aus.
Wählen Sie für das Feld Run As Account einen passenden Account aus (hier: NC_MgmtAdminRAA)
In das Feld SLB Manager VIP tragen Sie die letzte IP-Adresse aus dem vom Skript VMMExpress.ps1 erzeugten IP-Pool des logischen Netzes PrivateVIP ein (hier also: 10.10.30.199).
Selektieren Sie außerdem in der Liste SLBM VIP Pools die IP Pools PublicVIP_IPAddressPool_0 und PrivateVIP_IPAddressPool_0. Diese beiden IP Pools werden dann vom VMM dem SLB Manager zur Verfügung gestellt.
Klicken Sie auf die erste SLB/MUX Instanz SDN-MUXVM01. Geben Sie in das Feld Local ASN eine für Ihre Umgebung geeignete ASN (Autonome System Nummer im Sinne des BGP-Protokolls) ein, hier 65001. Über die Add Schaltfläche fügen Sie nun die Daten des BGP-Routers ein, mit dem diese SLB-Instanz kommunizieren soll. Unser System SDN-DC01 soll ja der BGP-Router werden und er soll die ASN 65000 erhalten. Für die Kommunikation verwenden wir das Transit Netzwerk, in dem das System SDN-DC01 die IP-Adresse 10.10.20.1 besitzt.
Wiederholen Sie diese Schritte für die restlichen SLB-Instanzen.
Damit ist die Konfiguration der SLB Instanzen für BGP abgeschlossen.
Konfiguration des BGP Routers
Bei der Installation unseres Domain Controllers SDN-DC01 haben wir unter anderem bereits die Serverrolle RRAS installiert, aber nicht weiter konfiguriert. Das werden wir nun nachholen, indem wir die BGP-Funktion dieser Serverrolle aktivieren. Dies muss über PowerShell Befehle geschehen.
Führen Sie auf dem SDN-DC01 in einer PowerShell Sitzung mit Administratorberechtigung folgenden Befehl aus:
Add-BgpRouter -BgpIdentifier 10.10.20.1 -LocalASN 65000
Hiermit wird die BGP-Router Funktion aktiviert. Dabei wird auch die lokale ASN (Autonome System Nummer) des BGP-Routers festgelegt. Dies kann ein beliebiger Integer-Wert sein. Üblicherweise werden in SDN-Umgebungen ASNs ab 65000 verwendet, da diese nicht zu Konflikten mit ASNs physischer Geräte führen können. Diese sind typischerweise kleiner 65000.
Als BgpIdentifier geben wir die IP-Adresse des BGP-Routers an – in unserem Fall die Adresse des SDN-DC01 im Transit Netz (also 10.10.20.1).
Jetzt können wir die Peers definieren, die sich mit dem BGP-Router verbinden und Routen austauschen können. Führen Sie für unsere Lab-Umgebung folgende PowerShell Befehle aus. Bitte vergleichen Sie vorher die Kombinationen PeerASN / PeerIPAddress mit den Parametern, die Sie bei der Konfiguration der SLB Service Instanzen weiter oben notiert haben und passen Sie diese gegebenenfalls im nachstehenden PowerShell Skript an:.
Add-BgpPeer -Name MUX001 -LocalIPAddress 10.10.20.1 -PeerIPAddress 10.10.20.101 `-LocalASN 65000 -PeerASN 65001 -OperationMode Mixed -PeeringMode AutomaticAdd-BgpPeer -Name MUX002 -LocalIPAddress 10.10.20.1 -PeerIPAddress 10.10.20.100 `-LocalASN 65000 -PeerASN 65002 -OperationMode Mixed -PeeringMode AutomaticAdd-BgpPeer -Name MUX003 -LocalIPAddress 10.10.20.1 -PeerIPAddress 10.10.20.102 `-LocalASN 65000 -PeerASN 65003 -OperationMode Mixed -PeeringMode Automatic
Warten Sie, bis sich alle Peers mit dem BGP-Router verbunden haben (ConnectivityStatus = Connected). Dies kann unter Umständen geraume Zeit dauern. Den Verbindungsstatus können Sie mit folgendem Kommando prüfen:
Get-BgpPeer
Validierung des Software Load Balancing
Über die SLB-Komponenten wollen wir nun versuchen, unsere Tenant VMs, die wir im Teil 2 erzeugt haben, von außen über das PublicVIP Netz zu kontaktieren.
Dazu müssen wir im PublicVIP Netz für jeden Tenant eine öffentliche IP-Adresse erzeugen und diese dem BGP-Router bekannt machen.
In unserer mit dem SCVMM erzeugten Umgebung müssen wir dazu zunächst ein VIP Template erzeugen, auf dessen Basis wir dann die PublicVIPs definieren können.
Erstellen eines VIP Templates
Wechseln Sie in der VMM Konsole in den Fabric Arbeitsbereich, öffnen die Kategorie Networking und klicken mit der rechten Maustaste auf VIP Templates. Wählen Sie im Kontextmenü Create VIP Template.
Geben Sie einen Namen für das VIP Template ein (z.B. Web VIP Template) sowie die Ports, zwischen denen die Netzwerkdaten ausgetauscht werden sollen (hier: jeweils Port 80). Klicken Sie auf Next.
Wählen Sie als Template Typ Specific und selektieren Sie in der Manufacturer Liste Microsoft sowie in der Model Liste Microsoft Network Controller. Klicken Sie auf Next.
Im Protocol Dialog wählen Sie die Option Custom und geben als Protokoll Name den Text TCP ein. Klicken Sie wieder auf Next.
Die Seite Persistance können wir direkt mit Next überspringen.
Auf der Seite Load Balancing wählen Sie aus der Liste Load Balancing Method den Eintrag Round Robin und klicken dann auf Next.
Die Seite Health Monitors überspringen wir mit Next und gelangen auf die Summary Seite.
Nach dem Klick auf Finish wird nun das VIP Template angelegt.
Erstellen einer öffentlichen virtuellen IP Adresse (PublicVIP) für ein Tenant VM Netz
Um eine PublicVIP für eines unserer Tenant VM Netze zu erstellen, müssen wir die PowerShell verwenden. Führen Sie folgendes Skript aus:
param([Parameter(Mandatory=$false)]# Name of the Network Controller Network Service# This value should be the name you gave the Network Controller service# when you on-boarded the Network Controller to VMM$LBServiceName = „Network Controller“,[Parameter(Mandatory=$false)]# Name of the VM instances to which you want to assign the VIP$VipMemberVMNames = @(„Red-VM01“, „Red-VM02“),[Parameter(Mandatory=$false)]# VIP address you want to assign from the VIP pool.# Pick any VIP that falls within your VIP IP Pool range.$VipAddress = „10.10.50.100“,[Parameter(Mandatory=$false)]# Name of the VIP VM Network$VipNetworkName = „PublicVIP“,[Parameter(Mandatory=$false)]# The name of the VIP template you created via the VMM Console.$VipTemplateName = „Web VIP Template“,[Parameter(Mandatory=$false)]# Arbitrary but good to match the VIP you’re using.$VipName = „Red-VIP“)Import-Module virtualmachinemanager$lb = Get-scLoadBalancer | where { $_.Service.Name -eq $LBServiceName};$vipNetwork = get-scvmnetwork -Name $VipNetworkName;$vipMemberNics = @();foreach ($vmName in $VipMemberVMNames){ $vm = get-scvirtualmachine -Name $vmName; # if ($vm.VirtualNetworkAdapters[0].VMNetwork.ID -ne $vipNetwork.ID) # { # $vm.VirtualNetworkAdapters[0] | set-scvirtualnetworkadapter -VMNetwork $vipNetwork; # } $vipMemberNics += $vm.VirtualNetworkAdapters[0];}$existingVip = get-scloadbalancervip -Name $VipNameif ($existingVip -ne $null){# foreach ($mem in $existingVip.VipMembers)# {# $mem | remove-scloadbalancervipmember;# }$existingVip | remove-scloadbalancervip;}$vipt = get-scloadbalancerviptemplate -Name $VipTemplateName;$vip = New-SCLoadBalancerVIP -Name $VipName -LoadBalancer $lb -IPAddress VipAddress -LoadBalancerVIPTemplate $vipt -FrontEndVMNetwork $vipNetwork -BackEndVirtualNetworkAdapters $vipMemberNics;Write-Output „Created VIP “ $vip;$vip = get-scloadbalancervip -Name $VipName;Write-Output „VIP with members “ $vip;
Anmerkung: Die Parameter dieses Skripts sind so vorbelegt, dass Sie direkt die PublicVIP 10.10.50.100 anlegen können, um ein Load Balancing zwischen den VMs Red-VM01 und Red-VM02 zu definieren.
Analog können Sie auch eine PublicVIP 10.10.50.101 für ein Load Balancing zwischen den Tenant VMs Green-VM01 und Green.VM02 zu definieren.
Mit dem CmdLet Get-SCLoadBalancerVIP können Sie sich nun eine Liste aller definierten PublicVIPs anzeigen lassen.
Load Balancing Test
Nachdem wir nun für die vNets unserer Tenants öffentliche IP-Adressen definiert haben, können wir das Load Balancing einmal ausprobieren.
Starten Sie auf einem System, das Zugriff auf das PublicVIP Netz hat – z.B. unser Domain Controller SDN-DC01 – einen Browser und geben in die Adresszeile http://10.10.50.100 (die VIP des Red Tenants) ein. Sie sollten folgende Anzeige erhalten:
Starten Sie eine weitere Browser Instanz und geben die gleiche Adresse ein. Stellen Sie dabei sicher, dass der Browser Cache leer ist (z.B. durch Beenden der Browser Instanz und Starten einer neuen Browser Sitzung). Ergebnis:
Geben Sie in die Adressleisten der Browser die PublicVIP des Green Tenants ein (http://10.10.50.101) und Sie erhalten folgende Anzeige:
NAT konfigurieren
Bislang können die Tenant VMs nur in ihrem eigenen VMnet kommunizieren. Nachdem wir die SLB-Instanzen konfiguriert haben, können wir ihnen nun auch den Zugriff auf externe Ressourcen per NAT (Netzwerk Address Translation) einrichten.
Wechseln Sie in der VMM-Konsole in den Arbeitsbereich VMs and Services, wählen die Kategorie VM Networks und klicken Sie mit der rechten Maustaste auf das VMnet, für das Sie NAT aktivieren wollen. Rufen Sie die Properties auf.
Wählen Sie die Registerkarte Connectivity. Aktivieren Sie das Kontrollkästchen Connect directly to an additional logical network und wählen Sie darunter die Option Network Address Translation (NAT) – im linken Bereich erscheint dabei ein Reiter für eine weitere Registerkarte Network Address… Stellen Sie sicher, dass im Feld Gateway Device der Network Controller eingestellt ist.
Klicken Sie jetzt auf den neuen Reiter für die Registerkarte Network Address… Im Feld IP Address Pool wählen Sie den PublicVIP_IPAddressPool_0. Das Feld IP Address können Sie freilassen. Vom VMM wird dann eine geeignete IP-Adresse aus dem gewählten Pool eingesetzt. Klicken Sie auf OK.
Zur Kontrolle können Sie nochmals die Properties des VMnets aufrufen. Auf der Registerkarte Network Address ist jetzt das Feld IP Address ausgefüllt (hier: 10.10.50.100).
Jetzt könnten Sie von einer VM im Red VMNet eine externe Webseite aufrufen. In meiner Lab-Umgebung fehlt jedoch die Verbindung zwischen dem PublicVIP Netz und dem öffentlichen Internet. Deshalb können Sie keine externen Ressourcen im Internet ansprechen. Sie können aber beispielsweise versuchen, über die öffentliche VIP eines anderen Tenant Netzes die IIS-Startseite einer VM zu erreichen, z.B
Jetzt können wir auch noch NAT-Regeln für eingehende Netzwerkpakete von unserer öffentlichen IP-Adresse definieren.
Öffnen Sie wieder die Properties des gewünschten Tenant VMnets und wechseln Sie auf die Registerkarte Network Address…
Über die Schaltfläche Add können Sie jetzt Regeln für den eingehenden Netzwerkverkehr konfigurieren. Um z.B. eine Remote Desktop Verbindung (RDP) von einem externen System zum System Red-VM01 herstellen zu können, geben Sie folgende Parameter ein:
Name:
Protocol:
Incoming Port:
Destination IP:
Destination Port:
Geben Sie einen Namen für die eingehende NAT-Verbindung ein, z.B. RDP_Red-VM01
Wählen Sie das Protokoll (TCP oder UDP) der eingehenden Verbindung.
Geben Sie die Portnummer für die eingehenden Netzwerkdaten an, hier 3389
Geben Sie die IP-Adresse der Tenant VM ein, an die die Daten weitergeben werden sollen, z.B. für die Red-VM01 die Adresse 192.168.0.4
Portnummer innerhalb der Tenant VM als Ziel der Datenweiterleitung (RDP-Standard 3389)
Und wenn Sie gerade schon dabei sind, konfigurieren Sie auch gleich eine NAT-Regel für RDP zum System Red-VM02. Diesen Datenverkehr erwarten wir auf dem Port 3390 und leiten ihn an an den Port 3389 der Ziel-VM weiter.
Name:
Protocol:
Incoming Port:
Destination IP:
Destination Port:
Geben Sie den Namen der eingehenden NAT-Verbindung ein, z.B. RDP_Red-VM02
Wählen Sie das Protokoll (TCP oder UDP) der eingehenden Verbindung.
Geben Sie die Portnummer für die eingehenden Netzwerkdaten an, hier 3390
Geben Sie die IP-Adresse der Tenant VM ein, an die die Daten weitergeben werden sollen, z.B. für die Red-VM02 die Adresse 192.168.1.4
Portnummer innerhalb der Tenant VM als Ziel der Datenweiterleitung (RDP-Standard 3389)
Jetzt können Sie von einem System in unserem PublicVIP Netz RDP-Verbindungen zu den Tenant VMs herstellen, z.B. zu Red-VM01:
mstsc /v 10.10.50.100:3389
Für eine RDP-Verbindung zu Red-VM02 geben Sie die in der NAT-Regel hinterlegte Portnummer 3390 an:
mstsc /v 10.10.50.100:3390
Die NAT-Konfiguration und Regeln für ein VMnet können Sie sich auch mit der PowerShell anzeigen lassen:
$vnet = Get-SCVMNetwork -Name „Red VMnet“Write-Output „NAT Connections and Rules for VM Network: $vnet“$NATconn = Get-SCNATConnection -VMNetwork $vnetWrite-Output $NATconn$NATrules = Get-SCNATRule -NATConnection $NATWrite-Output $NATrules
Nächste Schritte
Mit dem erfolgreichen Deployment der Software Load Balancer Komponenten haben wir den zweiten Schritt für den Aufbau unserer Software Defined Networking (SDN) Umgebung vollendet.
Im nächsten Beitrag werden wir unsere Lab-Umgebung um Remote Gateways erweitern, um remote Tenant Netze mit den VMs in unserer SDN-Umgebung zu verbinden.
Bleiben Sie also dran. Es bleibt weiterhin spannend …
