Software-defined Networking

Was ist SDN?

05.10.2023
Von 
Josh Fruhlinger ist freier Autor in Los Angeles.
Software-defined Networking ermöglicht Automatisierung, NetOps und vieles mehr. Das sollten Sie über SDN wissen.
Software-defined Networking kann für Unternehmen zahlreiche Vorteile realisieren - hält aber auch Herausforderungen bereit.
Software-defined Networking kann für Unternehmen zahlreiche Vorteile realisieren - hält aber auch Herausforderungen bereit.
Foto: designers circle - shutterstock.com

Im Jahr 2011 war das Open-Source-Protokoll OpenFlow das erste System im Bereich Software-defined Networking (SDN), das sich durchsetzen konnte. Seither sind eine ganze Reihe von SDN-Modellen entstanden - und jedes davon bietet im Vergleich zu herkömmlichen Netzwerken erhebliche Vorteile.

In diesem Artikel lesen Sie unter anderem, wie sich Software-defined Networking definiert, wie es funktioniert und wo die Unterschiede zu anderen Netzwerk-Management-Techniken liegen.

Software-defined Networking definiert

Software-defined Networking ist eine Netzwerk-Management-Technik, bei der die Steuerung von Networking-Geräten über Software zentralisiert wird. SDN vereinfacht das Netzwerk-Management dabei in zweierlei Hinsicht. Es ermöglicht:

  1. Netzwerke als Ganzes zu managen, statt auf Basis von Einzelgeräten, sowie

  2. Management-Tasks zu automatisieren und diese "on the fly" an sich verändernde Netzwerkanforderungen und -bedingungen anzupassen.

SDN - Funktionsweise

Ein Software-defined Network besteht aus drei Hauptkomponenten:

  • Controller,

  • Applikationen und

  • Devices.

Der Controller bildet die Steuerungsebene auf jedem einzelnen Netzwerkgerät: Er befüllt die Tabellen, mit denen die Daten-Layer der Devices ihre Arbeit verrichten. Es gibt verschiedene Kommunikationsprotokolle, die für diesen Zweck verwendet werden können (zum Beispiel OpenFlow), einige Anbieter nutzen auch proprietäre Protokolle. Die Kommunikation zwischen Controller und Devices wird als "Southbound API" bezeichnet.

Der Software-Controller wird wiederum von Applikationen verwaltet, die eine beliebige Anzahl von Netzwerkadministrationsrollen erfüllen können (darunter Load Balancer, Software-defined Security Services, Orchestrierungs- oder Analyseanwendungen, die die Vorgänge im Netzwerk im Auge behalten).

Die Applikationen kommunizieren mit dem Controller ("Northbound API") über gut dokumentierte REST-APIs, über die Anwendungen verschiedener Anbieter problemlos miteinander kommunizieren können.

Software-defined vs. traditionelles Networking

In einer herkömmlichen Netzwerkstruktur werden Entscheidungen darüber, wie Netzwerkpakete von einem Rechner zu einem anderen übertragen werden, von den physischen Routern, Switches und Firewalls getroffen, aus denen die Netzwerkinfrastruktur besteht. Die Funktionalität dieser Netzwerkgeräte ist konzeptionell in Elemente unterteilt, die als Ebenen ("planes") bezeichnet werden, darunter:

  • die Data Plane,

  • die Control Plane und

  • die Management Plane.

Die Data Plane leitet eingehende Netzwerkpakete an das entsprechende Ziel weiter. Das muss sie möglichst schnell erledigen, weswegen sie die die Routing-Informationen in den Headern mit Informationen aus Routing-Tabellen, Forward Information Bases und anderen ähnlichen Datenstrukturen abgleicht - anstatt wirklich zu "denken".

Die Daten in diesen Tabellen werden von der Control Plane mit Leben gefüllt, die die besten Routen für die Pakete durch das Netz bestimmt. Dazu nutzt die Steuerungsebene eine Reihe von Informationsquellen - zum Beispiel andere Router in der Nähe, die Standard-Netzwerkprotokolle verwenden. Diese Entscheidungsfindung kann dabei auch direkt manuell gesteuert werden - und zwar von der Management Plane.

In einem traditionellen Netzwerk arbeiten die Geräte unabhängig voneinander - die Administratoren müssen sich bei jedem einzelnen Device anmelden, um es zu managen und Netzwerkrichtlinien festzulegen. Software-defined Networking abstrahiert die Steuerungsebene hingegen in einem zentralen, softwarebasierten Controller, der auf einem Server im Rechenzentrum laufen kann. Dieser Controller kommuniziert mit den Datenebenen aller Netzwerkgeräte.

SDN vs. virtuelle Netzwerke

SDN und virtuelle Netzwerke ähneln sich: Beide zielen darauf ab, das Netzwerk-Management von den zugrundeliegenden physischen Geräten zu entkoppeln. In der Praxis sind es jedoch gänzlich unterschiedliche Ansätze:

In einem virtuellen Netzwerk werden Devices als virtuelle Maschinen simuliert, die auf Servern oder in der Cloud laufen und ein logisches Netzwerk bilden, das das physische Netzwerk überlagert. Ein Hypervisor vermittelt zwischen den beiden und übersetzt die Aktivitäten im virtuellen Netzwerk in Anweisungen für die physischen Router, die die Pakete übertragen. In diesem Szenario ist ein Netzwerkgerät - wenngleich vollständig virtuell ausgeführt - immer noch eine eigenständige Einheit mit eigenen Control- und Data Planes.

Bei einem Software-defined Network wird hingegen die Steuerungsfunktion von einzelnen Geräten auf eine zentralisierte Software verlagert, die auf einem Server läuft - ein gänzliches anderes Paradigma also.

Das bedeutet allerdings nicht, dass SDN und Virtual Networks nicht zusammengehen: Ein SDN-Controller kann virtuelle Netzwerkgeräte ebenso gut managen wie physische.

Software-defined Networking vs. SD-WAN

Softwaredefinierte Netzwerke werden hauptsächlich in LANs eingesetzt. Software-definierte WANs (SD-WANs) trennen ebenfalls Kontroll- und Datenebenen und verwenden teilweise identische Techniken wie SDN. Sie erstrecken sich aber über das offene Internet, um Zweigstellen mit Hauptniederlassungen oder der Cloud zu verbinden.

SDN - Vorteile und Herausforderungen

Software-defined Networking bietet eine Reihe spezifischer Benefits:

  • Netzwerkprogrammierbarkeit: Durch die Öffnung der Netzwerkinfrastruktur nicht nur für manuelle Eingriffe, sondern auch für programmatische Interaktionen über APIs, trägt SDN die Vernetzung in den zunehmend automatisierten IT-Betrieb von heute. Speziell NetOps (die Anwendung von automatisierten CI/CD-Methoden, die den Kern von DevOps bilden, auf die Welt der Netzwerke) ist ausschließlich in einer Welt möglich, in der das Netzwerk per Code bereitgestellt und gemanagt werden kann.

  • Richtlinien einfach erstellen und ändern: Durch die Zentralisierung des Netzwerk-Managements ermöglicht Software-defined Networking, neue Richtlinien in Bezug auf Sicherheit, QoS und mehr für alle Geräte auf einmal einzuziehen. In Kombination mit den Möglichkeiten der Automatisierung realisiert das eine schnelle und automatische Anpassung des Netzwerks an veränderte Bedingungen. Darüber hinaus ermöglicht SDN es auch, allgemeine Richtlinien festzulegen, die auf ein zugrundeliegendes, heterogenes Netzwerk angewendet werden können. Das ist insbesondere in Szenarien wichtig, in denen ein SDN-Controller Standard-Computer, Edge-Devices und IoT-Sensoren verwaltet.

  • Netzwerktransparenz: Während einzelne physische Netzwerkgeräte miteinander kommunizieren können, arbeiten sie in einem traditionell verwalteten LAN nicht zusammen, um ein "Gesamtbild" des Netzwerks zu erstellen. Durch die Zentralisierung der Controller-Funktionen bietet SDN Netzwerkadministratoren einen wesentlich besseren Einblick in das Netzwerk. Dazu kommt eine Vielzahl von Analyseanwendungen, mit denen sich diese Daten nutzen lassen - etwa zu Planungszwecken.

  • Geringere Kosten: Ein Hauptargument von SDN-Anbieter ist, dass ihre Lösungen dazu beitragen, die genannten Benefits zu realisieren und gleichzeitig die Kosten senken. Tatsächlich verspricht Software-defined Networking, die Betriebskosten zu senken, indem es das Netzwerkmanagement vereinfacht (und somit weniger Personalkosten anfallen). Die Investitionskosten kann SDN senken, indem es ermöglicht, teure proprietäre Netzwerkhardware durch virtualisierte Switches zu ersetzen, die auf handelsüblichen Geräten laufen (die Hardware benötigt weniger Rechenleistung, da die Steuerungsebene abstrahiert wurde). Das muss natürlich mit den Kosten für die jeweilige SDN-Lösung gegengerechnet werden.

Dennoch gibt es auch Herausforderungen bei der SDN-Einführung:

  • Viel Arbeit: Ein softwaredefiniertes Netzwerk einzuführen, erfordert eine umfassende Umstrukturierung, die viele Mannstunden in Anspruch nehmen wird und einen Teil der versprochenen OPEX-Einsparungen zunichte machen kann.

  • Steile Lernkurve: SDN-Anwendungen ermöglichen leistungsstarke Monitoring- und Management-Funktionen. Es kann aber einige Zeit in Anspruch nehmen, bis sich die Mitarbeiter damit vertraut gemacht haben. Das gilt insbesondere dann, wenn eine proprietäre Lösung zum Einsatz kommt. Wenn Sie ein Software-defined Network als Teil einer Umstellung auf NetOps einführen, muss das Netzwerkteam neben den neuen Tools auch eine völlig neue Kultur und Philosophie verinnerlichen.

  • Single Point of Failure: Im SDN-Modell ist der Controller entscheidend dafür, dass das gesamte Netzwerk funktioniert. Fällt er - oder der Server auf dem er läuft - aus, steht die gesamte Netzwerkkonnektivität auf dem Spiel. Sie sollten also eine möglichst hohe Verfügbarkeit anstreben und in Sachen Disaster Recovery entsprechend vorplanen.

  • Performance-Probleme: Ein Versprechen von SDN ist, dass die ganzheitliche Betrachtung des Netzwerks dazu beiträgt, die Netzwerk-Performance zu verbessern. Die Abhängigkeit von einem einzigen Controller kann jedoch auch zu Verzögerungen innerhalb des Netzwerks führen, insbesondere wenn dieses wächst.

  • Security-Schmerzen: In der Theorie kann ein softwaredefiniertes Netzwerk ebenso sicher sein wie ein herkömmliches. Schließlich steht eine Vielzahl von Netzwerksicherheitsanwendungen zur Verfügung. In der Praxis wird bei SDN-Implementierungen allerdings häufig von dedizierten Hardware-Firewalls auf handelsübliche Hardware für die zugrundeliegenden Netzwerkgeräte umgestellt. Das führt letztlich dazu, dass die Admins dedizierte, integrierte Security-Funktionen gegen Sicherheit "eintauschen", die sie selbst managen müssen - was negative Konsequenzen haben kann.

Gehen Sie eine SDN-Einführung mit offenen Augen für mögliche Fallstricke an. Dann sollten die Vorteile die Kosten auch bei weitem überwiegen. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Network World.