ProHoster > Blog > Administrimi > Orchestrator dhe VIP si zgjidhje HA për grupin MySQL

Orchestrator dhe VIP si zgjidhje HA për grupin MySQL

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

Orchestrator dhe VIP si zgjidhje HA për grupin MySQL

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.

  1. 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.
  2. Po pĂ«rpiqemi tĂ« heqim VIP nga masteri i vjetĂ«r — pa sukses.
  3. Repika kalon në rolin e masterit. Topologjia rindërtohet.
  4. 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.
  5. 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ë.

Orchestrator dhe VIP si zgjidhje HA për grupin MySQL

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

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