Drie identieke mini-pc's, een onbeheerde 2,5GbE-switch en Proxmox VE 9 — meer heb je niet nodig om een thuiscluster te bouwen waarbij een node gewoon offline mag gaan zonder dat je VM's dat merken. Dit is de complete walk-through, van netwerkopzet tot HA die écht migreert.
Hardware en netwerkopzet
Het startpunt is een trio Beelink SER5 of EQ12-mini-pc's. Beide modellen leveren twee 2,5GbE-poorten, wat cruciaal is: je hebt één interface voor het productieverkeer van je VM's en een aparte interface voor het clusternetwerk (corosync en migraties). Op één fysieke poort alles door elkaar sturen kan, maar het introduceert latentie op precies het moment dat het clusterprotocol het minst kan gebruiken.
De SER5 met de Ryzen 7 5700U is een iets warmere keuze — idle-verbruik zit rond de 18 à 22 watt — maar levert acht echte kernen en tot 64 GB DDR4. De EQ12 met Intel N100 is zuiniger (8 watt idle) en voldoende als je voornamelijk LXC-containers draait. Voor een cluster met live-migratie heb je minimaal 16 GB per node nodig: Proxmox reserveert een deel voor de host-OS en ZFS ARC, en je wil genoeg marge om een volledige node neer te leggen terwijl de VM's op de overgebleven twee draaien.
Cluster-build — drie identieke nodes
Verbind de eerste poort van elke node (enp2s0) met de switch voor VM-verkeer en beheer. De tweede poort (enp3s0) sluit je met een directe kabel aan: node1 ↔ node2 via een cross-over of direct-attach kabel, en node2 ↔ node3 idem. Heb je budget voor een tweede switch, nog beter — dan loop je al het clusterverkeer volledig gescheiden. Geef het clusternetwerk een apart /24-blok, bijvoorbeeld 10.10.10.0/24. Bewerk /etc/network/interfaces op elke node voor je aan de clusterinstallatie begint:
# enp2s0 — productieverkeer en beheer
auto enp2s0
iface enp2s0 inet static
address 192.168.1.11/24
gateway 192.168.1.1
# enp3s0 — clusternetwerk (corosync + migraties)
auto enp3s0
iface enp3s0 inet static
address 10.10.10.11/24Pas de adressen aan voor node 2 (.12) en node 3 (.13). Voeg de hostnamen toe aan /etc/hosts op alle drie de nodes zodat corosync ze kan resolven zonder DNS:
192.168.1.11 pve1
192.168.1.12 pve2
192.168.1.13 pve3
10.10.10.11 pve1-cluster
10.10.10.12 pve2-cluster
10.10.10.13 pve3-clusterProxmox installeren en het cluster joinen
Installeer Proxmox VE 9 op alle drie de nodes via de ISO. De installer is onveranderd eenvoudig: opstart van USB, klik door de wizard, kies de NVMe als doelschijf en stel een statisch IP in. Doe dit op alle drie de nodes voordat je iets met clustering doet — een node die je aan een cluster toevoegt mag geen actieve VM's of containers hebben.
Voeg eerst op elke node de no-subscription repository toe zodat updates werken zonder enterprise-licentie:
echo "deb http://download.proxmox.com/debian/pve trixie pve-no-subscription" \
> /etc/apt/sources.list.d/pve-install-repo.list
sed -i 's/^deb/#deb/' /etc/apt/sources.list.d/pve-enterprise.list
apt update && apt dist-upgrade -yMaak het cluster aan op node 1. De --link0 en --link1 parameters vertellen corosync welke interfaces het mag gebruiken — link0 is het primaire clusternetwerk, link1 is de fallback op het productie-interface:
pvecm create mijn-cluster \
--link0 address=10.10.10.11 \
--link1 address=192.168.1.11Voeg node 2 toe. SSH naar node 2 en voer uit:
pvecm add 192.168.1.11 \
--link0 address=10.10.10.12 \
--link1 address=192.168.1.12Herhaal voor node 3 met het bijbehorende adres. Na het joinen controleer je de status op een willekeurige node:
pvecm statusJe ziet drie nodes, elk met één stem, en de quorum-teller op 2 (meer dan de helft van 3). Met drie nodes heb je al een stabiel quorum: als één node uitvalt, houden de andere twee samen de meerderheid. Een extra qdevice is bij een oneven cluster niet noodzakelijk — de Proxmox-documentatie raadt het zelfs af voor clusters met een oneven knooppuntaantal, omdat de wiskundig meerwaarde dan wegvalt. Toch kan het nuttig zijn als je twee nodes lokaal hebt en één node op een andere locatie: een qdevice op die derde locatie zorgt dan voor een extra stembron.
"Met drie nodes heb je al een stabiel quorum. Een extra qdevice is bij een oneven cluster niet noodzakelijk — maar op een geografisch verspreid cluster geeft het je een extra stembron op het moment dat het er het meest op aankomt."
Controleer de webinterface van node 1 op poort 8006. Je ziet nu alle drie nodes in de linker boomstructuur. Datacenter-level instellingen — opslag, HA, netwerken — gelden voor het volledige cluster.
Gedeelde opslag: Ceph of ZFS-replicatie
Dit is het punt waar de meeste cluster-tutorials te snel doorheen gaan. Proxmox HA heeft gedeelde opslag nodig om een VM live te kunnen migreren: als de VM-disk alleen lokaal op node 1 staat, kan node 2 hem niet overnemen zonder eerst de schijf te kopiëren, en dat kost tijd. Er zijn twee praktische opties voor een drie-node thuis- of kantoorcluster.
Optie A: Ceph. Ceph is het technisch fraaiste antwoord — volledig gedistribueerd, automatisch herstel bij noduitval, geen NAS nodig. Proxmox VE 9 levert Ceph Squid 19.2.3 ingebouwd en je configureert alles via de GUI of de CLI. Het minimum is drie nodes met elk één OSD (Object Storage Daemon, in dit geval je NVMe-schijf). Maar: Ceph is gehongerig. Elke OSD daemon gebruikt 1 à 2 GB RAM standaard, en 2,5GbE is het absolute minimum — de officiële Ceph-documentatie raadt 10GbE aan voor productie. Op een mini-pc cluster met 32 GB per node en 2,5GbE werkt het, maar je merkt dat de opslaglatentie hoger is dan lokale ZFS en dat Ceph bij een failover-test de beschikbare bandbreedte volledig benut.
Optie B: ZFS met Proxmox-replicatie. Elke node heeft zijn eigen ZFS-pool. Proxmox replicatie synchroniseert VM-schijven tussen nodes op schema — standaard elk kwartier, maar configureerbaar tot elke minuut. Bij een node-uitval mis je maximaal één replicatiecyclus aan writes; de VM herstart op een andere node met een schijf die op zijn slechtst een minuut achterstaat. Voor een thuiscluster of testomgeving is dit ruim voldoende. Het RAM-verbruik is lager en de prestaties op lokale reads en writes zijn significant beter dan Ceph over 2,5GbE.
ZFS-pool aanmaken op elke node (vervang nvme0n1 door de juiste schijfnaam):
zpool create -o ashift=12 data /dev/nvme0n1Voeg de ZFS-pool toe als Proxmox-opslag via Datacenter > Storage > Add > ZFS. Stel replicatie in via de VM-configuratie onder Replication > Add: kies het doelknooppunt en een schema van */15 (elke 15 minuten). Herhaal voor elk knooppunt als doelbestemming zodat elke VM op alle drie de nodes gerepliceerd staat.
Voor wie toch Ceph wil proberen, zijn de CLI-stappen beknopt:
# Op elke node
pveceph install
pveceph init --network 10.10.10.0/24
# Monitor aanmaken (op alle drie)
pveceph mon create
# OSD aanmaken (één per node, disk zonder partitietabel)
pveceph osd create /dev/nvme0n1
# CephFS of RBD pool
pveceph pool create vm-pool --size 3HA in de praktijk
High Availability in Proxmox werkt via twee diensten: pve-ha-lrm (Local Resource Manager, per node) en pve-ha-crm (Cluster Resource Manager, cluster-breed). De CRM monitort de status van alle nodes via corosync. Zodra een node als offline wordt beschouwd — meer dan de helft van de overgebleven nodes stemt voor offline — stuurt de CRM een migratie- of herstart-opdracht voor alle VM's die als HA-resource geconfigureerd zijn.
Voeg een VM toe aan HA via Datacenter > HA > Add. Kies de VM, stel Max Restart in op 3 en Max Relocate op 1. De instelling Shutdown Policy op Datacenter-niveau bepaalt wat er gebeurt als je een node bewust neerzet: zet dit op migrate zodat HA VM's automatisch verhuizen bij een geplande herstart, in plaats van te wachten op een timeout.
# Handmatige live-migratie via CLI
qm migrate 101 pve2 --online --migration_network 10.10.10.0/24
# Container migreren
pct migrate 200 pve3 --onlineDe --migration_network-parameter stuurt het migratieverkeer expliciet over het clusternetwerk in plaats van het productie-interface. Op 2,5GbE migreert een VM van 8 GB geheugen in ongeveer 30 à 45 seconden bij een normale schrijflast. De VM is tijdens de migratie beschikbaar; er treedt alleen een korte onderbreking op bij de uiteindelijke overname, typisch onder de 200 milliseconden.
Test je HA-configuratie actief. Trek de stekker van node 1 eruit terwijl node 2 en node 3 draaien. Corosync markeert de node als offline zodra de heartbeats wegblijven — standaard na een fence-timeout van 60 seconden. Fencing zorgt ervoor dat de offline node zichzelf uitschakelt (STONITH) om split-brain te voorkomen. Op een thuiscluster zonder IPMI kun je softwarematige fencing configureren via de pve-ha-lrm-instelling of simpelweg de watchdog-timer gebruiken. Na de fence-timeout starten de HA-resources op de overgebleven nodes. In de praktijk zit je VM er na 90 tot 120 seconden opnieuw op.
Proxmox VE 9 introduceert HA affinity rules, waarmee je kunt afdwingen dat bepaalde VM's altijd op specifieke nodes draaien of juist nooit op dezelfde node als een andere VM. Dat is handig als je een primaire en een replica-VM van dezelfde dienst hebt: verplicht ze op verschillende nodes te draaien zodat één node-uitval nooit beide treft. Stel je dit in via Datacenter > HA > Groups, en wijs de group toe aan je HA-resources.
Veelgestelde vragen
Werkt Proxmox VE 9 op de Beelink EQ12 met N100? Ja, maar de N100 mist een hardware-random number generator die sommige virtualisatiefuncties gebruiken. Voeg virtio-rng toe aan je VM-configuratie om dat te compenseren. Er zijn ook meldingen van packet loss op de 2,5GbE-driver van de SER5 onder Proxmox 9.0.x bij hoge belasting — update naar 9.1 of pas de ring-buffergrootte aan met ethtool -G enp2s0 rx 4096 tx 4096.
Heb ik een gedeelde NAS nodig naast ZFS-replicatie? Niet voor HA-werking, maar wel handig als gedeelde opslag voor ISO-images en back-ups. Een eenvoudige NFS-share op een Raspberry Pi of een oude NAS werkt prima; voeg hem toe als NFS-opslag onder Datacenter > Storage.
Hoe herstel ik het cluster na een split-brain? Als twee nodes elk denken dat de derde de meerderheid heeft, bevriest het cluster. Sluit alle services af, breng de nodes één voor één online te beginnen met de node met de meest recente data, en herstel corosync via pvecm expected 1 op de eerste node om quorum tijdelijk met één stem te forceren.
Is 2,5GbE echt genoeg voor Ceph? Technisch werkt het, praktisch is het krap. Bij een OSD-herstel na een schijfwissel of node-uitval schrijft Ceph alle replicatiedata opnieuw over het netwerk — op 2,5GbE kan dat uren duren en tegelijk de VM-prestaties significant drukken. ZFS-replicatie heeft dit probleem niet omdat synchronisaties incrementeel zijn en goed planbaar.
