Úvod

Pred nejakým časom som dostal za úlohu vyvinúť klaster prepnutia pri zlyhaní PostgreSQL, fungujúce vo viacerých dátových centrách prepojených optickým vláknom v rámci jedného mesta a schopné odolať výpadku (napríklad výpadku prúdu) jedného dátového centra. Ako softvér, ktorý je zodpovedný za odolnosť voči chybám, som si vybral kardiostimulátorpretože toto je oficiálne riešenie od RedHat na vytváranie failover klastrov. Je to dobré, pretože RedHat pre to poskytuje podporu a pretože toto riešenie je univerzálne (modulárne). S jeho pomocou bude možné zabezpečiť odolnosť voči chybám nielen PostgreSQL, ale aj iných služieb, či už pomocou štandardných modulov alebo ich vytváraním pre špecifické potreby.

Toto rozhodnutie vyvolalo rozumnú otázku: ako odolný bude klaster prepnutia pri zlyhaní? Aby som to preskúmal, vyvinul som testovaciu lavicu, ktorá simuluje rôzne zlyhania na uzloch klastra, čaká na obnovenie služby, obnoví chybný uzol a pokračuje v testovaní v slučke. Tento projekt sa pôvodne volal hapgsql, no časom som sa pri názve, ktorý mal len jednu samohlásku, omrzel. Preto som začal volať databázy odolné voči chybám (a plávajúce IP smerujúce na ne) krogan (postava z počítačovej hry, v ktorej sú duplikované všetky dôležité orgány) a uzly, zhluky a samotný projekt sú tuchanka (planéta, kde žijú krogani).

Teraz vedenie povolilo otvoriť projekt komunite open source pod licenciou MIT. README bude čoskoro preložené do angličtiny (pretože sa očakáva, že hlavnými konzumentmi budú vývojári Pacemaker a PostgreSQL) a ja som sa rozhodol (čiastočne) prezentovať starú ruskú verziu README vo forme tohto článku.

Klastre sú nasadené na virtuálnych počítačoch VirtualBox. Celkovo bude nasadených 12 virtuálnych strojov (spolu 36GiB), ktoré tvoria 4 klastre odolné voči chybám (rôzne možnosti). Prvé dva klastre pozostávajú z dvoch PostgreSQL serverov, ktoré sú umiestnené v rôznych dátových centrách, a spoločného servera svedok c zariadenie na kvórum (hostené na lacnom virtuálnom stroji v treťom dátovom centre), čím sa rieši neistota 50% / 50%, čím dáte svoj hlas jednej zo strán. Tretí klaster v troch dátových centrách: jeden hlavný, dva podriadené, č zariadenie na kvórum. Štvrtý klaster pozostáva zo štyroch serverov PostgreSQL, dvoch na dátové centrum: jeden hlavný, ostatné repliky a tiež používa svedok c zariadenie na kvórum. Štvrtý dokáže vydržať výpadok dvoch serverov alebo jedného dátového centra. Toto riešenie je možné v prípade potreby škálovať na väčší počet replík.

Služba presného času ntpd tiež prekonfigurovaný na odolnosť voči chybám, ale používa samotnú metódu ntpd (sirotský režim). Zdieľaný server svedok funguje ako centrálny NTP server, ktorý distribuuje svoj čas do všetkých klastrov, čím synchronizuje všetky servery medzi sebou. Ak svedok zlyhá alebo sa izoluje, potom jeden z klastrových serverov (v rámci klastra) začne distribuovať svoj čas. Pomocné ukladanie do vyrovnávacej pamäte HTTP proxy tiež povýšený na svedok, s jeho pomocou majú ďalšie virtuálne stroje prístup k úložiskám Yum. V skutočnosti budú služby, ako je presný čas a proxy, s najväčšou pravdepodobnosťou hosťované na dedikovaných serveroch, ale v stánku sú hosťované na svedok len na úsporu počtu virtuálnych strojov a priestoru.

verzia

v0. Funguje s CentOS 7 a PostgreSQL 11 na VirtualBox 6.1.

Štruktúra klastra

Všetky klastre sú navrhnuté tak, aby boli umiestnené vo viacerých dátových centrách, skombinované do jednej plochej siete a musia vydržať zlyhanie alebo izoláciu siete jedného dátového centra. Preto je nemožné použiť na ochranu proti rozdelený mozog štandardná technológia Pacemaker tzv STONITH (Shoot The Other Node In The Head) resp oplotenie. Jeho podstata: ak uzly v klastri začnú mať podozrenie, že s niektorým uzlom nie je niečo v poriadku, nereaguje alebo sa správa nesprávne, potom ho násilne vypnú prostredníctvom „externých“ zariadení, napríklad riadiacej karty IPMI alebo UPS. . Bude to však fungovať iba v prípadoch, keď v prípade jedinej poruchy server IPMI alebo UPS naďalej funguje. Tu sa plánujeme chrániť pred oveľa katastrofálnejším zlyhaním, keď zlyhá celé dátové centrum (napríklad stratí napájanie). A pri takomto odmietnutí všetko kamenný-zariadenia (IPMI, UPS atď.) tiež nebudú fungovať.

Namiesto toho je systém založený na myšlienke uznášaniaschopnosti. Všetky uzly majú hlas a fungovať môžu iba tie, ktoré vidia viac ako polovicu všetkých uzlov. Toto množstvo „polovica + 1“ sa nazýva kvórum. Ak sa nedosiahne kvórum, tak uzol rozhodne, že je v izolácii siete a musí vypnúť svoje zdroje, t.j. toto je to, čo to je ochrana rozdeleného mozgu. Ak nefunguje softvér, ktorý je zodpovedný za toto správanie, potom bude musieť fungovať strážny pes, napríklad založený na IPMI.

Ak je počet uzlov párny (zhluk v dvoch dátových centrách), potom môže vzniknúť takzvaná neistota 50% / 50% (pätdesiat na päťdesiat), keď izolácia siete rozdelí klaster presne na polovicu. Preto pre párny počet uzlov pridávame zariadenie na kvórum je nenáročný démon, ktorý je možné spustiť na najlacnejšom virtuálnom stroji v treťom dátovom centre. Dá svoj hlas jednému zo segmentov (ktorý vidí), a tým vyrieši 50%/50% neistotu. Pomenoval som server, na ktorom sa spustí zariadenie kvóra svedok (názvoslovie z repmgr, páčilo sa mi to).

Zdroje je možné presúvať z miesta na miesto, napríklad z chybných serverov na zdravé, alebo na príkaz systémových administrátorov. Aby klienti vedeli, kde sa nachádzajú zdroje, ktoré potrebujú (kam sa pripojiť?), plávajúca IP (float IP). Sú to IP adresy, ktoré môže Pacemaker presúvať po uzloch (všetko je na plochej sieti). Každý z nich symbolizuje zdroj (službu) a bude umiestnený tam, kde sa potrebujete pripojiť, aby ste získali prístup k tejto službe (v našom prípade k databáze).

Tuchanka1 (okruh so zhutňovaním)

Štruktúra

Myšlienkou bolo, že máme veľa malých databáz s nízkou záťažou, pre ktoré je nerentabilné udržiavať dedikovaný podriadený server v horúcom pohotovostnom režime pre transakcie len na čítanie (nie je potrebné také plytvanie zdrojmi).

Každé dátové centrum má jeden server. Každý server má dve inštancie PostgreSQL (v terminológii PostgreSQL sa nazývajú klastre, ale aby nedošlo k zámene, budem ich nazývať inštancie (analogicky s inými databázami) a klastre Pacemaker budem nazývať iba klastre). Jedna inštancia funguje v režime master a iba ona poskytuje služby (vedie k nej iba pohyblivá IP). Druhá inštancia funguje ako slave pre druhé dátové centrum a bude poskytovať služby iba v prípade, že zlyhá jej master. Keďže väčšinou iba jedna inštancia z dvoch (master) bude poskytovať služby (vykonávať požiadavky), všetky prostriedky servera sú optimalizované pre master (pamäť je alokovaná pre cache shared_buffers atď.), ale druhá inštancia má tiež dostatok zdrojov (hoci na neoptimálnu prevádzku cez vyrovnávaciu pamäť súborového systému) v prípade zlyhania jedného z dátových centier. Slave neposkytuje služby (nevykonáva požiadavky len na čítanie) počas normálnej prevádzky klastra, aby nedošlo k vojne o zdroje s masterom na rovnakom počítači.

V prípade dvoch uzlov je odolnosť voči chybám možná len pri asynchrónnej replikácii, pretože pri synchrónnej replikácii povedie zlyhanie podriadeného zariadenia k zastaveniu hlavného zariadenia.

Neschopnosť svedčiť

Neschopnosť byť svedkom (zariadenie na kvórum) Budem uvažovať len pre klaster Tuchanka1, so všetkými ostatnými to bude rovnaký príbeh. Ak svedok zlyhá, v štruktúre klastra sa nič nezmení, všetko bude naďalej fungovať tak, ako doteraz. Ale kvórum bude 2 z 3, a preto každé následné zlyhanie bude pre klaster fatálne. Ešte to bude treba urgentne opraviť.

Tuchanka1 odmietnutie

Výpadok jedného z dátových centier pre Tuchanku1. V tomto prípade svedok odovzdáva svoj hlas druhému uzlu v druhom dátovom centre. Tam sa bývalý slave zmení na master, výsledkom čoho je, že obaja master pracujú na rovnakom serveri a obe ich plávajúce IP adresy smerujú na nich.

Tuchanka2 (klasická)

Štruktúra

Klasická schéma dvoch uzlov. Na jednom pracuje pán, na druhom otrok. Oba môžu vykonávať požiadavky (podriadený je len na čítanie), takže na oba ukazuje plávajúca IP: krogan2 je master, krogan2s1 je slave. Master aj slave budú odolné voči chybám.

V prípade dvoch uzlov je tolerancia chýb možná len pri asynchrónnej replikácii, pretože pri synchrónnej replikácii povedie zlyhanie podriadeného k zastaveniu nadriadeného.

Tuchanka2 odmietnutie

Ak jedno z dátových centier zlyhá svedok hlasuje za druhú. V jedinom fungujúcom dátovom centre bude master zdvihnutý a budú naň ukazovať obe plávajúce IP: master aj slave. Samozrejme, inštancia musí byť nakonfigurovaná tak, aby mala dostatok prostriedkov (limity pripojení a pod.) na súčasné akceptovanie všetkých pripojení a požiadaviek od master a slave float IP. To znamená, že pri bežnej prevádzke by mal mať dostatočnú zásobu limitov.

Tuchanka4 (veľa otrokov)

Štruktúra

Už ďalší extrém. Existujú databázy, ktoré dostávajú veľa požiadaviek iba na čítanie (typický prípad stránky s vysokým zaťažením). Tuchanka4 je situácia, keď môžu byť traja alebo viacerí otroci na vybavenie takýchto požiadaviek, ale stále ich nie je príliš veľa. Pri veľmi veľkom počte otrokov bude potrebné vymyslieť hierarchický replikačný systém. V minimálnom prípade (na obrázku) má každé z dvoch dátových centier dva servery, každý s inštanciou PostgreSQL.

Ďalšou vlastnosťou tejto schémy je, že už je možné zorganizovať jednu synchrónnu replikáciu. Je nakonfigurovaný na replikáciu, ak je to možné, do iného dátového centra, a nie do repliky v rovnakom dátovom centre ako hlavné. Master a každý slave sú nasmerované pomocou plávajúcej IP. Našťastie medzi otrokmi bude potrebné nejako vyvážiť požiadavky sql proxy, napríklad na strane klienta. Rôzne typy klientov môžu vyžadovať rôzne typy sql proxya iba vývojári klientov vedia, kto čo potrebuje. Táto funkcionalita môže byť implementovaná buď externým démonom alebo klientskou knižnicou (pool pripojení) atď. Toto všetko presahuje tému databázového klastra prepnutia pri zlyhaní (failover SQL proxy môžu byť implementované nezávisle, spolu s odolnosťou voči chybám klienta).

Tuchanka4 odmietnutie

Ak jedno dátové centrum (t. j. dva servery) zlyhá, svedok hlasuje za druhé. Výsledkom je, že v druhom dátovom centre bežia dva servery: na jednom je spustený hlavný a hlavná pohyblivá adresa IP ukazuje naň (na prijímanie požiadaviek na čítanie a zápis); a na druhom serveri beží slave so synchrónnou replikáciou a jedna z podriadených plávajúcich IP adries naň ukazuje (pre požiadavky len na čítanie).

Prvá vec, ktorú treba poznamenať, je, že nie všetky podriadené plávajúce IP budú pracovníci, ale iba jedna. A aby ste s ním mohli správne pracovať, bude to potrebné sql proxy presmeroval všetky požiadavky na jedinú zostávajúcu pohyblivú IP; A keď sql proxy nie, potom môžete uviesť zoznam všetkých plávajúcich IP slave oddelených čiarkami v adrese URL pripojenia. V tomto prípade s libpq pripojenie bude k prvej pracovnej IP, to sa robí v systéme automatického testovania. Možno v iných knižniciach, napríklad JDBC, to nebude fungovať a je to potrebné sql proxy. Deje sa tak preto, že plávajúce IP adresy pre podriadené servery sa nesmú vytvárať súčasne na jednom serveri, aby boli rovnomerne rozdelené medzi podriadené servery, ak ich beží niekoľko.

Po druhé: aj v prípade zlyhania dátového centra bude zachovaná synchrónna replikácia. A aj keď dôjde k sekundárnemu zlyhaniu, to znamená k zlyhaniu jedného z dvoch serverov vo zvyšnom dátovom centre, klaster, hoci prestane poskytovať služby, bude stále uchovávať informácie o všetkých potvrdených transakciách, pre ktoré vydal potvrdenie o potvrdení. (v prípade sekundárneho zlyhania nebudú žiadne informácie o strate).

Tuchanka3 (3 dátové centrá)

Štruktúra

Ide o klaster pre situáciu, keď existujú tri plne funkčné dátové centrá, z ktorých každé má plne funkčný databázový server. V tomto prípade zariadenie na kvórum nepotrebné. V jednom dátovom centre pracuje master, v ďalších dvoch pracujú otroci. Replikácia je synchrónna, zadajte ANY (slave1, slave2), to znamená, že klient dostane potvrdenie o odovzdaní, keď ktorýkoľvek z podriadených zariadení ako prvý odpovie, že prijal odovzdanie. Zdroje sú označené jednou pohyblivou IP pre master a dvomi pre slave. Na rozdiel od Tuchanka4 sú všetky tri float IP odolné voči chybám. Na vyváženie dotazov SQL iba na čítanie môžete použiť sql proxy (so samostatnou toleranciou chýb), alebo priraďte jednu slave float IP polovici klientov a druhú polovicu druhej.

Tuchanka3 odmietnutie

Ak jedno z dátových centier zlyhá, zostanú dve. V jednom sa zvýši hlavná a plávajúca IP od mastera, v druhom - slave a obe slave plávajúce IP (inštancia musí mať dvojitú rezervu zdrojov, aby mohla akceptovať všetky pripojenia z oboch podriadených plávajúcich IP). Synchrónna replikácia medzi mastermi a slave. Taktiež klaster uloží informácie o vykonaných a potvrdených transakciách (nedôjde k strate informácií) v prípade zničenia dvoch dátových centier (ak nie sú zničené súčasne).

Rozhodol som sa nepridávať podrobný popis štruktúry súborov a nasadenia. Každý, kto sa chce pohrať, si to všetko môže prečítať v README. Poskytujem len popis automatického testovania.

Automatický testovací systém

Na testovanie odolnosti klastrov proti chybám simuláciou rôznych porúch bol vytvorený automatický testovací systém. Spustené skriptom test/failure. Skript môže mať ako parametre počet klastrov, ktoré chcete testovať. Napríklad tento príkaz:

test/failure 2 3

bude testovať iba druhý a tretí klaster. Ak nie sú špecifikované parametre, budú testované všetky klastre. Všetky klastre sa testujú paralelne a výsledok sa zobrazí na paneli tmux. Tmux používa vyhradený server tmux, takže skript možno spustiť z predvoleného tmux, čo vedie k vnoreným tmux. Terminál odporúčam používať vo veľkom okne a s malým písmom. Pred začatím testovania sa všetky virtuálne stroje vrátia späť na snímku v čase dokončenia skriptu setup.

Terminál je rozdelený do stĺpcov podľa počtu testovaných klastrov, štandardne (na snímke obrazovky) sú štyri. Obsah stĺpcov popíšem na príklade Tuchanka2. Panely na snímke obrazovky sú očíslované:

1. Tu sa zobrazujú štatistiky testov. Stĺpce:
   • zlyhanie — názov testu (funkcia v skripte), ktorý emuluje chybu.
   • reakcia — aritmetický priemerný čas v sekundách, počas ktorého klaster obnovil svoju funkčnosť. Meria sa od spustenia skriptu emulujúceho poruchu až do momentu, kedy klaster obnoví svoju funkčnosť a je schopný pokračovať v poskytovaní služieb. Ak je čas veľmi krátky, napríklad šesť sekúnd (to sa stáva v klastroch s niekoľkými podriadenými jednotkami (Tuchanka3 a Tuchanka4)), znamená to, že chyba bola na asynchrónnom podriadenom zariadení a nijako neovplyvnila výkon; prepínače stavu klastra.
   • odchýlka — zobrazuje rozptyl (presnosť) hodnoty reakcia pomocou metódy štandardnej odchýlky.
   • počítať — koľkokrát sa tento test vykonal.
2. Krátky protokol vám umožňuje vyhodnotiť, čo klaster momentálne robí. Zobrazí sa číslo iterácie (testu), časová pečiatka a názov operácie. Príliš dlhý chod (> 5 minút) znamená problém.
3. srdce (srdce) - aktuálny čas. Na vizuálne hodnotenie výkonu majster Aktuálny čas sa neustále zapisuje do tabuľky pomocou plávajúceho IP mastera. V prípade úspechu sa výsledok zobrazí na tomto paneli.
4. poraziť (pulz) - „aktuálny čas“, ktorý bol predtým zaznamenaný skriptom srdce zvládnuť, teraz čítajte z otrok prostredníctvom svojej pohyblivej IP. Umožňuje vám vizuálne posúdiť výkon podriadeného zariadenia a replikácie. V Tuchanke1 nie sú žiadni slave s pohyblivou IP (žiadni slave poskytujúci služby), ale sú tam dve inštancie (DB), takže to tu nebude zobrazené poraziťA srdce druhá inštancia.
5. Monitorovanie stavu klastra pomocou pomôcky pcs mon. Zobrazuje štruktúru, distribúciu zdrojov medzi uzlami a ďalšie užitočné informácie.
6. Tu sa zobrazuje monitorovanie systému z každého virtuálneho počítača v klastri. Takýchto panelov môže byť viac v závislosti od toho, koľko virtuálnych strojov má klaster. Dva grafy Zaťaženie procesora (virtuálne počítače majú dva procesory), názov virtuálneho počítača, Zaťaženie systému (s názvom Load Average, pretože sa spriemeruje za 5, 10 a 15 minút), spracovávané dáta a prideľovanie pamäte.
7. Stopa skriptu vykonávajúceho testovanie. V prípade poruchy - náhle prerušenie prevádzky alebo nekonečný cyklus čakania - tu môžete vidieť dôvod tohto správania.

Testovanie prebieha v dvoch etapách. Najprv skript prechádza všetkými typmi testov, pričom náhodne vyberie virtuálny stroj, na ktorý sa má tento test aplikovať. Potom sa vykoná nekonečný cyklus testovania, virtuálne stroje a chyba sa zakaždým vyberú náhodne. Náhle ukončenie testovacieho skriptu (spodný panel) alebo nekonečná slučka čakania na niečo (> 5 minút času vykonania jednej operácie, je to vidieť na stope) naznačuje, že niektoré testy na tomto klastri zlyhali.

Každý test pozostáva z nasledujúcich operácií:

1. Spustite funkciu, ktorá emuluje chybu.
2. Pripravený? — čakanie na obnovenie klastra (keď sú poskytnuté všetky služby).
3. Zobrazuje časový limit obnovenia klastra (reakcia).
4. Opraviť — klaster sa „opravuje“. Potom by sa mal vrátiť do plne funkčného stavu a byť pripravený na ďalšiu poruchu.

Tu je zoznam testov s popisom toho, čo robia:

• ForkBomba: Vytvorí "Nedostatok pamäte" pomocou vidlicovej bomby.
• OutOfSpace: Pevný disk je plný. Test je však skôr symbolický, pri nevýznamnej záťaži, ktorá vzniká počas testovania, PostgreSQL zvyčajne nezlyhá, keď je pevný disk plný.
• Postgres-KILL: zabíja PostgreSQL príkazom killall -KILL postgres.
• Postgres-STOP: zablokuje príkaz PostgreSQL killall -STOP postgres.
• Vypnúť: „deaktivuje“ virtuálny počítač pomocou príkazu VBoxManage controlvm "виртуалка" poweroff.
• resetovať: preťaží virtuálny stroj príkazom VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: suspenduje démona SBD príkazom killall -STOP sbd.
• Vypnúť: odošle príkaz virtuálnemu stroju cez SSH systemctl poweroff, systém sa elegantne vypne.
• Odpojiť: izolácia siete, príkaz VBoxManage controlvm "виртуалка" setlinkstate1 off.

Dokončenie testovania buď pomocou štandardného príkazu tmux "kill-window" Ctrl-b &, alebo príkaz „detach-client“. Ctrl-b d: v tomto bode testovanie končí, tmux sa zatvorí, virtuálne stroje sú vypnuté.

Problémy zistené počas testovania

• V súčasnosti strážny pes démon sbd funguje na zastavení pozorovaných démonov, ale nie na ich zmrazení. A v dôsledku toho chyby, ktoré vedú len k zamrznutiu Corosync и kardiostimulátor, ale nie visiace SBD... Pre kontrolu Corosync už má PR#83 (na GitHub na SBD), prijatý do vlákna majster. Sľúbili (v PR#83), že niečo podobné bude aj pre Pacemaker, dúfam, že do Červený klobúk 8 urobí. Takéto „poruchy“ sú však špekulatívne a dajú sa ľahko umelo simulovať napr. killall -STOP corosync, ale nikdy sa nestretnú v reálnom živote.

• У kardiostimulátor vo verzii pre 7 CentOS nesprávne nastavený sync_timeout у zariadenie na kvórumako výsledok ak jeden uzol zlyhal, s určitou pravdepodobnosťou sa reštartoval aj druhý uzol, do ktorej sa mal presťahovať majster. Vyliečené zväčšením sync_timeout у zariadenie na kvórum počas nasadenia (v skripte setup/setup1). Tento pozmeňujúci a doplňujúci návrh vývojári neprijali kardiostimulátor, namiesto toho sľúbili, že prerobia infraštruktúru takým spôsobom (v nejakej bližšie nešpecifikovanej budúcnosti), aby sa tento časový limit rátal automaticky.

• Ak to konfigurácia databázy špecifikuje LC_MESSAGES (textové správy) Unicode možno použiť napr. ru_RU.UTF-8, potom pri spustení postgres v prostredí, kde miestne nastavenie nie je UTF-8, povedzme v prázdnom prostredí (tu kardiostimulátor+pgsqlms(paf) beží postgres), potom denník bude obsahovať otázniky namiesto písmen UTF-8. Vývojári PostgreSQL sa nedohodli na tom, čo robiť v tomto prípade. Stojí to, musíte nainštalovať LC_MESSAGES=en_US.UTF-8 pri konfigurácii (vytváraní) inštancie databázy.

• Ak je nastavený wal_receiver_timeout (štandardne je to 60s), tak počas testu PostgreSQL-STOP na masteri v klastroch tuchanka3 a tuchanka4 replikácia sa znova nepripojí k novému hlavnému serveru. Replikácia je tam synchrónna, takže sa zastaví nielen slave, ale aj nový master. Dá sa to vyriešiť nastavením wal_receiver_timeout=0 pri konfigurácii PostgreSQL.

• Občas som pozoroval zamrznutie replikácie v PostgreSQL v teste ForkBomb (pretečenie pamäte). Po ForkBombe sa niekedy otroci nemusia znova pripojiť k novému hlavnému zariadeniu. Stretol som sa s tým len v klastroch tuchanka3 a tuchanka4, kde master zamrzol v dôsledku synchrónnej replikácie. Problém po dlhom čase (asi dve hodiny) sám od seba zmizol. Na nápravu je potrebný ďalší výskum. Príznaky sú podobné predchádzajúcej chybe, ktorá je spôsobená iným dôvodom, ale s rovnakými následkami.

Kroganov obrázok prevzatý z deviantné umenia so súhlasom autora:

Zdroj: hab.com