Una nota da Zima
Grazie, Ted, per aver documentato ZimaCube 2 come un sistema che cresce per livelli, anziché come un dispositivo già completo. La tua build Pioneer registra gli aggiornamenti riusciti, i benchmark dello storage, la migrazione di Immich e le parti che hanno dato del filo da torcere — incluso un percorso Thunderbolt che alla fine è diventato una soluzione OCuLink. Pubblicando misurazioni, soluzioni alternative, errori e decisioni hardware in evoluzione man mano che la build procede, stai offrendo alla community qualcosa di più utile di una semplice scheda tecnica finale: una testimonianza di come si evolve un homelab ZimaOS reale.
— Zima
Incontra ted-knight
Ted-knight sta documentando una delle build di ZimaCube 2 più metodiche del Pioneer Program. Il suo Build di ZimaCube 2 non è organizzato attorno a un'unica configurazione finale. Il progetto è invece suddiviso in fasi, con ogni livello testato prima di aggiungere quello successivo.
L'obiettivo del progetto è semplice: creare un NAS a cui poter affidare dati importanti già oggi, lasciando al contempo spazio sufficiente per il self-hosting, i contenuti multimediali, l'IA locale e altri carichi di lavoro in futuro. Questo ha portato ted ad approfondire l'architettura dello storage, ZFS, btrfs, gli aggiornamenti di RAM e NVMe, l'espansione OCuLink, i benchmark, l'integrazione con ZimaOS, la migrazione di Immich e una roadmap sempre più dettagliata per ciò che la macchina potrebbe diventare.
Ha iniziato con lo ZimaCube 2 Standard: un sistema con Intel Core i3-1215U, 8 GB di DDR5 e un'unità NVMe di sistema da 256 GB. La configurazione originale non è rimasta tale a lungo.
Costruire le fondamenta dello storage prima di aggiungere altri servizi
La prima priorità di Ted non era riempire il server di applicazioni, ma decidere dove dovessero risiedere i diversi tipi di dati.
Il sistema risultante utilizza diversi livelli di archiviazione, ciascuno con un ruolo volutamente diverso. ZimaOS resta sul suo Kingston NVMe da 256 GB dedicato. Un Crucial P510 NVMe da 2 TB è diventato Arctic-Storage, un livello btrfs per AppData, immagini Docker, database e altri carichi di lavoro attivi. Quattro unità NVMe da 2 TB formano glacier, un pool ZFS RAIDZ1 con circa 5,5 TB di spazio utilizzabile. In seguito, quattro unità Seagate IronWolf da 4 TB sono diventate un pool btrfs RAID5 da 12 TB per i contenuti multimediali in massa e i dati meno utilizzati.
L'architettura non consiste tanto nel far comportare tutte le unità allo stesso modo, quanto nell'abbinare lo storage al carico di lavoro. I database con un uso intensivo dell'I/O casuale appartengono al veloce P510. I carichi sequenziali più grandi e i dati che beneficiano dei checksum e della ridondanza ZFS possono risiedere su glacier. I contenuti multimediali in massa possono essere spostati sul livello IronWolf a maggiore capacità.
Quando Thunderbolt 4 non ha funzionato, l'architettura è cambiata
Uno degli aspetti più utili del progetto di ted è che gli esperimenti falliti sono rimasti nella documentazione.
Il piano originale prevedeva di collegare un case Aoostar TB4S-OC a quattro NVMe allo ZimaCube 2 tramite Thunderbolt 4. Ted ha testato diversi cavi da 40 Gbps, entrambe le porte Thunderbolt, l'alimentazione esterna e il comportamento del kernel sottostante, ma il case non è comunque riuscito a stabilire una connessione PCIe stabile.
L'indagine ha infine evidenziato l'interazione tra la configurazione Thunderbolt di ZimaOS e il controller ASMedia ASM2462PDX all'interno del case. Invece di continuare a forzare il piano originale, ted ha cambiato l'architettura.
Un adattatore da PCIe x4 a OCuLink è stato installato nello slot 1. Il case Aoostar è passato da Thunderbolt a una connessione OCuLink diretta. Tutte e quattro le unità NVMe sono state rilevate al primo avvio, senza i problemi di tunneling e autorizzazione che avevano bloccato la configurazione Thunderbolt.
Il cambiamento ha influito anche sui piani successivi. Lo slot 1 è ora occupato dallo storage, mentre le due porte Thunderbolt restano disponibili per esperimenti futuri, come il networking diretto o un diverso percorso eGPU. Una connessione non riuscita non è diventata semplicemente una nota a margine nella risoluzione dei problemi: ha cambiato la roadmap dell'intera macchina.
Benchmarking dello storage invece di dare per scontato quale livello fosse più veloce
Una volta disponibile lo storage, ted lo ha misurato.
Il lavoro della Fase 1.5 utilizza fio per confrontare il pool ZFS RAIDZ1 glacier con Arctic-Storage, invece di considerare “NVMe” come un’unica categoria di prestazioni. Il benchmark a freddo ha mostrato che glacier raggiungeva 1.726 MB/s in scrittura sequenziale e 2.591 MB/s in lettura sequenziale, mentre il livello Arctic a unità singola era molto più forte nell’I/O casuale, raggiungendo 205.588 IOPS di lettura casuale 4K nella posizione originale.
Il risultato più interessante è emerso quando la cache ARC di ZFS è entrata in gioco. Le letture ripetute da glacier potevano essere servite dalla RAM invece di tornare alle unità NVMe. Con la precedente configurazione da 16 GB di memoria, le letture casuali a caldo hanno raggiunto circa 83.929 IOPS, invece del risultato a freddo di 14.781 IOPS.
Questa scoperta ha influenzato in seguito un’altra decisione hardware. Ted ha portato la macchina a 32 GB usando due moduli DDR5 da 16 GB, passando dalla memoria single-channel a quella dual-channel. Dopo l’aggiornamento, le letture casuali ARC a caldo sono aumentate nuovamente, raggiungendo 126.816 IOPS: un miglioramento misurato del 51% rispetto al risultato precedente.
I benchmark hanno anche messo in discussione la posizione iniziale del Crucial P510. Nel 7° alloggiamento del modello Standard, il throughput sequenziale era limitato dal bridge. Ted ha spostato l’unità nello slot M.2 integrato e ha misurato un aumento della lettura sequenziale da 874 MB/s a 1.677 MB/s, mentre le prestazioni di lettura casuale 4K sono salite da 205.588 a 403.078 IOPS.
La lezione non era semplicemente che uno slot fosse più veloce. Le misurazioni hanno cambiato la destinazione dei carichi di lavoro e indicato quali aggiornamenti valessero davvero la pena.
Far funzionare ZFS insieme a ZimaOS
La configurazione evidenzia anche un interessante confine tra ciò che ZimaOS gestisce nativamente e ciò che un utente esperto può aggiungere al di sotto di esso.
Ted usa deliberatamente btrfs per Arctic-Storage e per il pool IronWolf, perché questi volumi si integrano naturalmente con ZimaOS. Il pool glacier è diverso. È stato creato dalla riga di comando come ZFS RAIDZ1, offrendo a ted dataset ZFS, checksum, caching ARC, snapshot e un modello di archiviazione più adatto ad alcuni dei carichi di lavoro previsti.
Questa flessibilità presenta però un limite: i pool ZFS creati dalla riga di comando non vengono visualizzati nell’interfaccia come volumi di archiviazione nativi di ZimaOS.
La soluzione alternativa di Ted è semplice e pratica. Espone i singoli dataset ZFS tramite collegamenti simbolici sotto /DATA, è possibile visualizzare percorsi come i documenti, i contenuti multimediali, i backup e lo spazio di archiviazione delle VM di glacier all’interno dell’app File di ZimaOS, mentre il pool sottostante continua a essere gestito tramite ZFS.
Ha rilevato un altro problema di visibilità relativo alla memoria. ZimaOS può indicare come “utilizzata” una grande parte della RAM quando la cache ARC di ZFS riempie la memoria altrimenti inattiva. Esaminando btop e le statistiche ARC raccontano una storia più utile: la cache sta consumando memoria perché questa è disponibile, e ZFS può liberarla quando le applicazioni ne hanno bisogno.
Questo è il tipo di feedback che conta in una realizzazione Pioneer. Ted non mostra soltanto cosa funziona in ZimaOS; documenta anche il punto in cui una configurazione di storage avanzata raggiunge i limiti dell'interfaccia utente attuale e cosa fa quando ci arriva.
Trasferire una libreria Immich esistente senza perderne la cronologia
L'architettura dello storage diventa molto più significativa quando su di essa iniziano a essere spostati dati insostituibili.
Per ted, quella prova era Immich. Aveva già un'istanza Immich in esecuzione su un vecchio server ZimaOS fai-da-te e voleva trasferirla su ZimaCube 2 senza ricominciare da zero.
La migrazione ha riguardato 14.505 foto e 925 video, per un totale di 134 GiB. Tuttavia, i dati importanti non erano limitati ai file immagine. Album, persone, riconoscimento facciale, ricordi, link condivisi e altri metadati erano archiviati in PostgreSQL.
Utilizzando l'app File di ZimaOS sulla LAN, ted ha copiato entrambi /DATA/Gallery/immich e l'intero /DATA/AppData/immich directory, inclusi pgdata. L'istanza Immich di origine è stata arrestata prima della copia, in modo da mantenere coerenti i dati PostgreSQL.
Dopo la migrazione, l'account, gli album, le informazioni sui volti, i ricordi e la libreria sono rimasti intatti, senza alcuna perdita di dati segnalata. Ted ha quindi verificato direttamente il database PostgreSQL, invece di presumere che un accesso riuscito significasse che tutto fosse stato conservato.
Se stai pianificando un trasferimento dello stesso tipo, la nostra guida alla migrazione di Immich per ZimaCube 2 illustra la stessa distinzione fondamentale: spostare solo la libreria multimediale non basta: anche il database deve essere trasferito.
Da una migrazione di 134 GiB a 725 GiB di foto e video self-hosted
La fase Immich non si è conclusa quando la migrazione dal vecchio server è andata a buon fine.
Quello che era iniziato come il trasferimento di una libreria ZimaOS esistente si è trasformato in un passaggio molto più ampio, abbandonando iCloud come archivio principale per le foto e i video di ted. Il suo iPhone ha iniziato a trasferire la libreria originale di iCloud in Immich, in esecuzione su ZimaCube 2.
Al termine di quella fase, il server conteneva 63.665 elementi per un totale di 725 GiB: 55.604 foto e 8.061 video. Il trasferimento da iCloud rappresentava circa 655 GB, con i video 4K responsabili della maggior parte di quello spazio.
L'obiettivo non era fingere che ogni servizio cloud di Apple potesse essere sostituito. Ted ha comunque individuato backup dei dispositivi, messaggi e altri dati specifici di iOS che ha senso mantenere in un piano iCloud più economico. Il cambiamento era più mirato: spostare la grande libreria di foto e video su uno storage sotto il suo controllo, mantenendo i servizi cloud che continuano a essere utili.
Questa decisione ha creato anche una nuova responsabilità. Una libreria fotografica self-hosted diventa più sicura di una copia nel cloud solo quando viene sottoposta a un backup adeguato. Per questo le note di migrazione di Ted includono una seconda copia su TrueNAS, gettando le basi per la più ampia fase di backup 3-2-1 ancora prevista nella roadmap.
Costruire intorno a ciò che ZimaOS rende semplice e misurare il resto
Ted ha scelto ZimaOS deliberatamente. Dopo anni di utilizzo di Synology e una lunga esperienza come utente di CasaOS, voleva un modello applicativo più pulito e incentrato su Docker, mantenendo al contempo l'accesso al sistema sottostante quando la configurazione richiedeva qualcosa di più avanzato.
Diverse parti del progetto sfruttano questo equilibrio. Lo strumento integrato per la migrazione di AppData ha spostato i dati delle applicazioni Docker dall'unità di sistema ad Arctic-Storage senza dover ricreare ogni app. L'app File ha fornito il flusso di lavoro sulla LAN utilizzato per la migrazione di Immich. Gli strumenti nativi, tra cui fio, zpool, zfs, nvme, e iostat ha permesso di misurare e gestire l'architettura dello storage al di sotto del livello grafico.
Altri aspetti mostrano dove l'esperienza è ancora meno integrata. Lo storage ZFS creato dalla CLI richiede una soluzione alternativa basata su symlink. ARC rende facile interpretare erroneamente il quantitativo standard di RAM. Il comportamento di Thunderbolt ha imposto una riprogettazione hardware.
Queste osservazioni rendono il progetto più interessante di una vetrina in cui ogni esperimento funziona al primo tentativo. Ted sta documentando il confine tra una semplice esperienza ZimaOS e il lavoro più approfondito da homelab che inizia quando si decide di oltrepassarlo.
Cosa è già stato realizzato e cosa è ancora nella roadmap
Il titolo del repository di ted descrive la destinazione come un NAS compatto basato sull'IA, ma il progetto viene sviluppato intenzionalmente in più fasi.
La base è già una realtà. Lo storage a livelli è operativo. Il pool ZFS RAIDZ1 glacier è funzionante. Arctic-Storage è stato spostato nello slot M.2 integrato. La memoria ha raggiunto 32 GB in dual channel. Il pool IronWolf RAID5 esiste. I benchmark dello storage sono stati completati. La migrazione di Immich e il consolidamento più ampio delle foto di iCloud sono stati completati.
Il livello multimediale è ancora in crescita. Il pool IronWolf è stato creato per i contenuti multimediali in grandi quantità, mentre Jellyfin e lo stack più ampio di *arr fanno ancora parte del lavoro attuale della Fase 2.
I livelli dedicati all'IA sono ancora da realizzare. La roadmap di Ted prevede attualmente i test di Ollama solo con CPU nella Fase 4a, seguiti da un percorso con eGPU RTX 4090 nella Fase 4b e dalla ricerca semantica nell'archiviazione locale nella Fase 5.
Questa distinzione è importante. ZimaCube 2 viene già preparato per l'IA locale attraverso il posizionamento dello storage, la capacità di memoria, le scelte PCIe e la pianificazione dei carichi di lavoro, ma il progetto non è ancora arrivato al punto in cui l'inferenza con GPU possa essere presentata come un risultato completato.
Per i lettori che stanno già esplorando questa direzione futura, la nostra guida all'IA locale su ZimaCube 2 analizza come Ollama, la memoria, l'espansione PCIe e i successivi aggiornamenti con GPU possano inserirsi in una roadmap simile per un homelab.
Un progetto che cambia quando cambiano le evidenze
Il modello più coerente nel progetto di ted non è ZFS, Immich o un componente hardware specifico. È la disponibilità a cambiare una decisione dopo aver misurato ciò che è realmente accaduto.
Il contenitore Thunderbolt non ha funzionato, quindi il percorso di archiviazione è passato a OCuLink.
Il P510 non poteva sfruttare il suo potenziale nel 7th Bay, quindi è stato spostato nello slot M.2 integrato.
ZFS ARC ha offerto prestazioni migliori del previsto, quindi la memoria è diventata un miglioramento delle prestazioni, non semplicemente capacità aggiuntiva.
Una migrazione di Immich da 134 GiB è riuscita senza perdere il database, così l'esperimento si è ampliato, spostando altri centinaia di gigabyte fuori da iCloud.
Ogni fase lascia misurazioni, comandi, errori e ipotesi aggiornate per la fase successiva. Questo rende il repository utile anche a chi non realizza esattamente la stessa configurazione di archiviazione.
La storia è ancora in fase di scrittura
La storia di ted-knight e Zima è ancora in fase di scrittura. ZimaCube 2 è partito come modello Standard da 8 GB ed è già diventato un sistema di archiviazione a più livelli con btrfs, ZFS RAIDZ1, espansione NVMe OCuLink, 32 GB di memoria dual-channel, un archivio IronWolf RAID5 e una libreria Immich self-hosted che contiene centinaia di gigabyte di contenuti multimediali personali.
Le prossime fasi sono volutamente ancora aperte: Jellyfin e lo stack multimediale, procedure di backup più solide, IA locale solo con CPU, un futuro percorso con GPU, ricerca semantica e qualsiasi altra cosa che le misurazioni spingeranno ted a riconsiderare lungo il cammino.
Se vuoi seguire il progetto mentre queste fasi passano dalla roadmap ai risultati concreti, segui su GitHub il progetto in corso di ted-knight con ZimaCube 2.
