Orchestrierung in der Cloud

Die zweite neue Komponente in Havana ist Heat ( Abbildung 2 ). Heat wird alle Admins in Verzückung versetzen, denen Automatisierung und Orchestrierung von Bedeutung sind, denn letztlich ist Heat ein Spezialwerkzeug, mit dem sich aufwendige Tasks in OpenStack per Template vollständig automatisch umsetzen lassen. Die Idee hinter der Technik ist dabei keinesfalls neu. Denn schon in Amazons Public Cloud gibt es ein ganz ähnliches Werkzeug, das dort den Namen Amazon CloudFormation trägt. Wozu lässt sich die Lösung einsetzen?

Abbildung 2: Das Dashboard bildet die durch Heat hinzugekommenen Features in Havana bereits an.

Das Prinzip der Automatisierung ist beim Cloud Computing ja im Grunde omnipräsent: Die ganze Idee hinter der Einführung von Lösungen wie der OpenStack-Umgebung ist es, mit möglichst wenig Aufwand möglichst große Erträge zu erzielen. Die Zeit, die Anbieter in die Wartung investieren, soll kleiner werden. Für die tatsächliche Infrastruktur der Cloud funktioniert das auch prächtig; ist OpenStack einmal eingerichtet, klicken Benutzer sich nach Lust und Laune die Dienste zusammen, die sie in der Cloud brauchen. Nachdem bei typischen Cloud-Kunden der Wunsch im Raum steht, auch komplexe IT-Setups in die Cloud zu verlagern, kann es aber einige Zeit dauern, bis die passende Konfiguration erstellt ist. An dieser Stelle tritt AWS-CloudFormations auf den Plan: Der Ansatz hier ist, auch den Nutzern Automatisierung zu bieten, damit diese sich ganze Computing-Umgebungen innerhalb der Cloud binnen Sekunden anlegen können.

Technisch ist das Ganze über sogenannte Templates gelöst. In diesen legen die Cloud-Anwender die Parameter fest, die ihre Computing-Umgebung in der Cloud genauer beschreiben.

Nutzbare Parameter

Im Beispiel von OpenStack kommt genau hier Heat ins Spiel: Heat versteht das AWS-CloudFormations-Template und konstruiert eine digitale Computing-Umgebung anhand der Admin-Vorgaben.

Die Zahl der Parameter, die sich für die Automatisierung durch Heat festlegen lassen, ist beeindruckend. Grundsätzlich definiert der Admin zunächst einen Namen für die Computing-Umgebung. Ebenso kann er auch bestimmen, wieviele virtuelle Server Teil der Umgebung sein sollen und welche Dienste auf diesen Servern laufen sollen. Pro VM muss klar sein, welches Betriebssystem-Image zum Einsatz kommt. Sollen einzelnen VMs Sonderrollen zukommen (beispielsweise als Loadbalancer oder auch als Firewall), dann ist das selbstverständlich konfigurierbar. Dienste wie Clustering zwischen einzelnen VMs sind bei Bedarf ebenfalls über Heat einzurichten. Falls spezifische lokale Einstellungen nach dem Start notwendig sind, lassen sich auch beliebige Shell-Befehle direkt aus einem Heat-Template heraus ausführen. Sogar Firewall-Regeln für die einzelnen VMs lassen sich einstellen, sodass jedes virtuelle System von Anfang an mit den passenden Zugangsberechtigungen ausgestattet ist.

Der Lohn der Mühe besteht in jeder Menge Zeit, die ein Admin sich im weiteren Verlauf seiner Arbeit erspart. Will er eine Webserver-Plattform aus Loadbalancern und Webservern starten, klickt er das entsprechende Template an und hat nach einigen Sekunden eine fertige Umgebung. Heat tut sogar noch mehr und überwacht im weiteren Verlauf automatisch, dass das Setup – wie vom Admin festgelegt – funktioniert. Per Template lassen sich Lastgrenzen festlegen, die nicht überschritten werden dürfen. Falls doch, löffelt Heat die Suppe aus und startet automatisch zusätzliche Ressourcen nach ( Abbildung 3 ). Im Grunde erweitert Heat OpenStack also um horizontale Skalierung automatischer Art für die laufenden VMs. Fallen VMs nach dem Absturz eines Hypervisor-Knotens aus, würde Heat zudem auch das merken und automatisiert Abhilfe schaffen.

Abbildung 3: Anhand der Computing-Karte lässt sich darstellen, wie eine mit Heat gemanagte Umgebung gerade aussieht.

Im Innern von Heat

Heat besteht einerseits aus der »heat-engine« , die die Arbeit im Hintergrund macht; dazu gesellt sich die API-Komponente »heat-api« und »heat-api-cfn« (für AWS-CloudFormations, das Heat, wie erwähnt, neben dem eigenen Template-Format auch beherrscht). Dann gibt es auch noch »heat« , einen Kommandozeilen-Client, mit dem sich Heat direkt steuern lässt. Admins werden typischerweise ein Template schreiben und in Heat dann mit »heat« einfügen. Das Schreiben der Templates ist im Übrigen der lästige Teil der Arbeit mit Heat. Doch sind die Templates da, ist die Arbeit mit dem Dienst eine echte Freude. Sowohl für Heat als auch für Ceilometer gebühren den OpenStack-Entwicklern definitiv steil aufgerichtete Daumen.