Redis Sentinel

Anta et scenario der du bare har en Redis -forekomst i produksjonen din, og det mislykkes på et tidspunkt på grunn av en eller annen grunn. Din applikasjonsbufferdata i Redis Data Store, og nå er din eneste datakilde død. En måte å kontrollere disse slags scenarier er å opprettholde master-slavearkitektur der slaver kan gjenskape 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 av Redis -forekomster. Det overvåker Redis Master -noden for feil og utløser Failover -prosessen umiddelbart som vil fremme en eksisterende slaveknute til en helt ny mester.

Videre fungerer Redis Sentinel som en middelmann der klienter kobler seg sammen og ber om den nyeste IP-adressen til Master Node. Så den tilkoblede Sentinel gir masternodeadressen umiddelbart.

I tillegg bekreftes en masternodesvikt hvis flere sentineller var enige om at en gitt master ikke er tilgjengelig eller tilgjengelig. Dette avslutter feildeteksjonsfasen. Derfor kan Redis Sentinel sees på som et distribuert system med spesifikke egenskaper.

Avtalen med Sentinels er basert på en quorumverdi som vil bli diskutert i følgende avsnitt.

Quorum -verdi

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

Funksjoner av Redis Sentinel

Sentinel er kjent for å gi en høy tilgjengelighetsmekanisme for Redis Data Store. Bortsett fra det kan flere andre muligheter oppføres.

• Sentinel overvåker kontinuerlig status som master- og slaveknuter i Redis -systemet ditt.
• Hver gang det er en fiasko eller noe galt med Redis -forekomstene dine, er Sentinel i stand til å varsle administratoren eller tilkoblede applikasjoner ved hjelp av Sentinel API.
• Failover -fasen er regissert av Sentinel ved å promotere en kopi som den nye mesteren. Gjenværende replikker konfigurert til å bruke den nye mesteren. Endelig vil de tilsvarende klientene bli varslet om den nye masternodeadressen.
• Redis Sentinel er også en konfigurasjonsleverandør for de tilkoblede klientene der klienter kan be om adressen til den for tiden tilgjengelige masterforekomsten, og hvis en plutselig kollaps oppstod, er Sentinel forpliktet til å skyve den nye masternodeadressen umiddelbart.

I neste avsnitt vil vi konfigurere Redis Sentinels med master-replica-forekomster og bruke Sentinel API for å overvåke nodene.

Sentinel -konfigurasjon

Først lager vi to Redis -forekomster i porter 7000 og 7001. Port 7000 kommer til å bli masternoden og den andre gjentar mesteren. Begge tilfeller bruker henholdsvis følgende konfigurasjonsfiler:

Master Node -konfigurasjon

Port 7000
Cluster-aktivert nei
Cluster-Config-fil-noder.konf
Cluster-Node-Timeout 5000
appendonly ja

Slaveknute -konfigurasjon

Port 7001
Cluster-aktivert nei
Cluster-Config-fil-noder.konf
Cluster-Node-Timeout 5000
appendonly ja

Begge tilfeller vil starte med å tilby konfigurasjonsfilen tilknyttet hver. Vi kan bruke følgende kommando for å starte Redis -forekomster hver for seg:

Redis-server Redis.konf

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

Redis -CLI -p 7001

Nå kan vi gjøre dette forekomst til en kopi av mesteren som kjører på Port 7000. Replicaof -kommandoen kan brukes som følger:

Replicaof 127.0.0.1 7000

Som forventet ble forekomsten som kjørte på port 7001 replikatnoden til masteren som kjørte på Port 7000.

Nå er vi klare til å konfigurere tre Redis Sentinels for å overvåke ovennevnte hovedforekomst. Vi må ha tre konfigurasjonsfiler for å lage tre Sentinel -forekomster på porter 5000, 5001 og 5002 som vist i det følgende.

Hver vakt.konf Fil ser ut som følgende bortsett fra at portnummeret vil bli endret:

Port 5000
Sentinel Monitor Masternode 127.0.0.1 7000 2
Sentinel ned-etter-millisekunder masternode 5000
Sentinel Failover-Timeout Masternode 60000

Nå er det på tide å kjøre de tre Sentinels. Du kan bruke Redis-Sentinel kjørbar sammen med veien til vakt.konf Konfigurasjonsfil for å opprette en Sentinel -forekomst. Ellers kan vi fremdeles kalle redis-serveren som kjøres ved å spesifisere banen til vakt.konf og flagget -vakt.

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

Redis-server Sentinel.Conf - -Sentinel

Den første Sentinel er startet ved port 5000. Tilsvarende kan du starte de to andre forekomstene også.

Nå er vårt Redis Sentinel -oppsett i gang som vist i følgende illustrasjon:

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

Sentinel API

Redis gir et eget Sentinel API for å overvåke tilknyttede mestere og kopier, abonnere på varsler og endre Sentinel -innstillingene. Videre er flere bruksområder oppført i det følgende.

• Sjekk statusen til den overvåkede Redis -mesteren og slaveforekomstene
• Detaljer om andre vaktposter
• Motta push-stil varsler fra Sentinels i en hendelse av en failover

Sentinel -kommandoen kan brukes med tilhørende underkommandoer for å spørre, oppdatere eller stille Redis Sentinels og overvåkede noder.

Sjekk statusen til Master Node

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

Sentinel Master

Monitored_master_name: Navnet på hovednoden som er spesifisert i Sentinel -konfigurasjonsfilen som vi opprettet i det tidligere trinnet.

La oss bruke denne kommandoen til å spørre hovedstatus i vårt oppsett. I vårt tilfelle er masternodenavnet 'Masternode'.

Sentinel Master Masternode

Flere informasjonsstykker er hentet, og noen få av dem er viktige, for eksempel num-slaver, flagg og num-andre-sentinels.

De flagg Eiendom er satt til herre Noe som betyr at mesteren er ved god helse. Hver gang masternoden er nede, er det s_down eller o_down Flagget vises. Eiendommen num-andre-sentinels er satt til 2, noe som betyr at Redis Sentinel allerede anerkjente de to andre Sentinels for masternoden. i tillegg num-slaver Eiendom viser tilgjengelige kopier for masternoden. I dette tilfellet er det satt til 1 siden vi bare har en kopi.

Få informasjon om tilkoblede replikker

Vi kan sjekke replikkene som er koblet til masternoden ved å bruke følgende Sentinel Sub -kommando:

Sentinel -replikker

I dette eksemplet er mesternavnet 'Masternode'.

Sentinel Replicas Masternode

Som forventet oppdaget Sentinel slaveknuten som kjørte ved port 7001.

Få informasjon om tilhørende Sentinels

Tilsvarende kan vi spørre om detaljene relatert til andre vaktposter tilknyttet den nåværende masternoden ved å bruke følgende Sentinel Subcommand:

Sentinel Sentinels

I dette tilfellet vil vi hente informasjonen relatert til masternoden som heter 'Masternode'.

Sentinel Sentinels Masternode

Få masternodeadressen

Som nevnt i den tidligere delen, er Redis Sentinel en konfigurasjonsleverandør for tilkoblede klienter. Så det er i stand til å tilby den for øyeblikket Running Master Node IP -adresse og port til de forespurte klientene. Følgende Sentinel API -underkommando kan brukes til å hente den nevnte informasjonen.

Sentinel Get-Master-Adddr-by-Name

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

Sentinel Get-Master-Addr-by-Name Masternode

Vi diskuterte bare noen få Sentinel API -kommandoer. Flere andre underkommandoer er tilgjengelige, for eksempel Sentinel-Failover, Sentinel Info-Cache, Sentinel Masters og etc. Videre er mange kommandoer også tilgjengelige for administrasjonsformål. I det følgende avsnittet vil vi fokusere på Redis Sentinel failover -prosessen.

Sentinel failover -prosess

Siden Sentinel er konfigurert, kan vi teste feilfasen. La oss sende vår masternode i dvale i 300 sekunder som simulerer en feil i masternoden.

Debug Sleep 300

Masternoden som kjører på port 7000, skal være utilgjengelig nå. Så tilknyttede Sentinels vil merke at mesteren ikke er tilgjengelig med +Sdown begivenhet. Deretter vil dette bli satt til +Odown der 2 seksjoner bekrefter at masternoden er nede i henhold til quorum -verdien. Til slutt vil failover -fasen starte, og ideelt sett bør kopien fremmes til den nye mesteren.

La oss sjekke IP -adressen til masternoden og porten igjen.

Sentinel Get-Master-Addr-by-Name Masternode

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

Konklusjon

Redis Sentinel er den mest pålitelige tilnærmingen for å sikre den høye tilgjengeligheten av en gitt Redis Master Replica -forekomst. En vakt. Også flere sentineller er sammen enige om det faktum at masternoden er utilgjengelig og quorumverdien brukes som det maksimale antallet vaktposter som må avtales når du sjekker for tilgjengeligheten av masterforekomsten. Redis Sentinel tilbyr et brukervennlig API for å hente informasjon om helsen til masternoden og tilknyttede kopier og utføre administrative oppgaver også.