Feiltoleranse og høy tilgjengelighet er store temaer, så vi vil vie separate artikler til RabbitMQ og Kafka. Denne artikkelen handler om RabbitMQ, og den neste handler om Kafka, sammenlignet med RabbitMQ. Dette er en lang artikkel, så gjør deg komfortabel.

La oss se på strategiene for feiltoleranse, konsistens og høy tilgjengelighet (HA) og avveiningene som hver strategi gjør. RabbitMQ kan kjøres på en klynge av noder – og blir da klassifisert som et distribuert system. Når det gjelder distribuerte systemer snakker vi ofte om konsistens og tilgjengelighet.

Disse konseptene beskriver hvordan et system oppfører seg når det svikter. Nettverkstilkoblingsfeil, serverfeil, harddiskfeil, server midlertidig utilgjengelighet på grunn av søppelinnsamling, pakketap eller nedgang i nettverkstilkoblingen. Alt dette kan føre til tap av data eller konflikter. Det viser seg at det er praktisk talt umulig å sette opp et system som både er helt konsistent (ingen datatap, ingen datadivergens) og tilgjengelig (vil godta lesing og skriving) for alle feilscenarier.

Vi vil se at konsistens og tilgjengelighet er i motsatte ender av spekteret, og du må velge hvilken måte å optimalisere. Den gode nyheten er at med RabbitMQ er dette valget mulig. Du har slike "nerdete" spaker for å flytte balansen mot større konsistens eller større tilgjengelighet.

Vi vil være spesielt oppmerksomme på hvilke konfigurasjoner som fører til tap av data på grunn av bekreftede poster. Det er en ansvarskjede mellom utgivere, meglere og forbrukere. Når meldingen er overført til megleren, er det hans jobb å ikke miste meldingen. Når megleren bekrefter at utgiveren har mottatt meldingen, forventer vi ikke at den går tapt. Men vi vil se at dette faktisk kan skje avhengig av konfigurasjonen av megler og utgiver.

Resiliens-primitiver for enkelt node

Spenstig kø/ruting

Det er to typer køer i RabbitMQ: holdbare og ikke-holdbare. Alle køer lagres i Mnesia-databasen. Holdbare køer annonseres på nytt ved nodeoppstart og overlever dermed omstarter, systemkrasj eller serverkrasj (så lenge dataene vedvares). Dette betyr at så lenge du erklærer ruting (utveksling) og kø for å være motstandsdyktig, vil kø-/rutingsinfrastrukturen komme online igjen.

Volatile køer og ruting fjernes når noden startes på nytt.

Vedvarende meldinger

Bare fordi en kø er holdbar, betyr det ikke at alle meldingene vil overleve en omstart av noden. Bare meldinger angitt av utgiveren som vedvarende (vedvarende). Vedvarende meldinger skaper ekstra belastning på megleren, men hvis meldingstap er uakseptabelt, er det ikke noe annet alternativ.

Ris. 1. Bærekraftsmatrise

Klynger med køspeiling

For å overleve tapet av en megler trenger vi redundans. Vi kan kombinere flere RabbitMQ-noder til en klynge, og deretter legge til ekstra redundans ved å replikere køer mellom flere noder. På denne måten, hvis en node svikter, mister vi ikke data og forblir tilgjengelige.

Køspeiling:

• én hovedkø (master), som mottar alle skrive- og lesekommandoer
• ett eller flere speil som mottar alle meldinger og metadata fra hovedkøen. Disse speilene er ikke der for skalering, men utelukkende for redundans.

Ris. 2. Køspeiling

Speiling er satt av den aktuelle policyen. I den kan du velge replikeringskoeffisienten og til og med nodene som køen skal være plassert på. Eksempler:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (en mester og ett speil)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Utgiverbekreftelse

For å oppnå konsekvent opptak kreves utgiverbekreftelser. Uten dem er det fare for at meldinger går tapt. En bekreftelse sendes til utgiveren etter at meldingen er skrevet til disk. RabbitMQ skriver meldinger til disken ikke ved mottak, men på en periodisk basis, i området flere hundre millisekunder. Når en kø er speilvendt, sendes en bekreftelse først etter at alle speil også har skrevet kopien av meldingen til disken. Dette betyr at bruk av bekreftelser gir ventetid, men hvis datasikkerhet er viktig, så er de nødvendige.

Failover-kø

Når en megler avslutter eller krasjer, krasjer alle køledere (mastere) på den noden sammen med den. Klyngen velger deretter det eldste speilet for hver master og promoterer det som den nye masteren.

Ris. 3. Flere speilvendte køer og deres retningslinjer

Megler 3 går ned. Merk at Queue C-speilet på Broker 2 blir forfremmet til master. Vær også oppmerksom på at et nytt speil er opprettet for kø C på Broker 1. RabbitMQ prøver alltid å opprettholde replikeringsfaktoren som er spesifisert i policyene dine.

Ris. 4. Broker 3 mislykkes, noe som fører til at kø C mislykkes

Den neste Broker 1 faller! Vi har kun én megler igjen. Kø B-speilet er forfremmet til å mestre.

Fig. 5

Vi har returnert Broker 1. Uansett hvor godt dataene overlever tapet og gjenopprettingen av megleren, blir alle speilvendte kømeldinger forkastet ved omstart. Dette er viktig å merke seg fordi det vil få konsekvenser. Vi skal se på disse implikasjonene snart. Så Broker 1 er nå medlem av klyngen igjen, og klyngen prøver å overholde retningslinjene og oppretter derfor speil på Broker 1.

I dette tilfellet var tapet av Broker 1 fullstendig, det samme var dataene, slik at den ikke-speilede køen B ble fullstendig tapt.

Ris. 6. Megler 1 går tilbake til tjeneste

Broker 3 er tilbake online, så køene A og B får tilbake speilene som er opprettet på den for å tilfredsstille deres HA-policyer. Men nå er alle hovedkøene på én node! Dette er ikke ideelt, en jevn fordeling mellom noder er bedre. Dessverre er det ikke mange alternativer her for å rebalansere mestere. Vi kommer tilbake til dette problemet senere fordi vi må se på køsynkronisering først.

Ris. 7. Megler 3 går tilbake til tjeneste. Alle hovedkøer på én node!

Så nå bør du ha en ide om hvordan speil gir redundans og feiltoleranse. Dette sikrer tilgjengelighet i tilfelle en enkelt nodefeil og beskytter mot tap av data. Men vi er ikke ferdige ennå, for i virkeligheten er det mye mer komplisert.

synkronisering

Når du oppretter et nytt speil, vil alle nye meldinger alltid bli replikert til dette speilet og eventuelle andre. Når det gjelder eksisterende data i masterkøen, kan vi replikere dem til et nytt speil, som blir en komplett kopi av masteren. Vi kan også velge å ikke replikere eksisterende meldinger og la hovedkøen og det nye speilet konvergere i tid, med nye meldinger som kommer til baksiden og eksisterende meldinger som forlater hodet av hovedkøen.

Denne synkroniseringen utføres automatisk eller manuelt og administreres ved hjelp av en køpolicy. La oss se på et eksempel.

Vi har to speilvendte køer. Kø A synkroniseres automatisk, og Kø B synkroniseres manuelt. Begge køene inneholder ti meldinger.

Ris. 8. To køer med forskjellige synkroniseringsmoduser

Nå mister vi Broker 3.

Ris. 9. Megler 3 falt

Megler 3 går tilbake til tjeneste. Klyngen oppretter et speil for hver kø på den nye noden og synkroniserer automatisk den nye køen A med masteren. Imidlertid forblir speilet til den nye kø B tom. På denne måten har vi full redundans på kø A og bare ett speil for eksisterende kø B-meldinger.

Ris. 10. Det nye speilet til kø A mottar alle eksisterende meldinger, men det nye speilet til kø B gjør det ikke.

Det kommer ti meldinger til i begge køene. Broker 2 krasjer deretter og kø A ruller tilbake til det eldste speilet, som er på Broker 1. Det er ingen tap av data når det svikter. I kø B er det tjue meldinger i masteren og bare ti i speilet fordi denne køen aldri replikerte de ti opprinnelige meldingene.

Ris. 11. Kø A ruller tilbake til megler 1 uten å miste meldinger

Det kommer ti meldinger til i begge køene. Nå krasjer Broker 1. Kø A bytter enkelt til speilet uten å miste meldinger. Kø B har imidlertid problemer. På dette tidspunktet kan vi optimere enten tilgjengelighet eller konsistens.

Hvis vi ønsker å optimalisere tilgjengeligheten, så politikken ha-fremme-på-feil skal installeres i alltid. Dette er standardverdien, så du kan rett og slett ikke spesifisere policyen i det hele tatt. I dette tilfellet tillater vi i hovedsak feil i usynkroniserte speil. Dette vil føre til at meldinger går tapt, men køen vil forbli lesbar og skrivbar.

Ris. 12. Kø A rulles tilbake til Broker 3 uten å miste meldinger. Kø B ruller tilbake til Broker 3 med ti meldinger tapt

Vi kan også installere ha-promote-on-failure til mening when-synced. I dette tilfellet, i stedet for å rulle tilbake til speilet, vil køen vente til Broker 1 med sine data går tilbake til online-modus. Etter at den kommer tilbake, er hovedkøen tilbake på Broker 1 uten tap av data. Tilgjengelighet er ofret for datasikkerhet. Men dette er en risikabel modus som til og med kan føre til fullstendig tap av data, som vi snart skal se på.

Ris. 13. Kø B forblir utilgjengelig etter tap av megler 1

Du kan spørre: "Er det bedre å aldri bruke automatisk synkronisering?" Svaret er at synkronisering er en blokkeringsoperasjon. Under synkronisering kan ikke hovedkøen utføre noen lese- eller skriveoperasjoner!

La oss se på et eksempel. Nå har vi veldig lange køer. Hvordan kan de vokse til en slik størrelse? Av flere grunner:

• Køer brukes ikke aktivt
• Dette er høyhastighetskøer, og akkurat nå er forbrukerne trege
• Det er høyhastighetskøer, det har vært en feil og forbrukerne tar igjen

Ris. 14. To store køer med forskjellige synkroniseringsmoduser

Nå faller Broker 3.

Ris. 15. Megler 3 faller, og etterlater én master og speil i hver kø

Broker 3 kommer tilbake på nett og nye speil blir opprettet. Hovedkø A begynner å replikere eksisterende meldinger til det nye speilet, og i løpet av denne tiden er køen utilgjengelig. Det tar to timer å replikere dataene, noe som resulterer i to timers nedetid for denne køen!

Kø B forblir imidlertid tilgjengelig gjennom hele perioden. Hun ofret litt redundans for tilgjengelighet.

Ris. 16. Køen forblir utilgjengelig under synkronisering

Etter to timer blir også kø A tilgjengelig og kan begynne å godta lesing og skriving igjen.

Oppdateringer

Denne blokkeringsatferden under synkronisering gjør det vanskelig å oppdatere klynger med veldig store køer. På et tidspunkt må masternoden startes på nytt, noe som betyr enten å bytte til et speil eller deaktivere køen mens serveren oppgraderes. Hvis vi velger å gå over, vil vi miste meldinger hvis speilene ikke er synkronisert. Som standard, under et meglerbrudd, utføres ikke en failover til et usynkronisert speil. Dette betyr at så snart megleren kommer tilbake, mister vi ingen meldinger, den eneste skaden var en enkel kø. Regler for atferd når en megler er frakoblet er fastsatt av policy ha-promote-on-shutdown. Du kan angi én av to verdier:

• always= overgang til usynkroniserte speil er aktivert
• when-synced= kun overgang til et synkronisert speil, ellers blir køen uleselig og uskrivbar. Køen går tilbake til tjeneste så snart megleren kommer tilbake

På en eller annen måte, med store køer må du velge mellom tap av data og utilgjengelighet.

Når tilgjengelighet forbedrer datasikkerheten

Det er en komplikasjon til å vurdere før du tar en beslutning. Selv om automatisk synkronisering er bedre for redundans, hvordan påvirker det datasikkerheten? Selvfølgelig, med bedre redundans, er det mindre sannsynlig at RabbitMQ mister eksisterende meldinger, men hva med nye meldinger fra utgivere?

Her må du vurdere følgende:

• Kan utgiveren bare returnere en feil og få oppstrømstjenesten eller brukeren til å prøve igjen senere?
• Kan utgiveren lagre meldingen lokalt eller i en database for å prøve igjen senere?

Hvis utgiveren bare kan forkaste meldingen, forbedrer det faktisk også datasikkerheten ved å forbedre tilgjengeligheten.

Dermed må det søkes en balanse, og løsningen avhenger av den konkrete situasjonen.

Problemer med ha-promote-on-failure=when-synced

Idé ha-fremme-på-feil= når synkronisert er at vi forhindrer bytte til et usynkronisert speil og dermed unngår tap av data. Køen forblir uleselig eller skrivbar. I stedet prøver vi å gjenopprette den krasjete megleren med dataene intakt, slik at den kan fortsette å fungere som en master uten tap av data.

Men (og dette er et stort men) hvis megleren har mistet dataene sine, så har vi et stort problem: køen er tapt! All data er borte! Selv om du har speil som stort sett fanger opp med hovedkøen, blir disse speilene også forkastet.

For å legge til en node med samme navn på nytt, ber vi klyngen om å glemme den tapte noden (med kommandoen rabbitmqctl forget_cluster_node) og start en ny megler med samme vertsnavn. Mens klyngen husker den tapte noden, husker den den gamle køen og usynkroniserte speil. Når en klynge får beskjed om å glemme en foreldreløs node, blir den køen også glemt. Nå må vi erklære det på nytt. Vi mistet alle dataene, selv om vi hadde speil med et delvis sett med data. Det ville være bedre å bytte til et ikke-synkronisert speil!

Derfor manuell synkronisering (og manglende synkronisering) i kombinasjon med ha-promote-on-failure=when-synced, etter min mening, ganske risikabelt. Dokumentene sier at dette alternativet eksisterer for datasikkerhet, men det er en tveegget kniv.

Mestre rebalansering

Som lovet kommer vi tilbake til problemet med akkumulering av alle mestere på en eller flere noder. Dette kan til og med skje som et resultat av en rullende klyngeoppdatering. I en tre-node-klynge vil alle masterkøer samle seg på en eller to noder.

Å rebalansere mestere kan være problematisk av to grunner:

• Det finnes ingen gode verktøy for å utføre rebalansering
• Køsynkronisering

Det er en tredjepart for rebalansering plugg inn, som ikke er offisielt støttet. Angående tredjeparts plugins i RabbitMQ manualen sa: “Pluginen gir noen ekstra konfigurasjons- og rapporteringsverktøy, men støttes eller verifiseres ikke av RabbitMQ-teamet. Bruk på egen risiko."

Det er et annet triks for å flytte hovedkøen gjennom HA-policyer. Manualen nevner manus for dette. Det fungerer slik:

• Fjerner alle speil som bruker en midlertidig policy som har høyere prioritet enn den eksisterende HA-policyen.
• Endrer den midlertidige HA-policyen til å bruke nodemodus, og spesifiserer noden som hovedkøen skal overføres til.
• Synkroniserer køen for push-migrering.
• Etter at migreringen er fullført, sletter den midlertidige policyen. Den første HA-policyen trer i kraft og det nødvendige antallet speil opprettes.

Ulempen er at denne tilnærmingen kanskje ikke fungerer hvis du har store køer eller strenge krav til redundans.

La oss nå se hvordan RabbitMQ-klynger fungerer med nettverkspartisjoner.

Tap av tilkobling

Nodene til et distribuert system er koblet sammen med nettverkskoblinger, og nettverkskoblinger kan og vil bli frakoblet. Frekvensen av strømbrudd avhenger av den lokale infrastrukturen eller påliteligheten til den valgte skyen. Distribuerte systemer må uansett kunne takle dem. Nok en gang har vi et valg mellom tilgjengelighet og konsistens, og igjen er den gode nyheten at RabbitMQ tilbyr begge alternativene (bare ikke samtidig).

Med RabbitMQ har vi to hovedalternativer:

• Tillat logisk deling (splitt-hjerne). Dette sikrer tilgjengelighet, men kan føre til tap av data.
• Deaktiver logisk separasjon. Kan resultere i kortsiktig tap av tilgjengelighet avhengig av hvordan klienter kobler seg til klyngen. Kan også føre til fullstendig utilgjengelighet i en to-node klynge.

Men hva er logisk separasjon? Dette er når en klynge deler seg i to på grunn av tap av nettverksforbindelser. På hver side forfremmes speilene til en master, slik at det etter hvert blir flere mastere per kø.

Ris. 17. Hovedkø og to speil på hver sin node. Da oppstår det en nettverksfeil og det ene speilet løsner. Den adskilte noden ser at de to andre har falt av og fremmer speilene sine til mesteren. Vi har nå to hovedkøer, både skrivbare og lesbare.

Hvis utgivere sender data til begge mastere, ender vi opp med to divergerende kopier av køen.

RabbitMQs forskjellige moduser gir enten tilgjengelighet eller konsistens.

Ignorer modus (standard)

Denne modusen sikrer tilgjengelighet. Etter tap av tilkobling skjer en logisk separasjon. Etter at tilkoblingen er gjenopprettet, må administratoren bestemme hvilken partisjon som skal prioriteres. Den tapende siden vil bli startet på nytt og all akkumulert data på den siden vil gå tapt.

Ris. 18. Tre forlag er tilknyttet tre meglere. Internt ruter klyngen alle forespørsler til hovedkøen på Broker 2.

Nå mister vi megler 3. Han ser at andre meglere har falt av og promoterer speilet sitt til mesteren. Slik oppstår en logisk separasjon.

Ris. 19. Logisk deling (splitt-hjerne). Postene går i to hovedkøer, og de to kopiene divergerer.

Tilkoblingen er gjenopprettet, men logisk separasjon gjenstår. Administratoren må manuelt velge den tapende siden. I tilfellet nedenfor starter administratoren Broker 3 på nytt. Alle meldinger som han ikke klarte å sende går tapt.

Ris. 20. Administratoren deaktiverer Broker 3.

Ris. 21. Administratoren starter Broker 3 og blir med i klyngen, og mister alle meldinger som ble lagt igjen der.

Under tap av tilkobling og etter gjenoppretting var klyngen og denne køen tilgjengelig for lesing og skriving.

Autoheal-modus

Fungerer på samme måte som Ignorer-modus, bortsett fra at klyngen selv automatisk velger den tapende siden etter splitting og gjenoppretting av tilkobling. Den tapende siden går tom tilbake til klyngen, og køen mister alle meldinger som bare ble sendt til den siden.

Sett minoritetsmodus på pause

Hvis vi ikke vil tillate logisk partisjonering, er vårt eneste alternativ å forkaste lesing og skriving på den mindre siden etter klyngepartisjonen. Når megleren ser at den er på den mindre siden, stanser den arbeidet, det vil si at den stenger alle eksisterende forbindelser og nekter nye. En gang per sekund sjekker den for gjenoppretting av tilkobling. Når tilkoblingen er gjenopprettet, gjenopptar den driften og blir med i klyngen.

Ris. 22. Tre forlag er tilknyttet tre meglere. Internt ruter klyngen alle forespørsler til hovedkøen på Broker 2.

Megler 1 og 2 delte seg deretter fra megler 3. I stedet for å promotere speilet sitt til å mestre, suspenderes megler 3 og blir utilgjengelig.

Ris. 23. Broker 3 pauser, kobler fra alle klienter og avviser tilkoblingsforespørsler.

Når tilkoblingen er gjenopprettet, går den tilbake til klyngen.

La oss se på et annet eksempel der hovedkøen er på Broker 3.

Ris. 24. Hovedkø på Megler 3.

Da oppstår det samme tapet av tilkobling. Megler 3 stopper fordi den er på den mindre siden. På den andre siden ser nodene at Broker 3 har falt av, så det eldre speilet fra Brokers 1 og 2 blir forfremmet til master.

Ris. 25. Overgang til Broker 2 hvis Broker 3 ikke er tilgjengelig.

Når tilkoblingen er gjenopprettet, vil Broker 3 bli med i klyngen.

Ris. 26. Klyngen har gått tilbake til normal drift.

Det viktige å forstå her er at vi får konsistens, men vi kan også få tilgjengelighet, hvis Vi vil overføre kunder til det meste av seksjonen. For de fleste situasjoner ville jeg personlig valgt Pause Minority-modus, men det avhenger virkelig av det enkelte tilfellet.

For å sikre tilgjengelighet er det viktig å sikre at klienter kobler seg til verten. La oss se på alternativene våre.

Sikre kundetilkobling

Vi har flere alternativer for hvordan vi kan dirigere klienter til hoveddelen av klyngen eller til fungerende noder (etter at en node svikter) etter tap av tilkobling. Først, la oss huske at en spesifikk kø er vert for en bestemt node, men ruting og policyer er replikert på tvers av alle noder. Klienter kan koble til en hvilken som helst node, og intern ruting vil lede dem dit de skal. Men når en node er suspendert, avviser den tilkoblinger, så klienter må koble til en annen node. Hvis noden faller av, er det lite han kan gjøre i det hele tatt.

Våre alternativer:

• Klyngen er tilgjengelig ved hjelp av en lastbalanser som ganske enkelt går gjennom nodene og klienter prøver å koble til på nytt til de lykkes. Hvis en node er nede eller suspendert, vil forsøk på å koble til den noden mislykkes, men påfølgende forsøk vil gå til andre servere (på en round-robin måte). Dette er egnet for et kortvarig tap av tilkobling eller en nedlagt server som raskt vil bli hentet opp igjen.
• Få tilgang til klyngen gjennom en lastbalanser og fjern suspenderte/mislykkede noder fra listen så snart de oppdages. Hvis vi gjør dette raskt, og hvis klienter kan prøve tilkoblingen på nytt, vil vi oppnå konstant tilgjengelighet.
• Gi hver klient en liste over alle noder, og klienten velger tilfeldig én av dem når han kobler til. Hvis den mottar en feil når den prøver å koble til, flytter den til neste node i listen til den kobles til.
• Fjern trafikk fra en mislykket/suspendert node ved hjelp av DNS. Dette gjøres ved hjelp av en liten TTL.

Funn

RabbitMQ clustering har sine fordeler og ulemper. De mest alvorlige ulempene er at:

• når de blir med i en klynge, forkaster noder dataene sine;
• blokkering av synkronisering fører til at køen blir utilgjengelig.

Alle vanskelige avgjørelser stammer fra disse to arkitektoniske trekkene. Hvis RabbitMQ kunne lagre data når klyngen slås sammen igjen, ville synkroniseringen være raskere. Hvis den var i stand til ikke-blokkerende synkronisering, ville den bedre støttet store køer. Å fikse disse to problemene vil i stor grad forbedre RabbitMQs ytelse som en feiltolerant og svært tilgjengelig meldingsteknologi. Jeg vil være nølende med å anbefale RabbitMQ med clustering i følgende situasjoner:

• Upålitelig nettverk.
• Upålitelig lagring.
• Veldig lange køer.

Når det gjelder innstillinger for høy tilgjengelighet, bør du vurdere følgende:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (eller autoheal)
• vedvarende meldinger
• sikre at klienter kobler til den aktive noden når en node svikter

For konsistens (datasikkerhet), vurder følgende innstillinger:

• Utgiver bekrefter og manuelle anerkjennelser på forbrukersiden
• ha-promote-on-failure=when-synced, hvis utgiverne kan prøve igjen senere og hvis du har svært pålitelig lagring! Ellers satt =always.
• ha-sync-mode=automatic (men for store inaktive køer kan manuell modus være nødvendig; vurder også om utilgjengelighet vil føre til at meldinger går tapt)
• Sett minoritetsmodus på pause
• vedvarende meldinger

Vi har ikke dekket alle spørsmålene om feiltoleranse og høy tilgjengelighet ennå; for eksempel hvordan du sikkert utfører administrative prosedyrer (som rullende oppdateringer). Vi må også snakke om føderasjon og Shovel-plugin.

Hvis jeg har gått glipp av noe annet, vennligst gi meg beskjed.

Se også min post, der jeg utfører en ødeleggelse på en RabbitMQ-klynge ved å bruke Docker og Blockade for å teste noen av scenariene for meldingstap beskrevet i denne artikkelen.

Tidligere artikler i serien:
nr. 1 - habr.com/ru/company/itsumma/blog/416629
nr. 2 - habr.com/ru/company/itsumma/blog/418389
nr. 3 - habr.com/ru/company/itsumma/blog/437446

Kilde: www.habr.com