Tolerância a falhas e alta disponibilidade são tópicos importantes, por isso dedicaremos artigos separados ao RabbitMQ e ao Kafka. Este artigo é sobre RabbitMQ, e o próximo é sobre Kafka, em comparação com RabbitMQ. Este é um artigo longo, então fique à vontade.
Vejamos as estratégias de tolerância a falhas, consistência e alta disponibilidade (HA) e as compensações que cada estratégia faz. RabbitMQ pode ser executado em um cluster de nós – e então é classificado como um sistema distribuído. Quando se trata de sistemas distribuídos, falamos frequentemente sobre consistência e disponibilidade.
Esses conceitos descrevem como um sistema se comporta quando falha. Falha na conexão de rede, falha no servidor, falha no disco rígido, indisponibilidade temporária do servidor devido à coleta de lixo, perda de pacotes ou lentidão na conexão de rede. Tudo isso pode levar à perda de dados ou conflitos. Acontece que é virtualmente impossível criar um sistema que seja completamente consistente (sem perda de dados, sem divergência de dados) e disponível (aceite leituras e gravações) para todos os cenários de falha.
Veremos que consistência e disponibilidade estão em extremos opostos do espectro e você precisa escolher qual forma de otimização. A boa notícia é que com o RabbitMQ essa escolha é possível. Você tem esse tipo de alavanca “nerd” para mudar o equilíbrio em direção a uma maior consistência ou maior acessibilidade.
Daremos especial atenção a quais configurações levam à perda de dados devido a registros confirmados. Existe uma cadeia de responsabilidade entre editores, corretores e consumidores. Depois que a mensagem é transmitida ao corretor, é sua função não perdê-la. Quando o corretor confirma o recebimento da mensagem pelo editor, não esperamos que ela seja perdida. Mas veremos que isso pode realmente acontecer dependendo da configuração do seu corretor e editor.
Примитивы устойчивости одного узла
Enfileiramento/Roteamento Resiliente
Existem dois tipos de filas no RabbitMQ: duráveis e não duráveis. Todas as filas são salvas no banco de dados Mnesia. As filas duráveis são anunciadas novamente na inicialização do nó e, portanto, sobrevivem a reinicializações, falhas de sistema ou falhas de servidor (desde que os dados sejam persistidos). Isso significa que, contanto que você declare que o roteamento (troca) e a fila sejam resilientes, a infraestrutura de enfileiramento/roteamento voltará a ficar online.
Filas voláteis e roteamento são removidos quando o nó é reiniciado.
Mensagens persistentes
Só porque uma fila é durável não significa que todas as suas mensagens sobreviverão à reinicialização do nó. Somente mensagens definidas pelo editor como sustentável (persistente). Mensagens persistentes criam carga adicional no intermediário, mas se a perda de mensagens for inaceitável, não há outra opção.
Arroz. 1. Matriz de sustentabilidade
Clustering com espelhamento de fila
Para sobreviver à perda de um corretor, precisamos de redundância. Podemos combinar vários nós RabbitMQ em um cluster e, em seguida, adicionar redundância adicional replicando filas entre vários nós. Dessa forma, se um nó falhar, não perdemos dados e permanecemos disponíveis.
Espelhamento de fila:
- uma fila principal (mestre), que recebe todos os comandos de gravação e leitura
- um ou mais espelhos que recebem todas as mensagens e metadados da fila principal. Esses espelhos não existem para escalabilidade, mas apenas para redundância.
Arroz. 2. Espelhamento de fila
O espelhamento é definido pela política apropriada. Nele você pode selecionar o coeficiente de replicação e até mesmo os nós nos quais a fila deve estar localizada. Exemplos:
ha-mode: allha-mode: exactly, ha-params: 2(um mestre e um espelho)ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2
Confirmação do editor
Para obter uma gravação consistente, são necessárias confirmações do editor. Sem eles, existe o risco de perda de mensagens. Uma confirmação é enviada ao editor depois que a mensagem é gravada no disco. RabbitMQ grava mensagens no disco não após o recebimento, mas periodicamente, na região de várias centenas de milissegundos. Quando uma fila é espelhada, uma confirmação é enviada somente após todos os espelhos também terem gravado sua cópia da mensagem no disco. Isso significa que o uso de confirmações adiciona latência, mas se a segurança dos dados for importante, elas serão necessárias.
Fila de failover
Quando um intermediário é encerrado ou travado, todos os líderes de fila (mestres) naquele nó travam junto com ele. O cluster então seleciona o espelho mais antigo de cada mestre e o promove como o novo mestre.
Arroz. 3. Múltiplas filas espelhadas e suas políticas
O corretor 3 cai. Observe que o espelho da Fila C no Broker 2 está sendo promovido para mestre. Observe também que um novo espelho foi criado para a Fila C no Broker 1. RabbitMQ sempre tenta manter o fator de replicação especificado em suas políticas.
Arroz. 4. O corretor 3 falha, causando falha na fila C
O próximo Corretor 1 cai! Só nos resta um corretor. O espelho da Fila B é promovido a mestre.
Fig. 5
Devolvemos o Broker 1. Independentemente de quão bem os dados sobrevivem à perda e recuperação do broker, todas as mensagens da fila espelhada são descartadas na reinicialização. É importante observar isso porque haverá consequências. Veremos essas implicações em breve. Portanto, o Broker 1 agora é membro do cluster novamente e o cluster tenta cumprir as políticas e, portanto, cria espelhos no Broker 1.
Nesse caso, a perda do Corretor 1 foi completa, assim como os dados, portanto a Fila B não espelhada foi completamente perdida.
Arroz. 6. Corretora 1 retorna ao serviço
O Broker 3 está online novamente, então as filas A e B recuperam os espelhos criados nele para satisfazer suas políticas de HA. Mas agora todas as filas principais estão em um nó! Isto não é o ideal, uma distribuição uniforme entre os nós é melhor. Infelizmente, não há muitas opções aqui para reequilibrar os mestres. Voltaremos a esse problema mais tarde porque precisamos examinar primeiro a sincronização de filas.
Arroz. 7. O corretor 3 retorna ao serviço. Todas as filas principais em um nó!
Então agora você deve ter uma ideia de como os espelhos fornecem redundância e tolerância a falhas. Isso garante a disponibilidade no caso de falha de um único nó e protege contra perda de dados. Mas ainda não terminamos, porque na realidade é muito mais complicado.
sincronização
Ao criar um novo espelho, todas as novas mensagens serão sempre replicadas para este espelho e quaisquer outros. Quanto aos dados existentes na fila master, podemos replicá-los para um novo espelho, que se torna uma cópia completa do master. Também podemos optar por não replicar as mensagens existentes e deixar a fila principal e o novo espelho convergirem no tempo, com as novas mensagens chegando no final e as mensagens existentes saindo do início da fila principal.
Essa sincronização é executada automática ou manualmente e gerenciada por meio de uma política de fila. Vejamos um exemplo.
Temos duas filas espelhadas. A fila A é sincronizada automaticamente e a fila B é sincronizada manualmente. Ambas as filas contêm dez mensagens.
Arroz. 8. Duas filas com diferentes modos de sincronização
Agora estamos perdendo o Corretor 3.
Arroz. 9. Corretora 3 caiu
O corretor 3 retorna ao serviço. O cluster cria um espelho para cada fila no novo nó e sincroniza automaticamente a nova Fila A com o mestre. Porém, o espelho da nova Fila B permanece vazio. Dessa forma, temos redundância total na Fila A e apenas um espelho para as mensagens existentes da Fila B.
Arroz. 10. O novo espelho da Fila A recebe todas as mensagens existentes, mas o novo espelho da Fila B não.
Mais dez mensagens chegam em ambas as filas. O Broker 2 então trava e a Fila A reverte para o espelho mais antigo, que está no Broker 1. Não há perda de dados quando ela falha. Na Fila B, há vinte mensagens no mestre e apenas dez no espelho porque esta fila nunca replicou as dez mensagens originais.
Arroz. 11. A fila A reverte para o Broker 1 sem perder mensagens
Mais dez mensagens chegam em ambas as filas. Agora trava o Broker 1. A fila A alterna facilmente para o espelho sem perder mensagens. No entanto, a fila B está tendo problemas. Neste ponto, podemos otimizar a disponibilidade ou a consistência.
Se quisermos optimizar a acessibilidade, então a política ha-promover-em-falha deverá ser instalado em sempre. Este é o valor padrão, portanto você simplesmente não pode especificar a política. Neste caso, estamos essencialmente permitindo falhas em espelhos não sincronizados. Isso fará com que as mensagens sejam perdidas, mas a fila permanecerá legível e gravável.
Arroz. 12. A fila A é revertida para o Broker 3 sem perder mensagens. A fila B reverte para o Broker 3 com dez mensagens perdidas
Também podemos instalar ha-promote-on-failure em significado when-synced. Nesse caso, em vez de reverter para o espelho, a fila aguardará até que o Broker 1 com seus dados retorne ao modo online. Após retornar, a fila principal volta ao Broker 1 sem qualquer perda de dados. A disponibilidade é sacrificada pela segurança dos dados. Mas este é um modo arriscado que pode até levar à perda total de dados, que veremos em breve.
Arroz. 13. A fila B permanece indisponível após perder o Corretor 1
Você pode perguntar: “É melhor nunca usar a sincronização automática?” A resposta é que a sincronização é uma operação de bloqueio. Durante a sincronização, a fila principal não pode realizar nenhuma operação de leitura ou gravação!
Vejamos um exemplo. Agora temos filas muito longas. Como eles podem crescer até esse tamanho? Por várias razões:
- As filas não são usadas ativamente
- São filas de alta velocidade e, no momento, os consumidores estão lentos
- São filas de alta velocidade, houve uma falha e os consumidores estão se atualizando
Arroz. 14. Duas filas grandes com diferentes modos de sincronização
Agora o Corretor 3 cai.
Arroz. 15. O corretor 3 cai, deixando um mestre e um espelho em cada fila
O Broker 3 volta a ficar online e novos espelhos são criados. A Fila Principal A começa a replicar mensagens existentes para o novo espelho e, durante esse período, a Fila fica indisponível. Demora duas horas para replicar os dados, resultando em duas horas de inatividade para esta fila!
Porém, a Fila B permanece disponível durante todo o período. Ela sacrificou alguma redundância pela acessibilidade.
Arroz. 16. A fila permanece indisponível durante a sincronização
Após duas horas, a Fila A também fica disponível e pode começar a aceitar leituras e gravações novamente.
Atualizações
Esse comportamento de bloqueio durante a sincronização dificulta a atualização de clusters com filas muito grandes. Em algum momento, o nó mestre precisa ser reiniciado, o que significa mudar para um espelho ou desabilitar a fila enquanto o servidor está sendo atualizado. Se optarmos pela transição, perderemos mensagens se os espelhos não estiverem sincronizados. Por padrão, durante uma interrupção do broker, um failover para um espelho não sincronizado não é executado. Isso significa que assim que a corretora retornar não perderemos nenhuma mensagem, o único prejuízo foi uma simples fila. As regras de comportamento quando um corretor está desconectado são definidas pela política ha-promote-on-shutdown. Você pode definir um de dois valores:
always= a transição para espelhos não sincronizados está habilitadawhen-synced= transição apenas para um espelho sincronizado, caso contrário a fila se tornará ilegível e não gravável. A fila retorna ao serviço assim que o corretor retorna
De uma forma ou de outra, com filas grandes você tem que escolher entre perda de dados e indisponibilidade.
Quando a disponibilidade melhora a segurança dos dados
Há mais uma complicação a considerar antes de tomar uma decisão. Embora a sincronização automática seja melhor para redundância, como ela afeta a segurança dos dados? É claro que, com melhor redundância, o RabbitMQ tem menos probabilidade de perder mensagens existentes, mas e as novas mensagens dos editores?
Aqui você precisa considerar o seguinte:
- O editor poderia simplesmente retornar um erro e fazer com que o serviço ou usuário upstream tentasse novamente mais tarde?
- O editor pode salvar a mensagem localmente ou em um banco de dados para tentar novamente mais tarde?
Se o editor puder apenas descartar a mensagem, então, na verdade, melhorar a acessibilidade também melhora a segurança dos dados.
Assim, deve-se buscar um equilíbrio, e a solução depende da situação específica.
Problemas com ha-promote-on-failure=when-synced
Idéia ha-promover-em-falha= quando sincronizado é que evitamos a mudança para um espelho não sincronizado e, assim, evitamos a perda de dados. A fila permanece ilegível ou gravável. Em vez disso, tentamos recuperar o corretor travado com seus dados intactos para que ele possa voltar a funcionar como mestre sem perda de dados.
Mas (e este é um grande mas) se o corretor perdeu seus dados, então temos um grande problema: a fila está perdida! Todos os dados desapareceram! Mesmo se você tiver espelhos que acompanham a fila principal, esses espelhos também serão descartados.
Para adicionar novamente um nó com o mesmo nome, dizemos ao cluster para esquecer o nó perdido (com o comando coelhomqctl esqueça_cluster_node) e inicie um novo corretor com o mesmo nome de host. Embora o cluster se lembre do nó perdido, ele se lembra da fila antiga e dos espelhos não sincronizados. Quando um cluster é instruído a esquecer um nó órfão, essa fila também é esquecida. Agora precisamos declará-lo novamente. Perdemos todos os dados, embora tivéssemos espelhos com um conjunto parcial de dados. Seria melhor mudar para um espelho não sincronizado!
Portanto, a sincronização manual (e falha na sincronização) em combinação com ha-promote-on-failure=when-synced, na minha opinião, bastante arriscado. Os documentos dizem que esta opção existe para segurança de dados, mas é uma faca de dois gumes.
Reequilíbrio mestre
Conforme prometido, voltamos ao problema do acúmulo de todos os mestres em um ou vários nós. Isso pode até acontecer como resultado de uma atualização contínua do cluster. Em um cluster de três nós, todas as filas principais serão acumuladas em um ou dois nós.
O rebalanceamento dos mestres pode ser problemático por dois motivos:
- Não existem boas ferramentas para realizar o reequilíbrio
- Sincronização de fila
Existe um terceiro para reequilíbrio , que não é oficialmente suportado. Em relação a plugins de terceiros no manual do RabbitMQ : “O plugin fornece algumas ferramentas adicionais de configuração e relatórios, mas não é suportado ou verificado pela equipe RabbitMQ. Use por sua conta e risco."
Existe outro truque para mover a fila principal por meio de políticas de HA. O manual menciona por esta. Funciona assim:
- Remove todos os espelhos usando uma política temporária que tem prioridade mais alta que a política de HA existente.
- Altera a política temporária de HA para usar o modo de nó, especificando o nó para o qual a fila mestre deve ser transferida.
- Sincroniza a fila para migração push.
- Após a conclusão da migração, exclui a política temporária. A política inicial de HA entra em vigor e o número necessário de espelhos é criado.
A desvantagem é que essa abordagem pode não funcionar se você tiver filas grandes ou requisitos rígidos de redundância.
Agora vamos ver como os clusters RabbitMQ funcionam com partições de rede.
Perda de conectividade
Os nós de um sistema distribuído são conectados por links de rede, e os links de rede podem e serão desconectados. A frequência das interrupções depende da infraestrutura local ou da confiabilidade da nuvem selecionada. De qualquer forma, os sistemas distribuídos devem ser capazes de lidar com eles. Mais uma vez temos a escolha entre disponibilidade e consistência, e novamente a boa notícia é que o RabbitMQ oferece as duas opções (mas não ao mesmo tempo).
Com RabbitMQ temos duas opções principais:
- Permitir divisão lógica (cérebro dividido). Isso garante a disponibilidade, mas pode causar perda de dados.
- Desative a separação lógica. Pode resultar em perda de disponibilidade a curto prazo, dependendo de como os clientes se conectam ao cluster. Também pode levar à indisponibilidade total em um cluster de dois nós.
Mas o que é separação lógica? É quando um cluster se divide em dois devido à perda de conexões de rede. De cada lado, os espelhos são promovidos a mestre, de modo que eventualmente haja vários mestres por turno.
Arroz. 17. Fila principal e dois espelhos, cada um em um nó separado. Então ocorre uma falha na rede e um espelho é desconectado. O nó separado vê que os outros dois caíram e promove seus espelhos ao mestre. Agora temos duas filas principais, ambas graváveis e legíveis.
Se os editores enviarem dados para ambos os mestres, teremos duas cópias divergentes da fila.
Os diferentes modos do RabbitMQ fornecem disponibilidade ou consistência.
Modo ignorar (padrão)
Este modo garante acessibilidade. Após a perda de conectividade, ocorre uma separação lógica. Depois que a conectividade for restaurada, o administrador deverá decidir a qual partição dar prioridade. O lado perdedor será reiniciado e todos os dados acumulados nesse lado serão perdidos.
Arroz. 18. Três editoras estão associadas a três corretores. Internamente, o cluster roteia todas as solicitações para a fila principal no Broker 2.
Agora estamos perdendo o Corretor 3. Ele vê que outros corretores caíram e promove seu espelho ao mestre. É assim que ocorre uma separação lógica.
Arroz. 19. Divisão lógica (cérebro dividido). Os registros vão para duas filas principais e as duas cópias divergem.
A conectividade é restaurada, mas a separação lógica permanece. O administrador deve selecionar manualmente o lado perdedor. No caso abaixo, o administrador reinicia o Broker 3. Todas as mensagens que ele não conseguiu transmitir são perdidas.
Arroz. 20. O administrador desativa o Broker 3.
Arroz. 21. O administrador inicia o Broker 3 e ele se junta ao cluster, perdendo todas as mensagens que ali foram deixadas.
Durante a perda de conectividade e após sua restauração, o cluster e esta fila ficaram disponíveis para leitura e gravação.
Modo de recuperação automática
Funciona de forma semelhante ao modo Ignorar, exceto que o próprio cluster escolhe automaticamente o lado perdedor após dividir e restaurar a conectividade. O lado perdedor retorna vazio para o cluster e a fila perde todas as mensagens que foram enviadas apenas para aquele lado.
Pausar modo minoritário
Se não quisermos permitir o particionamento lógico, nossa única opção é descartar leituras e gravações no lado menor após a partição do cluster. Quando o corretor vê que está no lado menor, ele suspende o trabalho, ou seja, fecha todas as conexões existentes e recusa as novas. Uma vez por segundo, ele verifica a restauração da conectividade. Assim que a conectividade for restaurada, ele retoma a operação e ingressa no cluster.
Arroz. 22. Três editoras estão associadas a três corretores. Internamente, o cluster roteia todas as solicitações para a fila principal no Broker 2.
Os corretores 1 e 2 então se separam do corretor 3. Em vez de promover seu espelho para mestre, o corretor 3 é suspenso e fica indisponível.
Arroz. 23. O Broker 3 faz uma pausa, desconecta todos os clientes e rejeita solicitações de conexão.
Depois que a conectividade for restaurada, ela retornará ao cluster.
Vejamos outro exemplo onde a fila principal está no Broker 3.
Arroz. 24. Fila principal na Corretora 3.
Então ocorre a mesma perda de conectividade. O corretor 3 faz uma pausa porque está no lado menor. Por outro lado, os nós veem que o Broker 3 caiu, então o espelho mais antigo dos Brokers 1 e 2 é promovido a mestre.
Arroz. 25. Transição para o Corretor 2 se o Corretor 3 não estiver disponível.
Quando a conectividade for restaurada, o Broker 3 ingressará no cluster.
Arroz. 26. O cluster voltou à operação normal.
O importante a entender aqui é que conseguimos consistência, mas também podemos obter disponibilidade, se Transferiremos clientes com sucesso para a maior parte da seção. Para a maioria das situações, eu pessoalmente escolheria o modo Pause Minority, mas isso realmente depende de cada caso individual.
Para garantir a disponibilidade, é importante garantir que os clientes se conectem com êxito ao host. Vejamos nossas opções.
Garantindo a conectividade do cliente
Temos várias opções de como direcionar os clientes para a parte principal do cluster ou para nós de trabalho (após a falha de um nó) após uma perda de conectividade. Primeiro, vamos lembrar que uma fila específica está hospedada em um nó específico, mas o roteamento e as políticas são replicados em todos os nós. Os clientes podem se conectar a qualquer nó e o roteamento interno os direcionará para onde precisam ir. Mas quando um nó é suspenso, ele rejeita conexões, então os clientes devem se conectar a outro nó. Se o nó cair, há pouco que ele possa fazer.
Nossas opções:
- O cluster é acessado usando um balanceador de carga que simplesmente percorre os nós e os clientes tentam se conectar novamente até obter sucesso. Se um nó estiver inativo ou suspenso, as tentativas de conexão com esse nó falharão, mas as tentativas subsequentes irão para outros servidores (em um estilo round-robin). Isso é adequado para uma perda de conectividade de curto prazo ou um servidor inativo que será rapidamente reativado.
- Acesse o cluster por meio de um balanceador de carga e remova nós suspensos/com falha da lista assim que forem detectados. Se fizermos isso rapidamente e se os clientes conseguirem tentar novamente a conexão, alcançaremos disponibilidade constante.
- Dê a cada cliente uma lista de todos os nós e o cliente selecionará aleatoriamente um deles ao se conectar. Se receber um erro ao tentar se conectar, ele passará para o próximo nó da lista até se conectar.
- Remova o tráfego de um nó com falha/suspenso usando DNS. Isso é feito usando um pequeno TTL.
Descobertas
O clustering RabbitMQ tem suas vantagens e desvantagens. As desvantagens mais sérias são:
- ao ingressar em um cluster, os nós descartam seus dados;
- bloquear a sincronização faz com que a fila fique indisponível.
Todas as decisões difíceis decorrem dessas duas características arquitetônicas. Se o RabbitMQ pudesse salvar dados quando o cluster fosse reingressado, a sincronização seria mais rápida. Se fosse capaz de sincronização sem bloqueio, suportaria melhor filas grandes. A correção desses dois problemas melhoraria muito o desempenho do RabbitMQ como uma tecnologia de mensagens altamente disponível e tolerante a falhas. Eu hesitaria em recomendar RabbitMQ com clustering nas seguintes situações:
- Rede não confiável.
- Armazenamento não confiável.
- Filas muito longas.
Quando se trata de configurações de alta disponibilidade, considere o seguinte:
ha-promote-on-failure=alwaysha-sync-mode=manualcluster_partition_handling=ignore(ouautoheal)- mensagens persistentes
- garantir que os clientes se conectem ao nó ativo quando algum nó falhar
Para consistência (segurança de dados), considere as seguintes configurações:
- Confirmações do editor e reconhecimentos manuais do lado do consumidor
ha-promote-on-failure=when-synced, se os editores puderem tentar novamente mais tarde e se você tiver um armazenamento muito confiável! Caso contrário, coloque=always.ha-sync-mode=automatic(mas para grandes filas inativas o modo manual pode ser necessário; considere também se a indisponibilidade causará a perda de mensagens)- Pausar modo Minoritário
- mensagens persistentes
Ainda não cobrimos todas as questões de tolerância a falhas e alta disponibilidade; por exemplo, como executar procedimentos administrativos com segurança (como atualizações contínuas). Também precisamos falar sobre federação e o plugin Shovel.
Se eu perdi mais alguma coisa, por favor me avise.
Veja também meu , onde faço uma destruição em um cluster RabbitMQ usando Docker e Blockade para testar alguns dos cenários de perda de mensagens descritos neste artigo.
Artigos anteriores da série:
Nº 1 -
Nº 2 -
Nº 3 -
Fonte: habr.com