Serie Software-Defined Networking, Teil 1
SDN startet durch
Das Software-Defined Networking (SDN) hat sich innerhalb weniger Jahre vom akademischen Experiment zum Agendapunkt vieler Netzwerkverantwortlicher gemausert. Auch die Carrier-Variante NFV (Network Functions Virtualization) setzt gerade zum globalen Siegeszug an. Deshalb widmet sich LANline in einer neuen Artikelserie dem softwaregesteuerten Netzwerk, dessen zwei Spielarten mehr Agilität und schnellere Service-Rollouts versprechen.
Software-Defined Networking, ursprünglich Mitte der 2000er-Jahre an der Stanford University konzipiert, soll im Netzwerk für mehr Flexibilität sorgen. Dazu entkoppelt SDN die Control Plane von der Data Plane und somit die Intelligenz des Netzwerkbetriebs von der Aufgabe der reinen Weiterleitung von Datenpaketen [1]. Als zentrale Komponente bündelt ein sogenannter SDN Controller die Steuerungsaufgaben und gibt dem Netzwerk-Equipment Anweisungen, wohin, mit welcher Service-Qualität und unter welchen Bedingungen der Datenverkehr zu fließen hat.
Das Versprechen des SDNs ist es somit, den Management-Aufwand im Netzwerkbetrieb deutlich zu senken, indem zum Beispiel VLANs und Traffic-Engineering-Einstellungen nicht mehr manuell an den einzelnen Geräten zu konfigurieren sind. So soll das Netzwerk ähnlich dynamisch zu verwalten sein, wie dies im RZ durch Server-Virtualisierung und Software-Defined Storage bereits Usus ist. Unter dem Strich soll dies ein dynamisches Gesamtsystem ermöglichen, von manchen Anbietern als "Software-Defined Datacenter" bezeichnet, das schnell auf veränderliche Anforderungen reagieren kann, wie sie im Cloud-Umfeld auftreten.
Innerhalb einer SDN-Architektur unterscheidet die Fachwelt zwischen Northbound- und Southbound-Kommunikationsströmen: Southbound bezeichnet die Kommunikation zwischen Controller und Switch, Northbound jene zwischen dem Netzwerk und höherliegenden Schichten, also letztlich den Applikationen. Für die Southbound-Kommunikation hat sich inzwischen Openflow, verwaltet und propagiert von der Open Networking Foundation (ONF) [2], als Standardprotokoll etabliert, während sich in der Northbound-Richtung Openstack von der Openstack Foundation [3] als Protokoll-Stack der Wahl durchzusetzen scheint. Der Orchestrierung der SDN-Landschaft wiederum widmet sich das Opendaylight-Projekt [4] mit der gleichnamigen Software.
Neben der rein technischen Agilität im Handling des Datenverkehrs soll das SDN den Unternehmen aber auch noch eine ganz andere Art von Flexibilität ermöglichen: Die Abstraktion der Netzwerk-Services von der Netzwerk-Gerätschaft soll die IT-Organisationen in die Lage versetzen, bei der Einführung neuer Services auf spezialisierte Softwareanbieter zu bauen und somit von den Roadmaps und Entwicklungszyklen der Netzwerkausrüster unabhängiger zu werden. Ziel ist es hier, Funktionalität nachrüsten zu können, ohne dass der Administrator darauf warten muss, bis der Switch-Anbieter seines Vertrauens diese Funktion in seinem Switch-OS abbilden kann.
Flexibler Softwareeinsatz
SDN wirbelt damit die Netzwerkwelt ähnlich stark durcheinander wie die Server-Virtualisierung vor einigen Jahren die vormals wohlgeordnete Ruhe unterforderter x86-Maschinen. Aufgrund des Zeitversatzes ist der SDN-Markt aber noch vergleichsweise jung, entsprechend unübersichtlich ist die Gemeinde der SDN-Player.
Vorreiter waren Cloud-Größen wie Google und Facebook, die mit ihrem Wunsch nach agileren Netzen den SDN-Ball einst ins Rollen brachten. So betreibt Google bereits seit 2011 den weltweit ersten Openflow-gesteuerten WAN-Backbone mit dem Ziel schnellerer Roll-outs, verbesserten Traffic Engineerings mit kürzeren Wiederherstellungszeiten sowie niedrigerer Komplexität und Kosten [5]. Anfangs hatte die Cloud-Größe mit den Kinderkrankheiten von Openflow zu kämpfen, zeigte sich aber schon damals zuversichtlich bezüglich deren Überwindung.
Auch Facebook stieß bald an die Grenzen herkömmlicher Vernetzung und entwickelte deshalb selbst Netzwerkhardware und -software, beginnend mit einem eigenen Top-of-Rack-Switch ("Wedge"), Linux-basierter Switching-Software ("Fboss") und einer Switching-Fabric. Kürzlich hat der Cloud-Konzern dies um einen modularen, "6-Pack" genannten Switch ergänzt [6]. Als erster "offener" Chassis-Switch verbindet 6-Pack laut Facebook-Angaben zwölf unabhängige Line-Cards auf Wedge-Basis zu einem blockierungsfreien Gesamtsystem mit dualer Backplane und 1,28 TBit/s Durchsatz. Facebook betreibt ihn in zwei Konfigurationen: einmal mit 16 frontseitigen und ebenso vielen rückseitigen 40GbE-Ports, die andere für Aggregationszwecke mit der gesamten 1,28 TBit/s-Kapazität auf der Rückseite.
Jedes Element laufe dabei mit seiner eigenen Betriebssysteminstanz, beinhalte eine vollständige lokale Control Plane auf einem Micro-Server und einem Switching-ASIC und kommuniziere mit einem zentralen SDN-Controller, so Facebook. Durch diese Hybrid-SDN-Konfiguration lasse sich das Netzwerk einfach und flexibel betreiben, auch sei es dadurch sehr stabil und hochverfügbar: Die Administration könne jede Komponente ändern, ohne das Gesamtsystem zu beeinflussen.
Die Betreiber von Mega-Rechenzentren wie Google und Facebook haben natürlich sehr extreme Anforderungen an ihre Netzwerkinfrastruktur, die allein durch die Skalierung, aber auch durch die spezifischen Aufgaben der Cloud-Services stark vom Bedarf herkömmlicher Unternehmen abweichen. Dennoch fallen SDN-Argumente inzwischen auch bei anderen (Cloud-)Service-Providern sowie im Unternehmensumfeld auf fruchtbaren Boden.
Teil 2 dieser Serie wird sich deshalb in der kommenden LANline-Ausgabe mit dem SDN-Anbieterumfeld, den Einsatzmöglichkeiten von SDN im Datacenter und im Campus sowie der besonderen Rolle von Cisco in diesem Kontext beschäftigen. Teil 3 wird dann einen näheren Blick auf die NFV-Welt und die dort erwartete Vereinfachung von Netzwerk- und Cloud-Services werfen.
Der Autor auf LANline.de: wgreiner
Lesen Sie mehr zum Thema
