Brocade-Manager: OpenFlow-SDN wurde zu früh zum Produkt gemacht

Auf dem Weg zu Software-definierten Netzwerken ist OpenFlow als universelle Steuerungsebene entwickelt worden, aber „unfertig“ auf den Markt gekommen.

Durch Software sollen die Netzwerke von morgen zu offenen, programmierbaren Umgebungen aus Komponenten unterschiedlicher Hersteller werden. Doch derartige Software-definierte Netzwerke werden nicht unbedingt auf einer zentralisierten Architektur mit OpenFlow-Controller basieren, sagte jetzt David Meyer, CTO des Bereichs Service-Provider bei Brocade: OpenFlow sei verfrüht zum Produkt gemacht worden, so Meyer in dieser Woche bei einem Vortrag über große Netzwerk-Trends bei der Konferenz Techs in Paradise (TIP) 2013 in Honolulu, finanziert von Internet2, ESNet und dem Asia Pacific Advanced Network.

„OpenFlow 1.0 hatte nicht sehr viele Funktionen, nicht die nötige Funktionalität. Es war toll für Forschungsarbeit, aber wir haben Probleme mit allen möglichen Aspekten des Protokolls selbst“, sagte Meyer. Als Beispiel nannte er Schwierigkeiten bei der Zuordnung von Fluss-Tabellen: Informationen könnten verloren gehen, wenn ein Controller mit einem Switch kommuniziert oder umgekehrt.

Brocade hat OpenFlow-geeignete Router im Angebot, die schon im 100-GbE-Netzwerk von Internet2 eingesetzt werden, das Hunderte von Institutionen im Bereich Forschung und Bildung verbindet. Typische Teilnehmer der Konferenz aus dem Technik-Bereich würden wohl jederzeit bestätigen, dass OpenFlow spannend für Forschungsarbeit ist und auch vereinzelt Probleme in ihren Netzwerken löst – wirklich reif für den Produktiv-Betrieb ist es aber noch nicht. So kann es vorkommen, dass Controller immer weiter Pakete senden, auch wenn keine Verbindung zur Verfügung steht; mancherorts wird auch an einem Controller-Failover gearbeitet.

OpenFlow 1.3 wurde im vergangenen Frühjahr verabschiedet und soll einige der Probleme lösen, die es Netzwerk-Technikern derzeit noch macht. Letztlich wird es aber noch viel mehr Tests mit OpenFlow geben müssen – Techniker brauchen eine Umgebung, in der sie das Netzwerk absichtlich stören und dann wieder aufbauen können.

In einem Gespräch nach dem Vortrag sagte Meyer, er frage sich, ob das durch schnelle Produkt-Releases nicht eher verhindert werde. „Wir müssen Ideen ausprobieren und eine Kultur aufbauen, in der Scheitern nicht missbilligt wird. Wir wissen nicht, was das Feature der Zukunft sein wird, bevor wir ein technisches, intellektuelles und kulturelles Umfeld geschaffen haben, das Agilität ermöglicht“, sagte er.

Sind zentralisierte Controller zu radikal?

OpenFlow als Sprache ist jedoch nicht die einzige Herausforderung, die Meyer im Bereich Software-defined Networking (SDN) sieht. Im Allgemeinen sind Techniker begeistert über das Potenzial von OpenFlow, zur allgemeinen Kommunikationssprache in Umgebungen zu werden, in denen sie die Steuerungsebene des Netzwerkes mit direktem Einfluss auf die Forwarding-Ebene abstrahieren und zentralisieren können.

Laut Meyer ist dies jedoch nur eine von mehreren möglichen Architekturen. Eine Zentralisierung der Steuer-Ebene bezeichnete er als das radikale Ende eines „Kontinuums“ der Netzwerk-Programmierbarkeit. Am anderen Ende dieses Spektrums befinde sich der Ansatz von Nicira. Hier wird ein Software-Overlay mit eigener Steuer-Ebene über der physischen Infrastruktur angelegt, „und der eigentliche Pfad interessiert überhaupt nicht“, so Meyer.

Zwischen den beiden Extremen findet sich ein Mittelweg, der laut Meyer „Programmierbarkeit in der bestehenden Steuer-Ebene erlaubt“. Die Arbeitsgruppe I2RS (Interface to the Routing System) der IETF zum Beispiel arbeite an einem Rahmen, der zwecks Programmierbarkeit indirekten Zugang zur Weiterleitungsebene gebe. Cisco wiederum hat eine SDN-Strategie angekündigt, die mit einer bestehenden Struktur für die Steuer-Ebene funktioniert. Andere Anbieter wie Brocade selbst wollen hybride OpenFlow-Netzwerke unterstützen, in denen Techniker sowohl OpenFlow als auch ihre bestehenden Architekturen für die Steuerungsebene nutzen können.

Letztlich durchsetzen dürfte sich laut Meyer eine Kombination aus den unterschiedlichen Ansätzen – und er zerbricht sich nicht den Kopf darüber, welche das genau sein wird. Die wahre Magie von SDN werde darin liegen, dass es Umgebungen schafft, die vollständig offene APIs bieten und in denen jeder Hardware- und Software-Anbieter leicht eine vollständige Orchestrierung mit Integration über Netzwerke, Rechner und Storage hinweg realisieren kann.

Dafür werde es eine „gemeinsame Sprache“ brauchen, die mit Switches, Storage-Arrays oder Rechen-Elementen gleichermaßen kommunizieren kann und dann „eine gemeinsame Infrastruktur nutzt, um all das zu verwalten“, so Meyer. Ob OpenFlow dazu geeignet ist, darüber sei er sich aber nicht sicher.

Und noch schwieriger: Derartige Umgebungen würden zugleich zu einer „Ent-Siloisierung“ der IT führen und Bereitschaft der Anbieter erfordern, ihre Hardware und Software offen zu gestalten. Beides bereitet ihnen laut Meyer aber „Bauchschmerzen“: „Sie mögen keine Ökosysteme, sie mögen lieber end-to-end.“

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Software Defined Networking (SDN)

0 Kommentare

Älteste Beiträge 

Passwort vergessen?

Kein Problem! Tragen Sie Ihre E-Mail-Adresse unten ein. Wir werden Ihnen eine E-Mail mit Ihrem Passwort schicken.

Ihr Passwort wurde an die folgende E-Mail-Adresse gesendet::

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchDataCenter.de

SearchEnterpriseSoftware.de

Close