Herausforderungen für Software-Defined Networks

Nord-Süd-Gefälle

10. Mai 2013, 6:00 Uhr | Markus Nispel/wg, Chief Technology Strategist bei Enterasys Networks.

Derzeit dreht sich am Netzwerkmarkt alles um das Software-Defined Network (SDN). Fast alle Anbieter von Switching- und Virtualisierungslösungen verfolgen SDN-Ansätze. Auch darüber hinaus positionieren sich Hersteller im Bereich SDN, selbst wenn es mitunter zunächst keine direkte Verbindung zum Thema gibt.Initial war die Diskussion über SDN stark mit dem Openflow-Protokoll und der ONF (Open Network Foundation) verknüpft, obwohl es auch schon vorher ähnliche Ansätze am Markt gab. Im Rahmen der ersten Welle des Gartner-Hypecycles wurden die Themen Kostenersparnis durch Standardisierung der Switch-Hardware, Herstellerunabhängigkeit und Interoperabilität sowie die offene Programmierbarkeit des Netzes sehr stark in den Vordergrund gestellt. Doch leider sieht die Praxis auch etwas anders aus. Bereits jetzt ist klar, dass SDN die Netzwerkwelt dauerhaft verändert, wenn auch nicht vollkommen revolutioniert. Es gibt Mehrwerte, die zunächst nicht unbedingt im Fokus standen. Zudem beschäftigen sich immer mehr Unternehmen mit der intelligenten Verknüpfung von Netzwerk und Anwendungen, die eine direkte koordinierte Steuerung des Netzwerks (Orchestrierung) ermöglicht. Der wohl größte Vorteil von SDN liegt allerdings im Kostensenkungspotenzial und erhöhter Flexibilität durch die zentrale Konfiguration der Netzwerkinfrastruktur. Die Netzwerkvirtualisierung und die schnelle Einführung neuer Services gehören zu den häufig genannten Anwendungsfällen, die auch ohne Openflow möglich sind. Nur die letzte große Kategorie, Traffic Engineering, lässt sich gegebenenfalls durch Openflow besser umsetzen. Beispielsweise investierte Google knapp zwei Jahre in die Entwicklung der Google-Data-Center-Anwendung, die eigentlich eine Traffic-Engineering-Lösung ist.   Hybrides Flow-Management Zu den ursprünglichen Versprechungen zählte Kostensenkung durch den Einsatz standardisierter Hardware. Hier ist sogar ein gegenläufiger Trend zu erkennen, denn die Anforderung, eine hohe Anzahl von so genannten Flows zu managen, bringt die Hardware an ihre Grenzen. Zum einen sind die aktuellen Switching-Chips auf Kosten und Performance optimiert, damit bleiben die Flows "auf der Strecke". Denn viele Flows erfordern viel Speicher - und der ist bei den heutigen Geschwindigkeiten mit hohen Kosten verbunden. Daher setzt man vielmehr auf spezielle Chips einzelner Hersteller, was die Kosten für Hardware identisch hält. Zum anderen lassen sich viele Flows nicht vollkommen zentral verwalten- zumindest nicht, wenn Echtzeitentscheidungen zu treffen sind. Damit ist ein hybrider Ansatz, der einzig sinnvolle für derartige Management-Anforderungen. Wenn es darum geht, Flows pro Nutzer und Applikation zu managen, muss man mit rund einem neuen Flow pro Sekunde pro Nutzer rechnen. Dies summiert sich schnell auf 100.000 und mehr - und das ist weder auf der Ebene von Standard-ASICs noch auf Controller-Ebene zu erreichen. Daher setzen die Anbieter heute in den Openflow-basierten SDN-Ansätzen immer auf die Aggregation und statische Flow Konfiguration. Für den Aufbau eines SDN ist eine hybride Architektur sinnvoll, da das Management von Flows, der Topologien und Routing-Entscheidungen dezentral stattfindet. Die Service-Definition hingegen erfolgt zentral und wird auf alle Komponenten im Netz verteilt. Über APIs läuft dann die Integration in andere IT-Applikationen. Dadurch ergeben sich drei wichtige Vorteile der SDN-Architektur: Sicherheit, Stabilität und Skalierbarkeit. Dies begegnet den Anforderungen der Unternehmens-IT. Künftig werden mehr und mehr Protokolle durch Standards ersetzt. Durch die Integration offener Schnittstellen ist heute bereits einiges mit SDN erreichbar, so zum Beispiel im Rechenzentrum: Data-Center-Management-Lösungen, eine Kernkomponente für den Aufbau von SDN-Architekturen, erlauben hier die Bereitstellung neuer Dienste im Bereich virtueller Switches und garantieren die physische und virtuelle Netzwerkorchestrierung. Neue Services wie etwa anwenderbasierte Zugangslösungen oder standortabhängige Web-Filter-Anwendungen, Web-Proxy-Dienste sowie URL-Filter lassen sich in das Netzwerk integrieren und automatisch ausführen. Hinzu gesellt sich ein automatisches Onboarding und eine Gästeregistrierung. Dazu hören Applikations-Services für den Bereich Hospitality, etwa Business- oder Konferenz-Center, und Bildungseinrichtungen wie Universitäten und Schulen. Lösungen zur automatischen Erkennung von Geräten sind einfach zu integrieren. Über Mobile-Device-Management-Lösungen sind auch neue mobile Geräte unkompliziert und ohne Aufwand zu integrieren. Mobile Endgeräte von Mitarbeitern sind automatisch identifizierbar, sodass nur jene Anwendungen zur Verfügung stehen, die für den Einsatz in der Unternehmensumgebung zugelassen sind. Insgesamt lassen sich Betriebskosten reduzieren und Zufriedenheit der Nutzer erhöhen. Die Bereitstellung von UC-Anwendungen (Unified Communications) schließlich erfordert verschiedene Applikations-Services für UC-Nutzer und -Geräte. Wichtig sind automatisierte Einstellungen innerhalb der SDN-Fabric. Zu den weiteren Vorteilen zählen Herstellerunabhängigkeit und Interoperabilität. Dies betrifft hauptsächlich die Schnittstelle vom Switch zum Controller. Die heute vorhandenen Controller bieten aber keinerlei standardisierte Schnittstelle, um eigene Applikationen über mehrere Controller-Hersteller oder Open-Source-Projekte zu entwicklen, sodass sich hier nur die Ebene der Abhängigkeit verschiebt. Es bleibt die Programmierbarkeit, das Kernthema von Software-Defined Networks, das die meisten Mehrwerte bietet: eine zentrale Schnittstelle, typischerweise XML-basiert, um die Netzwerkkonfiguration zentral zu steuern, ohne jedoch Details über das Netz kennen zu müssen. Diese Funktion nutzen unsere Kunden und Partner längst, um neue Dienste schnell ins Netz zu bringen, den Netzbetrieb stark zu automatisieren und mehr Überblick, Kontrolle und Sicherheit ins Netz zu bringen. Auch wenn XML standardisiert ist, sind es die Inhalte leider nicht. Dies gilt sowohl für die Implementierung bei allen - auch Openflow-Controller-basierten - SDN-Lösungen am Markt. Selbst wenn die so genannte Southbound API (zwischen Controller-Instanz und Switch) standardisiert wäre, etwa durch Nutzung von SNMP, Radius, Netconf oder auch Openflow, wird die Standardisierung der Northbound API (zwischen Controller-Instanz und den IT-Applikationen), zur Zeit nicht unterstützt. Damit entsteht ein "Nord-Süd-Gefälle". Neben der Hersteller-API bieten die Open-Source-Controller für Openflow heute sehr unterschiedliche Möglichkeiten. Der Floodlight Controller zum Beispiel erlaubt die Programmierung statischer Regel und Abfragen via REST-APIs. Der Trema Controller fokussiert auf Mandantenfähigkeit, NOX wiederum bietet andere Funktionen. In der Community wurde zunächst diskutiert, die Marktentwicklung zu beobachten und abzuwarten, ob sich mit der Zeit ein "Sieger"-Interface herausbilden wird. Die Frage ist jedoch, wie lange so ein Prozess dauert und wie effizient er sein wird. Da die Anwendungsszenarien sehr verschieden sein können, ist es auch möglich, dass sich mehrere Northbound Interfaces durchsetzen werden, jeweils fokussiert auf die Anwendungsbereiche Netzvirtualisierung, Traffic Engineering und Service-Delivery. Da der Markt sich noch in einer sehr frühen Phase befindet und Ansätze und Ideen in alle Richtungen sprießen, wird man sich voraussichtlich auf absehbare Zeit auf eine Architektur und Schnittstelle festlegen müssen, um dann abzuwarten, wie sich die Standardisierung weiterentwickelt. Es bleibt auf alle Fälle sehr spannend.

Eine Policy zu einer Virtual Machine entsteht im physischen und virtuellen Netzwerk, wenn VMs erstellt oder bewegt werden. Bild: Enterasys

SDN stellt eine logische Weiterentwicklung auf dem Weg zu mehr Automation im Netzwerk dar. Bild: Enterasys
LANline.

Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu Intel Security

Weitere Artikel zu LG Electronics Deutschland GmbH

Matchmaker+