{"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\/cs\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah","title":{"rendered":"Cluster ze dvou uzl\u016f \u2013 \u010f\u00e1bel je v detailu","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Ahoj, Habr! P\u0159edstavuji v\u00e1m p\u0159eklad \u010dl\u00e1nku <noindex><a rel=\"nofollow\" href=\"http:\/\/blog.clusterlabs.org\/blog\/2018\/two-node-problems\">\u00abDva uzly \u2014 \u010e\u00e1bel je skryt v detailech\u00bb<\/a><\/noindex> autor Andrew Beekhof.<\/p>\n<p>Mnoho lid\u00ed d\u00e1v\u00e1 p\u0159ednost cluster\u016fm tvo\u0159en\u00fdm ze dvou uzl\u016f, proto\u017ee se zdaj\u00ed b\u00fdt konceptu\u00e1ln\u011b jednodu\u0161\u0161\u00ed a nav\u00edc jsou o 33 % levn\u011bj\u0161\u00ed ne\u017e jejich t\u0159\u00eduzlov\u00e9 prot\u011bj\u0161ky. A\u010dkoli je mo\u017en\u00e9 sestavit dobr\u00fd cluster ze dvou uzl\u016f, v mnoha p\u0159\u00edpadech tato konfigurace, kv\u016fli nevy\u0159e\u0161en\u00fdm sc\u00e9n\u00e1\u0159\u016fm, vytvo\u0159\u00ed \u0159adu neviditeln\u00fdch probl\u00e9m\u016f.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nPrvn\u00edm krokem k vytvo\u0159en\u00ed jak\u00e9hokoli syst\u00e9mu s vysokou dostupnost\u00ed je hledat a pokusit se odstranit jednotliv\u00e9 body selh\u00e1n\u00ed, \u010dasto zkr\u00e1cen\u011b naz\u00fdvan\u00e9 <i>SPoF<\/i> (single point of failure).<\/p>\n<p>Je t\u0159eba m\u00edt na pam\u011bti, \u017ee v jak\u00e9mkoli syst\u00e9mu nen\u00ed mo\u017en\u00e9 eliminovat v\u0161echny mo\u017en\u00e9 rizika v\u00fdpadku. To vypl\u00fdv\u00e1 alespo\u0148 z faktu, \u017ee typickou ochranou proti riziku je zaveden\u00ed ur\u010dit\u00e9 redundantnosti, co\u017e zvy\u0161uje slo\u017eitost syst\u00e9mu a vytv\u00e1\u0159\u00ed nov\u00e9 body selh\u00e1n\u00ed. Proto ji\u017e na za\u010d\u00e1tku jsme ochotni vyjedn\u00e1vat a soust\u0159ed\u00edme se na ud\u00e1losti souvisej\u00edc\u00ed s jednotliv\u00fdmi body selh\u00e1n\u00ed, nikoli na souvisej\u00edc\u00ed a tud\u00ed\u017e st\u00e1le m\u00e9n\u011b pravd\u011bpodobn\u00e9 ud\u00e1losti.<\/p>\n<p>Vz\u00edt v \u00favahu kompromisy, hled\u00e1me nejen SPoF, ale tak\u00e9 vyva\u017eujeme rizika a d\u016fsledky, co\u017e znamen\u00e1, \u017ee z\u00e1v\u011bry o tom, co je kritick\u00e9, mohou b\u00fdt pro ka\u017ed\u00e9 nasazen\u00ed odli\u0161n\u00e9.<\/p>\n<blockquote><p>Ne v\u0161ichni pot\u0159ebuj\u00ed alternativn\u00ed dodavatele energie s nez\u00e1visl\u00fdmi elektrop\u0159enosov\u00fdmi liniemi. A\u010dkoli paranoidn\u00ed p\u0159\u00edstup se vyplatil alespo\u0148 jednomu klientovi, kdy\u017e jejich monitoring odhalil vadn\u00fd transform\u00e1tor. Z\u00e1kazn\u00edk volal a sna\u017eil se varovat energetickou spole\u010dnost, dokud se vadn\u00fd transform\u00e1tor nevybuchl.<\/p><\/blockquote>\n<p>\nP\u0159irozen\u00fdm v\u00fdchoz\u00edm bodem je m\u00edt v syst\u00e9mu v\u00edce ne\u017e jeden uzel. Nicm\u00e9n\u011b, ne\u017e syst\u00e9m bude moci p\u0159esunout slu\u017eby na zb\u00fdvaj\u00edc\u00ed \u017eiv\u00fd uzel po selh\u00e1n\u00ed, v z\u00e1sad\u011b je t\u0159eba zajistit, \u017ee p\u0159esouvan\u00e9 slu\u017eby nejsou aktivn\u00ed na jin\u00e9m m\u00edst\u011b.<\/p>\n<p>Dvouuzlov\u00fd cluster nem\u00e1 nev\u00fdhody, pokud p\u0159i selh\u00e1n\u00ed oba uzly obsluhuj\u00ed stejnou statickou webovou str\u00e1nku. Nicm\u00e9n\u011b v\u0161echno se m\u011bn\u00ed, pokud ob\u011b strany nez\u00e1visle spravuj\u00ed spole\u010dnou frontu \u00faloh nebo poskytuj\u00ed nekoordinovan\u00fd p\u0159\u00edstup pro z\u00e1pis k replikovan\u00e9 datab\u00e1zi nebo sd\u00edlen\u00e9mu souborov\u00e9mu syst\u00e9mu.<\/p>\n<p>Proto, abyste zabr\u00e1nili po\u0161kozen\u00ed dat v d\u016fsledku selh\u00e1n\u00ed jednoho uzlu, spol\u00e9h\u00e1me se na to, co se naz\u00fdv\u00e1 <i>\u201eodizolov\u00e1n\u00ed\u201c<\/i> (fencing).<\/p>\n<h2>Princip odizolov\u00e1n\u00ed<\/h2>\n<p>\nZ\u00e1kladn\u00edm ot\u00e1zkou principu odizolov\u00e1n\u00ed je, zda m\u016f\u017ee konkuren\u010dn\u00ed uzel zp\u016fsobit po\u0161kozen\u00ed dat. Pokud je po\u0161kozen\u00ed dat pravd\u011bpodobn\u00fdm sc\u00e9n\u00e1\u0159em, je dobr\u00fdm \u0159e\u0161en\u00edm izolace uzlu jak od p\u0159\u00edchoz\u00edch po\u017eadavk\u016f, tak od trval\u00e9ho \u00falo\u017ei\u0161t\u011b. Nejb\u011b\u017en\u011bj\u0161\u00edm p\u0159\u00edstupem k odizolov\u00e1n\u00ed je odpojen\u00ed vadn\u00fdch uzl\u016f.<\/p>\n<p>Existuj\u00ed dv\u011b kategorie metod odizolov\u00e1n\u00ed, kter\u00e9 nazvu <i>p\u0159\u00edm\u00e9<\/i> a <i>nep\u0159\u00edm\u00e9<\/i>, ale v rovn\u00e9 m\u00ed\u0159e je lze nazvat <i>aktivn\u00edmi<\/i> a <i>pasivn\u00edmi<\/i>. P\u0159\u00edm\u00e9 metody zahrnuj\u00ed akce p\u0159e\u017eiv\u0161\u00edch rovnocenn\u00fdch uzl\u016f, jako je interakce s za\u0159\u00edzen\u00edmi IPMI (Intelligent Platform Management Interface \u2014 rozhran\u00ed pro vzd\u00e1len\u00e9 sledov\u00e1n\u00ed a spr\u00e1vu fyzick\u00e9ho stavu serveru) nebo iLO (mechanismus spr\u00e1vy server\u016f v podm\u00ednk\u00e1ch absence fyzick\u00e9ho p\u0159\u00edstupu k nim), zat\u00edmco nep\u0159\u00edm\u00e9 metody spol\u00e9haj\u00ed na selh\u00e1vaj\u00edc\u00ed uzel, aby n\u011bjak rozpoznal, \u017ee se nach\u00e1z\u00ed v nezdrav\u00e9m stavu (nebo alespo\u0148 br\u00e1n\u00ed ostatn\u00edm \u010dlen\u016fm v obnov\u011b) a signalizoval <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Watchdog_timer\">hardware watchdog<\/a><\/noindex> o nutnosti odpojen\u00ed selh\u00e1vaj\u00edc\u00edho uzlu.<\/p>\n<p>Kvorum pom\u00e1h\u00e1 v p\u0159\u00edpad\u011b pou\u017eit\u00ed jak p\u0159\u00edm\u00fdch, tak nep\u0159\u00edm\u00fdch metod.<\/p>\n<h3>P\u0159\u00edm\u00e9 odizolov\u00e1n\u00ed<\/h3>\n<p>\nV p\u0159\u00edpad\u011b p\u0159\u00edm\u00e9ho odizolov\u00e1n\u00ed m\u016f\u017eeme pou\u017e\u00edt kvorum k prevenci z\u00e1vod\u016f odizolov\u00e1n\u00ed v p\u0159\u00edpad\u011b selh\u00e1n\u00ed s\u00edt\u011b.<\/p>\n<p>P\u0159i zaveden\u00ed konceptu kvorum m\u00e1 syst\u00e9m dostatek informac\u00ed (i bez p\u0159ipojen\u00ed k partner\u016fm), aby uzly automaticky v\u011bd\u011bly, zda by m\u011bly iniciovat odizolov\u00e1n\u00ed a\/nebo obnovu.<\/p>\n<p>Bez kvorum si ob\u011b strany s\u00ed\u0165ov\u00e9ho rozd\u011blen\u00ed opr\u00e1vn\u011bn\u011b p\u0159edpokl\u00e1daj\u00ed, \u017ee druh\u00e1 strana je mrtv\u00e1, a budou usilovat o odizolov\u00e1n\u00ed druh\u00e9ho. V nejhor\u0161\u00edm p\u0159\u00edpad\u011b se ob\u011b strany poda\u0159\u00ed odpojit cel\u00fd cluster. Alternativn\u00edm sc\u00e9n\u00e1\u0159em je deathmatch, nekone\u010dn\u00fd cyklus uzl\u016f, kter\u00e9 se objevuj\u00ed, nevid\u00ed sv\u00e9 prot\u011bj\u0161ky, restartuj\u00ed je a iniciuj\u00ed obnovu jen proto, aby se restartovaly, kdy\u017e jejich prot\u011bj\u0161ek projde stejnou logikou.<\/p>\n<p>Probl\u00e9m s od\u0161krt\u00e1n\u00edm spo\u010d\u00edv\u00e1 v tom, \u017ee nej\u010dast\u011bji pou\u017e\u00edvan\u00e1 za\u0159\u00edzen\u00ed se st\u00e1vaj\u00ed nedostupn\u00fdmi kv\u016fli stejn\u00fdm ud\u00e1lostem selh\u00e1n\u00ed, na kter\u00e9 se chceme zam\u011b\u0159it pro obnoven\u00ed. V\u011bt\u0161ina karet IPMI a iLO je nainstalov\u00e1na na hostitel\u00edch, kter\u00e9 ovl\u00e1daj\u00ed, a ve v\u00fdchoz\u00edm nastaven\u00ed pou\u017e\u00edvaj\u00ed stejnou s\u00ed\u0165, co\u017e zp\u016fsobuje, \u017ee c\u00edlov\u00e9 uzly se domn\u00edvaj\u00ed, \u017ee ostatn\u00ed uzly jsou offline.<\/p>\n<p>Bohu\u017eel se zvl\u00e1\u0161tnosti funkce za\u0159\u00edzen\u00ed IPMI a iLo z\u0159\u00eddka zva\u017euj\u00ed v okam\u017eiku n\u00e1kupu hardwaru.<\/p>\n<h3>Nep\u0159\u00edm\u00e9 od\u0161krt\u00e1n\u00ed<\/h3>\n<p>\nKvorum je tak\u00e9 d\u016fle\u017eit\u00e9 pro spr\u00e1vu nep\u0159\u00edm\u00fdch od\u0161krt\u00e1n\u00ed; pokud je v\u0161e dob\u0159e nastaveno, kvorum m\u016f\u017ee umo\u017enit p\u0159e\u017eiv\u0161\u00edm p\u0159edpokl\u00e1dat, \u017ee ztracen\u00e9 uzly se po ur\u010dit\u00e9 dob\u011b dostanou do bezpe\u010dn\u00e9ho stavu.<\/p>\n<p>P\u0159i takov\u00e9m nastaven\u00ed se hardware watchdog resetuje ka\u017ed\u00fdch N sekund, pokud nen\u00ed ztraceno kvorum. Pokud \u010dasova\u010d (obvykle n\u011bkolikr\u00e1t N) vypr\u0161\u00ed, za\u0159\u00edzen\u00ed provede ne\u0161etrn\u00e9 vypnut\u00ed nap\u00e1jen\u00ed (ne shutdown).<\/p>\n<p>Tento p\u0159\u00edstup je velmi efektivn\u00ed, ale bez kvorum pro jeho spr\u00e1vu v\u0161ak uvnit\u0159 klastru chyb\u00ed dostatek informac\u00ed. Nen\u00ed snadn\u00e9 rozli\u0161it mezi odpojen\u00edm s\u00edt\u011b a selh\u00e1n\u00edm uzlu-partnera. D\u016fvod, pro\u010d na tom z\u00e1le\u017e\u00ed, spo\u010d\u00edv\u00e1 v tom, \u017ee bez mo\u017enosti rozli\u0161ovat mezi t\u011bmito dv\u011bma p\u0159\u00edpady mus\u00edte zvolit stejn\u00fd re\u017eim chov\u00e1n\u00ed v obou situac\u00edch.<\/p>\n<p>Probl\u00e9m s v\u00fdb\u011brem jednoho re\u017eimu spo\u010d\u00edv\u00e1 v tom, \u017ee neexistuje \u017e\u00e1dn\u00fd zp\u016fsob, jak postupovat, kter\u00fd by maximalizoval dostupnost a zabr\u00e1nil ztr\u00e1t\u011b dat.<\/p>\n<ul>\n<li>Pokud se rozhodnete p\u0159edpokl\u00e1dat, \u017ee uzel-partner je aktivn\u00ed, ale ve skute\u010dnosti do\u0161lo k selh\u00e1n\u00ed, klastr zbyte\u010dn\u011b zastav\u00ed slu\u017eby, kter\u00e9 by m\u011bly fungovat kv\u016fli kompenzaci ztr\u00e1ty slu\u017eeb selhan\u00e9ho uzlu-partnera.<\/li>\n<li>Pokud se rozhodnete p\u0159edpokl\u00e1dat, \u017ee uzel nefunguje, ale \u0161lo pouze o selh\u00e1n\u00ed s\u00edt\u011b a ve skute\u010dnosti vzd\u00e1len\u00fd uzel funguje, pak se v lep\u0161\u00edm p\u0159\u00edpad\u011b zavazujete k budouc\u00ed ru\u010dn\u00ed kontrole v\u00fdsledn\u00fdch datov\u00fdch sad.<\/li>\n<\/ul>\n<p>\nBez ohledu na to, jakou heuristiku pou\u017e\u00edv\u00e1te, je trivi\u00e1ln\u00ed vytvo\u0159it selh\u00e1n\u00ed, kter\u00e9 bu\u010f donut\u00ed ob\u011b strany pracovat, nebo p\u0159im\u011bje klastr vypnout p\u0159e\u017eiv\u0161\u00ed uzly. Nepou\u017e\u00edv\u00e1n\u00ed kvorum skute\u010dn\u011b zbavuje klastr jednoho z nejmocn\u011bj\u0161\u00edch n\u00e1stroj\u016f ve sv\u00e9m arzen\u00e1lu.<\/p>\n<p>Pokud neexistuje jin\u00e1 alternativa, nejlep\u0161\u00ed p\u0159\u00edstup je ob\u011btovat dostupnost (autor odkazuje na CAP teor\u00e9m). Vysok\u00e1 dostupnost po\u0161kozen\u00fdch dat nikomu nepom\u00e1h\u00e1 a ru\u010dn\u00ed kontrola r\u016fzn\u00fdch datov\u00fdch sad tak\u00e9 nen\u00ed p\u0159\u00edjemn\u00e1.<\/p>\n<h2>Kv\u00f3rum<\/h2>\n<p>\nKv\u00f3rum zn\u00ed skv\u011ble, \u017ee?<\/p>\n<p>Jedinou nev\u00fdhodou je, \u017ee aby bylo mo\u017en\u00e9 m\u00edt jej ve shluku s N \u010dleny, je t\u0159eba, aby z\u016fstalo p\u0159ipojen\u00ed mezi N \/ 2 + 1 va\u0161ich uzl\u016f. Co\u017e je nemo\u017en\u00e9 ve shluku se dv\u011bma uzly po selh\u00e1n\u00ed jednoho uzlu.<\/p>\n<p>Co n\u00e1s nakonec p\u0159iv\u00e1d\u00ed k z\u00e1kladn\u00edmu probl\u00e9mu se dv\u011bma uzly:<br \/>\nkv\u00f3rum nem\u00e1 smysl ve dvouuzlov\u00fdch clusterech a bez n\u011bj nen\u00ed mo\u017en\u00e9 spolehliv\u011b ur\u010dit postup, kter\u00fd maximalizuje dostupnost a zabra\u0148uje ztr\u00e1t\u011b dat.<br \/>\nI v syst\u00e9mu se dv\u011bma uzly spojen\u00fdmi k\u0159\u00ed\u017eov\u00fdm kabelem nen\u00ed mo\u017en\u00e9 kone\u010dn\u011b rozli\u0161it mezi odpojen\u00edm s\u00edt\u011b a selh\u00e1n\u00edm druh\u00e9ho uzlu. Odpojen\u00ed jednoho konce (jeho\u017e pravd\u011bpodobnost je bezpochyby \u00fam\u011brn\u00e1 vzd\u00e1lenosti mezi uzly) bude sta\u010dit k vyvr\u00e1cen\u00ed jak\u00e9hokoli p\u0159edpokladu, \u017ee provozuschopnost kan\u00e1lu se rovn\u00e1 zdrav\u00ed partnersk\u00e9ho uzlu.<\/p>\n<h3>P\u0159im\u011bt k fungov\u00e1n\u00ed cluster ze dvou uzl\u016f<\/h3>\n<p>\nN\u011bkdy klient nem\u016f\u017ee nebo nechce dokoupit t\u0159et\u00ed uzel a jsme nuceni hledat alternativu.<\/p>\n<h4>Varianta 1 \u2014 Duplicitn\u00ed metoda rozpojen\u00ed<\/h4>\n<p>\nZa\u0159\u00edzen\u00ed iLO nebo IPMI uzlu p\u0159edstavuje bod selh\u00e1n\u00ed, proto\u017ee v p\u0159\u00edpad\u011b v\u00fdpadku jej zb\u00fdvaj\u00edc\u00ed uzly nemohou pou\u017e\u00edt k p\u0159epnut\u00ed uzlu do bezpe\u010dn\u00e9ho stavu. V clusteru se 3 nebo v\u00edce uzly m\u016f\u017eeme tuto situaci zm\u00edrnit v\u00fdpo\u010dtem kv\u00f3rum a vyu\u017eit\u00edm hardware watchdog (mechanismus nep\u0159\u00edm\u00e9ho odpojen\u00ed, jak bylo diskutov\u00e1no d\u0159\u00edve). V p\u0159\u00edpad\u011b dvou uzl\u016f mus\u00edme m\u00edsto toho pou\u017e\u00edt p\u0159ep\u00edna\u010de nap\u00e1jen\u00ed (power distribution units nebo PDUs).<\/p>\n<p>Po selh\u00e1n\u00ed se p\u0159e\u017eiv\u0161\u00ed nejprve pokou\u0161\u00ed nav\u00e1zat spojen\u00ed s hlavn\u00edm rozpojen\u00fdm za\u0159\u00edzen\u00edm (integrovan\u00fdm iLO nebo IPMI). Pokud se to poda\u0159\u00ed, obnova pokra\u010duje jako obvykle. Pouze v p\u0159\u00edpad\u011b selh\u00e1n\u00ed za\u0159\u00edzen\u00ed iLO \/ IPMI dojde k dotazu na PDU, pokud je dotaz \u00fasp\u011b\u0161n\u00fd, m\u016f\u017ee obnova pokra\u010dovat.<\/p>\n<p>PDU um\u00edst\u011bte do s\u00edt\u011b odd\u011blen\u00e9 od provozu clusteru, jinak m\u016f\u017ee jedin\u00e9 selh\u00e1n\u00ed s\u00edt\u011b zablokovat p\u0159\u00edstup jak k za\u0159\u00edzen\u00edm k dispozici, tak k obnoven\u00ed slu\u017eeb.<\/p>\n<p>M\u016f\u017eete se pt\u00e1t \u2013 je za\u0159\u00edzen\u00ed PDU jedin\u00fdm bodem selh\u00e1n\u00ed? Odpov\u011b\u010f zn\u00ed \u2014 samoz\u0159ejm\u011b, \u017ee je.<\/p>\n<p>Pokud je toto riziko pro v\u00e1s v\u00fdznamn\u00e9 \u2014 nejste sami: p\u0159ipojte oba uzly k dv\u011bma PDU a nastavte clusterov\u00fd software, aby pou\u017e\u00edval ob\u011b p\u0159i zap\u00edn\u00e1n\u00ed a vyp\u00edn\u00e1n\u00ed uzl\u016f. Nyn\u00ed z\u016fst\u00e1v\u00e1 cluster aktivn\u00ed, pokud jedno PDU sel\u017ee, a pro zablokov\u00e1n\u00ed obnovy bude pot\u0159ebovat druh\u00e9 selh\u00e1n\u00ed bu\u010f jin\u00e9ho PDU, nebo za\u0159\u00edzen\u00ed IPMI.<\/p>\n<h4>Varianta 2 \u2014 P\u0159id\u00e1n\u00ed arbitra<\/h4>\n<p>\nV n\u011bkter\u00fdch sc\u00e9n\u00e1\u0159\u00edch, a\u010dkoliv je technicky mo\u017en\u00e9 pou\u017e\u00edt metodu du\u00e1ln\u00edho odm\u011b\u0159ov\u00e1n\u00ed, je to politicky slo\u017eit\u00e9. Mnoho firem d\u00e1v\u00e1 p\u0159ednost ur\u010dit\u00e9mu rozd\u011blen\u00ed mezi spr\u00e1vci a vlastn\u00edky aplikac\u00ed, a s\u00ed\u0165ov\u00ed administr\u00e1to\u0159i, kte\u0159\u00ed se staraj\u00ed o bezpe\u010dnost, ne v\u017edy s nad\u0161en\u00edm p\u0159ed\u00e1vaj\u00ed p\u0159\u00edstupov\u00e9 parametry k PDU n\u011bkomu jin\u00e9mu.<\/p>\n<p>V tomto p\u0159\u00edpad\u011b je doporu\u010denou alternativou vytvo\u0159it neutr\u00e1ln\u00ed t\u0159et\u00ed stranu, kter\u00e1 m\u016f\u017ee doplnit v\u00fdpo\u010det kvoru.<\/p>\n<p>V p\u0159\u00edpad\u011b selh\u00e1n\u00ed mus\u00ed m\u00edt uzel mo\u017enost vid\u011bt sv\u016fj prot\u011bj\u0161ek nebo arbitra, aby bylo mo\u017en\u00e9 obnovit slu\u017eby. Arbitra tak\u00e9 zahrnuje funkci p\u0159eru\u0161en\u00ed spojen\u00ed, pokud oba uzly mohou vid\u011bt arbitra, ale nevid\u00ed se navz\u00e1jem.<\/p>\n<p>Tato volba by m\u011bla b\u00fdt pou\u017e\u00edv\u00e1na v p\u00e1ru s nep\u0159\u00edmou metodou odm\u011b\u0159ov\u00e1n\u00ed, jako je hardware watchdog \u010dasova\u010d, kter\u00fd je nastaven na vypnut\u00ed stroje, pokud ztrat\u00ed spojen\u00ed se sv\u00fdm uzlem-partnerem a arbitrem. T\u00edmto zp\u016fsobem m\u016f\u017ee p\u0159e\u017eiv\u0161\u00ed s dostate\u010dnou jistotou p\u0159edpokl\u00e1dat, \u017ee jeho uzel-partner bude v bezpe\u010dn\u00e9m stavu po uplynut\u00ed doby platnosti hardware watchdog \u010dasova\u010de.<\/p>\n<p>Praktick\u00fd rozd\u00edl mezi arbitrem a t\u0159et\u00edm uzlem spo\u010d\u00edv\u00e1 v tom, \u017ee arbitr vy\u017eaduje mnohem m\u00e9n\u011b zdroj\u016f pro svoji \u010dinnost a potenci\u00e1ln\u011b m\u016f\u017ee obsluhovat v\u00edce ne\u017e jeden cluster.<\/p>\n<h4>Varianta 3 \u2014 Lidsk\u00fd faktor<\/h4>\n<p>\nPosledn\u00ed p\u0159\u00edstup spo\u010d\u00edv\u00e1 v tom, \u017ee p\u0159e\u017eiv\u0161\u00ed pokra\u010duj\u00ed v pln\u011bn\u00ed jak\u00fdchkoli slu\u017eeb, kter\u00e9 ji\u017e vykon\u00e1vali, ale neza\u010dnou nov\u00e9, dokud se probl\u00e9m nevy\u0159e\u0161\u00ed s\u00e1m (obnoven\u00ed s\u00edt\u011b, restart uzlu) nebo dokud si n\u011bkdo nep\u0159evezme odpov\u011bdnost za ru\u010dn\u00ed potvrzen\u00ed, \u017ee druh\u00e1 strana je mrtv\u00e1.<\/p>\n<h4>Bonusov\u00e1 mo\u017enost<\/h4>\n<p>\nU\u017e jsem zm\u00ednil, \u017ee m\u016f\u017eete p\u0159idat t\u0159et\u00ed uzel?<\/p>\n<h2>Dv\u011b stojany<\/h2>\n<p>\nPro argumentaci si p\u0159edstavme, \u017ee jsem v\u00e1s p\u0159esv\u011bd\u010dil o v\u00fdhod\u00e1ch t\u0159et\u00edho uzlu, nyn\u00ed mus\u00edme zv\u00e1\u017eit fyzick\u00e9 um\u00edst\u011bn\u00ed uzl\u016f. Pokud jsou um\u00edst\u011bny (a nap\u00e1jeny) ve stejn\u00e9m stojanu, p\u0159edstavuje to tak\u00e9 SPoF, co\u017e nelze vy\u0159e\u0161it p\u0159id\u00e1n\u00edm druh\u00e9ho stojanu.<\/p>\n<p>Pokud je to p\u0159ekvapuj\u00edc\u00ed, zamyslete se, co se stane, pokud se stojan se dv\u011bma uzly porouch\u00e1, a jak p\u0159e\u017eiv\u0161\u00ed uzel rozli\u0161uje tuto situaci a selh\u00e1n\u00ed s\u00edt\u011b.<\/p>\n<p>Kr\u00e1tk\u00e1 odpov\u011b\u010f: to nen\u00ed mo\u017en\u00e9, a op\u011bt \u010del\u00edme v\u0161em probl\u00e9m\u016fm spojen\u00fdm se dv\u011bma uzly. Bu\u010f p\u0159e\u017eiv\u0161\u00ed:<\/p>\n<ul>\n<li>ignoruje kv\u00f3rum a nespr\u00e1vn\u011b se pokou\u0161\u00ed zah\u00e1jit obnovu b\u011bhem v\u00fdpadk\u016f s\u00edt\u011b (mo\u017enost dokon\u010den\u00ed odd\u011blen\u00ed je jin\u00fd p\u0159\u00edb\u011bh a z\u00e1vis\u00ed na tom, zda je zapojen PDU a zda sd\u00edlej\u00ed nap\u00e1jen\u00ed s n\u011bkter\u00fdm z stojan\u016f), nebo<\/li>\n<li>respektuje kv\u00f3rum a p\u0159ed\u010dasn\u011b se odpoj\u00ed, kdy\u017e jeho partnersk\u00fd uzel sel\u017ee<\/li>\n<\/ul>\n<p>\nV ka\u017ed\u00e9m p\u0159\u00edpad\u011b dv\u011b stojany nejsou lep\u0161\u00ed ne\u017e jeden a uzly by m\u011bly bu\u010f z\u00edsk\u00e1vat nez\u00e1visl\u00e9 zdroje nap\u00e1jen\u00ed, nebo b\u00fdt rozlo\u017eeny do t\u0159\u00ed (nebo v\u00edce, v z\u00e1vislosti na tom, kolik uzl\u016f m\u00e1te) stojan\u016f.<\/p>\n<h3>Dv\u011b datacentra<\/h3>\n<p>\nV tuto chv\u00edli si \u010dten\u00e1\u0159i, kte\u0159\u00ed u\u017e nemaj\u00ed sklon k riziku, mohou za\u010d\u00edt uv\u011bdomovat obnovu po hav\u00e1rii. Co se stane, kdy\u017e asteroid zas\u00e1hne jedno datov\u00e9 centrum s na\u0161imi t\u0159emi uzly rozm\u00edst\u011bn\u00fdmi ve t\u0159ech r\u016fzn\u00fdch stojanech? Je jasn\u00e9, \u017ee \u0161patn\u00e9 v\u011bci, ale v z\u00e1vislosti na va\u0161ich pot\u0159eb\u00e1ch m\u016f\u017ee b\u00fdt p\u0159id\u00e1n\u00ed druh\u00e9ho datacentra nedostate\u010dn\u00e9.<\/p>\n<p>Pokud je v\u0161e nastaveno spr\u00e1vn\u011b, druh\u00e9 datov\u00e9 centrum v\u00e1m (a to je rozumn\u00e9) poskytuje aktu\u00e1ln\u00ed a konzistentn\u00ed kopii va\u0161ich slu\u017eeb a jejich dat. Nicm\u00e9n\u011b, stejn\u011b jako ve sc\u00e9n\u00e1\u0159\u00edch se dv\u011bma uzly a dv\u011bma racky, syst\u00e9m nem\u00e1 dostatek informac\u00ed, aby zajistil maxim\u00e1ln\u00ed dostupnost a p\u0159ede\u0161el po\u0161kozen\u00ed (nebo nesouladu datov\u00fdch sad). I s t\u0159emi uzly (nebo racky) jejich rozlo\u017een\u00ed pouze do dvou datov\u00fdch center ponech\u00e1v\u00e1 syst\u00e9m neschopn\u00fd spolehliv\u011b u\u010dinit spr\u00e1vn\u00e9 rozhodnut\u00ed v p\u0159\u00edpad\u011b (nyn\u00ed mnohem pravd\u011bpodobn\u011bj\u0161\u00edho) incidentu, kter\u00fd ob\u011b strany nemohou utlumit.<\/p>\n<p>To neznamen\u00e1, \u017ee \u0159e\u0161en\u00ed se dv\u011bma datov\u00fdmi centry nikdy nen\u00ed vhodn\u00e9. Spole\u010dnosti \u010dasto cht\u011bj\u00ed, aby byl n\u011bkdo informov\u00e1n, ne\u017e u\u010din\u00ed v\u00fdjime\u010dn\u00fd krok k p\u0159echodu na z\u00e1lo\u017en\u00ed datov\u00e9 centrum. Jen m\u011bjte na pam\u011bti, \u017ee pokud chcete automatizovat selh\u00e1n\u00ed, budete pot\u0159ebovat bu\u010f t\u0159et\u00ed datov\u00e9 centrum, aby quorum d\u00e1valo smysl (bu\u010f p\u0159\u00edmo, nebo prost\u0159ednictv\u00edm arbitra), nebo najdete zp\u016fsob, jak spolehliv\u011b odpojit cel\u00e9 datov\u00e9 centrum.<br \/>\n<br \/>Zdroj: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/494264\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u041f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u043b\u044f\u044e \u0432\u0430\u0448\u0435\u043c\u0443 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044e \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u0441\u0442\u0430\u0442\u044c\u0438 \u00abTwo Nodes \u2014 The Devil is in the Details\u00bb \u0430\u0432\u0442\u043e\u0440\u0430 Andrew Beekhof. \u041c\u043d\u043e\u0433\u0438\u0435 \u043b\u044e\u0434\u0438 \u043f\u0440\u0435\u0434\u043f\u043e\u0447\u0438\u0442\u0430\u044e\u0442 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u044b \u0441\u043e\u0441\u0442\u043e\u044f\u0449\u0438\u0435 \u0438\u0437 \u0434\u0432\u0443\u0445 \u0443\u0437\u043b\u043e\u0432, \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u043e\u043d\u0438 \u043a\u0430\u0436\u0443\u0442\u0441\u044f \u043a\u043e\u043d\u0446\u0435\u043f\u0442\u0443\u0430\u043b\u044c\u043d\u043e \u0431\u043e\u043b\u0435\u0435 \u043f\u0440\u043e\u0441\u0442\u044b\u043c\u0438, \u043a\u0440\u043e\u043c\u0435 \u0442\u043e\u0433\u043e \u0435\u0449\u0435 \u0438 \u043d\u0430 33% \u0431\u043e\u043b\u0435\u0435 \u0434\u0435\u0448\u0435\u0432\u044b\u043c\u0438 \u0447\u0435\u043c \u0438\u0445 \u0442\u0440\u0435\u0445-\u0443\u0437\u043b\u043e\u0432\u044b\u0435 \u0441\u043e\u0431\u0440\u0430\u0442\u044c\u044f. \u0425\u043e\u0442\u044f \u0432\u043f\u043e\u043b\u043d\u0435 \u0440\u0435\u0430\u043b\u044c\u043d\u043e \u0441\u043e\u0431\u0440\u0430\u0442\u044c \u0445\u043e\u0440\u043e\u0448\u0438\u0439 \u043a\u043b\u0430\u0441\u0442\u0435\u0440 \u0438\u0437 \u0434\u0432\u0443\u0445 \u0443\u0437\u043b\u043e\u0432, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-75726","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440!\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"cs_CZ\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u043b\u0430\u0441\u0442\u0435\u0440 \u0438\u0437 \u0434\u0432\u0443\u0445 \u0443\u0437\u043b\u043e\u0432 \u2013 \u0434\u044c\u044f\u0432\u043e\u043b \u0432 \u0434\u0435\u0442\u0430\u043b\u044f\u0445 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440!\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-03-28T05:42:08+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-03-28T05:42:08+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Dvouuzlov\u00fd klastr \u2013 \u010dert v detailech | ProHoster","description":"Ahoj, Habr!","canonical_url":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"cs_CZ","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u043b\u0430\u0441\u0442\u0435\u0440 \u0438\u0437 \u0434\u0432\u0443\u0445 \u0443\u0437\u043b\u043e\u0432 \u2013 \u0434\u044c\u044f\u0432\u043e\u043b \u0432 \u0434\u0435\u0442\u0430\u043b\u044f\u0445 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440!","og:url":"https:\/\/prohoster.info\/cs\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-03-28T05:42:08+00:00","article:modified_time":"2020-03-28T05:42:08+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"75726","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 17:50:33","updated":"2022-10-03 21:32:17","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts\/75726","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/comments?post=75726"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/posts\/75726\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/media?parent=75726"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/categories?post=75726"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/cs\/wp-json\/wp\/v2\/tags?post=75726"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}