© Baloncici, 123RF

In klassischen Virtualisierungsumgebungen ist Software Defined Networking ein nettes Add-on, aber in Clouds gehören virtuelle Netze zum Pflichtprogramm. Am Beispiel Open Stack lässt sich gut nachvollziehen, wie Clouds die abstrahierte Netzwerklogik konkret nutzen.

Wer sich zurzeit mit dem Thema Software Defined Networking beschäftigt, tut das auffallend oft im Kontext mit Cloud Computing. Tatsächlich wäre SDN heute nicht annähernd so verbreitet, hätten Lösungen wie Open Nebula oder das omnipräsente Open Stack nicht als integralen Teil SDN an Bord. Entsprechend finden sich die größten SDN-Setups in Clouds. Grund genug, genauer hinzusehen: Wieso passt das SDN-Konzept so gut zur Cloud? Wie setzen Clouds SDN um? Am Beispiel von Neutron, dem Open-Stack-Modul, das die SDN-Verwaltung übernimmt, lässt sich das gut illustrieren.

SDN-Grundlagen

Bei Software Defined Networking geht es vor allem darum, Management-Funktionalitäten im Netzwerk von der Switch-Hardware zu entkoppeln (Decoupling). Wo in konventionellen Setups VLANs auf der Switch-Ebene im Einsatz sind, finden sich in SDN-Umgebungen nur dumme Switches: Ihre Aufgabe besteht lediglich darin, Pakete von einem Port zu einem anderen weiterzuleiten. Eine Aufteilung des Netzwerks in logische Segmente leisten sie nicht mehr selbst.

Die Motivation dafür liegt auf der Hand: Die Konfiguration der Switches ist meist statisch, im laufenden Betrieb kann sie nur ein Admin anpassen. Clouds sollen aber so automatisch wie möglich funktionieren. Es wäre in einer Cloud nicht praktikabel, müsste die Switch-Konfiguration etwa für ein neues VLAN manuell geändert werden, nachdem sich ein neuer Kunde registriert hat.

Die entsprechende VLAN-Funktion ist in Clouds aber dennoch nötig. Schließlich soll ein Kunde nicht den Traffic sehen, den ein anderer Kunde in seinem virtuellen Cloudnetz produziert. Was in klassischen Setups die Switches steuert, findet sich in Clouds deshalb auf den einzelnen Rechnern der Installation. Der Grund: Was auf den Rechnern der Cloud läuft, lässt sich auch aus dieser heraus konfigurieren und automatisieren.

Dreh- und Angelpunkt bei SDN sind zwei Komponenten der Cloud: Auf der einen Seite nimmt üblicherweise eine API-Schnittstelle nach Restful-Prinzip die Befehle der Nutzer entgegen, auf der anderen Seite setzen Agents die gewünschte Konfiguration auf den Hosts um.

Unter der Haube kommt fast immer Open V-Switch zum Einsatz, das die virtuellen Switches auf den einzelnen Hosts technisch realisiert. Die Agents der Cloudlösungen hinterlegen also auf den Hosts eine passende Open-V-Switch-Konfiguration und ermöglichen Kunden so den Betrieb virtueller Netze.

Was in der Theorie kompliziert klingt, lässt sich am Beispiel von Open Stack Neutron gut erklären. Neutron ist Open Stacks SDN-Komponente und dafür verantwortlich, dass virtuelle Maschinen ein funktionierendes Netz vorfinden, und zwar sowohl ein virtuelles Kundennetz als auch eine Verbindung zur Außenwelt.

Neutron als Abstraktionsebene

Weil die Open-Stack-Entwickler ihre Nutzer bei der Wahl möglicher SDN-Lösungen nicht einschränken wollen, funktioniert Neutron als Abstraktionsebene mit eigenem Plugin-Mechanismus: Egal ob Open V-Switch [1], Midokuras Midonet [2], Open Contrail [3] von Juniper oder eine andere Lösung – für fast alle SDN-Ansätze am Markt gibt es ein Plugin, das die jeweilige Technik aus Neutron heraus steuerbar macht.

Die Vielfalt hat freilich auch Nachteile: Neutron-Anfänger wissen in vielen Fällen nicht, wo sie anfangen sollen, wenn sie die Lösung verstehen wollen. Scheinbar gibt es hier unendlich viel neu zu lernen. Auch der vorliegende Artikel kann nur ein mögliches Einsatzszenario für Neutron näher beleuchten; technisch realisierbar und sinnvoll wären auch andere. Er orientiert sich am Standard-Setup mit Open V-Switch, weil die grundlegenden SDN-Prinzipien in Open Stack hier am offensichtlichsten sind. Der Vollständigkeit halber sei erwähnt, dass die Open-Stack-Entwickler die Open-V-Switch-Variante für den produktiven Einsatz allerdings nicht bedingungslos empfehlen.

SDN in Open Stack: Das API

Um das Prinzip von Software Defined Networking in Open Stack zu verstehen, sollten die wichtigsten Teile von Open Stack Neutron bekannt sein. Da ist an erster Stelle das API: Der Neutron-Server, so der offizielle Name dieser Komponente, ist ein typisches Open-Stack-API auf Restful-Basis.

Damit ist er automatisch die Anlaufstelle für jede Anfrage, die in einer Open-Stack-Cloud die SDN-Konfiguration betrifft: Will ein Kunde sich per Webinterface oder Neutron-Befehl auf der Kommandozeile ein virtuelles Netz anlegen, landet der Befehl zuallererst beim Neutron-Server. Nova, die Komponente, die in Open Stack für die Verwaltung virtueller Maschinen verantwortlich ist, redet mit Neutron, wenn ein virtueller Port für eine neue VM nötig ist. Auch das Zuweisen einer öffentlichen IP-Adresse zu einer virtuellen Maschine geschieht über Kommunikation mit dem Neutron-Server.

So emsig der Neutron-Server nach außen auch wirkt, so wenig erledigt er effektiv selbst. Seine Spezifikation legt zwar die API-Befehle fest, die Clients an ihn für bestimmte Aufgaben senden müssen. Doch die Umsetzung der jeweiligen Befehle in eine konkrete Konfiguration auf konkreten Servern nimmt der Server nicht selbst vor. Stattdessen besitzt er eine Plugin-Schnittstelle (Abbildungen 1 und 2), über die sich externe Funktionen nachladen lassen.

Abbildung 1: Neutron selbst bietet nur die API-Schnittstelle an und rüstet die eigentliche SDN-Funktionalität über ein Plugin nach (im Bild: Midonet).

Abbildung 2: Das jeweilige SDN-Plugin braucht in der Regel auch eine eigene Konfiguration, um beispielsweise das API der SDN-Lösung zu erreichen.

Neutron selbst hat eine ganze Reihe von Plugins im Schlepptau. Gemeint sind alle Plugins, die Neutron mit der Management-Schnittstelle der SDN-Lösung verbinden, für die das Plugin konzipiert ist. Für das Standard-Szenario gibt es etwa ein Plugin, das Neutron um Open-V-Switch-Funktionen erweitert.

Andere Plugins erlauben Neutron die Kommunikation, zum Beispiel mit dem Midonet-API oder mit Contrail von Juniper. Die aktuelle Plugin-Schnittstelle von Neutron, die den Namen ML2 (für Modular Layer 2) trägt, erlaubt theoretisch sogar den Betrieb mehrerer Neutron-Plugins gleichzeitig. In der Praxis finden sich solche Setups aber nie.

Der um ein SDN-Plugin erweiterte Neutron-Server fungiert in Open Stack auch als zentrale Wissensquelle für alle SDN-bezogenen Informationen. Doch er ist nur die halbe Miete: Auf den Hosts, auf denen letztlich virtuelle Maschinen laufen, gilt es, die in der Neutron-Datenbank abgelegte Konfiguration irgendwie in eine Systemkonfiguration zu überführen. Die Neutron-Entwickler haben deshalb ein Konzept erdacht, bei dem für Neutron-Server auf den Hypervisor-Hosts Agents bereitstehen: Diese erhalten vom Neutron-Server ihre Anweisungen und konfigurieren das Zielsystem dann so, wie der Neutron-Server es vorgibt.

Das Standard-Setup mit Open V-Switch kennt in Neutron eine ganze Menge Agents: Der L2-Agent setzt die Open-V-Switch-Konfiguration auf den Hypervisor-Hosts um und sorgt so dafür, dass VMs in den gleichen Kundennetzen über Knotengrenzen hinweg miteinander kommunizieren. Der DHCP-Agent versorgt virtuelle Maschinen mit lokalen dynamischen IP-Adressen. Der L3-Agent wiederum fungiert auf Gateway-Knoten als Schnittstelle zum Internet.

Den Agents auf die Finger geschaut

Was genau tun die einzelnen Neutron-Agents auf den Hosts? Wie funktioniert ein virtueller Switch konkret? Ein Blick ins Getriebe schafft Klarheit. Clouds unterscheiden zwischen zwei Arten von Datenverkehr. Lokaler Traffic ist Traffic, der zwischen zwei VMs hin und her fließt.

Wie schon erwähnt ist die große Herausforderung dabei, virtuelle Netze auch über die Grenzen von Knoten hinweg miteinander zu realisieren. Wenn etwa mehrere VMs eines Kunden auf den Knoten 1 und 2 laufen, müssen diese ja miteinander sprechen können. Daneben gibt es außerdem noch Internet-Traffic: Dabei geht es sowohl um virtuelle Maschinen, die mit der Außenwelt sprechen möchten, als auch um eingehende Verbindungen für solche virtuellen Maschinen.

Von zentraler Bedeutung sind im SDN-Cloudkontext die beiden Begriffe Overlay und Underlay. Sie bezeichnen zwei unterschiedliche Netzwerk-Ebenen: Underlay meint dabei alle Netzwerk-Komponenten, die für die Kommunikation zwischen den physischen Rechnern notwendig sind. Das Overlay liegt auf dem Underlay; es ist der virtuelle Raum, in dem Kunden ihre virtuellen Netzwerke anlegen. Das Overlay nutzt also die Netzwerk-Hardware des Underlay. Mit anderen Worten verwendet es die gleiche physische Hardware, die auch die Dienste auf den Computing-Knoten für die Kommunikation mit anderen Knoten verwenden.

Damit dabei kein Chaos entsteht, unterstützen alle SDN-Lösungen auf dem Markt mindestens eine Spielart von Verkapselungstechnik: Open V-Switch lässt sich etwa mit VxLAN oder GRE nutzen. VxLAN ist eine Erweiterung von VLANs, die nicht an der Grenze von 4096 Tags scheitert. GRE steht für Generic Routing Encapsulation und bietet ganz ähnliche Funktionen.

Wichtig: Weder die eine noch die andere Lösung kennt irgendeine Verschlüsselung; es handelt sich also nicht um ein Quasi-VPN. Die einzige Daseinsberechtigung für Verkapselung im Underlay einer Cloud liegt darin, den Traffic virtueller Netze vom Traffic der Tools auf dem physischen Host zu trennen.

ID-Zuweisung im Underlay

Damit lokaler Traffic vom Sender zum Empfänger fließen kann, aktivieren die Neutron-Agents auf den Computing-Knoten virtuelle Switches. Sie sind ein Feature, das das Open-V-Switch-Kernelmodul zur Verfügung stellt. Auf der Ebene des Hosts sehen virtuelle Switches aus wie normale Bridge-Interfaces – allerdings haben sie eine praktische Zusatzfunktion: Sie erlauben es, Pakete mit IDs zu versehen. Jedem virtuellen Netz, das in der Cloud existiert, ist eine feste ID zugeordnet. Die virtuellen Netzwerkkarten der VMs sind im laufenden Betrieb mit den virtuellen Switches verbunden, die jedem eingehenden Paket so etwas wie einen Stempel mit der ID des zugehörigen Netzwerks aufdrücken.

Im Grunde funktioniert der Prozess also wie bei getaggten VLANs. Der Switch, der das Tag anwendet, ist im SDN-Cloudkontext aber jene Bridge, mit dem die VM verbunden ist. Und weil die Agents auf allen Hosts innerhalb der Cloud auf die gleiche Konfiguration zugreifen, sind die genutzten IDs für spezifische Netze auf allen Hosts gleich.

Auf der anderen Seite des Bridging-Interface liegt die Verkapselung an, meist also GRE oder VxLAN. Beide Protokolle bauen zwar Tunnel auf, doch die sind stateless: Es entsteht also kein Full-Mesh-Netz aktiver Verbindungen. Über die verkapselte Verbindung wickeln SDN-Lösungen den Traffic mit anderen Hosts ab. Traffic für VMs auf anderen Knoten geht also immer den Weg durch den Tunnel.

Ein konkretes Beispiel trägt zum besseren Verständnis bei: Gegeben sei die virtuelle Maschine »db1« , die zum Netzwerk A des Kunden 1 gehört. Deren NIC ist auf dem Computing-Knoten mit der Open-V-Switch-Bridge verbunden. Der Port der VM an jener Brücke hat die ID 5 gesetzt. Alle Pakete, die über diesen Port beim virtuellen Switch eingehen, werden also automatisch mit dieser ID versehen.

Möchte die VM »db1« nun mit dem Server »web1« sprechen, hängt der weitere Ablauf davon ab, wo die VM »web1« läuft: Läuft sie auf demselben Computing-Knoten, geht das Paket am Port von »db1« am virtuellen Switch rein und am Port der VM »web1« – der mit der gleichen ID versehen ist – wieder raus. Läuft »web1« auf einem anderen System, geht das Paket in den GRE- oder VxLAN-Tunnel und trifft dort beim virtuellen Switch ein. Dieser überprüft die gesetzte ID und leitet das Paket schließlich an den Zielport weiter.

Virtuelle Switches im Sinne von Open V-Switch erledigen also zwei Dinge: Sie sorgen für eine strikte Trennung zwischen Underlay und Overlay per Verkapselung sowie durch das dynamische Konfigurieren virtueller Switches dafür, dass ein Paket aus einem virtuellen Netz nur bei VMs landet, die mit demselben Netz verbunden sind. Die Aufgabe der SDN-spezifischen Agents von Neutron (L2-Agent) besteht darin, die virtuellen Switches auf den Hosts mit den passenden IDs zu versorgen. Ohne diese Agents gäbe es zwar virtuelle Switches, doch wären diese auf allen Hosts noch unkonfiguriert und mithin unbrauchbar.

Das beschriebene System reicht aus, um lokale virtuelle Netze zu administrieren und zu nutzen. Unbeachtet ist bisher Internet-Traffic – und der ist genauso wichtig wie lokaler Traffic.

Mit Internet-Traffic funktioniert es ähnlich

Die schönste VM ist in der Regel nichts wert, wenn sie nicht auf das Internet zugreifen kann oder von außen nicht erreichbar ist. Praktisch alle SDN-Ansätze sehen vor, dass der Traffic aus dem Internet oder dorthin durch ein separates Gateway fließt, das ebenfalls direkt aus der Cloud heraus konfiguriert wird. Das Gateway muss gar kein eigener Host sein; die notwendige Software kann grundsätzlich auch auf jedem Computing-Knoten laufen, wenn dieser genug Kraft unter der Haube hat.

“Notwendige Software” meint in diesem Falle mindestens Network Namespaces und in den meisten Fällen auch einen eigenen BGP-Daemon. Grundsätzlich ist ein typisches Open-Stack-Gateway ganz normal mit dem Underlay verbunden; für jene Netzwerke, für die auf der Open-Stack-Ebene virtuelle Gateways durch den Admin konfiguriert sind, existiert auf dem Gateway obendrein auch ein virtuelles Netzwerkinterface, das an einem virtuellen Switch des Overlay hängt. Klar: Wenn Pakete ins Internet sollen, muss auch dieser Traffic im Overlay von dem Traffic anderer virtueller Netze getrennt sein.

Network Namespaces helfen im letzten Schritt dabei, die Traffic-Trennung zwischen virtuellen Netzen auch auf dem Weg ins Internet durchzusetzen. Network Namespaces sind ein Feature des Linux-Kernels; es handelt sich um virtuelle Netzwerkstacks auf dem Host, die voneinander und vom Haupt-Netzwerkstack des Systems getrennt sind. Der eingehende Traffic virtueller Kundennetze landet auf dem Gateway also auch in unterschiedlichen Network Namespaces.

Der Umgang mit öffentlichen IP-Adressen

Öffentliche IPv4-Adressen kommen in Open-Stack-Clouds meist an zwei Stellen zum Einsatz: Einerseits sind sie im Gateway-Kontext nötig, weil nur mit einer öffentlichen IP-Adresse ein Network Namespace als Brücke zwischen einem virtuellen Kundennetz und dem echten Internet dienen kann. Andererseits wollen viele Kunden ihre virtuellen Maschinen per öffentlicher IP aus dem Internet erreichbar machen.

Wie IPv4-Verwaltung funktioniert, ist von der jeweiligen SDN-Lösung abhängig: Im Standard-Setup von Open V-Switch wird auf den Gateway-Knoten der L3-Agent von Neutron gesteuert. Der legt lediglich virtuelle Tap-Interfaces in den Namespaces an und weist im Anschluss eine öffentliche IP zu.

Fortgeschrittene Lösungen wie Midonet oder Open Contrail von Juniper sprechen selbst BGP: Admins verbinden sie dann mit dem eigenen Border-Gateway zum Internet. Das Software-Gateway leitet danach nur Announcements für jene IPv4-Adressen an das Border-Gateway weiter, die in der Cloud auch tatsächlich in Verwendung sind. Eine BGP-basierte Lösung bietet einerseits natürlich mehr Möglichkeiten, sie ist aber auch deutlich komplexer und erfordert mehr Vorwissen beim Admin. Midonet immerhin geht das Thema sehr geschickt an: Der BGP-Daemon Quagga ist mit Midonet fest verwoben; er wird auch direkt aus Midonet heraus konfiguriert. Der Admin muss sich um ihn also keine separaten Gedanken machen.

Floating-IPs

Im Cloudkontext firmieren IPv4-Adressen, die Kunden dynamisch reservieren und zurückgeben können, unter dem Namen Floating-IP. Das Konzept stößt bei gestandenen Sysadmins regelmäßig auf Unverständnis: Wer es gewohnt ist, einer Maschine eine öffentliche IP per Systemkonfiguration zu verpassen, fühlt sich beim Klicken im Open-Stack-Webinterface bisweilen verschaukelt.

Allerdings gibt es gute Gründe für das Konzept der Floating-IPs: Einerseits lässt sich so echtes On-Demand-Payment realisieren; Kunden zahlen also wirklich nur die IP-Adressen, die sie benötigen (Abbildung 3). Zweitens halten Floating-IPs den durch Netzwerksegmentierung entstehenden Overhead klein: In Open Stack lässt sich ein Netzwerk mit »/24« -Präfix als gesamter Block konfigurieren. Netzwerkadresse, Gateway und Broadcast sind nur einmal anzugeben. Die restlichen IP-Adressen lassen sich einzeln nutzen. Typische Segmentierung würde diverse Adressen allein für Broadcast-, Netzwerk- und Gateway-Adressen verschwenden.

Abbildung 3: Floating-IP-Adressen werden dynamisch an VMs angehängt. Das ist für eine Abrechnung nach Ressourcenverbrauch nützlich.

Ein dritter Grund spricht für die Idee: Dynamische IP-Adressen ermöglichen Prozesse wie Updates innerhalb einer Cloud. Eine Datenbank lässt sich etwa fertig vorbereiten und vorkonfigurieren. Die Inbetriebnahme besteht dann lediglich aus der Übernahme einer IP-Adresse von der alten VM auf die neue.

Auf der technischen Seite lässt sich die Umsetzung der Floating-IPs aus den vorangegangenen Erklärungen herleiten: Bei purem Open V-Switch konfiguriert der L3-Agent von Neutron die Floating-IP einfach auf einem Interface innerhalb des Network Namespace, der dem virtuellen Kundennetz mit der Ziel-VM zugeordnet ist. BGP-basierte Lösungen verfahren ähnlich und sorgen letztlich auch dafür, dass die Pakete beim richtigen Host ankommen.

DHCP

Ganz ähnlich ist es mit den DHCP-Agents bestellt: Ein DHCP-Agent kann in einem virtuellen Kundennetz nur effektiv sein, wenn er mit einem Bein darin steht. Die Hosts, auf denen der Neutron-DHCP-Agent läuft, sind deshalb auch Teil des Overlay. Wieder kommen Network Namespaces zum Einsatz – für jedes virtuelle Netz entsteht ein Network Namespace mit virtuellem Tap-Interface und entsprechender Open-V-Switch-Konfiguration. Für jeden dieser Namespaces läuft eine eigene Instanz des Neutron-DHCP-Agent. Startende VMs setzen wie üblich einen DHCP-Request ab, der durch das Overlay beim Host mit DHCP landet und entsprechend beantwortet wird.

Metadaten-Zugriff

Dass SDN in Clouds bisweilen eigenartige Blüten treibt, lässt sich bestens anhand des Metadaten-Zugriffs in Open Stack beschreiben. Auf Amazons Mist ist die Idee gewachsen, ein Werkzeug namens »cloud-init« zu schreiben. Das läuft beim Start einer VM in der Cloud los und führt einen HTTP-Request hin zu der Adresse »168.254.169.254« aus, um Informationen zu seinem Hostnamen oder zu SSH-Keys zu erhalten, denen es den Zugriff erlauben soll. Die genannte IP gehört freilich nicht zum IP-Raum des vom Kunden angelegten virtuellen Netzwerks – und landet folglich erst mal auf dem Gateway-Knoten.

Das Problem: Die Metadaten liefert der Dienst Nova-API, der meist auf separaten Cloudcontrollern läuft. Und die haben keine Anbindung an das Cloud-Overlay, wenn nicht der DHCP- oder L3-Agent zufällig auch auf ihnen läuft. Beholfen haben sich die Entwickler von Neutron letztlich mich einem kruden Hack: Auf den Gateway-Knoten läuft ein Metadaten-Agent, der aus zwei Teilen besteht. Der Agent selbst fängt erst die Pakete des HTTP-Request ab und sendet sie per Unix-Socket an den Metadaten-Proxy, der – direkt im Cloud-Underlay – schließlich zum Nova-API weiterleitet. Den Weg zurück nehmen die Pakete in umgekehrter Reihenfolge.

Aus Nutzersicht

Open Stack kombiniert im Hintergrund viele Techniken miteinander – das gelingt offenbar. Anwender klicken sich per Webinterface ihre virtuellen Netze zusammen (Abbildungen 4 und 5) und müssen sich keine Sorgen machen, dass unbefugte Dritte den Traffic ihrer Systeme sehen. Durch virtuelle Router (Abbildung 6) und Floating-IP-Adressen sind die wichtigsten Aspekte in Sachen Internet ebenfalls abgedeckt.

Abbildung 4: Die Topologie seiner Netzwerke samt den Routern sieht der Nutzer im Webinterface.

Abbildung 5: Der Fantasie des Nutzers sind beim Anlegen von SDN-Netzen kaum Grenzen gesetzt: Weil die Netze voneinander getrennt sind, sind sogar mehrere Netze mit gleichem Adressraum möglich.

Abbildung 6: Virtuelle Router verbinden ein virtuelles Netz in Open Stack direkt mit dem nach außen zeigenden Gateway der SDN-Lösung.

Auch aus Anbietersicht macht die Lösung Spaß: Zwar ist die Lernkurve steil und es dauert in der Regel einige Zeit, bis das SDN funktioniert. Doch dann verursacht das Thema Netz dem Admin praktisch keinen Aufwand mehr. Weil die ganze physische Infrastruktur auf Switch-Ebene eine flache Hierarchie bildet und die gesamte Netzwerk-Konfiguration direkt aus der Cloud heraus möglich ist, gehört das Umkonfigurieren von Switches der Vergangenheit an.

Die modulare Architektur von Neutron erlaubt es außerdem, neue Funktionen mit wenig Aufwand anzubieten. Die verschiedenen “XaaS”-Dienste in Neutron legen davon Zeugnis ab: Load Balancer as a Service etwa realisieren die Entwickler ebenfalls per Agent, der auf einem zuvor definierten Host eine HA-Proxy-Instanz installiert. Die Load-Balancer-Konfiguration erfolgt zentral per Neutron-CLI oder über das Open-Stack-Dashboard.

Ähnlich verhält es sich mit Firewall as a Service (FWaaS) und VPN as a Service (VPNaaS): Hier ist es für die Entwickler kein Problem, auf die vorhandene Neutron-Infrastruktur zurückzugreifen und die gewünschten Dienste ebenfalls per Agent anzubieten. Im Beispiel von VPNaaS bedeutet das etwa, dass der Kunde sich per VPN direkt mit seinem virtuellen Cloudnetz verbinden kann.

Welche SDN-Lösung?

Eine Entscheidung nimmt Neutron dem Admin allerdings nicht ab: die Frage nach der passenden SDN-Technologie. Wie erwähnt betrachten die Neutron-Entwickler das Thema Open V-Switch als ungeeignet für eine Vielzahl von Szenarien; besonders große Umgebungen mit Hunderten Computing-Knoten sorgen beispielsweise beim klassischen Open V-Switch für so viel Overhead, dass im schlimmsten Fall das physische Netz allein dadurch saturiert ist.

Wer Open Stack also in großem Maßstab ausrollen will, landet früher oder später bei Lösungen wie Midonet, Plumgrid oder Open Contrail. Eine generelle Empfehlung für oder wider eine der Lösungen ist unmöglich, jede hat ihre Stärken und Schwächen. Im Zweifel hilft also nur eine ausgiebige Evaluation. Dafür sollte der Admin genügend Zeit einplanen.