{"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\/sq\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","title":{"rendered":"Modelimi i klaster\u00ebve t\u00eb q\u00ebndruesh\u00ebm mbi baz\u00ebn e PostgreSQL dhe Pacemaker.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hyrje<\/h1>\n

<\/p>\n

Para nj\u00eb koh\u00eb, m\u00eb \u00ebsht\u00eb dh\u00ebn\u00eb detyra p\u00ebr t\u00eb zhvilluar nj\u00eb klaster t\u00eb q\u00ebndruesh\u00ebm p\u00ebr PostgreSQL<\/a><\/noindex>, q\u00eb funksionon n\u00eb disa qendra t\u00eb t\u00eb dh\u00ebnave t\u00eb lidhura me fibra optike brenda nj\u00eb qyteti, dhe q\u00eb \u00ebsht\u00eb n\u00eb gjendje t\u00eb p\u00ebrballoj\u00eb d\u00ebshtimin (p.sh., munges\u00ebn e energjis\u00eb) t\u00eb nj\u00eb qendre t\u00eb t\u00eb dh\u00ebnave. Si softuer q\u00eb responsabon p\u00ebr q\u00ebndrueshm\u00ebrin\u00eb, kam zgjedhur Pacemaker<\/a><\/noindex>, sepse \u00ebsht\u00eb zgjidhja zyrtare nga RedHat p\u00ebr krijimin e klaster\u00ebve t\u00eb q\u00ebndruesh\u00ebm. Ajo \u00ebsht\u00eb e mir\u00eb sepse RedHat e mb\u00ebshtet at\u00eb, dhe sepse kjo zgjidhje \u00ebsht\u00eb universale (modulare). N\u00ebp\u00ebrmjet saj, mund t\u00eb sigurohet q\u00ebndrueshm\u00ebria jo vet\u00ebm p\u00ebr PostgreSQL, por edhe p\u00ebr sh\u00ebrbime t\u00eb tjera, ose duke p\u00ebrdorur modulet standarde, ose duke krijuar ato p\u00ebr nevojat specifike.<\/p>\n

<\/p>\n

P\u00ebr k\u00ebt\u00eb zgjidhje ka lindur nj\u00eb pyetje e arsyeshme: sa e q\u00ebndrueshme do t\u00eb jet\u00eb klasteri i q\u00ebndruesh\u00ebm? P\u00ebr ta hetuar k\u00ebt\u00eb, kam zhvilluar nj\u00eb laborator testimi q\u00eb imiton d\u00ebshtime t\u00eb ndryshme n\u00eb nyjet e klasterit, pret p\u00ebr rikuperimin e funksionalitetit, rikuperon nyjen e d\u00ebshtuar dhe vazhdon testimin n\u00eb cik\u00ebl. Fillimisht, ky projekt quhej hapgsql, por me kalimin e koh\u00ebs m\u00eb \u00ebsht\u00eb b\u00ebr\u00eb e m\u00ebrzitshme emri q\u00eb kishte vet\u00ebm nj\u00eb vigj\u00eb. Prandaj, bazat e t\u00eb dh\u00ebnave t\u00eb q\u00ebndrueshme (dhe IP-t\u00eb q\u00eb tregojn\u00eb p\u00ebr to) fillova t\u2019i quaj krogan<\/strong> (nj\u00eb personazh nga nj\u00eb loj\u00eb kompjuterike, i cili ka t\u00eb gjitha organet e r\u00ebnd\u00ebsishme t\u00eb dyfishta), dhe nyjet, klaster\u00ebt dhe vet\u00eb projektin e quajta tuchanka<\/strong> (planeta ku jetojn\u00eb krogan\u00ebt).<\/p>\n

<\/p>\n

Tani udh\u00ebheqja ka lejuar hapjen e projektit p\u00ebr komunitetin open source n\u00ebn licenc\u00ebn MIT<\/a><\/noindex>. README n\u00eb nj\u00eb t\u00eb ardhme t\u00eb af\u00ebrt do t\u00eb p\u00ebrkthehet n\u00eb anglisht (sepse pritet q\u00eb konsumator\u00ebt kryesor\u00eb t\u00eb jen\u00eb zhvilluesit e Pacemaker dhe PostgreSQL), dhe variantin e vjet\u00ebr n\u00eb rus t\u00eb README e kam vendosur ta organizoj (pjes\u00ebrisht) n\u00eb form\u00ebn e k\u00ebtij artikulli.<\/p>\n

<\/p>\n

\"Modelimi<\/p>\n

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

Klaster\u00ebt vendosen n\u00eb virtualka VirtualBox<\/a><\/noindex>. Gjithsej do t\u00eb krijohen 12 virtualka (me nj\u00eb total prej 36GiB), t\u00eb cilat formojn\u00eb 4 klaster\u00eb t\u00eb q\u00ebndruesh\u00ebm (varianta t\u00eb ndryshme). Dy klaster\u00ebt e par\u00eb p\u00ebrb\u00ebhen nga dy server\u00eb PostgreSQL, t\u00eb cil\u00ebt jan\u00eb vendosur n\u00eb qendra t\u00eb ndryshme t\u00eb t\u00eb dh\u00ebnave, dhe nj\u00eb server i p\u00ebrbashk\u00ebt witness<\/em> me quorum device<\/strong> (i vendosur n\u00eb nj\u00eb virtualke t\u00eb lir\u00eb n\u00eb nj\u00eb qend\u00ebr t\u00eb tret\u00eb t\u00eb t\u00eb dh\u00ebnave), i cili zgjidh pasigurin\u00eb 50%\/50%<\/strong>, duke i dh\u00ebn\u00eb vot\u00ebn e tij nj\u00ebrit prej pal\u00ebve. Klasteri i tret\u00eb \u00ebsht\u00eb n\u00eb tre qendra t\u00eb t\u00eb dh\u00ebnave: nj\u00eb master, dy skllev\u00ebr, pa quorum device<\/strong>. Klasteri i kat\u00ebrt p\u00ebrb\u00ebhet nga kat\u00ebr server\u00eb PostgreSQL, me dy n\u00eb \u00e7do qend\u00ebr t\u00eb t\u00eb dh\u00ebnave: nj\u00eb master, t\u00eb tjer\u00ebt replikat, dhe gjithashtu p\u00ebrdor witness<\/em> me quorum device<\/strong>. Klasteri i kat\u00ebrt mban nj\u00eb d\u00ebshtim t\u00eb dy server\u00ebve ose nj\u00eb qendre t\u00eb t\u00eb dh\u00ebnave. Kjo zgjidhje mund t\u00eb shkall\u00ebzohet, n\u00ebse \u00ebsht\u00eb e nevojshme, n\u00eb m\u00eb shum\u00eb replika.<\/p>\n

<\/p>\n

Sh\u00ebrbimi i koh\u00ebs s\u00eb sakt\u00eb ntpd<\/a><\/noindex> \u00ebsht\u00eb gjithashtu rikonfiguruar p\u00ebr q\u00ebndrueshm\u00ebri, por aty \u00ebsht\u00eb p\u00ebrdorur metoda e vet\u00eb ntpd<\/code> (orphan mode<\/em>). Serveri i p\u00ebrbashk\u00ebt witness<\/em> p\u00ebrmbush rolin e serverit Qendror NTP, duke shp\u00ebrndar\u00eb koh\u00ebn e tij p\u00ebr t\u00eb gjith\u00eb klaster\u00ebt, duke sinjalizuar k\u00ebshtu t\u00eb gjith\u00eb server\u00ebt midis tyre. N\u00ebse witness<\/em> d\u00ebshmon d\u00ebshtimin ose t\u00eb izolohet, at\u00ebher\u00eb nj\u00eb nga server\u00ebt e klasterit do t\u00eb filloj\u00eb t\u00eb shp\u00ebrndaj\u00eb koh\u00ebn e tij (brenda klasterit). Nj\u00eb proxy ndihm\u00ebs HTTP proxy<\/strong> \u00ebsht\u00eb gjithashtu ngritur mbi witness<\/em>, me t\u00eb cilin virtualkat e tjera kan\u00eb qasje n\u00eb depozit\u00eb Yum. N\u00eb realitet, sh\u00ebrbime t\u00eb tilla si koha e sakt\u00eb dhe proxy, me siguri do t\u00eb vendosen n\u00eb server\u00eb t\u00eb dedikuar, nd\u00ebrsa n\u00eb k\u00ebt\u00eb laborator ato jan\u00eb vendosur n\u00eb witness<\/em> vet\u00ebm p\u00ebr t\u00eb kursyer numrin e virtualkave dhe hap\u00ebsir\u00ebn.<\/p>\n

<\/p>\n

Versionet<\/h1>\n

<\/p>\n

v0. Funksionon me CentOS 7 dhe PostgreSQL 11 n\u00eb VirtualBox 6.1.<\/p>\n

<\/p>\n

Struktura e klaster\u00ebve<\/h1>\n

<\/p>\n

T\u00eb gjith\u00eb klaster\u00ebt jan\u00eb t\u00eb destinuar p\u00ebr t'u vendosur n\u00eb disa qendra t\u00eb t\u00eb dh\u00ebnave, t\u00eb lidhura n\u00eb nj\u00eb rrjet t\u00eb shesht\u00eb dhe duhet t\u00eb p\u00ebrballojn\u00eb d\u00ebshtimin ose izolimin rrjetor t\u00eb nj\u00eb qendre t\u00eb t\u00eb dh\u00ebnave. Prandaj e pamundur<\/strong> p\u00ebrdorimi p\u00ebr mbrojtje nga split-brain<\/strong> teknologji standarde Pacemaker, e cila quhet STONITH<\/em> (Shoot The Other Node In The Head) ose fencing<\/em>. Thelbi i saj: n\u00ebse nyjet n\u00eb klaster fillojn\u00eb t\u00eb dyshojn\u00eb se ndonj\u00eb nyj\u00eb po kalon n\u00eb v\u00ebshtir\u00ebsi, nuk p\u00ebrgjigjet ose sillet n\u00eb m\u00ebnyr\u00eb t\u00eb pap\u00ebrshtatshme, ato e \u00e7activate at\u00eb me an\u00eb t\u00eb pajisjeve \"t\u00eb jashtme\", p\u00ebr shembull, kart\u00ebn kontrolluese IPMI ose UPS. Por kjo do t\u00eb funksionoj\u00eb vet\u00ebm n\u00eb rastet kur, n\u00eb rastin e nj\u00eb d\u00ebshtimi t\u00eb vet\u00ebm t\u00eb serverit, IPMI ose UPS vazhdojn\u00eb t\u00eb funksionojn\u00eb. K\u00ebtu planifikohet nj\u00eb mbrojtje nga nj\u00eb d\u00ebshtim shum\u00eb m\u00eb katastrofik, kur t\u00eb gjith\u00eb qendra e t\u00eb dh\u00ebnave d\u00ebshton (p.sh., humbet energjin\u00eb). Dhe n\u00eb nj\u00eb d\u00ebshtim t\u00eb till\u00eb, t\u00eb gjitha stonith<\/em>-pajisjet (IPMI, UPS, etj.) gjithashtu nuk do t\u00eb funksionojn\u00eb.<\/p>\n

<\/p>\n

N\u00eb vend t\u00eb k\u00ebsaj, ideja themelore e sistemit \u00ebsht\u00eb koncepti i kvorumit. T\u00eb gjitha nyjet kan\u00eb nj\u00eb vot\u00eb, dhe mund t\u00eb funksionojn\u00eb vet\u00ebm ato q\u00eb shohin m\u00eb shum\u00eb se gjysma e t\u00eb gjitha nyjeve. Ky num\u00ebr \"gjysm\u00eb+1\" quhet kvorum<\/strong>. N\u00ebse kvorumi nuk arrihet, nyja vendos se \u00ebsht\u00eb n\u00eb izolim rrjetor dhe duhet t\u00eb \u00e7aktivizoj\u00eb burimet e saj, pra kjo \u00ebsht\u00eb nj\u00eb mbrojtje nga split-brain<\/strong>. N\u00ebse softi q\u00eb \u00ebsht\u00eb p\u00ebrgjegj\u00ebs p\u00ebr k\u00ebt\u00eb sjellje nuk funksionon, at\u00ebher\u00eb duhet t\u00eb aktivizohet watchdog, p\u00ebr shembull, bazuar n\u00eb IPMI.<\/p>\n

<\/p>\n

N\u00ebse numri i nyjeve \u00ebsht\u00eb \u00e7ift (klaster n\u00eb dy qendra t\u00eb t\u00eb dh\u00ebnave), at\u00ebher\u00eb mund t\u00eb ndodh\u00eb ajo q\u00eb quhet pasiguri. 50%\/50%<\/strong> (pjesa 50-50<\/em>), kur izolimi rrjetor ndan klasterin sakt\u00ebsisht n\u00eb dy pjes\u00eb. Prandaj, p\u00ebr numrin \u00e7ift t\u00eb nyjeve shtohet quorum device<\/strong> \u2014 nj\u00eb demon q\u00eb nuk k\u00ebrkon burime, i cili mund t\u00eb ekzekutohet n\u00eb virtualizimin m\u00eb t\u00eb lir\u00eb n\u00eb qendr\u00ebn e tret\u00eb t\u00eb t\u00eb dh\u00ebnave. Ai i jep z\u00ebrin nj\u00ebrit prej segmenteve (q\u00eb sheh) dhe k\u00ebshtu zgjidh pasigurin\u00eb 50%\/50%. Serveri n\u00eb t\u00eb cilin do t\u00eb aktivizohet pajisja e kuorumit e quajta witness<\/em> (terminologji nga repmgr, m\u00eb p\u00eblqeu).<\/p>\n

<\/p>\n

Burimet mund t\u00eb l\u00ebvizin nga nj\u00eb vend n\u00eb tjetrin, p\u00ebr shembull, nga serverat e prishur n\u00eb ata t\u00eb funksionsh\u00ebm, ose me urdh\u00ebr t\u00eb administrator\u00ebve t\u00eb sistemit. P\u00ebr t'u siguruar q\u00eb klient\u00ebt e din\u00eb se ku ndodhen burimet q\u00eb u nevojiten (ku t\u00eb lidhen?), p\u00ebrdoren IP t\u00eb l\u00ebvizshme<\/em> (IP t\u00eb l\u00ebvizshme<\/strong>). K\u00ebto jan\u00eb IP q\u00eb Pacemaker mund t'i zhvendos\u00eb midis nyjeve (gjith\u00e7ka \u00ebsht\u00eb n\u00eb nj\u00eb rrjet t\u00eb shesht\u00eb). Secila prej tyre simbolizon nj\u00eb burim (sh\u00ebrbim) dhe do t\u00eb jet\u00eb aty ku duhet t\u00eb lidhen p\u00ebr t\u00eb marr\u00eb qasje n\u00eb k\u00ebt\u00eb sh\u00ebrbim (n\u00eb rastin ton\u00eb, DB).<\/p>\n

<\/p>\n

Tuchanka1 (schem\u00ebn me shkall\u00ebzim)<\/h2>\n

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelimi<\/p>\n

<\/p>\n

Ideja ishte se kemi shum\u00eb baza t\u00eb dh\u00ebnash t\u00eb vogla me ngarkes\u00eb t\u00eb ul\u00ebt, p\u00ebr t\u00eb cilat nuk \u00ebsht\u00eb ekonomike t\u00eb mbash nj\u00eb server t\u00eb dedikuar slave n\u00eb modalitetin hot standby p\u00ebr transaksione read only (nuk ka nevoj\u00eb p\u00ebr nj\u00eb shpenzim t\u00eb till\u00eb burimesh).<\/p>\n

<\/p>\n

N\u00eb secil\u00ebn qend\u00ebr t\u00eb t\u00eb dh\u00ebnave ka nga nj\u00eb server. N\u00eb \u00e7do server ka dy instanca PostgreSQL (n\u00eb terminologjin\u00eb PostgreSQL quhen klastere, por p\u00ebr t\u00eb shmangur konfuzionin do t'i quaj instanca (sip\u00ebrisht nga analogjia me DB t\u00eb tjera), nd\u00ebrsa klastere do t\u00eb quaj vet\u00ebm klasteret e Pacemaker). Nj\u00eb instanc\u00eb punon n\u00eb modin master, dhe vet\u00ebm ai ofron sh\u00ebrbime (vet\u00ebm ai ka float IP). Instanca e dyt\u00eb punon si slave p\u00ebr qendr\u00ebn e dyt\u00eb t\u00eb t\u00eb dh\u00ebnave dhe do t\u00eb ofroj\u00eb sh\u00ebrbime vet\u00ebm n\u00eb rast se masteri i tij d\u00ebshtoi. Duke pasur parasysh se pjesa m\u00eb e madhe e koh\u00ebs do t\u00eb ofrohet vet\u00ebm nj\u00eb instanc\u00eb nga t\u00eb dy (master), t\u00eb gjitha burimet e serverit optimizohen p\u00ebr masterin (i caktohet memorie p\u00ebr kesh shared_buffers etj.), por n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb mjaftoj\u00eb gjithashtu p\u00ebr instanc\u00ebn e dyt\u00eb (pavar\u00ebsisht se p\u00ebr t\u00eb do t\u00eb ket\u00eb burime jooptimale p\u00ebrmes keshit t\u00eb sistemit t\u00eb skedar\u00ebve) n\u00eb rast t\u00eb d\u00ebshtimit t\u00eb nj\u00eb prej qendrave t\u00eb t\u00eb dh\u00ebnave. Slave nuk ofron sh\u00ebrbime (nuk kryen k\u00ebrkesa read only) gjat\u00eb funksionimit normal t\u00eb klasterit, p\u00ebr t\u00eb shmangur luft\u00ebn p\u00ebr burime me masterin n\u00eb t\u00eb nj\u00ebjtin server.<\/p>\n

<\/p>\n

N\u00eb rastin e dy nyjeve, disponueshm\u00ebria e lart\u00eb \u00ebsht\u00eb e mundur vet\u00ebm me replikim asinkron, sepse n\u00ebse ndodh nj\u00eb d\u00ebshtim te slave, do t\u00eb \u00e7oj\u00eb n\u00eb ndalimin e masterit.<\/p>\n

<\/p>\n

D\u00ebshtimi i witness<\/h3>\n

<\/p>\n

\"Modelimi<\/p>\n

<\/p>\n

D\u00ebshtimi i witness (quorum device<\/em>) do ta shqyrtoj vet\u00ebm p\u00ebr klasterin Tuchanka1, me t\u00eb gjitha t\u00eb tjerat do t\u00eb ket\u00eb t\u00eb nj\u00ebjt\u00ebn histori. N\u00ebse witness d\u00ebshton, struktura e klasterit nuk do t\u00eb ndryshoj\u00eb, gjith\u00e7ka do t\u00eb vazhdoj\u00eb t\u00eb funksionoj\u00eb si\u00e7 ka funksionuar. Por kuorumi do t\u00eb b\u00ebhet 2 nga 3, dhe p\u00ebr k\u00ebt\u00eb arsye \u00e7do d\u00ebshtim tjet\u00ebr do t\u00eb jet\u00eb fatal p\u00ebr klasterin. Do t\u00eb duhet urgent t\u00eb riparohet.<\/p>\n

<\/p>\n

D\u00ebshtimi i Tuchanka1<\/h3>\n

<\/p>\n

\"Modelimi<\/p>\n

<\/p>\n

D\u00ebshtimi i nj\u00ebrit nga qendrat e t\u00eb dh\u00ebnave p\u00ebr Tuchanka1. N\u00eb k\u00ebt\u00eb rast witness<\/em> i jep z\u00ebrin nyj\u00ebs s\u00eb dyt\u00eb n\u00eb qendr\u00ebn e dyt\u00eb t\u00eb t\u00eb dh\u00ebnave. Atje, ish slave shnd\u00ebrrohet n\u00eb master, si pasoj e k\u00ebsaj, t\u00eb dy master\u00ebt punojn\u00eb n\u00eb nj\u00eb server dhe n\u00eb ta tregohet t\u00eb dy float IP e tyre.<\/p>\n

<\/p>\n

Tuchanka2 (klasike)<\/h2>\n

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelimi<\/p>\n

<\/p>\n

Skema klasike me dy nyje. Nj\u00ebri punon si master, tjetri si slave. T\u00eb dy mund t\u00eb kryejn\u00eb k\u00ebrkesa (slave vet\u00ebm read only), prandaj t\u00eb dy tregojn\u00eb float IP: krogan2 \u2014 p\u00ebr masterin, krogan2s1 \u2014 p\u00ebr slavin. Disponueshm\u00ebria e lart\u00eb do t\u00eb jet\u00eb si p\u00ebr masterin ashtu edhe p\u00ebr slavin.<\/p>\n

<\/p>\n

N\u00eb rastin e dy nyjeve, disponueshm\u00ebria e lart\u00eb \u00ebsht\u00eb e mundur vet\u00ebm me replikim asinkron, sepse n\u00ebse ndodh nj\u00eb d\u00ebshtim te slave, do t\u00eb \u00e7oj\u00eb n\u00eb ndalimin e masterit.<\/p>\n

<\/p>\n

D\u00ebshtimi i Tuchanka2<\/h3>\n

<\/p>\n

\"Modelimi<\/p>\n

<\/p>\n

N\u00eb rastin e d\u00ebshtimit t\u00eb nj\u00ebrit nga qendrat e t\u00eb dh\u00ebnave witness<\/em> voton p\u00ebr t\u00eb dytin. N\u00eb qendr\u00ebn e vetme t\u00eb funksionimit do t\u00eb ngrihet masteri, dhe n\u00eb t\u00eb do t\u00eb tregohen t\u00eb dy float IP: ai master dhe ai slave. Sigurisht, instanca duhet t\u00eb jet\u00eb e konfiguruar n\u00eb nj\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb ken\u00eb mjaft burime (limitet p\u00ebr lidhje etj.) p\u00ebr t\u00eb pranuar nj\u00ebkoh\u00ebsisht t\u00eb gjitha lidhjet dhe k\u00ebrkesat nga float IP master dhe slave. K\u00ebshtu q\u00eb gjat\u00eb funksionimit normal duhet t\u00eb ket\u00eb nj\u00eb rezerv\u00eb t\u00eb mjaftueshme n\u00eb limitet.<\/p>\n

<\/p>\n

Tuchanka4 (shum\u00eb slave)<\/h2>\n

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelimi<\/p>\n

<\/p>\n

Kjo \u00ebsht\u00eb nj\u00eb tjet\u00ebr ekstrem. Ka baza t\u00eb dh\u00ebnash, t\u00eb cilat kan\u00eb shum\u00eb k\u00ebrkesa read-only (rast tipik i nj\u00eb siti me ngarkes\u00eb t\u00eb lart\u00eb). Tuchanka4 \u00ebsht\u00eb situata kur mund t\u00eb ket\u00eb tre ose m\u00eb shum\u00eb slave p\u00ebr t\u00eb p\u00ebrballuar k\u00ebrkesat e tilla, por s\u00ebrish jo shum\u00eb. Kur ka nj\u00eb num\u00ebr shum\u00eb t\u00eb madh slave, do t\u00eb duhet t\u00eb krijohet nj\u00eb sistem hierarkik replikimi. N\u00eb rastin minimal (n\u00eb figur\u00eb) n\u00eb secil\u00ebn nga dy qendrat e t\u00eb dh\u00ebnave jan\u00eb dy servera, secili me nga nj\u00eb instanc\u00eb PostgreSQL.<\/p>\n

<\/p>\n

Nj\u00eb ve\u00e7ori tjet\u00ebr e k\u00ebsaj skeme \u00ebsht\u00eb se k\u00ebtu tashm\u00eb mund t\u00eb organizohet nj\u00eb replikim i sinkronizuar. Ajo \u00ebsht\u00eb e konfiguruar n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb replikoj\u00eb, sa m\u00eb shum\u00eb t\u00eb jet\u00eb e mundur, n\u00eb nj\u00eb datacenter tjet\u00ebr dhe jo n\u00eb nj\u00eb replika n\u00eb t\u00eb nj\u00ebjtin datacenter si master. N\u00eb master dhe n\u00eb \u00e7do skllav tregohet nj\u00eb float IP. N\u00eb t\u00eb v\u00ebrtet\u00eb, mes skllav\u00ebve duhet t\u00eb b\u00ebhet balancimi i k\u00ebrkesave me ndonj\u00eb sql proxy<\/em>, p\u00ebr shembull, n\u00eb an\u00ebn e klientit. Klient\u00eb t\u00eb ndrysh\u00ebm mund t\u00eb ken\u00eb nevoja t\u00eb ndryshme sql proxy<\/em>, dhe vet\u00ebm zhvilluesit e klient\u00ebve e din\u00eb se kush ka nevoj\u00eb p\u00ebr \u00e7far\u00eb. Kjo funksionalitet mund t\u00eb realizohet si nga nj\u00eb demon t\u00eb jasht\u00ebm, ashtu edhe nga biblioteka e klientit (connection pool), etj. Gjith\u00e7ka kjo del jasht\u00eb tem\u00ebs s\u00eb klasterit t\u00eb DB me q\u00ebllim p\u00ebrshtatshm\u00ebrin\u00eb ndaj d\u00ebshtimeve (p\u00ebrshtatshm\u00ebria SQL proxy<\/em> mund t\u00eb realizohet pavar\u00ebsisht, s\u00eb bashku me p\u00ebrshtatshm\u00ebrin\u00eb e klientit).<\/p>\n

<\/p>\n

D\u00ebshtimi i Tuchanka4<\/h3>\n

<\/p>\n

\"Modelimi<\/p>\n

<\/p>\n

Kur nj\u00eb datacenter d\u00ebshtojn\u00eb (dmth. dy servera), d\u00ebshmitari voton p\u00ebr t\u00eb dytin. Si rezultat, n\u00eb datacentin e dyt\u00eb funksionojn\u00eb dy servera: nj\u00eb ka masterin, dhe p\u00ebr t\u00eb tregohet float IP i masterit (p\u00ebr t\u00eb pranuar k\u00ebrkesat read-write); nd\u00ebrsa n\u00eb serverin e dyt\u00eb funksionon nj\u00eb skllav me replikim t\u00eb sinkronizuar, dhe p\u00ebr t\u00eb tregohet nj\u00eb nga float IP-t\u00eb e skllav\u00ebve (p\u00ebr k\u00ebrkesat read only).<\/p>\n

<\/p>\n

E para q\u00eb duhet t\u00eb theksohet: float IP skllav do t\u00eb jet\u00eb vet\u00ebm nj\u00eb. Dhe p\u00ebr funksionimin e tij t\u00eb sakt\u00eb duhet q\u00eb sql proxy<\/em> t\u00eb gjith\u00eb k\u00ebrkesat t\u00eb redirektohen n\u00eb float IP-in e mbetur; dhe n\u00ebse sql proxy<\/em> jo, at\u00ebher\u00eb mund t\u00eb listohen t\u00eb gjitha float IP-t\u00eb e skllav\u00ebve me presje n\u00eb URL p\u00ebr lidhje. N\u00eb k\u00ebt\u00eb rast, me libpq<\/em> lidhja do t\u00eb jet\u00eb me IP-n\u00eb e par\u00eb funksionale, ashtu si \u00ebsht\u00eb b\u00ebr\u00eb n\u00eb sistemin e testimit automatik. Mund t\u00eb ndodh\u00eb q\u00eb n\u00eb biblioteka t\u00eb tjera, si JDBC, t\u00eb mos funksionoj\u00eb k\u00ebshtu dhe t\u00eb nevojitet sql proxy<\/em>. Kjo \u00ebsht\u00eb b\u00ebr\u00eb p\u00ebr shkak se p\u00ebr float IP p\u00ebr skllav\u00ebt \u00ebsht\u00eb vendosur nj\u00eb ndales\u00eb p\u00ebr t'u ngjitur n\u00eb t\u00eb nj\u00ebjtin server n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb, n\u00eb m\u00ebnyr\u00eb q\u00eb ata t\u00eb shp\u00ebrndahen n\u00eb m\u00ebnyr\u00eb t\u00eb barabart\u00eb n\u00eb serverat skllav\u00eb, n\u00ebse punojn\u00eb disa.<\/p>\n

<\/p>\n

E dyta: edhe n\u00eb rast d\u00ebshtimi t\u00eb datacenterit do t\u00eb ruhet replikimi i sinkronizuar. Dhe madje edhe n\u00ebse ndodhet nj\u00eb d\u00ebshtim tjet\u00ebr, dmth. nj\u00eb nga dy serverat n\u00eb datacentin e mbetur d\u00ebshtojn\u00eb, klusteri do t\u00eb ndaloj\u00eb t\u00eb ofroj\u00eb sh\u00ebrbime, por prap\u00eb do t\u00eb ruaj\u00eb informacionin mbi t\u00eb gjitha transaksionet e komituara, p\u00ebr t\u00eb cilat ka dh\u00ebn\u00eb konfirmimin e komitimit (nuk do t\u00eb ket\u00eb humbje informacioni n\u00eb rast d\u00ebshtimi t\u00eb dyt\u00eb).<\/p>\n

<\/p>\n

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

<\/p>\n

Struktura<\/h3>\n

<\/p>\n

\"Modelimi<\/p>\n

<\/p>\n

Ky \u00ebsht\u00eb nj\u00eb kluster p\u00ebr situat\u00ebn kur ka tre datacentra q\u00eb funksionojn\u00eb plot\u00ebsisht, n\u00eb secilin prej t\u00eb cil\u00ebve ka nj\u00eb server DB q\u00eb funksionon plot\u00ebsisht. N\u00eb k\u00ebt\u00eb rast quorum device<\/em> nuk \u00ebsht\u00eb e nevojshme. N\u00eb nj\u00eb datacenter funksionon masteri, nd\u00ebrsa n\u00eb dy t\u00eb tjera - skllav\u00ebt. Replikimi \u00ebsht\u00eb sinkron, lloji ANY (slave1, slave2), dometh\u00ebn\u00eb klienti do t\u00eb marr\u00eb nj\u00eb konfirmim t\u00eb komitimit kur ndonj\u00eb nga skllav\u00ebt p\u00ebrgjigjet i pari, se ka pranuar komitimin. Nj\u00eb float IP i tregon burimet p\u00ebr masterin dhe dy p\u00ebr skllav\u00ebt. Ndryshe nga Tuchanka4, t\u00eb tri float IP-t\u00eb jan\u00eb t\u00eb p\u00ebrshtatshme p\u00ebr d\u00ebshtimin. P\u00ebr balancimin e k\u00ebrkesave SQL p\u00ebr vet\u00ebm leximin mund t\u00eb p\u00ebrdoren sql proxy<\/em> (me nj\u00eb q\u00ebndrim t\u00eb ve\u00e7ant\u00eb p\u00ebr d\u00ebshtimet), ose t'u caktohet gjysma e klient\u00ebve nj\u00eb float IP skllav, nd\u00ebrsa gjysma tjet\u00ebr - nj\u00eb tjet\u00ebr.<\/p>\n

<\/p>\n

D\u00ebshtimi i Tuchanka3<\/h3>\n

<\/p>\n

\"Modelimi<\/p>\n

<\/p>\n

Kur d\u00ebshtoni nj\u00eb nga datacentra, mbeten dy. N\u00eb nj\u00ebrin \u00ebsht\u00eb ngritur masteri dhe float IP i masterit, n\u00eb tjetrin - nj\u00eb skllav dhe t\u00eb dy float IP-t\u00eb e skllav\u00ebve (n\u00eb instanc\u00eb duhet t\u00eb ket\u00eb dyfish rezerv\u00eb p\u00ebr burimet, n\u00eb m\u00ebnyr\u00eb q\u00eb t\u00eb pranoj\u00eb t\u00eb gjitha lidhjet nga t\u00eb dy float IP-t\u00eb e skllav\u00ebve). Nd\u00ebrmjet masterit dhe skllavit ka nj\u00eb replikim t\u00eb sinkronizuar. Po ashtu, klusteri do t\u00eb ruaj\u00eb informacionin mbi transaksionet e komituara dhe t\u00eb konfirmuara (nuk do t\u00eb ket\u00eb humbje informacioni) n\u00eb rast shkat\u00ebrrimi t\u00eb dy datacentra (n\u00ebse ato nuk shkat\u00ebrrohen n\u00eb t\u00eb nj\u00ebjt\u00ebn koh\u00eb).<\/p>\n

<\/p>\n

P\u00ebrshkrimi i detajuar i struktur\u00ebs s\u00eb skedar\u00ebve dhe implementimit nuk e kam vendosur. Kushdo q\u00eb do t\u00eb d\u00ebshiroj\u00eb t\u00eb loz\u00eb, mund ta lexoj\u00eb t\u00eb gjith\u00eb k\u00ebt\u00eb n\u00eb README. Un\u00eb vet\u00ebm ofroj p\u00ebrshkrimin e testimit automatik.<\/em><\/p>\n

<\/p>\n

Sistemi i testimit automatik<\/h1>\n

<\/p>\n

P\u00ebr t\u00eb verifikuar p\u00ebrshtatshm\u00ebrin\u00eb e klustereve me simulimin e defekteve t\u00eb ndryshme \u00ebsht\u00eb krijuar nj\u00eb sistem automatizimi. Aktivizohet me skriptin test\/failure<\/code>. Skripti mund t\u00eb pranoj\u00eb si parametra numrat e klustereve q\u00eb d\u00ebshirojn\u00eb t\u00eb testohen. P\u00ebr shembull, ky urdh\u00ebr:<\/p>\n

<\/p>\n

test\/failure 2 3<\/code><\/pre>\n
<\/p>\n
do t\u00eb testoj\u00eb vet\u00ebm klusterin e dyt\u00eb dhe t\u00eb tret\u00eb. N\u00ebse parametrat nuk jan\u00eb caktuar, at\u00ebher\u00eb do t\u00eb testohen t\u00eb gjitha klustert. T\u00eb gjith\u00eb klustert testohen paralelisht, dhe rezultati shfaqet n\u00eb panelin tmux. Tmux p\u00ebrdor nj\u00eb server tmux t\u00eb dedikuar, k\u00ebshtu q\u00eb skripti mund t\u00eb ekzekutohet nga tmux-i default, duke krijuar nj\u00eb tmux t\u00eb thelluar. Rekomandoj p\u00ebrdorimin e terminalit n\u00eb nj\u00eb dritare t\u00eb madhe dhe me nj\u00eb shkronj\u00eb t\u00eb vog\u00ebl. Para fillimit t\u00eb testimit, t\u00eb gjitha virtualet rikthehen n\u00eb nj\u00eb snapshot n\u00eb momentin kur skripti p\u00ebrfundon. setup<\/code>.<\/p>\n
<\/p>\n
\"Modelimi<\/p>\n
<\/p>\n
Terminali \u00ebsht\u00eb i ndar\u00eb n\u00eb kolonat e numrit t\u00eb klaster\u00ebve t\u00eb testuar, me kat\u00ebr prej tyre si\u00e7 \u00ebsht\u00eb treguar n\u00eb screenshot. Do t\u00eb shpjegoj p\u00ebrmbajtjen e kolonave duke p\u00ebrdorur Tuchanka2 si shembull. Panelet n\u00eb screenshot jan\u00eb t\u00eb num\u00ebruara:<\/p>\n
<\/p>\n
    \n
  1. K\u00ebtu shfaqet statistika p\u00ebr testet. Kolonat:\n