Cluster de failover

Cluster de failover ( în engleză  High-Availability cluster , HA cluster  - high availability cluster ) - un cluster (grup de servere ), proiectat în conformitate cu tehnici de înaltă disponibilitate și care garantează timpi de nefuncționare minim din cauza redundanței hardware. Fără grupare, o defecțiune a serverului face ca aplicațiile sau serviciile de rețea pe care le acceptă să fie indisponibile până când se face backup. Gruparea de failover corectează această situație prin repornirea aplicațiilor pe alte noduri din cluster fără intervenția administratorului dacă sunt detectate defecțiuni hardware sau software. Procesul de repornire este cunoscut sub numele de failover . Ca parte a acestui proces, software-ul de clustering poate configura în continuare nodul înainte de a rula aplicația pe acesta (de exemplu, importați și montați sistemele de fișiere adecvate, reconfigurați hardware-ul rețelei sau rulați orice aplicații utilitare).

Clusterele de failover sunt utilizate pe scară largă pentru a sprijini bazele de date critice , stocarea fișierelor în rețea, aplicațiile de afaceri și sistemele de servicii pentru clienți, cum ar fi site- urile de comerț electronic .

Implementările clusterelor HA sunt încercări de a atinge toleranța la erori a clusterului în ansamblu prin eliminarea punctelor critice de defecțiune, inclusiv prin redundanța puterii de calcul, a conexiunilor de rețea și a stocării de date, combinate într-un SAN redundant .

Cerințele arhitecturii aplicației

Nu orice aplicație poate rula într-un mediu cluster foarte disponibil. Deciziile adecvate ar trebui stabilite într-un stadiu incipient al dezvoltării software-ului. Pentru a rula într-un cluster HA, o aplicație trebuie să îndeplinească cel puțin următoarele cerințe tehnice, dintre care ultimele două sunt critice pentru funcționarea sa fiabilă într-un cluster și care sunt cele mai dificil de satisfăcut pe deplin:

• Ar trebui să existe o modalitate relativ simplă de a porni, de a opri, de a forța oprirea și de a verifica starea unei aplicații. În practică, aceasta înseamnă că aplicația trebuie să aibă o interfață de linie de comandă sau scripturi pentru a o gestiona, inclusiv pentru a lucra cu mai multe instanțe care rulează ale aplicației.
• Aplicația trebuie să poată utiliza stocarea de date partajată ( NAS / SAN ).
• Este foarte important ca aplicația să stocheze cât mai multe date despre starea sa actuală într-un spațiu de stocare partajat nedistructibil. În mod corespunzător, capacitatea unei aplicații de a fi repornită pe un alt nod într-o stare premergătoare eșecului folosind datele de stare din depozitul partajat este la fel de importantă.
• Aplicația nu trebuie să corupă datele atunci când se blochează sau este restaurată dintr-o stare salvată.

Scheme de construcție

Cele mai comune clustere HA cu două noduri sunt configurația minimă necesară pentru a oferi toleranță la erori. Dar adesea clusterele conțin mult mai multe, uneori zeci de noduri. Toate aceste configurații pot fi descrise în general de unul dintre următoarele modele:

• Activ / activ - O parte din traficul procesat de nodul eșuat este redirecționată către un nod de lucru sau distribuit între mai multe noduri de lucru. Această schemă este utilizată atunci când nodurile au o configurație software omogenă și îndeplinesc aceeași sarcină.
• Activ / pasiv - Are o redundanță completă (copie sănătoasă) a fiecărui nod. Rezerva intră în funcțiune numai atunci când nodul principal corespunzător eșuează. Această configurație necesită un hardware redundant semnificativ.
• N + 1 - Are un nod de rezervă cu drepturi depline, căruia îi trece rolul nodului eșuat în momentul eșecului. În cazul unei configurații software eterogene a nodurilor primare, nodul secundar trebuie să poată prelua rolul oricăruia dintre nodurile primare de care este responsabil în mod redundant. Această schemă este utilizată în clustere care deservesc mai multe servicii eterogene care rulează simultan; in cazul unui singur serviciu, o astfel de configuratie degenereaza in Activ/pasiv.
• N + M - Dacă un singur cluster deservește mai multe servicii, inclusiv un singur nod redundant poate să nu fie suficient pentru un nivel adecvat de redundanță. În astfel de cazuri, clusterul include mai multe servere redundante, al căror număr este un compromis între prețul soluției și fiabilitatea necesară.
• N-to-1 - Permite nodului de așteptare să intre temporar online până când nodul eșuat este restaurat, după care încărcarea inițială este returnată la nodul primar pentru a menține nivelul original de disponibilitate a sistemului.
• N-to-N este o combinație de clustere active/active și N + M. Într-un cluster N-la-N, serviciile, instanțele de sistem sau conexiunile de la un nod eșuat sunt redistribuite către nodurile active rămase. Acest lucru elimină (ca și în schema activă / activă) necesitatea unui nod de așteptare separat, dar, în același timp, toate nodurile de cluster trebuie să aibă o oarecare capacitate în exces peste minimul necesar.

Termenii gazdă logică sau gazdă logică în cluster sunt utilizați pentru a se referi la adresa de rețea care este utilizată pentru a accesa serviciile furnizate de cluster. ID-ul logic al gazdei nu este legat de un singur nod de cluster. Este de fapt o adresă/nume de rețea care este asociată cu serviciul(e) furnizat(e) de cluster. Dacă un nod de cluster cu, de exemplu, o bază de date care rulează, scade, baza de date va fi repornită pe un alt nod de cluster, iar adresa de rețea la care utilizatorii accesează baza de date va fi păstrată pentru orice nod nou, astfel încât utilizatorii vor avea în continuare acces la baza de date .

Fiabilitatea unui singur nod

Clusterele HA, în plus față de schemele de redundanță între noduri descrise, folosesc toate metodele utilizate de obicei în sisteme separate (non-cluster) și infrastructura de rețea pentru a maximiza fiabilitatea. Acestea includ:

• Redundanța și replicarea discurilor: Eșecul unora dintre discurile interne nu duce la defecțiuni ale sistemului. DRBD este un exemplu.
• Redundanța conexiunilor externe la rețea : defecțiunile cablurilor, defecțiunile comutatorului sau ale interfeței de rețea nu duc la o deconectare completă de la rețea.
• Conexiuni interne ale rețelei de stocare redundante (SAN) : defecțiunile cablurilor, defecțiunile comutatorului sau ale interfeței de rețea nu vor cauza pierderea conexiunii serverelor la stocare (acest lucru ar rupe arhitectura nepartajată).
• Scheme de alimentare redundante pentru diverse echipamente, de obicei protejate de surse de alimentare neîntreruptibile și surse de alimentare redundante : defecțiunea unei singure intrări , cablu, UPS sau PSU nu duce la o întrerupere critică de alimentare a sistemului.

Măsurile individuale de funcționare ale nodurilor ajută la minimizarea șanselor de a recurge la mecanisme native de clustering de failover. Dacă acestea din urmă sunt activate, accesul la serviciu poate fi întrerupt, chiar dacă doar pentru o perioadă scurtă de timp, și este mai oportun să se prevină defecțiunile critice ale echipamentelor.

Algoritmi de recuperare a erorilor

Sistemele care gestionează erorile în sistemele computerizate distribuite utilizează diferite strategii pentru a face față consecințelor unei defecțiuni. De exemplu, Apache Cassandra API Hector (API) oferă trei opțiuni pentru gestionarea erorilor:

• Fail Fast , în scriptul - „FAIL_FAST”, returnează pur și simplu o eroare clientului atunci când nodul este indisponibil.
• La eșuare, încercați unul - Următorul disponibil , în scriptul - „ON_FAIL_TRY_ONE_NEXT_AVAILABLE”, înseamnă că atunci când un nod eșuează, sistemul încearcă să transfere cererea către un alt nod, cel mai liber, și returnează o eroare după prima încercare nereușită.
• La eșuare, încercați toate , în scriptul - „ON_FAIL_TRY_ALL_AVAILABLE”, înseamnă că sistemul, după prima încercare nereușită, încearcă secvenţial toate nodurile disponibile și abia apoi returnează o eroare.

Pentru a controla starea de sănătate a nodurilor dintr-un cluster, un semnal periodic continuu („puls”, bătăile inimii în engleză  ) este de obicei transmis în rețeaua internă a clusterului de la fiecare dintre noduri, prin prezența căruia software-ul de control judecă funcționarea normală. a nodurilor vecine. O problemă neevidentă, dar serioasă a „split-brain_(computing)” este legată de aceasta - în cazul unei întreruperi simultane a multor conexiuni în rețeaua internă a clusterului din cauza unei căderi de curent, a unei defecțiuni a echipamentului de rețea etc. , nodul nu va fi capabil să gestioneze corect această situație, începe să se comporte ca și cum toate celelalte noduri de cluster ar fi eșuat, pornind servicii duplicate care rulează deja în cluster, ceea ce poate duce la coruperea datelor în stocarea partajată.  

Vezi și

• Cluster (grup de calculatoare)
• Server (hardware)
• Mainframe
• Cameră cu servere

Note

Link -uri