Warum Nicira die Hardware-Steuerung über OpenFlow aufgegeben hat

Die Virtualisierung hat Netzwerke derart verändert, das eine Steuerung der Hardware über das OpenFlow-Protokoll nicht mehr sinnvoll ist.

Vor fünf Jahren schrieb der Nicira-Gründer Martin Casado seine Doktorarbeit in Informatik an der Stanford University. Mit einem ehrgeizigen Ziel: Er wollte das operative Modell von Netzwerken so transformieren, dass es mit der Automatisierung Schritt halten kann, die sich durch die Server-Virtualisierung ergibt.

Dazu hatte Casado das Protokoll OpenFlow erfunden, und er dachte, dieses würde das Problem ganz alleine lösen. Heute sagt er, dass das falsch war. Hardware-Steuerung über OpenFlow ist inzwischen ein heißer Trend in der Netzwerk-Branche, doch für Casado ist sie nicht mehr die richtige Antwort. Stattdessen wandte er sich dem Thema Software-Overlays für Netzwerk-Virtualisierung zu. VMware fand diese Strategie so überzeugend, dass es 1,2 Milliarden Dollar für die Übernahme von Nicira investierte.

„Das Problem ist: Wir haben uns getäuscht, und in meinen Augen hat ein großer Teil der Branche noch nicht verstanden, dass das so ist“, sagte Casado bei einem Treffen mit Journalisten in seinem Büro im US-Bundesstaat Massachusetts.

Entwickelt hatte Casado OpenFlow als Methode, um die Steuerungsebene und die Datenebene in Netzwerk-Hardware voneinander zu trennen und die Steuerung in einem zentralen „Gehirn“ – dem OpenFlow-Controller – anzusiedeln. Die Innovationen sollten Programmierbarkeit bringen und den Betrieb von Netzwerken komplett transformieren. „Das war meine Doktorarbeit in Stanford – so sollten sich Netzwerke automatisieren lassen“, sagte er. Also habe er die ersten drei Ingenieure bei Nicira das Protokoll schreiben lassen – und damit viel dafür getan, dass die Grenzen von Software-definierten Netzen (SDN) verstanden werden.

OpenFlow ist für viele Anwendungsfälle immer noch sinnvoll, vor allem für die Traffic-Steuerung, sagte Cascado. Ein perfektes Beispiel dafür seien die Verbindungen zwischen den Rechenzentren von Google. Bei Netzwerk-Virtualisierung im Rechenzentrum aber sei OpenFlow für die Steuerung der Hardware-Weiterleitung die falsche Methode.

Virtuelle Switches statt OpenFlow-Hardware

„Innerhalb des ersten Jahres bemerkten wir, dass etwas wirklich Wichtiges passierte“, sagte Casado. Server-Virtualisierung hatte die Zugriffsschicht in Rechenzentren transformiert: Die in Hypervisoren eingebetteten virtuellen Switches – vor allem vSwitch von VMware – waren zum neuen Edge des Netzwerks geworden. Und wenn dieser sich jetzt in Software auf Servern befand, warum sollte man dann noch mit OpenFlow physische Switches steuern?

Virtuelle Switches sind laut Casado aus zwei Gründen ideal für Netzwerk-Virtualisierung in Rechenzentren: „Erstens laufen sie auf x86, und x86 ist super-flexibel. Wir wissen, wie man so etwas programmiert – man muss dafür keinen Algorithmus auf irgendeinem Spezial-Chip basteln. Wenn ich die Art der Weiterleitung ändern möchte, schreibe ich einfach ein neues Programm“.

Und zweitens: „Sie sind nah am Edge. Die Netzwerk-Branche hat eine lange, hässliche Geschichte von Versuchen, zu erraten, was in den Maschinen passiert. Wenn man dagegen auf dem Server arbeitet, bekommt man Zugang zu reichhaltigen Informationen über den Edge, die es früher nie gab. Welche Adressen werden berücksichtigt? Welche Nutzer sind mit der Maschine verbunden? Man hat so viele Einblicke, wie es sich Netzwerk-Profis nur erträumen können.“

Diese Erkenntnisse brachten Casado und sein Team dazu, neu nachzudenken und einen anderen Ansatz zu wählen. „Wir hatten diesen Aha-Moment“, sagte er.

Nicira wollte weiter OpenFlow für Netzwerk-Virtualisierung nutzen, seinen Fokus aber von Hardware- zu Software-Steuerung verlagern. Man wollte virtuelle Switches kontrollieren. Dem Team bei Casado kam das perfekt vor, denn Paket-Weiterleitung ist in den heutigen Netzwerken nicht das Problem – sie sind immer noch hervorragend darin, Pakete zu den richtigen Zielen zu befördern.

Für Probleme und Verzögerungen sorgen eher all die Schichten für Regeln und Betrieb oberhalb traditioneller Netzwerk-Technik. Insbesondere die Implementation von Access Control Lists (ACLs), VLANs, Netzwerk-Isolierung und Abrechnung konnten Netzwerker in statischen Umgebungen einmal einrichten und dann vergessen. Doch als Server-Virtualisierung die Provisionierung von neuen Workloads beschleunigte und Mobilität virtueller Maschinen möglich machte, wurden die manuellen Prozesse dafür plötzlich sehr unpraktisch.

In den Augen von Casado mussten diese betrieblichen Lästigkeiten nicht auf der physischen Netzwerk-Hardware erledigt werden. Stattdessen sollten sie auf virtuelle Switches verlagert werden, die sich leicht über Software steuern lassen. So entstand die Network Virtualization Platform von Nicira, und aus diesem Grund sind virtuelle Netzwerk-Overlays neben SDN zu einem derart heißen Thema geworden.

Das Problem bei direkter Steuerung von OpenFlow-Hardware

Trotzdem sind immer noch viele Anbieter und Netzwerk-Praktiker daran interessiert, OpenFlow-Hardware für Netzwerk-Virtualisierung im Rechenzentrum zu nutzen. Für Casado aber gibt es eine Reihe von Gründen, warum das nicht funktionieren wird.

Das erste Hindernis ist das Ökosystem der Netzwerk-Anbieter: „Man bittet die Hersteller, OpenFlow in ihre Switches zu bringen, aber sie haben nicht viele Anreize dafür, weil man ihnen damit auf gewisse Weise einen Teil ihres Wertes nimmt“, so Casado. Die ersten OpenFlow-Protokolle habe er 2007 geschrieben, und seitdem habe es viele Ankündigungen gegeben, aber nur wenige nützliche OpenFlow-Switches. „Jeder, der einen nützlichen OpenFlow-Switch anbietet, hat auch einen Controller im Programm. Und ich bin sicher, dass Controller und Switches dann zusammen so eingesetzt werden, dass sie aneinander gebunden sind und die Kontrolle über die Kunden-Umgebung erhalten bleibt. Wegen solcher geschäftlicher Taktiken war es einfach zu schwierig, eine aktive Community aufzubauen“.

Viele Netzwerk-Anbieter haben OpenFlow auf ihren Switches möglich gemacht, was also meint Casado mit „nützlichen“ OpenFlow-Switches? Die meisten dieser Switches haben einfach nicht genügend frei nutzbare Kapazität in den Weiterleitungstabellen, um wirklich nützlich im Rechenzentrum zu sein, erklärte er. In einem typischen Switch-Chip gebe es eine ACK-Tabelle, eine Layer-2-Tabelle, eine Layer-3-Tabelle – „all diese Tabellen für spezielle Zwecke“, und keine davon kann für OpenFlow im Rechenzentrum genutzt werden.

„Für OpenFlow sollte die Welt so aussehen: Man hat Tabellen mit elf Tupels für Look-up, was super-allgemein ist, und zwar eine ganze Menge davon“, sagte Casado. „Um auch mit OpenFlow werben zu können, haben einige Anbieter einfach eine ihrer Tabellen überladen, mit vielleicht 5000 Einträgen. OpenFlow wird dort hineingezwängt. Die Chips sind aber gar nicht dafür ausgelegt. OpenFlow wird dafür noch angepasst, aber das wird sehr schwierig“.

Die Tabellen für Daten-Weiterleitung auf den meisten OpenFlow-Switches von heute sind in Ordnung für Forschung und Experimente, sagte Casado weiter, und auch für Traffic-Steuerung. „Aber die große Menge an Datenströmen und Verkehr im Rechenzentrum bedeutet, dass man etwas wie Layer 3 machen muss. OpenFlow wird nicht funktionieren, um die Forwarding-Fabric für Switches im Rechenzentrum aufzubauen“.

Hat die Lösung von Nicira und VMware noch Platz für OpenFlow-Hardware?

Bedeutet das, dass sich Nicira und sein Eigentümer VMware in Zukunft ausschließlich auf Software konzentrieren werden? Laut Casado gibt es drei Bereiche, in denen seine Technologie Schnittstellen mit Hardware braucht, und dafür brauche es auch einen Standard wie OpenFlow.

Der erste Punkt sei Quality of Service (Qos). „Mehr Warteschlangen sind besser. Je mehr davon Sie in Hardware haben, desto mehr Schichten an QoS können Sie den Kunden bieten. Wenn ich acht Warteschlangen habe, kann ich nur acht unterschiedliche Dienst-Klassen bieten. Bei einer Million Warteschlangen kann ich jedem Nutzer eine eigene geben“, so Casado.

QoS und ähnliche Hardware-basierte Features werden laut Casado ein einfacheres Modell für Operations, Administration und Management (OAM) bei Ethernet nötig machen. Damit könnten Nicira und andere Technologien diese Funktionen über physische wie virtuelle Workloads hinweg am Laufen halten und Fehler darin finden.

Eine weitere notwendige Schnittstelle sieht Casado zwischen Technologie zur Netzwerk-Virtualisierung und „Top of Rack“-Switches für alte Workloads, die noch nicht virtualisiert sind. „Man muss das Top of Rack steuern, um diese physischen Workloads in virtuelle Netzwerke zu bringen, und dafür braucht man ein OpenFlow-artiges Interface“, sagte Casado.

Dritter Punkt: Controller zur Netzwerk-Virtualisierung brauchen eine Schnittstelle zu Netzwerk-Appliances wie Firewalls oder Controllern für Anwendungsauslieferung. Auch hier, so Casado, werde das „OpenFlow-artige“ Interface gebraucht.

„OpenFlow selbst befindet sich in meinen Augen auf einer zu niedrigen Schicht dafür“, sagte Casado, „also haben wir etwas Neues vorgeschlagen: OVSdb-config. Damit verwalten wir den Open vSwitch zusammen mit OpenFlow. Wir können so Zustände auf höherer Ebene steuern. Wir hoffen, dass die anderen Leute es auch so machen werden, aber darauf kommt es letztlich nicht an“.

Warum kommt es darauf nicht an? Im Prinzip eignet sich jedes Protokoll dafür, lautete die Antwort von Casado – Hauptsache, es ist offen, ermöglicht Innovation und kann seine Aufgabe erledigen.

Pro+

Premium-Inhalte

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

Erfahren Sie mehr über Software Defined Networking (SDN)

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchStorage.de

SearchDataCenter.de

SearchEnterpriseSoftware.de

Close