Redis Sentinel

Stel dat u slechts één Redis-exemplaar in uw productie hebt en dat het op een bepaald moment om de een of andere reden mislukt. Uw toepassing slaat gegevens op in de Redis-gegevensopslag en nu is uw enige gegevensbron dood. Een manier om dit soort scenario's te beheersen, is door de master-slave-architectuur te behouden, waarbij slaves het masterknooppunt kunnen repliceren totdat het terugkomt. Redis-clusters ondersteunen tot op zekere hoogte hoge beschikbaarheid met de master-replica-benadering. Redis Sentinel is een andere benadering die een betrouwbaardere manier biedt om de hoge beschikbaarheid van Redis-instanties te behouden. Het bewaakt het Redis-masterknooppunt op fouten en activeert onmiddellijk het failover-proces, waardoor een bestaand slave-knooppunt wordt gepromoveerd tot een geheel nieuwe master.

Bovendien fungeert Redis-sentinel als tussenpersoon waar klanten verbinding maken en vragen om het nieuwste IP-adres van de Master node. De verbonden sentinel levert dus onmiddellijk het adres van de masternode.

Bovendien wordt een uitval van een masterknooppunt bevestigd als meerdere schildwachten het erover eens zijn dat een bepaalde master niet bereikbaar of beschikbaar is. Hiermee is de storingsdetectiefase afgesloten en begint het failoverproces meteen. De Sentinel van Redis kan dan ook worden gezien als een gedistribueerd systeem met specifieke eigenschappen.

De overeenkomst van schildwachten is gebaseerd op een quorumwaarde die in de volgende sectie zal worden besproken.

Wiens waarde?

De Quorum-waarde is het maximale aantal schildwachten dat moet worden overeengekomen wanneer het hoofdknooppunt niet beschikbaar is. Deze waarde wordt alleen gebruikt om een ​​storing in het hoofdknooppunt te identificeren. Het failoverproces begint met de autorisatie van meerdere beschikbare schildwachtknooppunten om door te gaan met een geselecteerde schildwacht als leider.

Kenmerken van Redis Sentinel

De schildwacht staat bekend om het leveren van een mechanisme met hoge beschikbaarheid voor de Redis-gegevensopslag. Afgezien daarvan kunnen verschillende andere mogelijkheden worden vermeld.

• Sentinel bewaakt continu de status van master- en slave-nodes in uw Redis-systeem.
• Wanneer er een storing is of er iets mis is met uw Redis-instanties, kan de Sentinel de beheerder of aangesloten applicaties op de hoogte stellen met behulp van de Sentinel API.
• De failover-fase wordt aangestuurd door de schildwacht door een replica te promoten als de nieuwe master. Resterende replica's die zijn geconfigureerd om de nieuwe master te gebruiken. Ten slotte zullen de corresponderende clients op de hoogte worden gebracht van het nieuwe masternode-adres.
• De Redis-sentinel is ook een configuratieprovider voor de verbonden clients waar clients kunnen vragen naar het adres van de momenteel beschikbare master-instantie en als er een plotselinge ineenstorting optreedt, is de schildwacht verplicht om het nieuwe master-node-adres onmiddellijk te pushen.

In de volgende sectie zullen we Redis-sentinels configureren met master-replica-instanties en de sentinel-API gebruiken om de knooppunten te bewaken.

Sentinel-configuratie

Eerst maken we twee Redis-instanties op poort 7000 en 7001. Poort 7000 wordt het masterknooppunt en de andere repliceert de master. Beide instanties gebruiken respectievelijk de volgende configuratiebestanden:

Configuratie hoofdknooppunt

Slave-knooppuntconfiguratie

Beide instanties beginnen met het verstrekken van het bijbehorende configuratiebestand. We kunnen de volgende opdracht gebruiken om Redis-instanties afzonderlijk te starten:

Laten we als volgt verbinding maken met de Redis-instantie die is gestart op poort 7001:

Nu kunnen we van deze instantie een replica maken van de master die op poort 7000 draait. De opdracht REPLICAOF kan als volgt worden gebruikt:

Zoals verwacht, werd de instantie die op poort 7001 werd uitgevoerd het replicaknooppunt van de master die op poort 7000 werd uitgevoerd.

Nu zijn we klaar om drie Redis-schildwachten te configureren om de bovenstaande hoofdinstantie te bewaken. We hebben drie configuratiebestanden nodig om drie sentinel-instanties op poorten 5000, 5001 en 5002 te maken, zoals hieronder wordt weergegeven.

Elk sentinel.conf bestand ziet er als volgt uit, behalve dat het poortnummer wordt gewijzigd:

Nu is het tijd om de drie schildwachten te leiden. U kunt het uitvoerbare bestand redis-sentinel gebruiken samen met het pad naar sentinel.conf configuratiebestand om een ​​sentinel-instantie te maken. Anders kunnen we het uitvoerbare bestand redis-server nog steeds aanroepen door het pad op te geven naar sentinel.conf en de vlag –schildwacht .

Laten we elke schildwacht starten met de volgende opdracht:

De eerste sentinel is gestart op poort 5000. Op dezelfde manier kunt u ook de andere twee instanties starten.

Nu is onze Redis-sentinelconfiguratie in gebruik, zoals weergegeven in de volgende afbeelding:

In de volgende sectie zullen we meer onderzoeken over Sentinel API en hoe we deze kunnen gebruiken om informatie op te halen met betrekking tot het Redis-hoofdknooppunt.

Sentinel-API

Redis biedt een afzonderlijke sentinel-API om de bijbehorende masters en replica's te bewaken, u te abonneren op meldingen en de sentinel-instellingen te wijzigen. Bovendien worden hieronder verschillende toepassingen vermeld.

• Controleer de status van de bewaakte Redis-master- en slave-instanties
• Details over andere schildwachten
• Ontvang push-achtige meldingen van schildwachten in het geval van een failover

De opdracht SENTINEL kan worden gebruikt met de bijbehorende subopdrachten om Redis-schildwachten en bewaakte knooppunten op te vragen, bij te werken of in te stellen.

Controleer de status van hoofdknooppunt

Het is erg belangrijk om de status van de masternode van tijd tot tijd te controleren of te controleren. De volgende sentinel API-opdracht kan worden gebruikt om hoofdgegevens op te halen:

monitor_master_name: De naam van het hoofdknooppunt dat is opgegeven in het sentinelconfiguratiebestand dat we in de eerdere stap hebben gemaakt.

Laten we deze opdracht gebruiken om de hoofdstatus op te vragen in onze setup. In ons geval is de naam van het hoofdknooppunt 'hoofdknooppunt'.

Er zijn verschillende stukjes informatie opgehaald en een paar daarvan zijn belangrijk, zoals aantal slaven, vlaggen en aantal andere schildwachten.

De vlaggen eigenschap is ingesteld op meester wat betekent dat de meester in goede gezondheid verkeert. Telkens wanneer het hoofdknooppunt niet beschikbaar is, wordt de s_down of o_down vlag wordt weergegeven. Het eigendom aantal-andere-schildwachten is ingesteld op 2, wat betekent dat de Redis-schildwacht de andere twee schildwachten voor het hoofdknooppunt al heeft herkend. tevens de aantal slaven eigenschap geeft de beschikbare replica's voor het hoofdknooppunt weer. In dit geval is het ingesteld op 1 omdat we maar één replica hebben.

Informatie krijgen over aangesloten replica's

We kunnen de replica's controleren die zijn verbonden met het hoofdknooppunt met behulp van de volgende SENTINEL-subopdracht:

In dit voorbeeld is de masternaam ‘masternode’.

Zoals verwacht, detecteerde de Sentinel het slave-knooppunt op poort 7001.

Krijg informatie over bijbehorende schildwachten

Op dezelfde manier kunnen we de details opvragen met betrekking tot andere schildwachten die zijn gekoppeld aan het huidige hoofdknooppunt met behulp van het volgende SENTINEL-subcommando:

In dit geval halen we de informatie op met betrekking tot het masterknooppunt met de naam 'masternode'.

Het hoofdknooppuntadres verkrijgen

Zoals vermeld in de eerdere sectie, is Redis sentinel een configuratieprovider voor verbonden clients. Het is dus in staat om het huidige IP-adres en de poort van het masterknooppunt aan de gevraagde clients te verstrekken. De volgende Sentinel API-subopdracht kan worden gebruikt om de genoemde informatie op te halen.

Laten we de bovenstaande opdracht voor ons scenario als volgt uitvoeren:

We hebben slechts enkele sentinel API-commando's besproken. Er zijn verschillende andere subcommando's beschikbaar, zoals sentinel-failover, sentinel info-cache, sentinelmasters, enz. Verder zijn er ook veel commando's beschikbaar om te gebruiken voor administratieve doeleinden. In de volgende sectie zullen we ons concentreren op het Redis-sentinel-failoverproces.

Sentinel-failoverproces

Omdat onze sentinel is geconfigureerd, kunnen we de failover-fase testen. Laten we ons hoofdknooppunt 300 seconden in slaapstand sturen, wat een storing in het hoofdknooppunt simuleert.

Het hoofdknooppunt dat op poort 7000 draait, zou nu onbereikbaar moeten zijn. Geassocieerde schildwachten zullen dus merken dat de master niet beschikbaar is met de +sdown evenement. Dit wordt dan ingesteld op +odown waarbij 2 schildwachten bevestigen dat het hoofdknooppunt niet beschikbaar is volgens de quorumwaarde. Ten slotte start de failover-fase en idealiter moet de replica worden gepromoveerd tot de nieuwe master.

Laten we het IP-adres van het hoofdknooppunt en de poort opnieuw controleren.

Zoals verwacht is de vorige replica gepromoveerd tot de nieuwe master, wat betekent dat het Sentinel-failoverproces is geslaagd. Hiermee is de implementatie en het testen van onze drie sentinel-opstellingen voor een enkel master-replicapaar afgerond.

Conclusie

Redis-sentinel is de meest betrouwbare benadering om de hoge beschikbaarheid van een bepaalde Redis-masterreplica-instantie te garanderen. Een sentinel is in staat om automatische failover te bewaken, te melden en te initiëren zonder menselijke tussenkomst. Ook zijn meerdere sentinels het samen eens over het feit dat de master node onbereikbaar is en wordt de quorumwaarde gebruikt als het maximale aantal sentinels dat moet worden afgesproken bij het controleren op de beschikbaarheid van de master instance. Redis sentinel biedt een gebruiksvriendelijke API om informatie op te halen over de status van het hoofdknooppunt en bijbehorende replica's en om ook administratieve taken uit te voeren.