Agora vou te dar algumas estratégias diferentes para a construção do Cluster. Uma estática, outra baseada em peer discovery. Aí podemos usar K8S, Etcd, Consul ou o próprio EC2.

No post passado

No post passado eu falei sobre a quantidade ideal de nós de um cluster.

Agora é hora de falar sobre quais estratégias estão disponíveis para subir um cluster RabbitMQ.

O RabbitMQ possui 2 formas de formar um cluster.

Você pode usar configurações estáticas, ou dinâmicas com peer discovery.

Configurações estáticas

As configurações estáticas de cluster do RabbitMQ envolvem a definição manual de nós na formação de um cluster. Isso significa que os nós devem ser previamente especificados e não podem ser adicionados ou removidos dinamicamente.

Para configurar um cluster estático, é necessário:

1. Instalar o RabbitMQ em cada nó que fará parte do cluster.
2. Configurar o arquivo de configuração do RabbitMQ (geralmente chamado de rabbitmq.config) em cada nó para especificar os detalhes da formação do cluster, incluindo endereços de nós remotos.
3. Iniciar o RabbitMQ em cada nó e verificar se os nós estão se conectando corretamente.
4. Verificar se o cluster está funcionando corretamente, verificando o status do cluster e testando a comunicação entre nós.

Observe que a configuração estática de cluster é mais adequada para cenários em que o número de nós no cluster é conhecido e não muda com frequência. Para cenários em que o número de nós pode mudar dinamicamente, é melhor considerar a configuração dinâmica de cluster.

Configurações dinâmicas

As configurações dinâmicas de cluster do RabbitMQ permitem que nós sejam adicionados ou removidos dinamicamente, sem a necessidade de reiniciar o cluster ou reconfigurá-lo manualmente.

Para configurar um cluster dinâmico, é necessário:

1. Dependendo do serviço de descoberta a ser usado, subir o serviço ou
2. Instalar o RabbitMQ em cada nó que fará parte do cluster.
3. Configurar o arquivo de configuração do RabbitMQ (geralmente chamado de rabbitmq.config) em cada nó para especificar o modo dinâmico de cluster, incluindo o endereço do service discoverer. E habilitar o plugin correspondente.
4. Iniciar o RabbitMQ em cada nó e verificar se os nós estão se conectando corretamente ao service discoverer.
5. Verificar se o cluster está funcionando corretamente, verificando o status do cluster e testando a comunicação entre nós.

Observe que a configuração dinâmica de cluster é mais adequada para cenários em que o número de nós no cluster pode mudar dinamicamente e é desejável manter o cluster funcionando sem interrupções. Para cenários em que o número de nós é conhecido e não muda com frequência, é melhor considerar a configuração estática de cluster.

Ao usar uma configuração dinâmica, estamos falando de peer discovery, e existem alguns plugins para lidar com isso no RabbitMQ, dependendo do contexto:

• AWS (EC2) | Plugin: rabbitmq_peer_discovery_aws
• Kubernetes | Plugin: rabbitmq_peer_discovery_k8s
• Consul | Plugin: rabbitmq_peer_discovery_consul
• etcd | Plugin: rabbitmq_peer_discovery_etcd

Cada uma das estratégias possui configurações especificas que apontam para algum recurso compartilhado. É acessando esse componente que cada nó se registra e obtém a lista de demais participantes do cluster.

Os links acima apontam para o exato ponto na documentação onde cada um desses temas é abordado.

O fluxo consiste em identificar qual estratégia usar, dependendo, se necessário, subir o serviço (consul, etcd etc) e depois configurar sua instância RabbitMQ para usar o serviço de descoberta.

Eu já subi com Consul e hoje uso os operators do Kubernetes.

Eu já falei deles em outro momento nos posts:

RabbitMQ Operators | Entendendo Kubernetes Operators

RabbitMQ Operators | RabbitMQ Cluster Operator for Kubernetes – Tutorial PT-BR

RabbitMQ Operators | RabbitMQ Messaging Topology Operator for Kubernetes – Tutorial PT-BR

Conclusão

Em qualquer cenário, todos os nós sabem da existência dos demais nós, é assim que o cluster é formado. Ou isso acontece dinamicamente, ou acontece de forma estática.

Próximo Post

Nessa série vamos abordar configurações estáticas, por ser mais simples e por não exigir outros conhecimentos, como Kubernetes, Consul, etcd ou EC2.

Se você quer ver outras estratégias aconselho conheça o Mensageria .NET.