© ANTONIO BALAGUER SOLER, 123RF

Das Netzwerk ist in vielen Bereichen der IT in den Fokus geraten. Schuld daran sind der Siegeszug der Virtualisierung, der Trend zu Software Defined Storage und Themen wie Industrie 4.0. Mit Software Defined Networking (SDN) existiert eine Architektur, die verspricht neue Anforderungen zu bewältigen.

Ganz allgemein gesprochen ist die IT-Infrastruktur für drei Aufgaben verantwortlich: Verarbeitung, Speicherung und Transport von Daten. In der Zeit vor der Virtualisierung der x86-Rechner war die IT-Landschaft mehr oder weniger statisch. Sowohl die Planung als auch die Implementierung von Veränderungen oder Erweiterungen lief über Monate oder gar Jahre, angefangen bei der Bestellung über die Lieferung bis zur physikalischen Installation der neuen Hardware. Mit VMware, KVM oder Hyper-V ([1], [2], [3]) hat sich das radikal geändert, denn damit ist es einfach, neue Rechner aus dem Boden zu stampfen.

Diese mit ein paar Klicks neu kreierten Rechner benötigen aber in den allermeisten Fällen nach wie vor eine IP-Adresse und die Integration in ein Netzwerk. Das dauerte früher samt physischem Ab- und Aufbau und Verkabelung bestenfalls Stunden, eher aber Tage. In der virtuellen Welt bemisst sich das Zeitlimit nach Minuten oder gar Sekunden.

Die Netzwerk-Infrastruktur muss mit dieser Dynamik umgehen, aber die traditionellen Ansätze und Konzepte sind dafür viel zu langsam. Hinzu kommt, dass auch andere Entwicklungen zur Beschleunigung beitragen, darunter der Siegeszug der Smartphones, auch verbunden mit BYOD (Bring Your Own Device, [4]). Hier geht es ebenfalls um das Einbinden und die Verwaltung von Geräten, die quasi aus dem Nichts auftauchen und wieder verschwinden.

Zugleich müssen bestimmte Verbindungen nicht nur sofort, sondern auch sicher und verlässlich funktionieren (siehe Kasten “Aber sicher doch!”). Die Reihe von Beispielen für die Notwendigkeit, neuartige Verfahren für die Netzwerkverwaltung zu finden, ließe sich fortsetzen. Ein Schlüsselfaktor aller Lösungen ist die Abstraktion von der Netzwerk-Hardware. Genau hier tritt SDN [5] auf den Plan.

Was bisher geschah

Dieser Artikel beschränkt sich auf IP-basierte Netzwerke, bei denen es eine Reihe autonomer Systeme gibt – typischerweise Switches, Router und Firewalls. Sie empfangen, prozessieren und verteilen Datenpakete. So analysieren sie Herkunft und Ziel und schlagen vor der Weiterleitung eventuell in Tabellen und Regelwerken nach.

Damit das funktioniert, müssen diese Systeme die Netzwerk-Topologie (zumindest teilweise) kennen. Funktion und Position eines Geräts im Netzwerk sind unmittelbar miteinander verbunden. Die Änderung der einen hat direkte Auswirkung auf die andere. Mit der Rechner-Virtualisierung ist die Neupositionierung eines Geräts im Netzwerk im Handumdrehen zu erledigen, das Device kann dadurch sowohl seine Position als auch seine Funktion ändern.

Doch das ist noch nicht alles. Das Netzwerk hat sich im Laufe der Zeit entwickelt. Damit dies kontrolliert geschieht, gibt es die IETF (Internet Engineering Task Force, [6]). Sie hat eine Reihe Protokolle entwickelt, um die einfache Steuerlogik aufzupeppen. Diese Erweiterungen adressieren oft nur eine bestimmte Aufgabe und wirken isoliert.

Die wachsende Anzahl dieser Standards, gepaart mit den herstellerspezifischen Optimierungen und Software-Abhängigkeiten, haben die Komplexität heutiger Netzwerke enorm vergrößert. Zudem haben sie nahezu jede Flexibilität verloren. Strukturelle Änderungen sind riskant und ein mittelgroßes Projekt.

Getrennt marschieren, vereint netzwerken

Die Grundidee von SDN ist schon fast zehn Jahre alt und stammt aus der Stanford University. Damals beschrieb Martin Casando die Idee der Trennung von Datenfluss und der zugehörigen Kontroll-Logik in seiner Doktorarbeit [7]. Er und seine Betreuter Nick McKeown und Scott Shenker gelten als die Väter von SDN. Kenner der Szene wissen, dass die genannten Personen auch eine Firma namens Nicira Networks gegründet haben, die inzwischen zu VMware gehört und die Basis von NSX [8] ist.

Etwas allgemeiner formuliert ist die Idee von SDN die Trennung von Konfiguration und Infrastruktur (Abbildung 1). Die Literatur verwendet hier die Begriffe Controlplane und Dataplane. Zur Letzteren gehören Geräte wie Firewalls, Switches oder Router. In einem SDN ist die auf ihnen vorhandene Kontroll-Logik aber deutlich beschränkt oder im Extremfall gar nicht vorhanden. Dafür ist die Controlplane zuständig. Die dummen Netzwerkgeräte kommen im Ergebnis mit einer viel einfacheren Firmware aus. Befreit vom Denken können sie sich auf das Weiterleiten der Datenpakete konzentrieren.

Abbildung 1: Die Architektur von Software Defined Network.

Die Intelligenz steckt in der Controlplane, die man sich als entsprechend potente Rechner mit Kontrollsoftware vorstellen kann. Sie geben die Richtlinien für den Empfang, die Verarbeitung und Weiterleitung der Datenpakete vor. Damit dies auch funktioniert, müssen Kontroll-Logik und Netzwerkgeräte miteinander kommunizieren. Die Schnittstellen sollten dabei bekannt und standardisiert sein, sodass beliebige Hersteller einfach darauf aufbauen können. Eine Vorreiter-Rolle spielt hier Open Flow [9].

Die Erfahrung hat gezeigt, dass es auch eine Art Aufsichtsinstanz geben muss, die die Entwicklung der Schnittstellen unterstützt, aber auch steuernd eingreift, wenn es in die falsche Richtung geht. Diese Aufgabe übernimmt für SDN seit über fünf Jahren die Open Networking Foundation (ONF, [10], [11]). Mit Google, Facebook, Microsoft, Deutsche Telekom, Verizon und Yahoo sind echte Schwergewichte als Gründungsmitglieder beteiligt.

Auf der Habenseite

Zu den schon genannten Vorteilen von SDN kommt die deutlich geringere Abhängigkeit von den Hardwareherstellern – das Gehirn steckt ja in der Controlplane. Außerdem ist die Entkopplung der Lebenszyklen der Netzwerk-Hardware und der logischen Topologie darüber vorteilhaft. Standardisierte Schnittstellen eröffnen zudem neue Möglichkeiten für die Automatisierung, idealerweise nahezu Hardware-agnostisch.

Der Admin legt einfach eine neue Richtlinie in der Controlplane fest. Die übermittelt die notwendigen Informationen an die jeweiligen Endgeräte. Die Separation der Kontroll-Logik erlaubt deren Zentralisierung. So erhält der Admin auf einfache Weise ein Gesamtbild seines Netzes. Die Informationen, die in der Prä-SDN-Ära über vielleicht Hunderte Geräte verteilt waren, sind nun im günstigsten Fall an einer Stelle abrufbar.

Der eigentliche Clou kommt aber noch: SDN führt eine Abstraktion ein, die das Netzwerk einfacher verständlich und übersichtlicher macht. Im traditionellen Ansatz musste die IT-Abteilung einen Geschäftsprozess letzten Endes auf Routingtabellen und Firewallregeln runterbrechen. Dabei waren diese noch über alle möglichen Geräte verteilt. Konsument (der Geschäftsprozess) und Dienstleister (der Netzwerk-Administrator) sprachen komplett verschiedene Sprachen.

Bei SDN dagegen versteht die Applikation die Topologie (Abbildung 2) und kann entsprechend auf Veränderungen reagieren oder diese sogar selbst einleiten. Neuere Beschreibungen von SDN führen hier den Begriff Applicationplane ein.

Abbildung 2: Eine aktuellere Sicht auf SDN (Software Defined Network).

Betriebsmodelle

Gibt es denn gar keine Schattenseiten bei so viel Licht? Doch natürlich! Eine bekannte Herausforderung von Zentralisierung ist deren Absicherung. Was passiert, wenn die Controlplane ausfällt? Wäre damit nicht der GAU programmiert? Wie sehen die notwendigen Hochverfügbarkeitskonzepte aus? Wenn mehrere Kontrollinstanzen beteiligt sind, stellt sich sofort die Frage, wie viele es denn sind? Wie sieht es mit der Skalierbarkeit aus? Ganz kritische Stimmen fragen auch nach dem Mehraufwand der Kommunikation zwischen Kontroll-Logik und Infrastruktur. Doch eins nach dem anderen: Es gibt verschiedene Ansätze für den Betrieb von SDN.

Im so genannten symmetrischen Modell ist die Kontrollinstanz so weit wie möglich zentralisiert. Die Vorteile hat dieser Artikel schon beschrieben, nachteilig ist die zentrale Störanfälligkeit. Hier will das asymmetrische Modell helfen. Bei ihm verfügen die Elemente der Dataplane über genug Informationen für den unmittelbaren Betrieb. Die einzelnen Systeme kennen die relevanten Konfigurationen und können daher auch beim Ausfall der Kontroll-Logik funktionieren.

Dieser Ansatz harmoniert oft mit der Arbeitsweise der Administratoren, die das Netzwerk sowieso in Zellen organisieren, die autonom arbeiten können. Die größere Unabhängigkeit von der zentralen Controlplane hat allerdings auch ihren Preis. Der liegt in der Redundanz von Informationen und der stärker dezentralisierten Verwaltung.

Ein ganz anderer Ansatz unterscheidet nach der Position der Kontroll-Logik. Bei hochgradig virtualisierten Umgebungen ist es sinnvoll, den Hypervisor beziehungsweise den Host die notwendige Denkarbeit verrichten zu lassen. Der andere Ansatz ist Netzwerk-zentriert. Hier erledigen dedizierte Netzwerkgeräte den SDN-Job. Eine Mischung ist auch denkbar, schmälert aber den Gewinn.

Die dritte Dimension der SDN-Betriebsmodelle nutzt die Verteilung der Informationen als Unterscheidungsmerkmal. Das kann entweder proaktiv oder reaktiv sein. Beim letzteren Ansatz empfängt das Netzwerkgerät ein Datenpaket und fragt bei der Controlplane nach, wie weiter zu verfahren ist. Der Vorteil ist, dass nur die benötigten Informationen über das Netz wandern. Gibt es allerdings hier Probleme, kommt es zu Verzögerungen bei der Zustellung.

Alternativ kann die Kontroll-Logik die Dataplane vorausschauend mit allen Informationen versorgen. Das erfolgt typischerweise über die bekannten Broad- und Multicast-Mechanismen. Die Vor- und Nachteile sind analog zum weiter oben beschriebenen asymmetrischen Betriebsmodell.

Was am Ende übrig bleibt

In den letzten fünf Jahren hat sich im SDN-Umfeld viel getan. Die Produktseite der ONF [15] ist inzwischen recht lang und listet nicht nur die üblichen Verdächtigen aus dem Netzwerkbereich. Open Flow brachte zwar Standardisierung, aber die Implementierung durch die Hersteller war und ist leider noch nicht schmerzfrei. Seit einiger Zeit taucht SDN im Gespann mit NFV (Network Function Virtualisation, [16]) auf. Beide stehen ganz oben auf den Themenliste von Telekommunikationsgrößen. Auch die Open-Stack-Gemeinde zeigte in den jüngsten Umfragen großes Interesse.

Ein Stillstand oder gar Verschwinden der Ideen von SDN ist damit ziemlich ausgeschlossen. Klassische Umgebungen tun sich allerdings immer noch recht schwer, den traditionellen Ansatz zu verlassen. Das notwendige Umdenken in den Köpfen geht manchmal deutlich langsamer als die Entwicklung der Technologie. Wer sein Netzwerk für die Zukunft plant, der kommt an SDN nicht vorbei. (jcb)