Come ho costruito un cluster Proxmox a 3 nodi attorno allo ZimaCube 2 come backend di archiviazione condivisa

Tre nodi Proxmox. Un ZimaCube 2. Ethernet da dieci gigabit. Tutto dentro una mensola Ikea Kallax, in funzione 24/7, più silenzioso del frigorifero nella stanza accanto.

Questa non è una costruzione ipotetica. Questo è il mio homelab — un rack da 10 pollici completamente stampato in 3D che si inserisce perfettamente in un cubo Kallax standard, con il ZimaCube 2 in basso che funge da cervello di archiviazione condivisa per l’intero cluster. Ecco perché ho scelto il ZimaCube 2 per questo ruolo, come l’ho integrato e cosa ho imparato lungo il percorso.

L’architettura

Il mio cluster ha tre nodi di calcolo che eseguono Proxmox con avvio da eMMC e replica ZFS tra loro. L’obiettivo è un HCI ad alta disponibilità completa — se un nodo si spegne, i carichi di lavoro migrano automaticamente e l’archiviazione rimane coerente.

Ma la replica ZFS tra tre nodi ha i suoi limiti. Serve ancora un backend di archiviazione condivisa — qualcosa con capacità, larghezza di banda e affidabilità sufficienti per fungere da fonte unica di verità per l’intero cluster. Qui entra in gioco il ZimaCube 2.

Perché il ZimaCube 2 come backend SAN/NAS

Ho valutato molte opzioni prima di scegliere il ZimaCube 2. Ecco cosa lo ha reso la scelta giusta:

Cosa mi serviva

• 6+ baie per unità per pool misti HDD/NVMe

• 10GbE per servire il cluster senza colli di bottiglia

• Espansione PCIe per futuri aggiornamenti GPU/NIC

• Nativo Docker per eseguire servizi infrastrutturali insieme all’archiviazione

• Abbastanza silenzioso per uno spazio abitativo (non una cantina)

• Abbastanza compatto da entrare in un cubo Kallax

Cosa offre il ZimaCube 2

• 6× baie SATA3 + 4× M.2 NVMe nella 7ª baia

• 10GbE (Marvell AQC113) + 2× 2.5GbE (Intel i226)

• Slot PCIe x16 Gen4 + PCIe x8 Gen3

• ZimaOS preinstallato con supporto Docker

• 240 × 221 × 220 mm — esattamente compatibile con Kallax

• Chassis in metallo con raffreddamento attivo, quasi silenzioso a riposo

La porta 10GbE è stata il fattore decisivo. Se stai servendo archiviazione a tre nodi hypervisor contemporaneamente, un singolo collegamento gigabit diventa il collo di bottiglia dal primo giorno. Il 10GbE del ZimaCube 2 significa che posso saturare la rete del cluster prima di saturare il backend di archiviazione.

Configurazione di archiviazione

Ecco come ho organizzato i pool di archiviazione sul ZimaCube 2:

Il cluster accede al ZimaCube 2 tramite un collegamento dedicato 10GbE. Ogni nodo Proxmox si connette via 2.5GbE a uno switch gestito, con il ZimaCube 2 sulla porta uplink 10GbE. Le migrazioni live delle VM avvengono tramite NFS dal pool NVMe. Media e backup risiedono sul pool HDD. Tutto è supportato da ZFS con snapshot.
Nota sull’aggiornamento RAM: Il ZimaCube 2 viene fornito con 8GB DDR5 (Standard) o 16GB (Pro). Per un backend di archiviazione basato su ZFS, più RAM è meglio — ZFS usa ARC (Adaptive Replacement Cache) in memoria, e ogni gigabyte di ARC è un gigabyte di archiviazione che non tocca il disco. Ho aggiunto un modulo SODIMM DDR5 da 32GB per portare il totale a 40GB, che dà a ZFS ampio margine ARC senza privare i container Docker.

La costruzione fisica: tutto stampato in 3D

L’intera configurazione vive in un formato rack da 10 pollici, stampato in 3D su un Elegoo Centauri Carbon e progettato per adattarsi esattamente all’interno di un cubo mensola Ikea Kallax standard.

Il ZimaCube 2 si trova alla base del rack — il suo peso e le esigenze di raffreddamento lo rendono la base naturale. Sopra: tre nodi di calcolo, un’appliance firewall dedicata e un pannello patch. Tutto è montato con staffe e pannelli di ventilazione stampati in 3D su misura.

Tutti i file STL e i remix sono disponibili su MakerWorld e Printables. Ho progettato supporti personalizzati per il ZimaCube 2, le unità ZimaBlade e l’appliance firewall.

Perché non TrueNAS o Unraid?

Ho mantenuto ZimaOS sul ZimaCube 2 invece di cancellarlo per TrueNAS o Unraid. Ecco il mio ragionamento:

1.Docker-nativo fin dal primo giorno. Nessun sistema di plugin con cui lottare. docker-compose up e hai finito.

2.Supporto ZFS integrato. Il gestore di archiviazione di ZimaOS gestisce la creazione dei pool ZFS e la programmazione degli snapshot senza richiedere tempo da terminale.

3.IceWhale lo sta sviluppando attivamente. Sto testando una build Beta di ZimaOS direttamente dal loro team — la reattività ai feedback della community è stata davvero buona.

4.Volevo testare la piattaforma così com'è progettata. Puoi sempre cancellare e installare altro in seguito. Ma se ZimaOS gestisce il carico, è un sistema operativo in meno da configurare e mantenere.

Per un backend di storage cluster, la stabilità conta più delle funzionalità. Finora, ZimaOS ha mantenuto le promesse.

Cosa gira sul Cluster

I tre nodi Proxmox attualmente ospitano:

• Home Assistant con Zigbee2MQTT — automazione domestica intelligente
• Frigate NVR su una ZimaBlade dedicata con Coral TPU — 4 telecamere esterne, rilevamento oggetti delegato al TPU
• Paperless-ngx — gestione documenti
• Vaultwarden — gestione password
• Nginx Proxy Manager — reverse proxy e SSL
• Pi-hole — filtro DNS a livello di rete
• Gitea — Git self-hosted per progetti personali
• Diverse VM di sviluppo per test e apprendimento

Il ZimaCube 2 esegue anche alcuni container infrastrutturali direttamente: Uptime Kuma per il monitoraggio, un orchestratore di backup e il pianificatore di snapshot ZFS.

Costruisci il tuo backend di storage cluster con ZimaCube 2 →

Domande Frequenti

Perché usare un ZimaCube 2 invece di un NAS tradizionale per un cluster Proxmox?

Tre motivi: 10GbE, espansione PCIe e architettura nativa ZFS. La maggior parte dei NAS consumer ha 1GbE, che diventa subito un collo di bottiglia servendo più hypervisor. La porta 10GbE del ZimaCube 2 più le due 2.5GbE offrono la larghezza di banda per servire lo storage senza contese. Lo slot PCIe permette di aggiungere una GPU o una NIC più veloce in seguito senza sostituire l'intero dispositivo.

ZimaOS gestisce bene ZFS per lo storage di un cluster?

Sì. ZimaOS include la creazione di pool ZFS, la pianificazione degli snapshot e il monitoraggio dello stato nel suo gestore di storage. Per un backend cluster, le funzionalità chiave — creazione pool, condivisione NFS/SMB, automazione snapshot — sono tutte presenti senza necessità di configurazione da terminale.

Quanta RAM serve al ZimaCube 2 per ZFS?

ZFS utilizza la RAM per l'ARC (cache), e più RAM significa prestazioni di lettura più veloci. I 8GB o 16GB di serie sono sufficienti per carichi leggeri, ma per servire più VM o container con un grande dataset, si consiglia l'upgrade a 32GB o 64GB. Gli slot SODIMM DDR5 sono accessibili all'utente — l'aggiornamento richiede pochi minuti.

Qual è il vantaggio di mantenere il Coral TPU su una ZimaBlade separata invece che sul ZimaCube 2?

Delegare il rilevamento oggetti di Frigate a una ZimaBlade dedicata con Coral TPU mantiene il carico di inferenza completamente fuori dalla CPU e GPU del ZimaCube 2. Il ZimaCube 2 gestisce lo storage e i servizi Docker; la ZimaBlade si occupa dell'analisi video in tempo reale. Separare questi carichi di lavoro evita che l'elaborazione delle telecamere entri in competizione con l'I/O delle VM o l'inferenza AI sul sistema principale.