Markus Nispel

ist als VP Solutions Architecture von Extreme Networks der Experte für strategische Netzwerkthemen.

SDN: Wer macht die Programmierung? Welches Level an Abstraktion wird benötigt?

Das Thema Software Defined Network hat neben technologischen Fragen noch zahlreiche weitere Aspekte, wie Markus Nispel, VP Solutions Architecture von Extreme Networks, in seinem aktuellen Beitrag für silicon.de darlegt. Doch allen Fragen zum Trotz: ein Netzwerk sollte “einfach Funktionieren”.

Unsere Branche hat damit begonnen, die Haupteigenschaften einer Software-Defined Networking Architektur zusammenfließen zu lassen. In einem meiner Blogs auf blogs.enterasys.com und sdncentral.com bin ich bereits auf diese Eigenschaften eingegangen und es gibt auch eine Reihe von Artikeln zu diesem Thema, wie beispielsweise bei der Network Computing, welcher eine gute Beschreibung darüber liefert.

Wenn ich mir die Eigenschaften und Versprechen von SDN ansehe, dann sehe ich als Hauptbestandteile:

  • Zentralisiertes Management & Kontrolle
  • Programmierbarkeit eines Netzwerkes
  • Herstellerinteropabilität und Möglichkeiten von Integrationen

Das zentrale Management und die Kontrolle können durch einen einzelnen, zentralisierten Controller oder durch eine zentrale Management Plane mit einer verteilten Controller Architektur umgesetzt werden: einen zentralen und programmierbaren Zugang in die Netzwerkinfrastruktur.  Zur Programmierung und Integration selbst braucht man dann natürlich eine offene und zugängliche API.

Und wahrscheinlich braucht man sogar mehr: Netzwerk-Abstraktion. Die Art und der Grad der Abstraktion hängt davon ab, was man erreichen möchte. Wenn man nur die gesamte Konfiguration aller Geräte dort “1:1” durchreicht bzw. auch nichts von der Komplexität der Netzwerk-Topologie abstrahiert, dann hat man nichts gewonnen. Das ist oft der Fall bei vielen Controller-Ansätzen, die OpenFlow nutzen: Man muss einfach sehr viel über das Netzwerk wissen, um die richtigen Entscheidungen zu treffen. Und wer außerhalb des Netzwerks kann dies wirklich?

Andererseits hat SDN für mich auch mit organisatorischen Änderungen und Prozessen zu tun – man übergibt die Kontrolle an Geschäftsbereiche außerhalb des Netzwerkteams, vielleicht sogar außerhalb der IT – das ergibt Agilität. Das Wissen über das Netzwerk mag in diesen Gruppen nahezu Null sein und sie sollten sich auch nicht damit befassen – es sollte einfach funktionieren. Aber selbst wenn man sich außerhalb des Netzwerks oder der IT befindet und ohne den Netzwerkadministrator Applikationen und Arbeitsabläufe in einer automatisierten und orchestrierten Art und Weise konfiguriert – das typische SDN-Fallbeispiel im Data Center – stellt sich eine Frage: Was muss und will der Systemadministrator über das Netzwerk wissen? Und was müssen die Applikationen über das Netzwerk wissen, in dem Sie aufgesetzt werden? “Nichts” ist keine gute Antwort, da man sich mit den Herausforderungen und Problemen auseinandersetzen muss, die Overlay Technologien heute mit sich bringen. Und “alles” ist auch keine gute Antwort, da man gegenüber dem alten Setup nichts gewinnt.

Die Einfachheit einer SDN Lösung, die Umsetzung im Unternehmen sowie auch der Erfolg der Hersteller, die SDN Lösungen bieten, wird davon abhängen, wie gut man diese Balance findet. Mögen die Spiele beginnen…