úvod

Před časem jsem dostal za úkol vyvinout cluster s podporou převzetí služeb při selhání PostgreSQL, fungující v několika datových centrech propojených vláknem ve stejném městě a schopných odolat selhání (například výpadku proudu) jednoho datového centra. Jako software, který je zodpovědný za odolnost proti chybám, jsem si vybral Kardiostimulátor, protože se jedná o oficiální řešení společnosti RedHat pro vytváření clusterů s podporou převzetí služeb při selhání. Je to dobré, protože RedHat pro to poskytuje podporu a protože toto řešení je univerzální (modulární). S jeho pomocí bude možné zajistit odolnost proti chybám nejen pro PostgreSQL, ale i pro další služby, ať už pomocí standardních modulů, nebo je vytvářet pro specifické potřeby.

K tomuto rozhodnutí vyvstala rozumná otázka: jak odolný bude cluster s podporou převzetí služeb při selhání? Abych to prozkoumal, vyvinul jsem testovací lavici, která simuluje různá selhání na uzlech clusteru, čeká na zotavení, obnoví neúspěšný uzel a pokračuje v testování ve smyčce. Zpočátku se tento projekt jmenoval hapgsql, ale postupem času mě název, který má pouze jednu samohlásku, omrzel. Proto jsem začal pojmenovávat databáze odolné proti chybám (a plovoucí IP adresy směřující na ně) krogan (postava z počítačové hry, ve které jsou duplikovány všechny důležité orgány) a uzly, shluky a samotný projekt jsou tuchanka (planeta, kde žijí krogani).

Vedení nyní schválilo otevřít projekt pro komunitu open source pod licencí MIT. Soubor README bude brzy přeložen do angličtiny (protože se očekává, že hlavními spotřebiteli budou vývojáři Pacemaker a PostgreSQL) a rozhodl jsem se vydat starou ruskou verzi README (částečně) ve formě tohoto článku.

Clustery jsou nasazeny na virtuálních počítačích VirtualBox. Celkem bude nasazeno 12 virtuálních strojů (celkem 36GiB), které tvoří 4 failover clustery (různé možnosti). První dva clustery se skládají ze dvou PostgreSQL serverů umístěných v různých datových centrech a společného serveru svědek c zařízení kvora (hostované na levném virtuálním počítači ve třetím datovém centru), který řeší nejistotu 50% / 50%odevzdáním svého hlasu. Třetí cluster ve třech datových centrech: jeden hlavní, dva podřízené, ne zařízení kvora. Čtvrtý cluster se skládá ze čtyř serverů PostgreSQL, dvou na datové centrum: jeden hlavní, zbytek jsou repliky a také používá svědek c zařízení kvora. Čtvrtý přežije výpadek dvou serverů nebo jednoho datového centra. Toto řešení lze v případě potřeby rozšířit na více replik.

Časová služba Ntpd také překonfigurován na odolnost proti chybám, ale používá metodu ntpd (sirotčí režim). Sdílený server svědek funguje jako centrální NTP server, rozděluje svůj čas do všech clusterů, čímž synchronizuje všechny servery mezi sebou. Li svědek selže nebo se ukáže, že je izolovaný, pak jeden z clusterových serverů (v rámci clusteru) začne rozdělovat svůj čas. Pomocné ukládání do mezipaměti HTTP proxy také zvýšen na svědek, s jeho pomocí mají další virtuální stroje přístup k úložištím Yum. Ve skutečnosti budou služby, jako je přesný čas a proxy, s největší pravděpodobností hostovány na vyhrazených serverech a v kabině jsou hostovány svědek pouze pro úsporu počtu virtuálních strojů a místa.

Verze

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

Struktura klastrů

Všechny clustery jsou navrženy tak, aby byly umístěny v několika datových centrech, sjednocených v jedné ploché síti a musí odolat selhání nebo síťové izolaci jednoho datového centra. Proto je nemožné použít k ochraně před rozdělený mozek standardní technologie Pacemaker tzv STONITH (Shoot The Other Node In The Head) popř oplocení. Jeho podstata: pokud uzly v clusteru začnou mít podezření, že s některým uzlem není něco v pořádku, nereaguje nebo se chová nesprávně, pak jej násilně vypnou prostřednictvím „externích“ zařízení, například řídicí karty IPMI nebo UPS. To však bude fungovat pouze v případech, kdy při jediném selhání serveru IPMI nebo UPS budou nadále fungovat. Plánuje také ochranu před mnohem katastrofičtějším selháním, kdy selže celé datové centrum (například je bez proudu). A s takovým odmítnutím všechno kamenitá-nebudou fungovat ani zařízení (IPMI, UPS atd.).

Místo toho je systém založen na myšlence kvora. Všechny uzly mají hlas a fungovat mohou pouze ty, které vidí více než polovinu všech uzlů. Toto číslo se nazývá „půl + 1“. usnášeníschopnost. Pokud není dosaženo kvora, pak se uzel rozhodne, že je v izolaci sítě a musí vypnout své zdroje, tzn. je to tak ochrana rozděleného mozku. Pokud nefunguje software, který je za toto chování zodpovědný, pak by měl fungovat hlídací pes, například založený na IPMI.

Pokud je počet uzlů sudý (shluk ve dvou datových centrech), pak může vzniknout tzv. nejistota 50% / 50% (padesát na padesát), kdy izolace sítě rozděluje cluster přesně na polovinu. Proto se pro sudý počet uzlů sčítá zařízení kvora - nenáročný daemon, který lze spustit na nejlevnějším virtuálním stroji ve třetím datovém centru. Dá svůj hlas jednomu ze segmentů (který vidí), a tím vyřeší 50%/50% nejistotu. Zavolal jsem server, na kterém poběží zařízení kvora svědek (názvosloví z repmgr, líbilo se mi to).

Zdroje se mohou přesouvat z místa na místo, například z vadných serverů na provozuschopné, nebo na příkaz systémových administrátorů. Aby klienti věděli, kde se nacházejí zdroje, které potřebují (kam se připojit?), plovoucí IP (plovoucí IP). Toto jsou IP adresy, které může Pacemaker pohybovat po uzlech (vše je v ploché síti). Každý z nich symbolizuje zdroj (službu) a bude umístěn tam, kde se potřebujete připojit, abyste získali přístup k této službě (v našem případě databáze).

Tuchanka1 (komprimované schéma)

Struktura

Myšlenka byla taková, že máme mnoho malých databází s nízkou zátěží, pro které je nerentabilní udržovat vyhrazený slave server v horkém pohotovostním režimu pro transakce pouze pro čtení (není potřeba takové plýtvání zdroji).

Každé datové centrum má jeden server. Každý server má dvě instance PostgreSQL (v terminologii PostgreSQL se jim říká clustery, ale aby nedošlo k záměně, budu je nazývat instancemi (analogicky s jinými databázemi) a clustery Pacemaker budu nazývat pouze clustery). Jedna instance pracuje v master režimu a pouze ona poskytuje služby (vede k ní pouze float IP). Druhá instance funguje jako slave pro druhé datové centrum a bude poskytovat služby pouze v případě, že její hlavní selže. Protože většinou pouze jedna ze dvou instancí (master) bude poskytovat služby (provádět požadavky), jsou všechny zdroje serveru optimalizovány pro master (paměť je alokována pro sdílenou mezipaměť, atd.), ale druhá instance má také dostatek prostředků (i když pro neoptimální práci přes mezipaměť souborového systému) pro případ, že by jedno z datových center selhalo. Slave neposkytuje služby (neprovádí požadavky pouze pro čtení) během normálního provozu clusteru, takže nedochází k válce o zdroje s masterem na stejném počítači.

V případě dvou uzlů je odolnost proti chybám možná pouze u asynchronní replikace, protože při synchronní replikaci povede selhání podřízeného k zastavení masteru.

neschopnost být svědkem

nebýt svědkem (zařízení kvora) Budu uvažovat pouze pro cluster Tuchanka1, stejný příběh bude se všemi ostatními. Pokud svědek selže, ve struktuře clusteru se nic nezmění, vše bude nadále fungovat tak, jak fungovalo. Ale kvorum bude 2 ze 3, a proto bude každé další selhání pro cluster fatální. Je třeba to ještě urychleně udělat.

Odmítnutí Tuchanka1

Výpadek jednoho z datových center pro Tuchanka1. V tomto případě svědek odevzdá svůj hlas druhému uzlu ve druhém datovém centru. Tam se bývalý slave promění v master, v důsledku toho oba master pracují na stejném serveru a obě jejich plovoucí IP adresy směřují na ně.

Tuchanka2 (klasika)

Struktura

Klasické schéma dvou uzlů. Na jednom pracuje pán, na druhém otrok. Oba mohou provádět požadavky (podřízený je pouze pro čtení), takže na oba ukazuje plovoucí IP: krogan2 je master, krogan2s1 je slave. Master i slave budou mít odolnost proti chybám.

V případě dvou uzlů je odolnost proti chybám možná pouze u asynchronní replikace, protože u synchronní replikace povede selhání podřízeného k zastavení masteru.

Odmítnutí Tuchanka2

Pokud selže jedno z datových center svědek hlasujte pro druhé. V jediném funkčním datovém centru bude master zvýšen a obě plovoucí IP budou na něj ukazovat: master a slave. Instance musí být samozřejmě nakonfigurována tak, aby měla dostatek prostředků (limity připojení atd.) k současnému přijímání všech připojení a požadavků od master i slave float IP. Čili při běžném provozu by měl mít dostatečnou rezervu na limity.

Tuchanka4 (mnoho otroků)

Struktura

Už další extrém. Existují databáze, které mají mnoho požadavků pouze pro čtení (typický případ vysoce zatíženého webu). Tuchanka4 je situace, kdy mohou být tři nebo více otroků na vyřízení takových požadavků, ale stále jich není příliš mnoho. Při velmi velkém počtu otroků bude nutné vymyslet hierarchický replikační systém. V minimálním případě (na obrázku) má každé ze dvou datových center dva servery, z nichž každý má instanci PostgreSQL.

Dalším rysem tohoto schématu je, že je zde již možné organizovat jednu synchronní replikaci. Je nakonfigurován tak, aby se pokud možno replikoval do jiného datového centra, a ne do repliky ve stejném datovém centru jako hlavní. Master a každý slave jsou označeny plovoucí IP. Nadobro mezi otroky bude nutné provést nějaké vyvažování požadavků sql proxy, například na straně klienta. Různé typy klientů mohou vyžadovat různé typy sql proxya pouze vývojáři klienta vědí, kdo který potřebuje. Tuto funkcionalitu lze implementovat buď externím démonem, nebo klientskou knihovnou (pool připojení) atd. To vše je nad rámec clusteru převzetí služeb při selhání databáze (failover SQL proxy lze implementovat nezávisle, spolu s převzetím služeb při selhání klienta).

Odmítnutí Tuchanka4

Pokud selže jedno datové centrum (tj. dva servery), svědek hlasuje pro druhé. Výsledkem je, že ve druhém datovém centru pracují dva servery: hlavní pracuje na jednom a hlavní plovoucí IP na něj ukazuje (pro přijímání požadavků na čtení a zápis); a na druhém serveru běží podřízený server se synchronní replikací a na něj ukazuje jedna z podřízených plovoucích IP (pro požadavky pouze pro čtení).

První věc, kterou je třeba poznamenat: ne všechny slave float IP budou fungovat, ale pouze jedna. A abychom s ním mohli správně pracovat, bude to nutné sql proxy přesměroval všechny požadavky na jedinou zbývající pohyblivou IP; a pokud sql proxy ne, můžete uvést všechny podřízené IP adresy s pohyblivou IP oddělenou čárkami v adrese URL připojení. V tom případě s libpq připojení bude k první pracovní IP, jako v automatickém testovacím systému. Možná v jiných knihovnách, například JDBC, to nebude fungovat a je to nutné sql proxy. Je to způsobeno tím, že float IP pro slave je zakázáno současně stoupat na jednom serveru, takže jsou rovnoměrně rozděleny mezi slave servery, pokud jich je několik.

Za druhé: i v případě selhání datového centra bude zachována synchronní replikace. A i když dojde k sekundárnímu selhání, to znamená, že jeden ze dvou serverů selže ve zbývajícím datovém centru, cluster, i když přestane poskytovat služby, bude stále uchovávat informace o všech potvrzených transakcích, u kterých potvrdil potvrzení (bude být žádná ztrátová informace o sekundárním selhání).

Tuchanka3 (3 datová centra)

Struktura

Jedná se o cluster pro situaci, kdy existují tři plně funkční datová centra, z nichž každé má plně funkční databázový server. V tomto případě zařízení kvora nepotřebný. Master pracuje v jednom datovém centru a slave pracují v dalších dvou. Replikace je synchronní, například ANY (slave1, slave2), to znamená, že klient obdrží potvrzení o potvrzení, když kterýkoli z podřízených jednotek jako první odpoví, že přijal potvrzení. Zdroje jsou označeny jednou plovoucí IP pro master a dvě pro slave. Na rozdíl od Tuchanka4 jsou všechny tři plovoucí IP odolné proti chybám. Chcete-li vyvážit dotazy SQL pouze pro čtení, můžete použít sql proxy (se samostatnou tolerancí proti chybám), nebo přiřadit jednu podřízenou IP float k polovině klientů a druhou k druhé polovině.

Odmítnutí Tuchanka3

Pokud jedno z datových center selže, zůstanou dvě. V jednom se zvednou hlavní a plovoucí IP od master, ve druhém se zvýší plovoucí IP podřízené a obě podřízené (instance musí mít dvojnásobnou rezervu prostředků, aby přijala všechna připojení z obou podřízených plovoucích IP). Synchronní replikace mezi mastery a slave. Cluster také uloží informace o potvrzených a potvrzených transakcích (nedojde ke ztrátě informací) v případě zničení dvou datových center (pokud nejsou zničena současně).

Rozhodl jsem se nezahrnout podrobný popis struktury souborů a nasazení. Pokud si chcete pohrát, můžete si to všechno přečíst v README. Uvádím pouze popis automatického testování.

Automatický testovací systém

Pro kontrolu chybové odolnosti clusterů s imitací různých poruch byl vytvořen automatický testovací systém. Spuštěno skriptem test/failure. Skript může mít jako parametry počet clusterů, které chcete testovat. Například tento příkaz:

test/failure 2 3

bude testovat pouze druhý a třetí cluster. Pokud parametry nejsou zadány, budou testovány všechny clustery. Všechny clustery jsou testovány paralelně a výsledek je zobrazen na panelu tmux. Tmux používá vyhrazený server tmux, takže skript lze spustit z výchozího tmux, což má za následek vnořený tmux. Terminál doporučuji používat ve velkém okně a s malým písmem. Před zahájením testování jsou všechny virtuální stroje vráceny zpět na snímek v době, kdy skript končí setup.

Terminál je rozdělen do sloupců podle počtu testovaných clusterů, standardně (na snímku obrazovky) jsou čtyři. Obsah sloupců popíšu na příkladu Tuchanka2. Panely na snímku obrazovky jsou očíslovány:

1. Zde se zobrazují statistiky testu. Řečníci:
   • selhání — název testu (funkce ve skriptu), který emuluje selhání.
   • reakce — aritmetický střední čas v sekundách, po který cluster obnovil svůj výkon. Měří se od spuštění skriptu, který emuluje selhání, až do okamžiku, kdy cluster obnoví svůj stav a je schopen pokračovat v poskytování služeb. Pokud je čas velmi krátký, například šest sekund (to se děje ve skupinách s několika podřízenými jednotkami (Tuchanka3 a Tuchanka4)), znamená to, že porucha skončila na asynchronním podřízeném zařízení a nijak neovlivnila výkon, nedošlo k přepínače stavu clusteru.
   • odchylka - ukazuje rozptyl (přesnost) hodnoty reakce metodou směrodatné odchylky.
   • počítat Kolikrát byl tento test proveden.
2. Krátký protokol umožňuje vyhodnotit, co cluster aktuálně dělá. Zobrazí se číslo iterace (testu), časové razítko a název operace. Příliš dlouhé provádění (> 5 minut) indikuje nějaký problém.
3. srdce (srdce) je aktuální čas. Pro hodnocení vizuálního výkonu mistři aktuální čas se neustále zapisuje do tabulky pomocí plovoucí IP adresy mastera. V případě úspěchu se výsledek zobrazí na tomto panelu.
4. porazit (puls) - "aktuální čas", který byl dříve zaznamenán skriptem srdce zvládnout, nyní číst z otrok prostřednictvím své plovoucí IP. Umožňuje vizuálně posoudit výkon podřízeného zařízení a replikace. V Tuchanka1 nejsou žádní slave s plovoucí IP (neexistují žádní slave poskytující služby), ale existují dvě instance (DB), takže zde nebude zobrazen porazita srdce druhá instance.
5. Sledování stavu clusteru pomocí nástroje pcs mon. Zobrazuje strukturu, rozdělení zdrojů podle uzlů a další užitečné informace.
6. Zobrazuje monitorování systému z každého virtuálního počítače clusteru. Těchto panelů může být více – kolik virtuálních strojů má cluster. Dva grafy Load CPU (dva procesory ve virtuálních strojích), název virtuálního stroje, Zatížení systému (s názvem Load Average, protože průměr za 5, 10 a 15 minut), procesní data a alokace paměti.
7. Sledování skriptu, který provádí testy. V případě poruchy – náhlé přerušení práce nebo nekonečný cyklus čekání – zde můžete vidět důvod tohoto chování.

Testování probíhá ve dvou fázích. Nejprve skript projde všemi typy testů, náhodně vybere virtuální stroj, na který má být tento test aplikován. Poté se provede nekonečný testovací cyklus, pokaždé se náhodně vyberou virtuální stroje a porucha. Náhlé ukončení testovacího skriptu (spodní panel) nebo nekonečná smyčka čekání na něco (> 5 minut času na dokončení jedné operace, je to vidět na trasování) naznačuje, že některé testy na tomto clusteru selhaly.

Každý test se skládá z následujících operací:

1. Spuštění funkce, která emuluje chybu.
2. Připraven? - čekání na obnovení zdraví clusteru (když jsou poskytovány všechny služby).
3. Je zobrazen časový limit obnovení klastru (reakce).
4. Opravit - cluster je "opraven". Poté by se měl vrátit do plně funkčního stavu a připraven na další poruchu.

Zde je seznam testů s popisem toho, co dělají:

• Vidlicová bomba: Vytvoří „Nedostatek paměti“ pomocí vidlicové bomby.
• OutOfSpace: pevný disk je plný. Test je ale spíše symbolický, při nevýznamné zátěži, která vzniká při testování, kdy se pevný disk přeteče, PostgreSQL většinou neselhává.
• Postgres-KILL: zabije PostgreSQL pomocí příkazu killall -KILL postgres.
• postgres-STOP: zavěsí PostgreSQL s příkazem killall -STOP postgres.
• Vypnutí: "deaktivuje" virtuální stroj pomocí příkazu VBoxManage controlvm "виртуалка" poweroff.
• resetovat: znovu načte virtuální počítač pomocí příkazu VBoxManage controlvm "виртуалка" reset.
• SBD STOP: pozastaví démona SBD pomocí příkazu killall -STOP sbd.
• Vypnutí: přes SSH odešle příkaz virtuálnímu počítači systemctl poweroff, systém se elegantně vypne.
• odpojit: izolace sítě, příkaz VBoxManage controlvm "виртуалка" setlinkstate1 off.

Ukončete testování buď standardním příkazem tmux "kill-window" ctrl-b&nebo příkazem "detach-client" ctrl-bd: současně je dokončeno testování, tmux je uzavřen, virtuální stroje jsou vypnuty.

Problémy zjištěné během testování

• V současné době hlídací démon sbd řeší zastavení pozorovaných démonů, ale ne jejich zmrazení. A v důsledku toho jsou poruchy nesprávně vyřešeny, což vede pouze k zamrznutí Corosync и Kardiostimulátor, ale ne visí Sbd. Pro kontrolu Corosync již mají PR#83 (na GitHubu na adrese Sbd), přijata do pobočky mistr. Slíbili (v PR#83), že něco podobného bude pro Pacemaker, doufám, že do Redhat xnumx udělám. Ale takové „poruchy“ jsou spekulativní, snadno uměle napodobitelné např. killall -STOP corosyncale nikdy se nepotkat v reálném životě.

• У Kardiostimulátor ve verzi pro CentOS 7 špatně nastaveno sync_timeout у zařízení kvorajako výsledek pokud jeden uzel selhal, druhý uzel se s určitou pravděpodobností restartoval, do kterého se měl mistr přestěhovat. Vytvrzeno zvětšením sync_timeout у zařízení kvora během nasazení (ve skriptu setup/setup1). Tento pozměňovací návrh nebyl vývojáři přijat Kardiostimulátor, místo toho slíbili přepracovat infrastrukturu tak (v nějaké neurčité budoucnosti), aby se tento časový limit počítal automaticky.

• Pokud jste zadali při konfiguraci databáze, že LC_MESSAGES (textové zprávy) Unicode lze použít např. ru_RU.UTF-8, poté při spuštění postgres v prostředí, kde není národní prostředí UTF-8, řekněme v prázdném prostředí (zde kardiostimulátor+pgsqlms(paf) začíná postgres), pak v logu místo písmen UTF-8 budou otazníky. Vývojáři PostgreSQL se nikdy neshodli na tom, co dělat v tomto případě. Stojí to, musíte dát LC_MESSAGES=en_US.UTF-8 při konfiguraci (vytváření) instance DB.

• Pokud je nastaven wal_receiver_timeout (ve výchozím nastavení je to 60s), pak při testování PostgreSQL-STOP na masteru v clusterech tuchanka3 a tuchanka4 Replikace se znovu nepřipojí k novému hlavnímu serveru. Replikace je tam synchronní, takže se zastaví nejen slave, ale i nový master. Získá se nastavením wal_receiver_timeout=0 při konfiguraci PostgreSQL.

• Občas jsem pozoroval, jak replikace PostgreSQL visí v testu ForkBomb (přetečení paměti). Po ForkBomb se někdy otroci nemusí znovu připojit k novému masteru. Viděl jsem to pouze v klastrech tuchanka3 a tuchanka4, kde kvůli tomu, že replikace je synchronní, master visel. Problém po nějaké dlouhé době (asi dvě hodiny) zmizel sám. K nápravě je zapotřebí další výzkum. Příznaky jsou podobné jako u předchozí chyby, která je způsobena jinou příčinou, ale se stejnými následky.

Kroganův snímek převzat z deviantní umění se svolením autora:

Zdroj: www.habr.com