{"id":75726,"date":"2020-03-28T07:42:08","date_gmt":"2020-03-28T05:42:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah"},"modified":"2020-03-28T07:42:08","modified_gmt":"2020-03-28T05:42:08","slug":"klaster-iz-dvuh-uzlov-dyavol-v-detalyah","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah","title":{"rendered":"Klastre s dvoma uzlami \u2013 diabol je v detailoch","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ahoj, Habr! Predstavujem v\u00e1m preklad \u010dl\u00e1nku \u201eDva uzly \u2014 Diabol je v detailoch\u201c<\/a><\/noindex> autora Andrewa Beekhoffa.<\/p>\n

Mnoh\u00ed \u013eudia uprednost\u0148uj\u00fa klastre pozost\u00e1vaj\u00face z dvoch uzlov, preto\u017ee sa javia konceptu\u00e1lne jednoduch\u0161ie a s\u00fa navy\u0161e o 33 % lacnej\u0161ie ako ich trojuzlov\u00e9 n\u00e1protivky. Aj ke\u010f je celkom re\u00e1lne zostavi\u0165 dobr\u00fd klaster z dvoch uzlov, v mnoh\u00fdch pr\u00edpadoch, kv\u00f4li nezoh\u013eadnen\u00fdm scen\u00e1rom, tak\u00e1to konfigur\u00e1cia vytvor\u00ed mno\u017estvo nejasn\u00fdch probl\u00e9mov.
\n<\/a><\/noindex>
\nPrv\u00fdm krokom k vytvoreniu akejko\u013evek vysoko dostupnej syst\u00e9mu je identifik\u00e1cia a sna\u017eenie sa odstr\u00e1ni\u0165 jednotliv\u00e9 body zlyhania, \u010dasto skr\u00e1tene naz\u00fdvan\u00e9 SPoF<\/i> (single point of failure).<\/p>\n

Je potrebn\u00e9 ma\u0165 na pam\u00e4ti, \u017ee v \u017eiadnom syst\u00e9me nie je mo\u017en\u00e9 eliminova\u0165 v\u0161etky mo\u017en\u00e9 rizik\u00e1 v\u00fdpadku. To vypl\u00fdva aspo\u0148 z toho, \u017ee typickou ochranou pred rizikom je zavedenie ur\u010ditej nadbyto\u010dnosti, \u010do vedie k zv\u00fd\u0161eniu zlo\u017eitosti syst\u00e9mu a vzniku nov\u00fdch zlyhan\u00ed. Preto zo za\u010diatku ideme na kompromis a s\u00fastre\u010fujeme sa na udalosti vz\u0165ahuj\u00face sa na jednotliv\u00e9 body zlyhania, a nie na re\u0165azce s\u00favisiacich a teda \u010doraz menej pravdepodobn\u00fdch udalost\u00ed.<\/p>\n

Zoh\u013ead\u0148uj\u00fac kompromisy, nielen\u017ee h\u013ead\u00e1me SPoF, ale tie\u017e vyva\u017eujeme rizik\u00e1 a n\u00e1sledky, \u010do vedie k z\u00e1veru, \u017ee to, \u010do je kritick\u00e9, a \u010do nie, sa m\u00f4\u017ee l\u00ed\u0161i\u0165 pre ka\u017ed\u00e9 nasadenie.<\/p>\n

Nie v\u0161etk\u00fdm s\u00fa potrebn\u00ed alternat\u00edvni dod\u00e1vatelia elektriny s nez\u00e1visl\u00fdmi elektrick\u00fdmi l\u00edniami. Hoci paranoia sa vyplatila aspo\u0148 pre jedn\u00e9ho klienta, ke\u010f ich monitoring odhalil chybn\u00fd transform\u00e1tor. Z\u00e1kazn\u00edk volal, sna\u017eiac sa upozorni\u0165 energetick\u00fa spolo\u010dnos\u0165, k\u00fdm chybn\u00fd transform\u00e1tor nevybuchol.<\/p><\/blockquote>\n

\nPrirodzen\u00fdm v\u00fdchodiskov\u00fdm bodom je ma\u0165 v syst\u00e9me viac ako jeden uzol. Av\u0161ak predt\u00fdm, ne\u017e syst\u00e9m m\u00f4\u017ee presun\u00fa\u0165 slu\u017eby na zost\u00e1vaj\u00faci uzol po v\u00fdpadku, vo v\u0161eobecnosti je potrebn\u00e9 zabezpe\u010di\u0165, \u017ee pres\u00favan\u00e9 slu\u017eby nie s\u00fa akt\u00edvne na inom mieste.<\/p>\n

Dvojuzlov\u00fd klaster nem\u00e1 nev\u00fdhody, ak v pr\u00edpade zlyhania oba uzly obsluhuj\u00fa rovnak\u00fa statick\u00fa webov\u00fa str\u00e1nku. Av\u0161ak v\u0161etko sa men\u00ed, ak obe strany nez\u00e1visle spravuj\u00fa spolo\u010dn\u00fa frontu \u00faloh alebo poskytuj\u00fa nekoordinovan\u00fd pr\u00edstup na z\u00e1pis do replikovanej datab\u00e1zy alebo spolo\u010dnej s\u00faborovej s\u00fastavy.<\/p>\n

Preto, aby sme predi\u0161li po\u0161kodeniu \u00fadajov v d\u00f4sledku zlyhania jedn\u00e9ho uzla \u2013 spoliehame sa na to, \u010do sa naz\u00fdva \u201eoddelenie\u201c<\/i> (fencing).<\/p>\n

Princ\u00edp oddelenia<\/h2>\n

\nZ\u00e1kladn\u00fdm ot\u00e1zkou princ\u00edpu oddelenia je: m\u00f4\u017ee konkuren\u010dn\u00fd uzol sp\u00f4sobi\u0165 po\u0161kodenie \u00fadajov? Ak je po\u0161kodenie \u00fadajov pravdepodobn\u00fdm scen\u00e1rom \u2013 dobr\u00fdm rie\u0161en\u00edm bude izolova\u0165 uzol od prich\u00e1dzaj\u00facich po\u017eiadaviek, ako aj od trval\u00e9ho \u00falo\u017eiska. Najroz\u0161\u00edrenej\u0161\u00edm pr\u00edstupom k oddeleniu je odpojenie poruchov\u00fdch uzlov.<\/p>\n

Existuj\u00fa dve kateg\u00f3rie met\u00f3d oddelenia, ktor\u00e9 nazvem priamymi<\/i> a nepriamymi<\/i>, ale rovnako ich mo\u017eno nazva\u0165 akt\u00edvnymi<\/i> a pas\u00edvnymi<\/i>. Priame met\u00f3dy zah\u0155\u0148aj\u00fa \u010dinnosti zo strany pre\u017e\u00edvaj\u00facich rovnocenn\u00fdch uzlov, ako je interakcia s zariaden\u00edm IPMI (Intelligent Platform Management Interface \u2013 rozhranie na vzdialen\u00e9 monitorovanie a spr\u00e1vu fyzick\u00e9ho stavu servera) alebo iLO (mechanizmus spr\u00e1vy serverov v podmienkach nedostatku fyzick\u00e9ho pr\u00edstupu k nim), zatia\u013e \u010do nepriam\u00e9 met\u00f3dy sa spoliehaj\u00fa na zlyh\u00e1vaj\u00faci uzol, aby nejak\u00fdm sp\u00f4sobom spoznal, \u017ee je v nezdravom stave (alebo aspo\u0148 br\u00e1ni ostatn\u00fdm \u010dlenom v regener\u00e1cii) a signalizoval hardware watchdog<\/a><\/noindex> o potrebe odpoji\u0165 zlyh\u00e1vaj\u00faci uzol.<\/p>\n

Kvorum pom\u00e1ha pri pou\u017e\u00edvan\u00ed ako priamych, tak aj nepriamych met\u00f3d.<\/p>\n

Priame oddelenie<\/h3>\n

\nV pr\u00edpade priameho oddelenia m\u00f4\u017eeme pou\u017ei\u0165 kvorum na zabr\u00e1nenie prete\u010deniu oddelenia v pr\u00edpade zlyhania siete.<\/p>\n

S koncepciou kvorumu m\u00e1 syst\u00e9m dostatok inform\u00e1ci\u00ed (aj bez pripojenia k svojim partnerom), aby uzly automaticky vedeli, \u010di by mali iniciova\u0165 oddelenie a \/ alebo obnovu.<\/p>\n

Bez kvorumu maj\u00fa obidve strany sie\u0165ov\u00e9ho rozdelenia opr\u00e1vnen\u00fa predstavu, \u017ee druh\u00e1 strana je m\u0155tva, a bud\u00fa sa sna\u017ei\u0165 oddeli\u0165 druh\u00e9ho. V najhor\u0161om pr\u00edpade sa obom stran\u00e1m podar\u00ed odpoji\u0165 cel\u00fd klaster. Alternat\u00edvny scen\u00e1r \u2013 deathmatch, nekone\u010dn\u00fd cyklus uzlov, ktor\u00e9 sa objavuj\u00fa, nevidia svojich partnerov, re\u0161tartuj\u00fa ich a iniciuj\u00fa obnovu len preto, aby sa re\u0161tartovali, ke\u010f ich partner prejde rovnakou logikou.<\/p>\n

Probl\u00e9m s oddelen\u00edm spo\u010d\u00edva v tom, \u017ee naj\u010dastej\u0161ie pou\u017e\u00edvan\u00e9 zariadenia sa st\u00e1vaj\u00fa nedostupn\u00fdmi kv\u00f4li t\u00fdm ist\u00fdm udalostiam zlyhania, na ktor\u00e9 sa chceme zamera\u0165 pri obnove. V\u00e4\u010d\u0161ina IPMI a iLO kariet je nain\u0161talovan\u00e1 na hostite\u013eoch, ktor\u00e9 kontroluj\u00fa, a predvolene pou\u017e\u00edvaj\u00fa t\u00fa ist\u00fa sie\u0165, \u010do sp\u00f4sobuje, \u017ee cie\u013eov\u00e9 uzly predpokladaj\u00fa, \u017ee ostatn\u00e9 uzly s\u00fa offline.<\/p>\n

\u017dia\u013e, vlastnosti fungovania zariaden\u00ed IPMI a iLO sa zriedka posudzuj\u00fa v momente n\u00e1kupu vybavenia.<\/p>\n

Nepriam\u00e9 oddelenie<\/h3>\n

\nKvorum je tie\u017e d\u00f4le\u017eit\u00e9 na riadenie nepriamych oddelen\u00ed. Ak je v\u0161etko spr\u00e1vne nastaven\u00e9, kvorum m\u00f4\u017ee umo\u017eni\u0165 pre\u017eiv\u0161\u00edm predpoklada\u0165, \u017ee straten\u00e9 uzly prejd\u00fa do bezpe\u010dn\u00e9ho stavu po ur\u010ditom \u010dase.<\/p>\n

Pri tomto nastaven\u00ed sa hardv\u00e9rov\u00fd watchdog timer resetuje ka\u017ed\u00fdch N sek\u00fand, ak ned\u00f4jde k strate kvoru. Ak timer (zvy\u010dajne nieko\u013eko n\u00e1sobkov N) uplynie, zariadenie vykon\u00e1 ne\u0161etrn\u00e9 vypnutie nap\u00e1jania (nie shutdown).<\/p>\n

Tento pr\u00edstup je ve\u013emi efekt\u00edvny, ale bez kvoru na jeho riadenie nie s\u00fa v r\u00e1mci klastra dostato\u010dn\u00e9 inform\u00e1cie. Nie je \u013eahk\u00e9 rozl\u00ed\u0161i\u0165 medzi odpojen\u00edm siete a zlyhan\u00edm uzla partnera. D\u00f4vod, pre\u010do to m\u00e1 v\u00fdznam, spo\u010d\u00edva v tom, \u017ee bez mo\u017enosti rozli\u0161ova\u0165 medzi t\u00fdmito dvoma pr\u00edpadmi mus\u00edte zvoli\u0165 rovnak\u00fd sp\u00f4sob spr\u00e1vania v oboch pr\u00edpadoch.<\/p>\n

Probl\u00e9m s vo\u013ebou jedn\u00e9ho re\u017eimu spo\u010d\u00edva v tom, \u017ee neexistuje sp\u00f4sob, ako maximalizova\u0165 dostupnos\u0165 a zabr\u00e1ni\u0165 strate d\u00e1t.<\/p>\n