Una nota de Zima
Gracias, Ted, por documentar el ZimaCube 2 como un sistema que crece por capas, en lugar de un dispositivo terminado. Tu proyecto Pioneer registra las ampliaciones realizadas correctamente, las pruebas de rendimiento del almacenamiento, la migración de Immich y los componentes que se resistieron —incluida una conexión Thunderbolt que finalmente se convirtió en una solución OCuLink—. Al publicar las mediciones, las soluciones alternativas, los errores y las decisiones cambiantes sobre el hardware a medida que avanza el proyecto, estás ofreciendo a la comunidad algo más útil que una simple hoja de especificaciones final: un registro de cómo evoluciona un homelab real con ZimaOS.
— Zima
Conoce a ted-knight
Ted-knight está documentando uno de los proyectos de ZimaCube 2 más metódicos del Pioneer Program. Su proyecto de ZimaCube 2 no está organizado en torno a una única configuración final. En su lugar, el proyecto se divide en fases, y cada capa se prueba antes de añadir la siguiente.
El objetivo del proyecto es sencillo: crear un NAS en el que se puedan confiar datos importantes hoy, dejando al mismo tiempo suficiente margen para el autohospedaje, los medios, la IA local y otras cargas de trabajo en el futuro. Esto ha llevado a ted por la arquitectura de almacenamiento, ZFS, btrfs, las ampliaciones de RAM y NVMe, la expansión OCuLink, las pruebas de rendimiento, la integración con ZimaOS, la migración de Immich y una hoja de ruta cada vez más detallada sobre aquello en lo que podría convertirse la máquina.
Comenzó con el ZimaCube 2 Standard: un sistema con Intel Core i3-1215U, 8 GB de DDR5 y una unidad NVMe de sistema de 256 GB. La configuración original no permaneció así durante mucho tiempo.
Construir la base de almacenamiento antes de añadir más servicios
La primera prioridad de Ted no fue llenar el servidor de aplicaciones. Fue decidir dónde deberían residir los distintos tipos de datos.
El sistema resultante utiliza varios niveles de almacenamiento con funciones deliberadamente diferentes. ZimaOS permanece en su propia unidad Kingston NVMe de 256 GB. Un Crucial P510 NVMe de 2 TB se convirtió en Arctic-Storage, un nivel btrfs para AppData, imágenes de Docker, bases de datos y otras cargas de trabajo activas. Cuatro unidades NVMe de 2 TB forman glacier, un grupo ZFS RAIDZ1 con aproximadamente 5,5 TB de espacio utilizable. Más tarde, cuatro unidades Seagate IronWolf de 4 TB se convirtieron en un grupo btrfs RAID5 de 12 TB para medios en bloque y datos menos activos.
La arquitectura consiste menos en hacer que todas las unidades se comporten igual y más en adaptar el almacenamiento a la carga de trabajo. Las bases de datos con muchas operaciones de E/S aleatorias corresponden a la rápida P510. Las cargas de trabajo secuenciales más grandes y los datos que se benefician de las sumas de comprobación y la redundancia de ZFS pueden residir en glacier. Los archivos multimedia en bloque pueden trasladarse al nivel IronWolf de mayor capacidad.
Cuando Thunderbolt 4 no funcionó, la arquitectura cambió
Una de las partes más útiles del proyecto de ted es que los experimentos fallidos siguen incluidos en la documentación.
El plan original era conectar una carcasa Aoostar TB4S-OC de cuatro NVMe al ZimaCube 2 mediante Thunderbolt 4. Ted probó distintos cables de 40 Gbps, ambos puertos Thunderbolt, alimentación externa y el comportamiento del kernel subyacente, pero la carcasa seguía sin establecer una conexión PCIe estable.
La investigación terminó señalando la interacción entre la configuración Thunderbolt de ZimaOS y el controlador ASMedia ASM2462PDX dentro de la carcasa. En lugar de seguir forzando el plan original, ted cambió la arquitectura.
Se instaló un adaptador PCIe x4 a OCuLink en la ranura 1. La carcasa Aoostar pasó de Thunderbolt a una conexión OCuLink directa. Las cuatro unidades NVMe aparecieron en el primer arranque, sin los problemas de tunelización y autorización que habían bloqueado la configuración Thunderbolt.
El cambio también afectó a los planes posteriores. La ranura 1 ahora está ocupada por el almacenamiento, mientras que los dos puertos Thunderbolt siguen disponibles para futuros experimentos, como la conexión en red directa o una ruta distinta para la eGPU. Una conexión fallida no se convirtió simplemente en una nota al pie sobre resolución de problemas; cambió la hoja de ruta de toda la máquina.
Evaluación comparativa del almacenamiento en lugar de suponer qué nivel era más rápido
Una vez que existió el almacenamiento, ted lo midió.
Su trabajo de la Fase 1.5 utiliza fio para comparar el grupo ZFS RAIDZ1 de glacier con Arctic-Storage, en lugar de tratar «NVMe» como una única categoría de rendimiento. La prueba en frío mostró que glacier alcanzaba 1.726 MB/s en escrituras secuenciales y 2.591 MB/s en lecturas secuenciales, mientras que el nivel Arctic de una sola unidad era muy superior en E/S aleatoria, con 205.588 IOPS de lectura aleatoria 4K en su ubicación original.
El resultado más interesante apareció cuando ZFS ARC entró en escena. Las lecturas repetidas desde glacier podían servirse desde la RAM en lugar de volver a las unidades NVMe. Con la configuración de memoria anterior de 16 GB, las lecturas aleatorias en caliente alcanzaron aproximadamente 83.929 IOPS, frente a las 14.781 IOPS del resultado en frío.
Ese descubrimiento influyó posteriormente en otra decisión de hardware. Ted actualizó la máquina a 32 GB mediante dos módulos DDR5 de 16 GB, pasando de memoria de un canal a memoria de doble canal. Tras la actualización, las lecturas aleatorias en caliente de ARC aumentaron de nuevo hasta 126.816 IOPS: una mejora medida del 51 % respecto al resultado anterior.
Las pruebas comparativas también cuestionaron la ubicación original de la Crucial P510. En la 7.ª bahía del modelo Standard, el rendimiento secuencial estaba limitado por el puente. Ted trasladó la unidad a la ranura M.2 integrada y midió un aumento de la lectura secuencial de 874 MB/s a 1.677 MB/s, mientras que el rendimiento de lectura aleatoria 4K subió de 205.588 a 403.078 IOPS.
La lección no fue simplemente que una ranura fuera más rápida. Las mediciones cambiaron dónde debían ubicarse las cargas de trabajo y qué actualizaciones merecía realmente la pena realizar.
Hacer funcionar ZFS junto a ZimaOS
La configuración también revela un límite interesante entre lo que ZimaOS gestiona de forma nativa y lo que un usuario experimentado puede añadir por debajo.
Ted utiliza deliberadamente btrfs para Arctic-Storage y el grupo IronWolf porque esos volúmenes se integran de forma natural con ZimaOS. El grupo glacier es diferente. Se creó como ZFS RAIDZ1 desde la línea de comandos, lo que proporcionó a Ted conjuntos de datos ZFS, sumas de comprobación, almacenamiento en caché ARC, instantáneas y un modelo de almacenamiento que se ajustaba mejor a algunas de las cargas de trabajo previstas.
Esa flexibilidad tiene un inconveniente: los grupos de almacenamiento ZFS creados desde la línea de comandos no aparecen como volúmenes de almacenamiento nativos de ZimaOS en la interfaz.
La solución alternativa de Ted es sencilla y práctica. Expone los conjuntos de datos individuales de ZFS mediante enlaces simbólicos en /DATA, permitiendo que rutas como documentos de glacier, archivos multimedia, copias de seguridad y almacenamiento de máquinas virtuales aparezcan dentro de la aplicación Archivos de ZimaOS mientras el grupo subyacente sigue gestionándose mediante ZFS.
Descubrió otro problema de visibilidad relacionado con la memoria. ZimaOS puede informar de que una gran parte de la RAM está «en uso» cuando ZFS ARC está ocupando memoria que, de otro modo, estaría inactiva. Al consultar btop y las estadísticas de ARC cuentan una historia más útil: la caché consume memoria porque está disponible, y ZFS puede liberarla cuando las aplicaciones necesitan más.
Este es el tipo de comentarios que importa en una configuración Pioneer. Ted no solo muestra lo que funciona en ZimaOS; también documenta hasta dónde llega la interfaz de usuario actual con una configuración de almacenamiento avanzada y qué hace cuando alcanza ese límite.
Trasladar una biblioteca de Immich existente sin perder su historial
La arquitectura de almacenamiento adquiere mucho más significado cuando los datos irremplazables empiezan a trasladarse a ella.
Para ted, esa prueba fue Immich. Ya tenía una instancia de Immich ejecutándose en un servidor ZimaOS DIY más antiguo y quería trasladarla a ZimaCube 2 sin empezar de cero.
La migración incluyó 14.505 fotos y 925 vídeos, 134 GiB en total. Pero los datos importantes no se limitaban a los archivos de imagen. Los álbumes, las personas, el reconocimiento facial, los recuerdos, los enlaces compartidos y otros metadatos se almacenaban en PostgreSQL.
Usando la aplicación Archivos de ZimaOS a través de la LAN, ted copió ambos /DATA/Gallery/immich y el /DATA/AppData/immich directorio, incluidos pgdata. La instancia de Immich de origen se detuvo antes de la copia para que los datos de PostgreSQL permanecieran coherentes.
Tras la migración, la cuenta, los álbumes, la información facial, los recuerdos y la biblioteca permanecieron intactos, sin pérdidas de datos notificadas. Después, Ted verificó directamente la base de datos de PostgreSQL, en lugar de asumir que un inicio de sesión correcto significaba que todo se había conservado.
Si estás planeando un traslado similar, nuestra guía de migración de Immich a ZimaCube 2 explica la misma distinción fundamental: trasladar solo la biblioteca multimedia no es suficiente; la base de datos también debe trasladarse.
De una migración de 134 GiB a 725 GiB de fotos y vídeos autoalojados
La fase de Immich no terminó cuando se completó correctamente la migración del servidor antiguo.
Lo que comenzó como el traslado de una biblioteca existente de ZimaOS se convirtió en un cambio mucho más amplio para dejar de usar iCloud como ubicación principal de las fotos y los vídeos de ted. Su iPhone empezó a transferir la biblioteca original de iCloud a Immich, ejecutándose en ZimaCube 2.
Al final de esa fase, el servidor contenía 63.665 elementos que sumaban 725 GiB: 55.604 fotos y 8.061 vídeos. La transferencia de iCloud representó unos 655 GB, y los vídeos 4K fueron responsables de la mayor parte de ese almacenamiento.
El objetivo no era fingir que todos los servicios en la nube de Apple podían reemplazarse. Ted todavía identificó copias de seguridad de dispositivos, mensajes y otros datos específicos de iOS que tiene sentido conservar en un plan de iCloud más pequeño. El cambio fue más concreto: trasladar la gran biblioteca de fotos y vídeos a un almacenamiento que controla, manteniendo los servicios en la nube que aún resultan útiles.
Esa decisión también creó una nueva responsabilidad. Una biblioteca de fotos autoalojada solo se vuelve más segura que una copia en la nube cuando se respalda correctamente. Por eso, las notas de migración de Ted se extienden a una segunda copia en TrueNAS, sentando las bases para la fase de copias de seguridad 3-2-1, que todavía forma parte de la hoja de ruta.
Construir en torno a lo que ZimaOS facilita y medir el resto
Ted eligió ZimaOS deliberadamente. Después de años usando Synology y de ser usuario de CasaOS durante mucho tiempo, quería un modelo de aplicaciones más limpio y centrado en Docker, manteniendo al mismo tiempo el acceso al sistema subyacente cuando la configuración requiriera algo más avanzado.
Varias partes del proyecto aprovechan ese equilibrio. La herramienta integrada de migración de AppData trasladó los datos de las aplicaciones Docker fuera de la unidad del sistema y a Arctic-Storage sin tener que reconstruir cada aplicación. La aplicación Archivos proporcionó el flujo de trabajo en la LAN utilizado para la migración a Immich. Las herramientas nativas, incluidas fio, zpool, zfs, nvme, y iostat permitieron medir y gestionar la arquitectura de almacenamiento por debajo de la capa gráfica.
Otras partes muestran dónde la experiencia todavía está menos integrada. El almacenamiento ZFS creado desde la CLI necesita el recurso alternativo del enlace simbólico. ARC hace que sea fácil interpretar mal la cantidad estándar de RAM. El comportamiento de Thunderbolt obligó a rediseñar el hardware.
Estas observaciones hacen que el proyecto sea más valioso que una demostración en la que todos los experimentos funcionan al primer intento. Ted está documentando la diferencia entre una experiencia sencilla con ZimaOS y el trabajo de homelab más profundo que comienza cuando alguien decide ir más allá.
Qué está construido ya y qué sigue siendo una hoja de ruta
El título del repositorio de Ted describe el destino como un NAS modesto con IA, pero el proyecto se está construyendo intencionadamente por fases.
La base ya es una realidad. El almacenamiento por niveles está funcionando. El grupo ZFS RAIDZ1 de Glacier está operativo. Arctic-Storage se ha trasladado a la ranura M.2 integrada. La memoria ha alcanzado los 32 GB en doble canal. El grupo RAID5 de IronWolf existe. Las pruebas de rendimiento del almacenamiento se han completado. La migración a Immich y la consolidación más amplia de las fotos de iCloud han finalizado.
La capa multimedia sigue creciendo. El grupo de IronWolf se ha creado para contenido multimedia masivo, mientras que Jellyfin y el conjunto más amplio de *arr siguen formando parte del trabajo actual de la Fase 2.
Las capas de IA aún están por llegar. La hoja de ruta de Ted sitúa actualmente las pruebas de Ollama usando solo la CPU en la fase 4a, seguidas de una opción de eGPU con RTX 4090 en la fase 4b y de la búsqueda semántica en el almacenamiento local en la fase 5.
Esa distinción es importante. ZimaCube 2 ya se está preparando para la IA local mediante la ubicación del almacenamiento, la capacidad de memoria, las decisiones sobre PCIe y la planificación de cargas de trabajo, pero el proyecto aún no ha llegado al punto en el que deba presentarse la inferencia mediante GPU como un resultado completado.
Para quienes ya están explorando esa dirección futura, nuestra guía sobre IA local en ZimaCube 2 analiza cómo Ollama, la memoria, la expansión PCIe y futuras actualizaciones de GPU pueden integrarse en una hoja de ruta de homelab similar.
Un proyecto que cambia cuando cambian las pruebas
El patrón más constante en el proyecto de ted no es ZFS, Immich ni ninguna pieza de hardware concreta. Es la disposición a cambiar una decisión después de medir lo que realmente ocurrió.
La carcasa Thunderbolt no funcionó, así que la ruta de almacenamiento pasó a OCuLink.
El P510 no podía aprovechar su potencial en la séptima bahía, así que se trasladó a la ranura M.2 integrada.
ZFS ARC rindió mejor de lo esperado, por lo que la memoria se convirtió en una mejora de rendimiento y no simplemente en capacidad adicional.
Una migración de Immich de 134 GiB se realizó sin perder la base de datos, así que el experimento se amplió para trasladar cientos de gigabytes más fuera de iCloud.
Cada fase deja mediciones, comandos, errores y suposiciones actualizadas para la siguiente fase. Por eso, el repositorio resulta útil incluso para quien nunca construya exactamente la misma configuración de almacenamiento.
La historia aún se está escribiendo
La historia de ted-knight y Zima aún se está escribiendo. ZimaCube 2 comenzó como un modelo Standard de 8 GB y ya se ha convertido en un sistema de almacenamiento multinivel con btrfs, ZFS RAIDZ1, expansión NVMe mediante OCuLink, 32 GB de memoria de doble canal, un archivo IronWolf RAID5 y una biblioteca Immich autoalojada que contiene cientos de gigabytes de archivos multimedia personales.
Las próximas fases siguen deliberadamente abiertas: Jellyfin y la plataforma multimedia, flujos de trabajo de copias de seguridad más sólidos, IA local basada exclusivamente en CPU, una futura opción de GPU, búsqueda semántica y cualquier otro aspecto que las mediciones obliguen a ted a replantearse por el camino.
Si quieres seguir el proyecto mientras esas fases pasan de la hoja de ruta a resultados reales, sigue en GitHub el proyecto en curso de ted-knight con ZimaCube 2.
