Proxmox VE (Proxmox Virtual Environment) [1] ist ein Open-Source-Hypervisor der Firma Proxmox Server Solutions GmbH aus Wien. Besonders markant sticht dabei die Vermarktung des Produkts heraus, die sich auf der Webseite des Herstellers in dem Satz "Es gibt keine Lizenzkosten und unsere Support-Abos für zusätzlichen Enterprise Support sind transparent und übersichtlich" definiert. Ein Traum nicht nur für kleine und mittelständische Unternehmen, die sich Werkzeuge wie VMware vSphere Foundation oder Microsoft Azure Stack HCI nicht mehr leisten wollen.

Als Basis für den Hypervisor dient immer das aktuellste Debian (stable), momentan also Debian "Bookworm" (Version 12). Kombiniert mit dem aktuellsten Ubuntu-Kernel (Linux-Kernel 6.5) vereint PVE eine stabile Paketbasis mit den Vorteilen aktueller Hardwarekompatibilität aufgrund des neueren Linux-Kernels.

Unter der Haube von Proxmox VE 8.1 versteckt sich allerdings noch viel mehr: Für die Virtualisierung kommen QEMU und KVM (Kernel-based Virtual Machine) zum Einsatz – sozusagen der Motor für den Betrieb von virtuellen Maschinen unter Linux-Systemen. Für den Einsatz von Containern ist LXC (Linux Containers) mit an Bord. Diese Komponenten sind keine Eigenentwicklung, sondern bereits langjährig erprobte Technologien, die auch in kommerziellen Hypervisoren wie "Red Hat Enterprise Linux" arbeiten. Selbiges gilt für die verfügbaren Storages für Proxmox VE, wobei vor allem ZFS und Ceph zu den Feature-reichsten und stabilsten Speicherumgebungen zählen.

Mit diesem Sammelsurium an geballter Open-Source-Power lassen sich sowohl Linux, BSD als auch Windows virtualisieren, inklusive TPM-Module-Support für aktuelle Windows-Server-Versionen. Standardfunktionen wie Snapshots, Backups, Clones, Templates, Livemigration und Thin-provisioned-Storage muss der Admin bei PVE ebenfalls nicht missen. Tiefgehendes Linux-Know-how ist nicht notwendig, da der Zugriff, das Management und die Konfiguration von VMs und Containern über eine intuitive Web-UI erfolgen.

Für Proxmox VE fallen keine Lizenzkosten an, das Produkt steht frei zum Down-load zur Verfügung und ist ohne Einschränkungen kostenlos nutzbar. Die angebotenen Subskriptionen sind optional, allerdings sehr empfehlenswert, wenn sich IT-Verantwortliche letztendlich für den Einsatz der Software im Unternehmen entscheiden. Denn die Subskriptionen enthalten neben getesteten Update-Paketen (Enterprise Repository) auch die Möglichkeit, bei Fragen oder Schwierigkeiten Enterprise-Support von Proxmox in Anspruch zu nehmen.

Doch wie beginnen Sie nun und welche Anfangsinvestitionen fallen an, wenn Sie sich entscheiden, den großen Playern der IT-Welt, zumindest was Virtualisierung betrifft, den Rücken zuzukehren? Den besten Start haben Sie mit einem einzelnen Server. Das Hardwaresizing eines solchen Single-Hosts hängt von verschiedenen Faktoren ab:

- Soll der Storage skalieren können?

- Ist geplant, die Umgebung später mit zusätzlichen Hosts zu erweitern?

- Ist zukünftig ein HA-Modus vorgesehen?

Sie merken schon, sehr viele Fragen drehen sich um den Storage. Dessen richtige Auswahl ist der größte Einflussfaktor hinsichtlich des HW-Sizings, da Sie jeden Speicher gesondert betrachten müssen und jeder anders funktioniert. Dabei sind iSCSI/NFS als Netzwerkspeicher, ZFS (via HBA) als lokales Storage oder RAID (via Controller) als lokaler Speicher die drei typischen Optionen für Single-hosts – technisch sinnvoll sind iSCSI und NFS aufgrund diverser Einschränkungen aber nur bedingt. Für iSCSI- und NFS-backed Storages gibt es keine einfache Möglichkeit, Snapshots von virtuellen Maschinen zu erstellen [2]. Übrig bleiben somit der klassische RAID-Controller oder der Einsatz von ZFS.

Beim klassischen, hardwarebasierten RAID (via Controller-Zusatzkarte) können Sie nach dem Erstellen des RAID-Sets und dem Konfigurieren des Storage-Pools in Proxmox VE (LVM-Thin) den Single-host für VMs und Container verwenden. Der Einsatz von Flash-Speicher ist empfohlen, HDDs eignen sich nicht für performante Virtualisierung.

Bei ZFS (Software-basiertes RAID) haben Sie mehr Möglichkeiten, was die Gestaltung der RAID-Level betrifft, als bei einem Hardware-RAID. Zugleich profitieren Sie von etlichen positiven Eigenschaften des Storage-Systems: Copy On Write, Komprimierung, Checksumming und Scrubbing. Der Einsatz von RAID-Controllern mit ZFS ist verboten – es wird unbedingt ein HBA oder eine direkte Verkabelung der Datenträger an das System benötigt. Besonders beim Sizing von RAM und Storage-Pool sollten Sie nicht sparen, da ZFS große Teile des Arbeitsspeichers zum Lese-Caching verwendet. Als Storage-Devices sollten Sie auf keinen Fall Festplatten verwenden, sondern mindestens mit SATA-SSDs, besser NVMe-SSDs arbeiten. Beim Planen von ZFS sind viele schwerwiegende Fehler denkbar, deswegen empfiehlt es sich, dies Experten wie Hardwareherstellern, Systemhäusern oder Consultants anzuvertrauen. Mit einem passenden Setup erhalten Sie einen performanten lokalen Storage für VMs und Container.

In der Erweiterbarkeit des Systems liegt hierbei ein großer Unterschied: Setzen Sie RAID-Controller ein, schränken Sie Ihre Möglichkeit ein, aus dem Single-Node-System später einen hochverfügbaren Proxmox-VE-Cluster zu bauen. Dieser HA-Aufbau startet mit zwei Nodes, einem dritten Node als Stimmgeber (auch Quorum genannt) und einem Pool, der zwischen den beiden Nodes asynchron repliziert. Dies ist allerdings mit einem RAID-Controller und dem Pool-Typ "LVM-Thin" nicht möglich und es muss zwingend ZFS zum Einsatz kommen. Proxmox VE unterstützt nämlich die Einrichtung von asynchronen Storage-Replikationen, die die ZFS-Features "ZFS send" und "ZFS receive" verwenden. Für maximale Flexibilität in die Zukunft setzen Sie auf ZFS bei Ihrem ersten Single-host.

Ein einzelner Server hat leider auch ein paar Nachteile: Es gibt keine Livemigration, keine Hochverfügbarkeit, Systemupdates oder -upgrades und darauffolgende Reboots unterbrechen den Betrieb der virtuellen Ressourcen und ein Hardwareausfall führt gegebenenfalls zu mehrtägiger Downtime oder sogar Datenverlust. Um diese Schwierigkeiten aus der Welt zu schaffen oder um zumindest ihre Auswirkung auf den Unternehmensbetrieb abzuschwächen, gibt es Proxmox-Clustering.

Sobald Sie mehr als einen Node in einer Oberfläche verwalten wollen, führt kein Weg am Clustering vorbei. Dank des Web-UI lassen sich mehrere Nodes in einem Userinterface zusammenfassen und diese (auch ohne shared oder repliziertes Storage) für die Livemigration von VMs (trotz lokalem Storage) und dem Einspielen von Updates und Upgrades ohne Downtime verwenden.

Selbst wenn Sie kein geteiltes oder repliziertes Storage wie etwa ZFS oder Ceph einsetzen, können Sie schon vom Clustering profitieren. Zum Beispiel ist die Livemigration von VMs Storage-unabhängig. Ist der Speicher nicht geshared, wird einfach die komplette VM-Disk über das Netzwerk kopiert. Ist die Übertragung komplett, findet ein Switch auf die neue Lokation der VM statt. Das Übertragen kompletter VM-Disks benötigt jedoch sehr viel Zeit und zudem muss das Netzwerk eine hohe Bandbreite aufweisen. Besser ist es, einen ersten Cluster auf ZFS-Basis aufzubauen, der folgende Features mitbringt:

- Asynchrone Replikation des Storage-Pools

- Schnellere Livemigration von VMs

- Einspielen von Updates und Upgrades ohne Downtime

- HA-Aktivierung möglich

- Automatisches Failover nach einem Ausfall des Servers

Dieses Szenario erreicht den vollen Fea-ture-Umfang, was Hochverfügbarkeit und Ausfallsicherheit betrifft. Die Mindestanforderungen dafür sind zwei vollwertige PVE-Server für Compute und Storage (HCI mit ZFS), ein Quorum-Device (Raspberry oder Low-Energy-System), ein dediziertes Cluster-Netzwerk (Corosync-Dienst) sowie ein dediziertes Storage-Netzwerk (asynchroner Sync und ZFS).

Berücksichtigen Sie dies bei der Planung und Installation, haben Sie nach dem initialen Setup die Möglichkeit, je Ressource eine Storage-Replikation einzustellen, die in einem definierten Zeitraum automatisch läuft. Wichtig ist hierbei ein eigenes Storage-Netzwerk für die Replikation bereitzustellen, das gerne auch direkt zwischen den beiden Nodes verkabelt werden kann und somit ohne eigene Switche auskommt. Erlaubt es die Hardware, verbauen Sie ruhig 25- bis 100-GBit/s-Netzwerkkarten rein für diesen Zweck. Je schneller das Netzwerk, desto zügiger passiert der Abgleich der Daten zwischen den Nodes, desto häufiger lässt sich die Storage-Replikation durchführen. Je öfter die Replikation stattfindet, desto geringer ist das Datendelta, das Sie bei einem Ausfall einer Node haben. Die Daten, die seit dem letzten Sync nicht repliziert wurden, sind nämlich bei einem Ausfall des Servers erstmal verloren, da das HA-Modul die Ressourcen auf dem zweiten Server mit dem Datenstand des letzten ZFS-Syncs automatisch startet.

Ob dieser Datenverlust (der bei starkem Netzwerk oft kleiner als eine Minute ist) für Ihr Unternehmen tragbar ist, das müssen Sie selbst einschätzen und bewerten. Einmal je Ressource eingerichtet, kümmert sich Proxmox selbstständig um die Storage-Replikation, auch nach dem Ausfall einer Node. So wird automatisch ein Richtungswechsel hinsichtlich des ZFS-Syncs durchgeführt, sodass der ausgefallene Server nach erfolgreichem Recovery die neu geschriebenen Daten erhält, obwohl er vorher die "Sender"-Rolle hatte.

Dank ZFS-Sync profitieren Sie außerdem von einer schnelleren Livemigration zwischen den beiden Nodes, da das System nur die noch nicht vorhandenen Daten (seit dem letzten Sync) übertragen muss. Wichtig ist jedoch, auf jedem Node denselben Pool-Namen zu verwenden, da sonst keine Übernahme der Ressourcen im HA-Fall möglich ist. Ansonsten funktionieren HA und auch der Storage-Sync zwischen den beiden ZFS-Nodes nicht.

Das Setup hat allerdings auch Einschränkungen: Es skaliert nicht mit mehreren Nodes, da sich ein Sync immer nur sinnvoll zwischen zwei Nodes einrichten lässt. Außerdem gibt es ein Datendelta, das Sie im HA-Fall verlieren. Um dies zu vermeiden und synchrone Daten zwischen allem Nodes zu haben, kommen Sie nicht an einem Proxmox-Ceph-Cluster vorbei.

Ceph [3] ist ein selbstheilender, sich selbst verwaltender Open-Source-Speicher, der seit dem ersten Release 2012 immer mehr an Beliebtheit gewinnt und sich vor allem durch Verlässlichkeit, aber noch viel mehr durch die nahezu unendliche Skalierbarkeit des Storage auszeichnet. So setzt beispielsweise auch das CERN (Europäische Organisation für Kernforschung) seit etlichen Jahren auf Ceph und betreibt unter anderem einen 20 PByte großen Storage-Cluster auf Ceph-Basis. Proxmox VE hat seit 2014 eine Integration von Ceph.

Ceph steht aktuell in Version 18.2 (Codename "Reef") bereit und ist eine verteilte Speicherlösung, die mit ihrem Kern "RADOS" ermöglicht, ein zentrales Storage über eine beliebige Anzahl von Servern (drei und mehr) zu erstellen. Das System ist dabei sehr flexibel und erlaubt eine ortbasierte Ablage von Daten über verschiedene Entitäten. So kann die erste Umgebung zum Beispiel aus einem Storage-Pool mit Dreifach-Replikation bestehen, sodass jeder Server eine Kopie der Daten erhält.

Und wollen Sie im Laufe der Zeit Ihre Umgebung aufstocken und einen weiteren Raum mit drei zusätzlichen Servern bereitstellen, ist dies kein Problem. Mit etwas Planung und einem dritten Raum für das Storage-Quorum können Sie live und on-the-fly den 3-Node-Cluster mit dreifacher Replikation zu einem Multi-Room-Cluster (sechs Storage-Nodes in zwei Räumen und ein Raum mit einem Quorum-Node) mit vierfacher Replikation umbauen. Dieses hochskalierbare Storage dient dem Einsatz von Ceph für virtuelle Blockdevices (RBD), als File-Storage (CephFS) sowie als Swift- und S3-kompatibler Objektspeicher (RGW).

Letzterer ist der Vollständigkeit halber aufgezählt, aber in PVE nicht verfügbar, da sich der Ceph-Support in Proxmox VE hauptsächlich auf den Einsatz des Speichers für virtuelle Maschinen und Container und die Ablage von Files (wie etwa ISO- Dateien oder Container-Templates) beschränkt. Mehr benötigen Sie auch tatsächlich für eine stabile, ausfallsichere und hochskalierbare Storage-Umgebung nicht, die sich perfekt in die Proxmox-VE-Oberfläche integriert und sich mittlerweile komplett von dort aus installieren, konfigurieren, administrieren und warten lässt.

Die folgenden fünf Punkte sorgen für einen idealen Start für Proxmox VE mit einem Ceph-Cluster:

- Mindestens drei Server für Ceph

- Mindestens vier Datenträger je Server

- Verwenden Sie keine HDDs als Storage für Ceph, sondern nur Flash

- Aufbau eines dedizierten Netzwerks für Ceph mit 25 GBit/s oder mehr

- Einsatz eines Monitoringtools zum Tracking von Disk- und Pool-Usage

Diese fünf Punkte sind unserer Empfehlung nach nicht verhandelbar und sollten auf jeden Fall eingehalten werden. Gehen wir daher genauer auf diese Aspekte ein. Zuerst beginnt ein Ceph-Cluster immer mit einem Minimum von drei Nodes, darunter können und sollten Sie nicht mit dem Storage arbeiten. Es sind genau drei, weil ein Ceph Pool in Proxmox VE im Standard immer mit einer dreifachen Replikation arbeitet, das heißt: Daten werden immer dreimal geschrieben. Damit das klappt, benötigen Sie natürlich mindestens drei Server, da die Replikate sich immer über die verfügbare Anzahl an Servern hinwegverteilen. Dieser Parameter nennt sich "SIZE" und gibt an, wie oft Daten über das gesamte Cluster hinweg gespeichert werden.

Ein weiterer Parameter namens "MIN-SIZE" spielt auch eine große Rolle im System, da dieser angibt, wie viele Datenkopien vorhanden, also online und verfügbar, sein müssen, damit der gesamte Storage-Pool weiterhin funktioniert und erreichbar ist. Dieser Parameter ist standardmäßig auf "2" gesetzt und Sie sollten ihn aus Sicherheitsgründen auch niemals reduzieren. Die Differenz aus SIZE und MIN-SIZE ergibt die Anzahl an Servern, die Sie gleichzeitig verlieren können, ohne dass es zum kompletten Stillstand des Storage-Systems kommt. Das heißt, bei einem Drei-Node-Proxmox-Ceph-Cluster darf maximal ein Server ausfallen, ohne dass es zu einer Downtime kommt. Verlieren Sie mehr als einen Server, wird die MIN-SIZE (minimale Anzahl an Replikaten) unterschritten und Ceph schaltet sich beziehungsweise den entsprechenden Pool aus Sicherheitsgründen ab, um das letzte Datenreplikat zu schützen.

Dabei ist es außerdem irrelevant, wie viele Ceph-Server Sie haben – auch bei fünf Ceph-Nodes dürfen Sie bei einer Drei/Zwei-Umgebung maximal einen Server gleichzeitig verlieren, da Ceph die Daten gleichmäßig über alle Nodes hinweg verteilt und ablegt. Wollen Sie mehrere Server gleichzeitig verlieren können, geht das nur, indem Sie den Replikationsfaktor hochdrehen, wohingegen die MIN-SIZE gleichbleibt, beispielsweise ein Vier/Zwei-Setup also mit SIZE=4 und MIN-SIZE=2.

Besagte Replikate verteilen sich über das Netzwerk auf alle Server. Deswegen ist sehr wichtig, dass das Ceph-Netzwerk eine geringe Latenz und eine hohe Bandbreite aufweist. Kleiner als 25 GBit/s ergibt bei aktueller Flash-Performance von NVMe keinen Sinn mehr, da Sie sich damit einen großen Flaschenhals im Netzwerk bauen würden. Dabei ist es wichtig zu wissen, dass Daten immer erst komplett geschrieben werden müssen, bevor der Storage-Client ein Write-Acknowledgement bekommt. Daten werden dabei nicht parallel, sondern seriell geschrieben, was die Bedeutung eines schnellen Storage-Netzwerks nochmals unterstreicht.

Verfügen Sie noch nicht über eine 25-GBit/s-Netzwerk-Infrastruktur und wollen dafür auch keine neuen, teuren Switches anschaffen, gibt es einen Trick: das "Full Meshed Network for Ceph". Dieses Verfahren ermöglicht eine Direktverkabelung von drei Proxmox- und Ceph-Servern als HCI und spart circa 10.000 bis 20.000 Euro im Vergleich zu einer neuen Switch-Infrastruktur.

Hierbei werden die Server jeweils miteinander "im Ring" verkabelt, sodass jede Maschine zu den anderen eine Verbindung hat und darüber kommunizieren kann. Proxmox bietet hierfür Anleitungen in seiner Dokumentation [4], um diesen Full-Mesh entsprechend einzusetzen und zu konfigurieren. Neben den anfallenden Kosten für neue Netzwerkgeräte bietet dieses Vorgehen zudem den Vorteil einer hohen Ceph-Performance, da sich 25- oder auch 100-GBit/s-Netzwerkkarten kostengünstig einsetzen lassen.

Der einzige Nachteil ist die Erweiterbarkeit des Systems. Aufgrund der Direktverkabelung lässt es sich nicht um zusätzliche Nodes ausbauen, da die Anzahl an Ports in Servern endlich ist. Ein Drei-Node-Cluster bleibt somit in der Regel auch immer ein solcher. Geld sparen Sie in diesem Szenario, indem Sie mehrere kleine Cluster bauen statt eines großen. Möchten Sie trotzdem wechseln, lösen Sie in einem Wartungsfenster die Direktverkabelung auf und setzen sie künftig über Switches um. Da langfristig die PVE-Web-UI auch eine Livemigration von Ressourcen über Cluster hinweg bieten soll (derzeit via CLI möglich), sind mehrere kleine und günstigere Insellösungen vielleicht sogar keine schlechte Idee.

Neben dem Netzwerk und der Mindestanzahl an Servern spielt auch die Anzahl der Datenträger (mindestens vier je Server) und natürlich das Sizing von CPU und RAM eine große Rolle. Hierfür gilt die Faustregel, pro Ceph-Datenträger (OSD) mindestens 4 bis 8 GByte Arbeitsspeicher und pro Ceph-Datenträger (OSD) mindestens einen CPU-Thread einzusetzen. Die Ressourcen für die anderen Ceph-Dienste (Ceph-MON, Ceph-MGR und Ceph MDS) sind in der Regel vernachlässigbar und benötigen fast keine Ressourcen.

Schnell ist auf jedem Node Proxmox VE installiert, danach konfigurieren Sie das Netzwerk für den PVE-Cluster (Corosync), den Storage (Ceph) und für die VMs (vmbr0) auf allen Nodes und erstellen über die Oberfläche einen Cluster. Ist dies passiert, spielen Sie Ceph auf jedem Node ein und richten die Web-UI ein. Hierbei ist wichtig, dass Sie vor allem das richtige Netzwerk (Storage) für Ceph auswählen, da dieses mit seiner Bandbreite primär über die Performance von Ceph entscheidet. Eine nachträgliche Änderung ist nicht so einfach möglich. Nach der Installation von Ceph auf jedem Node erstellen Sie die Ceph-Monitore, -Manager, -OSDs (Datenträger) und letztendlich den -Pool genau in dieser Reihenfolge. Dies passiert alles über die Oberfläche, eine Konfiguration über das CLI ist nicht mehr notwendig. Nachträgliche Änderungen am System erfolgen ebenfalls über die Weboberfläche und eine Erweiterung des Systems um weitere Hosts, Datenträger und so weiter ist jederzeit und ohne Downtime möglich.

Relativ schnell steht danach Ihr Drei-Node-Cluster mit Proxmox VE und Ceph und dann können Sie auch schon mit dem Erstellen von VMs auf dem redundanten Storage beginnen. Wichtig dabei ist, jede Ressource auch ins HA-Programm mitaufzunehmen. Ist dies geschehen, starten zukünftig Ressourcen eines ausgefallenen Hosts automatisch auf den noch verfügbaren Hosts. Die Downtime hierbei beträgt circa drei bis fünf Minuten, bis Ressourcen auf den neuen Servern wieder im Login stehen. Ceph stellt nach dem Recovery des ausgefallenen Hosts automatisch sicher, dass dieser alle neuen Daten erhält und somit die dreifache Replikation wieder voll hergestellt ist.

Als wir diesen Workshop mit dem Fokus Proxmox VE für KMU planten, nahm das VMware-Broadcom-Übernahmedesaster gerade erst seinen Anfang und es war nicht abzusehen, dass sich bereits im April 2024 zahlreiche IT-Verantwortliche nach Alternativen zu VMware vSphere umsehen. Proxmox VE ist definitiv eine davon. Es selbst, wie auch der Einsatz von Ceph unter Proxmox VE erfordern keine Lizenz. Kosten entstehen für Service und Support durch den Anbieter in Form der jeweiligen Subskriptionen, die jedoch auch Enterprise-Pakete und Support für Ceph beinhalten. Das hyperkonvergente System aus PVE und Ceph ermöglicht Ihnen insbesondere mit dem "Full Meshed Network for Ceph" einen günstigen Start in die Welt der Hochverfügbarkeit.