Verbesserung an Hintergrunddiensten

Der Blockspeicher-Dienst Cinder sowie Keystone, das Benutzer anhand ihres Passworts authentifiziert, werkeln für gewöhnlich unbeachtet im Hintergrund. Kein Grund jedoch, sie im Hinblick auf neue Features stiefmütterlich zu behandeln. In Keystone erfährt die neue API (Version 3) einige Updates; es zeichnet sich ab, dass die 3er-API auf lange Sicht die momentan mehrheitlich genutzte API in Version 2 verdrängen wird. Noch zwingen die Entwickler ihre Anwender aber nicht zu einer Entscheidung, die alte API wird in Icehouse ohne Einschränkung weiter funktionieren, auch wenn sie als “deprecated” markiert ist. Ob das bedeutet, dass die alte API im Juno-Release rausfliegt, steht allerdings noch nicht abschließend fest.

 Eine andere Änderung ergibt sich in Hinblick auf das Thema Sicherheit: Bis jetzt hatten die von Keystone ausgestellten Tokens eine Gültigkeit von 24 Stunden. In Icehouse gilt ein Authentifizierungstoken nur noch für eine Stunde. Die OpenStack-eigenen Komponenten lassen sich im Zweifelsfall durch Keystone einfach ein neues Token ausstellen. Wer allerdings um Keystone herum eigene Zusatzsoftware in seinem Setup verwendet, sollte sicherstellen, dass diese mit der kürzeren Gültigkeit von Tokens auch wirklich zurechtkommt.

 Cinder erhält wie so oft während der letzten Releases neue Treiber und für die bereits vorhandenen Treiber einige Updates: HPs MSA 2040-SAN lässt sich in Zukunft ebenso mit Cinder nutzen wie eine ganze Reihe zusätzlicher QoS-Parameter bei HP 3PAR-Storages und Speicherlösungen von SolidFire. Den FibreChannel-Support, der bereits in Grizzly Einzug hielt, haben die Developer so aufgebohrt, dass er nun auch das Zoning von FibreChannel-Storages direkt aus OpenStack heraus beherrscht.

Orchestration mit Heat aufgebohrt

Der Orchestration-Dienst Heat ist erst seit der letzten Version Teil von Open­Stack. Während viele Beobachter der ersten Version von Heat noch eine gewisse Unreife unterstellen, erhält der Dienst die meisten Neuerungen in Icehouse. So gibt es nun die Möglichkeit, für ein Template einen “Service”-Typ festzulegen. Die Autoren von Heat-Templates haben so die Wahl, ob sie generische Templates anbieten oder von vornherein festlegen wollen, dass ein Template für den Einsatz mit einem spezifischen Dienst vorgesehen ist. Für OpenStack ist das von großer Bedeutung, weil immer mehr Komponenten spezifische Dienste anbieten: Trove ist für DBaaS zuständig, Sahara soll Hadoop as a Service liefern. Entsprechend vorgefertigte Templates erleichtern es Admins, Heat für diese Dienste effektiv zu nutzen.

 Hinzu kommt eine Template-Schnittstelle für Heat: Ziel ist es, Heat je nach Kundenwunsch dynamisch um Funktionen zu erweitern, wobei der Kunde durchaus auch selbst in der Lage sein soll, Plug-Ins in Heat zu installieren. Die Heat-Engine soll laut einhelliger Entwickler-Meinung lediglich eine kleine Zahl von Grundfunktionen bieten. Dazu gehört das Starten oder Stoppen von VM-Umgebungen (“Stacks”) oder die automatische Netzwerkkonfiguration dieser virtuellen Systeme. Wer andere Funktionen automatisieren will, dem steht die Plug-In-Funktion von Heat zur Verfügung.

Bild 3: Heat war eine der großen Neuerungen in OpenStack Grizzly. In Icehouse haben die Entwickler die Orchestrierungslösung massiv erweitert.

Auch im Heat-Kern sind einige Template-Funktionen hinzugekommen. So erlaubt das “Software-Configuration”-Framework über ein standardisiertes Format die Konfiguration einzelner Dienste zu bestimmen, die innerhalb der Heat-VMs laufen. Die Design-Entscheidung deutet darauf hin, dass die “kleine Zahl von Grundfunktionen” in den Augen der an Heat beteiligten Entwickler deutlich über das bloße Starten und Stoppen von VMs hinausgehen wird. Interessant wird in Zukunft die Frage werden, wo hier die Grenze liegt: Welche Funktionen allgemein genug sind, um zum Kern von Heat zu gehören, und welche Funktionen in Plug-Ins auswandern.

 Etwas verwirrend beschreiben die Heat-Entwickler in ihrem Changelog das “Adopt”-Feature: In Icehouse wird es für einen Nutzer möglich sein, über einen laufenden Heat-Stack die Kontrolle aufzugeben, sodass ein anderer Nutzer den Stack quasi übernehmen kann. Das soll die Verwaltung von VMs vereinfachen und dynamischer gestalten.

 Bei Ceilometer fanden indes die meisten Änderungen statt, ohne dass Nutzer davon unmittelbar betroffen sind. Zugegeben: Ceilometer werkelt im Hintergrund und fungiert als Buchhalter der Cloud; Nutzer kommen höchstens über das Dashboard mit der Software unmittelbar in Verbindung. In Icehouse ist es den Entwicklern trotzdem gelungen, interessante Features einzuführen. So versteht Ceilometer nun Performance-Daten, die VMwares vCenter ausgibt. Zwar dürfte die Zahl der Open­Stack-Clouds mit VMware-Hypervisoren derzeit noch sehr überschaubar sein, wer diese Kombination aber bereits einsetzt, erhält in Icehouse mit Ceilometer eine vollständige Metering-Applikation. Wer aus einer eigenen App heraus die Ceilometer-Datenbank abfragt, kann in Zukunft deutlich besser über Filter bestimmen, welche Ergebnisse anzuzeigen sind. Denn Ceilomter erhält in Icehouse einen neuen Filter-Parser, der auch mit komplexen Regular Expressions zurechtkommt.