OpenStack-Workshop, Teil 4: Was ist neu in Grizzly?

Neben Ubuntu hält kein anderes Projekt so treu zu einem festen Release-Zyklus wie OpenStack. Im Parallelflug mit Canonical werfen die Entwickler im April und im Oktober jeweils eine neue Version auf den Markt. Auch in diesem April war das nicht anders: Seit kurzem steht OpenStack 2013.1 alias Grizzly bereit zum Download. Wie bei den vorangegangenen Versionen hat sich auch diesmal vieles geändert. Für Administratoren bestehender Cloud-Installationen stellt sich die Frage, ob sich ein Update lohnt – und ob das technisch ohne weiteres zu bewältigen ist. Bisher hat OpenStack sich im Hinblick auf Updates ja nicht eben mit Ruhm bekleckert.

So war bis dato der einzige vertretbare Rat an OpenStack-Admins, Updates von einer OpenStack-Version auf die nächste erst gar nicht zu probieren. Die erste mit dem "Enterprise Ready"-Siegel geadelte OpenStack-Version war Essex im April 2012. Schon damals versprachen die Entwickler, sich bei zukünftigen Versionen besser um die API-Kompatibilität zwischen alter und neuer Version zu kümmern. Mit sehr bescheidenem Erfolg: Ein Update von Essex auf Folsom als Nachfolger war kompliziert bis unmöglich.

API-Stabilität

Zwischen Folsom und Grizzly haben die Entwickler ihre Hausaufgaben allerdings besser erledigt: Anstatt vorhandene APIs zu verändern, haben sie zusätzliche APIs hinzugefügt und diese mit einer höheren Versionsnummer versehen. Ganz gut wird das bei Keystone deutlich, der Authentifizierungskomponente: Neben der schon in Folsom vorhandenen API v2 hat Keystone jetzt eine API 3.0, die parallel zur alten API funktioniert, sodass vorhandene Installationen keine Umkonfiguration brauchen. Die Entwickler versprechen, dass die alte API mindestens bis zur übernächsten Release bleibt, also dem I-Release (zur Erinnerung: Wie bei Ubuntu auch erhalten alle OpenStack-Releases Codenamen, die dem Alphabet folgen – der Nachfolger von Grizzly wird beispielsweise Havana heißen).

Funktionen der 3.0er-API lassen sich freilich aus der 2.0er-API heraus nicht nutzen. Im Test der Vorversion klappte die Migration von einem Folsom-Keystone auf ein Grizzly-Keystone gut, obgleich der zu migrierende User-Stamm eher klein war. Insgesamt machte das Update jedoch einen zuverlässigen Eindruck, vor der Umstellung des Produktivsystems tun Admins aber dennoch gut daran, den Umstieg unter Laborbedingungen gut zu testen.

Neue Komponenten

Grizzly kommt also mit Update-Potenzial, aber lohnt sich das Update denn überhaupt? Die Antwort auf diese Frage geben vielleicht bereits die beiden Neuzugänge in der Familie der OpenStack-Kernkomponenten: Ceilometer und Heat.

Ceilometer ist OpenStacks sehnlichst erwartete Statistik-Komponente. Wer jetzt an schnödes Zahlenwerk denkt, hat Recht und auch wieder nicht – denn Ceilometer soll keinesfalls nur Statistikdaten in OpenStack sammeln, um dann bunte Diagramme daraus zu generieren. Stattdessen weisen die Entwickler ihrem Schätzchen die Rolle eines Billing-Systems zu. Ceilometer tritt damit an die Stelle der in der Computing-Komponente Nova bereits enthaltenen, aber sehr rudimentären Nutzungsstatistiken.

Der Clou bei Ceilometer ist, dass es in der Lage sein soll, seine Daten grundsätzlich einer beliebigen Anzahl von Nutzern zur Verfügung zu stellen. Theoretisch kann es damit als Datenquelle für ein Verrechnungssystem nach Industriestandard genau so funktionieren wie als Quelle für ein Cloud Monitoring. Ein Client (im Ceilometer-Sprech auch Consumer genannt) ist BillingStack, das ein eigenständiges Billing-System für OpenStack ist und die Verrechnung von OpenStack-Diensten nach dem auch tatsächlich vorhandenen Konsum durch Anwender ermöglicht. Mehr Consumer sind zumindest auf der Ceilometer-Website bis dato nicht aufgelistet, allerdings ist die Umgebung eben auch erst seit Grizzly überhaupt als Incubated Project Teil von OpenStack. Die Hoffnung auf einen baldigen Reigen an Consumern ist also durchaus berechtigt.

Noch einen Neuling dürfen OpenStack-Benutzer in Grizzly willkommen heißen: Heat hat es ebenfalls in den Rang eines Incubated Projects geschafft. Heat bezeichnet sich selbst als Orchestration Suite; allerdings tritt Heat nicht in direkte Konkurrenz zu anderen Lösungen wie Chef oder Puppet. Denn Heat ist streng OpenStack-spezifisch: Mittels einer einzelnen Datei – einem Template – haben Benutzer per Heat die Möglichkeit, virtuelle Maschinen aus dem Boden zu stampfen und diese gleich miteinander zu verbinden. Ein Template könnte zum Beispiel "Webserver-Cluster" heißen und dafür sorgen, dass automatisch eine Webserver-Farm entsteht. Praktisch: Features wie Hochverfügbarkeit sowie ein grundlegendes Monitoring bringt Heat gleich mit. Außerdem unterstützt OpenStack Heat das AWS-CloudFormation-Format, das auch Amazon nutzt, um in der eigenen Wolke Inter-VM-Orchestrierung zu ermöglichen. Letztlich ist Heat vor allem ein Werkzeug, dass Admins bei der weiteren Automatisierung helfen soll. Damit passt es sehr gut in OpenStack, das Automatisierung insgesamt zum höchsten Prinzip erhoben hat.