Why use a ZimaCube 2 instead of a traditional NAS for a Proxmox cluster?

Three reasons: 10GbE, PCIe expansion, and ZFS-native architecture. Most consumer NAS devices ship with 1GbE, which bottlenecks immediately when serving multiple hypervisors. The ZimaCube 2 10GbE port plus dual 2.5GbE gives you the bandwidth to serve storage without contention. And the PCIe slot means you can add a GPU or faster NIC later without replacing the entire device.

Can ZimaOS handle ZFS well enough for cluster storage?

Yes. ZimaOS includes ZFS pool creation, snapshot scheduling, and health monitoring in its storage manager. For a cluster backend, the key features — pool creation, NFS/SMB sharing, snapshot automation — are all there without requiring terminal configuration.

How much RAM does the ZimaCube 2 need for ZFS?

ZFS uses RAM for ARC (cache), and more RAM means faster read performance. The stock 8GB or 16GB is workable for light workloads, but for serving multiple VMs or containers with a large dataset, upgrading to 32GB or 64GB is recommended. SODIMM DDR5 slots are user-accessible — the upgrade takes minutes.

What is the advantage of keeping the Coral TPU on a separate ZimaBlade instead of the ZimaCube 2?

Offloading Frigate object detection to a dedicated ZimaBlade with Coral TPU keeps inference load entirely off the ZimaCube 2 CPU and GPU. The ZimaCube 2 handles storage and Docker services; the ZimaBlade handles real-time video analysis. Separating those workloads prevents camera processing from competing with VM I/O or AI inference on the main system.

Hur jag byggde en 3-nods Proxmox-kluster med ZimaCube 2 som delad lagringsbackend

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

How I Built a 3-Node Proxmox Cluster Around the ZimaCube 2 as the Shared Storage Backend - Zima Store Online

Tre Proxmox-noder. En ZimaCube 2. Tio gigabit Ethernet. Allt detta sitter i en Ikea Kallax-hylla, körs dygnet runt, tystare än kylskåpet i nästa rum.

Det här är inte en hypotetisk konstruktion. Det är mitt homelab — ett helt 3D-utskrivet 10-tums rack som passar snyggt i en standard Kallax-kub, med ZimaCube 2 längst ner som den delade lagringshjärnan för hela klustret. Här är varför jag valde ZimaCube 2 för denna roll, hur jag integrerade det och vad jag lärde mig på vägen.

Arkitekturen

Mitt kluster har tre beräkningsnoder som kör Proxmox med eMMC-bootlagring och ZFS-replikering mellan dem. Målet är full hög tillgänglighet HCI — om en nod går ner migrerar arbetsbelastningar automatiskt och lagringen förblir konsekvent.

Men ZFS-replikering mellan tre noder räcker bara så långt. Du behöver fortfarande en delad lagringsbackend — något med tillräcklig kapacitet, bandbredd och tillförlitlighet för att fungera som den enda sanningskällan för hela klustret. Det är där ZimaCube 2 kommer in.

🧠 ZimaCube 2 är lagringshjärnan i klustret. De tre Proxmox-noderna hanterar beräkning. ZimaCube 2 hanterar allt annat — delad lagring, säkerhetskopior, mediedataset och 100GbE-ryggraden som binder ihop allt.

Varför ZimaCube 2 som SAN/NAS-backend

Jag tittade på många alternativ innan jag landade på ZimaCube 2. Här är vad som gjorde det till rätt val:

Vad jag behövde

6+ enhetsfack för blandade HDD/NVMe-pooler
10GbE för att servera klustret utan flaskhalsar
PCIe-expansion för framtida GPU/NIC-uppgraderingar
Docker-native för att köra infrastrukturtjänster tillsammans med lagring
Tillräckligt tyst för ett vardagsrum (inte en källare)
Tillräckligt kompakt för att passa i en Kallax-kub

Vad ZimaCube 2 levererar

6× SATA3-fack + 4× M.2 NVMe i det 7:e facket
10GbE (Marvell AQC113) + 2× 2,5GbE (Intel i226)
PCIe x16 Gen4 + PCIe x8 Gen3-platser
Förinstallerat ZimaOS med Docker-stöd
240 × 221 × 220 mm — exakt Kallax-kompatibel
Metallchassi med aktiv kylning, nästan ljudlös i vila

10GbE-porten var avgörande. Om du serverar lagring till tre hypervisornoder samtidigt blir en enda gigabit-länk flaskhals redan från dag ett. ZimaCube 2 med 10GbE gör att jag kan mätta klusternätverket innan lagringsbackend blir mättad.

Snygg silverfärgad ZimaCube 2 mini-server placerad på träbyrå i minimalistiskt vardagsrum bredvid TV:n

Lagringskonfiguration

Så här har jag organiserat lagringspoolerna på ZimaCube 2:

Pool	Enheter	Filsystem	Syfte
VM-lagring	2× NVMe (RAID 1)	ZFS	Proxmox VM/CT-bilder, mål för live-migrering
Stordata	4× HDD (RAID-Z1)	ZFS	Mediebibliotek, säkerhetskopior, ISO-arkiv, dataset
Snabb cache	1× NVMe	ZFS SLOG/L2ARC	Skrivcache för HDD-poolen, metadataacceleration
OS + Docker	1× NVMe (ombord)	ext4	ZimaOS, Docker-containrar, infrastrukturtjänster

Klustret ansluter till ZimaCube 2 via en dedikerad 10GbE-länk. Varje Proxmox-nod kopplas via 2.5GbE till en hanterad switch, med ZimaCube 2 på 10GbE uplink-porten. Live-migreringar av VM sker över NFS från NVMe-poolen. Media och säkerhetskopior finns på HDD-poolen. Allt är ZFS-baserat med snapshots.
Notering om RAM-uppgradering: ZimaCube 2 levereras med 8GB DDR5 (Standard) eller 16GB (Pro). För en ZFS-baserad lagringsbackend är mer RAM bättre — ZFS använder ARC (Adaptive Replacement Cache) i minnet, och varje gigabyte ARC är en gigabyte lagring som inte behöver nå disken. Jag lade till en 32GB DDR5 SODIMM-sticka för att få totalt 40GB, vilket ger ZFS gott om ARC-utrymme utan att svälta Docker-containrarna.

Den fysiska konstruktionen: Allt 3D-utskrivet

Hela uppsättningen finns i ett 10-tums rackformat, 3D-utskrivet på en Elegoo Centauri Carbon och designat för att passa exakt in i en standard Ikea Kallax-hyllkub.

ZimaCube 2 står längst ner i racket — dess vikt och kylbehov gör det till den naturliga basen. Ovanför finns tre beräkningsnoder, en dedikerad brandväggsapparat och en patchpanel. Allt är monterat med specialtillverkade 3D-utskrivna fästen och ventilationspaneler.

📐 ZimaCube 2:s mått (240 × 221 × 220 mm) är nästan kusligt perfekta för 10-tums rackformatet. Det är som om IceWhale mätte en Kallax-kub innan de designade chassit. Bredden på 220 mm lämnar precis tillräckligt med utrymme för luftflöde på båda sidor av en standard 10-tums hylla.

Alla STL-filer och remixar finns tillgängliga på MakerWorld och Printables. Jag designade specialanpassade fästen för ZimaCube 2, ZimaBlade-enheterna och brandväggsapparaten.

Baksidan av ZimaCube 2 mini-server monterad i ett träskåp, visar multi-Gigabit Ethernet, USB-portar och ventilationsgaller

Varför inte TrueNAS eller Unraid?

Jag behöll ZimaOS på ZimaCube 2 istället för att radera det för TrueNAS eller Unraid. Här är min motivering:

1.Docker-native från dag ett. Inget plugin-system att bråka med. docker-compose up och du är klar.

2.Inbyggt stöd för ZFS. ZimaOS lagringshanterare sköter skapandet av ZFS-pooler och schemaläggning av snapshots utan att kräva terminaltid.

Linux-terminal på ZimaCube som visar zpool create-kommandon och statusutdata för en frisk ONLINE ZFS pool1-lagring

3.IceWhale utvecklar det aktivt. Jag testar en ZimaOS Beta-version direkt från deras team — responsen på communityns feedback har verkligen varit bra.

4.Jag ville testa plattformen som den är designad. Du kan alltid radera och installera något annat senare. Men om ZimaOS klarar arbetsbelastningen är det ett operativsystem mindre att konfigurera och underhålla.

För en klusterlagrings-backend är stabilitet viktigare än funktioner. Hittills har ZimaOS levererat.

Vad som körs på klustret

De tre Proxmox-noderna kör för närvarande:

Home Assistant med Zigbee2MQTT — smart hemautomation
Frigate NVR på en dedikerad ZimaBlade med Coral TPU — 4 utomhuskameror, objektdetektering avlastad till TPU:n
Paperless-ngx — dokumenthantering
Vaultwarden — lösenordshantering
Nginx Proxy Manager — omvänd proxy och SSL
Pi-hole — nätverksomfattande DNS-filtrering
Gitea — självhostad Git för personliga projekt
Flera utvecklings-VM:ar för testning och lärande

ZimaCube 2 kör också några infrastrukturcontainrar direkt: Uptime Kuma för övervakning, en backup-orchestrator och ZFS snapshot-schemaläggare.

Bygg din egen klusterlagrings-backend med ZimaCube 2 →

Vanliga frågor

Varför använda en ZimaCube 2 istället för en traditionell NAS för ett Proxmox-kluster?

Tre anledningar: 10GbE, PCIe-expansion och ZFS-native arkitektur. De flesta konsument-NAS-enheter levereras med 1GbE, vilket snabbt blir en flaskhals när flera hypervisorer servas. ZimaCube 2:s 10GbE-port plus dubbla 2.5GbE ger dig bandbredd att serva lagring utan konkurrens. Och PCIe-platsen gör att du kan lägga till ett GPU eller snabbare nätverkskort senare utan att byta ut hela enheten.

Kan ZimaOS hantera ZFS tillräckligt bra för klusterlagring?

Ja. ZimaOS inkluderar skapande av ZFS-pooler, schemaläggning av snapshots och hälsomonitorering i sin lagringshanterare. För en kluster-backend finns nyckelfunktionerna — poolskapande, NFS/SMB-delning, snapshot-automation — utan att kräva terminalkonfiguration.

Hur mycket RAM behöver ZimaCube 2 för ZFS?

ZFS använder RAM för ARC (cache), och mer RAM innebär snabbare läsprestanda. Standard 8GB eller 16GB fungerar för lätta arbetsbelastningar, men för att serva flera VM:ar eller containrar med stora datamängder rekommenderas uppgradering till 32GB eller 64GB. SODIMM DDR5-platser är användartillgängliga — uppgraderingen tar bara några minuter.

Vad är fördelen med att ha Coral TPU på en separat ZimaBlade istället för på ZimaCube 2?

Att avlasta Frigate-objektdetektering till en dedikerad ZimaBlade med Coral TPU håller inferensbelastningen helt borta från ZimaCube 2:s CPU och GPU. ZimaCube 2 hanterar lagring och Docker-tjänster; ZimaBlade sköter realtidsvideoanalys. Att separera dessa arbetsbelastningar förhindrar att kamerabehandling konkurrerar med VM I/O eller AI-inferens på huvudsystmet.