La tolerància a errors i l'alta disponibilitat són temes importants, de manera que dedicarem articles separats a RabbitMQ i Kafka. Aquest article tracta sobre RabbitMQ, i el següent és sobre Kafka, en comparació amb RabbitMQ. Aquest és un article llarg, així que posa't còmode.
Vegem les estratègies de tolerància a errors, coherència i alta disponibilitat (HA) i les compensacions que fa cada estratègia. RabbitMQ es pot executar en un clúster de nodes i després es classifica com un sistema distribuït. Quan es tracta de sistemes distribuïts, sovint parlem de coherència i disponibilitat.
Aquests conceptes descriuen com es comporta un sistema quan falla. Error de connexió de xarxa, fallada del servidor, fallada del disc dur, indisponibilitat temporal del servidor a causa de la recollida d'escombraries, pèrdua de paquets o desacceleració de la connexió de xarxa. Tot això pot provocar pèrdues de dades o conflictes. Resulta que és pràcticament impossible instal·lar un sistema que sigui completament coherent (sense pèrdua de dades, sense divergència de dades) i disponible (acceptarà lectures i escriptures) per a tots els escenaris de fallada.
Veurem que la coherència i la disponibilitat es troben en extrems oposats de l'espectre i cal que escolliu la manera d'optimitzar. La bona notícia és que amb RabbitMQ aquesta elecció és possible. Teniu aquest tipus de palanques "nerdy" per canviar l'equilibri cap a una major consistència o una major accessibilitat.
Prestarem especial atenció a quines configuracions provoquen la pèrdua de dades a causa dels registres confirmats. Hi ha una cadena de responsabilitat entre editors, corredors i consumidors. Un cop transmès el missatge al corredor, la seva feina és no perdre el missatge. Quan el corredor reconeix que l'editor ha rebut el missatge, no esperem que es perdi. Però veurem que això pot passar en funció de la configuració de l'editor i de l'editor.
Primitives de resiliència d'un sol node
Cua/encaminament resistent
Hi ha dos tipus de cues a RabbitMQ: duradores i no duradores. Totes les cues es guarden a la base de dades Mnesia. Les cues duradores es tornen a anunciar a l'inici del node i, per tant, sobreviuen a reinicis, fallades del sistema o bloquejos del servidor (sempre que les dades es mantinguin). Això vol dir que, sempre que declareu que l'encaminament (intercanvi) i la cua són resistents, la infraestructura de cua/encaminament tornarà a estar en línia.
Les cues volàtils i l'encaminament s'eliminen quan es reinicia el node.
Missatges persistents
El fet que una cua sigui duradora no vol dir que tots els seus missatges sobreviurin a un reinici del node. Només els missatges establerts per l'editor com a resistent (persistent). Els missatges persistents creen una càrrega addicional al corredor, però si la pèrdua de missatges és inacceptable, no hi ha cap altra opció.
Arròs. 1. Matriu de sostenibilitat
Agrupació amb rèplica de cua
Per sobreviure a la pèrdua d'un corredor, necessitem la redundància. Podem combinar diversos nodes RabbitMQ en un clúster i, a continuació, afegir redundància addicional replicant cues entre diversos nodes. D'aquesta manera, si un node falla, no perdem dades i romandrem disponibles.
Replica de la cua:
- una cua principal (mestra), que rep totes les ordres d'escriptura i lectura
- un o més miralls que reben tots els missatges i metadades de la cua principal. Aquests miralls no estan allà per escalar, sinó purament per redundància.
Arròs. 2. Mirall de la cua
La rèplica està establerta per la política adequada. En ell podeu seleccionar el coeficient de replicació i fins i tot els nodes en què s'ha d'ubicar la cua. Exemples:
ha-mode: allha-mode: exactly, ha-params: 2(un mestre i un mirall)ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2
Confirmació de l'editor
Per aconseguir un enregistrament coherent, calen les confirmacions de l'editor. Sense ells, hi ha el risc que es perdin missatges. S'envia una confirmació a l'editor després d'escriure el missatge al disc. RabbitMQ escriu missatges al disc no després de rebre'ls, sinó de manera periòdica, al voltant de diversos centenars de mil·lisegons. Quan es reflecteix una cua, només s'envia un reconeixement després que tots els miralls també hagin escrit la seva còpia del missatge al disc. Això vol dir que l'ús de confirmacions afegeix latència, però si la seguretat de les dades és important, són necessàries.
Cua de failover
Quan un corredor surt o falla, tots els líders de la cua (masters) d'aquest node s'estavellen juntament amb ell. Aleshores, el clúster selecciona el mirall més antic de cada mestre i el promou com a nou mestre.
Arròs. 3. Múltiples cues reflectides i les seves polítiques
El corredor 3 cau. Tingueu en compte que el mirall de la cua C de Broker 2 s'està promocionant a mestre. Tingueu en compte també que s'ha creat una rèplica nova per a la cua C a l'agent 1. RabbitMQ sempre intenta mantenir el factor de replicació especificat a les vostres polítiques.
Arròs. 4. L'agent 3 falla i fa que la cua C falli
El proper Broker 1 cau! Només ens queda un corredor. El mirall de la cua B es promou a mestre.
La figura. 5
Hem retornat l'agent 1. Independentment de com sobreviuen les dades a la pèrdua i la recuperació de l'agent, tots els missatges de cua duplicats es descarten en reiniciar-se. Això és important tenir en compte perquè hi haurà conseqüències. En breu veurem aquestes implicacions. Per tant, Broker 1 torna a ser membre del clúster i el clúster intenta complir les polítiques i, per tant, crea miralls al Broker 1.
En aquest cas, la pèrdua del Broker 1 va ser completa, igual que les dades, de manera que la cua B no reflectida es va perdre completament.
Arròs. 6. El corredor 1 torna al servei
Broker 3 torna a estar en línia, de manera que les cues A i B recuperen els miralls creats per satisfer les seves polítiques d'HA. Però ara totes les cues principals estan en un node! Això no és ideal, és millor una distribució uniforme entre nodes. Malauradament, aquí no hi ha moltes opcions per reequilibrar els mestres. Tornarem a aquest problema més endavant perquè primer hem de mirar la sincronització de la cua.
Arròs. 7. El corredor 3 torna al servei. Totes les cues principals en un node!
Així que ara hauríeu de tenir una idea de com els miralls proporcionen redundància i tolerància a errors. Això garanteix la disponibilitat en cas de fallada d'un sol node i protegeix contra la pèrdua de dades. Però encara no hem acabat, perquè en realitat és molt més complicat.
Sincronització
En crear un mirall nou, tots els missatges nous sempre es replicaran a aquest mirall i a qualsevol altre. Pel que fa a les dades existents a la cua mestra, les podem replicar a un nou mirall, que es converteix en una còpia completa del mestre. També podem optar per no replicar els missatges existents i deixar que la cua principal i el nou mirall convergin en el temps, amb nous missatges que arriben a la cua i els missatges existents que surten del cap de la cua principal.
Aquesta sincronització es realitza automàticament o manualment i es gestiona mitjançant una política de cua. Vegem un exemple.
Tenim dues cues miralls. La cua A es sincronitza automàticament i la cua B es sincronitza manualment. Les dues cues contenen deu missatges.
Arròs. 8. Dues cues amb diferents modes de sincronització
Ara estem perdent Broker 3.
Arròs. 9. El corredor 3 va caure
El corredor 3 torna al servei. El clúster crea un mirall per a cada cua del nou node i sincronitza automàticament la nova cua A amb el mestre. Tanmateix, el mirall de la nova cua B roman buit. D'aquesta manera tenim una redundància completa a la cua A i només un mirall per als missatges de la cua B existents.
Arròs. 10. El nou mirall de la cua A rep tots els missatges existents, però el nou mirall de la cua B no.
Arriben deu missatges més a les dues cues. Aleshores, Broker 2 es bloqueja i la cua A torna a la rèplica més antiga, que es troba a Broker 1. No hi ha pèrdua de dades quan falla. A la cua B, hi ha vint missatges al mestre i només deu al mirall perquè aquesta cua no va replicar mai els deu missatges originals.
Arròs. 11. La cua A torna a l'agent 1 sense perdre missatges
Arriben deu missatges més a les dues cues. Ara Broker 1 es bloqueja. La cua A canvia fàcilment al mirall sense perdre missatges. Tanmateix, la cua B té problemes. En aquest punt podem optimitzar la disponibilitat o la coherència.
Si volem optimitzar l'accessibilitat, aleshores la política ha-promocionar-en-fallir s'ha d'instal·lar sempre. Aquest és el valor predeterminat, de manera que simplement no podeu especificar la política en absolut. En aquest cas, bàsicament estem permetent errors en miralls no sincronitzats. Això farà que es perdin missatges, però la cua es podrà llegir i escriure.
Arròs. 12. La cua A es torna a l'agent 3 sense perdre missatges. La cua B torna a l'agent 3 amb deu missatges perduts
També podem instal·lar ha-promote-on-failure en sentit when-synced. En aquest cas, en lloc de tornar a la rèplica, la cua esperarà fins que Broker 1 amb les seves dades torni al mode en línia. Un cop torna, la cua principal torna a Broker 1 sense cap pèrdua de dades. La disponibilitat es sacrifica per a la seguretat de les dades. Però aquest és un mode arriscat que fins i tot pot provocar una pèrdua total de dades, que veurem en breu.
Arròs. 13. La cua B continua no disponible després de perdre el corredor 1
Potser us preguntareu: "És millor no utilitzar mai la sincronització automàtica?" La resposta és que la sincronització és una operació de bloqueig. Durant la sincronització, la cua principal no pot realitzar cap operació de lectura o escriptura!
Vegem un exemple. Ara tenim cues molt llargues. Com poden créixer a tal mida? Per diversos motius:
- Les cues no s'utilitzen activament
- Són cues d'alta velocitat, i ara mateix els consumidors són lents
- Són cues d'alta velocitat, hi ha hagut un problema i els consumidors s'estan posant al dia
Arròs. 14. Dues grans cues amb diferents modes de sincronització
Ara cau Broker 3.
Arròs. 15. El corredor 3 cau, deixant un mestre i mirall a cada cua
Broker 3 torna a estar en línia i es creen nous miralls. La cua principal A comença a replicar els missatges existents a la rèplica nova i durant aquest temps la cua no està disponible. Es triguen dues hores a replicar les dades, la qual cosa comporta dues hores d'inactivitat per a aquesta cua.
Tanmateix, la cua B continua disponible durant tot el període. Va sacrificar una mica de redundància per l'accessibilitat.
Arròs. 16. La cua no està disponible durant la sincronització
Després de dues hores, la cua A també està disponible i pot començar a acceptar lectures i escriptures de nou.
Actualitzacions
Aquest comportament de bloqueig durant la sincronització fa que sigui difícil actualitzar clústers amb cues molt grans. En algun moment, s'ha de reiniciar el node mestre, la qual cosa significa canviar a un mirall o desactivar la cua mentre s'actualitza el servidor. Si optem per fer la transició, perdrem missatges si els miralls no estan sincronitzats. De manera predeterminada, durant una interrupció del corredor, no es realitza una migració per error a un mirall no sincronitzat. Això vol dir que tan bon punt torna el corredor, no perdem cap missatge, l'únic dany va ser una simple cua. Les regles de comportament quan un corredor es desconnecta les estableix la política ha-promote-on-shutdown. Podeu establir un dels dos valors:
always= la transició a miralls no sincronitzats està activadawhen-synced= només transició a un mirall sincronitzat, en cas contrari, la cua esdevé il·legible i no es pot escriure. La cua torna al servei tan bon punt torna el corredor
D'una manera o altra, amb cues grans cal triar entre la pèrdua de dades i la indisponibilitat.
Quan la disponibilitat millora la seguretat de les dades
Hi ha una complicació més a considerar abans de prendre una decisió. Tot i que la sincronització automàtica és millor per a la redundància, com afecta la seguretat de les dades? Per descomptat, amb una millor redundància, és menys probable que RabbitMQ perdi missatges existents, però què passa amb els missatges nous dels editors?
Aquí heu de tenir en compte el següent:
- L'editor podria simplement retornar un error i fer que el servei o l'usuari avançat ho torni a provar més tard?
- L'editor pot desar el missatge localment o a la base de dades per tornar-ho a provar més tard?
Si l'editor només pot descartar el missatge, de fet, millorar l'accessibilitat també millora la seguretat de les dades.
Per tant, s'ha de buscar un equilibri, i la solució depèn de la situació concreta.
Problemes amb ha-promote-on-failure=quan-s'ha sincronitzat
Idea ha-promocionar-en-fallir= quan es sincronitza és que evitem canviar a un mirall no sincronitzat i, per tant, evitem la pèrdua de dades. La cua roman il·legible o es pot escriure. En comptes d'això, intentem recuperar el corredor bloquejat amb les seves dades intactes perquè pugui reprendre el funcionament com a mestre sense pèrdua de dades.
Però (i això és un gran però) si el corredor ha perdut les seves dades, llavors tenim un gran problema: la cua s'ha perdut! Totes les dades han desaparegut! Fins i tot si teniu miralls que majoritàriament es posen al dia amb la cua principal, aquests miralls també es descarten.
Per tornar a afegir un node amb el mateix nom, diem al clúster que oblidi el node perdut (amb l'ordre rabbitmqctl forget_cluster_node) i inicieu un agent nou amb el mateix nom d'amfitrió. Mentre el clúster recorda el node perdut, recorda la cua antiga i els miralls no sincronitzats. Quan se li diu a un clúster que oblidi un node orfe, aquesta cua també s'oblida. Ara l'hem de tornar a declarar. Hem perdut totes les dades, tot i que teníem miralls amb un conjunt parcial de dades. Seria millor canviar a un mirall no sincronitzat!
Per tant, la sincronització manual (i la fallada de sincronització) en combinació amb ha-promote-on-failure=when-synced, al meu entendre, bastant arriscat. Els documents diuen que aquesta opció existeix per a la seguretat de les dades, però és un ganivet de doble tall.
Reequilibri mestre
Com es va prometre, tornem al problema de l'acumulació de tots els mestres en un o diversos nodes. Això pot passar fins i tot com a resultat d'una actualització de clúster en continu. En un clúster de tres nodes, totes les cues mestres s'acumularan en un o dos nodes.
El reequilibri dels mestres pot ser problemàtic per dos motius:
- No hi ha bones eines per fer el reequilibri
- Sincronització de la cua
Hi ha un tercer per reequilibrar , que no té suport oficial. Pel que fa als connectors de tercers al manual de RabbitMQ : "El connector proporciona algunes eines de configuració i informes addicionals, però l'equip de RabbitMQ no és compatible ni verificat. Feu servir sota el vostre propi risc".
Hi ha un altre truc per moure la cua principal a través de polítiques d'HA. El manual esmenta per això. Funciona així:
- Elimina totes les rèpliques mitjançant una política temporal que té una prioritat més alta que la política d'HA existent.
- Canvia la política temporal d'HA per utilitzar el mode de node, especificant el node al qual s'ha de transferir la cua mestra.
- Sincronitza la cua per a la migració push.
- Un cop finalitzada la migració, s'elimina la política temporal. La política d'HA inicial entra en vigor i es crea el nombre necessari de miralls.
L'inconvenient és que aquest enfocament pot no funcionar si teniu cues grans o requisits de redundància estrictes.
Ara vegem com funcionen els clústers RabbitMQ amb particions de xarxa.
Interrupció de la connectivitat
Els nodes d'un sistema distribuït estan connectats per enllaços de xarxa, i els enllaços de xarxa poden i seran desconnectats. La freqüència de les interrupcions depèn de la infraestructura local o de la fiabilitat del núvol seleccionat. En qualsevol cas, els sistemes distribuïts han de poder fer-hi front. Una vegada més, tenim l'opció de triar entre disponibilitat i coherència, i una altra vegada la bona notícia és que RabbitMQ ofereix les dues opcions (no al mateix temps).
Amb RabbitMQ tenim dues opcions principals:
- Permetre la divisió lògica (split-brain). Això garanteix la disponibilitat, però pot provocar la pèrdua de dades.
- Desactiva la separació lògica. Pot provocar una pèrdua de disponibilitat a curt termini en funció de com es connectin els clients al clúster. També pot provocar una indisponibilitat total en un clúster de dos nodes.
Però què és la separació lògica? Això és quan un clúster es divideix en dos a causa de la pèrdua de connexions de xarxa. A cada costat, els miralls ascendeixen a un mestre, de manera que finalment hi ha diversos mestres per cua.
Arròs. 17. Cua principal i dos miralls, cadascun en un node independent. Aleshores es produeix un error de xarxa i un mirall es desconnecta. El node separat veu que els altres dos han caigut i promou els seus miralls al mestre. Ara tenim dues cues principals, ambdues escrivibles i llegibles.
Si els editors envien dades als dos mestres, acabem amb dues còpies divergents de la cua.
Els diferents modes de RabbitMQ proporcionen disponibilitat o coherència.
Ignora el mode (per defecte)
Aquest mode garanteix l'accessibilitat. Després de la pèrdua de connectivitat, es produeix una separació lògica. Un cop restaurada la connectivitat, l'administrador ha de decidir a quina partició donar prioritat. El costat perdedor es reiniciarà i totes les dades acumulades en aquest costat es perdran.
Arròs. 18. Tres editors estan associats amb tres corredors. Internament, el clúster encamina totes les sol·licituds a la cua principal de Broker 2.
Ara estem perdent el corredor 3. Ell veu que altres corredors han caigut i promociona el seu mirall al mestre. Així és com es produeix una separació lògica.
Arròs. 19. Divisió lògica (split-brain). Els registres entren en dues cues principals i les dues còpies divergeixen.
La connectivitat es restableix, però es manté la separació lògica. L'administrador ha de seleccionar manualment el costat perdedor. En el cas següent, l'administrador reinicia Broker 3. Es perden tots els missatges que no ha aconseguit transmetre.
Arròs. 20. L'administrador desactiva Broker 3.
Arròs. 21. L'administrador inicia Broker 3 i s'uneix al clúster, perdent tots els missatges que hi van quedar.
Durant la pèrdua de connectivitat i després de la seva restauració, el clúster i aquesta cua estaven disponibles per llegir i escriure.
Mode de cura automàtica
Funciona de manera similar al mode Ignora, excepte que el propi clúster tria automàticament el costat perdedor després de dividir i restaurar la connectivitat. El costat perdedor torna al clúster buit i la cua perd tots els missatges que s'han enviat només a aquest costat.
Posa en pausa el mode minoritari
Si no volem permetre el particionament lògic, la nostra única opció és descartar les lectures i les escriptures al costat més petit després de la partició del clúster. Quan el corredor veu que està al costat més petit, suspèn el treball, és a dir, tanca totes les connexions existents i rebutja les noves. Una vegada per segon, comprova la restauració de la connectivitat. Un cop restaurada la connectivitat, reprèn el funcionament i s'uneix al clúster.
Arròs. 22. Tres editors estan associats amb tres corredors. Internament, el clúster encamina totes les sol·licituds a la cua principal de Broker 2.
Aleshores, els corredors 1 i 2 se separen del corredor 3. En comptes de promoure el seu mirall a mestre, el corredor 3 se suspèn i no està disponible.
Arròs. 23. L'agent 3 posa en pausa, desconnecta tots els clients i rebutja les sol·licituds de connexió.
Un cop restaurada la connectivitat, torna al clúster.
Vegem un altre exemple on la cua principal es troba a Broker 3.
Arròs. 24. Cua principal a Broker 3.
Aleshores es produeix la mateixa pèrdua de connectivitat. El corredor 3 s'atura perquè està al costat més petit. A l'altra banda, els nodes veuen que Broker 3 s'ha caigut, de manera que el mirall més antic dels Brokers 1 i 2 ascendeix a mestre.
Arròs. 25. Transició a Broker 2 si Broker 3 no està disponible.
Quan es restableixi la connectivitat, Broker 3 s'unirà al clúster.
Arròs. 26. El clúster ha tornat al funcionament normal.
L'important que cal entendre aquí és que aconseguim coherència, però també podem obtenir disponibilitat, si Transferirem clients amb èxit a la major part de la secció. Per a la majoria de situacions, jo personalment escolliria el mode Pausa minoritari, però realment depèn del cas individual.
Per garantir la disponibilitat, és important assegurar-se que els clients es connectin correctament a l'amfitrió. Vegem les nostres opcions.
Garantir la connectivitat del client
Tenim diverses opcions sobre com dirigir els clients a la part principal del clúster o als nodes de treball (després que un node falla) després d'una pèrdua de connectivitat. En primer lloc, recordem que una cua específica està allotjada en un node específic, però l'encaminament i les polítiques es repliquen a tots els nodes. Els clients es poden connectar a qualsevol node i l'encaminament intern els dirigirà cap a on han d'anar. Però quan se suspèn un node, rebutja les connexions, de manera que els clients s'han de connectar a un altre node. Si el node cau, poc pot fer.
Les nostres opcions:
- S'accedeix al clúster mitjançant un equilibrador de càrrega que simplement recorre els nodes i els clients tornen a intentar connectar-se fins que tingui èxit. Si un node està caigut o suspès, els intents de connectar-se a aquest node fallaran, però els intents posteriors aniran a altres servidors (de manera round-robin). Això és adequat per a una pèrdua de connectivitat a curt termini o un servidor caigut que es tornarà a activar ràpidament.
- Accediu al clúster mitjançant un equilibrador de càrrega i elimineu els nodes suspesos/fallits de la llista tan bon punt es detectin. Si ho fem ràpidament i si els clients poden tornar a provar la connexió, aconseguirem una disponibilitat constant.
- Doneu a cada client una llista de tots els nodes i el client en selecciona un a l'atzar quan es connecta. Si rep un error en intentar connectar-se, es mou al següent node de la llista fins que es connecta.
- Elimineu el trànsit d'un node fallit/suspès mitjançant DNS. Això es fa amb un petit TTL.
Troballes
La agrupació RabbitMQ té els seus avantatges i desavantatges. Els desavantatges més greus són:
- quan s'uneixen a un clúster, els nodes descarten les seves dades;
- bloquejar la sincronització fa que la cua no estigui disponible.
Totes les decisions difícils deriven d'aquestes dues característiques arquitectòniques. Si RabbitMQ pogués desar dades quan es torni a unir el clúster, la sincronització seria més ràpida. Si fos capaç de sincronitzar sense bloqueig, seria millor compatible amb cues grans. La solució d'aquests dos problemes milloraria molt el rendiment de RabbitMQ com a tecnologia de missatgeria tolerant a errors i altament disponible. No dubtaria a recomanar RabbitMQ amb agrupació en les situacions següents:
- Xarxa poc fiable.
- Emmagatzematge poc fiable.
- Cues molt llargues.
Quan es tracta de la configuració d'alta disponibilitat, tingueu en compte el següent:
ha-promote-on-failure=alwaysha-sync-mode=manualcluster_partition_handling=ignore(Oautoheal)- missatges persistents
- Assegureu-vos que els clients es connectin al node actiu quan algun node falla
Per a la coherència (seguretat de les dades), tingueu en compte la configuració següent:
- Confirmes de l'editor i reconeixements manuals per part del consumidor
ha-promote-on-failure=when-synced, si els editors poden tornar-ho a provar més tard i si teniu un emmagatzematge molt fiable! En cas contrari posa=always.ha-sync-mode=automatic(però per a grans cues inactives pot ser necessari el mode manual; també considereu si la indisponibilitat farà que es perdin missatges)- Posa en pausa el mode minoritari
- missatges persistents
Encara no hem cobert tots els problemes de tolerància a errors i alta disponibilitat; per exemple, com realitzar tràmits administratius de manera segura (com ara actualitzacions continuades). També hem de parlar de la federació i del connector Shovel.
Si m'he perdut alguna cosa més, feu-m'ho saber.
Vegeu també el meu , on faig estralls en un clúster RabbitMQ mitjançant Docker i Blockade per provar alguns dels escenaris de pèrdua de missatges descrits en aquest article.
Articles anteriors de la sèrie:
Núm. 1 -
Núm. 2 -
Núm. 3 -
Font: www.habr.com