Essential Guide

Einführung in Software-defined Networking (SDN)

Eine umfassende Auswahl von Artikeln, Videos und mehr, die von unseren Redakteuren gewählt wurden.

SDN-Grundlagen: Zentrale Kontrolle und Programmierbarkeit

SDN steht für die nächste große Revolution im Netzwerk-Umfeld. Unser Artikel erklärt, was hinter dem Buzzword steckt und welche Neuerungen SDN bringt.

Dieser Artikel ist der erste Teil eines Zweiteilers zu den Grundlagen von SDN. In diesem Beitrag diskutieren wir die Eckpunkte von SDN, zentralisierte Kontrolle und die Programmierbarkeit des Netzwerks. Im zweiten Teil erklären wir Virtualisierung und Orchestrierung.

Virtualisierung und Cloud Computing, zwei Techniken, die in der letzten Dekade eingeführt wurden, hatten einen enormen Effekt auf die IT. Diese miteinander verwandten Techniken haben Netzwerkverantwortliche und Applikationsentwickler mit der notwendigen Flexibilität ausgestattet, um jeden Quadratmeter im Rechenzentrum auszunutzen und das Meiste aus der verfügbaren Hardware herauszuholen.

Im Vergleich zu den Applikationen hat sich das darunter liegende Netzwerk allerdings kaum weiterentwickelt. Tatsächlich haben Virtualisierung und Cloud Computing zwar den Blick auf die IT geändert, Netzwerk als Disziplin blieb allerdings bislang weitestgehend unverändert. Die meisten Netzwerke wurden inkrementell mit mehr Bandbreite ausgestattet, eine grundlegende Veränderung fand aber kaum statt. Bücher über Netzwerkdesign, meist fünf oder zehn Jahre alt, gelten noch immer als valide Grundlage. Einfach gesagt ist das so, weil sich die Netzwerkgrundlagen in diesem Zeitraum kaum verändert haben.

Die fehlende Innovation im Netzwerkbereich macht sich langsam bemerkbar. Entwickler müssen sich immer häufiger mit den Beschränkungen der Netzwerke auseinandersetzen und Lösungen finden. Das ist mit einer der Gründe, warum Anbieter von Netzwerk-Hardware mittlerweile daran arbeiten, Netzwerke so flexibel zu machen, dass sie die gestiegenen Anforderungen von Unternehmen und Anbietern erfüllen.

Vier spezielle Bereiche, an denen in den letzten Jahren gearbeitet wurde, sind zentralisierte Kontrolle, Programmierbarkeit, Orchestrierung und Virtualisierung. Zusammengefasst werden diese Veränderungen unter dem Oberbegriff Software-Defined Networking, kurz SDN. Diese Innovationen adressieren die spezifischen Probleme, die Unternehmen begegnen, wenn sie ihre Infrastruktur virtualisieren und Cloud Computing integrieren.

SDN-Grundlagen: Zentralisierte Kontrolle

SDN will das Netzwerk mit Hilfe eines zentralen Controllers und Software effektiv programmieren. Die meisten aktuellen Systeme nutzen lokale Forwarding Tables, die vom jeweiligen Gerät gepflegt und programmiert werden. Das bedeutet, dass die Netzwerkkomponenten ihre eigenen Entscheidungen treffen, dabei aber keine komplette Übersicht übers Netzwerk haben. Dabei helfen Control-Plane-Protokolle wie Spanning Tree, OSPF und Border Gateway Protocol (BGP), etwa wenn es um die Weiterleitung von Datenverkehr geht. Diese traditionellen Netzwerkprotokolle bieten allerdings nur limitierte Flexibilität. Damit diese funktionieren, müssen alle Netzwerkkomponenten in der gleichen Domäne exakt den gleichen Regeln folgen. Das bietet wenig Raum, um Probleme kreativ anzugehen oder um spezielle Probleme einzelner Unternehmen anzugehen.

SDN nimmt die Control Plane (die entscheidet, wie eine Komponente im Netzwerk den Datenverkehr weiterleitet) und trennt sie von der Data beziehungsweise Forwarding Plane (die aufgrund der Entscheidungen der Control Plane den Verkehr weiterleitet). Die so separierte Control Plane sitzt bei SDN auf dem zentralisierten Controller und kann so alle Bereiche des Netzwerks überwachen. Dadurch sieht das zentrale Systeme, welche Geräte (und Endpunkte) sich wie im Netzwerk verhalten. Ein allwissender Controller kann enorm flexibel auf Anforderungen im Netzwerk reagieren und die Forwarding-Regeln entsprechend anpassen. Limitiert wird der Controller dabei nur von der auf ihm laufenden Software.

Dieser zentrale Controller ist ein wichtiger Eckpunkt von SDN. In den Diskussionen um diese Technik kommen zwei Begriffe immer wieder vor: Northbound und Southbound. Am einfachsten kann man sich den Controller als Middleware vorstellen. Applikationen, die dem Controller erklären, wie er das Netzwerk programmieren soll, sind Northbound-Kommunikation. Southbound-Kommunikation programmiert die einzelnen Geräte im Netzwerk. Der Controller arbeitet als Vermittler und abstrahiert das unterliegende Netzwerk von den Applikationen, die das Netzwerk programmieren möchten.

Es gibt einige praktische Beispiele, wann diese Funktionen eines zentralisierten Controllers nützlich sind:

  • Beim Erstellen eines experimentellen Netzwerks, das auf der gleichen physischen Infrastruktur wie ein Produktiv-Netzwerk läuft, davon allerdings komplett isoliert ist.
  • Beim Durchsetzen von Datenverkehrs-Richtlinien, wen einzelne Datenpakete über eigene Richtlinien verfügen, die im Netzwerk dynamisch umgesetzt werden sollen, um Quality-of-Service-Vorgaben (QoS) zu erfüllen.
  • „Routing for Dollars“, sprich, wenn der Datenverkehr innerhalb eines Netzwerks gemäß bestimmter Vorgaben geleitet werden soll, die einen finanziellen Einfluss auf das Unternehmen haben.
  • Intelligente Netzwerksicherheit, die verdächtige Datenpakete dynamisch an das Intrusion Detection System (IDS) zur Deep Packet Inspection weiterleitet, während andere offensichtlich harmlose Pakete ungehindert weiterfließen können.
  • Netzwerkweites Monitoring von Datenverkehr (wie beim Spanning), etwa wenn Datenverkehr aus jedem Bereich des Netzwerks an einen anderen Punkt zur Analyse gespeichert werden soll.

SDN-Grundlagen: Programmierbarkeit des Netzwerks

Netzwerk-Verantwortliche konfigurieren ihre Geräte über eine Kommandozeile (CLI) oder eine grafische Oberfläche (GUI). Das ist normal, aber nicht ohne Probleme. Eine komplexe Netzwerk-Konfiguration setzt oftmals voraus, dass mehrere Geräte separat eingerichtet werden müssen. Dieser Prozess ist zeitintensiv, fehleranfällig und fade. Systemadministratoren stehen zwar Tools wie Puppet zur Verfügung, allerdings gibt es kaum eine Software, die alle Komponenten im Netzwerk verwalten und alle anfallenden Aufgaben erfüllen kann.

Programmierbare Netzwerke wollen diese Probleme durch standardisierte Application Programming Interfaces (APIs) angehen. Damit lassen sich die Geräte im Netzwerk durch gängige Programmiersprachen steuern. Der Einsatz von APIs ermöglicht außerdem komplett neue Szenarien: Künftig muss die Netzwerk-Hardware nicht mehr nur von Netzwerk-Profis konfiguriert werden, es stehen eine ganze Reihe von Tools zur Verfügung, um diese an die neuen Anforderungen anzupassen. Einige Beispiele:

  • Netzwerk-Admins können Skripte nutzen, um Aufgaben automatisiert auszuführen oder Netzwerk-Statistiken aufzuzeichnen (das klappt zwar bereits jetzt, meist sind diese Skripte aber nicht mehr als glorifizierte Interaktionen mit SNMP oder dem CLI). APIs versprechen hier deutlich vielseitigere Einsatzszenarien und Zusammenarbeit zwischen verschiedenen Bereichen und Verantwortlichen.
  • Orchestrierungs-Werkzeuge können mit Business-Applikationen zusammenarbeiten, um Provisioning-Aufgaben dynamisch anzustoßen.
  • Netzwerk-Applikationen können mit dem System zusammenarbeiten und das Netzwerk um neue Funktionen erweitern – analog zu Apps auf Smartphones.

Zahlreiche Hersteller von Netzwerk-Hardware arbeiten aktuell an APIs, mit denen Entwickler das volle Potential ihrer Geräte nutzen können. Beispiele sind etwa Cisco oder Juniper Networks. Obwohl sie sich noch in der Entwicklung befindet, bietet onePK von Cisco bereits zahlreiche Programm-Bibliotheken, mit denen sich Hardware auf Basis von IOS, IOS-XR und NX-OS programmieren lässt. Das Junos-Betriebssystem von Juniper hatte schon immer eine XML-API, sogar die Kommandozeile liefert XML-Code an das unterliegende Betriebssystem.

Eine Diskussion über OpenFlow lässt sich kaum vermeiden, wenn man über programmierbare Netzwerkfunktionen spricht. OpenFlow wird ständig von der Open Network Foundation weiterentwickelt und ist ein sehr gutes Beispiel dafür, wie sich programmierbare Netzwerke mit einem zentralen Controller steuern lassen. OpenFlow ist ein anbieterunabhängiger Ansatz, der beschreibt, wie sich Netzwerk-Switches programmieren lassen. Die Technik identifiziert spezifische Abläufe, basierend auf unterschiedlichen Kriterien (darunter etwa die MAC-Adresse, IP-Zieladresse, etc.) und führt anschließend die notwendigen Aktionen aus, um diese Abläufe zu steuern (etwa Weiterleitung via Port X etc.). Ein zentralisierter OpenFlow-Controller, der die komplette Netzwerk-Topologie im Blick hat, kann alle Netzwerk-Switches zentral steuern.

Zu kompatiblen Open Source OpenFlow-Controllern zählen unter anderem Beacon und FloodLight. Netzwerkhersteller, die OpenFlow in ihren Produkten unterstützen, sind unter anderem HP, Juniper, Pica8, Cisco und einige andere. Konzeptionell ist OpenFlow eine sichere Sache, allerdings gibt es aktuell noch Probleme bei Themen wie Skalierbarkeit und Kompatibilität. OpenFlow lässt sich nicht Eins-zu-Eins in Silikon abbilden, weswegen „OpenFlow kompatibel“ bei unterschiedlichen Herstellern unterschiedliche Bedeutung hat. Das ist leider ein Grund, warum die Zukunft von OpenFlow aktuell nicht hundertprozentig sicher ist.

Artikel wurde zuletzt im Februar 2014 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Essential Guide

Einführung in Software-defined Networking (SDN)

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchDataCenter.de

SearchEnterpriseSoftware.de

Close