ProHoster > Blogs > Administrācija > Orchestrator un VIP kā HA risinājums MySQL klasterim

Orchestrator un VIP kā HA risinājums MySQL klasterim

Uzņēmums Citymobil kā galveno pastāvīgo datu krātuvi izmantojam MySQL datu bāzi. Mums ir vairāki datu bāzu klasteri dažādiem pakalpojumiem un mērķiem.

Kapteiņa pastāvÄ«gā pieejamÄ«ba ir kritisks rādÄ«tājs visas sistēmas un tās atseviŔķu daļu veiktspējai. Automātiskā klasteru atkopÅ”ana galvenās kļūmes gadÄ«jumā ievērojami samazina incidentu reakcijas laiku un sistēmas dÄ«kstāves laiku. Å ajā rakstā es aplÅ«koÅ”u augstas pieejamÄ«bas (HA) dizainu MySQL klasterim, kura pamatā ir MySQL Orchestrator un virtuālās IP adreses (VIP).

Orchestrator un VIP kā HA risinājums MySQL klasterim

HA risinājums, kas balstīts uz VIP

Vispirms es Ä«si pastāstÄ«Å”u, kas ir mÅ«su datu uzglabāŔanas sistēma.

Mēs izmantojam klasisko replikācijas shēmu ar vienu rakstÄ«Å”anai pieejamu Å”ablonu un vairākām tikai lasāmām replikām. Klasteris var saturēt starpposma galveno elementu ā€” mezglu, kas ir gan replika, gan galvenais citiem. Klienti piekļūst replikām, izmantojot HAProxy, kas nodroÅ”ina vienmērÄ«gu slodzes sadalÄ«jumu un vieglu mērogoÅ”anu. HAProxy izmantoÅ”ana ir saistÄ«ta ar vēsturiskiem iemesliem, un paÅ”laik notiek migrÄ“Å”ana uz ProxySQL.

Replikācija tiek veikta daļēji sinhronā režīmā, pamatojoties uz GTID. Tas nozÄ«mē, ka vismaz vienai replikai ir jāreÄ£istrē darÄ«jums, lai to uzskatÄ«tu par veiksmÄ«gu. Å is replikācijas režīms nodroÅ”ina optimālu lÄ«dzsvaru starp veiktspēju un datu droŔību galvenā mezgla kļūmes gadÄ«jumā. BÅ«tÄ«bā visas izmaiņas tiek pārsÅ«tÄ«tas no galvenā uz replikām, izmantojot Row Based Replication (RBR), bet dažiem mezgliem var bÅ«t mixed binlog format.

OrÄ·estris periodiski atjaunina klastera topoloÄ£ijas stāvokli, analizē saņemto informāciju un, ja rodas problēmas, var uzsākt automātisku atkopÅ”anas procedÅ«ru. Izstrādātājs ir atbildÄ«gs par paÅ”u procedÅ«ru, jo to var ieviest dažādos veidos: pamatojoties uz VIP, DNS, izmantojot pakalpojumu atklāŔanas pakalpojumus vai paÅ”rakstÄ«tus mehānismus.

Viens vienkārŔs veids, kā atjaunot galveno, ja tas neizdodas, ir izmantot peldoŔās VIP adreses.

Kas jums jāzina par Ŕo risinājumu, pirms turpināt darbu:

  • VIP ir IP adrese, kas nav saistÄ«ta ar konkrētu fizisko tÄ«kla interfeisu. Ja mezgls neizdodas vai tiek veikta plānotā apkope, mēs varam pārslēgt VIP uz citu resursu ar minimālu dÄ«kstāvi.
  • Virtuālās IP adreses atbrÄ«voÅ”ana un izsniegÅ”ana ir lēta un ātra darbÄ«ba.
  • Lai strādātu ar VIP, jums ir nepiecieÅ”ama piekļuve serverim, izmantojot SSH, vai, piemēram, Ä«paÅ”u utilÄ«tu izmantoÅ”ana, keepalived.

ApskatÄ«sim iespējamās problēmas ar mÅ«su vedni un iedomāsimies, kā jādarbojas automātiskajam atkopÅ”anas mehānismam.

Tīkla savienojums ar galveno ierīci ir pazudis vai ir radusies problēma aparatūras līmenī, un serveris nav pieejams

  1. OrÄ·estris atjaunina klastera topoloÄ£iju, un katra replika ziņo, ka kapteinis nav pieejams. OrÄ·estris sāk jaunā meistara lomai piemērotas kopijas atlases procesu un sāk atveseļoÅ”anos.
  2. Mēģinām noņemt VIP no vecmeistara - bez panākumiem.
  3. Replika pāriet uz meistara lomu. Topoloģija tiek pārbūvēta.
  4. Jauna tÄ«kla saskarnes pievienoÅ”ana ar VIP. Tā kā VIP nebija iespējams noņemt, mēs periodiski sākam sÅ«tÄ«t pieprasÄ«jumu fonā bezmaksas ARP. Šāda veida pieprasÄ«jums/atbilde ļauj atjaunināt pievienoto slēdžu IP un MAC adreÅ”u kartÄ“Å”anas tabulu, tādējādi paziņojot, ka mÅ«su VIP ir pārcēlies. Tas samazina iespējamÄ«bu split brain atgriežot vecmeistaru.
  5. Visi jaunie savienojumi tiek nekavējoties novirzīti uz jauno galveno. Vecie savienojumi neizdodas, un lietojumprogrammas līmenī tiek veikti atkārtoti izsaukumi uz datu bāzi.

Serveris darbojas normālā režīmā, radās kļūme DBVS līmenī

Algoritms ir lÄ«dzÄ«gs iepriekŔējam gadÄ«jumam: topoloÄ£ijas atjaunināŔana un atkopÅ”anas procesa sākÅ”ana. Tā kā serveris ir pieejams, mēs veiksmÄ«gi atbrÄ«vojam VIP uz vecā galvenā, pārsÅ«tām to uz jauno un nosÅ«tām vairākus ARP pieprasÄ«jumus. Iespējamā vecā meistara atgrieÅ”ana nedrÄ«kst ietekmēt pārbÅ«vēto klasteru un lietojumprogrammas darbÄ«bu.

Citas problēmas

Kopiju vai starpposma meistaru neveiksmes neved automātiskām darbībām un nepiecieŔama manuāla iejaukŔanās.

Virtuālā tÄ«kla saskarne vienmēr tiek pievienota Ä«slaicÄ«gi, tas ir, pēc servera atsāknÄ“Å”anas VIP netiek automātiski pieŔķirts. Katrs datu bāzes gadÄ«jums pēc noklusējuma sākas tikai lasÄ«Å”anas režīmā, orÄ·estrētājs automātiski pārslēdz jauno galveno, lai rakstÄ«tu un mēģina instalēt read only par vecmeistaru. Å o darbÄ«bu mērÄ·is ir samazināt iespējamÄ«bu split brain.

AtkopÅ”anas procesa laikā var rasties problēmas, par kurām papildus standarta uzraudzÄ«bas rÄ«kiem ir jāinformē arÄ« orÄ·estra lietotāja saskarne. Mēs esam paplaÅ”inājuÅ”i REST API, pievienojot Å”o funkciju (PR paÅ”laik tiek pārskatÄ«ts).

HA risinājuma vispārējā diagramma ir parādīta zemāk.

Orchestrator un VIP kā HA risinājums MySQL klasterim

Jauna meistara izvēle

OrÄ·estris ir pietiekami gudrs un cenÅ”as izvēlēties vispiemērotākā kopija kā jauns meistars pēc Ŕādiem kritērijiem:

  • replika atpaliek no meistara;
  • Master un replikas MySQL versija;
  • replikācijas veids (RBR, SBR vai jaukts);
  • atraÅ”anās vieta tajā paŔā vai dažādos datu centros;
  • pieejamÄ«ba errant GTID ā€” transakcijas, kas tika veiktas reprodukcijā un neatrodas galvenajā ierÄ«cē;
  • tiek ņemti vērā arÄ« pielāgotie atlases noteikumi.

Ne katrs signāls ir ideāls meistara kandidāts. Piemēram, reprodukciju var izmantot datu dublÄ“Å”anai, vai arÄ« serverim ir vājāka aparatÅ«ras konfigurācija. OrÄ·estris atbalsta manuāli noteikumi, ar kuriem jÅ«s varat pielāgot kandidātu atlases preferences no vispiemērotākās uz ignorētajām.

Reakcijas un atveseļoŔanās laiks

NegadÄ«juma gadÄ«jumā ir svarÄ«gi samazināt sistēmas dÄ«kstāves laiku, tāpēc ņemsim vērā MySQL parametrus, kas ietekmē klastera topoloÄ£ijas izveidi un atjaunināŔanu, ko veicis orÄ·estrētājs:

  • slave_net_timeout ā€” sekunžu skaits, kuru laikā replika gaida jaunus datus vai sirdsdarbÄ«bas signālu, kas tiek saņemts no galvenā datora, pirms savienojums tiek atzÄ«ts par zaudētu un izveidots no jauna. Jo zemāka ir vērtÄ«ba, jo ātrāk kopija var noteikt, ka saziņa ar meistaru ir pārtraukta. Mēs iestatÄ«jām Å”o vērtÄ«bu uz 5 sekundēm.
  • MASTER_CONNECT_RETRY ā€” sekunžu skaits starp atkārtotas savienoÅ”anas mēģinājumiem. TÄ«kla problēmu gadÄ«jumā zema Ŕī parametra vērtÄ«ba ļaus ātri izveidot savienojumu un neļaus sākt klastera atkopÅ”anas procesu. Ieteicamā vērtÄ«ba ir 1 sekunde.
  • MASTER_RETRY_COUNT ā€” maksimālais atkārtotas savienoÅ”anas mēģinājumu skaits.
  • MASTER_HEARTBEAT_PERIOD ā€” intervāls sekundēs, pēc kura kapteinis nosÅ«ta sirdsdarbÄ«bas signālu. Noklusējuma vērtÄ«ba ir puse no vērtÄ«bas slave_net_timeout.

Orķestra iespējas:

  • DelayMasterPromotionIfSQLThreadNotUpToDate - ja vienāds true, tad galvenā loma kandidāta replikā netiks lietota, kamēr replikas SQL pavediens nebÅ«s pabeidzis visas neizmantotās transakcijas no pārraides žurnāla. Mēs izmantojam Å”o opciju, lai nezaudētu darÄ«jumus, kad visas kandidātu kopijas atpaliek.
  • InstancePollSeconds ā€” topoloÄ£ijas veidoÅ”anas un atjaunināŔanas biežums.
  • RecoveryPollSeconds ā€” topoloÄ£ijas analÄ«zes biežums. Ja tiek atklāta problēma, tiek uzsākta topoloÄ£ijas atkopÅ”ana. Å is nemainÄ«gs, vienāds ar 1 sekundi.

Katru klastera mezglu orÄ·estrētājs aptaujā vienu reizi InstancePollSeconds sekundes Kad tiek konstatēta problēma, klastera stāvoklis tiek piespiests atjaunināts, un tad tiek pieņemts galÄ«gais lēmums veikt atkopÅ”anu. Eksperimentējot ar dažādiem datu bāzes un orÄ·estratora parametriem, mēs varējām samazināt reakcijas un atkopÅ”anas laiku lÄ«dz 30 sekundēm.

Testa stends

Mēs sākām testēt HA shēmu, izstrādājot lokālo testu stends un turpmāka ievieÅ”ana testa un ražoÅ”anas vidēs. Vietējais stends ir pilnÄ«bā automatizēts, pamatojoties uz Docker, un ļauj eksperimentēt ar orÄ·estratora un tÄ«kla konfigurāciju, mērogot kopu no 2-3 serveriem lÄ«dz vairākiem desmitiem un veikt vingrinājumus droŔā vidē.

Vingrinājumu laikā mēs izvēlamies vienu no problēmu emulācijas metodēm: uzreiz noÅ”aut meistaru, izmantojot kill -9, maigi pārtrauciet procesu un apturiet serveri (docker-compose stop), simulē tÄ«kla problēmas, izmantojot iptables -j REJECT vai iptables -j DROP. Mēs sagaidām Ŕādus rezultātus:

  • orÄ·estrētājs atklās problēmas ar meistaru un atjauninās topoloÄ£iju ne vairāk kā 10 sekundēs;
  • automātiski sāksies atkopÅ”anas procedÅ«ra: mainÄ«sies tÄ«kla konfigurācija, galvenā loma tiks nodota kopijai, topoloÄ£ija tiks pārbÅ«vēta;
  • jaunais meistars kļūs rakstāms, dzÄ«vās kopijas pārbÅ«ves procesā netiks zaudētas;
  • datus sāks rakstÄ«t jaunajam meistaram un replicēt;
  • Kopējais atkopÅ”anas laiks bÅ«s ne vairāk kā 30 sekundes.

Kā zināms, sistēma testÄ“Å”anas un ražoÅ”anas vidēs var darboties atŔķirÄ«gi dažādu aparatÅ«ras un tÄ«kla konfigurāciju, sintētiskās un reālās slodzes atŔķirÄ«bu dēļ utt. Tāpēc mēs periodiski veicam vingrinājumus reālos apstākļos, pārbaudot, kā sistēma uzvedas, ja tiek zaudēta tÄ«kla savienojamÄ«ba vai tās atseviŔķas daļas ir degradētas. Nākotnē vēlamies izveidot pilnÄ«gi identisku infrastruktÅ«ru abām vidēm un automatizēt tās testÄ“Å”anu.

Atzinumi

Galvenā krātuves sistēmas mezgla veselÄ«ba ir viens no galvenajiem SRE un operāciju komandas uzdevumiem. OrÄ·estratora un HA risinājuma ievieÅ”ana, pamatojoties uz VIP, ļāva mums sasniegt Ŕādus rezultātus:

  • uzticama datu bāzes klastera topoloÄ£ijas problēmu noteikÅ”ana;
  • automātiska un ātra reakcija uz ar meistaru saistÄ«tiem incidentiem, samazinot sistēmas dÄ«kstāves laiku.

Tomēr risinājumam ir savi ierobežojumi un trūkumi:

  • lai mērogotu HA shēmu vairākiem datu centriem, starp tiem bÅ«s nepiecieÅ”ams viens L2 tÄ«kls;
  • Pirms VIP pieŔķirÅ”anas jaunajam galvenajam, mums tas ir jāatbrÄ«vo vecajā. Process ir secÄ«gs, kas palielina atveseļoÅ”anās laiku;
  • VIP atbrÄ«voÅ”anai nepiecieÅ”ama SSH piekļuve serverim vai jebkura cita attālo procedÅ«ru izsaukÅ”anas metode. Tā kā serverÄ« vai datu bāzē ir problēmas, kas izraisÄ«ja atkopÅ”anas procesu, mēs nevaram bÅ«t pārliecināti, ka VIP noņemÅ”ana tiks veiksmÄ«gi pabeigta. Un tas var izraisÄ«t divu serveru parādÄ«Å”anos ar vienādu virtuālo IP adresi un problēmu split brain.

IzvairÄ«ties split brain, varat izmantot metodi STONITS (ā€œShoot The Other Node In The Headā€), kas pilnÄ«bā izolē vai atspējo problēmas mezglu. Ir arÄ« citi veidi, kā ieviest klastera augstu pieejamÄ«bu: VIP un DNS kombinācija, pakalpojumu atklāŔanas un starpniekservera pakalpojumi, sinhronā replikācija un citas metodes, kurām ir savi trÅ«kumi un priekÅ”rocÄ«bas.

Es runāju par mÅ«su pieeju MySQL kļūmjpārlēces klastera izveidei. Tas ir viegli Ä«stenojams un nodroÅ”ina pieņemamu uzticamÄ«bas lÄ«meni paÅ”reizējos apstākļos. AttÄ«stoties visai sistēmai kopumā un jo Ä«paÅ”i infrastruktÅ«rai, Ŕī pieeja neapÅ”aubāmi attÄ«stÄ«sies.

Avots: www.habr.com

Pievieno komentāru