Uma nota da Zima
Obrigado, Ted, por documentares o ZimaCube 2 como um sistema que cresce por camadas, em vez de um equipamento finalizado. A tua construção Pioneer regista as atualizações bem-sucedidas, os testes de desempenho do armazenamento, a migração do Immich e as partes que ofereceram resistência — incluindo um caminho Thunderbolt que acabou por dar lugar a uma solução OCuLink. Ao publicares as medições, soluções alternativas, erros e decisões de hardware em mudança à medida que a construção evolui, estás a oferecer à comunidade algo mais útil do que uma simples ficha técnica final: um registo de como um homelab ZimaOS real evolui.
— Zima
Conheça ted-knight
Ted-knight está a documentar uma das construções de ZimaCube 2 mais metódicas do Pioneer Program. A sua Construção do ZimaCube 2 não está organizada em torno de uma única configuração final. Em vez disso, o projeto está dividido em fases, com cada camada a ser testada antes de a seguinte ser adicionada.
O objetivo do projeto é simples: criar um NAS em que seja possível confiar para dados importantes hoje, deixando ao mesmo tempo espaço suficiente para self-hosting, multimédia, IA local e outras cargas de trabalho no futuro. Isso conduziu ted através da arquitetura de armazenamento, ZFS, atualizações de RAM e NVMe, expansão OCuLink, testes de desempenho, integração com o ZimaOS, migração do Immich e um roteiro cada vez mais detalhado para aquilo em que a máquina se poderá transformar.
Começou com o ZimaCube 2 Standard: um sistema com Intel Core i3-1215U, 8 GB de DDR5 e uma unidade NVMe de sistema de 256 GB. A configuração original não permaneceu original durante muito tempo.
Construir a base de armazenamento antes de adicionar mais serviços
A primeira prioridade de Ted não foi encher o servidor de aplicações. Foi decidir onde deveriam ficar os diferentes tipos de dados.
O sistema resultante utiliza vários níveis de armazenamento, cada um com funções deliberadamente diferentes. O ZimaOS permanece no seu próprio Kingston NVMe de 256 GB. Um Crucial P510 NVMe de 2 TB tornou-se o Arctic-Storage, um nível btrfs para AppData, imagens Docker, bases de dados e outras cargas de trabalho ativas. Quatro unidades NVMe de 2 TB formam o glacier, um conjunto ZFS RAIDZ1 com cerca de 5,5 TB de espaço utilizável. Mais tarde, quatro unidades Seagate IronWolf de 4 TB tornaram-se um conjunto btrfs RAID5 de 12 TB para multimédia em massa e dados menos utilizados.
A arquitetura tem menos que ver com fazer todas as unidades comportarem-se da mesma forma e mais com adequar o armazenamento à carga de trabalho. As bases de dados com muitas operações de E/S aleatórias pertencem ao P510 rápido. Cargas de trabalho sequenciais maiores e dados que beneficiem de somas de verificação e redundância ZFS podem ficar no glacier. Os conteúdos multimédia em massa podem passar para o nível IronWolf de maior capacidade.
Quando o Thunderbolt 4 não funcionou, a arquitetura mudou
Uma das partes mais úteis do projeto de ted é o facto de as experiências falhadas permanecerem documentadas.
O plano original consistia em ligar uma caixa Aoostar TB4S-OC para quatro NVMe ao ZimaCube 2 através de Thunderbolt 4. Ted testou diferentes cabos de 40 Gbps, ambas as portas Thunderbolt, alimentação externa e o comportamento do kernel subjacente, mas a caixa continuou sem conseguir estabelecer uma ligação PCIe estável.
A investigação acabou por apontar para a interação entre a configuração Thunderbolt do ZimaOS e o controlador ASMedia ASM2462PDX no interior da caixa. Em vez de continuar a forçar o plano original, ted alterou a arquitetura.
Foi instalado na ranhura 1 um adaptador PCIe x4 para OCuLink. A caixa Aoostar passou de Thunderbolt para uma ligação OCuLink direta. As quatro unidades NVMe apareceram no primeiro arranque, sem os problemas de tunelamento e autorização que tinham bloqueado a configuração Thunderbolt.
A alteração também afetou os planos seguintes. A ranhura 1 está agora ocupada pelo armazenamento, enquanto as duas portas Thunderbolt continuam disponíveis para experiências futuras, como redes diretas ou uma abordagem diferente para uma eGPU. Uma ligação falhada não se tornou simplesmente uma nota de rodapé de resolução de problemas; alterou o roteiro de toda a máquina.
Avaliação comparativa do armazenamento em vez de presumir qual o nível mais rápido
Assim que o armazenamento ficou disponível, ted mediu-o.
O trabalho da Fase 1.5 utiliza fio para comparar o pool ZFS RAIDZ1 do glacier com o Arctic-Storage, em vez de tratar “NVMe” como uma única categoria de desempenho. O teste frio mostrou o glacier a atingir 1 726 MB/s de escrita sequencial e 2 591 MB/s de leitura sequencial, enquanto o Arctic de uma única unidade era muito mais forte em E/S aleatória, atingindo 205 588 IOPS de leitura aleatória 4K na sua localização original.
O resultado mais interessante surgiu quando a ARC do ZFS entrou em ação. As leituras repetidas do glacier podiam ser servidas a partir da RAM, em vez de voltarem às unidades NVMe. Com a configuração anterior de 16 GB de memória, as leituras aleatórias quentes atingiram aproximadamente 83 929 IOPS, em vez do resultado frio de 14 781 IOPS.
Essa descoberta influenciou posteriormente outra decisão de hardware. Ted atualizou a máquina para 32 GB utilizando dois módulos DDR5 de 16 GB, passando de memória de canal único para canal duplo. Após a atualização, as leituras aleatórias quentes da ARC aumentaram novamente para 126 816 IOPS — uma melhoria medida de 51% relativamente ao resultado anterior.
Os testes também puseram em causa a colocação original do Crucial P510. No 7.º compartimento do modelo Standard, o débito sequencial era limitado pela bridge. Ted transferiu a unidade para a ranhura M.2 integrada e mediu um aumento da leitura sequencial de 874 MB/s para 1 677 MB/s, enquanto o desempenho de leitura aleatória 4K subiu de 205 588 para 403 078 IOPS.
A lição não foi simplesmente que uma ranhura era mais rápida. As medições alteraram a localização das cargas de trabalho e quais as atualizações que realmente valia a pena fazer.
Fazer o ZFS funcionar em conjunto com o ZimaOS
A configuração também revela uma fronteira interessante entre o que o ZimaOS gere nativamente e o que um utilizador experiente pode adicionar por baixo dele.
Ted utiliza deliberadamente btrfs no Arctic-Storage e no pool IronWolf, porque esses volumes se integram naturalmente no ZimaOS. O pool glacier é diferente. Foi criado como ZFS RAIDZ1 a partir da linha de comandos, proporcionando a Ted conjuntos de dados ZFS, somas de verificação, cache ARC, instantâneos e um modelo de armazenamento mais adequado a algumas das cargas de trabalho que tinha planeado.
Essa flexibilidade tem uma limitação: os pools ZFS criados a partir da linha de comandos não aparecem como volumes de armazenamento nativos do ZimaOS na interface.
A solução alternativa de Ted é simples e prática. Ele expõe os conjuntos de dados individuais do ZFS através de ligações simbólicas em /DATA, permitindo que caminhos como documentos do glacier, multimédia, cópias de segurança e armazenamento de máquinas virtuais apareçam na aplicação Ficheiros do ZimaOS, enquanto o pool subjacente continua a ser gerido pelo ZFS.
Ele encontrou outro problema de visibilidade relacionado com a memória. O ZimaOS pode reportar uma grande parte da RAM como “utilizada” quando a ARC do ZFS está a ocupar memória que, de outro modo, estaria inativa. Ao consultar btop e as estatísticas do ARC contam uma história mais útil: a cache está a consumir memória porque ela está disponível, e o ZFS pode libertá-la à medida que as aplicações precisam de mais.
Este é o tipo de feedback que importa numa montagem Pioneer. Ted não está apenas a mostrar o que funciona no ZimaOS; está a documentar onde uma configuração de armazenamento avançada atinge os limites da interface de utilizador atual e o que faz quando isso acontece.
Transferir uma biblioteca Immich existente sem perder o seu histórico
A arquitetura de armazenamento torna-se muito mais significativa quando dados insubstituíveis começam a ser transferidos para ela.
Para ted, esse teste foi o Immich. Já tinha uma instância do Immich a funcionar num servidor ZimaOS DIY mais antigo e queria transferi-la para o ZimaCube 2 sem começar do zero.
A migração envolveu 14,505 fotografias e 925 vídeos — 134 GiB no total. Mas os dados importantes não se limitavam aos ficheiros de imagem. Os álbuns, as pessoas, o reconhecimento facial, as memórias, as ligações partilhadas e outros metadados estavam armazenados no PostgreSQL.
completo. Utilizando a aplicação Ficheiros do ZimaOS através da LAN, ted copiou ambos /DATA/Gallery/immich e o /DATA/AppData/immich diretório, incluindo pgdata. A instância Immich de origem foi parada antes da cópia, para manter os dados do PostgreSQL consistentes.
Após a migração, a conta, os álbuns, as informações faciais, as memórias e a biblioteca permaneceram intactos, sem qualquer perda de dados comunicada. Ted verificou então diretamente a base de dados PostgreSQL, em vez de presumir que um início de sessão bem-sucedido significava que tudo tinha sobrevivido.
Se está a planear o mesmo tipo de mudança, o nosso guia de migração do Immich para o ZimaCube 2 explica a mesma distinção fundamental: mover apenas a biblioteca multimédia não é suficiente — a base de dados também tem de ser transferida.
De uma migração de 134 GiB para 725 GiB de fotografias e vídeos autoalojados
A fase do Immich não terminou quando a migração do servidor antigo foi concluída com êxito.
O que começou por ser a transferência de uma biblioteca ZimaOS existente tornou-se numa mudança muito maior, afastando-se do uso do iCloud como principal local para as fotografias e os vídeos de ted. O iPhone começou a transferir a biblioteca original do iCloud para o Immich, a funcionar no ZimaCube 2.
No final dessa fase, o servidor continha 63,665 recursos, num total de 725 GiB: 55,604 fotografias e 8,061 vídeos. A transferência do iCloud representou, por si só, cerca de 655 GB, sendo o vídeo 4K responsável pela maior parte desse espaço de armazenamento.
O objetivo não era fingir que todos os serviços de nuvem da Apple podiam ser substituídos. Ted identificou também cópias de segurança de dispositivos, mensagens e outros dados específicos do iOS que faz sentido manter num plano iCloud mais pequeno. A mudança foi mais focada: transferir a grande biblioteca de fotografias e vídeos para um armazenamento que controla, mantendo os serviços de nuvem que continuam a ter uma utilidade real.
Essa decisão também criou uma nova responsabilidade. Uma biblioteca de fotografias autoalojada só se torna mais segura do que uma cópia na nuvem quando é devidamente salvaguardada. Por isso, as notas de migração de Ted estendem-se a uma segunda cópia no TrueNAS, preparando o caminho para a fase mais abrangente de cópias de segurança 3-2-1 que ainda faz parte do roteiro.
Construir em Torno do Que o ZimaOS Facilita — e Medir o Restante
Ted escolheu deliberadamente o ZimaOS. Depois de anos a utilizar a Synology e de ser utilizador de longa data do CasaOS, queria um modelo de aplicações mais simples e centrado no Docker, mantendo simultaneamente o acesso ao sistema subjacente quando a configuração exigisse algo mais avançado.
Várias partes do projeto tiram partido desse equilíbrio. A ferramenta integrada de migração do AppData transferiu os dados das aplicações Docker da unidade do sistema para o Arctic-Storage sem reconstruir todas as aplicações. A aplicação Ficheiros forneceu o fluxo de trabalho LAN utilizado na migração do Immich. As ferramentas nativas, incluindo fio, zpool, zfs, nvme, e iostat permitiu medir e gerir a arquitetura de armazenamento sob a camada gráfica.
Outras partes revelam onde a experiência ainda está menos integrada. O armazenamento ZFS criado através da CLI precisa da solução alternativa com uma ligação simbólica. A ARC faz com que seja fácil interpretar incorretamente a quantidade padrão de RAM. O comportamento do Thunderbolt obrigou a uma reformulação do hardware.
Estas observações tornam o projeto mais valioso do que uma demonstração em que todas as experiências funcionam à primeira tentativa. Ted está a documentar a linha entre uma experiência simples com o ZimaOS e o trabalho mais profundo de um homelab que começa quando alguém decide atravessá-la.
O Que Já Foi Construído — e o Que Ainda Está no Roteiro
O título do repositório de ted descreve o destino como um NAS modesto com IA, mas o projeto está a ser construído intencionalmente por fases.
A base já é uma realidade. O armazenamento por níveis está a funcionar. O conjunto ZFS RAIDZ1 glacier está operacional. O Arctic-Storage foi transferido para a ranhura M.2 integrada. A memória atingiu 32 GB em canal duplo. O conjunto IronWolf RAID5 existe. Os testes de desempenho do armazenamento foram concluídos. A migração do Immich e a consolidação mais abrangente das fotografias do iCloud estão concluídas.
A camada multimédia continua a crescer. O conjunto IronWolf foi criado para conteúdos multimédia em massa, enquanto o Jellyfin e a restante pilha *arr continuam a fazer parte do trabalho atual da Fase 2.
As camadas de IA ainda estão por vir. Atualmente, o roteiro de Ted prevê testes com Ollama apenas através da CPU na Fase 4a, seguidos de um caminho com eGPU RTX 4090 na Fase 4b e de pesquisa semântica no armazenamento local na Fase 5.
Essa distinção é importante. O ZimaCube 2 já está a ser preparado para IA local através da disposição do armazenamento, da capacidade de memória, das decisões relativas à PCIe e do planeamento das cargas de trabalho, mas o projeto ainda não chegou ao ponto em que a inferência com GPU deva ser apresentada como um resultado concluído.
Para os leitores que já estão a explorar essa futura direção, o nosso guia sobre IA local no ZimaCube 2 analisa como o Ollama, a memória, a expansão PCIe e futuras atualizações com GPU podem enquadrar-se num roteiro de homelab semelhante.
Uma Construção Que Muda Quando as Evidências Mudam
O padrão mais consistente no projeto de ted não é o ZFS, o Immich nem qualquer componente de hardware específico. É a vontade de alterar uma decisão depois de medir o que realmente aconteceu.
A caixa Thunderbolt não funcionou, pelo que o caminho de armazenamento passou para OCuLink.
O P510 não conseguiu utilizar todo o seu potencial no 7.º compartimento, pelo que foi transferido para a ranhura M.2 integrada.
O ARC do ZFS teve um desempenho melhor do que o esperado, pelo que a memória se tornou uma melhoria de desempenho, em vez de representar simplesmente capacidade adicional.
Uma migração de 134 GiB do Immich foi concluída sem perder a base de dados, pelo que o experimento se expandiu para a transferência de mais centenas de gigabytes para fora do iCloud.
Cada fase deixa medições, comandos, erros e pressupostos atualizados para a fase seguinte. Isso torna o repositório útil até para quem nunca constrói exatamente a mesma configuração de armazenamento.
A História Ainda Está a Ser Escrita
A história de ted-knight e da Zima ainda está a ser escrita. O ZimaCube 2 começou como um modelo Standard de 8 GB e já se tornou num sistema de armazenamento multicamada com btrfs, ZFS RAIDZ1, expansão NVMe por OCuLink, 32 GB de memória em canal duplo, um arquivo IronWolf em RAID5 e uma biblioteca Immich autoalojada que contém centenas de gigabytes de conteúdos multimédia pessoais.
As próximas fases continuam deliberadamente em aberto: Jellyfin e a pilha multimédia, fluxos de cópia de segurança mais robustos, IA local apenas com CPU, um futuro caminho para GPU, pesquisa semântica e tudo o que as medições levarem ted a reconsiderar ao longo do percurso.
Se quiser acompanhar a evolução à medida que estas fases passam do roteiro aos resultados concretos, acompanhe no GitHub a construção contínua do ZimaCube 2 de ted-knight.
