Sissejuhatus

Mõni aeg tagasi seisis mulle ülesanne luua talitlushäirete taluv klaster, PostgreSQL, mis töötab mitmes andmekeskuses, ühendatud kiudoptilise kaabli kaudu ühe linna piires, ja mis suudaks taluda talitlushäiret (näiteks elektrikatkestust) ühes andmekeskuses. Tarkvara, mis vastutab talitlushäirete taluvuse eest, on valitud Pacemaker, kuna see on ametlik lahendus RedHat'ilt talitlushäirete taluvate klastrite loomiseks. Selle eelisteks on, et RedHat pakub sellele tuge ja et see lahendus on universaalne (modulaarne). Selle abil saab tagada talitlushäirete taluvuse mitte ainult PostgreSQL-le, vaid ka muudele teenustele, kasutades kas standardmooduleid või luues neid vastavalt konkreetsetele vajadustele.

Selle lahenduse kohta tekkis õigustatud küsimus: kui talitlushäirete taluv on tegelikult talitlushäirete taluv klaster? Selle uurimiseks olen loonud testimisstandardi, mis simuleerib erinevaid talitlushäireid klastrite sõlmedes, ootab taastumist, taastab talitlushäirenenud sõlme ja jätkab testimist tsüklis. Alguses kandis see projekt nime hapgsql, kuid aja jooksul hakkas meeldima nimi, kus on ainult üks täishäälik. Seetõttu hakkan talitlushäirete taluvate andmebaaside (ja nendele viitava float IP) nimetama krogan (videomängu tegelane, kellel on kõik olulised organid dubleeritud), ja sõlmed, klastrid ja kogu projekt – tuchanka (planeet, kus kroganid elavad).

Praegu on juhtkond lubanud ava projekt avatud lähtekoodiga kogukonnale MIT litsentsi alusel.README tõlgitakse peagi inglise keelde (sest oodatakse, et peamised kasutajad on Pacemakeri ja PostgreSQL'i arendajad), ja vana vene versioon README-st otsustasin kujundada (osaliselt) selle artikli kujul.

Klastrid seadistatakse virtuaalmasinates VirtualBox. Kokku seadistatakse 12 virtuaalmasinat (kokku 36GiB), mis moodustavad 4 talitlushäirete taluvat klastrit (erinevad variandid). Esimesed kaks klastrit koosnevad kahest PostgreSQL serverist, mis asuvad erinevates andmekeskustes, ja ühine server witness c quorum device (mis asub odavas virtuaalmasinas kolmandas andmekeskuses), mis lahendab määramatuse 50%/50%, andes oma hääle ühe poole kasuks. Kolmas klaster asub kolmes andmekeskuses: üks peamine, kaks alamkäsku, ilma quorum device. Neljas kluster koosneb neljast PostgreSQL serverist, kaks igas andmekeskuses: üks peamine, teised koopiad, ja kasutab samuti witness c quorum device. Neljas talub kahe serveri või ühe andmekeskuse tõrget. Seda lahendust saab vajadusel laiendada suurema arvu koopiaid.

Aja täpsuse teenus ntpd on samuti konfigureeritud töökindluse tagamiseks, aga seal kasutatakse ntpd (orphan mode). Ühine server witness töötab kesksena NTP-serverina, jagades oma aega kõikidele klustereile, nii et kõik serverid on omavahel sünkroniseeritud. Kui witness üks neist puruneb või isoleeritakse, hakkab klusterist üks serveritest oma aega jagama (kliendi sees). Täiendav vahemäletav HTTP proxy on samuti seadistatud witness, mille kaudu saavad teised virtuaalmasinad juurdepääsu Yum-repositoritele. Tegelikult on sellised teenused nagu aja täpsus ja proksi kindlasti paigutatud eraldi serveritele, samas kui katsekeskkonnas on need paigutatud witness ainult virtualiseerimise ja ruumi säästmiseks.

Versioonid

v0. Töötab CentOS 7 ja PostgreSQL 11 peal VirtualBox 6.1.

Klustrite struktuur

Kõik klustid on mõeldud paigutamiseks mitmes andmekeskuses, ühendatud ühte lamedasse võrku ja peavad taluma ühe andmekeskuse tõrget või võrgu eraldamist. Seetõttu teostada kasutatakse kaitseks split-brain standardeid Pacemakeri tehnoloogia, mida nimetatakse STONITH (Shoot The Other Node In The Head) või fencing. Selle põhiolemus: kui klusteri sõlmed hakkavad kahtlema, et mõne sõlmega on midagi valesti, näiteks ei vasta või käitub ebaõigesti, siis nad sunnivad selle välja lülitama läbi 'välistest' seadmetest, nagu IPMI juhtimiskaart või UPS. Kuid see töötab ainult siis, kui ühel serveri tõrkel IPMI või UPS jätkub töötamine. Siin on aga planeeritud kaitse märksa katastroofilisema tõrke eest, kui kogu andmekeskus ebaõnnestub (näiteks kaotab toite). Sellises tõrkes ei tööta kõiked stonith-seadmed (IPMI, UPS jne) samuti.

Selle asemel põhineb süsteemi põhimõte kvoorumil. Kõigil sõlmedel on hääl ja töötada saavad ainult need, kes näevad rohkem kui pooli kõigist sõlmedest. Seda 'pool+1' nimetatakse kvoraum. Kui kvoorumit ei saavutata, otsustab sõlm, et ta on võrgu isolatsioonis ja peab oma ressursid välja lülitama, st see on selline split-brain kaitse. Kui tarkvara, mis vastutab sellise käitumise eest, ei tööta, siis peab tööle minema watchdog, näiteks IPMI alapõhine.

Kui sõlmede arv on paarisarv (klaster kahes andmekeskuses), siis võib tekkida nn määramatuse olukord 50%/50% (viiskümmend viiskümmend), kui võrgu isoleerimine jagab klastrit täpselt pooleks. Seetõttu paarisarvude puhul lisandub quorum device — mitteressursside intensiivne demon, mida saab käivitada kõige odavamas virtuaalmasinas kolmandas andmekeskuses. Ta annab oma hääle ühelt segmendilt (keda ta näeb) ja sellega lahendab 50%/50% määramatuse. Server, kus quorum device tööle hakkab, nimetan ma witness (terminoloogia repmgr-ist, mulle meeldis see).

Ressursid võivad liikuda ühest kohast teise, näiteks rikkest põhjustatud serveritest korralike serverite juurde, või süsteemiadministraatorite käsul. Et kliendid teaksid, kus asuvad vajalikke ressursse (kuhu minna?), kasutatakse ujuvad IP-d (float IP). Need on IP-d, mida Pacemaker saab liikuda sõlmede vahel (kõik asub tasases võrgus). Igaühed sümboliseerivad ressursi (teenust) ja asuvad seal, kuhu tuleb ühenduda, et pääseda sellele teenusele (meie juhul andmebaasile).

Tuchanka1 (tiheduse skeem)

Struktuur

Idee oli see, et meil on palju väikese koormuse andmebaase, mille jaoks pole mõistlik hoida spetsiaalset slave-serverit hot standby režiimis lugemiseks (selliste ressursside raiskamine pole vajalik).

Iga andmevariandis on üks server. Igasse serverisse on paigaldatud kaks PostgreSQL instantsi (PostgreSQL'i terminoloogias nimetatakse neid klusteriteks, kuid segaduse vältimiseks nimetan ma neid instantsideks (sarnaselt teiste andmebaasidega), ja klusteriteks ainult Pacemaker'i klastri). Üks instants töötab meistrina ning ainult tema pakub teenuseid (ainult temale osutatakse float IP). Teine instants töötab orjana teises andmevariandis ja hakkab teenuseid pakkuma ainult juhul, kui tema meister peaks rikki minema. Kuna suurema osa ajast osutab teenuseid (täidab päringud) ainult üks kahest instantsist (meister), optimeeritakse serveri ressursid meistri jaoks (mälu eraldamine shared_buffers’ile jne), kuid nii, et teisest instantsist jätkuks piisavalt ressurssi (kuigi mitte optimaalseks töötamiseks failisüsteemi kaudu) ühe allika rikke korral. Orjad ei osuta teenuseid (ei täida read only päringuid), kui klastri normaalne töö toimub, et vältida ressursisõda meistriga samal masinal.

Kaks sõlme tekitavad tõrget ainult asünkroonse replikatsiooni korral, kuna sünkroonse korral viib orja rike meistri seiskumiseni.

Witness'i rike

Witness'i rike (quorum device) käsitlen ma ainult klastri Tuchanka1 puhul, teistega on lugu sama. Witness'i rikke korral klastri struktuuris midagi ei muutu, kõik töötab edasi nii nagu varem. Kuid kvoorum suureneb 2-lt 3-le ja seetõttu muutuda mis tahes järgmine rike fataalseks klastri jaoks. Tõenäoliselt tuleb kiiresti parandada.

Tuchanka1 rike

Ühe andmevariandi rike Tuchanka1 jaoks. Sellisel juhul witness annab oma hääle teisele sõlmele teises andmevariandis. Seal muutub endine orja meisteriks, mistõttu töötavad mõlemad meistrid samas serveris ja neid suunatakse mõlemale nende float IP-le.

Tuchanka2 (klassikaline)

Struktuur

Klassikaline skeem kahe sõlmega. Ühel töötab meister, teisel orjand. Mõlemad saavad täita päringuid (orjand ainult read only), seega suunatakse mõlemale float IP: krogan2 — meistrile, krogan2s1 — orjale. Tõrgetaluvus on nii meistril kui orjal.

Kaks sõlme tekitavad tõrget ainult asünkroonse replikatsiooni korral, sest sünkroonse korral viib orja rike meistri seiskumiseni.

Tuchanka2 rike

Ühe andmevariandi rike witness hääletab teise poolt. Ainult ühes töötavas andmekeskuses tõstetakse master ja sellele osutavad mõlemad float IP: master ja slave. Muidugi peab instants olema seadistatud nii, et tal on piisavalt ressursse (ühenduse piirid jne) samaaegselt võtma kõik ühendused ja päringud nii masterilt kui slaveilt float IP-lt. See tähendab, et normaalses töökorralduses peab tal olema piisav varu piirides.

Tuchanka4 (palju slave'e)

Struktuur

Juba teine äärmus. On Andmebaase, kuhu tuleb väga palju read-only päringuid (typical case for high-load website). Tuchanka4 on olukord, kus slave'e võib olla kolm või enam, et selliseid päringuid töödelda, kuid siiski mitte liiga palju. Kui slave'e on väga palju, tuleb välja mõelda hierarhiiline replikatsioonisüsteem. Minimaalsetel juhtudel (pildil) asub igas kahes andmekeskuses kaks serverit, millel igas on üks PostgreSQL instants.

Veel üheks selle skeemi omaduseks on see, et siin on võimalik korraldada üks sünkroonse replikatsiooni. See on seadistatud nii, et replikatsioon toimuks, kui võimalik, teise andmekeskuse poole, mitte replikale samas andmekeskuses, kus on master. Masterile ja igale slave'ile osutab float IP. Hästi, slave'ide vahel on vajalik päringute tasakaalustamine mingisuguse sql proxy, näiteks kliendi poolel. Erinevat tüüpi klientidele võib olla vajalik erinev tüüp sql proxy, ja ainult kliendi arendajad teavad, kellele milline on vajalik. See funktsionaalsus võib olla rakendatud nii välist daemonina kui ka kliendi teegina (connection pool) jne. Kõik see ulatub väljapoole teemat andmebaasi hooldekeskust (hooldus SQL proxy saab rakendada sõltumatult, koos kliendi hooldusega).

Tuchanka4 rike

Ühe andmekeskuse (st kahe serveri) rikke korral hääletab witness teise poolt. Tulemuseks on see, et teises andmekeskuses toimivad kaks serverit: ühel töötab master ja sellele osutab master float IP (read-write päringute vastuvõtmiseks); teisel serveril töötab slave sünkroonse replikatsiooniga ja sellele osutab üks slave float IP (read only päringute jaoks).

Esimene asi, mida tuleb märkida: töötavad slave float IP ei ole kõik, vaid ainult üks. Ja selle õige töö tagamiseks on vajalik, et sql proxy suunähkuna kõik taotlused ainus alles jäänud float IP; ja kui sql proxy ei, siis saab loetleda kõik float IP orjad komadega URL-is ühendamiseks. Sel juhul libpq ühendus on esimese töökorras oleva IP-ga, nii on see automaatse testimise süsteemis seadistatud. Võib-olla muudes teekides, näiteks JDBC-s, ei pruugi see toimida ja on vajalik sql proxy. See on nii seadistatud, kuna float IP orjadele on seadistatud keeld üheaegselt ühes serveris tõusta, et nad saaksid võrdselt jaotuda orjade serverite vahel, kui neid töötab mitu.

Teine: isegi andmekeskuse rikke korral säilib sünkroonne replikatsioon. Ja isegi kui toimub teine rike, see tähendab, et jäänud andmekeskuses rikki läheb üks kahest serverist, kaob klaster ehk ei paku teenuseid, kuid siiski säilitab teavet kõigi kinnitatud tehingute kohta, mille kohta ta andis kinnituse (teabe kaotust teise rikke korral ei toimu).

Tuchanka3 (3 andmekeskust)

Struktuur

See on klaster olukorraks, kus on kolm täielikult toimivat andmekeskust, igas neist on täielikult töötav andmebaasi server. Sellisel juhul quorum device pole vajalik. Ühes andmekeskuses töötab master, kahes teises - orjad. Replikatsioon on sünkroonne, tüüpi ANY (slave1, slave2), see tähendab, et kliendile saadetakse kinnitamine, kui üks orjadest esmalt vastab, et ta on kinnituse vastu võtnud. Ressursside jaoks on määratud üks float IP jaoks master ja kaks orjade jaoks. Erinevalt Tuchanka4-st on kõik kolm float IP talitlushäirekindlad. Read-only SQL-päringute tasakaalustamiseks võib kasutada sql proxy (eraldi talitlushäirekindlusega) või jagada poolele klientidest üks orja float IP ja teisele poolele teine.

Tuchanka3 talitlushäire

Ühe andmekeskuse talitlushäire korral jääb kaks. Ühes on master ja masteri float IP, teises - orja ja mõlemad orjade float IP (instansil peab olema kahekordne ressursside varu, et vastu võtta kõik ühendused mõlemalt orja float IP-lt). Masterite ja orja vahel on sünkroonne replikatsioon. Klaster säilitab samuti teavet kinnitatud ja kinnitatud tehingute kohta (teabe kaotust ei toimu) kahe andmekeskuse hävitamise korral (kui need ei hävinud samaaegselt).

Maailma struktuuri ja juurutamise põhjalikku kirjeldust ma siia ei pane. Kes soovib katsetada, võib selle kõik lugeda README-st. Toetan ainult automaatse testimise kirjelduse.

Automaatse testimise süsteem

Klusterite tõrkevastupidavuse testimiseks, simuleerides erinevaid tõrkeid, on loodud automaatse testimise süsteem. See käivitatakse skripti kaudu test/failure. Skript võib võtta parameetritena klusterite numbrid, mida soovitakse testida. Näiteks see käsk:

test/failure 2 3

testib ainult teist ja kolmandat klusterit. Kui parameetreid ei ole, siis testitakse kõiki klustreid. Kõiki klustreid testitakse paralleelselt ja tulemus kuvatakse tmux-i paneelis. Tmux kasutab eraldi tmux-serverit, seega saab skripti käivitada default tmux-ist, tekib sissekõrvalne tmux. Soovitan kasutada terminali suure aknaga ja väikese fondiga. Testimise alguses taastatakse kõik virtuaalmasinad skripti lõpulejõudmise hetke snapshotile. setup.

Terminal on jagatud veergudeks testitavate klusterite arvu järgi, vaikimisi (kuid fotol) on neid neli. Veergude sisu selgitab Tuchanka2 näitel. Paneelid fotol on nummerdatud:

1. Siin kuvatakse testide statistika. Veerud:
   • failure — testi (funktsiooni skriptis) nimetus, mis simuleerib tõrket.
   • reaction — keskmine aeg sekundites, mille jooksul kluster taastab oma töökorrasoleku. Mitu mõõdetakse skripti käivitamise algusest, mis simuleerib tõrget, kuni hetkeni, mil kluster taastab oma töökorrasoleku ja suudab jätkata teenuste osutamist. Kui aeg on väga lühike, näiteks kuus sekundit (see juhtub mitme orjaga klusterites (Tuchanka3 ja Tuchanka4)), tähendab see, et tõrge sattus asünkroonsesse orja ja ei mõjutanud töövõimet, klustereis ei toimunud olekumuutusi.
   • deviation — näitab väärtuse hajuvust (täpsust) reaction «standardhälbe» meetodit.
   • count — kui sageli on seda testi teostatud.
2. Kokkuvõtte päevik võimaldab hinnata, millega kluster praegu tegeleb. Kuvatakse iteratsiooni (testi) number, ajatemple ning operatsiooni nimetus. Liialt pikk täitmine (> 5 minutit) viitab mingile probleemile.
3. heart (süda) - praegune aeg. Töövõime hindamiseks visuaalne ülevaade meistrid tema tabelisse kirjutatakse pidevalt praegune aeg, kasutades meistri float IP-d. Edu korral kuvatakse tulemus selles paneelis.
4. beat (pulss) - "praegune aeg", mis on varem skripti poolt salvestatud heart meistrisse, nüüd loetakse orjast tema float IP kaudu. See võimaldab visuaalselt hinnata orja töövõimet ja replikatsiooni. Tuchanka1-s ei ole orje, kellel oleks float IP (ei ole orje, kes teenuseid pakuvad), kuid seal on kaks instantsi (DB), seega kuvatakse siin mitte beat, vaid heart teise instantsi.
5. Klastri oleku jälgimine utiliidi kaudu pcs mon. Näitab struktuuri, ressursside jaotust sõlmedes ja muud kasulikku teavet.
6. Siin kuvatakse süsteemi jälgimine iga klastris oleva virtuaalmasina kohta. Selliseid paneele võib olla rohkem - nii palju virtuaalmasinaid, kui klastril on. Kaks graafikut CPU Load (virtuaalmasinatel on kaks protsessorit), virtuaalmasina nimi, System Load (nimetatakse Load Average, sest see on keskmine 5, 10 ja 15 minuti jooksul), protsesside andmed ja mälu jaotumine.
7. Skripti jälgimine, mis teostab testimist. Rikkumise korral - äkilise töö katkemise või lõputu ootamise tsükli korral - saab siit näha selle käitumise põhjust.

Testimine toimub kahes etapis. Esmalt läbib skript kõik testiliigid, valides juhuslikult virtuaalmasina, millele test rakendada. Seejärel toimub lõpmatu testimistsükkel, virtuaalsed masinad ja rikkumine valitakse iga kord juhuslikult. Skripti äkiline lõpetamine (alumine paneel) või lõputu ootamise tsükkel (rohkem kui 5 minuti jooksul ühe operatsiooni täitmise aeg, see on nähtav jälgimises) näitab, et mõni test selle klastris ebaõnnestus.

Iga test koosneb järgmiste toimingute seeriast:

1. Funktsiooni käivitamine, mis simuleerib riket.
2. Valmis? - klassi töövõime taastumise ootamine (kui kõik teenused on saadaval).
3. Klastri taastumise ooteaeg kuvatakse (reaction).
4. Repair - klass "parandatakse". Pärast seda peaks see naasma täielikult töövõimelisse olekusse ja olema valmis järgmisteks riketeks.

Siin on nimekiri testidest koos kirjeldusega, mida nad teevad:

• ForkBomb: loob "Mälu ületäitmine" fork-bombiga.
• OutOfSpace: täidab ketast. Kuid test on pigem sümboolne, arvestades vähest koormust, mis testimise käigus tekib; ketta täitumisel PostgreSQL tavaliselt ei crash'ita.
• Postgres-KILL: tapab PostgreSQL käsuga killall -KILL postgres.
• Postgres-STOP: peatab PostgreSQL käsuga killall -STOP postgres.
• PowerOff: "lülitab välja" virtuaalmasina käsuga VBoxManage controlvm "virtuaalmasin" poweroff.
• Reset: taaskäivitab virtuaalmasina käsuga VBoxManage controlvm "virtuaalmasin" reset.
• SBD-STOP: peatab SBD deemonit käsuga killall -STOP sbd.
• ShutDown: saadab virtuaalmasinale käsu SSH kaudu systemctl poweroff, süsteem lõpetab korralikult töö.
• UnLink: võrgusisene isolatsioon, käsk VBoxManage controlvm "virtuaalmasin" setlinkstate1 off.

Testimise lõpetamine kas standardse käsu tmux "kill-window" kaudu Ctrl-b &, või käsuga "detach-client" Ctrl-b d: sellega test lõpetatakse, tmux suletakse, virtuaalmasinad lülitatakse välja.

Testimisel tuvastatud probleemid

• Praegusel hetkel watchdog deemon sbd töötab jälgitavate deemonite peatamisega, kuid mitte nende hangumisega. Seetõttu käituvad puudused, mis põhjustavad ainult hangumist, valesti Corosync ja Pacemaker, kuid siiski ei hangu sbd. Kontrollimiseks Corosync juba olemas PR#83 (GitHubis sbd), vastu võetud harusse master. Lubati (PR#83), et ka Pacemaker’ile tuleb midagi sarnast, loodan, et RedHat 8 tehakse. Kuid sellised "puudused" on teoreetilised, neid on hõlbus kunstlikult imiteerida näiteks killall -STOP corosync, kuid kunagi ei esine need reaalses elus.

• Uus Pacemaker versioonis CentOS 7 on vale sync_timeout on quorum device, mille tagajärjel ühe sõlme tõrke korral oli teise sõlme taaskäivitamine teatud tõenäosusega, kuhu meistrilt pidanuks minema. Probleem lahendati sync_timeout on quorum device installeerimise käigus (skriptis setup/setup1). See parandamine ei olnud arendajate poolt vastu võetud Pacemaker, selle asemel lubati nad infrastruktuuri ümber kujundada nii, et see ajaks automaatselt välja selle ajutise vahe.

• Kui andmebaasi konfigureerimisel on määratud, et LC_MESSAGES (tekstisõnumites) võib kasutada Unicode'i, näiteks ru_RU.UTF-8, siis käivitamisel postgres keskkonnas, kus locale ei ole UTF-8, näiteks tühjas keskkonnas (siin pacemaker+pgsqlms(paf) käivitab postgres), siis logis kuvatakse UTF-8 tähtede asemel küsimärgid. PostgreSQL arendajad ei jõudnud kokkuleppele, mida sel juhul teha. See on lahendatav, tuleb paigaldada LC_MESSAGES=en_US.UTF-8 andmebaasi instantsi konfigureerimisel (loomisel).

• Kui wal_receiver_timeout on seadistatud (vaikimisi 60s), siis testides PostgreSQL-STOP master'is klastrites tuchanka3 ja tuchanka4 ei toimu replikatsiooni uuesti ühendamist uue master'iga. Replikatsioon on seal sünkroonne, seega peatub mitte ainult tööline, vaid ka uus master. Seda saab vältida, seades wal_receiver_timeout=0 PostgreSQL seadistamisel.

• Harva olen täheldanud PostgreSQL replikatsiooni seiskumist testis ForkBomb (mälude üleküllus). Pärast ForkBombi ei pruugi töötajad mõnikord uuesti uue master'iga ühendada. Olen sellist olukorda kohanud ainult klastrites tuchanka3 ja tuchanka4, kus sünkroonse replikatsiooni tõttu seiskus master. Probleem lahendus ennast mõne aja pärast (umbes kahe tunni pärast). Vajalik on täiendav uurimine, et see lahendada. Sümpptomid sarnanevad varasema veaga, mis on põhjustatud muust tegurist, kuid on sama mõju.

Krogani pildiallikas on Deviant Art autori loal:

Allikas: habr.com