In 2009 haalde ik mijn netwerkdiploma. Subnetten, VLAN’s, trunks, tagged en untagged — ik kon het uittekenen op papier en het uitleggen aan wie het maar horen wilde. Wat ik nooit heb gehad, is een omgeving waarin ik het écht mocht bouwen. Geen labopstelling met acht switches, geen productienetwerk waar ik aan mocht komen. Zeventien jaar later staat er een rek in Zutphen dat helemaal van mij is, en is er niemand die zegt dat ik ergens niet aan mag zitten.
Dit is het verslag van een week waarin ik een Proxmox-cluster van drie nodes heb opgebouwd, het netwerk eronder in VLAN’s heb opgeknipt, de opslag heb ontward en de kernmachine hoogbeschikbaar heb gemaakt. Inclusief de avond waarop ik mezelf buiten mijn eigen switch sloot. Dat hoort erbij, en het is meteen het leerzaamste stuk.
Drie ongelijke nodes, en waarom dat mag
Het cluster heet PCPal-cluster en bestaat uit drie machines die niets met elkaar gemeen hebben behalve dat ze Proxmox draaien:
- pve — zestien cores, 128 GB geheugen. De werkezel. Hier draait alles.
- pve2 — vier cores, 8 GB. De kleinste van het stel.
- pve3 — vier cores, 16 GB. De aangewezen reservebank.
Elk handboek zegt dat je een cluster met identieke hardware bouwt. Elk handboek gaat er ook van uit dat je een inkoopbudget hebt. In de praktijk bouw je met wat er staat, en dan is de vraag niet of het mag, maar wat je ermee kunt en wat níet. Het antwoord op die tweede vraag is de rode draad van dit hele stuk.
Wat een cluster van drie ongelijke machines je wél geeft: één beheerinterface voor alles, gedeelde opslagdefinities, live migratie tussen nodes, en — mits je het goed inricht — automatische herstart van een kritieke machine op een andere node als de eerste omvalt. Wat het je níet geeft is het gevoel dat je nu klaar bent. Een cluster is geen product dat je installeert, het is een verzameling keuzes die je expliciet moet maken.
Eerst het netwerk, want daar hangt alles aan
Voordat er ook maar één virtuele machine verhuist, moet het netwerk kloppen. Ik wilde af van één platte /24 waarin de containers, de VPS’en, de wifi-apparaten en het beheer allemaal door elkaar heen praten. Dus: VLAN’s.
- VLAN A — untagged, het beheernet. Hier hangen de nodes zelf en de switches aan.
- VLAN B — het wifi-net, untagged op de poort waar het accesspoint aan hangt.
- VLAN C — tagged, containers.
- VLAN D — tagged, de VPS’en. Alles wat naar buiten publiceert.
Op papier is dat een schema van vier regels. In de praktijk moeten die tags door een keten van drie fabrikanten heen: een TP-Link ER707-M2 router, een TP-Link TL-SG108PE smart switch, en een HP ProCurve 1810G-24. Drie merken, drie webinterfaces, drie manieren om exact hetzelfde te bedoelen met totaal verschillende woorden. En elk van die drie kan de tag stilzwijgend laten vallen.
Twee fouten die ik onderweg tegenkwam en die het onthouden waard zijn:
Een trunk heeft minstens twee tagged poorten nodig. Op de ProCurve had ik netjes de poort naar de server tagged gezet in VLAN C, maar de uplink-poort naar de andere switch stond nog op excluded. Een VLAN dat maar op één poort bestaat gaat nergens heen. Logisch als je het opschrijft, onzichtbaar als je in een webinterface zit te klikken.
Weten waar de kabel echt in zit. Ik heb een tijd zitten zoeken naar een probleem dat niet bestond, omdat ik de VLAN’s op de verkeerde poort had getagd. De twee switches zijn onderling gekoppeld, maar de ProCurve hing aan een andere poort dan ik in mijn hoofd had. Een netwerkdiagram in je hoofd is geen netwerkdiagram.
De VLAN-test in tien seconden
Het handigste trucje van de hele operatie. Je wilt weten of een VLAN daadwerkelijk op de node aankomt, zonder eerst een testcontainer op te tuigen. Op de node zelf:
ip link add link vmbr0 name test111 type vlan id 111
ip link set dev test111 up
dhclient -v test111
ip link delete test111Krijg je een DHCPACK met een adres uit het juiste bereik, dan kloppen de trunk, de tag én de DHCP-server in één klap. Krijg je niets, dan weet je dat het probleem in de switchketen zit en niet in Proxmox. Vier regels, en je hoeft niet meer te gokken.
De avond dat de switch verdween
En toen sloot ik mezelf buiten.
Bij het opschonen van de VLAN-tabel op de TP-Link verwijderde ik het wifi-VLAN. Wat ik me op dat moment niet realiseerde: de switch haalde zijn eigen beheeradres via DHCP, en dat verzoek ging over precies dat VLAN. Na de herstart was het beheeradres weg. Niet onbereikbaar — wég. Geen ping, geen webinterface, niets.
Aan die ene switch hangt mijn complete rek. Er is een fase in zo’n avond waarin je geen ingenieur meer bent maar iemand die tegen een kastje staat te schreeuwen. Dat mag. Wat niet mag, is in die toestand de resetknop indrukken — want dan ben je ook alle andere VLAN-configuratie kwijt en begin je om elf uur ’s avonds helemaal opnieuw.
De redding was de TP-Link Easy Smart Configuration Utility. Dat is een Windows-tool die de switch niet via IP zoekt, maar via een broadcast op laag 2. Het maakt dus niet uit in welk VLAN de switch zit of welk adres hij heeft: als er een kabel tussen zit, vindt hij hem. De switch bleek keurig een adres te hebben gekregen uit het wifi-bereik — een subnet waar mijn beheer-pc helemaal niet in zat.
De les die ik eruit meeneem, en die ik meteen heb toegepast: geef beheerapparatuur een statisch adres en zet DHCP uit. Een switch die zijn eigen bereikbaarheid van een dienst laat afhangen die jij aan het herconfigureren bent, is een switch die je vroeg of laat kwijtraakt. En: zorg dat je een out-of-band manier hebt om erbij te komen vóórdat je hem nodig hebt.
Proxmox erop: twee vinkjes die alles bepalen
Aan de Proxmox-kant zijn er twee dingen die je moet weten.
Ten eerste: de bridge vmbr0 moet VLAN aware zijn. Staat dat vinkje uit, dan gooit Proxmox de tags weg zonder te klagen. Je machine krijgt netjes een interface, er gebeurt alleen niets. Geen foutmelding, geen waarschuwing — de pakketjes verdwijnen gewoon. Dit is precies het soort stille fout waar je een halve avond aan kwijt bent.
Ten tweede: Proxmox heeft tegenwoordig SDN aan boord. In plaats van bij elke machine handmatig een VLAN-tag in te tikken, definieer je één keer een zone op de bridge en daarbinnen VNets — een virtueel netwerk per VLAN. Bij het aanmaken van een container kies je dan gewoon “Containers” of “VPSen” uit een lijstje in plaats van een getal te onthouden. Dat scheelt niet alleen typwerk, het scheelt vooral de categorie fouten waarbij je ergens 110 typt in plaats van 111.
Opslag: de gemene deler en de grote pool
Hier zit de belangrijkste architectuurbeslissing van het hele project, en ik ontdekte hem zoals de meeste mensen hem ontdekken: doordat er iets rood werd.
De grote node heeft een 4TB ZFS-pool. Die pool bestaat fysiek alleen daar. Toen ik de replicatie van mijn kernmachine naar de reservenode aanzette, kreeg ik een foutmelding die op het eerste gezicht over ruimte leek te gaan, maar dat niet deed:
storage ‘dc-king’ is not available on node ‘pve3’
ZFS-replicatie in Proxmox eist dat de pool op beide nodes exact dezelfde naam heeft. Niet vergelijkbare ruimte, niet een pool die toevallig groot genoeg is — dezelfde naam. Dat is geen bug, dat is hoe zfs send en zfs receive werken, maar het heeft een gevolg dat je bewust moet maken:
local-zfsis de gemene deler. Elke Proxmox-installatie maakt die aan op de systeemschijf. Alles wat moet kunnen failoveren hoort daar te staan, punt.- De grote pool is capaciteit, geen beschikbaarheid. Wat daarop staat kan alleen repliceren naar een node waar jij zelf een pool met exact die naam hebt aangemaakt.
De oplossing was de schijf van de kernmachine verplaatsen naar local-zfs. Sindsdien loopt de replicatie foutloos en duurt een synchronisatie een seconde of vijf.
Delen wat niet gedeeld is
Die 4TB-pool wil je natuurlijk wel cluster-breed kunnen gebruiken, al is het maar voor templates en images. Daarom exporteert de grote node hem via NFS naar de rest van het cluster, als storage dc-king-nfs. Alle drie de nodes zien dezelfde inhoud.
Maar wees eerlijk over wat dat is. De NFS-server draait op de node zélf. Dat maakt de pool cluster-breed bereikbaar, niet hoogbeschikbaar. Valt die node weg, dan valt de NFS-share mee weg. Voor templates en ISO’s is dat prima. Voor de virtuele schijf van een machine die het juist moet overleven, absoluut niet. Het is verleidelijk om “shared storage” te zien staan in de interface en te denken dat je klaar bent.
Daarnaast hangt er een Synology-NAS in het rek, als aparte NFS-share aan alle drie de nodes gekoppeld. Die doet twee dingen: hij bewaart de back-ups (met een bewaarregel van de laatste vijf), en hij levert de installatie-images aan het hele cluster. Eén keer een ISO uploaden, en je kunt op elke node een machine bouwen. Dat klinkt als een detail totdat je het een keer zonder hebt gedaan en op drie nodes hetzelfde bestand staat te uploaden.
Het verschil tussen die twee shares is precies het punt: de NAS is losse hardware. Als de grote node uitvalt, staat de Synology er nog steeds.
Load balancing: alles staat op één node, en dat is een keuze
Op dit moment draaien alle dertien gasten op de grote node. De andere twee staan leeg. Dat ziet er in een dashboard uit als een ontwerpfout, en dat is het niet.
De verhouding is zestien cores tegen vier, en 128 GB tegen 8 en 16. Werk verdelen over nodes die een fractie van de capaciteit hebben is geen balanceren, dat is spreiden tot het ergens knelt. Wat de kleine nodes wél doen is stemmen uitbrengen voor het quorum en één specifieke machine kunnen overnemen. Dat is hun functie.
Er zit trouwens een valkuil in de automatische verdeling van Proxmox. De HA-stack heeft een optie die een machine bij herstart naar de leegste node stuurt. Leeg is niet hetzelfde als geschikt: mijn kleinste node had minder geheugen dan de machine vroeg, en was volgens dat criterium toch de aantrekkelijkste kandidaat. Automatische verdeling zonder expliciete regels is een generator van verrassingen op het slechtst denkbare moment.
Hoogbeschikbaarheid voor de kernmachine
Eén machine in het cluster is echt belangrijk: de server waarop de hosting draait. Die moet een uitval van zijn node overleven. Dat vraagt vier dingen, en ze moeten alle vier kloppen.
1. Een recente kopie op de andere node. ZFS-replicatie draait elke vijf minuten van de grote node naar de reservenode. Een synchronisatie duurt ongeveer vijf seconden, dus het venster waarin je data kunt verliezen is maximaal vijf minuten. Dat is de bewuste ruil: geen gedeelde SAN, dus geen nul.
2. Een regel die zegt wáár hij mag draaien. Proxmox 9 heeft de oude HA-groepen vervangen door HA rules. Ik heb een strikte node-affinity-regel gemaakt die de machine toestaat op de grote node (prioriteit 2) en op de reservenode (prioriteit 1). De kleinste node staat er niet in en komt dus nooit in aanmerking — die heeft geen replica en te weinig geheugen.
3. Failback uit. Standaard springt een machine terug zodra zijn favoriete node weer online is. Klinkt netjes, maar dat betekent dat je tijdens een instabiele node een tweede ongeplande verhuizing krijgt bovenop de eerste. Ik wil zelf bepalen wanneer hij teruggaat, als ik heb vastgesteld dat de node ook echt gezond is.
4. Quorum dat het juiste scenario afdekt. En daar wordt het interessant.
Stemgewicht: je moet kiezen wat je wilt beschermen
Een Proxmox-cluster stemt. Elke node heeft stemmen, en om iets te mogen doen moet je meer dan de helft van het totaal achter je hebben. Heb je dat niet, dan ben je inquorate: de configuratie gaat op alleen-lezen en de HA-stack doet helemaal niets. Bovendien schiet de watchdog de node na een paar minuten opnieuw op, om te voorkomen dat twee helften van een cluster dezelfde machine gaan draaien.
Ik heb hier onderweg mee zitten schuiven, en dat was leerzaam. Even had de grote node drie stemmen en de andere twee elk één. Totaal vijf, drempel drie. Effect: de grote node overleeft in zijn eentje het wegvallen van beide andere nodes. Prima gedachte — behalve dat het omgekeerde dan ook geldt. Valt de grote node weg, dan houden de twee overlevers samen twee van de vijf stemmen. Onder de drempel. Inquorate. Geen HA, geen recovery, geen automatische start van de belangrijke machine.
Dat zijn tegengestelde eisen. Je kunt niet tegelijk hebben dat één node alleen overleeft én dat de overlevers het van hem overnemen. Stemgewicht kiest een winnaar, en je moet zelf beslissen welke.
Ik heb het teruggezet naar één stem per node. Totaal drie, drempel twee. Valt de grote node weg, dan houden de twee kleintjes samen twee stemmen over — genoeg. Ze blijven quorate, het cluster verhuist zijn coördinator, en de HA-stack start de kernmachine op de reservenode. Precies het scenario waar het me om te doen was.
De prijs: valt er een kleine node weg terwijl de grote alleen overblijft, dan heeft die één van de drie stemmen en fencet de watchdog hem weg. Dat is bij een cluster van drie met gelijke stemmen normaal gedrag, en het is de goedkopere van de twee risico’s. Er is een oplossing voor — een QDevice, een vierde stem op een kleine machine buiten het cluster — en die staat op de lijst.
Wat er nog niet af is
Ik heb een hekel aan verhalen die eindigen met “en toen was het klaar”. Dat is het nooit. Wat er open staat:
- De failover is nooit getest. Een replicatiejob zonder fouten bewijst dat er data overkomt, niet dat de kopie opstart. Dat verschil ontdek je liever op een dinsdagmiddag dan om drie uur ’s nachts. Een geplande testmigratie staat ingepland.
- De guest agent draait niet in de kernmachine. Hij staat wel aan in de configuratie. Gevolg: Proxmox kan geen nette afsluiting doen en ziet het adres van de gast niet.
- De bridges verschillen tussen nodes. Op de grote node is
vmbr0VLAN-aware, op de reservenode staat die vlag niet. Proxmox vangt dat meestal zelf op, en mijn VLAN-test bewees dat het verkeer aankomt. Maar dit is exact het soort verschil dat je ontdekt tijdens een failover. - Eén corosync-ring, over hetzelfde netwerk als het VM- en NFS-verkeer. Een tweede ring over een apart pad is de nette oplossing.
Wat ik ervan heb geleerd
Er loopt één patroon door dit hele project heen: de fouten zaten nooit in het moeilijke deel. Ze zaten in aannames. Een poort waarvan ik dacht te weten waar hij heen liep. Een pool waarvan ik dacht dat “genoeg ruimte” het criterium was. Een switch waarvan ik niet doorhad dat hij zijn eigen bereikbaarheid ophaalde via het VLAN dat ik aan het slopen was. Een stemverdeling waarvan de keerzijde pas zichtbaar werd toen ik hem hardop uitschreef.
Ik heb hierbij ook AI-assistenten ingezet, en die hebben zeker geholpen — de VLAN-test hierboven kwam er zo uit en was meteen raak. Maar ze produceerden ook commando’s die niet bestaan, en zeiden een paar keer met veel overtuiging dat mijn opstelling nu “kogelvrij” was terwijl dat aantoonbaar niet zo was. Dat is geen aanklacht; het is de gebruiksaanwijzing. Dit gereedschap werkt precies zo goed als de persoon die de foutmelding leest en het antwoord nacontroleert. Ik ben zelf ook een keer de mist in gegaan door de uitvoer van één node te lezen als waarheid over het hele cluster.
En verder: zeventien jaar na dat diploma heb ik eindelijk een trunk geconfigureerd die het doet. Op mijn eigen apparatuur, in mijn eigen rek, met mijn eigen fouten. Dat blijkt precies zo bevredigend te zijn als ik toen dacht dat het zou zijn.