Como Construí um Cluster Proxmox de 3 Nós com o ZimaCube 2 como Backend de Armazenamento Partilhado

Três nós Proxmox. Um ZimaCube 2. Ethernet de dez gigabits. Tudo isto dentro de uma estante Ikea Kallax, a funcionar 24/7, mais silencioso do que o frigorífico na sala ao lado.

Esta não é uma construção hipotética. Este é o meu homelab — um rack de 10 polegadas totalmente impresso em 3D que encaixa perfeitamente num cubo Kallax padrão, com o ZimaCube 2 na base a atuar como o cérebro de armazenamento partilhado para todo o cluster. Aqui está por que escolhi o ZimaCube 2 para este papel, como o integrei e o que aprendi pelo caminho.

A Arquitetura

O meu cluster tem três nós de computação a correr Proxmox com armazenamento de arranque eMMC e replicação ZFS entre eles. O objetivo é alta disponibilidade total HCI — se um nó falhar, as cargas de trabalho migram automaticamente e o armazenamento mantém-se consistente.

Mas a replicação ZFS entre três nós só vai até certo ponto. Ainda precisa de um backend de armazenamento partilhado — algo com capacidade suficiente, largura de banda suficiente e fiabilidade suficiente para servir como a única fonte de verdade para todo o cluster. É aqui que o ZimaCube 2 entra.

Por que o ZimaCube 2 como Backend SAN/NAS

Analisei muitas opções antes de escolher o ZimaCube 2. Aqui está o que o tornou a escolha certa:

O que Eu Precisava

• 6+ baias para pools mistos de HDD/NVMe

• 10GbE para servir o cluster sem gargalos

• Expansão PCIe para futuras atualizações de GPU/NIC

• Nativo Docker para executar serviços de infraestrutura juntamente com armazenamento

• Silencioso o suficiente para um espaço habitacional (não uma cave)

• Compacto o suficiente para caber num cubo Kallax

O que o ZimaCube 2 Oferece

• 6× baias SATA3 + 4× M.2 NVMe na 7ª Baia

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

• Slots PCIe x16 Gen4 + PCIe x8 Gen3

• ZimaOS pré-instalado com suporte Docker

• 240 × 221 × 220 mm — exatamente compatível com Kallax

• Chassis metálico com arrefecimento ativo, quase silencioso em repouso

A porta 10GbE foi o fator decisivo. Se estiver a servir armazenamento para três nós hypervisor simultaneamente, uma ligação gigabit única torna-se o gargalo no primeiro dia. O ZimaCube 2 10GbE significa que posso saturar a rede do cluster antes de saturar o backend de armazenamento.

Configuração de Armazenamento

Aqui está como organizei os pools de armazenamento no ZimaCube 2:

O cluster acede ao ZimaCube 2 através de uma ligação dedicada 10GbE. Cada nó Proxmox liga-se via 2.5GbE a um switch gerido, com o ZimaCube 2 na porta uplink 10GbE. As migrações ao vivo das VMs acontecem via NFS a partir do pool NVMe. Os media e backups vivem no pool HDD. Tudo é suportado por ZFS com snapshots.
Nota sobre atualização de RAM: O ZimaCube 2 vem com 8GB DDR5 (Standard) ou 16GB (Pro). Para um backend de armazenamento baseado em ZFS, mais RAM é melhor — o ZFS usa ARC (Adaptive Replacement Cache) na memória, e cada gigabyte de ARC é um gigabyte de armazenamento que não toca no disco. Adicionei um módulo DDR5 SODIMM de 32GB para totalizar 40GB, o que dá ao ZFS bastante margem de ARC sem prejudicar os containers Docker.

A Construção Física: Tudo Impresso em 3D

Todo o conjunto está num formato de rack de 10 polegadas, impresso em 3D numa Elegoo Centauri Carbon e desenhado para encaixar exatamente dentro de um cubo de prateleira Ikea Kallax padrão.

O ZimaCube 2 fica na base do rack — o seu peso e necessidades de refrigeração fazem dele a base natural. Por cima: três nós de computação, um dispositivo firewall dedicado e um painel de patch. Tudo está montado com suportes e painéis de ventilação personalizados impressos em 3D.

Todos os ficheiros STL e remixes estão disponíveis no MakerWorld e Printables. Desenhei suportes personalizados para o ZimaCube 2, as unidades ZimaBlade e o dispositivo firewall.

Porquê não TrueNAS ou Unraid?

Mantive o ZimaOS no ZimaCube 2 em vez de o apagar para instalar TrueNAS ou Unraid. Aqui está a minha razão:

1.Docker nativo desde o primeiro dia. Sem sistema de plugins para complicar. docker-compose up e está feito.

2.Suporte ZFS integrado. O gestor de armazenamento do ZimaOS trata da criação de pools ZFS e do agendamento de snapshots sem necessidade de usar o terminal.

3.A IceWhale está a desenvolvê-lo ativamente. Estou a testar uma versão Beta do ZimaOS diretamente da equipa deles — a resposta ao feedback da comunidade tem sido realmente boa.

4.Queria testar a plataforma conforme projetada. Pode sempre apagar e instalar outra coisa mais tarde. Mas se o ZimaOS suporta a carga de trabalho, é um sistema operativo a menos para configurar e manter.

Para um backend de armazenamento em cluster, a estabilidade é mais importante que as funcionalidades. Até agora, o ZimaOS tem correspondido.

O que está a correr no Cluster

Os três nós Proxmox alojam atualmente:

• Home Assistant com Zigbee2MQTT — automação doméstica inteligente
• Frigate NVR num ZimaBlade dedicado com Coral TPU — 4 câmaras exteriores, deteção de objetos descarregada para o TPU
• Paperless-ngx — gestão documental
• Vaultwarden — gestão de passwords
• Nginx Proxy Manager — proxy reverso e SSL
• Pi-hole — filtragem DNS a nível de rede
• Gitea — Git auto-hospedado para projetos pessoais
• Várias VMs de desenvolvimento para testes e aprendizagem

O ZimaCube 2 também executa alguns contêineres de infraestrutura diretamente: Uptime Kuma para monitorização, um orquestrador de backups e o agendador de snapshots ZFS.

Construa o seu próprio backend de armazenamento em cluster com ZimaCube 2 →

Perguntas Frequentes

Por que usar um ZimaCube 2 em vez de um NAS tradicional para um cluster Proxmox?

Três razões: 10GbE, expansão PCIe e arquitetura nativa ZFS. A maioria dos dispositivos NAS para consumidores vem com 1GbE, que se torna um gargalo imediato ao servir múltiplos hipervisores. A porta 10GbE do ZimaCube 2 mais as duas 2.5GbE dão-lhe a largura de banda para servir armazenamento sem contenção. E o slot PCIe permite adicionar uma GPU ou NIC mais rápida mais tarde sem substituir o dispositivo inteiro.

O ZimaOS consegue gerir o ZFS suficientemente bem para armazenamento em cluster?

Sim. O ZimaOS inclui criação de pools ZFS, agendamento de snapshots e monitorização de saúde no seu gestor de armazenamento. Para um backend de cluster, as funcionalidades principais — criação de pools, partilha NFS/SMB, automação de snapshots — estão todas presentes sem necessidade de configuração via terminal.

Quanta RAM precisa o ZimaCube 2 para o ZFS?

O ZFS usa RAM para ARC (cache), e mais RAM significa desempenho de leitura mais rápido. Os 8GB ou 16GB de origem são adequados para cargas de trabalho leves, mas para servir múltiplas VMs ou contêineres com um grande conjunto de dados, recomenda-se atualizar para 32GB ou 64GB. Os slots SODIMM DDR5 são acessíveis ao utilizador — a atualização demora minutos.

Qual é a vantagem de manter o Coral TPU num ZimaBlade separado em vez do ZimaCube 2?

Descarregar a deteção de objetos Frigate para um ZimaBlade dedicado com Coral TPU mantém a carga de inferência totalmente fora da CPU e GPU do ZimaCube 2. O ZimaCube 2 gere o armazenamento e os serviços Docker; o ZimaBlade trata da análise de vídeo em tempo real. Separar essas cargas de trabalho evita que o processamento da câmara concorra com a E/S da VM ou a inferência de IA no sistema principal.