© gregeperson, photocase.com

An Hooks, also an Haken, können trittsichere Open-Nebula-Anwender ihre Shellprogramme einklicken, die bei Statusänderungen virtueller Maschinen automatisch Aktionen auslösen. Der Berg ruft.

Virtualisierung hat die Schlagzahl beträchtlich erhöht – mit KVM, Xen, VMware & Co. stellt der Admin neue Systeme viel schneller bereit, als sich neue Hardware in den Zeiten dedizierter Server beschaffen ließ. Die gewonnene Zeit bringt der nun für viel mehr Systeme Verantwortliche mit dem Klonen von Image-Konfigurationen, dem Kopieren von Verzeichnissen und dem Mounten von Speicherressourcen zu. Richtig knifflig wird es, wenn die Hardware nach Wartung ruft, denn dann gilt es, virtuelle Maschinen herunterzufahren, zu verschieben und neu zu starten.

Wer die Schwemme an Handgriffen reduzieren will, greift zu einer Infrastructure-as-a-Service-Lösung (IaaS). Sie nimmt sich der wichtigsten Aufgaben der Servervirtualisierung an, verwaltet Basisinfrastruktur wie DNS und DHCP und stellt dem Admin eine Weboberfläche zur Verfügung. Mit Open Stack [1], Open QRM [2], Eucalyptus [3] oder Ganeti [4] darf der Systemverwalter aus Open-Source-Produkten unterschiedlicher Herkunft und Funktionsumfangs und mit jeweils eigenen Konzepten wählen.

Wegen der Verschiedenartigkeit abzudeckender Einsatzszenarien gebärden sich die meisten Cloudstacks aber komplex und erfordern eine langwierige Einarbeitung. Dass bei normalen Anforderungen der Benutzer auch schneller vorangehen kann, will das aus Spanien stammende Open Nebula [5] beweisen.

Schlanke Cloudverwaltung aus Spanien

Die Software verbrachte ihre Kindheit im akademischen Elternhaus des Grid Computing, mittlerweile gilt sie als leichtgewichtige Enterprise-Lösung [6]. Der amerikanische Teilchenbeschleuniger Fermilab verwaltet damit mehrere Hundert virtuelle Maschinen, auf industrieller Seite listet das Projekt unter anderem Telefonica und Akamai als Anwender. Die Hauptentwickler von C12G Labs bieten kommerziellen Support an und bauen derzeit ein internationales Partnernetzwerk auf [7].

Open Nebula zeichnet sich durch schlichte Eleganz aus. Wo andere IaaS-Wettbewerber vom Admin fordern, ein halbes Dutzend Dienste und Komponenten zu installieren und zu konfigurieren, kommt Open Nebula mit wenigen Komponenten und nur einem Frontend zum Steuern und Konfigurieren der eigenen Cloud aus, dem Open Nebula Sunstone. Der Kasten “Installation” skizziert die Inbetriebnahme, Abbildung 1 die Architektur.

Abbildung 1: Open-Nebula-Admins steuern ihre Cloud hauptsächlich über die Oberfläche Sunstone im Webbrowser. Das Frontend wiederum verbindet sich per API mit dem Open Nebula Server, der seinerseits die Virtualisierungshosts steuert. Open Nebula fordert von seinen Hosts nur einen laufenden SSH-Server.

Installation

Das Projekt Open Nebula liefert fertige Pakete für eine ganze Reihe von Distributionen aus, darunter für Centos, Arch und Gentoo. Um es unter Open Suse zu starten, fügt Root zusätzlich zum Packman-Repository die Paketquellen des Projekts hinzu und installiert die Software:

zypper addrepo --no-gpgcheck --refresh  -t YUM http://opennebula.org/repo/openSUSE/12.3/stable/x86_64 opennebula
zypper refresh
zypper install opennebula
zypper install opennebula-sunstone

Für Debian und Ubuntu gibt es ein Tar-Archiv mit mehreren angepassten Debian-Paketen, von denen der Admin »opennebula-common« und »libopennebula-ruby« sowie deren Abhängigkeiten installiert. Das Tutorial [8] hilft kompetent weiter, sollten allfällige Ruby-Warnungen den Installationsprozess aufhalten.

Die Installation legt den Linux-Benutzer »oneadmin« an, der mit gleicher UID auch auf allen Compute-Nodes existieren muss, die Open Nebula auch Hosts nennt. Außer einem laufenden Open-SSH-Server braucht der Systemverwalter dort keine Software zu installieren. Er stellt nur sicher, dass der öffentliche SSH-Schlüssel des Benutzers »oneadmin« in den »authorized_keys« des gleichen Accounts auf allen Compute-Nodes vorhanden ist und sich der Clouddienst damit überall einzuloggen vermag.

Hypervisor-agnostische Virtualisierung

Noch fehlt die Virtualisierungssoftware auf den Hosts, denn sie ist nicht Teil von Open Nebula. Der IaaS-Stack kennt aber die meisten Hypervisoren, darunter KVM, Xen sowie VMware, und steuert auch die Libvirt an.

Auf dem Frontend hat die Installationsroutine unter »~oneadmin/.one/one_auth« einen Anwendungsaccount angelegt. Als »oneadmin« startet der Systemverwalter nun den Open-Nebula-Server mit dem Kommando »one start« und prüft mit »onevm list« , ob er ohne Fehlermeldungen das interne API des Servers erreicht. Um an das Webfrontend von beliebigen Hosts aus zu gelangen, fügt er die gewünschte IP-Adresse oder den Eintrag

:host = 0.0.0.0

in die Konfigurationsdatei »/etc/one/sunstone -server.conf« ein. Ohne weitere Änderungen bindet sich Sunstone (Abbildung  2) nur an Localhost und ist nach »sunstone-server start« unter »http://localhost:9869/« zu erreichen. Bei Problemen prüft der Admin »/var/log/one/sunstone.log« und das zugehörige Errorfile im selben Verzeichnis.

Übrigens laufen nur auf dem Frontend Dienste dauerhaft: Zu Open Nebulas Verwaltungsserver verbinden sich der Scheduler, der gegebenenfalls virtuelle Maschinen von einem Host auf einen anderen verschiebt, die Weboberfläche Sunstone und das API, über das Entwickler per OCCI- oder EC2-API Zugriff auf die Cloudfunktionen erlangen. Auf den Hosts selbst arbeitet außer den VMs und dem Open-SSH-Server kein Dienst auf Dauer.

Abbildung 2: Das Dashboard zeigt oben wichtige Systemparameter, darunter eine einfache Monitoring-Ansicht von Hosts (links) und virtuellen Maschinen (rechts). Über die Menüleiste (links) erzeugen und verwalten Administratoren – auf Wunsch auch Anwender – die Systeme der Open-Nebula-Cloud.

Versionen und Features

Open Nebula nennt seine Releases nach interstellaren Nebeln. Die im Mai 2013 veröffentlichte stabile Version 4.0 taufte das Projekt “Eagle” – nach dem rund 7000 Lichtjahre entfernten Adlernebel, einem Mitte des 18. Jahrhunderts entdecktem Sternenhaufen. Gegenüber der rund zwei Jahre älteren 3.x-Linie kamen Bugfixes und vor allem eine Runderneuerung der Weboberfläche Sunstone dazu. Die betraf zum Beispiel den VNC-Zugriff auf virtuelle Maschinen.

Die neueste Version 4.2 mit dem Codenamen “Flame” erschien Anfang August 2013. Der namengebende Flammennebel liegt im Sternenbild Orion, sein Licht benötigt rund 1000 Jahre bis zu uns. Die Macher des Projekts haben die Bedienung der Sunstone-Oberfläche für Flame etwas rundgeschliffen. Neu ist eine vereinfachte Ansicht, die sich explizit an Anwender wendet, die nur eine VM provisionieren und nicht den ganzen Cluster einrichten möchten. Admins können nun die Größe der Images besser beobachten und eingreifen, falls eine VM aus dem Ruder zu laufen droht. Dazu monitort Open Nebula neuerdings diese Ressource.

Ganz neu haben die Entwickler das Backend für die VMware-Virtualisierung geschrieben, die sich nun einfacher installieren lässt und weniger Abhängigkeiten besitzt. Der Xen-Treiber nutzt neuerdings die XL-Funktionen von Version 4.0 des Hypervisors.

Unter Open-Nebula-Anwendern hat sich die Praxis etabliert, in Testumgebungen die neueste Version der Features wegen zu benutzen, für den Produktivbetrieb jedoch die vorletzte Version. Die im Folgenden beschriebenen Programmierschnittstelle existierte zwar schon in der 3er Version, ihre ganze Funktionalität entfaltet sich aber erst mit der 4.0.

Am Hook

Ein wichtiger Grund, Server zu virtualisieren, ist das Streben nach Automatisierung. Hat die eigene Entwicklungsabteilung beispielsweise per CI-Server Jenkins [9] eine neue Release für ihre PHP-, Perl-, Ruby- oder Java-Anwendung gebaut, so kann sie automatisch eine Stage-VM mit den notwendigen Paketen und Frameworks erzeugen. Hat die beauftragende Fachabteilung die Anwendung getestet und freigegeben, reicht dem Admin im besten Fall ein Klick, um die zugehörigen Ressourcen wieder freizugeben.

In den Hochglanzbroschüren zum Thema Cloud Computing bleibt unerwähnt, dass hier die Tücke im Detail steckt. Denn oft ist es nötig, in der einen virtuellen Maschine ein Datenbankschema zu aktualisieren oder in einer anderen einen besonderen Dienst zu starten. Open Nebula stellt zum Glück für solche Aufgaben so genannte Hooks bereit [10]. Bei vielen Gelegenheiten ruft die Software damit externe Programme auf, die der Admin in der Programmier- oder Skriptsprache seiner Wahl verfassen darf.

Nachhaken bei Ereignissen

Das Grundprinzip: Wenn ein Open-Nebula-Anwender erfahren möchte, ob sich etwas bei einer virtuellen Maschine, einem Host, den konfigurierten Netzen, Benutzern, Gruppen oder Images ändert, schaltet er ein eigenes Skript in die Abarbeitungsreihenfolge ein. Seine Tools legt er im Verzeichnis »/var/lib/one/remotes/hooks« ab (bei Debian »/var/lib/opennebula/remotes/hooks« ).

Um festzulegen, auf welche Ereignisse er reagieren möchte, sucht sich der Cloudverwalter das auslösende Objekt und Ereignis aus Tabelle 1 oder 2 heraus und trägt es in »/etc/one/oned.conf« ein. Listing  1 registriert beispielsweise das Shellskript aus Listing  2, um die aktive Laufzeit der VMs zu messen.

Das »VM_HOOK« -Konstrukt darf in der Konfiguration mehrfach auftauchen. Auf welches Ereignis Open Nebula reagiert, legt der Parameter »on« fest (Listing  1, Zeilen 3 und 9). Der Eintrag »commands« spezifiziert das aufzurufende Skript, »arguments« einen String, der seine Übergabeparameter enthält. Wie Kenner sofort an der Syntax sehen, ist die IaaS-Verwaltung selbst in Ruby verfasst. Bei der Sprache eigener Skripte bleibt dem Admin jedoch die freie Wahl.

Das Shellskript aus Listing  2 prüft in den Zeilen 5 bis 9, ob die VM läuft, und verzeichnet zusammen mit der VM-ID in Zeile 24 einen Unix-Epoch-Zeitstempel im konfigurierbaren Logfile. Mit einem Awk-Skript, das sich Logfiles vornimmt und Werte parst, ließe sich daraus die Gesamtlaufzeit jeder VM leicht ermitteln und beispielsweise in der Fakturierungssoftware einer Abteilung oder eines Kunden der IaaS-Cloud weiterberechnen.

01 VM_HOOK = [
02     name      = "vm_einschalten",
03     on        = "RUNNING",
04     command   = "account.sh",
05     arguments = "on $ID" ]
06
07 VM_HOOK = [
08     name      = "vm_ausschalten",
09     on        = "STOP",
10     command   = "account.sh",
11     arguments = "off $ID" ]
12 [...]

01 #!/bin/bash
02
03 ACCOUNTING=/var/log/one/accounting.log
04
05 case "$1" in
06     "on"|"off")
07         mode=$1
08         shift
09         ;;
10      *)
11         echo "$0 error: wrong mode." >&2
12         exit 1
13         ;;
14 esac
15
16 if [ "$1" = "" ]
17 then
18     echo "$0 error: ID missing." >&2
19 fi
20
21 id=$1
22 shift
23
24 echo "$id $(date +%s) $mode" >> $ACCOUNTING

Die $TEMPLATE-Variable

Das Beispiel übergibt Parameter nur auf eine sehr einfache Weise. Mehr Informationen über die betroffenen Ressourcen erlangt der Anwender, wenn er den Inhalt der Variablen »$TEMPLATE« an das Skript weiterreicht. Sie speichert in einer Art XML-Dialekt eine Vielzahl von Details über die VM, das Netz oder das Speichersystem. Um nicht mit einem externen XML-Parser ganz großes Geschütz auffahren zu müssen, liefern die Entwickler ein Werkzeug mit, das die Inhalte in handliche Key-Value-Paare zerlegt und ausfiltert. So liefert das Bash-Fragment

X=/var/lib/one/remotes/datastore/xpath.rb
mem=$($X -b $template HOST_SHARE/MAX_MEM)

den Inhalt des Containers von »<HOST_SHARE><MAX_MEM>« unterhalb des Wurzelknotens. In diesem Feld verschickt Open Nebula den Wert für verfügbaren Gesamtspeicher auf dem Virtualisierungshost, Listing  3 zeigt als Beispiel ein ganzes Bündel an Werten.

01 <HOST>
02   <ID>1</ID>
03   <NAME>one-sandbox</NAME>
04   <STATE>2</STATE>
05   <IM_MAD>kvm</IM_MAD>
06   <VM_MAD>qemu</VM_MAD>
07   <VN_MAD>dummy</VN_MAD>
08   <LAST_MON_TIME>1377716985</LAST_MON_TIME>
09   <CLUSTER_ID>-1</CLUSTER_ID>
10   <CLUSTER/>
11   <HOST_SHARE>
12     <DISK_USAGE>0</DISK_USAGE>
13     <MEM_USAGE>65536</MEM_USAGE>
14     <CPU_USAGE>10</CPU_USAGE>
15     <MAX_DISK>0</MAX_DISK>
16     <MAX_MEM>502568</MAX_MEM>
17     <MAX_CPU>100</MAX_CPU>
18     <FREE_DISK>0</FREE_DISK>
19     <FREE_MEM>259512</FREE_MEM>
20     <FREE_CPU>87</FREE_CPU>
21     <USED_DISK>0</USED_DISK>
22     <USED_MEM>243056</USED_MEM>
23     <USED_CPU>12</USED_CPU>
24     <RUNNING_VMS>1</RUNNING_VMS>
25   </HOST_SHARE>
26   <VMS>
27     <ID>16</ID>
28   </VMS>
29   <TEMPLATE>
30     <ARCH><![CDATA[x86_64]]></ARCH>
31     [...]
32   </TEMPLATE>
33 </HOST>

Monitoring als Hauptanwendung

Diese einfache Schnittstelle bietet vielfältige Möglichkeiten: Über den Umweg des Pollens von Log- oder Statusdateien lässt sich etwa ein bestehendes Verfügbarkeitsmonitoring wie Nagios oder Zabbix einbinden. Alternativ bringt Open Nebula mit Ganglia [11] selbst ein einfaches Performance-Monitoring mit, womit der Systemverwalter die wichtigen Systemparameter wie CPU-Last oder freien Speicher im Auge behält.

Wer sich an das »CREATE« -Event einer VM anhängt, kann die Monitoring-Agentensoftware per Konfigurationsmanagement gleich mitinstallieren oder eine fertige Anwendung per Continous-Integration-Trigger ausrollen. Sowohl Puppet, Chef & Co. als auch Jenkins bieten dafür Schnittstellen, die der Admin mit Wget oder Curl anzusteuern im Stande ist.

Ein- und Ausblick

Eine eigene private Open-Nebula-Cloud baut der Systemverwalter mit vergleichsweise wenigen Handgriffen auf. Im einfachsten Fall benötigt er bloß zwei Systeme, eine Managementkonsole mit Webzugriff und einen Virtualisierungshost. Wegen seiner gut handhabbaren und offenen Schnittstellen lässt sich das modulare Open Nebula erweitern. Das gelingt – wie im Artikel beschrieben – mittels Hooks, die sich in wichtige Systemereignisse einklinken.

Darüber hinaus stellt die IaaS-Verwaltung Interessierten eine Reihe weiterer APIs bereit: Mittels so genannter Treiber können sie ähnlich einfach neue Hypervisoren einbinden. Über EC2- oder OCCI-Konnektoren (Oracle C++ Call Interface) steuert der Wolkenkapitän das Hoch- und Herunterfahren seiner virtuellen Anwendungen. Der Admin legt Speicherressourcen zwar von Hand an und verwaltet seine VLANs selbst, erhält dafür aber mit Open Nebula eine private Cloud, die transparent und nachvollziehbar über den Himmel zieht.