Redis Sentinel

Să presupunem un scenariu în care aveți o singură instanță Redis în producția dvs. și aceasta eșuează la un moment dat din anumite motive. Aplicația dvs. memorează în cache datele în depozitul de date Redis, iar acum singura sursă de date este moartă. O modalitate de a controla acest tip de scenarii este menținerea arhitecturii master-slave în care sclavii pot replica nodul master până când acesta revine. Clusterele Redis acceptă disponibilitate ridicată până la o anumită măsură cu abordarea master-replica. Redis Sentinel este o altă abordare care oferă o modalitate mai fiabilă de a menține disponibilitatea ridicată a instanțelor Redis. Monitorizează nodul master Redis pentru defecțiuni și declanșează imediat procesul de failover, care va promova un nod slave existent la un master nou-nouț.

Mai mult, Redis sentinel acționează ca un intermediar în care clienții se conectează și solicită cea mai recentă adresă IP a nodului Master. Deci, sentinelul conectat oferă imediat adresa nodului principal.

În plus, o defecțiune a nodului principal este confirmată dacă mai multe santinele au convenit că un anumit master nu este accesibil sau disponibil. Aceasta încheie faza de detectare a erorilor și procesul de failover începe imediat. Prin urmare, sentinelul Redis poate fi văzut ca un sistem distribuit cu proprietăți specifice.

Acordul santinelelor se bazează pe o valoare de cvorum care va fi discutată în secțiunea următoare.

A cărui valoare

Valoarea cvorumului este numărul maxim de santinele asupra cărora trebuie convenit atunci când nodul principal este oprit. Această valoare este folosită numai pentru a identifica o eroare în nodul master. Procesul de failover începe cu autorizarea mai multor noduri santinelă disponibile pentru a continua cu o santinelă selectată ca lider.

Caracteristicile Redis Sentinel

Santinela este cunoscută pentru furnizarea unui mecanism de înaltă disponibilitate pentru depozitul de date Redis. În afară de aceasta, mai multe alte capacități pot fi enumerate.

• Sentinel monitorizează continuu starea nodurilor master și slave din sistemul dumneavoastră Redis.
• Ori de câte ori există o eroare sau ceva în neregulă cu instanțele dvs. Redis, sentinelul este capabil să notifice administratorul sau aplicațiile conectate folosind sentinel API.
• Faza de failover este dirijată de santinelă prin promovarea unei replici ca noul maestru. Replicile rămase au fost configurate pentru a utiliza noul master. În cele din urmă, clienții corespunzători vor fi notificați cu privire la noua adresă de nod master.
• De asemenea, sentinelul Redis este un furnizor de configurare pentru clienții conectați, unde clienții pot cere adresa instanței master disponibile în prezent și, dacă a avut loc un colaps brusc, sentinelul se angajează să împingă imediat noua adresă de nod master.

În secțiunea următoare, vom configura sentinelele Redis cu instanțe master-replica și vom folosi API-ul sentinel pentru a monitoriza nodurile.

Configurare sentinelă

În primul rând, creăm două instanțe Redis la porturile 7000 și 7001. Portul 7000 va fi nodul master, iar celălalt va replica masterul. Ambele instanțe folosesc următoarele fișiere de configurare:

Configurarea nodului principal

Configurarea nodului slave

Ambele instanțe vor începe prin a furniza fișierul de configurare asociat cu fiecare. Putem folosi următoarea comandă pentru a porni instanțe Redis separat:

Să ne conectăm la instanța Redis începută la portul 7001 după cum urmează:

Acum, putem face din această instanță o replică a masterului care rulează la portul 7000. Comanda REPLICAOF poate fi utilizată după cum urmează:

După cum era de așteptat, instanța care rulează la portul 7001 a devenit nodul replica al masterului care rulează la portul 7000.

Acum, suntem gata să configuram trei santinelele Redis pentru a monitoriza instanța principală de mai sus. Trebuie să avem trei fișiere de configurare pentru a crea trei instanțe sentinelă la porturile 5000, 5001 și 5002, așa cum se arată în continuare.

Fiecare santinelă.conf fișierul arată astfel, cu excepția faptului că numărul portului va fi schimbat:

Acum, este timpul să alergăm pe cele trei santinele. Puteți utiliza executabilul redis-sentinel împreună cu calea către santinelă.conf fișier de configurare pentru a crea o instanță santinelă. În caz contrar, putem apela în continuare executabilul redis-server specificând calea către santinelă.conf și steagul -santinelă .

Să începem fiecare santinelă folosind următoarea comandă:

Prima santinelă a fost pornită la portul 5000. În mod similar, puteți porni și celelalte două instanțe.

Acum, configurarea noastră Redis sentinel este în funcțiune, așa cum se arată în următoarea ilustrație:

În secțiunea următoare, vom explora mai multe despre API-ul Sentinel și despre cum îl putem utiliza pentru a prelua informații legate de nodul principal Redis.

Sentinel API

Redis furnizează un API santinel separat pentru a monitoriza master și replici asociate, pentru a vă abona pentru notificări și pentru a modifica setările santinelă. În plus, mai multe utilizări sunt enumerate în cele ce urmează.

• Verificați starea instanțelor Redis master și slave monitorizate
• Detalii despre alte santinele
• Primiți notificări în stil push de la santinelele în cazul unui failover

Comanda SENTINEL poate fi utilizată împreună cu subcomenzile asociate pentru a interoga, actualiza sau seta santinelele Redis și nodurile monitorizate.

Verificați starea nodului principal

Este foarte important să monitorizați sau să verificați starea nodului principal din când în când. Următoarea comandă API sentinel poate fi utilizată pentru a prelua detaliile principale:

monitored_master_name: Numele nodului master care este specificat în fișierul de configurare sentinelă pe care l-am creat în pasul anterior.

Să folosim această comandă pentru a interoga starea master în configurația noastră. În cazul nostru, numele nodului principal este 'masternode'.

Au fost preluate mai multe informații și câteva dintre ele sunt importante, cum ar fi num-slaves, flags și num-alte-santinele.

The steaguri proprietatea este setată la maestru ceea ce înseamnă că stăpânul este sănătos. Ori de câte ori nodul master este oprit, s_jos sau o_jos va fi afișat steag. Proprietatea num-alte-santinele este setat la 2, ceea ce înseamnă că sentinelul Redis le-a recunoscut deja pe celelalte două santinele pentru nodul principal. In plus num-sclavi proprietatea afișează replicile disponibile pentru nodul master. În acest caz, este setat la 1, deoarece avem o singură replică.

Obțineți informații despre replicile conectate

Putem verifica replicile conectate cu nodul master folosind următoarea subcomandă SENTINEL:

În acest exemplu, numele principal este „masternode”.

După cum era de așteptat, Sentinel a detectat nodul slave care rulează la portul 7001.

Obțineți informații despre santinelele asociate

În mod similar, putem interoga detaliile legate de alte santinele asociate cu nodul principal curent folosind următoarea subcomandă SENTINEL:

În acest caz, vom prelua informațiile legate de nodul principal numit „masternode”.

Obțineți adresa nodului principal

După cum sa menționat în secțiunea anterioară, Redis sentinel este un furnizor de configurare pentru clienții conectați. Deci, este capabil să furnizeze clienților solicitați adresa IP și portul nodului master care rulează în prezent. Următoarea subcomandă Sentinel API poate fi utilizată pentru a prelua informațiile menționate.

Să executăm comanda de mai sus pentru scenariul nostru, după cum urmează:

Am discutat doar câteva comenzi API sentinel. Mai multe alte subcomenzi sunt disponibile, cum ar fi sentinel-failover, sentinel info-cache, santinel masters și etc. În plus, multe comenzi sunt disponibile pentru a fi utilizate și în scopuri de administrare. În secțiunea următoare, ne vom concentra asupra procesului de failover Redis sentinel.

Procesul de failover Sentinel

Deoarece sentinelul nostru este configurat, putem testa faza de fail-over. Să trimitem nodul nostru principal în somn timp de 300 de secunde, ceea ce simulează o defecțiune în nodul principal.

Nodul master care rulează la portul 7000 ar trebui să fie inaccesibil acum. Deci, santinelele asociate vor observa că maestrul nu este disponibil cu +sdown eveniment. Apoi, acesta va fi setat la +odown unde 2 santinele confirmă că nodul principal este în jos conform valorii cvorumului. În cele din urmă, va începe faza de failover și, în mod ideal, replica ar trebui promovată la noul master.

Să verificăm din nou adresa IP a nodului principal și portul.

După cum era de așteptat, replica anterioară a fost promovată la noul master, ceea ce înseamnă că procesul de failover sentinelă are succes. Aceasta încheie implementarea și testarea celor trei setări santinelă pentru o singură pereche master-replică.

Concluzie

Redis sentinel este cea mai fiabilă abordare pentru a asigura disponibilitatea ridicată a unei anumite instanțe Redis master replica. O santinelă este capabilă să monitorizeze, să notifice și să inițieze transferul automat la erori fără intervenția umană. De asemenea, mai multe santinele împreună sunt de acord cu privire la faptul că nodul master este inaccesibil și valoarea cvorumului este utilizată ca număr maxim de santinele care trebuie convenite atunci când se verifică disponibilitatea instanței master. Redis sentinel oferă un API ușor de utilizat pentru a prelua informații despre starea nodului principal și a replicilor asociate și pentru a efectua și sarcini administrative.