Sunteți pe pagina 1din 9

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.
;
<