Se você sabe que precisa de um cluster, então é hora de pensar em como desenhar esse projeto.

---

No post 2 dessa série(As 2 métricas vitais para o RabbitMQ), abordamos as métricas que fazem o RabbitMQ cair. Já no post 3 (RabbitMQ consome muita memória e disco?) falamos sobre o consumo de recursos, que está diretamente relacionado às métricas do post 2.

Então, fora isso, o que faz o RabbitMQ cair?

Pane em hardware!

Na verdade, quando o hardware falha, não há o que fazer. Seja com banco de dados SQL, NoSQL, API, quando um servidor tem uma falha grave de hardware, tudo que estiver rodando ali morre.

Isso não difere quando falamos de RabbitMQ.

E em cenários críticos, precisamos estar preparados para isso.

Talvez você nunca tenha projetado um sistema pensando nesse tipo de falha.

É comum atribuirmos quedas ao comportamento humano: enxurrada de acessos, erros de configuração e/ou operação.

É comum não considerarmos que o hardware possa falhar, que um disco possa queimar, que um componente físico como memória ou CPU possam simplesmente fritar.

Não há como, naquele servidor danificado, ser resiliente a esse tipo de acontecimento.

Assim precisamos lidar com a possibilidade de perder um servidor, portanto precisamos de mais servidores, com alguma estratégia de replicação para conseguirmos fazer com que esse tipo de evento não produza perdas para o negócio.

É por isso que projetamos alta disponibilidade ou High availability, ou simplesmente HA.

Existem alguns tipos comuns de soluções de alta disponibilidade.

Cluster

Com um cluster você tem diversos nós cooperando. Eles ajudam na distribuição de carga mas também na falha de algum dos participantes do cluster.

Há algorítimos variados para a formação de clusters, o vendor/fabricante/desenvolvedor decide qual adotar.

O RabbitMQ por exemplo possui clustering e utiliza raft consensus para a gestão do cluster. E novamente usa Raft Consensus para a gestão das Quorum Queues.

Fail Over

Aqui a ideia é ter nós secundários esperando pela falha do principal, na medida que o principal falha, algum desses nós assume a demanda. Bancos de dados costumam usar essa estratégia.

HA e a Cloud

Tudo, ou quase tudo nos principais Cloud Providers, ou tem redundância by default, ou tem a opção de habilitar redundância com um clique.

Ou seja, em um cenário não redundante, basta um clique em uma configuração e pronto, o cloud provider lida com toda a complexidade para você, sem que você precise de conhecimento específico sobre como criar um cluster corretamente, com as configurações adequadas.

Esse é um dos milhares de recursos, que fazem da cloud tão prática e tão fácil.

Mas também tão cara!

Se olharmos com cuidado, considerando os riscos envolvidos em uma perda de dados, ou uma catástrofe muito grande, se considerarmos o nível de cofiabilidade e disponibilidade dos Cloud Providers e o nível de disponibilidade de serviços PaaS oferecidos por ele, conseguimos perceber claramente que no final do dia, é barato!

Entretanto, em contraponto, vejo reclamações e mais reclamações sobre custos de cloud e o que eu considero sobre isso é simplesmente falta de capacidade financeira para lidar com esse custo.

Como projetar para o caos?

O primeiro ponto do planejamento é entender contra qual tipo de evento estamos projetando alta disponibilidade.

Estamos planejando tolerar a falha de um servidor?

Ou esperamos a falha de um datacenter? ou de uma região?

Ou estamos planejando ser tolerantes a uma falha em um cloud provider inteiro?

Primeiro deliberamos e decidimos até que ponto faz sentido ou não tolerar falhas.

A regra é bem simples:

• Se você quer tolerar queda de um servidor, terá de ter mais servidores.
• Se você quer tolerar a queda de um datacenter, terá de ter servidores em mais de um datacenter.
• Se você quer tolerar a queda de uma região inteira do seu cloud provider, terá de ter servidores em mais de uma região.
• Se você quer tolerar a queda de uma cloud inteira, terá de ter servidores em mais de um cloud provider.

Não tem mágica, é simples e complexo quanto isso.

Na sua empresa, no seu projeto, é necessário deliberar e chegar a um consenso sobre até que ponto vocês precisam ou querem ser resilientes, até que ponto vale a pena ser tolerante a uma queda de cloud provider, região, ou datacenter ou servidor.

O mais comum é ser tolerando à quedas de servidores. Mas é importante citar os demais tipos de resiliência até porque eu tenho o interesse de usar esse post para falar de resiliência at all.

HA com RabbitMQ

O RabbitMQ permite a clusterização.

A gestão dos nós utiliza Raft Consensus, enquanto a manutenção das filas clusterizadas as Quorum Queues, também utiliza Raft Consensus.

Se você nunca viu nada sobre o algorítimo, vale a pena visitar https://raft.github.io/.

O exemplo abaixo ilustra visualmente como funciona.

Então quando pensamos em Raft Consensus, temos de considerar a quantidade de nós do nosso cluster.

Abaixo temos a tabela retirada do site do RabbitMQ explicando qual o nível de disponibilidade e tolerância à falhas de acordo om a quantidade de nós.

Cluster node count	Tolerated number of node failures	Tolerant to a network partition
1	0	not applicable
2	0	no
3	1	yes
4	1	yes if a majority exists on one side
5	2	yes
6	2	yes if a majority exists on one side
7	3	yes
8	3	yes if a majority exists on one side
9	4	yes

A partir de 3 nós, a cada ímpar subsequente, você ganha 1 nó de tolerância.

Com 3=1, 5=2, 7=3, 9=4, 11=5, 13=6…

Se levarmos em conta os warning que avisam para não criarmos Quorum Queues em mais de 7 nós, então podemos inferir quem um número entre 3 e 7 é o ideal para a maioria dos cenários.

Levando em conta que números pares entram na zona cinzenta do raft concensus, então a quantidade de nós ideal é sempre impar, entre 3 e 7.

Nos restando 3, 5 ou 7.

Pronto, temos agora um universo bem limitado de possibilidades.

Entre 3, 5 e 7, o que vai diferir para mim é a quantidade de nós indisponíveis que queremos tolerar.