Software-Defined Networking: Wer braucht das?

Kommentieren Drucken

Seit einiger Zeit wird in der Netzbranche intensiv über Software-Defined Networking (SDN) und damit zusammenhängend auch über OpenFlow diskutiert. Das Open Networking Foundation (ONF) genannte Konsortium hat sich beides, SDN und OpenFlow, auf die Fahne geschrieben und behauptet auf der eigenen Webseite, mit SDN werde man über Netze nie wieder wie früher denken. Nun, ewig das Gleiche denken tun nur jene, die nichts dazu lernen. Insofern wird jeder, der etwas davon versteht, in ein paar Jahren über eine so dynamische Technologie wie Kommunikationsnetze anders denken als heute. Die Frage ist nur, welche Rolle SDN und Open-Flow dabei spielen werden.

Ein Blick auf die Initiatoren der ONF gibt darüber Aufschluss, wen SDN und Open-Flow am meisten interessieren: Deutsche Telekom, Facebook, Google, Microsoft, Verizon und Yahoo, also allesamt Unternehmen, die sehr große Rechenzentren betreiben müssen. Technisches Kernstück von SDN ist das OpenFlow, ein Protokoll, mit dem Netzkomponenten mit sogenannten Controllern kommunizieren. Der Controller übernimmt Aufgaben, die bei einem konventionellen Switch oder Router von der sogenannten Control Plane übernommen werden. Die Unterscheidung der Control Plane und der Data Plane hat sich in den letzten circa zwei Jahrzehnten bei Netzkomponenten etabliert. Aufgabe der Data Plane ist die (möglichst schnelle) Vermittlung von Paketen anhand sogenannter Forwarding-Tabellen. Diese legen fest, wie ein Netzgerät ein Paket mit bestimmten Merkmalen (zum Beispiel MAC- und/oder IP-Adressen) behandeln, d. h. vor allem verwerfen oder weiterleiten und über welchen Port senden soll. Die Einträge der Forwarding-Tabelle können jedoch von Mechanismen der Control Plane stammen, zum Beispiel einem Routing-Protokoll, das in der Regel von der Central Processing Unit (CPU) eines Routers oder Switches bearbeitet wird.

Welchen Sinn kann es für die Konzentration der Control Plane auf den Controller geben? Die Idee ist, dass in einem großen Netz die Konfiguration vieler intelligenter Komponenten entfällt und komplexe Aufgaben der Control Plane nur noch vom Controller übernommen werden. Die Namensgleichheit mit einem Wireless Local Area Network (WLAN) Controller ist nicht zufällig. Auch in einem Controller-basierenden WLAN ist die Intelligenz auf die Controller konzentriert. Die WLAN Access Points werden von Controllern gesteuert. Der OpenFlow-Ansatz ist ähnlich. OpenFlow Switches sollen sich auf die Data Plane konzentrieren. Die Control Plane ist die Domäne des Controllers. Man stelle sich ein ganz großes Rechenzentrum vor, das aus hunderttausenden virtuellen Servern besteht, die auf tausenden physikalischen Servern laufen. Der Betreiber eines solchen RZs hat ein großes Interesse daran, dass die ganze Infrastruktur aus gleich aufgebauten und standardisierten Modulen besteht. Die Netzkomponenten dieser Module müssen dann einheitlich konfiguriert sein und nach den gleichen Verfahren und Modellen funktionieren. Die Konzentration der Intelligenz auf den Controller erleichtert die Einrichtung, den Betrieb und die Erweiterung einer solchen Infrastruktur.

Daher ist das Interesse großer RZ-Betreiber an OpenFlow kein Zufall. Auch kein Zufall ist die zeitliche Koinzidenz der OpenFlow-Aktivitäten mit dem Trend Cloud Computing. Wenn Betreiber öffentlicher Clouds erfolgreich Kunden anwerben, müssen sie eines ihrer wichtigsten Versprechen, nämlich dass sie eine IT-Infrastruktur dank Synergieeffekten effizienter und wirtschaftlicher betreiben können als ihre Kunden, einhalten. Sie müssen ein RZ der o. g. Dimensionen insgesamt mit deutlich weniger Mitarbeitern betreiben als die Summe der bisher dafür eingesetzten Mitarbeiter ihrer Kunden.

Die Motivation für die Standardisierung von OpenFlow ähnelt der Motivation jeder anderen Standardisierung, vor allem: Vermeidung der Abhängigkeit von einzelnen Herstellern, unkomplizierter Austausch einzelner Komponenten und Herstellung einer Marktmacht durch Bündelung der Potenziale mehrerer Hersteller. Ein Controller des Herstellers x soll eine Komponente des Herstellers y steuern können, solange beide die OpenFlow-Spezifikation einhalten.

Was hat das Ganze mit dem Begriff SDN zu tun? Der Controller basiert vor allem auf Software, die auf einem Standard-Server laufen soll. Dadurch soll die Möglichkeit eröffnet werden, dass ein Markt für Lösungsanbieter entsteht, die ihre Netzlösung auf Controller-Basis entwickeln. Die Konfiguration des Netzes erfolgt dann Software-gesteuert, womit wir bei der Namensgebung für SDN wären.

Soweit die Idee. Wie ist sie aber zu bewerten?

Grundsätzlich ist zu berücksichtigen, dass das Design und der Aufbau sehr großer Rechenzentren, die von Betreibern öffentlicher Clouds genutzt werden, anderen Gesetzmäßigkeiten und Prioritäten folgen als das Design und der Aufbau von wesentlich kleineren Umgebungen, die nur von einem Unternehmen genutzt werden. Ein privates RZ hat meistens nicht die dringenden Probleme, mit denen sich ein Public-Cloud-Anbieter auseinandersetzen muss. Andererseits kann sich ein Unternehmen für das eigene, privat genutzte RZ-Netz in der Regel keine Lösung leisten, für die kein einziger Lieferant verantwortlich ist. Stellen Sie sich die Situation vor, in der ein Controller- und ein Switch-Hersteller sich gegenseitig für eine Fehlfunktion im Netz verantwortlich machen. Bei der Komplexität von OpenFlow sind Fehlfunktionen und Interoperabilitätsprobleme trotz Standard nicht ausgeschlossen. Der Alptraum jedes Betreibers eines kleinen, privaten Rechenzentrums ist es, mit seinem Problem allein gelassen zu werden, weil ihm selbst die Expertise und der tiefe Einblick fehlen, um die Zuständigkeit für ein Problem eindeutig zuweisen zu können. Große Cloud-Anbieter haben völlig andere Möglichkeiten, Probleme selbst zu analysieren, den Verantwortlichen dafür zu finden und ihn zu einer Lösung zu motivieren. Eine Firma Microsoft oder Google ist für jeden Lieferanten so wichtig, dass die Bearbeitung jedes Problems auch für den Lieferanten oberste Priorität hat. Wie viele RZ-Betreiber gibt es, denen eine solche privilegierte Stellung zukommt?

Deshalb legen die meisten Betreiber privater Rechenzentren Wert darauf, in ihrer Umgebung klare Zuständigkeiten für bestimmte Teilbereiche der Infrastruktur zu haben. Und es haben sich im Laufe der Jahre nun einmal spezialisierte Kompetenzbereiche für die Bereiche Netz, Speicher, Server und Virtualisierung herausgebildet. Für den Betreiber eines relativ kleinen Rechenzentrums ist die Situation mit diesen verschiedenen Kompetenzschwerpunkten bereits komplex genug. Viele sehnen sich ja nach weniger Komplexität, nach der guten alten Zeit, in der ein Unternehmen den Großrechner, die dazu gehörenden Kommunikationseinrichtungen, die Endgeräte und sogar viel Software dazu lieferte. Noch mehr Komplexität, zum Beispiel durch die Trennung der Zuständigkeit für die Control Plane und Data Plane innerhalb des Teilsystems Netz, ist das Letzte, wonach solche RZ-Betreiber fragen. In ihrem Bestreben nach Vereinfachung der Verhältnisse achten viele Betreiber kleiner und mittlerer Rechenzentren darauf, nur ja keine „exotische“ Lösung einzusetzen. Für solche RZ-Betreiber soll die Netzinfrastruktur am besten mit denselben Produkten und derselben Konfiguration vielfach erprobt und bewährt sein. Für die meisten kommen Netze mit Produkten verschiedener Hersteller nicht infrage.

Mit Unikaten und Sonderlösungen haben die großen Provider aber keine vergleichbaren Probleme. Vielmehr kommt es darauf an, Dienstleistungsprodukte anzubieten, die einen Markt möglichst schnell erschließen. Eine funktionierende Sonderlösung, die sich gut verkauft, d. h. im Falle der Public Clouds schnell Millionenumsätze generiert, ist kein Problem. Solche Anbieter erwarten gerade von SDN, dass sich Sonderlösungen schnell entwickeln lassen.

Wenn Sie zu den RZ-Betreibern gehören, die solche Sonderlösungen brauchen, wenn Sie schon nach Lösungen und Funktionen suchen, die von den bisherigen Netzprodukten nicht angeboten werden, dann sollten Sie SDN und OpenFlow mit großem Interesse verfolgen. Funktionierende, produktive Referenzinstallationen in großen Rechenzentren gibt es allerdings noch nicht. Aber mittlerweile haben sich viele führende Netzhersteller wie Alcatel-Lucent, Brocade, Cisco, Extreme, HP und Juniper der ONF angeschlossen. Sie wollen vor allem den o. g. Initiatoren der ONF zeigen, dass sie sich der Herausforderung stellen und nicht abseits stehen wollen, wenn es um die Lösung besonderer Herausforderungen großer Rechenzentren geht. Aber solche Situationen gab es in der Netzbranche häufig. Nicht die Idee jedes Konsortiums mit einer langen imponierenden Mitgliederliste hat sich durchgesetzt.

Wenn Sie Betreiber eines eher kleinen bis mittleren Rechenzentrums sind, in dem die Anzahl der Netzkomponenten im ein-, zwei- bis maximal unteren dreistelligen Bereich liegt, müssen Sie sich höchstwahrscheinlich Herausforderungen stellen, für die SDN und OpenFlow noch keine Lösung bieten. Ob es jemals dazu kommt, dass die Betreiber kleiner und mittlerer RZs wirklich von SDN und OpenFlow profitieren, ist noch offen. Diese RZ-Betreiber sollten SDN und OpenFlow auch nicht ignorieren, aber immer berücksichtigen, dass der Fokus dieser Trends noch bei den RZs großer Cloud-Anbieter liegt.

zugeordnete Kategorien: LAN, Virtualisierung
zugeordnete Tags: , , ,

Sie fanden diesen Beitrag interessant? Sie können



Anmerkungen, Fragen, Kommentare, Lob und Kritik:

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

.