Microsofts Windows-Azure-Netzwerk steuert ein riesiges virtuelles SDN

Microsoft gewährt Einblick in das Netzwerk von Windows Azure und zeigt, wie ein riesiges Software-defined Network Microsofts Cloud-Plattform steuert.

Auf dem Open Networking Summit hat Microsoft enthüllt, welches virtuelle Software-defined Network hinter der über viele Data Center verteilten Microsoft-Cloud Windows Azure steckt.

Die virtuelle SDN-Architektur des Windows-Azure-Netzwerks erzielt Skalierbarkeit durch die massive Verteilung sowohl der Controller- als auch der Daten-Ebene des Netzwerks. Es besitzt mehrere zu einem Bund vereinte Controller, wovon jeder speziellen Applikationen, Services oder Funktionen zugewiesen ist. Die Daten-Schicht und auch alle Layer-4- bis Layer-7-Services und -Policies sind in jedem Hypervisor-Host der Azure-Data-Center implementiert.

Virtuelle Netzwerk-Controller und Load Balancing durch die Northbound-API

Microsofts virtuelle SDN-Steuerebene beinhaltete spezielle, zu einem Bund vereinte Controller, so Albert Greenberg, Partner Development Manager bei Microsoft: „Es gibt nicht einfach nur einen Controller. Sie sind Applikations-spezifisch und sie sind gebündelt.  Wenn sie durch die Northbound-API kommen erhalten Sie einen virtuellen Netzwerk-Controller und einen Load-Balancing-Controller, die beide unterschiedliche Aufgaben wahrnehmen und in kleinen Clustern arbeiten. Regionale Controller wiederum verwalten diese und untergliedern das Netzwerk.“

Microsoft hat sich bei der Herangehensweise bezüglich der Forwarding Plane im Windows-Azure-Netzwerk von OpenFlow inspirieren lassen: „Die OpenFlow-Idee der Match-Action-Tables ist der richtige Schritt und so haben wir mehrere dieser Match-Action-Tables erstellt. Es gibt Tabellen für virtuelle Netzwerke, Load-Balancer, Network Address Translation (NAT) und Access Control Lists (ACLs). Wir können uns hunderte an Funktionen zu Nutze machen und die Dinge so ändern und implementieren, wie es mit reinen Hardware-Lösungen nicht machbar wäre.“, so Greenberg.

Die Ebene zur Daten-Weiterleitung kommuniziert nicht direkt mit Microsofts SDN-Controllern. Stattdessen setzt Microsoft auf jedem Hypervisor-Host virtuelle Netzwerk-Agents ein und der entsprechende virtuelle Netzwerk-Agent sendet den Daten-Strom an den vSwitch weiter. Passt der Datenstrom zu den Match-Action-Tables im vSwitch, führt dieser die notwendigen Transaktionen hinsichtlich der virtuellen Maschinen auf dem Host aus und die resultierenden Daten fließen dann über die Netzwerk-Karte des Servers. Kann der virtuelle Switch mit dem Flow nichts anfangen, dann schickt er eine so genannte Mapping-Anfrage an den Agent zurück, der wiederum einen Mapping-Service im Controller-Cluster adressiert.

„Windows Azures Daten-Schicht muss Pro-Flow-Policies zu Millionen virtueller Maschinen einspeisen.“, sagte Greenberg. „Wie adressieren wir Milliarden an Flows und übersetzen diese in Paket-Aktionen? Der Host führt alle Paket-Aktionen in seiner eigenen virtuellen Maschine aus, während für das SDN ein klein wenig der verteilten Computing-Leistung, die durch Millionen an Servern zur Verfügung steht, verwendet wird.“, erklärt Greenberg.

Southbound-API: Zwischen Agent und virtuellem Switch

Die Southbound-SDN-Schnittstelle im Windows-Azure-Netzwerk sitzt laut Greenberg zwischen Agent und virtuellem Switch. Somit kann Microsoft anstelle eines Wire-Protokolls eine hochperformante API auf Betriebssystem-Ebene verwenden. Die Wire-Protokolle finden für einfachere und weniger häufige Transaktionen zwischen Controller, Agent und dazugehörigen Services Verwendung.

Der virtuelle Cloud-Load-Balancing-Service von Windows Azure ist ein Beispiel dafür, wie das virtuelle SDN-Modell in einer massiven Cloud skalieren kann. Er wird auf jedem einzelnen Host im Data Center vorgehalten. „Wir verschieben die Network Address Translation Richtung virtuellem Switch, was die Load-Balancer wiederum zustandslos macht und eine direkte Rückkehr zum Client ermöglicht, während der Controller die entsprechenden Policies programmiert.“, fügte Greenberg an.

Die CPU-Leistung war für diesen Erfolg ebenfalls eine kritische Barriere. Microsoft adressiert dieses Problem, indem man das erste Paket eines Flows verwendet, um alle Tabellen-Informationen auszuloten. Die restlichen Pakete eines Flows können „effizient mithilfe von Caching durchflitzen“, so Greenberg.

Die Management-Schicht für das virtuelle SDN ist ein Front-End-Portal für Windows Azure, das für Self-Service-Orchestrierung verwendet wird. Mithilfe des Portals können Kunden ihre virtuellen Netzwerke und Policies durch ihre eigenen Enterprise-Adress-Schemata definieren. Das Portal schickt dieses virtuelle Netzwerk-Modell durch eine Northbound-API an Microsofts Cluster an SDN-Controllern, der das virtuelle Netzwerk steuert.

„Ein virtuelles Netzwerk ist ein Satz an Mappings, der aus dem Kunden-definierten Adress-Raum an den Provider weitergegeben wird. Dieser leitet das Konstrukt an die Hosts weiter, auf dem sich die virtuellen Maschinen befinden.“, erläuterte Greenberg.

Die Controller disponieren ebenso geeignete Policies in den Nodes der virtuellen Azure-Switche. Die Policies lassen sich nach der Aussage von Greenberg an die Betriebsumgebung des Kunden über ein ebenfalls dort vorhandenes VPN-Gateway zurückgeben.

Azures virtuelles Software-defined-Network ist das Ergebnis von 100 Entwicklern und Netzwerk-Technikern aus den Microsoft-Sitzen in Redmond und Dublin, die vier Jahre daran gearbeitet haben. Das virtuelle SDN treibt die öffentliche Azure-Cloud und alle anderen Microsoft-Services an, unter anderem Office365, die Suchmaschine Bing, Skype, OneDrive und Xbox Live.

Erfahren Sie mehr über Software-defined Networking

- GOOGLE-ANZEIGEN

ComputerWeekly.de

Close