Mehr Schein als Sein?

Offene Standards im Netzwerk

Aufgrund seiner 20-jährigen Erfahrung in der IT-Branche kennt sich Reiner Dresbach mit den Trends und Themen, die diese beschäftigen aus. Seine besonderen Schwerpunkte liegen dabei auf IT-Sicherheit, Threat Intelligence und Incident Response.
Kaum eine Diskussion ist momentan so lebendig wie die um die Einführung von Software-Defined Networking im Netzwerk. Bei all der Diskussion wird eines übersehen: Für die Durchsetzung einer Technologie müssen die Rahmenbedingungen stimmen. Und die lauten aus meiner Sicht: Offene Standards.
SDN bedeutet für viele Unternehmen mehr Flexibilität, einfacheres Management und schnellere Konfiguration der Netzwerke.
SDN bedeutet für viele Unternehmen mehr Flexibilität, einfacheres Management und schnellere Konfiguration der Netzwerke.
Foto: VMware

Kaum eine Diskussion ist in der Netzwerkbranche momentan so lebendig wie die um die Einführung von Software-Defined Networking. Die Fronten schwanken zwischen den Fragen: Ist SDN ein überschätzter Hype, der auf einigen Testinstallationen in Großforschungsprojekten oder bei Service-Providern basiert? Oder führt der Siegeszug von Cloud-Services dazu, dass sich diese Technologie auch flächendeckend durchsetzen wird? Was allerdings bei der Diskussion oft übersehen wird, ist, dass unabhängig von jeglichen Überzeugungen die Rahmenbedingungen für die Durchsetzung einer Technologie stimmen müssen. Und die lauten aus meiner Sicht: Offene Standards.

Die Vorteile von offenen Standards und Schnittstellen sind schnell erklärt: Unternehmen haben wesentlich größere Gestaltungsfreiheiten bei ihrer IT-Infrastruktur. Bislang war es so, dass man bei der Entscheidung für eine Lösung an den Hersteller gebunden blieb - nicht nur in technologischer Hinsicht aufgrund proprietärer Formate, sondern meist auch in Bezug auf Service und Support.

Und auch wenn Lösungen aus einer Hand durchaus auch Vorteile haben können, versperrt dies oft den Weg, wenn neue Komponenten integriert werden sollen. Statt die bestmögliche Lösung zu integrieren, kann lediglich unter denjenigen Komponenten gewählt werden, die kompatibel sind zu der bestehenden Architektur. Es ist leicht nachvollziehbar, dass dies nicht gerade ideale Voraussetzungen sind, um hochverfügbare und agile Netzwerke aufzubauen oder zu betreiben. Und genau das erhoffen sich Unternehmen von SDN: mehr Flexibilität, einfacheres Management und schnellere Konfiguration der Netzwerke. Dies zeigt nicht zuletzt eine Umfrage der US-Zeitschrift Network World im Juni 2014. Geschlossene, proprietäre Lösungen sind hingegen genau das Gegenteil, nämlich das Grab jeglicher Innovation.

"Offenheit" hat viele Elemente: Sei es Protokoll, Schnittstelle oder Controller

Bei aller Begeisterung über "Offenheit" im Netzwerk. Ganz so einfach wie beispielsweise bei OpenSource-Software ist es leider nicht. Zumal das Thema der offenen Standards mehrere Elemente hat. Es bedarf offener Protokolle und Schnittstellen, bei SDN kommt zusätzlich noch das Element eines offenen Controllers hinzu.

Punkte die zu beachten sind

Zunächst zu einer der wichtigsten Voraussetzungen: offene Protokolle. Mit OpenFlow hat sich in den vergangenen Jahren ein Protokoll etabliert, das eine vergleichsweise einfache Architektur hat und damit eine gute Basis für Software-definierte Netze ist. Ungewöhnlich ist, dass damit zwischen mehreren Herstellern tatsächlich so etwas wie eine Einigung auf ein Protokoll erzielt wurde. Auch wenn nicht alle die aktuelle Version 1.4 unterstützen - es existiert ein Konzept, das auch von "IT-Schwergewichten" wie Google oder Facebook unterstützt wird. In Deutschland ist beispielweise die Deutsche Telekom mit dabei. Seit 2011 wird das Protokoll von der Open Networking Foundation zentral verwaltet.

Ein weiterer wichtiger Schritt in Richtung Open Networking ist der SDN-Controller der OpenDaylight-Initiative, die unter der Ägide von Linux steht und rund 40 Mitglieder hat. Mit der Bekanntgabe des Open Source Controllers zeigte die Initiative im vergangenen Jahr, dass sie eine zentrale Steuerung für alle SDN-Architekturen unabhängig vom Hersteller bieten kann - die in der Grundversion wirklich vollständig "OpenSource" ist. Während das erste Release noch stark in den Kinderschuhen steckte, trumpfte "Helium" im September mit einigen Neuerungen auf, darunter eine wesentlich engere Vernetzung mit der Orchestrierungsplattform OpenStack und insgesamt ein vereinfachtes Management.

Ein weiteres bedeutendes Kriterium für offene Netzwerke - und mit engem Bezug zum SDN-Controller - sind offene APIs, um die Programmierbarkeit zu gewährleisten. Dank dieser offenen und standardbasierten North- und Southbound APIs wie beispielsweise RestAPI lässt sich SDN erheblich einfacher implementieren und die Automatisierung und Orchestrierung von Rechenzentren vorantreiben.

Von der Theorie zur Praxis

Zwei kleine Wermutstropfen gibt es allerdings doch. Zum einen ist es so, dass es teilweise noch konkurrierende Standards gibt - hier wird sich zeigen, welche Initiativen dauerhaft die meisten Unterstützer vereinen werden. Gerade deshalb ist OpenFlow als ein positives Beispiel zu nennen und auch die OpenDaylight-Initiative verbucht eine namhafte Anzahl aktiver Unterstützer.

Der zweite Wermutstropfen betrifft die Umsetzbarkeit im Unternehmen. Denn umfangreiche Möglichkeiten beispielsweise bei der Programmierung des OpenDaylight-Controllers bedeuten auch, dass man diesen Möglichkeiten gewachsen sein muss. Kommerzielle Lösungen, die die Offenheit bewahren aber dennoch von Netzwerkspezialisten auf ihre einfache Anwendbarkeit getestet wurden, können hier eine interessante Alternative darstellen.

Insgesamt werden wir aus meiner Sicht die Entwicklung sehen, dass die zunehmende Anwendung von Cloud-Diensten auch SDN beflügeln wird. Schon jetzt nutzen viele größere Unternehmen die Vorteile dieser Technologie. Auch das grundlegende Prinzip hinter offenen Standards bei SDN wird dann zum Tragen kommen - und die Innovationskraft nicht mehr nur bei einem einzelnen Hersteller liegen. Stattdessen entwickeln Gruppen von Experten gemeinsam Lösungen für ganz spezielle und konkrete Probleme im Netzwerk. Innovation braucht offene Standards. Wer sich dem verschließt, verschließt sich auch dem technologischen Fortschritt. (bw)