Să ne concentrăm mai mult pe unele dintre principiile arhitecturale mai mari ale gestionării clusterelor decât pe orice soluție tehnologică unică.

Vom vedea câteva implementări reale mai târziu în carte – și puteți afla multe despre modul în care funcționează acest lucru pe AWS-ul Amazonului în Aflați Amazon Web Services într-o carte de o lună de prânz din Manning. Dar, deocamdată, să ne asigurăm mai întâi că suntem confortabili cu elementele de bază.

Rularea operațiunilor serverului utilizând clustere de computere fizice sau virtuale are ca scop îmbunătățirea atât a fiabilității, cât și a performanței, dincolo de ceea ce vă puteți aștepta de la un singur server de mare putere. Adăugați fiabilitate evitând suspendarea întregii infrastructuri într-un singur punct de eșec (adică un singur server). Și puteți crește performanța prin capacitatea de a adăuga foarte repede puterea și capacitatea de calcul prin scalare în sus și în afară.

Acest lucru s-ar putea întâmpla prin distribuirea inteligentă a sarcinilor dvs. de muncă în diverse medii geografice și de cerere (echilibrarea încărcării), oferind
servere de rezervă care pot fi puse rapid în funcțiune în cazul în care un nod funcționează eșuează (failover), optimizând modul în care este implementat nivelul dvs. de date sau permite toleranța la erori prin arhitecturi cuplate slab.

Vom ajunge la toate astea. Mai întâi, însă, iată câteva definiții de bază:

Nodul: O singură mașină (fizică sau virtuală) care rulează operațiuni de server în mod independent pe propriul sistem de operare. Deoarece orice nod unic poate eșua, îndeplinirea obiectivelor de disponibilitate necesită ca mai multe noduri să funcționeze ca parte a unui cluster.

Cluster: Două sau mai multe noduri de server care rulează în coordonare între ele pentru a finaliza sarcini individuale ca parte a unui serviciu mai mare, în care conștientizarea reciprocă permite unuia sau mai multor noduri să compenseze pierderea altuia.

Eroare server: Incapacitatea unui nod server de a răspunde în mod adecvat la solicitările clientului. Acest lucru s-ar putea datora unui accident complet, a unor probleme de conectivitate sau pentru că a fost copleșit de o cerere mare.

Failover: Modul în care un cluster încearcă să răspundă nevoilor clienților orfani de eșecul unui singur nod de server prin lansarea sau redirecționarea altor noduri pentru a umple un gol de serviciu.

Failback: Restabilirea responsabilităților la un nod server pe măsură ce se recuperează dintr-un eșec.

Replicare: Crearea de copii ale magazinelor de date critice pentru a permite accesul sincron de încredere de la mai multe noduri de server sau clienți și pentru a se asigura că vor supraviețui dezastrelor. Replicarea este, de asemenea, utilizată pentru a permite echilibrarea fiabilă a sarcinii.

Redundanţă: Furnizarea mai multor noduri identice ale serverului fizic sau virtual, din care oricine poate adopta clienții orfani ai altuia care nu reușește.

Creier impartit: O stare de eroare în care comunicațiile de rețea între noduri sau stocarea partajată s-au întrerupt cumva și mai multe noduri individuale, fiecare crezând că este singurul nod încă activ, continuă să acceseze și să actualizeze o sursă de date comună. Deși acest lucru nu are impact asupra proiectelor partajate, poate duce la erori ale clienților și corupția datelor în cadrul clusterelor partajate.

Împrejmuire: Pentru a preveni creierul divizat, demonul stonithd poate fi configurat pentru a opri automat un nod care nu funcționează sau pentru a impune un gard virtual între acesta și resursele de date ale restului unui cluster. Atâta timp cât există șansa ca nodul să fie în continuare activ, dar nu se coordonează corect cu restul clusterului, acesta va rămâne în spatele gardului. Stonith înseamnă „Trageți celălalt nod din cap”. Într-adevăr.

Cvorum: Puteți configura împrejmuirea (sau oprirea forțată) pentru a fi impuse nodurilor care au căzut în contact unul cu celălalt sau cu o resursă partajată. Cvorumul este adesea definit ca mai mult de jumătate din toate nodurile din clusterul total. Folosind astfel de configurații definite, evitați să aveți două subclustere de noduri, fiecare crezând că celălalt funcționează defectuos, încercând să îl elimine pe celălalt.

Recuperare în caz de dezastruy: Infrastructura dvs. poate fi considerată cu greu disponibilă dacă nu aveți un sistem de backup automat instalat împreună cu un plan de recuperare în caz de dezastru integrat și testat. Planul dvs. va trebui să țină cont de redistribuirea fiecăruia dintre serverele din clusterul dvs.

Cluster activ / pasiv

Ideea din spatele failover-ului serviciului este că pierderea bruscă a oricărui nod dintr-un cluster de servicii ar fi repede alcătuită de un alt nod care să-i ia locul. Pentru ca acest lucru să funcționeze, adresa IP este mutată automat în nodul de așteptare în cazul unei reluări. Alternativ, instrumentele de rutare a rețelei, cum ar fi echilibratoarele de sarcină, pot fi folosite pentru a redirecționa traficul de la nodurile eșuate. Modul precis de reluare a eșecului depinde de modul în care v-ați configurat nodurile.

Doar un singur nod va fi configurat inițial pentru a deservi clienții și va continua să facă acest lucru singur până când nu cumva eșuează. Responsabilitatea pentru clienții existenți și noi va trece apoi (adică „failover”) la nodul pasiv – sau de rezervă – care până acum a fost păstrat pasiv în rezervă. Aplicând modelul pe mai multe servere sau componente ale camerei serverului (cum ar fi sursele de alimentare), redundanța n + 1 oferă resurse suficiente pentru cererea actuală, plus încă o unitate pentru acoperirea unei defecțiuni.

O introducere in calculul de inalta disponibilitate concepte si teorie
1611204132 490 O introducere in calculul de inalta disponibilitate concepte si teorie

Cluster activ / activ

Un cluster care utilizează un design activ / activ va avea două sau mai multe noduri configurate identic care deservesc clienții în mod independent.

1611204132 916 O introducere in calculul de inalta disponibilitate concepte si teorie

În cazul în care un nod eșuează, clienții săi se vor conecta automat cu al doilea nod și, în măsura în care resursele permit, vor primi acces complet la resurse.

1611204133 798 O introducere in calculul de inalta disponibilitate concepte si teorie

Odată ce primul nod se recuperează sau este înlocuit, clienții vor fi din nou împărțiți între ambele noduri de server.

Avantajul principal al executării clusterelor active / active constă în capacitatea de a echilibra eficient o sarcină de lucru între noduri și chiar rețele. Echilibratorul de încărcare – care direcționează toate cererile de la clienți către serverele disponibile – este configurat pentru a monitoriza activitatea nodului și a rețelei și pentru a utiliza un algoritm predeterminat pentru a direcționa traficul către acele noduri cele mai capabile să o gestioneze. Politicile de rutare ar putea urma un model rotund, în care cererile clienților sunt pur și simplu alternate între nodurile disponibile sau printr-o greutate prestabilită în care un nod este favorizat față de altul de un anumit raport.

Având un nod pasiv care acționează ca un înlocuitor stand-by pentru partenerul său într-o configurație de cluster activ / pasiv oferă o redundanță încorporată semnificativă. Dacă operațiunea dvs. necesită în mod absolut un serviciu neîntrerupt și tranziții fără failover, atunci o anumită variantă a unei arhitecturi active / pasive ar trebui să fie scopul dvs.

Shared-Nothing vs. Shared-Disc Clusters

Unul dintre principiile directoare ale calculelor distribuite este să evitați ca operațiunea dvs. să se bazeze pe un singur punct de eșec. Adică, fiecare resursă ar trebui fie să fie replicată activ (redundantă), fie înlocuibilă în mod independent (failover) și nu ar trebui să existe un singur element al cărui eșec ar putea să doboare întregul dvs. serviciu.

Acum, imaginați-vă că rulați câteva zeci de noduri care se bazează pe un singur server de baze de date pentru funcția lor. Chiar dacă eșecul oricărui număr de noduri nu va afecta sănătatea continuă a acelor noduri care rămân, în cazul în care baza de date va merge în jos, întregul cluster ar deveni inutil. Cu toate acestea, nodurile dintr-un cluster de nimic partajat își vor menține (de obicei) propriile baze de date, astfel încât – presupunând că sunt sincronizate și configurate în mod corespunzător pentru siguranța tranzacției în curs – niciun eșec extern nu le va afecta.

Acest lucru va avea un impact mai semnificativ asupra unui cluster echilibrat de încărcare, deoarece fiecare nod echilibrat de încărcare are o nevoie constantă și critică de acces simultan la date. Cu toate acestea, nodul pasiv al unui sistem simplu de failover ar putea supraviețui o vreme fără acces.

1611204133 954 O introducere in calculul de inalta disponibilitate concepte si teorie
1611204134 673 O introducere in calculul de inalta disponibilitate concepte si teorie

În timp ce o astfel de configurare ar putea încetini modul în care clusterul răspunde la anumite cereri – parțial pentru că temerile de eșecuri ale creierului divizat ar putea necesita împrejmuiri periodice prin stonit – compromiterea poate fi justificată pentru desfășurarea misiunilor critice în care fiabilitatea este considerarea principală.

Disponibilitate

Când vă proiectați clusterul, va trebui să aveți un bun simț al cât de tolerant puteți fi la eșec. Sau, cu alte cuvinte, având în vedere nevoile oamenilor sau mașinilor care vă consumă serviciile, cât de mult poate dura o întrerupere a serviciului înainte ca mafia să vină prin porțile din față cu furci și torțe aprinse. Este important să știți acest lucru, deoarece cantitatea de redundanță pe care o construiți în proiectul dvs. va avea un impact enorm asupra perioadelor de nefuncționare pe care le veți confrunta în cele din urmă.

Evident, sistemul pe care îl construiți pentru un serviciu care poate merge în jos pentru un weekend fără ca nimeni să observe nu va fi foarte diferit de un site de comerț electronic ai cărui clienți așteaptă acces nonstop. Cel puțin, ar trebui să vizați în general o medie a disponibilității de cel puțin 99% – cu unele operațiuni care necesită rezultate semnificativ mai mari din lumea reală. Timpul de până la 99% s-ar traduce printr-o pierdere mai mică de un total de patru zile din fiecare an.

Există o formulă relativ simplă pe care o puteți utiliza pentru a construi o estimare utilă a disponibilității (A). Ideea este de a împărți timpul mediu înainte de eșec la timpul mediu înainte de eșec, plus timpul mediu de reparare.

A = MTBF / (MTBF + MTTR)

Cu cât valoarea lui A se apropie de 1, cu atât clusterul dvs. va fi mai disponibil. Pentru a obține o valoare realistă pentru MTBF, probabil că va trebui să petreceți timp expunând un sistem real la o pedeapsă serioasă și urmărind-o cu atenție pentru a detecta eșecuri de software, hardware și rețea. Presupun că ați putea consulta, de asemenea, valorile publicate ale ciclului de viață ale furnizorilor de hardware sau ale consumatorilor la scară largă, cum ar fi Backblaze, pentru a vă face o idee despre cât de mult poate fi de așteptat să reziste hardware-ul foarte utilizat.

MTTR va fi un produs al timpului necesar grupului dvs. pentru a înlocui funcționalitatea unui nod server care nu a reușit (un proces similar cu, deși nu identic cu recuperarea în caz de dezastru – care se concentrează pe înlocuirea rapidă a hardware-ului și conectivității eșuate). În mod ideal, aceasta ar fi o valoare cât mai aproape de zero secunde posibil.

1611204134 375 O introducere in calculul de inalta disponibilitate concepte si teorie
Disponibilitatea serverului

Problema este că, în lumea reală, există de obicei prea multe variabile necunoscute pentru ca această formulă să fie cu adevărat precisă, deoarece nodurile care rulează diferite configurații software și construite cu hardware de profiluri și vârste variate vor avea o gamă largă de speranțe de viață. Cu toate acestea, poate fi un instrument bun pentru a vă ajuta să identificați designul clusterului cel mai potrivit pentru proiectul dvs.

Cu aceste informații, puteți genera cu ușurință o estimare a duratei de nefuncționare generală pe care serviciul dvs. o va avea probabil pe parcursul unui an întreg.

Un aspect asemănător, dacă vă implementați resursele pe un furnizor terț de platforme, cum ar fi VMWare sau Amazon Web Services, este Acordul de nivel de serviciu (SLA) al furnizorului. EC2 de la Amazon, de exemplu, garantează că instanțele lor de calcul și dispozitivele de stocare a magazinului de blocuri vor oferi un procent lunar de funcționare de cel puțin 99,95% – care este mai puțin de cinci ore de funcționare pe an. AWS va emite credite pentru lunile în care și-au ratat obiectivele – deși nu sunt suficient de mari pentru a compensa costurile totale ale afacerii timpului tău de nefuncționare. Cu aceste informații, puteți aranja un nivel de redundanță a serviciilor adecvat nevoilor dvs. unice.

Bineînțeles, ca furnizor de servicii pentru clienții dvs., poate fi necesar să vă publicați propriul SLA pe baza estimărilor MTBF și MTTR.

Gestionarea sesiunii

Pentru orice relație server-client, datele generate de sesiunile HTTP stabile trebuie să fie salvate într-un mod care să le facă disponibile pentru interacțiuni viitoare. Arhitecturile de cluster pot introduce complexitate serioasă în aceste relații, deoarece serverul specific cu care un client sau un utilizator interacționează s-ar putea schimba între un pas și următorul.

Pentru a ilustra, imaginați-vă că sunteți conectat la Amazon.com, căutați cărțile lor despre instruirea LPIC și adăugați periodic un articol în coș (sperăm, mai multe exemplare ale acestei cărți). În momentul în care sunteți gata să introduceți informațiile de plată și să verificați, totuși, este posibil ca serverul pe care l-ați navigat să nu mai existe. Cum va ști serverul dvs. actual ce cărți ați decis să achiziționați?

Nu știu exact cum gestionează Amazon acest lucru, dar problema este adesea abordată printr-un instrument de replicare a datelor, cum ar fi memcached care rulează pe un
nod extern (sau noduri). Scopul este de a oferi acces constant la o sursă de date fiabilă și consecventă la orice nod care ar putea avea nevoie de ea.

Acest articol este adaptat din „Învățați-vă virtualizarea Linux și disponibilitate ridicată: pregătiți-vă pentru examenul de certificare LPIC-3 304”. Verifică-mi alte cărți despre administrarea AWS și Linux, inclusiv Linux în acțiune și Linux în mișcare– un curs hibrid format din mai mult de două ore de videoclip și aproximativ 40% din textul Linux în acțiune.