Predstavitev

Pred časom sem dobil nalogo, da razvijem failover cluster za PostgreSQL, ki delujejo v več podatkovnih centrih, povezanih z optičnimi vlakni znotraj enega mesta, in so sposobni prenesti izpad (na primer izpad) enega podatkovnega centra. Kot programsko opremo, ki je odgovorna za toleranco napak, sem izbral Srčni spodbujevalnikker je to uradna rešitev podjetja RedHat za ustvarjanje failover grozdov. Dobro je, ker RedHat nudi podporo za to in ker je ta rešitev univerzalna (modularna). Z njegovo pomočjo bo mogoče zagotoviti toleranco na napake ne samo PostgreSQL, ampak tudi drugih storitev, bodisi z uporabo standardnih modulov ali ustvarjanjem le-teh za posebne potrebe.

Ta odločitev je sprožila razumno vprašanje: kako odporna bo na napake gruča? Da bi to raziskal, sem razvil preskusno napravo, ki simulira različne napake na vozliščih gruče, čaka na obnovitev storitve, obnovi okvarjeno vozlišče in nadaljuje s testiranjem v zanki. Ta projekt se je prvotno imenoval hapgsql, vendar sem se čez čas naveličal imena, ki je imelo samo en samoglasnik. Zato sem začel klicati baze podatkov, odporne na napake (in plavajoči IP, ki kaže nanje) krogan (lik iz računalniške igre, v kateri so podvojeni vsi pomembni organi), vozlišča, grozdi in sam projekt pa so tuchanka (planet, kjer živijo krogani).

Zdaj je vodstvo dovolilo odprite projekt odprtokodni skupnosti pod licenco MIT. README bo kmalu preveden v angleščino (ker se pričakuje, da bodo glavni porabniki Pacemaker in PostgreSQL razvijalci), zato sem se odločil, da staro rusko različico README (delno) predstavim v obliki tega članka.

Grozdi so razporejeni na virtualnih strojih VirtualBox. Razmeščenih bo skupno 12 virtualnih strojev (skupaj 36GiB), ki tvorijo 4 grozde, odporne na napake (različne možnosti). Prvi dve gruči sta sestavljeni iz dveh strežnikov PostgreSQL, ki se nahajata v različnih podatkovnih centrih, in skupnega strežnika priča c naprava kvoruma (gostuje na poceni virtualnem stroju v tretjem podatkovnem centru), kar rešuje negotovost 50% / 50%, da svoj glas oddate eni od strank. Tretji grozd v treh podatkovnih centrih: en glavni, dva podrejena, št naprava kvoruma. Četrto gručo sestavljajo štirje strežniki PostgreSQL, dva na podatkovno središče: en glavni, ostale replike, uporablja pa tudi priča c naprava kvoruma. Četrti lahko prenese izpad dveh strežnikov ali enega podatkovnega centra. To rešitev je mogoče povečati na večje število replik, če je potrebno.

Storitev točnega časa ntpd prav tako preoblikovan za toleranco napak, vendar uporablja samo metodo ntpd (način sirote). Strežnik v skupni rabi priča deluje kot osrednji NTP strežnik, ki svoj čas porazdeli v vse grozde in s tem sinhronizira vse strežnike med seboj. če priča odpove ali postane izoliran, bo eden od strežnikov gruče (znotraj gruče) začel razporejati svoj čas. Pomožno predpomnjenje HTTP proxy tudi dvignili na priča, z njegovo pomočjo imajo drugi virtualni stroji dostop do skladišč Yum. V resnici bodo storitve, kot sta točen čas in posredniki, najverjetneje gostovale na namenskih strežnikih, v kabini pa gostujejo na priča samo zato, da prihranite število virtualnih strojev in prostora.

Različice

v0. Deluje s CentOS 7 in PostgreSQL 11 na VirtualBox 6.1.

Struktura grozda

Vse gruče so zasnovane tako, da se nahajajo v več podatkovnih centrih, združenih v eno ravno omrežje in morajo vzdržati napake ali omrežno izolacijo enega samega podatkovnega centra. Zato nemogoče uporabite za zaščito pred razcepljeni možgani standardna tehnologija srčnega spodbujevalnika imenovana STONITH (Shoot The Other Node In The Head) oz ograje. Njegovo bistvo: če vozlišča v gruči začnejo sumiti, da je z nekim vozliščem nekaj narobe, se ne odziva ali se obnaša nepravilno, potem ga prisilno izklopijo prek "zunanjih" naprav, na primer nadzorne kartice IPMI ali UPS. . A to bo delovalo le v primerih, ko v primeru enkratne okvare strežnik IPMI ali UPS še naprej deluje. Tukaj načrtujemo zaščito pred veliko bolj katastrofalno okvaro, ko celoten podatkovni center odpove (na primer izgubi napajanje). In s takšno zavrnitvijo vse kamniti-naprave (IPMI, UPS itd.) tudi ne bodo delovale.

Namesto tega sistem temelji na ideji sklepčnosti. Vsa vozlišča imajo glas in delujejo lahko samo tista, ki vidijo več kot polovico vseh vozlišč. Ta količina "pol + 1" se imenuje sklepčnost. Če kvorum ni dosežen, se vozlišče odloči, da je v omrežni izolaciji in mora izklopiti svoje vire, tj. to je to zaščita pred razcepljenimi možgani. Če programska oprema, ki je odgovorna za to vedenje, ne deluje, bo moral delovati nadzorni pes, na primer na podlagi IPMI.

Če je število vozlišč sodo (gruča v dveh podatkovnih centrih), lahko pride do t. i. negotovosti. 50% / 50% (petdeset-petdeset), ko izolacija omrežja razdeli gručo točno na pol. Zato za sodo število vozlišč dodajamo naprava kvoruma je nezahteven demon, ki ga je mogoče zagnati na najcenejšem virtualnem stroju v tretjem podatkovnem centru. Svoj glas da enemu izmed segmentov (ki ga vidi) in s tem odpravi negotovost 50%/50%. Poimenoval sem strežnik, na katerem bo zagnana naprava kvoruma priča (terminologija iz repmgr, mi je bila všeč).

Vire je mogoče premikati iz kraja v kraj, na primer z okvarjenih strežnikov na zdrave ali na ukaz sistemskih skrbnikov. Da stranke vedo, kje se nahajajo viri, ki jih potrebujejo (kje se povezati?), plavajoči IP (plavajoči IP). To so IP-ji, ki jih lahko Pacemaker premika po vozliščih (vse je v ravnem omrežju). Vsak od njih simbolizira vir (storitev) in se nahaja tam, kjer se morate povezati, da pridobite dostop do te storitve (v našem primeru baze podatkov).

Tuchanka1 (vezje z zbijanjem)

Struktura

Ideja je bila, da imamo veliko majhnih baz podatkov z nizko obremenitvijo, za katere je nerentabilno vzdrževati namenski podrejeni strežnik v vročem stanju pripravljenosti za transakcije samo za branje (ni potrebe po takšni izgubi virov).

Vsak podatkovni center ima en strežnik. Vsak strežnik ima dve instanci PostgreSQL (v terminologiji PostgreSQL se imenujejo gruče, a da ne bi prišlo do zmede, jih bom imenoval instance (po analogiji z drugimi bazami podatkov), gruče Pacemaker pa bom imenoval le gruče). En primerek deluje v glavnem načinu in samo on zagotavlja storitve (do njega vodi samo plavajoči IP). Drugi primerek deluje kot podrejeni za drugi podatkovni center in bo zagotavljal storitve le, če njegov glavni odpove. Ker bo večino časa samo ena instanca od dveh (master) zagotavljala storitve (izvajala zahteve), so vsi viri strežnika optimizirani za master (pomnilnik je dodeljen predpomnilniku shared_buffers itd.), vendar tako, da je druga instanca ima tudi dovolj sredstev (čeprav za neoptimalno delovanje prek predpomnilnika datotečnega sistema) v primeru okvare enega od podatkovnih centrov. Slave ne zagotavlja storitev (ne izvaja read only requests) med normalnim delovanjem gruče, tako da ni vojne za vire z masterjem na istem stroju.

V primeru dveh vozlišč je toleranca napak možna le pri asinhronem podvajanju, saj bo pri sinhronem podvajanju okvara podrejenega vodila do zaustavitve glavnega.

Nezmožnost pričevanja

Nezmožnost pričevanja (naprava kvoruma) Upošteval bom samo gručo Tuchanka1, z vsemi ostalimi bo ista zgodba. Če pričanje ne uspe, se v strukturi gruče ne bo nič spremenilo, vse bo še naprej delovalo na enak način kot je. Toda kvorum bo postal 2 od 3, zato bo vsak naslednji izpad usoden za grozd. Še vedno bo treba nujno urediti.

Tuchanka1 zavrnitev

Okvara enega od podatkovnih centrov za Tuchanka1. V tem primeru priča odda svoj glas drugemu vozlišču v drugem podatkovnem centru. Tam se nekdanji podrejeni spremeni v glavnega, posledično oba gospodarja delata na istem strežniku in oba njuna plavajoča IP-ja kažeta nanje.

Tučanka2 (klasika)

Struktura

Klasična shema dveh vozlišč. Gospodar dela na enem, suženj na drugem. Oba lahko izvajata zahteve (podrejeni je samo za branje), zato na oba kaže plavajoči IP: krogan2 je glavni, krogan2s1 je podrejeni. Tako glavni kot podrejeni bosta imela toleranco za napake.

V primeru dveh vozlišč je toleranca napak možna le pri asinhronem podvajanju, ker bo pri sinhronem podvajanju okvara podrejenega vodila do zaustavitve glavnega.

Tuchanka2 zavrnitev

Če eden od podatkovnih centrov odpove priča glasuje za drugega. V edinem delujočem podatkovnem centru bo glavni dvignjen in oba plavajoča IP-ja bosta kazala nanj: glavni in podrejeni. Seveda mora biti instanca konfigurirana tako, da ima dovolj sredstev (omejitve povezav itd.), da hkrati sprejme vse povezave in zahteve glavnega in podrejenega plavajočega IP-ja. To pomeni, da mora imeti med normalnim delovanjem zadostno količino omejitev.

Tuchanka4 (veliko sužnjev)

Struktura

Že druga skrajnost. Obstajajo zbirke podatkov, ki prejmejo veliko zahtev samo za branje (tipični primer zelo obremenjenega mesta). Tuchanka4 je situacija, ko so morda trije ali več sužnjev za obravnavanje takšnih zahtev, vendar še vedno ne preveč. Pri zelo velikem številu sužnjev bo treba izumiti hierarhični replikacijski sistem. V minimalnem primeru (na sliki) ima vsak od obeh podatkovnih centrov dva strežnika, vsak s primerkom PostgreSQL.

Druga značilnost te sheme je, da je že mogoče organizirati eno sinhrono replikacijo. Konfiguriran je tako, da se, če je mogoče, podvaja v drug podatkovni center, namesto v repliko v istem podatkovnem centru kot glavni. Na glavnega in vsakega podrejenega naslova kaže plavajoči IP. Na srečo bo treba med sužnji nekako uravnotežiti zahteve sql proxy, na primer na strani odjemalca. Različne vrste strank lahko zahtevajo različne vrste sql proxy, in samo razvijalci strank vedo, kdo kaj potrebuje. To funkcionalnost lahko implementira zunanji demon ali odjemalska knjižnica (področje povezav) itd. Vse to presega temo gruče baze podatkov za samodejni preklop (failover SQL proxy mogoče implementirati neodvisno, skupaj s toleranco napak odjemalca).

Tuchanka4 zavrnitev

Če en podatkovni center (tj. dva strežnika) odpove, priča glasuje za drugega. Posledično se v drugem podatkovnem centru izvajata dva strežnika: eden izvaja glavnega, glavni plavajoči IP pa kaže nanj (za sprejemanje zahtev za branje in pisanje); in na drugem strežniku se izvaja podrejeni strežnik s sinhrono replikacijo in eden od podrejenih plavajočih IP-jev kaže nanj (za zahteve samo za branje).

Prva stvar, ki jo je treba opozoriti, je, da vsi podrejeni plavajoči IP-ji ne bodo delavci, ampak samo eden. In za pravilno delo z njim bo to potrebno sql proxy preusmeril vse zahteve na edini preostali plavajoči IP; in če sql proxy ne, potem lahko v URL-ju povezave navedete vse podrejene IP-je, ločene z vejicami. V tem primeru s libpq povezava bo na prvi delujoči IP, to se izvede v sistemu za samodejno testiranje. Morda v drugih knjižnicah, na primer JDBC, to ne bo delovalo in je potrebno sql proxy. To je storjeno, ker je prepovedano istočasno vzpostavljanje plavajočih IP-jev za podrejene na enem strežniku, tako da so enakomerno porazdeljeni med podrejene strežnike, če jih teče več.

Drugič: tudi v primeru okvare podatkovnega centra se bo ohranila sinhrona replikacija. In tudi če pride do sekundarne okvare, to je, da eden od dveh strežnikov v preostalem podatkovnem centru odpove, bo gruča, čeprav bo prenehala zagotavljati storitve, še vedno obdržala informacije o vseh izvršenih transakcijah, za katere je dala potrditev potrditve. (v primeru sekundarne okvare ne bo informacij o izgubi).

Tuchanka3 (3 podatkovni centri)

Struktura

To je gruča za situacijo, ko obstajajo trije popolnoma delujoči podatkovni centri, od katerih ima vsak popolnoma delujoč strežnik baze podatkov. V tem primeru naprava kvoruma ni potrebno. En podatkovni center ima osebje master, druga dva pa podrejena. Replikacija je sinhrona, tip ANY (suženj1, suženj2), kar pomeni, da bo odjemalec prejel potrdilo o potrditvi, ko kateri koli od suženj prvi odgovori, da je sprejel potrditev. Viri so označeni z enim plavajočim IP-jem za nadrejenega in z dvema za podrejene. Za razliko od Tuchanka4 so vsi trije plavajoči IP-ji odporni na napake. Za uravnoteženje poizvedb SQL samo za branje, ki jih lahko uporabite sql proxy (z ločeno toleranco napak) ali dodelite en podrejeni plavajoči IP polovici odjemalcev, drugo polovico pa drugemu.

Tuchanka3 zavrnitev

Če eden od podatkovnih centrov odpove, ostaneta dva. V enem se dvigneta glavni in plavajoči IP iz nadrejenega, v drugem pa podrejeni in oba podrejena plavajoča IP (instanca mora imeti dvojno rezervo virov, da lahko sprejme vse povezave obeh podrejenih plavajočih IP-jev). Sinhrono podvajanje med glavnimi in podrejenimi. Prav tako bo gruča shranjevala podatke o izvedenih in potrjenih transakcijah (izgub informacij ne bo) v primeru uničenja dveh podatkovnih centrov (če ne bosta uničena hkrati).

Odločil sem se, da ne bom vključil podrobnega opisa datotečne strukture in uvajanja. Kdor se želi poigrati, si lahko vse prebere v README. Ponujam le opis avtomatiziranega testiranja.

Avtomatski sistem testiranja

Za testiranje tolerance na napake grozdov s simulacijo različnih napak je bil ustvarjen sistem za samodejno testiranje. Zagnano s skriptom test/failure. Skript lahko kot parametre vzame število gruč, ki jih želite preizkusiti. Na primer ta ukaz:

test/failure 2 3

bo preizkusil samo drugo in tretjo gručo. Če parametri niso določeni, bodo testirani vsi grozdi. Vse gruče so testirane vzporedno, rezultat pa je prikazan na plošči tmux. Tmux uporablja namenski strežnik tmux, tako da je skript mogoče zagnati iz privzetega tmuxa, kar povzroči ugnezdeni tmux. Priporočam uporabo terminala v velikem oknu in z majhno pisavo. Pred začetkom testiranja se vsi virtualni stroji vrnejo nazaj na posnetek v času, ko se skript zaključi setup.

Terminal je razdeljen na stolpce glede na število preskušanih grozdov, privzeto (na posnetku zaslona) so štirje. Vsebino stolpcev bom opisal na primeru Tuchanka2. Plošče na posnetku zaslona so oštevilčene:

1. Tukaj je prikazana statistika testa. Stolpci:
   • napaka — ime testa (funkcija v skriptu), ki posnema napako.
   • reakcija — aritmetično povprečje časa v sekundah, v katerem je gruča obnovila svojo funkcionalnost. Meri se od začetka skripta, ki posnema napako, do trenutka, ko gruča obnovi svojo funkcionalnost in lahko nadaljuje z zagotavljanjem storitev. Če je čas zelo kratek, na primer šest sekund (to se zgodi v gručah z več podrejenimi napravami (Tuchanka3 in Tuchanka4)), to pomeni, da je bila napaka na asinhroni podrejeni enoti in ni vplivala na delovanje; ni bilo stikala stanja gruče.
   • odstopanje — prikazuje razpon (natančnost) vrednosti reakcija z uporabo metode standardnega odklona.
   • štetje — kolikokrat je bil ta preskus opravljen.
2. Kratek dnevnik vam omogoča, da ocenite, kaj grozd trenutno počne. Prikažejo se številka ponovitve (testa), časovni žig in ime operacije. Predolgo delovanje (> 5 minut) kaže na težavo.
3. srce (srce) - trenutni čas. Za vizualno oceno delovanja mojstri Trenutni čas se stalno piše v njegovo tabelo z uporabo glavnega IP-ja s plavajočim elementom. Če je uspešen, se rezultat prikaže na tej plošči.
4. premagati (pulz) - "trenutni čas", ki je bil predhodno zabeležen s skriptom srce obvladati, zdaj preberite iz suženj prek svojega plavajočega IP-ja. Omogoča vizualno oceno delovanja podrejenega in podvajanja. V Tuchanki1 ni podrejenih s plavajočim IP-jem (ni podrejenih, ki zagotavljajo storitve), obstajata pa dva primerka (DB), zato tukaj ne bo prikazan premagatiIn srce druga stopnja.
5. Spremljanje stanja gruče z uporabo pripomočka pcs mon. Prikazuje strukturo, porazdelitev virov po vozliščih in druge uporabne informacije.
6. Tukaj je prikazano spremljanje sistema iz vsakega virtualnega stroja v gruči. Takih plošč je lahko več, odvisno od tega, koliko virtualnih strojev ima gruča. Dva grafa Obremenitev procesorja (virtualni stroji imajo dva procesorja), ime virtualnega stroja, Nalaganje sistema (imenovano povprečna obremenitev, ker je povprečje 5, 10 in 15 minut), podatki o procesu in dodelitev pomnilnika.
7. Sled skripta, ki izvaja testiranje. V primeru okvare - nenadne prekinitve delovanja ali neskončnega čakalnega cikla - tukaj lahko vidite razlog za takšno vedenje.

Testiranje poteka v dveh fazah. Najprej gre skript skozi vse vrste testov, pri čemer naključno izbere virtualni stroj, na katerem naj uporabi ta test. Nato se izvede neskončen cikel testiranja, vsakič naključno izbrani virtualni stroji in napaka. Nenadna prekinitev testnega skripta (spodnja plošča) ali neskončna zanka čakanja na nekaj (> 5 minutni čas izvajanja za eno operacijo, to je razvidno iz sledenja) pomeni, da so bili nekateri testi v tej gruči neuspešni.

Vsak test je sestavljen iz naslednjih operacij:

1. Zaženite funkcijo, ki posnema napako.
2. Pripravljeni? — čakanje na obnovitev gruče (ko so zagotovljene vse storitve).
3. Prikazuje časovno omejitev obnovitve gruče (reakcija).
4. fiksna — grozd se »popravlja«. Po tem se mora vrniti v popolnoma operativno stanje in biti pripravljen na naslednjo okvaro.

Tukaj je seznam testov z opisom, kaj počnejo:

• ForkBomb: Ustvari "Out of memory" z uporabo bombe z vilicami.
• OutOfSpace: trdi disk je poln. Toda preizkus je precej simboličen; z nepomembno obremenitvijo, ki nastane med testiranjem, PostgreSQL običajno ne odpove, ko je trdi disk poln.
• Postgres-KILL: ubije PostgreSQL z ukazom killall -KILL postgres.
• Postgres-STOP: prekine ukaz PostgreSQL killall -STOP postgres.
• Ugasniti: »odklopi« virtualni stroj z ukazom VBoxManage controlvm "виртуалка" poweroff.
• Ponastavi: preobremeni virtualni stroj z ukazom VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: prekine SBD demona z ukazom killall -STOP sbd.
• Ugasniti: pošlje ukaz virtualnemu stroju prek SSH systemctl poweroff, se sistem elegantno izklopi.
• Prekini povezavo: izolacija omrežja, ukaz VBoxManage controlvm "виртуалка" setlinkstate1 off.

Dokončanje testiranja z uporabo standardnega tmux ukaza "kill-window" Ctrl-b &, ali ukaz "detach-client". Ctrl-b d: na tej točki se testiranje konča, tmux se zapre, virtualni stroji so izklopljeni.

Težave, ugotovljene med testiranjem

• V tem trenutku čuvaj demon sbd deluje na zaustavitev opazovanih demonov, vendar jih ne zamrzne. In posledično napake, ki vodijo samo do zmrzovanja Corosync и Srčni spodbujevalnik, vendar ne visi sbd. Za preverjanje Corosync že imate PR#83 (na GitHubu na sbd), sprejet v nit mojster. Obljubili so (v PR#83), da bo nekaj podobnega za Pacemaker, upam, da do Rdeči klobuk 8 bo naredil. Toda takšne "napake" so špekulativne in jih je mogoče enostavno umetno simulirati z uporabo npr. killall -STOP corosync, vendar se nikoli ne srečata v resničnem življenju.

• У Srčni spodbujevalnik v različici za 7 CentOS nepravilno nastavljeno sync_timeout у naprava kvoruma, kot rezultat če je eno vozlišče odpovedalo, se je z nekaj verjetnosti ponovno zagnalo tudi drugo vozlišče, kamor naj bi se gospodar preselil. Ozdravljena s povečanjem sync_timeout у naprava kvoruma med uvajanjem (v skriptu setup/setup1). Tega amandmaja razvijalci niso sprejeli Srčni spodbujevalnik, namesto tega so obljubili, da bodo preoblikovali infrastrukturo na tak način (v neki nedoločeni prihodnosti), da bo ta časovna omejitev samodejno izračunana.

• Če konfiguracija baze podatkov to določa LC_MESSAGES (besedilna sporočila) Uporabite lahko Unicode, npr. ru_RU.UTF-8, nato ob zagonu postgres v okolju, kjer lokalna nastavitev ni UTF-8, recimo v praznem okolju (tukaj spodbujevalnik+pgsqlms(paf) teče postgres) torej dnevnik bo vseboval vprašaje namesto črk UTF-8. Razvijalci PostgreSQL se niso strinjali, kaj storiti v tem primeru. Stane, morate namestiti LC_MESSAGES=en_US.UTF-8 pri konfiguriranju (ustvarjanju) primerka baze podatkov.

• Če je wal_receiver_timeout nastavljen (privzeto je 60 s), potem med preizkusom PostgreSQL-STOP na glavnem v gruči tuchanka3 in tuchanka4 replikacija se ne poveže znova z novim glavnim. Tam je replikacija sinhrona, tako da se ne ustavi samo podrejeni, ampak tudi novi glavni. Deluje tako, da pri konfiguraciji PostgreSQL nastavi wal_receiver_timeout=0.

• Občasno sem opazil zamrznitev replikacije v PostgreSQL v testu ForkBomb (prelivanje pomnilnika). Po ForkBomb se včasih podrejeni ne morejo znova povezati z novim glavnim. To sem srečal samo v gruči tuchanka3 in tuchanka4, kjer je master zamrznil zaradi sinhronega podvajanja. Težava je po dolgem času (približno dve uri) izginila sama od sebe. Da bi to popravili, je potrebnih več raziskav. Simptomi so podobni prejšnji napaki, ki jo povzroča drugačen vzrok, vendar z enakimi posledicami.

Slika Krogan posneta iz deviantno Art z dovoljenjem avtorja:

Vir: www.habr.com