Tipps für die Suche nach den geeigneten Servern und HCI-Systemen Virtualisierung mit Proxmox – Welche Hardware passt?

Autor / Redakteur: Jonas Sterr und Ulrich Wolf* / Ulrike Ostler

Die Beliebtheit der Virtualisierungsplattform „Proxmox VE“ steigt seit etwa zehn Jahren langsam, aber kontinuierlich an. Sie ist vielseitig, unterstützt klassische Virtualisierung genauso wie Container-Infrastrukturen. Doch genau das kann die Suche nach passender Hardware kompliziert machen. Hier gibt es Hilfe.

Firmen zum Thema

Drei Knoten mit möglichst identischer Ausstattung stellen für High Availability Cluster und HCI mit „Proxmox“ das Minimum dar.
Drei Knoten mit möglichst identischer Ausstattung stellen für High Availability Cluster und HCI mit „Proxmox“ das Minimum dar.
(Bild: Thomas-Krenn AG)

Als Open-Source-Alternative zu „VMware vSphere“ und „Microsoft Hyper-V“-Technologie bietet Proxmox VE Server- und Storage-Virtualisierung ohne Lizenzkosten auf der Basis stabiler, ausgereifter Technologien wie „Linux KVM“, Linux Containern, „ZFS“und „Ceph“. Enterprise-Support in Form von Subskriptionspaketen ist optional, aber ausgesprochen günstig. So sind im Standard-Paket für knapp 400 Euro pro Jahr und CPU-Sockel beispielsweise schon zehn jährliche Support-Tickets enthalten.

Mit Proxmox VE lässt sich klassische Server-Virtualisierung genauso realisieren wie hyperkonvergente, hoch skalierbare Systeme, inklusive Hochverfügbarkeit für Storage und VMs. Zusätzlich zur Hardware-Virtualisierung ist eine Container-Infrastruktur integriert. Container und VMs lassen sich also unter einer gemeinsamen Oberfläche weitgehend einheitlich verwalten.

Bei einem derart vielseitigen System wird die Auswahl geeigneter Hardware für Server, Storage und Netzwerk zur Herausforderung. Sie wird durch folgende Anforderungen bestimmt:

  • 1. Kompatibilität mit Proxmox VE
  • 2. Anforderungen der zu virtualisierenden Anwendungen
  • 3. Art der verwendeten Virtualisierungstechnik (VMs oder Container)
  • 4. Art des eingesetzten Filesystems und der eingesetzten Storage-Technologie
  • 5. Anforderungen an Verfügbarkeit/Business Continuity

Im Gegensatz zu VMware oder anderen Closed-Source-Hypervisors existieren für Proxmox VE keine offiziellen Hardware-Zertifizierungen oder Hardware-Kompatibilitätslisten. Dennoch ist das Risiko, auf inkompatible Komponenten zu stoßen, in der Praxis überschaubar.

Die Anforderungen

Proxmox VE basiert auf einem Unterbau aus „Debian GNU/Linux“. Alle Server, auf denen sich ein aktuelles Debian-Linux installieren lässt, sollten also prinzipiell auch mit Proxmox VE funktionieren. Die Mindestanforderungen aus der Software-Dokumentation sind ausgesprochen moderat. Sie erheben aber keinesfalls den Anspruch, für ausreichende Performance eines jeden individuellen Systems zu garantieren.

Wer über wenig Erfahrungen mit Debian oder Proxmox VE verfügt oder auf Nummer sicher gehen will, sollte seine Systeme bei einem Anbieter mit ausreichend großer Linux-Erfahrung kaufen. Die A-Brands führen zwar zum Teil Kompatibilitätslisten für diverse Linux-Distributionen. Debian bleibt dort jedoch oft außen vor, da hinter diesem Community-Projekt kein Unternehmen steht.

Als einziger Server-Anbieter weltweit ist die Thomas-Krenn.AG offizieller Technologiepartner der Proxmox Server Solutions GmbH. Fast alle Systeme des bayerischen Herstellers sind mit Proxmox (und Debian GNU/Linux) getestet. Über die Filterfunktion auf der Website lässt sich leicht feststellen, ob die Komponenten des Wunsch-Server kompatibel sind.

Kaum Overhead bei virtuellen Maschinen

Bei der Kapazitätsplanung sollten die Anforderungen der zu virtualisierenden Anwendungen an erster Stelle stehen. KVM, der Hypervisor in Proxmox, bringt zwar einen gewissen Overhead mit, doch selbst unter ungünstigsten Bedingungen ist dieser kaum größer als etwa 7 Prozent, in den meisten Fällen weit darunter.

Voraussetzung dafür ist, dass im Gast-Betriebssystem paravirtualisierte Treiber beziehungsweise Passthrough für PCI-Geräte zum Einsatz kommen. Dann können die Anforderungen an CPU, RAM und Netzwerk in erster Näherung wie beim Betrieb auf einem physischen System (Bare Metal) angenommen werden. Noch geringer ist der Overhead, wenn die Anwendungen innerhalb von Linux-Containers laufen können.

Prinzipiell läuft Proxmox VE auf jeder CPU mit „Intel VT“- oder „AMD-V“-Technik. Hardware-Virtualisierung profitiert aber extrem von CPUs mit vielen Kernen. Bei höheren Lasten empfiehlt sich auch ein Dual-Socket-System.

Besonders speicherhungrig ist das Proxmox-Hostsystem selbst nicht. Zwei oder vier Gigabyte reichen aus. Diese werden einfach zum geplanten RAM-Bedarf der virtuellen Maschinen oder Container addiert.

In Produktivsystemen sollten mindestens zwei physische Netzwerk-Interfaces pro Node vorhanden sein, um den Traffic, der beim Cluster-Management, bei Replikation und Migration von VMs entsteht, von der 'Nutzlast', also dem Datenverkehr der virtuellen Maschinen und Container selbst, zu trennen. Mehr Netzwerkkarten erhöhen die Flexibilität im Betrieb. Beispielsweise lassen sich durch Bonding eventuell aufgetretene Engpässe oder Ausfälle vermeiden.

Und dann kommt Storage

Dieses unkomplizierten Regeln gelten aber nur so lange, wie die Storage-Planung unberücksichtigt bleibt. Bei dieser bietet Proxmox VE viel Flexibilität, von der Shared-Storage-Anbindung über zahlreiche block- oder filebasierte Protokolle bis zum Set-Up hyperkonvergenter Systemen ausschließlich mit Bordmitteln.

Für letztere kommt vor allem der verteilte Objektspeicher Ceph in Frage, für fehlertoleranten lokalen Speicher, auch mit sehr hohen Kapazitäten, ist ZFS die einfachere Lösung. Beide Systeme können im weitesten Sinn zum Software Defined Storage (SDS) gezählt werden.

Software Defined Storage braucht Power im Server

Bei beiden ist auch eine großzügig dimensionierte Hardware-Ausstattung für eine hinreichende Performance unbedingt nötig. Flaschenhälse an den verschiedensten Punkten können das Gesamtsystem schnell ausbremsen. Das betrifft nicht nur die Storage-Medien selbst, sondern auch RAM- und CPU-Ausstattung sowie das Netzwerk.

RAID-Controller hingegen werden weder für ZFS noch für Ceph benötigt. Deren Funktionalität (und mehr) wird vollständig in der Software abgebildet. Vorhandene RAID-Controller müssen im Passthrough-Modus ohne eigenes RAID-Layer betrieben werden (bei LSI als IT-Modus bezeichnet). Bei Neuanschaffungen sind Host Bus Adapter die bessere Wahl, sofern nicht ohnehin NVMe-Medien direkt angeschlossen werden.

Ceph – Mehr Ressourcen für viel Sicherheit und Skalierbarkeit

Vor allem Ceph steht nicht ganz zu Unrecht im Ruf, hardwareseitig anspruchsvoll zu sein. Je mehr Storage-Medien es verwaltet, um so mehr RAM und CPU-Kapazität ist nötig. Die Kapazität der einzelnen Medien wirkt sich hingegen kaum aus.

Ein Storage Medium entspricht in der Ceph-Terminologie in der Regel einem „Object Storage Device“ (OSD). Für Storage Nodes (OSD Nodes) empfiehlt sich, mindestens einen CPU-Thread pro SSD oder HDD zu reservieren, die von Ceph genutzt wird, zusätzlich zu den Threads beziehungsweise Cores für die virtuellen Maschinen und das Host-System selbst. Dazu werden in der Praxis meist 8 bis 10 GB RAM pro OSD verwendet. (Die Ceph-Dokumentation empfiehlt 3GB bis 5GB RAM pro OSD zuzüglich der Kapazitäten für Cluster-Management und Metadaten).

Neben den OSD Nodes benötigt Ceph auch Monitor- und Manager-Server. Setzt man „CephFS“ als Filestorage ein, kommt noch ein oder mehrere Metadaten-Server hinzu. All diese Dienste können auf den gleichen physischen Servern wie die OSD Nodes betrieben werden, benötigen dort aber zusätzliche Ressourcen. Das gilt vor allem für den Monitor-Dienst, für den je nach Cluster-Größe zwischen 1 und 10 GB und zwei Cores zu veranschlagen sind.

Die Verbindungen

Ceph-Knoten erzeugen hohe Netzwerklasten, für die Interconnects innerhalb des Ceph-Clusters sollte also mindestens 10-GBit-Technik zum Einsatz kommen, besser 25-GBit-Ethernet. Um den Durchsatz von NVMe-Speicher auch netzwerkseitig voll nutzen zu können, ist oft sogar 100-Gbit-Infrastruktur nötig.

Lange Zeit galt es als Best Practice, Public Network und Cluster-Network auch physisch zu trennen. Mittlerweile bevorzugen viele technische Consultants ein nicht gesplittetes Netzwerk mit entsprechend höherer Bandbreite.

Auch in der Proxmox-Konfiguration ist dies die Default-Einstellung. Je nach Setup sind also zwei oder vier Netzwerk-Ports pro Server mindestens erforderlich, da aus Gründen der Ausfallsicherheit das Netzwerk immer redundant aufgesetzt werden sollte.

Die Storage-Medien

Als Storage-Medien sind für kleine und mittlere Kapazitäten derzeit NVMe-SSDs die beste Wahl, die mittlerweile auch für Server kaum noch teurer sind als SATA-SSDs, aber dank PCIe-Anbindung um ein vielfaches schneller. Dabei kann bei größeren Storage-Arrays die Anzahl der verfügbaren PCIe-Lanes zum limitierenden Faktor werden.

Deren Gesamtzahl hängt vom Mainboard beziehungsweise der CPU ab. Die meisten Enterprise-SSDs benötigen vier Lanes, jedoch sind auch besonders schnelle Exemplare mit acht Lanes im Handel.

Für „Proxmox“-basierte HCI-Lösungen mittlerer Storage-Kapazitäten haben reine NVMe-Systeme das beste Preis-Performance-Verhältnis.
Für „Proxmox“-basierte HCI-Lösungen mittlerer Storage-Kapazitäten haben reine NVMe-Systeme das beste Preis-Performance-Verhältnis.
(Bild: Thomas-Krenn AG)

Außerdem müssen andere über PCIe angeschlossene Geräte wie Netzwerkkarten berücksichtigt werden, die ebenfalls mehrere Lanes benötigen. Bei sehr großen Storage-Kapazitäten, etwa bei Backup- oder Archivsystemen, empfiehlt sich eine Kombination aus konventionellen SATA-Festplatten und NVMe-Speicher als Cache Device.

ZFS – Fehlertoleranz und hohe Kapazität auf Single-Node-Systemen

Mit dem bis in den Petabyte-Bereich skalierenden, fehlertoleranten Dateisystem ZFS ließe sich theoretisch auch verteilter Storage über iSCSI betreiben, in der Praxis ist es mit Proxmox aber nur für Single Nodes relevant, da Ceph für hyperkonvergente Systeme wesentlich besser integriert ist.

Die Anforderungen von ZFS an CPU und RAM sind möglicherweise etwas geringer als bei Ceph, aber dennoch nicht zu vernachlässigen. Die Lese-Performance hängt hier wesentlich von den Einstellungen des so genannten Adaptive Replacement Cache (ARC) und dem Second Level Adaptive Replacement Cache (L2ARC) ab. Der ARC wird immer im Hauptspeicher gehalten, für den L2ARC sollten die schnellsten Storage-Medien im System vorgehalten werden.

Bei kleineren aktiven Datenmengen kann man auf den L2ARC verzichten. Als sehr grober Richtwert sollten für den Anfang für ZFS etwa 7 bis 8 GB RAM plus je ein GB für jedes TB Storage-Kapazität eingeplant werden. Im Vergleich zu Ceph spielt aber die CPU-Geschwindigkeit bei ZFS eine kleinere Rolle. Mindestens vier Kerne und 2,8 Gigahertz(GHz) sind zu empfehlen. Konkrete Anforderungen hängen aber stark davon ab, wie ZFS genutzt wird. Vor allem beim Einsatz von Dedpulizierung steigen die Anforderungen an RAM und CPU stark an.

Hochverfügbarkeit

Selbst wenn mit der eingebauten HA-Lösung bei Proxmox sehr einfach ist, hochverfügbare Cluster zu erstellen, sollte man dennoch auf die Ausfallsicherheit der einzelnen Server Wert legen. Denn die automatische Migration von VMs kann durchaus einige Minuten dauern. Redundante Netzteile und ECC-RAM belasten das Budget kaum, erhöhen aber spürbar die Betriebssicherheit.

Ein Hochverfügbarkeits-Cluster benötigt bei Proxmox mindestens drei Server. In Produktionsumgebungen ist es in der Regel praktisch, wenn diese die gleiche Hardware-Ausstattung besitzen, um sicherzustellen, dass eine beim Server-Ausfall migrierte virtuelle Maschine überall die gleichen Bedingungen vorfindet. Spar-Varianten mit nur zwei “Arbeitsservern”, externem Shared Storage und einem sehr kleinen System als Quorum-Server sind zwar möglich, bieten aber geringere Ausfallsicherheit bei höherer Komplexität.

* Für den Artikel haben Jonas Sterr, Senior Solution Engineer Ceph bei der Thomas-Krenn AG und der freie Journalist Ulrich Wolf zusammengearbeitet.

(ID:47357251)