Drei Knoten als Proxmox-Cluster: zwei Mini-PCs und ein Desktop-PC

Mein Homelab läuft auf einem Proxmox-Cluster mit drei Knoten. Das klingt nach drei gleichen Kisten im Regal, ist es aber nicht: Zwei Knoten sind gebrauchte Mini-PCs, der dritte ist ein normaler Desktop-PC. Diese Mischung ist nicht geplant, sondern gewachsen. Sie hat Vorteile, aber auch Folgen, die ich erst im Betrieb gemerkt habe. Hier stehen die Hardware, der Speicher pro Knoten, was ich zum Stromverbrauch weiß, die Fehler im Betrieb und was ich heute anders kaufen würde.

Die drei Knoten im Überblick

	Knoten 1	Knoten 2	Knoten 3
Bauform	Mini-PC (Thin Client)	Mini-PC (Thin Client)	Desktop-PC
CPU	Celeron J4105, 4 Kerne	Celeron J4105, 4 Kerne	Core i5-13500, 6 P- und 8 E-Kerne, 20 Threads
RAM	20 GB DDR4 (16 + 4)	20 GB DDR4 (16 + 4)	64 GB DDR4 (2 × 32, zwei Bänke frei)
SSD	1 TB SATA	1 TB SATA	1 TB SATA und 2 TB NVMe
Festplatten	zwei 10-TB-Platten per USB	keine	3 TB, 10 TB und 8 TB intern, weitere per USB
Netzwerk	USB-Adapter 2,5 GbE, Onboard 1 GbE ungenutzt	USB-Adapter 2,5 GbE, Onboard 1 GbE für WAN	USB-Adapter 2,5 GbE, Onboard ungenutzt

Alle drei laufen mit Proxmox VE 9.2 und bilden einen Cluster mit drei Stimmen. Fällt ein Knoten aus, bleibt der Rest arbeitsfähig. Fallen zwei aus, verliert der letzte das Quorum: Gastkonfigurationen sind dann schreibgeschützt, und Starts gehen nur noch mit einem bewussten Eingriff.

Zwei Mini-PCs für die Grunddienste

Knoten 1 und 2 sind zwei gebrauchte Thin Clients vom Typ Dell Wyse 5070. Darin steckt ein Celeron J4105 mit vier Kernen, ohne Hyperthreading. Ich habe beide mit je einem 16-GB- und einem 4-GB-Riegel bestückt, also 20 GB. Proxmox meldet davon 19,4 GB. Als Speicher dient jeweils eine 1-TB-SATA-SSD.

Auf diesen beiden Kisten liegen die Dienste, ohne die im Haus nichts geht: die Firewall als VM, je ein Domänencontroller, ein AdGuard Home (der zweite läuft auf Knoten 3), das Monitoring mit der Doku, die Zertifizierungsstelle und ein kleiner Verwaltungscontainer. Das sind viele kleine Gäste mit wenig Last. Für diese Rolle reichen vier Celeron-Kerne. Für alles mit Rechenlast reichen sie nicht. Als ich überlegt habe, wo mein GitLab laufen soll, war die Antwort deshalb schnell klar: nicht auf einem Knoten mit vier Celeron-Kernen.

Die Thin Clients haben nur einen Netzwerkanschluss mit 1 GbE. Das Heimnetz hängt deshalb bei allen Knoten an einem USB-Netzwerkadapter mit 2,5 GbE, auf Knoten 2 trägt der Onboard-Port zusätzlich die WAN-Seite der Firewall. Genau hier lag mein größtes Problem: Der Adapter mit Realtek-Chip (RTL8156) verliert unter Last die Verbindung und kommt nicht von allein in die Bridge zurück. Knoten 2 ist deshalb dreimal ausgefallen. Heute prüft ein kleiner Watchdog-Dienst alle zehn Sekunden den Link und stuft sich hoch, bis die Verbindung wieder steht. Auf Knoten 2 schaltet außerdem ein Kernel-Parameter das Energiesparen für den Adapter ab. Das ist eine Krücke, keine Lösung.

Ein Desktop-PC als Arbeitspferd

Knoten 3 ist ein normaler PC mit einem Mainboard mit B760-Chipsatz, einem Core i5-13500 und 64 GB RAM. Der Prozessor hat sechs Performance-Kerne mit Hyperthreading und acht Effizienzkerne, zusammen 20 Threads. Zwei von vier Speicherbänken sind noch frei. Gekühlt wird mit einer Wasserkühlung, und in einem PCIe-Slot steckt eine Grafikkarte mit 16 GB Speicher, die an eine VM für lokale KI-Modelle durchgereicht ist.

Hier läuft alles, was Leistung oder Platten braucht: der Dateiserver mit den Medienplatten, Plex, Home Assistant, die KI-VM, GitLab, der Proxmox Backup Server und zwei Windows-Clients. Der Desktop hat genug SATA-Anschlüsse, Platz für eine NVMe-SSD und für eine Grafikkarte. Das kann kein Mini-PC.

Die Hybrid-CPU hat eine Tücke: Linux verteilt die virtuellen CPUs frei auf P- und E-Kerne. Zeitweise waren 50 vCPU auf 20 Threads verteilt, ich habe die Zahl reduziert. Eine feste Zuordnung, bei der die KI-VM und Plex die P-Kerne bekommen und der Rest die E-Kerne, ist noch in Arbeit.

Eine Zeit lang lief der Rechner außerdem mit nicht angeschlossener Pumpe der Wasserkühlung und fiel regelmäßig aus. Die NVMe zählt seitdem über 700 unsichere Abschaltungen. Das ist behoben, aber der Zähler bleibt. Nach dem Wechsel auf Proxmox VE 9 ist Knoten 3 zudem zweimal ohne Logeintrag stehen geblieben, beide Male bei hoher Last der KI-VM. Die Ursache ist offen. Bis dahin nutze ich die Grafikkarte nicht unter Dauerlast.

Speicher pro Knoten

Auf jedem Knoten ist die SATA-SSD gleich aufgeteilt: Das System liegt auf LVM mit etwa 96 GB, der Rest ist ein ZFS-Pool mit rund 800 GB für die Gäste. Gleicher Poolname auf allen Knoten ist Voraussetzung dafür, dass Proxmox die Gäste zwischen den Knoten replizieren kann. Knoten 3 hat zusätzlich eine 2-TB-NVMe als LVM-Thin-Speicher. Dort liegen die großen Gäste. Das 96-GB-System füllt sich schneller als gedacht: ISO-Dateien, Journal und alte Kernel haben es auf Knoten 3 auf fast 90 Prozent gebracht. Bei lokal abgelegten ISOs würde ich die Systempartition größer anlegen.

Knoten	ZFS-Pool	belegt	Kompression	weiterer Speicher
Knoten 1	800 GB	19 %	1,33 : 1	–
Knoten 2	800 GB	17 %	1,21 : 1	–
Knoten 3	780 GB	26 %	1,40 : 1	2 TB NVMe (LVM-Thin)

Die Belegung des Pools täuscht etwas. Die Replikate der anderen Knoten liegen mit drin, und die virtuellen Platten sind nicht „sparse“: Jede Replik belegt den vollen Platz. Das muss man einplanen, bevor man Replikation auf einen kleinen Knoten richtet.

Beim Arbeitsspeicher war Knoten 3 lange mein Sorgenkind. Die Summe der zugesagten Gast-RAMs lag bei 97 GB auf einem Host mit 62,6 GB. Der Host stand bei 94 Prozent und lagerte aus. Ich habe dann in jedem Gast gemessen, was er wirklich belegt, und die Zusagen danach gesetzt. Am Ende waren es 53 GB. Zusätzlich habe ich den ZFS-Cache (ARC) begrenzt, der bis dahin keine eigene Grenze hatte und mit den Gästen um den Speicher konkurrierte.

# ZFS-Cache (ARC) auf 4 GB begrenzen, sofort und dauerhaft
echo 4294967296 > /sys/module/zfs/parameters/zfs_arc_max
echo "options zfs zfs_arc_max=4294967296" > /etc/modprobe.d/zfs.conf

Viel Luft ist trotzdem nicht. Die Gäste füllen ihren Speicher mit der Zeit, und mit GitLab ist ein weiterer großer Gast dazugekommen. Die Erweiterung auf 128 GB steht deshalb auf meiner Liste.

Stromverbrauch

Die Server hängen an zwei Notstrom-Wechselrichtern mit Batterie. Die Werte stammen aus deren Anzeige und aus zwei schaltbaren Steckdosen, gemessen an einem einzelnen Tag im Normalbetrieb.

Knoten 3 allein zieht rund 132 W, darin stecken der Desktop-PC, die Festplatten und die Grafikkarte. Der Netzwerkschrank mit beiden Mini-PCs, Switches, Glasfasermodem und ein paar Kleingeräten kommt auf rund 46 bis 55 W.

Einzelwerte für die beiden Mini-PCs habe ich nicht gemessen. Das Verhältnis ist trotzdem klar: Der Desktop-PC braucht mehr als doppelt so viel wie der ganze Schrank mit beiden Mini-PCs. Ein laufendes KI-Modell oder ein Backup-Lauf treibt den Wert noch weiter nach oben.

Was ich heute anders kaufen würde

Einige Punkte stehen als Maßnahme auf meiner Liste, gekauft ist davon noch nichts.

Beim Netzwerk würde ich auf USB verzichten: Mini-PCs mit zwei eingebauten Ports, am besten mit Intel-Chip, und für den Desktop eine PCIe-Netzwerkkarte, Platz ist da. Jeder ZFS-Pool liegt heute auf einer einzigen SSD. Ein Spiegel kostet nicht viel und macht aus „Platte tot“ einen Plattentausch statt eines Wiederaufbaus. 20 GB auf den Mini-PCs und 64 GB auf dem Desktop sind knapp, beim Desktop würde ich direkt alle vier Bänke bestücken.

Dazu käme ein vierter, sparsamer Knoten: ein Mini-PC mit N100 oder N305, 32 GB und zwei Platten im ZFS-Spiegel, als eigener Backup-Server und als vierte Stimme für das Quorum. Mein Backup-Server liegt heute auf demselben Desktop wie die meisten Gäste. Fällt Knoten 3 aus, sind Dateiserver, Home Assistant, Backup-Server und GitLab gleichzeitig weg. Die Lasten würde ich gleichmäßiger planen oder zwei mittlere Rechner statt eines großen kaufen.

Die Mini-PCs selbst würde ich wieder nehmen. Sie sind sparsam, leise und für Firewall, Domänencontroller und DNS völlig ausreichend.