Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 4
Allgemeines
Dieser Blogpost ist der vierte 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
RAS Gateways
Im Teil 3 dieser Blogpost Serie haben wir uns mit dem Deployment der Software Load Balancer (SLB)Komponenten in unserer SDN Lab-Umgebung beschäftigt und einige Testszenarien für den Zugriff von außen auf Tenant VMs über die SLBs sowie den Zugriff aufs Internet per NAT aus Tenant VMs 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 unsere SDN Lab-Umgebung um RAS Gateways erweitern, um unsere Tenant Testsysteme von außen erreichbar zu machen.
Ich gehe im Folgenden davon aus, dass Sie die im Teil 2 und Teil 3 beschriebenen Installationsschritte einschließlich der Testszenarien erfolgreich durchgeführt haben.
Die Tools zum Ausrollen der Gateway Komponenten bleiben die gleichen wie für das Deployment der Netzwerk Controller und SLB 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 Gateway Deployment
Wie schon die Netzwerk Controller und SLB Instanzen werden auch die Gateway-Komponenten als Netzwerk Service im VMM erzeugt. Die dafür erforderlichen Service Templates finden wir im aus Github heruntergeladenen Unterverzeichnis VMM\Templates\GW:
Hier finden wir 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 und SLB können wir diese Template Dateien an unsere Bedürfnisse anpassen. Öffnen Sie die jeweilige XML-Datei (hier: EdgeServiceTemplate_Generation2.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 GW 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 und den SLBs, die ich während des Deployments der Service Templates dem SCVMM „unterjuble“. Die Datei sollte noch in der VMM-Library vom NC- bzw. SLB-Deployment vorhanden sein.
Nachdem wir das gewünschte Service Templates gegebenenfalls angepasst haben, können wir uns nun dem eigentlichen Deployment der GW-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- bzw. SLB-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 GW-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 importGatewayTemplate Zeile 1050:
Dies wäre eine geeignete Stelle, um über den Service Designer in das importierte Gateway 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.
Funktion ConfigureAndDeployGatewayService Zeile 1091:
if($ServiceUpdate.deploymenterrorlist -ne $null)
Überprüfen Sie die Variable wieder, ob sie $null enthält und korrigieren Sie eventuell das Placement der VMs.
Funktion ConfigureAndDeployGatewayService Zeile 1112:
Hier können Sie im Service Designer der VMM-Konsole nochmals alle Parameter zum Erzeugen der Gateway VMs überprüfen.
Post Gateway Deployment Schritte
Wenn Sie das Skript VMMExpress.ps1 erfolgreich für die Gateways ausgeführt haben, finden Sie nun neben den Netzwerk Controller (NC) und SLB Komponenten auch die Gateway Komponenten als virtuelle Maschinen und Services im VMM:
Gateway Service VMs konfigurieren
Nun müssen wir die Gateway Manager Rolle 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 Gateway Manager Role.
Für das Feld Associated Service wählen Sie über die Browse Schaltfläche den gerade installierten Gateway Manager aus.
Wählen Sie einen Run As Account (hier: NC_LocalAdminRAA). Dieser wird vom Netzwerk Controller verwendet, um auf die Gateway VMs zuzugreifen. Der Account muss auf den Gateway VMs Administratorrechte besitzen.
Für das GRE VIP Subnet wählen Sie aus der Liste das entsprechende logische Netz aus. Es wurde beim Erzeugen der Netzwerk Controller Instanzen vom Skript VMMExpress.ps1 bereits definiert.
Für das Feld Public IPv4 Pool wählen Sie aus der Liste den entsprechenden IP-Pool aus. Auch er wurde beim Erzeugen der NC-Instanzen bereits vom Skript VMMExpress.ps1 definiert und wurde auch bereits beim Deployment der SLB-Komponenten verwendet.
Geben Sie in das Feld Public IPv4 Address eine Adresse aus dem Public IPv4 Pool ein. Wählen Sie aber keine der ersten 3 Adressen des Pools, die haben wir bereits beim Erzeugen von virtuellen IPs für die SLBs belegt. Ich verwende hier die letzte Adresse aus dem Public IPv4 Pool 10.10.50.199
Bei den Feldern Gateway Capacity (Mbps) und Nodes reserved for failures können wir die Standardwerte lassen.
Jetzt müssen wir noch die einzelnen Gateway VMs konfigurieren. Klicken Sie auf jede VM
Wählen Sie als IPv4 Frontend Subnet unser Transit Netz aus.
Legen Sie eine beliebige freie ASN (Autonomous System Number) für das BGP Peering festder Gateway VM fest, hier 65011.
Tragen Sie in die Liste der Geräte, mit denen ein Peering stattfinden soll (List of devices to peer with) unseren BGP-Router ein (IP-Adresse 10.10.20.1, ASN 65000). Wir haben ihn im Zuge des Deployments unserer SLB-Komponenten konfiguriert.
Wiederholen Sie diese Schritte für die anderen Gateway VMs, wobei Sie jeweils eine andere lokale ASN verwenden (z.B. 65012, 65013)
Wenn Sie alle Gateway VMs entsprechend konfiguriert haben, klicken Sie auf OK. Damit sind sie jetzt mit der Gateway Manager Rolle verknüpft.
Und zu guter Letzt müssen wir unsere Gateway VMs noch bei unserem BGP-Router anmelden. Führen Sie auf der BGP VM folgende PowerShell Befehle aus:
Add-BgpPeer -Name GW001 -LocalIPAddress 10.10.20.1 -PeerIPAddress 10.10.20.104 ` -LocalASN 65000 -PeerASN 65011 -OperationMode Mixed -PeeringMode AutomaticAdd-BgpPeer -Name GW002 -LocalIPAddress 10.10.20.1 -PeerIPAddress 10.10.20.105 ` -LocalASN 65000 -PeerASN 65012 -OperationMode Mixed -PeeringMode AutomaticAdd-BgpPeer -Name GW003 -LocalIPAddress 10.10.20.1 -PeerIPAddress 10.10.20.103 ` -LocalASN 65000 -PeerASN 65013 -OperationMode Mixed -PeeringMode Automatic
Nach einiger Zeit sollten alle Peer Systeme verbunden sein:
Get-BgpPeerPeerName LocalIPAddress PeerIPAddress PeerASN OperationMode ConnectivityStatus——– ————– ————- ——- ————- ——————GW001 10.10.20.1 10.10.20.104 65011 Mixed Connected GW002 10.10.20.1 10.10.20.105 65012 Mixed Connected GW003 10.10.20.1 10.10.20.103 65013 Mixed Connected MUX001 10.10.20.1 10.10.20.102 65001 Mixed Connected MUX002 10.10.20.1 10.10.20.100 65002 Mixed Connected MUX003 10.10.20.1 10.10.20.101 65003 Mixed Connected
