Foto: Markus Feilner

Während Open Flow von Idealen und der Technik getrieben ist, zählt für Konzerne zuerst die Frage, wie sich Software Defined Networking monetarisieren lässt. Vor allem VMware, aber auch Midokura, Cisco und IBM bringen eigene Ansätze als Konkurrenz zu Open Flow.

Wer sich mit dem Thema Software Defined Networking beschäftigt, bekommt den Eindruck, SDN sei nur in Sachen Cloud Computing interessant. Und in der Tat fallen die Begriffe Cloud und SDN meist im gleichen Atemzug. Über den Umweg gängiger Cloud-Umgebungen und dort insbesondere mit Hilfe von Open Stack hat sich Open Flow mitsamt seinen Frontends zu einem weithin akzeptierten Standard entwickelt. Und wer von SDN im Open-Stack-Kontext redet, meint damit fast immer das Open-Vswitch-Projekt [1], das bekanntlich auf Open Flow zurückgreift.

Ein Stück vom Kuchen

Diese Vereinnahmung des SDN-Begriffs kann Firmen wie VMware und Cisco freilich nicht gefallen. Denn selbstverständlich möchten auch die Platzhirsche [2] ein Stück des Kuchens abhaben, den sie griffig und Cloud-unabhängig als Software Defined Data Center (SDDC) titulieren. Aus diesem Grund wundert es nicht, dass die großen Unternehmen in letzter Zeit ihre eigenen SDN-Lösungen propagieren. Nicht jedes von ihnen hatte allerdings bereits passende Entwicklungen in der Schublade: VMware kaufte sein SDN-Angebot ein, übernahm die Firma Nicira und vermarktet die Software nun als VMware NSX [3].

Die Konkurrenz hat den Trend ein wenig verschlafen und versucht jetzt, aufzuholen: Cisco ([4], Kasten “Cisco und das SDN”) wagt sich mit seinem Ansatz gerade aus der Deckung und möchte Anteile am Netzwerkmarkt halten. Ganz erwartungsgemäß will auch Big Blue noch ein Wörtchen mitreden ([5], Kasten “Ganz frisch: IBM SDN VE”) und geht deshalb mit einer eigenen SDN-Software an den Start.

Anders als im OSS-Umfeld ist der Markt kommerzieller SDN-Lösungen derzeit unübersichtlich. Als Beispiel für manchen Underdog im SDN-Business stellt der Artikel stellvertretend Midokura vor. Das Unternehmen mit einer überschaubaren Anzahl an Büros weltweit bietet in Form von Midonet ([6], Kasten “Der Underdog – Midonet”) auch einen SDN-Stack an, mit dem es gegen die großen Konzerne anzurennen versucht.

Auch auf Seiten freier Software sind einige Projekte im Spiel: Open Vswitch, Open Daylight, Ryu und noch einige Nischenprodukte tauchen auch im kommerziellen Zusammenhang immer wieder auf. Diesen Lösungen ist gemein, dass sie im Hintergrund Open Flow verwenden. Anders ist das bei den kommerziellen Produkten: Es existieren bis dato nur wenige echte Referenzinstallationen, die auf Basis der SDN-Software von VMware oder Cisco arbeiten. Dieser Artikel konzentriert sich daher auf ein konkretes Beispiel mit VMware, das am längsten auf dem Markt ist und viele bekannte Konzepte vereint.

Auf Shopping-Tour

Angesichts der wachsenden Konkurrenz von Xen, KVM und vor allem Open Stack hat der Virtualisierungs-Platzhirsch VMware in letzter Zeit viel Geld investiert, um vorhandene Funktionen mit Cloud-Computing-Umgebungen unter einen Hut zu bringen. Ein gutes Beispiel liefert Open Stack, mit dem VMware mittlerweile klaglos zusammenarbeitet: Ein vorhandenes Vcenter lässt sich aus Open Stack heraus problemlos ansprechen.

Langfristig genügte es VMware aber offensichtlich nicht, nur den Markt für die Virtualisierung von Computing-Angeboten zu bedienen. Mit dem Anspruch, die Messlatte im Sinne des Software Defined Data Center selbst anzulegen, knöpfte sich VMware mit dem Software Defined Networking ein weiteres Ziel auf dem Weg vor. Anstatt aber ein eigenes Entwicklerteam für ein passendes Produkt aufzubauen, angelte sich der Konzern kurzerhand Nicira [7], einen der Vorreiter und quasi das Bootcamp für SDN-Experten im IT-Bereich.

Nicira

Das amerikanische Unternehmen Nicira war durchaus kein Unbekannter. Seine Gründer sind Nick McKeown, Scott Shenker und Martin Casado. Gerade der Dritte profilierte sich als treibender Kopf hinter der Entwicklung von Open Flow. Casados wissenschaftliche Arbeit an der Uni in Stanford hat Open Flow eine definierte Grundlage verschafft, und auch Open Vswitch geht auf das Konto von Nicira. VMware erwarb also nicht irgendein Unternehmen, sondern eine der wichtigsten Firmen im SDN-Land.

NVP

Vorrangig gekauft hat VMware Nicira aber wohl wegen der Network Virtualization Platform (NVP, Abbildung 1), einem von Nicira entwickelten Open-Flow- und Open-Vswitch-Aufsatz. Das Produkt war quasi ein Framework um Open Vswitch herum, das die in Open Flow vorgesehene Funktionalität über kommerzielle aber immerhin standardisierte Interfaces exponiert und dabei deutlich mehr zu bieten hat, als es bei Open Vswitch ab Werk der Fall ist.

Abbildung 1: Niciras NVP ist nun Bestandteil von VMwares NSX. Die Grafik zeigt, wie sich VMware den ganzen Stack vorstellt.

Relaunch unter einem neuem Mäntelchen

Mit einem Schlag erwarb VMware sowohl die Software als auch die gesamte Entwicklertruppe von Nicira. Kurze Zeit später folgte ein Relaunch von NVP als VMware-Brand: VMware NSX war geboren, NVP wurde ein Teil davon. Welche Komponenten von NSX ein Kunde zum Einsatz bringt, hängt von der Infrastruktur vor Ort ab: Wer bis dato nur auf Vsphere, Vcenter und Co. gesetzt hat, benutzt lediglich den Controller-Cluster von NVP und setzt bei den Hypervisoren mittelfristig auf den zuvor schon vorhandenen Virtual Distributed Switch (Abbildung 2).

Abbildung 2: Auf physikalischer Ebene baut VMware NSX ein virtuelles L2-Netz auf einem echten Layer-3-Netzwerk auf. Dabei vermittelt an vielen Stellen Open Vswitch (in der Abbildung kurz als OVS gekennzeichnet) zwischen den Fabrics.

Kommen Linux-Hypervisoren auf Basis von KVM oder Xen zum Einsatz, sieht die Sache anders aus: Dann übernimmt NVP praktisch durchgehend das Kommando. Dass sich NVP ursprünglich im Linux-Kontext wohler fühlte als im klassischen VMware-Universum, lässt sich auch aus einer anderen Tatsache ablesen: Auf das Konto von Nicira gehen nicht nur NVP und Open Flow, sondern auch beträchtliche Teile von Open Stack Neutron ([8], vormals auch als Quantum bekannt), der SDN-Komponente von Open Stack (Abbildung 3 und 4).

Abbildung 3: Open Stack wird zum Consumer von NVP. Dank des passenden Plugins …

Abbildung 4: … lassen sich problemlos die NVP-Funktionen aus Neutron heraus nutzen.

Die NVP-Architektur

Das ideale NVP-Setup im Unternehmen hängt davon ab, ob bereits VMware-Komponenten im Einsatz sind oder ob VMware erst als neuer Lieferant in ein Rechenzentrum einzieht. Allen Varianten gemein ist, dass es einen NVP-Controller-Cluster gibt. Der ist quasi das Hirn der gesamten SDN-Infrastruktur: Er enthält die Datenbank mit der spezifischen Konfiguration für die vorhandenen virtuellen Netze der Kunden.

Es handelt sich beim NVP jedoch nicht um eine Kombination von Bordmitteln wie MySQL. Vielmehr stellt der Controller-Cluster eine NVP-Eigenentwicklung dar, und er beherrscht dabei auch Funktionen wie die automatische Replikation von Daten. Der Controller ist in aktuellen NVP-Installationen stets ein redundant aufgebauter 3-Knoten-Cluster. Fällt einer der Server also aus, kümmert sich NVP automatisch um einen Failover.

Fest mit dem NVP-Controller verbunden ist ein RESTful-API: Das ermöglicht es, Änderungen an der Konfiguration des NVP-Clusters vorzunehmen – per HTTP steuerbar. Darüber lässt sich das gesamte Verhalten des NVP-Clusters detailliert bestimmen. Natürlich bietet NVP auch einen eigenen Consumer für dieses API, ein umfangreiches Webinterface, das im Hintergrund REST-Befehle absetzt.

Die physikalische Topologie des restlichen Netzwerkes hängt vom genutzten Deployment-Szenario ab. Im Vsphere-Beispiel holen sich die Hypervisoren ihre Konfigurationsparameter von dem oben beschriebenen Controller-Cluster.

Topologie

Langfristig will VMware die einzelnen Bestandteile der NSX-Architektur in ein einheitliches Produkt gießen. Bis dahin behalten Vsphere-basierte Architekturen ihre Sonderrolle und nutzen nur bedingt die Features von NVP. Allerdings investiert die Firma einen großen Teil ihrer Arbeit derzeit auf diese Komponente – ein weiterer Beleg dafür, dass VMware diese Technologie für strategisch wichtig hält.

Deutlich eleganter wirkt VMwares NSX mit seiner Kernkomponente NVP. Für freie Cloud-Lösungen wie Open Stack oder Cloud Stack hat Nicira NVP ja eigentlich entwickelt. Dass es sich hier auch mehr zu Hause fühlt, spürt der Admin vielerorts.

Im Open-Stack-Kontext greifen die einzelnen Komponenten von NVP fast nahtlos ineinander: Auch hier gibt es natürlich den Controller-Cluster samt API und Webinterface, der sich um alle Belange der NVP-Konfiguration kümmert. Hinzu kommen diverse Zusatzkomponenten, die im Cloud-Kontext eigene Rollen übernehmen.

SDN in der Cloud

Wer die Funktionen der einzelnen NVP-Komponenten verstehen will, braucht ein wenig Hintergrundwissen über SDN, Cloud Computing und Netzwerke im Allgemeinen, weil sich in einer Wolke ganz andere Anforderungen stellen als in konventionellen Setups. SDN-Deployments müssen in hohem Maße dynamisch sein, was den Einsatz klassischer Technologien häufig ausschließt: VLANs beispielsweise sind tendenziell eine statische Angelegenheit. Ein Kunde in der Cloud will aber nicht darauf warten, dass ein Admin ein VLAN auf allen Switches einrichtet.

Freilich ist es aber auch in einer Cloud notwendig, dass die VMs verschiedener Kunden über die Grenzen von Computing-Knoten hinweg sicher kommunizieren. Im SDN-Konstrukt muss also ein Ersatz für VLANs her, der die sichere Kommunikation von VMs einzelner Kunden innerhalb des Setups garantiert.

Für die Cloud geht man deshalb typischerweise von mehreren, rein virtuellen Layern aus (siehe auch Abbildung 2): Zwischen den einzelnen Computing-Knoten entspannt sich ein virtuelles Layer-2-Netzwerk, das physikalisch auf dem Layer 3 liegt, weil es Techniken wie GRE-Tunneling benutzt.

Um das Netzwerk nach außen kümmern sich spezielle Knoten der Cloud, die so genannten Layer-3-Knoten: Sie routen einerseits Pakete von VMs ins Internet, und über eine Zusatzkomponente (nämlich den DHCP-Dienst) sorgen sie auch dafür, dass Kunden-VMs IP-Adressen erhalten, die zum jeweiligen privaten und virtuellen Kundennetzwerk passen. Die Verwaltung der Netzwerktopologie obliegt in typischen Cloud-Setups allein dem Kunden, der sich seine privaten Netze so anlegen kann, wie es ihm gefällt. Im Idealfall entsteht so ein Setup, in dem jeder Kunde nach seiner Facon glücklich wird, während der Anbieter sich über eine hochgradig flexible Installation freut.

Neutron als Blaupause

Open Stack Neutron, die SDN-Komponente der Cloud-Umgebung, bildet für diese Art der Installation quasi die Blaupause. In einer Standardinstallation kümmern sich bei Open Stack Open Flow und Open Vswitch Hand in Hand darum, die gewollten Effekte zu erreichen.

Wie passt NVP hier rein?

Die physikalische Netzwerktopologie einer NVP-Installation ist so flach wie im Beispiel beschrieben. VLANs sucht man hier meist vergebens. VMware nennt dieses physikalische Netzwerk offiziell übrigens Layer-3-Fabric (siehe Abbildung 1). Tatsächlich ist diese Komponente das virtuelle L2-Netzwerk im physischen Layer 3: Jeder Hypervisor-Host betreibt seine eigene Instanz von Open Vswitch.

Auf den Hypervisoren unterscheidet sich ein NVP-Setup damit gar nicht so sehr von einem Setup, das ohne NVP auskommt und nur auf das bekannte Open Vswitch setzt. Letzteres kümmert sich darum, dass die Systeme im Hintergrund Open-Flow-Tabellen anlegen und entsprechend der gewünschten Konfiguration warten. In einem auf Open Flow basierenden Netz beruht schließlich jeglicher Paketfluss auf eben den Flows, die Open Flow im Kernel verankert. Hinzu kommen im NVP-Setup die Layer-2- und Layer-3-Gateways. Die Layer-2-Gateways sind eine NVP-Besonderheit: Sie bieten die Möglichkeit, mit externen Netzwerken Verbindungen herzustellen, die “außen” über diverse, auch geroutete Pfade führen können, während nach innen in der virtuellen Sicht das gesamte L2-Netz noch immer wie ein großes Netzwerksegment aussieht. Anders formuliert: Über die L2-Gateways in NVP können Kunden ihr vorhandenes Netz in ein virtuelles Cloud-Netz integrieren und so die Migration von echtem Blech in virtuelle VMs erleichtern. Überhaupt hat sich VMware dem virtuellen Layer 2 stärker gewidmet als es Open Vswitch tut (Abbildung 5).

Abbildung 5: VMware NSX erfindet jede Menge Funktionalität um Open Vswitch herum.

Layer 2 und 3

Denn während bei Open-Vswitch-Setups das gesamte Layer-2-Netz im Hintergrund entweder über GRE-Tunnel zwischen den Hypervisoren, den L3-Gateways oder über separate, physikalische VLANs funktioniert, bietet VMwares Ansatz mehr: Außer GRE oder VXLAN lässt sich bei NVP auch IPsec nutzen, wenn zwei Computing-Knoten aus Sicherheitsgründen verschlüsselt reden sollen.

VMware nennt diesen Ansatz “Programmatic Tunneling”, die Technik ist deutlich umfangreicher als die mit Open Vswitch gelieferte. Als offensichtlicher Vorteil zählt auch, dass diese Art von Layer-2-Routing dabei hilft, Kunden von bestehenden, klassischen Virtualisierungsumgebungen hin zu Cloud-Lösungen zu migrieren.

Die Layer-3-Gateways im NVP-Kontext sind – siehe oben – für das Routing von Paketen nach draußen verantwortlich, ihre Rolle entspricht also ziemlich genau jener, die klassische Layer-3-Gateways in einem Open-Stack-Setup mittels Open Vswitch auch einnehmen.

Dann gibt es noch die Service-Nodes: So nennt VMware Netzwerkknoten, die den Hypervisor-Nodes Arbeit abnehmen, insbesondere also Broadcast- sowie Multicast-Traffic und Unicast-Pakete an unbekannte Adressen. In großen SDN-Deployments verursacht solcher Geister-Traffic bereits jede Menge Verkehr auf der Leitung; je mehr sich die Hypervisor-Knoten selbst um ihn kümmern müssen, umso weniger Ressourcen bleiben ihnen für das eigentliche Computing.

Die Service-Nodes gelten als VMwares Antwort auf berechtigte Kritik von Admins, denen SDN-Deployments suspekt erschienen, weil sie DOS-Angriffe ermöglichen. Schon mit Broadcast- oder Multicast-Traffic lässt sich in einem Hypervisor-Verbund mit GRE-Verbindungen ein echtes Denial-of-Service starten, das wahllos VMs beeinträchtigt. Indem VMware diesen Traffic an separate Hosts auslagert, verringert es die Gefahr deutlich.

Hochverfügbar oder lieber Standalone?

VMware hat sich auch eines weiteren Problems angenommen, das im normalen, auf Open Vswitch fußenden Open Stack derzeit ungelöst ist: Die Hochverfügbarkeit von Netzwerkdiensten. Typische Open-Stack-Installationen benötigen dazu Pacemaker, das im Stile eines klassischen Failover-Clusters ausgefallene Dienste wie das Layer-3-Gateway oder den SDN-Controller ersetzt.

Bei NVP sind alle diese Funktionen bereits enthalten, und zwar mit automatischem Failover. Fällt ein Knoten des Controller-Clusters aus, übernimmt der nächste. Ausfallende L2- oder L3-Gateways ersetzt NVP automatisch durch eine andere Instanz – und das fast augenblicklich, sodass es zu keiner merklichen Downtime kommt. Wer sich bereits mit Open Stack beschäftigt hat und dort über der Hochverfügbarkeit der Open-Stack-Komponenten brütete, weiß solche Features zu schätzen.

Fast schon überflüssig zu erwähnen, dass die Integration von Open Stacks SDN-Dienst Neutron und VMwares NVP annähernd perfekt ist – schließlich stammen beide Programme in weiten Teilen von denselben Entwicklern, und VMware hat nach dem Kauf von Nicira viel Wert darauf gelegt, die gute Open-Stack-Integration beizubehalten.

Das darf aber nicht darüber hinweg täuschen, dass NVP auch ohne Open Stack gut benutzbar ist. Sobald Linux-basierte Hypervisoren im Spiel sind, kann das Programm seine Dienste bieten. Die Konfiguration passiert dann natürlich nicht direkt aus der Cloud-Umgebung heraus, sie bleibt am Administrator hängen.

Fazit: Wohl zukunfsträchtig, aber teuer

Die Cloud und kein Ende: Allen voran VMware lässt derzeit wenig Zweifel daran, wo nach Meinung der Platzhirsche die Reise hingeht – nämlich weiter in die Wolken. Wer eine Cloud-Computing-Umgebung aufbaut, hat viele Möglichkeiten, sich mit kommerziellen Zusatzdiensten auszustatten. Die Kombination aus Open Stack und VMware erscheint derzeit eine der vielversprechendsten zu sein. Mehrere große Unternehmen wie Ebay oder der US-amerikanische Anbieter von Hosting-Dienstleistungen Rackspace setzen auf NVP (Rackspace sogar im direkten Tandem mit Open Stack). Mittlerweile vermarktet VMware NVP für Umgebungen, in denen KVM und Xen den Ton angeben, auch als separates Produkt, losgelöst von Open Stack.

Das Unternehmen sieht darin offensichtlich einen Weg, den Fuß auch bei den Unternehmen in die Türe zu kriegen, die sich VMware für Virtualisierungsdienste nicht zulegen wollen. In der Community genießt NVP selbst bei den FLOSS-Entwicklern viel Prestige; nicht selten scheint es, als schiele man bei Open Flow etwas neidisch auf NVP, weil das Zusatzfunktionen bietet, die Open Flow selbst fehlen.

Einziger NVP-Pferdefuß dürfte wohl der Preis sein, denn die Lizenzen lässt sich VMware nach Erfahrung des Autors eine satte Stange Geld kosten. Das Plus an Komfort im Vergleich mit einer OSS-Lösung ist insofern ziemlich teuer erkauft.

Gegenüber Preisanfragen schweigt sich die Branche wohlweislich lieber aus: Nur Midokura sah sich in der Lage, dem Linux-Magazin auf Nachfrage binnen zwei Wochen einen konkreten Preis für das Produkt und den Premium-Support zu nennen.

Der Autor

Martin Gerhard Loschwitz arbeitet als Principal Consultant bei hastexo. Er beschäftigt sich dort intensiv mit den Themen HA, Distributed Storage und Open Stack. In seiner Freizeit pflegt er Pacemaker für Debian.