Open Source im professionellen Einsatz
Linux-Magazin 08/2016
© Baloncici, 123RF

© Baloncici, 123RF

Software Defined Networking in Open Stack

Zwischenschicht

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.

572

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.

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 6 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

Ähnliche Artikel

  • Red Hat Open Stack Plattform 6 verfügbar

    Red Hat aktualisiert sein Infrastructure-as-a-Service-Portfolio mit der neuen Version 6 von Red Hat Enterprise Linux Open Stack Platform, die auf Basis von Red Hat Enterprise Linux 7 entstand.

  • Open Stack Newton

    Ihrem eigenen Release-Gesetz folgend verabreichten die Open-Stack-Entwickler im Oktober der Cloudwelt mit ihrer neuen Version auch neue Impulse. Neben diversen Fehlerkorrekturen implementierten sie in den Kernkomponenten auch Neuerungen, die zu bewerten sich dieser Artikel zur Aufgabe macht.

  • Open-Stack-Summit: Zehn Systeme, 168 000 Instanzen

    Am Rande des Open-Stack-Summits in Atlanta hat Ubuntus Server-Team mit Open Stack 168 000 Cloud-OS-Instanzen auf AMD-Hardware laufen lassen. Dafür mussten die Admins einige Bugs umschiffen.

  • Open Stack Juno

    Open Stack will im ganz großen Geschäft mitspielen und muss deshalb liefern. Die neue Version 2014.2 alias Juno räumt auf und leistet Modellpflege – von einer großen Neuerung abgesehen: Ironic, das Baremetal-Deployment-Tool, das wohl auf dem Sprung zur offiziellen Komponente ist.

  • Open Stack Liberty

    Pünktlich stellte das Open-Stack-Projekt im Oktober die neue Version seiner Cloudverwaltung Open Stack vor, Codename Liberty. Die bringt nicht den ganz großen Wurf, aber zahlreiche kleinere Verbesserungen, angefangen beim Support für QoS bis zu einem radikalen Umbau beim Orchestrierungsdienst Heat.

comments powered by Disqus

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.