© foottoo, 123RF

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.

Auf Open Stack ist Verlass, zumindest was den Releasezyklus angeht: Die neue stabile Version namens Liberty war für Oktober angekündigt und Thierry Carrez, altgedienter Releasemanager, erreichte sein Ziel mit der Präzision eines Schweizer Uhrwerks. Admins haben ab sofort Gelegenheit, sich mit der insgesamt zwölften Version der freien Cloudverwaltung vertraut zu machen. Grund genug, einen Blick auf die Neuerungen von Liberty zu werfen und der Frage nachzugehen, ob sich ein Update lohnt.

Versions-Chaos

Noch bevor es um die technischen Neuerungen in Liberty geht, steht eine andere Diskussion auf dem Plan: Die Versionsnummern der einzelnen Komponenten in Open Stack wirken auf den ersten Blick nämlich wie wahllos ausgewürfelt. Bis zur letzten Open-Stack-Version namens Kilo war das anders: Alle Komponenten folgten demselben Versionsschema, das aus dem Kalenderjahr und der Nummer der Major-Release im Jahr bestand. Open Stack Kilo trug deshalb die Version 2015.2 einheitlich für alle Komponenten. In Liberty hat sich das geändert: Nova hat nun die Version 12.0.0, Neutron ist 7.0.0 und Keystone bekommt die Version 8.0.0 zugeordnet.

Die Erklärung für das vermeintliche Chaos liefert Thierry Carrez in seinem Blog [1]. Er erläutert, dass sich in den vergangenen Releases auch die Art geändert hat, wie Open Stack grundsätzlich entwickelt wird: Erst bezog sich der Name als Marke lediglich auf eine Sammlung von Kernwerkzeugen. Dann wechselte Open Stack zur Idee des Big Tent: Open Stack bezeichnet in diesem Sinne viel eher das Projekt per se und nicht mehr eine spezifische Kompilation von Softwarekomponenten.

Zwar gibt es auch im Big-Tent-Schema noch Kernkomponenten, die als solche zusammen veröffentlicht werden, aber die Entwickler wollten über unterschiedliche Versionsnummern zum Ausdruck bringen, dass die Entwicklung dieser Werkzeuge nicht zwangsläufig starr aneinander gekoppelt ist.

Die Versionsnummern sind zudem weniger zufällig, als es auf den ersten Blick scheint. Die Major-Version ist ganz einfach die Anzahl an Open-Stack-Releases, in denen der jeweilige Dienst schon zum Core-Umfang des Projekts zählt. Keystone etwa hielt in Essex zum ersten Mal Einzug in das Projekt, die Liberty-Version ist also die insgesamt achte Version, zu der Keystone gehört – die Keystone-Versionsnummer ist aus diesem Grund in Liberty 8.0.

Nova-Objekte und eine neue API-Version

Open Stack Nova ist als Virtualisierungskomponente dafür verantwortlich, den Betrieb virtueller Maschinen zu gewährleisten. Traditionell liegt hier daher ein Schwerpunkt der Open-Stack-Entwicklung. In Liberty haben die Entwickler sich vorrangig um das Rest-API von Nova gekümmert und zudem die Hochverfügbarkeitsfunktionen verbessert.

Die Änderungen beim API sind durchaus bemerkenswert: Zwar ist das »nova-api« -Programm nur eines von vielen der Nova-Suite, tatsächlich geht ohne das API aber nichts. Denn es ist die Schnittstelle für Nutzer, die neue VMs starten oder vorhandene löschen wollen.

In der Liberty-Variante von Nova hält die neue API-Version 2.1 Einzug in Open Stack. Sie bietet mehr Funktionalität als ihre Vorgängerin. Von großer Bedeutung ist etwa die Nova-Objects-Funktion. Objects sind quasi Konfigurationsparameter zu einer bestimmten VM, die der Starter des virtuellen Systems schon beim Launch bei Nova deponiert.

Im Gegensatz zu den Metadaten, die aus der VM heraus sichtbar sind, beziehen sich die Objects mehr darauf, welche Parameter Qemu mit auf den Weg bekommt, wenn es die jeweilige VM ausführt. Dank der Objects stellt Liberty so multiple Netzwerk-Queues für VMs bereit. Der virtuelle Netzwerktreiber der VM kann so mehr als einen CPU-Kern nutzen, wenn er Daten mit der Außenwelt austauscht. Vorher waren die entsprechenden Einstellungen bei Glance angesiedelt, mussten also beim Auswählen festgelegt werden. Durch die direkte Umsetzung in Nova versprechen sich die Entwickler in Zukunft mehr Optionen.

Bessere HA, bessere VM-Verwaltung

Deutlich weniger abstrakt sind die API-Verbesserungen in Sachen HA. Bis heute bietet Open Stack Nova selbst keine funktionierende Hochverfügsbarkeitslösung für VMs; für Infrastruktur-Dienste lässt sie sich nur mit externen Werkzeugen nachrüsten. Immerhin: Das Evacuate-Feature bietet Admins seit einigen Releases die Möglichkeit, bei einem Serverausfall die betroffenen VMs auf einem anderen Host erneut zu starten.

Open Stack selbst hat dafür jedoch keine Automatisierung an Bord. Liberty stellt immerhin eine direkt im API verankerte Schnittstelle für externe HA-Dienste bereit, damit diese Nova mitteilen können, wenn ein Host das Zeitliche gesegnet hat. Erst wenn ein Host offiziell als »down« markiert ist, lässt sich der Evacuate-Befehl nämlich auf den Host anwenden, der daraufhin dafür sorgt, dass alle betroffenen VMs auf anderen Hosts neu starten. Die Voraussetzung dafür, dass der Evacuate-Befehl überhaupt funktioniert, ist natürlich nach wie vor, dass die ausgefallene VM für ihre Daten persistenten Speicher nutzt.

Apropos Evacuate: Liberty bringt diverse Verbesserungen im Hinblick auf den erzwungenen VM-Neustart auf anderen Hosts. So ist es nun unwahrscheinlicher, dass der Evacuate-Befehl durch Fehler Daten innerhalb betroffener VMs schreddert. Ein solches Szenario war beim Vorgänger Kilo durchaus denkbar und auch dokumentiert.

QoS und HA bei Neutron

Zwei Features stechen beim Netzwerkdienst Neutron in Liberty hervor: QoS für einzelne Kunden lässt sich erstmals zentral konfigurieren, zudem hat ein neuer Treiber für LBaaS Einzug gehalten.

Besonders nach dem Quality-of-Service-Feature (QoS, Abbildung 1) haben in der Vergangenheit viele Nutzer gerufen: Noch in Open Stack Kilo ist es etwa denkbar, dass eine einzelne gehackte VM eines Kunden die Verbindungsqualität aller anderen Kunden erheblich beeinträchtigt. Es fehlte die Möglichkeit, für die VMs einzelner Kunden den Datendurchsatz zu beschränken.

Abbildung 1: Das QoS-Feature in Neutron erlaubt es künftig, den erlaubten Traffic einzelner VMs zu begrenzen. Das macht Angriffe weniger effektiv.

Das ist nun in Liberty möglich: Mittels API lassen sich in Neutron Maximalwerte für ein- und ausgehenden Traffic definieren, die danach auf Betriebssystemebene forciert werden. Selbst wenn in einer Public Cloud jemand böswillig gehackte Images nutzt, lässt sich so der durch sie verursachte Schaden eingrenzen.

Auch die Änderungen beim Load Balancing as a Service (LBaaS) sind wichtig: Mittels LBaaS erhofft sich das Open Stack-Projekt einen Fuß in die NFV-Türe zu bekommen (Network Functions Virtualization). Die Idee ist, Load Balancer auf Hardware- oder Software-Basis direkt aus Open Stack Neutron heraus zu steuern. Für den Hardware-Ansatz bietet Neutron seit einigen Releases die Möglichkeit, Module zu laden, die dann etwa Radware- oder F5-Load-Balancer mit Konfiguration füttern.

Auf Software-Ebene kam bisher vorrangig HA-Proxy zum Einsatz. Das soll sich in Zukunft ändern: In Form von Octavia [2] stellen die Neutron-Entwickler eine eigene Referenzimplementierung für einen Software-Load-Balancer vor, der sich aus Neutron heraus auch schon steuern lässt. Die selbst gesteckten Ziele wären mit ambitioniert noch vorsichtig umschrieben: Nicht weniger als der neue Standard für Load Balancing in großen Open-Stack-Installationen möchte man werden. Ob das klappt, wird sich zeigen.

Heiße Sache: Heat

Heat ist für Open Stack von großer Bedeutung – es handelt sich um die Orchestrierungskomponente. Orchestrierung ist im Cloudkontext deshalb so wichtig, weil sie den Faktor IaaS um sinnvolle Automatisierung erweitert. Eine Open-Stack-Plattform per se bringt ja nicht viel anderes als etwa eine VMware-Installation – beide Lösungen ermöglichen es, VMs von zentraler Stelle aus zu starten und zu steuern. Orchestrierung erlaubt es, auf Basis der Open-Stack-Funktionalität per Mausklick ganze virtuelle Umgebungen zu schaffen, die etwa Entwicklern als Staging-Plattform dienen.

Technisch betrachtet besteht Heat aus drei Komponenten: Zwei APIs – eins für das Heat-eigene HOT-Template-Format und eins für Amazons CFN-Format – in Richtung Nutzer, zudem im Hintergrund die Heat-Engine, die Nutzereingaben in Open-Stack-Dienste umwandelt und diese startet. In Liberty hält ein neuer Unterbau für Heat Einzug: Convergence (Abbildung 2).

Abbildung 2: Das Heat-Frontend wird auch weiterhin die gewohnte Optik liefern, die neue Convergence-Engine im Hintergrund soll aber besser funktionieren.

Convergence soll gleich mehrere Probleme der alten Lösung beseitigen. Zum einen ist die alte Heat-Engine bemerkenswert schlecht darin, viele Dinge zur gleichen Zeit zu tun. Das ist ein echtes Problem: Die Heat-APIs sind meist in Form von hochverfügbaren LB-Setups mit vielen Webservern ausgelegt, wie es bei HTTP-basierten Diensten üblich ist. Wenn von mehreren Webservern kommende Requests gleichzeitig bei derselben Heat-Engine aufschlagen und die Templates, die Requests auslösen, obendrein groß sind, gerät die Heat-Engine oft aus dem Tritt. In Liberty lässt sich die Convergence-Engine bereits nutzen, die Entwickler raten aber, das noch nicht in der Produktion zu tun.

Auch die alte Heat-Engine hat zusammen mit den vorhandenen APIs so manches Update abbekommen. Mit Hilfe von »heat stack-preview« lässt sich ein Admin beispielsweise anzeigen, welche Auswirkungen der Befehl »heat stack-update« für einen bestehenden Heat-Stack hätte. Überhaupt soll »stack-update« nun robuster als vorher sein. Ressourcentypen sind ebenfalls hinzugekommen: Heat kann nun im DNS-Dienst Designate [3] DNS-Einträge anlegen oder auch neue Passwörter in Barbican erstellen.

Designate und Barbican

Liberty bringt zwei neue Programme in der Version 1.0, auf die Admins seit einiger Zeit gewartet haben: Designate und Barbican. Technisch haben die beiden nichts miteinander zu tun, aber sie sind jeweils von großer Bedeutung.

Designate (Abbildung 3) rüstet offiziell die DNS-as-a-Service-Funktionalität für Neutron nach. Erstmals wird es in Liberty also möglich sein, DNS-Einträge für gestartete VMs anzulegen. Dass dies von hervorgehobener Bedeutung ist, leuchtet schnell ein: Wer etwa per Heat ein VM-Ensemble aus 30 einzelnen virtuellen Maschinen startet, will danach nicht in einem separaten, von Open Stack völlig losgelösten DNS-Setup für die gestarteten VMs DNS-Einträge anlegen.

Abbildung 3: Designate bietet in Open Stack erstmals DNSaaS, sodass neue VMs nicht nur IPs haben, sondern auch brauchbare Namen.

Designate bietet in Zukunft die Möglichkeit, entsprechende DNS-Einträge direkt aus Open Stack heraus automatisch anzulegen und zu löschen. Dabei hält die Software die Open-Stack-Vorgaben etwa in Sachen Nutzerverwaltung ein, sodass Kunden in der Cloud trotzdem nicht unbeschränkten Zugriff auf einzelne Zonefiles haben – und etwa Host-Einträge anderer Kunden sehen oder manipulieren können. Designate ist insofern eine wichtige Erweiterung der von Open Stack bereitgestellten Funktionalität.

Ganz ähnlich verhält es sich mit Barbican (Abbildung 4): Die Software will innerhalb von Open Stack ein zentraler Speicher für Passwörter und Zertifikate sein. Wer etwa verschlüsselte Volumes in Cinder nutzen möchte, braucht eine Verwaltung – Cinder selbst bietet keine Möglichkeit und andere Open-Stack-Dienste auch nicht. Seit Monaten verweisen praktisch alle Open-Stack-Komponenten darauf, dass die nötige Funktionalität von einer zentralen Komponente bereitgestellt werden solle. Indem Barbican die Version 1.0 erreicht, wird es offiziell zu eben dieser Komponente.

Abbildung 4: Barbican ist erstmals Teil einer Open-Stack-Release in Version 1.0. Es soll das zentrale Speichern von Passwörtern leichter machen.

Ab Werk lassen sich drei Arten von Einträgen in Barbican ablegen: Passwörter (so genannte Raw Keys) sowie symmetrische und asymmetrische Schlüssel. Damit ist auch die Verwaltung von X-509-Zertifikaten möglich. Der Quick-Start-Guide [4] verrät Admins, wie sie Barbican in eine vorhandene Cloud integrieren und die anderen Open-Stack-Dienste mit Barbican verbinden.

Ceilometer und Gnocchi

Wichtige Neuerungen gibt es überdies beim Open-Stack-Abrechnungsdienst. Zur Erinnerung: Ceilometer halten nicht wenige Open-Stack-Entwickler eher für ein Problem als für eine Lösung. Der Dienst existiert in Open Stack seit einigen Releasezyklen, hat sich über die Zeit jedoch als zu ineffizient, zu behäbig und zu Ressourcen-hungrig herausgestellt. Rackspace hat in Form von Stacktach gar eine Ceilometer-Alternative veröffentlicht, die allerdings selbst unter so manchem Problem leidet.

Der Ceilometer-Chefentwickler Julien Danjou hat in seinem Blog vor über einem Jahr öffentlich Abbitte getan und eine Reihe von Designfehlern in Ceilometer eingeräumt. Damals stellte er auch die Lösung vor, die aus seiner Sicht die Probleme beseitigen soll: Anstatt auf klassische Datenbanken wie MySQL oder Mongo DB zu setzen, sollte Ceilometer eine eigene Datenbank namens Gnocchi benutzen, die auf dem Prinzip einer Time-Series-Database beruht. Billing-Daten, so die Theorie, seien das perfekte Futter für eine solche Datenbank, Ceilometer solle viel schneller werden, wenn es im Hintergrund einen entsprechenden Datenspeicher hat.

Aber es folgten wenige sichtbare Taten: Gnocchi, also die Datenbank für Ceilometer, war bei der letzten Open-Stack-Release gerade in Version 1.0 fertig, aber an ihre Integration in Ceilometer war noch gar nicht zu denken. Der Release-Zyklus hin zu Open Stack Liberty hat die Situation nun grundlegend geändert: Danjou hält Gnocchi für fertig und hat es offiziell bereits in Version 1.2 veröffentlicht. Parallel dazu haben die Entwickler auf dem Weg zur Liberty-Version von Ceilometer die nötige Integration für den Billing-Dienst gebaut, sodass Ceilometer nun auch tatsächlich mit Gnocchi sprechen kann.

Wer sich bislang mit Ceilometer auf Mongo DB oder MySQL herumgeschlagen hat, sollte die Gnocchi-Anbindung von Ceilometer in Liberty also dringlichst ausprobieren. Die Wahrscheinlichkeit, dass Ceilometer dadurch in vielerlei Hinsicht zuverlässiger und schneller wird, ist sehr hoch – und sehr viel schlimmer als zuvor kann es ohnehin nicht werden.

Fazit

Open Stack Liberty führt den Trend fort, der bereits die letzten Releases der Cloudsoftware dominiert hat: Die Zeit wegweisender Updates scheint fürs Erste vorbei zu sein. Stattdessen beschränken sich die Entwickler auf graduelle Verbesserungen, von denen es im Gegenzug sehr viele gibt. Die neue Engine für Heat ist noch eine der auffälligsten Neuerungen, auch wenn erst in der Folgeversion Nutzer überhaupt in den Genuss dieses Updates kommen dürften.

Die endlich fertiggestellte Gnocchi-Integration von Ceilometer hat das Potenzial, aus dem Open-Stack-Metering-Dienst endlich ein funktionierendes Werkzeug zu machen. In den Kernkomponenten finden sich darüber hinaus viele Kleinigkeiten, die das Leben von Admins und Nutzern insgesamt angenehmer gestalten werden.

Deutlich mehr Fortschritt findet sich bei den Projekten, die bis dato nicht als Teil von Open Stack gegolten haben und erst durch die Big-Tent-Initiative in den Fokus rückten: Designate etwa wartet anlässlich der Liberty-Release mit einer Version 1.0 auf. Die Möglichkeit, DNSaaS direkt aus Open Stack heraus zu betreiben, ist dadurch real geworden. Ähnlich hält es Barbican: Erstmals ist eine Open-Stack-Version mit einem Werkzeug ausgerüstet, um Passwörter und sicheren Speicher in der gesamten Cloud zentral zu managen. Es scheint, als habe die Big-Tent-Initiative Schwung in das Projekt gebracht. Wenn die nächste Open-Stack-Version, Mitaka, ähnliche Erfolge zeitigt, wird Big Tent als erfolgreiche Änderung in die Geschichte von Open Stack eingehen. Bis dahin gilt, dass sich ein Update von Kilo auf Liberty auszahlt.

Doch Achtung: Die Open-Stack-Entwickler weisen darauf hin, dass der Upgrade-Pfad von Kilo auf Liberty allein dann reibungslos funktioniert, wenn die zu aktualisierende Open-Stack-Cloud vorher die letzten verfügbaren Kilo-Pakete bekommt. Als Grund geben sie mehrere Änderungen unter der Haube an, die in der letzten stabilen Kilo-Version vorbereitet worden sind.

Der Autor

Martin Gerhard Loschwitz arbeitet als Cloud Architect bei Sys Eleven. Er beschäftigt sich dort intensiv mit den Themen Open Stack, Distributed Storage und Puppet. Außerdem pflegt er in seiner Freizeit Pacemaker für Debian.