Como configurar um cluster de alta disponibilidade no Proxmox com Ceph passo a passo

A implementação de um cluster hiperconvergente utilizando Proxmox VE e Ceph representa o padrão ouro para infraestruturas de código aberto que buscam resiliência empresarial sem os custos proibitivos de soluções proprietárias. Ao unificar computação e armazenamento na mesma camada de hardware, eliminamos a necessidade de SANs externas complexas, mas introduzimos a necessidade de um rigoroso planejamento de rede e disco.

Neste guia, vamos construir um cluster de 3 nós capaz de suportar a falha completa de um servidor sem perda de dados ou interrupção prolongada dos serviços, utilizando o Ceph Reef como backend de armazenamento distribuído.

Resumo em 30 segundos

• Hiperconvergência: O Ceph utiliza os discos locais de cada servidor Proxmox para criar um pool de armazenamento único e distribuído. Não use controladoras RAID de hardware; o Ceph precisa de acesso direto ao disco (HBA/IT Mode).
• Regra de Três: Para um quórum saudável e failover automático seguro, o mínimo absoluto são 3 nós. Com 2 nós, você perde a automação em caso de falha de um deles.
• Segregação de Rede: O tráfego de replicação de dados (backend) deve ser fisicamente separado do tráfego de gerenciamento e VMs (frontend) para evitar gargalos de latência que derrubam o cluster.

---

Pré-requisitos de hardware e arquitetura

Antes de digitar qualquer comando, a física do armazenamento deve ser respeitada. O Ceph é um sistema de armazenamento definido por software que exige baixa latência.

1. Nós de Computação: 3 servidores com Proxmox VE 8.x instalado.

2. Discos de OSD (Object Storage Daemons): Pelo menos um SSD ou NVMe dedicado por nó para armazenamento.

   • ⚠️ Perigo: Nunca utilize discos SMR (Shingled Magnetic Recording) com Ceph. A latência de escrita causará timeouts e derrubará seus OSDs. Use apenas CMR ou SSDs/NVMes.

3. Rede:

   • Public Network: Para acesso à interface web e tráfego das VMs (ex: 192.168.10.0/24).
   • Cluster Network: Uma rede dedicada, preferencialmente 10GbE ou superior, para a replicação de dados do Ceph (ex: 10.10.10.0/24).

Figura: Arquitetura física recomendada: Separação total entre tráfego de gerenciamento e replicação de dados (backend).

Passo 1: Preparação do ambiente e rede

A comunicação entre os nós deve ser impecável. Primeiro, vamos configurar o arquivo hosts para garantir resolução de nomes independente de DNS externo, o que é crítico durante a inicialização do cluster.

Edite o arquivo /etc/hosts em todos os nós:

nano /etc/hosts

Adicione as entradas dos IPs da rede de gerenciamento (Public):

127.0.0.1       localhost
192.168.10.11   pve-node-01
192.168.10.12   pve-node-02
192.168.10.13   pve-node-03

Configuração das interfaces de rede

No painel do Proxmox, ou via /etc/network/interfaces, garanta que a segunda interface (para o Cluster Network) esteja configurada com IP estático e MTU 9000 (Jumbo Frames) se o seu switch suportar, para otimizar a transferência de grandes blocos de dados.

Exemplo de configuração para a interface de cluster (ens19):

auto ens19
iface ens19 inet static
    address 10.10.10.11/24
    mtu 9000

💡 Dica Pro: Teste a conectividade e a velocidade da rede de cluster com iperf3 antes de instalar o Ceph. Uma rede instável aqui causará "flapping" nos OSDs posteriormente.

Passo 2: Inicialização do Cluster Proxmox

Antes de instalar o Ceph, os nós devem formar um cluster Proxmox (Corosync).

1. Acesse o Node 01 via shell.

2. Crie o cluster:

pvecm create cluster-lab --link0 192.168.10.11

3. Nos Nodes 02 e 03, solicite a entrada no cluster. Você precisará do IP do Node 01 e a senha de root (ou fingerprint):

pvecm add 192.168.10.11 --link0 192.168.10.12
# No Node 03:
pvecm add 192.168.10.11 --link0 192.168.10.13

Verifique o status do quórum:

pvecm status

Você deve ver Total votes: 3 e Quorum: 2. Se todos os nós estiverem listados, podemos prosseguir para o armazenamento.

Passo 3: Instalação do Ceph Reef e configuração de rede

O Proxmox possui um assistente de instalação do Ceph que simplifica drasticamente o processo, mas precisamos tomar decisões críticas sobre a rede aqui.

1. Selecione o Node 01 na interface web.

2. Navegue até Ceph no menu lateral.

3. Clique em Install Ceph.

4. Escolha a versão Reef (ou a mais recente marcada como estável).

5. Inicie a instalação. O sistema baixará os pacotes necessários.

Configuração Crítica de Rede

Após a instalação dos pacotes, o assistente pedirá as redes. Esta é a etapa mais importante para a performance do storage.

• Public Network: Selecione a sub-rede de gerenciamento (ex: 192.168.10.0/24). É por onde os clientes (VMs) acessam os dados.

• Cluster Network: Selecione a sub-rede dedicada de alta velocidade (ex: 10.10.10.0/24). É por onde os dados são replicados e rebalanceados.

Figura: A segregação de tráfego na configuração inicial define a estabilidade futura do seu cluster.

Conclua o assistente. O Proxmox configurará o primeiro Monitor (MON) e Manager (MGR) no Node 01.

Passo 4: Expansão de Monitores e Managers

Para que o sistema de armazenamento seja de Alta Disponibilidade (HA), precisamos que o "cérebro" do Ceph (os Monitores) esteja distribuído.

1. Vá para Ceph > Monitor.

2. Você verá o monitor do Node 01 criado.

3. Clique em Create e selecione o Node 02.

4. Repita para o Node 03.

Agora você tem 3 Monitores. Se um nó cair, os outros dois mantêm o quórum e o cluster continua operando (leitura/escrita). Faça o mesmo para os Managers (MGR), garantindo que haja pelo menos uma réplica em outro nó.

Passo 5: Provisionamento de OSDs (Object Storage Daemons)

Agora vamos transformar os discos físicos em armazenamento lógico. O Ceph utiliza o BlueStore, que escreve diretamente no dispositivo bruto, sem sistema de arquivos intermediário (como ext4 ou xfs), para máxima performance.

Requisito: Os discos devem estar "limpos" (sem partições). Se necessário, use o comando wipefs -a /dev/sdX no shell do nó correspondente.

1. Navegue até Ceph > OSD.

2. Clique em Create: OSD.

3. Na janela modal:

   • Disk: Selecione o disco NVMe ou SSD físico (ex: /dev/nvme0n1).
   • DB/WAL: Se você estiver usando HDDs mecânicos (spinners) para os dados, é altamente recomendável usar um SSD/NVMe para o DB (Database) e WAL (Write Ahead Log). Se o disco principal já for SSD/NVMe, deixe essas opções em branco (o Ceph colocará tudo no mesmo dispositivo, o que é ideal para flash storage).

4. Repita o processo para todos os discos em todos os 3 nós.

Figura: Estratégia de OSD: Para discos rotacionais, o offload de WAL/DB para flash é obrigatório para performance aceitável.

Ao final, você deve ter um número equilibrado de OSDs por nó (ex: 2 OSDs em cada um dos 3 nós, totalizando 6 OSDs). O status deve estar up e in.

Passo 6: Criação de Pools e Regras de Réplica

Com os discos ativos, precisamos criar o "Pool" onde as VMs serão armazenadas.

1. Vá para Ceph > Pools.

2. Clique em Create.

3. Name: rbd-vm-storage (ou outro nome de sua preferência).

4. Size: 3. Isso significa que cada dado será gravado em 3 discos diferentes, preferencialmente em hosts diferentes.

5. Min. Size: 2.

   • 💡 Conceito Chave: O Min. Size define o mínimo de cópias necessárias para aceitar uma escrita (I/O). Se definirmos como 2, o cluster aceita gravações mesmo se um nó estiver offline. Se definirmos como 1, arriscamos perda de dados. Nunca use Min. Size 1 em produção.

6. CRUSH Rule: Deixe o padrão (replicated_rule).

7. Marque a caixa Add as Storage. Isso adicionará automaticamente este pool como um storage disponível para o Proxmox criar discos de VM.

Passo 7: Configuração de Alta Disponibilidade (HA) e Fencing

Ter o armazenamento replicado é apenas metade da batalha. Se um nó falhar, o Proxmox precisa saber automaticamente reiniciar as VMs nos nós sobreviventes.

Criando Grupos de HA

1. Vá para Datacenter > HA > Groups.

2. Crie um grupo chamado ha-cluster.

3. Adicione todos os 3 nós.

4. Defina restricted (opcional, mas recomendado para evitar que VMs migrem para nós fora do grupo em clusters maiores).

Adicionando Recursos (VMs) ao HA

Para que uma VM seja protegida:

1. Vá para Datacenter > HA.

2. Clique em Add.

3. Selecione a VM desejada.

4. Defina Max. Restart: 1 (Tenta reiniciar uma vez no mesmo nó antes de migrar) ou 0 (Migra direto).

5. Defina Max. Relocate: 1.

O papel vital do Fencing (Watchdog)

Em clusters hiperconvergentes, o "Split-brain" (quando dois nós acham que são o mestre e tentam escrever no mesmo disco) corrompe dados. O Proxmox usa um mecanismo de Watchdog de hardware para evitar isso. Se um nó perde contato com o quórum, o watchdog reinicia o servidor fisicamente ("Fencing") para garantir que ele pare de escrever dados.

Verifique se o watchdog está ativo em todos os nós:

wdctl

Você deve ver um dispositivo como /dev/watchdog0 ou similar ativo. O Proxmox gerencia isso automaticamente na maioria das instalações modernas, mas é vital confirmar.

Passo 8: Validação de Falha e Recuperação

Um cluster não testado é um cluster que não existe. Vamos simular uma falha.

1. Crie uma VM de teste e armazene seu disco no pool rbd-vm-storage.

2. Configure a VM para HA (como no passo 7).

3. Inicie a VM no Node 01.

4. Deixe um ping contínuo rodando para a VM.

O Teste de Fogo: Desconecte o cabo de rede ou force o desligamento abrupto do Node 01 (não use shutdown, puxe a tomada ou use echo c > /proc/sysrq-trigger para simular um kernel panic).

O que deve acontecer:

1. O ping da VM vai parar.

2. Após cerca de 60 a 120 segundos (tempo de detecção do timeout), o Proxmox nos nós 02 e 03 perceberá a morte do nó 01.

3. O status do cluster mudará, mas o quórum se manterá (2 de 3 votos).

4. O Ceph entrará em estado DEGRADED (pois faltam as cópias do nó 1), mas continuará operacional (graças ao Min. Size 2).

5. A VM será reiniciada automaticamente em um dos nós sobreviventes.

6. O ping retornará.

Figura: Diagnóstico visual: O estado "Degraded" no Ceph é esperado durante falhas. O sistema continua funcional enquanto recupera a redundância.

Diagnóstico de Split-brain e Estados de Degradação

Durante a operação, você pode encontrar estados que exigem atenção:

• HEALTH_WARN (Degraded): Significa que alguns dados não têm o número total de réplicas (3), mas ainda existem cópias suficientes para leitura/escrita. Isso ocorre durante a falha de um nó ou substituição de disco. O Ceph se cura sozinho ("Self-healing") assim que o nó volta ou um novo disco é adicionado.

• HEALTH_ERR (Blocked requests): Se você perder 2 nós de 3, o cluster para de aceitar escritas para proteger a integridade dos dados (perda de quórum).

• Split-Brain: Se a rede de cluster falhar mas a rede pública funcionar, os nós podem ficar confusos. O Corosync resolve isso via votos. Nunca altere manualmente o número de votos (pvecm expected) a menos que saiba exatamente o que está fazendo, pois isso pode causar corrupção irreversível de dados.

Manutenção Preditiva

A configuração de um cluster Proxmox com Ceph transforma hardware commodity em uma fortaleza de dados. No entanto, a alta disponibilidade não elimina a necessidade de monitoramento.

Recomendo fortemente configurar o Scrubbing (verificação de integridade de dados) para rodar semanalmente e configurar alertas de e-mail para falhas de disco (SMART values). Em armazenamento distribuído, a rede é tão importante quanto o disco; monitore a saturação da sua rede de backend (Cluster Network), pois ela será o primeiro gargalo de performance à medida que seu cluster cresce.