{"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\/sk\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","title":{"rendered":"Modelovanie odoln\u00fdch klastrov zalo\u017een\u00fdch na PostgreSQL a Pacemaker","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00davod<\/h1>\n

<\/p>\n

Pred nieko\u013ek\u00fdmi mesiacmi sa mi naskytla \u00faloha vyvin\u00fa\u0165 vysoko dostupn\u00fd klaster pre PostgreSQL<\/a><\/noindex>, ktor\u00fd funguje v nieko\u013ek\u00fdch d\u00e1tov\u00fdch centr\u00e1ch prepojen\u00fdch optick\u00fdm vl\u00e1knom v r\u00e1mci jedn\u00e9ho mesta a odol\u00e1va poruche (napr\u00edklad v\u00fdpadku energie) jedn\u00e9ho d\u00e1tov\u00e9ho centra. Ako softv\u00e9r, ktor\u00fd zais\u0165uje vysok\u00fa dostupnos\u0165, som zvolil Pacemaker<\/a><\/noindex>, preto\u017ee je to ofici\u00e1lne rie\u0161enie od RedHat pre vytv\u00e1ranie vysoko dostupn\u00fdch klastrov. Je dobr\u00e9 t\u00fdm, \u017ee RedHat zabezpe\u010duje jeho podporu a \u017ee ide o univerz\u00e1lne (modul\u00e1rne) rie\u0161enie. S jeho pomocou bude mo\u017en\u00e9 zabezpe\u010di\u0165 vysok\u00fa dostupnos\u0165 nielen pre PostgreSQL, ale aj pre in\u00e9 slu\u017eby, bu\u010f pou\u017eit\u00edm \u0161tandardn\u00fdch modulov, alebo vytvoren\u00edm vlastn\u00fdch pod\u013ea konkr\u00e9tnych potrieb.<\/p>\n

<\/p>\n

K tomuto rie\u0161eniu sa objavila opr\u00e1vnen\u00e1 ot\u00e1zka: ak\u00e1 vysok\u00e1 bude dostupnos\u0165 vysoko dostupn\u00e9ho klastru? Na presk\u00famanie tejto t\u00e9my som vytvoril testovac\u00ed syst\u00e9m, ktor\u00fd imituje r\u00f4zne poruchy na uzloch klastru, o\u010dak\u00e1va obnovenie funk\u010dnosti, obnovuje nefunk\u010dn\u00fd uzol a pokra\u010duje v testovan\u00ed v cykle. P\u00f4vodne sa tento projekt volal hapgsql, ale \u010dasom ma omrzelo toto meno, v ktorom bola len jedna samohl\u00e1ska. Preto som za\u010dal naz\u00fdva\u0165 vysoko dostupn\u00e9 datab\u00e1zy (a float IP, ktor\u00e9 na ne odkazuj\u00fa) krogan<\/strong> (postava z po\u010d\u00edta\u010dovej hry, ktor\u00e1 m\u00e1 v\u0161etky d\u00f4le\u017eit\u00e9 org\u00e1ny duplikovan\u00e9), a uzly, klastry a samotn\u00fd projekt \u2013 tuchanka<\/strong> (plan\u00e9ta, kde \u017eij\u00fa krogania).<\/p>\n

<\/p>\n

Teraz vedenie povolilo otvori\u0165 projekt pre open source komunitu pod licenciou MIT<\/a><\/noindex>. README bude \u010doskoro prelo\u017een\u00e9 do angli\u010dtiny (preto\u017ee sa o\u010dak\u00e1va, \u017ee hlavn\u00fdmi pou\u017e\u00edvate\u013emi bud\u00fa v\u00fdvoj\u00e1ri Pacemaker a PostgreSQL), a star\u00fa rusk\u00fa verziu README som sa rozhodol upravi\u0165 (\u010diasto\u010dne) vo forme tohto \u010dl\u00e1nku.<\/p>\n

<\/p>\n

\"Modelovanie<\/p>\n

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

Klastre sa nasadzuj\u00fa na virtu\u00e1lnych strojoch VirtualBox<\/a><\/noindex>. Celkovo bude nasaden\u00fdch 12 virtu\u00e1lnych strojov (spolu 36GiB), ktor\u00e9 vytvoria 4 vysoko dostupn\u00e9 klastry (r\u00f4zne varianty). Prv\u00e9 dva klastry pozost\u00e1vaj\u00fa z dvoch serverov PostgreSQL, ktor\u00e9 s\u00fa umiestnen\u00e9 v r\u00f4znych d\u00e1tov\u00fdch centr\u00e1ch, a spolo\u010dn\u00e9ho servera witness<\/em> c quorum device<\/strong> (umiestnen\u00e9 na lacnom virtu\u00e1lnom stroji v tre\u0165om d\u00e1tovom centre), ktor\u00fd rozuzl\u00ed nejasnos\u0165 50%\/50%<\/strong>, d\u00e1vaj\u00fac svoj hlas jednej zo str\u00e1n. Tret\u00ed klaster je v troch d\u00e1tov\u00fdch centr\u00e1ch: jeden master, dva slave, bez quorum device<\/strong>. \u0160tvrt\u00fd cluster pozost\u00e1va zo \u0161tyroch serverov PostgreSQL, po dva na d\u00e1tov\u00e9 centrum: jeden je hlavn\u00fd, ostatn\u00e9 s\u00fa repliky, a tie\u017e pou\u017e\u00edva witness<\/em> c quorum device<\/strong>. \u0160tvrt\u00fd zvl\u00e1da v\u00fdpadok dvoch serverov alebo jedn\u00e9ho d\u00e1tov\u00e9ho centra. Toto rie\u0161enie m\u00f4\u017ee by\u0165, ak je to potrebn\u00e9, roz\u0161\u00edren\u00e9 na v\u00e4\u010d\u0161\u00ed po\u010det replik.<\/p>\n

<\/p>\n

Slu\u017eba presn\u00e9ho \u010dasu ntpd<\/a><\/noindex> tie\u017e je prekonfigurovan\u00e1 na vysok\u00fa dostupnos\u0165, pri\u010dom sa pou\u017e\u00edva met\u00f3da ntpd<\/code> (orphan mode<\/em>). Spolo\u010dn\u00fd server witness<\/em> zohr\u00e1va \u00falohu centr\u00e1lny NTP server, poskytuj\u00fac svoj \u010das v\u0161etk\u00fdm clusterom, \u010d\u00edm synchronizuje v\u0161etky servery medzi sebou. Ak witness<\/em> vypadne alebo bude izolovan\u00fd, za\u010dne svoj \u010das poskytova\u0165 jeden zo serverov klastrov (v r\u00e1mci klastru). Pomocn\u00fd vyrovn\u00e1vac\u00ed HTTP proxy<\/strong> taktie\u017e je spusten\u00fd na witness<\/em>, s jeho pomocou maj\u00fa ostatn\u00e9 virtu\u00e1lne stroje pr\u00edstup k Yum-repozit\u00e1rom. V skuto\u010dnosti bud\u00fa tak\u00e9to slu\u017eby, ako presn\u00fd \u010das a proxy, ur\u010dite hosten\u00e9 na vyhraden\u00fdch serveroch, zatia\u013e \u010do v st\u00e1nku s\u00fa hosten\u00e9 na witness<\/em> len kv\u00f4li \u00faspore po\u010dtu virtu\u00e1lnych strojov a miesta.<\/p>\n

<\/p>\n

Verzie<\/h1>\n

<\/p>\n

v0. Funguje s CentOS 7 a PostgreSQL 11 na VirtualBox 6.1.<\/p>\n

<\/p>\n

\u0160trukt\u00fara klastrov<\/h1>\n

<\/p>\n

V\u0161etky clustre s\u00fa ur\u010den\u00e9 na umiestnenie v nieko\u013ek\u00fdch d\u00e1tov\u00fdch centr\u00e1ch, s\u00fa prepojen\u00e9 do jednej plochej siete a musia odol\u00e1va\u0165 v\u00fdpadku alebo sie\u0165ovej izol\u00e1cii jedn\u00e9ho d\u00e1tov\u00e9ho centra. Preto ned\u00e1 vykona\u0165<\/strong> pou\u017ei\u0165 na ochranu pred split-brain<\/strong> \u0161tandardn\u00fa technol\u00f3giu Pacemaker, ktor\u00e1 sa naz\u00fdva STONITH<\/em> (Shoot The Other Node In The Head) alebo fencing<\/em>. Jej podstata: ak uzly v klastri za\u010dn\u00fa podozrieva\u0165, \u017ee s niektorou uzlom sa deje nie\u010do zl\u00e9, nenap\u00e1ja sa alebo sa spr\u00e1va nespr\u00e1vne, tak ho n\u00fatene odpoja cez \u201eextern\u00e9\u201c zariadenia, ako napr\u00edklad riadiacu kartu IPMI alebo UPS. Ale toto funguje len v pr\u00edpadoch, ke\u010f pri jednotkovom v\u00fdpadku servera IPMI alebo UPS na\u010falej funguj\u00fa. Tu sa pl\u00e1nuje ochrana pred ove\u013ea katastrofickej\u0161\u00edm v\u00fdpadkom, ke\u010f zlyh\u00e1 (napr. je odpojen\u00e9 od nap\u00e1jania) cel\u00e9 d\u00e1tov\u00e9 centrum. A pri takomto v\u00fdpadku v\u0161etky stonith<\/em>-zariadenia (IPMI, UPS at\u010f.) tie\u017e nebud\u00fa fungova\u0165.<\/p>\n

<\/p>\n

Namiesto toho v z\u00e1kladnom syst\u00e9me le\u017e\u00ed my\u0161lienka kv\u00f3ra. V\u0161etky uzly maj\u00fa hlas a m\u00f4\u017eu pracova\u0165 len tie, ktor\u00e9 vidia viac ako polovicu v\u0161etk\u00fdch uzlov. Tento po\u010det \u201epolovica+1\u201c sa naz\u00fdva kv\u00f3rum<\/strong>. Ak sa kv\u00f3rum nenazbiera, uzol sa rozhodne, \u017ee sa nach\u00e1dza v sie\u0165ovej izol\u00e1cii a mus\u00ed odpoji\u0165 svoje zdroje, t.j. to je tak\u00e1 ochrana proti split-brain<\/strong>. Ak softv\u00e9r, ktor\u00fd zodpoved\u00e1 za tak\u00e9to spr\u00e1vanie, nefunguje, mal by sa aktivova\u0165 watchdog, napr\u00edklad na b\u00e1ze IPMI.<\/p>\n

<\/p>\n

Ak je po\u010det uzlov p\u00e1rny (klaster v dvoch d\u00e1tov\u00fdch centr\u00e1ch), m\u00f4\u017ee vznikn\u00fa\u0165 takzvan\u00e1 neur\u010ditos\u0165 50%\/50%<\/strong> (fifty-fifty<\/em>), kedy sie\u0165ov\u00e1 izol\u00e1cia rozdel\u00ed klaster presne napoly. Preto sa pre p\u00e1rny po\u010det uzlov prid\u00e1va quorum device<\/strong> \u2014 nen\u00e1ro\u010dn\u00fd d\u00e9mon, ktor\u00fd m\u00f4\u017ee by\u0165 spusten\u00fd na najlacnej\u0161ej virtu\u00e1lke v tre\u0165om d\u00e1tovom centre. D\u00e1va svoj hlas jedn\u00e9mu z segmentov (ktor\u00fd vid\u00ed), \u010d\u00edm odstra\u0148uje neur\u010ditos\u0165 50%\/50%. Server, na ktorom bude spusten\u00e9 quorum device, som nazval witness<\/em> (terminol\u00f3gia z repmgr, p\u00e1\u010dila sa mi).<\/p>\n

<\/p>\n

Zdroje m\u00f4\u017eu pres\u00fava\u0165 svoje umiestnenie, napr\u00edklad z nefunk\u010dn\u00fdch serverov na funk\u010dn\u00e9, alebo na pr\u00edkaz syst\u00e9mov\u00fdch administr\u00e1torov. Aby klienti vedeli, kde sa nach\u00e1dzaj\u00fa potrebn\u00e9 zdroje (kam sa pripoji\u0165?), pou\u017e\u00edvaj\u00fa sa pl\u00e1vaj\u00face IP<\/em> (float IP<\/strong>). To s\u00fa IP, ktor\u00e9 m\u00f4\u017ee Pacemaker pres\u00fava\u0165 medzi uzlami (v\u0161etko je v plochej sieti). Ka\u017ed\u00fd z nich symbolizuje zdroj (slu\u017ebu) a bude sa nach\u00e1dza\u0165 tam, kam je potrebn\u00e9 pripoji\u0165 sa, aby sa z\u00edskal pr\u00edstup k tejto slu\u017ebe (v na\u0161om pr\u00edpade DB).<\/p>\n

<\/p>\n

Tuchanka1 (sch\u00e9ma s utesnen\u00edm)<\/h2>\n

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelovanie<\/p>\n

<\/p>\n

My\u0161lienka bola v tom, \u017ee m\u00e1me mnoho drobn\u00fdch datab\u00e1z s n\u00edzkym za\u0165a\u017een\u00edm, pre ktor\u00e9 nie je v\u00fdhodn\u00e9 udr\u017eiava\u0165 vyhraden\u00fd slave-server v re\u017eime hot standby pre read only transakcie (nie je potrebn\u00e9 takto zbyto\u010dne m\u00ed\u0148a\u0165 zdroje).<\/p>\n

<\/p>\n

V ka\u017edom d\u00e1tovom centre je jeden server. Na ka\u017edom serveri s\u00fa dve in\u0161tancie PostgreSQL (v terminol\u00f3gii PostgreSQL sa volaj\u00fa klastre, ale aby sa predi\u0161lo zm\u00e4tku, budem ich naz\u00fdva\u0165 in\u0161tanciami (podobne ako in\u00e9 DB) a klastrami budem naz\u00fdva\u0165 iba klastre Pacemaker). Jeden in\u0161tancia funguje v re\u017eime majstra a len ona poskytuje slu\u017eby (iba na \u0148u vedie float IP). Druh\u00e1 in\u0161tancia funguje ako otrok pre druh\u00e9 d\u00e1tov\u00e9 centrum a bude poskytova\u0165 slu\u017eby iba v pr\u00edpade, \u017ee jej majster zlyh\u00e1. Ke\u010f\u017ee v\u00e4\u010d\u0161inu \u010dasu poskytuje slu\u017eby (vykon\u00e1va dotazy) iba jedna in\u0161tancia z dvoch (majster), v\u0161etky prostriedky servera s\u00fa optimalizovan\u00e9 pre majstra (vy\u010dlenen\u00e1 pam\u00e4\u0165 pre cache shared_buffers at\u010f.), ale tak, aby aj druh\u00e1 in\u0161tancia mala dostatok prostriedkov (nech aj na suboptim\u00e1lnu pr\u00e1cu cez cache s\u00faborov\u00e9ho syst\u00e9mu) v pr\u00edpade zlyhania jedn\u00e9ho z d\u00e1tov\u00fdch centier. Otrok neposkytuje slu\u017eby (nevykon\u00e1va read only dotazy) za norm\u00e1lnej prev\u00e1dzky klastru, aby nedo\u0161lo k boju o prostriedky s majstrom na tej istej ma\u0161ine.<\/p>\n

<\/p>\n

V pr\u00edpade dvoch uzlov je vysok\u00e1 dostupnos\u0165 mo\u017en\u00e1 iba pri asynchr\u00f3nnej replik\u00e1cii, preto\u017ee pri synchronizovanej replik\u00e1cii zlyhanie otroka vedie k zastaveniu majstra.<\/p>\n

<\/p>\n

Zlyhanie witness<\/h3>\n

<\/p>\n

\"Modelovanie<\/p>\n

<\/p>\n

Zlyhanie witness (quorum device<\/em>) sa budem zaobera\u0165 iba pre klaster Tuchanka1, so v\u0161etk\u00fdmi ostatn\u00fdmi bude rovnak\u00fd pr\u00edbeh. Pri zlyhan\u00ed witness v \u0161trukt\u00fare klastru sa ni\u010d nezmen\u00ed, v\u0161etko bude aj na\u010falej fungova\u0165 tak, ako fungovalo. Ale kv\u00f3rum sa stane rovn\u00e9 2 z 3, a preto ak\u00e9ko\u013evek nasleduj\u00face zlyhanie bude fat\u00e1lne pre klaster. A tak \u010di tak bude nutn\u00e9 okam\u017eite opravi\u0165.<\/p>\n

<\/p>\n

Zlyhanie Tuchanka1<\/h3>\n

<\/p>\n

\"Modelovanie<\/p>\n

<\/p>\n

Zlyhanie jedn\u00e9ho z d\u00e1tov\u00fdch centier pre Tuchanka1. V tomto pr\u00edpade witness<\/em> odovzd\u00e1va svoj hlas druh\u00e9mu uzlu na druhom d\u00e1tovom centre. Tam sa b\u00fdval\u00fd otrok premen\u00ed na majstra, v\u00fdsledkom \u010doho na jednom serveri pracuj\u00fa obaja majstri a na nich smeruj\u00fa oba ich float IP.<\/p>\n

<\/p>\n

Tuchanka2 (klasick\u00e9)<\/h2>\n

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelovanie<\/p>\n

<\/p>\n

Klasick\u00e9 sch\u00e9ma z dvoch uzlov. Na jednom be\u017e\u00ed majster, na druhom otrok. Obaja m\u00f4\u017eu vykon\u00e1va\u0165 dotazy (otrok iba read only), preto na oboch smeruj\u00fa float IP: krogan2 \u2014 na majstra, krogan2s1 \u2014 na otroka. Vysok\u00e1 dostupnos\u0165 bude aj u majstra, aj u otroka.<\/p>\n

<\/p>\n

V pr\u00edpade dvoch uzlov je vysok\u00e1 dostupnos\u0165 mo\u017en\u00e1 iba pri asynchr\u00f3nnej replik\u00e1cii, preto\u017ee pri synchronizovanej replik\u00e1cii zlyhanie otroka vedie k zastaveniu majstra.<\/p>\n

<\/p>\n

Zlyhanie Tuchanka2<\/h3>\n

<\/p>\n

\"Modelovanie<\/p>\n

<\/p>\n

Pri zlyhan\u00ed jedn\u00e9ho z d\u00e1tov\u00fdch centier witness<\/em> hlasuje za druh\u00fd. Na jedinom funguj\u00facom d\u00e1tovom centre bude spusten\u00fd master a na\u0148 bud\u00fa ukazova\u0165 oba float IP: master a slave. Samozrejme, in\u0161tancia mus\u00ed by\u0165 nastaven\u00e1 tak, aby mala dostatok zdrojov (limitov na pripojenia at\u010f.) na to, aby s\u00fa\u010dasne akceptovala v\u0161etky pripojenia a po\u017eiadavky od master a slave float IP. To znamen\u00e1, \u017ee pri be\u017enej prev\u00e1dzke by mala ma\u0165 dostato\u010dn\u00fa rezervu po limitoch.<\/p>\n

<\/p>\n

Tuchanka4 (ve\u013ea slave)<\/h2>\n

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelovanie<\/p>\n

<\/p>\n

U\u017e in\u00fd extr\u00e9m. Existuj\u00fa DB, na ktor\u00e9 prich\u00e1dza ve\u013emi ve\u013ea po\u017eiadaviek read-only (typick\u00fd pr\u00edpad vysoce za\u0165a\u017eenej str\u00e1nky). Tuchanka4 \u2014 to je situ\u00e1cia, ke\u010f m\u00f4\u017ee by\u0165 troch alebo viac slave na spracovanie tak\u00fdchto po\u017eiadaviek, ale predsa len nie pr\u00edli\u0161 ve\u013ea. Pri ve\u013emi vysokom po\u010dte slave bude potrebn\u00e9 vym\u00fd\u0161\u013ea\u0165 hierarchick\u00fd syst\u00e9m replik\u00e1cie. V minim\u00e1lnom pr\u00edpade (na obr\u00e1zku) sa v ka\u017edom z dvoch d\u00e1tov\u00fdch centier nach\u00e1dzaj\u00fa po dva servery, na ktor\u00fdch be\u017e\u00ed jedna in\u0161tancia PostgreSQL.<\/p>\n

<\/p>\n

\u010eal\u0161ou zvl\u00e1\u0161tnos\u0165ou tohto sch\u00e9my je, \u017ee tu u\u017e je mo\u017en\u00e9 usporiada\u0165 jednu synchronn\u00fa replik\u00e1ciu. Je nastaven\u00e1 tak, aby replikovala, ak je to mo\u017en\u00e9, do in\u00e9ho d\u00e1tov\u00e9ho centra, a nie na replik\u00e1t v tej istej d\u00e1tovej centr\u00e1le, kde je aj master. Na master a na ka\u017ed\u00e9ho slave ukazuje float IP. V skuto\u010dnosti by medzi slave potrebn\u00e1 vyv\u00e1\u017eenos\u0165 po\u017eiadaviek prostredn\u00edctvom nejak\u00e9ho sql proxy<\/em>, napr\u00edklad na strane klienta. R\u00f4znemu typu klientov m\u00f4\u017ee by\u0165 potrebn\u00fd r\u00f4zny typ sql proxy<\/em>, a len v\u00fdvoj\u00e1ri klientov vedia, ktor\u00fdm typom potrebuj\u00fa. T\u00e1to funk\u010dnos\u0165 m\u00f4\u017ee by\u0165 realizovan\u00e1 bu\u010f extern\u00fdm d\u00e9monom, alebo kni\u017enicou klienta (connection pool) at\u010f. V\u0161etko toto presahuje r\u00e1mec t\u00e9my odoln\u00e9ho klastrov\u00e9ho DB (odolnos\u0165 SQL proxy<\/em> je mo\u017en\u00e9 realizova\u0165 nez\u00e1visle, s\u00fa\u010dasne s odolnos\u0165ou klienta).<\/p>\n

<\/p>\n

Porucha Tuchanka4<\/h3>\n

<\/p>\n

\"Modelovanie<\/p>\n

<\/p>\n

Pri poruche jedn\u00e9ho d\u00e1tov\u00e9ho centra (t.j. dvoch serverov) witness hlasuje za druh\u00fd. V d\u00f4sledku toho v druhom d\u00e1tovom centre pracuj\u00fa dva servery: na jednom be\u017e\u00ed master a na\u0148 ukazuje master float IP (na prij\u00edmanie read-write po\u017eiadaviek); a na druhom serveri pracuje slave so synchronnou replik\u00e1ciou a na\u0148 ukazuje jeden zo slave float IP (na read only po\u017eiadavky).<\/p>\n

<\/p>\n

Prv\u00e1 vec, ktor\u00fa treba poznamena\u0165: pracovn\u00fdm slave float IP nebude v\u0161etko, ale iba jeden. A pre spr\u00e1vnu funk\u010dnos\u0165 s n\u00edm bude potrebn\u00e9, aby sql proxy<\/em> presmeroval v\u0161etky po\u017eiadavky na jedin\u00fd zost\u00e1vaj\u00faci float IP; a ak nie, sql proxy<\/em> m\u00f4\u017eete v URL na pripojenie uvies\u0165 v\u0161etky float IP slave oddelen\u00e9 \u010diarkou. V takom pr\u00edpade s libpq<\/em> pripojenie bude na prv\u00fd pracovn\u00fd IP, ako je to nastaven\u00e9 v automatizovanom testovan\u00ed. Mo\u017eno, \u017ee v in\u00fdch kni\u017eniciach, ako napr\u00edklad JDBC, to tak fungova\u0165 nebude a je potrebn\u00e9 sql proxy<\/em>. Je to tak preto, \u017ee float IP pre slave maj\u00fa zak\u00e1zan\u00e9 s\u00fa\u010dasne sa zvy\u0161ova\u0165 na jednom serveri, aby sa rovnomerne rozde\u013eovali medzi slave servery v pr\u00edpade, \u017ee ich pracuje nieko\u013eko.<\/p>\n

<\/p>\n

Druh\u00e9: aj v pr\u00edpade zlyhania d\u00e1tov\u00e9ho centra zostane zachovan\u00e1 synchronn\u00e1 replik\u00e1cia. A aj ke\u010f d\u00f4jde k sekund\u00e1rnemu zlyhaniu, t.j. v zost\u00e1vaj\u00facom d\u00e1tovom centre zlyh\u00e1 jeden z dvoch serverov, klaster s\u00edce prestane poskytova\u0165 slu\u017eby, ale st\u00e1le si uchov\u00e1 inform\u00e1cie o v\u0161etk\u00fdch potvrden\u00fdch transakci\u00e1ch, ku ktor\u00fdm dal potvrdenie o commite (ned\u00f4jde k strate inform\u00e1ci\u00ed pri sekund\u00e1rnom zlyhan\u00ed).<\/p>\n

<\/p>\n

Tuchanka3 (3 d\u00e1tov\u00e9 centr\u00e1)<\/h2>\n

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelovanie<\/p>\n

<\/p>\n

Toto je klaster pre situ\u00e1ciu, ke\u010f s\u00fa tri plne funk\u010dn\u00e9 d\u00e1tov\u00e9 centr\u00e1, v ktor\u00fdch ka\u017ed\u00fd obsahuje plne funk\u010dn\u00fd datab\u00e1zov\u00fd server. V tomto pr\u00edpade quorum device<\/em> nie je potrebn\u00fd. V jednom d\u00e1tovom centre funguje master, v dvoch ostatn\u00fdch \u2014 slaves. Replik\u00e1cia je synchronn\u00e1, typu ANY (slave1, slave2), \u010do znamen\u00e1, \u017ee klient dostane potvrdenie o commite, ke\u010f ktor\u00fdko\u013evek z slave odpovie ako prv\u00fd, \u017ee prijal commit. Na zdroje ukazuje jeden float IP pre mastera a dva pre slaves. Na rozdiel od Tuchanka4 s\u00fa v\u0161etky tri float IP odoln\u00e9 vo\u010di zlyhaniu. Pre vyva\u017eovanie SQL po\u017eiadaviek len na \u010d\u00edtanie m\u00f4\u017eete pou\u017ei\u0165 sql proxy<\/em> (s oddelenou odolnos\u0165ou vo\u010di zlyhaniu), alebo polovici klientov priradi\u0165 jeden slave float IP a druhej polovici \u2014 druh\u00fd.<\/p>\n

<\/p>\n

Zlyhanie Tuchanka3<\/h3>\n

<\/p>\n

\"Modelovanie<\/p>\n

<\/p>\n

Pri zlyhan\u00ed jedn\u00e9ho z d\u00e1tov\u00fdch centier zostan\u00fa dve. V jednom je spusten\u00fd master a float IP od mastera, vo druhom \u2014 slave a oba slave float IP (na in\u0161tancii by mal by\u0165 zdvojen\u00fd z\u00e1sobn\u00edk zdrojov, aby prijal v\u0161etky pripojenia z oboch slave float IP). Medzi masterom a slave je synchronn\u00e1 replik\u00e1cia. Klaster tie\u017e uchov\u00e1 inform\u00e1cie o potvrden\u00fdch a schv\u00e1len\u00fdch transakci\u00e1ch (ned\u00f4jde k strate inform\u00e1ci\u00ed) v pr\u00edpade zni\u010denia dvoch d\u00e1tov\u00fdch centier (ak nie s\u00fa zni\u010den\u00e9 s\u00fa\u010dasne).<\/p>\n

<\/p>\n

Podrobn\u00e9 opisy s\u00faborovej \u0161trukt\u00fary a nasadenia som sa rozhodol neuv\u00e1dza\u0165. Kto chce experimentova\u0165, m\u00f4\u017ee si v\u0161etko pre\u010d\u00edta\u0165 v README. Prip\u00e1jame len popis automatizovan\u00e9ho testovania.<\/em><\/p>\n

<\/p>\n

Syst\u00e9m automatizovan\u00e9ho testovania<\/h1>\n

<\/p>\n

Na overenie odolnosti klastrov s imit\u00e1ciou r\u00f4znych por\u00fach bol vytvoren\u00fd syst\u00e9m automatizovan\u00e9ho testovania. Sp\u00fa\u0161\u0165a sa skriptom test\/failure<\/code>. Skript m\u00f4\u017ee prij\u00edma\u0165 ako parametre \u010d\u00edsla klastrov, ktor\u00e9 sa maj\u00fa testova\u0165. Napr\u00edklad tento pr\u00edkaz:<\/p>\n

<\/p>\n

test\/failure 2 3<\/code><\/pre>\n
<\/p>\n
bude testova\u0165 len druh\u00fd a tret\u00ed klaster. Ak nie s\u00fa parametre zadan\u00e9, testova\u0165 sa bud\u00fa v\u0161etky klastre. V\u0161etky klastre sa testuj\u00fa paralelne a v\u00fdsledok sa zobrazuje v paneli tmux. Tmux pou\u017e\u00edva vyhraden\u00fd tmux server, tak\u017ee skript je mo\u017en\u00e9 sp\u00fa\u0161\u0165a\u0165 z defaultn\u00e9ho tmux, vytvor\u00ed sa vnoren\u00fd tmux. Odpor\u00fa\u010dam pou\u017e\u00edva\u0165 termin\u00e1l v ve\u013ekom okne a s mal\u00fdm p\u00edsmom. Pred za\u010diatkom testovania sa v\u0161etky virtu\u00e1lne stroje vr\u00e1tia sp\u00e4\u0165 na snapshot v momente ukon\u010denia skriptu. setup<\/code>.<\/p>\n
<\/p>\n
\"Modelovanie<\/p>\n
<\/p>\n
Termin\u00e1l je rozdelen\u00fd na st\u013apce pod\u013ea po\u010dtu testovan\u00fdch klastrov, predvolene (na sn\u00edmke) ich je \u0161tyri. Obsah st\u013apcov podrobne op\u00ed\u0161em na pr\u00edklade Tuchanka2. Panely na sn\u00edmke s\u00fa \u010d\u00edslovan\u00e9:<\/p>\n
<\/p>\n
    \n
  1. Tu sa zobrazuje \u0161tatistika testov. St\u013apce:\n