Abstraktion extrem

Ein gewisses Maß an Abstraktion gehört bei Cloudlösungen fest dazu. So ist es für den Endanwender, der eine virtuelle Maschine für einen bestimmten Zweck braucht, völlig irrelevant, woher der Speicher für diese VM kommt, auf welchen Festplatten innerhalb der Cloud seine Daten lagern und wie das Netzwerk funktioniert. Es zählt nur, ob die Cloud die erwartete Leistung bringt.

Open QRM führt die Abstraktion auch im Konfigurationsinterface ein. Zwar müssen Admins noch immer festlegen, an welchem Speicher eine mit Open QRM realisierte Virtualisierungslösung sich bedient und auf welchen Nodes die virtuellen Maschinen starten, aber das Open-QRM-Webinterface bietet dafür vielfältige Werkzeuge und eine eigene Logik.

Unter der Haube kombiniert der so genannte Storage Abstraction Layer alle zur Verfügung stehenden Storage-Devices zu einfachen Speicherpools. Er sorgt dafür, dass Programme und Werkzeuge innerhalb des Open-QRM-Universums stets mit den gleichen Befehlen auf Speicherplatz zugreifen können. Somit ist es letztlich egal, ob der Speicher-Zugriff auf ein per I-SCSI angebundenes SAN oder ein DRBD-Laufwerk auf einem Storage-Cluster erfolgt: In Open QRM sieht jeder Speicherplatz gleich aus, was gerade für die Automatisierungsfunktionen an Bedeutung gewinnt.

Die Abstraktion gilt übrigens nicht nur im Hinblick auf denStorage, sondern auch für virtuelle und echte Geräte. Alle Dienste in Open QRM betrachtet das Management-Center einfach als Ressourcen. Nicht-virtualisierte Systeme lassen sich mithin genauso als Ressource verwalten wie virtuelle Maschinen (siehe Abbildung 4).

Abbildung 4: Open QRM setzt verstärkt auf Abstraktion. Alles ist entweder ein Storage oder eine Ressource. Das zahlt sich schnell aus, vor allem beim automatischen Start abgestürzter VMs.

Bootservice

In unmittelbarem Zusammenhang mit der Steuerung von Computersystemen steht der Open-QRM-Bootservice. Der Dienst wirkt auf den ersten Blick wie eine Nebensache, ist aber eminent wichtig: Von ihm erfahren physikalische und virtuelle Systeme, welches System sie booten sollen. Indirekt sorgt er dafür, dass aus Systemen überhaupt erst Ressourcen im Open-QRM-Sinne werden. Der Bootservice wird aktiv, wenn auf einem System ein bestimmtes Software-Image deployt werden soll. Er erfüllt aber auch eine wichtige Rolle, wenn physikalische oder virtuellle Maschinen ein neues System booten sollen.

Fällt eine Instanz unter Open QRM aus, dann bleibt das dem eingebauten Monitoringsystem, einem internen Nagios 3 (Abbildung 5), nicht verborgen. Um dessen Konfiguration braucht der Admin sich nicht zu kümmern: Es landet zusammen mit Open QRM automatisch auf dem zentralen Server und ist für Open QRM gleich passend konfiguriert. Wesentlich angenehmer als bei einem reinen Nagios gestaltet sich das Hinzufügen neuer Hosts: Per Mausklick erweitern Admins die Konfiguration, sodass das Monitoring neue Hosts in Sekundenschnelle erfasst und überwacht.

Abbildung 5: Open QRM hat Nagios 3 eingebaut, nimmt aber dem Admin viel lästige Konfigurationsarbeit ab.

Aber Open QRM kann auch etwas unternehmen, wenn eine Ressource etwa nach dem Ausfall einer Hardwarekomponente nicht mehr funktioniert. Hier greift das Abstraktionsmodell: Nach Lage der Dinge reanimiert Open QRM die abgestürzte Ressource entweder auf anderer Hardware, wandelt sie unmittelbar in ein physikalisches System um oder – und das ist durchhaus beachtlich – bootet mittels IPMI (Intelligent Platform Management Interface, eine Schnittstellensammlung zur Wartung und Administration von Rechnern, [14]) einen zusätzlichen Server, um die Ressource dort zu starten (siehe Abbildung 6).

Abbildung 6: Hochverfügbarkeit im Webinterface einstellen, das kann nur Open QRM mit dem HA-Manager-Plugin. Wer das mit IPMI kombinieren will, braucht aber die Enterprise-Variante.