Salut, Habr! Vă prezint traducerea articolului autor Andrew Beekhof.
Multe persoane preferă clusterele formate din două noduri pentru că acestea par conceptual mai simple și sunt, de asemenea, cu 33% mai ieftine decât omologii lor cu trei noduri. Deși este posibil să construiești un cluster bun din două noduri, în majoritatea cazurilor, din cauza scenariilor neconsiderate, această configurație va crea multe probleme neocluze.
Primul pas în crearea oricărei sisteme de înaltă disponibilitate este identificarea și încercarea eliminării punctelor unice de eșec, adesea abreviate ca SPoF (punct unic de eșec).
Este important de menționat că, în orice sistem, nu este posibil să elimini toate riscurile de întrerupere. Acest lucru se datorează în mare parte faptului că protecția tipică împotriva riscurilor presupune introducerea unei anumite redundanțe, ceea ce duce la o creștere a complexității sistemului și la apariția unor noi puncte de eșec. Prin urmare, noi inițial facem un compromis și ne concentrăm pe evenimentele legate de punctele unice de eșec, nu pe lanțurile de evenimente corelate și, prin urmare, tot mai puțin probabile.
Având în vedere compromisurile, nu căutăm doar SPoF, ci echilibrăm și riscurile și consecințele, rezultând că ceea ce este critic și ceea ce nu este poate varia de la un apel la altul.
Nu toată lumea are nevoie de furnizori alternativi de energie cu linii electrice independente. Deși paranoia s-a dovedit a fi profitabilă pentru cel puțin un client, când monitorizarea lor a detectat un transformator defect. Clientul a sunat pentru a încerca să avertizeze compania de electricitate, până când transformatorul defect a explodat.
Punctul de pornire natural este să ai în sistem mai mult de un nod. Cu toate acestea, înainte ca sistemul să poată muta serviciile pe nodul rămas funcțional după o defecțiune, în general, este necesar să ne asigurăm că serviciile transferate nu sunt active în altă parte.
Un cluster cu două noduri nu are dezavantaje dacă, în urma unei defecțiuni, ambele noduri gestionează același website static. Totuși, totul se schimbă dacă, în rezultat, ambele părți gestionează independent o coadă comună de sarcini sau oferă acces nesupravegheat la o bază de date replicată sau la un sistem de fișiere comun.
Prin urmare, pentru a preveni deteriorarea datelor ca urmare a defecțiunii unui nod, ne bazăm pe ceea ce se numește «izolare» (fencing).
Principiul de izolare
La baza principiului de izolare stă întrebarea: poate un nod concurent să cauzeze deteriorarea datelor? În cazul în care deteriorarea datelor este un scenariu probabil, o soluție bună ar fi izolarea nodului atât de cererile de intrare, cât și de stocarea persistentă. Cea mai comună abordare de izolare este de a închide nodurile defecte.
Există două categorii de metode de izolare pe care le voi numi directe și indirecte, dar în egală măsură le putem numi active și pascive. Metodele directe includ acțiuni din partea nodurilor de tip peer care au supraviețuit, cum ar fi interacțiunea cu dispozitivele IPMI (Interfața de Management al Platformei Inteligente - o interfață pentru monitorizarea de la distanță și gestionarea stării fizice a serverului) sau iLO (un mecanism de management al serverului în condiții de absență a accesului fizic), în timp ce metodele indirecte se bazează pe nodul defect pentru a recunoaște cumva că se află într-o stare nesănătoasă (sau, cel puțin, împiedică ceilalți membri să se recupereze) și a semnala în legătură cu necesitatea de a dezactiva nodul defect.
Cvorumul ajută în cazul utilizării atât a metodelor directe cât și a celor indirecte.
Izolarea directă
În cazul izolării directe, putem folosi cvorumul pentru a preveni cursa de izolare în cazul unei defecțiuni de rețea.
Dispunând de conceptul de cvorum, în sistem există suficiente informații (chiar și fără a se conecta la partenerii lor), astfel încât nodurile să știe automat dacă trebuie să inițieze o izolarea și/sau o recuperare.
Fără cvorum, ambele părți ale divizării rețelei presupun în mod just că cealaltă parte este moartă și vor căuta să se izoleze una de cealaltă. În cel mai rău caz, ambele părți reușesc să deconecteze întregul cluster. Un alt scenariu este un deathmatch, un ciclu nesfârșit de noduri care apar, nu își văd perechile, le repornesc și inițiază recuperarea doar pentru a reporni când perechea lor trece prin aceeași logică.
Problema cu izolarea este că cele mai utilizate dispozitive devin inaccesibile din cauza acelorași evenimente de defecțiune la care dorim să ne referim pentru recuperare. Cele mai multe dintre plăcile IPMI și iLO sunt instalate pe gazdele pe care le controlează și, implicit, folosesc aceeași rețea, ceea ce îi face pe nodurile țintă să creadă că celelalte noduri sunt offline.
Din păcate, particularitățile funcționării dispozitivelor IPMI și iLo sunt rareori discutate în momentul achiziționării echipamentului.
Izolarea indirectă
Cvorumul este, de asemenea, important pentru gestionarea izolărilor indirecte; dacă totul este făcut corect, cvorumul poate permite supraviețuitorilor să presupună că nodurile pierdute, după o anumită perioadă de timp, vor trece în siguranță.
În această configurație, temporizatorul hardware watchdog este resetat la fiecare N secunde, dacă cvorumul nu este pierdut. Dacă temporizatorul (de obicei un multiplu al lui N) expiră, dispozitivul efectuează o oprire necontrolată a alimentării (nu shutdown).
Acest abordare este foarte eficientă, dar fără cvorum pentru gestionarea sa, informația din interiorul clusterului este insuficientă. Este greu de distins între o deconectare a rețelei și o defecțiune a nodului partener. Motivul pentru care acesta este un aspect important este că, fără capacitatea de a distinge între cele două cazuri, ești constrâns să alegi același mod de comportament în ambele situații.
Problema alegerii unui singur mod de operare este că nu există o cale de acțiune care să maximizeze disponibilitatea și să evite pierderea de date.
- Dacă decizi să presupui că nodul partener este activ, dar de fapt a avut o defecțiune, clusterul va opri în mod excesiv serviciile care ar fi trebuit să funcționeze pentru a compensa pierderea serviciilor nodului partener căzut.
- Dacă decizi să presupui că nodul nu funcționează, dar aceasta a fost doar o problemă de rețea și de fapt nodul îndepărtat funcționează, atunci, în cel mai bun caz, te abonezi la o verificare manuală viitoare a seturilor de date rezultate.
Indiferent de heuristica pe care o folosești, este simplu să creezi o defecțiune care fie va face ca ambele părți să funcționeze, fie va determina clusterul să deconecteze nodurile supraviețuitoare. Nerespectarea cvorumului privează clusterul de unul dintre cele mai puternice instrumente din arsenalul său.
Dacă nu există o altă alternativă, cea mai bună abordare va fi să sacrifici disponibilitatea (aici autorul se referă la teorema CAP). O disponibilitate mare a datelor corupte nu ajută pe nimeni, iar verificarea manuală a diverselor seturi de date nu este nici plăcută.
Cvorum
Cvorum suna bine, nu-i așa?
Singurul dezavantaj este că, pentru a-l avea într-un cluster cu N membri, trebuie să existe o conectivitate între N / 2 + 1 dintre nodurile tale. Ceea ce este imposibil într-un cluster cu două noduri după ce unul dintre noduri eșuează.
Ce, în cele din urmă, ne conduce la problema fundamentală cu două noduri:
cvorumul nu are sens în clusterele cu două noduri, iar fără acesta, nu este posibil să determinăm cu fiabilitate cursul de acțiune care maximizează disponibilitatea și previne pierderile de date.
Chiar și într-un sistem cu două noduri conectate printr-un cablu încrucișat, este imposibil să distingi în mod definitiv între o deconectare a rețelei și defectarea celuilalt nod. O deconectare la un capăt (probabilitatea căreia este, fără îndoială, proporțională cu distanța dintre noduri) va fi suficientă pentru a infirma orice presupunere că funcționalitatea canalului este egală cu sănătatea nodului-partener.
Punem în funcțiune un cluster cu două noduri
Uneori, clientul nu poate sau nu dorește să achiziționeze un al treilea nod, iar noi suntem nevoiți să căutăm o alternativă.
Opțiunea 1 - Metoda de dublare a delimitării
Dispozitivul iLO sau IPMI al nodului reprezintă un punct de eșec, deoarece, în caz de defecțiune, nodurile rămase nu pot folosi acest dispozitiv pentru a aduce nodul într-o stare sigură. Într-un cluster format din 3 sau mai multe noduri, putem atenua acest lucru prin calcularea cvorumului și utilizarea hardware watchdog (mecanismul de dezactivare indirectă, așa cum a fost discutat anterior). În cazul a două noduri, trebuie să folosim în schimb unități de distribuție a alimentării (power distribution units sau PDUs).
După o defecțiune, nodul supraviețuitor încearcă mai întâi să se conecteze la dispozitivul principal de dezactivare (încorporat iLO sau IPMI). Dacă reușește, recuperarea continuă ca de obicei. Numai în cazul unei defecțiuni a dispozitivului iLO / IPMI se apelează la PDU, iar dacă apelul reușește, recuperarea poate continua.
Asigurați-vă că plasați PDU într-o rețea distinctă de traficul clusterului, altfel o defecțiune unică în rețea va bloca accesul atât la dispozitivele de dezactivare, cât și va împiedica recuperarea serviciilor.
Aici s-ar putea să vă întrebați – nu este dispozitivul PDU unicul punct de eșec? Răspunsul este – desigur că da.
Dacă acest risc este semnificativ pentru dumneavoastră – nu sunteți singur: conectați ambele noduri la două PDU și indicați software-ului clusterului să utilizeze ambele la pornirea și oprirea nodurilor. Acum clusterul rămâne activ dacă un PDU eșuează, și pentru a bloca recuperarea va fi necesar un al doilea eșec fie al altui PDU, fie al dispozitivului IPMI.
Opțiunea 2 – Adăugarea unui arbitru
În unele scenarii, deși tehnic este posibilă metoda dezactivării duplicate, aceasta este complicată din punct de vedere politic. Multe companii preferă să aibă o separare clară între administratori și proprietarii aplicațiilor, iar administratorii de rețea preocupați de securitate nu sunt întotdeauna entuziasmați să ofere cuiva detalii de acces la PDU.
În acest caz, alternativa recomandată este crearea unei terțe părți neutre, care poate suplini calculul cvorumului.
În cazul unei defecțiuni, nodul trebuie să aibă capacitatea de a vedea canalul partenerului său sau al arbitrilor, pentru a recupera serviciile. Arbitrii includ, de asemenea, o funcție de deconectare, dacă ambele noduri pot vedea arbitrul, dar nu se văd între ele.
Această opțiune ar trebui folosită împreună cu o metodă indirectă de separare, cum ar fi un timer hardware watchdog, care este configurat să oprească mașina dacă își pierde conexiunea cu nodul său partener și arbitru. Astfel, supraviețuitorul poate presupune cu un anumit grad de încredere că nodul său partener va fi într-o stare sigură după expirarea timer-ului hardware watchdog.
Diferența practică între arbitru și al treilea nod constă în faptul că arbitru necesită mult mai puține resurse pentru funcționare și, potențial, poate deservi mai mult de un cluster.
Opțiunea 3 — Factorul uman
Ultima abordare constă în a permite supraviețuitorilor să continE să execute orice servicii pe care deja le desfășurau, dar să nu inițieze altele noi, până când fie problema nu se rezolvă de la sine (recuperarea rețelei, repornirea nodului), fie o persoană nu preia responsabilitatea de a confirma manual că cealaltă parte este moartă.
Opțiunea bonus
Am spus deja că poți adăuga un al treilea nod?
Două rack-uri
Pentru argumente, să presupunem că v-am convins de avantajele unui al treilea nod; acum trebuie să luăm în considerare amplasarea fizică a nodurilor. Dacă sunt plasate (și primesc energie) în același rack, acesta reprezintă, de asemenea, un SPoF, iar acesta nu poate fi rezolvat prin adăugarea unui al doilea rack.
Dacă acest lucru este surprinzător, să ne gândim la ce s-ar întâmpla dacă rack-ul cu două noduri se defectează și cum va supraviețuitorul va distinge această situație de o cădere a rețelei.
Răspunsul scurt: este imposibil și ne confruntăm din nou cu toate problemele întâlnite în cazul a două noduri. Fie supraviețuitorul:
- ignoră cvorumul și încearcă greșit să inițieze recuperarea în timpul întreruperilor de rețea (posibilitatea de a finaliza separarea — este o poveste separată și depinde de implicarea PDU și de împărțirea puterii cu oricare dintre rack-uri), sau
- respectă cvorumul și se deconectează prematur atunci când nodul său partener eșuează.
În orice caz, două rack-uri nu sunt mai bune decât unul, iar nodurile ar trebui fie să primească surse de alimentare independente, fie să fie distribuite pe trei (sau mai multe, în funcție de câte noduri aveți) rack-uri.
Două centre de date
Până la acest moment, cititorii care nu mai sunt dispuși la risc s-ar putea gândi la recuperarea în cazul unei intersecții. Ce se întâmplă când un asteroid lovește un centru de date cu cele trei noduri distribuite în trei rack-uri diferite? Evident, lucruri rele, dar, în funcție de nevoile dvs., adăugarea unui al doilea centru de date poate să nu fie suficientă.
Dacă este făcut corect, al doilea centru de date vă oferă (și este rezonabil) o copie actualizată și consistentă a serviciilor și datelor dvs. Cu toate acestea, la fel ca în scenariile cu două noduri și două rack-uri, sistemul nu are suficiente informații pentru a asigura disponibilitatea maximă și a preveni deteriorarea (sau discrepanța seturilor de date). Chiar și cu trei noduri (sau rack-uri), distribuția lor doar în două centre de date lasă sistemul incapabil să ia o decizie corectă în cazul (acum mult mai probabil) unui eveniment pe care ambele părți nu îl pot corela.
Acest lucru nu înseamnă că soluția cu două centre de date nu este potrivită niciodată. Companiile doresc adesea ca cineva să fie la curent înainte de a lua o măsură extraordinară în ceea ce privește trecerea la un centru de date de rezervă. Doar rețineți că, dacă doriți să automatizați defecțiunea, va trebui fie să aveți un al treilea centru de date pentru ca cvorum-ul să aibă sens (direct sau printr-un arbitru), fie să găsiți o modalitate de a decupla fiabil întregul centru de date.
Sursa: habr.com
