Software-Defined Networking – von der Theorie zur Praxis

Kommentieren Drucken

Unter Software Defined Networking (SDN) versteht man im Wesentlichen die Einführung von Abstraktionsebenen in Netzwerk-Komponenten und weiterführend eine Trennung der Control Plane von der Data Plane.

Die Trennung der verschiedenen Ebenen ermöglicht es auf Basis der standardisierten Schnittstellen eine Interoperabilität zwischen verschiedenen Komponenten zu schaffen. Die unterste Ebene ist die Hardware oder Data Plane. Sie ist für das reine Forwarding auf Basis von definierten Policies oder Flows zuständig. Die Data Plane trifft keine Entscheidungen, sondern ist sozusagen das ausführende Organ.

Über der Data Plane sitzt die Control Plane. Die Control Plane ist sozusagen das Netzwerk Betriebssystem. Sie trifft die Entscheidungen und definiert die Flows, die im Netzwerk erlaubt und nötig sind. Die Control Plane kommuniziert mit der Data Plane über die so genannte Southbound API als Schnittstelle. Vielfach wird die Control Plane in SDN Umgebungen auch einfach als Controller bezeichnet. Vor Allem, wenn es sich um eine einzige zentrale Instanz handelt.
Nach oben hin kommuniziert die Control Plane oder der Controller über das so genannte Northbound API mit den Applikationen. Dabei können auch klassische Router Funktionalitäten wie OSPF oder BGP als Applikationen betrachtet werden.

Was ist also die Motivation hinter der Zentralisierung?
Die Anforderungen an die Netze haben sich in den letzen Jahren grundlegend geändert. Heutige Netze sind bei Weitem komplexer als sie es noch vor einigen Jahren waren. Es gibt bei Weitem mehr Applikationen mit unterschiedlichen Anforderungen. Durch die zunehmende Virtualisierung in den Bereichen Server, Desktop und Storage müssen Netze heute flexibler sein. Die erwartete Dienstgüte verbunden mit gestiegenen Anforderungen an die Sicherheit bedeutet einen deutlich höheren Konfigurationsaufwand als in der Vergangenheit. Clouddienste verlangen die Provisionierung von virtuellen Maschinen im Netz. Gleichzeitig sehen sich jedoch nahezu alle Netzbetreiber mit dem Problem mangelhafter Ressourcen und Budgets konfrontiert. Alles in allem können wir derartigen Anforderungen nur durch einen steigenden Grad von Automatisierung begegnen. Dabei ist die dezentrale Control Plane kein optimaler Ansatz mehr. In einem klassischen Netz muss jede Komponente einzeln konfiguriert werden, da sie jeweils für sich eine autonome Instanz darstellt. Das führt zu enormem Aufwand und langsamen Reaktionsgeschwindigkeiten. Eine Automatisierung kann hier Abhilfe schaffen. In diesem Zuge ist eine zentrale Control Plane natürlich eindeutig im Vorteil. Es gibt eine zentrale Instanz, die das gesamte Netzwerk kontrolliert. Also müssen etwaige Änderungen auch nur noch an einer Stelle vorgenommen werden.

Darüber hinaus bietet der zentrale Controller auch noch andere Vorteile. Zunächst einmal handelt es sich hier um ein Stück Software und die Entwicklungszyklen sind bei Software deutlich kürzer als in der Hardware. Somit können neue Funktionalitäten schneller implementiert werden. Außerdem können neue Funktionen und Services auf einem Klon des Controllers vorab umfangreich getestet werden, bevor sie ihren Weg in die Produktionsumgebung finden. Darüber hinaus kann die konsequente Umsetzung eines solchen Modells auch die Fehlersuche deutlich vereinfachen. Vorausgesetzt, dass alle Entscheidungen zentral vom Controller getroffen werden und dass die Southbound API verlässlich umgesetzt wurde, können etwaige Fehler nur noch im Controller selbst auftreten. Alle Informationen zur Fehlersuche sind also auch an einer zentralen Stelle verfügbar.

Soviel zur Theorie der reinen Lehre von SDN. In der Praxis haben sich jedoch einige Punkte ebendieser als nicht sehr praktikabel und nicht skalierbar herausgestellt. So findet man heute im Markt überwiegend einen hybriden Ansatz, bei dem der Switch weiterhin eine eigene Control Plane behält. Diese kann jedoch von einem zentralen Controller gesteuert werden. Das erleichtert zum einen die Migrationsszenarien von der klassischen Technologie hin zu einer SDN Architektur. Zum anderen entlastet es den zentralen Controller. Es gibt zum Beispiel keinen zwingenden Grund, warum das Hashing für Link Aggregation Groups nicht im Switch selbst, sondern im Controller vorgenommen werden sollte. Genau so ist das Scheduling der QoS Queues eine Aufgabe, die lokal vom Switch übernommen werden sollte. Der Switch braucht also auch weiterhin eine gewisse Intelligenz. Der Controller ist bezüglich der Umsetzung seiner Steuerungsbefehle und Flow Einträge agnostisch. Eine Link Aggregation Group wird beispielsweise einfach als eine Punkt-zu-Punkt-Verbindung mit mehrfacher Kapazität zum Controller gemeldet. Durch welchen der physischen Links das Paket letztlich übertragen wird, ist dem Controller egal. Das kann der Switch lokal entscheiden.

Bezüglich der Southbound API des Controllers haben sich im Markt zwei Konsortien als federführend erwiesen. Das ist zum einen die Open Network Foundation (www.opennetworking.org) und zum anderen die Open Daylight Foundation (www.opendaylight.org). Beides sind Zusammenschlüsse mehrerer namhafter Hersteller, welche sich des Protokolls OpenFlow als Southbound API annehmen.

zugeordnete Kategorien: LAN
zugeordnete Tags:

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.