V Citymobile používame databázu MySQL ako naše hlavné trvalé úložisko dát. Máme niekoľko databázových klastrov pre rôzne služby a účely.

Neustála dostupnosť mastera je kritickým ukazovateľom výkonu celého systému a jeho jednotlivých častí. Automatická obnova klastra v prípade hlavného zlyhania výrazne skracuje dobu odozvy na incidenty a výpadky systému. V tomto článku sa pozriem na dizajn vysokej dostupnosti (HA) pre klaster MySQL založený na MySQL Orchestrator a virtuálne IP adresy (VIP).

HA riešenie založené na VIP

Najprv vám stručne poviem, aký je náš systém ukladania údajov.

Používame klasickú schému replikácie s jedným masterom prístupným na zápis a viacerými replikami len na čítanie. Klaster môže obsahovať prechodný hlavný server – uzol, ktorý je pre ostatných replikou aj hlavným. Klienti pristupujú k replikám cez HAProxy, čo umožňuje rovnomerné rozloženie záťaže a jednoduché škálovanie. Použitie HAProxy je z historických dôvodov av súčasnosti prebieha proces migrácie na ProxySQL.

Replikácia sa vykonáva v semisynchrónnom režime na základe GTID. To znamená, že aspoň jedna replika musí zaznamenať transakciu predtým, ako sa považuje za úspešnú. Tento režim replikácie poskytuje optimálnu rovnováhu medzi výkonom a bezpečnosťou údajov v prípade zlyhania hlavného uzla. V podstate všetky zmeny sa prenesú z predlohy na repliky pomocou Row Based Replication (RBR), ale niektoré uzly môžu mať mixed binlog format.

Orchestrator pravidelne aktualizuje stav topológie klastra, analyzuje prijaté informácie a ak sa vyskytnú problémy, môže spustiť procedúru automatickej obnovy. Vývojár je zodpovedný za samotný postup, pretože ho možno implementovať rôznymi spôsobmi: na základe VIP, DNS, pomocou služieb zisťovania služieb alebo mechanizmov, ktoré si sami napíšu.

Jeden jednoduchý spôsob, ako obnoviť master, ak zlyhá, je použiť plávajúce VIP adresy.

Čo potrebujete vedieť o tomto riešení predtým, ako budete pokračovať:

• VIP je IP adresa, ktorá nie je spojená s konkrétnym fyzickým sieťovým rozhraním. Ak zlyhá uzol alebo počas plánovanej údržby, môžeme prepnúť VIP na iný zdroj s minimálnymi prestojmi.
• Uvoľnenie a vydanie virtuálnej IP adresy je lacná a rýchla operácia.
• Na prácu s VIP potrebujete prístup k serveru cez SSH alebo použitie špeciálnych nástrojov, napr. keepalived.

Pozrime sa na možné problémy s naším sprievodcom a predstavme si, ako by mal fungovať mechanizmus automatického obnovenia.

Sieťové pripojenie k hlavnému zariadeniu zmizlo alebo sa vyskytol problém na úrovni hardvéru a server je nedostupný

1. Orchestrator aktualizuje topológiu klastra, každá replika hlási, že hlavný server je nedostupný. Orchestrátor spustí proces výberu repliky vhodnej pre úlohu nového majstra a začne s obnovou.
2. Snažíme sa odstrániť VIP zo starého majstra - neúspešne.
3. Replika sa prepne do úlohy majstra. Prebieha prestavba topológie.
4. Pridanie nového sieťového rozhrania s VIP. Keďže VIP nebolo možné odstrániť, na pozadí začneme pravidelne odosielať žiadosť bezodplatná ARP. Tento typ požiadavky/odpovede vám umožňuje aktualizovať tabuľku mapovania IP a MAC adries na pripojených prepínačoch, čím vás upozorní, že sa náš VIP presťahoval. Tým sa minimalizuje pravdepodobnosť split brain pri vrátení starého majstra.
5. Všetky nové pripojenia sú okamžite presmerované na nový master. Staré pripojenia zlyhávajú a na úrovni aplikácie sa uskutočňujú opakované volania do databázy.

Server pracuje v normálnom režime, došlo k zlyhaniu na úrovni DBMS

Algoritmus je podobný ako v predchádzajúcom prípade: aktualizácia topológie a spustenie procesu obnovy. Keďže server je dostupný, úspešne uvoľníme VIP na starom mastere, prenesieme ho na nový a odošleme niekoľko požiadaviek ARP. Prípadné vrátenie starého mastera by nemalo ovplyvniť prebudovaný klaster a fungovanie aplikácie.

Iné problémy

Zlyhanie replík alebo prechodných predloh nevedie na automatické akcie a vyžaduje manuálny zásah.

Rozhranie virtuálnej siete sa vždy pridáva dočasne, to znamená, že po reštarte servera sa VIP nepriradí automaticky. Každá inštancia databázy sa štandardne spúšťa v režime len na čítanie, orchestrátor automaticky prepne nový master na zápis a pokúsi sa ho nainštalovať read only na starom pánovi. Tieto akcie sú zamerané na zníženie pravdepodobnosti split brain.

Počas procesu obnovy môžu nastať problémy, na ktoré by sa okrem štandardných monitorovacích nástrojov malo upozorniť aj prostredníctvom používateľského rozhrania orchestrátora. Rozšírili sme REST API pridaním tejto funkcie (PR v súčasnosti sa skúma).

Všeobecný diagram riešenia HA je uvedený nižšie.

Výber nového majstra

Orchestrátor je dostatočne šikovný a snaží sa vyberať najvhodnejšia replika ako nový majster podľa nasledujúcich kritérií:

• replika zaostáva za predlohou;
• MySQL verzia predlohy a repliky;
• typ replikácie (RBR, SBR alebo zmiešané);
• umiestnenie v rovnakých alebo rôznych dátových centrách;
• dostupnosť errant GTID — transakcie, ktoré boli vykonané na replike a nie sú na hlavnej;
• zohľadňujú sa aj pravidlá vlastného výberu.

Nie každé tágo je ideálnym kandidátom na majstra. Napríklad na zálohovanie údajov možno použiť repliku alebo server má slabšiu hardvérovú konfiguráciu. Orchestra podporuje manuálne pravidlá, pomocou ktorých si môžete prispôsobiť svoje preferencie výberu kandidátov od najpreferovanejších po ignorované.

Čas odozvy a zotavenia

V prípade incidentu je dôležité minimalizovať prestoje systému, preto zvážme parametre MySQL, ktoré ovplyvňujú vytváranie a aktualizáciu topológie klastra zo strany orchestrátora:

• slave_net_timeout — počet sekúnd, počas ktorých replika čaká na príchod nových údajov alebo signálu srdcového tepu od hlavného zariadenia, kým sa spojenie rozpozná ako stratené a znovu sa pripojí. Čím nižšia je hodnota, tým rýchlejšie môže replika určiť, že komunikácia s masterom je prerušená. Túto hodnotu nastavíme na 5 sekúnd.
• MASTER_CONNECT_RETRY — počet sekúnd medzi pokusmi o opätovné pripojenie. V prípade problémov so sieťou nízka hodnota tohto parametra umožní rýchle opätovné pripojenie a zabráni spusteniu procesu obnovy klastra. Odporúčaná hodnota je 1 sekunda.
• MASTER_RETRY_COUNT — maximálny počet pokusov o opätovné pripojenie.
• MASTER_HEARTBEAT_PERIOD — interval v sekundách, po ktorom master vyšle signál srdcového tepu. Predvolená hodnota je polovičná slave_net_timeout.

Parametre orchestra:

• DelayMasterPromotionIfSQLThreadNotUpToDate - ak je rovnaký true, potom sa hlavná rola nepoužije na kandidátsku repliku, kým vlákno SQL repliky nedokončí všetky neaplikované transakcie z protokolu prenosu. Túto možnosť používame, aby sme sa vyhli strate transakcií, keď všetky kandidátske repliky zaostávajú.
• InstancePollSeconds — frekvencia budovania a aktualizácie topológie.
• RecoveryPollSeconds — frekvencia topologickej analýzy. Ak sa zistí problém, spustí sa obnova topológie. Toto konštantný, rovná 1 sekunde.

Každý klastrový uzol je dotazovaný orchestrátorom raz za InstancePollSeconds sekúnd Keď sa zistí problém, vynúti sa stav klastra aktualizovanéa potom sa urobí konečné rozhodnutie o vykonaní obnovy. Experimentovaním s rôznymi parametrami databázy a orchestrátora sa nám podarilo skrátiť čas odozvy a obnovy na 30 sekúnd.

skúšobná stolica

Schému HA sme začali testovať s vývojom lokálu skúšobná stolica a ďalšiu implementáciu v testovacích a produkčných prostrediach. Lokálny stojan je plne automatizovaný na základe Dockera a umožňuje vám experimentovať s konfiguráciou orchestrátora a siete, škálovať klaster z 2-3 serverov na niekoľko desiatok a vykonávať cvičenia v bezpečnom prostredí.

Počas cvičení si vyberáme jednu z metód emulácie problému: okamžite zastreliť majstra pomocou kill -9, jemne ukončite proces a zastavte server (docker-compose stop), simulujte problémy so sieťou pomocou iptables -j REJECT alebo iptables -j DROP. Očakávame nasledovné výsledky:

• orchestrátor zistí problémy s masterom a aktualizuje topológiu do 10 sekúnd;
• automaticky sa spustí procedúra obnovy: zmení sa konfigurácia siete, úloha master prejde na repliku, prebuduje sa topológia;
• nová predloha sa stane zapisovateľnou, živé repliky sa počas procesu prestavby nestratia;
• údaje sa začnú zapisovať do nového hlavného servera a replikovať sa;
• Celkový čas obnovy nebude dlhší ako 30 sekúnd.

Ako viete, systém sa môže správať odlišne v testovacích a produkčných prostrediach v dôsledku rôznych hardvérových a sieťových konfigurácií, rozdielov v syntetickom a reálnom zaťažení atď. Preto pravidelne vykonávame cvičenia v reálnych podmienkach, kde kontrolujeme, ako sa systém správa pri strate sieťového pripojenia alebo degradácii jeho jednotlivých častí. V budúcnosti chceme vybudovať úplne identickú infraštruktúru pre obe prostredia a automatizovať jej testovanie.

Závery

Zdravie uzla hlavného úložného systému je jednou z hlavných úloh SRE a operačného tímu. Implementácia orchestrátora a riešenia HA na báze VIP nám umožnila dosiahnuť nasledovné výsledky:

• spoľahlivá detekcia problémov s topológiou databázového klastra;
• automatická a rýchla reakcia na incidenty súvisiace s masterom, čím sa znižuje prestoje systému.

Riešenie má však svoje obmedzenia a nevýhody:

• škálovanie schémy HA na niekoľko dátových centier si bude vyžadovať jedinú sieť L2 medzi nimi;
• Pred priradením VIP k novému masteru ho musíme uvoľniť na starom. Proces je sekvenčný, čo zvyšuje čas zotavenia;
• uvoľnenie VIP vyžaduje SSH prístup k serveru alebo akýkoľvek iný spôsob volania vzdialených procedúr. Keďže server alebo databáza má problémy, ktoré spôsobili proces obnovy, nemôžeme si byť istí, že sa odstránenie VIP úspešne dokončí. A to môže viesť k objaveniu sa dvoch serverov s rovnakou virtuálnou IP adresou a problémom split brain.

Vyhnúť sa split brain, môžete použiť metódu STONITH („Shoot The Other Node In The Head“), čo úplne izoluje alebo deaktivuje problémový uzol. Existujú aj iné spôsoby implementácie vysokej dostupnosti klastra: kombinácia VIP a DNS, služby zisťovania služieb a proxy služieb, synchrónna replikácia a iné metódy, ktoré majú svoje nevýhody a výhody.

Hovoril som o našom prístupe k vytvoreniu failover klastra MySQL. Je ľahko implementovateľný a poskytuje prijateľnú úroveň spoľahlivosti v súčasných podmienkach. S vývojom celého systému vo všeobecnosti a konkrétnej infraštruktúry sa tento prístup bude nepochybne vyvíjať.

Zdroj: hab.com