Die Globalisierung der Firmen, die rasant ansteigende Menge von Geräten, Virtualisierung, Cloud und “Bring your own device” machen klassisch organisierte IP-Netze schwer plan- und administrierbar. Statt zu hadern, sollten sich Admins mit einem radikal neuen Ansatz befassen: Software Defined Networking.

Nicht nur einmal revolutionierten Virtualisierungstechniken in den vergangenen zehn Jahren die IT-Welt. Vor allem die x86-Architekturen zogen mit vielen Features, aber auch in Sachen Leistungsfähigkeit mit Mainframes und Großrechnern gleich, die derlei Ressourcenaufteilung bereits seit Jahrzehnten beherrschen. IBMs Z-Serie und ihre Vorläufer, die System/360-Maschinen, feiern just zur Cebit 2014 ihren 40. Geburtstag [1].

Server, Storage und Network

Virtualisierung als Konzept ist gleichermaßen einfach wie erfolgreich: Die Serverhardware existiert nicht real, sondern nur mehr als pure Software. Dabei treten die ursprünglich notwendigen Hardwaretreiber hinter die Virtualisierung zurück. Server-Umzüge sind so viel einfacher, herstellerspezifische Hardware-Limitierungen fast irrelevant.

Admins stampfen neue Server jetzt binnen Minuten aus dem Boden – das Konzept ist so erfolgreich, dass es auch andere Bereiche erfasst hat: Wie die vorige Ausgabe des Linux-Magazins am Beispiel von Open Stack zeigte [2], geht auch der Storage-Bereich seit ein paar Jahren einen ähnlichen, virtuellen Weg. Analog zur Virtualisierung ganzer Rechner ziehen Admins auch hier eine Abstraktionsschicht zwischen Datenträgern und dem Anwender oder der Applikation ein und gewinnen ähnliche Vorzüge wie im Server-Bereich.

Wenig überraschend macht der Trend auch vor dem Netzwerk nicht halt. Ganze Firmennetze existieren mittlerweile nur mehr virtuell, aus Software aufgebaut und per Mausklick konfigurierbar [3].

Quo vadis?

IP-Netzwerke bestehen in der Regel aus eine Reihe von autonomen Systemen: Switches, Routern und Firewalls. Die Netzwerkgeräte werten ankommende Datenpakete aus, schlagen eventuell in Tabellen nach und senden sie entsprechend weiter. Damit das funktioniert, müssen diese Systeme die Netzwerktopologie zumindest teilweise kennen (Abbildung 1). Die Position eines bestimmten Geräts im Netzwerk definiert dessen Funktion, ein Stellungswechsel hat unter Umständen fatale Folgen.

Abbildung 1: Ein traditionelles IP-Netzwerk besteht aus echten Geräten, die in Tabellen Informationen vorhalten und nach definierten Regeln kommunizieren.

Im Laufe der Zeit stellte die Internet Engineering Task Force (IETF, [4]) Admins eine Reihe von Protokollen zur Seite, um die einfache Steuerlogik aufzupeppen. Diese Erweiterungen adressierten jedoch oft nur eine bestimmte Aufgabe und wirken aus heutiger Sicht vergleichsweise isoliert. Hinzu kam, dass die wachsende Anzahl dieser Standards im Verbund mit herstellerspezifischen Optimierungen und Software-Abhängigkeiten die Komplexität heutiger Netzwerk anwachsen ließ.

Never touch a running network …

Ganz nebenbei blieb dabei nahezu jegliche Flexibilität auf der Strecke. Strukturelle Änderungen sind in vielen Netzen heute mindestens ein mittelgroßes Projekt, über dem das Damoklesschwert eines teuren und gefährlichen Betriebsausfalls hängt.

Mehr Peers und viele neue Datentypen

Auch die Welt außerhalb des Netzwerks stand nicht still. An die Stelle klassischen Client-Server-Verkehrs tritt eher Peer-artiger Datenfluss. Immer mehr Rechner und Anwendungen sind an der Kommunikation beteiligt. Die Servervirtualisierung schiebt Rechner hin und her und verändert so dynamisch ganze Bereiche der Netzwerktopologie. Smartphones und Tablet-PCs lassen die Anzahl der Teilnehmer explodieren.

Mit Software Defined Storage kommen ganz neue Datentypen hinzu, und Big-Data-Herausforderungen manifestieren sich in steigenden Datenvolumina, die schnell durchs Netzwerk müssen. Die Veränderung einer Richtlinie für das gesamte Netzwerk erfordert Konfigurationsanpassungen von Hunderten, vielleicht Tausenden von Systemen.

Und damit nicht genug: Die Cloud bringt noch weitere neue Herausforderung an das Netzwerk mit sich. Da wären beispielsweise hochgradige Flexibilität, Sicherheit, Konformität und Revisionsfähigkeit. All das ließ sich zwar auch in klassischen Netzwerken bewerkstelligen, aber nur durch eine Vielzahl von Mitarbeitern oder durch teure Managementlösungen – oder eben durch Virtualisierung auf der Netzwerkebene.

Divide et conquer

Die grundlegenden Ideen hinter dem Software Defined Networking (SDN) sind über sieben Jahre alt und stammen aus der Stanford University. Primäres Anliegen von SDN ist die Trennung von Konfiguration und Infrastruktur (Abbildung 2). In seiner Doktorarbeit [5] beschrieb Martin Casando 2008 die Idee der logischen Trennung der Kontroll-Logik vom Datenfluss. Casando und seine Betreuer – Nick McKeown und Scott Shenker – gelten daher als die Väter von SDN.

Abbildung 2: Die Architektur von Software Defined Networking ist flexibel, aber hierarchisch gegliedert.

Im selben Jahr gründeten sie die Firma Nicira Networks, die sich auf das neue Themengebiet konzentrierte. Um 2012 übernahm VMware diese Firma für sagenhafte 1,2 Milliarden Dollar [6]. Niciras Network Virtualisation Platform ist die Basis von VMwares NSX [7].

In der einschlägigen Literatur finden sich oft die Begriffe Control Plane und Data Plane. Letztere sind die Switches, Router und Firewalls. Die Control Plane befindet sich dagegen außerhalb der Netzwerkgeräte. Ihre Geräte brauchen daher nicht so viel eigene Intelligenz mitzubringen, wie dies im traditionellen IP-Netzwerk der Fall ist – die verbaute Firmware darf deutlich schlanker ausfallen.

Die physikalische Trennung von Kontroll- und Infrastruktur-Schicht (also Control Plane und Data Plane) erlaubt es darüber hinaus, auch die darunter liegende Hardware unabhängig zu tunen, weil der leistungsfähige Rechner mit der Kontroll-Software die Arbeit erledigt. Die Data Plane leitet lediglich die Datenpakete weiter, nach den Richtlinien der Kontroll-Logik.

Das bedeutet aber auch, dass beide Instanzen miteinander kommunizieren müssen. An dieser Stelle kommt Technologie wie Open Flow ([8], siehe Kasten “Offene Flüsse”) ins Spiel und definiert eine Standardschnittstelle für diesen Informationsaustausch.

Die oben genannten Wissenschaftler um Shenker beteiligten sich konsequenterweise auch an der Gründung der Open Network Foundation im März 2011. Ziel der Non-Profit-Organisation ist die Unterstützung und Überwachung der Schnittstellen und Standards für SDN. Mit Google, Facebook, Microsoft, der Deutschen Telekom, Verizon und Yahoo sind echte Schwergewichte als Gründungsmitglieder engagiert.

Pro et contra

SDN ist beliebt, nicht nur wegen der inhärent geringeren Abhängigkeit von den Herstellern der Netzwerkhardware. Die Intelligenz ist nun im Controller beheimatet, der über standardisierte Schnittstellen die notwendigen Informationen mit den Geräten austauscht. Admins freuen sich, weil das auch die Entwicklung des eigenen Netzwerks vom Lebenszyklus der darunter liegenden Hardware entkoppelt – wie bei der Servervirtualisierung auch. Das Trennen von Datenfluss und Kontroll-Logik zentralisiert das Management und erlaubt es dem Administrator, sein Netzwerk in seiner Gesamtheit zu überblicken und zentral zu verwalten. Die vorher autonomen Systeme werden damit Teile eines sich zusammenfügenden Puzzles.

Für Admins entstehen ganz neue Möglichkeiten, die Datenflüsse effizienter zu gestalten. Eine Firewall muss nun nicht mehr jedes Paket untersuchen, wenn vorherige Prüfungen erfolgreich waren und ausreichend sind. Die Abstraktion von den (herstellerbedingten) Gegebenheiten der einzelnen Netzwerkgeräte erlaubt nun Konfigurationen zu automatisieren, die vorher unmöglich waren.

Richtlinien legt der Netzwerk-Admin über die Kontroll-Logik fest. Diese übermittelt die notwendigen Informationen über die standardisierten Schnittstellen an die jeweiligen Endgeräte. Eigenschaften oder sogar einzelne Dienste sind nicht mehr auf Port-Ebene definiert, sondern an zentraler, vielleicht sogar globaler Stelle. Letztlich stellt SDN eine Abstraktion der Netzwerkschicht bereit, was das Verwalten aus Geschäftsprozessen heraus erlaubt (das wäre die Anwendungsschicht in Abbildung 2). So lässt sich auch das Netzwerk auf eine Anwendung zuschneiden, denn diese kennt ja die Fähigkeiten des Netzes.

Kritik

Aber es gibt auch einige Kritikpunkte oder zumindest offene Fragen. Der Controller ist nun das Hirn des Netzwerks – und damit der Single Point of Failure: Fällt er aus, ist der GAU vorprogrammiert. Ihn ohne Hochverfügbarkeits-Konzepte zu betreiben, erscheint mutig bis fahrlässig. Weitere Fragen stellen sich fast von selbst: Wie viele Geräte kann eine Kontrollinstanz verwalten? Wie organisiert man die Kontrollinstanzen, damit sie hochverfügbar und zudem skalierend sind? Der Anteil der Kommunikation von Control- und Data Plane macht, glaubt man der Literatur, typischerweise 3 bis 5 Prozent des Traffics aus.

Für den Einsatz von SDN gibt es mehrere Ansätze. Die Unterschiedlichkeit trägt dabei teilweise den eben genannten Kritikpunkten Rechnung. Das symmetrische Modell zentralisiert die Kontrollinstanz so weit wie möglich, wobei natürlich die Störanfälligkeit den offensichtlichsten und im Alltag vielleicht auch gravierendsten Nachteil ausmacht.

Das zu lindern versucht der asymmetrische Ansatz, bei dem die einzelnen Systeme die relevanten Konfigurationen kennen und daher auch beim Ausfall der Kontroll-Logik weiterarbeiten. Typischerweise organisiert der Administrator sein Netzwerk in Zellen, die – für sich genommen – autonom arbeiten. Nachteile dieser Lösung sind die eigentlich unnötige Redundanz von Informationen und das Mehr an dezentraler Verwaltung.

Eine weitere Unterscheidung lässt sich bezüglich des Ortes machen, an dem das SDN-Hirn liegt. Bei hochgradig virtualisierten Umgebungen ist es sinnvoll, dem Hypervisor beziehungsweise dem Host die notwendige Denkarbeit aufzubrummen. Anders der Netzwerk-zentrierte Ansatz: Hier erledigen dedizierte Netzwerkgeräte den SDN-Job. Auch eine Mischung ist denkbar, selbst wenn sie den Gewinn durch Software Defined Networking schmälert.

Eine dritte Art, SDN-Modelle zu unterscheiden, betrifft die Verteilung der Informationen. Einerseits können die Controller die Informationen über die bekannten Broad- und Multicast-Mechanismen verbreiten. Das führt aber zum erwähnten Anstieg der Netzwerklast. Die Alternative dazu besteht in verteiltem Hashing und verteilten Nachschlagetabellen, was deutlich weniger Informationen übers Netz schickt. Dieser so genannte Floodless-Ansatz ist weniger zentral, bringt dafür aber die gleichen Nachteile wie das asymmetrische Modell mit sich.

Geglückter Start

Seit 2011 hat SDN so richtig Fahrt aufgenommen. Insbesondere auf der Controller-Seite haben Netzwerkarchitekten die Qual der Wahl. Die Open-Source-Community kann auf Projekte wie Floodlight [10], Beacon [11] oder Open Daylight [12] verweisen. Auch kommerzielle Produkte gibt es, natürlich sind neben VMware auch Cisco [13], HP [14], IBM [15] und Brocade [16] dort vertreten.

Die Netzwerkgeräte-Seite lässt noch genügend Raum für Verbesserung. Leider ist die Anzahl der SDN-fähigen Switches noch recht übersichtlich. Die Gründungsmitglieder der Open Networking Foundation arbeiten mit Nachdruck daran, die eigenen Netze auf das Paradigma umzustellen, flächendeckende praktische Erfahrung mit dem neuen Ansatz zum Netzwerkeln fehlen jedoch.

Aber immerhin hat das Cloud Computing Bewegung in die Sache gebracht. Open Stack [17] mit seiner Netzwerk-Komponente Neutron [18] ist nur die Spitze des Eisbergs.