• Home →
  • Netzwerk →
  • Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 2

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 2

Allgemeines

Dieser Blogpost ist der zweite 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

​​​​SDN Deployment

Im letzten Beitrag (Teil 1) haben wir uns mit der Architektur und der Netzwerk Topologie einer SDN-Umgebung mit dem Windows Server 2016 beschäftigt. In diesem Beitrag wollen wir nun mit dem Aufbau und dem Deployment einer SDN Lab-Umgebung beginnen. Da dieser Beitrag etwas länger ist, hier erst mal zum leichteren Navigieren eine Inhaltsübersicht:

Mcirosoft bietet für das SDN-Deployment verschiedene Methoden an:

Manuelle Installation mit PowerShell

Diese Methode ist sehr mühsam, kann aber sinnvoll sein, wenn man nur einzelne SDN-Technologien einsetzen will. Details siehe DeploySoftware Defined Network Technologies using Windows PowerShell​ in der Technet Library.

Installation mit Hilfe vorgefertigter PowerShell Skripte

Diese Methode empfiehlt sich, wenn man eine SDN-Umgebung ohne den System Center Virtual Machine Manager (SCVMM) aufbauen und betreiben will, weil man andere Management Werkzeuge einsetzen will. Details siehe Deploy a Software Defined Network infrastructure using scripts in der Technet Library.

Installation über die Netzwerkfabrik des System Center Virtual Machine Manager 2016 (SCVMM 2016) 

Dies ist meiner Meinung nach aktuell die bequemste und übersichtlichste Methode zur Installation einer SDN-Umgebung, insbesondere wenn der SCVMM 2016 sowieso als Management Werkzeug für die virtuelle Welt eingesetzt wird. Wir haben dabei sowohl die Möglichkeit der manuellen Installation über die VMM Konsole (Details siehe Setup a Software Defined Network (SDN) infrastructure in the VMM fabric in der Technet Library) als auch die automatisierte Installation mit PowerShell Skripten, die von Microsoft auf Github bereitgestellt werden.

Ich werde im Folgenden auf die automatisierte SCVMM Installation mit PowerShell Skripten näher eingehen und damit auch die Lab-Umgebung aufbauen.

Die SDN Lab Umgebung

Legen wir also los mit dem Aufbau einer SDN Lab-Umgebung. Klären wir zunächst mal die Voraussetzungen.

Hardware

In meinem Testlabor habe ich nicht die notwendige Anzahl an Hardware-Systemen zur Verfügung, um eine vollständige SDN-Umgebung auszurollen. Ich werde deshalb das Ganze auf einem einzigen Hyper-V Host aufbauen und mit Nested Virtualisierung arbeiten.

Dieser Hyper-V sollte mindestens 128 GB RAM haben, für Windows Server 2016 Datacenter geeignet bzw. zertifiziert sein und natürlich Hyper-V unterstützen. Zur Not tut es auch ein System mit Windows 10 Pro (Laptop), das aber mindestens 64 GB RAM besitzen sollte. Falls Sie kein solches physisches System zur Verfügung haben, können Sie das Ganze auch in einer einzigen virtuellen Maschine umsetzen, die Sie z.B. in der Microsoft Azure Cloud oder bei einem anderen Service Provider anmieten.

Software

Sie benötigen folgende Softwarekomponenten für die Installation:

Da wir hier nur eine Testumgebung aufbauen wollen, genügen die Evaluierungs-Versionen der jeweiligen Komponenten. 

Auf das Downloaden und die Verwendung der SCVMM Service Templates und PowerShell Skripte werde ich später noch genauer eingehen.

Die Lab Infrastruktur

Für die SDN-Umgebung benötigen wir einige virtuelle Maschinen sowie die Parameter der logischen SDN-Netzwerke.

Virtuelle Maschinen

Bei der Infrastruktur der SDN-Umgebung beschränke ich mich auf folgende virtuelle Maschinen:

Domain Controller SDN-DC01

Dieses System dient als Active Directory Controller mit integriertem DNS. Darüber hinaus stellt es über File Shares den Storage für unser Hyper-V Failover Cluster bereit.

BGP-Router SDN-BGP01

Dieses System stellt den BGP-Router für unsere Lab-Umgebung dar. Es verwendet dazu die Windows Serverrolle Remote Access.

SDN-VMM01

Auf diesem System ist der System Center Virtual Machine Manager 2016 einschließlich der dafür notwendigen Basiskomponenten wie SQL-Server und Windows Assessment and Deployment Kit installiert. Von diesem System werden wir auch das Deployment der SDN-Umgebung steuern.

SDN-HV01, SDN-HV02, SDN-HV03 und SDN-HV04

Diese 4 Systeme bilden ein Hyper-V Failover Cluster, in das wir die virtuellen SDN-Systeme wie Network Controller, SLB-MUXs und Gateways sowie auch beispielhaft einige Tenant VMs ausrollen werden.

Logische SDN Netze

Zum Ausrollen der SDN-Umgebung müssen wir auch die Parameter der logischen SDN-Netze festlegen. Die nachstehenden Tabellen zeigen die Parameter, wie wir sie später im VMM verwenden werden.

NC_Management

SubnetzNetzmaskeVLAN (optional)GatewayDNSverwendeter IP-Bereichreserviert für andere Zwecke

192.168.80.0255.255.255.00192.168.80.1192.168.80.10192.168.80.230 – 192.168.80.254192.168.80.230 (IP-Adresse für REST-API)

HNVPA

SubnetzNetzmaskeVLAN (optional)GatewayDNSverwendeter IP-Bereich

10.10.10.0255.255.255.0010.10.10.1192.168.80.1010.10.10.100 – 10.10.10.199

Transit

SubnetzNetzmaskeVLAN (optional)GatewayDNSverwendeter IP-Bereich

10.10.20.0255.255.255.0010.10.20.1192.168.80.1010.10.20.100 – 10.10.20.199

PrivateVIP

SubnetzNetzmaskeVLAN (optional)GatewayDNSverwendeter IP-Bereichreserviert für andere Zwecke

210.10.30.0255.255.255.0010.10.30.1192.168.80.1010.10.30.100 – 10.10.30.19910.10.30.100 – 10.10.30.199 (für Load Balancer VIPs) 

GREVIP

SubnetzNetzmaskeVLAN (optional)GatewayDNSverwendeter IP-Bereichreserviert für andere Zwecke

10.10.40.0255.255.255.0010.10.40.1192.168.80.1010.10.40.100 – 10.10.40.19910.10.40.100 – 10.10.40.199 (für Load Balancer VIPs)

PublicVIP

SubnetzNetzmaskeVLAN (optional)GatewayDNSverwendeter IP-Bereichreserviert für andere Zwecke

10.10.50.0255.255.255.0010.10.50.1192.168.80.1010.10.50.100 – 10.10.50.19910.10.50.100 – 10.10.50.199 (für Tenant VIPs))

Ein grober Überblick

Die Infrastruktur der Lab-Umgebung hat also folgendes Aussehen:

Vorbereitungen

  • Installieren Sie auf dem physischen Hyper-V Host die Datacenter Edition von Windows Server 2016 und installieren Sie die Hyper-V Rolle. Für unsere Tests ist keine Windows Aktivierung erforderlich; ersatzweise können Sie auch Windows 10 Pro verwenden.
  • Erstellen Sie im Hyper-V Host die 3 folgenden virtuellen Switche – entweder über die GUI im Hyper-V Manager oder per PowerShell:

New-VMSwitch -Name „SDN“ -SwitchType InternalNew-VMSwitch -Name „Public“ -SwitchType InternalNew-VMSwitch -Name „Private“ -SwitchType Internal

  • Erzeugen Sie Windows Server 2016 VHDX-Dateien für die verschiedenen zu erzeugenden VMs, z.B. mit dem PowerShell Skript Convert-WindowsImage.ps1, das Sie im Verzeichnis <ISO>/NanoServer/NanoServerImageGenerator der heruntergeladenen ISO Datei des Windows Server 2016 finden.

cd ‚<ISO>:\nanoserver\NanoServerImageGenerator‘.\Convert-WindowsImage.ps1# Erzeuge dyn. VHDX für Gen2 Hyper-V VM# mit Windows Server 2016 Datacenter (= Edition4)Convert-WindowsImage `    -SourcePath ‚<ISO>:\sources\install.wim‘ `    -Edition 4 `    -VHDPath ‚E:\Hyper-V\WS2016.vhdx‘ `    -SizeBytes 80GB `    -VHDFormat VHDX `    -DiskLayout UEFI

  • Erzeugen Sie auf dem physischen Hyper-V Host nun folgende virtuelle Gen 2 Maschinen. Als Festplatte können Sie jeweils die im vorstehenden Schritt erzeugte VHDX-Datei verwenden. Statten Sie die VMs mit den angegebenen Netzwerkadaptern und gegebenenfalls mit den zusätzlichen Datenlaufwerken aus. Verbinden Sie die Netzwerkadapter mit dem jeweils angegebenen virtuellen Switch. 

SDN-DC01

vCPUMemoryNetzwerkadapterZusätzliches Laufwerk

24 GBNC_ManagementIP-AdresseGatewayDNS

Verbunden mit internen Switch SDN192.168.80.10192.168.80.1192.168.80.101 virt. Festplatte, dynamisch erweiterbarGröße: >= 512 GBShares:- Hyper-V – Storage für die HV01 – HV04– Cluster-Witn6ess – Syncdaten für das Hyper-V Cluster

Installieren und konfigurieren Sie folgende Serverrollen und Features einschließlich der jeweiligen Management Tools:

Active Directory

Domainname: SDNcloud.local

Legen Sie folgende Benutzerkonten an:

  • FabAdminFabric Admin: Klon des Benutzerkontos Administrator (optional). Ich arbeite normalerweise nur mit diesem Domain User. Damit kann keine Verwechslung mit dem lokalen Administrator-Konto entstehen beim Login an einem Member Server. Sie sollten dieses Konto jedoch auf allen Member Systemen in die lokale Gruppe Administrators aufnehmen, um dort auch alle Aufgaben durchführen zu können.
  • VMM-SVC – Service Account für den VMM Service

Legen Sie folgende lokale Security Gruppen an:

  • Network Controller AdminsMitglieder dieser Sicherheitsgruppe dürfen die Netzwerk Controller Konfiguration verwalten (Kreieren, Löschen und Updaten von NC Komponenten). Für unsere Lab-Umgebung verwende ich die Standardgruppe Domain Admins und setze zusätzlich das oben beschriebene Benutzerkonto FabAdmin ein.

  • Network Controller UsersMitglieder dieser Sicherheitsgruppe dürfen nach dem NC-Deployment mit dem Netzwerk Controller über dessen REST-API kommunizieren. Für unsere Lab-Umgebung verwende ich die Standardgruppe Domain Admins und setze zusätzlich das oben beschriebene Benutzerkonto FabAdmin ein.

DNS

Active Directory integriert

Definieren Sie ggf. DNS-Forwarders, um Internet Namen auflösen zu können (optional; für einige spätere Testszenarien sinnvoll)

Stellen Sie sicher, dass Sie alle aktuellen Updates und Patches installiert haben.

SDN-BGP01

vCPUMemoryNetzwerkadapter

24 GBNC_ManagementIP-AdresseGatewayDNSHNVPAIP-AdresseTransitIP-AdressePublicIP-Adresse

Verbunden mit internen Switch SDN192.168.80.50192.168.80.1192.168.80.10Verbunden mit internen Switch SDN10.10.10.1Verbunden mit internen Switch SDN10.10.20.1Verbunden mit internen Switch Public10.10.50.1

Joinen Sie das System als Member Server ins Active Directory.

Installieren und konfigurieren Sie folgende Serverrollen und Features einschließlich der jeweiligen Management Tools:

Remote Access 

Es genügen die Rollen Direct Access and VPN sowie Routing

Aktivieren Sie die LAN-Router Funktion oder optional NAT (in meiner Lab-Umgebung arbeite ich mit NAT, da ich über das logische Netz NC_Management Internetzugriff habe).

Eine weitere Konfiguration ist zunächst nicht notwendig; sie erfolgt später.

Stellen Sie sicher, dass Sie alle aktuellen Updates und Patches installiert haben.

SDN-HV01– SDN-HV04

vCPUMemoryNetzwerkadapter

je 4>= 16 GBNC_ManagementIP-AdressenGatewayDNS

dynamic Memory darf nicht aktiviert sein!Verbunden mit internen Switch SDNSDN-HV01: 192.168.80.21SDN-HV02: 192.168.80.22SDN-HV03: 192.168.80.23SDN-HV04: 192.168.80.24192.168.80.1192.168.80.10

Joinen Sie alle 4 Systeme als Member Server ins Active Directory.

Installieren und konfigurieren Sie folgende Serverrollen und Features einschließlich der jeweiligen Management Tools auf allen 4 VMs:

Hyper-V

Achtung: Aktivieren Sie Nested Virtualization und MAC Address Spoofing für alle 4 VMs mit PowerShell:

Get-VMProcessor -VMName SDN-HV01 | Set-VMProcessor -ExposeVirtualizationExtensions $trueGet-VMNetworkAdapter -VMName SDN-HV01 | Set-VMNetworkAdapter -MacAddressSpoofing On

Definieren Sie in den Hyper-V Systemen noch keinen virtuellen Switch. Wir werden dies später mit dem SCVMM erledigen.

Setzen Sie im Hyper-V Manager in den Hyper-V Einstellungen die Pfade für virtuelle Maschinen und virtuelle Hard Disks auf den Share, den Sie beim Kreieren des Systems SDN-DC01 angelegt haben.

​​​​Failover Clustering

Erzeugen Sie ein Hyper-V Failover Cluster mit den 4 Hyper-V Systemen. In meiner Lab-Umgebung verwende ich folgende Parameter:

  • Clustername: SDN-HVCL
  • Cluster IP: 192.168.80.20

Stellen Sie sicher, dass Sie alle aktuellen Updates und Patches installiert haben.

SDN-VMM01

vCPUMemoryNetzwerkadapterZusätzliches Laufwerk

mind. 4 GBNC_ManagementIP-AdresseGatewayDNS

Verbunden mit internen Switch SDN192.168.80.31192.168.80.1192.168.80.10

1 virt. Festplatte, dynamisch erweiterbarGröße: >= 512 GBLegen Sie Verzeichnisse für die VMM-Library (z.B. D:\VMMLibrary) und für die SDN Installationsskripte (z.B. D:\Software) an.

Joinen Sie das System als Member Server ins Active Directory.

Downloaden und installieren Sie nun folgende Softwarekomponenten auf den SDN-VMM01:

Verwenden Sie als Benutzerkonto für den VMM Serverdienst den beim SDN-DC01 erstellten Service Account VMM-SVC.

Stellen Sie sicher, dass Sie alle aktuellen Updates und Patches installiert haben.

Starten Sie nach der vollständigen VMM Installation die VMM Konsole über das Icon auf dem Desktop und führen Sie folgende Basiskonfiguration durch:

Rufen Sie im Arbeitsbereich Settings unter General die Network Settings auf und deaktivieren Sie das Kontrollkästchen Create logical networks automatically.

Klicken Sie im Arbeitsbereich Settings mit der rechten Maustaste auf den Eintrag Run As Accounts und rufen den Befehl Create Run As Account auf. Im Dialogfenster geben Sie jetzt ein Benutzerkonto aus dem Active Directory einschließlich Kennwort an, das Domain Admin Rechte besitzt – im Beispiel der FabAdmin aus der Domain sdncloud.

Erstellen Sie eine SDN-Host Gruppe im VMM

Technisch ist dieser Schritt nicht unbedingt erforderlich. Man kann dann jedoch schnell sehen, welche Hosts zu der SDN-Umgebung gehören.

Wechseln Sie in der VMM-Konsole in den Arbeitsbereich Fabric, klicken mit der rechten Maustaste unter Servers auf All Hosts und wählen im Kontextmenü den Befehl Create Host Group. Geben Sie als Namen SDN-Hosts ein.

Importieren Sie die Hyper-V Hosts in den VMM

Klicken Sie in der VMM-Konsole im Arbeitsbereich Fabric mit der rechten Maustaste auf die soeben erstellte Hostgruppe SDN-Hosts und wählen im Kontextmenü den Befehl Add Hyper-V Hosts and Clusters.

Es öffnet sich der Add Resource Wizard. Wählen Sie dort die Option Windows Server computers in a trusted Active Directory domain und klicken Sie dann auf Next.

Wählen Sie den Run As Account, mit dem der Import durchgeführt werden soll, indem Sie auf Browse klicken.

Wählen Sie in der angezeigten Liste den vorhin angelegten VMM Admin aus und klicken Sie auf OK.

Zurück im Add Resource Wizard sehen Sie den ausgewählten Run As Account. klicken Sie auf Next.

Im nächsten Fenster müssen Sie jetzt die Namen der zu importierenden Hyper-V Hosts bzw. Cluster eingeben, in unserem Fall also den Clusternamen SDN-HVCL. Klicken Sie dann wieder auf Next.

Jetzt wird Ihnen das Cluster mit den Mitgliedsservern angezeigt. Aktivieren Sie die Checkbox neben dem Clusternamen und klicken Sie auf Next.

Wählen Sie jetzt die Host Group für den Import aus. Aktivieren Sie auch die Checkbox Reassociate this host with this VMM environment. Klicken Sie nochmals auf Next.

Prüfen Sie in der angezeigten Zusammenfassung nochmals Ihre Angaben und klicken Sie dann auf Finish.

Der Importvorgang startet und Sie können den Fortschritt in der Jobliste des VMM mitverfolgen.

Warten Sie, bis alle Jobs erfolgreich abgeschlossen sind (Anzeige Completed). Die angezeigten Warnungen über das nicht aktivierte Multipath IO können wir hier ignorieren.

Schließen Sie das Jobfenster. In der VMM Konsole sind jetzt unser Cluster und die Hyper-V Hosts importiert.

Im nächsten Schritt müssen wir dem VMM noch mitteilen, wo die Images für unsere zukünftigen virtuellen Maschinen abgelegt werden sollen.

Wechseln Sie im Fabric Arbeitsbereich in die Kategorie Storage, klicken mit der rechten Maustaste auf Providers und wählen den Befehl Add Storage Devices.

Es öffnet sich der Add Storage Devices Wizard. Da wir in dieser Lab-Umgebung für das Ablegen der VM-Images einen File Share mit dem Namen Hyper-V auf unserem Domain Controller SDN-DC01 verwenden wollen, wählen wir als Provider Typ Windows-based file server und klicken auf Next.

Jetzt müssen wir den Servernamen und einen Run As account angeben. 

Nach einem Klick auf Next wird uns der SDN-DC01 als Storage Device angezeigt …

… und nach einem weiteren Klick auf Next die darauf verfügbaren Shares. Wählen Sie den Hyper-V Share aus und klicken Sie nochmals auf Next.

Es wird eine Zusammenfassung angezeigt. Wenn wir nun auf Finish klicken, wird unser File Share als Storage Device importiert.

Über die Jobliste können wir den Vorgang mitverfolgen.

Jetzt müssen wir den gerade importierten Storage Provider noch in den Properties unseres Clusters registrieren, damit der VMM weiß, wo er VM Images für dieses Cluster ablegen kann.

Klicken Sie mir der rechten Maustaste auf das Cluster im Fabric Arbeitsbereich unter der vorhin angelegten Hostgroup SDN-Hosts und rufen Sie im Kontextmenü die Properties auf.

Klicken Sie auf der Registerkarte File Share Storage auf die Schaltfläche Add…

Im Add File Share Dialogfenster können Sie nun den vorher als Storage Provider definierten Pfad \\SDN-DC01.sdncloud.local\Hyper-V in der Klappbox auswählen. Klicken Sie auf OK …

… und der Pfad wird in den File Share Properties unseres Clusters angezeigt. Durch einen weiteren Klick auf OK wird die Änderung übernommen.

Damit ist die Basis-Installation und Konfiguration für unsere SDN Lab-Umgebung erstmal abgeschlossen.

Bereitstellen der Skripte für das SDN Deployment – VMM Express.ps1

Für das SDN Deployment mit dem SCVMM stellt Microsoft ein eigenes Repository auf GitHub mit Service Templates und Skripten zur Verfügung. Laden Sie dieses Paket als .ZIP-Datei in ein Verzeichnis auf dem Datenlaufwerk des System SDN-VMM01 (z.B. D:\Software).

Entsperren und extrahieren Sie die heruntergeladene .ZIP-Datei. Sie erhalten dann folgende Verzeichnisstruktur:

Interessant für unsere weitere Arbeit ist der Unterordner VMM. Er enthält 3 Unterverzeichnisse:

  • Scripts – PowerShell Beispiel-Skripte für virtuelle Tenant IP-Adressen nach dem SDN Deployment
  • Templates – VMM Service Templates für Network Controller, SLB und Gateway VMs
  • VMM SDN Express – PowerShell Skripte für das SDN-Deployment

Werfen wir zunächst einen Blick in das Templates Verzeichnis. Es enthält 3 Ordner, je einen für die Netzwerk Controller (NC), für die Software Load Balancer(SLB) und für die Gateways (GW). Im NC-Verzeichnis finden wir 4 XML-Dateien für verschiedene Methoden zum Erzeugen der Netzwerk Controller VMs. Der Unterschied: Mit den Production Varianten wird ein virtuelles Guest Cluster mit 3 Network Controllern erzeugt, wohingegen die Standalone Varianten nur einen einzelnen Network Controller kreieren.

Für produktive Umgebungen sollten Sie auf jeden Fall die Production Varianten einsetzen. Wir werden in unserer Lab-Umgebung ebenfalls damit arbeiten und Gen2 VMs erzeugen.

Bei Bedarf können Sie in den Service Templates die Definitionen für die zu erzeugenden VMs noch anpassen. Öffnen Sie die jeweilige XML-Datei (hier: Network Controller Production Generation 2 VM.xml) in einem XML-Editor (z.B. PowerShell ISE). Sie können z.B. die Werte für RAM, Anzahl virtueller CPUs und die TimeZone anpassen:

Für unsere Lab-Umgebung reduziere ich den RAM-Wert auf 4096 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.

Analog können Sie auch die Service Templates für die SLBs und Gateways anpassen.

Um die Location Einstellungen der VMs (wie z.B. Tastatur Layout und Datum / Uhrzeit Anzeige in Deutsch) anzupassen, habe ich mir eine eigene Unattend.xml Datei erstellt, die ich während des Deployments der Service Templates dem SCVMM „unterjuble“.

Nachdem wir die Service Templates gegebenenfalls angepasst haben, können wir uns dem eigentlichen Deployment der SDN-Umgebung zuwenden.

Dazu wechseln wir in das Verzeichnis VMM SDN Express:

In diesem Verzeichnis finden wir eine PowerShell Skriptdatei VMMExpress.ps1 sowie einige PowerShell Datendateien (.PSD1).

VMMExpress.ps1

Dieses PowerShell Skript enthält die komplette Logik zum Ausrollen einer SDN-Umgebung. Es installiert die notwendigen virtuellen Switches in den Hyper-V Systemen, kreiert die weiter oben beschriebenen logischen Netze und erzeugt dann die VMs für die SDN-Komponenten (Network Controller, Software Load Balancer und Gateways).

Das Skript wird über eine Konfigurationsdatei (PowerShell Datendatei – .PSD1-Datei) gesteuert, die beim Aufruf von VMMExpress.ps1 über den Parameter -ConfigurationDataFile angegeben wird. Diese Konfigurationsdatei enthält sowohl die Parameter für die SDN-Umgebung wie logische Netze und VMs als auch Ablaufsteuerungsschalter. Letztere ermöglichen entweder einen gesamten Durchlauf für alle Komponenten oder ein schrittweises Deployment der einzelnen Komponenten. So kann festgelegt werden, dass zunächst nur die Netzwerk Controller Instanzen erzeugt werden. In einem weiteren Aufruf von VMMExpress.ps1 werden dann die Software Load Balancer erzeugt und in einem dritten Aufruf schließlich die Gateways. Diese Methode für das schrittweise Deployment der diversen SDN-Komponenten werde ich für unsere Lab-Umgebung verwenden.

Das Verzeichnis VMM SDN Express enthält 2 Beispiele für Konfigurationsdateien. Die Datei Fabricconfig.psd1 stellt ein „leeres“ Muster dar. Fabricconfig_Example.psd1 enthält die Parameter für eine von Microsoft erstellte Beispielkonfiguration.

Für unsere SDN Lab-Umgebung habe ich eine eigene Konfigurationsdatei mit den weiter oben beschriebenen Parametern erstellt – Fabricconfig-SDNcloud-Production.psd1.

Fabricconfig-SDNcloud-Production.psd1

Nachstehend finden Sie die vollständige Konfigurationsdatei, um in unserer SDN Lab-Umgebung zunächst nur den Netzwerk Controller und die logischen SDN-Netze zu erzeugen. Speichern Sie diese Datei im gleichen Verzeichnis wie VMMExpress.ps1 unter dem Namen Fabricconfig-SDNcloud-Pro1duction.psd1. Auf die notwendigen Änderungen für das Deployment der SLB- und Gateway-Komponenten werde ich in den späteren Blog-Beiträgen jeweils noch eingehen.

# This is a sample configuration file for VMM Express. All the paremeters should be# modified according to your setup for correct deployment of VMM Express.# Start VMMExpress.ps1:# change into the directory with VMMExpress.ps1 and then start the following command# .\VMMExpress.ps1 -ConfigurationDataFile .\Fabricconfig-SDNcloud-Production.psd1@{    AllNodes =     @(        @{             ###########################            #  VM Creation variables             ###########################                        # Name of the VHD or VHDX to use for VM creation. Must Exist in the            # VMM Library                        VHDName=“WS2016_EN.vhdx“                        # VMM Library share to be used for keeping the resources.            VMMLibrary=“\\SDN-VMM01\MSSCVMMLibrary“                        # Product key Can be blank if using a volume license VHD or VHDX, or you are            # deploying in eval mode.  (Don’t forget to press „skip“ while VM creation).            # This key is the AVMA for Windows Server 2016 Datacenter Edition            ProductKey=“TMJ3Y-NTRTM-FJYXT-T22BY-CWG3J“            #Generation of VM to be used for deployment : Gen1 or Gen2            Generation=“Gen2″            #Type of Deployment. The values are :            #Standalone : For single Node             #Production : For 3-node            DeploymentType=“Production“                #Higly Available VM. Do you want the infrastructural VMs to be deployed on            #Clustered Host and being higly Available ? If yes pass $true else $false            HighlyAvailableVMs = $true                        StorageClassification = „Remote Storage“            #leave it if you want default IPvAddressType to be taken which is static            # else change it to „Dynamic“            IPv4AddressType=““                                    #Host Group to be Managed by Network Controller            NCHostGroupName=“SDN-Hosts“                        #########################################################################            # Section for deploying Logical switch and Logical Network for NC.             #            # Specify IsLogicalSwitchDeployed = $false and             #         IsManagementVMNetworkExisting = $false            # if VMMExpress.ps1 should try to create a SET switch.             #            # If SET cannot be used you have to deploy Logical Switch and             # Management Network by yourself.            #            # NOTE : This script assumes either you have both logical switch and            # logical Network created and deployed or else you will use the script            # to deploy both.             #########################################################################                        #Do you have an existing logical switch and the switch is deployed on all            #the hosts you wish to Manage by NC            IsLogicalSwitchDeployed = $false            # IsLogicalSwitchDeployed =  $true                        #if above is true give the name of logical switch               LogicalSwitch  = „NC_LogicalSwitch“            # Do you have existing Management Network that you would like to use            IsManagementVMNetworkExisting = $false            # IsManagementVMNetworkExisting = $true            #if above is true give the name of ManagementVMNetwork            ManagementVMNetwork = „NC_Management“            #Uplink Port Profile to be used            UplinkPortProfile = „HV Uplink Port“                                     #====================================================================================            # The below set of Parameters are required for creation of Management Logical Network            # and other Logical Networks Managed by NC.                                                       # NOTE : If you already have Management Logical Network Created and switch deployed,            # you don’t need to specify any parameters for „NC_Management“ LN            #====================================================================================             LogicalNetworks = @(               @{                    Name = „HNVPA“                    Subnets = @(                        @{                            # VLANID = 255                                                                  VLANID = 0                                                                         AddressPrefix = „10.10.10.0/24“                                   DNS = @(„192.168.80.10“)                                             Gateways = „10.10.10.1“                                                 PoolStart = „10.10.10.100“                                              PoolEnd = „10.10.10.199“                                           }                    )                },               @{                    Name = „Transit“                    Subnets = @(                        @{                            # VLANID = 254                                                                VLANID = 0                                                                        AddressPrefix = „10.10.20.0/24“                                  DNS = @(„192.168.80.10“)                                            Gateways = „10.10.20.1“                                                PoolStart = „10.10.20.100“                                            PoolEnd = „10.10.20.199“                                          }                      )                },                 @{                    #The first IP address (PoolStart) for this logical network is                     #automatically assigned to the SLB Manager. Other addresses such                    #as the GatewayPublicIPAddress will start after that.                    Name = „PublicVIP“                    Subnets = @(                        @{                            VLANID = 0                            AddressPrefix = „10.10.50.0/24“                               DNS = @(„192.168.80.10“)                                         Gateways = „10.10.50.1“                                             PoolStart = „10.10.50.100“                                          PoolEnd = „10.10.50.199“                                            IsPublic = $true                        }                      )                },                @{                    #The first IP address (PoolStart) for this logical network is                     #automatically assigned to the SLB Manager. Other addresses such                    #as the GatewayPublicIPAddress will start after that.                    Name = „PrivateVIP“                    Subnets = @(                        @{                            # VLANID = 253                            VLANID = 0                            AddressPrefix = „10.10.30.0/24“                                 DNS = @(„192.168.80.10“)                                           Gateways = „10.10.30.1“                                               PoolStart = „10.10.30.100“                                            PoolEnd = „10.10.30.199“                                              IsPublic = $false                        }                      )                },                @{                    #This is used for onboarding Gateway                    Name = „GREVIP“      # Don’t change this. There should be no LN with this name in VMM                    Subnets = @(                        @{                            VLANID = 0                            AddressPrefix = „10.10.40.0/24“                                   DNS = @(„192.168.80.10“)                                             Gateways = „10.10.40.1“                                                 PoolStart = „10.10.40.100“                                              PoolEnd = „10.10.40.199“                                                IsPublic = $false                        }                      )                }                    @{                  # if Management VM Network is not deployed give the ManagementVMNetwork information. Skip                  # this if you already have this created.                    Name = „NC_Management“                    Subnets = @(                        @{                            # VLANID = 811                                                             VLANID = 0                                                                     AddressPrefix = „192.168.80.0/24“                            DNS = @(„192.168.80.10“)                                          Gateways = „192.168.80.1“                                         PoolStart = „192.168.80.230“                                      PoolEnd = „192.168.80.254“                                        ReservedIPset =  „192.168.80.230“      #This IP will be used for NC Rest API                           }                      )                }            )                    #=========================================================================================            # The following set of paremeters are required for importing VMM service Template,            # configuring the Service Template and Deploying the service Template.            #==========================================================================================            # Make this true if self signed certificate is to be used            # Example : $True , $False            IsCertSelfSigned = $true             #The password for server certificate. This certificate will be installed on the Host            ServerCertificatePassword=“Passw0rd!“                      # The following are service settings required for configuring and            # deploying the service template imported client security Group Name            ClientSecurityGroupName= „SDNcloud\Network Controller Users“            # Local Admin credentials            # The local admin user name will be .\Administrator            LocalAdminPassword= „Passw0rd!“               # Management Domain Account Which will be used for NC Deployment            ManagementDomainUser=“SDNcloud\FabAdmin“            ManagementDomainUserPassword=“Passw0rd!“            # This is the domain which NC VMs will join            ManagementDomainFDQN=“SDNcloud.local“              #Managemet Security Group Name            ManagementSecurityGroupName=“SDNcloud\Network Controller Admins“                        # Prefix to be added to infrastructural VMs created. Put the prefix such            # that it makes VM name unique as this is the machine name of VM and should be unique.                        ComputerNamePrefix = „SDN“              # RestName = „SDN-NCREST.SDNcloud.local“            RestName = „192.168.80.230“                        ##################################            #  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        };                );}

Schrittweises Deployment der SDN-Komponenten

Ich habe bereits erwähnt, dass die Datei Fabricconfig.psd1 auch Schalter zur Steuerung der von VMMExpress.ps1 durchzuführenden Aktionen enthält. Ich werde dies für das Deployment unserer SDN Lab-Umgebung nutzen.

Ich sehe darin den Riesenvorteil, dass man jede Komponentenkategorie separat ausrollen und validieren kann. So kann man z.B. vor der Installation der Software Load Balancer sicherstellen, dass die Netzwerk Controller Umgebung korrekt arbeitet und die Netzwerkvirtualisierung mit dem VXLAN-Protokoll funktioniert.

Folgende Schalter stehen zur Verfügung. Sie finden Sie am Ende der Datei Fabricconfig.psd1:

DeployNC = $true | $false

Durch Angabe von $true weisen Sie das Skript an, die Netzwerk Controller Instanzen zu erzeugen. Ändern Sie diesen Wert auf $false, wenn Sie nach einer erfolgreichen Installation des Netzwerk Controllers nur die Software Load Balancer bzw. Gateway Instanzen erzeugen wollen.

createNCManagedNetworks = $true | $false

Durch Angabe von $true werden durch VMMExpress.ps1 die für die SDN-Umgebung notwendigen logischen Netze wie HNVPA, Transit, PublicVIP, GREVIP und PrivateVIP im VMM erzeugt und an die SDN-Switches in den Hyper-V Hosts verteilt. Diese Netze müssen vorhanden sein, um die SLB und Gateway Komponenten erzeugen zu können.

DeploySLB = $false | $true

Damit legen Sie fest, dass die Software Load Balancer Komponenten erzeugt werden. Wenn Sie $true angeben, muss sichergestellt sein, dass zuvor der Netzwerk Controller und die logischen SDN-Netze erfolgreich erzeugt wurden.

DeployGW = $false | $true

Damit legen Sie fest, dass die Gateway Komponenten erzeugt werden. Wenn Sie $true angeben, muss sichergestellt sein, dass zuvor der Netzwerk Controller, die logischen SDN-Netze sowie die SLB-Komponenten erfolgreich erzeugt wurden.

Starten des Netzwerk Controller  Deployments

Wenn Sie die Konfigurationsdatei Fabricconfig.psd1 mit den zu Ihrer Umgebung passenden Parametern und den gewünschten Ablaufsteuerungsschaltern erstellt haben, speichern Sie diese im gleichen Verzeichnis wie das Skript VMMExpress.ps1 mit einem passenden Namen, z.B. für unsere Lab-Umgebung unter Fabricconfig-SDNcloud-Production.psd1.

Dann können Sie das SDN-Deployment mit folgendem Aufruf in einer Powershell Konsole mit Admin-Rechten folgendermaßen starten:

.\VMMExpress.ps1 -ConfigurationDataFile .\Fabricconfig-SDNcloud-Production.psd1

Anmerkung: Mit den in der vorstehenden Fabricconfig-SDNcloud-Production.psd1 angegebenen Ablaufsteuerungsschaltern werden wir zunächst nur die Netzwerk Controller Komponenten und die notwendigen logischen Netze erzeugen.

Tipp: Laden Sie VMMExpress.ps1 in ein PowerShell ISE Fenster und arbeiten Sie im Debug Modus. Ich werde gleich darauf zurückkommen.

Erfahrungen, Tipps und Tricks

Hyper-V Switch Deployment

In den meisten Fällen kann die Logik in VMMExpress.ps1 verwendet werden, um in den Hyper-V Hosts einen SDN-kompatiblen Switch zu erzeugen. Dieser wird mit SET (Switch Embedded Teaming) angelegt. Das Skript prüft dazu die in den Hyper-V Hosts vorhandenen physischen Netzwerkadapter und bindet den SDN-Switch an den ersten Adapter, der im Trunk Mode mit dem physischen Netz verbunden ist und dem noch kein logisches Netz zugeordnet ist.

Skript-Ausschnitt Zeile 738:

         $NetworkAdapter = @(Get-SCVMHostNetworkAdapter -VMHost $VMHost | `                    where {$_.VLanMode -eq „Trunk“ -and `                           $_.ConnectionState -eq „Connected“ -and `                           $_.LogicalNetworkMap.count -eq  0})

Wird kein geeigneter Adapter gefunden ($NetworkAdapter.count -eq 0), gibt das Skript eine Warnung aus. In diesem Fall müssen Sie den logischen SDN-Switch über die VMM-Konsole selbst erzeugen und an die Hyper-V Hosts verteilen.

Ebenso müssen Sie den logischen SDN-Switch selbst erzeugen, wenn Sie SET nicht verwenden wollen (z.B. weil keine geeigneten Netzwerkadapter vorhanden sind oder weil Sie mit „klassischem“ Teaming auf Betriebssystemebene in den Hyper-V Hosts arbeiten wollen).

Anmerkung: SET in Verbindung mit geeigneter Hardware bringt zwar deutliche Performance Vorteile, ist aber keine zwingende Voraussetzung für SDN!

Selbst erzeugte Hyper-V Switches müssen vor dem Start von VMMExpress.ps1 definiert und verteilt sein. Setzen Sie in diesem Fall in der Konfigurationsdatei Fabricconfig.psd1 dann folgende Werte:

            #Do you have an existing logical switch and the switch is deployed on all            #the host you wish to Manage by NC            IsLogicalSwitchDeployed = $true                        #if above is true give the name of logical switch               LogicalSwitch  = „NC_LogicalSwitch“            # Do you have existing Management Network that you would like to use            IsManagementVMNetworkExisting = $true            #if above is true give the name of ManagementVMNetwork            ManagementVMNetwork = „NC_Management“            #Uplink Port Profile to be used            UplinkPortProfile = „HV Uplink Port“ 

REST-IP

Wenn Sie die Production Variante des Netzwerk Controllers ausrollen wollen, müssen Sie für die REST API des NC eine IP-Adresse in der Konfigurationsdatei angeben. Diese muss eine Adresse aus dem IP-Pool für das Management Netz sein und darf nicht für andere Zwecke verwendet werden. Geben Sie in der Definition für das Managementnetz diese IP-Adresse beim Parameter ReservedIPset an:

ReservedIPset = „192.168.80.230“

oder über die VMM Konsole:

Damit ist sichergestellt, dass der VMM diese Adresse nicht einem anderen Objekt zuweisen kann.

In der Konfigurationsdatendatei geben Sie dann diese Adresse beim Parameter RestName an:

RestName = „192.168.80.230“

Beim Erzeugen der NC VMs wird hierdurch von VMMExpress.ps1 diese Adresse für die REST API des NC Guest Clusters konfiguriert.

Bitte verwenden Sie keinen DNS-Namen; dies wird im Deployment für unsere Lab-Umgebung nicht unterstützt. 

Wenn Sie für das NC Deployment die Standalone Variante definiert haben, werden diese Angaben ignoriert. Als IP-Adresse für die REST API wird dann direkt die IP-Adresse der NC VM verwendet.

Undo Funktion

VMMExpress.ps1 hat eine eingebaute Undo-Funktion, die aufgerufen wird, wenn während der Ausführung des Skripts ein Fehler auftritt. Sie sorgt dafür, dass alle zuvor angelegten Objekte in der richtigen Reihenfolge wieder aus dem VMM entfernt werden. Das funktioniert aber nur, solange der Netzwerk Controller noch nicht im VMM als Netzwerk Service registriert ist. Danach müssen Sie manuell die Umgebung wieder bereinigen. Hilfe dazu erhalten Sie in der Technet-Library

Tipp: Führen Sie VMMExpress.ps1 im Debug Modus aus und setzen Sie einen Breakpoint auf den Start der UndoNCDeployment-Funktion (ab Zeile 513). Dann können Sie im Fehlerfall die einzelnen Schritte beim Beseitigen fehlerhafter Objekte genauer mitverfolgen und gegebenenfalls manuell eingreifen.

function undoNCDeployment    {        param([Object] $node)        if ($NetworkControllerOnBoarder -eq $false)…

VMMExpress.ps1 im Debugger ausführen

Im Zusammenhang mit der Undo-Funktion von VMMExpress.ps1 habe ich Ihnen gerade empfohlen, VMMExpress.ps1 im Debug Modus der PowerShell ISE auszuführen. Nach meiner Erfahrung hat dies den Vorteil, dass man die einzelnen Schritte bzw. Funktionsblöcke genauer mitverfolgen kann. VMMExpress.ps1 arbeitet intern mit den CmdLets des PowerShell Moduls für den Virtual Machine Manager. Diese CmdLets starten jeweils einen Job im VMM Server, was im Job-Fenster der VMM-Konsole mitverfolgt werden kann.

Der folgende Screenshot zeigt eine Situation, als während des Erzeugens der VMs für den Netzwerk Controller ein Problem im Hyper-V Cluster auftrat (Zeile 505 in VMMExpress.ps1).

Oftmals können Sie die Ursache des Problems sofort beheben und dann einen Restart des fehlgeschlagenen Jobs versuchen (im Kontextmenü des Jobs).

Ich empfehle Ihnen an folgenden Stellen Breakpoints zu setzen und dann die jeweiligen Befehle im Einzelschrittmodus auszuführen:

NC Deployment

Funktion OnBoardNetworkController Zeile 252:

An dieser Stelle können Sie den Connection String für die REST API des Netzwerk Controllers in der Variablen $ConnectionString überprüfen.

Funktion importServiceTemplate Zeile 359:

Dies wäre eine geeignete Stelle, um über den Service Designer in das importierte NC 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 configureAndDeployService Zeile 467:

if($ServiceUpdate.deploymenterrorlist -ne $null)

Überprüfen Sie, ob die Variable wirklich $null enthält. Nur dann war die Verteilung der NC 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 configureAndDeployService Zeile 505:

$sc= New-SCService -ServiceConfiguration $ServiceConfig

Hier können Sie im Service Designer der VMM-Konsole nochmals alle Parameter zum Erzeugen der NC VMs überprüfen.

NC Deployment Validierung

Wenn Sie das Skript VMMExpress.ps1 erfolgreich ausgeführt haben, finden Sie die Netzwerk Controller Komponenten als virtuelle Maschinen und Services im VMM.

Und auch die logischen SDN-Netze sind angelegt:

Damit ist zwar das Deployment des Netzwerk Controllers und der logischen SDN-Netze abgeschlossen. Bevor wir aber weitere SDN-Komponenten ausrollen, sollten wir einige Testszenarien durchspielen, um den NC und die Netzwerkvirtualisierung mit VXLAN zu validieren.

Tenant Testumgebungen

Wir werden 2 Tenant Testumgebungen anlegen. Jede Tenant Umgebung enthält ein VM Network mit jeweils 2 Subnetzen. In jedem Tenant VM Network gibt es dann jeweils 2 VMs.

Tenant VM Netze

Erzeugen Sie 2 Tenant VM Netzwerk Umgebungen („Red VMNet“ und „Green VMNet“) mit identischen Netzwerkdefinitionen:

Subnetz 0: „Red VMnet_0“ bzw. „Green VMnet_0“ – 192.168.0.0/24IP-Pool 0: “Red IP Pool 0” bzw. “Green IP Pool 0” – 192.168.0.4 – 192.168.0.254Gateway in den IP Pools: jeweils 192.168.0.1

Subnetz 1: „Red VMnet_1“ bzw. „Green VMnet_1“ – 192.168.1.0/24IP-Pool 1: “Red IP Pool 1” bzw. “Green IP Pool 1” – 192.168.1.4 – 192.168.1.254Gateway in den IP Pools: jeweils 192.168.1.1

DNS in allen IP Pools:192.168.80.10 (der Standard DNS-Server in unserer Lab-Umgebung auf dem SystemSDN-DC01). 

Sie können dies über die VMM-Konsole oder mit dem weiterunten folgenden PowerShell Skript erledigen.

VMM Konsole

Klicken Sie im VMM Arbeitsbereich VMs and Services mit der rechten Maustaste auf die Kategorie VM Networks und wählen Sie im Kontextmenü Create VM Network.

Geben Sie den Namen des anzulegenden VM Netzwerks an und achten Sie darauf, dass in der Klappliste Logical Network das HNVPA Netz ausgewählt ist. Klicken Sie auf Next.

Lassen Sie im Dialogfenster Isolation die Voreinstellung Isolate using Hyper-V network virtualization und klicken Sie auf Next.

Tragen Sie im Dialogfenster VM Subnets die Parameter für die beiden Subnetze ein. Klicken Sie dann wieder auf Next.

Im Dialog Connectivity lassen Sie die Voreinstellungen und klicken auf Next.

Sie sehen nun eine Zusammenfassung Ihrer Eingaben.

Durch einen Klick auf Finish können Sie nun das Anlegen des VM Networks starten. In der Job-Liste des VMM können Sie das mitverfolgen.

Nun müssen Sie für jedes Subnetz noch den zugehörigen IP Pool anlegen.

Klicken Sie mit der rechten Maustaste auf das soeben erzeugte VM Network (Green VMnet) und wählen Sie im Kontextmenü die Aktion Create IP Pool.

Geben Sie den Namen des IP Pools an. Stellen Sie sicher, dass im Feld VM network das richtige Tenant VM-Netz und im Feld VM Subnet das gewünschte Subnetz ausgewählt sind. Klicken Sie dann auf Next.

Die im Dialog IP address range angezeigten Werte können Sie für unsere Test-Umgebung durch einen Klick auf Next übernehmen.

Geben Sie im Gateway Dialog die Adresse des jeweiligen Gateways ein und klicken Sie auf Next.

Im DNS Dialog geben Sie die Adresse des DNS-Servers unserer Lab-Umgebung (192.168.80.10) ein und klicken auf Next.

Den WINS Dialog können Sie mit Next überspringen. Überprüfen Sie in der Zusammenfassung nochmals Ihre Eingaben und klicken Sie dann auf Finish, um den IP Pool zu erstellen.

In der VMM Jobliste können Sie den Vorgang wieder mitverfolgen. 

Erzeugen Sie analog die IP Pools für die anderen Subnetze der Tenants.

PowerShell

Etwas schneller und komfortabler geht das Ganze mit dem nachstehenden PowerShell Skript. Weisen Sie der Variablen $tenantname den gewünschten Tenant Namen zu und starten das Skript in einer PowerShell Sitzung mit Administrator Rechten.

# Create VM network for tenant$tenantname = „Red“# $tenantname = „Green“$subnet0 = „192.168.0.0/24″$IPrangeStart0 = „192.168.0.4“$IPrangeEnd0 = „192.168.0.254“$gateway0 = „192.168.0.1“$subnet1 = „192.168.1.0/24″$IPrangeStart1 = „192.168.1.4“$IPrangeEnd1 = „192.168.1.254“$gateway1 = „192.168.1.1“$DNSserver = „192.168.80.10“$logicalNetwork = Get-SCLogicalNetwork -Name „HNVPA“# tenant VM net$vmNetwork = New-SCVMNetwork -Name „$tenantname VMnet“ `             -LogicalNetwork $logicalNetwork -IsolationType „WindowsNetworkVirtualization“ `             -CAIPAddressPoolType „IPV4“ -PAIPAddressPoolType „IPV4″# tenant subnets$subnetVLan0 = New-SCSubnetVLan -Subnet $subnet0$VMsubnet0 = New-SCVMSubnet -Name „$tenantname VMnet_0“ `             -VMNetwork $vmNetwork -SubnetVLan $subnetVLan0$subnetVLan1 = New-SCSubnetVLan -Subnet $subnet1$VMsubnet1 = New-SCVMSubnet -Name „$tenantname VMnet_1“ `             -VMNetwork $vmNetwork -SubnetVLan $subnetVLan1# VMnet_0# Gateways$allGateways = @()$allGateways += New-SCDefaultGateway -IPAddress $gateway0 -Automatic# DNS servers$allDnsServer = @($DNSserver)# DNS suffixes$allDnsSuffixes = @()# WINS servers$allWinsServers = @()New-SCStaticIPAddressPool -Name „$Tenantname IP Pool 0“ -VMSubnet $VMsubnet0 `    -Subnet $subnet0 -IPAddressRangeStart $IPrangeStart0 -IPAddressRangeEnd $IPrangeEnd0 `    -DefaultGateway $allGateways -DNSServer $allDnsServer -DNSSuffix „“ `    -DNSSearchSuffix $allDnsSuffixes# VMnet_1# Gateways$allGateways = @()$allGateways += New-SCDefaultGateway -IPAddress $gateway1 -Automatic# DNS servers$allDnsServer = @($DNSserver)# DNS suffixes$allDnsSuffixes = @()# WINS servers$allWinsServers = @()New-SCStaticIPAddressPool -Name „$Tenantname IP Pool 1“ -VMSubnet $VMsubnet1 `    -Subnet $subnet1 -IPAddressRangeStart $IPrangeStart1 -IPAddressRangeEnd $IPrangeEnd1 `    -DefaultGateway $allGateways -DNSServer $allDnsServer -DNSSuffix „“ `    -DNSSearchSuffix $allDnsSuffixes

Den Ablauf des Skripts können Sie wieder über die Jobliste im VMM verfolgen. Als Ergebnis erhalten Sie dann das jeweilige Tenant VM Netzwerk einschließlich der IP Pools.

Tenant Test VMs

Erzeugen Sie für jeden der beiden Tenants 2 VMs und verbinden Sie diese wie folgt mit den Subnetzen der beiden VM Netze:

analog:

  • Red-VM02 – verbunden mit Subnetz 1 von VM Netzwerk Red VMnet
  • Green-VM01 – verbunden mit Subnetz 0 von VM Netzwerk Green VMnet
  • Green-VM02 – verbunden mit Subnetz 1 von VM Netzwerk Green VMnet

Installieren Sie in jeder dieser VMs die Serverrolle Web Server mit Standardeinstellungen. Modifizieren Sie anschließend das Bild der IIS-Startseite – Datei iisstart.png im Verzeichnis C:\inetpub\wwwroot – so dass sie den Namen der VM zeigt, z.B.

Tipp: Das können Sie ganz einfach mit Paint aus dem Windows Zubehör durchführen.

Validierung der Netzwerkisolation mit dem VXLAN-Protokoll

Nun können Sie folgende Szenarien zur Netzwerkisolation mit dem VXLAN-Protokoll durchspielen.

Melden Sie sich auf dem Tenant System Red-VM01 an. Im Server Manager können Sie die zugewiesene IP-Adresse überprüfen:

Melden Sie sich jetzt auf dem Tenant System Red-VM02 an. Der Server Manager wird Ihnen die Adresse 192.168.1.4 anzeigen. Starten Sie den Internet Explorer und geben Sie in die Adresszeile folgende Adresse ein: http://192.168.0.4 – Ergebnis:

Natürlich können Sie auch die umgekehrte Richtung wählen – vom System Red-VM01 (192.168.0.4) aus die Startseite von Red-VM02 (192.168.1.4) aufrufen. Entsprechend erhalten Sie:

Die gleichen Spielchen können Sie jetzt auch zwischen den Systemen im Green-VMnet ausführen. Sie werden immer nur die Systeme im gleichen VMnet erreichen, können aber nicht auf Systeme in anderen VM Netzen zugreifen.

Erkenntnisse:

Innerhalb eines Tenant VM Netzes werden IP-Pakete zwischen den definierten Subnetzen geroutet. Eine Verbindung zu Systemen in andere Tenant VM Netze ist jedoch nicht möglich, auch wenn die IP-Bereiche identisch sind oder sich überlappen.

Nächste Schritte

Mit dem erfolgreichen Deployment der Netzwerk Controller Komponenten haben wir nun die Basis für den weiteren Ausbau unserer Software Defined Networking (SDN) Umgebung geschaffen.

Im nächsten Beitrag werden wir unsere Lab-Umgebung um die SDN-Komponenten für Software Load Balancing erweitern und auch den Zugriff auf unsere Tenant VMs von außen ermöglichen.

Bleiben Sie also dran. Es bleibt weiterhin spannend …

←Previous post Next post→
Dazu passende Blogpost

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 5

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 4

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 3

Software Defined Networking (SDN) mit Windows Server 2016 und System Center Virtual Machine Manager 2016 (SCVMM 2016) – Teil 1
Gerhard Glenk
 

Diplom Informatiker Gerhard Glenk ist seit über 30 Jahren in der IT-Branche tätig und arbeitet für die Rachfahl IT-Solutions GmbH & Co. KG als freier Mitarbeiter in den Bereichen Cloud Computing mit Microsoft Technologien wie Hyper-V, System Center und Windows Azure Pack.