0

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

Allgemeines

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

Die Microsoft SDN-Architektur

Eigentlich gibt es SDN im Windows Server bereits seit der Version 2012R2. Dort hatte Microsoft die Technologie an verschiedenen Stellen im Betriebssystem und im SCVMM „versteckt“. Zur Isolation von Netzen wurde der GRE-Standard (Generic Routing Encapsulation) verwendet. GRE hat sich für diesen Zweck jedoch nicht so recht am Markt durchgesetzt. Die Mehrzahl von Netzwerk-Anbietern setzt mittlerweile auf den VXLAN-Standard (Virtual Extensible LAN), was zur Folge hatte, dass Microsoft dieses Protokoll sowohl in der Microsoft Azure Cloud implementierte und die entsprechenden Komponenten nun auch im Windows Server 2016 bereitstellt.

Anmerkung: VXLAN ist nun das Standard-Protokoll für SDN. Jedoch wird auch weiterhin das GRE-Protokoll unterstützt, so dass bisherige Installationen weiter genutzt werden können. Eine Migration von GRE auf VXLAN ist jedoch nicht vorgesehen und bedeutet eine Neuinstallation.

​Werfen wir zunächst einen Blick auf das folgende Architekturbild, das aus der Microsoft TechNet Library stammt.

Im Zentrum der neuen SDN-Architektur steht eine neue Serverrolle, die nur in der Datacenter Edition von Windows Server 2016 verfügbar ist, der Network Controller. Wir benötigen dafür entweder physische oder auch virtuelle W2016 Datacenter Systeme, auf denen diese Serverrolle installiert und konfiguriert ist. Und warum die Mehrzahl? Technisch würde eine Instanz des Network Controllers genügen. Um aber eine Hochverfügbarkeit zu gewährleisten, empfiehlt Microsoft für produktive Umgebungen aber wenigstens 3 Instanzen.

Der Network Controller besitzt zwei Schnittstellen (APIs), die Northbound API und die Southbound API. Über die Southbound API kommuniziert der Network Controller mit den physischen und virtuellen Netzwerkgeräten, also z.B. mit den physischen Switches im Server Rack (Top of Rack – TOR) oder mit den virtuellen Switches in den Hyper-V Hostsystemen. Über die Northbound API erhält der Network Controller von verschiedenen Netzwerk Management Tools Anweisungen bzw. Richtlinien, wie die über die Southbound API verbundenen Netzwerkgeräte den Netzwerkverkehr behandeln sollen.

Für die Kommunikation zwischen dem Network Controller und den verschiedenen Netzwerkkomponenten muss in einer Microsoft SDN Plattform das in jedem Rechenzentrum ohnehin vorhandene (logische) Management Netz verwendet werden, das ich in diesem Artikel mit NC_Management bezeichnen will.

Anmerkung: Die Einbettung des Network Controllers in das NC_Management Netz hat nicht zur Folge, dass der Netzwerkverkehr virtueller (Kunden-) Maschinen ebenfalls über dieses Netz läuft. Hierfür werden wir noch weitere logische Netze einführen.

Die Northbound API ist als Representational State Transfer (REST) API ausgelegt, so dass beliebige Management Tools, die dieses Protokoll beherrschen, verwendet werden können, um dem Network Controller Richtlinien zu übermitteln. Darüber hinaus bietet diese API auch die Möglichkeit, das Netzwerk zu überwachen und bei Problemen Informationen fürs Troubbleshooting abzurufen.

Als Management Tools für den Network Controller bietet Microsoft aktuell folgende Werkzeuge:

• PowerShell Cmdlets
• den Azure Resource Manager (ARM)
• den System Center 2016 Virtual Machine Manager (SCVMM 2016)

Insbesondere der SCVMM 2016 bietet mit seiner grafischen Benutzeroberfläche eine einfache Möglichkeit zum Konfigurieren des Network Controllers und stellt auch alle Funktionen über eigene PowerShell Cmdlets zur Verfügung. Wir werden uns dies später noch genauer ansehen.

Die über die Northbound API erhaltenen Richtlinien verteilt der Network Controller dann über seine Southbound API an die betroffenen Netzwerkgeräte. Bei Hyper-V Hosts ist dies eine neue Hyper-V Switch Erweiterung (Extension) mit dem Namen Microsoft Azure VFP Switch Extension. VFP steht für „Virtual Filtering Platform“.

Die Microsoft SDN-Architektur besteht also aus 3 Ebenen, wie die folgende Abbildung zeigt.

Netzwerk Controller Funktionalitäten

Mit dem Netzwerk Controller können nun folgende Funktionalitäten realisiert werden:

Netzwerk Virtualisierung

Es können für Gruppen von Kunden VMs (häufig auch als „Tenant“ VMs bezeichnet) eigene logische virtuelle Netze definiert werden. Diese Netze sind voneinander völlig getrennt, auch wenn sie identische Netzwerkparameter wie IP-Bereiche oder VLANIDs besitzen. Die Isolation des Datenverkehrs innerhalb eines solchen virtuellen Netzes erfolgt durch „Verpacken“ der Datenpakete nach dem VXLAN-Protokoll.

Das VXLAN-Protokoll

VMs in einem virtuellen Netz verwenden typischerweise kundenspezifische IP-Adressen („Customer Addresses“ – CAs), die nicht vom Rechenzentrumsbetreiber verwaltet und mit denen die Netzwerkgeräte im Rechenzentrum somit nichts anfangen können. Will nun eine Kunden-VM mit einer anderen kommunizieren, gibt sie ein Ethernet Netzwerkpaket über ihren Netzwerkadapter an einen Switch weiter, in einer Hyper-V Umgebung also an den Hyper-V Switch des Hosts, auf dem sie gerade läuft. Im Hyper-V Switch wird geprüft, ob die Ziel-VM im gleichen Host läuft. Falls ja, wird das Netzwerkpaket vom Switch direkt an die entsprechende VM weitergeleitet. 

Falls die Ziel-VM jedoch auf einem anderen Host läuft, wird das Datenpaket in ein neues Netzwerkpaket mit vom RZ-Betreiber verwalteten IP-Adressen („Provider Addresses“ – PAs) gemäß dem VXLAN-Protokoll verpackt und an den Zielhost per UDP weitergeleitet. Dieser kann dann das ursprüngliche Datenpaket wieder auspacken und an die entsprechende VM weiterleiten.

Um die Zuordnung eines verpackten Kunden-Datenpakets zu gewährleisten, wird jedem virtuellen Kundennetz beim Anlegen über den Netzwerk Controller eine eindeutige VXLANID zugewiesen. Diese VXLANID hat eine Länge von24 Bit. Somit können bis zu 16 Millionen Kundennetze identifiziert werden. Beim Verpacken eines Kunden-Datenpakets wird die VXLANID des Kundennetzes dem Kunden-Datenpaket als Header vorangestellt, so dass beim Auspacken der Daten im Zielhost diese in das entsprechende Kundennetz geleitet werden können.

Für die Kommunikation zwischen den Kunden-VMs benötigen wir also ein (und nur ein) zusätzliches vom Provider verwaltetes logisches Netz, über das die in VXLAN eingepackten Kunden-Datenpakete weitergeleitet werden. Für die weiteren im Netzwerk vorhandenen Geräte wie Switches oder Router sind die Datenpakete der Kunden-VMs also „unsichtbar“ und benötigen somit auch keine weiteren Management Aktivitäten.

Zum Vergleich: Bei der bisherigen Methode zur Netzwerk Virtualisierung mit VLANIDs muss hingegen jedes Kundennetz mit einer eindeutigen VLANID vom Provider definiert, verwaltet und an alle Netzwerkgeräteverteilt werden. Da die VLANIDs nur aus 12 Bits bestehen, ist die Anzahl von Kunden-Netzen außerdem auf knapp 4096 begrenzt.

Das logische Netzwerk zum Weiterleiten der mit VXLAN verpackten Datenpakete wird in einer Microsoft SDN-Umgebung üblicherweise als HNVPA (Hyper-V Netzwerk Virtualisierung mit Provider Adressen)Netz bezeichnet.

Die Netzwerk Virtualisierung mit VXLAN vereinfacht also drastisch das Netzwerkmanagement in einem Rechenzentrum, da sich der Provider nicht mehr explizit um die Isolation von Kundennetzen kümmern muss.

Load Balancing

Für VMs, die in einem virtuellen Kundennetzwerk den gleichen Workload bereitstellen (z.B. Webserver Cluster), kann per Software ein Lastenausgleich („Software Load Balancing“ – SLB) in Form eines SLB-Pools definiert werden. Das Load Balancing wird von eigenständigen über den Netzwerk Controller verwalteten VMs durchgeführt. Die SLB VMs ermöglichen dann auch den Zugriff von außen auf die SLB-Pools in einem virtuellen Kundennetzwerk.

Ein SLB-Pool enthält die virtuellen IP-Adressen der für das Load Balancing vorgesehenen Kunden-VMs (hier als dynamische IP-Adressen – DIPs – bezeichnet). Dem Pool wird dann eine öffentliche IP-Adresse (PublicIP) zugeordnet. PublicVIPs sind typischerweise über das Internet erreichbar, so dass sich Anwender von außen damit verbinden können.

Der Netzwerk Controller übergibt diese Definitionen an die SLB VMs über das NC_Management Netz. Diese wiederum geben die PublicVIPs über das BGP-Protokoll bei einem zentralen BGP-Router bekannt, der die Verbindung zur Außenwelt bereitstellt. Die Kommunikation zwischen den SLB-VMs und dem BGP-Router wird typischerweise über ein eigenes logisches Netz mit dem Namen Transit abgewickelt.

Erreicht nun eine Anfrage den BGP-Router zu einer ihm bekannt gemachten öffentliche VIP-Adresse, leitet er diese über das Transit Netzwerk einer SLB-VM zur weiteren Bearbeitung weiter. Da alle SLB-VMs die gleichen Pool-Definitionen enthalten, bestehen also mehrere Wege für diese Weiterleitung. Wir sprechen deshalb hier auch von einem SLB Multiplexer oder SLB-MUX. Bei der Weiterleitung wird die Zieladresse der Anfrage mit der SLB-MUX Adresse im Transit Netz überschrieben.

Der SLB-MUX kann nun in Zusammenspiel mit den SLB Agents in den Hyper-V Switches entscheiden, an welche VM bzw. DIP die Anfrage zur Bearbeitung gegeben wird. In der Anfrage wird dazu die Zieladresse mit der ermittelten DIP überschrieben, das Datenpaket mit VXLAN verpackt und dem entsprechenden Hyper-V Host über das HNVPA-Netz übermittelt. Der Hyper-V Host entpackt das Paket und leitet es an die VM weiter.

Die VM erstellt nun eine Antwort, die als Ziel die ursprüngliche Client Adresse enthält und als Sender die eigene DIP. Der Switch im Hyper-V Host ersetzt diese DIP wieder mit der dem SLB-Pool zugeordneten PublicVIP und sendet das Paket dann über ein Gateway im öffentlichen Netz direkt an den Client, von dem die Anfrage kam. Der Client bekommt also nichts mit von den verschiedenen Weiterleitungsschritten innerhalb der SLB-MUX Umgebung.

Remote Access Service (RAS) Multitenant Gateways

In der vorstehenden Beschreibung für die Load Balancing Funktion habe ich kurz beschrieben, wie eine Anfrage eines einzelnen Clients aus dem Internet in einer SDN-Umgebung bearbeitet wird. In vielen Fällen wird es jedoch notwendig sein, nicht nur von einem einzelnen Client System eine Verbindung zu den VMs eines Tenants herzustellen, sondern ganze externe Netzwerke mit den virtuellen Systemen eines Tenants zu verbinden.

Hierzu stellt der Netzwerk Controller die Funktion Remote Access Service (RAS) Multitenant Gateway bereit. Es handelt sich dabei (ähnlich den SLB-MUX Systemen) um eigene VMs, die über den Netzwerk Controller verwaltet werden. Damit können dann folgende Remote Szenarien realisiert werden:

• Site-to-Site VPN
• Point-to-Site VPN
• GRE Tunneling
• ​Dynamic Routing mit dem Border Gateway Protocol (BGP)

Ich werde hier nicht näher auf diese Themen eingehen, da wir dazu entsprechende Remote Systeme benötigen, deren Konfiguration weit über das Thema SDN hinausgehen. Vielleicht kommen wir in einem späteren eigenen Beitrag darauf zurück.

SDN-Topologie

Nachdem wir nun einige grundlegende Merkmale der Microsoft SDN Architektur geklärt haben, wollen wir uns kurz anschauen, wie dies alles in eine physikalische Umgebung abgebildet werden kann.

Logische Netze

Fassen wir zusammen, welche logischen Netze in einer SDN-Umgebung notwendig sind:

• NC_Management – Dies ist das zentrale Netzwerk, über das alle Systeme in einem „Software Defined Datacenter“ (SDDC) verwaltet und konfiguriert werden, also die Netzwerk Controller mit den SDN-Komponenten wie SLB-MUXe und Gateways, die Hyper-V Hosts, aber auch weitere Infrastruktursysteme wie Active Directory, DNS und der SCVMM. Der Netzwerk Controller erhält und verteilt über dieses Netz auch die Anweisungen für die SDN-Komponenten.
• HNVPA – Über dieses Netz laufen die mit dem VXLAN-Protokoll verpackten Netzwerkpakete der Tenant VMs zwischen den Hyper-V Hosts.
• Transit – Dieses Netz wird verwendet für die Kommunikation zwischen den SLB-MUX Systemen und der Außenwelt, z.B. mit einem BGP-Router, der mit dem Internet verbunden ist.

Diese 3 logischen Netze bilden das Rückgrat von SDN. Sie müssen in allen beteiligten Hyper-V Hosts verfügbar und dort mit den virtuellen Switches verbunden sein. Diese Netze besitzen jeweils einen eigenen IP-Adresspool. Zusätzlich können sie optional durch VLANs untereinander isoliert sein, was jedoch kein Muss ist (in der später noch zu beschreibenden Lab-Umgebung werde ich darauf verzichten).

Für spezielle Szenarien sind gegebenenfalls weitere logische Netze notwendig, die dann aber nicht in den Hyper-V Hosts verfügbar sein müssen:

• PublicVIP – Dieses Netz stellt das Tor zum und vom Internet dar. Bei den verwendeten IP- Adressen wird es sich also in der Praxis um öffentliche Adressen handeln und es gibt auch keine Isolation mit VLAN IDs. 
• PrivateVIP – Dieses Netz enthält private Adressen, über die interne Clients wie z.B. die SLB Manager und andere interne Dienste miteinander kommunizieren können.
• GREVIP – Dieses Netz enthält virtuelle IP-Adressen für Endpunkte von Site-to-Site (S2S) Verbindungen mit externen (Tenant) Netzen, bei denen das GRE-Protokoll verwendet wird.

Neben diesen SDN-spezifischen logischen Netzen wird es in einem Rechenzentrum weitere logische Netze z.B. für die Storage Anbindung geben, die wir hier aber nicht weiter betrachten wollen.

Hyper-V Hardware

Für den Aufbau einer SDN-Umgebung benötigen wir eine Reihe von Hyper-V Hosts mit der Windows Server 2016 Datacenter Edition. Es sollten wenigstens 3-4 Systeme verfügbar sein, die idealerweise in einem Hyper-V Failover Cluster zusammengefasst sind. In einer produktiven Umgebung wird man natürlich deutlich mehr Systeme einsetzen.

Netzwerk Hardware

Eigentlich stellt SDN keine speziellen Anforderungen an die Netzwerk Hardware in den Hyper-V Hosts. Jedoch muss man berücksichtigen, dass der gesamte SDN-Netzwerkverkehr über die virtuellen Switches in den Hyper-V Hosts läuft und deshalb eine hohe Bandbreite und Verfügbarkeit erfordert. Deshalb sollte man über Teaming der in den Hyper-V Hosts verbauten Netzwerkadapter als Option nachdenken, was aber nicht zwingend ist. 

Für Teaming kann sowohl das „klassische“ Teaming auf Basis des Windows Betriebssystems als auch das „Switch Embedded Teaming“ (SET) im Hyper-V Switch von Server 2016 zum Einsatz kommen. Letzteres ist natürlich vorzuziehen, wenn dies mit den vorhandenen Netzwerkadaptern möglich ist.

Putting It All Together

Wenn wir alle vorstehend beschriebenen Komponenten in einerSDN-Umgebung zusammenfassen, dann ergibt sich folgendes Bild für die SDN-Topologie:

Quelle: https://docs.microsoft.com/en-us/windows-server/networking/sdn/plan/plan-a-software-defined-network-infrastructure#network-controller-software-load-balancer-and-ras-gateway-deployment

 Die unterste Ebene zeigt das physikalische Netz und die darin eingebetteten logischen SDN-Netze. Mit diesem Netz sind die Netzwerkadapter aller Hyper-V Hosts verbunden, gegebenenfalls auch als Team. Wenn Sie die logischen SDN-Netze als VLANs definiert haben, ist es wichtig, dass für die Ports an den physischen Switches, mit denen die Hyper-V Hosts verbunden sind, der Trunk Mode eingestellt ist. Nur dann sind in den virtuellen Hyper-V Switches alle SDN-Netze verfügbar.

Die virtuellen Hyper-V Switches präsentieren die SDN-Netze den im Host laufenden Infrastruktur VMs wie Netzwerk Controller, SLB-MUXe oder Gateways, so dass sie sich mit ihren virtuellen Netzwerkadaptern damit verbinden können.

Die virtuellen Netzwerkadapter von Tenant VMs sind im Hyper-V Switch mit dem HNVPA Netz verbunden. Das Ver- und Entpacken der Tenant Daten mit dem VXLAN-Protokoll erfolgt dann im virtuellen Hyper-V Switch.

Weitere Infrastruktursysteme

Außer den Hyper-V Compute Systemen benötigen wir noch einige weitere Infrastruktursysteme:

• Active Directory mit DNS
• Ein System mit dem System Center Virtual Machine Manager (SCVMM) 2016 für das Management der SDN-Umgebung
• Einen BGP-Router, der uns die Verbindung zum öffentlichen Netz bereitstellt.

Auf diese Systeme werde ich im nächsten Blogpost wieder zurückkommen, wenn wir unsere Lab-Umgebung aufbauen.