Redis Sentinel

Anta et scenario der du bare har én Redis-forekomst i produksjonen din og den mislykkes på et tidspunkt av en eller annen grunn. Applikasjonen din bufrer data i Redis-datalageret, og nå er din eneste datakilde død. En måte å kontrollere denne typen scenarier på er å opprettholde master-slave-arkitektur der slaver kan replikere masternoden til den kommer tilbake. Redis-klynger støtter høy tilgjengelighet opp til en viss grad med master-replica-tilnærmingen. Redis Sentinel er en annen tilnærming som gir en mer pålitelig måte å opprettholde den høye tilgjengeligheten til Redis-forekomster på. Den overvåker Redis-masternoden for feil og utløser failover-prosessen umiddelbart som vil promotere en eksisterende slavenode til en helt ny master.

Videre fungerer Redis sentinel som en mellommann der klienter kobler til og ber om den nyeste IP-adressen for masternoden. Så den tilkoblede vaktposten gir hovednodens adresse umiddelbart.

I tillegg bekreftes en masternodefeil hvis flere vaktposter ble enige om at en gitt master ikke er tilgjengelig eller tilgjengelig. Dette avslutter feildeteksjonsfasen og failover-prosessen starter umiddelbart. Derfor kan Redis-vaktposten sees på som et distribuert system med spesifikke egenskaper.

Avtalen mellom vaktposter er basert på en quorumsverdi som vil bli diskutert i neste avsnitt.

Hvem sin verdi

Quorum-verdien er det maksimale antallet vaktposter som må avtales når masternoden er nede. Denne verdien brukes kun til å identifisere en feil i masternoden. Failover-prosessen starter med autorisasjon av flere tilgjengelige vaktpostnoder til å fortsette med en valgt vaktpost som leder.

Funksjoner av Redis Sentinel

Sentinelen er kjent for å tilby en høy tilgjengelighetsmekanisme for Redis-datalageret. Bortsett fra det kan flere andre funksjoner listes opp.

• Sentinel overvåker kontinuerlig statusen til master- og slavenoder i Redis-systemet ditt.
• Når det er en feil eller noe galt med Redis-forekomstene dine, er sentinel i stand til å varsle administratoren eller tilkoblede applikasjoner ved hjelp av sentinel API.
• Failoverfasen styres av vaktposten ved å promotere en kopi som den nye masteren. Gjenværende replikaer konfigurert til å bruke den nye masteren. Til slutt vil de korresponderende klientene bli varslet om den nye hovednodeadressen.
• Redis-vaktposten er også en konfigurasjonsleverandør for de tilkoblede klientene der klienter kan be om adressen til den nåværende tilgjengelige hovedforekomsten, og hvis en plutselig kollaps inntreffer, er vaktposten forpliktet til å sende den nye hovednodens adresse umiddelbart.

I neste seksjon vil vi konfigurere Redis-vaktposter med master-replika-forekomster og bruke sentinel API for å overvåke nodene.

Sentinel-konfigurasjon

Først lager vi to Redis-forekomster ved portene 7000 og 7001. Port 7000 kommer til å være masternoden og den andre replikerer masteren. Begge forekomstene bruker følgende konfigurasjonsfiler:

Konfigurasjon av hovednode

Konfigurasjon av slavenode

Begge forekomstene starter med å oppgi konfigurasjonsfilen knyttet til hver. Vi kan bruke følgende kommando for å starte Redis-forekomster separat:

La oss koble til Redis-forekomsten startet ved port 7001 som følger:

Nå kan vi gjøre denne instansen til en kopi av masteren som kjører på port 7000. REPLICAOF-kommandoen kan brukes som følger:

Som forventet ble forekomsten som kjørte på port 7001 replika-noden til masteren som kjørte på port 7000.

Nå er vi klare til å konfigurere tre Redis-vakter for å overvåke hovedforekomsten ovenfor. Vi må ha tre konfigurasjonsfiler for å lage tre sentinel-forekomster ved portene 5000, 5001 og 5002 som vist i det følgende.

Hver sentinel.conf filen ser ut som følgende bortsett fra at portnummeret vil bli endret:

Nå er det på tide å kjøre de tre vaktpostene. Du kan bruke den kjørbare redis-sentinel sammen med banen til sentinel.conf konfigurasjonsfil for å lage en vaktpostforekomst. Ellers kan vi fortsatt kalle redis-serveren kjørbar ved å spesifisere banen til sentinel.conf og flagget -vakt .

La oss starte hver sentinel ved å bruke følgende kommando:

Den første vaktposten er startet ved port 5000. På samme måte kan du starte de to andre instansene også.

Nå er Redis sentinel-oppsettet vårt oppe og går som vist i følgende illustrasjon:

I den følgende delen vil vi utforske mer om Sentinel API og hvordan vi kan bruke det til å hente informasjon relatert til Redis-masternoden.

Sentinel API

Redis tilbyr et eget sentinel-API for å overvåke tilknyttede mastere og replikaer, abonnere på varsler og endre sentinel-innstillingene. Videre er flere bruksområder listet opp i det følgende.

• Sjekk statusen til de overvåkede Redis master- og slaveforekomstene
• Detaljer om andre vaktposter
• Motta varsler i push-stil fra vaktposter i tilfelle en failover

SENTINEL-kommandoen kan brukes med tilhørende underkommandoer for å spørre, oppdatere eller sette Redis-vaktposter og overvåkede noder.

Sjekk statusen til masternoden

Det er veldig viktig å overvåke eller sjekke masternodens helse fra tid til annen. Følgende sentinel API-kommando kan brukes til å hente hoveddetaljer:

monitored_master_name: Navnet på masternoden som er spesifisert i konfigurasjonsfilen for sentinel som vi opprettet i det tidligere trinnet.

La oss bruke denne kommandoen til å spørre masterstatus i oppsettet vårt. I vårt tilfelle er hovednodens navn 'masternode'.

Flere opplysninger har blitt hentet, og noen få av dem er viktige som num-slaver, flagg og num-other-sentinels.

De flagg egenskapen er satt til herre som betyr at mesteren er ved god helse. Når masternoden er nede, vil s_ned eller o_ned flagget vil vises. Eiendommen num-andre-sentinels er satt til 2 som betyr at Redis-vaktposten allerede har gjenkjent de to andre vaktpostene for masternoden. i tillegg num-slaver egenskap viser tilgjengelige replikaer for masternoden. I dette tilfellet er den satt til 1 siden vi bare har én replika.

Få informasjon om tilkoblede replikaer

Vi kan sjekke replikaene som er koblet til masternoden ved å bruke følgende SENTINEL-underkommando:

I dette eksemplet er hovednavnet 'masternode'.

Som forventet oppdaget Sentinel slavenoden som kjørte på port 7001.

Få informasjon om tilknyttede vaktposter

På samme måte kan vi spørre etter detaljene knyttet til andre vaktposter knyttet til den gjeldende hovednoden ved å bruke følgende SENTINEL-underkommando:

I dette tilfellet henter vi informasjonen knyttet til masternoden kalt 'masternode'.

Skaff Master Node-adressen

Som nevnt i den tidligere delen, er Redis sentinel en konfigurasjonsleverandør for tilkoblede klienter. Så den er i stand til å gi den aktuelle hovednodens IP-adresse og port til de forespurte klientene. Følgende Sentinel API-underkommando kan brukes til å hente den nevnte informasjonen.

La oss utføre kommandoen ovenfor for vårt scenario som følger:

Vi diskuterte bare noen få sentinel API-kommandoer. Flere andre underkommandoer er tilgjengelige som sentinel-failover, sentinel info-cache, sentinel masters, osv. Videre er mange kommandoer tilgjengelige for bruk for administrasjonsformål også. I den følgende delen vil vi fokusere på Redis sentinel failover-prosessen.

Sentinel Failover-prosess

Siden vaktposten vår er konfigurert, kan vi teste fail-over-fasen. La oss sende masternoden vår i dvale i 300 sekunder, noe som simulerer en feil i masternoden.

Hovednoden som kjører på port 7000 skal være utilgjengelig nå. Så tilknyttede vaktposter vil legge merke til at masteren ikke er tilgjengelig med +ned begivenhet. Deretter vil dette bli satt til +ned hvor 2 vaktposter bekrefter at masternoden er nede i henhold til quorum-verdien. Til slutt vil failover-fasen starte, og ideelt sett bør replikaen forfremmes til den nye masteren.

La oss sjekke masternodens IP-adresse og porten på nytt.

Som forventet har den forrige kopien blitt forfremmet til den nye masteren, noe som betyr at sentinel failover-prosessen er vellykket. Dette avslutter distribusjonen og testingen av våre tre sentinel-oppsett for enkelt master-replika-par.

Konklusjon

Redis sentinel er den mest pålitelige tilnærmingen for å sikre høy tilgjengelighet for en gitt Redis-masterreplika-forekomst. En vaktpost er i stand til å overvåke, varsle og starte automatisk failover uten menneskelig innblanding. Dessuten er flere vaktposter sammen enige om det faktum at masternoden er utilgjengelig og quorumsverdien brukes som det maksimale antallet vaktposter som må avtales når man sjekker tilgjengeligheten til masterforekomsten. Redis sentinel tilbyr en brukervennlig API for å hente informasjon om helsen til masternoden og tilhørende replikaer og utføre administrative oppgaver også.