Über viele Jahre hinweg wurden Datennetze mit den immer gleichen Protokollen gebaut, die in den 70er Jahren entwickelt und Mitte der 80er Jahre weiter verfeinert wurden. In dieser Zeit war eine der wichtigsten Aufgaben dieser Netzprotokolle (wie OSPF, Spanning-Tree, BGP) die Ausfallsicherheit zu verbessern. Im Falle eines Falles sollte der Verkehr in einem Netzwerk über alternative Wege zum Ziel geleitet werden.

In dem Maß, wie sich die Anforderungen an die Unternehmensnetze weiterentwickelten, wurden auch diese Protokolle verbessert. Schließlich mussten sie an die neue Realität angepasst werden, um Schritt zu halten mit der Erhöung von Bandbreiten, dem Datenumfang und den Latenz-Anforderungen moderner, web-basierter Anwendungen und hochvirtualisierter Workloads So entwickelten sich beispielsweise die Netzwerktechnologien hin zu Spanning-Tree, dann Rapid-Spanning-Tree, dann zum Multiple Rapid Spanning-Tree mit VLAN-Instanzen. Die Branche versuchte, die Protokolle aufzubohren, wie die Automobile in der Fernsehsendung "Pimp My Ride" getuned werden.

In jüngster Zeit konnten diese Protokolle allerdings nicht mehr mit der Netzrealität Schritt halten, die heute aus sich ständig verändernden virtuellen Servern, der On-Demand-Erstellung von Workloads oder Hybrid-Cloud-Designs besteht. Das Networking brauchte deshalb neue Werkzeuge. Und hier kommt nun das Software Defined Networking - SDN - ins Spiel. Software Defined Networking zentralisiert den Entscheidungsprozess, wie Daten in einem Netzwerk bewegt werden, in einem Controller-Cluster, der Einblick in die gesamte Netzwerk-Infrastruktur hat. Dies ist eine wichtige Veränderung gegenüber traditionellen Netzen, wo die Weiterleitungsentscheidung auf lokal verfügbaren Informationen und einer Reihe von Legacy-Protokollen basierte. Jetzt, da zentralisierte Controller den gesamten Datenpfad überblicken und definieren können, lassen sich wichtige Mehrwertdienste für die Nutzer ergänzen.

Eine gute Analogie hierzu ist die des klassischen Taxifahrers im Vergleich zu einem modernen GPS-Navigationssystem. Traditionelle Netzprotokolle sind ein bisschen vergleichbar mit diesem Taxifahrer, der sich für die seiner Meinung nach beste Route zum Flughafen entscheidet - auf Basis seiner Erfahrung und seiner Informationen. Aber der Taxifahrer weiß vielleicht nicht, dass eine spontane Verkehrsbehinderung auf einem Teil der Route entstanden ist. Und der beste Weg zum Flughafen könnte auch je nach den Priorität variieren -legt der Gast etwa auf den niedrigsten Preis, die kürzeste Entfernung oder den schnellsten Weg wert. Mit dem Zugriff auf ein zentrales Informationssystem und GPS hat das Navigationssystem einen gesamtheitlichen Blick auf die gesamte Straßeninfrastruktur sowie minutengenaue Verkehrsinformationen, Wettervorhersagen und Hinweise zu sonstigen Gegebenheiten. Das System berücksichtigt all das und sendet dann Richtungsempfehlungen für den besten Weg zum Flughafen.

SDN agiert ähnlich wie ein GPS-Navigationssystem. Ein SDN-Controller stellt Informationen über die Anwendungen und die gesamte Netzinfrastruktur bereit und gibt Empfehlungen, welcher vorgeschlagene Weg der Beste ist, um Informationen von A nach B zu senden, basierend auf konfigurierbaren Parametern für die jeweilige Anwendung am jeweiligen Tag und zum jeweiligen Zeitpunkt. Das ist etwas, was traditionelle Netzwerkprotokolle so nicht leisten können.

Mit dem Wissen über die jeweilige Anwendung können Controller das Latenzverhalten, bandbreitenhungrige Workloads und vermutliche Engpässe im Routing-Entscheidungsprozess berücksichtigen. Dies sind wertvolle Möglichkeiten für die IT-Verantwortlichen, die mit der schieren Menge von virtuellen Maschinen, die sich mit unterschiedlichen Anforderungen im Netz bewegen, zu kämpfen haben. Routing-Algorithmen, die verwendet werden, um diese Entscheidungen zu treffen, basieren nicht länger auf Ziel-IP-oder MAC-Adressen, sondern auf einem völlig neuen Satz an Parametern, die wiederum auf dem Wissen über die Anwendungen basieren.

Möglich wird der Einsatz von SDN-basierten Konzepten unter anderem deshalb, weil die Hardwarehersteller nun extrem schnelle Switches bauen, die in der Lage sind, eine zentral gesteuerte Verkehrsbestimmung so schnell umzusetzen, dass der Anwender davon nichts merkt. Ein so schnelles Versenden und Empfangen von Steuerungsdaten war früher einfach nicht möglich. Diese Systeme sind Low-Latency-Switches.

Software ist das Schlüsselwort in Sachen Software Defined Networking. Der Wert von SDN liegt weniger in der verwendeten Hardware für die Verbindung der Komponenten oder im Controller-Cluster, der die Informationen mit OpenFlow verbreitet, sondern in den Algorithmen, die auf diesen Controllern laufen und die Route zu einem gewünschten Ziel definieren. Ein anderer Aspekt ist die dazugehörige Analyse-Software für die Erkennung von Sicherheitsrisiken und die Bereitstellung von Tools, um sie zu beheben, bevor sicherheitsrelevante Ereignisse geschehen.

Aufgrund der wichtigen Rolle der Software, glauben wir bei IBMIBM, dass es sowohl im Interesse der Anwender als auch der IndustrieIndustrie sein sollte, die Networking-Software- und -Hardware-Plattformen so zu öffnen, dass jeder etwas beitragen kann - vor allem die Experten mit Anwendungs-Know-how. Über viele Jahre haben Netzhersteller teure und komplexe Hardware/Software mit Features vertrieben, die in erster Linie für Netzbetreiber mit großen Rechenzentren gedacht waren. Anwender spielten erst in zweiter Linie eine Rolle. So war es beispielsweise für einen Datenbank-Software-Anbieter praktisch unmöglich, einen optimierten Load-Balancing-Algorithmus für seine Plattform anzubieten, weil die netzwerkrelevanten Stellschrauben in einer Reihe von Features versteckt waren, die ausschließlich von den Netzwerktechnologieherstellern bestimmt wurden. Alles zu IBM auf CIO.de Top-Firmen der Branche Industrie

Um dieses Problem zu lösen und die Netzinfrastruktur für Anwendungsentwickler zu öffnen, haben IBM und andere branchenrelevante Unternehmen das OpenDaylight-Konsortium gegründet. Eine der Aufgaben dieser Organisation ist es, ein Standard SDN-Controller-Framework mit einer offenen API bereitzustellen, damit jeder Software auf einem OpenDaylight-basierenden Controller entwickeln kann.

Weil sich viele Markteilnehmer jetzt dem SDN-Thema anschließen, stehen die Software-Fähigkeiten im Vordergrund. Dabei standardisieren sich Netzwerk-Switches auf Basis von OpenFlow. Controller konvergieren in Richtung des OpenDaylight-Frameworks. Das Unterscheidungsmerkmal für SDN-Implementierungen sind nun die Anwendungen, die mit der Netzinfrastruktur bereitgestellt werden können. Egal, ob es sich um eine virtuelle Overlay-Netzwerk-Anwendung handelt oder eine wegeoptimierte Anwendung: Die Wahl der Software für die jeweilige SDN-Infrastruktur wird künftig wohl wichtiger als alles andere sein. Dank SDN kann sich das Networking zu einer agileren, flexibleren und offeneren Technologieumgebung entwickeln, die auf die Belange der Endbenutzer eingeht.