{"id":92570,"date":"2020-08-28T19:42:21","date_gmt":"2020-08-28T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker"},"modified":"2020-08-28T19:42:21","modified_gmt":"2020-08-28T17:42:21","slug":"modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","title":{"rendered":"PostgreSQL ja Pacemaker p\u00f5hinevate t\u00f5rkeaatust peetavate klastrite modelleerimine","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Sissejuhatus<\/h1>\n

<\/p>\n

M\u00f5ni aeg tagasi seisis mulle \u00fclesanne luua talitlush\u00e4irete taluv klaster, PostgreSQL<\/a><\/noindex>, mis t\u00f6\u00f6tab mitmes andmekeskuses, \u00fchendatud kiudoptilise kaabli kaudu \u00fche linna piires, ja mis suudaks taluda talitlush\u00e4iret (n\u00e4iteks elektrikatkestust) \u00fches andmekeskuses. Tarkvara, mis vastutab talitlush\u00e4irete taluvuse eest, on valitud Pacemaker<\/a><\/noindex>, kuna see on ametlik lahendus RedHat'ilt talitlush\u00e4irete taluvate klastrite loomiseks. Selle eelisteks on, et RedHat pakub sellele tuge ja et see lahendus on universaalne (modulaarne). Selle abil saab tagada talitlush\u00e4irete taluvuse mitte ainult PostgreSQL-le, vaid ka muudele teenustele, kasutades kas standardmooduleid v\u00f5i luues neid vastavalt konkreetsetele vajadustele.<\/p>\n

<\/p>\n

Selle lahenduse kohta tekkis \u00f5igustatud k\u00fcsimus: kui talitlush\u00e4irete taluv on tegelikult talitlush\u00e4irete taluv klaster? Selle uurimiseks olen loonud testimisstandardi, mis simuleerib erinevaid talitlush\u00e4ireid klastrite s\u00f5lmedes, ootab taastumist, taastab talitlush\u00e4irenenud s\u00f5lme ja j\u00e4tkab testimist ts\u00fcklis. Alguses kandis see projekt nime hapgsql, kuid aja jooksul hakkas meeldima nimi, kus on ainult \u00fcks t\u00e4ish\u00e4\u00e4lik. Seet\u00f5ttu hakkan talitlush\u00e4irete taluvate andmebaaside (ja nendele viitava float IP) nimetama krogan<\/strong> (videom\u00e4ngu tegelane, kellel on k\u00f5ik olulised organid dubleeritud), ja s\u00f5lmed, klastrid ja kogu projekt \u2013 tuchanka<\/strong> (planeet, kus kroganid elavad).<\/p>\n

<\/p>\n

Praegu on juhtkond lubanud ava projekt avatud l\u00e4htekoodiga kogukonnale MIT litsentsi alusel.<\/a><\/noindex>README t\u00f5lgitakse 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.<\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/a><\/noindex><\/p>\n

Klastrid seadistatakse virtuaalmasinates VirtualBox<\/a><\/noindex>. Kokku seadistatakse 12 virtuaalmasinat (kokku 36GiB), mis moodustavad 4 talitlush\u00e4irete taluvat klastrit (erinevad variandid). Esimesed kaks klastrit koosnevad kahest PostgreSQL serverist, mis asuvad erinevates andmekeskustes, ja \u00fchine server witness<\/em> c quorum device<\/strong> (mis asub odavas virtuaalmasinas kolmandas andmekeskuses), mis lahendab m\u00e4\u00e4ramatuse 50%\/50%<\/strong>, andes oma h\u00e4\u00e4le \u00fche poole kasuks. Kolmas klaster asub kolmes andmekeskuses: \u00fcks peamine, kaks alamk\u00e4sku, ilma quorum device<\/strong>. Neljas kluster koosneb neljast PostgreSQL serverist, kaks igas andmekeskuses: \u00fcks peamine, teised koopiad, ja kasutab samuti witness<\/em> c quorum device<\/strong>. Neljas talub kahe serveri v\u00f5i \u00fche andmekeskuse t\u00f5rget. Seda lahendust saab vajadusel laiendada suurema arvu koopiaid.<\/p>\n

<\/p>\n

Aja t\u00e4psuse teenus ntpd<\/a><\/noindex> on samuti konfigureeritud t\u00f6\u00f6kindluse tagamiseks, aga seal kasutatakse ntpd<\/code> (orphan mode<\/em>). \u00dchine server witness<\/em> t\u00f6\u00f6tab kesksena NTP-serverina, jagades oma aega k\u00f5ikidele klustereile, nii et k\u00f5ik serverid on omavahel s\u00fcnkroniseeritud. Kui witness<\/em> \u00fcks neist puruneb v\u00f5i isoleeritakse, hakkab klusterist \u00fcks serveritest oma aega jagama (kliendi sees). T\u00e4iendav vahem\u00e4letav HTTP proxy<\/strong> on samuti seadistatud witness<\/em>, mille kaudu saavad teised virtuaalmasinad juurdep\u00e4\u00e4su Yum-repositoritele. Tegelikult on sellised teenused nagu aja t\u00e4psus ja proksi kindlasti paigutatud eraldi serveritele, samas kui katsekeskkonnas on need paigutatud witness<\/em> ainult virtualiseerimise ja ruumi s\u00e4\u00e4stmiseks.<\/p>\n

<\/p>\n

Versioonid<\/h1>\n

<\/p>\n

v0. T\u00f6\u00f6tab CentOS 7 ja PostgreSQL 11 peal VirtualBox 6.1.<\/p>\n

<\/p>\n

Klustrite struktuur<\/h1>\n

<\/p>\n

K\u00f5ik klustid on m\u00f5eldud paigutamiseks mitmes andmekeskuses, \u00fchendatud \u00fchte lamedasse v\u00f5rku ja peavad taluma \u00fche andmekeskuse t\u00f5rget v\u00f5i v\u00f5rgu eraldamist. Seet\u00f5ttu teostada<\/strong> kasutatakse kaitseks split-brain<\/strong> standardeid Pacemakeri tehnoloogia, mida nimetatakse STONITH<\/em> (Shoot The Other Node In The Head) v\u00f5i fencing<\/em>. Selle p\u00f5hiolemus: kui klusteri s\u00f5lmed hakkavad kahtlema, et m\u00f5ne s\u00f5lmega on midagi valesti, n\u00e4iteks ei vasta v\u00f5i k\u00e4itub eba\u00f5igesti, siis nad sunnivad selle v\u00e4lja l\u00fclitama l\u00e4bi 'v\u00e4listest' seadmetest, nagu IPMI juhtimiskaart v\u00f5i UPS. Kuid see t\u00f6\u00f6tab ainult siis, kui \u00fchel serveri t\u00f5rkel IPMI v\u00f5i UPS j\u00e4tkub t\u00f6\u00f6tamine. Siin on aga planeeritud kaitse m\u00e4rksa katastroofilisema t\u00f5rke eest, kui kogu andmekeskus eba\u00f5nnestub (n\u00e4iteks kaotab toite). Sellises t\u00f5rkes ei t\u00f6\u00f6ta k\u00f5iked stonith<\/em>-seadmed (IPMI, UPS jne) samuti.<\/p>\n

<\/p>\n

Selle asemel p\u00f5hineb s\u00fcsteemi p\u00f5him\u00f5te kvoorumil. K\u00f5igil s\u00f5lmedel on h\u00e4\u00e4l ja t\u00f6\u00f6tada saavad ainult need, kes n\u00e4evad rohkem kui pooli k\u00f5igist s\u00f5lmedest. Seda 'pool+1' nimetatakse kvoraum<\/strong>. Kui kvoorumit ei saavutata, otsustab s\u00f5lm, et ta on v\u00f5rgu isolatsioonis ja peab oma ressursid v\u00e4lja l\u00fclitama, st see on selline split-brain kaitse<\/strong>. Kui tarkvara, mis vastutab sellise k\u00e4itumise eest, ei t\u00f6\u00f6ta, siis peab t\u00f6\u00f6le minema watchdog, n\u00e4iteks IPMI alap\u00f5hine.<\/p>\n

<\/p>\n

Kui s\u00f5lmede arv on paarisarv (klaster kahes andmekeskuses), siis v\u00f5ib tekkida nn m\u00e4\u00e4ramatuse olukord 50%\/50%<\/strong> (viisk\u00fcmmend viisk\u00fcmmend<\/em>), kui v\u00f5rgu isoleerimine jagab klastrit t\u00e4pselt pooleks. Seet\u00f5ttu paarisarvude puhul lisandub quorum device<\/strong> \u2014 mitteressursside intensiivne demon, mida saab k\u00e4ivitada k\u00f5ige odavamas virtuaalmasinas kolmandas andmekeskuses. Ta annab oma h\u00e4\u00e4le \u00fchelt segmendilt (keda ta n\u00e4eb) ja sellega lahendab 50%\/50% m\u00e4\u00e4ramatuse. Server, kus quorum device t\u00f6\u00f6le hakkab, nimetan ma witness<\/em> (terminoloogia repmgr-ist, mulle meeldis see).<\/p>\n

<\/p>\n

Ressursid v\u00f5ivad liikuda \u00fchest kohast teise, n\u00e4iteks rikkest p\u00f5hjustatud serveritest korralike serverite juurde, v\u00f5i s\u00fcsteemiadministraatorite k\u00e4sul. Et kliendid teaksid, kus asuvad vajalikke ressursse (kuhu minna?), kasutatakse ujuvad IP-d<\/em> (float IP<\/strong>). Need on IP-d, mida Pacemaker saab liikuda s\u00f5lmede vahel (k\u00f5ik asub tasases v\u00f5rgus). Iga\u00fched s\u00fcmboliseerivad ressursi (teenust) ja asuvad seal, kuhu tuleb \u00fchenduda, et p\u00e4\u00e4seda sellele teenusele (meie juhul andmebaasile).<\/p>\n

<\/p>\n

Tuchanka1 (tiheduse skeem)<\/h2>\n

<\/p>\n

Struktuur<\/h3>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Idee oli see, et meil on palju v\u00e4ikese koormuse andmebaase, mille jaoks pole m\u00f5istlik hoida spetsiaalset slave-serverit hot standby re\u017eiimis lugemiseks (selliste ressursside raiskamine pole vajalik).<\/p>\n

<\/p>\n

Iga andmevariandis on \u00fcks server. Igasse serverisse on paigaldatud kaks PostgreSQL instantsi (PostgreSQL'i terminoloogias nimetatakse neid klusteriteks, kuid segaduse v\u00e4ltimiseks nimetan ma neid instantsideks (sarnaselt teiste andmebaasidega), ja klusteriteks ainult Pacemaker'i klastri). \u00dcks instants t\u00f6\u00f6tab meistrina ning ainult tema pakub teenuseid (ainult temale osutatakse float IP). Teine instants t\u00f6\u00f6tab orjana teises andmevariandis ja hakkab teenuseid pakkuma ainult juhul, kui tema meister peaks rikki minema. Kuna suurema osa ajast osutab teenuseid (t\u00e4idab p\u00e4ringud) ainult \u00fcks kahest instantsist (meister), optimeeritakse serveri ressursid meistri jaoks (m\u00e4lu eraldamine shared_buffers\u2019ile jne), kuid nii, et teisest instantsist j\u00e4tkuks piisavalt ressurssi (kuigi mitte optimaalseks t\u00f6\u00f6tamiseks failis\u00fcsteemi kaudu) \u00fche allika rikke korral. Orjad ei osuta teenuseid (ei t\u00e4ida read only p\u00e4ringuid), kui klastri normaalne t\u00f6\u00f6 toimub, et v\u00e4ltida ressursis\u00f5da meistriga samal masinal.<\/p>\n

<\/p>\n

Kaks s\u00f5lme tekitavad t\u00f5rget ainult as\u00fcnkroonse replikatsiooni korral, kuna s\u00fcnkroonse korral viib orja rike meistri seiskumiseni.<\/p>\n

<\/p>\n

Witness'i rike<\/h3>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Witness'i rike (quorum device<\/em>) k\u00e4sitlen ma ainult klastri Tuchanka1 puhul, teistega on lugu sama. Witness'i rikke korral klastri struktuuris midagi ei muutu, k\u00f5ik t\u00f6\u00f6tab edasi nii nagu varem. Kuid kvoorum suureneb 2-lt 3-le ja seet\u00f5ttu muutuda mis tahes j\u00e4rgmine rike fataalseks klastri jaoks. T\u00f5en\u00e4oliselt tuleb kiiresti parandada.<\/p>\n

<\/p>\n

Tuchanka1 rike<\/h3>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

\u00dche andmevariandi rike Tuchanka1 jaoks. Sellisel juhul witness<\/em> annab oma h\u00e4\u00e4le teisele s\u00f5lmele teises andmevariandis. Seal muutub endine orja meisteriks, mist\u00f5ttu t\u00f6\u00f6tavad m\u00f5lemad meistrid samas serveris ja neid suunatakse m\u00f5lemale nende float IP-le.<\/p>\n

<\/p>\n

Tuchanka2 (klassikaline)<\/h2>\n

<\/p>\n

Struktuur<\/h3>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Klassikaline skeem kahe s\u00f5lmega. \u00dchel t\u00f6\u00f6tab meister, teisel orjand. M\u00f5lemad saavad t\u00e4ita p\u00e4ringuid (orjand ainult read only), seega suunatakse m\u00f5lemale float IP: krogan2 \u2014 meistrile, krogan2s1 \u2014 orjale. T\u00f5rgetaluvus on nii meistril kui orjal.<\/p>\n

<\/p>\n

Kaks s\u00f5lme tekitavad t\u00f5rget ainult as\u00fcnkroonse replikatsiooni korral, sest s\u00fcnkroonse korral viib orja rike meistri seiskumiseni.<\/p>\n

<\/p>\n

Tuchanka2 rike<\/h3>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

\u00dche andmevariandi rike witness<\/em> h\u00e4\u00e4letab teise poolt. Ainult \u00fches t\u00f6\u00f6tavas andmekeskuses t\u00f5stetakse master ja sellele osutavad m\u00f5lemad float IP: master ja slave. Muidugi peab instants olema seadistatud nii, et tal on piisavalt ressursse (\u00fchenduse piirid jne) samaaegselt v\u00f5tma k\u00f5ik \u00fchendused ja p\u00e4ringud nii masterilt kui slaveilt float IP-lt. See t\u00e4hendab, et normaalses t\u00f6\u00f6korralduses peab tal olema piisav varu piirides.<\/p>\n

<\/p>\n

Tuchanka4 (palju slave'e)<\/h2>\n

<\/p>\n

Struktuur<\/h3>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Juba teine \u00e4\u00e4rmus. On Andmebaase, kuhu tuleb v\u00e4ga palju read-only p\u00e4ringuid (typical case for high-load website). Tuchanka4 on olukord, kus slave'e v\u00f5ib olla kolm v\u00f5i enam, et selliseid p\u00e4ringuid t\u00f6\u00f6delda, kuid siiski mitte liiga palju. Kui slave'e on v\u00e4ga palju, tuleb v\u00e4lja m\u00f5elda hierarhiiline replikatsioonis\u00fcsteem. Minimaalsetel juhtudel (pildil) asub igas kahes andmekeskuses kaks serverit, millel igas on \u00fcks PostgreSQL instants.<\/p>\n

<\/p>\n

Veel \u00fcheks selle skeemi omaduseks on see, et siin on v\u00f5imalik korraldada \u00fcks s\u00fcnkroonse replikatsiooni. See on seadistatud nii, et replikatsioon toimuks, kui v\u00f5imalik, teise andmekeskuse poole, mitte replikale samas andmekeskuses, kus on master. Masterile ja igale slave'ile osutab float IP. H\u00e4sti, slave'ide vahel on vajalik p\u00e4ringute tasakaalustamine mingisuguse sql proxy<\/em>, n\u00e4iteks kliendi poolel. Erinevat t\u00fc\u00fcpi klientidele v\u00f5ib olla vajalik erinev t\u00fc\u00fcp sql proxy<\/em>, ja ainult kliendi arendajad teavad, kellele milline on vajalik. See funktsionaalsus v\u00f5ib olla rakendatud nii v\u00e4list daemonina kui ka kliendi teegina (connection pool) jne. K\u00f5ik see ulatub v\u00e4ljapoole teemat andmebaasi hooldekeskust (hooldus SQL proxy<\/em> saab rakendada s\u00f5ltumatult, koos kliendi hooldusega).<\/p>\n

<\/p>\n

Tuchanka4 rike<\/h3>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

\u00dche andmekeskuse (st kahe serveri) rikke korral h\u00e4\u00e4letab witness teise poolt. Tulemuseks on see, et teises andmekeskuses toimivad kaks serverit: \u00fchel t\u00f6\u00f6tab master ja sellele osutab master float IP (read-write p\u00e4ringute vastuv\u00f5tmiseks); teisel serveril t\u00f6\u00f6tab slave s\u00fcnkroonse replikatsiooniga ja sellele osutab \u00fcks slave float IP (read only p\u00e4ringute jaoks).<\/p>\n

<\/p>\n

Esimene asi, mida tuleb m\u00e4rkida: t\u00f6\u00f6tavad slave float IP ei ole k\u00f5ik, vaid ainult \u00fcks. Ja selle \u00f5ige t\u00f6\u00f6 tagamiseks on vajalik, et sql proxy<\/em> suun\u00e4hkuna k\u00f5ik taotlused ainus alles j\u00e4\u00e4nud float IP; ja kui sql proxy<\/em> ei, siis saab loetleda k\u00f5ik float IP orjad komadega URL-is \u00fchendamiseks. Sel juhul libpq<\/em> \u00fchendus on esimese t\u00f6\u00f6korras oleva IP-ga, nii on see automaatse testimise s\u00fcsteemis seadistatud. V\u00f5ib-olla muudes teekides, n\u00e4iteks JDBC-s, ei pruugi see toimida ja on vajalik sql proxy<\/em>. See on nii seadistatud, kuna float IP orjadele on seadistatud keeld \u00fcheaegselt \u00fches serveris t\u00f5usta, et nad saaksid v\u00f5rdselt jaotuda orjade serverite vahel, kui neid t\u00f6\u00f6tab mitu.<\/p>\n

<\/p>\n

Teine: isegi andmekeskuse rikke korral s\u00e4ilib s\u00fcnkroonne replikatsioon. Ja isegi kui toimub teine rike, see t\u00e4hendab, et j\u00e4\u00e4nud andmekeskuses rikki l\u00e4heb \u00fcks kahest serverist, kaob klaster ehk ei paku teenuseid, kuid siiski s\u00e4ilitab teavet k\u00f5igi kinnitatud tehingute kohta, mille kohta ta andis kinnituse (teabe kaotust teise rikke korral ei toimu).<\/p>\n

<\/p>\n

Tuchanka3 (3 andmekeskust)<\/h2>\n

<\/p>\n

Struktuur<\/h3>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

See on klaster olukorraks, kus on kolm t\u00e4ielikult toimivat andmekeskust, igas neist on t\u00e4ielikult t\u00f6\u00f6tav andmebaasi server. Sellisel juhul quorum device<\/em> pole vajalik. \u00dches andmekeskuses t\u00f6\u00f6tab master, kahes teises - orjad. Replikatsioon on s\u00fcnkroonne, t\u00fc\u00fcpi ANY (slave1, slave2), see t\u00e4hendab, et kliendile saadetakse kinnitamine, kui \u00fcks orjadest esmalt vastab, et ta on kinnituse vastu v\u00f5tnud. Ressursside jaoks on m\u00e4\u00e4ratud \u00fcks float IP jaoks master ja kaks orjade jaoks. Erinevalt Tuchanka4-st on k\u00f5ik kolm float IP talitlush\u00e4irekindlad. Read-only SQL-p\u00e4ringute tasakaalustamiseks v\u00f5ib kasutada sql proxy<\/em> (eraldi talitlush\u00e4irekindlusega) v\u00f5i jagada poolele klientidest \u00fcks orja float IP ja teisele poolele teine.<\/p>\n

<\/p>\n

Tuchanka3 talitlush\u00e4ire<\/h3>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

\u00dche andmekeskuse talitlush\u00e4ire korral j\u00e4\u00e4b kaks. \u00dches on master ja masteri float IP, teises - orja ja m\u00f5lemad orjade float IP (instansil peab olema kahekordne ressursside varu, et vastu v\u00f5tta k\u00f5ik \u00fchendused m\u00f5lemalt orja float IP-lt). Masterite ja orja vahel on s\u00fcnkroonne replikatsioon. Klaster s\u00e4ilitab samuti teavet kinnitatud ja kinnitatud tehingute kohta (teabe kaotust ei toimu) kahe andmekeskuse h\u00e4vitamise korral (kui need ei h\u00e4vinud samaaegselt).<\/p>\n

<\/p>\n

Maailma struktuuri ja juurutamise p\u00f5hjalikku kirjeldust ma siia ei pane. Kes soovib katsetada, v\u00f5ib selle k\u00f5ik lugeda README-st. Toetan ainult automaatse testimise kirjelduse.<\/em><\/p>\n

<\/p>\n

Automaatse testimise s\u00fcsteem<\/h1>\n

<\/p>\n

Klusterite t\u00f5rkevastupidavuse testimiseks, simuleerides erinevaid t\u00f5rkeid, on loodud automaatse testimise s\u00fcsteem. See k\u00e4ivitatakse skripti kaudu test\/failure<\/code>. Skript v\u00f5ib v\u00f5tta parameetritena klusterite numbrid, mida soovitakse testida. N\u00e4iteks see k\u00e4sk:<\/p>\n

<\/p>\n

test\/failure 2 3<\/code><\/pre>\n
<\/p>\n
testib ainult teist ja kolmandat klusterit. Kui parameetreid ei ole, siis testitakse k\u00f5iki klustreid. K\u00f5iki klustreid testitakse paralleelselt ja tulemus kuvatakse tmux-i paneelis. Tmux kasutab eraldi tmux-serverit, seega saab skripti k\u00e4ivitada default tmux-ist, tekib sissek\u00f5rvalne tmux. Soovitan kasutada terminali suure aknaga ja v\u00e4ikese fondiga. Testimise alguses taastatakse k\u00f5ik virtuaalmasinad skripti l\u00f5pulej\u00f5udmise hetke snapshotile. setup<\/code>.<\/p>\n
<\/p>\n
\"PostgreSQL<\/p>\n
<\/p>\n
Terminal on jagatud veergudeks testitavate klusterite arvu j\u00e4rgi, vaikimisi (kuid fotol) on neid neli. Veergude sisu selgitab Tuchanka2 n\u00e4itel. Paneelid fotol on nummerdatud:<\/p>\n
<\/p>\n
    \n
  1. Siin kuvatakse testide statistika. Veerud:\n