Kas yra Redis Sentinel ir kodėl jis svarbus
Jei kada nors teko susidurti su situacija, kai jūsų Redis serveris nukrito ir visa aplikacija sustojo veikti kaip užšalusi, puikiai suprasite, kodėl aukštas prieinamumas (High Availability arba HA) yra ne prabanga, o būtinybė. Redis Sentinel – tai būtent tas įrankis, kuris padeda išvengti tokių košmarų.
Redis Sentinel veikia kaip stebėjimo ir automatinio atkūrimo sistema jūsų Redis infrastruktūrai. Paprastai tariant, tai yra protingas „sargybinis”, kuris nuolat stebi jūsų Redis serverius ir, jei kas nors nutinka pagrindiniam serveriui (master), automatiškai perkelia valdymą į vieną iš replikų. Viskas vyksta be jūsų įsikišimo – bent jau taip turėtų būti, jei viską teisingai sukonfigūruosite.
Sentinel sistema susideda iš kelių procesų, kurie veikia atskiruose serveriuose ar konteinieriuose. Jie tarpusavyje bendrauja, balsuoja ir priima sprendimus apie tai, kas vyksta su jūsų Redis infrastruktūra. Tai labai panaš į demokratinį procesą – vienas Sentinel negali vienasmeniškai nuspręsti, kad master serveris nukrito. Reikia kvorumo.
Kaip veikia Redis Sentinel architektūra
Prieš lendant į konfigūracijos detales, svarbu suprasti, kaip visa ši sistema veikia. Redis Sentinel architektūra remiasi trimis pagrindiniais komponentais: master serveriu, viena ar keliomis replikomis ir Sentinel procesais.
Master serveris priima visus rašymo užklausas. Replikos nuolat kopijuoja duomenis iš master serverio ir gali aptarnauti skaitymo užklausas. Sentinel procesai stebi visus šiuos serverius ir koordinuoja failover procesą, jei reikia.
Štai kur tampa įdomu: Sentinel procesai tarpusavyje bendrauja naudodami Redis pub/sub mechanizmą ir specialius kanalus. Jie nuolat siunčia PING komandas į master ir replicas, tikrina atsakymus ir stebi, ar viskas veikia sklandžiai. Jei master neatsako tam tikrą laiką, Sentinel procesai pradeda balsuoti.
Kad failover procesas įvyktų, reikia, kad tam tikras skaičius Sentinel procesų (kvorum) sutiktų, jog master tikrai yra nepasiekiamas. Tai apsaugo nuo klaidingų alarmų – pavyzdžiui, jei tik vienas Sentinel turi tinklo problemų ir negali pasiekti master, tai nereiškia, kad master tikrai nukrito.
Minimalios HA konfigūracijos paruošimas
Dabar pereikime prie praktikos. Minimaliai veikiančiai Redis Sentinel konfigūracijai jums reikės bent trijų mašinų ar konteinerių. Taip, trijų – ne dviejų. Kodėl? Nes reikia kvorumo, o su dviem procesais negalite turėti daugumos balsų.
Tipinė minimali setup’o struktūra atrodo taip:
– Vienas Redis master serveris
– Viena Redis replika
– Trys Sentinel procesai (galite juos paleisti tuose pačiuose serveriuose, kur veikia Redis)
Pradėkime nuo Redis master konfigūracijos. Sukurkite failą redis-master.conf:
bind 0.0.0.0 port 6379 requirepass jūsų_saugus_slaptažodis masterauth jūsų_saugus_slaptažodis
Pastaba dėl masterauth – jis reikalingas todėl, kad kai replika tampa master, ji turėtų žinoti slaptažodį autentifikacijai su kitomis replikomis. Tai dažnai praleidžiamas momentas, kuris vėliau sukelia galvos skausmą.
Replikos konfigūracija (redis-replica.conf) bus panaši, tik su papildomomis eilutėmis:
bind 0.0.0.0 port 6379 requirepass jūsų_saugus_slaptažodis masterauth jūsų_saugus_slaptažodis replicaof master_ip 6379
Sentinel konfigūracijos subtilybės
Dabar pats smagiausias dalykas – Sentinel konfigūracija. Sukurkite sentinel.conf failą. Štai minimali veikianti konfigūracija:
port 26379 sentinel monitor mymaster master_ip 6379 2 sentinel auth-pass mymaster jūsų_saugus_slaptažodis sentinel down-after-milliseconds mymaster 5000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 10000
Išnagrinėkime šias eilutes, nes kiekviena iš jų yra svarbi:
sentinel monitor mymaster master_ip 6379 2 – čia „mymaster” yra jūsų master serverio pavadinimas (galite pasirinkti bet kokį), „master_ip” yra tikrasis IP adresas, o skaičius 2 pabaigoje yra kvorum. Tai reiškia, kad du Sentinel procesai turi sutikti, jog master yra nepasiekiamas, kad įvyktų failover.
down-after-milliseconds nustato, kiek milisekundžių Sentinel lauks atsakymo iš master, kol jį paskelbsią „subjectively down”. Nustatymas 5000 (5 sekundės) yra pagrįstas kompromisas – ne per greitas, kad išvengtumėte klaidingų alarmų, bet ir ne per lėtas, kad sistema greitai reaguotų į tikras problemas.
parallel-syncs kontroliuoja, kiek replikų vienu metu gali sinchronizuotis su nauju master po failover. Nustatymas 1 reiškia, kad replikos sinchronizuosis po vieną, kas yra saugiau, bet lėčiau. Jei turite daug replikų ir galite sau leisti didesnę apkrovą, galite padidinti šį skaičių.
Diegimas ir testavimas realybėje
Teorija teorija, bet kaip tai paleisti ir įsitikinti, kad veikia? Pirma, paleiskite Redis master:
redis-server /path/to/redis-master.conf
Tada repliką:
redis-server /path/to/redis-replica.conf
Patikrinkite, ar replika sėkmingai prisijungė prie master. Prisijunkite prie master su redis-cli ir paleiskite:
redis-cli -a jūsų_saugus_slaptažodis INFO replication
Turėtumėte matyti savo repliką sąraše. Jei ne – tikrinkite tinklo nustatymus, firewall taisykles ir slaptažodžius.
Dabar paleiskite Sentinel procesus. Rekomenduoju paleisti juos trimis atskirais procesais:
redis-sentinel /path/to/sentinel.conf
Sentinel logai bus labai informatyvūs. Turėtumėte matyti pranešimus apie tai, kad Sentinel rado master ir replikas, ir kad jie visi yra stebimi.
Dabar ateina smagioji dalis – testavimas. Sustabdykite master procesą:
redis-cli -a jūsų_saugus_slaptažodis SHUTDOWN
Stebėkite Sentinel logus. Per kelias sekundes turėtumėte matyti, kaip Sentinel procesai aptinka, kad master yra nepasiekiamas, balsuoja ir išrenka naują master iš turimų replikų. Visas procesas paprastai užtrunka 10-15 sekundžių su standartinėmis nustatymais.
Dažniausios klaidos ir kaip jų išvengti
Iš savo patirties galiu pasakyti, kad yra keletas klasikinių klaidų, kurias daro beveik visi, pirmą kartą konfigūruodami Redis Sentinel.
Pirma klaida – neteisingas kvorumo nustatymas. Jei turite tris Sentinel procesus, kvorum turėtų būti 2, ne 3. Kodėl? Nes jei vienas Sentinel procesas nukris, likę du vis tiek galės priimti sprendimus. Su kvorumo nustatymu 3, jums reikėtų, kad visi trys Sentinel procesai veiktų, o tai prieštarauja visos HA idėjai.
Antra klaida – pamiršti masterauth parametrą. Kai replika tampa master, ji turi autentifikuotis su kitomis replikomis. Be šio parametro failover procesas gali įvykti, bet naujasis master negalės priimti replikų.
Trečia klaida – per agresyvūs timeout nustatymai. Jei nustatysite down-after-milliseconds į 1000 (1 sekundę), galite gauti klaidingus failover procesus dėl laikino tinklo lėtėjimo. Geriau pradėti nuo konservatyvesnių nustatymų (5000-10000) ir koreguoti pagal poreikį.
Ketvirta – nepakankamas Sentinel procesų skaičius. Vienas ar du Sentinel procesai nėra HA sprendimas. Jums reikia bent trijų, o geriau – penkių ar septynių didelėse sistemose. Visada naudokite nelyginį skaičių, kad išvengtumėte balsavimo lygiosiomis.
Aplikacijos integracija su Sentinel
Turėti veikiančią Sentinel sistemą yra puiku, bet jūsų aplikacija turi mokėti su ja bendrauti. Dauguma Redis klientų bibliotekų palaiko Sentinel režimą, bet reikia žinoti, kaip jį teisingai sukonfigūruoti.
Python su redis-py biblioteka:
from redis.sentinel import Sentinel
sentinel = Sentinel([
('sentinel1_ip', 26379),
('sentinel2_ip', 26379),
('sentinel3_ip', 26379)
], socket_timeout=0.1)
master = sentinel.master_for('mymaster',
socket_timeout=0.1,
password='jūsų_saugus_slaptažodis')
slave = sentinel.slave_for('mymaster',
socket_timeout=0.1,
password='jūsų_saugus_slaptažodis')
Node.js su ioredis:
const Redis = require('ioredis');
const redis = new Redis({
sentinels: [
{ host: 'sentinel1_ip', port: 26379 },
{ host: 'sentinel2_ip', port: 26379 },
{ host: 'sentinel3_ip', port: 26379 }
],
name: 'mymaster',
password: 'jūsų_saugus_slaptažodis'
});
Svarbu suprasti, kad jūsų aplikacija jungiasi prie Sentinel procesų, ne tiesiogiai prie Redis master. Sentinel praneša aplikacijai, kur yra dabartinis master. Kai įvyksta failover, Sentinel automatiškai nukreips jūsų aplikaciją į naują master.
Monitoringas ir priežiūra
Sukonfigūravus Sentinel sistemą, ji neturėtų būti palikta be priežiūros. Štai keletas dalykų, kuriuos turėtumėte stebėti:
Sentinel procesų sveikata – naudokite redis-cli -p 26379 SENTINEL masters komandą, kad pamatytumėte master būseną iš Sentinel perspektyvos. Turėtumėte reguliariai tikrinti, ar visi Sentinel procesai mato tą patį master.
Failover istorija – Sentinel saugo informaciją apie ankstesnius failover įvykius. Galite ją pamatyti su SENTINEL failover komandomis. Jei matote dažnus failover įvykius, tai signalas, kad kažkas negerai su jūsų infrastruktūra.
Replikacijos vėlavimas – net ir su Sentinel, replikacijos vėlavimas gali būti problema. Naudokite INFO replication komandą master serveryje, kad pamatytumėte, kiek duomenų kiekviena replika atsilieka.
Prometheus ir Grafana puikiai tinka Redis Sentinel monitoringui. Redis exporter palaiko Sentinel metrikas, ir galite sukurti dashboard’us, kurie rodo master būseną, replikų skaičių, replikacijos vėlavimą ir kitas svarbias metrikas.
Kai viskas veikia kaip turėtų
Redis Sentinel nėra sudėtingas, bet reikalauja dėmesio detalėms. Teisingai sukonfigūruota sistema turėtų veikti tyliai fone, automatiškai tvarkydama problemas, kol jūs miegote ar atostogaujate paplūdimyje.
Svarbiausias dalykas – nepersistengti su optimizacija iš karto. Pradėkite nuo konservatyvių nustatymų, stebėkite, kaip sistema veikia realiomis sąlygomis, ir tik tada koreguokite. Kiekviena aplinka yra skirtinga, ir tai, kas veikia vienam, gali neveikti kitam.
Nepamirškit reguliariai testuoti failover procesą. Bent kartą per kelis mėnesius sustabdykite master ir įsitikinkite, kad viskas veikia kaip tikėtasi. Geriau atrasti problemas testuojant, nei per tikrą incidentą 3 valandą nakties.
Ir paskutinis patarimas – dokumentuokite savo setup’ą. Po šešių mėnesių nebeprisiminsite, kodėl nustatėte tam tikrus parametrus būtent taip. Turėti gerą dokumentaciją gali sutaupyti daug laiko ir nervų ateityje. Redis Sentinel yra patikimas įrankis, kuris, teisingai sukonfigūruotas, leis jums ramiai miegoti naktimis, žinant, kad jūsų duomenų sluoksnis yra apsaugotas nuo vieno taško gedimų.
