alphaspirit - Fotolia
SDN: Mehr als ein Weg führt zum Ziel
Für die Implementierung von Software-defined Networking (SDN) gibt es mehrere Ansätze. Grundsätzlich lässt sich zwischen Open SDN und SDN via APIs unterscheiden.
Mit Software-defined Networking (SDN) sind Administratoren nicht mehr an die statische Architektur traditioneller Netzwerke gebunden, sondern können das Netzwerk über offene Schnittstellen zentral und dynamisch verwalten. Dies wird erreicht, indem die Kontrollebene von der Datenebene getrennt wird. Bei der Implementierung lassen sich zwei Kategorien unterscheiden: Open SDN und SDN via APIs.
Langjährig gewachsene Netzwerke haben in vielen Fällen die Grenzen ihrer Leistungsfähigkeit erreicht. Administratoren sind damit kaum noch in der Lage, die Dynamik und Flexibilität anspruchsvoller Anwendungsszenarien bereitzustellen, die Fachabteilungen verlangen.
Ganz oben auf deren Agenda stehen etwa digitale Geschäftsmodelle, die in hohem Maße von mobil verfügbaren Apps und Daten geprägt sind. Dazu kommen die für die verschiedensten Private-, Public- und Hybrid-Cloud-Services erforderliche Virtualisierung und Flexibilität. Ein weiterer Treiber sind die hohen Skalierungsanforderungen in vielen IoT-Anwendungen. Mobility, Cloud-Services und das IoT sind drei Ansätze, mit denen Unternehmen den digitalen Wandel vorantreiben. SDN und andere Virtualisierungs-Technologien für Server und Storage sind zentrale Bausteine, mit denen Rechenzentren solche IoT-Applikationen erfolgreich bereitstellen können.
In einem ersten Überblick führen zwei Wege zum Ziel des Software-defined Networking: Open SDN und SDN via APIs.
Open SDN
SDN-Technologien können sich oft auf eine Open-Source-Community stützen, die es sich zur Aufgabe gemacht hat, offene Standards zu fördern. Das gilt beispielsweise für den OpenFlow-Standard, für den die Open Networking Foundation (ONF) verantwortlich zeichnet. OpenFlow trennt die Datenebene (Data Plane) von der Kontrollebene (Control Plane) und lagert die Control Plane von einem Network Device auf einen SDN-Controller aus.
Das Network Device übernimmt dann das Forwarding und die Data-Plane-Funktionen, während der SDN-Controller für Funktionen der Steuerungsebene verantwortlich ist. Dieser kann dann direkt mit den Network Devices wie Routern und Switches interagieren. OpenFlow ist dabei nur das SDN-Protokoll, das heißt, bei Bedarf können Unternehmen Open SDN auch mit anderen Protokollen verwenden.
SDN via APIs
Eine SDN-Implementierung via APIs bezieht sich auf Southbound-APIs, mit denen Administratoren die Network Device Control Plane konfigurieren und programmieren. Unternehmen haben bereits eine Reihe von Network Device APIs, wie SNMP, CLO, TL1, RADIUS und TR-069, im Einsatz. Dazu kommen neuere APIs wie NETCONF/YANG, REST, XMPP und BGP-LS, die unterschiedliche Kontrollgrade über die Network Devices, Data Plane und Topologie bieten. Ein wichtiger Unterschied zum Open-SDN-Ansatz: OpenFlow wird verwendet, um direkt die Data Plane zu steuern, nicht nur die Konfiguration der Devices und der Control Plane.
Auch in der heutigen Netzwerkwelt konfigurieren Administratoren die meisten Geräte immer noch über ein Command Line Interface (CLI). Dazu verbinden sie sich entweder mit der Konsole oder über Telnet/SSH des Geräts. Jedes Device wird dann individuell konfiguriert. Der Open-SDN-Ansatz, bietet technologische und operative Vorteile. Er erfordert aber auch, dass ein Unternehmen alte durch neue Hardware austauscht, die die Open-SDN-Technologie unterstützt, sowie in einigen Fällen auch neue Protokolle wie OpenFlow einführt.
Verständlicherweise wird kein Unternehmen seine gesamte Netzwerkhardware über Nacht ersetzen, da ein solcher Schritt erhebliche Kosten, Implementierungs- und Architekturprobleme mit sich bringen würde. Ältere Geräte, die das Ende ihres Lebenszyklus erreicht haben, durch neuere zu ersetzen ist eine der Möglichkeiten, um von einer Software-defined-Networking-Infrastruktur zu profitieren. Eine andere Option besteht darin, im Einsatz befindliche Network Devices mit einer RESTful API als zusätzliche Abstraktionsschicht aufzurüsten, so dass diese von einem SDN-Controller gesteuert werden können, der dazu nicht das OpenFlow-Protokoll benötigt.
OpenDaylight mit hybridem Ansatz
OpenDaylight (ODL) ist ein Open-Source-SDN-Projekt, das darauf abzielt, die Verbreitung softwaredefinierter Netzwerke zu fördern. Dazu stellt das Projekt ein von der Open-Source-Community entwickeltes und von IT-Unternehmen unterstütztes Framework für den OpenDaylight Controller bereit. OpenDaylight lässt sich als hybrider Ansatz charakterisieren. Auf der einen Seite kommt im Sinne eines reinen Open-SDN-Ansatzes OpenFlow zum Einsatz.
„Kein Unternehmen wird seine gesamte Netzwerkhardware über Nacht ersetzen, da ein solcher Schritt erhebliche Kosten, Implementierungs- und Architekturprobleme mit sich bringen würde.“
Alexander Thiele, Dell EMC
Der ODL-Controller unterstützt jedoch auch Southbound-APIs, um mit Plug-ins wie NETCONF und BGP-LS/PCE-P die Legacy Control Plane auf Netzwerkgeräten zu programmieren. Einige Unternehmen wie etwa Dell EMC verfolgen bei OpenDaylight einen strikten Open-Source-Ansatz, andere haben SDN-Controller auf Basis von OpenDaylight entwickelt und um proprietäre Funktionen erweitert.
Schrittweise Migration zu SDN
SDN via APIs ermöglicht einen schrittweisen Übergang zu einem Controller-basierten Networking-Modell. Diese Variante eignet sich beispielsweise für Unternehmen mit einer großen Zahl von proprietären und Legacy Network Devices. Ein Vorteil gegenüber Open SDN: Es gibt keinen Single Point of Failure, wie er in einem reinen Open-SDN-Modell anzutreffen ist. Schwerpunktmäßige Einsatzgebiete von SDN via APIs sind typische Rechenzentren in Unternehmen. Die hier benötigte Skalierbarkeit und Performance stellen API-basierten Lösungen problemlos bereit.
Über den Autor:
Alexander Thiele ist Director Dell, Enterprise Solutions, Networking, Germany. Dell EMC unterstützt sowohl Open SDN als auch OpenDaylight und SDN via APIs. Dazu kommt als weitere Option SDN by Overlays, die auf einem Hypervisor Network Virtualization Model basiert. Analog zur Server-Virtualisierung sind Administratoren mit diesem Modell in der Lage, in einem physischen Netzwerk mit Hilfe virtueller Switches mehrere virtuelle Netzwerke zu betreiben. Die virtuellen Netzwerke verhalten sich Anwendern gegenüber wie ein physisches Netzwerk. Dell EMC arbeitet in diesem Umfeld beispielsweise mit Intel, Midokura und VMware zusammen.
Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!
