Wer sich Open QRM nähert, sollte sich allerdings ein wenig Zeit nehmen, um die Philosophie zu verstehen. Open QRM treibt den Virtualisierungsansatz auf die Spitze, indem es das Setup weitestgehend von physischen und virtuellen Ressourcen im Netzwerk abkoppelt. Sein Appliance-Modell versteht physische Rechnersysteme und virtuelle Maschinen als Ressourcen, um Dienste im Netzwerk bereitzustellen. Eine Appliance besteht demzufolge aus den folgenden Komponenten:

• Ressource (physisch oder virtuell)
• Betriebssystem
• Image eines vorkonfigurierten OS-Containers (Root-Filesystem,
  Kernel, Applikationen)
• SLA für Cloud-Setup: Anzahl CPUs, Menge an Memory und
  Plattenplatz

Die Abstraktion des mit der Appliance realisierten Dienstes erlaubt es Open QRM, die zugrunde liegenden Subsysteme als Objekte zu behandeln.

Klone

Übers Cloning gelingt Admins das schnelle Aufsetzen und Ausrollen neuer Systeme, die Provisionierung erfolgt dabei automatisiert mit LVM-Snapshots. Die Basis stellt eine transparente Integration von Virtualisierungstechnologien. Open QRM unterstützt die Hypervisoren Xen, KVM, VMware Server 1 und 2 sowie ESX, zudem Citrix Xen Server und Virtualbox, ab der nächsten Release laut Roadmap auch LXC-Container.

Open QRM beherrscht zudem eine Vielzahl an Storagetechnologien, etwa NFS, I-SCSI, SAN sowie die Anbindung verbreiteter Herstellersysteme wie Dell Equallogic, ZFS oder Netapp. Über einen modularen Aufbau delegiert es die Steuerung und Verwaltung aller Ressourcen und Komponenten an Plugins, zum Beispiel auch die Unterstützung für einen bestimmten Hypervisor oder für eine Storage-Appliance, beispielsweise Netapp Filer. Solche Plugins kann aufgrund der offenen Architektur auch die Community bereitstellen.

Hochverfügbar und absolut Enterprise-tauglich

Open QRM adressiert insbesondere den geschäftskritischen Einsatz von Ressourcen und setzt daher auf die Integration von Hochverfügbarkeits-Funktionen direkt in seiner Architektur. Es überwacht kontinuierlich alle Dienste und startet diese in einem anderen Container neu, falls die entsprechende Ressource ausfällt. Dabei spielt es für das HA-Plugin keine Rolle, ob eine überwachte Appliance physischer oder virtueller Natur ist. Bei Bedarf kann beispielsweise ein physischer Server mittels der integrierten P2V-Technik auch automatisch in einer virtuellen Maschine neu starten.

Interessant ist die Fähigkeit zum N-zu-1-Failover: Für eine größere Anzahl von physischen oder virtuellen Systemen braucht der Admin nur einen Standby-Host bereitzuhalten, auf den Open QRM im Fehlerfall automatisch umschaltet. Ab Version 4.7 muss dieser noch nicht einmal eingeschaltet sein. Weil das neue Out-of-Band-Managementmodul ihn notfalls via Wake on LAN (WOL) oder IPMI (Intelligent Platform Management Interface) weckt, lässt sich der Stromverbrauch der Gesamtumgebung stark reduzieren.

Für die Hochverfügbarkeit des Open-QRM-Managementservers selbst muss der Admin allerdings von Hand sorgen, etwa durch den Einsatz von Linux-HA und der doppelten Absicherung der verwendeten MySQL-Datenbank.

Aufgrund des zentralisierten Storage-Ansatzes und des durchgängigen Thinprovisioning lassen sich Backups der gesamten Umgebung leicht mit der Synchronisation der LVM-Snapshots auf entsprechenden Backupsystemen durchführen. Die Restores kann der Admin als Deployment des entsprechenden Snapshots in einer separaten Appliance ausführen.

Für einen schnellen Test reicht ein einfaches Setup auf einem einzelnen Server. Ein ausführliches Howto [24] dazu sowie die Open-QRM-Doku [25] liefern gute Anleitungen. Bei der Vorbereitung sollte der Admin darauf achten, dass kein DHCP-Server im Netz ist, der auf die PXE-Bootrequests der Open-QRM-Appliances antwortet, sonst booten die virtuellen Maschinen nicht.

Massenbetrieb: Install once, deploy many

Als Basisserver kann ein aktuelles Ubuntu in der Minimalinstallation herhalten. In diesem sind die Bridgetools zu installieren und eine Bridge auf »eth0« zu konfigurieren. Außerdem bedarf es eines Storagebereichs, der sich am einfachsten auf Basis von NFS aufbauen lässt. Wer bei dieser Gelegenheit schon eine LVOL-Group anlegt, spart sich später diese Arbeit. Als Nächstes installiert der Admin einen MySQL-Datenbankserver sowie KVM für die Hypervisordienste.