© Knud Nielsen, 123RF

Im April war die Zeit fürs Winterlager vorbei: Dank der gewissenhaften Arbeit von Release-Manager Thierry Carrez konnte das Open-Stack-Projekt die nächste Version seiner Software veröffentlichen, die Release mit dem Codenamen Kilo. Das Linux-Magazin hat sie sich genauer angesehen.

Spätestens seit Firmen wie Suse, Red Hat, Canonical oder HP, IBM und Intel Geld und Zeit in Open Stack investieren ist klar, dass es keine Eintagsfliege ist. Allerdings hat die Medaille zwei Seiten: Die Investoren haben großes Interesse daran, aus ihrem Investment möglichst viel Kapital fürs eigene Unternehmen zu schlagen.

Deshalb halten sie Open Stack und ihre eigenen Leistungen in den Nachrichten und präsentieren es bei jeder sich bietenden Gelegenheit. Dem steht der tatsächliche Fortschritt der Technik gegenüber – und gerade in dieser Disziplin kommt Open Stack bei vielen Admins bis heute sehr schlecht weg.

Die Kritikpunkte sind dabei immer die gleichen: Open Stack sei als Projekt nicht ausgereift genug, um den Ansprüchen des Provider-Alltags zu genügen. Außerdem sei das Geld, das von Unternehmen kommt, gar nicht immer nur förderlich: Gerade weil sich in Open Stack so viele Interessen schneiden, falle es dem Projekt schwer, klare technische Ziele zu formulieren und umzusetzen.

Deshalb ist die Spannung innerhalb der Community jedes Mal groß, wenn eine neue Open-Stack-Version ansteht. Das ist in aller Regel zweimal im Jahr der Fall, so wie im April: Kilo stand als Nachfolger von Open Stack Juno in den Startlöchern. Welche Features bringt das erneuerte Open Stack und ist es den Entwicklern gelungen, einige der großen Probleme zu lösen?

Das große Zelt

Vielleicht eine der wichtigsten Neuerungen hat mit der Open-Stack-Technik im Grunde gar nichts zu tun: Die Big-Tent-Initiative der Open Stack Foundation. Das Bild vom großen Zelt soll verdeutlichen, dass sich ab sofort Open Stack als große Heimstatt für alle Projekte verstehen möchte, die irgendwas mit der Cloud-Computing-Lösung zu tun haben. Der Umsetzung der Big-Tent-Initiative sind einige längliche Diskussionen vorausgegangen, auch und gerade innerhalb der Open Stack Foundation selbst. Die Problematik beschreibt Release Manager Thierry Carrez in einem ausführlichen Aufsatz [1] gut verständlich.

Bis einschließlich Juno habe Open Stack aus einer großen Release bestanden und ausschließlich die offiziell integrierten Teile von Open Stack durften sich auch so nennen. Wer zu solch einer integrierten Komponente werden wollte, musste den Incubation-Prozess und damit verschiedene Prüfungen hinter sich bringen. Erst nach etlichen eingehenden Checks war der Weg endlich frei, um zu einer offiziellen Open-Stack-Komponente erhoben zu werden.

Allerdings tummeln sich im Open-Stack-Dunstkreis mittlerweile so viele Subprojekte, die um Aufnahme in das Projekt gebeten haben, dass die Koordination von Releases zusehends schwieriger wird. Gleichzeitig entsteht für die Programme, die noch nicht integriert sind, der Eindruck, es handle sich um Projekte, die in der Open-Stack-Community nicht fest verankert sind. Dieser Eindruck ist freilich nicht immer zutreffend oder erwünscht.

Nicht zuletzt hat die bisher genutzte Policy tatsächlich auch Entwicklungen verhindert: Zur Komponente Ceilometer (Abbildung 1) etwa gibt es zwei Alternativen, die ebenfalls Metering für Open Stack anbieten. Bis jetzt vermochte keines der beiden Projekte – Stacktach und Monasca – jedoch zur offiziell anerkannten Komponente zu werden. Denn sie hätten eine Alternative zu bereits vorhandener Funktionalität geboten. Und das war in den Statuten bisher schlicht nicht vorgesehen.

Abbildung 1: Bis heute nutzt Ceilometer ein Design, hinter dem nicht mal mehr der ursprüngliche Autor steht. Doch in Kilo ändert sich gar nichts.

Vier-Punkte-Programm

Die Big-Tent-Initiative soll diese Probleme aus dem Weg räumen. Nach ihrer Einführung soll sich im Grunde jedes Projekt als Bestandteil von Open Stack bezeichnen dürfen, solange es vier sehr wichtige Regeln beachtet:

1. Das Projekt muss sich mit den Open- Stack-Zielen identifizieren und sollte daran interessiert sein, das Ansehen von Open Stack zu steigern.

2. Die Lizenzierung, das Entwicklungsmodell und die Entwicklerwerkzeuge (wie etwa Gerrit für die Code-Review) müssen mit denen des Open-Stack-Projekts identisch sein.

3. Grundlegende API-Kompatibilität, beispielsweise zum Modul Keystone, muss gegeben sein.

4. Die Projekte unterstellen sich dem Open Stack Technical Committee.

Big Tent hat in der Community bereits zu heftigen Diskussionen geführt. Während die Befürworter dieser Regelung sich freuen und sie für einen wichtigen Schritt in die richtige Richtung halten, schlagen die Gegner die Hände über dem Kopf zusammen. Denn das große Zelt sei üblicherweise voll mit Clowns, mit der Big-Tent-Initiative gebe die Foundation de facto jede Kontrolle über die technische Architektur von Open Stack auf, sie sei im Grunde nichts anderes als der Ausverkauf der Marke Open Stack.

Dieser Gefahr will das Projekt mit Tags entgegenwirken: Admins sollen in Zukunft an den Tags verschiedener Komponenten erkennen können, ob diese sich etwa dem sechsmonatigen Releasezyklus unterworfen haben oder lieber ihren eigenen Zyklus definieren. Eine Liste der aktuellen Tags findet sich in [2].

Für Kilo gilt ohnedies, dass längst nicht alles so heiß gegessen wie gekocht wird: Kilo besteht im Wesentlichen aus den Teilen, die früher bereits integrierte Komponenten waren. Hinzu gesellt sich Ironic, das in Kilo aber auch ohne Big Tent zur integrierten Komponente geworden wäre. Diversifizierung nach den neuen Regeln dürfte sich also erst nach der Veröffentlichung von Kilo langsam ergeben. Nach der Veröffentlichung der Liberty-Version im Oktober 2015 wird über dieses Thema wieder zu sprechen sein.

Ironic: Endlich!

Ironic ist als einzige offiziell neue Komponente in Kilo eines der großen Highlights. Ironic funktioniert nur zusammen mit Nova. Nova ist die Komponente, die sich um die Verwaltung von Computing-Power in Open-Stack-Clouds kümmert. Will ein Admin eine VM nutzen, sucht Nova dafür den passenden Host aus und startet dort das virtuelle System. Bisher war Nova auf virtuelle Maschinen beschränkt. Ironic ändert das und erweitert es um die Fähigkeit, auch mit physischen System zu hantieren. Echtes Blech wird in Open Stack damit genauso behandelt wie eine VM: Beides lässt sich per Webinterface zentral steuern.

Wie sinnvoll Ironic alleine ist, wird noch zu klären sein. Es entstammt der Feder von HP und wurde dort zusammen mit Triple-O entwickelt. Triple-O steht für “Open Stack on Open Stack”: Die eigentliche Hardware ist bei solchen Setups eine durch Open Stack gesteuerte “Under-Cloud”, auf der dann für Kunden separate “Over-Clouds” gestartet werden können. Ausprobieren kann man Ironic auch mit weniger Aufwand, wer aber das volle Potenzial der Lösung ausschöpfen möchte, braucht Triple-O.

Keystone: Weniger Overhead, mehr Federation

Kaum Beachtung findet in Release-Nachrichten häufig Keystone, das als die zentrale Benutzerverwaltung von Open Stack meist im Hintergrund werkelt. Kilo bringt für Keystone aber gleich zwei wichtige Neuerungen. Einerseits lassen sich jetzt die Keystone-Instanzen mehrerer Open-Stack-Clouds so verbinden, dass daraus ein Federation-Netzwerk entsteht. Nutzer können sich mit den gleichen Credentials an mehreren Clouds anmelden – ein echtes Komfort-Feature.

Fast noch wichtiger sind die Keystone Lightweight Tokens, auch KLWT abgekürzt. Wenn Nutzer sich bei Keystone mit ihrer Kombination aus Name und Passwort anmelden, erhalten sie im Gegenzug einen digitalen Schlüssel, auch als Token bezeichnet. Dieses Token nutzen sie, wenn sie mit den anderen Open-Stack-Diensten reden. Keystone speichert jedes ausgestellte Token in einer eigenen Datenbank ab. Wenn Nutzer sich mit ihrem Token bei anderen Diensten in der Wolke anmelden, dann fragen diese Dienste bei Keystone nach und erkundigen sich, ob denn das Token noch gültig ist (Abbildung 2).

Abbildung 2: In Juno legt Keystone für jedes ausgestellte Token einen Eintrag in der eigenen Datenbank ab.

Die Notwendigkeit, persistente Tokens zu speichern, führt allerdings auch zu hässlichen Nebeneffekten. Neben dem Einfluss auf die Performance läuft außerdem gerade in größeren Open-Stack-Wolken regelmäßig die Tokentabelle von Keystone so voll, dass der Admin sie händisch ausräumen muss.

Hier setzen in Kilo die KLWT an: Die Idee ist, dass sich die Echtheit von Tokens durch andere Dienste verifizieren lässt, ohne dass die Tokens zentral gespeichert werden müssen. Das passiert mittels einer digitalen Signatur: Ein KLWT enthält neben vielen Informationen über den Nutzer, das zu ihm gehörige Projekt und den Zeitpunkt der Ausstellung des Tokens auch eine digitale Signatur.

Anhand dieser Signatur stellt dann ein vom Nutzer kontaktierter Dienst unabhängig von Keystone fest, ob das Token gültig ist oder nicht. Morgan Fainberg, der im Kilo-Releasezyklus Keystone als Project Technical Lead vorstand, erhofft sich von KLWT bessere Performance und zuverlässigere Funktion.

Nova: Als Objekt behandelt

Der Computing-Dienst Nova bietet in Kilo mehrere neue Funktionen. Zunächst haben die Entwickler unter der Haube viel geschraubt und so die Konvertierung hin zu Datenbankobjekten vorangetrieben. Gemeint ist das Datenmodell, das Nova für seine eigene Datenbank nutzt. Frühere Nova-Versionen haben per SQL-Alchemy direkt einzelne Einträge in die Datenbank geschrieben.

Allerdings ist es innerhalb eines großen Computing-Framework mit Dutzenden Servern sehr schwer, diese Schreibvorgänge ordentlich zu koordinieren. Schon in der Havana-Version von Open Stack (2014) hat die Konvertierung hin zu Objekten begonnen. Seither betrachtet Nova etwa Instanzen als Objekte, die es direkt in der Datenbank ändern kann, aber eben auch per RPC-Aufruf quer durch die gesamte Wolke. De facto zieht das Layer-Modell also eine Abstraktionsschicht ein, die bis jetzt allerdings nicht alle Nova-Komponenten genutzt haben.

Kilo bringt einen Schwung von Updates für die Objekt-Funktion und sorgt nebenbei im Handstreich dafür, dass etwa Updates von Nova leichter werden. Denn dank der Abstraktionsschicht hängen zunehmend weniger Nova-Komponenten davon ab, dass sich das Datenbankschema von Nova von einer zur nächsten Version nicht ändert.

Frischzellenkur

In Kilo haben die Open-Stack-Entwickler endlich auch damit begonnen, die Zellenerweiterung von Nova aufzubohren. Unter Cells verstehen die Nova-Entwickler autonome Computing-Einheiten, die über eine zentrale Stelle miteinander verbunden sind. Bisher war es Nova nicht möglich, in den einzelnen Zellen lokale Datenbanken und RPC-Dienste zu verwenden. Gerade das kann jedoch zum Nadelöhr werden, wenn die einzelnen Zellen nicht in direkter Netzwerknähe zueinander stehen. Die Zellen 2.0 in Kilo beheben dieses Problem, so sollen Zellen besser nutzbar sein.

Die Axt im Walde bei Neutron

Mancher Cloud-Admin zuckt beim Wort Neutron zusammen. Kein Wunder, denn die Open-Stack-SDN-Komponente gilt als hyperkomplex und schwer beherrschbar. Als hätten die Entwickler die Kritik gehört, reagieren sie in Kilo und misten das riesige Projekt Neutron gehörig aus. Das bedeutet nicht, dass Funktionalität wegfällt. In Zukunft gibt es lediglich nicht mehr ein großes Neutron-Projekt, sondern mehrere kleine mit spezifischen Funktionen (etwa L2- oder L3-Netzwerkkonnektivität).

Die abgespaltenen Teile, etwa die LBaaS- oder VPNaaS-Plugins, sollen ebenfalls von diesem Schritt profitieren: Über definierte APIs werden sie künftig mit Neutron reden, statt direkt auf den Neutron-Code zuzugreifen. Eine eigene Neutron-Bibliothek mit geteilten Code-Elementen hilft dabei zusätzlich. Kilo ist ohnehin erst die erste Phase der Umstellung: Bis zur M-Version sollen die Änderungen weitergehen, wobei dann sogar jede Neutron-Zusatzkomponente ihr eigenes API haben soll.

Vorerst ins Wasser fällt dagegen Perestroika. Unter diesem Codenamen war für Kilo schon lange ein neues Plugin-Interface geplant, das SDN-Plugins wie Open Vswitch oder Open Contrail mehr Funktionalität bieten sollte. Ende Februar mussten die Entwickler den Plan jedoch verwerfen. Weil schon Arbeit investiert wurde, dürfte aber sicher sein, dass in der Open-Stack-Version Liberty Gorbatschow sein Denkmal bekommt.

Wer Open Stack mit Windows einsetzt, wird sich über den Neutron-OVS-Agent für Windows freuen, der Kilo ebenfalls beiliegt. Cloudbase hat mal wieder ganze Arbeit geleistet und nicht nur die Open-Vswitch-Portierung auf Windows erfolgreich gemanagt, sondern die Open-Stack-Integration gleich mitgeliefert.

Glance: Kleine Änderungen, große Wirkung

Für Glance haben sich die Kilo-Entwickler lediglich 21 Funktionen auf die To-do-Liste geschrieben – bei Neutron mehr als doppelt so viele, ebenso bei Nova. Im direkten Vergleich mit den anderen Komponenten ist das Leben in der Welt des Open-Stack-Imagedienstes also eher beschaulich. Im Grunde ist das aber nur folgerichtig: Glance unterstützt praktisch sämtliche Funktionen, die in einer Cloud relevant sind.

Als dringlichste Probleme für Kilo implementierten die Entwickler eine verbesserte Sortierreihenfolge samt Uservorgabe bei der Ausgabe aller Images in Glance sowie die Unterstützung für Versionsnummern nach Sem-Ver-Standard [3]. Performance-Verbesserungen etwa beim Ablegen von Images im Open-Stack-Objektspeicher Swift und weitere neue Performance-Tweaks runden die Glance-Änderungen ab.

Mehr Treiber für Cinder

Der Dienst für persistente Volumes, Cinder, wandelt auf Novas Spuren und nimmt ebenfalls eine Umwandlung hin zu Objekten in Angriff. Demnach soll in Zukunft jedes Cinder-Volume über einen ähnlichen Zwischenlayer angesprochen werden, wie es für Instanzen bei Nova jetzt schon der Fall ist.

Die Gründe sind identisch und zum Teil schauen sich die Devs von Cinder auch Details bei Nova ab. Für Admins deutlich interessanter dürfte indes die Tatsache sein, dass Cinder mehrere neue Treiber bekommt – und ein neues Treiberinterface: Die ABC-Python-Bibliothek dient hierfür als Basis. Erste Treiber sind bereits auf das neue ABC-Interface portiert, etwa der für Ceph zuständige »rbd« -Treiber. Die anderen dürften im Rahmen des Liberty-Releasezyklus folgen.

Neue Treiber und Treiber-Erweiterungen stehen für HP 3Par, Storpool oder Open Vstorage zur Verfügung. Massiv ausgebaut haben die Cinder-Entwickler auch ihre I-SCSI-Implementation. Der Netapp-Treiber beherrscht in Kilo zudem offiziell Unterstützung für Fibrechannel.

Das Billing als ewige Baustelle

Wer Open Stack produktiv einsetzt, wird seinen Kunden vermutlich etwas für die erbrachte Dienstleistung berechnen wollen. Dafür ist ein zuverlässiges und leistungsstarkes Billing-Modul unumgänglich. Genau das fehlt allerdings bei Open Stack seit Jahren. Spätestens seit Julien Danjou als erster Autor von Ceilometer letztes Jahr quasi öffentlich Abbitte [4] leistete, sieht es so aus, als begebe sich Ceilometer auf den richtigen Weg.

So viel gleich vorweg: An der Ceilometer-Architektur ändert sich auch in der neuen Version Kilo nicht viel. Die flächendeckende Einführung von Gnocchi als Time-based-Datenbank lässt weiter auf sich warten. Wer nicht warten will, der sollte sich die Konkurrenzprojekte Stachtach [5] oder Monasca [6] genauer ansehen, die zumindest zum Teil die benötigten Features bieten.

Frühjahrsputz bei Horizon

Endanwender kommen in Open-Stack-Clouds in der Regel mit Horizon in Kontakt, dem Open-Stack-Webinterface (Dashboard). In den letzten Jahren hat sich in Sachen Optik bei Horizon allerdings nicht allzu viel getan. Mittlerweile wirkt das Werkzeug leicht altbacken (Abbildung 3). Kilo beseitigt diesen Umstand und bringt für Horizons Instanz-starten-Dialog eine ganz neue Tapete mit. Die soll das Werkzeug aber nicht nur optisch auffrischen, sondern soll Horizon auch deutlich effizienter bedienbar machen (Abbildung 4).

Abbildung 3: Der alte Dialog zum Starten von Instanzen in Horizon wirkt in der Tat eher altbacken.

Abbildung 4: Alles neu macht der April: Der neue Launch-Instance-Dialog wirkt nicht nur deutlich eleganter und funktionaler, er ist es auch.

Nun sind grafische Oberflächen zwar meist Geschmackssache. Die Umgestaltung von Horizon zwischen Juno und Kilo kann sich aber sehen lassen: Insgesamt wirkt Horizon durch den neuen Dialog zum Starten von Instanzen viel eleganter und gradliniger.

Für Anbieter wie Canonical oder HP hält Horizon eine weitere angenehme Überraschung bereit: Ein eigenes Theme-Interface bietet ab Kilo die Option, Themes direkt und ordentlich in Horizon zu implementieren. Zwar waren Themes auch bis jetzt schon möglich, doch nur indem der Admin das ab Werk ausgelieferte Theme per Python-Override mit einem lokalen Thema überschrieb. Kilo bietet dafür eine eigene Schnittstelle, sodass sich zum Beispiel auch mehrere Themes gleichzeitig nutzen und in der Theorie per Dropdown-Menü auswählen lassen.

Fazit: Ganz nett

Kilo gehört wieder einmal nicht zu den Open-Stack-Versionen, die besonders durch bahnbrechende neue Funktionen auffallen. Die Big-Tent-Diskussion hat sich über weite Teile der Release-Arbeit im Hintergrund hartnäckig gehalten und dabei auch einiges an Zeit verschluckt – obwohl die Auswirkungen von Big Tent in Kilo noch gar nicht richtig zum Tragen kommen. Ob sich die Initiative für das Projekt letztlich auszahlt oder nur noch mehr Chaos verursacht, muss sich erst noch herausstellen.

Technisch sind die Änderungen zwar nicht gerade epochal, aber gerade das macht sie in gewisser Weise auch berechenbar. Kilo präsentiert sich als sinnvolles Update zu Juno – und das ohne großes Zerstörungspotenzial.