{"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\/cs\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","title":{"rendered":"Modelov\u00e1n\u00ed odoln\u00fdch cluster\u016f na b\u00e1zi PostgreSQL a Pacemaker","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00davod<\/h1>\n

<\/p>\n

N\u011bjakou dobu zp\u011bt jsem dostal \u00fakol vyvinout vysoce dostupn\u00fd klastr pro PostgreSQL<\/a><\/noindex>, funguj\u00edc\u00ed ve v\u00edce datov\u00fdch centrech, propojen\u00fdch optick\u00fdmi vl\u00e1kny v r\u00e1mci jednoho m\u011bsta, a schopn\u00fd odolat v\u00fdpadku (nap\u0159\u00edklad v\u00fdpadku nap\u00e1jen\u00ed) jednoho datov\u00e9ho centra. Jako software, kter\u00fd zaji\u0161\u0165uje vysokou dostupnost, jsem zvolil Pacemaker<\/a><\/noindex>, proto\u017ee je to ofici\u00e1ln\u00ed \u0159e\u0161en\u00ed od RedHat pro vytv\u00e1\u0159en\u00ed vysoce dostupn\u00fdch klastr\u016f. Je v\u00fdhodn\u00e9, \u017ee RedHat zaji\u0161\u0165uje jeho podporu, a \u017ee toto \u0159e\u0161en\u00ed je univerz\u00e1ln\u00ed (modul\u00e1rn\u00ed). S jeho pomoc\u00ed je mo\u017en\u00e9 zajistit vysokou dostupnost nejen pro PostgreSQL, ale i pro dal\u0161\u00ed slu\u017eby, bu\u010f pomoc\u00ed standardn\u00edch modul\u016f, nebo jejich vytvo\u0159en\u00edm na m\u00edru.<\/p>\n

<\/p>\n

K tomu se objevila rozumn\u00e1 ot\u00e1zka: jak moc bude vysoce dostupn\u00fd klastr skute\u010dn\u011b odoln\u00fd? Abych to prozkoumal, vytvo\u0159il jsem testovac\u00ed stanici, kter\u00e1 simuluje r\u016fzn\u00e9 v\u00fdpadky na uzlech klastru, \u010dek\u00e1 na obnoven\u00ed funk\u010dnosti, obnovuje selh\u00e1vaj\u00edc\u00ed uzel a pokra\u010duje v testov\u00e1n\u00ed v cyklu. Tento projekt byl p\u016fvodn\u011b nazv\u00e1n hapgsql, ale \u010dasem m\u011b omrzelo jm\u00e9no, kter\u00e9 m\u00e1 jen jednu samohl\u00e1sku. Proto jsem za\u010dal naz\u00fdvat vysoce dostupn\u00e9 datab\u00e1ze (a float IP, kter\u00e9 na n\u011b ukazuj\u00ed) krogan<\/strong> (postava z po\u010d\u00edta\u010dov\u00e9 hry, jej\u00ed\u017e v\u0161echny d\u016fle\u017eit\u00e9 org\u00e1ny jsou replikov\u00e1ny), a uzly, klastry a samotn\u00fd projekt \u2014 tuchanka<\/strong> (planeta, kde \u017eij\u00ed krogani).<\/p>\n

<\/p>\n

Nyn\u00ed veden\u00ed povolilo otev\u0159\u00edt projekt pro open source komunitu pod licenc\u00ed MIT<\/a><\/noindex>. README bude brzy p\u0159elo\u017eeno do angli\u010dtiny (proto\u017ee se o\u010dek\u00e1v\u00e1, \u017ee hlavn\u00edmi u\u017eivateli budou v\u00fdvoj\u00e1\u0159i Pacemaker a PostgreSQL), a starou ruskou verzi README jsem se rozhodl zpracovat (\u010d\u00e1ste\u010dn\u011b) ve form\u011b tohoto \u010dl\u00e1nku.<\/p>\n

<\/p>\n

\"Modelov\u00e1n\u00ed<\/p>\n

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

Klastury se implementuj\u00ed na virtu\u00e1ln\u00edch stroj\u00edch VirtualBox<\/a><\/noindex>. Celkem bude nasazeno 12 virtu\u00e1ln\u00edch stroj\u016f (celkem 36GiB), kter\u00e9 tvo\u0159\u00ed 4 vysoce dostupn\u00e9 klastry (r\u016fzn\u00e9 varianty). Prvn\u00ed dva klastry se skl\u00e1daj\u00ed ze dvou server\u016f PostgreSQL, kter\u00e9 jsou um\u00edst\u011bny v r\u016fzn\u00fdch datov\u00fdch centrech, a jednoho spole\u010dn\u00e9ho serveru witness<\/em> s quorum device<\/strong> (um\u00edst\u011bn\u00e9ho na levn\u00e9m virtu\u00e1ln\u00edm stroji ve t\u0159et\u00edm datov\u00e9m centru), kter\u00fd \u0159e\u0161\u00ed neur\u010ditost 50%\/50%<\/strong>, d\u00e1v\u00e1 sv\u016fj hlas jedn\u00e9 ze stran. T\u0159et\u00ed klastr je ve t\u0159ech datov\u00fdch centrech: jeden master, dva slave, bez quorum device<\/strong>. \u010ctvrt\u00fd klastr se skl\u00e1d\u00e1 ze \u010dty\u0159 server\u016f PostgreSQL, po dvou v datacentru: jeden master a ostatn\u00ed repliky, a tak\u00e9 pou\u017e\u00edv\u00e1 witness<\/em> s quorum device<\/strong>. \u010ctvrt\u00fd zvl\u00e1dne selh\u00e1n\u00ed dvou server\u016f nebo jednoho datacentra. Toto \u0159e\u0161en\u00ed m\u016f\u017ee b\u00fdt v p\u0159\u00edpad\u011b pot\u0159eby \u0161k\u00e1lov\u00e1no na v\u011bt\u0161\u00ed po\u010det replik.<\/p>\n

<\/p>\n

Slu\u017eba p\u0159esn\u00e9ho \u010dasu ntpd<\/a><\/noindex> tak\u00e9 je p\u0159econfugurov\u00e1n pro odolnost, ale pou\u017e\u00edv\u00e1 metodu takzvan\u00e9ho ntpd<\/code> (orphan mode<\/em>). Hlavn\u00ed server witness<\/em> pln\u00ed roli centr\u00e1ln\u00edho NTP serveru, kter\u00fd rozd\u00e1v\u00e1 sv\u016fj \u010das v\u0161em klastr\u016fm a t\u00edm synchronizuje v\u0161echny servery mezi sebou. Pokud witness<\/em> se porouch\u00e1 nebo bude izolov\u00e1n, jeden z server\u016f klastru za\u010dne distribuovat sv\u016fj \u010das (uvnit\u0159 klastru). Pomocn\u00fd cachingov\u00fd HTTP proxy<\/strong> tak\u00e9 je nasazen na witness<\/em>, pomoc\u00ed n\u011bho\u017e maj\u00ed ostatn\u00ed virtu\u00e1ln\u00ed stroje p\u0159\u00edstup k Yum repozit\u00e1\u0159\u016fm. Ve skute\u010dnosti budou takov\u00e9 slu\u017eby, jako p\u0159esn\u00fd \u010das a proxy, pravd\u011bpodobn\u011b um\u00edst\u011bny na vyhrazen\u00fdch serverech, zat\u00edmco v testovac\u00edm prost\u0159ed\u00ed jsou um\u00edst\u011bny na witness<\/em> pouze pro \u00fasporu po\u010dtu virtu\u00e1ln\u00edch stroj\u016f a m\u00edsta.<\/p>\n

<\/p>\n

Verze<\/h1>\n

<\/p>\n

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

<\/p>\n

Struktura klastr\u016f<\/h1>\n

<\/p>\n

V\u0161echny klastry jsou ur\u010deny pro um\u00edst\u011bn\u00ed v n\u011bkolika datacentrech, spojeny do jedn\u00e9 ploch\u00e9 s\u00edt\u011b a m\u011bly by odol\u00e1vat selh\u00e1n\u00ed nebo s\u00ed\u0165ov\u00e9 izolaci jednoho datacentra. Proto nemo\u017en\u00e9<\/strong> je nutn\u00e9 pou\u017e\u00edt pro ochranu p\u0159ed split-brain<\/strong> standardn\u00ed technologii Pacemaker, kter\u00e1 se naz\u00fdv\u00e1 STONITH<\/em> (Shoot The Other Node In The Head) nebo fencing<\/em>. Jej\u00ed podstata: pokud uzly v klastru za\u010dnou m\u00edt podez\u0159en\u00ed, \u017ee s n\u011bjak\u00fdm uzlem je n\u011bco v nepo\u0159\u00e1dku, neodpov\u00edd\u00e1 nebo se chov\u00e1 nespr\u00e1vn\u011b, vynut\u00ed si jeho odpojen\u00ed pomoc\u00ed \"vn\u011bj\u0161\u00edch\" za\u0159\u00edzen\u00ed, jako nap\u0159\u00edklad \u0159\u00eddic\u00ed karta IPMI nebo UPS. Ale to bude fungovat pouze v p\u0159\u00edpadech, kdy p\u0159i jednostrann\u00e9m selh\u00e1n\u00ed serveru IPMI nebo UPS nad\u00e1le funguj\u00ed. Zde je pl\u00e1nov\u00e1na ochrana proti mnohem katastrof\u00e1ln\u011bj\u0161\u00edmu selh\u00e1n\u00ed, kdy sel\u017ee (nap\u0159\u00edklad se odpoj\u00ed od proudu) cel\u00e9 datacentrum. A p\u0159i takov\u00e9m selh\u00e1n\u00ed v\u0161echna stonith<\/em>-za\u0159\u00edzen\u00ed (IPMI, UPS atd.) tak\u00e9 nebudou fungovat.<\/p>\n

<\/p>\n

M\u00edsto toho je z\u00e1kladem syst\u00e9mu my\u0161lenka kv\u00f3ra. V\u0161echny uzly maj\u00ed hlas a pracovat mohou pouze ty, kter\u00e9 vid\u00ed v\u00edce ne\u017e polovinu v\u0161ech uzl\u016f. Toto mno\u017estv\u00ed \"polovina + 1\" se naz\u00fdv\u00e1 kv\u00f3rum<\/strong>. Pokud kv\u00f3rum nen\u00ed dosa\u017eeno, uzel rozhodne, \u017ee se nach\u00e1z\u00ed v s\u00ed\u0165ov\u00e9 izolaci a mus\u00ed odpojit sv\u00e9 zdroje, tj. to je takov\u00e1 ochrana p\u0159ed split-brain<\/strong>. Pokud software, kter\u00fd za takov\u00e9 chov\u00e1n\u00ed odpov\u00edd\u00e1, nefunguje, m\u011bl by se spustit watchdog, nap\u0159\u00edklad na b\u00e1zi IPMI.<\/p>\n

<\/p>\n

Pokud je po\u010det uzl\u016f sud\u00fd (klastr ve dvou datov\u00fdch centrech), m\u016f\u017ee nastat takzvan\u00e1 neur\u010ditost 50%\/50%<\/strong> (pades\u00e1t na pades\u00e1t<\/em>), kdy s\u00ed\u0165ov\u00e1 izolace d\u011bl\u00ed klastr p\u0159esn\u011b na polovinu. Proto se pro sud\u00fd po\u010det uzl\u016f p\u0159id\u00e1v\u00e1 quorum device<\/strong> \u2014 nen\u00e1ro\u010dn\u00fd d\u00e9mon, kter\u00fd m\u016f\u017ee b\u00fdt spu\u0161t\u011bn na nejlevn\u011bj\u0161\u00edm virtu\u00e1ln\u00edm stroji ve t\u0159et\u00edm datov\u00e9m centru. D\u00e1v\u00e1 sv\u016fj hlas jednomu ze segment\u016f (kter\u00fd vid\u00ed), a t\u00edm roz\u0159e\u0161\u00ed neur\u010ditost 50%\/50%. Server, na kter\u00e9m bude spu\u0161t\u011bn quorum device, jsem nazval witness<\/em> (terminologie z repmgr, l\u00edb\u00ed se mi).<\/p>\n

<\/p>\n

Zdroje mohou p\u0159ech\u00e1zet z m\u00edsta na m\u00edsto, nap\u0159\u00edklad z nefunk\u010dn\u00edch server\u016f na funk\u010dn\u00ed, nebo na p\u0159\u00edkaz administr\u00e1tor\u016f. Aby klienti v\u011bd\u011bli, kde se nach\u00e1zej\u00ed pot\u0159ebn\u00e9 zdroje (kam se p\u0159ipojit?), pou\u017e\u00edvaj\u00ed se plovouc\u00ed IP<\/em> (float IP<\/strong>). To jsou IP, kter\u00e9 Pacemaker m\u016f\u017ee p\u0159esouvat mezi uzly (v\u0161echno se nach\u00e1z\u00ed v ploch\u00e9 s\u00edti). Ka\u017ed\u00e1 z nich symbolizuje zdroj (slu\u017ebu) a bude se nach\u00e1zet tam, kam je t\u0159eba se p\u0159ipojit, abyste z\u00edskali p\u0159\u00edstup k t\u00e9to slu\u017eb\u011b (v na\u0161em p\u0159\u00edpad\u011b k DB).<\/p>\n

<\/p>\n

Tuchanka1 (sch\u00e9ma s t\u011bsn\u011bn\u00edm)<\/h2>\n

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelov\u00e1n\u00ed<\/p>\n

<\/p>\n

My\u0161lenka byla v tom, \u017ee m\u00e1me mnoho mal\u00fdch datab\u00e1z\u00ed s n\u00edzkou z\u00e1t\u011b\u017e\u00ed, pro kter\u00e9 nen\u00ed v\u00fdhodn\u00e9 udr\u017eovat vyhrazen\u00fd slave server v re\u017eimu hot standby pro read only transakce (nen\u00ed t\u0159eba takov\u00e9ho pl\u00fdtv\u00e1n\u00ed zdroji).<\/p>\n

<\/p>\n

V ka\u017ed\u00e9m datov\u00e9m centru je jeden server. Na ka\u017ed\u00e9m serveru jsou dv\u011b instance PostgreSQL (v terminologii PostgreSQL se naz\u00fdvaj\u00ed klastr, ale abych p\u0159ede\u0161el z\u00e1m\u011bn\u011b, budu je naz\u00fdvat instancemi (podobn\u011b jako u dal\u0161\u00edch DB), a klastr ozna\u010d\u00edm pouze pro klastry Pacemaker). Jedna instance funguje v re\u017eimu master a pouze ona poskytuje slu\u017eby (pouze na n\u00ed sm\u011b\u0159uje float IP). Druh\u00e1 instance funguje jako slave pro druh\u00e9 datov\u00e9 centrum a slu\u017eby poskytne pouze tehdy, pokud jej\u00ed master sel\u017ee. Proto\u017ee v\u011bt\u0161inu \u010dasu poskytuje slu\u017eby (prov\u00e1d\u00ed dotazy) pouze jedna z obou instanc\u00ed (master), jsou v\u0161echny zdroje serveru optimalizov\u00e1ny na master (vy\u010dle\u0148uje se pam\u011b\u0165 pro cache shared_buffers atd.), ale tak, aby i na druhou instanci zb\u00fdvalo dostatek zdroj\u016f (i pro suboptim\u00e1ln\u00ed funkci p\u0159es cache souborov\u00e9ho syst\u00e9mu) pro p\u0159\u00edpad selh\u00e1n\u00ed jednoho z datov\u00fdch center. Slave neposkytuje slu\u017eby (neprov\u00e1d\u00ed read only dotazy) p\u0159i norm\u00e1ln\u00edm chodu klastru, aby nedoch\u00e1zelo k boji o zdroje s masterem na t\u00e9\u017ee ma\u0161in\u011b.<\/p>\n

<\/p>\n

V p\u0159\u00edpad\u011b dvou uzl\u016f je dostupnost mo\u017en\u00e1 pouze p\u0159i asynchronn\u00ed replikaci, proto\u017ee p\u0159i synchronn\u00ed selh\u00e1n\u00ed slava dojde k zastaven\u00ed mastera.<\/p>\n

<\/p>\n

Selh\u00e1n\u00ed witness<\/h3>\n

<\/p>\n

\"Modelov\u00e1n\u00ed<\/p>\n

<\/p>\n

Selh\u00e1n\u00ed witness (quorum device<\/em>) se budu zab\u00fdvat pouze u klastru Tuchanka1, u v\u0161ech ostatn\u00edch bude stejn\u00fd p\u0159\u00edb\u011bh. P\u0159i selh\u00e1n\u00ed witness ve struktu\u0159e klastru se nic nezm\u011bn\u00ed, v\u0161echno bude fungovat tak, jak fungovalo. Ale kvorum se stane 2 z 3, a proto jak\u00e9koliv dal\u0161\u00ed selh\u00e1n\u00ed se stane fat\u00e1ln\u00ed pro klastr. Budeme muset urgentn\u011b opravit.<\/p>\n

<\/p>\n

Selh\u00e1n\u00ed Tuchanka1<\/h3>\n

<\/p>\n

\"Modelov\u00e1n\u00ed<\/p>\n

<\/p>\n

Selh\u00e1n\u00ed jednoho z datov\u00fdch center pro Tuchanka1. V tomto p\u0159\u00edpad\u011b witness<\/em> dod\u00e1v\u00e1 sv\u016fj hlas druh\u00e9mu uzlu ve druh\u00e9m datov\u00e9m centru. Tam se b\u00fdval\u00fd slave m\u011bn\u00ed na mastera, tak\u017ee na jednom serveru pracuj\u00ed oba masterov\u00e9 a na n\u011b sm\u011b\u0159uj\u00ed oba jejich float IP.<\/p>\n

<\/p>\n

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

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelov\u00e1n\u00ed<\/p>\n

<\/p>\n

Klasick\u00e9 sch\u00e9ma ze dvou uzl\u016f. Na jednom b\u011b\u017e\u00ed master, na druh\u00e9m slave. Oba mohou prov\u00e1d\u011bt dotazy (slave pouze read only), proto na obou sm\u011b\u0159uj\u00ed float IP: krogan2 \u2014 na mastera, krogan2s1 \u2014 na slava. Dostupnost bude jak u mastera, tak u slava.<\/p>\n

<\/p>\n

V p\u0159\u00edpad\u011b dvou uzl\u016f je dostupnost mo\u017en\u00e1 pouze p\u0159i asynchronn\u00ed replikaci, proto\u017ee p\u0159i synchronn\u00ed selh\u00e1n\u00ed slava dojde k zastaven\u00ed mastera.<\/p>\n

<\/p>\n

Selh\u00e1n\u00ed Tuchanka2<\/h3>\n

<\/p>\n

\"Modelov\u00e1n\u00ed<\/p>\n

<\/p>\n

P\u0159i selh\u00e1n\u00ed jednoho z datov\u00fdch center witness<\/em> hlasuje pro druh\u00fd. Na jedin\u00e9m funk\u010dn\u00edm datov\u00e9m centru bude spu\u0161t\u011bn master a na n\u011bj budou ukazovat oba float IP: master a slave. Samoz\u0159ejm\u011b, instance mus\u00ed b\u00fdt nakonfigurov\u00e1na tak, aby m\u011bla dostatek zdroj\u016f (limit\u016f p\u0159ipojen\u00ed atd.) pro sou\u010dasn\u00e9 zpracov\u00e1n\u00ed v\u0161ech p\u0159ipojen\u00ed a po\u017eadavk\u016f jak od master, tak od slave float IP. To znamen\u00e1, \u017ee p\u0159i norm\u00e1ln\u00edm fungov\u00e1n\u00ed by m\u011bla m\u00edt dostate\u010dnou rezervu limit\u016f.<\/p>\n

<\/p>\n

Tuchanka4 (mnoho otrok\u016f)<\/h2>\n

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelov\u00e1n\u00ed<\/p>\n

<\/p>\n

U\u017e jin\u00fd extr\u00e9m. Existuj\u00ed DB, na kter\u00e9 sm\u011b\u0159uje velmi mnoho read-only dotaz\u016f (typick\u00fd p\u0159\u00edpad vysoce zat\u00ed\u017een\u00e9 str\u00e1nky). Tuchanka4 \u2014 to je situace, kdy m\u016f\u017ee b\u00fdt t\u0159i nebo v\u00edce otrok\u016f pro zpracov\u00e1n\u00ed takov\u00fdch dotaz\u016f, ale p\u0159esto ne p\u0159\u00edli\u0161 mnoho. P\u0159i velmi velk\u00e9m po\u010dtu otrok\u016f bude t\u0159eba vymyslet hierarchick\u00fd syst\u00e9m replikace. V minim\u00e1ln\u00edm p\u0159\u00edpad\u011b (na obr\u00e1zku) se v ka\u017ed\u00e9m ze dvou datov\u00fdch center nach\u00e1z\u00ed dva servery, na ka\u017ed\u00e9m z nich s jednou instanc\u00ed PostgreSQL.<\/p>\n

<\/p>\n

Dal\u0161\u00ed zvl\u00e1\u0161tnost\u00ed tohoto sch\u00e9matu je, \u017ee zde ji\u017e m\u016f\u017eeme zorganizovat jednu synchronn\u00ed replikaci. Je nastavena tak, aby replikovala, pokud mo\u017eno, do jin\u00e9ho datov\u00e9ho centra a ne na replikaci ve stejn\u00e9m datov\u00e9m centru, kde je i master. Na master a na ka\u017ed\u00fd slave ukazuje float IP. Opr\u00e1vn\u011bn\u011b, mezi otroky bude t\u0159eba prov\u00e1d\u011bt vyva\u017eov\u00e1n\u00ed dotaz\u016f n\u011bjak\u00fdm sql proxy<\/em>, nap\u0159\u00edklad, na stran\u011b klienta. R\u016fzn\u00e9mu typu klient\u016f m\u016f\u017ee b\u00fdt pot\u0159eba r\u016fzn\u00fd typ sql proxy<\/em>, a pouze v\u00fdvoj\u00e1\u0159i klient\u016f v\u011bd\u00ed, kdo jak\u00fd pot\u0159ebuje. Tato funk\u010dnost m\u016f\u017ee b\u00fdt realizov\u00e1na jak extern\u00edm d\u00e9monem, tak knihovnou klienta (connection pool), atd. V\u0161e toto p\u0159esahuje r\u00e1mec t\u00e9matu dostupn\u00e9ho datab\u00e1zov\u00e9ho clustera (dostupnost SQL proxy<\/em> bude mo\u017en\u00e9 realizovat nez\u00e1visle, spolu s dostupnost\u00ed klienta).<\/p>\n

<\/p>\n

Selh\u00e1n\u00ed Tuchanka4<\/h3>\n

<\/p>\n

\"Modelov\u00e1n\u00ed<\/p>\n

<\/p>\n

P\u0159i selh\u00e1n\u00ed jednoho datov\u00e9ho centra (tj. dvou server\u016f) sv\u011bdek hlasuje pro druh\u00fd. V d\u016fsledku toho ve druh\u00e9m datov\u00e9m centru pracuj\u00ed dva servery: na jednom b\u011b\u017e\u00ed master, a na n\u011bj ukazuje master float IP (pro p\u0159\u00edjem read-write dotaz\u016f); a na druh\u00e9m serveru b\u011b\u017e\u00ed slave se synchronn\u00ed replikac\u00ed, a na n\u011bj ukazuje jeden z otrock\u00fdch float IP (pro read-only dotazy).<\/p>\n

<\/p>\n

Prvn\u00ed, co je t\u0159eba poznamenat: pracovn\u00ed otrock\u00fd float IP nebude pro v\u0161echny, ale pouze pro jeden. A pro spr\u00e1vnou funkci s n\u00edm bude t\u0159eba, aby sql proxy<\/em> p\u0159esm\u011broval v\u0161echny po\u017eadavky na jedinou zb\u00fdvaj\u00edc\u00ed float IP; a pokud sql proxy<\/em> ne, je mo\u017en\u00e9 uv\u00e9st v\u0161echny float IP slave odd\u011blen\u00e9 \u010d\u00e1rkou v URL pro p\u0159ipojen\u00ed. V takov\u00e9m p\u0159\u00edpad\u011b bude libpq<\/em> p\u0159ipojen\u00ed provedeno k prvn\u00edmu pracovn\u00edm IP, jak je to nastaveno v syst\u00e9mu automatick\u00e9ho testov\u00e1n\u00ed. Mo\u017en\u00e1, \u017ee v jin\u00fdch knihovn\u00e1ch, jako je JDBC, to tak fungovat nebude a bude pot\u0159ebn\u00e9 sql proxy<\/em>. Je to tak ud\u011bl\u00e1no, proto\u017ee pro slave float IP je nastavena prohibice na sou\u010dasn\u00e9 zv\u00fd\u0161en\u00ed na jednom serveru, aby se rovnom\u011brn\u011b rozlo\u017eily na slave servery, pokud jich pracuje n\u011bkolik.<\/p>\n

<\/p>\n

Druh\u00e9: i v p\u0159\u00edpad\u011b selh\u00e1n\u00ed datacentra bude zachov\u00e1na synchronn\u00ed replikace. A i kdy\u017e dojde ke sekund\u00e1rn\u00edmu selh\u00e1n\u00ed, tedy kdy\u017e v zb\u00fdvaj\u00edc\u00edm datacentru sel\u017ee jeden ze dvou server\u016f, cluster sice p\u0159estane poskytovat slu\u017eby, ale i tak si uchov\u00e1 informace o v\u0161ech potvrzen\u00fdch transakc\u00edch, na kter\u00e9 poskytl potvrzen\u00ed o commitu (nebude doch\u00e1zet ke ztr\u00e1t\u011b informac\u00ed p\u0159i sekund\u00e1rn\u00edm selh\u00e1n\u00ed).<\/p>\n

<\/p>\n

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

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelov\u00e1n\u00ed<\/p>\n

<\/p>\n

To je cluster pro situaci, kdy jsou t\u0159i pln\u011b funguj\u00edc\u00ed datacentra, v ka\u017ed\u00e9m z nich\u017e je pln\u011b funk\u010dn\u00ed datab\u00e1zov\u00fd server. V tomto p\u0159\u00edpad\u011b quorum device<\/em> nen\u00ed pot\u0159eba. V jednom datacentru pracuje master, v dvou dal\u0161\u00edch \u2014 slaves. Replikace je synchronn\u00ed, typu ANY (slave1, slave2), tedy klientovi p\u0159ijde potvrzen\u00ed commitu, kdy\u017e jak\u00fdkoli ze slave prvn\u00edch odpov\u00ed, \u017ee p\u0159ijal commit. Na zdroje ukazuje jeden float IP pro mastera a dva pro slaves. Na rozd\u00edl od Tuchanka4 jsou v\u0161echny t\u0159i float IP odoln\u00e9 v\u016f\u010di v\u00fdpadk\u016fm. Pro vyva\u017eov\u00e1n\u00ed read-only SQL dotaz\u016f lze pou\u017e\u00edt sql proxy<\/em> (s individu\u00e1ln\u00ed odolnost\u00ed v\u016f\u010di v\u00fdpadk\u016fm), nebo prvn\u00ed polovin\u011b klient\u016f p\u0159id\u011blit jeden slave float IP a druh\u00e9 polovin\u011b \u2014 druh\u00fd.<\/p>\n

<\/p>\n

Selh\u00e1n\u00ed Tuchanka3<\/h3>\n

<\/p>\n

\"Modelov\u00e1n\u00ed<\/p>\n

<\/p>\n

P\u0159i selh\u00e1n\u00ed jednoho datacentra z\u016fstanou dv\u011b. V jednom je master a float IP od mastera, ve druh\u00e9m \u2014 slave a oba slave float IP (na instance mus\u00ed b\u00fdt dvojn\u00e1sobek zdroj\u016f, aby p\u0159ijal v\u0161echna p\u0159ipojen\u00ed z obou slave float IP). Mezi masterem a slaven prob\u00edh\u00e1 synchronn\u00ed replikace. Tak\u00e9 cluster uchov\u00e1 informace o potvrzen\u00fdch a schv\u00e1len\u00fdch transakc\u00edch (nebude doch\u00e1zet ke ztr\u00e1t\u011b informac\u00ed) v p\u0159\u00edpad\u011b zni\u010den\u00ed dvou datacenter (pokud nebyla zni\u010dena sou\u010dasn\u011b).<\/p>\n

<\/p>\n

Podrobn\u00fd popis souborov\u00e9 struktury a nasazen\u00ed jsem se rozhodl nezahrnout. Kdo se chce zab\u00fdvat detaily, m\u016f\u017ee si to p\u0159e\u010d\u00edst v README. Uv\u00e1d\u00edm pouze popis automatick\u00e9ho testov\u00e1n\u00ed.<\/em><\/p>\n

<\/p>\n

Syst\u00e9m automatick\u00e9ho testov\u00e1n\u00ed<\/h1>\n

<\/p>\n

Pro ov\u011b\u0159en\u00ed odolnosti klastr\u016f s simulac\u00ed r\u016fzn\u00fdch poruch byl vytvo\u0159en syst\u00e9m automatick\u00e9ho testov\u00e1n\u00ed. Spou\u0161t\u00ed se skriptem test\/failure<\/code>. Skript m\u016f\u017ee p\u0159ij\u00edmat jako parametry \u010d\u00edsla klastr\u016f, kter\u00e9 chcete testovat. Nap\u0159\u00edklad tento p\u0159\u00edkaz:<\/p>\n

<\/p>\n

test\/failure 2 3<\/code><\/pre>\n
<\/p>\n
bude testovat pouze druh\u00fd a t\u0159et\u00ed klastr. Pokud parametry nejsou uvedeny, budou testov\u00e1ny v\u0161echny klastry. V\u0161echny klastry se testuj\u00ed paraleln\u011b a v\u00fdsledek se zobrazuje na panelu tmux. Tmux pou\u017e\u00edv\u00e1 vyhrazen\u00fd tmux server, tak\u017ee skript lze spustit z b\u011b\u017en\u00e9ho tmux, co\u017e vytvo\u0159\u00ed vno\u0159en\u00fd tmux. Doporu\u010duji pou\u017e\u00edvat termin\u00e1l v \u0161irok\u00e9m okn\u011b a s mal\u00fdm p\u00edsmem. P\u0159ed zah\u00e1jen\u00edm testov\u00e1n\u00ed se v\u0161echny virtu\u00e1ln\u00ed stroje vr\u00e1t\u00ed na sn\u00edmek na okam\u017eik dokon\u010den\u00ed skriptu. setup<\/code>.<\/p>\n
<\/p>\n
\"Modelov\u00e1n\u00ed<\/p>\n
<\/p>\n
Termin\u00e1l je rozd\u011blen na sloupce podle po\u010dtu testovan\u00fdch klastr\u016f, defaultn\u011b (na screenshotu) jich je \u010dty\u0159icet. Obsah sloupc\u016f pop\u00ed\u0161u na p\u0159\u00edkladu Tuchanka2. Panely na screenshotu jsou o\u010d\u00edslov\u00e1ny:<\/p>\n
<\/p>\n
    \n
  1. Zde se zobrazuje statistika test\u016f. Sloupce:\n