{"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\/pl\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","title":{"rendered":"Modelowanie odpornych klastr\u00f3w bazuj\u0105cych na PostgreSQL i Pacemaker","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Wprowadzenie<\/h1>\n

<\/p>\n

Jaki\u015b czas temu postawiono przede mn\u0105 zadanie opracowania klastra o wysokiej dost\u0119pno\u015bci dla PostgreSQL<\/a><\/noindex>, dzia\u0142aj\u0105cego w kilku centrach danych po\u0142\u0105czonych \u015bwiat\u0142owodem w obr\u0119bie jednego miasta, zdolnego przetrwa\u0107 awari\u0119 (np. wy\u0142\u0105czenie zasilania) jednego z centr\u00f3w danych. Jako oprogramowanie odpowiedzialne za wysok\u0105 dost\u0119pno\u015b\u0107 wybra\u0142em Pacemaker<\/a><\/noindex>, poniewa\u017c to oficjalne rozwi\u0105zanie od RedHat do tworzenia klastr\u00f3w o wysokiej dost\u0119pno\u015bci. Jego zalet\u0105 jest wsparcie, jakie zapewnia RedHat, oraz to, \u017ce jest to rozwi\u0105zanie uniwersalne (modu\u0142owe). Dzi\u0119ki temu mo\u017cna zapewni\u0107 wysok\u0105 dost\u0119pno\u015b\u0107 nie tylko dla PostgreSQL, ale tak\u017ce dla innych us\u0142ug, wykorzystuj\u0105c standardowe modu\u0142y lub tworz\u0105c je wed\u0142ug specyficznych potrzeb.<\/p>\n

<\/p>\n

Do tego rozwi\u0105zania pojawi\u0142o si\u0119 zasadnicze pytanie: jak bardzo odporny b\u0119dzie klaster o wysokiej dost\u0119pno\u015bci? Aby to zbada\u0107, opracowa\u0142em testowe \u015brodowisko, kt\u00f3re imituje r\u00f3\u017cne awarie w w\u0119z\u0142ach klastra, czeka na przywr\u00f3cenie sprawno\u015bci, naprawia uszkodzony w\u0119ze\u0142 i kontynuuje testowanie w cyklu. Pocz\u0105tkowo projekt nosi\u0142 nazw\u0119 hapgsql, ale z czasem znudzi\u0142o mi si\u0119 to imi\u0119 z jedn\u0105 samog\u0142osk\u0105. Dlatego odpornym bazom danych (i przypisanym do nich float IP) zacz\u0105\u0142em nadawa\u0107 nazw\u0119 krogan<\/strong> (posta\u0107 z gry komputerowej, w kt\u00f3rej wszystkie wa\u017cne organy s\u0105 zduplikowane), natomiast w\u0119z\u0142y, klastry i sam projekt nazwano tuchanka<\/strong> (planeta, na kt\u00f3rej \u017cyj\u0105 kroganie).<\/p>\n

<\/p>\n

Obecnie kierownictwo zatwierdzi\u0142o otwarcie projektu dla spo\u0142eczno\u015bci open source na licencji MIT<\/a><\/noindex>. README wkr\u00f3tce zostanie przet\u0142umaczone na j\u0119zyk angielski (poniewa\u017c oczekuje si\u0119, \u017ce g\u0142\u00f3wnymi u\u017cytkownikami b\u0119d\u0105 programi\u015bci Pacemaker i PostgreSQL), a stary rosyjski wariant README postanowi\u0142em opracowa\u0107 (cz\u0119\u015bciowo) w formie tego artyku\u0142u.<\/p>\n

<\/p>\n

\"Modelowanie<\/p>\n

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

Klastry s\u0105 uruchamiane na wirtualnych maszynach VirtualBox<\/a><\/noindex>. \u0141\u0105cznie zostanie uruchomionych 12 wirtualnych maszyn (w sumie 36GiB), kt\u00f3re utworz\u0105 4 klastry o wysokiej dost\u0119pno\u015bci (r\u00f3\u017cne opcje). Dwa pierwsze klastry sk\u0142adaj\u0105 si\u0119 z dw\u00f3ch serwer\u00f3w PostgreSQL, kt\u00f3re s\u0105 rozmieszczone w r\u00f3\u017cnych centrach danych oraz wsp\u00f3lnego serwera witness<\/em> c urz\u0105dzenia quorum<\/strong> (umieszczonego na taniej wirtualnej maszynie w trzecim centrum danych), kt\u00f3ry rozstrzyga niepewno\u015b\u0107 50%\/50%<\/strong>, oddaj\u0105c sw\u00f3j g\u0142os jednej ze stron. Trzeci klaster znajduje si\u0119 w trzech centrach danych: jeden g\u0142\u00f3wny, dwa podrz\u0119dne, bez urz\u0105dzenia quorum<\/strong>. Czwarty klaster sk\u0142ada si\u0119 z czterech serwer\u00f3w PostgreSQL, po dwa na centrum danych: jeden g\u0142\u00f3wny, pozosta\u0142e replikami, i r\u00f3wnie\u017c wykorzystuje witness<\/em> c urz\u0105dzenia quorum<\/strong>. Czwarty wytrzymuje awari\u0119 dw\u00f3ch serwer\u00f3w lub jednego centrum danych. To rozwi\u0105zanie mo\u017ce by\u0107 w razie potrzeby skalowane na wi\u0119ksz\u0105 liczb\u0119 replik.<\/p>\n

<\/p>\n

Us\u0142uga dok\u0142adnego czasu ntpd<\/a><\/noindex> r\u00f3wnie\u017c zosta\u0142 przystosowany do awaryjno\u015bci, ale tam stosuje si\u0119 metod\u0119 samego ntpd<\/code> (orphan mode<\/em>). Og\u00f3lny serwer witness<\/em> pe\u0142ni rol\u0119 centralnego serwera NTP, rozprowadzaj\u0105c sw\u00f3j czas wszystkim klastrom, tym samym synchronizuj\u0105c wszystkie serwery ze sob\u0105. Je\u015bli witness<\/em> wyjdzie z u\u017cytku lub zostanie odizolowany, wtedy sw\u00f3j czas zacznie rozprowadza\u0107 jeden z serwer\u00f3w klastra (wewn\u0105trz klastra). Pomocniczy pami\u0119ciowy HTTP proxy<\/strong> r\u00f3wnie\u017c zosta\u0142 uruchomiony na witness<\/em>, dzi\u0119ki niemu pozosta\u0142e maszyny wirtualne maj\u0105 dost\u0119p do repozytori\u00f3w Yum. W rzeczywisto\u015bci takie us\u0142ugi, jak dok\u0142adny czas i proxy, z pewno\u015bci\u0105 b\u0119d\u0105 umieszczone na dedykowanych serwerach, a w te\u015bcie s\u0105 usytuowane na witness<\/em> tylko dla oszcz\u0119dno\u015bci liczby maszyn wirtualnych i miejsca.<\/p>\n

<\/p>\n

Wersje<\/h1>\n

<\/p>\n

v0. Dzia\u0142a z CentOS 7 i PostgreSQL 11 na VirtualBox 6.1.<\/p>\n

<\/p>\n

Struktura klastr\u00f3w<\/h1>\n

<\/p>\n

Wszystkie klastry s\u0105 przeznaczone do umieszczania w kilku centrach danych, po\u0142\u0105czone w jedn\u0105 p\u0142ask\u0105 sie\u0107 i musz\u0105 wytrzyma\u0107 awari\u0119 lub izolacj\u0119 sieci jednego centrum danych. Dlatego niemo\u017cliwe<\/strong> u\u017cycie w celu ochrony przed split-brain<\/strong> standardowej technologii Pacemaker, kt\u00f3ra nazywa si\u0119 STONITH<\/em> (Shoot The Other Node In The Head) albo fencing<\/em>. Jej istota polega na tym, \u017ce je\u015bli w\u0119z\u0142y w klastrze zaczynaj\u0105 podejrzewa\u0107, \u017ce z kt\u00f3rym\u015b w\u0119z\u0142em dzieje si\u0119 co\u015b z\u0142ego, on nie odpowiada lub dzia\u0142a nieprawid\u0142owo, to skutecznie go od\u0142\u0105czaj\u0105 przez \u201ezewn\u0119trzne\u201d urz\u0105dzenia, takie jak kontroler IPMI lub UPS. Ale to zadzia\u0142a tylko w przypadkach, gdy przy jednorazowej awarii serwera IPMI lub UPS nadal b\u0119d\u0105 dzia\u0142a\u0107. Tutaj planowana jest ochrona przed znacznie bardziej katastrofaln\u0105 awari\u0105, gdy odmawia (na przyk\u0142ad zostaje odci\u0119te zasilanie) ca\u0142e centrum danych. A przy takiej awarii wszystkie stonith<\/em>-urz\u0105dzenia (IPMI, UPS itp.) r\u00f3wnie\u017c nie b\u0119d\u0105 dzia\u0142a\u0107.<\/p>\n

<\/p>\n

Zamiast tego podstaw\u0105 systemu jest idea kworum. Wszystkie w\u0119z\u0142y maj\u0105 g\u0142os i mog\u0105 pracowa\u0107 tylko te, kt\u00f3re widz\u0105 wi\u0119cej ni\u017c po\u0142ow\u0119 wszystkich w\u0119z\u0142\u00f3w. Ta liczba \u201epo\u0142owa+1\u201d nazywa si\u0119 kworum<\/strong>. Je\u015bli quorum nie zostanie osi\u0105gni\u0119ty, w\u0119ze\u0142 uznaje, \u017ce znajduje si\u0119 w izolacji sieciowej i powinien wy\u0142\u0105czy\u0107 swoje zasoby, tzn. jest to taka ochrona przed split-brain<\/strong>. Je\u015bli oprogramowanie odpowiedzialne za takie zachowanie nie dzia\u0142a, powinien zadzia\u0142a\u0107 watchdog, na przyk\u0142ad oparty na IPMI.<\/p>\n

<\/p>\n

Je\u015bli liczba w\u0119z\u0142\u00f3w jest parzysta (klaster w dw\u00f3ch centrach danych), mo\u017ce wyst\u0105pi\u0107 tak zwana niejednoznaczno\u015b\u0107 50%\/50%<\/strong> (50-50<\/em>), kiedy izolacja sieciowa dzieli klaster dok\u0142adnie na p\u00f3\u0142. Dlatego dla parzystej liczby w\u0119z\u0142\u00f3w dodaje si\u0119 urz\u0105dzenia quorum<\/strong> \u2014 ma\u0142o wymagaj\u0105cy demon, kt\u00f3ry mo\u017ce by\u0107 uruchomiony na najta\u0144szej wirtualce w trzecim centrum danych. Daje sw\u00f3j g\u0142os jednemu z segment\u00f3w (kt\u00f3ry widzi) i tym samym rozwi\u0105zuje niejednoznaczno\u015b\u0107 50%\/50%. Serwer, na kt\u00f3rym zostanie uruchomione urz\u0105dzenie quorum, nazwa\u0142em witness<\/em> (terminologia z repmgr, podoba mi si\u0119).<\/p>\n

<\/p>\n

Zasoby mog\u0105 przemieszcza\u0107 si\u0119 z miejsca na miejsce, na przyk\u0142ad z uszkodzonych serwer\u00f3w na sprawne, lub na polecenie administrator\u00f3w. Aby klienci wiedzieli, gdzie znajduj\u0105 si\u0119 potrzebne im zasoby (gdzie si\u0119 pod\u0142\u0105czy\u0107?), u\u017cywane s\u0105 p\u0142ywaj\u0105ce IP<\/em> (float IP<\/strong>). To s\u0105 IP, kt\u00f3re Pacemaker mo\u017ce przenosi\u0107 pomi\u0119dzy w\u0119z\u0142ami (wszystko znajduje si\u0119 w p\u0142askiej sieci). Ka\u017cdy z nich symbolizuje zas\u00f3b (us\u0142ug\u0119) i b\u0119dzie znajdowa\u0107 si\u0119 tam, gdzie nale\u017cy si\u0119 pod\u0142\u0105czy\u0107, aby uzyska\u0107 dost\u0119p do tej us\u0142ugi (w naszym przypadku do bazy danych).<\/p>\n

<\/p>\n

Tuchanka1 (schemat ze spr\u0119\u017ceniem)<\/h2>\n

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelowanie<\/p>\n

<\/p>\n

Pomys\u0142 polega\u0142 na tym, \u017ce mamy wiele ma\u0142ych baz danych o niskim obci\u0105\u017ceniu, dla kt\u00f3rych nieop\u0142acalne jest utrzymywanie wydzielonego serwera slave w trybie hot standby dla transakcji tylko do odczytu (brak potrzeby takiego marnotrawstwa zasob\u00f3w).<\/p>\n

<\/p>\n

W ka\u017cdym centrum danych znajduje si\u0119 jeden serwer. Na ka\u017cdym serwerze s\u0105 dwa instancje PostgreSQL (w terminologii PostgreSQL nazywane s\u0105 one klastrami, ale dla unikni\u0119cia zamieszania b\u0119d\u0119 je nazywa\u0142 instancjami, a klastry Pacemaker klastry). Jedna instancja dzia\u0142a w trybie master, i tylko ona \u015bwiadczy us\u0142ugi (tylko na ni\u0105 prowadzi float IP). Druga instancja dzia\u0142a jako slave dla drugiego centrum danych i b\u0119dzie \u015bwiadczy\u0107 us\u0142ugi tylko w przypadku awarii swojego mastera. Poniewa\u017c wi\u0119ksz\u0105 cz\u0119\u015b\u0107 czasu us\u0142ugi (wykonywanie zapyta\u0144) b\u0119dzie \u015bwiadczy\u0107 tylko jedna instancja z dw\u00f3ch (master), wszystkie zasoby serwera s\u0105 optymalizowane dla mastera (przydzielana jest pami\u0119\u0107 na bufor cache shared_buffers itd.), ale tak, aby na drug\u0105 instancj\u0119 tak\u017ce wystarczy\u0142o zasob\u00f3w (nawet do pracy w trybie nieoptymalnym przez cache systemu plik\u00f3w) na wypadek awarii jednego z centr\u00f3w danych. Slave nie \u015bwiadczy us\u0142ug (nie wykonuje zapyta\u0144 typu read only) przy normalnej pracy klastra, aby nie dosz\u0142o do walki o zasoby z masterem na tej samej maszynie.<\/p>\n

<\/p>\n

W przypadku dw\u00f3ch w\u0119z\u0142\u00f3w odporno\u015b\u0107 na awarie jest mo\u017cliwa tylko przy asynchronicznej replikacji, poniewa\u017c przy synchronizowanej awaria slave'a spowoduje zatrzymanie mastera.<\/p>\n

<\/p>\n

Awaria witness<\/h3>\n

<\/p>\n

\"Modelowanie<\/p>\n

<\/p>\n

Awaria witness (urz\u0105dzenia quorum<\/em>) rozwa\u017c\u0119 tylko dla klastra Tuchanka1, w przypadku wszystkich pozosta\u0142ych b\u0119dzie ta sama historia. Przy awarii witness w strukturze klastra nic si\u0119 nie zmieni, wszystko b\u0119dzie dzia\u0142a\u0142o tak, jak dot\u0105d. Ale kworum stanie si\u0119 r\u00f3wne 2 z 3, i dlatego ka\u017cda kolejna awaria b\u0119dzie fatalna dla klastra. I tak czy inaczej trzeba b\u0119dzie szybko naprawi\u0107.<\/p>\n

<\/p>\n

Awaria Tuchanka1<\/h3>\n

<\/p>\n

\"Modelowanie<\/p>\n

<\/p>\n

Awaria jednego z centr\u00f3w danych dla Tuchanka1. W takim przypadku witness<\/em> przekazuje sw\u00f3j g\u0142os drugiemu w\u0119z\u0142owi w drugim centrum danych. Tam by\u0142y slave przekszta\u0142ca si\u0119 w mastera, w wyniku czego na jednym serwerze dzia\u0142aj\u0105 oba mastera i na nich wskazuj\u0105 obie ich float IP.<\/p>\n

<\/p>\n

Tuchanka2 (klasyczny)<\/h2>\n

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelowanie<\/p>\n

<\/p>\n

Klasyczny schemat z dw\u00f3ch w\u0119z\u0142\u00f3w. Na jednym dzia\u0142a master, na drugim slave. Oba mog\u0105 wykonywa\u0107 zapytania (slave tylko read only), wi\u0119c na obu wskazuj\u0105 float IP: krogan2 \u2014 na master, krogan2s1 \u2014 na slave. Odporno\u015b\u0107 na awarie b\u0119dzie zar\u00f3wno dla mastera, jak i dla slave'a.<\/p>\n

<\/p>\n

W przypadku dw\u00f3ch w\u0119z\u0142\u00f3w odporno\u015b\u0107 na awarie jest mo\u017cliwa tylko przy asynchronicznej replikacji, poniewa\u017c przy synchronizowanej awaria slave'a spowoduje zatrzymanie mastera.<\/p>\n

<\/p>\n

Awaria Tuchanka2<\/h3>\n

<\/p>\n

\"Modelowanie<\/p>\n

<\/p>\n

Przy awarii jednego z centr\u00f3w danych witness<\/em> g\u0142osuje na drugi. Na jedynym dzia\u0142aj\u0105cym centrum danych zostanie uruchomiony master, a oba float IP: masterowy i roboczy b\u0119d\u0105 do niego wskazywa\u0107. Oczywi\u015bcie instancja musi by\u0107 skonfigurowana w taki spos\u00f3b, aby mia\u0142a wystarczaj\u0105ce zasoby (limity pod po\u0142\u0105czenia itp.), aby jednocze\u015bnie przyjmowa\u0107 wszystkie po\u0142\u0105czenia i \u017c\u0105dania od masterowego i roboczego float IP. Oznacza to, \u017ce przy normalnej pracy powinna mie\u0107 wystarczaj\u0105cy zapas limit\u00f3w.<\/p>\n

<\/p>\n

Tuchanka4 (wiele robot\u00f3w)<\/h2>\n

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelowanie<\/p>\n

<\/p>\n

To ju\u017c inny ekstremum. S\u0105 bazy danych, kt\u00f3re otrzymuj\u0105 bardzo du\u017co \u017c\u0105da\u0144 tylko do odczytu (typowy przypadek wysoko obci\u0105\u017conej strony internetowej). Tuchanka4 to sytuacja, w kt\u00f3rej mo\u017ce by\u0107 trzech lub wi\u0119cej robot\u00f3w do obs\u0142ugi takich \u017c\u0105da\u0144, ale nie za du\u017co. Przy bardzo du\u017cej liczbie robot\u00f3w b\u0119dzie trzeba wymy\u015bli\u0107 hierarchiczny system replikacji. W minimalnym przypadku (na obrazku) w ka\u017cdym z dw\u00f3ch centr\u00f3w danych znajduj\u0105 si\u0119 po dwa serwery, z kt\u00f3rych ka\u017cdy ma jedn\u0105 instancj\u0119 PostgreSQL.<\/p>\n

<\/p>\n

Kolejn\u0105 cech\u0105 tego schematu jest to, \u017ce mo\u017cna ju\u017c zorganizowa\u0107 jedn\u0105 synchronizowan\u0105 replikacj\u0119. Jest ona skonfigurowana tak, aby replikowa\u0107, w miar\u0119 mo\u017cliwo\u015bci, do innego centrum danych, a nie do repliki w tym samym centrum danych, gdzie znajduje si\u0119 master. Na mastera i na ka\u017cdego robota wskazuje float IP. W zasadzie mi\u0119dzy robotami nale\u017ca\u0142oby zrealizowa\u0107 r\u00f3wnowa\u017cenie \u017c\u0105da\u0144. sql proxy<\/em>, na przyk\u0142ad, po stronie klienta. R\u00f3\u017cnym typom klient\u00f3w mo\u017ce by\u0107 potrzebny r\u00f3\u017cny typ sql proxy<\/em>, i tylko programi\u015bci klient\u00f3w wiedz\u0105, kto czego potrzebuje. Ta funkcjonalno\u015b\u0107 mo\u017ce by\u0107 zrealizowana zar\u00f3wno jako zewn\u0119trzny demon, jak i biblioteka klienta (connection pool) itd. Wszystko to wykracza poza temat systemu baz danych odpornego na awarie (odporno\u015b\u0107 SQL proxy<\/em> mo\u017ce by\u0107 realizowana niezale\u017cnie, razem z odporno\u015bci\u0105 klienta).<\/p>\n

<\/p>\n

Awaria Tuchanka4<\/h3>\n

<\/p>\n

\"Modelowanie<\/p>\n

<\/p>\n

W przypadku awarii jednego centrum danych (tzn. dw\u00f3ch serwer\u00f3w) witness g\u0142osuje na drugi. W rezultacie w drugim centrum danych dzia\u0142aj\u0105 dwa serwery: na jednym dzia\u0142a master, a na niego wskazuje masterowy float IP (do przyjmowania \u017c\u0105da\u0144 read-write); a na drugim serwerze dzia\u0142a robot z synchronizowan\u0105 replikacj\u0105, a na niego wskazuje jeden z roboczych float IP (do \u017c\u0105da\u0144 tylko do odczytu).<\/p>\n

<\/p>\n

Pierwsz\u0105 rzecz\u0105, kt\u00f3r\u0105 nale\u017cy odnotowa\u0107: roboczym float IP b\u0119dzie tylko jeden, a aby poprawnie z nim dzia\u0142a\u0107, b\u0119dzie trzeba, aby sql proxy<\/em> przekierowywa\u0142 wszystkie zapytania na jedyny pozosta\u0142y adres float IP; a je\u015bli sql proxy<\/em> nie, to mo\u017cna wymieni\u0107 wszystkie adresy float IP niewolnik\u00f3w oddzielaj\u0105c je przecinkiem w URL do po\u0142\u0105czenia. W takim przypadku z libpq<\/em> po\u0142\u0105czenie b\u0119dzie na pierwszym dzia\u0142aj\u0105cym IP, tak jest zrobione w systemie automatycznego testowania. Mo\u017ce si\u0119 okaza\u0107, \u017ce w innych bibliotekach, na przyk\u0142ad JDBC, mo\u017ce to nie zadzia\u0142a\u0107 i b\u0119dzie potrzebne sql proxy<\/em>. Zosta\u0142o to zrobione, poniewa\u017c dla float IP niewolnik\u00f3w obowi\u0105zuje zakaz jednoczesnego uruchamiania na jednym serwerze, aby by\u0142y r\u00f3wnomiernie rozdzielane mi\u0119dzy serwery niewolnik\u00f3w, je\u015bli dzia\u0142a ich kilka.<\/p>\n

<\/p>\n

Drugie: nawet w przypadku awarii centrum danych synchronizowana replikacja b\u0119dzie zachowana. A nawet je\u015bli nast\u0105pi wt\u00f3rna awaria, czyli w pozosta\u0142ym centrum danych jeden z dw\u00f3ch serwer\u00f3w ulegnie awarii, klaster, mimo \u017ce przestanie \u015bwiadczy\u0107 us\u0142ugi, nadal zachowa informacje o wszystkich zakommitowanych transakcjach, dla kt\u00f3rych wyda\u0142 potwierdzenie o commicie (nie b\u0119dzie utraty informacji w przypadku wt\u00f3rnej awarii).<\/p>\n

<\/p>\n

Tuchanka3 (3 centra danych)<\/h2>\n

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelowanie<\/p>\n

<\/p>\n

To klaster na sytuacj\u0119, gdy s\u0105 trzy w pe\u0142ni dzia\u0142aj\u0105ce centra danych, w ka\u017cdym z nich dzia\u0142a w pe\u0142ni dzia\u0142aj\u0105cy serwer bazy danych. W takim przypadku urz\u0105dzenia quorum<\/em> nie jest potrzebny. W jednym centrum danych dzia\u0142a master, w dw\u00f3ch innych \u2014 niewolnicy. Replikacja jest synchronizowana, typu ANY (slave1, slave2), co oznacza, \u017ce klient otrzyma potwierdzenie commitu, gdy kt\u00f3rykolwiek z niewolnik\u00f3w jako pierwszy odpowie, \u017ce przyj\u0105\u0142 commit. Na zasoby wskazuje jeden float IP dla mastera i dwa dla niewolnik\u00f3w. W przeciwie\u0144stwie do Tuchanka4 wszystkie trzy float IP s\u0105 odporne na awarie. Do balansowania zapyta\u0144 SQL w trybie tylko do odczytu mo\u017cna u\u017cy\u0107 sql proxy<\/em> (z osobn\u0105 odporno\u015bci\u0105 na awarie), lub przydzieli\u0107 jednej po\u0142owie klient\u00f3w jeden niewolniczy float IP, a drugiej po\u0142owie \u2014 drugi.<\/p>\n

<\/p>\n

Awaria Tuchanka3<\/h3>\n

<\/p>\n

\"Modelowanie<\/p>\n

<\/p>\n

W przypadku awarii jednego z centr\u00f3w danych pozostaj\u0105 dwa. W jednym dzia\u0142a master i float IP od mastera, w drugim \u2014 niewolnik i oba niewolnicze float IP (na instancji powinien by\u0107 podw\u00f3jny zapas zasob\u00f3w, aby przyj\u0105\u0107 wszystkie po\u0142\u0105czenia z obu niewolniczych float IP). Mi\u0119dzy masterem a niewolnikiem jest synchronizowana replikacja. Ponadto klaster zachowa informacje o zakommitowanych i potwierdzonych transakcjach (nie b\u0119dzie utraty informacji) w przypadku zniszczenia dw\u00f3ch centr\u00f3w danych (je\u015bli nie zostan\u0105 zniszczone jednocze\u015bnie).<\/p>\n

<\/p>\n

Nie zamieszcza\u0142em szczeg\u00f3\u0142owego opisu struktury plik\u00f3w i wdra\u017cania. Kto chce si\u0119 pobawi\u0107, mo\u017ce to wszystko przeczyta\u0107 w README. Przedstawiam tylko opis automatycznego testowania.<\/em><\/p>\n

<\/p>\n

System automatycznego testowania<\/h1>\n

<\/p>\n

Aby sprawdzi\u0107 odporno\u015b\u0107 klastr\u00f3w przy symulacji r\u00f3\u017cnych usterek, stworzono system automatycznego testowania. Uruchamiany jest za pomoc\u0105 skryptu test\/failure<\/code>. Skrypt mo\u017ce przyjmowa\u0107 jako parametry numery klastr\u00f3w, kt\u00f3re chce si\u0119 przetestowa\u0107. Na przyk\u0142ad, to polecenie:<\/p>\n

<\/p>\n

test\/failure 2 3<\/code><\/pre>\n
<\/p>\n
b\u0119dzie testowa\u0107 tylko drugi i trzeci klaster. Je\u015bli parametry nie s\u0105 podane, b\u0119d\u0105 testowane wszystkie klastry. Wszystkie klastry s\u0105 testowane r\u00f3wnolegle, a wyniki wy\u015bwietlane s\u0105 w panelu tmux. Tmux u\u017cywa dedykowanego serwera tmux, wi\u0119c skrypt mo\u017cna uruchamia\u0107 z domy\u015blnego tmux, co daje zagnie\u017cd\u017cony tmux. Rekomenduj\u0119 u\u017cycie terminala w du\u017cym oknie i z ma\u0142\u0105 czcionk\u0105. Przed rozpocz\u0119ciem testowania wszystkie wirtualne maszyny s\u0105 przywracane do migawki w momencie zako\u0144czenia skryptu. setup<\/code>.<\/p>\n
<\/p>\n
\"Modelowanie<\/p>\n
<\/p>\n
Terminal jest podzielony na kolumny wed\u0142ug liczby testowanych klastr\u00f3w, domy\u015blnie (na zrzucie ekranu) jest ich cztery. Zawarto\u015b\u0107 kolumn opisz\u0119 na przyk\u0142adzie Tuchanka2. Panel na zrzucie ekranu jest ponumerowany:<\/p>\n
<\/p>\n
    \n
  1. Tutaj wy\u015bwietlane s\u0105 statystyki test\u00f3w. Kolumny:\n