{"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\/ro\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah","title":{"rendered":"Clusterul format din dou\u0103 noduri \u2013 diavolul este \u00een detalii","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Salut, Habr! V\u0103 prezint traducerea articolului <noindex><a rel=\"nofollow\" href=\"http:\/\/blog.clusterlabs.org\/blog\/2018\/two-node-problems\">\u201eDou\u0103 noduri \u2014 Diavolul se afl\u0103 \u00een detalii\u201d<\/a><\/noindex> autor Andrew Beekhof.<\/p>\n<p>Multe persoane prefer\u0103 clusterele formate din dou\u0103 noduri pentru c\u0103 acestea par conceptual mai simple \u0219i sunt, de asemenea, cu 33% mai ieftine dec\u00e2t omologii lor cu trei noduri. De\u0219i este posibil s\u0103 construie\u0219ti un cluster bun din dou\u0103 noduri, \u00een majoritatea cazurilor, din cauza scenariilor neconsiderate, aceast\u0103 configura\u021bie va crea multe probleme neocluze.<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\nPrimul pas \u00een crearea oric\u0103rei sisteme de \u00eenalt\u0103 disponibilitate este identificarea \u0219i \u00eencercarea elimin\u0103rii punctelor unice de e\u0219ec, adesea abreviate ca <i>SPoF<\/i> (punct unic de e\u0219ec).<\/p>\n<p>Este important de men\u021bionat c\u0103, \u00een orice sistem, nu este posibil s\u0103 elimini toate riscurile de \u00eentrerupere. Acest lucru se datoreaz\u0103 \u00een mare parte faptului c\u0103 protec\u021bia tipic\u0103 \u00eempotriva riscurilor presupune introducerea unei anumite redundan\u021be, ceea ce duce la o cre\u0219tere a complexit\u0103\u021bii sistemului \u0219i la apari\u021bia unor noi puncte de e\u0219ec. Prin urmare, noi ini\u021bial facem un compromis \u0219i ne concentr\u0103m pe evenimentele legate de punctele unice de e\u0219ec, nu pe lan\u021burile de evenimente corelate \u0219i, prin urmare, tot mai pu\u021bin probabile.<\/p>\n<p>Av\u00e2nd \u00een vedere compromisurile, nu c\u0103ut\u0103m doar SPoF, ci echilibr\u0103m \u0219i riscurile \u0219i consecin\u021bele, rezult\u00e2nd c\u0103 ceea ce este critic \u0219i ceea ce nu este poate varia de la un apel la altul.<\/p>\n<blockquote><p>Nu toat\u0103 lumea are nevoie de furnizori alternativi de energie cu linii electrice independente. De\u0219i paranoia s-a dovedit a fi profitabil\u0103 pentru cel pu\u021bin un client, c\u00e2nd monitorizarea lor a detectat un transformator defect. Clientul a sunat pentru a \u00eencerca s\u0103 avertizeze compania de electricitate, p\u00e2n\u0103 c\u00e2nd transformatorul defect a explodat.<\/p><\/blockquote>\n<p>\nPunctul de pornire natural este s\u0103 ai \u00een sistem mai mult de un nod. Cu toate acestea, \u00eenainte ca sistemul s\u0103 poat\u0103 muta serviciile pe nodul r\u0103mas func\u021bional dup\u0103 o defec\u021biune, \u00een general, este necesar s\u0103 ne asigur\u0103m c\u0103 serviciile transferate nu sunt active \u00een alt\u0103 parte.<\/p>\n<p>Un cluster cu dou\u0103 noduri nu are dezavantaje dac\u0103, \u00een urma unei defec\u021biuni, ambele noduri gestioneaz\u0103 acela\u0219i website static. Totu\u0219i, totul se schimb\u0103 dac\u0103, \u00een rezultat, ambele p\u0103r\u021bi gestioneaz\u0103 independent o coad\u0103 comun\u0103 de sarcini sau ofer\u0103 acces nesupravegheat la o baz\u0103 de date replicat\u0103 sau la un sistem de fi\u0219iere comun.<\/p>\n<p>Prin urmare, pentru a preveni deteriorarea datelor ca urmare a defec\u021biunii unui nod, ne baz\u0103m pe ceea ce se nume\u0219te <i>\u00abizolare\u00bb<\/i> (fencing).<\/p>\n<h2>Principiul de izolare<\/h2>\n<p>\nLa baza principiului de izolare st\u0103 \u00eentrebarea: poate un nod concurent s\u0103 cauzeze deteriorarea datelor? \u00cen cazul \u00een care deteriorarea datelor este un scenariu probabil, o solu\u021bie bun\u0103 ar fi izolarea nodului at\u00e2t de cererile de intrare, c\u00e2t \u0219i de stocarea persistent\u0103. Cea mai comun\u0103 abordare de izolare este de a \u00eenchide nodurile defecte.<\/p>\n<p>Exist\u0103 dou\u0103 categorii de metode de izolare pe care le voi numi <i>directe<\/i> \u0219i <i>indirecte<\/i>, dar \u00een egal\u0103 m\u0103sur\u0103 le putem numi <i>active<\/i> \u0219i <i>pascive<\/i>. Metodele directe includ ac\u021biuni din partea nodurilor de tip peer care au supravie\u021buit, cum ar fi interac\u021biunea cu dispozitivele IPMI (Interfa\u021ba de Management al Platformei Inteligente - o interfa\u021b\u0103 pentru monitorizarea de la distan\u021b\u0103 \u0219i gestionarea st\u0103rii fizice a serverului) sau iLO (un mecanism de management al serverului \u00een condi\u021bii de absen\u021b\u0103 a accesului fizic), \u00een timp ce metodele indirecte se bazeaz\u0103 pe nodul defect pentru a recunoa\u0219te cumva c\u0103 se afl\u0103 \u00eentr-o stare nes\u0103n\u0103toas\u0103 (sau, cel pu\u021bin, \u00eempiedic\u0103 ceilal\u021bi membri s\u0103 se recupereze) \u0219i a semnala <noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Watchdog_timer\">hardware watchdog<\/a><\/noindex> \u00een leg\u0103tur\u0103 cu necesitatea de a dezactiva nodul defect.<\/p>\n<p>Cvorumul ajut\u0103 \u00een cazul utiliz\u0103rii at\u00e2t a metodelor directe c\u00e2t \u0219i a celor indirecte.<\/p>\n<h3>Izolarea direct\u0103<\/h3>\n<p>\n\u00cen cazul izol\u0103rii directe, putem folosi cvorumul pentru a preveni cursa de izolare \u00een cazul unei defec\u021biuni de re\u021bea.<\/p>\n<p>Dispun\u00e2nd de conceptul de cvorum, \u00een sistem exist\u0103 suficiente informa\u021bii (chiar \u0219i f\u0103r\u0103 a se conecta la partenerii lor), astfel \u00eenc\u00e2t nodurile s\u0103 \u0219tie automat dac\u0103 trebuie s\u0103 ini\u021bieze o izolarea \u0219i\/sau o recuperare.<\/p>\n<p>F\u0103r\u0103 cvorum, ambele p\u0103r\u021bi ale diviz\u0103rii re\u021belei presupun \u00een mod just c\u0103 cealalt\u0103 parte este moart\u0103 \u0219i vor c\u0103uta s\u0103 se izoleze una de cealalt\u0103. \u00cen cel mai r\u0103u caz, ambele p\u0103r\u021bi reu\u0219esc s\u0103 deconecteze \u00eentregul cluster. Un alt scenariu este un deathmatch, un ciclu nesf\u00e2r\u0219it de noduri care apar, nu \u00ee\u0219i v\u0103d perechile, le repornesc \u0219i ini\u021biaz\u0103 recuperarea doar pentru a reporni c\u00e2nd perechea lor trece prin aceea\u0219i logic\u0103.<\/p>\n<p>Problema cu izolarea este c\u0103 cele mai utilizate dispozitive devin inaccesibile din cauza acelora\u0219i evenimente de defec\u021biune la care dorim s\u0103 ne referim pentru recuperare. Cele mai multe dintre pl\u0103cile IPMI \u0219i iLO sunt instalate pe gazdele pe care le controleaz\u0103 \u0219i, implicit, folosesc aceea\u0219i re\u021bea, ceea ce \u00eei face pe nodurile \u021bint\u0103 s\u0103 cread\u0103 c\u0103 celelalte noduri sunt offline.<\/p>\n<p>Din p\u0103cate, particularit\u0103\u021bile func\u021bion\u0103rii dispozitivelor IPMI \u0219i iLo sunt rareori discutate \u00een momentul achizi\u021bion\u0103rii echipamentului.<\/p>\n<h3>Izolarea indirect\u0103<\/h3>\n<p>\nCvorumul este, de asemenea, important pentru gestionarea izol\u0103rilor indirecte; dac\u0103 totul este f\u0103cut corect, cvorumul poate permite supravie\u021buitorilor s\u0103 presupun\u0103 c\u0103 nodurile pierdute, dup\u0103 o anumit\u0103 perioad\u0103 de timp, vor trece \u00een siguran\u021b\u0103.<\/p>\n<p>\u00cen aceast\u0103 configura\u021bie, temporizatorul hardware watchdog este resetat la fiecare N secunde, dac\u0103 cvorumul nu este pierdut. Dac\u0103 temporizatorul (de obicei un multiplu al lui N) expir\u0103, dispozitivul efectueaz\u0103 o oprire necontrolat\u0103 a aliment\u0103rii (nu shutdown).<\/p>\n<p>Acest abordare este foarte eficient\u0103, dar f\u0103r\u0103 cvorum pentru gestionarea sa, informa\u021bia din interiorul clusterului este insuficient\u0103. Este greu de distins \u00eentre o deconectare a re\u021belei \u0219i o defec\u021biune a nodului partener. Motivul pentru care acesta este un aspect important este c\u0103, f\u0103r\u0103 capacitatea de a distinge \u00eentre cele dou\u0103 cazuri, e\u0219ti constr\u00e2ns s\u0103 alegi acela\u0219i mod de comportament \u00een ambele situa\u021bii.<\/p>\n<p>Problema alegerii unui singur mod de operare este c\u0103 nu exist\u0103 o cale de ac\u021biune care s\u0103 maximizeze disponibilitatea \u0219i s\u0103 evite pierderea de date.<\/p>\n<ul>\n<li>Dac\u0103 decizi s\u0103 presupui c\u0103 nodul partener este activ, dar de fapt a avut o defec\u021biune, clusterul va opri \u00een mod excesiv serviciile care ar fi trebuit s\u0103 func\u021bioneze pentru a compensa pierderea serviciilor nodului partener c\u0103zut.<\/li>\n<li>Dac\u0103 decizi s\u0103 presupui c\u0103 nodul nu func\u021bioneaz\u0103, dar aceasta a fost doar o problem\u0103 de re\u021bea \u0219i de fapt nodul \u00eendep\u0103rtat func\u021bioneaz\u0103, atunci, \u00een cel mai bun caz, te abonezi la o verificare manual\u0103 viitoare a seturilor de date rezultate.<\/li>\n<\/ul>\n<p>\nIndiferent de heuristica pe care o folose\u0219ti, este simplu s\u0103 creezi o defec\u021biune care fie va face ca ambele p\u0103r\u021bi s\u0103 func\u021bioneze, fie va determina clusterul s\u0103 deconecteze nodurile supravie\u021buitoare. Nerespectarea cvorumului priveaz\u0103 clusterul de unul dintre cele mai puternice instrumente din arsenalul s\u0103u.<\/p>\n<p>Dac\u0103 nu exist\u0103 o alt\u0103 alternativ\u0103, cea mai bun\u0103 abordare va fi s\u0103 sacrifici disponibilitatea (aici autorul se refer\u0103 la teorema CAP). O disponibilitate mare a datelor corupte nu ajut\u0103 pe nimeni, iar verificarea manual\u0103 a diverselor seturi de date nu este nici pl\u0103cut\u0103.<\/p>\n<h2>Cvorum<\/h2>\n<p>\nCvorum suna bine, nu-i a\u0219a?<\/p>\n<p>Singurul dezavantaj este c\u0103, pentru a-l avea \u00eentr-un cluster cu N membri, trebuie s\u0103 existe o conectivitate \u00eentre N \/ 2 + 1 dintre nodurile tale. Ceea ce este imposibil \u00eentr-un cluster cu dou\u0103 noduri dup\u0103 ce unul dintre noduri e\u0219ueaz\u0103.<\/p>\n<p>Ce, \u00een cele din urm\u0103, ne conduce la problema fundamental\u0103 cu dou\u0103 noduri:<br \/>\ncvorumul nu are sens \u00een clusterele cu dou\u0103 noduri, iar f\u0103r\u0103 acesta, nu este posibil s\u0103 determin\u0103m cu fiabilitate cursul de ac\u021biune care maximizeaz\u0103 disponibilitatea \u0219i previne pierderile de date.<br \/>\nChiar \u0219i \u00eentr-un sistem cu dou\u0103 noduri conectate printr-un cablu \u00eencruci\u0219at, este imposibil s\u0103 distingi \u00een mod definitiv \u00eentre o deconectare a re\u021belei \u0219i defectarea celuilalt nod. O deconectare la un cap\u0103t (probabilitatea c\u0103reia este, f\u0103r\u0103 \u00eendoial\u0103, propor\u021bional\u0103 cu distan\u021ba dintre noduri) va fi suficient\u0103 pentru a infirma orice presupunere c\u0103 func\u021bionalitatea canalului este egal\u0103 cu s\u0103n\u0103tatea nodului-partener.<\/p>\n<h3>Punem \u00een func\u021biune un cluster cu dou\u0103 noduri<\/h3>\n<p>\nUneori, clientul nu poate sau nu dore\u0219te s\u0103 achizi\u021bioneze un al treilea nod, iar noi suntem nevoi\u021bi s\u0103 c\u0103ut\u0103m o alternativ\u0103.<\/p>\n<h4>Op\u021biunea 1 - Metoda de dublare a delimit\u0103rii<\/h4>\n<p>\nDispozitivul iLO sau IPMI al nodului reprezint\u0103 un punct de e\u0219ec, deoarece, \u00een caz de defec\u021biune, nodurile r\u0103mase nu pot folosi acest dispozitiv pentru a aduce nodul \u00eentr-o stare sigur\u0103. \u00centr-un cluster format din 3 sau mai multe noduri, putem atenua acest lucru prin calcularea cvorumului \u0219i utilizarea hardware watchdog (mecanismul de dezactivare indirect\u0103, a\u0219a cum a fost discutat anterior). \u00cen cazul a dou\u0103 noduri, trebuie s\u0103 folosim \u00een schimb unit\u0103\u021bi de distribu\u021bie a aliment\u0103rii (power distribution units sau PDUs).<\/p>\n<p>Dup\u0103 o defec\u021biune, nodul supravie\u021buitor \u00eencearc\u0103 mai \u00eent\u00e2i s\u0103 se conecteze la dispozitivul principal de dezactivare (\u00eencorporat iLO sau IPMI). Dac\u0103 reu\u0219e\u0219te, recuperarea continu\u0103 ca de obicei. Numai \u00een cazul unei defec\u021biuni a dispozitivului iLO \/ IPMI se apeleaz\u0103 la PDU, iar dac\u0103 apelul reu\u0219e\u0219te, recuperarea poate continua.<\/p>\n<p>Asigura\u021bi-v\u0103 c\u0103 plasa\u021bi PDU \u00eentr-o re\u021bea distinct\u0103 de traficul clusterului, altfel o defec\u021biune unic\u0103 \u00een re\u021bea va bloca accesul at\u00e2t la dispozitivele de dezactivare, c\u00e2t \u0219i va \u00eempiedica recuperarea serviciilor.<\/p>\n<p>Aici s-ar putea s\u0103 v\u0103 \u00eentreba\u021bi \u2013 nu este dispozitivul PDU unicul punct de e\u0219ec? R\u0103spunsul este \u2013 desigur c\u0103 da.<\/p>\n<p>Dac\u0103 acest risc este semnificativ pentru dumneavoastr\u0103 \u2013 nu sunte\u021bi singur: conecta\u021bi ambele noduri la dou\u0103 PDU \u0219i indica\u021bi software-ului clusterului s\u0103 utilizeze ambele la pornirea \u0219i oprirea nodurilor. Acum clusterul r\u0103m\u00e2ne activ dac\u0103 un PDU e\u0219ueaz\u0103, \u0219i pentru a bloca recuperarea va fi necesar un al doilea e\u0219ec fie al altui PDU, fie al dispozitivului IPMI.<\/p>\n<h4>Op\u021biunea 2 \u2013 Ad\u0103ugarea unui arbitru<\/h4>\n<p>\n\u00cen unele scenarii, de\u0219i tehnic este posibil\u0103 metoda dezactiv\u0103rii duplicate, aceasta este complicat\u0103 din punct de vedere politic. Multe companii prefer\u0103 s\u0103 aib\u0103 o separare clar\u0103 \u00eentre administratori \u0219i proprietarii aplica\u021biilor, iar administratorii de re\u021bea preocupa\u021bi de securitate nu sunt \u00eentotdeauna entuziasma\u021bi s\u0103 ofere cuiva detalii de acces la PDU.<\/p>\n<p>\u00cen acest caz, alternativa recomandat\u0103 este crearea unei ter\u021be p\u0103r\u021bi neutre, care poate suplini calculul cvorumului.<\/p>\n<p>\u00cen cazul unei defec\u021biuni, nodul trebuie s\u0103 aib\u0103 capacitatea de a vedea canalul partenerului s\u0103u sau al arbitrilor, pentru a recupera serviciile. Arbitrii includ, de asemenea, o func\u021bie de deconectare, dac\u0103 ambele noduri pot vedea arbitrul, dar nu se v\u0103d \u00eentre ele.<\/p>\n<p>Aceast\u0103 op\u021biune ar trebui folosit\u0103 \u00eempreun\u0103 cu o metod\u0103 indirect\u0103 de separare, cum ar fi un timer hardware watchdog, care este configurat s\u0103 opreasc\u0103 ma\u0219ina dac\u0103 \u00ee\u0219i pierde conexiunea cu nodul s\u0103u partener \u0219i arbitru. Astfel, supravie\u021buitorul poate presupune cu un anumit grad de \u00eencredere c\u0103 nodul s\u0103u partener va fi \u00eentr-o stare sigur\u0103 dup\u0103 expirarea timer-ului hardware watchdog.<\/p>\n<p>Diferen\u021ba practic\u0103 \u00eentre arbitru \u0219i al treilea nod const\u0103 \u00een faptul c\u0103 arbitru necesit\u0103 mult mai pu\u021bine resurse pentru func\u021bionare \u0219i, poten\u021bial, poate deservi mai mult de un cluster.<\/p>\n<h4>Op\u021biunea 3 \u2014 Factorul uman<\/h4>\n<p>\nUltima abordare const\u0103 \u00een a permite supravie\u021buitorilor s\u0103 continE s\u0103 execute orice servicii pe care deja le desf\u0103\u0219urau, dar s\u0103 nu ini\u021bieze altele noi, p\u00e2n\u0103 c\u00e2nd fie problema nu se rezolv\u0103 de la sine (recuperarea re\u021belei, repornirea nodului), fie o persoan\u0103 nu preia responsabilitatea de a confirma manual c\u0103 cealalt\u0103 parte este moart\u0103.<\/p>\n<h4>Op\u021biunea bonus<\/h4>\n<p>\nAm spus deja c\u0103 po\u021bi ad\u0103uga un al treilea nod?<\/p>\n<h2>Dou\u0103 rack-uri<\/h2>\n<p>\nPentru argumente, s\u0103 presupunem c\u0103 v-am convins de avantajele unui al treilea nod; acum trebuie s\u0103 lu\u0103m \u00een considerare amplasarea fizic\u0103 a nodurilor. Dac\u0103 sunt plasate (\u0219i primesc energie) \u00een acela\u0219i rack, acesta reprezint\u0103, de asemenea, un SPoF, iar acesta nu poate fi rezolvat prin ad\u0103ugarea unui al doilea rack.<\/p>\n<p>Dac\u0103 acest lucru este surprinz\u0103tor, s\u0103 ne g\u00e2ndim la ce s-ar \u00eent\u00e2mpla dac\u0103 rack-ul cu dou\u0103 noduri se defecteaz\u0103 \u0219i cum va supravie\u021buitorul va distinge aceast\u0103 situa\u021bie de o c\u0103dere a re\u021belei.<\/p>\n<p>R\u0103spunsul scurt: este imposibil \u0219i ne confrunt\u0103m din nou cu toate problemele \u00eent\u00e2lnite \u00een cazul a dou\u0103 noduri. Fie supravie\u021buitorul:<\/p>\n<ul>\n<li>ignor\u0103 cvorumul \u0219i \u00eencearc\u0103 gre\u0219it s\u0103 ini\u021bieze recuperarea \u00een timpul \u00eentreruperilor de re\u021bea (posibilitatea de a finaliza separarea \u2014 este o poveste separat\u0103 \u0219i depinde de implicarea PDU \u0219i de \u00eemp\u0103r\u021birea puterii cu oricare dintre rack-uri), sau<\/li>\n<li>respect\u0103 cvorumul \u0219i se deconecteaz\u0103 prematur atunci c\u00e2nd nodul s\u0103u partener e\u0219ueaz\u0103.<\/li>\n<\/ul>\n<p>\n\u00cen orice caz, dou\u0103 rack-uri nu sunt mai bune dec\u00e2t unul, iar nodurile ar trebui fie s\u0103 primeasc\u0103 surse de alimentare independente, fie s\u0103 fie distribuite pe trei (sau mai multe, \u00een func\u021bie de c\u00e2te noduri ave\u021bi) rack-uri.<\/p>\n<h3>Dou\u0103 centre de date<\/h3>\n<p>\nP\u00e2n\u0103 la acest moment, cititorii care nu mai sunt dispu\u0219i la risc s-ar putea g\u00e2ndi la recuperarea \u00een cazul unei intersec\u021bii. Ce se \u00eent\u00e2mpl\u0103 c\u00e2nd un asteroid love\u0219te un centru de date cu cele trei noduri distribuite \u00een trei rack-uri diferite? Evident, lucruri rele, dar, \u00een func\u021bie de nevoile dvs., ad\u0103ugarea unui al doilea centru de date poate s\u0103 nu fie suficient\u0103.<\/p>\n<p>Dac\u0103 este f\u0103cut corect, al doilea centru de date v\u0103 ofer\u0103 (\u0219i este rezonabil) o copie actualizat\u0103 \u0219i consistent\u0103 a serviciilor \u0219i datelor dvs. Cu toate acestea, la fel ca \u00een scenariile cu dou\u0103 noduri \u0219i dou\u0103 rack-uri, sistemul nu are suficiente informa\u021bii pentru a asigura disponibilitatea maxim\u0103 \u0219i a preveni deteriorarea (sau discrepan\u021ba seturilor de date). Chiar \u0219i cu trei noduri (sau rack-uri), distribu\u021bia lor doar \u00een dou\u0103 centre de date las\u0103 sistemul incapabil s\u0103 ia o decizie corect\u0103 \u00een cazul (acum mult mai probabil) unui eveniment pe care ambele p\u0103r\u021bi nu \u00eel pot corela.<\/p>\n<p>Acest lucru nu \u00eenseamn\u0103 c\u0103 solu\u021bia cu dou\u0103 centre de date nu este potrivit\u0103 niciodat\u0103. Companiile doresc adesea ca cineva s\u0103 fie la curent \u00eenainte de a lua o m\u0103sur\u0103 extraordinar\u0103 \u00een ceea ce prive\u0219te trecerea la un centru de date de rezerv\u0103. Doar re\u021bine\u021bi c\u0103, dac\u0103 dori\u021bi s\u0103 automatiza\u021bi defec\u021biunea, va trebui fie s\u0103 ave\u021bi un al treilea centru de date pentru ca cvorum-ul s\u0103 aib\u0103 sens (direct sau printr-un arbitru), fie s\u0103 g\u0103si\u021bi o modalitate de a decupla fiabil \u00eentregul centru de date.<br \/>\n<br \/>Sursa: <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.2 - 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\/ro\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"ro_RO\" \/>\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\/ro\/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\udd47Clusterul cu dou\u0103 noduri \u2013 diavolul st\u0103 \u00een detalii | ProHoster","description":"Salut, Habr!","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/klaster-iz-dvuh-uzlov-dyavol-v-detalyah","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/75726","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=75726"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/75726\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=75726"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=75726"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=75726"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}