Citymobilis kasutame peamise püsiva andmesalvestusena MySQL-i andmebaasi. Meil on mitu andmebaasiklastrit erinevate teenuste ja eesmärkide jaoks.

Kapteni pidev kättesaadavus on kogu süsteemi ja selle üksikute osade jõudluse kriitiline näitaja. Klastrite automaatne taastamine ülemtõrke korral vähendab oluliselt intsidentidele reageerimise aega ja süsteemi seisakuaega. Selles artiklis vaatlen MySQL-i klastri kõrge kättesaadavuse (HA) disaini, mis põhineb sellel MySQL Orchestrator ja virtuaalsed IP-aadressid (VIP).

HA lahendus, mis põhineb VIPil

Esiteks räägin teile lühidalt, mis on meie andmesalvestussüsteem.

Kasutame klassikalist replikatsiooniskeemi, millel on üks kirjutamiskõlbulik juht ja mitu kirjutuskaitstud koopiat. Klaster võib sisaldada vahepealset juhtseadet – sõlme, mis on teistele nii koopia kui ka juht. Kliendid pääsevad koopiatele juurde HAProxy kaudu, mis võimaldab koormuse ühtlast jaotust ja hõlpsat skaleerimist. HAProxy kasutamine on tingitud ajaloolistest põhjustest ja me oleme praegu ProxySQL-ile ülemineku protsessis.

Replikatsioon toimub poolsünkroonses režiimis, mis põhineb GTID. See tähendab, et vähemalt üks koopia peab tehingu logima, enne kui see loetakse edukaks. See replikatsioonirežiim tagab optimaalse tasakaalu jõudluse ja andmeohutuse vahel põhisõlme rikke korral. Põhimõtteliselt kantakse kõik muudatused üle põhiseadmest koopiatesse, kasutades Row Based Replication (RBR), kuid mõnel sõlmel võib see olla mixed binlog format.

Orkester värskendab perioodiliselt klastri topoloogia olekut, analüüsib saadud teavet ja probleemide ilmnemisel saab käivitada automaatse taastamise protseduuri. Protseduuri enda eest vastutab arendaja, kuna seda saab rakendada erineval viisil: VIP-i, DNS-i alusel, kasutades teenusetuvastusteenuseid või ise kirjutatud mehhanisme.

Üks lihtne viis juhtfaili taastamiseks, kui see ebaõnnestub, on ujuvate VIP-aadresside kasutamine.

Mida peate selle lahenduse kohta teadma enne edasiliikumist:

• VIP on IP-aadress, mis ei ole seotud konkreetse füüsilise võrguliidesega. Kui sõlm ebaõnnestub või plaanilise hoolduse ajal, saame VIP-i minimaalse seisakuajaga teisele ressursile lülitada.
• Virtuaalse IP-aadressi vabastamine ja väljastamine on odav ja kiire toiming.
• VIP-iga töötamiseks vajate juurdepääsu serverile SSH kaudu või näiteks spetsiaalsete utiliitide kasutamist, keepalived.

Vaatame oma viisardi võimalikke probleeme ja kujutame ette, kuidas automaatne taastemehhanism peaks töötama.

Võrguühendus ülemseadmega on kadunud või riistvara tasemel on tekkinud probleem ja server pole saadaval

1. Orkestraator värskendab klastri topoloogiat, iga koopia teatab, et juht pole saadaval. Orkester alustab uue meistri rolli jaoks sobiva koopia valimist ja alustab taastumist.
2. Üritame VIP-i vanameistrist eemaldada – edutult.
3. Koopia lülitub kapteni rolli. Topoloogiat ehitatakse ümber.
4. Uue võrguliidese lisamine VIP-iga. Kuna VIP-i ei olnud võimalik eemaldada, hakkame taustal perioodiliselt päringut saatma tasuta ARP. Seda tüüpi päring/vastus võimaldab teil värskendada ühendatud lülitite IP- ja MAC-aadresside vastendamise tabelit, teavitades teid, et meie VIP on kolinud. See vähendab tõenäosust split brain vanameistri tagastamisel.
5. Kõik uued ühendused suunatakse koheselt uuele juhile. Vanad ühendused ebaõnnestuvad ja korduvad andmebaasikõned tehakse rakenduse tasemel.

Server töötab tavarežiimis, DBMS-i tasemel ilmnes tõrge

Algoritm on sarnane eelmisele juhtumile: topoloogia värskendamine ja taastamisprotsessi käivitamine. Kuna server on saadaval, vabastame edukalt VIP-i vanal masteril, edastame selle uude ja saadame mitu ARP-päringut. Vana masteri võimalik tagastamine ei tohiks mõjutada ümberehitatud klastrit ja rakenduse tööd.

Muud probleemid

Koopiate või vahepealsete meistrite ebaõnnestumine ei vii automaatsete toimingute jaoks ja nõuab käsitsi sekkumist.

Virtuaalne võrguliides lisatakse alati ajutiselt, st pärast serveri taaskäivitamist VIP-i automaatselt ei määrata. Iga andmebaasi eksemplar käivitub vaikimisi kirjutuskaitstud režiimis, orkestraator lülitab automaatselt uue juhtseadme kirjutama ja proovib installida read only vanameistri kallal. Nende tegevuste eesmärk on vähendada tõenäosust split brain.

Taasteprotsessi käigus võivad tekkida probleemid, millest tuleks lisaks tavapärastele jälgimisvahenditele teatada ka orkestri kasutajaliidese kaudu. Oleme laiendanud REST API-t, lisades selle funktsiooni (PR praegu läbivaatamisel).

HA lahenduse üldskeem on esitatud allpool.

Uue meistri valimine

Orkester on piisavalt tark ja püüab valida sobivaim koopia uue meistrina järgmiste kriteeriumide järgi:

• koopia jääb kaptenist maha;
• Masteri ja koopia MySQL-versioon;
• replikatsiooni tüüp (RBR, SBR või segatud);
• asukoht samas või erinevates andmekeskustes;
• kättesaadavus errant GTID — tehingud, mis sooritati koopias ja mis ei ole põhiseadmes;
• arvesse võetakse ka kohandatud valikureegleid.

Mitte iga vihje pole ideaalne kandidaat meistriks. Näiteks saab andmete varundamiseks kasutada koopiat või serveri riistvarakonfiguratsioon on nõrgem. Orkester toetab käsitsi reeglid, mille abil saate kohandada oma kandidaadi valiku eelistusi eelistatuimast ignoreerituks.

Reageerimis- ja taastumisaeg

Juhtumi korral on oluline süsteemi seisakuid minimeerida, seega mõelgem MySQL-i parameetritele, mis mõjutavad klastri topoloogia loomist ja värskendamist orkestraatori poolt:

• slave_net_timeout — sekundite arv, mille jooksul koopia ootab ülemseadmelt uute andmete või südamelöögisignaali saabumist, enne kui ühendus tuvastatakse katkenuks ja taasühendatakse. Mida madalam väärtus, seda kiiremini saab koopia kindlaks teha, et side ülemseadmega on katkenud. Seadsime selle väärtuse 5 sekundiks.
• MASTER_CONNECT_RETRY — taasühendamiskatsete vaheline sekundite arv. Võrguprobleemide korral võimaldab selle parameetri madal väärtus kiiresti uuesti ühendada ja takistab klastri taastamise protsessi käivitamist. Soovitatav väärtus on 1 sekund.
• MASTER_RETRY_COUNT — maksimaalne taasühendamiskatsete arv.
• MASTER_HEARTBEAT_PERIOD — intervall sekundites, mille järel kapten saadab südamelöögisignaali. Vaikimisi on pool väärtusest slave_net_timeout.

Orkestri parameetrid:

• DelayMasterPromotionIfSQLThreadNotUpToDate - kui võrdne true, siis ei rakendata põhirolli kandidaatreplicale enne, kui replica SQL-lõim on lõpetanud kõik edastuslogi rakendamata tehingud. Kasutame seda valikut tehingute kaotamise vältimiseks, kui kõik kandidaatkoopiad jäävad maha.
• InstancePollSeconds — topoloogia koostamise ja ajakohastamise sagedus.
• RecoveryPollSeconds — topoloogiaanalüüsi sagedus. Kui probleem tuvastatakse, käivitatakse topoloogia taastamine. See pidev, võrdne 1 sekundiga.

Iga klastri sõlme küsitleb orkestraator üks kord InstancePollSeconds sekundit Kui probleem tuvastatakse, sunnitakse klastri olek uuendatudja seejärel tehakse lõplik otsus taastamise teostamiseks. Erinevate andmebaasi ja orkestraatori parameetritega katsetades suutsime vähendada reageerimis- ja taastumisaega 30 sekundini.

Katselaud

HA-skeemi testimist alustasime lokaalse arendusega katsestend ja edasine juurutamine katse- ja tootmiskeskkondades. Kohalik stend on Dockeril põhinev täielikult automatiseeritud ning võimaldab katsetada orkestraatori ja võrgu konfiguratsiooni, skaleerida klastrit 2-3 serverilt mitmekümneni ning läbi viia harjutusi turvalises keskkonnas.

Harjutuste ajal valime ühe probleemide emuleerimismeetoditest: tulistage meister koheselt kasutades kill -9, lõpetage pehmelt protsess ja peatage server (docker-compose stop), simuleerida võrguprobleeme kasutades iptables -j REJECT või iptables -j DROP. Ootame järgmisi tulemusi:

• orkestraator tuvastab kapteniga seotud probleemid ja värskendab topoloogiat mitte rohkem kui 10 sekundiga;
• taastamise protseduur käivitub automaatselt: võrgu konfiguratsioon muutub, kapteni roll läheb üle koopiale, topoloogia ehitatakse ümber;
• uus master muutub kirjutatavaks, reaalajas koopiad ei lähe ümberehituse käigus kaduma;
• andmeid hakatakse uude põhiseadmesse kirjutama ja kopeerima;
• Kogu taastumisaeg ei ületa 30 sekundit.

Teadupärast võib süsteem testimis- ja tootmiskeskkondades käituda erinevalt erineva riistvara- ja võrgukonfiguratsiooni, sünteetilise ja reaalse koormuse jms tõttu. Seetõttu viime perioodiliselt läbi harjutusi reaalsetes tingimustes, kontrollides, kuidas süsteem käitub võrguühenduse katkemise või selle üksikute osade halvenemise korral. Tulevikus tahame ehitada mõlemale keskkonnale täiesti identse taristu ja automatiseerida selle testimise.

Järeldused

Peamise salvestussüsteemi sõlme tervis on SRE ja operatsioonide meeskonna üks peamisi ülesandeid. VIP-il põhineva orkestraatori ja HA lahenduse rakendamine võimaldas meil saavutada järgmised tulemused:

• andmebaasi klastri topoloogiaga seotud probleemide usaldusväärne tuvastamine;
• automaatne ja kiire reageerimine kapteniga seotud intsidentidele, vähendades süsteemi seisakuid.

Siiski on sellel lahendusel oma piirangud ja puudused:

• HA-skeemi skaleerimine mitmele andmekeskusele nõuab nende vahel ühte L2-võrku;
• Enne VIP-i määramist uuele juhile peame selle vanale välja andma. Protsess on järjestikune, mis suurendab taastumisaega;
• VIP-i vabastamiseks on vaja SSH-juurdepääsu serverile või mõnda muud meetodit kaugprotseduuride väljakutsumiseks. Kuna serveril või andmebaasil on probleeme, mis põhjustasid taastamisprotsessi, ei saa me olla kindlad, et VIP-i eemaldamine lõpeb edukalt. Ja see võib viia kahe sama virtuaalse IP-aadressiga serveri ilmumiseni ja probleemini split brain.

Vältima split brain, saate meetodit kasutada STONITH (“Shoot The Other Node In The Head”), mis isoleerib või keelab probleemse sõlme täielikult. Klastri kõrge kättesaadavuse rakendamiseks on ka teisi viise: VIP-i ja DNS-i kombinatsioon, teenuse avastamise ja puhverserveri teenused, sünkroonne replikatsioon ja muud meetodid, millel on oma puudused ja eelised.

Rääkisin meie lähenemisviisist MySQL-i tõrkesiirdeklastri loomisel. Seda on lihtne rakendada ja see tagab praegustes tingimustes vastuvõetava töökindluse. Kuna kogu süsteem üldiselt ja eriti infrastruktuur arenevad, siis see lähenemisviis kahtlemata areneb.

Allikas: www.habr.com