Redis Sentinel

Anta ett scenario där du bara har en Redis-instans i din produktion och den misslyckas någon gång av någon anledning. Din applikation cachar data i Redis datalager och nu är din enda datakälla död. Ett sätt att kontrollera den här typen av scenarier är att upprätthålla master-slave-arkitektur där slavar kan replikera masternoden tills den kommer tillbaka. Redis-kluster stöder hög tillgänglighet upp till viss grad med master-repica-metoden. Redis Sentinel är ett annat tillvägagångssätt som ger ett mer tillförlitligt sätt att upprätthålla den höga tillgängligheten av Redis-instanser. Den övervakar Redis masternod för fel och utlöser failover-processen omedelbart vilket kommer att främja en befintlig slavnod till en helt ny master.

Dessutom fungerar Redis sentinel som en mellanhand där klienter ansluter och frågar efter den senaste IP-adressen för masternoden. Så den anslutna vaktposten tillhandahåller huvudnodens adress omedelbart.

Dessutom bekräftas ett masternodfel om flera sentinels kommit överens om att en given master inte är nåbar eller tillgänglig. Detta avslutar feldetekteringsfasen och failover-processen startar omedelbart. Därför kan Redis sentinel ses som ett distribuerat system med specifika egenskaper.

Överenskommelsen mellan sentinels baseras på ett kvorumvärde som kommer att diskuteras i följande avsnitt.

Vems värde

Quorum-värdet är det maximala antalet vaktposter som måste komma överens om när masternoden är nere. Detta värde används endast för att identifiera ett fel i masternoden. Failover-processen börjar med auktorisering av flera tillgängliga vaktpostnoder för att fortsätta med en vald vaktpost som ledare.

Funktioner hos Redis Sentinel

Sentineln är känd för att tillhandahålla en hög tillgänglighetsmekanism för Redis datalager. Bortsett från det kan flera andra funktioner listas.

• Sentinel övervakar kontinuerligt statusen för master- och slavnoder i ditt Redis-system.
• Närhelst det är ett fel eller något fel med dina Redis-instanser, kan sentinel meddela administratören eller anslutna applikationer med Sentinel API.
• Fasen för failover styrs av vaktposten genom att marknadsföra en replik som den nya mastern. Återstående repliker konfigurerade för att använda den nya mastern. Slutligen kommer motsvarande klienter att få meddelande om den nya huvudnodadressen.
• Redis sentinel är också en konfigurationsleverantör för de anslutna klienterna där klienter kan fråga efter adressen till den för närvarande tillgängliga huvudinstansen och om en plötslig kollaps inträffade, är vaktposten förpliktigad att skicka den nya masternodadressen omedelbart.

I nästa avsnitt kommer vi att konfigurera Redis sentinels med master-repica-instanser och använda sentinel API för att övervaka noderna.

Sentinel-konfiguration

Först skapar vi två Redis-instanser vid portarna 7000 och 7001. Port 7000 kommer att vara masternoden och den andra replikerar mastern. Båda instanserna använder följande konfigurationsfiler respektive:

Master Node Konfiguration

Konfiguration av slavnod

Båda instanserna börjar med att tillhandahålla den konfigurationsfil som är associerad med var och en. Vi kan använda följande kommando för att starta Redis-instanser separat:

Låt oss ansluta till Redis-instansen som startade vid port 7001 enligt följande:

Nu kan vi göra denna instans till en kopia av mastern som körs vid port 7000. Kommandot REPLICAOF kan användas enligt följande:

Som väntat blev instansen som kördes vid port 7001 replikanoden för mastern som kördes vid port 7000.

Nu är vi redo att konfigurera tre Redis-vaktposter för att övervaka ovanstående huvudinstans. Vi behöver ha tre konfigurationsfiler för att skapa tre sentinel-instanser vid portarna 5000, 5001 och 5002 som visas i följande.

Varje sentinel.conf filen ser ut som följande förutom att portnumret kommer att ändras:

Nu är det dags att köra de tre vaktposterna. Du kan använda redis-sentinel körbar tillsammans med sökvägen till sentinel.conf konfigurationsfil för att skapa en sentinel-instans. Annars kan vi fortfarande anropa redis-serverns körbara fil genom att ange sökvägen till sentinel.conf och flaggan -vakt .

Låt oss starta varje sentinel med följande kommando:

Den första sentinelen har startats vid port 5000. På samma sätt kan du starta de andra två instanserna också.

Nu är vår Redis sentinel-inställning igång som visas i följande illustration:

I följande avsnitt kommer vi att utforska mer om Sentinel API och hur vi kan använda det för att hämta information relaterad till Redis huvudnod.

Sentinel API

Redis tillhandahåller ett separat sentinel-API för att övervaka associerade masters och repliker, prenumerera på aviseringar och ändra sentinelinställningarna. Dessutom listas flera användningsområden i det följande.

• Kontrollera statusen för de övervakade Redis master- och slavinstanserna
• Detaljer om andra vaktposter
• Ta emot push-stil aviseringar från sentinels i händelse av en failover

SENTINEL-kommandot kan användas med tillhörande underkommandon för att fråga, uppdatera eller ställa in Redis-vaktposter och övervakade noder.

Kontrollera statusen för masternoden

Det är mycket viktigt att övervaka eller kontrollera masternodens hälsa då och då. Följande sentinel API-kommando kan användas för att hämta huvudinformation:

monitored_master_name: Namnet på masternoden som är specificerat i sentinel-konfigurationsfilen som vi skapade i det tidigare steget.

Låt oss använda det här kommandot för att fråga masterstatus i vår installation. I vårt fall är huvudnodens namn 'masternode'.

Flera bitar av information har hämtats och några av dem är viktiga som num-slaves, flaggor och num-other-sentinels.

De flaggor egenskapen är inställd på bemästra vilket betyder att befälhavaren är vid god hälsa. Närhelst masternoden är nere, visas s_ner eller o_ner flaggan kommer att visas. Egendomen num-other-sentinels är satt till 2 vilket betyder att Redis-vaktposten redan kände igen de andra två vaktposterna för masternoden. Dessutom har num-slavar egenskapen visar tillgängliga repliker för masternoden. I det här fallet är den inställd på 1 eftersom vi bara har en replik.

Få information om anslutna repliker

Vi kan kontrollera replikerna som är anslutna till masternoden med hjälp av följande SENTINEL-underkommando:

I det här exemplet är huvudnamnet 'masternode'.

Som väntat upptäckte Sentinel slavnoden som kördes vid port 7001.

Få information om associerade vaktposter

På liknande sätt kan vi fråga detaljerna relaterade till andra sentinels som är associerade med den aktuella huvudnoden med hjälp av följande SENTINEL-underkommando:

I det här fallet kommer vi att hämta informationen relaterad till masternoden som heter 'masternode'.

Skaffa huvudnodens adress

Som nämnts i det tidigare avsnittet är Redis sentinel en konfigurationsleverantör för anslutna klienter. Så den kan tillhandahålla den aktuella huvudnodens IP-adress och port till de begärda klienterna. Följande Sentinel API-underkommando kan användas för att hämta den nämnda informationen.

Låt oss utföra kommandot ovan för vårt scenario enligt följande:

Vi diskuterade bara några sentinel API-kommandon. Flera andra underkommandon är tillgängliga såsom sentinel-failover, sentinel info-cache, sentinel masters, etc. Dessutom finns många kommandon tillgängliga att använda för administrationsändamål också. I följande avsnitt kommer vi att fokusera på Redis sentinel failover-processen.

Sentinel Failover Process

Eftersom vår sentinel är konfigurerad kan vi testa fail-over-fasen. Låt oss skicka vår masternod i viloläge i 300 sekunder, vilket simulerar ett fel i masternoden.

Masternoden som körs vid port 7000 borde vara oåtkomlig nu. Så associerade vaktposter kommer att märka att befälhavaren inte är tillgänglig med +nedgång händelse. Sedan kommer detta att ställas in på +nedåt där 2 sentinels bekräftar att masternoden är nere enligt kvorumvärdet. Slutligen kommer failover-fasen att starta och helst bör repliken flyttas upp till den nya mastern.

Låt oss kontrollera huvudnodens IP-adress och porten igen.

Som väntat har den tidigare repliken flyttats upp till den nya mastern vilket betyder att sentinel failover-processen är framgångsrik. Detta avslutar driftsättningen och testningen av våra tre sentinel-inställningar för enstaka master-replika-par.

Slutsats

Redis sentinel är det mest tillförlitliga tillvägagångssättet för att säkerställa den höga tillgängligheten för en given Redis master replica-instans. En sentinel kan övervaka, meddela och initiera automatisk failover utan mänsklig inblandning. Dessutom är flera sentinels tillsammans överens om det faktum att masternoden är otillgänglig och kvorumvärdet används som det maximala antalet sentinels som måste komma överens om när man kontrollerar om masterinstansen är tillgänglig. Redis sentinel erbjuder ett lättanvänt API för att hämta information om tillståndet för masternoden och tillhörande repliker och även utföra administrativa uppgifter.