© Irina Schmidt, 123RF

Dass Open Stack in aller Munde ist, bedeutet nicht, dass es überall installiert ist. Die für eigene Anwendungsfälle richtigen Komponenten auszuwählen und das Setup des Stapels erweisen sich als hochkomplex. Mit diesem Artikel startet ein dreiteiliger Workshop, der Admins fit für die Open-Stack-Praxis macht.

Mit beeindruckender Konsequenz hat Open Stack Konkurrenten marginalisiert – es sei etwa an Eucalyptus oder Cloud Stack erinnert. Die waren technisch zwar oft auf Augenhöhe mit Open Stack, spielen aber heute nur eine untergeordnete Rolle. Während gerade in der Anfangszeit die technische Substanz bei Open Stack die große Aufmerksamkeit kaum rechtfertigte, ist die Lösung besonders in den letzten zwei Jahren allerdings auch technisch merklich gereift: Viele Probleme, die Admins zuvor das Leben schwer machten, sind mittlerweile beseitigt. Bei den halbjährlichen Open-Stack-Konferenzen zeigt sich außerdem, dass eine ganze Reihe großer Unternehmen mittlerweile auf Open Stack setzt und durchaus stolz auf das Erreichte ist.

Die vielleicht größte praktische Herausforderung bei Open Stack bildet dessen Komplexität. Sie ist inhärent: Wenn der Bau einer Cloudumgebung mit etlichen Hunderten oder gar Tausenden Knoten ansteht, greifen die meisten Konzepte nicht mehr, die für konventionelle Rechenzentren existieren. Das betrifft sowohl die Planung der physischen Umgebung – bauliche Gegebenheiten, Racks, Server, Hardware, Netzwerk und Strom – wie auch die Software, die die Kernfunktionalität liefert.

Aus der Komplexität des Konstrukts ergibt sich, dass selbst eingefleischten Admins der Einstieg in Open Stack nicht einfach so gelingt. Bevor es mit Open Stack ernsthaft losgehen kann, steht viel Lernen und Üben auf dem Lehrplan – bis zum ersten Open Stack, das ohnehin nur in virtuellen Maschinen als Testsetup läuft, ist es ein langer Weg.

Das Linux-Magazin greift Admins mit einem dreiteiligen Workshop beim Einstieg unter die Arme. In diesem ersten Teil geht es zunächst um die Vorstellung der wichtigsten Open-Stack-Komponenten und der Methoden, die für das Deployment von Open Stack aktueller Standard sind. Teil zwei geht das Thema ganz praktisch an und beschreibt die Open-Stack-Installation auf Basis von MaaS und Juju in virtuellen Maschinen.

Der dritte Teil schließlich beschäftigt sich mit der Übertragung des Gelernten auf die Praxis: Was ist bei großen Open-Stack-Installationen in Sachen Rechenzentrum zu beachten? Wie lässt sich Hochverfügbarkeit erreichen und welche Optionen stehen für SDN und SDS bereit?

Ein ganzer Kosmos von Komponenten

Wenn von Open Stack die Rede ist, verbinden viele damit intuitiv nur ein großes Stück Software. Tatsächlich ist Open Stack eher eine Sammlung von vielen Programmen (Abbildung 1), die sich im Hintergrund Kommunikationswege teilen und eine große Gemeinsamkeit haben: Der gesamte Open-Stack-Quelltext ist in Python verfasst.

Abbildung 1: Zwar besteht Open Stack aus deutlich mehr Diensten als den hier gezeigten – doch für eine Basis-Cloud reichen sechs Komponenten bereits völlig aus.

Was genau zu Open Stack gehört, lässt sich mittlerweile nicht mehr ganz deutlich bestimmen: In der Anfangszeit des Projekts war der Begriff als Marke nämlich für jene Dienste reserviert, die sich offiziell Core Services nennen durften. Zum Core Service wurde eine einzelne Komponente, nachdem sie eine Weile im Incubator-Status verbracht, eine große Community hinter sich geschart und das Technical Committee von Open-Stack die Aufnahme in die Core Services offiziell beschlossen hatte.

Die Big-Tent-Initiative hat dem ein Ende gesetzt: Seither muss eine Komponente sich nur noch zur Einhaltung einiger grundlegender Regeln verpflichten, um offiziell als Open-Stack-Komponente zu gelten. Die ursprüngliche Idee hinter Big Tent war es, die Innovationskraft innerhalb des Projekts zu steigern – das Ziel haben die Entwickler erreicht, denn mittlerweile gibt es mehr als 30 Komponenten. Befürchtungen, durch das große Zelt sei die Marke Open Stack in Gefahr, weil unreife Dienste sie beschädigen könnten, haben sich zumindest bisher nicht bewahrheitet.

Freilich gibt es noch immer die Unterscheidung zwischen einer Sammlung von Kerndiensten und schmückendem Beiwerk. Um mit einer Open-Stack-Cloud sinnvoll Dienstleistungen zu erbringen, sind sechs Komponenten zwingend nötig: Keystone, Glance, Nova, Neutron, Cinder und Horizon. Die sechs Bezeichnungen sind übrigens die Codenamen, jeder Open-Stack-Dienst hat aber auch einen offiziellen Namen.

Doch die werden kaum genutzt, auch wenn sie es eher erlauben würden, die Funktion eines Dienstes zu erahnen: Glance etwa ist offiziell der Image Service. Übrigens: Auch die einzelnen Open-Stack-Komponenten sind in der Regel keine einzelnen Programme, sondern teilen sich wiederum in mehrere Dienste auf. Glance beispielsweise besteht aus einem API- und einem Registry-Dienst.

Unterstützende Dienste

Bevor es um die Open-Stack-Komponenten selbst geht, sei zunächst auf zwei Dienste hingewiesen, die sich in praktisch jeder produktiven Open-Stack-Cloud finden: Rabbit MQ und MySQL. MySQL nutzen die Open-Stack-Komponenten samt und sonders, um ihre eigenen Metadaten persistent zu speichern. Metadaten meint im Open-Stack-Kontext die Laufzeitdaten, die durch Benutzerinteraktion oder durch das Eingreifen des Admins entstehen, zum Beispiel die angelegten Nutzer oder auch die laufenden virtuellen Maschinen.

Mit Rabbit MQ ist es etwas komplizierter. Warum braucht eine Cloudsoftware einen RPC-Dienst im Hintergrund? Laut Aussage der Open-Stack-Entwickler geht es darum, dass die einzelnen Teile der Dienste über Knotengrenzen hinweg miteinander kommunizieren müssen. Ein gutes Beispiel ist Open Stack Nova, der Virtualisierungsdienst: Ein Befehl für das Anlegen einer neuen VM geht bei dessen API-Komponente ein und führt dazu, dass auf irgendeinem beteiligten Hypervisor-Knoten eine neue VM aus dem Boden gestampft wird. Die Kommunikation zwischen den einzelnen Diensten von Nova geschieht dabei über das von Rabbit MQ angebotene Advanced Message Queuing Protocol (AMQP).

Sowohl Rabbit MQ als auch MySQL sind nicht alternativlos. Weil der Zugriff auf RPC über eine eigene Python-Bibliothek erfolgt, die alle Dienste in Open Stack nutzen und die auch Qpid beherrscht, ließe sich Rabbit MQ ohne Probleme durch Qpid ersetzen. Ähnliches gilt für MySQL, das PostgreSQL ohne Schwierigkeiten weichen könnte. In der Praxis dominieren MySQL und Rabbit MQ jedoch mit weitem Abstand.

Keystone: Der Türsteher

Damit kann das Schaulaufen der Open-Stack-Dienste losgehen. Den Anfang macht naturgemäß Keystone: Der Dienst ist bei Open Stack für alles zuständig, was mit der Authentifizierung und Autorisierung von Benutzern zu tun hat. Keystone ist zwar deutlich später zu Open Stack gestoßen als Nova oder Glance, trotzdem ist der Dienst für Open Stack unerlässlich. Keystone ist übrigens tatsächlich nur eine einzelne Applikation: Der Dienst ist als Restful-API konzipiert, das sich über HTTP-Befehle ansprechen lässt. Ein solches Restful-API findet sich jedoch bei allen Open-Stack-Diensten. Denn APIs sind der Standardweg in Open Stack, um generell Anfragen von Nutzern oder anderen Komponenten zu beantworten.

Keystones Hauptaufgabe besteht darin, die so genannten Tokens für Clients auszustellen: Ein Token ist ein temporär gültiger String, mit dem sich ein Nutzer bei anderen Diensten ausweisen kann. Erfragt der Nutzer von Keystone ein Token mit gültiger Kombination aus Benutzernamen und Passwort, so kann er das Token anschließend in den HTTP-Requests anderer Dienste gleich als Header einbetten. Und Keystone kann noch mehr: Im Hintergrund lässt der Dienst sich etwa an LDAP anbinden. Obendrein dient der Service auch den Open-Stack-Komponenten selbst zur Authentifizierung: Will ein Dienst einen Request an einen anderen Dienst schicken, so benötigt er dazu wie jeder andere Client ein gültiges Token (Abbildung 2).

Abbildung 2: Keystone regelt in Open Stack die Authentifizierung und auch die Autorisierung mittels Tokens.

Intern ist Keystone auf Basis von Benutzern, Klienten und Rollen organisiert. Die Nutzer gehören zu einem bestimmten Klienten und haben innerhalb dieses Klienten eine bestimmte Rolle. Die Rollen wiederum, deren Berechtigungen jedoch auf Ebene jedes einzelnen Dienstes festgelegt sind, bestimmt der Admin nach eigenem Gutdünken.

Ganz unscheinbar: Glance

Der Imagedienst Glance übernimmt in Open Stack eine sehr wichtige Aufgabe, kommt allerdings ganz unscheinbar daher. Weil es Nutzern in Clouds kaum zuzumuten ist, für jede neue VM ein eigenes Betriebssystem von Grund auf neu zu installieren, stellt Glance fertige, vorkonfigurierte Festplatten-Abbilder bereit. Diese laden Nutzer sich für neue VMs einfach auf ihre virtuelle Platte herunter und haben so innerhalb von wenigen Sekunden ein fertig installiertes und lauffähiges System. Per Cloud-Init-Dienst lassen sich verschiedene Konfigurationsparameter nach Belieben in die VM übertragen.

Glance setzt sich aus den bereits erwähnten Komponenten API und Registry zusammen. Der Dienst beherrscht mehrere Formate für die virtuellen Festplatten und lässt sich zudem direkt an verschiedene Storage-Systeme wie etwa Ceph oder Gluster FS anschließen, mit deren Hilfe er dann seine Images ablegt.

Obendrein ist Glance auch nahtlos mit der Komponente Nova verbunden. Wenn ein Nutzer eine neue VM konfiguriert und startet, wählt er also lediglich noch das passende Betriebssystem aus einer entsprechenden Liste aus – Nova und Glance machen die Details der Inbetriebnahme anschließend im Hintergrund untereinander aus.

Nova: Das Urgestein

Open Stack Nova ist der älteste Open-Stack-Dienst, gewissermaßen die Ursuppe, aus der Open Stack in seiner heutigen Form entstanden ist. Anfangs war Open Stack nämlich ein Joint Venture zwischen dem amerikanischen Hostingdienst Rackspace und der US-Weltraumbehörde NASA. Letztere hat das Engagement für die Cloudumgebung zwar mittlerweile komplett eingestellt, zeichnet aber für die ersten Versionen von Nova noch verantwortlich.

Vereinfacht gesagt kümmert sich Nova in Open Stack um alles, was mit der Verwaltung von virtuellen Maschinen zu tun hat. Dazu gehört das Anlegen neuer VMs, das Löschen alter VMs sowie das Starten und das Stoppen derselben – alles jeweils auf Zuruf durch einen Nutzer oder Admin. Nova besteht aus einer Vielzahl von Diensten, wobei das API, der Scheduler und die Compute-Komponente die wichtigsten Dienste sind.

Das API nimmt dabei alle Befehle von den Nutzern und Komponenten an und verarbeitet sie. Schreibt ein eingegangener Befehl das Anlegen einer neuen VM vor, schickt das API den Befehl zunächst an den Scheduler. Dieser hat einen Überblick über die verfügbaren Compute-Knoten und die dort noch verfügbaren Ressourcen und wählt schließlich einen passenden Host. Dort läuft anschließend die Compute-Komponente von Nova los und startet lokal die neue VM.

Lobend ist dabei hervorzuheben, dass die Open-Stack-Entwickler bei der Compute-Komponente das Rad nicht neu erfunden haben, sondern auf bestehende Technik setzen. Kommt etwa KVM als Hypervisor zum Einsatz, verwaltet Nova Compute die VMs per Libvirt. Nova unterstützt jedoch nicht nur KVM: Auch Xen und diverse Containertechniken gehören genauso zum Lieferumfang wie eher kommerzielle Ansätze, etwa VMware ESX oder Hyper-V für Windows.

Bestens verbunden mit Neutron

Virtuelle Maschinen brauchen in den meisten Fällen Zugang zu einem Netzwerk. Anders als bei konventionellen Virtualisierungsumgebungen genügt es in Clouds aber nicht, einfach ein am Host anliegendes Netz per Bridge durchzuschleifen. Denn in Clouds und gerade in großen Public Clouds ist eine grundlegende Annahme, dass VMs mehrerer Kunden unbehelligt voneinander auf ein und demselben Host laufen können – alles andere skaliert nicht.

Deshalb ist Software Defined Networking (SDN), in Clouds Pflicht. Diverse Implementierungen von SDN sind am Markt präsent: Open Vswitch sowie etliche darauf basierende Lösungen kommerzieller Art (Midonet von Midokura, Plumgrud) und Alternativen wie etwa Open Contrail von Juniper.

Open Stack Neutron (Abbildung 3) schlägt die Brücke zwischen Open Stack und den verschiedenen SDN-Ansätzen. Im Grunde ist Neutron nicht viel mehr als ein API, das über eine Plugin-Schnittstelle verfügt. Über diese lässt sich dann ein Plugin für eine spezifische SDN-Spielart nachladen. Neutron selbst hat obendrein ein paar SDN-Implementierungen selbst im Gepäck, zum Beispiel Open Vswitch. Auf den Hosts des Setups laufen dann diverse, zu Neutron gehörende Zusatzdienste, auch als Agents bezeichnet, die dort die passende SDN-Konfiguration hinterlegen.

Abbildung 3: Neutron kümmert sich in Open Stack um das SDN und ermöglicht im Hintergrund die Anbindung an verschiedene SDN-Lösungen.

Neutron gilt als einer der Open-Stack-Dienste mit der höchsten Komplexität. Gerade am Anfang sind die Querverstrebungen zwischen den Agents und Diensten nur schwer zu durchdringen. Dennoch ist Neutron für komplexe Setups heute unverzichtbar und praktisch alternativlos: Die alte Komponente, die sich um SDN kümmerte und als Nova Network Teil von Nova war, wird seit einiger Zeit nicht mehr entwickelt und soll bald aus Nova verschwinden.

Platz da! Open Stack Cinder

Wie SDN ist auch der Software Defined Storage in Clouds ein sehr wichtiges Thema. Die Art des genutzten Storage spielt dabei gar nicht eine besonders große Rolle: Ob die Daten letztlich auf einem Ceph-Cluster landen oder auf einem per Fibre Channel oder NFS angebundenen SAN ist eigentlich irrelevant. Wichtig ist hingegen, dass die im Cluster laufenden VMs den vorhandenen Speicher nutzen können.

Im Beispiel von KVM bedeutet das etwa, dass auf Zuruf des Nutzers ein Storage-Segment entsprechend provisioniert und danach der VM per Hotplug-Funktionalität von KVM untergeschoben bekommt. Genau hier beginnt die Zuständigkeit von Open Stack Cinder: Der Dienst verwaltet vorhandenen Speicher und richtet ihn so her, dass Nova ihn an laufende VMs anschließen kann.

Cinder besteht ebenfalls aus mehreren Diensten: einem API, einem Scheduler und einer Storage-Komponente. Letztere verwaltet den Speicher im Hintergrund, wobei der Scheduler entscheidet, von welchem Backend-Speicher aus eine Nutzeranfrage erfüllt wird. Über Treiber lassen sich mannigfaltige Storages anbinden: Von dem schon erwähnten Ceph über andere SDS-Lösungen wie Gluster FS bis hin zu beinahe sämtlichen SAN-Systemen von Netapp, Dell/EMC oder HP reicht die Palette der unterstützten Lösungen.

Horizon fürs Auge

Bei der letzten Komponente der Liste ist bereits strittig, ob sie für eine Open-Stack-Installation eigentlich nötig ist. Denn weil jeder Open-Stack-Dienst ein eigenes API mitbringt und für jedes API auch ein eigener Client auf der Kommandozeile existiert, lässt sich Open Stack komplett per CLI nutzen. Die Sache hat aber einen Haken: Gerade unerfahrene Nutzer sind mit dem CLI schnell überfordert. Ein Cloudanbieter kann jedoch nicht davon ausgehen, dass nur Kommandozeilenritter seinen Dienst nutzen.

Die Lösung ist ein GUI im Stile eines Self-Servicing-Portals, über das Anwender bei Bedarf VMs, Netze und Speicher selbst zusammenklicken können. Genau diese Option bietet Horizon, das offiziell Open Stack Dashboard heißt. Horizon basiert auf Django, ist also Web-optimiertes Python und gehört zu jenen Open-Stack-Komponenten, die von Anfang an dazugehörten.

Der Funktionsumfang von Horizon ist durchaus beachtlich: Je nach den vergebenen Rechten lassen sich Nutzerzugänge administrieren, VMs, Speichergeräte und virtuelle Netze verwalten und Zusatzfunktionen nutzen.

Für Anbieter besonders spannend ist das eingebaute Theme-Interface: Durch ein entsprechendes Theme lässt sich die äußere Erscheinung von Horizon etwa an die Corporate Identity einer Firma so anpassen, dass die Lösung wie aus einem Guss wirkt. Alle Hersteller fertiger Plattformen auf Open-Stack-Basis – Suse, Canonical und Red Hat – machen das vor, sodass dort das Dashboard jeweils in Grün (Abbildung 4), grellem Orange oder Rot erstrahlt.

Abbildung 4: Weil sich das Dashboard mit Themes verändern lässt, erstrahlt hier die Suse-Version von Horizon im typischen SLES-Stil.

Und sonst so?

Die vorgestellten Open-Stack-Komponenten bilden zusammen die Basis. In der Praxis wird man in einer Open-Stack-Cloud aber eine Reihe weitere Dienste nutzen wollen. Erwähnt seien beispielhaft Heat, das Orchestrierung bietet, oder Ceilometer, das Billing-Daten liefert und sich an bestehende Billing-Systeme anbinden lässt. Auch andere Dienste wie Trove für Database as a Service (DBaaS), Magnum für Container as a Service oder Designate für DNS as a Service (DNSaaS) ziehen regelmäßig das Interesse der Admins auf sich.

Wer mit Open Stack gerade erst anfängt, sollte sich jedoch auf das absolut Notwendigste beschränken, auch weil sich bei einem funktionierenden Design der Plattform solche Dienste später ohne große Schwierigkeiten nachrüsten lassen.

Gretchenfrage: Das Deployment

Open-Stack-Einsteiger sehen sich mit einer Vielzahl an Informationen über die einzelnen Komponenten konfrontiert und stehen oft wie der sprichwörtliche Ochse vor dem neuen Tor. Die dominierende Frage ist dabei immer dieselbe: Wie lässt sich ein Monster wie Open Stack sinnvoll ausrollen und betreiben? Schnell wird klar, dass die händische Konfiguration und das manuelle Installieren der für Open Stack benötigten Pakete auf den einzelnen Hosts keine Option ist. Denn große Open-Stack-Clouds umfassen locker Hunderte Knoten, sodass sich Basteln von selbst verbietet.

Das wissen freilich auch die großen Hersteller und warten mit diversen Lösungen auf, die Admins das Leben leichter machen sollen. Besonders Suse, Red Hat und Canonical tun sich mit Tools zur automatischen Open-Stack-Installation hervor.

Suse: Früh dabei

Als eines der ersten Unternehmen sprang Suse auf den Open-Stack-Zug auf und ist seit Jahren mit seinem Produkt Suse Cloud aktiv, wenig überraschend basiert sie auf dem Suse Linux Enterprise Server (SLES). Bei der Cloud liefert Suse nicht nur Pakete von allen relevanten Open-Stack-Diensten für SLES, sondern auch eine Deployment-Lösung auf Basis von Crowbar. Das wiederum setzt auf die Automatisierungslösung Chef und bietet Bare-Metal-Deployment,

Dabei werden neue Hosts im Setup per PXE in ein Basis-System gebootet und inventarisiert. Per GUI weist der Admin anschließend Rollen, mit denen bestimmte Dienste aus der Open-Stack-Sammlung verbunden sind, einer Anzahl Hosts zu. Schließlich legt der Admin noch die Details des Setups fest und stößt das Ausrollen von Open Stack an. Suse Cloud bietet einen komfortablen Einstieg, wenn man ohnehin Suse gewohnt ist.

Red Hat mit Entwicklungsverzögerung

Anders als bei Suse dauerte es bei den roten Hüten sehr lange, bis man sich für ein umfassendes Open-Stack-Engagement entschieden hatte. Danach drehte die Firma aus Raleigh aber auf, stellte massenhaft Open-Stack-Entwickler ein und ist heute eine Triebfeder der Open-Stack-Entwicklung insgesamt.

Das auf den etwas sperrigen Namen RHOSP (Red Hat Open Stack Platform) getaufte Produkt basiert auf Red Hat Enterprise Linux (RHEL) und kreiert um Open Stack herum eine Vielzahl von Tools und Werkzeugen, die die Installation und die Administration der Cloudlösung für den Anwender erleichtern. Dazu gehört ein eigenes GUI zusammen mit Pack Stack, einer Komponente, die Open Stack auf Basis der Automatisierungslösung Puppet ausrollt.

Große Unterschiede zwischen der Suse Cloud und Red Hat Open Stack Platform gibt es bei der Kernfunktionalität zwar nicht, manche Details unterscheiden sich aber. Die dominierende Frage bleibt, ob bereits Erfahrung im Umgang mit Suse oder Red Hat vorhanden ist. Darauf sollte die Entscheidung für eine der beiden Lösungen letztlich beruhen.

Canonical und Open Stack sind eng verzahnt

Der dritte im Bunde, Canonical, pflegt seit dem Beginn der Arbeit an Open Stack ein ausgesprochen enges Verhältnis zu dessen Entwicklern. Es war Cannonicals Chef Mark Shuttleworth höchstpersönlich, der bereits vor einigen Jahren Eucalyptus in Ubuntu durch Open Stack ersetze und den Open-Stack-Hype so zum Teil mit auslöste. Dass die Open-Stack-Releases meist nur wenige Tage vor den Ubuntu-Releases im April und im Oktober herauskommen, ist ebenso wenig ein Zufall.

Technisch gestaltet sich die Ubuntu-Cloud solide: Auf Basis von MaaS (Metal as a Service) sowie der Canonical-eigenen Automatisierungslösung Juju bietet Ubuntu Cloud dieselbe Funktionalität, die auch Suse und Red Hat im Programm haben. Hinzu kommt, dass der Admin bei Ubuntu-Systemen auch die Möglichkeit hat, ein normales Ubuntu zu installieren und sich mit den offiziellen Ubuntu-Open-Stack-Paketen selbst ein Deployment zu basteln, ohne dafür irgendwelche Lizenzgebühren zu zahlen. Auf Support muss der Anwender dann freilich verzichten, dennoch ist diese Kombination sehr beliebt: Viele Open-Stack-Setups setzen wegen eben dieser Freiheit auf Ubuntu.

Mirantis als Underdog

Nicht unerwähnt bleiben darf Mirantis: Das US-Unternehmen nimmt seinen Slogan “Pure Play Open Stack” ernst und bietet in Form von Fuel (Abbildung 5) sogar ein eigenes Deployment-Werkzeug an. Damit sollen sich sowohl auf Ubuntu als auch auf Red-Hat-Systemen die Mirantis-eigenen Open-Stack-Pakete leicht und simpel installieren lassen.

Abbildung 5: Fuel von Mirantis gilt als das Werkzeug schlechthin, wenn es um den Aufbau einer Open-Stack-Cloud ohne Distributor geht. Das Tool befindet sich im Augenblick allerdings im Umbruch.

Allerdings steckt Fuel aktuell im Umbruch: Vor etwa vier Monaten gab Mirantis bekannt, dass man das Werkzeug auf Kubernetes-Basis komplett neu schreiben wolle, wofür man auch Google und Intel ins Boot geholt hat. Bis auf Weiteres scheint es also eher keine so gute Idee, ein neues Setup auf Fuel zu gründen.

Echtes Pure Play gibt es nicht

“Pure Play Open Stack” bezieht sich bei Mirantis übrigens vorrangig darauf, dass die Anwender bei der Nutzung von Mirantis Open Stack nicht automatisch in die Fänge eines der großen Distributoren geraten.

Tatsächlich findet sich “Pure Play Open Stack” aktuell bei keinem der großen Anbieter: Suse, Red Hat, Canonical und Mirantis reichern ihre Open-Stack-Pakete jeweils um diverse Patches an. Dabei handelt es sich einerseits um zurückportierte Fehlerkorrekturen aus späteren Versionen von Open Stack und andererseits um neue Funktionen.

Auf eine ungetrübte Kompatibilität mit der offiziellen Open-Stack-Version der Dienste legen dabei alle Hersteller jedoch großen Wert – wohl auch weil das Open-Stack-Projekt den Herstellern an dieser Stelle Daumenschrauben ansetzen kann: Mit Hilfe von Ref Stack [1] lässt sich eine laufende Open-Stack-Installation auf ihre API-Kompatibilität mit den Vorgaben des Open-Stack-Projekts hin testen. Je höher die Kompatibilität dort offiziell ist, desto besser für den jeweiligen Cloudbetreiber.

Ausblick

Im nächsten Teil des Workshops geht es darum, erste praktische Erfahrung mit Open Stack zu sammeln: Auf Basis mehrerer virtueller Maschinen wird es das Ziel sein, MaaS und Juju auf Ubuntu so zu installieren, dass sich eine echte Open-Stack-Cloud in virtuellen Maschinen nutzen lässt. Das wäre zwar eigentlich die Domäne von Fuel – aufgrund der bereits beschriebenen Problematik mit dem anstehenden Fuel-Rewrite fiel die Wahl des Autors jedoch zu diesem Zeitpunkt auf Ubuntu.