© Tom Wang, Fotolia

Ein Proxmox-Cluster ebnet für seine Anwender so manche Hürde der komplexen Virtualisierungstechnik. Mit wenigen Klicks verwalten sie ganze Herden virtueller Maschinen, ohne sich um deren Installation oder Partitionierung kümmern zu müssen. Hart wird es erst beim Thema HA.

Eine professionelle Wolkendecke geht normalerweise ordentlich ins Geld. Wer bei Citrix [1] oder VMware [2] einkauft, legt für die Infrastrukturen der beiden Marktführer schnell sechsstellige Summen auf den Tisch. Immer mehr Hersteller freier Alternativen versuchen, den Cloud-Platzhirschen wenigstens ein paar Kunden streitig zu machen.

Proxmox VE

Neben Open Stack, Red Hats Enterprise Virtualisierung, oder Ubuntus Cloudprodukten [3] findet dabei derzeit auch eine Lösung aus Wien Anklang bei Administratoren und Hostern: das Proxmox Virtual Environment (Proxmox VE, [4]). Dabei handelt es sich um eine komplette, auf Debian basierende Distribution, die es auch Virtualisierungslaien ermöglichen will, auf einfachste Art und Weise mit dieser Technik umzugehen.

Die aktuelle Proxmox-Version 2.1 vom April 2012 fußt auf Debian Squeeze und dem schon etwas betagten RHEL-Kernel 2.6.32-13. Sie nutzt neben KVM 1.1.1 auch Open VZ als Hypervisor. Jeder der beiden hat seine Vor- und Nachteile – die sich schon beim Einrichten der virtuellen Gäste auswirken.

Hypervisor: Open VZ oder KVM?

Bei der Open Virtualization [5] nutzen die Gäste die Ressourcen eines Hostsystems, setzen aber auf eigene Prozessbäume, Netzwerkschnittstellen, Dateien sowie Benutzer- und Administratorkonten. Open VZs Containersystem ähnelt einer Chroot-Umgebung, schirmt aber die Betriebssystem-Instanzen voneinander ab, was den Zugriff aus einem Open-VZ-Container aufs Hostsystem unmöglich macht. Alle Prozesse verarbeitet der Betriebssystemkern des Hosts.

Open VZ kann derzeit bis zu 64 CPUs und 64 GByte RAM ansprechen. Lediglich der verbaute RAM oder die CPU-Leistung begrenzen die maximale Anzahl von Containern. Der Admin installiert einen neuen Container über Vorlagen (Templates, Abbildung 1), was das Einrichten einer neuen VM recht schnell gestaltet, in der Regel dauert es zwischen 2 und 5 Minuten.

Abbildung 1: Proxmox kann Open VZ und KVM als Hypervisor verwenden. Die Open-VZ-Container richtet der Admin über Templates im Web-GUI ein.

Die Kernel-based Virtual Machine (KVM, [6]) dagegen zeichnet sich dadurch aus, dass jede Instanz aus einem komplett virtualisierten Betriebssystem besteht und keine Softwareressourcen des Hostsystems benutzt. Einzige Voraussetzung ist eine CPU mit Hardware-Virtualisierungstechniken von Intel (VT), AMD (AMD-V) oder die System-Z-Architektur von IBM. Auch hier begrenzt nur die Hardware (CPU und RAM) die maximale Anzahl der VMs. Weil die Installation eines Gastes normalerweise von ISO-Images der Distributoren erfolgt, dauert sie – je nach Hardware – zwischen 10 und 40 Minuten (Abbildung 2).

Abbildung 2: KVM-Gäste verlangen eine Installation, in der Regel aus ISO-Images, was deutlich länger dauert, aber auch mehr Freiheit bietet.

Automatisch bedeutet – kaum Entscheidungsfreiheit

Wer Proxmox testen will, sollte auf jeden Fall auf eine Mehrkern-CPU mit mindestens vier echten Kernen und Hardwarevirtualisierung setzen. 8 GByte RAM und eine 1-TByte-Festplatte reichen für den Anfang vollkommen aus, im Unternehmensbetrieb dürften die Anforderungen aber schnell steigen.

Schon die Installation zeigt, dass die Wiener Hersteller der GPLv3-Software es dem Benutzer einfach machen wollen und ihm dabei viel Arbeit abnehmen – natürlich zu Lasten der Entscheidungsfreiheit. Das Installations-GUI fordert den Anwender auf, Land und Zeitzone, Tastaturlayout, Rootkennwort, E-Mail-Adresse, Hostname und diverse IP-Einstellungen einzugeben – fertig. Jetzt startet Proxmox einmal durch und zeigt vor dem Login an der Konsole die IP-Adresse und den Port des Managementinterface an.

Im Rahmen einer normalen Installation kann der Anwender leider nicht individuell partitionieren, Proxmox teilt die Platte(n) automatisch auf, offensichtlich prozentual: Auf einer 250-GByte-Festplatte fanden die Linux-Magazin-Tester 150 GByte für die Imagedaten, 50 GByte fürs Rootsystem, dazu Boot-, Tmp- und Swap-Partitionen.

Wem die durchaus sinnvollen Vorgaben nicht gefallen, der muss zu Bootparametern greifen: »maxroot« oder »swapsize« erzwingen die erwünschten Partitionsgrößen. Auch die Dateisysteme lassen sich hier vorgeben: Soll beispielsweise die Rootpartition 40 GByte, die Swap-Partition 5 GByte groß sein und Ext 4 als Dateisystem dienen, reicht am Bootprompt des Installers das Kommando:

linux ext4 maxroot=40 swapsize=5

Trotz all der Optionen gibt es sicherlich komfortablere Arten, Partitionen zu definieren. Software-Raids schon bei der Installation anzulegen oder das Auslagern einzelner Verzeichnisse in eigene Partitionen ist hier nicht möglich.

Die Oberfläche

Seit Version 2 basiert die Oberfläche des Web-GUI auf dem Javascript-Framework Ext JS 4. Für die Authentifizierung integriert Proxmox PAM, LDAP, Active Directory oder den hauseigenen Proxmox VE Authentication Server [7]. Proxmox arbeitet rollenbasiert, der Admin kann am GUI jedem Anwender und jeder Gruppe dedizierte Rechte verschaffen oder entziehen. Die Reiter »Rollen« und »Rechte« verschaffen dazu einen schnellen Überblick (Abbildung 3).

Abbildung 3: Aufgeräumt trotz vieler Optionen kommt das Webinterface von Proxmox daher.

Die virtuellen Rechner fasst Proxmox in Pools zusammen, die der gleichnamige Reiter verwaltet. Dessen linke Spalte zeigt die Maschinen eines Pools an. In einer virtuellen Softwareschmiede könnte der Admin an dieser Stelle vielleicht drei separate Pools für drei Abteilungen mit jeweils unterschiedlichen Bedürfnissen an die virtuellen Rechner anlegen, zum Beispiel für »Entwickler« , »Testnetz« und »Produktion« .

Backup via Suspend, Stop oder Snapshot

Der Reiter »Backup« hilft dabei, die virtuellen Maschinen über simple Cronjobs zu sichern. Doch bevor der Benutzer einen Backup-Cronjob anlegt, muss er zuerst Speichermedien über den Reiter »Storage« hinzufügen. Hier darf er zwischen einem Verzeichnis, einer LVM-Gruppe, einem NFS-Share oder einem I-SCSI-Ziel auswählen.

Bei Backup-Jobs bietet Proxmox Auswahldialoge für Zeitpunkt (Wochentag, Uhrzeit) und Kompressionsalgorithmen des Backups: LZO (schnell), Gzip (gut) oder keine (sicher). Wer hier seine E-Mail-Adresse angibt, erhält ein sehr übersichtliches Protokoll und erkennt auf Anhieb, ob das Backup erfolgreich war. Proxmox bietet dem Admin dabei verschiedene Modi für Backups: »Snapshot« , »Suspend« und »Stop« .

• Snapshot: Backup über einen LVM-2-Snapshot (keine Ausfallzeit).
• Suspend: Die virtuelle Maschine wird in einen Ruhezustand versetzt, gesichert und wieder gestartet (mittlere Ausfallzeit).
• Stop: Proxmox fährt die virtuelle Instanz herunter, sichert sie und startet sie nach dem Backup neu (lange Ausfallzeit).

Beim »Suspend« hängt die Ausfallzeit vom gewählten Hypervisor ab: Mit Open VZ ist sie eher kurz, sie dauert nur so lange, bis Rsync die Dateien in ein temporäres Verzeichnis gesichert und den Container wieder gestartet hat. Bei KVM dauert das länger, weil Proxmox die VM in den Ruhezustand versetzt und dann mit »vzdump« dasselbe Tool anwendet wie im Stop-Modus.

Die Backup-Cronjobs landen normalerweise in der Datei »/etc/cron.d/vzdump« . Wem die Optionen der Weboberfläche nicht ausreichen, der steuert Vzdump an der Konsole, »man vzdump« listet alle verfügbaren Optionen.

Das Restore gelingt ebenso einfach: In der linken Seite des GUI lässt sich das System auswählen, in dessen »Backup« -Reiter markiert der Admin das wiederherzustellende Image und klickt auf »Zurückspielen« . An der Konsole gelingt das mit »vzrestore« für Open-VZ-Container und »qmrestore« für KVM-Instanzen.

Virtuelle Maschinen anlegen und verwalten

Auch neue virtuelle Rechner legt der Anwender per Mausklick an: In der rechten oberen Ecke des GUI findet er die Buttons »Erstelle VM« und »Erstelle CT« . Ersterer legt eine virtuelle KVM-Maschine an, der zweite einen Open-VZ-Container. Es öffnet sich ein Wizard, in dem der Benutzer Einstellungen zu Netzwerk, RAM, CPU, Laufwerken und ISO-Images, Betriebssystem und Proxmox-Variablen (VM ID, Name, Ressource Pool) eingibt (Abbildungen 1 und 2).

Die Übersicht laufender Maschinen erreicht der Anwender über die linke Spalte des GUI, entweder jede Maschine einzeln oder pro Ressourcenpool. In der Server-Übersicht zeigt Proxmox nützliche Informationen über die Auslastung der CPU und des Arbeitsspeichers sowie den Status der virtuellen Maschinen auf diesem Knoten. Per Klick startet, stoppt oder resettet ein Admin hier Maschinen, migriert sie auf einen anderen Proxmox-Knoten oder fährt sie sanft herunter.

Wie es bei vielen Cloudmanagern üblich ist, bettet auch Proxmox eine Konsole ins Web-GUI ein. Die bringt mit Hilfe von Java einen virtuellen Bildschirm in den Browser, der erweist sich als sehr nützlich, wenn die VM nicht mehr über das Netzwerk erreichbar ist.

Für Hochverfügbarkeit nur vorbereitet

Wer mit den großen Virtualisierungslösungen konkurrieren will, muss auch Hochverfügbarkeit bieten. Proxmox VE ist zumindest darauf vorbereitet – siehe das eben erwähnte Migrieren eines Hosts zwischen Knoten. Der Anwender muss allerdings an manchen Stellen doch einige Abstriche machen, vor allem im Hinblick auf DRBD [8].

Grundsätzlich gilt: Am besten funktioniert Proxmox VE, wenn für das Setup ein Shared Storage in Form eines klassischen SAN zur Verfügung steht. Dann liegen die Container der virtuellen Maschinen von Proxmox auf dem SAN und die Virtualisierungsknoten greifen darauf zu, um die konfigurierten VMs zu starten. Unter der Haube werkelt der standardisierte Kommunikationsstack Corosync [9], der in Kombination mit Red Hats Clustersuite [10] die HA-Eigenschaften der VMs sicherstellt.

HA-Konfiguration: Ein Cluster plus Corosync

Um die HA-Fähigkeiten von Proxmox zu nutzen, muss der Admin jedoch selbst Hand an das System legen. Nicht alle Schritte für ein funktionierendes HA-Setup lassen sich über das GUI erledigen. Ein ausführlicher Artikel im Proxmox-Wiki [11] erläutert die dazu notwendigen Arbeiten.

Proxmox unterscheidet einen normalen Cluster und einen Hochverfügbarkeitscluster. Unter Ersterem verstehen die Hersteller einen Verbund aus Rechnern, die als Virtualisierungsknoten im Rahmen einer Proxmox-Installation funktionieren. Dagegen ist ein Hochverfügbarkeitscluster ein normaler Cluster, aber erweitert um HA-Fähigkeiten.

Am GUI ist dafür nichts einzustellen, aber Proxmox stellt immerhin ein eigenes Tool namens »pvecm« bereit, das die Konfiguration auf der Kommandozeile erledigt: »pvecm« erleichtert das Setup, indem es auf den Virtualisierungsknoten eine Corosync-Konfiguration anlegt und dafür sorgt, dass alle Knoten im Rechnerverbund miteinander kommunizieren. Dann stimmen sich die Knoten automatisch über das Multicast-Protokoll ab. Aktuelle Versionen von Corosync unterstützen allerdings auch das bei Netzwerk-Admins deutlich beliebtere Unicast-Protokoll. Das aber hat Proxmox noch nicht in »pvecm« integriert.

Ist der Proxmox-Cluster aufgesetzt, folgt im nächsten Schritt die ebenfalls manuelle Konfiguration des Clustermanagers. Proxmox setzt zwingend voraus, dass Admins zwischen den Knoten die Stonith-Funktion aktivieren. Stonith steht für “Shoot the other node in the head” [12] und beschreibt die Technik, Knoten gewaltsam aus dem Cluster zu katapultieren, die scheinbar defekt sind und deshalb zur Gefahr entweder für die Integrität von Daten oder für den gesamten Rechnerverbund werden könnten. Ist der Clustermanager aufgesetzt, lässt sich die HA-Funktion für einzelne Knoten im Proxmox-Cluster übers Webinterface aktivieren und überprüfen (Abbildung 4).

Abbildung 4: Ist der Cluster einmal eingerichtet, lässt er sich mit dem Webinterface komfortabel verwalten – doch vorher bedarf es einiger Handarbeit.

Intelligente Konfigurationsverwaltung mit Pmxc-FS

Ein Ärgernis für Admins bei der Verwaltung von HA-Clustern ist der Umgang mit Konfigurationsdateien. Diese müssen meist auf allen Clusterknoten identisch sein, damit gleiche Dienste auf verschiedenen Knoten auch die gleichen Funktionen bringen. Viele Admins bemühen dafür Krückenkonstruktionen wie Rsync-Skripte oder die ebenfalls Rsync-basierte Lösung mit »csync2« , um das Problem in den Griff zu kriegen.

Proxmox geht einen anderen Weg und steuert Pmxc-FS [13] bei. Das vom Hersteller selbst entwickelte Cluster-Dateisystem baut auf Fuse auf und macht sich Kommunikationsfunktionen von Corosync zu eigen. Alle Konfigurationsdateien, die Cluster-weit identisch sein sollen, landen in einem solchen Filesystem und stehen fortan allen Proxmox-Knoten zur Verfügung.

Locking

Auch ans Locking haben die Proxmox-Entwickler dabei gedacht, damit nicht zwei gleichzeitig erfolgende Änderungen eine Konfiguration unbrauchbar machen. Im Hintergrund kümmert sich SQlite um die sinnvolle Verwaltung der Files. Zwar ist die Größe eines Pmxc-FS auf 30 MByte begrenzt, aber mehr Platz ist für die Konfigurationsdateien meist nicht nötig. Der Vorteil: »pmxcfs« puffert die gesamten Inhalte eines Dateisystems im RAM und sorgt so für kurze Zugriffszeiten.

Problemfall DRBD

Dass Proxmox auf DRBD verzichtet, ist nur konsequent: Proxmox VE will Virtualisierungsnetzwerke mit etlichen Knoten bereitstellen, aber DRBD kann in Version 8 nur zwei Knoten bedienen. Über den Umweg der »Stacked Resources« sind zwar drei Knoten möglich, aber eine solche Limitierung würde auch die maximale Größe eines Proxmox-Clusters auf drei Knoten bedeuten – ein Nachteil, den die Proxmox-Entwickler nicht in Kauf nehmen wollten.

Ob DRBD in Version 9 Einzug in Proxmox hält, bleibt abzuwarten: Diese Version verspricht, mit mehr als zwei Knoten gleichzeitig zurechtzukommen, und würde somit das größte Problem für die Proxmox-Integration aus der Welt schaffen. Wer DRBD in Proxmox verwenden will, muss selbst Hand anlegen.

Weich gebettet

Das Management von Proxmox ist gut gelungen, und dass sich HA-Fähigkeiten für Knoten per Klick aktivieren lassen, freut den Admin. Das unaussprechliche »pmxcfs« erweist sich im Test als pfiffige Lösung, um Konfigurationsdateien zu verwalten, wenn es auch nicht ein ausgewachsenes Framework wie Puppet oder auch Chef ersetzen kann. Lediglich die Tatsache, dass das grundlegende Setup des Clustermanagers »rgmanager« händisch abzuwickeln ist, bietet Grund für Kritik. Schaffen es die Proxmox-Entwickler, hierfür einen Button ins GUI einzubauen, wäre Proxmos auch in Sachen HA eine gelungene Lösung.

Wem die wenigen Schwächen von Proxmox nichts ausmachen, der bekommt eine sehr gute Lösung, die das Verwalten einer eigenen Cloud zur Sache von wenigen Mausklicks macht. Für Fortgeschrittene sind Hürden wie die umständliche Partitionierung bei der Installation, die DRBD-Integration oder das HA-Setup zu meistern. Das Web-GUI ist aber gelungen und der Funktionsumfang ausreichend genug, sodass auch der Admin mal in Urlaub gehen kann – die Einweisung seiner Vertretung dürfte nicht lange dauern. Und wenn doch mal was brennt, gibt es schon ab knapp 400 Euro kostenpflichtigen Support vom Hersteller http://14.