De architectuur van mijn homelab opnieuw opbouwen
Mijn homelab is in de loop van de tijd flink veranderd. Wat begon als een vrij simpele setup met een paar virtuele machines, Docker-containers, interne services en een OPNsense-VM, groeide langzaam uit tot een grotere omgeving met Proxmox, Kubernetes, interne DNS, S3-opslag, monitoring, VPN-toegang en meer services die van buitenaf bereikbaar zijn.
De oude setup werkte prima, maar veel ervan was organisch gegroeid. Services kwamen erbij wanneer ik ze nodig had, het netwerk veranderde mettertijd en sommige onderdelen deden uiteindelijk meer dan oorspronkelijk de bedoeling was. De volgende versie van het homelab draait dus vooral om de bestaande setup gestructureerder, redundanter en makkelijker uitbreidbaar maken.
De oude setup
De vorige omgeving gebruikte al een Proxmox-cluster van drie nodes als belangrijkste virtualisatieplatform. De meeste workloads draaiden als virtuele machines of containers, en een k3s-cluster van vijf nodes nam de gecontaineriseerde applicaties voor zijn rekening.
Het netwerk draaide om een HPE Aruba 2530-48G-switch, met OPNsense als virtuele router en firewall. Cloudflare regelde de externe DNS en tunnels voor services die vanaf het internet bereikbaar moesten zijn.
De opslag was, afhankelijk van de workload, een mix van lokale opslag, ZFS, S3-compatibele opslag en NAS-opslag.
Deze setup was nuttig, omdat hij een paar zwakke plekken vrij snel blootlegde. Routing en firewalling draaien binnen dezelfde virtuele infrastructuur die ze beschermen werkte wel, maar zorgde ook voor onnodige afhankelijkheden. Opslag voor infrastructuur en opslag voor gebruikersbestanden hadden bovendien heel andere eisen, en ze als één probleem behandelen maakte het geheel minder overzichtelijk.
De nieuwe setup scheidt die verantwoordelijkheden veel duidelijker.
De nieuwe architectuur
Het belangrijkste virtualisatieplatform blijft een Proxmox-cluster van drie nodes.
Elke node heeft op dit moment:
- 8 CPU-cores
- 16 GB RAM
- Proxmox VE
De grootste verandering hier is opslag. Het cluster gaat Ceph gebruiken als gedeelde opslag voor virtuele machines en containers. Daardoor kunnen workloads tussen nodes verhuizen en wordt Proxmox HA een stuk nuttiger.
In plaats van dat een VM vastzit aan schijven in één specifieke host, is de opslag in het hele cluster beschikbaar.
Dat betekent ook dat het cluster veel netter kan omgaan met het uitvallen van een losse node dan voorheen.
Netwerkoverzicht
Het diagram hierboven laat de belangrijkste scheiding zien tussen netwerk, virtualisatie, opslag, Kubernetes en dedicated compute.
Netwerk
De grootste verandering in het netwerk is dat de virtuele OPNsense-router verdwijnt.
Hij wordt vervangen door twee Check Point 1450-appliances in een failover-opstelling.
Het Check Point-paar regelt:
- WAN-connectiviteit
- Firewalling
- Routing tussen VLAN’s
- VPN-toegang
- Netwerksegmentatie
Door routing uit het Proxmox-cluster te halen, verdwijnt een onhandige afhankelijkheid waarbij de virtuele infrastructuur deels afhing van een router die binnen diezelfde infrastructuur draaide.
De HPE Aruba 2530-48G blijft de hoofdswitch van de omgeving en verbindt de verschillende fysieke systemen en VLAN’s met elkaar.
Daarmee lijkt de netwerktopologie ook meer op een traditionele enterprise-setup, met dedicated routing en firewalling vóór de compute-infrastructuur.
Proxmox en Ceph
De drie Proxmox-nodes vormen samen het belangrijkste high-availability compute-platform.
Ceph levert gedeelde opslag tussen de nodes, terwijl Proxmox het VM-beheer, de clustering en HA regelt.
Deze opslag is specifiek bedoeld voor infrastructuurworkloads, zoals:
- Schijven van virtuele machines
- Containerschijven
- Kubernetes-nodes
- Infrastructuurservices
Wat ik deze keer wilde voorkomen, was dat deze opslag vermengd raakt met grote hoeveelheden gebruikersdata.
VM-opslag en opslag voor gebruikersbestanden hebben andere toegangspatronen en andere prioriteiten, dus die worden gescheiden.
Aparte Ceph-opslag voor gebruikersdata
Er komt een tweede Ceph-omgeving, opgebouwd rond de 1 TB-schijven die in het cluster beschikbaar zijn.
In plaats van schijven van virtuele machines komen hier vooral gebruikersbestanden op te staan.
De opslag wordt via S3 aangeboden, met Cloudreve als frontend voor gebruikers.
Het pad ziet er ongeveer zo uit:
Cloudreve → S3 → Ceph object storage
Zo krijgen applicaties een S3-compatibele interface, terwijl de onderliggende opslag over meerdere machines verdeeld blijft.
Door de twee Ceph-toepassingen te scheiden, is het ontwerp ook makkelijker te begrijpen.
De ene opslagomgeving is er voor infrastructuur.
De andere is er voor data.
Kubernetes
Het k3s-cluster van vijf nodes blijft het belangrijkste platform voor gecontaineriseerde services.
De k3s-nodes draaien bovenop de Proxmox-omgeving en hosten de meeste services die geen eigen virtuele machine nodig hebben.
Denk aan dingen als:
- Cloudreve
- Monitoring
- Interne applicaties
- Webservices
- Ondersteunende infrastructuur
Omdat Kubernetes gevirtualiseerd blijft, zijn de nodes ook relatief wegwerpbaar. Het gaat om de clusterconfiguratie, de persistente opslag en de applicatiedefinities, niet om de losse VM zelf.
Het doel op langere termijn is om zoveel mogelijk configuratie reproduceerbaar te houden, in plaats van afhankelijk te zijn van handmatig ingerichte systemen.
Dedicated 2U-computeserver
Niet alles past even goed in het hoofdcluster.
Voor zwaardere workloads bouw ik op dit moment een aparte 2U-server met NixOS.
Het systeem heeft op dit moment:
- 16 CPU-cores
- 64 GB RAM
- RTX 4060
- 2 × 2 TB-schijven in RAID
- NixOS
Deze machine is bedoeld voor workloads waarbij pure rekenkracht of directe toegang tot een GPU belangrijker is dan high availability.
Geplande workloads zijn onder andere:
- Video-encoding
- Gamestreaming
- GPU-workloads
- Bestanden serveren
- Rekenintensieve taken
- Windows-VM
- Ubuntu-VM
De RTX 4060 is vooral handig voor workloads zoals hardwarematige video-encoding en gamestreaming.
Deze server staat bewust los van het Proxmox-cluster. Als hij niet beschikbaar is, moet de kerninfrastructuur gewoon blijven draaien.
Cloudflare en externe services
Cloudflare blijft tussen delen van het homelab en het publieke internet zitten.
Op dit moment regelt het onder andere:
- Externe DNS
- Cloudflare-tunnels
- Gecontroleerde toegang tot interne services
Ook draait niet elke workload in het homelab.
Sommige services, vooral websites van klanten en andere publieke workloads, blijven op externe cloudinfrastructuur draaien.
Zo blijven publieke workloads gescheiden van het thuisnetwerk, terwijl DNS en toegang toch vanaf dezelfde plek beheerd kunnen worden.
Wat er anders is dan in de oude setup
De losse technologieën verschillen niet radicaal van wat ik al gebruikte. Proxmox, Kubernetes, Cloudflare, S3-opslag, VLAN’s en self-hosted applicaties maakten al deel uit van de omgeving.
Het grootste verschil is hoe ze verdeeld zijn.
In de vorige setup was het makkelijk om nog een VM, container, schijf of service toe te voegen, maar mettertijd zorgden die toevoegingen voor afhankelijkheden die niet altijd duidelijk waren.
Het nieuwe ontwerp probeert die verantwoordelijkheden gescheiden te houden:
Check Point regelt de netwerkrand.
Aruba regelt de switching.
Proxmox regelt de algemene virtualisatie.
Ceph regelt de gedistribueerde infrastructuuropslag.
k3s regelt de gecontaineriseerde workloads.
Ceph S3 regelt de gebruikersdata.
Cloudreve levert de frontend voor bestanden.
De NixOS 2U-server regelt rekenintensieve en GPU-workloads.
Cloudflare regelt externe DNS en tunnels.
Die scheiding is waarschijnlijk de belangrijkste les uit de vorige setup. Een homelab kan verrassend complex worden zodra opslag, netwerk, virtualisatie en applicaties allemaal van elkaar afhankelijk worden.
De nieuwe setup is vooral een poging om die grenzen duidelijker te houden en toch genoeg ruimte te laten om te experimenteren.
Er moet nog behoorlijk wat gebouwd worden, vooral rond Ceph, failover, het VLAN-ontwerp, monitoring, back-ups en de 2U-server, dus deze architectuur verandert waarschijnlijk nog wel een keer naarmate de herbouw vordert.