A tolerancia a fallos e a alta dispoñibilidade son temas importantes, polo que dedicaremos artigos separados a RabbitMQ e Kafka. Este artigo trata sobre RabbitMQ, e o seguinte trata sobre Kafka, en comparación con RabbitMQ. Este é un artigo longo, así que ponte cómodo.
Vexamos as estratexias de tolerancia a fallos, coherencia e alta dispoñibilidade (HA) e as compensacións que fai cada estratexia. RabbitMQ pode executarse nun clúster de nós e despois clasifícase como un sistema distribuído. Cando se trata de sistemas distribuídos, adoitamos falar de coherencia e dispoñibilidade.
Estes conceptos describen como se comporta un sistema cando falla. Fallo de conexión á rede, fallo do servidor, fallo do disco duro, indisponibilidade temporal do servidor debido á recollida de lixo, perda de paquetes ou ralentización da conexión de rede. Todo isto pode levar á perda de datos ou a conflitos. Resulta que é practicamente imposible poñer en marcha un sistema que sexa totalmente consistente (sen perda de datos, sen diverxencia de datos) e dispoñible (aceptará lecturas e escrituras) para todos os escenarios de fallo.
Veremos que a coherencia e a dispoñibilidade están nos extremos opostos do espectro e cómpre escoller o xeito de optimizar. A boa noticia é que con RabbitMQ esta elección é posible. Tes este tipo de pancas "nerdy" para cambiar a balanza cara a unha maior coherencia ou unha maior accesibilidade.
Prestaremos especial atención ás configuracións que provocan a perda de datos debido aos rexistros confirmados. Existe unha cadea de responsabilidade entre editores, corredores e consumidores. Unha vez que a mensaxe se transmite ao corredor, o seu traballo é non perder a mensaxe. Cando o corredor confirma a recepción da mensaxe por parte do editor, non esperamos que se perda. Pero veremos que isto pode ocorrer dependendo da configuración do teu corredor e editor.
Primitivas de resiliencia de nodo único
Enrutamento/colas resistentes
Hai dous tipos de colas en RabbitMQ: duradeiras e non duradeiras. Todas as filas gárdanse na base de datos de Mnesia. As colas duradeiras volven anunciarse no inicio do nodo e, polo tanto, sobreviven aos reinicios, fallos do sistema ou fallos do servidor (sempre que se conserven os datos). Isto significa que, mentres declares que o enrutamento (intercambio) e a cola son resistentes, a infraestrutura de encamiñamento/enrutamento volverá estar en liña.
As colas e o enrutamento volátiles elimínanse cando se reinicia o nodo.
Mensaxes persistentes
Só porque unha cola sexa duradeira non significa que todas as súas mensaxes sobrevivirán a un reinicio do nodo. Só as mensaxes definidas polo editor como resistente (persistente). As mensaxes persistentes crean carga adicional no corredor, pero se a perda de mensaxes é inaceptable, non hai outra opción.
Arroz. 1. Matriz de sustentabilidade
Agrupación con réplica de filas
Para sobrevivir á perda dun corredor, necesitamos a redundancia. Podemos combinar varios nodos RabbitMQ nun clúster e, a continuación, engadir redundancia adicional replicando colas entre varios nodos. Deste xeito, se un nodo falla, non perdemos datos e permanecemos dispoñibles.
Espello da cola:
- unha cola principal (mestra), que recibe todos os comandos de escritura e lectura
- un ou máis espellos que reciben todas as mensaxes e metadatos da cola principal. Estes espellos non están aí para escalar, senón simplemente para redundancia.
Arroz. 2. Replicación de filas
A duplicación está establecida pola política adecuada. Nel pódese seleccionar o coeficiente de replicación e mesmo os nodos nos que se debe situar a cola. Exemplos:
ha-mode: allha-mode: exactly, ha-params: 2(un mestre e un espello)ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2
Confirmación do editor
Para conseguir unha gravación coherente, é necesaria a confirmación do editor. Sen eles, existe o risco de que se perdan as mensaxes. Envíase unha confirmación ao editor despois de escribir a mensaxe no disco. RabbitMQ escribe mensaxes no disco non despois da recepción, senón de forma periódica, na rexión de varios centos de milisegundos. Cando se duplica unha cola, só se envía un acuse de recibo despois de que todos os espellos tamén escribiron a súa copia da mensaxe no disco. Isto significa que o uso de confirmacións engade latencia, pero se a seguridade dos datos é importante, entón son necesarias.
Fila de failover
Cando un corredor sae ou falla, todos os líderes da cola (masters) dese nodo colapsan xunto con el. A continuación, o clúster selecciona o espello máis antigo de cada mestre e promóveo como novo mestre.
Arroz. 3. Múltiples colas reflectidas e as súas políticas
O corredor 3 cae. Teña en conta que o espello da cola C en Broker 2 está a ser promovido a mestre. Teña en conta tamén que se creou unha nova réplica para a cola C no intermediario 1. RabbitMQ sempre tenta manter o factor de replicación especificado nas súas políticas.
Arroz. 4. O corredor 3 falla, o que fai que a cola C falle
O próximo Broker 1 cae! Só nos queda un corredor. O espello da cola B ascende a mestre.
Fig 5
Devolvemos o corredor 1. Independentemente de que tan ben sobrevivan os datos á perda e recuperación do corredor, todas as mensaxes de cola reflectidas descartanse ao reiniciar. Isto é importante ter en conta porque haberá consecuencias. En breve veremos estas implicacións. Polo tanto, Broker 1 volve ser membro do clúster e o clúster tenta cumprir coas políticas e, polo tanto, crea réplicas no Broker 1.
Neste caso, a perda de Broker 1 foi completa, do mesmo xeito que os datos, polo que a cola B sen espellar perdeuse por completo.
Arroz. 6. O corredor 1 volve ao servizo
O corredor 3 está de novo en liña, polo que as filas A e B recuperan os espellos creados nel para satisfacer as súas políticas de alta disponibilidad. Pero agora todas as filas principais están nun nodo! Isto non é ideal, é mellor unha distribución uniforme entre nós. Desafortunadamente, aquí non hai moitas opcións para reequilibrar os mestres. Volveremos sobre este problema máis tarde porque primeiro debemos analizar a sincronización da fila.
Arroz. 7. O corredor 3 volve ao servizo. Todas as colas principais nun só nodo!
Entón, agora deberías ter unha idea de como os espellos proporcionan redundancia e tolerancia a fallos. Isto garante a dispoñibilidade en caso de fallo dun só nodo e protexe contra a perda de datos. Pero aínda non rematamos, porque en realidade todo é moito máis complicado.
Sincronización
Ao crear un novo espello, todas as mensaxes novas sempre se replicarán neste espello e en calquera outro. En canto aos datos existentes na cola mestra, podemos replicalos nun novo espello, que se converte nunha copia completa do mestre. Tamén podemos optar por non replicar as mensaxes existentes e deixar que a cola principal e o novo espello converxen no tempo, chegando novas mensaxes á cola e as existentes deixando a cabeza da cola principal.
Esta sincronización realízase de forma automática ou manual e xestionase mediante unha política de filas. Vexamos un exemplo.
Temos dúas colas espelladas. A cola A sincronízase automaticamente e a cola B de forma manual. Ambas filas conteñen dez mensaxes.
Arroz. 8. Dúas colas con diferentes modos de sincronización
Agora estamos perdendo Broker 3.
Arroz. 9. Caeu o corredor 3
O corredor 3 volve ao servizo. O clúster crea un espello para cada cola no novo nodo e sincroniza automaticamente a nova cola A co mestre. Non obstante, o espello da nova Fila B segue baleiro. Deste xeito, temos unha redundancia total na cola A e só un espello para as mensaxes existentes da cola B.
Arroz. 10. O novo espello da cola A recibe todas as mensaxes existentes, pero o novo réplica da cola B non.
Chegan dez mensaxes máis ás dúas filas. A continuación, o Broker 2 falla e a cola A volve ao espello máis antigo, que está no Broker 1. Non hai perda de datos cando falla. Na cola B, hai vinte mensaxes no mestre e só dez no espello porque esta cola nunca replicou as dez mensaxes orixinais.
Arroz. 11. A cola A volve ao Corretor 1 sen perder mensaxes
Chegan dez mensaxes máis ás dúas filas. Agora o Broker 1 falla. A cola A cambia facilmente ao espello sen perder mensaxes. Non obstante, a cola B está a ter problemas. Neste punto podemos optimizar a dispoñibilidade ou a coherencia.
Se queremos optimizar a accesibilidade, entón a política ha-promover-en-fracaso debe instalarse en sempre. Este é o valor predeterminado, polo que simplemente non podes especificar a política en absoluto. Neste caso, esencialmente estamos permitindo fallos en espellos non sincronizados. Isto fará que as mensaxes se perdan, pero a cola permanecerá lexible e escribible.
Arroz. 12. A cola A revélase ao Corretor 3 sen perder mensaxes. A cola B volve ao Corretor 3 con dez mensaxes perdidas
Tamén podemos instalar ha-promote-on-failure en significado when-synced. Neste caso, en lugar de volver ao espello, a cola agardará ata que o Broker 1 cos seus datos volva ao modo en liña. Despois de que regrese, a cola principal volve estar no Broker 1 sen perda de datos. A dispoñibilidade sacrificase pola seguridade dos datos. Pero este é un modo arriscado que incluso pode levar á perda completa de datos, que veremos en breve.
Arroz. 13. A cola B segue sen estar dispoñible despois de perder o corredor 1
Podes preguntar: "É mellor non usar nunca a sincronización automática?" A resposta é que a sincronización é unha operación de bloqueo. Durante a sincronización, a cola principal non pode realizar ningunha operación de lectura ou escritura.
Vexamos un exemplo. Agora temos colas moi longas. Como poden medrar ata tal tamaño? Por varias razóns:
- As colas non se utilizan activamente
- Son colas de alta velocidade e agora mesmo os consumidores son lentos
- Son colas de alta velocidade, houbo un fallo e os consumidores están a poñerse ao día
Arroz. 14. Dúas grandes colas con diferentes modos de sincronización
Agora cae o Broker 3.
Arroz. 15. O corredor 3 cae, deixando un mestre e un espello en cada cola
Broker 3 volve estar en liña e créanse novos espellos. A cola principal A comeza a replicar as mensaxes existentes no novo espello e durante este tempo a cola non está dispoñible. Leva dúas horas replicar os datos, o que supón dúas horas de inactividade para esta cola.
Non obstante, a cola B permanece dispoñible durante todo o período. Ela sacrificou algo de redundancia pola accesibilidade.
Arroz. 16. A cola segue sen estar dispoñible durante a sincronización
Despois de dúas horas, a cola A tamén está dispoñible e pode comezar a aceptar lecturas e escrituras de novo.
Actualizacións
Este comportamento de bloqueo durante a sincronización dificulta a actualización de clústeres con colas moi grandes. Nalgún momento, o nodo mestre debe reiniciarse, o que significa cambiar a un espello ou desactivar a cola mentres se está a actualizar o servidor. Se optamos pola transición, perderemos mensaxes se os espellos non están sincronizados. De forma predeterminada, durante unha interrupción do intermediario, non se realiza unha conmutación por fallo nun espello non sincronizado. Isto significa que tan pronto como o corredor volve, non perdemos ningunha mensaxe, o único dano foi unha simple cola. As regras de comportamento cando un corredor está desconectado son establecidas pola política ha-promote-on-shutdown. Podes establecer un dos dous valores:
always= a transición a espellos non sincronizados está activadawhen-synced= transición só a un espello sincronizado, se non, a cola faise ilegible e non escribible. A cola volve ao servizo tan pronto como o corredor volve
Dun xeito ou doutro, con grandes colas hai que escoller entre a perda de datos e a indisponibilidade.
Cando a dispoñibilidade mellora a seguridade dos datos
Hai unha complicación máis a considerar antes de tomar unha decisión. Aínda que a sincronización automática é mellor para a redundancia, como afecta a seguridade dos datos? Por suposto, cunha mellor redundancia, é menos probable que RabbitMQ perda as mensaxes existentes, pero que pasa coas novas mensaxes dos editores?
Aquí tes que ter en conta o seguinte:
- Podería o editor simplemente devolver un erro e facer que o servizo de upstream ou o usuario tente de novo máis tarde?
- Pode o editor gardar a mensaxe localmente ou nunha base de datos para tentalo de novo máis tarde?
Se o editor só pode descartar a mensaxe, de feito, mellorar a accesibilidade tamén mellora a seguridade dos datos.
Así, hai que buscar un equilibrio, e a solución depende da situación concreta.
Problemas con ha-promote-on-failure=cando se sincroniza
Idea ha-promover-en-fracaso= cando se sincroniza é que evitamos cambiar a un espello non sincronizado e, así, evitamos a perda de datos. A cola segue sendo ilexible ou escribible. En vez diso, tentamos recuperar o corredor accidentado cos seus datos intactos para que poida retomar o seu funcionamento como mestre sen perda de datos.
Pero (e este é un gran pero) se o corredor perdeu os seus datos, entón temos un gran problema: a cola está perdida! ¡Todos os datos desapareceron! Aínda que teñas espellos que se atopan na súa maioría coa cola principal, eses espellos tamén se descartan.
Para engadir de novo un nodo co mesmo nome, dicímoslle ao clúster que esqueza o nodo perdido (co comando rabbitmqctl forget_cluster_node) e inicie un novo corredor co mesmo nome de host. Mentres o clúster lembra o nodo perdido, lembra a cola antiga e os espellos non sincronizados. Cando se lle indica a un clúster que esqueza un nodo orfo, tamén se esquece esa cola. Agora temos que volver declaralo. Perdemos todos os datos, aínda que tiñamos espellos cun conxunto parcial de datos. Sería mellor cambiar a un espello non sincronizado!
Polo tanto, sincronización manual (e falla de sincronización) en combinación con ha-promote-on-failure=when-synced, na miña opinión, bastante arriscado. Os documentos din que esta opción existe para a seguridade dos datos, pero é un coitelo de dobre fío.
Reequilibrio mestre
Como prometemos, volvemos ao problema da acumulación de todos os mestres nun ou varios nodos. Isto mesmo pode ocorrer como resultado dunha actualización do clúster en curso. Nun clúster de tres nodos, todas as colas mestras acumularanse nun ou dous nodos.
O reequilibrio dos mestres pode ser problemático por dúas razóns:
- Non hai boas ferramentas para realizar o reequilibrio
- Sincronización de filas
Hai un terceiro para o reequilibrio , que non ten soporte oficial. Respecto aos complementos de terceiros no manual de RabbitMQ : "O complemento ofrece algunhas ferramentas de configuración e informes adicionais, pero o equipo de RabbitMQ non admite nin verifica. Use baixo o seu propio risco".
Hai outro truco para mover a cola principal a través das políticas de alta disponibilidad. O manual menciona para isto. Funciona así:
- Elimina todas as réplicas mediante unha política temporal que teña unha prioridade máis alta que a política de alta disponibilidad existente.
- Cambia a política temporal de alta disponibilidad para utilizar o modo de nodo, especificando o nodo ao que se debe transferir a cola mestra.
- Sincroniza a cola para a migración push.
- Despois de completar a migración, elimina a política temporal. A política de alta disponibilidad inicial entra en vigor e créase o número necesario de réplicas.
A desvantaxe é que este enfoque pode non funcionar se tes grandes colas ou requisitos estritos de redundancia.
Agora vexamos como funcionan os clústeres RabbitMQ coas particións de rede.
Perda de conectividade
Os nodos dun sistema distribuído están conectados por enlaces de rede, e os enlaces de rede poden e serán desconectados. A frecuencia das interrupcións depende da infraestrutura local ou da fiabilidade da nube seleccionada. En calquera caso, os sistemas distribuídos deben ser capaces de facerlles fronte. Unha vez máis temos a posibilidade de escoller entre a dispoñibilidade e a coherencia, e de novo a boa noticia é que RabbitMQ ofrece ambas opcións (non só ao mesmo tempo).
Con RabbitMQ temos dúas opcións principais:
- Permitir división lóxica (split-brain). Isto garante a dispoñibilidade, pero pode provocar a perda de datos.
- Desactivar a separación lóxica. Pode producir unha perda de dispoñibilidade a curto prazo dependendo de como se conecten os clientes ao clúster. Tamén pode provocar unha indisponibilidade completa nun clúster de dous nodos.
Pero que é a separación lóxica? Isto ocorre cando un clúster se divide en dous debido á perda de conexións de rede. A cada lado, os espellos ascenden a un mestre, polo que finalmente hai varios mestres por turno.
Arroz. 17. Fila principal e dous espellos, cada un nun nodo separado. Entón prodúcese un fallo de rede e un espello se separa. O nodo separado ve que os outros dous caeron e promove os seus espellos ao mestre. Agora temos dúas filas principais, tanto escribibles como lexibles.
Se as editoriais envían datos aos dous mestres, acabamos con dúas copias diverxentes da cola.
Os diferentes modos de RabbitMQ proporcionan dispoñibilidade ou coherencia.
Modo Ignorar (predeterminado)
Este modo garante a accesibilidade. Despois da perda de conectividade, prodúcese unha separación lóxica. Despois de restaurar a conectividade, o administrador debe decidir a que partición darlle prioridade. O lado perdedor reiniciarase e todos os datos acumulados nese lado perderanse.
Arroz. 18. Tres editores están asociados con tres corredores. Internamente, o clúster envía todas as solicitudes á cola principal de Broker 2.
Agora estamos perdendo o corredor 3. El ve que outros corredores caeron e promove o seu espello ao mestre. Así é como se produce unha separación lóxica.
Arroz. 19. División lóxica (split-brain). Os rexistros entran en dúas filas principais e as dúas copias diverxen.
A conectividade restableceuse, pero mantense a separación lóxica. O administrador debe seleccionar manualmente o lado perdedor. No seguinte caso, o administrador reinicia Broker 3. Todas as mensaxes que non conseguiu transmitir pérdense.
Arroz. 20. O administrador desactiva o Broker 3.
Arroz. 21. O administrador inicia o Broker 3 e únese ao clúster, perdendo todas as mensaxes que quedaron alí.
Durante a perda de conectividade e despois da súa restauración, o clúster e esta cola estaban dispoñibles para ler e escribir.
Modo de autocuración
Funciona de xeito similar ao modo Ignorar, agás que o propio clúster escolle automaticamente o lado perdedor despois de dividir e restaurar a conectividade. O lado perdedor volve ao clúster baleiro e a cola perde todas as mensaxes que só se enviaron a ese lado.
Pausa o modo minoritario
Se non queremos permitir a partición lóxica, entón a nosa única opción é descartar lecturas e escrituras no lado máis pequeno despois da partición do clúster. Cando o corredor ve que está no lado máis pequeno, suspende o traballo, é dicir, pecha todas as conexións existentes e rexeita as novas. Unha vez por segundo comproba a restauración da conectividade. Unha vez restaurada a conectividade, retoma a operación e únese ao clúster.
Arroz. 22. Tres editores están asociados con tres corredores. Internamente, o clúster envía todas as solicitudes á cola principal de Broker 2.
Despois, os corredores 1 e 2 sepáranse do corredor 3. En lugar de promover o seu espello a mestre, o corredor 3 suspende e non está dispoñible.
Arroz. 23. O corredor 3 fai unha pausa, desconecta todos os clientes e rexeita as solicitudes de conexión.
Unha vez restaurada a conectividade, volve ao clúster.
Vexamos outro exemplo onde a cola principal está en Broker 3.
Arroz. 24. Fila principal en Broker 3.
Entón prodúcese a mesma perda de conectividade. O corredor 3 fai unha pausa porque está no lado máis pequeno. Por outro lado, os nodos ven que Broker 3 caeu, polo que o espello máis antigo dos Brokers 1 e 2 ascende a mestre.
Arroz. 25. Transición ao Corretor 2 se o Corretor 3 non está dispoñible.
Cando se restaure a conectividade, o Broker 3 unirase ao clúster.
Arroz. 26. O clúster volveu ao funcionamento normal.
O importante a entender aquí é que temos coherencia, pero tamén podemos obter dispoñibilidade, se Transferiremos clientes con éxito á maior parte da sección. Para a maioría das situacións, eu persoalmente escollería o modo Pausa minoritaria, pero realmente depende do caso individual.
Para garantir a dispoñibilidade, é importante asegurarse de que os clientes se conecten correctamente ao host. Vexamos as nosas opcións.
Garantir a conectividade do cliente
Temos varias opcións sobre como dirixir os clientes á parte principal do clúster ou aos nodos de traballo (despois de que falle un nodo) despois dunha perda de conectividade. En primeiro lugar, lembremos que unha cola específica está aloxada nun nodo específico, pero o enrutamento e as políticas replícanse en todos os nodos. Os clientes poden conectarse a calquera nodo e o enrutamento interno dirixiraos a onde precisan ir. Pero cando se suspende un nodo, rexeita as conexións, polo que os clientes deben conectarse a outro nodo. Se o nodo cae, hai pouco que poida facer.
As nosas opcións:
- Accédese ao clúster mediante un equilibrador de carga que simplemente percorre os nodos e os clientes tentan conectarse de novo ata que teña éxito. Se un nodo está inactivo ou suspendido, os intentos de conexión a ese nodo fallarán, pero os intentos posteriores irán a outros servidores (de forma round-robin). Isto é adecuado para unha perda de conectividade a curto prazo ou un servidor caído que se recuperará rapidamente.
- Acceda ao clúster a través dun equilibrador de carga e elimine os nós suspendidos/fallados da lista en canto se detecten. Se o facemos rapidamente e se os clientes poden tentar de novo a conexión, conseguiremos unha dispoñibilidade constante.
- Dálle a cada cliente unha lista de todos os nós e o cliente selecciona un deles ao azar ao conectarse. Se recibe un erro ao tentar conectarse, pasa ao seguinte nodo da lista ata que se conecte.
- Elimina o tráfico dun nodo fallido/suspendido mediante DNS. Isto faise usando un pequeno TTL.
Descubrimentos
A agrupación RabbitMQ ten as súas vantaxes e desvantaxes. As desvantaxes máis graves son:
- ao unirse a un clúster, os nodos descartan os seus datos;
- bloquear a sincronización fai que a cola non estea dispoñible.
Todas as decisións difíciles derivan destas dúas características arquitectónicas. Se RabbitMQ puidese gardar datos cando se reúna ao clúster, entón a sincronización sería máis rápida. Se fose capaz de sincronización sen bloqueo, sería mellor admitir colas grandes. Corrixir estes dous problemas melloraría moito o rendemento de RabbitMQ como tecnoloxía de mensaxería altamente dispoñible e tolerante a fallos. Dubidaría en recomendar RabbitMQ coa agrupación nas seguintes situacións:
- Rede pouco fiable.
- Almacenamento pouco fiable.
- Colas moi longas.
Cando se trata de configuracións de alta dispoñibilidade, teña en conta o seguinte:
ha-promote-on-failure=alwaysha-sync-mode=manualcluster_partition_handling=ignore(Ouautoheal)- mensaxes persistentes
- asegúrese de que os clientes se conecten ao nodo activo cando algún nodo falla
Para a coherencia (seguridade dos datos), considere as seguintes opcións:
- Confirmacións do editor e recoñecementos manuais no lado do consumidor
ha-promote-on-failure=when-synced, se os editores poden tentalo de novo máis tarde e se tes un almacenamento moi fiable! En caso contrario pon=always.ha-sync-mode=automatic(pero para grandes colas inactivas pode ser necesario o modo manual; tamén considere se a falta de dispoñibilidade fará que se perdan as mensaxes)- Pausa o modo minoritario
- mensaxes persistentes
Aínda non cubrimos todos os problemas de tolerancia a fallos e alta dispoñibilidade; por exemplo, como realizar de forma segura procedementos administrativos (como actualizacións continuas). Tamén hai que falar de federación e do complemento Shovel.
Se perdín algo máis, avísame.
Vexa tamén o meu , onde realizo un estrago nun clúster RabbitMQ usando Docker e Blockade para probar algúns dos escenarios de perda de mensaxes descritos neste artigo.
Artigos anteriores da serie:
número 1 -
número 2 -
número 3 -
Fonte: www.habr.com