Në Sitimobil, ne përdorim bazën e të dhënave MySQL si magazinën kryesore të të dhënave të përhershme. Kemi disa grupe të të dhënave për shërbime dhe objektiva të ndryshme.

Disponueshmëria e vazhdueshme e masterit është një tregues kritik i funksionimit të gjithë sistemit dhe pjesëve të tij. Rindërtimi automatik i grupit në rastin e dështimit të masterit zvogëlon ndjeshëm kohën e përgjigjes ndaj incidenteve dhe kohën e papunësisë së sistemit. Në këtë artikull do të shqyrtoj skemën e sigurimit të disponueshmërisë së lartë (HA) të grupit MySQL të bazuar në MySQL Orchestrator dhe adresave IP virtuale (VIP).

Zgjidhje HA e bazuar në VIP

Më parë do të shpjegoj shkurtimisht se çfarë ka sistemi ynë i ruajtjes së të dhënave.

Ne përdorim një skemë klasike replikimi me një master të vetëm, i cili është i disponueshëm për shkrim, dhe shumë replika, të cilat përdoren vetëm për lexim. Klienti mund të përmbajë një master të mesëm — një nyje që është njëkohësisht dhe një replikë, dhe master për të tjerët. Klientët i drejtohen kopjeve përmes HAProxy, që lejon shpërndarjen e barabartë të ngarkesës dhe lehtësi në shkallëzim. Përdorimi i HAProxy është për shkak të arsyeve historike, dhe tani jemi në procesin e migrimit në ProxySQL.

Replikimi kryhet në një mod të gjysmë sinkronizuar bazuar në GTID. Kjo do të thotë se të paktën një replikë duhet të regjistrojë transaksionin në regjistër, përpara se të njihet si e suksesshme. Ky mod replikimi ofron balancimin optimal midis performancës dhe ruajtjes së të dhënave në rast se ndodhi dështimi i nyjës kryesore. Kryesisht, të gjitha ndryshimet transmetohen nga masteri në replikë përmes Replikimit të Bazeve të Rreshtit (RBR), por disa nyje mund të kenë formati mixed binlog.

Orkestratori përditëson periodikisht gjendjen e topologjisë së klasterit, analizon informacionin e marrë dhe në rast problemi mund të nisë procedurën e rikuperimit automatik. Për vetë procedurën përgjigjet zhvilluesi, pasi ajo mund të realizohet në mënyra të ndryshme: në bazë të VIP, DNS, duke përdorur shërbime zbulimi të shërbimeve (service discovery) ose mekanizma të shkruar vetë.

Një nga mënyrat e thjeshta për të rikuperuar master-in në rast dështimi është përdorimi i adresave VIP lëvizëse.

Çfarë duhet të dimë rreth këtij zgjidhjeje para se të vazhdojmë:

VIP është një adresë IP që nuk është e lidhur me një ndërfaqe fizike të caktuar të rrjetit. Kur një nyje dështon ose gjatë punimeve të planifikuara, mund të ndërrojmë VIP në një burim tjetër me minimumin e kohës së papunësisë.
Çlirimi dhe lëshimi i një adrese IP virtuale janë operacione të lira dhe të shpejta.
Për të punuar me VIP, kërkohet qasje në serverin përmes SSH, ose përdorimi i utilitareve speciale, për shembull, keepalived.

Le të shqyrtojmë problemet e mundshme me master-in tonë dhe të paraqesim se si duhet të funksionojë mekanizmi i rikuperimit automatik.

Ka humbur lidhja rrjet me masterin, ose ka ndodhur një problem në nivelin e "harduerit", dhe serveri nuk është i aksesueshëm.

Orkestratori po përditëson topologjinë e klasterit, çdo replikë raporton për mospërfshirjen e masterit. Orkestratori nis procesin e zgjedhjes së një replice të përshtatshme për rolin e masterit të ri dhe fillon rikuperimin.
Po përpiqemi të heqim VIP nga masteri i vjetër — pa sukses.
Repika kalon në rolin e masterit. Topologjia rindërtohet.
Po shtojmë një ndërfaqe të re rrjeti me VIP. Duke qenë se nuk arritëm ta heqim VIP-in, në sfond nisnim një dërgim të rregullt të kërkesës. gratuitous ARP. Ky lloj kërkese/faqe lejon përditësimin në switch-at e lidhur të tabelës së përputhjes së IP- dhe MAC-adresave, duke njoftuar kështu për zhvendosjen e VIP-it tonë. Kjo minimizon probabilitetin e split brain në kthimin e masterit të vjetër.
Të gjitha lidhjet e reja menjëherë redirektohen në masterin e ri. Lidhjet e vjetra përfundojnë me dështim, duke kryer kërkesa të përsëritura në DB në nivelin e aplikacionit.

Serveri punon në modalitet normal, është shfaqur një dështim në nivelin e DBMS.

Algoritmi është i ngjashëm me rastin e mëparshëm: përmirësimi i topologjisë dhe nisja e procesit të rikuperimit. Duke qenë se serveri është në dispozicion, ne me sukses lirojmë VIP-in në master-in e vjetër, e transferojmë atë tek ai i ri dhe dërgojmë disa kërkesa ARP. Rikthimi i mundshëm i master-it të vjetër nuk duhet të ndikojë në klasterin e ndërtuar dhe funksionimin e aplikacionit.

Problemet e tjera

Dështimi i kopjeve ose masterëve të ndërmjetëm nuk çon në veprime automatike dhe kërkon ndërhyrje manuale.

Interface-i virtual i rrjetit gjithmonë shtohet përkohësisht, domethënë pas rindizjes së serverit VIP nuk i caktohet automatikisht. Çdo instancë e DB fillon për default në modin e leximit vetëm, orkestratori automatikisht ndërron master-in e ri në shkrim dhe provon të vendosë lexim vetëm në master-in e vjetër. Këto veprime synojnë të zvogëlojnë probabilitetin split brain.

Gjatë procesit të rikuperimit mund të ndodhin probleme, për të cilat gjithashtu duhet të njoftohet përmes UI të orkestratorit përveç mjeteve standarde të monitorimit. Ne kemi zgjeruar REST API-në, duke shtuar këtë mundësi (PR aktualisht është në shqyrtim).

Diagrami i përgjithshëm i zgjidhjes HA paraqitet më poshtë.

Zgjedhja e masterit të ri

Orkestratori është mjaft i mençur dhe përpiqet të zgjedhë replikën më të përshtatshme si master të ri sipas kritereve të mëposhtme:

distanca e replikës nga masteri;
versioni i MySQL të masterit dhe replikës;
tipo i replikimit (RBR, SBR ose mixed);
pozita në të njëjtin ose në qendra të ndryshme të të dhënave;
praninë GTID i gabuar — transaksionet që janë kryer në replikë dhe mungojnë në master;
rregullat e zgjedhjes të përdoruesve gjithashtu merren parasysh.

Jo çdo replikë është një kandidatë ideal për rolin e masterit. Për shembull, një replikë mund të përdoret për backup të të dhënave, ose serveri ka një konfigurim të dobët të 'harduerit'. Orkestratori mbështet rregulla manuale, me ndihmën e të cilave mund të përcaktoni preferencat tuaja për zgjedhjen e kandidatit nga më të preferuarit deri tek ata që injorohen.

Koha e reagimit dhe rikuperimit

Në rast incidenti, është e rëndësishme të minimizohet koha e pezullimit të sistemit, prandaj do të shqyrtojmë parametrat e MySQL që ndikojnë në ndërtimin dhe përditësimin e topologjisë së klasterit nga orkestratori:

slave_net_timeout — numri i sekondave gjatë të cilëve një replikë pret për të marrë të dhëna të reja ose sinjalin heartbeat nga masteri, para se lidhja të njihet si e humbur dhe të kryhet ri-lidhja. Sa më e vogël të jetë vlera, aq më shpejt do të jetë në gjendje replikimi të përcaktojë se lidhja me masterin është prishur. Ne e vendosim këtë vlerë në 5 sekonda.
MASTER_CONNECT_RETRY — numri i sekondave midis përpjekjeve për ri-lidhje. Në rast të problemeve të rrjetit, një vlerë e ulët e këtij parametri do të lejojë ri-lidhjen e shpejtë dhe do të parandalojë nisjen e procesit të rikuperimit të klasterit. Vlera e rekomanduar është 1 sekond.
MASTER_RETRY_COUNT — numri maksimal i përpjekjeve për ri-lidhje.
MASTER_HEARTBEAT_PERIOD — intervali në sekonda, pas të cilit masteri dërgon sinjalin heartbeat. Me default është gjysma e vlerës slave_net_timeout.

Parametrat e orkestratorit:

DelayMasterPromotionIfSQLThreadNotUpToDate — nëse është i barabartë me e vërtetë, roli i masterit nuk do të aplikohet në replikën-kandidate derisa rrjeta SQL e replikës të ketë përfunduar të gjitha transaksionet e papërfunduara nga Relay Log. Ne e përdorim këtë opsion për të mos humbur transaksionet në kushte të prapambetjes së të gjithë replikave-kandidate.
InstancePollSeconds — frekuenca e ndërtimit dhe azhurnimit të topologjisë.
RecoveryPollSeconds — frekuenca e analizës së topologjisë. Në rast se zbulohet një problem, niset rikthimi i topologjisë. Kjo konstante, e barabartë me 1 sekondë.

Çdo nyje e klasterit kontrollohet nga orkestratori një herë në InstancePollSeconds sekondë. Në rast zbulimi të një problemi, gjendja e klasterit përditësohet me forcë , dhe pastaj merret një vendim përfundimtar për të realizuar rikthimin. Duke eksperimentuar me parametra të ndryshëm të DB-së dhe orkestratorit, kemi arritur të zvogëlojmë kohën e reagimit dhe rikthimit në 30 sekonda., dhe pastaj merret një vendim përfundimtar mbi kryerjen e rikthimit. Duke eksperimentuar me parametra të ndryshëm të DB dhe orkestratorit, arritëm të ulni kohën e përgjigjes dhe rikthimit në 30 sekonda.

Njësia e testimit

Testimin e skemës HA e nisim me zhvillimin e një stende testuese dhe implementimin e mëtejshëm në mjediset testuese dhe të prodhimit. Stenda lokale është plotësisht e automatizuar mbi bazën e Docker dhe lejon eksperimentimin me konfigurimin e orkestratorit dhe rrjetit, duke shkallëzuar klasterin nga 2-3 serverë në disa dhjetëra dhe duke realizuar stërvitje në një ambient të sigurt.

Gjatë stërvitjeve, ne zgjedhim një nga metodat e simulimit të problemit: të qëllojmë menjëherë master-in me kill -9, të përfundojmë butësisht procesin dhe të ndalojmë serverin (docker-compose stop), imituar probleme me rrjetin duke përdorur iptables -j REJECT ose iptables -j DROP. Ne presim rezultate të tilla:

orkestratori do të zbulojë problemet me masterin dhe do të azhurnojë topologjinë brenda 10 sekondave;
procedura e rikuperimit do të niset automatikisht: konfigurimi i rrjetit do të ndryshojë, roli i masterit do t’i kalojë një replikimi, topologjia do të ristrukturohet;
masteri i ri do të bëhet i accesueshëm për të shkruar, dhe replikat aktive nuk do të humbasin gjatë procesit të ristrukturimit;
të dhënat do të fillojnë të regjistrohen në masterin e ri dhe të replikohen;
koha totale e rikuperimit do të jetë jo më shumë se 30 sekonda.

Siç e dini, sistemi mund të sillet ndryshe në ambientet testuese dhe production për shkak të konfigurimeve të ndryshme të ‘harduerit’ dhe rrjetit, dallimeve midis ngarkesës sintetike dhe reale etj. Prandaj, periodicisht ne zhvillojmë ushtrime në kushte reale, duke testuar se si sillet sistemi gjatë humbjes së lidhjes rrjetore ose degradimit të pjesëve të saj. Në të ardhmen, duam të ndërtojmë një infrastrukturë plotësisht identike për të dy ambientet dhe ta automatizojmë testimin e saj.

Përfundimet

Funksionaliteti i nyjes kryesore të sistemit të ruajtjes të dhënash është një nga detyrat kryesore të ekipit SRE dhe të operacioneve. Implementimi i orkestruesit dhe zgjidhjes HA të bazuar në VIP ka mundësuar arritjen e rezultateve të mëposhtme:

zbulim të besueshëm të problemeve me topologjinë e klasterit të DB;
reagim automatike dhe të shpejtë ndaj incidenteve që lidhen me masterin, gjë që ul kohën e papunësisë së sistemit.

Megjithatë, zgjidhja ka kufizime dhe disavantazhe:

shkallëzimi i skemës HA në disa QENDRA të DAD-it do të kërkojë një rrjet L2 të përbashkët midis tyre;
përpara se të caktojmë VIP në masterin e ri, na nevojitet të lironim atë në të vjetrin. Procesi është sekuencial, gjë që rrit kohën e rikthimit;
lirimi i VIP kërkon akses SSH në server, ose ndonjë mundësi tjetër për thirrjen e procedurave të largëta. Nëse serveri ose DB ka probleme që shkaktojnë procesin e rikthimit, nuk mund të jemi të sigurt se heqja e VIP do të përfundojë me sukses. Kjo mund të çojë në dy serverë me të njëjtin adresë IP virtuale dhe të krijojë një problem split brain.

Për të shmangur split brain, mund të përdorim metodën STONITH («Shoot The Other Node In The Head»), i cili izolon plotësisht ose çaktivizon nyjën problematike. Ekzistojnë edhe mënyra të tjera për të realizuar disponueshmërinë e lartë të grupit: kombinimi i VIP dhe DNS, zbulimi i shërbimeve dhe shërbimet proxy, replikimi sinkron dhe mënyra të tjera që kanë avantazhe dhe disavantazhe të veta.

Kam folur për qasjen tonë në krijimin e një grupi MySQL të papërshkueshëm nga dështimet. Ai është i lehtë për t'u zbatuar dhe siguron një nivel të pranueshëm të besueshmërisë në kushtet aktuale. Ndërsa sistemi i tërë dhe infrastruktura veç e veç do të zhvillohen, kjo qasje padyshim do të evoluojë.

Burimi: habr.com