Alta Disponibilidade Linux: Cluster HA com DRBD e Pacemaker

Para uma PME que depende de serviços críticos (base de dados, servidor de ficheiros, aplicação web), um downtime de horas pode custar mais do que a própria infra-estrutura. Um cluster de alta disponibilidade (HA) em Linux garante que, se um nó falhar, outro assume automaticamente o serviço em segundos — sem armazenamento partilhado caro (SAN).

Este guia mostra como implementar um cluster HA com DRBD (replicação de armazenamento block-level), Corosync (comunicação entre nós) e Pacemaker (orquestração de recursos) — a stack de código aberto de referência para HA em Linux, suportada pelo ClusterLabs.

1. Introdução ao HA em Linux

Alta disponibilidade não é cópia de segurança nem tolerância a falhas de hardware individual. É a capacidade de um serviço continuar disponível quando um componente falha. Em Linux, isto consegue-se com um cluster de pelo menos dois nós que partilham estado através de replicação e coordenam falhas via quorum.

A stack clássica tem três camadas: DRBD replica discos block-level pela rede (RAID-1 via Ethernet), Corosync mantém o heartbeat entre nós e gere o quorum, e Pacemaker decide qual nó corre cada recurso e executa o failover. Ao contrário de soluções com SAN partilhada, não há ponto único de falha no armazenamento.

Pré-requisitos: dois servidores Linux (Debian/Ubuntu ou RHEL/AlmaLinux) com rede dedicada para replicação (idealmente 1 Gbps ou superior), um disco livre em cada nó (ex: /dev/sdb1), e IPs estáticos. Para quorum num cluster de 2 nós, recomenda-se um terceiro nó witness ou dispositivo de quorum.

2. Instalar DRBD

O DRBD (Distributed Replicated Block Device) cria um dispositivo de bloco virtual (/dev/drbd0) que replica escritas para ambos os nós em tempo real. O DRBD é mantido pela LINBIT e disponível nos repositórios oficiais das principais distribuições.

Instalar o pacote em ambos os nós e configurar o recurso r0:

# Instalar DRBD em ambos os nos
sudo apt install drbd-utils

# Configurar recurso /etc/drbd.d/r0.res
resource r0 {
  protocol C;
  on node1 { device /dev/drbd0; disk /dev/sdb1; address 10.0.0.1:7789; meta internal; }
  on node2 { device /dev/drbd0; disk /dev/sdb1; address 10.0.0.2:7789; meta internal; }
}

# Inicializar metadata em ambos os nos
sudo drbdadm create-md r0

# Activar o recurso em ambos os nos
sudo drbdadm up r0

# Marcar o node1 como primary (apenas no node1)
sudo drbdadm primary r0 --force

# Formatar e montar (no node1)
sudo mkfs.ext4 /dev/drbd0
sudo mount /dev/drbd0 /mnt/data

O protocol C garante replicação síncrona — a escrita só confirma após chegar ao disco remoto. É o protocolo mais seguro (zero perda de dados), mas tem mais latência. Para cargas onde alguma perda é tolerável, o protocolo A (assíncrono) oferece melhor desempenho.

Verificar o estado da replicação com cat /proc/drbd — deve mostrar Primary/Secondary e UpToDate/UpToDate após a sincronização inicial.

3. Configurar Corosync

O Corosync é o motor de comunicação do cluster — mantém o heartbeat entre nós, gere o quorum e entrega mensagens de membership. Sem Corosync, o Pacemaker não sabe quais nós estão vivos. Para clusters de 2 nós, é obrigatório configurar um dispositivo de quorum externo para evitar split-brain.

Em Debian/Ubuntu, o pcs automatiza a configuração do Corosync. Instalar Pacemaker, Corosync e pcs em ambos os nós:

# Instalar Pacemaker + Corosync + pcs em ambos os nos
sudo apt install pacemaker corosync pcs

# Activar e iniciar o servico pcsd
sudo systemctl enable --now pcsd

# Definir password do utilizador hacluster (igual em ambos os nos)
sudo passwd hacluster

# Autenticar os nos (a partir de um deles)
sudo pcs cluster auth node1 node2

# Criar e iniciar o cluster
sudo pcs cluster setup hacluster node1 node2
sudo pcs cluster start --all
sudo pcs cluster enable --all

# Verificar o estado
sudo pcs status corosync
sudo corosync-cmapctl | grep quorum

Para um cluster de 2 nós sem terceiro nó, desactivar a política de quorum estrito (não recomendado em produção crítica) ou configurar um dispositivo de quorum externo:

# Para cluster de 2 nos, permitir operacao sem quorum
# (apenas se nao houver witness node - usar com cautela)
sudo pcs property set no-quorum-policy=ignore

# Alternativa recomendada: configurar quorum device (QDevice)
sudo pcs qdevice add model net host=10.0.0.100 algorithm=ffsplit
sudo pcs qdevice start

4. Configurar Pacemaker

O Pacemaker é o gestor de recursos do cluster — decide onde cada serviço corre, monitoriza a sua saúde e executa o failover. Um recurso pode ser um IP virtual, um filesystem, um serviço systemd ou um script OCF (Open Cluster Framework).

Começar por criar o IP virtual — o endereço que os clientes usam para aceder ao serviço, que flutua entre nós conforme o failover:

# Criar recurso IP virtual
sudo pcs resource create VIP ocf:heartbeat:IPaddr2 \
  ip=10.0.0.100 cidr_netmask=24 \
  op monitor interval=30s

# Criar recurso DRBD (filesystem replicado)
sudo pcs resource create DRBD ocf:linbit:drbd \
  drbd_resource=r0 \
  op monitor interval=15s

# Promover DRBD a master/slave (Primary/Secondary)
sudo pcs resource master DRBDClone DRBD \
  master-max=1 master-node-max=1 clone-max=2 clone-node-max=1 notify=true

# Criar filesystem que monta o DRBD
sudo pcs resource create FS ocf:heartbeat:Filesystem \
  device=/dev/drbd0 directory=/mnt/data fstype=ext4

# Ordenar: DRBD -> FS -> VIP
sudo pcs constraint order DRBDClone then FS
sudo pcs constraint order FS then VIP

# Colocar tudo no mesmo no
sudo pcs constraint colocation add FS DRBDClone INFINITY with-rsc-role=Master
sudo pcs constraint colocation add VIP FS INFINITY

As restrições de ordem garantem que o DRBD é promovido a Primary antes de montar o filesystem, e este antes de activar o IP. As restrições de colocação garantem que tudo corre no mesmo nó.

5. Recursos e Fencing

Fencing (STONITH — Shoot The Other Node In The Head) é o mecanismo que desliga fisicamente ou isolamenta um nó que deixou de responder. Sem fencing, se o heartbeat falhar mas o nó continuar a escrever no disco, ambos os nós podem tentar ser Primary simultaneamente — split-brain, que corrompe dados.

Tipos de fencing comuns em PME: IPMI/BMC (desliga o servidor via interface de gestão), iLO/iDRAC (vendor-specific), libvirt (em ambientes virtualizados), APC/Schneider PDU (corta energia pela tomada de rede).

# Exemplo: fencing via IPMI
sudo pcs stonith create stonith-ipmi-node1 fence_ipmilan \
  pcmk_host_list=node1 ipaddr=10.0.0.11 login=admin passwd=SEGREDO \
  lanplus=1 cipher=3 op monitor interval=60s

sudo pcs stonith create stonith-ipmi-node2 fence_ipmilan \
  pcmk_host_list=node2 ipaddr=10.0.0.12 login=admin passwd=SEGREDO \
  lanplus=1 cipher=3 op monitor interval=60s

# Verificar configuracao de fencing
sudo pcs stonith show
sudo pcs stonith fence --confirm node1  # teste manual

Para PME sem IPMI, uma alternativa é o fence_scsi (fencing via SCSI persistent reservations) ou fence_vmware_soap em ambientes virtualizados no VMware.

6. Testar Failover

Após configurar o cluster, é obrigatório testar o failover em todos os cenários antes de entrar em produção. Um cluster não testado é uma falsa sensação de segurança.

# Cenario 1: Failover manual
sudo pcs node standby node1
# Verificar que os recursos migraram para node2
sudo pcs status

# Reativar node1 (os recursos nao voltam automaticamente)
sudo pcs node unstandby node1

# Cenario 2: Simular falha de servico
sudo pcs resource fail-stop FS
sudo pcs status  # verificar se Pacemaker reiniciou o recurso

# Cenario 3: Mover recurso explicitamente
sudo pcs resource move VIP node2
sudo pcs resource clear VIP  # limpar restricao temporaria

# Cenario 4: Matar processo do DRBD
sudo killall drbdworker
sudo pcs status  # verificar recuperacao automatica

Os tempos dependem do timeout configurado em cada recurso (op monitor interval, timeout, e do tempo de promovção do DRBD). Ajustar conforme os requisitos de RTO (Recovery Time Objective).

7. Erros Comuns e Lista de Verificação

A maioria dos problemas em clusters HA não vem de bugs, mas de configuração incorrecta ou pressupostos inválidos. Estes são os erros mais frequentes e como os evitar:

Lista de Verificação pré-produção

Antes de considerar o cluster pronto para produção, confirmar cada ponto:

• STONITH configurado e testado — executar pcs stonith fence --confirm nodeX e confirmar que o nó desliga.
• Quorum garantido — cluster de 2 nós tem QDevice ou no-quorum-policy=stop (não ignore).
• DRBD sincronizado — cat /proc/drbd mostra UpToDate/UpToDate.
• Restrições de ordem e colocação — pcs constraint show sem conflitos.
• Firewall configurado — portas 7789 (DRBD), 5404/5405 UDP (Corosync), 2224 TCP (pcsd) abertas.
• Rede dedicada de replicação — interface separada para DRBD, idealmente cross-link directo.
• Failover testado em todos os cenários — standby, kill de processo, power off, falha de rede.
• Monitorização activa — alertas para estado do cluster, DRBD, quorum e STONITH.
• Backups independente do DRBD — DRBD não substitui backups; se ambos os nós corrompem, perde-se tudo.

Um cluster HA bem configurado proporciona RTO de segundos e RPO zero (com protocol C). Para PME, é a forma mais custo-eficiente de alcançar disponibilidade elevada sem investir em SAN ou soluções proprietárias. A chave está no testing rigoroso e no fencing correctamente configurado.