Linux em ambientes de alta disponibilidade: Pacemaker e Corosync

1. Introdução à Alta Disponibilidade no Linux

Alta disponibilidade (HA) refere-se à capacidade de um sistema permanecer operacional por períodos prolongados, minimizando interrupções. No contexto Linux, isso é alcançado através de clusters que garantem failover automático e redundância. Os conceitos fundamentais incluem:

Tempo de atividade (uptime): métrica que mede a disponibilidade do serviço.
Failover: transferência automática de recursos para um nó substituto em caso de falha.
Redundância: duplicação de componentes críticos para eliminar pontos únicos de falha.

Cenários típicos incluem servidores web críticos, bancos de dados relacionais (como PostgreSQL ou MariaDB), servidores de arquivos NFS e infraestrutura de virtualização. O ecossistema padrão no Linux é composto por duas ferramentas principais:

Corosync: responsável pela comunicação entre os nós do cluster, fornecendo heartbeat, votação e entrega confiável de mensagens.
Pacemaker: gerenciador de recursos que toma decisões baseadas no estado do cluster e executa ações como iniciar, parar ou migrar serviços.

2. Arquitetura do Stack de Alta Disponibilidade

A arquitetura do cluster HA é organizada em camadas:

Camada de comunicação: Corosync gerencia o heartbeat (batimento cardíaco) entre nós, detectando falhas através de mensagens periódicas. O protocolo utiliza votação para determinar o quorum (número mínimo de nós para operação segura) e entrega mensagens ordenadas a todos os membros.
Camada de gerenciamento de cluster: Pacemaker interpreta as informações do Corosync e mantém o estado global do cluster. Ele implementa políticas de decisão, como onde um recurso deve ser executado e quando realizar failover.
Camada de recursos: São os serviços gerenciados (IP virtual, sistemas de arquivos, aplicações). O Pacemaker executa ações como start, stop, monitor e promote (para recursos mestre/escravo).

A comunicação entre nós utiliza uma rede privada dedicada (geralmente Ethernet com baixa latência). O Corosync suporta protocolos UDP e SCTP, garantindo entrega confiável mesmo em redes congestionadas.

3. Instalação e Configuração Inicial do Cluster

Requisitos de hardware e rede

Mínimo de 2 nós (recomendado 3 para quorum robusto)
Rede privada entre nós (ex: 10.0.0.0/24)
Sincronismo de tempo via NTP ou Chrony
Resolução de nomes consistente (DNS ou /etc/hosts)

Instalação dos pacotes (exemplo para RHEL/CentOS/Fedora)

sudo dnf install -y corosync pacemaker pcs
sudo systemctl enable --now pcsd

Para Debian/Ubuntu:

sudo apt update
sudo apt install -y corosync pacemaker pcs
sudo systemctl enable --now pcsd

Configuração básica do Corosync

O arquivo principal é /etc/corosync/corosync.conf. Exemplo para cluster de dois nós:

totem {
    version: 2
    cluster_name: meu_cluster
    transport: knet
    crypto_cipher: aes256
    crypto_hash: sha256
}

nodelist {
    node {
        ring0_addr: 10.0.0.1
        name: node1
        nodeid: 1
    }
    node {
        ring0_addr: 10.0.0.2
        name: node2
        nodeid: 2
    }
}

quorum {
    provider: corosync_votequorum
    two_node: 1
}

logging {
    to_logfile: yes
    logfile: /var/log/corosync/corosync.log
    to_syslog: yes
}

Após configurar, autentique os nós e inicie o cluster:

sudo pcs cluster auth node1 node2 -u hacluster
sudo pcs cluster setup --name meu_cluster node1 node2
sudo pcs cluster start --all

4. Gerenciamento de Recursos com Pacemaker

Definição de recursos primitivos

Exemplo de IP virtual (VIP):

sudo pcs resource create vip IPaddr2 ip=192.168.1.100 cidr_netmask=24 op monitor interval=10s

Recurso do Apache:

sudo pcs resource create webserver apache configfile=/etc/httpd/conf/httpd.conf op monitor interval=30s

Grupos e restrições

Agrupar recursos para que sejam executados no mesmo nó:

sudo pcs resource group add webgroup vip webserver

Restrições de ordem (webserver deve iniciar após VIP):

sudo pcs constraint order start vip then start webserver

Restrições de localização (preferir node1):

sudo pcs constraint location webgroup prefers node1=50

5. Estratégias de Failover e Recuperação

Modos de failover

Ativo/passivo: um nó executa os recursos, o outro fica em espera. Failover ocorre em segundos.
Ativo/ativo: ambos os nós executam recursos simultaneamente (ex: balanceamento de carga).

Verificação de saúde

O Pacemaker monitora recursos através de ações monitor. Se um recurso falhar, o cluster tenta reiniciá-lo localmente antes de migrar para outro nó.

Tratamento de falhas

Split-brain: ocorre quando a comunicação entre nós é perdida. O quorum impede decisões conflitantes.
Fencing (STONITH): mecanismo para isolar nós com falha, garantindo que não acessem recursos compartilhados. Exemplo com fence_ilo:

sudo pcs stonith create my_fence fence_ilo ipaddr=10.0.0.10 login=admin passwd=secret

6. Monitoramento e Manutenção do Cluster

Ferramentas de monitoramento

sudo pcs status             # Resumo do cluster
sudo crm_mon -1             # Monitoramento em tempo real
sudo journalctl -u corosync # Logs do Corosync
sudo journalctl -u pacemaker # Logs do Pacemaker

Operações comuns

Parar um recurso:

sudo pcs resource disable webserver

Migrar manualmente para outro nó:

sudo pcs resource move webserver node2

Atualizações sem downtime

Ative o modo de manutenção:

sudo pcs property set maintenance-mode=true

Após atualizações, desative o modo:

sudo pcs property set maintenance-mode=false

Drenagem de nós (mover todos os recursos):

sudo pcs node standby node1
sudo pcs node unstandby node1

7. Exemplos Práticos e Boas Práticas

Configuração completa de cluster de dois nós

# Configurar VIP e Apache
sudo pcs resource create WebVIP ocf:heartbeat:IPaddr2 ip=192.168.1.100 cidr_netmask=24 op monitor interval=10s
sudo pcs resource create WebServer ocf:heartbeat:apache configfile=/etc/httpd/conf/httpd.conf op monitor interval=30s

# Agrupar recursos
sudo pcs resource group add WebGroup WebVIP WebServer

# Configurar STONITH (exemplo com fence_virt)
sudo pcs stonith create my_fence fence_virt pcmk_host_list="node1 node2"

# Verificar status
sudo pcs status

Integração com contêineres (Docker/Podman)

Recurso para gerenciar contêiner via Docker:

sudo pcs resource create docker-web ocf:heartbeat:docker image=nginx:latest run_opts="-p 80:80" op monitor interval=30s

Boas práticas

Testes de failover: simule falhas periodicamente (ex: desligar um nó).
Documentação: mantenha registros de todas as configurações.
Backups: faça backup dos arquivos /etc/corosync/corosync.conf e da configuração do Pacemaker (pcs config backup).
Rede dedicada: use uma interface de rede separada para tráfego do cluster.
Atualizações planejadas: utilize modo de manutenção para evitar interrupções.

Referências

Documentação Oficial do Pacemaker — Guia completo de configuração e administração do Pacemaker.
Documentação do Corosync — Referência técnica sobre o protocolo de comunicação e configuração do Corosync.
Tutorial Cluster Labs: Two-Node Cluster — Guia rápido para configurar um cluster básico de dois nós.
Red Hat High Availability Add-On Documentation — Documentação oficial da Red Hat sobre clusters HA no RHEL.
SUSE Linux Enterprise High Availability Guide — Guia completo de alta disponibilidade da SUSE, incluindo exemplos práticos.
Pacemaker Explained: A Practical Guide — Artigo do Linux Journal com explicações detalhadas e exemplos de código.
Corosync and Pacemaker: Building Resilient Linux Clusters — Tutorial da OpenSource.com sobre construção de clusters resilientes.

Linux em ambientes de alta disponibilidade: Pacemaker e Corosync ✓