{"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 Pacemakeri p\u00f5hjal t\u00f6\u00f6tavate vigadeta klastrite modelleerimine","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Sissejuhatus<\/h1>\n

<\/p>\n

M\u00f5ni aeg tagasi sain \u00fclesande luua vigadeta klaster PostgreSQL<\/a><\/noindex>, mis t\u00f6\u00f6tab mitmes andmekeskuses, mis on \u00fchendatud kiudoptilise kaabliga \u00fches linnas, ja suudab taluda \u00fchte andmekeskust puudutavat riket (nt elektrikatkestus). Vigadeta funktsionaalsuse tagamiseks valisin Pacemakeri<\/a><\/noindex>, kuna see on RedHati ametlik lahendus vigadeta klastrite loomiseks. Selle eeliseks on, et RedHat tagab selle toe, ja et see on universaalne (modulaarne) lahendus. Selle abil on v\u00f5imalik tagada vigadeta mitte ainult PostgreSQL-ile, vaid ka teistele teenustele, kasutades kas standardmooduleid v\u00f5i luues neid konkreetsete vajaduste jaoks.<\/p>\n

<\/p>\n

Selle lahenduse kohta tekkis \u00f5igustatud k\u00fcsimus: kui t\u00f5rkekindel on t\u00f5rkekindel klaster? Selle uurimiseks koostasin katse seadme, mis simuleerib erinevaid t\u00f5rkeid klastrite s\u00f5lmedes, ootab taastumist, taastab t\u00f5rkena t\u00f6\u00f6tanud s\u00f5lme ja j\u00e4tkab testimist ts\u00fcklis. Esialgu nimetati seda projekti hapgsql, kuid aja jooksul hakkas mind \u00e4rritama nimi, milles on ainult \u00fcks vokaal. Seet\u00f5ttu hakkan t\u00f5rkekindlaid andmebaase (ja float IP, mis neile viitavad) nimetama krogan<\/strong> (iseloom arvutim\u00e4ngust, kellel on k\u00f5ik olulised organid duplitseeritud), ja s\u00f5lmed, klastrid ning kogu projekt \u2014 tuchanka<\/strong> (planeet, kus kroganid elavad).<\/p>\n

<\/p>\n

Praegu on juhtkond lubanud avatud projekti open source kogukonnale MIT litsentsi alla<\/a><\/noindex>. README t\u00f5lgitakse peagi inglise keelde (sest oodatakse, et p\u00f5hitarbijad oleksid Pacemakeri ja PostgreSQL arendajad), ja vana venekeelne README otsustasin osaliselt vormistada selle artikli kujul.<\/p>\n

<\/p>\n

\"PostgreSQL<\/p>\n

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

Klastrid paigutatakse virtuaalmasinatele VirtualBox<\/a><\/noindex>. Kokku luuakse 12 virtuaalset masinat (kokku 36GiB), mis moodustavad 4 talitush\u00e4iret kestvat klusterit (erinevad variandid). Esimene kaks klastrit koosnevad kahest PostgreSQL serverist, mis asuvad erinevates andmekeskustes, ja \u00fchest serverist witness<\/em> c quorum device<\/strong> (mis on paigutatud odavale virtuaalmasinale kolmandas andmekeskuses), mis lahendab ebamugavustunde 50%\/50%<\/strong>, andes oma h\u00e4\u00e4le \u00fchele osapoolele. Kolmas klaster asub kolmes andmekeskuses: \u00fcks peamine, kaks alam, ilma quorum device<\/strong>. Neljas klaster koosneb neljast PostgreSQL serverist, kaks igas andmekeskuses: \u00fcks peamine, teised replikad, ja kasutab samuti witness<\/em> c quorum device<\/strong>. Neljas talub kahe serveri v\u00f5i \u00fche andmekeskuse riket. See lahendus v\u00f5ib vajadusel ulatuda suuremale arvule replikatele.<\/p>\n

<\/p>\n

Ajavahe teenus ntpd<\/a><\/noindex> on samuti \u00fcmber seadistatud talitush\u00e4irete v\u00e4ltimiseks, kuid seal kasutatakse meetodit, mille nimi on ntpd<\/code> (orphan mode<\/em>). \u00dchine server witness<\/em> t\u00e4idab keskses NTP serveri rolli, jagades oma aega k\u00f5igile klastritele, seel\u00e4bi s\u00fcnkroniseerides k\u00f5ik serverid \u00fcksteisega. Kui witness<\/em> kui see eba\u00f5nnestub v\u00f5i isoleeritakse, hakkab klastris \u00fcks serveritest oma aega jagama. Abistav vahem\u00e4lu HTTP proxy<\/strong> on samuti \u00fcles t\u00f5stetud witness<\/em>, mille abil \u00fclej\u00e4\u00e4nud virtuaalmasinad p\u00e4\u00e4sevad juurde Yum-repositooriumidele. Tegelikult, nagu t\u00e4pne aeg ja proksid, paigutatakse need t\u00f5en\u00e4oliselt eraldi serveritesse, kuid katsetes nad asuvad witness<\/em> ainult virtuaalmasinate arvu ja ruumi kokkuhoiu eesm\u00e4rgil.<\/p>\n

<\/p>\n

Versioonid<\/h1>\n

<\/p>\n

v0. Toimib CentOS 7 ja PostgreSQL 11 peal VirtualBox 6.1-s.<\/p>\n

<\/p>\n

Klastri struktuur<\/h1>\n

<\/p>\n

K\u00f5ik klastrid on m\u00f5eldud paiknema mitmes andmekeskuses, \u00fchendatud \u00fche tasase v\u00f5rku ja peavad taluma \u00fche andmekeskuse rikke v\u00f5i v\u00f5rgu isoleerimist. Seet\u00f5ttu ei ole v\u00f5imalik<\/strong> kasutada kaitseks split-brain<\/strong> standardi tehnoloogiat Pacemaker, mis tuntakse STONITH<\/em> (Shoot The Other Node In The Head) v\u00f5i fencing<\/em>. Selle sisu seisneb selles, et kui klastris olevad s\u00f5lmed hakkavad kahtlema, et m\u00f5ne s\u00f5lmega on midagi valesti, et see ei reageeri v\u00f5i k\u00e4itub eba\u00f5igesti, siis nad sunnivad selle v\u00e4liste seadmete, n\u00e4iteks IPMI juhtimiskaardi v\u00f5i UPS-i kaudu v\u00e4lja l\u00fclitama. Kuid see t\u00f6\u00f6tab ainult siis, kui \u00fcksikserveri rikke korral IPMI v\u00f5i UPS j\u00e4tkab t\u00f6\u00f6tamist. Siin on ette n\u00e4htud kaitse palju katastroofilisema rikke eest, kui kogu andmekeskus kaotab, n\u00e4iteks voolu. Ja sellise rikke korral ei t\u00f6\u00f6ta ka stonith<\/em>-seadmed (IPMI, UPS jne) samuti.<\/p>\n

<\/p>\n

Selle asemel p\u00f5hineb s\u00fcsteem kvoorumil. K\u00f5igil s\u00f5lmedel on h\u00e4\u00e4l ja t\u00f6\u00f6tada saavad ainult need, mis n\u00e4evad rohkem kui poole k\u00f5igist s\u00f5lmedest. Seda arvu, mis on \"pool+1\", nimetatakse kvorum<\/strong>. Kui kvoorumit ei saavutata, siis otsustab s\u00f5lm, et ta asub v\u00f5rguisolatsioonis ja peab v\u00e4lja l\u00fclitama oma ressursid, st see on selline kaitse split-brain<\/strong>. Kui see tarkvara, mis vastutab selle k\u00e4itumise eest, ei toimi, siis peab t\u00f6\u00f6le hakkama watchdog, n\u00e4iteks IPMI baasil.<\/p>\n

<\/p>\n

Kui s\u00f5lmede arv on paaris (kluster kahes andmekeskuses), v\u00f5ib tekkida nn ebamugavus 50%\/50%<\/strong> (viisk\u00fcmmend viisk\u00fcmmend<\/em>), kui v\u00f5rgu isolatsioon jagab kluster t\u00e4pselt pooleks. Seet\u00f5ttu lisatakse paarisarvuliste s\u00f5lmede jaoks quorum device<\/strong> \u2014 madala n\u00f5udlikkusega demon, mida saab k\u00e4ivitada odavaimal virtuaalmudelis kolmandas andmekeskuses. Ta annab oma h\u00e4\u00e4le \u00fchele segmentidest (mida ta n\u00e4eb), lahendades seel\u00e4bi 50%\/50% ebamugavuse. Serverit, kus quorum seade t\u00f6\u00f6le pannakse, nimetasin ma witness<\/em> (terminoloogia repmgr-ist, meeldiv).<\/p>\n

<\/p>\n

Ressursid saavad liikuda \u00fchest kohast teise, n\u00e4iteks rikete t\u00f5ttu serverite pealt toimivatele v\u00f5i s\u00fcsteemiadministraatorite k\u00e4sul. Et kliendid teaksid, kus vajalikud ressursid asuvad (kuhu \u00fchendada?), kasutatakse ujutavaid IP<\/em> (float IP<\/strong>). Need on IP, mida Pacemaker saab s\u00f5lmedel liigutada (k\u00f5ik asub tasases v\u00f5rgus). Iga\u00fcks neist s\u00fcmboliseerib ressursi (teenuse) ja on seal, kuhu tuleb \u00fchendada, et sellele teenusele (meie puhul andmebaasile) ligip\u00e4\u00e4s saada.<\/p>\n

<\/p>\n

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

<\/p>\n

Struktuur<\/h3>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

M\u00f5te oli selles, et meil on palju v\u00e4ikseid andmebaase madala koormusega, mille jaoks ei ole kasulik hoida p\u00fchendatud slave-serverit kuumvarundusre\u017eiimis ainult lugemisv\u00f5imetustega tehingute jaoks (sellise ressursside raiskamise vajadus puudub).<\/p>\n

<\/p>\n

Igas andme keskuses on \u00fcks server. Igal serveril on kaks PostgreSQL instantsi (PostgreSQL terminoloogias nimetatakse neid klasteriteks, kuid segaduse v\u00e4ltimiseks nimetatakse neid instantsideks (nagu teiste andmebaaside puhul), ja klastreid nimetatakse ainult Pacemakeri klasteriteks). \u00dcks instants t\u00f6\u00f6tab meistrina ja ainult tema osutab teenuseid (ainult tema suunas on float IP). Teine instants t\u00f6\u00f6tab orjana teise andmekeskuse jaoks ja hakkab teenuseid osutama ainult siis, kui tema meister t\u00f5rkub. Kuna enamik aega osutab teenuseid (t\u00e4idab p\u00e4ringuid) ainult \u00fcks kahest instantsist (meister), optimeeritakse serveri k\u00f5ik ressursid meistrile (m\u00e4lu eraldatakse shared_buffers jaoks jne), kuid nii, et ka teisele instantsile jagub ressursse (kuigi mitteoptimaalse t\u00f6\u00f6 jaoks failis\u00fcsteemi cache'i kaudu) \u00fche andmekeskuse rikke korral. Ori ei osuta teenuseid (ei t\u00e4ida read only-p\u00e4ringuid) klastrite normaalse t\u00f6\u00f6 korral, et v\u00e4ltida ressursikonflikte meistriga samas masinas.<\/p>\n

<\/p>\n

Kui tegemist on kahe s\u00f5lmega, siis on t\u00f5hususe tagamine v\u00f5imalik ainult as\u00fcnkroonse replikatsiooni puhul, kuna s\u00fcnkroonse puhul viib orja rike meistri peatamiseni.<\/p>\n

<\/p>\n

Rikke witness<\/h3>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Rikke witness (quorum device<\/em>) vaatlen ainult Tuchanka1 klastri puhul, k\u00f5igi teiste osas on lugu sama. Witness'i rikke korral klastristruktuuris ei muutu midagi, k\u00f5ik t\u00f6\u00f6tab edasi nagu varem. Kuid quorum muutub 2-st 3-st, seega iga j\u00e4rgmine rike on klastrile saatuslik. Igal juhul on kiirelt remontima.<\/p>\n

<\/p>\n

Riik Tuchanka1<\/h3>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

\u00dche andmekeskuse rike Tuchanka1 jaoks. Sel juhul witness<\/em> annab oma h\u00e4\u00e4le teisele s\u00f5lmele teises andmekeskuses. Seal muutub endine ori meistriks, mille tulemuseks on see, et \u00fchel serveril t\u00f6\u00f6tavad m\u00f5lemad meistrid ja suunavad m\u00f5lemad oma float IP-d.<\/p>\n

<\/p>\n

Tuchanka2 (klassikaline)<\/h2>\n

<\/p>\n

Struktuur<\/h3>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Klassikaline skeem kahest s\u00f5lmest. \u00dchel t\u00f6\u00f6tab meister, teisel ori. M\u00f5lemad saavad p\u00e4ringuid teostada (ori ainult read only), seet\u00f5ttu suunatakse m\u00f5lemale float IP: krogan2 \u2014 meistrile, krogan2s1 \u2014 orjale. T\u00f5hususe tagamine on nii meistril kui orjal.<\/p>\n

<\/p>\n

Kahe s\u00f5lme puhul on soovitatav kasutada as\u00fcnkroonset replikatsiooni, sest s\u00fcnkrone replikatsiooni korral toob \u00fcksiku orja rike kaasa pea seadme t\u00f6\u00f6 seiskumise.<\/p>\n

<\/p>\n

Rike Tuchanka2<\/h3>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

\u00dche andmekeskuse rikke korral witness<\/em> h\u00e4\u00e4letab teise poolt. Ainult t\u00f6\u00f6tavas andmekeskuses t\u00f5stetakse pea seade ja m\u00f5lemad float IP: pea ja orja IP viivad sinna. Loomulikult peab instants olema seadistatud nii, et tal on piisavalt ressursse (\u00fchenduse piirangud jne), et \u00fcheaegselt vastu v\u00f5tta k\u00f5ik \u00fchendused ja p\u00e4ringud pea- ja orja float IP-lt. See t\u00e4hendab, et normaalses t\u00f6\u00f6s peab tal olema piisav varu piirangutest.<\/p>\n

<\/p>\n

Tuchanka4 (palju orje)<\/h2>\n

<\/p>\n

Struktuur<\/h3>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

See on juba teine \u00e4\u00e4rmus. On andmebaase, kuhu saadetakse v\u00e4ga palju lugemisettepanekuid (t\u00fc\u00fcpiline olukord k\u00f5rge koormusega veebisaidi puhul). Tuchanka4 on olukord, kus orje v\u00f5ib olla kolm v\u00f5i rohkem selliste p\u00e4ringute t\u00f6\u00f6tlemiseks, kuid mitte siiski liiga palju. Kui orje on v\u00e4ga palju, peab v\u00e4lja m\u00f5tlema hierarhilise replikatsioonis\u00fcsteemi. Minimaalses juhtumis (pildil) on igas kahes andmekeskuses kaks serverit, millel on iga\u00fchel instants PostgreSQL.<\/p>\n

<\/p>\n

Teise olulise omaduse puhul on see, et siin on juba v\u00f5imalik korraldada \u00fchtset s\u00fcnkroonimist. See on seadistatud nii, et vajadusel replikeerida teise andmeti keskusesse, mitte sama andmeti keskuse kopeerimisele. Peamine ja iga orja prindib float IP. T\u00f5epoolest, orjade vahel tuleks teha p\u00e4ringute tasakaalustamine millegi kaudu. sql proxy<\/em>, n\u00e4iteks kliendi pool. erinevatel t\u00fc\u00fcpidel klientidel v\u00f5ib vaja minna erinevat t\u00fc\u00fcpi sql proxy<\/em>, ning ainult klientide arendajad teavad, kellele milline on vajalik. See funktsionaalsus v\u00f5ib olla rakendatud nii v\u00e4lise deemoni kui ka klientide teegi (connection pool) kaudu jne. K\u00f5ik see j\u00e4\u00e4b andmebaasi usaldusv\u00e4\u00e4rse kihi teemade sisse (usaldusv\u00e4\u00e4rsus SQL proxy<\/em> saab rakendada eraldi koos kliendi usaldusv\u00e4\u00e4rsusega).<\/p>\n

<\/p>\n

Tuchanka4 t\u00f5rge<\/h3>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Kui \u00fcks andmekeskus (st kaks serverit) eba\u00f5nnestub, h\u00e4\u00e4letab witness teise poolt. Tulemuseks on see, et teises andmekeskuses t\u00f6\u00f6tavad kaks serverit: \u00fches t\u00f6\u00f6tab meisters server ja sellele viitab meistriserveri float IP (read-write p\u00e4ringute vastuv\u00f5tmiseks); teises serveris t\u00f6\u00f6tab slave, millel on s\u00fcnkroonreplikatsioon, ja sellele viitab \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-d ei ole k\u00f5ik, vaid ainult \u00fcks. Ja selle korrektselt toimimiseks tuleb, et sql proxy<\/em> suunaks k\u00f5ik p\u00e4ringud ainukesele allesj\u00e4\u00e4nud float IP-le; ja kui sql proxy<\/em> ei, siis v\u00f5ib loetleda k\u00f5ik slave float IP-d komaga eraldatult URL-is \u00fchenduse loomiseks. Sellisel juhul on libpq<\/em> \u00fchendamine esimese t\u00f6\u00f6tava IP-ga, nagu on tehtud automaattestimise s\u00fcsteemis. V\u00f5imalik, et teistes raamatukogudes, n\u00e4iteks JDBC-s, ei pruugi see nii t\u00f6\u00f6tada ja vajalik on sql proxy<\/em>. Nii on tehtud, sest slave float IP-de puhul on keelatud samaaegselt sama serveris t\u00f6\u00f6tamine, et need jaotuksid \u00fchtlaselt slave serverite vahel, kui neid t\u00f6\u00f6tab mitu.<\/p>\n

<\/p>\n

Teiseks: isegi andmekeskuse rikke korral s\u00e4ilib s\u00fcnkroonne kopeerimine. Isegi kui juhtub teine rike, kui \u00fches allesj\u00e4\u00e4nud andmekeskuses eba\u00f5nnestub \u00fcks kahest serverist, l\u00f5petab klaster k\u00fcll teenuste osutamise, kuid salvestab siiski teavet k\u00f5igi kinnitatud tehingute kohta, millele ta on andnud kinnituse (teise rikke korral ei tohi info kaduma minna).<\/p>\n

<\/p>\n

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

<\/p>\n

Struktuur<\/h3>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

See klaster on m\u00f5eldud olukorraks, kus on kolm t\u00e4ielikult t\u00f6\u00f6tavat andmekeskust, milles igas on t\u00e4ielikult toimiv andmebaasi server. Sel juhul quorum device<\/em> ei ole vajalik. \u00dches andmekeskuses t\u00f6\u00f6tab master, kahes teises - orjad. Replikatsioon on s\u00fcnkroonne, t\u00fc\u00fcpi ANY (slave1, slave2), st kliendile saadakse kinnituskiri kommitud tehingute kohta, kui \u00fcks orjadest esimesena vastab, et ta on kommitud vastu v\u00f5tnud. Ressursside jaoks on m\u00e4\u00e4ratud \u00fcks float IP masterile ja kaks orjadele. Erinevalt Tuchanka4-st on k\u00f5ik kolm float IP-d t\u00f5rke jooksul vastupidavad. Read-only SQL-p\u00e4ringute tasakaalustamiseks saab kasutada sql proxy<\/em> (eraldiseisva rikkevastupidavusega), v\u00f5i m\u00e4\u00e4rata poolele klientidele \u00fche orja float IP ning teisele poolele teise.<\/p>\n

<\/p>\n

T\u00f5rge Tuchanka3<\/h3>\n

<\/p>\n

\"PostgreSQL<\/p>\n

<\/p>\n

Kui \u00fcks andmete keskus eba\u00f5nnestub, j\u00e4\u00e4vad alles kaks. \u00dches on master ja float IP masterist, teises on t\u00f6\u00f6 ja m\u00f5lemad t\u00f6\u00f6 float IP-d (instantsil peab olema kahekordne ressursside varu, et vastu v\u00f5tta k\u00f5ik \u00fchendused m\u00f5lemalt t\u00f6\u00f6 float IP-lt). Masterite ja t\u00f6\u00f6 vahel toimub s\u00fcnkroonne replikatsioon. Samuti s\u00e4ilitab klaster teavet kinnitatud ja kinnitatud tehingute kohta (mingeid andmeid ei kao) juhul, kui kaks andmete keskust h\u00e4vivad (kui need ei h\u00e4vi samal ajal).<\/p>\n

<\/p>\n

Otsustasin mitte lisada \u00fcksikasjalikku kirjeldust failistruktuurist ja juurutamisest. Kes soovib m\u00e4ngida, v\u00f5ite selle k\u00f5ik lugeda README-s. Toodan ainult automaatse testimise kirjelduse.<\/em><\/p>\n

<\/p>\n

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

<\/p>\n

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

<\/p>\n

test\/failure 2 3<\/code><\/pre>\n
<\/p>\n
testib ainult teist ja kolmandat klastrit. Kui parameetreid ei ole m\u00e4\u00e4ratud, testitakse k\u00f5iki klasse. K\u00f5iki klasse testitakse paralleelselt ja tulemused kuvatakse tmuxi paneelil. Tmux kasutab p\u00fchendatud tmux serverit, seega saab skripti k\u00e4ivitada ka vaikimisi tmuxist, mille tulemuseks on sisemine tmux. Soovitan kasutada terminali suure akna ja v\u00e4ikese fontiga. Enne testimise alustamist taastatakse k\u00f5ik virtuaalmasinad r\u00e4\u00e4kima hetkel, mil skript l\u00f5ppes. setup<\/code>.<\/p>\n
<\/p>\n
\"PostgreSQL<\/p>\n
<\/p>\n
Terminal on jagatud veergudeks, mis vastavad testitavatele klastritele, vaikimisi on neid neli (nagu ekraanipildil). Veergude sisu kirjeldan Tuchanka2 n\u00e4itel. Paneelid ekraanipildil on numeeritud:<\/p>\n
<\/p>\n
    \n
  1. Siin kuvatakse testide statistika. Veerud:\n