SITIMOBILis kasutame MySQL andmebaasi kui peamist püsivate andmete salvestamise kohta. Meil on mitmeid andmebaasi klastreid erinevate teenuste ja eesmärkide tarvis.

Meistri pidev kättesaadavus on kogu süsteemi ja selle osade toimimise kriitiline näitaja. Klastri automaatne taastamine meistri rikkega vähendab oluliselt reageerimisaega ja süsteemi seisu aega. Selles artiklis käsitlen MySQL klastrite kõrge kättesaadavuse (HA) tagamise skeemi, mis põhineb MySQL Orkestratoril ja virtuaalsetel IP-aadressidel (VIP).

VIP-põhine HA-lahendus

Alustuseks räägin lühidalt meie andmesalvestussüsteemist.

Kasutame klassikalist replikatsiooni schooti, kus on üks kirjutatav meister ja mitu replit, mida kasutatakse ainult lugemiseks. Klastri võib sisaldada vahepealset meest — sõlme, mis on samal ajal ka replik ja meister teistele. Klientide päringud suunatakse replitelt läbi HAProxy, mis võimaldab koormust ühtlaselt jaotada ja hõlpsasti skaleeruda. HAProxy kasutamine on ajaloost tulenev ning hetkel oleme migratsiooniprotsessis ProxySQL-ile.

Replikatsioon toimub pool-sünkroonse režiimi alusel GTID. See tähendab, et vähemalt üks replik peab kirjutama tehingu logisse, enne kui see loetakse edukaks. Selline replikatsiooni režiim tagab optimaalse tasakaalu jõudluse ja andmete säilitamise vahel peamise sõlme rikete korral. Peamiselt edastatakse kõik muudatused meistrilt replitelle Row Based Replication (RBR), kuid osa sõlme võib omada mixed binlog format.

Orkestrator uuendab regulaarselt klastrite topoloogia staatust, analüüsib saadud teavet ja probleemide ilmnemisel saab käivitada automaatse taastamisprotseduuri. Protseduuri eest vastutab arendaja, kuna seda saab ellu viia erinevatel viisidel: põhinedes VIP-l, DNS-il, teenuste avastamise teenuste (service discovery) või enda lahenduste abil.

Üks lihtsamaid viise meistri taastamiseks tema rikete korral on liikuvate VIP-aadresside kasutamine.

Mida tuleb selle lahenduse kohta teada, enne kui edasi minna:

• VIP on IP-aadress, mis ei ole seotud konkreetse füüsilise võrgu liidesega. Kui sõlm ebaõnnestub või toimub plaaniline töö, saame VIP-i suunata teisele ressursile minimaalse katkestusajaga.
• Virtuaalse IP-aadressi vabastamine ja väljastamine on odavad ja kiired toimingud.
• VIP-iga töötamiseks on vajalik juurdepääs serverile SSH üle, või kasutada spetsiaalseid utiliite, näiteks keepalived.

Vaatame võimalikke probleeme meie meistriga ja kujutame ette, kuidas peaks tööle hakkama automaatse taastumise mehhanism.

Võrguside meistriga on kadunud või on tekkinud probleem „rauda” tasemel, ja server pole kergesti saadaval.

1. Orkestreerija värskendab klastrite topoloogiat, iga koopia teatab meistri puudumisest. Orkestreerija käivitab protsessi, mille käigus valitakse uus meister ja käivitab taastamise.
2. Püüame VIP-i vana meistrilt eemaldada — tulutult.
3. Koopia vahetab meistri rolli. Topoloogia rekonstrueeritakse.
4. Lisame uue võrgu liidese VIP-iga. Kuna VIP-i eemaldamine ei õnnestunud, käivitame taustal perioodilise päringu saatmise gratuitous ARP. See päring/vastus võimaldab värskendada ühildatud lülitites IP- ja MAC-aadresside vastavustabelit, teavitades seega meie VIP-i liikumisest. See minimeerib tõenäosust split brain vana meistri tagasiviimisel.
5. Kõik uued ühendused suunatakse kohe uuele meistrile. Vanad ühendused lõppevad ebaõnnestumisega, rakenduses tehakse korduvate päringute saatmine andmebaasi.

Server töötab normaalses režiimis, andmebaasi tasemel on juhtunud tõrge.

Algoritm on sarnane eelmise juhtumiga: topoloogia värskendamine ja taastamisprotsessi käivitamine. Kuna server on saadaval, vabastame edukalt VIP-i vanalt meistrilt, kanname selle uuele ja saadame mitu ARP-päringut. Vana meistri tagasiviimine ei tohiks mõjutada rekonstrueeritud klastrit ja rakenduse toimimist.

Teised probleemid

Koopiate või vahepealsete meistrite rikke ei põhjusta automaatset tegutsemist ja nõuab käsitsi sekkumist.

Virtuaalne võrguliides lisatakse alati ajutiselt, st pärast serveri taaskäivitamist ei määrata VIP automaatselt. Iga andmebaasi eksemplar käivitub vaikesätete kohaselt ainult lugemise režiimis, orkestrator vahetab automaatselt uue meistri kirjutamiseks ja proovib seadistada ainult lugemine vana meistri peal. Need toimingud on suunatud tõenäosuse vähendamisele split brain.

Taastamise protsessi käigus võivad ilmneda probleemid, millest tuleb samuti teavitada läbi orkestratori kasutajaliidese, lisaks standardsetele jälgimisvahenditele. Oleme laiendanud REST API-d, lisades sellise võimaluse (PR praegu on ülevaatamisel).

Üldine HA-lahenduse skeem on esitatud allpool.

Uue meistri valimine

Orkestrator on piisavalt intelligentne ja püüab valida kõige sobivama replikatsiooni uue meistrina järgmiste kriteeriumide alusel:

• replikatsiooni mahajäämus meistri ees;
• Meistri ja replikatsiooni MySQL versioon;
• replikatsiooni tüüp (RBR, SBR või segatud);
• asukoht ühes või erinevates andmekeskustes;
• erinevate errant GTID — tehingud, mis on sooritatud replikatsioonil ja puuduvad meistril;
• arvesse võetakse ka kasutaja määratud valikureegleid.

Iga replikatsioon ei ole ideaalne kandidaat meistri rolliks. Näiteks võib replikatsioon olla andmete varundamiseks kasutatav või serveril võib olla nõrgem riistvara konfiguratsioon. Orkestrator toetab käskude reeglite abil saab seadistada oma eelistusi kandidaadi valimisel alates kõige eelistatumast kuni ignoreeritavani.

Reaktsiooniaeg ja taastamine

Tõrke korral on oluline võimalikult kiiresti vähendada süsteemi seisakuaega, seetõttu vaatame MySQL parameetreid, mis mõjutavad orkestratori klastrite topoloogia loomist ja uuendamist:

• slave_net_timeout — sekundite arv, mille jooksul replikatsioon ootab uusi andmeid või meistri poolt saadetavat heartbeat-signaali, enne kui ühendus tunnistatakse kadunuks ja toimub ümberühendamine. Mida väiksem on väärtus, seda kiiremini saab replikatsioon määrata, et ühendus meisteriga on katkenud. Seame selle väärtuse 5 sekundiks.
• MASTER_CONNECT_RETRY — sekundide arv taaskoondamiskatsete vahel. Kui esinevad võrguprobleemid, võimaldab madal selle parameetri väärtus kiiresti uuesti ühenduda ja vältida klastrite taastamisprotsessi käivitamist. Soovitatav väärtus on 1 sekund.
• MASTER_RETRY_COUNT — maksimaalne katsete arv taaskoondamiseks.
• MASTER_HEARTBEAT_PERIOD — sekundite vahemaa, pärast mida master saadab heartbeat-signaali. Vaikimisi on see pool väärtusest slave_net_timeout.

Orkestratori parameetrid:

• DelayMasterPromotionIfSQLThreadNotUpToDate — kui on seatud true, siis ei rakendata master'i rolli kandidaadireplikas enne, kui replikatsiooni SQL-voog on täitnud kõik rakendamata tehingud Relay Log's. Me kasutame seda valikut, et mitte kaotada tehinguid, kui kõik kandidaadireplikad on maas.
• InstancePollSeconds — tipu ja topoloogia uuendamise sagedus.
• RecoveryPollSeconds — topoloogia analüüsi sagedus. Probleemide avastamisel käivitub topoloogia taastamine. See on konstant, mis on 1 sekund.

Iga klastrite sõlm küsitakse orkestratori poolt üks kord InstancePollSeconds sekundi jooksul. Probleemi avastamisel värskendatakse klastriseisundit sundvõimuga , seejärel tehakse lõplik otsus taastamise kohta. Katsetades erinevaid andmebaasi ja orkestratori parameetreid, oleme suutnud vähendada reageerimise ja taastamise kestust 30 sekundini.HA-skeemi teste alustasime kohaliku

Testseade

testimise seadmestiku arendamise ja edasise rakendamisega testimis- ja tootmiskeskkondades. Kohalik seade on täielikult automatiseeritud Docker'i põhjal ja võimaldab katsetada orkestratori ja võrgu konfiguratsiooni, skaleerida klastrit 2-3 serverilt mitmekümnele ja läbi viia harjutusi turvalises keskkonnas. Harjutuste ajal valime üht probleemide emuleerimise meetodit: master'i hetkeline sulgemine kasutades

kill -9 , protsessi õrn sulgemine ja serveri seiskamine (docker-compose stop), võrguprobleemide simuleerimine kasutadesiptables -j REJECT iptables -j DROP või . Ootame selliseid tulemusi:orkestrator tuvastab probleeme master'iga ja värskendab topoloogiat mitte rohkem kui 10 sekundiga;

• taastamisprotseduur käivitub automaatselt: muutub võrgu konfiguratsioon, master'i roll läheb replikale, topoloogia uueneb;
• taastamisprotseduur käivitub automaatselt: muudatatakse võrgu konfiguratsiooni, peamine roll antakse replikale, topoloogia ehitatakse ümber;
• uus meister on salvestamiseks saadaval, elavad koopiad ei kao ümberkorraldamise käigus;
• andmed hakkavad salvestuma uude meistrisse ja replitseeruma;
• üldine taastamisaeg ei ületa 30 sekundit.

Nagu teate, võib süsteem test- ja tootmiskeskkondades käituda erinevalt, kuna riistvara ja võrgu konfiguratsioon, sünteetilise ja reaalse koormuse erinevused jne. Seetõttu viime aeg-ajalt läbi harjutusi reaalsetes tingimustes, kontrollides, kuidas süsteem käitub võrguühenduse kadumise või selle üksikute osade halvenemise korral. Tulevikus tahame ehitada mõlemale keskkonnale täielikult identse infrastruktuuri ja automatiseerida selle testimise.

Järeldused

Andmesalvestussüsteemi põhielemendi töökindlus on SRE ja ekspluateerimise meeskonna üks peamisi ülesandeid. Orkestrandi ja HA-lahenduse rakendamine VIP-i põhjal on võimaldanud saavutada järgmised tulemused:

• usaldusväärne DB klastrite topoloogia probleemide tuvastamine;
• automaatne ja kiire reageerimine meistriga seotud intsidentidele, mis vähendab süsteemi seisakuaega.

Kuid lahendusel on oma piirangud ja puudused:

• HA-skeemi skaleerimine mitme andmekeskuse vahel nõuab ühtset L2-võrku nende vahel;
• enne VIP-i määramist uuele meistrile tuleb see eemaldada vanalt. Protsess on sequential, mis pikendab taastamisaega;
• VIP-i vabastamine nõuab SSH-juurdepääsu serverile või mõnd muud kaugprotseduuride väljakutse meetodit. Kuna server või DB kogeb probleeme, mis põhjustasid taastamisprotsessi, ei saa me olla kindlad, et VIP-i eemaldamine õnnestub. See võib viia kahe ühesuguse virtuaalse IP-aadressiga serveri ja probleemideni. split brain.

Probleemide vältimiseks split brain, võib kasutada meetodit STONITH ('Shoot The Other Node In The Head'), mis isoleerib või katkestab probleemi tekitava sõlme täielikult. On ka teisi kõrge kättesaadavuse rakendamise meetodeid: VIP-i ja DNS-i kombinatsioon, teenuste tuvastamine ja vaheteenused, sünkroonne replikatsioon ja muud meetodid, millel on oma puudused ja eelised.

Rääkisin meie lähenemisest MySQLi vastupidava klastriga. See on rakendamisel lihtne ja tagab aktsepteeritava usaldusväärsuse hetkeoludes. Kogu süsteemi ja eriti infrastruktuuri jätkudes areneb see lähenemine kindlasti edasi.

Allikas: habr.com