Aula 29: Alta disponibilidade — clustering e failover no Linux

A alta disponibilidade é um dos pilares fundamentais da infraestrutura moderna. Em ambientes corporativos, uma aplicação ou serviço fora do ar pode representar prejuízos financeiros, perda de dados e danos irreparáveis à reputação da empresa. No contexto do Linux, alcançar alta disponibilidade significa eliminar pontos únicos de falha por meio de clusters, replicação de estado e mecanismos automáticos de failover. Nesta aula, você vai dominar os conceitos e as ferramentas que permitem manter serviços críticos operando mesmo diante de falhas de hardware, rede ou aplicação.

Ao longo desta aula, vamos trabalhar com as duas principais soluções de clustering para Linux: Corosync e Pacemaker. O Corosync é responsável pela camada de comunicação e associação (membership) entre os nós do cluster, enquanto o Pacemaker atua como o gerenciador de recursos, decidindo onde cada serviço deve rodar e reagindo a falhas. Você aprenderá a instalar, configurar e validar um cluster de dois nós com failover automático de um serviço web e de um IP virtual — um cenário realista e amplamente utilizado em produção.

Esta é uma aula avançada do curso Linux — Do Zero ao Avançado. Se você concluiu as aulas anteriores, já possui familiaridade com administração de sistemas, rede, serviços e shell script. Agora, vamos elevar o nível para arquiteturas resilientes. Nosso objetivo é que, ao final, você consiga projetar e implementar um cluster de alta disponibilidade funcional, realizar testes de failover reais e diagnosticar os problemas mais comuns nesse tipo de ambiente.

Em nossos projetos na JRT Technology Solutions, utilizamos diariamente clusters Corosync/Pacemaker para sustentar ambientes críticos de clientes dos setores financeiro, industrial e de saúde. Os procedimentos descritos aqui refletem práticas reais de implementação e operação que nossos especialistas aplicam em campo. Siga cada passo com atenção: todos os comandos foram testados em distribuições Ubuntu 22.04, Debian 12, Rocky Linux 9 e CentOS Stream 9.

O que você vai aprender nesta aula

Esta aula foi estruturada para levar você de uma compreensão teórica sólida até a execução prática completa de um cluster de alta disponibilidade. Os objetivos de aprendizagem são:

• Compreender os conceitos de alta disponibilidade, clustering e failover no contexto Linux
• Diferenciar soluções de HA ativo-passivo e ativo-ativo
• Instalar e configurar o Corosync e o Pacemaker em distribuições Debian/Ubuntu e RHEL/Rocky
• Configurar autenticação e comunicação segura entre os nós do cluster
• Criar recursos de IP virtual e serviços gerenciados pelo cluster
• Definir constraints de ordem, colocação e localização para controlar o comportamento do failover
• Executar testes práticos de failover e verificar a integridade do cluster
• Diagnosticar e corrigir os erros mais comuns em ambientes de clustering Linux

Ao final, você terá implementado um cluster de dois nós com failover automático, capaz de garantir alta disponibilidade para um serviço web. Mais do que isso, entenderá os mecanismos internos que tornam essa arquitetura confiável.

Pré-requisitos e Ambiente

Antes de iniciar esta aula, você precisará de um ambiente com pelo menos duas máquinas virtuais ou físicas rodando Linux. O ideal é que ambas tenham configurações idênticas de sistema operacional e versões de pacotes para evitar comportamentos inesperados. Em nossos laboratórios na JRT Technology Solutions, padronizamos os nós para reduzir variáveis de troubleshooting.

Os requisitos mínimos para acompanhar esta aula são:

• Dois servidores Linux (físicos ou virtuais) com acesso root ou sudo
• Rede local com comunicação bidirecional entre os nós
• Nomes de host únicos e resolução de nomes configurada em /etc/hosts
• Portas de firewall liberadas para o cluster (UDP 5404 e 5405)
• Serviço de sincronização de horário (NTP ou Chrony) ativo em ambos os nós
• Conhecimento de linha de comando, edição de arquivos e serviços systemd

Nesta aula, utilizaremos os nós node01 (IP 192.168.56.101) e node02 (IP 192.168.56.102). Ajuste os valores conforme seu ambiente. O recurso de alta disponibilidade será um IP virtual na faixa 192.168.56.200 e o serviço Apache. Se você estiver usando VirtualBox, VMware ou Proxmox, crie duas VMs com pelo menos 2 GB de RAM e 2 vCPUs cada.

Conceitos Fundamentais de Alta disponibilidade, Clustering e Failover

Antes de executar qualquer instalação, é essencial compreender a terminologia e os princípios que sustentam a alta disponibilidade. Um cluster de HA é um conjunto de computadores que trabalham em conjunto para manter serviços disponíveis. Quando um nó falha, outro assume automaticamente a carga — processo chamado failover. O oposto, failback, ocorre quando o nó original se recupera e o serviço retorna a ele, dependendo das políticas configuradas.

No universo Linux, a stack mais madura e amplamente adotada para alta disponibilidade é composta por Corosync e Pacemaker. O Corosync oferece o transporte de mensagens e o gerenciamento de quórum, garantindo que todos os nós do cluster compartilhem uma visão consistente de quem está ativo. O Pacemaker, por sua vez, abstrai a complexidade de decidir quais recursos rodam em quais nós, usando um motor de políticas baseado em constraints.

Um conceito central é o quórum. Em um cluster com dois nós, o quórum exige a maioria dos votos. Se os nós perdem comunicação, há risco de split-brain — situação em que ambos tentam executar o mesmo recurso simultaneamente, corrompendo dados. Para evitar isso, usa-se o STONITH (Shoot The Other Node In The Head), um mecanismo de isolamento que desliga ou reinicia o nó problemático. Em ambientes de produção na JRT Technology Solutions, nunca configuramos clusters sem STONITH, mesmo em testes.

Os recursos gerenciados pelo Pacemaker podem ser primitivos (um IP, um serviço systemd, um filesystem) ou grupos (conjunto de recursos que sobem juntos no mesmo nó). As constraints definem relações: onde um recurso pode rodar, em que ordem e com quais outros recursos. Compreender essa camada de políticas é o que diferencia um cluster funcional de um cluster frágil.

Existem dois modelos principais de alta disponibilidade: ativo-passivo, onde um nó fica ocioso aguardando falha, e ativo-ativo, onde todos os nós processam carga. Nesta aula, focaremos no modelo ativo-passivo por ser mais simples, robusto e adequado à maioria das aplicações corporativas. O modelo ativo-ativo exige balanceamento de carga e replicação de dados, tópicos avançados que recomendamos apenas para cenários específicos.

Arquitetura do Cluster e Planejamento da Implementação

Antes de tocar nos servidores, precisamos definir a arquitetura do nosso cluster de alta disponibilidade. Nosso cenário consistirá em dois nós idênticos executando um serviço web Apache e um IP virtual de frontend. O objetivo é que, em condições normais, o serviço rode no node01; se ele falhar, o node02 assume em poucos segundos, sem intervenção manual.

A comunicação do cluster utilizará a rede de dados principal, mas em ambientes críticos recomendamos uma rede dedicada para o tráfego do Corosync. Essa separação evita que picos de tráfego de dados afetem a troca de mensagens do cluster. Em nossos projetos na JRT Technology Solutions, quando o orçamento permite, configuramos uma interface dedicada exclusivamente para heartbeat, geralmente uma VLAN isolada.

Os componentes que serão instalados incluem: corosync (camada de mensageria), pacemaker (gerenciador de recursos), pcs (interface de linha de comando para configurar e operar o cluster) e apache2/httpd (serviço a ser protegido). No Debian/Ubuntu, os pacotes são corosync, pacemaker e pcs. No RHEL/Rocky, os pacotes também são encontrados nos repositórios padrão ou no High Availability Add-On.

Precisamos também definir o STONITH. Em um cluster virtual, a implementação de STONITH pode ser feita com fence_virsh (para libvirt/KVM) ou fence_vmware_soap (para VMware). Como estamos em ambiente educacional, configuraremos o STONITH como desabilitado, mas com um alerta claro: em produção, isso é inaceitável. O motivo é simples — sem STONITH, o Pacemaker não consegue isolar um nó com problemas, deixando o cluster vulnerável a split-brain.

Com a arquitetura definida, prepare os dois nós conforme os passos a seguir. Certifique-se de que os nomes de host estão corretamente configurados, que o relógio está sincronizado e que a resolução de nomes funciona. Esses detalhes evitam a maioria dos problemas de instalação.

Passo a Passo — Instalação do Corosync e Pacemaker no Ubuntu/Debian e RHEL/Rocky

Vamos iniciar a instalação dos pacotes necessários em ambos os nós. O procedimento é semelhante nas duas famílias de distribuições, mas os comandos de gerenciamento de pacotes e os caminhos de alguns arquivos diferem. Executaremos todos os comandos como root ou com sudo. Em nossos treinamentos na JRT Technology Solutions, recomendamos o uso de um usuário administrativo com sudo para rastreabilidade.

Passo 1: Atualizar os repositórios e instalar os pacotes no Ubuntu/Debian

Em cada nó Ubuntu ou Debian, execute os comandos abaixo. O pacote pcs inclui a ferramenta pcsd, que fornece uma API e interface web para gerenciamento do cluster.

# Atualiza a lista de pacotes disponíveis
sudo apt update

# Instala o Corosync, Pacemaker, PCS e os agentes de fencing
sudo apt install -y corosync pacemaker pcs fence-agents

# Habilita e inicia o serviço pcsd (usado pelo PCS para comunicação)
sudo systemctl enable --now pcsd

# Verifica o status do serviço pcsd
sudo systemctl status pcsd --no-pager

Passo 2: Instalar os pacotes no RHEL/Rocky Linux

No RHEL, Rocky Linux ou CentOS Stream, os pacotes estão disponíveis nos repositórios oficiais. Em versões mais antigas, pode ser necessário habilitar o repositório HighAvailability. No Rocky Linux 9, os pacotes são encontrados no repositório highavailability.

# Instala os pacotes de alta disponibilidade
sudo dnf install -y pacemaker corosync pcs fence-agents-all

# Habilita e inicia o pcsd
sudo systemctl enable --now pcsd

# Verifica o status do pcsd
sudo systemctl status pcsd --no-pager

A saída esperada após a execução em ambos os sistemas deve mostrar o serviço pcsd ativo e habilitado. A falta de erros indica que a instalação foi bem-sucedida.

● pcsd.service - PCS GUI and remote configuration support
     Loaded: loaded (/usr/lib/systemd/system/pcsd.service; enabled; preset: disabled)
     Active: active (running) since Tue 2026-09-15 14:32:10 -03; 5s ago
       Docs: man:pcsd(8)
   Main PID: 2841 (pcsd)
      Tasks: 1 (limit: 2312)
     Memory: 4.7M
        CPU: 102ms
     CGroup: /system.slice/pcsd.service
             └─2841 /usr/lib/pcs/pcsd start

Passo 3: Configurar o arquivo /etc/hosts em ambos os nós

A resolução de nomes é crítica para o cluster. Adicione as entradas correspondentes aos IPs dos dois nós. Substitua os IPs pelos valores do seu ambiente. O arquivo deve ficar idêntico nos dois servidores.

# Edita o arquivo de hosts
sudo nano /etc/hosts

Conteúdo a ser adicionado ao arquivo /etc/hosts:

# Configuração de resolução de nomes para o cluster de alta disponibilidade
192.168.56.101  node01
192.168.56.102  node02

Passo 4: Definir a senha do usuário hacluster

O PCS utiliza o usuário hacluster para autenticação entre os nós. Defina a mesma senha em ambos os nós — essa consistência é obrigatória para que a autenticação funcione.

# Define a senha do usuário hacluster (a mesma em todos os nós)
sudo passwd hacluster

Digite uma senha forte e repita-a. Em nossos ambientes na JRT Technology Solutions, usamos cofres de senhas e políticas de complexidade, mas para fins didáticos, uma senha como Cluster@2026 é suficiente.

Passo 5: Configurar o firewall

O tráfego do cluster usa os protocolos UDP nas portas 5404 e 5405. Além disso, o PCSD usa a porta TCP 2224. Libere essas portas no firewall de cada nó.

No Ubuntu/Debian com UFW:

# Libera as portas de comunicação do cluster no firewall UFW
sudo ufw allow 2224/tcp
sudo ufw allow 5404/udp
sudo ufw allow 5405/udp

# Recarrega as regras
sudo ufw reload

No RHEL/Rocky com firewalld:

# Libera as portas de comunicação do cluster no firewalld
sudo firewall-cmd --permanent --add-port=2224/tcp
sudo firewall-cmd --permanent --add-port=5404/udp
sudo firewall-cmd --permanent --add-port=5405/udp

# Recarrega as regras
sudo firewall-cmd --reload

Após liberar as portas, valide com sudo ufw status ou sudo firewall-cmd –list-ports. A saída deve incluir as três portas configuradas. Esse passo evita que o cluster fique impossibilitado de comunicar-se, um dos erros mais comuns em implementações de alta disponibilidade.

Passo 6: Autenticar os nós e formar o cluster

Agora, a partir do node01, autentique os dois nós e crie o cluster. O comando pcs host auth autentica o usuário hacluster nos nós especificados via PCSD. Em seguida, o comando pcs cluster setup gera a configuração do Corosync e inicia os serviços.

# Autentica os nós do cluster (execute no node01)
sudo pcs host auth node01 node02 -u hacluster

# Cria o cluster chamado "webcluster" com os dois nós
sudo pcs cluster setup webcluster node01 node02

# Inicia todos os serviços do cluster em todos os nós
sudo pcs cluster start --all

# Habilita os serviços para iniciarem no boot
sudo pcs cluster enable --all

A saída esperada do comando de autenticação deve confirmar a autorização de ambos os nós. Se houver erro de autenticação, revise a senha do usuário hacluster e a conectividade na porta TCP 2224.

node01: Authorized
node02: Authorized

Ao executar pcs cluster setup, o PCS gera automaticamente o arquivo /etc/corosync/corosync.conf. Esse arquivo contém as definições de transporte, quórum e configuração dos nós. Vamos analisar seu conteúdo na próxima seção para entender o que foi criado.

Configuração Detalhada — Arquivo corosync.conf e Parâmetros do Pacemaker

Após a criação do cluster, o arquivo /etc/corosync/corosync.conf é gerado automaticamente pelo PCS. No entanto, compreender cada diretiva é essencial para diagnosticar problemas e personalizar o comportamento do cluster. Em nossos atendimentos na JRT Technology Solutions, sempre auditamos esse arquivo antes de colocar qualquer cluster em produção.

O conteúdo típico gerado para nosso cenário de dois nós é o seguinte:

# Configuração do Corosync gerada pelo PCS para o cluster webcluster
totem {
    version: 2
    cluster_name: webcluster
    secauth: on
    transport: udpu
    token: 3000
    join: 60
}

nodelist {
    node {
        ring0_addr: 192.168.56.101
        name: node01
        nodeid: 1
    }
    node {
        ring0_addr: 192.168.56.102
        name: node02
        nodeid: 2
    }
}

quorum {
    provider: corosync_votequorum
    two_node: 1
    wait_for_all: 0
}

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

Vamos analisar cada seção. No bloco totem, o parâmetro transport: udpu indica comunicação unicast (ponto a ponto), adequada para dois nós sem rede multicast. O token: 3000 define o intervalo máximo em milissegundos para troca de mensagens antes de considerar um nó inativo. Em redes congestionadas, esse valor pode ser aumentado para 5000, mas isso impacta o tempo de detecção de falha.

A lista nodelist define os dois nós com seus endereços IP, nomes e IDs. O bloco quorum é crucial: two_node: 1 habilita o modo especial para dois nós, onde o quórum pode ser mantido por um único nó, mas requer um mecanismo de tie-breaker (como STONITH) para evitar split-brain. Sem two_node, um cluster de dois nós perderia quórum imediatamente quando um deles caísse.

Após configurar o Corosync, o Pacemaker inicia automaticamente e fica pronto para gerenciar recursos. O comando pcs status exibe o estado do cluster. Inicialmente, ele mostrará os dois nós online, mas sem recursos configurados.

Configuração de Recursos — IP Virtual e Serviço Web com Alta disponibilidade

Agora que o cluster está operacional, vamos configurar os recursos que garantirão a alta disponibilidade do serviço web. Em nosso cenário, criaremos dois recursos primitivos: um IP virtual que será o endereço de frontend e o serviço Apache que responderá às requisições. Em seguida, criaremos um group para que ambos rodem sempre no mesmo nó e na ordem correta.

Passo 1: Instalar o Apache em ambos os nós

O serviço protegido precisa estar instalado nos dois nós, mesmo que fique parado em um deles durante a operação normal. A instalação deve ser feita em ambos os servidores.

No Ubuntu/Debian:

# Instala o Apache no Ubuntu/Debian
sudo apt install -y apache2

# Interrompe e desabilita o Apache local, pois o Pacemaker gerenciará o serviço
sudo systemctl stop apache2
sudo systemctl disable apache2

No RHEL/Rocky:

# Instala o Apache no RHEL/Rocky
sudo dnf install -y httpd

# Interrompe e desabilita o Apache local
sudo systemctl stop httpd
sudo systemctl disable httpd

É fundamental desabilitar o serviço no systemd para que ele não inicie sozinho. Se o Apache subir fora do controle do Pacemaker, o cluster poderá entrar em conflito, pois dois processos tentarão usar o mesmo IP virtual. Em nossos projetos na JRT Technology Solutions, sempre deixamos os serviços protegidos sob gestão exclusiva do cluster.

Passo 2: Criar uma página de teste personalizada

Para facilitar a identificação de qual nó está atendendo, crie um arquivo index.html personalizado em cada nó. Isso permitirá visualizar claramente o failover em ação.

No node01:

# Cria uma página HTML que identifica o node01
echo "<h1>Servidor ativo: NODE01</h1>" | sudo tee /var/www/html/index.html

No node02:

# Cria uma página HTML que identifica o node02
echo "<h1>Servidor ativo: NODE02</h1>" | sudo tee /var/www/html/index.html

Passo 3: Criar os recursos no Pacemaker

O Pacemaker gerencia recursos por meio de comandos pcs resource. Primeiro, criamos o recurso de IP virtual usando o agente ocf:heartbeat:IPaddr2, que é altamente confiável e suporta IPv4 e IPv6. O parâmetro ip define o endereço virtual e cidr_netmask a máscara de rede.

# Cria o recurso de IP virtual "virtual_ip" com o agente IPaddr2
sudo pcs resource create virtual_ip ocf:heartbeat:IPaddr2 ip=192.168.56.200 cidr_netmask=24 op monitor interval=10s

# Cria o recurso do serviço web "web_server" com o agente systemd
sudo pcs resource create web_server systemd:apache2 op monitor interval=10s

No RHEL/Rocky, o nome do serviço systemd é httpd, portanto o comando do serviço web deve ser ajustado:

# Para RHEL/Rocky, use httpd no lugar de apache2
sudo pcs resource create web_server systemd:httpd op monitor interval=10s

O parâmetro op monitor interval=10s define que o Pacemaker verificará a saúde do recurso a cada 10 segundos. Esse monitoramento é essencial para a alta disponibilidade, pois permite ao cluster detectar falhas rapidamente e acionar o failover.

Passo 4: Agrupar os recursos e definir ordem e colocação

Para garantir que o IP virtual e o serviço web rodem sempre no mesmo nó e na ordem correta, criamos um group. Grupos simplificam a gestão e evitam estados inconsistentes. O IP virtual deve subir antes do serviço web, pois o Apache precisa associar-se ao endereço virtual.

# Cria um grupo "webgroup" contendo o IP virtual e o serviço web, nesta ordem
sudo pcs resource group add webgroup virtual_ip web_server

Com esse grupo, o Pacemaker automaticamente gerencia a ordem de inicialização e a colocação co-localizada. Se um recurso falhar, todo o grupo é movido para o outro nó. Esse comportamento é o coração da alta disponibilidade em clusters ativo-passivos.

Passo 5: Verificar o estado dos recursos

Após criar os recursos e o grupo, execute pcs status para verificar o estado do cluster. A saída deve mostrar os recursos iniciados e um dos nós como ativo.

Cluster name: webcluster
Status of pacemakerd: 'Pacemaker is running'
Cluster Summary:
  * Stack: corosync
  * Current DC: node01 (version 2.1.2-1ubuntu3) - partition with quorum
  * Last updated: Tue Sep 15 15:20:45 2026
  * Last change:  Tue Sep 15 15:18:30 2026 by root via cibadmin on node01
  * 2 nodes configured
  * 1 resource instance configured

Node List:
  * Online: [ node01 node02 ]

Full List of Resources:
  * Resource Group: webgroup:
    * virtual_ip  (ocf:heartbeat:IPaddr2):  Started node01
    * web_server  (systemd:apache2):        Started node01

Daemon Status:
  corosync: active/disabled
  pacemaker: active/disabled
  pcsd: active/enabled

Observe que ambos os recursos estão Started node01, indicando que o nó 01 é o ativo atual. O nó 02 está online e pronto para assumir em caso de falha. Esse é o estado saudável de um cluster de alta disponibilidade ativo-passivo.

Configuração de STONITH e Quórum Avançado

Até agora, configuramos um cluster funcional, mas sem STONITH. Em um ambiente de produção, essa omissão é um risco grave. O Pacemaker, quando detecta que um nó não responde, precisa ter uma forma de isolá-lo para evitar split-brain. O STONITH fornece exatamente isso: o cluster dispara um agente de fencing que desliga ou reinicia o nó problemático.

Em nosso ambiente educacional, como não temos um dispositivo de fencing real, vamos desabilitar o STONITH para permitir que o cluster funcione. O comando abaixo deve ser executado com plena compreensão das implicações:

# Desabilita o STONITH (apenas para laboratório; em produção, configure um fence device!)
sudo pcs property set stonith-enabled=false

# Verifica a propriedade aplicada
sudo pcs property list | grep stonith

A saída esperada confirma que a propriedade foi aplicada:

stonith-enabled: false

Em nossos projetos na JRT Technology Solutions, configuramos STONITH usando agentes como fence_vmware_soap para ambientes VMware ou fence_ipmilan para servidores físicos com IPMI. Recomendamos fortemente que você implemente fencing em qualquer ambiente que não seja estritamente educacional. Um cluster sem STONITH pode ter comportamento imprevisível em cenários de particionamento de rede.

Outra propriedade importante é o no-quorum-policy. Em clusters com mais de dois nós, essa propriedade define o que fazer quando o quórum é perdido. O valor padrão é stop, que interrompe todos os recursos. Em nosso cenário de dois nós, o modo two_node do Corosync já trata o quórum de forma especial, mas compreender essa propriedade é útil para clusters maiores.

Verificando a Instalação / Testando a Configuração

Agora chegamos ao momento crítico da aula: testar se a alta disponibilidade realmente funciona. Vamos executar uma série de verificações e provocar falhas controladas para observar o comportamento do cluster. Cada teste deve ser realizado com atenção aos tempos de detecção e failover, que geralmente ficam entre 10 e 60 segundos dependendo da configuração.

Teste 1: Verificar o estado geral do cluster

O comando pcs status é o principal instrumento de verificação. Ele mostra o estado dos nós, recursos e propriedades. Execute-o em ambos os nós para confirmar que a visão é consistente.

# Verifica o status completo do cluster
sudo pcs status

# Verifica apenas os recursos
sudo pcs resource status

# Verifica o estado do Corosync
sudo corosync-cfgtool -s

A saída de pcs status já foi mostrada anteriormente e deve indicar todos os recursos iniciados no nó ativo. O comando corosync-cfgtool -s exibe o estado do quórum e da comunicação:

Printing ring status.
Local node ID 1
RING ID 0
	id	= 192.168.56.101
	status	= ring 0 active with no faults

Teste 2: Testar o IP virtual

Confirme que o IP virtual 192.168.56.200 está associado ao nó ativo. O comando ip addr show deve listar o IP na interface correspondente. Em seguida, acesse o serviço web via curl.

# Verifica a associação do IP virtual no nó ativo
ip addr show | grep 192.168.56.200

# Testa o serviço web através do IP virtual
curl http://192.168.56.200

A saída esperada do comando curl deve mostrar a página personalizada do nó ativo, confirmando que o serviço está respondendo pelo IP virtual:

2: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.168.56.101/24 brd 192.168.56.255 scope global noprefixroute enp0s8
    inet 192.168.56.200/24 brd 192.168.56.255 scope global secondary noprefixroute enp0s8
<h1>Servidor ativo: NODE01</h1>

Teste 3: Forçar failover manual (migração de recursos)

Para testar a alta disponibilidade, podemos mover o grupo de recursos do nó ativo para o nó passivo usando o comando pcs resource move. Esse comando adiciona uma constraint temporária de localização que força o recurso a mudar de nó.

# Move o grupo webgroup para o node02
sudo pcs resource move webgroup node02

# Aguarda alguns segundos e verifica o status
sudo pcs status

Após o comando, o cluster deve mover os recursos para o node02. A saída de status confirmará a mudança:

Full List of Resources:
  * Resource Group: webgroup:
    * virtual_ip  (ocf:heartbeat:IPaddr2):  Started node02
    * web_server  (systemd:apache2):        Started node02

Agora, acesse novamente o IP virtual e observe que a página exibida mudou para NODE02, comprovando o failover bem-sucedido.

Teste 4: Simular falha do nó ativo

O teste mais realista é derrubar o nó ativo de forma abrupta. Para isso, execute um reboot ou desligamento forçado no nó que atualmente hospeda os recursos. Em nosso exemplo, o node02 está ativo. Vamos desligá-lo e observar o comportamento do node01.

# No node02, execute um reboot forçado
sudo reboot -f

No node01, monitore o status do cluster em tempo real com watch pcs status. Após alguns segundos, o node01 detectará a falha do node02, assumirá os recursos e o IP virtual passará a responder por ele.

# No node01, monitora o cluster a cada 2 segundos
watch -n 2 sudo pcs status

O resultado esperado é a recuperação automática dos recursos no node01, sem intervenção manual. Esse é o objetivo final de qualquer cluster de alta disponibilidade: garantir continuidade do serviço mesmo diante de falhas catastróficas.

Erros Comuns e Como Resolver

Durante a implementação e operação de clusters de alta disponibilidade, alguns erros são recorrentes. Conhecer esses problemas e suas soluções é essencial para reduzir o tempo de indisponibilidade e evitar dores de cabeça. Em nossa experiência na JRT Technology Solutions, listamos abaixo os quatro erros mais frequentes que encontramos em campo.

• Erro: Falha de autenticação do PCS (“Unable to authenticate to node”)
  Causa: Senha do usuário hacluster divergente entre os nós ou serviço pcsd parado.
  Sintoma: O comando pcs host auth retorna erro de autorização, impedindo a criação do cluster.
  Solução: Execute sudo passwd hacluster em ambos os nós, defina a mesma senha, verifique se o serviço pcsd está ativo (sudo systemctl status pcsd) e se a porta TCP 2224 está liberada no firewall. Em seguida, repita o comando de autenticação.
• Erro: “Cluster is not currently running on this node”
  Causa: O cluster foi configurado, mas os serviços corosync e pacemaker não foram iniciados ou não estão habilitados.
  Sintoma: O comando pcs status informa que o cluster não está em execução, mesmo após o setup.
  Solução: Execute sudo pcs cluster start –all para iniciar os serviços em todos os nós. Se o problema persistir, verifique os logs em /var/log/cluster/corosync.log e certifique-se de que as portas 5404/5405 UDP estão liberadas. Por fim, habilite os serviços com sudo pcs cluster enable –all.
• Erro: Recursos não iniciam e status mostra “unmanaged” ou “blocked”
  Causa: Propriedade is-managed-default definida como false, ou falta de STONITH configurado com stonith-enabled=true, ou dependências não atendidas.
  Sintoma: Os recursos aparecem como Stopped ou Blocked, e o cluster não os inicia apesar de estarem configurados.
  Solução: Verifique com sudo pcs property list se stonith-enabled está false (em laboratório) e se is-managed-default está true. Para recursos Blocked, inspecione com sudo pcs resource debug-start webgroup para identificar a dependência ausente. Se a causa for STONITH, desabilite-o temporariamente com sudo pcs property set stonith-enabled=false apenas em ambiente de teste.
• Erro: Failover não ocorre quando um nó é desligado
  Causa: Quórum perdido e política no-quorum-policy definida como freeze, ou falha de comunicação por bloqueio de portas/firewall.
  Sintoma: O nó sobrevivente não assume os recursos e o serviço fica indisponível, apesar do cluster estar ativo.
  Solução: Para clusters de dois nós, verifique se o parâmetro two_node: 1 está presente no arquivo /etc/corosync/corosync.conf e reinicie o Corosync. Confirme que as portas 5404/5405 UDP estão liberadas. Caso o quórum esteja perdido, ajuste a política com sudo pcs property set no-quorum-policy=ignore apenas para testes, mas lembre-se dos riscos de split-brain.

Boas Práticas e Dicas Avançadas em Alta disponibilidade

Além do funcionamento básico, existem práticas que elevam a maturidade de um cluster de alta disponibilidade. Em nossos projetos na JRT Technology Solutions, seguimos um conjunto de diretrizes que reduzem incidentes e facilitam a manutenção. A primeira delas é sempre configurar STONITH, independentemente do tamanho do ambiente. Mesmo em laboratórios, recomendamos ao menos planejar a implementação de um fence device.

A segunda prática é padronizar a configuração dos nós. Isso inclui versões de pacotes, configurações de rede, fuso horário e até mesmo a ordem das interfaces. Diferenças sutis podem causar comportamentos erráticos difíceis de diagnosticar. Utilizamos ferramentas como Ansible para provisionar e manter a consistência entre os nós, garantindo que qualquer alteração seja replicada de forma controlada.

A terceira prática envolve a monitoração proativa. Um cluster de alta disponibilidade deve ser integrado a plataformas de observabilidade como Zabbix, Prometheus ou Nagios. Configure alertas para eventos de failover, perda de quórum e falhas de recursos. Em nossos atendimentos na JRT Technology Solutions, recomendamos exportar métricas do Pacemaker via pacemaker-exporter para Grafana, criando dashboards que mostram o estado do cluster em tempo real.

Outra dica avançada é o uso de constraints de localização com scores para definir preferências de nós sem bloquear o failover. Por exemplo, você pode configurar o node01 como preferido com score 100 e o node02 com score 50. Assim, em condições normais, o serviço roda no node01, mas em caso de falha, migra para o node02. Use sudo pcs constraint location webgroup prefers node01=100 para implementar essa política.

Por fim, documente todos os procedimentos de recuperação e treine a equipe. Um cluster bem configurado é inútil se ninguém souber operá-lo durante um incidente. Em nossos treinamentos na JRT Technology Solutions, simulamos falhas reais com as equipes de operação para garantir que todos saibam como agir. A alta disponibilidade é uma combinação de tecnologia, processos e pessoas.

Resumo da Aula 29

Nesta aula, você aprendeu os fundamentos e a prática da alta disponibilidade no Linux usando Corosync e Pacemaker. Instalamos e configuramos um cluster de dois nós completo, criamos recursos de IP virtual e serviço web, agrupamos esses recursos e testamos cenários de failover manual e automático. Também discutimos a importância do STONITH, quórum e monitoração, elementos essenciais para um cluster robusto.

Os comandos e conceitos apresentados formam a base para qualquer implementação de alta disponibilidade em ambientes corporativos. A tabela abaixo serve como referência rápida para os comandos mais utilizados no dia a dia:

As melhores práticas incluem sempre configurar STONITH, padronizar os nós, monitorar proativamente e documentar procedimentos. A alta disponibilidade não é um recurso que