Redis Sentinel – høj tilgængelighed: alt hvad du behøver at vide fra DEV til PROD: komplet Guide

hvad betyder udtrykket ‘Redis’ faktisk?

det betyder Fjernordbogsserver.

okay! Der er masser af forskellige Redis-artikler derude, men jeg ville dele min erfaring som udvikler med Redis ved at oprette en “alt i en ordentlig artikel”, der dækker de mest vigtige og vigtige ting, der er nødvendige og nyttige for en udvikler eller en devops-ingeniør til at opbygge en meget tilgængelig Redis-klynge med Sentinel.

så lad os komme i gang…

Redis, som er en open source i hukommelsesdatastrukturbutik, er et meget populært valg blandt udviklere, der bruges til cachingformål, som en meddelelsesmægler og også hovedsageligt brugt som en noskl-nøgleværdidatabase til forskellige brugssager.

i dette indlæg vil jeg specifikt diskutere og demo om Redis sammen med Master/Slave replikation, høj tilgængelighed (Redis Sentinel), automatisk Failover, nogle produktionsniveau optimering tips og overvågning aspekter. Derudover vil jeg sammen med disse emner nævne de problemer og de fejl, jeg stod overfor under implementeringen af Redis Sentinel med Ubuntu. Følgende viser OS version og Redis version detaljer.

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

derudover vil jeg fremhæve, at Redis-dokumentationen er meget informativ, og det er ‘gå til sted’, hvis du har brug for yderligere afklaring på Redis.

flytning frem til Redis basics; Redis er en in-memory database, simpelthen hvilket betyder Redis kører på RAM. Du skal også vide, at Redis understøtter flere datastrukturer såsom strenge, hashes, lister, sæt, sorterede sæt med rækkeforespørgsler, bitmaps. Desuden understøtter det også atomoperationer såsom at tilføje en streng, øge værdien i en hash, skubbe et element til en liste osv.

Nå, lad os få tingene i gang med Redis høj tilgængelighed.

Redis sentinel er den høje tilgængelighed løsning, der tilbydes af Redis. I tilfælde af en fejl i din Redis-klynge registrerer Sentinel automatisk fejlpunktet og bringer klyngen tilbage til stabil tilstand uden nogen menneskelig indgriben.

Hvad sker der virkelig inde i Redis Sentinel ?

Sentinel kontrollerer altid MASTER-og SLAVEFOREKOMSTERNE i Redis-klyngen og kontrollerer, om de arbejder som forventet. Hvis sentinel registrerer en fejl i MASTERNODEN i en given klynge, starter Sentinel en failover-proces. Som et resultat vælger Sentinel en SLAVEINSTANS og promoverer den til at mestre. I sidste ende konfigureres de andre resterende SLAVEFOREKOMSTER automatisk til at bruge den nye MASTERINSTANS.

Sentinel fungerer som en konfigurationsudbyder eller en kilde til autoritet for klientserviceopdagelse.

hvad betyder det ? Simpelthen, ansøgning klienter forbindelse til Sentinels og Sentinels give den nyeste Redis MASTER adresse til dem.

desuden er Sentinel et robust distribueret system, hvor flere sentinels skal acceptere det faktum, at en given master ikke længere er tilgængelig. Så kun failover processen starter en udvalgt en ny MASTER node. Denne sentinel-aftale udføres i henhold til kvorumsværdien.

hvad er beslutningsdygtighed ?

kvorumværdien er antallet af sentineller, der skal være enige om, at mesteren ikke kan nås. Kvorummet bruges dog kun til at opdage fejlen. For faktisk at udføre en failover skal en af Sentinels vælges til leder for failover og have tilladelse til at fortsætte. Dette sker kun med afstemningen af flertallet af Sentinelprocesserne.

lad os få vores hænder beskidte med Redis Sentinel.

vi holder os til den grundlæggende opsætning med 3 serverforekomster.

se ovenstående diagram, der illustrerer 3 serverforekomst grundlæggende opsætning. Først og fremmest skal du sørge for, at dine Ubuntu-forekomster er opdaterede med relevante build-afhængigheder. Nogle gange har du muligvis også brug for jemalloc. Følgende viser trinnene for at installere Redis på dine serverforekomster.

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-biblioteket skal du kunne se begge redis.conf og sentinel.conf konfigurationsfiler.

før vi kører Redis lad os gøre nogle nødvendige grundlæggende konfigurationer til op og køre en Redis klynge. Følgende er IP-adresserne for denne opsætning.

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

standardporten for Redis-serveren er 6379, og Sentinel er 26379. Sørg derfor for at åbne disse porte ved hjælp af,

sudo ufw allow 6379
sudo ufw allow 26379

Redis-konfigurationerne (begge i redis.conf og sentinel.conf) i ovenstående servere skal konfigureres som følger.

for den grundlæggende opsætning ovenfor konfigurationer vil være nok, men for produktionsniveau kan du overveje de tips, der er nævnt i den sidste del af dette indlæg. Den eneste forskel i redis.conf filer i 3 servere er, at alle slaverne skal have følgende config. 10.52.209.46 er den primære IP-adresse.

slaveof 10.52.209.46 6379

slaveof fortæller Redis cluster at gøre denne særlige serverinstans som en SLAVEFOREKOMST af den givne masternode (10.52.209.46).

i sentinel.conf, efter config underrette Sentinels at starte klynge overvågning med følgende indledende indstillinger. Derefter opdateres denne konfigurationsindstilling muligvis automatisk i overensstemmelse hermed.

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)

yderligere, sentinel.conf inkluderer også følgende konfigurationsværdier.

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! Lad os køre Redis.

der er mange måder at køre Redis på. I denne demo vil jeg holde mig til følgende 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.)

derefter kan du blot kontrollere Redis-processerne via ps-ef | grep redis-kommandoen. Hver serverinstans skal køre både en Redis-proces og en Sentinel-proces. Hvis alt går til planen, skal der være 2 processer, der kører som følger.

Opret nu forbindelse til Redis-klienten via en af følgende kommandoer, og test, om Redis fungerer fint.

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

fantastisk! Nu har du Redis i gang. Lad os fokusere på Master/Slave replikation.

Master/Slave replikation

nu, hvis du tjekker redis.log (som er placeret på det sted, vi definerede i redis.conf) af hvert tilfælde kan du se, at Master — Slave-synkroniseringen opstod.

Master node — redis.log

Slave node-redis.log

kontrol af Replikationsstatus

du kan også kontrollere replikationsoplysningerne via info replication command I Redis cli. Under rolleattributten nævnes det, om den pågældende knude er en mester eller en SLAVE (gul boks).derudover viser den i Masternoden detaljerne for alle de tilsluttede slaver. (grøn boks)

lad os nu undersøge, hvad sentinel.log angive. (som er placeret på det sted, vi definerede i sentinel.conf)

Desuden, hvis du tjekker sentinel.conf fil, kan du få at se, at conf fil opdateres automatisk med de nyeste configs, herunder sentinel kendte-slave og Sentinel kendte-sentinel værdier.

sejt! Lad os nu oprette en prøveværdi i alle noder.

127.0.0.1:6739> set demokey "Amila"

som du kan se i ovenstående diagram, er slaver kun læst, derfor kan du kun skrive data til Master. Da Redis asynkront replikerer med alle de resterende slaver, kan du hente den indsatte værdi fra alle Redis-slaver ved hjælp af den samme givne nøgle. Derudover via,KEYS* du kan liste alle de indsatte taster. Ovenstående diagram beskriver klart, hvad vi lige har talt om.

lad os nu kontrollere, hvordan Redis Sentinel Automatic Failover fungerer.

Redis Sentinel Automatisk Failover

Okiee! Lad os simulere et automatisk failover-scenarie. For at simulere et failover-scenarie kan du blot stoppe Redis-serveren eller dræbe Redis-processen i MASTERINSTANSEN. Selv Du kan sove Redis-processen også. Du kan vælge, hvad den måde, du ønsker.

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

som illustreret i ovenstående diagram, i et failover-scenarie, hvis masternode mislykkes, bestemmer de 2 resterende Sentinels failover, og hvis begge er enige (da kvorumsværdien er 2), vælges en ny MASTER blandt de 2 resterende noder.

Følgende viser log hale for denne failover scenario.

redis.log af Slave noder.

sentinel.log af Slave noder

lad os nu kontrollere for replikationsstatus via info replication kommando.

yderligere uddybning af loghalen,

hver Sentinel opdager, at mesteren er nede med en +sdown begivenhed. (+sned betyder, at den angivne forekomst nu er i subjektivt ned tilstand.)

+ny-epoke betyder, at den aktuelle epoke blev opdateret.

+sdown begivenheden eskaleres senere til +odown, hvilket betyder, at flere sentineller er enige om, at mesteren ikke kan nås. det betyder, at den angivne forekomst nu er i objektivt ned tilstand.)

Sentinels +stem en Sentinel, der starter det første failover-forsøg.

failover sker.

yderligere, Følgende viser upstart job.

Upstart for 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

Upstart for 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

Tillykke! Det er simpelthen det. Sådan håndterer Redis høj tilgængelighed og automatisk Failover. Lad os nu få et kig på nogle interessante Redis fakta, før vi hopper i at optimere tips og tricks.

interessante fakta om Redis.

Redis kan håndtere op til 2 32 nøgler og blev testet i praksis for at håndtere mindst 250 millioner nøgler pr.

en tom forekomst bruger ~ 3 MB hukommelse.

1 Million små taster -> String værdi par bruger ~ 85MB hukommelse.

1 Million nøgler- > hashværdi, der repræsenterer et objekt med 5 felter, brug ~ 160 MB hukommelse.

Redis er enkelt gevind. Hvordan kan jeg udnytte flere CPU / kerner?

det er ikke meget hyppigt, at CPU bliver din flaskehals med Redis, som normalt Redis er enten hukommelse eller netværk bundet. Hvis det er tilfældet, vil vandret eller lodret skalering af Redis-forekomster bidrage til at reducere CPU-relaterede flaskehalse.

Redis er en in-memory, men vedholdende på disk database.

Redis Persistens – >RDB : point-in-time snapshots af dit datasæt med bestemte intervaller. (Data backup)| AOF : logger hver skrive operation modtaget af serveren. (Mere holdbar)

hvis du bruger Java, kan du bruge Jedis, som er en java-klient, til at forbinde dit Java-program med Redis. Bemærk: Jedis bruger Apache Commons Pool til forbindelse pooling (GenericObjectPool). A single Jedis instance is not threadsafe! for at undgå disse problemer, bør du bruge JedisPool, som er en threadsafe pulje af netværksforbindelser. Standard maks tilslutning pool størrelse er 8.

lad os nu fokusere på de problemer/fejl, du måtte få, og nogle produktionsydelsesoptimerende tip og tricks til Redis.

problemer/fejl, som du muligvis får& produktionsydelse optimering af tip og tricks

først og fremmest i redis.conf og sentinel.conf, alle configs er i en rækkefølge, så ikke rod op med ordren. Ellers får du konfigurationsfejl som følger.

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

fra sikkerhedsperspektiv skal du oprette en adgangskode til godkendelse med master og slaver. Til dette kan du nemt ændre redis.conf og sentinel.conf følgelig med følgende config værdi.

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

gør det klart, at TCP-backlogindstillingen (maks.forbindelser) er 511. Du kan indstille denne værdi i overensstemmelse hermed (i betragtning af din serverspecifikation) med følgende trin.

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.

nogle af de advarsler, som du måske støder på fra redis.log kan være,

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 skal muligvis deaktivere THP eller gennemsigtig enorm side.

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

brug af unik stik i stedet for TCP-port 6379 vil også bidrage til Redis performance gain.

for at opnå dette, redis.conf bør ændres til følgende indstilling.

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

afhængigt af din brugssag kan du også konfigurere Redis persistence-indstillingen.

hvis du ønsker det, kan du deaktivere persistens overhovedet, hvis du vil have dine data bare til at eksistere, så længe serveren kører. Bemærk: Du kan deaktivere RDB persistens ved at kommentere alle “Gem” linjer i redis.conf som følger.

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

AOF persistance (tilføj kun fil) er deaktiveret som standard i redis.conf.

appendonly no

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

overvågning Redis

fra Overvågningsperspektiv er der flere værktøjer til overvågning af Redis. Nyrelic giver forhåndsfunktioner til at overvåge og analysere Redis inklusive “mest tidsforbrugte db-operationer” , “operationer efter gennemstrømning” , “operationer efter forespørgselstid” osv.

mere information om nye Relic Redis er nævnt her. Derudover er Redis-stat også et godt opensource Redis overvågningsværktøj.

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

av ElasticCache

av tilbyder også en cloud-tjeneste i hukommelsen med navnet “ElastiCache”, som også leveres med Redis inkluderet. Det kan specificeres som en effektiv brugervenlig skytjeneste, der aflaster de fleste af de manuelle konfigurationer og administrative opgaver.

ElastiCache er en internettjeneste, der gør det nemmere at starte, administrere og skalere en distribueret cache i hukommelsen i skyen.

interessant nok leveres det med fantastiske avancerede funktioner såsom Klyngetilstand med sharding inden for få klik, Multi-AES med Auto-Failover, kryptering i hvile, kryptering i transit, Import RDB-fil til S3, aktiver automatiske sikkerhedskopier og mange flere.

Det tilbyder et omfattende overvågningspanel til din Redis-klynge, herunder overvågningsaspekter som CPU/hukommelsesudnyttelse (bytte og fri hukommelse), Tilslutningstælling, Varetælling, udsættelser, streng;nøgle;Hashbaseret Kommandotælling, Replikationsforsinkelse og mange flere.

nå … det er stort set det for dette indlæg!

som jeg nævnte i begyndelsen af dette indlæg, er der masser af forskellige Redis-artikler derude, men jeg ønskede at oprette en “alt i en ordentlig artikel”, der dækker de mest væsentlige fakta og tip, der er nødvendige og nyttige for en udvikler eller en devops-ingeniør til at opbygge en meget tilgængelig Redis-klynge med Sentinel.

før jeg afsluttede dette indlæg, var en af de interessante artikler, jeg fandt, hvordan Flickr implementerede Redis Sentinel. Sørg også for at tjekke dette indlæg.

okay. Så tak så meget for at læse denne artikel, og jeg ser frem til snart at komme med en anden interessant artikel og dele min erfaring som udvikler. Indtil da, skål! glad kodning!