Bună, Habr! Vă prezint atenției o traducere a articolului de Andrew Beekhof.
Mulți oameni preferă clusterele cu două noduri, deoarece par mai simple din punct de vedere conceptual și sunt, de asemenea, cu 33% mai ieftine decât omologii lor cu trei noduri. Deși este destul de posibil să alcătuiți un cluster bun de două noduri, în cele mai multe cazuri, din cauza scenariilor neconsiderate, o astfel de configurație va crea multe probleme neevidente.
Primul pas pentru crearea oricărui sistem de înaltă disponibilitate este găsirea și încercarea de a elimina punctele individuale de defecțiune, adesea prescurtate ca SPoF (punct unic de eșec).
Merită să rețineți că este imposibil să eliminați toate riscurile posibile de nefuncționare în orice sistem. Acest lucru rezultă din faptul că o apărare tipică împotriva riscului este introducerea unei anumite redundanțe, ceea ce duce la creșterea complexității sistemului și la apariția de noi puncte de defecțiune. Prin urmare, inițial facem un compromis și ne concentrăm pe evenimente asociate cu puncte individuale de eșec, și nu pe lanțuri de evenimente înrudite și, prin urmare, din ce în ce mai puțin probabile.
Având în vedere compromisurile, nu căutăm doar SPoF, ci și echilibrăm riscurile și consecințele, în urma cărora concluzia a ceea ce este critic și a ceea ce nu este poate diferi pentru fiecare implementare.
Nu toată lumea are nevoie de furnizori alternativi de energie electrică cu linii electrice independente. Deși paranoia a dat roade pentru cel puțin un client atunci când monitorizarea lor a detectat un transformator defect. Clientul a făcut apeluri telefonice încercând să alerteze compania electrică până când transformatorul defect a explodat.
Un punct de plecare natural este acela de a avea mai mult de un nod în sistem. Cu toate acestea, înainte ca sistemul să poată muta serviciile în nodul supraviețuitor după o defecțiune, în general trebuie să se asigure că serviciile mutate nu sunt active în altă parte.
Nu există niciun dezavantaj pentru un cluster cu două noduri dacă o defecțiune are ca rezultat ambele noduri să deservească același site web static. Cu toate acestea, lucrurile se schimbă dacă rezultatul este că ambele părți gestionează în mod independent o coadă de joburi partajată sau oferă acces de scriere necoordonat la o bază de date replicată sau la un sistem de fișiere partajat.
Prin urmare, pentru a preveni coruperea datelor ca urmare a eșecului unui singur nod - ne bazăm pe ceva numit "disociere" (împrejmuire).
Principiul disocierii
În centrul principiului disocierii se află întrebarea: poate un nod concurent să provoace coruperea datelor? În cazul în care coruperea datelor este un scenariu probabil, o soluție bună ar fi izolarea nodului atât de solicitările primite, cât și de stocarea persistentă. Cea mai comună abordare a disocierii este deconectarea nodurilor defecte.
Există două categorii de metode de disociere, pe care le voi numi direct и indirect, dar pot fi numite în egală măsură activ и pasiv. Metodele directe includ acțiuni din partea colegilor supraviețuitori, cum ar fi interacțiunea cu un dispozitiv IPMI (Intelligent Platform Management Interface) sau iLO (un mecanism de gestionare a serverelor în absența accesului fizic la acestea), în timp ce metodele indirecte se bazează pe dispozitivul eșuat. nodul să recunoască cumva că se află într-o stare nesănătoasă (sau cel puțin împiedicând alți membri să-și revină) și să semnaleze despre necesitatea deconectarii nodului eșuat.
Quorumul ajută atunci când se utilizează atât metode directe, cât și indirecte.
Disocierea directă
În cazul disocierii directe, putem folosi cvorumul pentru a preveni cursele de disociere în cazul unei defecțiuni a rețelei.
Cu conceptul de cvorum, există suficiente informații în sistem (chiar și fără conectarea la colegii săi) pentru ca nodurile să știe automat dacă ar trebui să inițieze disocierea și/sau recuperarea.
Fără cvorum, ambele părți ale unei diviziuni de rețea vor presupune pe bună dreptate că cealaltă parte este moartă și vor căuta să o disocieze pe cealaltă. În cel mai rău caz, ambele părți reușesc să închidă întregul cluster. Un scenariu alternativ este un deathmatch, o buclă nesfârșită de noduri care apar, nu își văd colegii, îi repornesc și inițiază recuperarea doar pentru a reporni atunci când egalul lor urmează aceeași logică.
Problema disocierii este că cele mai frecvent utilizate dispozitive devin indisponibile din cauza acelorași evenimente de defecțiune pe care vrem să le țintim pentru recuperare. Majoritatea plăcilor IPMI și iLO sunt instalate pe gazdele pe care le controlează și, implicit, folosesc aceeași rețea, ceea ce face ca gazdele țintă să creadă că alte gazde sunt offline.
Din păcate, caracteristicile de operare ale dispozitivelor IPMI și iLo sunt rareori luate în considerare la momentul achiziționării echipamentului.
Disocierea indirectă
Cvorumul este, de asemenea, important pentru gestionarea disocierii indirecte; dacă este făcut corect, cvorumul poate permite supraviețuitorilor să presupună că nodurile pierdute vor trece la o stare sigură după o anumită perioadă de timp.
Cu această configurație, cronometrul de supraveghere hardware este resetat la fiecare N secunde dacă nu se pierde cvorumul. Dacă cronometrul (de obicei mai mulți multipli de N) expiră, atunci dispozitivul efectuează o oprire neplăcută (nu oprire).
Această abordare este foarte eficientă, dar fără cvorum nu există suficiente informații în cluster pentru a-l gestiona. Nu este ușor să facem diferența dintre o întrerupere a rețelei și o defecțiune a nodului egal. Motivul pentru care acest lucru contează este că, fără abilitatea de a diferenția între cele două cazuri, ești forțat să alegi același comportament în ambele cazuri.
Problema cu alegerea unui mod este că nu există nicio cale de acțiune care să maximizeze disponibilitatea și să prevină pierderea de date.
- Dacă alegeți să presupuneți că un nod peer este activ, dar de fapt eșuează, clusterul va opri în mod inutil serviciile care ar rula pentru a compensa pierderea serviciilor de la nodul peer eșuat.
- Dacă decideți să presupuneți că un nod este oprit, dar a fost doar o defecțiune a rețelei și, de fapt, nodul la distanță este funcțional, atunci în cel mai bun caz vă înscrieți pentru o viitoare reconciliere manuală a setului de date rezultate.
Indiferent de ce euristică utilizați, este trivial să creați o defecțiune care fie va duce la eșecul ambelor părți, fie va determina clusterul să închidă nodurile supraviețuitoare. Neutilizarea cvorumului privează cu adevărat grupul de unul dintre cele mai puternice instrumente din arsenalul său.
Dacă nu există altă alternativă, cea mai bună abordare este sacrificarea disponibilității (aici autorul se referă la teorema CAP). Disponibilitatea ridicată a datelor corupte nu ajută pe nimeni și nici reconcilierea manuală a diferitelor seturi de date nu este distractivă.
Cvorum
Cvorumul sună grozav, nu?
Singurul dezavantaj este că, pentru a-l avea într-un cluster cu N membri, trebuie să aveți o conexiune între N/2+1 dintre nodurile rămase. Ceea ce nu este posibil într-un cluster cu două noduri după ce un nod eșuează.
Ceea ce în cele din urmă ne duce la problema fundamentală cu două noduri:
Cvorumul nu are sens în două clustere de noduri și fără el este imposibil să se determine în mod fiabil cursul de acțiune care maximizează disponibilitatea și previne pierderea datelor
Chiar și într-un sistem de două noduri conectate printr-un cablu încrucișat, este imposibil să distingem definitiv între o întrerupere a rețelei și o defecțiune a celuilalt nod. Dezactivarea unui capăt (a cărui probabilitate este, desigur, proporțională cu distanța dintre noduri) va fi suficientă pentru a invalida orice presupunere că sănătatea conexiunii este egală cu sănătatea nodului partener.
Realizarea unui cluster cu două noduri să funcționeze
Uneori clientul nu poate sau nu vrea să cumpere un al treilea nod, iar noi suntem nevoiți să căutăm o alternativă.
Opțiunea 1 - Metoda de disociere duplicat
Dispozitivul iLO sau IPMI al unui nod reprezintă un punct de eșec deoarece, dacă eșuează, supraviețuitorii nu îl pot folosi pentru a aduce nodul într-o stare sigură. Într-un cluster de 3 sau mai multe noduri, putem atenua acest lucru calculând cvorumul și utilizând un watchdog hardware (un mecanism indirect de disociere, așa cum sa discutat mai devreme). În cazul a două noduri, trebuie să folosim în schimb unități de distribuție a energiei de rețea (PDU).
După o eroare, supraviețuitorul încearcă mai întâi să contacteze dispozitivul de disociere principal (iLO încorporat sau IPMI). Dacă acest lucru are succes, recuperarea continuă ca de obicei. PDU-ul este accesat numai dacă dispozitivul iLO/IPMI eșuează; dacă accesul are succes, recuperarea poate continua.
Asigurați-vă că plasați PDU-ul pe o altă rețea decât traficul cluster-ului, altfel o singură defecțiune a rețelei va bloca accesul la ambele dispozitive de disociere și va bloca restabilirea serviciilor.
Aici vă puteți întreba - este PDU un singur punct de eșec? La care este răspunsul, desigur că este.
Dacă acest risc este semnificativ pentru tine, nu ești singur: conectează ambele noduri la două PDU-uri și spune-i software-ului de clustering să le folosească pe ambele la pornirea și la oprirea nodurilor. Clusterul rămâne acum activ dacă o PDU moare și va fi necesară o a doua defecțiune fie a celeilalte PDU, fie a dispozitivului IPMI pentru a bloca recuperarea.
Opțiunea 2 - Adăugarea unui arbitru
În unele scenarii, deși metoda de disociere duplicat este posibilă din punct de vedere tehnic, este dificilă din punct de vedere politic. Multe companii le place să aibă o anumită separare între administratori și proprietarii de aplicații, iar administratorii de rețea atenți la securitate nu sunt întotdeauna entuziasmați de partajarea setărilor de acces PDU cu nimeni.
În acest caz, alternativa recomandată este crearea unui terț neutru care să suplimenteze calculul cvorumului.
În cazul unei defecțiuni, un nod trebuie să fie capabil să vadă undele emise de peer sau arbitru pentru a restabili serviciile. Arbitrul include și o funcție de deconectare dacă ambele noduri îl pot vedea pe arbitru, dar nu se pot vedea unul pe celălalt.
Această opțiune trebuie utilizată împreună cu o metodă indirectă de disociere, cum ar fi un temporizator de supraveghere hardware, care este configurat pentru a ucide o mașină dacă își pierde conexiunea la nodul său egal și de arbitru. Astfel, un supraviețuitor poate presupune în mod rezonabil că nodul său peer va fi într-o stare sigură după expirarea temporizatorului de supraveghere hardware.
Diferența practică dintre un arbitru și un al treilea nod este că un arbitru necesită mult mai puține resurse pentru a funcționa și poate deservi mai mult de un cluster.
Opțiunea 3 - Factorul uman
Abordarea finală este ca supraviețuitorii să continue să ruleze orice servicii pe care le rulau deja, dar să nu înceapă altele noi până când fie problema se rezolvă de la sine (restaurarea rețelei, repornirea nodului) sau o persoană își asumă responsabilitatea pentru a confirma manual că cealaltă parte este moartă.
Opțiune bonus
Am menționat că puteți adăuga un al treilea nod?
Două rafturi
De dragul argumentării, să presupunem că v-am convins de meritele celui de-al treilea nod, acum trebuie să luăm în considerare aranjarea fizică a nodurilor. Dacă sunt găzduite (și alimentate) în același rack, acesta constituie și SPoF și unul care nu poate fi rezolvat prin adăugarea unui al doilea rack.
Dacă acest lucru este surprinzător, luați în considerare ce s-ar întâmpla dacă un rack cu două noduri s-ar defecta și modul în care nodul supraviețuitor ar diferenția între acesta și o defecțiune a rețelei.
Răspunsul scurt este că nu este posibil și, din nou, avem de-a face cu toate problemele din cazul cu două noduri. Sau supraviețuitor:
- ignoră cvorumul și încearcă în mod incorect să inițieze restabilirea în timpul întreruperii rețelei (capacitatea de a finaliza disocierea este o poveste diferită și depinde dacă PDU-ul este implicat și dacă împart puterea cu oricare dintre rafturi) sau
- respectă cvorumul și se deconectează prematur atunci când nodul său egal eșuează
În orice caz, două rafturi nu sunt mai bune decât unul, iar nodurile trebuie fie să primească surse de alimentare independente, fie să fie distribuite pe trei rafturi (sau mai multe, în funcție de câte noduri aveți).
Două centre de date
În acest moment, cititorii care nu mai sunt dezvăluiți la risc ar putea dori să ia în considerare recuperarea în caz de dezastru. Ce se întâmplă când un asteroid lovește același centru de date cu cele trei noduri ale noastre răspândite pe trei rafturi 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 în mod rezonabil) o copie actualizată și consecventă a serviciilor dvs. și a datelor acestora. Cu toate acestea, ca și în scenariile cu două noduri, două rafturi, nu există suficiente informații în sistem pentru a asigura disponibilitatea maximă și pentru a preveni corupția (sau discrepanța setului de date). Chiar și cu trei noduri (sau rafturi), distribuirea acestora în doar două centre de date face ca sistemul să nu poată lua decizia corectă în mod fiabil în cazul unui eveniment (acum mult mai probabil) pe care ambele părți nu pot comunica.
Acest lucru nu înseamnă că o soluție de centru de date dual nu este niciodată potrivită. Companiile doresc adesea ca o persoană să fie conștientă înainte de a face pasul extraordinar de a trece la un centru de date de rezervă. Rețineți că, dacă doriți să automatizați întreruperea, fie veți avea nevoie de un al treilea centru de date pentru ca cvorumul să aibă sens (fie direct, fie prin intermediul unui arbitru), fie veți găsi o modalitate de a închide în mod fiabil toate datele. centru.
Sursa: www.habr.com