© sorcerer44, 123RF

Fernab großer Hersteller werkelt die Firma Proxmox in Wien seit Jahren an ihrer Virtualisierungsverwaltung, die ganz ohne Wolken auskommt. In der neuen Version 5.0 verbessern die Entwickler die Zuverlässigkeit der Software und packen auch neue Features dazu.

Seltsamer Trend: Plötzlich will jeder Open Stack einsetzen, auch wenn es nur darum geht, ein paar VMs zu verwalten. Auf dieser Grundlage gestartete Open-Stack-Projekte verschwinden meist ganz schnell wieder. Spätestens dann nämlich, wenn dem Unternehmen klar wird, wie viel Overhead es sich mit Open Stack in Wahrheit eigentlich auflädt.

Keine Frage: Wer nur wenige VMs verwalten möchte, der ist mit einer typischen Virtualisierungsverwaltung deutlich besser bedient als mit Software, die den Betrieb einer Public-Cloud-Plattform ermöglichen soll. Obwohl die klassischen VM-Verwaltungen im Vergleich zu den Cloudlösungen eher ein Schattendasein fristen: Es gibt sie und sie sind sehr erfolgreich. Red Hats RHEV erfreut sich ähnlicher Beliebtheit wie Suses SLES 12, das sich mit Extensions um Hochverfügbarkeit erweitern lässt und alternative Storagekonzepte unterstützt.

Seit Jahren existiert eine weitere Lösung: Proxmox VE der Wiener Firma Proxmox. Vor wenigen Wochen hat sie die Version 5.0 erreicht. Was kann es, für welche Einsatzzwecke eignet es sich und welche Kosten kommen auf Admins zu? Der folgende Artikel gibt Aufschluss.

Des Pudels Kern: KVM & LXC

Proxmox VE versteht sich als echte Virtualisierungsverwaltung und nicht als verkappte Cloud. Im Kern des Produkts kombiniert Proxmox zwei Virtualisierungstechniken, aus denen der Nutzer wählen kann: das nunmehr als Virtualisierungsstandard für Linux geltende KVM einerseits sowie LXC für den Betrieb von leichtgewichtigen Containern. Der Nutzer hat also die Wahl, ob er mit Proxmox ganze Computer paravirtualisiert oder ob er auf Container setzt und auf deren Grundlage einzelne Anwendungen betreibt (Abbildung 1).

Abbildung 1: Proxmox VE beherrscht sowohl die Virtualisierung mittels KVM als auch die Containervirtualisierung unter Zuhilfenahme von LXC.

Auf der Systemebene unterscheidet sich ein mit Proxmox verwalteter Server zunächst nicht von einem System, auf dem der Admin händisch KVM oder LXC-Instanzen ausgerollt hat. Was Proxmox VE ausmacht, das ist eine Zwischenschicht, die es dem Nutzer präsentiert. Diese Zwischenschicht gewährleistet nach unten die Verwaltung von VMs und daran angebundenen Speicher und bietet nach oben hin standardisierte Interfaces, über die der Admin seine gewünschte Konfiguration festlegt.

Eben diese Zwischenschicht ist bei Proxmox sehr mächtig: Sie kümmert sich auf Wunsch darum, dass virtuelle Systeme oder persistenter Speicher redundant sind, dass neue VMs auf Zuruf angelegt werden und dass der Administrator stets über die gerade anliegende Last Bescheid weiß. Um dieses Ziel zu erreichen, haben die Entwickler unterschiedliche Werkzeuge miteinander kombiniert.

Das Proxmox-API

Das wichtigste dieser Werkzeuge ist das API, das bei Proxmox auf den leicht sperrigen Namen »pvedaemon« hört. Es bildet die zentrale Schaltstelle im gesamten Setup. Möchte der Benutzer eine Operation innerhalb der Plattform ausführen – zum Beispiel eine virtuelle Maschine starten oder ein neues Volume auf einem angeschlossenen Storage anlegen – so landet dieser Befehl letztlich bei einer der laufenden API-Instanzen.

An dieser Stelle ist Proxmox einer Lösung für Cloud Computing gar nicht unähnlich. Auch dort gibt es das Konzept des von allen Seiten verfügbaren, zentralen API. Anders als etwa bei Open Stack läuft eine Instanz des API bei Proxmox VE allerdings auf jedem Host; jeder Host hat sein eigenes API.

Trotzdem müssen Nutzer beim Ausführen von Befehlen nicht ein spezifisches API ansprechen. Weil Proxmox die Möglichkeit hat, den Ziel-Host als Teil eines Befehls mitzusenden, genügt der Hilfsdienst »pveproxy«, der ebenfalls auf jedem Host läuft. Ganz gleich an welche Proxy-Instanz innerhalb des Clusters der Anwender einen Befehl schickt – das Kommando landet immer zunächst beim Proxy des jeweiligen Hosts und dieser leitet es an den Ziel-Host weiter, falls er nicht selbst der Ziel-Host ist.

Der PVE-Stats-Daemon, kurz »pvestatsd«, unterstützt die Proxmox-Werkzeuge bei ihrer Arbeit. Er listet regelmäßig für jeden Host die laufenden und die verfügbaren Ressourcen auf und teilt diese Info mit allen anderen Knoten im Cluster. Jeder Knoten hat also zu jedem Zeitpunkt ein vollständiges Bild hinsichtlich der Ressourcen-Situation, was etwa das Starten zusätzlicher VMs signifikant erleichtert – denn es lässt sich auf diese Weise deutlich schneller herausfinden, auf welchem Host die neue Ressource anzulegen ist.

Hochverfügbarkeit

Ein signifikanter Unterschied zwischen klassischer Virtualisierung und dem für Clouds propagierten “Alles kann jederzeit kaputtgehen”-Mantra ist die Art und Weise, wie das Setup auf Ausfälle reagiert. In der Cloud ist die Sache klar: Hier kommt dem Autor einer Software oder dem Admin, der diese Software betreibt, die volle Verantwortung zu. Zusammen müssen beide die Software so konzipieren und ausrollen, dass der Ausfall einzelner Server oder anderer, für den Betrieb wichtiger Infrastruktur, nicht zu Service-Ausfällen führt.

Klassische Setups versuchen dagegen Ausfälle durch Maßnahmen auf der Infrastruktur-Ebene abzufangen: Dazu muss etwa die VM auf redundantem Speicher liegen, damit ihre Daten selbst dann noch verfügbar bleiben, wenn der vorherige Computing-Knoten ausfällt. Zudem muss sich ein Cluster Resource Manager (CRM) darum kümmern, dass die VM automatisch auf einem anderen Knoten neu gestartet wird, falls der vorige Heimatknoten abgestürzt ist.

Weil Proxmox sich als klassische Virtualisierungslösung versteht, hat man in Wien genau diesen Weg eingeschlagen: Die Dienste »pve-ha-lrm« und »pve-cluster« bauen einen vollständigen HA-Cluster auf, der Abstürze von einzelnen Knoten abfängt. Der »pve-ha-lrm« ist dabei der Ressourcen-Manager: Er führt auf dem lokalen System die Befehle aus, die er vom »pve-ha-crm« empfängt.

Dieser ist Bestandteil von »pve-cluster« und der Cluster-weite Ressourcen-Manager: Stürzt ein Knoten ab, entscheidet der CRM-Dienst zunächst, auf welchen Hosts die zuvor auf dem abgestürzten Knoten beheimateten VMs erneut gestartet werden. Danach erteilt er entsprechende Kommandos an die LRMs.

Spannend: Proxmox setzt zwar auf Corosync, um die Kommunikation zwischen den Clusterknoten zu ermöglichen. Doch verwendet es als Cluster Resource Manager nicht Pacemaker, das in dieser Kombination eigentlich Usus wäre. Stattdessen haben die Wiener den eigenen Clustermanager »ha-manager« geschrieben und setzen ihn nun seit der Proxmox-VE-Version 4 ein (Abbildung 2).

Abbildung 2: Hochverfügbarkeit spielt bei klassischer Virtualisierung eine große Rolle. Proxmox liefert einen kompletten Clustermanager mit.

Zu »pve-cluster« gehört aber noch mehr: Unter dem Namen »pmxcfs« hat man in Wien auch ein Dateisystem auf Datenbankbasis entwickelt, das sich darum kümmert, relevante Konfigurationsdateien über die Hosts eines Setups hinweg synchron zu halten. Genau das war in der Cluster-Geschichte von Linux nicht immer ganz leicht. Zwar existieren Lösungen wie »csync2«, das sich in der Vergangenheit allerdings regelmäßig als zu wenig flexibel erwies.

Klassische Automatisierer helfen auch nicht weiter. Einige Dateien, die über die Hosts hinweg synchron zu halten sind, verändern sich während des laufenden Betriebs. Das regelmäßige Ersetzen durch ein statisches Template funktioniert also nicht. Aus heutiger Sicht ist es dennoch fraglich, ob man diesem Problem tatsächlich mit einem eigenen, nur zum Teil Posix-kompatiblen und auf Fuse basierenden Dateisystem zu Leibe rücken muss. Sowohl Consul als auch dessen Konkurrent Etcd ermöglichen heute vergleichbare Funktionalität ohne eigenes Dateisystem. Gut denkbar allerdings, dass es beide Dienste einfach noch nicht gab, als Proxmox mit der Entwicklung von »pmxcfs« begann.

Virtualisierungsfunktionen

Das umfassende Management-Framework, mit dem Proxmox VE unterfüttert ist, zahlt sich aus Sicht des Anwenders aus: Virtuelle Maschinen lassen sich – egal ob KVM- oder Container-basiert – mit einem standardisierten und in Json definierten REST-ähnlichen API starten. Dabei beherrscht Proxmox VE auf Netzwerk-Seite verschiedene Ansätze: Grundsätzlich basiert das Netzwerkkonzept der Lösung auf Netzwerk-Brücken, doch darf der Admin auch SDN-Lösungen wie Open Vswitch integrieren. IPv4- und IPv6-Support für die VMs gehören zum Lieferumfang.

Auch auf der Storage-Seite kann es Proxmox VE durchaus mit den typischen Cloudlösungen aufnehmen. Lokaler Speicher lässt sich per LVM oder über die klassischen Linux-Dateisysteme (Ext 4/XFS, auch auf Basis von LVM) genauso anbinden wie ZFS. Wer stattdessen Netzwerkspeicher will, findet auch hier viele Möglichkeiten: Fibre Channel, I-SCSI oder NFS funktionieren ebenso wie verteilte Speicherlösungen, etwa Ceph oder Gluster FS. (Auf das Thema Ceph geht der Artikel später noch genauer ein, weil Proxmox es auf Wunsch auch selbst installieren kann.)

Wer mit seinen virtuellen Maschinen jonglieren muss, freut sich darüber, dass Live-Migration in Proxmox VE grundsätzlich funktioniert. Doch sollte die virtuelle Maschine dabei auf redundantem Speicher liegen, bevorzugt also auf einem Objektspeicher wie Ceph.

Falls mal etwas schiefgeht, haben die Proxmox-Entwickler auch dafür vorgesorgt: Direkt integriert in die Lösung sind Backup- und Restore-Werkzeuge, mit denen sich virtuelle Maschinen im Notfall schnell wiederherstellen lassen. Das umfasst auch während des Betriebs angelegte Snapshots sowie die Möglichkeit, per Klick im GUI sofort ein komplett neues Backup anzulegen.

Von Templates und Klonen

Proxmox VE bietet die Möglichkeit, VM-Templates und von diesen Klone anzulegen. Beide Funktionen sind besonders im Cloud Computing beliebt: Fußt eine VM auf einem Template, lässt sie sich deutlich schneller ausrollen, als es im Falle einer händischen Installation möglich wäre. Ein VM-Template ist im Wesentlichen ein vorbereitetes und generalisiertes Festplatten-Abbild, das per Mausklick als neue VM startet. Etwaige Parameter kommen von außen.

Das Ausrollen passiert über Klone von Templates, wobei der Anbieter hier zwischen “verlinkten Klonen” und “vollständigen Klonen” unterscheidet. Bei verlinkten Klonen hängen Template und Klon fest zusammen, der Klon kann ohne Template nicht funktionieren. Das schränkt zwar die Flexibilität ein, führt aber auch dazu, dass die VM wenig Speicherplatz benötigt. Beim vollen Klon kopiert Proxmox beim Start das gesamte Template, dafür läuft die VM aber anschließend auch ohne ihr ursprüngliches Template (Abbildung 3).

Abbildung 3: Über Klone lassen sich in Proxmox VE von VM-Templates neue VMs anlegen, die nach wenigen Mausklicks startbereit sind.

Zugriffsmöglichkeiten

Von dem Web-GUI war schon die Rede, das Teil von Proxmox VE ist. Tatsächlich ist es ausgesprochen gelungen. Es lässt sich per Webbrowser erreichen und kann auf irgendeinem Host der Cloud mitlaufen, sodass kein separater Management-Server benötigt wird. Die optische Erscheinung der grafischen Oberfläche hat Proxmox in den vergangenen Jahren sukzessive verändert, ohne dabei den Faktor Benutzerfreundlichkeit aus den Augen zu lassen.

Genauso wenig ist Funktionalität auf der Strecke geblieben: Links findet der Admin eine Liste der verfügbaren Hosts. Klickt er einen dieser Hosts an, erscheint im rechten Teil des Fensters eine Liste der Eigenschaften des Hosts inklusive der Möglichkeit, sie zu verändern.

Rudimentäres Monitoring für Systemwerte wie CPU-Last und RAM-Nutzung ist hier ebenfalls integriert. Auf Wunsch kann der Admin sogar einen Blick in zentrale Logdateien werfen, etwa das Syslog. Ein Login per virtueller Konsole unterstützt Proxmox VE per Web-GUI ebenfalls, sodass dieses ein zentrales Management-Werkzeug ist und der Konkurrenz von Suse oder Red Hat in nichts nachsteht (Abbildung 4).

Abbildung 4: Mit Hilfe von NoVNC ermöglicht Proxmox 5.0 auch den direkten Zugriff auf die Kommandozeile des virtualisierten Systems.

Wer erfahrener CLI-Jockey ist und sich nicht so recht mit dem Web-GUI anfreunden kann, erhält bei Proxmox als Alternative auch eine Lkw-Ladung voller Kommandozeilen-Werkzeuge. Proxmox VE spielt hier den Vorteil des offenen und standardisierten API aus: Die CLI-Befehle produzieren letztlich dieselben API-Aufrufe wie auch das Webinterface. Die Pflege der CLI-Werkzeuge bedeutet deshalb deutlich weniger Aufwand, den Proxmox offensichtlich gerne treibt, um Power-User nicht zu vergrätzen.

Umfassende Benutzerverwaltung

Bei Virtualisierungslösungen ist Benutzerverwaltung ein sehr wichtiges Thema. In der Regel brauchen mehr Leute als nur ein Admin Zugriff auf das zentrale Managementinstrument. Die Buchhaltung etwa will regelmäßig wissen, welche Kunden welche Dienstleistung in Anspruch nehmen. Und nicht jeder Admin soll jede Berechtigung haben: Wer virtuelle Maschinen anlegen und verwalten soll, muss nicht zwingend auch neue Nutzer anlegen dürfen.

Proxmox trägt diesem Umstand mit einer umfassenden Rechteverwaltung Rechnung, die auf dem Rollen-Prinzip basiert. Eine Rolle ist eine Sammlung spezifischer Berechtigungen, die sich nach Belieben kombinieren lassen. Die Rechteverwaltung ist dabei fein granuliert: Bis hin zu einzelnen Befehlen lässt sich festlegen, was welche Rolle ausführen darf.

Zudem lässt sich Proxmox VE mit mehreren Quellen verbinden, um daraus Nutzerdaten zu beziehen. PAM auf Linux ist der Klassiker, und Proxmox hat auf Wunsch auch eine eigene Benutzerverwaltung. Falls bereits ein funktionierendes LDAP-Verzeichnis oder eine AD-Domäne existieren, können auch sie als Quelle für Accounts dienen. An der Rechteverwaltung ändert das nichts.

Auch Nutzern aus diesen Quellen lassen sich Rollen zuweisen. Und damit bei der Anmeldung nichts schiefgeht, unterstützt Proxmox mittlerweile auch Zwei-Faktor-Authentifizierung: Neben den zeitbasierten Einmalpasswörtern ist auch ein Ubikey einsetzbar, den Nutzer am Schlüsselbund tragen.

Proxmox bietet über sein API außerdem die Möglichkeit, die am Cluster beteiligten Server mit Firewallregeln auszustatten. Die Technik basiert auf Netfilter, also auf IPtables, und ermöglicht das Durchsetzen von Zugriffsregeln auf den einzelnen Hosts. Zwar kommt Proxmox mit einem vordefinierten Regelwerk daher, doch kann es der Admin nach Belieben umbauen und modifizieren.

Ceph ist integriert

Eine der größten Herausforderungen im Hinblick auf den Betrieb virtueller Maschinen ist seit jeher das Thema redundanter Speicher, ohne bleibt Hochverfügbarkeit unerreichbar. Verschiedene Lösungen existieren im Markt, etwa DRBD, das die ebenfalls in Wien ansässige Firma Linbit herstellt und das sich besonders im Zusammenhang mit Zwei-Knoten-Clustern einen Namen gemacht hat.

Proxmox hat DRBD eine ganze Weile als Plugin unterstützt, inzwischen schlägt das Herz der Entwickler aber für eine andere Lösung: Ceph. Dieser verteilte Objektspeicher, der im Open-Stack-Fahrwasser bekannt geworden ist, hat mittlerweile auch außerhalb der Cloud viele Fans. Proxmox hat Ceph vollständig in Proxmox VE integriert. Das bedeutet, dass sich ein existierender Ceph-Cluster dort nicht nur als externer Speicher anbinden lässt.

Proxmox VE installiert auf Wunsch auch einen eigenen Ceph-Cluster, der sich mit den gewohnten Proxmox-Werkzeugen verwalten lässt. Dabei deckt Proxmox alle Stufen des Ceph-Deployments ab. Die Monitoring-Server, die in Ceph das Cluster-Quorum erzwingen und allen Clients Informationen über den Zustand des Clusters zur Verfügung stellen, lassen sich per Mausklick ebenso auf einzelnen Servern ausrollen wie sich dort befindliche Festplatten als OSD deklarieren, also als Object Storage Device. Auf OSDs liegen bei Ceph letztlich die in kleine Segmente aufgeteilten Daten.

Art, Umfang und Qualität, die Proxmox bei der Ceph-Integration in die VE-Umgebung bietet, sind beachtenswert: Das Cluster-Setup mittels Proxmox-GUI geht leicht von der Hand und funktioniert zufriedenstellend. Bei Bedarf kann der Admin sogar einzelne Parameter des Clusters nachjustieren, um etwa bessere Performance zu erreichen.

Und weil der schönste Speicher nur wenig nutzt, wenn ihn die virtuellen Maschinen am Ende nicht auch verwenden, hat Proxmox das Ceph-Blockgerät RBD gleich mitintegriert. Wer also eine VM startet, kann Proxmox sagen, dass dies auf Basis eines neuen RBD-Volumes zu geschehen hat. RBD lässt sich dabei als Storage Volume genauso wie andere Storage-Arten regulär auswählen.

Einzig der Umstand, dass Proxmox Nutzern kleinerer Umgebungen den Betrieb eines “hyperconverged” Setups nahelegt, führt zu Stirnrunzeln. Hyperconverged bedeutet, dass auf jenen Systemen, die Festplatten für Ceph bereitstellen, gleichzeitig auch virtuelle Maschine betrieben werden.

Inktank, die Firma hinter Ceph, rät von einem solchen Setup regelmäßig ab: Cephs Crush-Algorithmus ist Ressourcen-hungrig. Fällt ein Knoten eines Ceph-Setups aus, liegt auf den anderen Ceph-Knoten viel Last, um fehlende Replikas wiederherzustellen. Das kann negativen Einfluss auf virtuelle Systeme haben, die auf denselben Servern laufen.

Neuigkeiten in Version 5.0

Die Version 5 enthält gleich mehrere wichtige Neuerungen. Wer virtuelle Maschinen von anderen Hypervisor-Typen importieren möchte, kann das in Proxmox VE 5.0 deutlich leichter tun als bisher. Das Basissystem haben die Entwickler zudem ordentlich aufgemöbelt: Proxmox VE basiert grundsätzlich auf Debian GNU/Linux. Die neue Version 5.0 fußt auf Debian 9, das Debian selbst erst kürzlich veröffentlicht hat. Im Gegensatz zur originalen Version liefert Proxmox sein Produkt allerdings mit einem modifizierten Kernel 4.10 aus.

Neuerungen ergeben sich auch in Sachen Ceph. Ab Proxmox VE 5.0 liefern die Proxmox-Entwickler ihre eigenen Debian-Pakete für Ceph aus. Bisher hatten sie sich noch auf jene Pakete verlassen, die Inktank offiziell zur Verfügung gestellt hat.

Das Hauptziel der Entwickler besteht darin, den Proxmox-Kunden Bugfixes schneller zukommen zu lassen, als es bei den offiziellen, von Inktank angebotenen Paketen der Fall ist. Ob das wie geplant funktioniert, wird erst die Zeit zeigen: Ceph ist schließlich keine kleine Lösung mehr, sondern ein komplexes Biest. Inwiefern es einem externen Dienstleister ohne Ceph-Kernentwickler gelingt, schneller als der Hersteller zu sein, wird zweifellos interessant zu beobachten sein.

So oder so: Ceph-RBD wird in Proxmox VE 5.0 zum offiziellen De-facto-Standard für verteilten Speicher. Zeitnah ist zudem geplant, die Vorteile der künftigen Ceph-LTS-Version 12.2 alias Luminous zu integrieren: Das dort enthaltene “Blue Store”-Backend für OSDs soll deutlich schneller sein als der bisherige Ansatz auf Basis von XFS. Noch hat Inktank die neue Version aber nicht freigegeben.

Die mit Abstand wichtigste Neuerung in Proxmox VE 5.0 ist laut Aussagen der Entwickler allerdings der neue Replication Stack. Er fußt auf ZFS und bietet die Möglichkeit, von Storage Volumes in Proxmox asynchrone Replikas anzulegen. Im Kontext spricht Proxmox davon, dass dieses Vorgehen den Datenverlust im Falle von Fehlfunktionen “minimiert” – wie üblich leidet auch in diesem Fall die asynchrone Replikation daran, dass im Fehlerfall eben nicht alle Daten erhalten bleiben. Wer das Feature nutzen möchte, der konfiguriert auf Basis von Volumes die Replikation mittels Proxmox-GUI oder per Kommandozeile (Abbildung 5).

Abbildung 5: Zu Proxmox 5.0 gehört auch ein neuer Replication Stack, der auf ZFS basiert, allerdings nur asynchron arbeitet.

Wie viel kostet es?

Den Preis seines Produkts berechnet Proxmox anhand von CPU-Sockets. Die Standard-Subskription, die neben Zugriff auf das Proxmox-Enterprise-Paketrepository auch zehn Support-Tickets beim Anbieter und eine maximale Reaktionszeit von einem Tag sowie Support per SSH-Login bietet, kostet unter 40 Euro pro CPU und Monat. Für das Doppelte erhält man unbegrenzte Support-Anfragen, für 20 Euro immerhin drei Support-Tickets pro Tag, dafür entfällt der SSH-Support. Alle Preise verstehen sich zuzüglich Mehrwertsteuer.

Wer keinen Support von Proxmox will, kann sich die einzelnen Komponenten auch aus dem dortigen Github laden und händisch installieren [1]. Damit der Admin weiß, worauf er sich einlässt, bietet Proxmox eine Trial-Lizenz [2]. Die gilt für 30 Tage und enthält alle Funktionen.

Fazit

Proxmox VE 5.0 ist eine solide Virtualisierungslösung, die sich hinter Red Hat und Suse nicht zu verstecken braucht. Wer ein kleines Setup betreiben möchte, ist mit Proxmox VE deutlich besser bedient als mit einer klassischen Cloudlösung wie Open Stack. Das Verfahren, das die Wiener für die Hochverfügbarkeit virtueller Maschinen erdacht haben, überzeugt genauso wie die Liebe zum Detail bei vielen einzelnen Proxmox-Features. Bevor man bei RHEV oder Suse landet, ist ein Test mit Proxmox dringend anzuraten.