Warum genau 3 Nodes?
Ein Proxmox-Cluster braucht für automatisches Failover (HA) ein Quorum, also eine Mehrheit der Stimmen. Bei zwei Nodes fällt mit einem Ausfall die Mehrheit weg und das Cluster sperrt sich selbst (Schutz vor Split-Brain). Drei Nodes lösen das: Fällt einer aus, halten die übrigen zwei die Mehrheit und können HA-VMs automatisch neu starten. Genau deshalb will man eine ungerade Zahl – das ist günstiger als ein separater QDevice-Witness und im Betrieb sauberer.
Nodes: gleiche Mini-PCs statt lautem Blech
Für ein 24/7-Homelab im Wohnraum sind drei möglichst baugleiche Mini-PCs die beste Wahl: leise, sparsam (oft 6–15 W Idle) und einheitlich im Handling. Die Intel-N100/N305-Klasse reicht für Docker, *arr-Stack, Pi-hole und ein paar leichte VMs; für mehr parallele VMs oder Live-Migration greifst du zu gebrauchten Mini-PCs mit Intel i5/i7 der 8.–10. Gen (z. B. Dell OptiPlex Micro, Lenovo ThinkCentre Tiny, HP EliteDesk Mini). Wichtig: Gleiche CPU-Generation auf allen Nodes erspart dir bei Live-Migration den Ärger mit inkompatiblen CPU-Flags – mit identischer Hardware kannst du den schnellen CPU-Typ "host" fahren. Plane pro Node mindestens 16 GB RAM, besser 32 GB.
RAM: ECC wenn möglich, sonst genug
ECC-RAM fängt Bit-Fehler ab und ist bei 24/7-Servern mit ZFS oder Ceph dringend zu empfehlen – Pflicht ist es technisch nicht, aber wer auf Datenintegrität setzt, will sie konsequent. Das Problem: klassische Mini-PCs (N100, OptiPlex Micro) können meist kein ECC. Wer ECC will, baut die Nodes eher auf kleinen Server-/Workstation-Boards oder gebrauchten Xeon-D-/Supermicro-Systemen auf und bestückt sie mit DDR4-ECC-Modulen. Pro Node solltest du 32 GB einplanen, wenn mehrere VMs plus Ceph laufen – Ceph allein will Reserve. Ohne ECC ist ein 3-Node-Cluster trotzdem brauchbar, du verzichtest nur auf die zusätzliche Fehlerkorrektur.
Storage: lokale Replikation vs. Ceph
Zwei Wege führen zu HA-Storage. Einfach und robust: lokales ZFS auf jedem Node plus Proxmox-Storage-Replikation (pvesr) – die VM-Daten werden minütlich (kleinstes Intervall: 1 Minute) auf die anderen Nodes gespiegelt, bei einem Ausfall verlierst du nur die Minuten seit der letzten Replikation. Voll synchron und selbstheilend: Ceph über alle drei Nodes, dann ist der Storage geteilt und Live-Migration ohne Datenkopie möglich. Ceph will aber gute SSDs und schnelles Netz. In beiden Fällen gehören Enterprise-SSDs mit Power-Loss-Protection (z. B. Samsung PM883/PM9A3, Intel S4510) ins System – Consumer-QLC-SSDs brechen unter ZFS/Ceph-Last bei der Latenz ein und verschleißen am Schreibaufkommen früh.
Netzwerk: 2,5GbE reicht, 10GbE für Ceph
Das Cluster-Netz (Corosync) braucht vor allem niedrige Latenz, nicht viel Bandbreite – ideal ist ein eigener, dedizierter Link dafür. Für lokale ZFS-Replikation genügt 2,5GbE bequem; viele Mini-PCs haben das schon onboard oder du rüstest per USB-NIC bzw. M.2-Adapter nach. Sobald du Ceph fährst, willst du 10GbE für das Storage-Netz, sonst wird die Latenz zum Flaschenhals: gebrauchte Intel X520/X710 (SFP+) oder X550 (10GBASE-T) sind günstig und unter Linux problemlos. Dazu passt ein gebrauchter Switch mit ein paar SFP+-Ports; für ein reines 3-Node-Setup geht zur Not sogar ein direktes Mesh (full-mesh) ohne 10GbE-Switch.
