© Vitalik Pakhnyushchyy, 123RF.com

Für firmenweite Virtualisierung und fürs Cloud Computing: SLES 11 SP1, Univention UCS, Ubuntu Enterprise Cloud und Open QRM stellen sich einem Vergleich.

Heute im Unternehmen eine Linux-Maschine als Gastgeber für die virtuelle Herde aufzusetzen ist nicht mehr schwer. Doch beim Management hat der Admin die Qual der Wahl. Die Bandbreite freier Lösungen reicht von einfachen, KVM- oder Xen-fähigen Enterprise-Distributionen bis zu umfangreichen Cloud-Management-Tools, die die eigene private oder öffentliche Wolke verwalten.

Im folgenden Artikel testet das Linux-Magazin vier verschiedene Ansätze: Von SLES 11 über die ins Firmen-Directory integrierte Univention-Debian-Distribution und Ubuntus Enterprise Cloud bis zu Open QRM reichen die Kandidaten. Ihre Fähigkeiten beweisen mussten die Produkte auf einem modernen Multicore-Server von Thomas Krenn (siehe Kasten “Test-Hardware”). Ohne Hardwarevirtualisierung in der CPU geht da schon länger nichts mehr.

Wie die Tabelle 1 mit den wichtigsten Ergebnissen zeigt, unterstützen alle in diesem Artikel betrachteten Virtualisierungssysteme mindestens die führenden Open-Source-Hypervisoren KVM und Xen. Die meisten nutzen für das Management der VM-Umgebung Libvirt als zugrunde liegende Schnittstelle.

Univention und Suse vertreten den typischen Ansatz der klassischen, vollständig integrierten Distributionen, während die Ubuntu Enterprise Cloud und Open QRM eher den stärker abstrahierenden Managementansatz der Cloud repräsentieren und ein wenig Einarbeitung in die Philosophie der Entwickler voraussetzen. Hier ist der Hypervisor nur noch Mittel zum (Hosting-)Zweck. Vor allem das komplett freie Open QRM hat da einiges an Features zu bieten und steht den kommerziell vermarkteten Produkten in nichts nach.

Tabelle 1: Vier Virtualisierungsmanager im Vergleich

Novell Suse Enterprise Linux

War SLES 2006 noch einer der Xen-Pioniere, so beschleicht den Tester beim Anblick der 2010er Ausgabe des SLES 11 [1] mit dem aktuellen SP1 das Gefühl, der Innovationsmotor sei zum Stehen gekommen. So ist zwar inzwischen auch KVM offiziell und gleichberechtigt mit an Bord, gerade beim Management hat sich aber recht wenig getan. Alle Cloud-Ambitionen sind dem System sogar völlig fremd. Vielleicht hilft ja der von Novell kurz vor Redaktionsschluss veröffentlichte Cloud Manager weiter [2], der sich in die diversen Managementkonsolen der Hypervisoren einklinkt und so laut Hersteller beliebige, auch heterogene Wolken managen kann.

Die Installation von SLES 11 geht Suse-typisch leicht vonstatten. Stutzig macht zunächst, dass Xen und KVM gleichzeitig installiert werden dürfen, auch wenn der gleichzeitige Betrieb nicht möglich ist. Das altbekannte Yast dient sich mit dem Reiter »Virtualisierung« zu VM-Management-Zwecken an, jedoch beschränken sich diese auf einen Installationsassistenten sowie den auch von anderen Distributionen bekannten »virt-manager« (Abbildung 1). Der ist inzwischen recht brauchbar, er offenbart reichlich Konfigurationsoptionen bis hin zur Anpassung von Storage, CPU sowie Peripheriekomponenten und ermöglicht das übliche Lifecycle-Management bis hin zum Erstellen von Klonen.

Abbildung 1: Suse integriert den Virt-manager in Yast, hier die Konfigurationsoptionen für eine virtuelle Maschine.

Wer schon Mitte des Jahrzehnts Suse eingesetzt hat, wird sich gleich wohlfühlen, auch weil die Verwaltung einheitlich und unabhängig vom gerade eingesetzten Hypervisor gestaltet ist. Leider merkt man KVM den Nachrücker-Status an, zum Beispiel am Fehlen jedweder Dokumentation. Die von Xen dagegen ist Suse ausgesprochen gut gelungen und auch sehr ausführlich.

Xen 4

Unter der Haube steckt viel Gutes. Admins schätzen SLES für seine Stabilität. Umso bemerkenswerter ist, dass in der SP1-Ausgabe sehr frische Komponenten zum Einsatz kommen. So ist Suse als eine der wenigen großen Distributionen bereits mit Xen 4.0 ausgestattet. Der Xen-Admin profitiert damit von interessanten Neuerungen dieser Version [3], zum Beispiel höherer Leistung vor allem bei Ein-/Ausgabe-intensiven Workloads durch die Unterstützung von SR-IOV (Single Root I/O Virtualization) und SR-ATS (Single Root Address Translation Services).

Virtuelles Windows

Wenn Windows-Workloads im Vordergrund stehen, spielt Suse den Vorteil der mitgelieferten Virtual Machine Driver Packs aus. Diese paravirtualisierten Treiber beschleunigen den Betrieb aller wichtigen Windows-Versionen. Vergleichbares gibt es nur bei anderen kommerziellen Produkten, beispielsweise bei Red Hat und Citrix Xen Server.

HA-Optionen sind bei SLES 11 nur in Form diverser bekannter Pakete wie DRBD mit an Bord, die der Admin unabhängig von der Virtualisierungslösung aufsetzt und konfiguriert. Mit SP1 kam jedoch die Suse Linux High Availability Extension (ehemals HA-Cluster Manager) zur Produktfamilie, ein Managementsystem zum Aufbau von HA-Clustern mit physischen und virtuellen Maschinen.Es bietet Monitoring, Failover sowie Echtzeit-Replikation mittels DRBD.

Einen Ressourcen-Agenten gibt es bislang jedoch nur für Xen, nicht für KVM. Auf Datacenter-Ebene gibt es aus der Platespin-Reihe das Produkt Platespin Orchestrator (ehemals ZEN Works Orchestrator, [4]) für das Management und die Provisionierung der Workloads physischer und virtueller Maschinen.

SLES 11 ist bekanntermaßen ein recht massiges System. Für den, der möglichst schlanke virtuelle Maschinen betreiben möchte, hat sich Novell Jeos [5] ausgedacht, ein Just Enough Operating System. Das ist im Grunde ein verschlanktes Suse, für dessen optimierte Erstellung Tools wie Kiwi [6] existieren. Das Jeos von Suse Linux Enterprise ist eine anpassbare Minimalkonfiguration von SLES, die lediglich ein bootfähiges Image bereitstellt, das für VMware und OVF mit 32- und 64-Bit-x86-Images formatiert ist.

Wer es gerne bunt mag, für den geht gerade Suse Studio [7] an den Start. Hier kann der Administrator, wie in Abbildung 2 zu sehen, virtuelle Maschinen auf Basis verschiedener Betriebssysteme interaktiv zusammenstellen, im Browser vorab testen und diese dann herunterladen oder mit anderen teilen.

Abbildung 2: Mit Suse Studio lassen sich Open-Suse-VMs im Browser erstellen und konfigurieren.

Arbeitstier

SLES ist ein Virtualisierungs-Arbeitspferd und erweist sich als stabil und zuverlässig. So ist es beispielsweise von SAP zertifiziert für den virtualisierten R3-Betrieb. Darüber hinaus bietet sich dem Admin auch die Wahlmöglichkeit zwischen den führenden Hypervisoren an.

Sehr fair ist auch Novells Support-Policy: Der Hersteller supportet alle offiziell zugelassenen Microsoft-Gastbetriebssysteme. Für performanteren Windows-Betrieb gibt es spezialisierte Windows-Treiber – vielleicht die Frucht der engen Kooperation mit Microsoft. Insgesamt ist SLES aufgrund der eingeschränkten Tools und des Fehlens mächtiger Werkzeuge für das Management sowie integrierter HA- und Failover-Lösungen eher für kleinere Umgebungen und Single-Server-Setups geeignet.

Univention UCS

Der gerade in der neuen Version 2.4 (Abbildung 3) erschienene Univention Corporate Server (UCS, [8]) ist ein auf Debian beruhendes Linux, das vor allem in mittelständischen Unternehmen und Behörden zum Einsatz kommt. Mit der Univention Management Console (UMC) bringt es ein modular aufgebautes Web-GUI für die zentrale Verwaltung von Servern, Diensten, Clients, Desktops und Benutzern. Zu den wichtigsten Eigenschaften von UCS zählt die LDAP-basierte Domänenverwaltung mit dem UCS-Managementsystem und dem darauf aufsetzenden Univention Directory Manager.

Abbildung 3: Neu in Version 2.4 ist der Univention Virtual Machine Manager (UVMM), hier mit Zugriff auf eine VM mittels VNC. Die Features sind noch überschaubar, aber stabil.

Dieses System bildet einen Single Point of Administration für das Identity- und Infrastrukturmanagement. Gleichzeitig bietet es zahlreiche Schnittstellen zur Integration anderer Systeme, beispielsweise über einen Konnektor zu Microsofts Active Directory.

Mit der Version 2.4 ist nun erstmals der Univention Virtual Machine Manager (UVMM, Abbildung 4) verfügbar, ein in die UMC integriertes Modul zur Verwaltung der gesamten Virtualisierungsinfrastruktur in einer UCS-Umgebung. Die Distribution made in Bremen stellt dafür wahlweise Xen oder KVM bereit.

Abbildung 4: Univentions Virtualisierungs-Managementmodul bei der Steuerung der VMs.

Die Installation erfolgt per menügeführtem Text-Installer und funktioniert sowohl interaktiv als auch unbeaufsichtigt. Für die Verwendung des UVMM installiert der Admin ein UCS-System in einer der Systemrollen Domaincontroller (DC) Master, DC Backup, DC Slave oder Memberserver. Es dient als physischer Server für die Virtualisierung.

Die erste UCS-Systemrolle in der UCS-Domäne sollte immer ein DC Master sein. Auf dem installiert der Sysadmin per Default das UCS-Managementsystem (Univention Directory Manager und Infrastrukturkomponenten wie Open LDAP, PKI, Kerberos und DNS-Server). Alle anderen UCS-Server- und Desktop-Systemrollen mit Ausnahme des UCS-Basissystems treten dann bei ihrer Installation dem Vertrauenskontext der UCS-Domäne bei. Um die Virtualisierungskomponenten zu installieren, wählt der Admin bei der Software-Auswahl: »Virtual Machine Manager (UVMM)« und »Xen Virtualisierung Server« (oder KVM) aus [9].

Nach der Installation bietet das UCS-System per Browser eine Übersicht der Funktionen und Administratorwerkzeuge an, erreichbar unter [https://server]. Die Anmeldung zu diesen Werkzeugen erfolgt als Benutzer »Administrator« mit dem während der Installation vergebenen Passwort für Root. Der UVMM findet sich dabei als Unterpunkt in der Univention Management Console wieder. Er läuft als Dienst und sammelt automatisch die notwendigen Informationen über die physischen Server für die Virtualisierung und stellt sie übersichtlich im UCS-Managementsystem dar.

Einheitliches Management

In der UMC absolviert der Administrator seine Verwaltungstätigkeiten grafisch, beispielsweise Dienste steuern, Systemauslastungen prüfen oder Konfigurationsparameter ändern. Die im Univention Directory Manager (UDM) angelegten Objekte speichert das System im Open-LDAP-Verzeichnisdienst und repliziert sie auf die anderen UCS-Systeme in der UCS-Domäne. UDM bietet auch eine Kommandozeilen-Schnittstelle.

Über den UVMM lassen sich alle physischen Hosts, die Teil der UCS-Domäne sind, in einer Übersicht erfassen, verwalten sowie auf ihnen virtuelle Maschinen installieren. Dabei ist wie bei SLES dank Libvirt das Management völlig einheitlich gestaltet, unabhängig davon, ob als Hypervisor Xen oder KVM zum Einsatz kommt. UCS 2.4 unterstützt als Gäste alle wesentlichen Windows-Varianten sowie natürlich UCS selbst und alle verbreiteten Linux-Distributionen.

Ein Zugriff auf die Konsole der virtuellen Maschinen ist direkt aus dem Browser per VNC-Java-Applet möglich. Wer einen zentralen Storage eingerichtet hat, (NFS oder I-SCSI), migriert mit nur einem Klick in UVMM einzelne VMs live zu einem anderen Host.

Im Assistenten des UVMM reichen wenige Schritte, um eine neue Instanz anzulegen:

• Zunächst bestimmt der Admin Basisparameter wie CPU, RAM
  oder HDs.
• Dann erstellt er ein virtuelles CD/DVD-Laufwerk und wählt
  das Installationsimage.
• Im vierten Schritt definiert er virtuelle Festplatten, wobei
  der Installer Swap-Bereiche selbstständig anlegt und
  verwaltet.
• Jetzt lässt sich die VM erstmals starten und die
  Betriebssysteminstallation per VNC durchführen.

Windows-VMs kann der Admin aus ISOs installieren, die er aus dem DVD-Installationsmedium generiert hat. Die Abbilder müssen dabei unter »/var/lib/libvirt/images« liegen, damit die UMC sie beim Erstellen neuer VMs unter dem Punkt »Vorhandenes Laufwerk« anzeigt.

UVMM integriert sich nahtlos in die Univention-Managementkonsole. Die Verwaltung virtueller Maschinen auf Basis von Xen oder KVM ist einheitlich gelöst und geht leicht von der Hand. Die Management-Tools lassen sich einfach bedienen, offenbaren jedoch noch kleinere Schwächen. So fehlen zahlreiche Komponenten, die ein Admin gewöhnlich in Virtualisierungslösungen vorfindet. Wer mit UCS Windows virtualisieren möchte, sollte aus Performance-Gründen zu KVM greifen. Die für Xen notwendigen beschleunigenden Treiber für Windows fehlen dem Xen-Fan.

Erstlingswerk

Man sieht Univentions System das Erstlingswerk an einigen Stellen an. Zu rudimentär sind noch einige Features, sie beschränken sich auf die üblichen Lifecycle-Funktionen sowie die Installation virtueller Maschinen. Import, Export, erweiterte Storage-Optionen, zum Beispiel Snapshots oder Cloning, sucht man vergeblich. Die Storage-Verwaltung erfolgt standardmäßig in Form von Imagedateien. Thinprovisioning oder andere von LVM bekannte Funktionen stehen somit nicht zur Verfügung.

Wer Migration nutzen möchte, braucht von Hand aufgesetzten NFS- oder I-SCSI-basierten Storage. Besonders Admins von geschäftskritischen Setups werden eine HA-Infrastruktur vermissen. Daher erscheint die Lösung zum jetzigen Zeitpunkt eher geeignet für kleinere Umgebungen mit wenigen VMs. Jedoch hat der Hersteller für 2011 hierzu Erweiterungen angekündigt.

Dem eigenen Anspruch jedenfalls, mit VMware und Xen Server vergleichbar zu sein, wird das System nicht gerecht. Aber die Anfänge sind vielversprechend und vermutlich darf man noch einiges aus der Bremer Softwareschmiede erwarten. Für bestehende UCS-Kunden sowie Virtualisierungs-Einsteiger darf der UVMM jedoch als eine schlanke und sofort nutzbare Lösung gelten, zumal Univention die Kunden mit passenden Updates versorgt, sodass eine lauffähige Umgebung langfristig gewährleistet ist.

Wer sich nicht mit dem Hypervisor-Setup herumschlagen möchte und Wert auf eine grafische VM-Verwaltung legt, findet in UCS eine schöne Alternative zu anderen Linux-Distributionen. Zudem dient sich UCS als virtualisierte Plattform für das Hosting verschiedener großer Open-Source-Applikationspakete an. So sind auch diverse Enterprise-Produkte wie Scalix, Zarafa, Open Xchange, SEP und weitere für den UCS-Betrieb zertifiziert.

Ubuntu Enterprise Cloud

Ubuntus Enterprise Cloud (UEC, [10], [11]) ist eine Serverplattform zum Aufbau und Betrieb von Private oder Public Clouds. Aufbauend auf der aktuellen Ubuntu-10.04-Serverplattform erhält der Anwender die Open-Source-Software Eucalyptus (Elastic Utility Computing Architecture Linking Your Programs To Useful Systems, [12]) in Version 2.0 als Ubuntu-Paket. Diese aus einem universitären Projekt hervorgegangene Software wird zum einen als Service von dem gleichnamigen Start-up betrieben und steht darüber hinaus für RHEL, Cent OS, Open Suse und Fedora zur Verfügung. Im Kern kann Eucalyptus verschiedene Hypervisoren verwenden, um Systeme in der Cloud laufen zu lassen: Eucalyptus bevorzugt zwar Xen, Ubuntu sieht jedoch KVM als Default vor. In der kommerziellen Eucalyptus-Variante ist als Motor auch VMware verfügbar.

UEC geht mit seinem Cloud-Computing-Ansatz deutlich über klassische Server-Virtualisierungslösungen wie SLES oder Univention hinaus: Rechner-, Speicher- und Netzwerkressourcen bündelt das System und stellt sie transparent für das Hosting virtueller Maschinen bereit. Die Workloads lassen sich dabei elastisch verwalten, inklusive dynamischer Zuweisung von IP-Adressen und Rechnerressourcen, nachträglicher Erweiterung von Speicher und vielem mehr.

Eine Besonderheit von UEC/Eucalyptus ist dabei die weitgehende Kompatibilität zum Cloud-Computing-Pionier Amazon [13]: Alle wesentlichen Steuerungskommandos (EC2) sowie das Storage-Format (S3) sind kompatibel, sodass jederzeit ein nahtloser Übergang von Amazon zur eigenen Wolke und zurück möglich ist. UEC/Eucalyptus besteht aus mehreren Server- und Steuerungskomponenten. Grundsätzlich unterscheidet das System zwischen der zentralen Steuerung einerseits und den Nodes andererseits, auf denen die eigentlichen VMs laufen und die die Wolke ausmachen. Eucalyptus spricht hier von “Instances”.

uecadmin@uec:~$ sudo euca_conf --get-credentials mycreds.zip
uecadmin@uec:~$ unzip mycreds.zip
uecadmin@uec:~$ ln -s eucarc .eucarc

uecadmin@uec:~$ sudo euca_conf --register-nodes 192.168.10.226

uecadmin@uec:~$ euca-describe-availability-zones verbose
AVAILABILITYZONE    cluster1        192.168.10.169
AVAILABILITYZONE    |- vm types     free / max   cpu   ram  disk
AVAILABILITYZONE    |- m1.small     0021 / 0024   1    192     2
AVAILABILITYZONE    |- c1.medium    0021 / 0024   1    256     5
AVAILABILITYZONE    |- m1.large     0009 / 0012   2    512    10
AVAILABILITYZONE    |- m1.xlarge    0009 / 0012   2   1024    20
AVAILABILITYZONE    |- c1.xlarge    0003 / 0006   4   2048    20

Die Steuerung beinhaltet Cloud Controller (CLC), Cluster Controller (CC) sowie den Storage Controller (SC), die in einer hierarchisch aufgebauten Architektur verwoben sind (Abbildung 5). Jeder Node gehört zu einem Cluster, jeder Cluster gehört zu einer Cloud. Der CLC verwaltet die Cloud, der CC den Cluster.

Abbildung 5: Die Architektur der Ubuntu Enterprise Cloud mit Cluster, Cloud, Storage und Node Controller.

Die Ubuntu-Variante von Eucalyptus fügt dem System einen Image-Store hinzu: Das Walrus-Speichersystem [14] kann ein lokales Repository von Images oder VMs verwalten. Darauf erhält das Cloud-System dynamischen Zugriff, um VMs zu provisionieren.

Ein typisches Setup fasst die Controller auf einem Rechner zusammen, der dann das so genannte Frontend bildet. Sämtliche Komponenten lassen sich aber auch auf einzelnen Rechnern betreiben, wobei die Nodes auf dedizierten Rechnern laufen, die Hardware-seitig allerdings über Unterstützung für die Virtualisierung (also Intel VT oder AMD SVM) verfügen müssen.

Teilweise wolkig

Praktischerweise erfolgt die Cloud-Installation direkt im Hauptmenü des Ubuntu-Installationsprogramms (Abbildung 6). Das macht es dem Admin einfach, die Basis aufzusetzen: Auf dem Frontend-Rechner richtet er UEC als Controller mit allen nötigen Komponenten ein. Der Installer erfragt dabei vor allem, welche IP er verwenden, welchen IP-Adressenbereich er den Nodes bereitstellen und welche Steuerungskomponenten (Controller) er auf dem System einrichten soll. Auf allen Nodes erfolgt die Installation über denselben Menüpunkt »Node controller«. Im Anschluss ist die Webadministration unter der IP des Controllers auf Port 8443 zu erreichen.

Abbildung 6: Ein Ubuntu-Server installiert auf Wunsch die benötigten Controller für Cloud, Storage, Cluster und Nodes.

Aber das Bild trügt: UEC suggeriert mit dem Installationsprozess eine Einfachheit, die das ganze Prozedere in der Praxis nicht hat. Insbesondere die eigentliche Inbetriebnahme der Nodes kann sich als Hürde erweisen. Die sollten eigentlich mit einem einzigen Kommando im entsprechenden Cluster registriert und damit nutzbar sein. Aber zum einen muss dazu deren Networking richtig konfiguriert sein, dafür passen die Voreinstellungen des Installers aber nicht immer. Zum anderen wollen die durchaus sinnvollen Security-Komponenten richtig aufgesetzt sein: Alle Steuerungskommandos sichert UEC über X509-Zertifikate. Diese gilt es, im System zu registrieren und richtig anzuwenden, kein triviales Thema.

Richtig vernetzt

Besonderes Augenmerk sollte der Planung des Netzwerk-Setups gelten: UEC kennt vier Netzwerkmodi (»SYSTEM«, »STATIC«, »MANAGED« und »MANAGED-NOVLAN«). Dabei sehen »SYSTEM« und »STATIC« einen bereits im Netz vorhandenen DHCP-Server vor. Die Managed-Varianten dagegen verteilen IP-Adressen mit einem eigenen Server in der Cloud. Hier ist dafür zu sorgen, dass keine Konflikte mit im LAN vorhandenen DHCP-Diensten auftreten.

Zudem sollte der Administrator darauf achten, in der Eucalyptus-Konfigdatei »/etc/eucalyptus/eucalyptus.conf« den gleichen Netzwerkmodus einzustellen wie auf dem Controller, damit das System zusammenspielt. Die recht gute Doku [15] sowie der Eucalyptus Beginner’s Guide [16] helfen hier zuverlässig über die schwierigsten Klippen hinweg.

Ist ein erster Node eingerichtet und rebootet, geht die Wolke in Betrieb (siehe Kasten “Unter UEC einen Node in Betrieb nehmen”). Vorher empfiehlt es sich aber zu prüfen, ob alle Dienste laufen und miteinander kommunizieren. Die Datei »/var/log/eucalyptus/registration.log« sollte entsprechende positive Meldungen enthalten.

Images im Store

Ubuntu möchte es dem Administrator einfach machen und bietet im Webinterface auf dem Reiter »Store« eine Reihe fertig vorbereiteter Images zum Download an. Per Klick lädt er diese herunter und legt sie automatisch im UEC-Storage ab. Anschließend kann er sich das Kommando anzeigen lassen, mit dem er das Image als VM startet, zum Beispiel »euca-run-instances -k mykey emi-DFE11073«. Später zeigt »euca-describe-instances« den VM-Status:

uecadmin@uec:~$ euca-describe-instances
RESERVATION r-47FB07CB admin default
INSTANCE i-4A060949 emi-39D4160B 192.168.
10.172 192.168.10.242 running mykey 0
 m1.small 2010-07-23T16:14:21.737Z
 cluster1 eki-AE9517D0 eri-17361927

Jeder Administrator wird aber früher oder später seine eigenen Images erstellen und betreiben wollen. Ein Eucalyptus-Image besteht aus den Komponenten VM-Image (»*.img«), einem Xen-kompatiblen Pärchen aus Kernel und Ramdisk (»xen-kernel[…]vmlinuz*« und »xen-kernel[…]initrd*«) oder einem entsprechenden KVM-kompatiblen Pärchen.

Die in einem Bundle zusammengefassten Bestandteile landen per Upload im Storage (Abbildung 7). Anschließend registriert der Admin das Bundle im Cluster-Controller. Leider muss er diesen Vorgang für jeden Bestandteil (VM-Image, Kernel, Ramdisk) auf der Kommandozeile einzeln durchführen.

Abbildung 7: Die Webadministration der Ubuntu Enterprise Cloud zeigt die Eucalyptus-Verwandtschaft.

Management

Los geht es anschließend endlich mit dem Kommando zum Start:

uecadmin@uec:~$ euca-run-instances -k mykey
 --kernel eki-AE9517D0 --ramdisk
 eri-17361927 emi-39D4160B

Grundsätzlich sind mehrere Wege vorgesehen, um die Dienste und VMs in der Wolke zu verwalten: Der vollständige Funktionsumfang ist (nur) über die Amazon-kompatiblen Euca2ools [17] erreichbar, die Bestandteil des Eucalyptus-Pakets von UEC sind. Ein GUI bietet die Firefox-Extension Elasticfox (Abbildung 8, [18]) oder alternativ deren sehr ähnlicher Fork Hybridfox [19]. Die eigene Cloud lässt sich zudem über Tools von Drittanbietern registrieren und managen: Landscape von Canonical [20] als gehostete oder lokale Edition sowie Right Scale [21].

Abbildung 8: Mit einem GUI, das einer lokalen Anwendung gleicht, verwaltet der UEC-Admin seine Instanzen einer Cloud im Firefox-Browser über das Plugin Elasticfox.

Das Konzept ist faszinierend: Ubuntu liefert mit UEC und Eucalyptus eine vollständige Plattform für Cloud Computing, kostenlos und quelloffen. Der Betrieb erweist sich als stabil und das System lässt sich sehr gut skalieren. Durchaus vorstellbar, dass dieses Modell künftig auch in Unternehmen Schule machen könnte. Als Pluspunkt darf dabei die weitgehende Kompatibilität zu Amazons Produkten EC2/S3 zählen, die eine Migration in beiden Richtung zu einer einfachen Aufgabe macht und damit auch die Zukunftssicherheit fördert.

Sammelsurium

Trotzdem: Ob das System derzeit für mehr als Test- und Evaluierungszwecke taugt, scheint zweifelhaft. Lediglich die Kommandozeilentools sind vollständig, der Rest – inklusive Web-GUI Elasticfox oder Hybridfox – stellt eher ein Sammelsurium dar als eine vollständige, einheitliche und integrierte Managementumgebung. Hier muss Canonical noch deutlich nachbessern, um gerade im Vergleich mit den großen Server-Virtualisierungslösungen von Citrix, Red Hat und VMware Stand halten zu können.

Für den Enterprise-Betrieb selbstverständliche Sicherheitsmechanismen für Failover oder High Availability fehlen komplett und müssten von Hand im System aufgesetzt werden. Die Storage-Architektur EBS ist aus Anwendersicht zwar interessant, erinnert aber aus Administrator-Perspektive an eine Blackbox. Insgesamt ist der Ansatz dennoch vielversprechend und zeigt, in welche Richtung das Cloud Computing out of the Box gehen kann.

Open QRM

Ganz oben auf der Abstrahierungsleiter steht mit Open QRM [22] ein umfangreiches Management-Framework, das sichtbar aus dem Datacenter-Ressourcenmanagement stammt. Es vereinheitlicht und automatisiert die Administration physischer Server sowie virtueller Maschinen in einer übergreifenden Management-Webkonsole und erlaubt die flexible Verteilung und Verwaltung von Workloads und Ressourcen. Ziel ist das automatisierte Deployment physischer und virtueller Systeme bis hin zu den darin gehosteten Applikationen in einer skalierbaren, hoch verfügbaren öffentlichen, privaten oder hybriden Cloud.

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.

Dann ist Open QRM an der Reihe: Wenngleich Sourceforge Binärpakete für diverse Distributionen hostet, empfiehlt das Entwicklerteam den Download aus dem SVN-Repository [26] mit anschließendem Kompilieren aus den Quellen. Open QRM besteht im Wesentlichen aus Shell- und PHP-Skripten (für das Web-GUI) sowie diversen Zusatzpaketen.

Online-Update

Mit demselben Prozedere sollen Updates einer produktiven Open-QRM-Umgebung direkt aus den Quellen ohne Unterbrechung des laufenden Betriebs möglich sein. Abschließend klappt das erste Login per Webbrowser unter der Adresse [http://localhost/openqrm] mit dem User »openqrm« (Passwort »openqrm«). Der Admin konfiguriert nun noch in einem Assistenten die Datenbank.

Da bei Open QRM alle Funktionen auf Plugins beruhen, sind diese noch im Dashboard (Abbildung 9) zu aktivieren, in dem sich eine lange Liste mit Plugins findet. Für den Anfang genügen: »cloud«, »dhcpd«, »image-shelf«, »kvm«, »lvm-storage« und »tftpd«. Die einzelnen Komponenten lassen sich selbstredend auch auf mehreren Servern einrichten. Ein typisches Production-Setup umfasst vier plus n physische Rechnersysteme:

Abbildung 9: Das Dashboard ist der Mittelpunkt von Open QRM und bietet umfangreiche Funktionen.

• Zwei für Open-QRM-Server (HA-Setup)
• 1+n Storage-Server
• 1+n Virtualisierungsserver; diese müssen über CPUs
  mit Virtualisierungs-Unterstützung (Intel VT, AMD V)
  verfügen

Die Einrichtung einer Appliance auf Basis von KVM erfolgt in drei Schritten: Da Storage bei Open QRM genau wie die Appliances auf Ressourcen beruht, muss der Admin zum Reservieren von Speicher zunächst die entsprechende Ressource hinzufügen. Unter »Base | Components | Create | Storage« legt er einen neuen Storage vom Typ »LVM Storage Server (NFS)« an, anschließend wählt er die bei der Installation generierte Volumegroup und legt nach Belieben über den Assistenten neue Volumes an.

Unter »Base | Components | Create | Image« kann der Benutzer nun zunächst leere Images als Ressourcen erstellen, wobei er die gewählten Volumes als Root-Storage wählt. Open QRM erzeugt dabei automatisch aus dem physischen Volume ein logisches Image-Objekt.

Image-Regal

Anschließend bekommen die Image-Ressourcen Leben eingehaucht. Am einfachsten geht das mit dem mitgelieferten Werkzeug »image-shelf«, über das das Open-QRM-Team Betriebssystem-Templates für gängige Linux-Distributionen bereitstellt. Das Plugin erlaubt es, auch eigene Server-Templates in verschiedenen Lokationen (lokal, HTTP, HTTPS, FTP) bereitzustellen.

Der Ablauf ist dabei immer gleich: Ein Shelf (Regal) wählen (zwei sind bereits vorhanden), dort ein Image und schließlich einen geeigneten Storage aus der vorhandenen Liste als Ziel wählen. Danach sind die Volumes mit dem Betriebssystem bevölkert, was ein »ls /vol/ubuntu64/« dokumentiert.

Bis zu diesem Zeitpunkt hat der Open-QRM-Admin Storage und Betriebssystem-Templates angelegt, außerdem hat Image-shelf praktischerweise auch schon die korrekten Kernel für die Betriebssysteme als Ressourcen in Open QRM hinterlegt. Jetzt braucht es noch den passenden KVM-Host. Der definiert sich unter »Base | Components | Create | Ressource«. Der KVM-Host ist dabei ebenfalls als Appliance definiert, wichtig ist hier, beim Ressourcen-Typ die Angabe »KVM-Host« auszuwählen.

Jetzt ist die erste Appliance bereit zum Start. Unter »Plugins | Virtualization | KVM | VM-Manager« wählt der Administrator den KVM-Host und definiert und verwaltet mit »+ VM« virtuelle Maschinen. Hilfreich ist noch das Plugin »SSH-Term«, das eine Ajax-SSH-Konsole in das Web-GUI einbettet, über das Admins grafischen Zugriff auf laufende VMs erhalten.

Beim Start bootet die Appliance per PXE über das Netzwerk. Vom als Storage verknüpften Server holt Open QRM das Boot-Image, anschließend klont es das Filesystem vom Storage per LVM, heftet es an die Appliance und konfiguriert das Netzwerk. Open QRM sieht den Netzwerk-Boot als Default vor, da so 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” deployed werden, per SAN-Boot.

Über den Wolken

Open QRM liefert die Cloud-Fähigkeit durch sein Design und durch das praktische Cloud-Plugin (Abbildung 10) mit. Dies stellt ein Selfservice-Portal zur Verfügung, über das Anwender ihre Systeme konfigurieren und das Deployment anfragen können. Die Schnittstellen sind dabei Amazon-konform (AWS), was eine Migration von Appliances in beiden Richtungen einfach macht.

Abbildung 10: Der visuelle Cloud-Designer ermöglicht den Open-QRM-Anwendern eine schnelle Definition der gewünschten Dienste mit wenigen Mausklicks.

Mit wenigen Klicks lassen sich Open-QRM-Systeme um Cloud-Fähigkeiten erweitern. In der Open-QRM-Cloud definiert der Cloud-Admin aus den Komponenten seines Rechenzentrums die Cloud-Produkte, die der Cloud-Benutzer auswählen kann, wenn er sich über das Open-QRM-Cloud-Portal seine Appliance zusammenstellt. Dazu gehört vor allem, den Kernel für die unterstützten Betriebssysteme zu definieren und ein »VM-Product« zu erstellen. Abschließend konfiguriert der Admin die Images, die die Cloud den Usern anbieten soll, und die Cloud-User selbst.

Drag&Drop-Cloud

Ein unter [http://localhost/cloud-portal] angemeldeter Cloud-Benutzer kann einfach seine Serversysteme mit Hilfe des Visual-Cloud-Designers im Drag&Drop-Verfahren zusammenstellen und die Provisionierung beantragen. Der Rest läuft automatisch: Der Benutzer bestimmt selbst, wann welche Appliances laufen und wann Open QRM sie provisioniert und deprovisioniert. Das auf einer eigenen Cloud-Währung (CCU, Cloud Currency Unit) beruhende Abrechnungssystem weist die genutzten Ressourcen minutengenau aus und rechnet sie ab. Für die Steuerung und Automatisierung der Cloud existiert ein gut dokumentiertes Webservice-API (SOAP).

Open QRM vermag auf ganzer Linie zu überzeugen. Gerade bei größeren Umgebungen mit geschäftskritischen Diensten spielt es seine Fähigkeiten aus. Zu denen gehören ein sehr ausgeklügeltes Management, schnelle Provisionierung von Systemen, die durchgehende Unterstützung physischer wie virtueller Ressourcen und die integrierten Failover-Features.

Interessant ist zudem das hybride Cloud-Modell: Mit Open QRM können Administratoren private und öffentliche Clouds oder auch gemischte Clouds aufsetzen und betreiben. Das verfügbare API sowie der Plugin-Ansatz versprechen eine einfache Erweiterung um gewünschte zusätzliche Funktionalitäten.

Open QRM ist das einzige System im Vergleich, das Failover integriert anbietet und dabei weitgehende Automatisierung zulässt. Zudem liefert es mit dem Web-GUI eine sehr einheitliche und vor allem vollständige Management-Umgebung. Nicht zuletzt vermag auch die Vielfalt bei den Virtualisierungs- und Storage-Technologien zu überzeugen, die dem Anwender eine große Freiheit und Flexibilität liefert. Systeme können nicht nur von physischen Servern zu virtuellen Maschinen migriert werden (P2V), sondern auch von virtuellen Maschinen zurück zu physischen Servern (V2P) und von Virtualisierungs-Technologie A zu Virtualisierungs-Technologie B verschoben werden.

Ganz perfekt ist Open QRM freilich nicht: Es gibt beispielsweise keinen integrierten VNC-Zugriff aus dem Web-GUI auf die Appliances, und die VLAN-Konfiguration und deren Management ist noch nicht automatisiert.

Open QRM gibt es ausschließlich unter der GPL. Eine Enterprise-Variante ist seitens der Open QRM Enterprise GmbH [23] in Köln nicht vorgesehen. Die Firma versteht sich im Wesentlichen als Haupt-Kontributor und Sponsor von Open QRM. Sie bietet dafür Trainings sowie Service und Support. Letzterer ist in drei SLA-Stufen erhältlich (Basic, Standard, Premium), der Einstiegspreis liegt bei 600 Euro pro Monat.

Fazit

Die heutigen Open-Source-Lösungen für Server-Virtualisierung haben für jeden Geschmack und Geldbeutel die passende Antwort, und egal, wie sich der Admin entscheidet, auf kommerziellen Support muss er nicht verzichten.

Den Ausschlag zugunsten eines bestimmten Produkts aus dem Vergleich gibt sicher immer der konkrete Anwendungsfall: Sind im Unternehmen nur wenige Server zu verwalten und gutes Suse- oder Debian-Know-how vorhanden, dann bieten sich SLES und UCS als treue Diener an. Aber auf dem Markt tut sich gerade einiges, auch Konkurrenten wie zum Beispiel die Corebiz Virtual Server Base der LIS AG (Kasten “Corebiz Virtual Server Base”) sind im Auge zu behalten, die mit komplett grafischer KDE-Administration kommen soll.

Corebiz Virtual Server Base

Auch die Linux Information Systems AG (LIS) integriert Virtualisierung in ihr Portfolio: Für die Unternehmensdistribution Corebiz gibt es auf Wunsch ein entsprechendes Managementmodul (Abbildung 11) für KDE. Es ermöglicht mit Hilfe von Luma das Setup und die Verwaltung virtueller KVM-Instanzen. Allerdings ist die Software noch nicht ganz fertig, der Screenshot zeigt eine Preview, die immerhin Status, Storage, Network und andere Konfigurationen einzustellen erlaubt, aber noch viel Handarbeit erfordert. Das Besondere daran: Alle Einstellungen stehen im zentralen LDAP-Verzeichnis, die Administration vollzieht sich aber vollständig in einem Snap-in fürs KDE-Kontrollzentrum. Abbildung 11: Alle Einstellungen im LDAP-Verzeichnis, aber die Konfiguration per Mausklick: So soll die Corebiz Virtual Server Base demnächst an den Start gehen

Wolkig: UEC und Open QRM

Weiter oben in den Wolken sind dagegegen Produkte wie Ubuntus Enterprise Cloud angesiedelt. Ihr gelingt der Spagat zwischen Distributionsintegration und Wolke recht gut, doch an der Flughöhe und Qualität von Open QRM kann sich keiner der anderen Kandidaten messen.Spätestens in Unternehmen, in denen Hochverfügbarkeit und Automatisierung Priorität haben, verringert sich die Anzahl der ernst zu nehmenden Alternativen erheblich. Open QRM bietet sich dabei als Universalwerkzeug und Ersatz für teure proprietäre VMware-Sphären an. Es erschließt mit wenig Aufwand out of the Box die Welt des Cloud Computing und brilliert mit fast vollständigem Funktionsumfang. (mfe)