Cluster Proxmox HA com Mini PCs: Alta disponibilidade no home lab

Sabe aquele momento em que você precisa reiniciar o servidor do home lab para uma atualização de kernel e a casa inteira grita? O Plex para, o Home Assistant morre e o DNS (Pi-hole/AdGuard) deixa de resolver nomes. Se você já passou por isso, bem-vindo ao clube. A solução para esse caos doméstico e para a paz de espírito do sysadmin de fim de semana tem um nome: High Availability (HA).

Antigamente, ter um cluster de alta disponibilidade exigia racks barulhentos, SANs dedicadas e uma conta de luz que faria qualquer um chorar. Hoje, graças à revolução dos Mini PCs (o famoso formato "TinyMiniMicro" que tanto amamos) e ao amadurecimento do Proxmox VE, podemos construir uma infraestrutura resiliente, silenciosa e relativamente barata.

Vamos montar um cluster que sobrevive a falhas de hardware, cabos desconectados e até à sua própria curiosidade destrutiva.

Resumo em 30 segundos

A Regra de Três: Você precisa de no mínimo 3 nós para um cluster HA confiável (quorum). Dois nós são uma armadilha sem um dispositivo de arbitragem externo.

O Gargalo do Storage: Não use SSDs baratos de entrada (DRAM-less/QLC) com Ceph. A latência vai destruir a performance do seu cluster.

Rede é Vida: 1GbE não é mais suficiente para storage distribuído. 2.5GbE é o novo padrão mínimo para manter a sincronia de dados sem engasgos.

Figura: A "trindade" do Home Lab: Três Mini PCs empilhados formando a base física do cluster.

O fim do downtime doméstico com hardware reaproveitado

A premissa é simples: se um computador queima, o outro assume. Mas a execução disso envolve uma dança complexa de dados. Em um cenário corporativo, usaríamos servidores Dell PowerEdge ou HP ProLiant. No nosso laboratório, vamos de Mini PCs de 1 litro.

Modelos como Lenovo ThinkCentre Tiny, HP ProDesk Mini ou Dell OptiPlex Micro são perfeitos. Eles consomem pouco (10-15W em idle), são silenciosos e, o mais importante, baratos no mercado de usados. Processadores de 8ª geração Intel (i5-8500T, por exemplo) são o "sweet spot" atual: baratos, suportam bastante RAM e têm instruções modernas de virtualização.

💡 Dica Pro: Evite processadores muito antigos (pré-6ª geração) não apenas pela eficiência energética, mas pelo suporte a instruções de criptografia que aceleram o tráfego de storage seguro.

A trindade dos mini PCs e a escolha crítica dos SSDs

Para ter HA real, precisamos de três nós. Por que três? Porque o Proxmox (e o sistema de arquivos distribuído Ceph, que veremos adiante) funciona baseada em votos. Se você tem 2 nós e um cai, o sobrevivente tem apenas 50% dos votos. Ele não sabe se o outro morreu ou se apenas o cabo de rede soltou. Para evitar corrupção de dados (o temido split-brain), ele se bloqueia. Com 3 nós, se um cai, os outros dois mantêm 66% dos votos e o cluster segue vivo.

Mas o verdadeiro "calcanhar de Aquiles" desse projeto não é a CPU ou a RAM, é o armazenamento.

Quando falamos de cluster hiperconvergente (onde computação e storage vivem nas mesmas máquinas), o disco local sofre. Se você usar SSDs SATA comuns de consumidor (aqueles baratos da promoção), prepare-se para o desastre. O Ceph, sistema que usaremos para replicar os dados, faz muitas escritas síncronas. SSDs comuns não têm capacitores de proteção contra perda de energia (PLP - Power Loss Protection) e dependem de cache RAM volátil. Para garantir que o dado foi gravado, o Ceph obriga o SSD a "flushar" o cache para a memória flash constantemente. Isso mata a performance de SSDs domésticos.

Figura: A diferença invisível: Capacitores de PLP em SSDs Enterprise garantem que os dados no cache sejam gravados mesmo se a energia cair, essencial para a performance do Ceph.

Se possível, procure SSDs Enterprise usados (séries Intel DC, Samsung PM/SM, Micron). Um SSD Enterprise SATA antigo de 400GB vai humilhar um NVMe Gen4 de consumidor em cargas de trabalho de sincronização de cluster.

Por que a rede 2.5GbE se tornou o novo mínimo

No passado, tentávamos rodar Ceph em redes de 1 Gigabit. Funcionava? Sim. Era bom? Não. Quando um nó cai e volta, o cluster precisa "curar" (resync) os dados. Em 1GbE, isso pode levar horas, deixando tudo lento.

Hoje, adaptadores USB para 2.5GbE (com chipsets Realtek RTL8156B) custam pouco e funcionam bem no Proxmox (às vezes exigindo um driver dkms, mas funcionam). Melhor ainda se seus Mini PCs tiverem slots PCIe livres para placas nativas.

Você deve separar o tráfego em pelo menos duas redes físicas ou VLANs robustas:

Rede de Cluster/Corosync + VM: Por onde os nós conversam "estou vivo" e por onde os usuários acessam os serviços.
Rede de Storage (Ceph Backend): Uma via expressa exclusiva para a replicação de dados.

Se você misturar o tráfego de replicação de dados (que pode saturar o link) com o "heartbeat" do cluster, você terá falsos positivos de falha. O cluster vai achar que um nó morreu só porque ele estava ocupado copiando um filme 4K.

Implementando Ceph para transformar discos locais em um pool unificado

Aqui a mágica acontece. O Ceph pega o SSD de 1TB do Nó 1, o SSD de 1TB do Nó 2 e o SSD de 1TB do Nó 3 e cria um "piscinão" lógico de armazenamento. Para o Proxmox, isso aparece como um único storage gigante.

A configuração padrão recomendada é Replica 3. Isso significa que cada bit de dado é gravado em três discos diferentes simultaneamente.

Vantagem: Você pode perder qualquer nó completo e seus dados estão seguros e acessíveis nos outros dois.
Custo: Você perde capacidade bruta. 3TB de discos físicos viram 1TB de espaço útil.

É um preço alto? Sim. Mas é o preço da disponibilidade imediata. Diferente de um RAID tradicional ou ZFS local, se um nó pega fogo, o Ceph redireciona as leituras/escritas para os sobreviventes instantaneamente.

Figura: O conceito de Replicação 3/2: O dado existe em três lugares ao mesmo tempo. Se um nó falha, o acesso continua sem interrupção.

Tabela comparativa: Estratégias de storage para home lab

Característica	Local ZFS/LVM	NAS Centralizado (TrueNAS/NFS)	Ceph (Hiperconvergente)
Custo de Hardware	Baixo (Discos locais)	Médio (Requer servidor dedicado)	Alto (Requer 3+ nós e SSDs melhores)
Performance de Leitura	Altíssima (Velocidade nativa)	Limitada pela Rede	Alta (Leitura distribuída)
Performance de Escrita	Altíssima	Limitada pela Rede	Média/Baixa (Latência de rede + Sync)
Ponto Único de Falha	Sim (Se o host cair, a VM para)	Sim (Se o NAS cair, tudo para)	Não (Redundância total)
Tempo de Recuperação	Manual (Restore de backup)	Rápido (Se tiver outro host)	Zero (Automático)
Complexidade	Baixa	Média	Alta

Orquestrando o cluster e isolando o tráfego de corosync

O Corosync é o protocolo que mantém o cluster unido. Ele envia pequenos pacotes de dados constantemente entre os nós. Se esses pacotes atrasarem mais que alguns milissegundos, o cluster entra em pânico.

⚠️ Perigo: Nunca coloque o tráfego do Corosync na mesma interface física que está fazendo o rebalancing pesado do Ceph sem QoS (Quality of Service) rigoroso. A saturação do link vai causar perda de pacotes do Corosync, resultando em fencing (reinicialização forçada) dos nós.

No Proxmox, ao criar o cluster, você pode definir múltiplos "Links" para o Corosync. Use isso. Configure o Link 0 na sua rede principal e o Link 1 na sua rede secundária/storage como backup. Isso cria redundância na comunicação vital do cluster.

Configurando grupos de HA e políticas de failover

Ter o cluster montado não significa que o HA está ativo. Você precisa explicitamente dizer ao Proxmox quais VMs ou Containers devem ser protegidos.

No menu "Datacenter > HA", criamos grupos. Aqui você define a afinidade. Por exemplo, você pode querer que o "Home Assistant" rode preferencialmente no "Nó 1" (talvez porque ele tenha o dongle Zigbee USB passado via passthrough - embora isso quebre a migração automática, a menos que você use Zigbee via rede).

A política de Failover funciona assim: O Proxmox detecta que o "Nó 1" parou de responder. Ele espera um tempo de segurança (dead interval). Confirmada a morte, ele "mata" qualquer resquício daquela VM (fencing) para garantir que não haja duplicidade e inicia a VM no "Nó 2".

O tempo total de downtime? Geralmente cerca de 1 a 2 minutos para o sistema operacional da VM bootar novamente. Não é "zero downtime" para a aplicação (a RAM é perdida), mas é recuperação automática sem intervenção humana.

O teste do cabo de força e a verificação de integridade

Não existe cluster HA até que você tenha puxado o cabo da tomada. É sério. Você precisa testar.

Abra um terminal e deixe um ping rodando para sua VM crítica. Vá até o Mini PC onde ela está rodando e puxe o cabo de energia.

O ping vai parar.
Você vai suar frio.
O Proxmox vai marcar o nó como "Dead".
Após cerca de 60-90 segundos, o ping deve voltar.

Se isso aconteceu, parabéns. Você tem um sistema resiliente. Se o cluster inteiro travou, você provavelmente tem problemas de configuração de quorum ou sua rede de storage engargalou o Corosync.

Figura: O "Teste do Grito": A única forma de validar seu cluster é simulando uma falha catastrófica física.

Quando a latência dispara e os SSDs de consumo falham

Voltando ao ponto dos SSDs, é aqui que muitos entusiastas desistem. Se você usar SSDs QLC baratos, durante a recuperação de um nó (quando o Ceph está copiando centenas de GBs para restaurar a redundância), a latência de I/O vai disparar.

O que acontece é o fenômeno de Latência de Cauda (Tail Latency). O SSD fica tão ocupado gravando dados de recuperação que demora 2, 3 ou 5 segundos para responder a uma simples leitura de banco de dados da sua VM. O resultado? Suas aplicações travam, o docker dentro da VM dá timeout e a experiência de uso vira um lixo.

Monitore o "IO Delay" no dashboard do Proxmox. Em um sistema saudável, deve ficar abaixo de 1-2%. Se você ver 10-20% de IO Delay, seus discos são o gargalo. A solução paliativa é diminuir a velocidade de recuperação do Ceph nas configurações globais, mas a solução real é hardware adequado.

Veredito Técnico

Montar um cluster Proxmox HA com Mini PCs e Ceph é o projeto final de graduação do homelabber. É complexo, exige planejamento de rede e escolha criteriosa de SSDs. Não é a forma mais barata de armazenar dados (o custo por TB é alto devido à tripla replicação), mas é imbatível em aprendizado e resiliência.

Se você quer apenas armazenar filmes, use um NAS simples. Se você quer aprender como a infraestrutura da nuvem funciona e garantir que seu DNS e automação residencial sobrevivam ao apocalipse (ou a uma fonte queimada), esse é o caminho. Comece com o que tem, mas respeite as leis da física do storage: latência importa mais que largura de banda.

Perguntas Frequentes (FAQ)

Posso usar SSDs comuns (Consumer) com Ceph?

Pode, mas prepare-se para sofrer. O Ceph gera uma quantidade brutal de escritas de sincronização (write amplification). SSDs de consumo sem proteção contra perda de energia (PLP) terão sua performance destruída porque precisam confirmar cada gravação na flash, ignorando o cache DRAM volátil. Além disso, a vida útil (TBW) deles será consumida rapidamente. Se o orçamento for curto, procure SSDs Enterprise usados no eBay ou AliExpress.

É possível fazer um cluster HA com apenas 2 nós?

Para HA automático e confiável, a matemática exige 3 votos para manter o quorum (51%). Com apenas 2 nós, se um cair, o outro entra em modo somente leitura para evitar o "split-brain" (onde ambos acham que são o mestre e corrompem os dados). Existe uma gambiarra oficial: usar um "QDevice" (Quorum Device). Pode ser um Raspberry Pi ou até uma VM em outra máquina que serve apenas como o "terceiro voto" de desempate, sem armazenar dados pesados.

Qual a diferença entre Ceph e ZFS Replication?

A diferença é o tempo real versus o "quase" tempo real. O Ceph é um storage distribuído onde todos os nós veem os mesmos dados simultaneamente; se um nó morre, o dado já está nos outros. A Replicação ZFS copia os dados periodicamente (ex: a cada 5 ou 15 minutos). Se usar ZFS Replication e o nó cair, você perde os dados gerados no intervalo desde a última cópia e o failover pode demorar mais para montar o disco no outro lado.