Redis Sentinel-disponibilitate ridicată: tot ce trebuie să știți de la DEV la PROD: ghid complet

ce înseamnă de fapt termenul ‘Redis’?

înseamnă server de dicționar la distanță.

bine! Există o mulțime de articole Redis diferite, dar am vrut să împărtășesc experiența mea Ca dezvoltator cu Redis, creând un „articol all in one proper” care acoperă cele mai esențiale și importante lucruri necesare și utile pentru un dezvoltator sau un inginer devops pentru a construi un cluster Redis extrem de disponibil cu Sentinel.

deci, să începem…

Redis, care este o sursă deschisă în memoria data structure store, este o selecție foarte populară în rândul dezvoltatorilor utilizați în scopuri de cache, ca broker de mesaje și, de asemenea, utilizat în principal ca bază de date cu valori cheie NoSQL pentru diferite cazuri de utilizare.

în acest post, voi discuta în mod specific și demo despre Redis împreună cu replicarea Master/Slave, disponibilitate ridicată (Redis Sentinel), Failover automat , unele sfaturi de optimizare a nivelului de producție și aspecte de monitorizare. În plus, împreună cu aceste subiecte voi menționa problemele și erorile cu care m-am confruntat în timpul implementării Redis Sentinel cu Ubuntu. În urma arată versiunea sistemului de operare și Redis detalii versiune.

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

în plus, vreau să subliniez că documentația Redis este foarte informativ și este ‘du-te la loc’ dacă aveți nevoie de clarificări suplimentare pe Redis.

Mergând mai departe la elementele de bază ale Redis; Redis este o bază de date în memorie, pur și simplu ceea ce înseamnă că Redis rulează pe RAM. De asemenea, trebuie să știți că Redis acceptă mai multe structuri de date, cum ar fi șiruri, hash-uri, liste, seturi, seturi sortate cu interogări de gamă, bitmap-uri. În plus, aceasta susține, de asemenea, operațiuni atomice, cum ar fi, adăugarea la un șir de caractere, incrementarea valoarea într-un hash, împingând un element la o listă și etc.

Ei bine, să începem cu Redis disponibilitate ridicată.

Redis sentinel este soluția de înaltă disponibilitate oferită de Redis. În cazul unei defecțiuni în clusterul Redis, Sentinel va detecta automat punctul de eșec și va readuce clusterul în modul stabil fără nicio intervenție umană.

ce se întâmplă cu adevărat în Redis Sentinel ?

Sentinel verifică întotdeauna instanțele MASTER și SLAVE din clusterul Redis, verificând dacă funcționează conform așteptărilor. Dacă sentinel detectează o eroare în nodul MASTER într-un cluster dat, Sentinel va începe un proces de failover. Drept urmare, Sentinel va alege o instanță SLAVE și o va promova pentru a stăpâni. În cele din urmă, celelalte instanțe SLAVE rămase vor fi reconfigurate automat pentru a utiliza noua instanță MASTER.

Sentinel acționează ca un furnizor de configurare sau o sursă de autoritate pentru descoperirea serviciului clienților.

ce înseamnă asta ? Pur și simplu, clienții de aplicații se conectează la Sentinelele și Sentinelele le oferă cea mai recentă adresă Redis MASTER.

mai mult, Sentinel este un sistem distribuit robust, în care mai multe sentineluri trebuie să fie de acord cu privire la faptul că un anumit maestru nu mai este disponibil. Apoi, numai procesul de failover începe o selectați un nou nod de MASTER. Acest Acord de santinelă se face în funcție de valoarea cvorumului.

ce este cvorumul ?

valoarea cvorumului este numărul de santinele care trebuie să convină asupra faptului că maestrul nu este accesibil. Cu toate acestea, cvorumul este folosit doar pentru a detecta eșecul. Pentru a efectua efectiv un failover, unul dintre santinele trebuie să fie ales lider pentru failover și să fie autorizat să continue. Acest lucru se întâmplă numai cu votul majorității proceselor Sentinel.

să ne murdărim mâinile cu Redis Sentinel.

vom rămâne la configurarea de bază cu 3 instanțe de server.

vă rugăm să consultați diagrama de mai sus, care ilustrează configurarea de bază a instanței de server 3. În primul rând, asigurați-vă că instanțele Ubuntu sunt actualizate cu dependențele relevante de construire. Uneori, s-ar putea fi nevoie de jemalloc, de asemenea. În urma arată pașii pentru a instala Redis pe instanțele de server.

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

acum, în directorul redis, ar trebui să puteți vedea ambele redis.conf și sentinel.conf fișiere de configurare.

înainte de a rula Redis să facem câteva configurații de bază necesare pentru a rula un cluster Redis. Următoarele sunt adresele IP ale acestei configurații.

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

portul implicit pentru Redis server este 6379 și Sentinel este 26379. Prin urmare, asigurați-vă că deschideți aceste porturi folosind,

sudo ufw allow 6379
sudo ufw allow 26379

configurațiile Redis (ambele în redis.conf și sentinel.conf) în serverele de mai sus ar trebui să fie configurate după cum urmează.

pentru configurarea de bază de mai sus configurațiile vor fi suficiente, dar pentru nivelul de producție vă rugăm să luați în considerare sfaturile menționate în ultima parte a acestui post. Singura diferență în redis.fișiere conf în 3 servere este că, toți sclavii trebuie să aibă următoarea configurare. 10.52.209.46 este adresa IP principală.

slaveof 10.52.209.46 6379

slaveof îi spune clusterului Redis să facă această instanță de server particulară ca instanță sclavă a nodului MASTER dat (10.52.209.46).

în sentinel.conf, în urma config notifica Sentinels pentru a începe monitorizarea cluster cu următoarele setări inițiale. Ulterior, această setare de configurare poate fi actualizată automat în consecință.

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)

mai departe, sentinel.conf include următoarele valori de configurare, de asemenea.

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! Acum … să rulăm Redis.

există mai multe moduri de a rula Redis. În acest demo voi lipi la următoarea comandă.

(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.)

după aceea, puteți verifica pur și simplu procesele Redis prin comanda ps-ef | grep redis. Fiecare instanță de server ar trebui să ruleze atât un proces Redis, cât și un proces Sentinel. Dacă totul merge la plan, ar trebui să existe 2 procese care rulează după cum urmează.

acum conectați-vă la clientul Redis printr-una din următoarele comenzi și testați dacă Redis funcționează bine.

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

minunat! Acum ai Redis în sus și să fie difuzate. Să ne concentrăm pe replicarea Master / Slave.

replicare Master/Slave

acum, dacă verificați redis.jurnal (care se află în locul pe care l-am definit în redis.conf) din fiecare instanță, puteți vedea sincronizarea Master-Slave.

maestru nod — redis.jurnal

nodul Sclav-redis.jurnal

Verificarea stării de replicare

puteți verifica informațiile de replicare prin comanda de replicare info în Redis CLI, de asemenea. Sub atributul rol se menționează dacă acel nod special este un maestru sau un sclav (cutie galbenă).în plus, în nodul principal, afișează detaliile tuturor sclavilor conectați. (caseta verde)

acum să examinăm ce sentinel.Jurnalul indică. (care se află în locul pe care l-am definit în santinelă.conf)

mai mult, dacă verificați santinela.fișier conf, puteți obține pentru a vedea că fișierul conf este actualizat automat cu cele mai recente configs, inclusiv sentinel cunoscut-slave și sentinel cunoscut-sentinel valori.

Super! Acum să creăm o valoare de probă în toate nodurile.

127.0.0.1:6739> set demokey "Amila"

după cum puteți vedea în diagrama de mai sus, sclavii sunt citiți numai, prin urmare, puteți scrie doar date pentru a stăpâni. Deoarece Redis se reproduce asincron cu toți sclavii rămași, puteți prelua valoarea inserată de la orice sclav Redis folosind aceeași cheie dată. În plus, via,KEYS* puteți lista toate tastele introduse. Diagrama de mai sus descrie în mod clar ceea ce tocmai am vorbit despre.

acum să verificăm cum funcționează Redis Sentinel Automatic Failover.

Redis Sentinel Failover Automat

Okiee! Să simulăm un scenariu de failover automat. În scopul de a simula un scenariu failover puteți opri pur și simplu serverul Redis sau ucide procesul Redis în instanța de MASTER. Chiar și tu poți dormi procesul Redis, de asemenea. Puteți alege orice mod pe care doriți.

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

așa cum este ilustrat în diagrama de mai sus, într-un scenariu de failover, dacă nodul principal eșuează, atunci cele 2 santinele rămase vor determina failover-ul și dacă ambele sunt de acord (deoarece valoarea cvorumului este 2), atunci un nou MASTER va fi ales din acele 2 noduri rămase.

următoarele arată coada jurnal pentru acest scenariu failover.

redis.Jurnalul nodurilor Slave.

sentinel.Jurnalul nodurilor Slave

acum să verificăm starea replicării prin comanda de replicare a informațiilor.

elaborarea în continuare a cozii de jurnal,

fiecare santinelă detectează că maestrul este în jos cu un eveniment +sdown. (+sdown înseamnă instanța specificată este acum în stare subiectiv în jos.)

+new-epoch înseamnă epoca actuală a fost actualizată.

+sdown evenimentul este ulterior escaladat la +odown, ceea ce înseamnă că mai multe santinele sunt de acord cu privire la faptul că maestrul nu este accesibil. (+odown înseamnă că instanța specificată este acum în stare obiectiv în jos.)

sentinele +votează o Sentinelă care va începe prima încercare de failover.

failover se întâmplă.

mai departe, în urma arată upstart de locuri de muncă.

parvenit pentru 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

parvenit pentru 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

Felicitări! Asta e pur și simplu. Acesta este modul în care Redis gestionează disponibilitatea ridicată și Failover-ul automat. Acum, să aruncăm o privire asupra unor fapte interesante Redis înainte de a sări la optimizarea sfaturi și trucuri.

fapte interesante despre Redis.

Redis poate gestiona până la 2 32 de taste și a fost testat în practică pentru a gestiona cel puțin 250 de milioane de taste pe instanță.

o instanță goală utilizează ~ 3 MB de memorie.

1 milion de chei mici- > perechi de valori șir folosesc ~ 85MB de memorie.

1 milion de taste- > valoarea Hash, reprezentând un obiect cu 5 câmpuri, utilizați ~ 160 MB de memorie.

Redis este un singur filet. Cum pot exploata mai multe CPU / nuclee?

nu este foarte frecvent ca CPU să devină blocajul Dvs. cu Redis, deoarece de obicei Redis este fie memorie, fie rețea legată. Dacă este cazul, scalarea orizontală sau verticală a instanțelor Redis va ajuta la reducerea blocajelor legate de CPU.

Redis este o bază de date în memorie, dar persistentă pe disc.

Redis persistența- > RDB : instantanee punct-in-time ale setului de date la intervale specificate. (Backup de date)| AOF : înregistrează fiecare operație de scriere primită de server. (Mai durabil)

dacă utilizați Java, puteți utiliza Jedis care este un client java, pentru a conecta aplicația Java cu Redis. Notă: Jedis utilizează Apache Commons Pool pentru punerea în comun a conexiunilor (GenericObjectPool). A single Jedis instance is not threadsafe! pentru a evita aceste probleme, ar trebui să utilizați JedisPool, care este o piscină threadsafe de conexiuni de rețea. Implicit dimensiunea maximă piscină conexiune este 8.

acum să ne concentrăm asupra problemelor/erorilor pe care le-ați putea obține și a unor sfaturi și trucuri de optimizare a performanței producției pentru Redis.

probleme/eroare pe care s-ar putea obține& performanță de producție optimizarea sfaturi și trucuri

în primul rând, în redis.conf și sentinel.conf, toate configs sunt într-o ordine asa ca nu te pui cu ordinea. În caz contrar, veți primi erori de configurare, cum ar fi următoarele.

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

din perspectiva securității, configurați o parolă pentru a vă autentifica cu Maestrul și sclavii. Pentru aceasta puteți schimba cu ușurință redis.conf și sentinel.conf în consecință, cu următoarea valoare de configurare.

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

Makesute că setarea TCP backlog (conexiuni maxime) este 511. Puteți seta această valoare în consecință (luând în considerare specificația serverului dvs.) cu pașii următori.

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.

unele dintre avertismentele pe care le-ați putea întâlni din redis.Jurnalul ar putea fi,

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

poate fi necesar să dezactivați THP sau pagina uriașă transparentă.

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

utilizarea soclului UNIX în locul portului TCP 6379 va contribui, de asemenea, la creșterea performanței Redis.

pentru a realiza acest lucru, redis.conf ar trebui să fie schimbat la următoarea setare.

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

în plus, în funcție de cazul de utilizare, puteți configura și opțiunea de persistență Redis.

dacă doriți, puteți dezactiva persistența deloc, dacă doriți ca datele dvs. să existe doar atâta timp cât serverul rulează. Notă: puteți dezactiva persistența RDB comentând toate liniile „salvare” din redis.conf după cum urmează.

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

AOF persistance (adăugați numai fișierul) este dezactivat în mod implicit în redis.conf.

appendonly no

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

monitorizarea Redis

din perspectiva monitorizării, există mai multe instrumente pentru monitorizarea Redis. NewRelic oferă capabilități în avans pentru a monitoriza și analiza Redis, inclusiv” cele mai multe operațiuni db timp consumat”,” operațiuni de tranzitată”,” operațiuni de timp de interogare ” și etc.

mai multe informații despre New Relic Redis sunt menționate aici. În plus, Redis-stat este, de asemenea, un bun instrument de monitorizare opensource Redis.

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

AWS ElasticCache

AWS oferă, de asemenea, un serviciu cloud cache în memorie numit „ElastiCache”, care vine și cu Redis inclus. Poate fi specificat ca un serviciu cloud eficient, ușor de utilizat, care descarcă majoritatea configurațiilor manuale și a sarcinilor administrative.

ElastiCache este un serviciu web care facilitează lansarea, gestionarea și scalarea unui cache distribuit în memorie în cloud.

interesant este că este livrat cu funcții avansate fabuloase, cum ar fi modul Cluster cu sharding în câteva clicuri, Multi-az cu auto-Failover, criptare în repaus, criptare în tranzit, importați fișierul RDB în S3, activați copii de rezervă automate și multe altele.

cea mai tare caracteristică a AWS ElastichCache este că oferă un tablou de bord cuprinzător de monitorizare pentru clusterul dvs.

Ei bine … asta e destul de mult pentru acest post!

așa cum am menționat la începutul acestui post, există o mulțime de diferite articole Redis acolo, dar am vrut să creeze un „toate într-un articol propriu-zis” care acoperă faptele cele mai esențiale și sfaturi care este necesar și util pentru un dezvoltator sau un inginer devops pentru a construi un cluster Redis extrem de disponibil cu Sentinel.

înainte de a termina această postare, unul dintre articolele interesante pe care le-am găsit a fost modul în care Flickr a implementat Redis Sentinel. Asigurați-vă că pentru a verifica acest post, de asemenea.

bine. Deci, vă mulțumesc foarte mult pentru citirea acestui articol și aștept cu nerăbdare să vină cu un alt articol interesant în curând, schimbul de experiența mea ca un dezvoltator. Până atunci, noroc! și codificare fericit!