Redis Sentinel

Antag et scenarie, hvor du kun har én Redis-instans i din produktion, og den fejler på et tidspunkt af en eller anden grund. Din applikation cacher data i Redis datalager, og nu er din eneste datakilde død. En måde at kontrollere denne slags scenarier på er at opretholde master-slave-arkitektur, hvor slaver kan replikere master-knuden, indtil den kommer tilbage. Redis-klynger understøtter høj tilgængelighed op til en vis grad med master-repica-tilgangen. Redis Sentinel er en anden tilgang, der giver en mere pålidelig måde at opretholde den høje tilgængelighed af Redis-instanser på. Den overvåger Redis masterknudepunktet for fejl og udløser failover-processen med det samme, hvilket vil promovere en eksisterende slaveknude til en helt ny master.

Ydermere fungerer Redis sentinel som en mellemmand, hvor klienter forbinder og beder om den seneste Master node IP-adresse. Så den tilsluttede vagtpost giver straks masterknudeadressen.

Derudover bekræftes en masterknudefejl, hvis flere vagtposter var enige om, at en given master ikke er tilgængelig eller tilgængelig. Dette afslutter fejlfindingsfasen, og failover-processen starter med det samme. Derfor kan Redis-vagten ses som et distribueret system med specifikke egenskaber.

Aftalen mellem vagtposter er baseret på en kvorumværdi, som vil blive diskuteret i det følgende afsnit.

hvis værdi

Quorum-værdien er det maksimale antal vagtposter, der skal aftales, når masternoden er nede. Denne værdi bruges kun til at identificere en fejl i masterknuden. Failover-processen starter med autorisation af flere tilgængelige vagtpostknuder til at fortsætte med en valgt vagtpost som leder.

Funktioner af Redis Sentinel

Sentinel er kendt for at levere en høj tilgængelighedsmekanisme til Redis datalager. Bortset fra det, kan flere andre funktioner angives.

• Sentinel overvåger løbende status for master- og slaveknudepunkter i dit Redis-system.
• Når der er en fejl eller noget galt med dine Redis-instanser, er sentinel i stand til at underrette administratoren eller tilsluttede applikationer ved hjælp af sentinel API.
• Failoverfasen styres af vagtposten ved at promovere en replika som den nye master. Resterende replikaer konfigureret til at bruge den nye master. Til sidst vil de tilsvarende klienter få besked om den nye masterknudeadresse.
• Redis sentinel er også en konfigurationsudbyder for de tilsluttede klienter, hvor klienter kan bede om adressen på den aktuelt tilgængelige masterinstans, og hvis der opstod et pludseligt sammenbrud, er vagtposten forpligtet til at skubbe den nye masterknudeadresse med det samme.

I næste afsnit vil vi konfigurere Redis-vagtposter med master-replik-forekomster og bruge sentinel-API'et til at overvåge noderne.

Sentinel konfiguration

Først opretter vi to Redis-instanser ved porte 7000 og 7001. Port 7000 vil være masterknudepunktet, og den anden replikerer masteren. Begge forekomster bruger henholdsvis følgende konfigurationsfiler:

Master Node Konfiguration

Konfiguration af slaveknude

Begge forekomster starter med at levere den konfigurationsfil, der er knyttet til hver. Vi kan bruge følgende kommando til at starte Redis-forekomster separat:

Lad os oprette forbindelse til Redis-instansen, der startede ved port 7001 som følger:

Nu kan vi gøre denne instans til en replika af masteren, som kører ved port 7000. Kommandoen REPLICAOF kan bruges som følger:

Som forventet blev den instans, der kørte ved port 7001, replikaknudepunktet for masteren, der kørte ved port 7000.

Nu er vi klar til at konfigurere tre Redis-vagter til at overvåge ovenstående masterinstans. Vi skal have tre konfigurationsfiler for at oprette tre sentinel-instanser ved porte 5000, 5001 og 5002 som vist i det følgende.

Hver sentinel.conf fil ser ud som følgende bortset fra at portnummeret vil blive ændret:

Nu er det tid til at køre de tre vagtposter. Du kan bruge den eksekverbare redis-sentinel sammen med stien til sentinel.conf konfigurationsfil for at oprette en sentinel-instans. Ellers kan vi stadig kalde redis-serveren eksekverbar ved at angive stien til sentinel.conf og flaget -vagtpost .

Lad os starte hver sentinel ved at bruge følgende kommando:

Den første vagtpost er startet ved port 5000. På samme måde kan du starte de to andre instanser.

Nu er vores Redis sentinel opsætning oppe og køre som vist i følgende illustration:

I det følgende afsnit vil vi udforske mere om Sentinel API, og hvordan vi kan bruge det til at hente information relateret til Redis master node.

Sentinel API

Redis leverer en separat sentinel API til at overvåge tilknyttede mastere og replikaer, abonnere på meddelelser og ændre sentinel-indstillingerne. Desuden er flere anvendelser anført i det følgende.

• Kontroller status for de overvågede Redis master- og slave-instanser
• Detaljer om andre vagtposter
• Modtag push-agtige meddelelser fra vagtposter i tilfælde af en failover

SENTINEL-kommandoen kan bruges med dens tilknyttede underkommandoer til at forespørge, opdatere eller indstille Redis-vagtposter og overvågede noder.

Tjek status for Master Node

Det er meget vigtigt at overvåge eller kontrollere masterknudesundheden fra tid til anden. Følgende sentinel API-kommando kan bruges til at hente masterdetaljer:

monitored_master_name: Navnet på masterknuden, der er angivet i vagtpostkonfigurationsfilen, som vi oprettede i det tidligere trin.

Lad os bruge denne kommando til at forespørge masterstatus i vores opsætning. I vores tilfælde er hovedknudenavnet 'masternode'.

Adskillige oplysninger er blevet hentet, og nogle få af dem er vigtige, såsom num-slaves, flag og num-other-sentinels.

Det flag egenskab er indstillet til mestre hvilket betyder, at mesteren er ved godt helbred. Når masternoden er nede, vil s_ned eller o_ned flag vil blive vist. Ejendommen num-andre-sentinels er sat til 2, hvilket betyder, at Redis-vagten allerede har genkendt de to andre vagtposter for masterknuden. Hertil kommer num-slaver egenskaben viser de tilgængelige replikaer for masternoden. I dette tilfælde er den sat til 1, da vi kun har én replika.

Få oplysninger om tilsluttede replikaer

Vi kan kontrollere replikaerne forbundet med masterknuden ved hjælp af følgende SENTINEL-underkommando:

I dette eksempel er masternavnet 'masternode'.

Som forventet opdagede Sentinel slaveknuden, der kører ved port 7001.

Få information om tilknyttede vagtposter

På samme måde kan vi forespørge på detaljerne relateret til andre vagtposter, der er knyttet til den aktuelle masterknude ved hjælp af følgende SENTINEL-underkommando:

I dette tilfælde henter vi informationen relateret til masterknuden ved navn 'masternode'.

Få masterknudeadressen

Som nævnt i det tidligere afsnit er Redis sentinel en konfigurationsudbyder til tilsluttede klienter. Så det er i stand til at levere den aktuelt kørende master node IP-adresse og port til de anmodede klienter. Følgende Sentinel API-underkommando kan bruges til at hente de nævnte oplysninger.

Lad os udføre ovenstående kommando for vores scenarie som følger:

Vi diskuterede kun nogle få sentinel API-kommandoer. Adskillige andre underkommandoer er tilgængelige såsom sentinel-failover, sentinel info-cache, sentinel masters, osv. Desuden er mange kommandoer også tilgængelige til brug til administrationsformål. I det følgende afsnit vil vi fokusere på Redis sentinel failover-processen.

Sentinel Failover-proces

Da vores sentinel er konfigureret, kan vi teste fail-over-fasen. Lad os sende vores masterknude i dvale i 300 sekunder, hvilket simulerer en fejl i masterknuden.

Masterknudepunktet, som kører ved port 7000, burde være utilgængeligt nu. Så tilknyttede vagtposter vil bemærke, at mesteren ikke er tilgængelig med +sned begivenhed. Derefter vil dette blive indstillet til +ned hvor 2 vagtposter bekræfter, at masterknudepunktet er nede i henhold til kvorumværdien. Til sidst vil failover-fasen starte, og ideelt set bør replikaen forfremmes til den nye master.

Lad os tjekke masterknudepunktets IP-adresse og porten igen.

Som forventet er den tidligere replika blevet forfremmet til den nye master, hvilket betyder, at sentinel failover-processen er vellykket. Dette afslutter implementeringen og testen af ​​vores tre sentinel-opsætninger for enkelt master-replika-par.

Konklusion

Redis sentinel er den mest pålidelige tilgang til at sikre den høje tilgængelighed af en given Redis master replika-instans. En vagtpost er i stand til at overvåge, underrette og starte automatisk failover uden menneskelig indgriben. Desuden er flere vagtposter tilsammen enige om, at masterknudepunktet ikke er tilgængeligt, og kvorumværdien bruges som det maksimale antal vagtposter, der skal aftales, når der kontrolleres for tilgængeligheden af ​​masterinstansen. Redis sentinel tilbyder en brugervenlig API til at hente oplysninger om tilstanden af ​​masterknuden og tilhørende replikaer og også udføre administrative opgaver.