ProHoster > Blog > Administrim > Orchestrator dhe VIP si zgjidhje HA për klasterin MySQL

Orchestrator dhe VIP si zgjidhje HA për klasterin MySQL

Në Sitimobil përdorim bazën e të dhënave MySQL si depozitat kryesore të të dhënave të qëndrueshme. Kemi disa klastera të bazës së të dhënave për shërbime dhe qëllime të ndryshme.

Disponueshmëria e vazhdueshme e masterit është një tregues kritik i funksionimit të sistemit të tërësishëm dhe pjesëve të tij. Rindërtimi automatik i klasterit në rast të dështimit të masterit zvogëlon ndjeshëm kohën e reagimit ndaj incidenteve dhe kohën e pushimit të sistemit. Në këtë artikull do të shqyrtoj skemën e sigurisë së disponueshmërisë së lartë (HA) të klasterit MySQL mbi MySQL Orchestrator dhe adresat IP virtuale (VIP).

Orchestrator dhe VIP si zgjidhje HA për klasterin MySQL

Zgjidhja HA mbi VIP

Fillimisht do të flas shkurtimisht mbi atë që përfaqëson sistemi ynë i ruajtjes së të dhënave.

Ne pĂ«rdorim njĂ« skemĂ« klasike replikimi me njĂ« master tĂ« vetĂ«m, i cili Ă«shtĂ« nĂ« dispozicion pĂ«r shk writing dhe shumĂ« replika qĂ« pĂ«rdoren vetĂ«m pĂ«r lexim. Klasteri mund tĂ« pĂ«rmbajĂ« njĂ« master ndĂ«rmjetĂ«s — njĂ« nyjĂ« qĂ« Ă«shtĂ« njĂ«kohĂ«sisht replikĂ« dhe master pĂ«r tĂ« tjerĂ«t. KlientĂ«t qasen nĂ« replikat pĂ«rmes HAProxy, qĂ« lejon shpĂ«rndarjen e barabartĂ« tĂ« ngarkesĂ«s dhe lehtĂ«sinĂ« nĂ« shkallĂ«zim. PĂ«rdorimi i HAProxy ka shkak historik dhe tani jemi nĂ« procesin e migrimit nĂ« ProxySQL.

Replikimi realizohet në mënyrë gjysmë-sinkrone në bazë të GTID. Do të thotë, së paku një replikë duhet të regjistrojë transaksionin në log, përpara se të pranohet si e suksesshme. Ky mod i replikimit siguron një balancim optimal midis performancës dhe ruajtjes së të dhënave në rast dështimi të nyjës kryesore. Në përgjithësi, të gjitha ndryshimet dërgohen nga masteri te replikat përmes Row Based Replication (RBR), por disa nyje mund të kenë mixed binlog format.

Orkestratori përditëson periodikisht gjendjen e topologjisë së klasterit, analizon informacionin e marrë dhe në rast problemeve mund të fillojë procedurën e rindërtimit automatik. Vetë procedura është përgjegjësi e zhvilluesit, pasi mund të realizohet në shumë mënyra: mbi VIP, DNS, duke përdorur shërbime zbulimi (service discovery) ose mekanizma të shkruar vetë.

Një nga mënyrat e thjeshta për të rindërtuar masterin në rast të dështimit të tij është përdorimi i adresave VIP lundruese.

ÇfarĂ« duhet tĂ« dini mbi kĂ«tĂ« zgjidhje para se tĂ« vazhdoni mĂ« tutje:

  • VIP — Ă«shtĂ« njĂ« adresĂ« IP qĂ« nuk Ă«shtĂ« e lidhur me njĂ« ndĂ«rfaqe fizike tĂ« caktuar rrjeti. Kur njĂ« nyje dĂ«shton ose gjatĂ« punimeve tĂ« planifikuara, ne mund ta kalojmĂ« VIP nĂ« njĂ« burim tjetĂ«r me njĂ« kohĂ« tĂ« minimizuar ndalimi.
  • Largimi dhe dhĂ«nia e njĂ« adrese IP virtuale janĂ« operacione tĂ« lira dhe tĂ« shpejta.
  • PĂ«r tĂ« punuar me VIP, kĂ«rkohet akses nĂ« server pĂ«rmes SSH, ose pĂ«rdorimi i utilitareve speciale, pĂ«r shembull, keepalived.

Të shqyrtojmë problemet e mundshme me masterin tonë dhe të paraqesim se si duhet të funksionojë mekanizmi i rikuperimit automatik.

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

  1. Orkestratori përditëson topologjinë e klasterit, çdo riprodhim raporton për mungesën e masterit. Orkestratori nis procesin e zgjedhjes së një riprodhimi të përshtatshëm për rolin e masterit të ri dhe fillon rikuperimin.
  2. PĂ«rpiqemi tĂ« heqim VIP nga masteri i vjetĂ«r — pa sukses.
  3. Riprodhimi kalon në rolin e masterit. Topologjia ristrukturohet.
  4. Shtojmë një ndërfaqe të re rrjeti me VIP. Duke qenë se nuk arritëm ta heqim VIP, në sfond nisemi me dërgimin e periudhshëm të kërkesës gratuitous ARP. Ky lloj kërkese/ndjelljeje lejon përditësimin në switch-ët e lidhur të tabelës së përputhjes së adresave IP dhe MAC, duke njoftuar kështu për lëvizjen e VIP tonë. Kjo minimizon probabilitetin e split brain në rastin e rikthimit të masterit të vjetër.
  5. Të gjitha lidhjet e reja menjëherë drejtohen në masterin e ri. Lidhjet e vjetra përfundojnë pa sukses, duke bërë apel të përsëritur në DB në nivelin e aplikacionit.

Serveri punon në mënyrë normale, ka ndodhur një dështim në nivelin e DBMS.

Algoritmi është i ngjashëm me rastin e mëparshëm: përditësimi i topologjisë dhe nisja e procesit të rikuperimit. Duke qenë se serveri është i aksesueshëm, ne me sukses lirojmë VIP-në nga masteri i vjetër, e transferojmë në të riun dhe dërgojmë disa kërkesa ARP. Rikthimi i mundshëm i masterit të vjetër nuk duhet të ndikoje në klasterin e ristrukturuar dhe punën e aplikacionit.

Probleme të tjera

Dështimi i riprodhimeve ose i masterëve të përkohshëm nuk sjell veprime automatike dhe kërkon ndërhyrje manuale.

Interfejsi virtual rrjetit gjithmonĂ« shtohet pĂ«rkohĂ«sisht, qĂ« do tĂ« thotĂ« se pas rinisjes sĂ« serverit, VIP nuk shenjohet automatikisht. Çdo instancĂ« e DB fillon nĂ« mĂ«nyrĂ« standarde nĂ« modalitetin vetĂ«m pĂ«r lexim, orkestratori automatikisht kalon master-in e ri nĂ« tĂ« shkruajtur dhe pĂ«rpiqet tĂ« vendosĂ« vetĂ«m pĂ«r lexim nĂ« master-in e vjetĂ«r. KĂ«to veprime janĂ« tĂ« orientuara pĂ«r tĂ« reduktuar probabilitetin split brain.

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

Schema e përgjithshme e zgjidhjes HA është e paraqitur më poshtë.

Orchestrator dhe VIP si zgjidhje HA për klasterin MySQL

Zgjedhja e master-it të ri

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

  • mungesa e repikĂ«s nga master-i;
  • versioni i MySQL i master-it dhe repikĂ«s;
  • tipi i repikimit (RBR, SBR ose miks);
  • vlerĂ«simi nĂ« njĂ« ose mĂ« shumĂ« qendra tĂ« tĂ« dhĂ«nave;
  • praninĂ« GTID i gabuar — transaksionet qĂ« janĂ« kryer nĂ« repikĂ« dhe mungojnĂ« nĂ« master;
  • po ashtu merren parasysh rregullat e pĂ«rdoruesve pĂ«r zgjedhjen.

Jo çdo repikë është kandidati ideal për rolin e master-it. Për shembull, repika mund të përdoret për kopjimin e të dhënave, ose serveri ka një konfigurim më të dobët të "harduerit". Orkestratori mbështet rregulla manuale, me ndihmën e të cilave mund të rregulloni preferencat tuaja për zgjedhjen e kandidatëve nga më të preferuarit deri te ata të injoruar.

Koha e reagimit dhe rikuperimit

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

  • slave_net_timeout — numri i sekondave, pĂ«r tĂ« cilat repika pret ardhjen e tĂ« dhĂ«nave tĂ« reja ose sinjalit heartbeat nga master-i, para se lidhja tĂ« njihet si e humbur dhe tĂ« kryhet ripĂ«rcaktimi. Sa mĂ« i vogĂ«l tĂ« jetĂ« ky vlerĂ«, aq mĂ« shpejt repika do tĂ« jetĂ« nĂ« gjendje tĂ« pĂ«rcaktojĂ« se lidhja me master-in Ă«shtĂ« shkeputur. Ne e vendosim kĂ«tĂ« vlerĂ« tĂ« jetĂ« 5 sekonda.
  • MASTER_CONNECT_RETRY — numri i sekondave midis pĂ«rpjekjeve pĂ«r rikthim. NĂ« rast tĂ« problemeve nĂ« rrjet, njĂ« vlerĂ« e ulĂ«t e kĂ«tij parametri do tĂ« lejojĂ« rikthim tĂ« shpejtĂ« dhe do tĂ« parandalojĂ« nisjen e procesit tĂ« rimĂ«kĂ«mbjes sĂ« klasterit. Vlera e rekomanduar Ă«shtĂ« 1 sekondĂ«.
  • MASTER_RETRY_COUNT — numri maximal i pĂ«rpjekjeve pĂ«r rikthim.
  • MASTER_HEARTBEAT_PERIOD — intervali nĂ« sekonda, pas tĂ« cilit master-i dĂ«rgon njĂ« sinjal heartbeat. NĂ« parazgjedhje, Ă«shtĂ« e barabartĂ« me gjysmĂ«n e vlerĂ«s slave_net_timeout.

Parametrat e orkestratorit:

  • DelayMasterPromotionIfSQLThreadNotUpToDate — nĂ«se Ă«shtĂ« i barabartĂ« me true, atĂ«herĂ« roli i master-it nuk do tĂ« zbatohet nĂ« replikĂ«n-kandidate derisa rrjedha SQL e replikĂ«s tĂ« pĂ«rfundojĂ« tĂ« gjitha transaksionet e papĂ«rfunduara nga Relay Log. Ne e pĂ«rdorim kĂ«tĂ« opsion pĂ«r tĂ« mos humbur transaksionet nĂ« kushte vonese tĂ« tĂ« gjitha 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 Ă«shtĂ« nje konstantĂ«, e barabartĂ« me 1 sekondĂ«.

Çdo nod nĂ« klasteri pyetet nga orkestratori njĂ« herĂ« nĂ« InstancePollSeconds sekonda. NĂ« rast se zbulohet ndonjĂ« problem, gjendja e klasterit detyrohet azhornohet, dhe mĂ« pas merret njĂ« vendim pĂ«rfundimtar pĂ«r tĂ« realizuar rikthimin. Duke eksperimentuar me parametra tĂ« ndryshĂ«m tĂ« DB dhe orkestratorit, kemi arritur tĂ« ulemi kohĂ«n e reagimit dhe rikthimit nĂ« 30 sekonda.

Standi i testimit

Testimi i skemës HA e filluam me zhvillimin e një të testimit lokal dhe më pas implementimin në mjedise testimi dhe prodhimi. Stenda lokale është plotësisht e automatizuar mbi bazën e Docker-it dhe lejon të eksperimentojmë me konfigurimin e orkestratorit dhe rrjetit, të shkallëzojmë klasterin nga 2-3 servera në disa dhjetëra dhe të zhvillojmë ushtrime në një mjedis të sigurt.

Gjatë ushtrimeve ne zgjedhim një nga metodat e imitim të problemeve: të qetësojmë menjëherë master-in me kill -9, të përfundojmë butë procesin dhe të ndalojmë serverin (docker-compose stop), të imitojmë probleme me rrjetin me iptables -j REJECT ose iptables -j DROP. Ne presim këto rezultate:

  • orkestratori do tĂ« zbulojĂ« probleme me master-in dhe do tĂ« azhurnojĂ« topologjinĂ« pĂ«r mĂ« pak se 10 sekonda;
  • procedura e rikthimit do tĂ« nisĂ« automatikisht: do tĂ« ndryshojĂ« konfigurimi i rrjetit, roli i master-it do tĂ« kalojĂ« nĂ« replikĂ«, topologjia do tĂ« rinovohet;
  • masteri i ri do tĂ« jetĂ« i disponueshĂ«m pĂ«r regjistrim, replikat e drejtpĂ«rdrejta nuk do tĂ« humbasin gjatĂ« procesit tĂ« rindĂ«rtimit;
  • 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Ă« sillej ndryshe nĂ« mjediset e testimit dhe nĂ« ato tĂ« prodhimit pĂ«r shkak tĂ« konfigurimeve tĂ« ndryshme tĂ« ‘harduerit’ dhe rrjetit, dallimeve nĂ« ngarkesat sintetike dhe reale, etj. Prandaj, herĂ« pas here ne kryejmĂ« ushtrime nĂ« kushte reale, duke kontrolluar se si sillej sistemi nĂ« rast tĂ« humbjes sĂ« lidhjes rrjet dhe degradimit tĂ« disa pjesĂ«ve tĂ« tij. NĂ« tĂ« ardhmen dĂ«shirojmĂ« tĂ« ndĂ«rtuam njĂ« infrastrukturĂ« krejtĂ«sisht identike pĂ«r tĂ« dy mjediset dhe ta automatizojmĂ« testimin e saj.

PĂ«rfundimet

Funksionaliteti i nodës kryesore të sistemit të ruajtjes së të dhënave është një nga detyrat kryesore të ekipit SRE dhe të operacioneve. Zbatimi i orkestratorit dhe zgjidhjes HA të bazuar në VIP ka sjellë rezultatet e mëposhtme:

  • zbulesa e besueshme e problemeve me topologjinĂ« e klasterit tĂ« DB;
  • reaksion automatik dhe tĂ« shpejtĂ« nĂ« incidentet e lidhura me masterin, duke reduktuar kohĂ«n e papunĂ«sisĂ« sĂ« sistemit.

Megjithatë, zgjidhja ka kufizimet dhe disavantazhet e saj:

  • zhvillimi i skemĂ«s HA nĂ« disa Qendra tĂ« DhĂ«nash do tĂ« kĂ«rkojĂ« njĂ« rrjet L2 tĂ« pĂ«rbashkĂ«t ndĂ«rmjet tyre;
  • para se tĂ« emĂ«rojmĂ« VIP nĂ« masterin e ri, na nevojitet tĂ« lirohet ai nĂ« tĂ« vjetrin. Procesi Ă«shtĂ« sekuencial, gjĂ« qĂ« rrit kohĂ«n e rikuperimit;
  • lirimi i VIP kĂ«rkon qasje SSH nĂ« serverin, ose çdo mĂ«nyrĂ« tjetĂ«r pĂ«r thirrjen e procedurave tĂ« distancuara. Duke qenĂ« se serveri ose DB Ă«shtĂ« duke pĂ«rjetuar probleme qĂ« shkaktuan procesin e rikuperimit, nuk mund tĂ« jemi tĂ« sigurt se lirimi i VIP do tĂ« pĂ«rfundojĂ« me sukses. Dhe kjo mund tĂ« çojĂ« nĂ« dy servera me tĂ« njĂ«jtin adresĂ« IP virtuale dhe njĂ« problem split brain.

Për të shmangur split brain, mund të përdoret metoda STONITH ('Qëlloni Nodën Tjetër Në Kokë'), e cila izolon plotësisht ose fik nodën problematike. Ka edhe mënyra të tjera për realizimin e disponueshmërisë së lartë të klasterit: kombinimi i VIP dhe DNS, zbulimi i shërbimeve dhe shërbimet proxy, replikimi sinkron dhe metoda të tjera, të cilat kanë disavantazhet dhe avantazhet e tyre.

Kam tregova për qasjen tonë në krijimin e një klasteri MySQL me tolerancë për dështime. Ai është i lehtë për t'u zbatuar dhe ofron një nivel të pranueshëm besueshmërie në kushtet aktuale. Ndërsa sistemi zhvillohet si një e tërë dhe infrastruktura në veçanti, ky qasje do të evoluojë pa dyshim.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster