Na infraestrutura de TI, chega um momento em que confiar em um único servidor físico — por mais robusto e caro que ele seja — deixa de ser uma opção viável. O hardware falha, discos queimam, placas de rede travam e manutenções exigem reboots. Se o seu sistema não pode parar durante esses eventos, você precisa de um Cluster.
Trabalhar com clusters é elevar o nível do seu datacenter. Vamos desmistificar quando você realmente precisa dessa arquitetura e como instalar o motor de clusterização padrão da indústria (Pacemaker + Corosync) nas principais distribuições Linux.
Quando (e Por Que) Usar um Cluster?
Um cluster nada mais é do que um conjunto de servidores (chamados de "nós" ou nodes) que trabalham juntos como se fossem um único sistema. Na prática do dia a dia de um sysadmin, usamos clusters principalmente para dois cenários:
Alta Disponibilidade (High Availability - HA): O cenário mais clássico. Se o Servidor A (Ativo) sofrer uma falha de hardware ou kernel panic, o Servidor B (Passivo) assume instantaneamente o IP, os serviços e a montagem dos discos. O usuário final mal percebe a queda. Ideal para bases de dados críticas (PostgreSQL, MySQL/Galera) e servidores de arquivos vitais.
Balanceamento de Carga (Load Balancing): Quando o tráfego é muito alto para uma única máquina. O cluster distribui as requisições entre vários nós simultaneamente. Comum em servidores web (fazendas de Nginx/Apache) e microsserviços.
Dica da Trincheira: Não monte um cluster se a aplicação não for crítica. A complexidade do ambiente aumenta drasticamente. Você precisará lidar com conceitos como Split-Brain (quando os nós perdem comunicação entre si e ambos tentam assumir o controle) e STONITH (fencing - a capacidade de um nó "atirar na cabeça" do outro e desligá-lo à força para evitar corrupção de dados).
Procedimento de Instalação (Pacemaker e Corosync)
Para criar um cluster de Alta Disponibilidade padrão no Linux, a dupla dinâmica é o Corosync (que cuida da comunicação e do heartbeat entre os nós) e o Pacemaker (o cérebro que decide onde e como os recursos/serviços vão rodar). Hoje em dia, usamos a ferramenta pcs (Pacemaker Configuration System) para gerenciar tudo de forma mais simples.
Para este laboratório, assumimos que você tem pelo menos dois servidores (node1 e node2) com IPs fixos e que eles conseguem resolver os nomes um do outro via /etc/hosts.
1. Instalação no Ecossistema Red Hat (RHEL, AlmaLinux, Rocky Linux)
Nestas distros, o Pacemaker é amplamente utilizado e muito bem suportado.
# Execute em todos os nós do cluster
sudo dnf install pacemaker corosync pcs -y
# Libere as portas no firewall
sudo firewall-cmd --permanent --add-service=high-availability
sudo firewall-cmd --reload
# Inicie e habilite o serviço PCS
sudo systemctl enable --now pcsd
Ao instalar o pcs, o sistema cria automaticamente um usuário chamado hacluster. Você precisa definir uma senha para ele (use a mesma senha em todos os nós):
sudo passwd hacluster
2. Instalação no Ecossistema Debian / Ubuntu Server
A lógica é a mesma, mudando apenas o gerenciador de pacotes e pequenos detalhes de serviço.
# Execute em todos os nós do cluster
sudo apt update
sudo apt install pacemaker corosync pcs -y
# Inicie e habilite o serviço PCS
sudo systemctl enable --now pcsd
No Debian/Ubuntu, o usuário hacluster também é criado. Defina a senha:
sudo passwd hacluster
Criando e Iniciando o Cluster (Universal)
A partir daqui, os comandos do pcs são iguais para qualquer distribuição. Escolha apenas um dos nós (por exemplo, o node1) e execute os passos abaixo.
Passo 1: Autenticar os nós
Isso fará com que o node1 consiga se comunicar e enviar configurações para o node2.
sudo pcs host auth node1 node2 -u hacluster -p sua_senha_aqui
Passo 2: Criar o Cluster
Vamos criar um cluster chamado cluster_infra contendo os dois nós.
sudo pcs cluster setup cluster_infra node1 node2
Passo 3: Iniciar o Cluster e Habilitar no Boot
sudo pcs cluster start --all
sudo pcs cluster enable --all
Passo 4: Verificar o Status
sudo pcs status
Se tudo correu bem, você verá um painel informando que o cluster está online e ambos os nós estão ativos e prontos para receber recursos.
O Próximo Passo
A partir deste ponto, o motor do cluster está rodando. O próximo passo em um ambiente real seria desativar o STONITH temporariamente (apenas para laboratórios locais: sudo pcs property set stonith-enabled=false), adicionar um IP Virtual (VIP) que flutuará entre os nós, e amarrar serviços como o Apache ou o banco de dados ao cluster.
Gerenciar clusters é uma arte que exige testes rigorosos de falha. A regra de ouro é: puxe o cabo de rede ou desligue o servidor primário de propósito na homologação. Se o cluster não se recuperar sozinho, ele não está pronto para a produção.
Você já teve que "puxar a tomada" para testar se o seu HA estava funcionando? Como foi a experiência?