Guia Passo a Passo para Implantar um Cluster Ativo-Passivo RabbitMQ

A alta disponibilidade do RabbitMQ precisa de mais do que dois servidores que podem se ver. Você precisa de clustering para metadados compartilhados, filas replicadas para disponibilidade de mensagens e um caminho de failover claro para os clientes.

Este guia mostra o lado RabbitMQ de uma implantação no estilo ativo-passivo. O failover do cliente geralmente vem de um balanceador de carga, mudança de DNS, descoberta de serviço ou um IP virtual gerenciado fora do RabbitMQ.

Pré-requisitos para um Cluster Ativo-Passivo

Antes de iniciar a configuração, garanta que os seguintes pré-requisitos sejam atendidos em todos os nós do cluster pretendidos (Nó A - Ativo, Nó B - Passivo):

Versões de Software Compatíveis: Mantenha as versões do RabbitMQ Server e Erlang/OTP alinhadas entre os nós. Na prática, execute a mesma versão do RabbitMQ em cada nó, a menos que você esteja seguindo o caminho de atualização contínua documentado do RabbitMQ.
Acessibilidade de Rede: Os nós devem se comunicar pelas portas AMQP usadas pelos clientes, a porta de distribuição usada para clustering e quaisquer portas de gerenciamento ou TLS que você habilitar.
Resolução de Host: Configure o arquivo /etc/hosts (ou DNS) em todos os nós para que cada nó possa resolver o nome do host de todos os outros nós de forma confiável.
Consistência do Cookie: O 'cookie mágico' Erlang deve ser idêntico em todos os nós. Isso é crucial para que os nós confiem uns nos outros para clustering.

Estabelecendo Consistência do Cookie

O cookie Erlang determina se os nós podem se comunicar com segurança. Ele deve ser copiado do primeiro nó inicializado para todos os outros.

No Nó A (O primeiro nó):

Localize o arquivo de cookie (geralmente /var/lib/rabbitmq/.erlang.cookie ou ~/.erlang.cookie dependendo do método de instalação) e copie seu conteúdo.

No Nó B (e nós subsequentes):

Pare o serviço RabbitMQ:
```
sudo systemctl stop rabbitmq-server
```

Substitua o arquivo de cookie existente pelo conteúdo copiado do Nó A, garantindo as permissões corretas (geralmente 400).

# Exemplo usando echo (substitua o conteúdo conforme necessário)
echo "SUA_LONGA_STRING_DE_COOKIE" | sudo tee /var/lib/rabbitmq/.erlang.cookie
sudo chmod 400 /var/lib/rabbitmq/.erlang.cookie

Inicie o serviço no Nó B:
```
sudo systemctl start rabbitmq-server
```

Passo 1: Configurando Nomes de Host e Rede

Garanta que os arquivos de host tanto no Nó A quanto no Nó B mapeiem corretamente seus nomes de host.

Exemplo /etc/hosts (em ambos os servidores):

192.168.1.10   rabbitmq-node-a
192.168.1.11   rabbitmq-node-b

Passo 2: Inicializando o Primeiro Nó do Cluster (Ativo)

O Nó A será o nó primário inicial, onde o cluster é estabelecido pela primeira vez.

Inicie o serviço no Nó A (se ainda não estiver em execução):
```
sudo systemctl start rabbitmq-server
```
Verifique o Status: Garanta que o nó esteja funcionando corretamente.
```
rabbitmqctl status
```

Passo 3: Juntando o Segundo Nó (Passivo) ao Cluster

Agora, instruímos o Nó B a se juntar ao cluster liderado pelo Nó A.

Pare a aplicação RabbitMQ no Nó B enquanto mantém o nó Erlang disponível:
```
sudo rabbitmqctl stop_app
```
Redefina o estado local do Nó B se ele já foi inicializado como um nó independente:
```
sudo rabbitmqctl reset
```
Comando de Junção: Execute o comando de junção no Nó B, especificando o nome do host do Nó A como o par.
```
sudo rabbitmqctl join_cluster rabbit@rabbitmq-node-a
```
Dica: Use o nome do host definido em /etc/hosts.
Inicie a aplicação RabbitMQ no Nó B:
```
sudo rabbitmqctl start_app
```

Passo 4: Verificando a Formação do Cluster

Faça login no Nó A e verifique se ambos os nós se reconhecem.

rabbitmqctl cluster_status

Trecho de Saída Esperada:

Você deve ver tanto rabbitmq-node-a quanto rabbitmq-node-b listados em running_nodes.

Cluster status of node rabbit@rabbitmq-node-a ...
[{nodes,[{disc,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]}]},
 {running_nodes,[rabbit@rabbitmq-node-a,rabbit@rabbitmq-node-b]},
 ...
]

Passo 5: Configurando Alta Disponibilidade para Filas

O clustering padrão do RabbitMQ compartilha metadados como usuários, exchanges, bindings e políticas. O conteúdo das filas precisa de um tipo de fila replicada se você quiser que as mensagens sobrevivam à falha do nó.

Para implantações modernas do RabbitMQ, use filas de quorum para filas duráveis replicadas. Filas espelhadas clássicas usavam políticas ha-mode em versões mais antigas do RabbitMQ, mas essa abordagem está obsoleta e removida das versões principais mais recentes.

Declare uma Fila de Quorum

Você pode declarar filas de quorum a partir da sua aplicação ou com rabbitmqadmin. Este exemplo cria uma fila de quorum durável:

rabbitmqadmin declare queue name=orders durable=true arguments='{"x-queue-type":"quorum"}'

Para laboratórios de dois nós, uma fila de quorum pode funcionar, mas não pode tolerar a perda de um nó e ainda manter uma maioria. Para produção, use pelo menos três nós RabbitMQ para filas de quorum, para que um nó possa falhar enquanto a fila ainda tem uma maioria.

Passo 6: Teste de Failover

Antes de considerar o cluster pronto, teste o caminho que seus clientes usarão:

Publique algumas mensagens de teste persistentes em uma fila de quorum.
Pare a aplicação RabbitMQ do nó ativo com sudo rabbitmqctl stop_app.
Confirme que os clientes se reconectam através do seu balanceador de carga, alvo DNS ou configuração de descoberta de serviço.
Consuma as mensagens de teste do nó sobrevivente.
Inicie a aplicação parada novamente com sudo rabbitmqctl start_app e verifique rabbitmqctl cluster_status.

Conclusão Final

O clustering RabbitMQ fornece metadados de broker compartilhados, mas a disponibilidade da fila depende do tipo de fila e do design de failover do cliente. Use filas de quorum para filas duráveis replicadas, mantenha pelo menos três nós para tolerância a falhas real e teste o failover com o mesmo caminho de conexão que suas aplicações usam.