Physische und virtuelle Ressourcen im Data Center in einer zentralen Konsole zu verwalten, ist der Ansatz des Open-Source-Systems openQRM.
Andrej Radonic (freier Autor in Köln und Verfasser des Buchs Xen 3.2)
IT als Service zu etablieren hat durch den Mega-Trend Cloud-Computing einen neuen starken Schub erfahren. Um ungeklärten Fragen bei Datensicherheit und Datenschutz aus dem Weg zu gehen, beschäftigen sich Unternehmen derzeit vor allem mit dem Aufbau privater Clouds. Hierfür bedarf es ausgefeilter und umfassender Werkzeuge, welche die Ressourcen des Datacenter durchgängig verwalten und gebündelt als Services bereitstellen können.
openQRM dient sich hier als ausgereifter Vertreter aus der Opensource-Szene an. Es handelt sich dabei um eine zentralisierte Management-Lösung, deren Wurzeln aus dem Datacenter-Ressourcemanagement stammen. openQRM vereinheitlicht und automatisiert die Administration physischer Server sowie virtueller Maschinen in einer übergreifenden Web-Managementkonsole. Es ermöglicht die flexible Verteilung und Verwaltung von Workloads und Ressourcen und integriert dabei eine beachtliche Zahl von Mainstream-Virtualisierungslösungen wie VMware ESX / ESXi / Server1 / Server 2, Citrix XenServer, Opensource Xen sowie KVM in einer einheitlichen Konsole.
Lesen Sie mehr zum Thema Virtualisierung
Backup-Tools für virtuelle Server
Einsatz-Szenarien umfassen dabei klassische Konsolidierung durch Virtualisierung, automatisiertes bedarfsgesteuertes Deployment von Server- oder Desktop-Systemen bis hin zur Realisierung von public oder private Clouds. Gute Skalierbarkeit und Hochverfügbarkeit in Verbindung mit Automatisierung sind dabei integrale Systembestandteile.
Alles ist ein Dienst
openQRM realisiert dies, indem es weitgehend von den zugrundeliegenden physischen und virtuellen Ressourcen abstrahiert. Das Modell behandelt physische Rechnersysteme und virtuelle Maschinen gleichermaßen als „Appliances“, mit denen sich Dienste im Netzwerk bereitstellen lassen. Eine openQRM-Appliance besteht aus den Komponenten:
-
Ressource (physisch oder virtuell)
-
Betriebssystem
-
Image eines vorkonfigurierten OS-Containers (Root-Filesystem, Kernel, Applikationen)
-
SLA für Cloudsetup: Anzahl CPUs, Menge an Memory und Plattenplatz, usw.
Entscheidender Vorteil dieses Ansatzes ist die völlige Abstraktion des mit der Appliance bereitgestellten Dienstes von den zugrundeliegenden Subsystemen. Damit lässt er sich als Objekt behandeln und durch Cloning ein schnelles Aufsetzen und Ausrollen neuer Systeme realisieren.
Grundlage für dieses Modell ist die Flexibilität im Umgang mit dem Speicher. openQRM unterstützt eine Vielzahl an Storagetechnologien, wie NFS, iSCSI, SAN sowie die Anbindung verbreiteter Herstellersysteme wie Dell Equallogic, ZFS oder Netapp.
Der konsequent modulare Aufbau sieht vor, dass die Steuerung und Verwaltung aller Ressourcen und Komponenten an Plugins deligiert wird, wie die Unterstützung für einen bestimmten Hypervisor (z.B. XenServer) oder für eine bestimmte Storage-Appliance (z.B. Netapp filer). Plugins können aufgrund der offenen Architektur auch von der Community bereitgestellt werden und lassen sich mit nur einem Kommando in das openQRM-Setup integrieren.
Enterprise-tauglich
Die besondere Eignung von openQRM für kritische Umgebungen resultiert aus der konsequenten Integration von Hochverfügbarkeit (HA) in dieser Architektur. openQRM überwacht kontinuierlich automatisch 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 gestartet werden.
Interessant ist dabei die Fähigkeit zum N-zu-1 Failover: für eine größere Anzahl von physischen oder virtuellen Systemen muss dabei lediglich ein Standby-Host bereitgehalten werden, auf den im Fehlerfall automatisch umgeschaltet wird. Dafür muss dieser nicht einmal eingeschaltet sein – über das Out-of-Band Managementmodul kann ein solcher Rechner von openQRM via WOL oder IPMI „geweckt“ werden. Damit läßt sich der Stromverbrauch der Gesamtumgebung auf ein Minimum reduzieren.
Aufgrund des zentralisierten Storage-Ansatzes und der konsequenten Verwendung von Thinprovisioning können Backups der gesamten Umgebung leicht mittels der Synchronisation der LVM-Snapshots auf entsprechende Backup-Systeme durchführt werden. Restores lassen sich bei Bedarf als Deployment des entsprechenden Snapshots in einer separaten Appliance ausführen.
Installation
Für einen ersten schnellen Test lässt sich openQRM problemlos auf einem einzelnen Server einrichten. Ein ausführliches Howto sowie die openQRM-Doku liefern dazu gute Unterstützung.
Die einzelnen Komponenten lassen sich selbstverständlich auf mehreren Servern einrichten. Ein typisches Production Setup umfasst 4 plus n physische Rechnersysteme:
-
2 für openQRM-Server (HA Setup)
-
1+n Storage-Server
-
1+n Virtualisierungsserver. Diese sollten CPU-seitig über Virtualisierungsunterstützung verfügen (Intel VT, AMD-V)
Als Basis-Server kann ein aktuelles Ubuntu-Linux in der Minimalinstallation mit einigen zusätzlichen Paketen wie bridgetools, MySQL, NFS und KVM als Hypervisor herhalten. Dann ist openQRM selbst an der Reihe: Der openQRM-Kern besteht im Wesentlichen aus Shellscripts sowie PHP-Scripts (für die Web-GUI) sowie den diversen Zusatzpaketen. Wenngleich bei Sourceforge Binärpakete für diverse Distributionen gehostet werden, empfiehlt das Entwicklerteam aufgrund der bei der Entwicklung angewendeten Continuous Integration Methode den Download aus dem SVN-Repo. Nach dem Kompiliervorgang ist ein funktionierendes openQRM-Setup vorhanden. Mit derselben Prozedur lassen sich Updates einer produktiven openQRM-Umgebung direkt aus den Quellen ohne Unterbrechnung des laufenden Betriebs bewerkstelligen.
Unter der Adresse http://localhost/openQRM (User "openQRM“, Passwort "openQRM“) kann sich der Administrator nun anmelden. Er konfiguriert nun noch in einem Assistenten die gewünschte Datenbank. Da bei openQRM alle Funktionen auf Plugins beruhen, sind diese im Dashboard, wo sich eine lange Liste zur Verfügung stehender Plugins findet, zu aktivieren.
Management: Install once, deploy many
Nachdem die Basis damit verfügbar ist, erstellt der Administrator sinnvollerweise eine Appliance für das Hosting von Applikationen, beispielsweise auf Basis von KVM. Dies erfolgt in drei Schritten.
-
Storage bereitstellen, hierfür muss zunächst die entsprechende Storage-Ressource hinzugefügt werden.
-
Anschließend wird das Betriebssystem als logisches Image-Objekt erstellt und selbiges mit Leben befüllt. Am einfachsten geht das mit dem mitgelieferten Werkzeug "image-shelf", über welches das openQRM-Team fertige OS-Templates für gängige Linux-Distributionen bereitstellt.
-
KVM-Host erstellen: Nun ist zunächst noch ein KVM-Host als Appliance zu definieren.
Anschließend kann der Admin seine neue Appliance starten: Sie bootet per PXE über das Netzwerk. Vom als Storage verknüpften Storageserver wird das Bootimage geholt, anschließend wird das Filesystem vom Storage per LVM gecloned und an die Appliance geheftet.
openQRM sieht den Netzwerkboot als Default vor, da auf diese Weise die größte Flexibilität für die Verwaltung und Provisionierung gegeben ist. Auf diesem Wege können beispielsweise massenweise Windows-Workstations aus einem einzigen zentralen „Golden Image“ per SAN-Boot deployed werden.
Über den Wolken
openQRM liefert die Cloudfähigkeit durch sein Design und in Form eines Cloud-Plugins mit. Dieses stellt ein Selfservice-Portal zur Verfügung, über welches Anwender ihre Systeme konfigurieren und das Deployment anfragen können. Ein Abrechnungssystem ist ebenfalls an Bord. Die Schnittstellen sind dabei Amazon-konform (AWS), was eine Migration von Appliances in beide Richtungen einfach macht.
Mit wenigen Klicks kann der Admin sein openQRM-System um Cloud-Fähigkeiten erweitern.
Abbildung: Der visuelle Clouddesigner ermöglicht den openQRM-Anwendern eine schnelle Definition der gewünschten Dienste
In der openQRM-Cloud definiert der Cloud-Admin aus den verfügbaren Komponenten seines Datacenters diejenigen Cloud-Produkte, die der Cloud-Benutzer auswählen kann, wenn er sich über das openqrn-cloudportal seine Appliance zusammenstellt. Anschließend sind die „Cloud Products“ zu erstellen, welche über das Cloud-Portal angeboten werden sollen. Dazu gehört vor allem, den Kernel je unterstütztem Betriebssystem zu definieren und ein „VM-Product“ zu erstellen.
Dann ist noch zu konfigurieren, welche Betriebssystem-Images die Cloud den Cloud-Usern anbieten soll. Zuletzt sind noch die CloudUser zu erstellen, damit diese sich in ihrer private Cloud anmelden können. Nun sind alle Ressourcen sowie die Cloud angelegt und vorbereitet.
Als unter http://localhost/cloud-portal angemeldeter Cloud-Benutzer kann man nun einfach seine Serversysteme mit Hilfe des Visual Cloud Designers im Drag-und-Drop Verfahren zusammenstellen und die Provisionierung beantragen. openQRM kann so konfiguriert werden, dass diese Requests automatisch akzeptiert oder aber manuell zugelassen werden müssen. Der Rest läuft automatisch: der Clouduser kann selber bestimmen, wann welche Appliances laufen und wann sie provisioniert und deprovisioniert werden. Das auf einer eigenen Cloud-Währung („CCU“) basierende Abrechnungssystem ermöglicht die minutengenaue Abrechnung und Ausweisung der genutzten Ressourcen. Der Administrator kann dabei je Ressource die „Kosten“ in CCU definieren. Auf diesem Wege ist ein automatisierter elektronischer Vertrieb von Computingressourcen denkbar, ein Magentoshop-Verkaufsmodul existiert bereits (für zahlende Support-Kunden).
Für die Steuerung und Automatisierung der Cloud existiert eine wohldokumentierte Webservice-API (SOAP).
Lizenzierung und Support
openQRM gibt es ausschließlich in einer „free“ Lizenz und es unterliegt vollständig der GPL. Eine Enterprise-Variante ist seitens der openQRM Enterprise GmbH in Köln nicht vorgesehen. Die Firma versteht sich im Wesentlichen als Haupt-Contributor und Sponsor von openQRM. Angeboten werden Trainings sowie Service und Support. Letzterer ist in drei SLA-Stufen erhältlich (Basic, Standard, Premium), der Einstiegspreis liegt bei 480,- € pro Monat.
Fazit
openQRM überzeugt. Gerade für größere Umgebungen mit geschäftskritischen Diensten kann es seine Fähigkeiten ausspielen durch ein sehr ausgeklügeltes Management, schnelle Provisionierung von Systemen, die durchgehende Unterstützung physischer wie virtueller Ressourcen und die nahtlos integrierten Failover-Fähigkeiten.
Interessant ist zudem das hybride Cloud-Modell, d.h. mit openQRM können Administratoren sowohl private wie auch öffentliche Clouds sowie gemischte Clouds aufsetzen und betreiben. Die verfügbare API sowie der Plugin-Ansatz versprechen eine einfache Erweiterung um gewünschte zusätzliche Funktionalitäten.
Nicht zuletzt vermag auch die Vielfalt bei den unterstützten Virtualisierungs- und Storage-Technologien zu überzeugen, was dem Anwender eine große Freiheit und Flexibilität liefert. Systeme können nicht nur von physikalischen Servern zu virtuellen Maschinen migriert werden (P2V), sondern auch ohne großen Aufwand von virtuellen Maschinen zurück zu physikalischen Servern (V2P) und von Virtualisierungs-Technologie A zu Virtualisierungs-Technolgie B verschoben werden.
Pro
Zentrale Webkonsole und einheitliche Managementlösung
Integriertes Failover-System
Umfassende Lösung für Cloud-Bereitstellung
Contra
VLAN-Konfiguration und -Management ist noch nicht automatisiert
(Der Beitrag wurde von der ChannelPartner-Schwesterpublikation Computerwoche übernommen / rb)