Erst Eucalyptus 3 bringt Hochverfügbarkeit

Offensichtlich hatten aber auch die Macher bei Eucalyptus gemerkt, dass der Zustand ohne Hochverfügbarkeitsfunktionen eigentlich untragbar ist, und bei der neuen Version 3 entsprechend nachgebessert. Eucalyptus 3 (Abbildung 2) kommt gewissermaßen frisch aus der Presse – Eucalyptus-CEO Marten Mickos ließ in diversen Interviews im August [13] keinen Zweifel daran, welches Feature sich die Admins und Nutzer von Eucalyptus am dringlichsten gewünscht hatten: Hochverfügbarkeit.

Abbildung 2: Eucalyptus 3 bekommt endlich eine vollständige HA-Lösung: Ähnlich wie bei Open QRM klappt hier künftig das Neustarten von abgestürzten virtuellen Maschinen völlig automatisch.

Und darum haben die Entwickler wohl auch einige Arbeit in das Thema HA gesteckt: Eucalyptus 3 verspricht seine eigenen Komponenten wie die verschiedenen Controller innerhalb des Eucalyptus-Universums redundant auszulegen. Außerdem unterstützt der Node Controller in Kombination mit dem Cluster Controller jetzt Notfallaktionen: Merkt der CC, dass ein Knoten nicht mehr zur Verfügung steht, streicht er ihn – wie bisher – aus der Cloud.

Anders als in Version 2 stellt Eucalyptus 3 auch fest, welche Cloud-Dienste auf dem just ausgefallenen Knoten liefen, und startet sie deshalb jetzt auf einem anderen Node neu.

Open QRM

Der dritte Bolide im Test ist Open QRM, und schon auf den ersten Blick zeigen sich im Vergleich mit Eucalyptus und Open Stack sehr deutliche Unterschiede. Während die beiden letzten ausdrücklich als Framework für Cloud Computing daherkommen, will Open QRM mehr sein als das. Die Suite bezeichnet der Hersteller vollmundig als "Data-Center Management Platform" und legt damit die Messlatte reichlich hoch: Mit Open QRM sollen sich die Abläufe eines gesamten Rechenzentrums umfassend kontrollieren und steuern lassen, inklusive des Einrichtens von virtuellen Domains für Kunden und des Betriebs der VMs über Hardware-Ausfälle hinweg.

Der Dreh- und Angelpunkt einer Open-QRM-Architektur ist der zentrale Server, dessen Administrationsinterface die Wolke verwaltet (Abbildung 3). Die Administration der Storage-Einheiten, die Open QRM zur Verfügung stehen, erledigt der Admin hier. Ebenso legt er in diesem GUI fest, welche virtuellen Maschinen es gibt und welche Netzwerkverbindungen diese miteinander haben.

Abbildung 3: Die Abstraktion spiegelt sich bei Open QRM nur zum Teil im Interface für Admins – das ist wohl besser so: KVM anlegen klingt eindeutiger als Virtualisierungsressource anlegen.

Der Kern von Open QRM ist modular aufgebaut. In einem schlanken Framework sind integriert: Konfigurationsplugins für diverse Aufgaben, ein Modul für Storage-Verwaltung, eines für Monitoring, eines für das Provisioning und sogar ein Modul, das sich explizit um Hochverfügbarkeit kümmert. Die einzelnen Plugins greifen ineinander und führen die Tasks durch, die der Administrator per Browser in Auftrag gibt.