Redis Sentinel-hög tillgänglighet: allt du behöver veta från DEV till PROD: komplett Guide

vad betyder termen ’Redis’ egentligen?

det betyder Fjärrordboksserver.

okej! Det finns många olika Redis-artiklar där ute, men jag ville dela min erfarenhet som utvecklare med Redis genom att skapa en ”all in one proper article” som täcker de viktigaste och viktigaste sakerna som behövs och hjälper en utvecklare eller en DevOps-ingenjör att bygga ett mycket tillgängligt Redis-kluster med Sentinel.

så låt oss komma igång …

Redis, som är en öppen källkod i minnesdatastrukturbutiken, är ett mycket populärt urval bland utvecklare som används för cachningsändamål, som meddelandemäklare och används också huvudsakligen som en NoSQL-Nyckelvärdedatabas för olika användningsfall.

i det här inlägget kommer jag specifikt att diskutera och demo om Redis tillsammans med Master/Slave Replication, hög tillgänglighet (Redis Sentinel), Automatisk Failover, vissa optimeringstips för produktionsnivå och övervakningsaspekter. Dessutom kommer jag tillsammans med dessa ämnen att nämna problemen och de fel som jag mötte under implementeringen av Redis Sentinel med Ubuntu. Följande visar OS-versionen och Redis version detaljer.

OS version: Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-119-generic x86_64)
Redis Version: 4.0.9

dessutom vill jag lyfta fram att Redis-dokumentationen är mycket informativ och det är’ the go to place ’ om du behöver ytterligare förtydligande om Redis.

går vidare till Redis basics; Redis är en databas i minnet, vilket helt enkelt betyder att Redis körs på RAM. Du måste också veta att Redis stöder flera datastrukturer som strängar, hashar, listor, uppsättningar, sorterade uppsättningar med intervallfrågor, bitmappar. Dessutom stöder den också atomoperationer som att lägga till en sträng, öka värdet i en hash, trycka ett element på en lista och etc.

Tja, låt oss komma igång med Redis hög tillgänglighet.

Redis sentinel är den höga tillgänglighetslösningen som erbjuds av Redis. I händelse av ett fel i ditt Redis-kluster upptäcker Sentinel automatiskt felpunkten och återför klustret till stabilt läge utan någon mänsklig intervention.

vad händer egentligen i Redis Sentinel ?

Sentinel kontrollerar alltid MASTER-och slav-instanserna i Redis-klustret och kontrollerar om de fungerar som förväntat. Om sentinel upptäcker ett fel i huvudnoden i ett givet kluster startar Sentinel en failover-process. Som ett resultat kommer Sentinel att välja en SLAVINSTANS och främja den för att behärska. I slutändan konfigureras de andra återstående SLAVINSTANSERNA automatiskt om för att använda den nya HUVUDINSTANSEN.

Sentinel fungerar som en konfigurationsleverantör eller en källa till auktoritet för kunder service upptäckt.

vad betyder det ? Enkelt, applikationsklienter ansluter till Sentinels och Sentinels ger den senaste Redis-huvudadressen till dem.

dessutom är Sentinel ett robust distribuerat system, där flera sentinels måste komma överens om att en viss master inte längre är tillgänglig. Då endast failover processen startar en välja en ny huvudnod. Detta sentinelavtal görs enligt kvorumvärdet.

vad är kvorum ?

kvorumvärdet är antalet vaktposter som måste komma överens om att befälhavaren inte kan nås. Kvorumet används dock bara för att upptäcka felet. För att faktiskt utföra en failover, en av Sentinels måste väljas ledare för failover och ha rätt att fortsätta. Detta händer bara med omröstningen av majoriteten av Sentinelprocesserna.

Låt oss få våra händer smutsiga med Redis Sentinel.

vi håller oss till grundinställningen med 3 serverinstanser.

se ovanstående diagram som illustrerar 3 serverinstans basic setup. Först och främst se till att dina Ubuntu-instanser är uppdaterade med relevanta byggberoenden. Ibland, du kanske behöver jemalloc också. Följande visar stegen för att installera Redis på dina serverinstanser.

sudo apt-get update 
sudo apt-get install build-essential tcl
sudo apt-get install libjemalloc-dev (Optional)curl -O http://download.redis.io/redis-stable.tar.gz
tar xzvf redis-stable.tar.gz
cd redis-stable
make
make test
sudo make install

nu i Redis-katalogen bör du kunna se båda redis.conf och sentinel.conf konfigurationsfiler.

innan vi kör Redis låt oss göra några nödvändiga grundläggande konfigurationer för att upp och köra en Redis kluster. Följande är IP-adresserna för denna inställning.

10.52.209.46 (Initial Master Node)
10.52.209.47 (Initial Slave Node)
10.52.209.49 (Initial Slave Node)

standardporten för Redis-servern är 6379 och Sentinel är 26379. Se därför till att du öppnar dessa portar med,

sudo ufw allow 6379
sudo ufw allow 26379

Redis-konfigurationerna (båda i redis.conf och sentinel.conf) i ovanstående servrar bör konfigureras enligt följande.

för den grundläggande inställningen ovan konfigurationer kommer att vara tillräckligt men för produktionsnivå kan du överväga de tips som nämns i den senare delen av detta inlägg. Den enda skillnaden i redis.conf filer i 3 servrar är att, alla slavar måste ha följande config. 10.52.209.46 är Huvud-IP-adressen.

slaveof 10.52.209.46 6379

slaveof berättar Redis cluster att göra denna speciella serverinstans som en SLAVINSTANS av den givna huvudnoden (10.52.209.46).

i vaktpost.conf, efter config meddela Sentinels för att starta klusterövervakningen med följande initiala inställningar. Därefter kan denna konfigurationsinställning uppdateras automatiskt i enlighet med detta.

sentinel monitor mymaster 10.52.209.46 6379 2
(This tells sentinel to monitor the master node. And the last argument which is 2 is the quorum value)

vidare, vaktpost.conf innehåller också följande konfigurationsvärden.

sentinel down-after-milliseconds mymaster 5000
(Means server will unresponsive for 5 seconds before being classified as +down and consequently activating a +vote to elect a new master node.)sentinel failover-timeout mymaster 10000
(Specifies the failover timeout in milliseconds.)

Okie Dokie! Nu kör vi Redis.

det finns många sätt att köra Redis. I denna demo ska jag hålla mig till följande kommando.

(Go to src folder.)
cd src/ && redis-server ../redis.conf &
cd src/ && redis-server ../sentinel.conf — sentinel &(Or else you can simply use cd utils && ./install_server.sh.)

därefter kan du helt enkelt kontrollera Redis-processerna via ps-ef | grep Redis-kommandot. Varje serverinstans bör köra både en Redis-process och en Sentinel-process. Om allt går till planen ska det finnas 2 processer som körs enligt följande.

Anslut nu till Redis-klienten via ett av följande kommando och testa om Redis fungerar bra.

redis-cli ping
or
redis-cli -h IP_Address pingYou should get a output of PONG.

Häftigt! Nu har du Redis igång. Låt oss fokusera på Master/Slave replication.

Master/Slave Replication

nu om du kontrollerar redis.log (som ligger på den plats vi definierade i redis.conf) i varje instans kan du få se Master — Slave-synkroniseringen inträffade.

huvudnod — redis.logga in

slavnod-redis.logga in

kontrollera Replikationsstatus

du kan också kontrollera replikationsinformationen via info replication-kommandot i Redis CLI. Under rollattributet nämns om den specifika noden är en mästare eller en slav (gul ruta).dessutom visar den i huvudnoden detaljerna för alla anslutna slavar. (grön ruta)

låt oss nu undersöka vad sentinel.logga ange. (som ligger på den plats vi definierade i sentinel.conf)

dessutom, om du kontrollerar sentinel.conf-fil, kan du få se att conf-fil uppdateras automatiskt med de senaste configs, inklusive Sentinel kända-slav och sentinel kända-sentinel värden.

coolt! Låt oss nu skapa ett provvärde i alla noder.

127.0.0.1:6739> set demokey "Amila"

som du kan se i ovanstående diagram läses slavar endast, så du kan bara skriva data för att behärska. Eftersom Redis asynkront replikerar med alla återstående slavar kan du hämta det infogade värdet från alla Redis-slavar med samma givna nyckel. Dessutom via,KEYS* kan du lista alla tangenter infogade. Ovanstående diagram beskriver tydligt vad vi just pratade om.

låt oss nu kolla hur Redis Sentinel Automatisk Failover fungerar.

Redis Sentinel Automatisk Failover

Okiee! Låt oss simulera ett automatiskt failover-scenario. För att simulera ett failover-scenario kan du helt enkelt stoppa Redis-servern eller döda Redis-processen i HUVUDINSTANSEN. Även du kan sova Redis-processen också. Du kan välja vad du vill.

kill -9 <process id>
or
redis-cli -p 6379 DEBUG sleep 30
or
redis-cli -p 6379 DEBUG SEGFAULT

som illustreras i ovanstående diagram, i ett failover-scenario, om huvudnoden misslyckas kommer de 2 återstående Sentinelsna att bestämma failover och om båda är överens (eftersom kvorumvärdet är 2 ), kommer en ny mästare att väljas från de 2 återstående noderna.

följande visar loggens svans för detta failover-scenario.

redis.logg över slavnoder.

sentinel.logg över slavnoder

låt oss nu leta efter replikationsstatus via info replication command.

ytterligare utarbetande av loggens svans,

varje Sentinel upptäcker master är nere med en +sdown händelse. (+sdown betyder att den angivna instansen nu är i subjektivt nedläge.)

+ ny epok betyder att den aktuella epoken uppdaterades.

+sdown händelse eskaleras senare till +odown, vilket innebär att flera Sentinels är överens om att mästaren inte kan nås. (+odown betyder att den angivna instansen nu är i objektivt nedläge.)

Sentinels +rösta på en Sentinel som startar det första failoverförsöket.

failover händer.

vidare, följande visar uppkomling jobb.

uppstart för Redis

description "Redis Server"start on runlevel 
stop on runlevel script
echo $$ > /var/run/redis.pid
su - amila -c "cd /home/amila/redis-stable/src/; redis-server ../redis.conf"
end scriptpost-stop script
rm -f /var/run/redis.pid
end script

uppstart för Sentinel

description "Redis Sentinel Server"start on runlevel 
stop on runlevel script
echo $$ > /var/run/redis.pid
su - amila -c "cd /home/amila/redis-stable/src/; redis-server ../sentinel.conf --sentinel"
end scriptpost-stop script
rm -f /var/run/redis.pid
end script

Grattis! Det är helt enkelt det. Så hanterar Redis hög tillgänglighet och automatisk Failover. Låt oss nu titta på några intressanta Redis-fakta innan vi hoppar in för att optimera tips och tricks.

intressanta fakta om Redis.

Redis kan hantera upp till 2 32 nycklar och testades i praktiken för att hantera minst 250 miljoner nycklar per instans.

en tom instans använder ~ 3 MB minne.

1 miljoner små nycklar- > Strängvärdespar använder ~ 85 MB minne.

1 miljon nycklar -> hashvärde, som representerar ett objekt med 5 fält, använder ~ 160 MB minne.

Redis är enkelgängad. Hur kan jag utnyttja flera CPU / kärnor?

det är inte så ofta att CPU blir din flaskhals med Redis, eftersom Redis vanligtvis är antingen minne eller nätverksbundet. Om så är fallet kommer horisontell eller vertikal skalning av Redis-instanser att bidra till att minska CPU-relaterade flaskhalsar.

Redis är en in-memory men ihållande på disk databas.

Redis Persistens – >RDB : punkt-i-tid-ögonblicksbilder av din dataset med angivna intervaller. (Data backup)| AOF : loggar varje skrivoperation som tas emot av servern. (Mer hållbar)

om du använder Java kan du använda Jedis som är en java-klient för att ansluta din Java-applikation med Redis. Obs: Jedis använder Apache Commons Pool för anslutning pooling (GenericObjectPool). A single Jedis instance is not threadsafe! för att undvika dessa problem, bör du använda Jedispoolsom är en threadsafe pool av nätverksanslutningar. Standard max anslutning pool storlek är 8.

nu ska vi fokusera på de frågor/fel som du kan få och vissa produktionsprestanda optimera tips och tricks för Redis.

problem/fel som du kan få & produktionsprestanda optimera tips och tricks

först av allt, i redis.conf och sentinel.conf, alla configs är i en ordning så att inte röra upp med ordern. Annars får du konfigurationsfel som följer.

*** FATAL CONFIG FILE ERROR ***
Reading the configuration file, at line 98
>>> 'sentinel down-after-milliseconds mymaster 5000'
No such master with specified name.

ur säkerhetsperspektiv, skapa ett lösenord för att autentisera med mästaren och slavarna. För detta kan du enkelt ändra redis.conf och sentinel.conf följaktligen med följande config värde.

In sentinel.conf
sentinel auth-pass <master-name> <password>In redis.conf
masterauth <master-password>

Makesute att TCP-backlog-inställningen (Max-anslutningar) är 511. Du kan ställa in det värdet i enlighet därmed (med tanke på din serverspecifikation) med följande steg.

sudo nano /etc/rc.local
Add this:
sysctl -w net.core.somaxconn=65535When you reboot the next time, the new setting will be to allow 65535 connections instead of 128 as before. When you add the line to rc.local make sure it's before the exit 0.

några av de varningar som du kan komma över från redis.log kan vara,

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.You can add this via following command as well as using a cat command you can makesure whether the value is set properly.echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
cat /etc/sysctl.conf

du kan behöva inaktivera THP eller Transparent enorm sida.

WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.Fixsudo nano /etc/rc.local
echo never > /sys/kernel/mm/transparent_hugepage/enabled

att använda UNIX-uttag istället för TCP-port 6379 kommer också att bidra till Redis-prestandaökning.

för att uppnå detta, redis.conf bör ändras till följande inställning.

unixsocket /var/run/redis.sock
unixsocketperm 777# Accept connections on the specified port, default is 6379.
# If port 0 is specified Redis will not listen on a TCP socket.
port 0

Dessutom kan du, beroende på ditt användningsfall, konfigurera alternativet Redis persistence också.

om du vill kan du inaktivera uthållighet alls om du vill att dina data bara ska existera så länge servern körs. Du kan inaktivera RDB-uthållighet genom att kommentera alla ”spara” rader i redis.conf enligt följande.

Comment out these 3 values in redis.conf
save 900 1
save 300 10
save 60 10000rdbcompression no
rdbchecksum no

AoF persistance (Append only File) är inaktiverat som standard i redis.conf.

appendonly no

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

övervakning av Redis

ur Övervakningsperspektiv finns det flera verktyg för att övervaka Redis. NewRelic ger avancerade funktioner för att övervaka och analysera Redis inklusive ”mest tid som förbrukas db operationer” , ”operationer genom genomströmning” , ”operationer genom frågestund” och etc.

mer information om New Relic Redis nämns här. Dessutom är Redis-stat också ett bra opensource Redis övervakningsverktyg.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

AWS ElasticCache

AWS erbjuder också en molntjänst i minnet med namnet” ElastiCache”, som också kommer med Redis ingår. Det kan anges som en effektiv, lättanvänd molntjänst, som avlastar de flesta manuella konfigurationer och administrativa uppgifter.

ElastiCache är en webbtjänst som gör det lättare att starta, hantera och skala en distribuerad cache i minnet i molnet.

intressant nog levereras den med fantastiska avancerade funktioner som Klusterläge med sharding inom några få klick, Multi-AZ med automatisk Failover, kryptering i vila, kryptering i transit, importera RDB-fil till S3, aktivera automatiska säkerhetskopior och många fler.

coolaste inslag i AWS ElastichCache är att det erbjuder en omfattande övervakning instrumentpanelen för din Redis kluster inklusive övervakning aspekter såsom CPU / minnesanvändning (Swap och Freeable minne), anslutning räkna, objekt räkna, vräkningar, sträng;Nyckel;Hash baserat kommando räkna, replikering eftersläpning och många fler.

Tja … det är ganska mycket det för det här inlägget!

som jag nämnde i början av det här inlägget finns det många olika Redis-artiklar där ute, men jag ville skapa en ”all in one proper article” som täcker de viktigaste fakta och tips som behövs och är till hjälp för en utvecklare eller en DevOps-ingenjör att bygga ett mycket tillgängligt Redis-kluster med Sentinel.

innan jag avslutade det här inlägget var en av de intressanta artiklarna som jag hittade hur Flickr implementerade Redis Sentinel. Var noga med att kontrollera det inlägget också.

okej. Så tack så mycket för att du läste den här artikeln och jag ser fram emot att komma med en annan intressant artikel snart och dela min erfarenhet som utvecklare. Tills dess, skål! och glad kodning!