Clustering presupune existena unui al doilea sistem configurat sa stea in
asteptare pentru un sistem primar. In cazul in care sistemul primar esueaza,
sistemul aflat in asteptare, dupa o scurta intrerupere a serviciului preia functiile sistemului primar. Deoarece serverul aflat in asteptare preia intr-un interval scurt de timp sarcinile serverului primar, timpul de nefunctionare se reduce la acest interval. Defectarile server si procedeul de failover O modalitate practica pentru a reduce timpul de nefunctionare in cazul defectiunilor la nivel de server o constituie folosirea a doua sau mai multe servere interconectate, impreuna cu software de control care permite preluarea sarcinilor serverului defectat in mod automat. Preluarea se realizeaza cu intreruperea serviciilor, insa aceasta intrerupere este de scurta durata. Pentru a asigura consistenta datelor si recuperarea rapida, serverele trebuie conectate la aceleasi discuri partajate. om considera cazul serverelor aflate in acelasi site. Cazul serverelor aflate la distanta si migrarea aplicatiilor pe un site aflat la distanta, desi pare similar, introduce alte nivele de complexitate si intra in cazul strategiilor de disaster recover!. "igrarea serviciilor de pe un server pe un altul poarta denumirea de failover. Procedeul de failover trebuie sa indeplineasca cel putin urmatoarele criterii# - transparenta# procedeul nu trebuie sa fie intrusiv pentru clientii care acceseaza serverul, in sensul ca ei nu trebuie sa faca operatiuni speciale pentru a isi relua munca dupa ce serviciul a fost restaurat. Operatiunile uzuale ce trebuie efectuate constau in reautentificarea clientilor in aplicatiile ce necesita acest lucru. - rapiditate# procesul de failover nu ar trebui sa dureze mai mult de cateva minute, interval de timp acceptabil pentru majoritatea aplicatiilor. - operatii manuale minime: de preferat sa nu fie nevoie de interventie umana deloc, intregul proces ar trebui sa fie automat. - Garantarea accesului la date: dupa failover, sistemul care preia serviciul ar trebui sa primeasca aceleasi date ca si sistemul original. $eplicarea datelor pe un alt %ost in cazul discurilor nepartajate adauga riscuri si complexitate inutila si nu este recomandata pentru sisteme care se afla unul langa celalalt. &istemele dintr-o configuratie failover trebuie sa comunice intre ele neintrerupt astfel incat fiecare sistem sa cunoasca starea partenerului. 'ceasta comunicare este numita heartbeat. ( Cand apare evenimentul de failover, trei elemente critice trebuie mutate de pe serverul care a esuat pe cel care preia serviciul, pentru ca utilizatorii sa-si poata relua activitatile si pentru ca aplicatiile sa poata fi reconsiderate disponibile. - Identitatea in retea# in general aceasta inseamna adresa IP pe care o folosesc clientii serverului. )nele aplicatii si medii pot solicita informatii suplimentare cum ar fi adresa "'C, iar daca serverul se afla in mai multe retele sau are indentitati publice multiple, poate fi necesara mutarea mai multor adrese. - Accesul la discurile partajate# &istemele de operare si c%iar unele te%nologi files!stem interzic in general scrierea pe acelasi disc in acelasi timp de catre mai multe servere. Intr-o configuratie de discuri partajate, accesul logic trebuie restrictionat la un singur server la un momendat. In timpul procesului de failover, procesul care opreste a doua masina sa acceseze discurile, trebuie sa-si sc%imbe comportamentul si sa bloc%eze serverul original, in acelasi timp cu permiterea accesului serverului care a preluat controlul. - Setul de procese# odata cu migrarea discurilor la serverul care a preluat controlul, toate procesele legate de date trebuie repornite. Consistenta datelor trebuie asigurata din perspectiva aplicatiei. 'ceasta colectie de elemente este cunoscuta in mod obisnuit ca service group. )n grup de servicii reprezinta unitatea care se muta de pe un membru al cluster-ului pe alt membru. )neori numite si virtual machine, grupul de servicii ofera serviciile critice pentru care se realizeaza disponibilitatea ridicata. )n cluster poate avea mai multe grupuri de servicii, si in functie de softul care gestioneaza clusterul, este posibil sa nu fie o limitare a numarului de grupuri de servicii. *rupurile de servicii trebuie sa fie absolut independente intre ele astfel incat sa poata functiona pe oricare din serverele din cluster, indiferent de starea celorlalte grupuri de servicii. O colectie de servere aflate in cluster trebuie privita intr-un mod netraditional, prin prisma grupului de servicii pe care le ofera. In principiu reprezinta un dispozitiv ce livreaza o aplicatie sau un serviciu in retea. &erverul insusi devine o componenta intr-un mecanism de livrare aplicatii+servicii. Daca acesta se defecteaza, el trebuie sa poata fi inlocuit cu un altul si sistemul sa continue functionarea. ,ailover "anagement &oftware, este softul care automatizeaza procesul de failover, realizand acest - sc%imb automat prin mutarea grupului de servicii pe al doilea sistem care a fost configurat si predestinat pentru aceasta functie. In unele configuratii, al doilea sistem se afla in starea de asteptare a unui grup de servicii, in altele el realizeaza alte functii si va accepta grupul de servicii in plus fata de functionalitatile sale de pana atunci. Intr-o configuratie de tip cluster, o adresa IP nu face legatura cu un anumit server ci mai degraba cu un anumit grup de servicii care foloseste acel nume la acel moment. .umele si adresa IP, se pot gasi pe orice masina din cluster si nu este important pentru utilizatori ce masina din configuratie ruleaza aplicatia, ci faptul ca aplicatia ruleaza si ca ei au acces la serviciul pe care aceasta il ofera. Cerinte pentru failover Pentru a implementa un cluster failover e nevoie de mai mult decat de doua servere plasate unul langa celalat. Componentele necesare realizarii unui cluster sunt # - Serverele: minim doua. /ste de preferat ca acestea sa ruleze aceeasi versiune de sistem de operare, sa aiba aceleasi patc%-uri instalate, pe cat posibil sa fie configurate identic - Conexiuni de retea: &unt doua tipuri de conexiuni de retea necesare pentru a implementa failover si o a treia care este recomandata. O perec%e 0pt redundanta1 de retele dedicate pentru heartbeat, ce functioneaza intre toate serverele din cluster este cerinta de baza. 'ceste retele permit serverelor sa comunice si sa se monitorizeze unele pe altele, cu un minim de trafic astfel incat fiecare server stie imediat daca s-a intamplat ceva cu un membru din cluster ce necesita anumite actiuni. 'l doilea tip de conexiunie de retea o reprezinta reteaua publica sau reteaua serviciului. /ste reteaua prin care sunt sc%imbate date cu clientii. 'l treilea tip de retea este reteaua administrativa care permite administratorilor de sistem sa acceseze serverele c%iar si dupa ce a aparul un failover. - Discurile: &unt doua tipuri diferite de discuri necesare pentru un failover. Discurile nepartajate ce contin sistemul de operare si alte fisiere ce sunt necesare pentru operarea fiecarui server din cluster cand nu este server activ si orice soft necesar pentru initierea si realizarea procesului de failover. 'l doilea tip de discuri este reprezentat de discurile partajate, unde se afla datele de aplicatie critice. 'cestea sunt discurile care migreaza intre servere cand apare failover. /le trebuie sa poata fi accesate de toate serverele din configuratie, desi vor fi accesate de un singur server la un 2 momendat. 3oate discurile, atat cele partajate cat si cele nepartajate ce servesc un cluster ar trebui sa aiba un grad de redundanta. 0in general este preferata oglindirea in locul datelor de paritate1. In unele configuratii numite shared nothing, datele de pe un server sunt replicate prin retea catre celalat server. - Portabilitatea aplicatiei. )n element vital dar adesea trecut cu vederea in designul failover il reprezinta cerinta ca aplicatiile critice sa poata rula pe ambele servere din perec%e, pe rand 0licentierea1. Daca acest aspect nu este indeplinit atunci nu obtineti disponibilitate ridicata. )neori este nevoie de cumpararea licentelor pentru fiecare server. - Nici un punct unic de esec. /ste un principiu de proiectare decat o componenta fizica, totusi este un tel important in realizarea clusterelor. Daca exista o singura componenta in perec%ea de failover a carei defectare cauzeaza nefunctionarea ambelor servere atunci nu obtineti disponibilitate ridicata. Failover Management Software 3oate metodele de failover management pornesc de la acelasi lucru# monitorizarea componentelor c%eie ale sistemelor, componente a caror nefunctionare induce oprirea serviciilor oferite de aplicatiile critice. Partea %ardware este de obicei cel mai simplu de monitorizat. Pot fi discurile accesate4/xista conectivitate la nivel retea4/ste sistemul 5 functional4/xista teste relativ simple pentru a monitoriza starea curenta pentru fiecare din componentele fizice.In plus tipurile de componente fizice nu este asa mare, deci un numar mic de teste trebuie create si gestionate. De exemplu testul care monitorizeaza functionarea unui disc poate fi folosit pentru a monitoriza functionarea oricarui disc. Desi exista unele dificultati si in determinarea stari de functionare a unor componente fizice 0diferenta intre un sistem care raspunde cu intarziere si unul care nu functioneaza1, totusi este mult mai usor de monitorizat componente fizice decat aplicatii. /xista mai multe modalitati de monitorizare a functionarii aplicatiilor. Cea mai simpla, dar si cea mai slaba metoda o reprezinta monitorizarea tabelei de procese a sistemului. Desi ofera informatii despre procesele ce ruleaza, aceasta metoda nu ofera informatii despre rularea corecta a proceselor. Pentru testarea functionarii apliatiilor se pot dezvolta intern soft- uri de monitorizare sau se pot folosi soft-uri comerciale.0/$I3'& Cluster &erver, "& Cluster &erver, &un Clusterm, 6P "C+&erviceguard, I7" 6'+C"P etc.1 Failover Configuration ActivePassive Failover: /ste punctul de plecare in orice configuratie de cluster. Intr-o astfel de configuratie exista un server master, care ofera toate serviciile critice in mod normal. /l este conectat prin intermediul a doua retele de heartbeat de serverul partener, nodul de rezerva. 'mbele servere sunt conectate la aceleasi seturile de discuri si la reteaua publica in care se afla clientii. 8 &erverele partajeaza o singura adresa IP care este migrata de catre ,"& de la un server la celalalt in timpul procesului de failover. Doar un server din perec%e detine adresa la un momendat si orice conflict de proprietate este gestionat de ,"&. Consideratii si probleme# Intr-o astfel de configurati se ac%izitioneaza practic doua sisteme pentru a realiza treaba unuia singur. )nul din ele este in majoritatea timpului inactiv, consumand energie, efort administrativ, spatiu in data center, si alte resurse. 3otusi aceasta configuratie este in timp cea cu disponibilitatea mai mare, intrucat neexistand procese inutile care sa ruleze pe cel de-al doilea server, exista putine posibilitati ca acesta sa esueze. Activeactive failover: Principala diferenta fizica a acestui model este aceea ca fiecare server va avea in mod obisnuit mai mult de o conexiune la reteaua publica. 'devarata diferenta intre o configuratie activ-activ si activ-pasiv este ca in configuratia activ-activ ambele servere ruleaza aplicatiile critice in acelasi timp. ,iecare server actioneaza ca server de rezerva pentru celalalt server din cluster, in timp ce livreaza propriile servicii critice. Cand un server esueaza, partenerul sau preia si serviciile acestuia pana cand serverul defect este reparat sau inlocuit. Din perspectiva pura a costurilor, varianta activ-activ este una mai buna, intrucat utilizeaza mai eficient %ardware-ul. /xista insa doua inconveniente in cazul acetor configuratii. $iscul ca in cazul defectarii unui server celalalt sa nu fie capabil sa preia functiile partenerului atunci cand ii este solicitat acest lucru din cauza problemelor cu serviciile propri.Daca toate aplicatiile din cluster sunt bine testate si mature, 9 acest risc este acceptabil de scazut. 'l doilea inconvenient il reprezinta impactul de performanta inevitabil asupra serverului care preia serviciile serverului defect. O solutie pentru aceasta problema ar putea fi ac%izitionarea de putere de calcul suprimentara 0CP) si+sau memorie1 pentru ambele servere. 3otusi aceasta nu garanteaza ca aceasta putere suplimentara va fi folosita la failover, datorita tendintei aplicatiilor de a folosi toate resursele disponibile. /ste foarte probabil ca aceste resurse sa fie folosite de aplicatiile rezidente si sa nu fie disponibile atunci cand este nevoie de ele. /ste foarte important ca serverele sa fie independente unul de celalalt, nu se poate folosi unul dintre ele ca si client pentru celalalt. 'ltfel in caz de failover el va influentat de nefunctionarea celuilalt. : Clustere N to ! : 'cest model foloseste un singur sistem de rezerva pentru toate cele . sisteme din cluster. Intr-o implementare a unui astfel de cluster folosind &C&I, nodul de rezerva trebuie sa aiba acces la toate discurile, cand serverul care a esuat redevine functional este necesar ca serviciile ce au fost preluate sa fie mutate iar de acesta pentru a putea elibera nodul de rezerva si a-l face disponibil pentru preluarea unui alt grup de servicii. &'.-ul simplifica mult proiectarea si implementarea clusterelor .-la-(, prin faptul ca toate serverele sunt conectate identic la storage. Clusterele .-la-( bazate pe &C&I au limitari serioase prin faptul ca introduc un timp suplimentar de nefunctionare dupa ce serverul care a esuat a fost reparat, pentru migrarea serviciilor de pe serverul de rezerva inapoi pe serverul care a esuat. In clusterele ce folosesc &'., toate nodurile pot vedea toate discurile asadar nu mai este necesara remigrarea serviciilor pe serverul original. ; <