Jedes Jahr aufs Neue überlege ich, ob ich etwas in meinem Heimnetz grundlegend ändern sollte. Und dieses Mal wollte ich das Thema Hypervisor mit mehr Elan und vor allem auch etwas mehr Budget angehen. In letzter Zeit werden ja immer wieder Thin Clients oder Mini-PCs als Raspberry Pi Alternative in diversen Blogs und YouTube-Videos vorgestellt.
Die kleinen Rechenkünstler brauchen nämlich ebenso wenig Strom und sind häufig sogar günstiger als die beliebten Einplatinenrechner. Darüber hinaus werden hier performante x86-Prozessoren verbaut. Konkret bedeutet dies, dass du in puncto Betriebssystem oder auch Docker-Image die Qual der Wahl hast. Das hat mich dann auf eine interessante Idee gebracht.
Anstelle auf meinen 3 lüfterlosen Thin Clients einfach Rocky Linux auszurollen und direkt im Anschluss Kubernetes aufzusetzen, probiere ich mal das Aufsetzen eines kleinen Proxmox-Clusters aus. Und das hat recht gut funktioniert. Ein paar Abstriche muss man aber natürlich machen. So habe ich weder ein Raid noch zusätzliche Netzwerkschnittstellen für die interne Cluster-Kommunikation.
Aber mit solchen Abstrichen kann ich im Homelab gut leben. Das gilt übriges auch für den Punkt Storage. Weder läuft hier das in Proxmox integrierte Ceph-Speichersystem, noch habe ich einen anderen Shared Storage in Benutzung. Meine Workloads lassen sich also nur durch einen langwierigen Kopiervorgang zwischen den Nodes transferieren und hochverfügbar ist mein Cluster damit auch nicht.
Allerdings habe ich seit ein paar Tagen noch einen vierten Thin Client im Einsatz, auf dem Debian samt einem installierten NFS-Server läuft. Sicherungen meiner Spielwiese mache ich also schon von Zeit zu Zeit. Es wäre zudem auch problemlos möglich, diese Freigabe als Speicher für die Festplatten meiner Linux-Container oder virtuellen Maschinen zu nutzen. Als notwendig erachte ich das aber nicht.
Doch genug über mein eigenes Setup geschnackt. In diesem kurzen Beitrag möchte ich dir zeigen, wie du selbst mit 3 Thin Clients ein geräuschloses Proxmox-Cluster in deinem Nachttischchen betreiben kannst. Und die Best Practices wie zum Beispiel den Einsatz von getrennten Netzwerken oder eines Shared-Storage samt Backup-Lösung erkläre ich auch noch.
Welche Hardware-Konfiguration kommt bei mir zum Einsatz?
Ursprünglich wollte ich kein Proxmox-Cluster aus den 3 kleinen PCs bauen. Ziel war ein Kubernetes-Cluster mit RKE2. Allerdings habe ich aufgrund der höheren Flexibilität doch noch meinen Plan geändert. Bei Bedarf kann ich so nämlich schnell eine virtuelle Maschine oder einen Linux-Container ausrollen. Und das ist im Labor logischerweise Gold wert.
Ich benutze für mein Proxmox-Cluster drei HP T630 Thin Clients mit AMD-Prozessor. Beim Kauf habe ich darauf geachtet, dass jede verbaute CPU über die Hardware-Virtualisierungserweiterung SVM verfügt und sich diese auch im BIOS aktivieren lässt. Die konkrete Ausstattung der künftigen Proxmox-Nodes habe ich dann aus den Resten vergangener Projekte zusammen gekratzt.
Herausgekommen ist dabei die folgende Konfiguration:
- 2 × 8 GB DDR4 RAM & 1 × 16 GB DDR4 RAM
- 2 × 120 GB M.2 SSD & 1 × 256 GB M.2 SSD
- 3 × AMD GX-420GI (2,2/2,0 GHz & 4 Kerne)
An meiner Hardware-Auflistung solltest du dir aber kein Beispiel nehmen. Es ist nämlich immer ratsam, bei einem Cluster auf eine vollständig einheitliche Hardware zu setzen. Das ist bei Proxmox zwar nicht ganz so entscheidend wie im VMware-Universum, aber man schließt so von vorneherein diverse Fehlerquellen aus. Außerdem vereinfacht man so auch den administrativen Aufwand.
Abseits dessen solltest du dir Gedanken darüber machen, wie viele Netzwerkbuchsen du brauchst. Bei mir läuft die Cluster-Kommunikation und der gesamte restliche Traffic über eine Netzwerkschnittstelle. Und das ist gar nicht empfehlenswert. Das bei Proxmox zum Einsatz kommende Corosync benötigt nämliche geringe Latenzen und die sind so schon mal nicht immer gegeben.
Und eine dritte NIC pro Clusterknoten schadet ebenfalls nicht. Darüber würde ausschließlich der Verkehr des Ceph-Speichers laufen. Da hier permanent alles repliziert wird, kommen schnell große Datenmengen zustande. Auch ein NAS kann und sollte man über eine eigene NIC anbinden. Doch selten lassen sich in den Geräten weitere PCI-Steckarten verbauen.
Das ist ein großes Ärgernis und hält viele davon ab, die kleinen, lüfterlosen Geräte in einem Hypervisor-Cluster zu nutzen. Zum Glück gibt es inzwischen aber zuhauf zuverlässige USB-Netzwerkkarten am Markt. Weiterhin sollte man immer 2 gleich große Festplatten pro Clusterknoten benützen. Ein ZFS-Software-Raid für Proxmox selbst lässt sich direkt bei der Installation anlegen.
Und an der Ausfallsicherheit der Festplatten sollte man selbst bei einem Hobby-Cluster nicht sparen. Das gilt übriges auch für deren Bauweise. Laute und vor allem langsame HDDs gehören der Vergangenheit an. Sie mögen zwar günstig sein, aber mehr spricht nicht mehr für sie. Außerdem passen in die meisten Thin Clients eh nur noch schnelle M.2 SSDs und die sind ja auch nicht mehr so teuer.
Wie wird denn das Netzwerk für so ein Cluster eingerichtet?
Best Practices in Bezug auf Hypervisor-Cluster gibt es zur Genüge. Die Wichtigsten von ihnen habe ich auch schon kurz im Abschnitt weiter oben angerissen. Ich empfehle immer das Anlegen von mehreren getrennten Netzwerken. Ich gehe bei einer Standardinstallation wie folgt vor:
- Vlan 100 für das Cluster-Backend (Corosync oder VM-Transfers)
- Vlan 200 für den Shared-Storage (Ceph oder NAS)
- Vlan 300 für den Backup-Speicher (NAS, Block- oder Objekt-Speicher)
- Tagged Uplink (VMBridge samt IP für den administrativen PVE-Zugang)
Doch warum mache ich es so kompliziert? Einerseits begrenzt man den Broadcast-Traffic, andererseits kommen sich die verschiedenen Services beziehungsweise deren Datenströme so nicht in den Weg. Sinnvoll ist ein Vlan für den internen Cluster-Traffic, um die Latenzen für Corosync gering zu halten. Zudem ist es damit nur schwer möglich, als Hacker den internen Cluster-Verkehr mitzulesen.
Ebenfalls ein eigenes Netz verträgt der Speicher. Ob es sich dabei um die integrierte Ceph-Variante oder um ein kleines NAS handelt, spielt dabei keine Rolle. Hier werden nämlich große Datenmengen transferiert und diese stören den restlichen Datenverkehr ungemein. So wird beispielsweise die Latenz erhöht. Wenn es möglich ist, würde ich über 2,5 Gbit/s oder sogar 10 Gbit/s nachdenken.
Wer viele Vlans über eine einzige VMBridge in Proxmox zur Verfügung stellen möchte, wäre auch hier mit etwas mehr Power gut bedient. Angebunden wird so ein vSwitch an einem tagged Port. Die restlichen NICs hängen dann an untagged Ports wie normale Clients. Wer möchte, kann die Ausfallsicherheit noch deutlich steigern, in dem er 2 Netzwerkkarten und 2 Switches einsetzt.
Empfehlen kann ich dabei gestackte Switche. Es handelt sich hierbei um 2 physische Geräte, die aber einen logischen Verbund darstellen. Können diese noch mit dem Protokoll LACP umgehen, ist nicht nur die Ausfallsicherheit gewährleistet, sondern die Bandbreite ist auch noch größer. Allerdings hat man damit 2 × 1 Gbit/s und nicht 1 × 2 Gbit/s.
Wem stackbare Switches zu teuer sind, der kann auch ein Aktiv-Passiv-Bonding in der Weboberfläche von Proxmox konfigurieren. Angeschlossen werden die beiden Kabel dann jeweils an unterschiedliche Switches. Dort muss man außer einem untagged Port auch nichts weiter einrichten. Da immer nur auf einer Leitung gefunkt wird, gibt es auch keine Probleme mit Spanning Tree.
Wie setzt man Shared-Storage günstig mit Proxmox um?
Bis vor ein paar Jahren war es bei kleinen Hypervisor-Clustern völlig normal, eine NAS als Storage für die laufenden VMs sowie die Container zu nutzen. Leider wurde der Speicherort nicht selten auch noch für die nächtlichen Sicherungen herangezogen. Das ist aber gar kein guter Ansatz, da die Backups und die aktuellen Daten damit auf dem gleichen Server liegen.
Denn was geschieht bei einem Defekt? Man kommt nicht ohne Weiteres an die Daten heran. Und im schlimmsten Fall klappt das auch gar nicht mehr, wenn es einen Kurzschluss im System gab oder ein Verschlüsselungstrojaner sein Unwesen getrieben hat. Daher sollte man die Backups auf einem anderen Gerät und noch dazu an einem anderen Ort lagern.
Letzteres ist natürlich kein Muss im Homelab. Aber getrennte Speicherpools lassen sich sehr einfach umsetzen. In Proxmox kann man zum Beispiel mit wenigen Klicks ein eigenes Ceph-Storage-Cluster neben dem Hypervisor-Cluster betreiben. Die Updates sowie die Einrichtung lassen sich bequem über die grafische Oberfläche vornehmen, wie ich aus eigener Erfahrung weiß.
Und ein sehr netter Nebeneffekt von Ceph ist die integrierte Datenreplikation. Standardmäßig bekommt man von den Platten der VMs und Container 3 Duplikate. Konkret heißt das, dass man nicht pro Clusterknoten ein Raid 1 für den Ceph-Festplatten-Pool benötigt. Man spart also noch etwas Geld bei der Hardware ein und erhält trotzdem eine 1A Redundanz.
Die täglichen Sicherungen hingegen kann man wie gewohnt auf eine NAS-Freigabe packen. So ein kleines Datengrab hat vermutlich eh so ziemlich jeder begeisterte Homelabber daheim herumstehen. Alternativ dazu tut es natürlich auch ein günstiger Speicher in der Cloud. Dazu aber im nächsten Abschnitt mehr.
Wie kann man das Thema Backup bei Proxmox-Clustern angehen?
Die einfachste Variante ist es sicherlich, eine NFS- oder SMB-Freigabe clusterweit einzuhängen und dann über das integrierte Backup-Tool jede Nacht eine Vollsicherung durchführen zu lassen. Das hat allerdings einen großen Nachteil. Die Rede ist von dem enormen Speicherverbrauch. Etwas geschickter ist da schon der Einsatz des Proxmox eigenen Backup-Servers.
Dessen inkrementelle Sicherungen reduzieren zudem noch die Netzwerkauslastung deutlich. Abseits dessen werden die angefertigten Sicherheitskopien dedupliziert gespeichert. Wer seine Backups also an einem anderen Standort oder gar in der Cloud lagern möchte, spart so etwas Geld. Außerdem geht der Upload deutlich schneller vonstatten.
Wissen sollte man aber, dass der Backup-Server für den Einsatz auf physischer Hardware mit ordentlich Festplattenkapazität gebaut ist. Dessen ungeachtet läuft die Lösung auch gut als virtuelle Maschine direkt auf dem vorhandenen Proxmox-Cluster. Soll beispielsweise eine NFS-Freigabe als Sicherungsziel dienen, muss diese aber zuerst im Linux-System gemountet werden.
Im Proxmox Backup-Server lässt sich alles sehr granular einstellen. Das kann aber auch schnell zu großer Verwirrung führen. Daher möchte ich an dieser Stelle noch erwähnen, welche Retention Policy ich für die Sicherungen von Workloads im Homelab einsetzen würde:
- 7 tägliche Sicherungen
- 4 wöchentliche Sicherungen
- 12 monatliche Sicherungen
Das Thema Datensicherung ist ein sehr komplexes Feld und kann noch dazu viele Ressourcen in Anspruch nehmen. Je nach Größe des Clusters tut es aber häufig schon das in Proxmox integrierte Backup-Tool. Wer will, kann aber auch einen Thin Client mit ordentlich Festplattenspeicher ausstatten und den Proxmox Backup Server installieren. In diesem Sinne wünsche ich viel Spaß beim Clusterbau.