Cómo construí un clúster Proxmox de 3 nodos alrededor del ZimaCube 2 como el backend de almacenamiento compartido

Tres nodos Proxmox. Un ZimaCube 2. Ethernet de diez gigabits. Todo dentro de una estantería Ikea Kallax, funcionando 24/7, más silencioso que el refrigerador de la habitación contigua.

Esta no es una construcción hipotética. Este es mi homelab: un rack de 10 pulgadas completamente impreso en 3D que encaja perfectamente en un cubo Kallax estándar, con el ZimaCube 2 en la parte inferior actuando como el cerebro de almacenamiento compartido para todo el clúster. Aquí está por qué elegí el ZimaCube 2 para este rol, cómo lo integré y lo que aprendí en el camino.

La arquitectura

Mi clúster tiene tres nodos de cómputo ejecutando Proxmox con almacenamiento de arranque eMMC y replicación ZFS entre ellos. El objetivo es una HCI de alta disponibilidad completa: si un nodo falla, las cargas de trabajo migran automáticamente y el almacenamiento se mantiene consistente.

Pero la replicación ZFS entre tres nodos solo llega hasta cierto punto. Aún necesitas un backend de almacenamiento compartido, algo con suficiente capacidad, ancho de banda y fiabilidad para servir como la única fuente de verdad para todo el clúster. Ahí es donde entra el ZimaCube 2.

Por qué el ZimaCube 2 como backend SAN/NAS

Examiné muchas opciones antes de decidirme por el ZimaCube 2. Esto fue lo que lo hizo la elección correcta:

Lo que necesitaba

• 6+ bahías para unidades mixtas HDD/NVMe

• 10GbE para servir al clúster sin cuellos de botella

• Expansión PCIe para futuras actualizaciones de GPU/NIC

• Nativo para Docker para ejecutar servicios de infraestructura junto con almacenamiento

• Lo suficientemente silencioso para un espacio habitable (no un sótano)

• Lo suficientemente compacto para caber en un cubo Kallax

Lo que ofrece el ZimaCube 2

• 6× bahías SATA3 + 4× M.2 NVMe en la séptima bahía

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

• Ranuras PCIe x16 Gen4 + PCIe x8 Gen3

• ZimaOS preinstalado con soporte para Docker

• 240 × 221 × 220 mm — exactamente compatible con Kallax

• Chasis metálico con refrigeración activa, casi silencioso en reposo

El puerto 10GbE fue el factor decisivo. Si sirves almacenamiento a tres nodos hipervisores simultáneamente, un enlace gigabit único se convierte en el cuello de botella desde el primer día. El 10GbE del ZimaCube 2 significa que puedo saturar la red del clúster antes de saturar el backend de almacenamiento.

Configuración de almacenamiento

Así es como configuré los pools de almacenamiento en el ZimaCube 2:

El clúster accede al ZimaCube 2 a través de un enlace dedicado 10GbE. Cada nodo Proxmox se conecta mediante 2.5GbE a un switch gestionado, con el ZimaCube 2 en el puerto uplink 10GbE. Las migraciones en vivo de VM se realizan por NFS desde el pool NVMe. Los medios y las copias de seguridad están en el pool HDD. Todo está respaldado por ZFS con snapshots.
Nota sobre la ampliación de RAM: El ZimaCube 2 viene con 8GB DDR5 (Estándar) o 16GB (Pro). Para un backend de almacenamiento basado en ZFS, más RAM es mejor — ZFS usa ARC (Adaptive Replacement Cache) en memoria, y cada gigabyte de ARC es un gigabyte de almacenamiento que no toca el disco. Añadí un módulo SODIMM DDR5 de 32GB para llegar a un total de 40GB, lo que le da a ZFS mucho margen de ARC sin dejar sin recursos a los contenedores Docker.

La construcción física: todo impreso en 3D

Toda la configuración vive en un formato de rack de 10 pulgadas, impreso en 3D con una Elegoo Centauri Carbon y diseñado para encajar exactamente dentro de un cubo de estantería Ikea Kallax estándar.

El ZimaCube 2 se sitúa en la parte inferior del rack; su peso y requisitos de refrigeración lo convierten en la base natural. Encima: tres nodos de cómputo, un dispositivo firewall dedicado y un panel de conexiones. Todo está montado con soportes y paneles de ventilación impresos en 3D personalizados.

Todos los archivos STL y remixes están disponibles en MakerWorld y Printables. Diseñé montajes personalizados para el ZimaCube 2, las unidades ZimaBlade y el dispositivo firewall.

¿Por qué no TrueNAS o Unraid?

Mantuve ZimaOS en el ZimaCube 2 en lugar de borrarlo para TrueNAS o Unraid. Aquí está mi razonamiento:

1.Docker nativo desde el primer día. No hay sistema de plugins con el que pelear. docker-compose up y listo.

2.Soporte ZFS incorporado. El gestor de almacenamiento de ZimaOS maneja la creación de pools ZFS y la programación de snapshots sin necesidad de usar la terminal.

3.IceWhale lo está desarrollando activamente. Estoy probando una versión Beta de ZimaOS directamente de su equipo; la capacidad de respuesta a los comentarios de la comunidad ha sido realmente buena.

4.Quería probar la plataforma tal como está diseñada. Siempre puedes borrar e instalar otra cosa después. Pero si ZimaOS maneja la carga de trabajo, es un sistema operativo menos que configurar y mantener.

Para un backend de almacenamiento en clúster, la estabilidad importa más que las funciones. Hasta ahora, ZimaOS ha cumplido.

Qué se está ejecutando en el clúster

Los tres nodos Proxmox actualmente alojan:

• Home Assistant con Zigbee2MQTT — automatización del hogar inteligente
• Frigate NVR en un ZimaBlade dedicado con Coral TPU — 4 cámaras exteriores, detección de objetos delegada al TPU
• Paperless-ngx — gestión documental
• Vaultwarden — gestión de contraseñas
• Nginx Proxy Manager — proxy inverso y SSL
• Pi-hole — filtrado DNS a nivel de red
• Gitea — Git autoalojado para proyectos personales
• Varias VMs de desarrollo para pruebas y aprendizaje

El ZimaCube 2 también ejecuta algunos contenedores de infraestructura directamente: Uptime Kuma para monitoreo, un orquestador de backups y el programador de snapshots ZFS.

Construye tu propio backend de almacenamiento en clúster con ZimaCube 2 →

Preguntas frecuentes

¿Por qué usar un ZimaCube 2 en lugar de un NAS tradicional para un clúster Proxmox?

Tres razones: 10GbE, expansión PCIe y arquitectura nativa ZFS. La mayoría de los dispositivos NAS para consumidores vienen con 1GbE, que se convierte en cuello de botella inmediatamente al servir múltiples hipervisores. El puerto 10GbE del ZimaCube 2 más dos puertos 2.5GbE te dan el ancho de banda para servir almacenamiento sin contención. Y la ranura PCIe significa que puedes añadir una GPU o una NIC más rápida después sin reemplazar todo el dispositivo.

¿Puede ZimaOS manejar ZFS lo suficientemente bien para almacenamiento en clúster?

Sí. ZimaOS incluye creación de pools ZFS, programación de snapshots y monitoreo de salud en su gestor de almacenamiento. Para un backend de clúster, las funciones clave — creación de pools, compartición NFS/SMB, automatización de snapshots — están todas disponibles sin necesidad de configuración por terminal.

¿Cuánta RAM necesita el ZimaCube 2 para ZFS?

ZFS usa RAM para ARC (caché), y más RAM significa un rendimiento de lectura más rápido. Los 8GB o 16GB de serie son adecuados para cargas de trabajo ligeras, pero para servir múltiples VMs o contenedores con un conjunto de datos grande, se recomienda actualizar a 32GB o 64GB. Las ranuras SODIMM DDR5 son accesibles para el usuario — la actualización toma minutos.

¿Cuál es la ventaja de mantener el Coral TPU en un ZimaBlade separado en lugar de en el ZimaCube 2?

Delegar la detección de objetos de Frigate a un ZimaBlade dedicado con Coral TPU mantiene la carga de inferencia completamente fuera de la CPU y GPU del ZimaCube 2. El ZimaCube 2 se encarga del almacenamiento y los servicios Docker; el ZimaBlade maneja el análisis de video en tiempo real. Separar esas cargas de trabajo evita que el procesamiento de cámaras compita con la E/S de VM o la inferencia de IA en el sistema principal.