Investigarea Si Testarea Metodelor De Balansare A Traficului Pentru Baze De Date [622827]

UNIVERSITATEA “POLITEHNICA” TIMIȘOARA
FACULTATEA DE AUTOMATICĂ ȘI CALCULATOARE
MASTER TEHNOLOGII INFORMATICE

LUCRARE DE DI SERTA ȚIE

Coordonator științific:
Prof.Dr.Ing. Horia Ciocârlie

Candidat: [anonimizat]

2011

UNIVERSITATEA “POLITEHNI CA” TIMIȘOARA
FACULTATEA DE AUTOMATICĂ ȘI CALCULATOARE
MASTER TEHNOLOGII INFORMATICE

TEMA PROIECTULUI

INVESTIGAREA ȘI TESTAREA
METODELOR DE BALANSARE A TRAFICULUI
PENTRU BAZE DE DATE

2011

Cuprins

Introducere ………………………….. ………………………….. ………………………….. ………….. 6

Capitolul 1 ………………………….. ………………………….. ………………………….. ………….. 10
Noțiuni introductive ………………………….. ………………………….. ……………………… 10
1.1. Load balancers ………………………….. ………………………….. ……………………… 10
1.2. Tema proiectului ………………………….. ………………………….. …………………… 12
1.3. Motiva ția ………………………….. ………………………….. ………………………….. … 13
1.4. Obiective ………………………….. ………………………….. ………………………….. … 14

Capitolul 2 ………………………….. ………………………….. ………………………….. ………….. 16
Fundamentare teoretică ………………………….. ………………………….. ………………… 16
2.1. Funcționalitate ………………………….. ………………………….. ……………………… 16
2.2. Algoritmi de planificare ………………………….. ………………………….. …………. 18
2.3. Expedierea pachetelor ………………………….. ………………………….. ……………. 19

Capitolul 3 ………………………….. ………………………….. ………………………….. ………….. 21
Specifica ții tehnice ………………………….. ………………………….. ………………………… 21
3.1. Caracteristici ale testelor ………………………….. ………………………….. ………… 21
3.2. Struc tura cluster -ului de servere ………………………….. ………………………….. . 21
3.3. Stocarea informa țiilor ………………………….. ………………………….. ……………. 23

Capitolul 4 ………………………….. ………………………….. ………………………….. ………….. 27
Proiectarea de detaliu ………………………….. ………………………….. …………………… 27
4.1. Arhitectura aplica ției ………………………….. ………………………….. …………….. 27
4.3. Descrierea func ționalității ………………………….. ………………………….. ………. 30

Capitolul 5 ………………………….. ………………………….. ………………………….. ………….. 31
Realizarea testelor ………………………….. ………………………….. ………………………… 31
5.1. Descrierea procesului de realizare a testelor ………………………….. …………… 31

5.2. Laten ța introdusă ………………………….. ………………………….. ………………….. 31
5.3. Capacitatea de transmisie ………………………….. ………………………….. ……….. 35
5.4. Solicitări/c ereri pe r secundă ………………………….. ………………………….. ……. 38
5.5. Scalarea ………………………….. ………………………….. ………………………….. ….. 41
5.6. Performanța la supraîncă rcare ………………………….. ………………………….. …. 42
5.7. Protecția împotriva defecț iunilor ………………………….. ………………………….. 43
5.8. Persistenț a sesiunii ………………………….. ………………………….. ………………… 43

Capitolul 6 ………………………….. ………………………….. ………………………….. ………….. 44
Utilizare a aplicației ………………………….. ………………………….. ………………………. 46
6.1. Probleme întâmpinate la realizarea testelor ………………………….. ……………. 46
6.2. Compara ția testelor cu alte teste similare ………………………….. ………………. 46

Capitolul 7 ………………………….. ………………………….. ………………………….. ………….. 47
Avantaje ale utilizării acestor sisteme ………………………….. ………………………….. … 47

Concluzii ………………………….. ………………………….. ………………………….. ……………. 48

Bibliografie ………………………….. ………………………….. ………………………….. ………… 49

Cuprins al figurilor

Introducere
Figura A: Structura unei aplicații web moderne ………………………… ……7
Figura B : Balansarea traficului …………………………………………………………………8

Capitolul 3
Specifica ții tehnice
Figura 3.a. Rulare script pe server ……………………………………………26

Capitolul 4
Proiectarea de detaliu
Figura 4. a. Arhitectura cluster -ului de servere ………………………………..2 8

Capitolul 5
Realizarea testelor
Figura 5.a. Lat ența introdusă …………………………………………………3 2
Figura 5.b. Lărgimea de bandă ……………………………………………….3 5
Figura 5.c. Solicitări/ cereri per secundă ……………………………………….3 9
Figura 5.d. Performanța la supraîncărcare …… .……………………………..4 3

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Introducere

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 6
Introducere

Rețeaua Internet pe care o cunoa ștem aztăzi s -a schimbat destul de mult de -a lungul
anilor, fiind rezultatul unui proces schimbare și extindere de circa 40 de ani. În ultimii ani,
Internetul s -a răspândit foarte mult, în special din cauza posibilită ții de a publica și oferi
informa ții, prin metode simple, unui număr foarte mare de utilizatori. “De-a lungul timpului,
au apărut o mul țime de unelte de publicare de informa ții pe Internet. Primele dintre ele, cele
care au dominat pînă în 1992, au fost FTP și NetNews. În anul 1993, câ țiva cercetători de la
un centru de cercetare în fizică din Elve ția (CERN) au inventat o nouă unealtă pentru
publicarea pe Internet a infoma țiilor: World Wide Web, respectiv protocolul HTTP
(HyperText Transfer Protocol). “
[http://www.byte.ro/byte97 -08/caut.h tm]
Odată cu această apari ție, publicarea informa țiilor pe World Wide Web a cunoscut o
creștere și o răspândire uluitoare. Din acest moment, s -a produs o explozie de informa ții, iar
utilizarea Internetului a cunoscut o rapidă răspândire, numărul calculatoa relor conectate la
Internet crescând exponen țial, precum și numărul utilizatorilor. Explozia continuă și azi, iar
numărul utilizatorilor Internetului cre ște într-un ritm ame țitor și se a șteaptă ca această
creștere să continue și în următorii ani.
La înce putul Internetului, site -urile web erau foarte putine la numar, majoritatea
având un con ținut static, iar utilizatorii care le foloseau fiind într -un număr și mai mic decât
acestea. Acest lucru a însemnat că server -ele web care au găzduit site-urile se con fruntau cu
încărcări foarte mici și nu au avut probleme în a ține pasul cu cererile utilizatorilor .
Cu timpul, popularitatea Internetului a crescut exponen țial, iar site -urile web au
început să devină aplica ții web care servesc din ce în ce mai mult ca pagini web dinamice.
Această trecere de la con ținut static la con ținut dinamic a schimbat modul în care utilizatorii
interac ționează cu site -urile web; în trecut utilizatorii primeau informa ții de pe server, le
citeau, iar apoi treceau la pagina următoare, interac țiunea fiind destul de limitată. În prezent,
utilizatorii petrec mai mult timp pe un site web, iar interac țiunea este mult mai frecventă,
unele aplica ții web îndeplinind sarcini CPU intensive pentru fiecare sesiune utilizator.

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Noțiuni introductive

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 7

Figura A: Structur a unei aplica ții web moderne

După cum este redat și în figura de mai sus există un pas suplimentar; sunt câteva
etape care sunt necesare pentru a completa o cerere de utilizator. Principala diferen ță dintre
site-urile web statice și site -urile web dinamic e este pasul numărul 4 din figură, atunci când
un limbaj de scripting care se află pe server va solicita pagina cerută, în mod dinamic si apoi
redată către utilizator. De multe ori, acest lucru implică, de asemenea efectuarea de apeluri
către un server ext ern de baze de date, care adaugă timp suplimentar la perioada totală de
timp care o necesită pentru a procesa cererea.
Pe scurt, acest pas suplimentar, face diferen ța atunci când vine vorba de puterea de
calcul necesară pentru o anumită aplica ție web și timpul pe care îl necesită pentru a procesa
fiecare cerere.
Din moment ce publicarea de informa ții pe Internet a devenit u șoară, populară și
ieftină, utilizarea în mod efectiv a informa țiilor accesibile a devenit tot mai greoaie. Astfel,
sistemele de inf orma ții actuale – serverele Web – se confruntă cu o supraîncărcare și avem de –
a face cu încărcări greoaie, întreruperi și chiar blocaje pe re țea, din cauza numărului tot mai
mare de utilizatori care încearcă să acceseze informa ții disponibile pe Internet. Serverele web

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Noțiuni introductive

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 8
actuale ne oferă un serviciu extrem de util: stocarea, localizarea și prelucrarea informa țiilor
dorite, pe baza unor cereri create de utilizator. Acestea ne ajută foarte mult însă, nu sunt
perfecte, ci au anumite deficien țe.
Astfel serverele web trebuie să trateze simultan un număr mare de cereri. Un server
popular pe Internet recep ționează câteodată sute sau chiar mii de cereri pe secundă, la care
trebuie să răspundă în timp util. Acest lucru poate duce la o supraîncărcare a serverelor, iar pe
lângă aceasta, un trafic intens pe re țea poate cauza blocaje.
Deoarece fiecare utilizator este costisitor pentru aplica ția web, când baza de
utilizatori cre ște, există un moment în care serverul de hostare nu mai poate să țină pasul cu
cererea. Atunci c ând un anumit serviciu web depă șește serverul său, din punct de vedere al
puterii de calcul, există două abordări principale care pot fi luate în considerare:
 Distribuirea solicitărilor pe mai multe servere
 Utilizarea unui server mai mare, mai puternic si bineîn țeles mult mai scump

În această lucrare voi detalia doar prima abordare, mai precis distribuirea solicitărilor
pe servere multiple utilizând software de tip sursă deschisă pentru balansarea traficului.
Acestea sunt deosebit de importante deoarece un ele dintre solu ții oferă un pre ț foarte bun
pentru raportul de performan ță comparativ cu a doua solu ție care presupune cumpărarea mult
mai scumpă de hardware.

Figura B : Balansarea traficului

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Noțiuni introductive

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 9
În figura anterioară, sarcina de încărcare este distribuită pe două servere web de către
un software de balansare a traficului care este hostat pe un alt server. Astfel toate cererile care
vin de pe internet sunt distribuite pe serverele din spatele său. Deoarece singura lui
intrebuin țare este de a distribui cereril e, acesta poate gestiona mai multe cereri decât poate
procesa serverul. Astfel, când baza de utilizatori va cre ște mai mult, se poate adăuga un nou
server la grupul existent de servere, cererile fiind acum distribuite pe trei servere, crescând
astfel capa citatea întregii aplica ții.

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Noțiuni introductive

Investigar ea și testarea metodelor de balansare a traficului pentru baze de date 10
Capitolul 1
Noțiuni introductive
1.1. Load balancers

Load balancers sunt metodologii hardware sau software dedicate pentru a distribui
volumul de muncă pe două sau mai multe calculatoare pentru a evita supraîncărcarea și
pentr u a mic șora timpul de răspuns.
[http://en.wikipedia.org/wiki/Load_balancer ]

Wikipedia define ște balansarea traficului ca fiind o tehnică de distribuire uniformă a
întregului volum de muncă pe două sau mai multe calculatoare, link -uri de re țea, procesoare ,
hard disk -uri, sau alte resurse în scopul de a ob ține utilizarea optimă a resurselor, de a
maximiza debitul, de a minimiza timpul de răspuns și pentru a evita supraîncărcarea.
Folosind componente multiple cu balansare a traficului, în loc de o singură
componentă, poate cre ște fiabilitatea prin redundan ță. Serviciul de balansare a traficului este
furnizat de obicei de către software sau hardware dedicate.
“Balansarea traficului este procesul prin care traficul IP poate fi distribuit pe mai
multe servere. Acest serviciu îmbunată țește performan țele serverelor, duce la utilizarea lor
optimă și asigură că nici un server singur nu este cople șit. Balansarea traficului reduce
timpul de răspuns prin faptul că permite mai multor servere să gestioneze cererile, ace stea
fiind repartizate server -ului/server -elor cu disponibilitatea corespunzătoare cea mai aproiat ă
de a primi traficul.“
[http://www.wisegeek.com/what -is-load-balancing.htm ]
Balansarea traficului este importantă în special pentru re țele acolo unde este dificil
de prezis numărul de cereri care vor fi emise de către un server. Site -urile web cu trafic foarte
mare de obicei folosesc două sau mai multe servere web într -un sistem de balansare a
traficului. Dacă unul dintre servere începe să se împotmolească, cererile vor fi transmise către

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și C alculatoare
Noțiuni introductive

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 11
un server cu capacitate mai mare. “Balansarea traficului se poate referi, de asemenea și la
canalele de comunica ție între ele. Balansarea traficului asigură distribuirea de prelucrare și
de comunica ții uniform pe o re țea de calculatoare astfel încât nici un dispozitiv nu va fi
cople șit.”
[http://www.webopedia.com/TERM/L/load_balancing.html ]
“Balansarea traficului este folosită pentru a spori capacitatea (de utilizatori
simultani) si fiabilitatea aplica țiilor web. Ei îmbunătă țesc performan ța generală a
aplica țiilor prin scăderea poverii serverelor asociată cu aplica ții de administrare și
între ținere și sesiuni de re țea, precum și prin efectuarea de sarcini specifice aplica ției.“
[http://www.f5.com/glossary/load -balancer.html ]
Ca formă generală, acest proces de balansare a traficului este foarte simplu. O cerere
de pagină web este trimisă către software -ul de balansare a traficului, care va transmite
cererea mai departe către serverul cel mai apropiat care are o disponibilitate corespunzătoare
de a primi cereri. Apoi acel server va răspunde înapoi soft -ului de balansare a traficului, care,
la rândul său, va trimite cererea până la utilizatorul final.
Există mai multe tipuri de metode de balansare a traficului. În cazul în care serverele
sunt similare în specifica ții hardware, metoda Perceptive (care prezice server -ul pe baza
datelor curente și arhivate) și metoda Fastest Response Time (cel mai rapid timp de răspuns)
sunt cele mai bune de utilizat. Pe de altă parte, în cazul în c are specifica țiile hardware sunt
diferite, metoda Wheighted Round Robin, care la rândul ei atribuie cererile către servere în
funcție de greutate, pote fi o solu ție mai bună deoarece poate atribui mai multe cereri către
server -ul care poate gestiona un vol um mai mare de cereri.
Putem spune cu alte cuvinte că alansarea traficului împarte cantitatea de muncă pe
care un calculator o are de facut, între două sau mai multe calculatoare, astfel în acela și
interval de timp se poate face un volum mai mare de muncă și, în general to ți utilizatorii
primesc mai repede un răspuns la solicitările făcute. Balansarea treficului poate fi
implementată prin intermediul hardware, software sau chiar ambele combinate. De obicei,
balansarea traficului este principala metodă pent ru gruparea calculatoarelor -server care apar
pentru utilizatori ca un singur sistem extrem de complet și disponibil.

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și C alculatoare
Noțiuni introductive

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 12
“Pe internet, companiile ale căror site -uri web ob țin o mare parte de trafic folosesc
de obicei metode de balansare a traficului. Datorită faptului că balansarea traficului
necesită servere multiple, aceasta este de obicei combinată cu servicii de erori si de backup.
În unele abordări, serverele sunt distribuite pe zone geografice diferite. ”
[http://searchcio -midmarket.techtarget.com/defini tion/load -balancing ]

1.2. Tema proiectului

Am ales pentru acest proiect să investighez metode software de balansare a traficului
pentru baze de date și să testez care sunt cele mai bune și prin care pot ob ține cele mai bune
performan țe. De altfel aș do ri să evidențiez și calitatea programelor de balansare a traficului
de a continua activitatea chiar și la apariția unor erori în cluste -ul de servere.
“Unul dintre elementele care contribuie la realizarea eficientă a programelor de
calitate este stilul de programare. Stilul de programare se poate caracteriza prin: aspectul
general al programului; claritatea și lizibilitatea programului; structurarea și modularizarea
programului în conformitate cu funcțiile și operațiile care se implementează ; robustețea
programului : calitatea sa de a continua și la apariția unor erori ; mentenabilitatea
programului: ușurința cu care poate fi modificat și îmbunătățit. ” [chc]
Astfel, prin utilizarea metodelor de balansare a traficului de către site -urile web cu un
trafic mare, utilizatorii dispun de un timp de răspuns foarte scăzut la cererile făcute către
acestea, beneficiază de o încarcare foare rapidă și ușoară, ceea ce prezintă un avantaj foarte
mare atat pentru utilizatori cât și pentru administratorii de aplica ții web. Pe de altă parte,
deținătorii aplica țiilor web scutesc o mare parte din bugetul alocat pentru achizi ționarea de
hardware de capacită ți mai mari și mai performante, și evită supraîncărcarea serverelor ceea
ce ar fi dus la o încarcare greoaie sau chiar blocaje pe re țea, lucru neplacut atât pentru
utilizatori cât și pentru administratori.
Există foarte multe firme care ofera servicii și solu ții hardware și software de
balansare a traficului, dintre care cele mai cunoscute fiind Kemp Technologies

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și C alculatoare
Noțiuni introductive

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 13
(http://www.ke mptechnologies.com), Loadbalancer (http://eu.loadbalancer.org), Optrics
Engineering (http://www.loadbalancersolutions.com), http://www.loadbalancers.com etc.
Din multitudinea de produse software pentru balansarea traficului care există la ora
actuală pe in ternet, pentru această lucrare am ales să testez HAProxy, Nginx, Crossroads
datorită diferen țelor dintre planificarea algoritmilor pe care le pot utiliza.
În continuare în capitolul doi am prezentat câteva no țiuni generale despre algoritmii
de planificare pentru balansarea traficului, am detaliat modul de functionare al uneltelor de
balansare a traficului, precum și modul de redirec ționare al cererilor/pachetelor.
Capitolul trei prezintă o scurtă descriere a modului în care am efectuat testele,
caracteristi cile serverelor pe care am rulat testele precum și alte specifica ții referitoare la
uneltele de balansare a traficului.
În capitolul următor am detaliat întregul proces de testare, unde am detaliat arhitectura
aplica țiilor și am descris func ționalitatea p rocesului de testare. Tot în acest capitol am
prezentat și câteva scheme care vor face posibilă o în țelegere mai u șoară a întregului proces.
Capitolul cinci va cuprinde rezultatele testelor făcute,
În capitolul șase voi prezenta problemele întâmpinate la realizarea acestui proiect
precum si modul lor de rezolvare și tot aici voi compara rezultatele ob ținute cu rezultatele
altor teste similare.
În ultimul capitol vor fi prezentate avantajele utilizării uneltelor de balansare a
traficului pentru baze de dat e.
În final vor fi prezentate câteva concluzii privind proiectul, utilizarea si testarea
uneltelor de balansare a traficului pentru baze de date.

1.3. Motiva ția

Mi s-a părut interesantă această temă deoarece în zilele noastre majoritatea oamenilor
stau zilnic pe internet, iar una dintre problemele cu care ne confruntăm de fiecare dată este

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și C alculatoare
Noțiuni introductive

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 14
încărcarea greoaie sau chiar blocarea unor aplica ții web în momentul în care interac ționăm cu
acestea.
Această problemă este datorată mai multor factori precum : supraîncărcarea serverelor,
trafic foarte mare, func ționalitate complexă a aplica țiilor web, administrare gre șită etc.
În această eră a vitezei tot mai mult se dore ște ca acesarea paginilor web, precum ș i
orice func ționalitate legată de aplica țiile web accesa te online, să se execute instant, viteza de
lucru fiind problema principală în jurul căreia se fac în permanen ță îmbună țiri pentru a atinge
performan țe cât mai mari. Acest proces de balansare a traficului u șurează foarte mult munca
și reduce stresul, fiin d totodată foarte util și dorit atâta timp cât implică costuri minime
comparativ cu alte solu ții similare.

1.4. Obiective

Prin prezenta lucrare doresc să eviden țiez avantajele balansării traficului pe serverele
aplica țiilor web, precum și să încurajez administratorii de aplica ții web în care traficul este
foarte mare să folosească metode de balansare a traficului.
Un obiectiv clar pe care prezenta lucrare vrea să -l traseze este faptul că prin
balansarea traficului se evită supraîncărcarea serverelor sau blocajele pe re țea și astfel se
minimizează timpul de răspuns la interac țiunea utilizatorilor cu aplica țiile web, unde
stabilitatea aplica țiilor si timpul în care acestea răspund cererilor reprezintă unele dintre cele
mai importante aspecte.
Multe dintre cele mai mari companii din lume se folosesc deja de acest avantaj al
balansării traficului prin diverse metode pe care acestea le suportă.
Prin prezentul proiect doresc să imi aduc aportul la răspândirea acestor metodologii de
distribuire uniformă a traf icului web prin testarea câtorva dintre acestea și prin scoaterea în
eviden ță a celor mai bune performan țe obținute.
De asemenea voi prezenta care este impactul performan ței și a disponibilită ții cauzate
de diferite tehnici folosite în uneltele de tip s ursă deschisă pentru balansarea traficului.

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și C alculatoare
Noțiuni introductive

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 15
Astfel că voi arăta care sunt tehnicile actuale de balansare a traficului folosite de
fiecare produs; care sunt avantajele si dezavantajele oferite de fiecare tehnică de balansare a
traficului ; cum sunt comparate soluțiile de balansare a traficului comparate în termeni de
performan ță cu alte scenarii.

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Fundamentare teoretică

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 16
Capitolul 2
Fundamentare teoretică
2.1. Func ționalitate

Wikipedia define ște Modelul de Referin ță OSI (OSI este un acronim
pentru interconectarea sistemelor deschi se, engleză Open Systems Interconnection ), ca o
structură de comunicare ierarhică foarte des folosită pentru a realiza o rețea de calculatoare.
OSI este un standard al Organiza ției interna ționale de standardizare, emis în 1984.
“Modelul de Referin ță OSI of eră metode generale pentru realizarea
comunica ției sistemelor de calcul pentru ca acestea să poată schimba informa ții, indiferent
de particularită țile constructive ale sistemelor (fabricant, sistem de operare, țară, etc).
Modelul de Referin ță are aplica ții în toate domeniile comunica țiilor de date, nu doar în cazul
rețelelor de calculatoare.
Modelul OSI divizează problema complexă a comunicării între două sau mai multe
sisteme în 7 straturi numite și niveluri ( layers ) distincte, într -o arhitectură ierarhică . Fiecare
strat (nivel) are func ții bine determinate și comunică doar cu straturile adiacente. Cele 7
niveluri ale Modelului de Referin ță se numesc: Aplica ție (nivelul 7, superior) , Prezentare,
Sesiune, Transport, Re țea, Legătură de date, Fizic (nivelul 1 , inferior). ”
[http://ro.wikipedia.org/wiki/Modelul_OSI ]

Conform modelului OSI, balansarea traficului poate func ționa pe mai multe nivel uri:
 Layer 2 – Data Link Layer
Nivelul 2, numit și nivelul Legături de date sau agragarea legăturilor, agragarea
porturilor etc ; are ca scop de a lega două sau mai multe link -uri într -o singură legătură logică
cu lă țime de bandă mai mare. Legăturile agregate furnizează de asemenea redundan ță și
toleran ță dacă fiecare dintre legăturile agregate urmează căi fizice diferite . Agragarea

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Fundamentare teoretică

Investigarea și testarea metodelor de balansare a traf icului pentru baze de date 17
legăturilor poate fi utilizată pentru a îmbunătă ți accesul la re țelele publi ce prin agregarea
legăturilor modem sau a liniilor digitale.
Nivelul Legatură de date se ocupă cu adresarea fizica, topologia re țelei, accesul la
rețea, detec ția și anunțarea erorilor și controlul fluxului fizic (flow control). Acesta furnizează
un transport sigur, fiabil, al datelor de -a lungul unei legături fizice, realizând:
– Controlul erorilor de comunica ție
– Controlul fluxului de date
– Controlul legăturii
– Sincronizare a la nivel de cadru
Exemplu : un pod de balansare a traficului care balansaeză încărcările pe legăturile
disponibile.
 Layer 4 – Transport Layer
Nivelul 4, numit și nivelul Transport are rolul de a distribui cererile către stratul de
transport al serverelor , ca și portocoale de transport TCP, UDP și SCTP. Balansarea traficului
distribuie conexiunile de re țea de la clien ții care știu o singură adresă IP pentru un serviciu,
către un set de servere care de fapt realizează munca. Atâta timp cât conexiunea trebui e să fie
stabilită între client și server în transportul orientat pe conxiune înainte de a trimite
conținutul cererii, balansarea traficului de obicei selectează un server fără a se uita la
conținutul cererii. Stratul 4 de balansare a încărcării poate fi, de asemenea, folosit pentru a
balansa traficul pe legături multiple de acces la internet, în scopul de a cre ște viteza de acces
la inter net. Nivelul 4 asigură transferul fiabil al informa ției între două sisteme terminale ( end
points ) ale unei comunica ții. Furnizează controlul erorilor și controlul fluxului de date între
două puncte terminale, asigurând ordinea corectă a pachetelor de date. Oferă un serviciu de
transport de date care izolează nivelurile superioare de orice specificita ții legate de modul în
care este executat transportul datelor.
Exemplu : Metode de balansare a încărcării care distribuie cererile către protocoalele
de transport TCP și UDP.
 Layer 7 – Application Layer
Nivelul 7, de asemenea numit și nivelul Aplica ție, are rolul de a analiza și distribui
cererile către servere pe baza diferitelor tipuri ale con ținutului cererilor, astfel încât să

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Fundamentare teoretică

Investigarea și testarea metodelor de balansare a traf icului pentru baze de date 18
poată asigura calitatea cerin țelor serviciilor ale clien ților pentru diferite tipuri de
conținut și pentru a îmbunătă ții performan ța generală întregul ui grup.
Astfel, nivelul 7 realizează interfa ța cu utilizatorul și interfa ța cu aplica țiile, specifică
interfa ța de lucru cu utilizatorul și gestionează comunica ția între aplica ții. Acest strat
nu reprezintă o aplica ție de sine stătătoare, ci doar interfa ța între aplica ții și
componentele sistemelui de calcul.
Exemplu: Echilibrarea încărcărilor care func ționează pe stratul 7 se face prin
distribuirea cererilor bazate pe con ținutul unui pachet, precum HTTP.

2.2. Algoritmi de planificare

Există câ țiva a lgoritmi de planificare pe care echilibrarea încărcării îi poate folosi
pentru a distribui încărcarea pe diferite servere. Mai departe am prezentat cî țiva dintre
algoritmii de planificare folosi ți.
Algoritmii utiliza ți pentru a selecta care server va prim i cereri:
 Least -Connection (lc):
Redirectează conec țiile către serverul care are cel mai mic număr de cone xiuni .
 Weighted Least -Connection (wlc):
Acest algoritm este acel ași cu Least -Connection , dar se po t atribui priorit ăți serverelor
 Round -Robin (rr):
Acesta este un algoritm care redirectează conec țiile către servere pe o bază circulară.
 Weighted Round -Robin (wrr):
Acest algoritm este același cu Round -Robin , dar se pot atribui priorită ți serverelor.
 Locality -Based Least -Connection (lblc):
Acest algoritm î ncearcă să redirec ționeze conec țiile la un anumit IP la acela și server.
 Locality -Based Least -Connection with Replication (lblcr):
Acest algoritm este același cu Locality -Based Least -Connection, dar are oportunitatea
de a redirecta către un fond comun.

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Fundamentare teoretică

Investigarea și testarea metodelor de balansare a traf icului pentru baze de date 19
 Destination -Hashing (dh)
 Source -Hashing (sh):
Acest algoritm este la fel ca Destination -Hashing, doar că acum salvează sursa
trunchiată IP într -un tabel.
 Shortest Expected Delay (sed):
Redirectează cone xiunile către serverul care va răspunde cel mai rapid cer erilor.
 Never Queue (nq):
Redirectează cone xiunile către un server inactiv. Dacă nu ex istă nici un server inactiv,
folose ște algoritmul ”Shortest Expected Delay”
.

2.3. Expedierea pachetelor

Există diverse feluri de expediere a pachetelor de la o sursă către un server. Acest
lucru este realizat după ce softul de echilibrare a încărcării decide către care server trebuie s ă
meargă conec ția. Astfel am aflat diferite feluri de expediere a pachetelor :
Direct Routing – În acest caz al rutării directe, pachetel e sunt neatinse și sunt trimise
către serverul corespunzător prin intermediul softului de echilibrare a încărcării. Aceasta
înseamnă că serverul designated trebuie să accepte pachete care nu sunt trimise către IP -ul
său. Solu ția pentru aceasta este crearea unei interfe țe sau a unui filtru de pachete, care să
redirec ționeze traficul către un port local. Softurile de echilibrare a încărcării și grupul de
servere trebuie să fie pe re țeaua fizică, aceasta datorându -se faptului că softul de echilibrare a
încărcă rii va retimite pachetul cu adresa MAC a serverului care va trebui să servească cererii.
IP-IP Encapsulation – Numit și Tunneling , este capabil de să redirec ționeze pachete
către servere din altă re țea. Diferen ța dintre Rutarea Directă, care poate redirec ționa pachete
în aceea și rețea, este că softul de încărcare a echilibirării nu schimbă adresa MAC, dar este
încapsulat într -un pachet IP. Dar ce înseamnă acest lucru mai exact?

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Fundamentare teoretică

Investigarea și testarea metodelor de balansare a traf icului pentru baze de date 20
Ceea ce face aceasta este defapt foarte simplu. Softul de echilibrare a încăr cării
plasează un header IP cu IP -ul serverului asignat , înaintea header -ului IP original. Deci
acesta nu schimbă nimic în header -ul IP original cu excep ția TTL.
Network Address Translation (NAT) – NAT defapt schimbă adresa de destina ție (și
portul) a pac hetului original, în adresa IP a serverului asignat care este de asemenea cunoscut
ca și header manipulation în conformitate cu RFC 1631, sau IP masquerading în conformitate
cu. Dezavantajul NAT este că traficul care merge înapoi la client, trebuie să trea că din nou
prin softul de echilibrare a încărcării ca să readucă schimbările NAT. Acest lucru înseamnă
că softul de echilibrare a încărcării trebuie să manevreze o încărcătură dublă de trafic.

Universitatea “Politehnica” din Timi șoara
Facultate a de Automatică și Calculatoare
Specificații tehnice

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 21
Capitolul 3
Specifica ții tehnice
3.1. Caracteristici ale test elor

În acest proiect voi cerceta diferite tehnici folosite pentru balansarea traficului și pe
baza aceasta voi alege diferite solu ții software pentru a le testa. Scopul lucrării este de a avea
o varietate cât mai mare de metode de balansare a traficului în solu țiile software pe care le
voi testa.
În contiunare voi stabili un set de scenarii pe baza cărora voi testa fiecare software:
– voi măsura laten ța introdusă de către fiecare software de balansare a traficului;
– voi măsura performan ța transferului fiecărui software de balansare a traficului;
– voi testa dacă perfoman ța este scalabilă liniar odată cu introducerea de noi servere;
– voi testa comportamentul balansării traficului cu privire la e șecul serverelor ;
– voi măsura performan ța balansării trafic ului atunci când unele dintre servere sunt
foarte încărcate din punct de vedere al traficului.
Pasul final va consta în setarea mediilor de balansare a traficului pentru fiecare
soluție, rularea testelor, colectarea și analizarea datelor.

3.2. Structura cluster -ului de servere

Mediul de testare pe care l -am proiectat pentru acest proiect este bazat pe VirtualBox.
Astfel, am creat câteva ma șini virtuale, cărora le -am atribuit rolurile corespunzătoare. Am
optat pentru VirtualBox deoarece cred că poate rel iza planificarea resurselor cu pierderi
minime de performan ță și totodată este o aplica ție cu sursă deschisă.

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Specificații tehnice

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 22
Pentru acest proiect am folosit:
– trei servere web
– un server cu rol de load balancer
– un calculator cu rol de client

Configurațiile server elor utilizate sunt următoarele:
1 load balancer:
Software:
Sistem de Operare Ubuntu Server 11.04 64 -bit (natty)
Kernel Linux 2.6.38 -8-server
HAProxy versiunea 1.3.15.2 -2
Nginx Nginx versiunea 0.6.32 -3
Crossroads Crossroads versiunea2.64. Aceasta a fost ultima versiune stabilă pe site -ul
oficial al crossroads
[http://crossroads.e -tunity.com/ ]
Hardware:
CPU 1 i3 CPU
Memory 512MB

3 servere web:
Software:
Sistem de Operare Ubuntu Server 11.04 64 -bit (natty)
Kernel Linux 2.6.38 -8-server
Web server Apache2 2 .2.9-10
Hardware:
CPU 1 i3 CPU
Memorie 512MB

Statie client:
Software:

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Specificații tehnice

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 23
Sistem de Operare Linux Mint 11 64 -bit (katya)
Kernel Linux 2.6.38 -8-generic
ApacheBench face parte din pachetul "apache2 -utils".
Am folosit apache2 -utils versiunea 2.2.11 -2ubuntu2.6
Hardware:
CPU i3 M350 @ 2.27GHz
Memorie 4GB (3.7GB folosită )

3.3. Stocarea informa țiilor

Pentru stocarea informaț iilor pe serverele web am folosit o bază de date relatională
mysql în care am creat două tabele cu ajutorul unui script php
“<?php
include("dbcon.php");
mysql_query("CREAT E TABLE tabel1 (ID MEDIUMINT NOT NULL
AUTO_INCREMENT PRIMARY KEY, numere int(30)) ") or die(mysql_error());
echo " Tabelul a fost creat !"
?>”
[cif]
respectiv ,
<?php
include("dbcon.php");
mysql_query("CREATE TABLE tabel 2 (ID MEDIUMINT NOT NULL
AUTO_INCREMEN T PRIMARY KEY, numere int(30)) ") or die(mysql_error());
echo " Tabelul a fost creat !"

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Specificații tehnice

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 24
?>
și în fiecare tabel am adăugat câteva înregistrări de tip int cu numere î ntregi. Astf el că
fiecare server din cele trei conține o bază de date cu două tabele și câteva înregistră ri.
Pentru a simula traficul pe servere a m programat un script php care ț ine locul unei
pagini web care face câ teva calcule matematice. Acestor calcule matematice le -am atribuit în
mod intenționat un număr mai mare de iteraț ii pen tru a avea un timp mai mare de încă rcare a
paginii pe server. Acest lucru mă ajută mai bine pentru a si mula activitatea pe un server web.
<?php

$mtime = microtime();
$mtime = explode(" ",$mtime);
$mtime = $mtime[1] + $mtime[0];
$starttime = $mtime;

function putere($numar,$putere){
$a=1;
for($i=0; $i<$putere; $i++){
$a=$b=$numar*$a;
}
return $a;
}

function adunare($numar,$repetari){
$a=0;
for($i=0; $i<$repetari; $i++){
$a=$b=$numar+$a;
}
return $a;
}

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Specificații tehnice

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 25
function operatie($nr){
$j= putere($nr,16);
$k = adunare($j,16)+$j*putere($nr,4);
$l = ($k*$j*putere($nr,5))*$k*putere($nr,10);
$f=$l/$k*$k;
return $f;

}
mysql_connect("localhost","root","test");
mysql_select_db("lbtests") or die("Nu poate selecta baza de date!");
$sql=mysql_query("SELECT * FROM numere") or die(mysql_error());

while($nr=mysql_fetch_row($sql)){
$str=34;
for ($i=1; $i<=$str; $i += 1){
$rez=operatie($str);
}
}
ob_start();
system(â €˜ifconfigâ €™);
$mycom=ob_get_contents();
ob_clean();

$findme = `HWaddr `;
$pmac = strpos($mycom, $findme);
$mac=substr($mycom,($pmac+36),17);

$mtime = microtime();
$mtime = explode( " ",$mtime);
$mtime = $mtime[1] + $mtime[0];

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Specificații tehnice

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 26
$endtime = $mtime;
$totaltime = ($endtime – $starttime);
echo "<br/>Pagina a fost generata in: ".substr($totaltime, 0, -8)." sec";
echo "<br/>Numar de interatii: ".$iteratii;
echo "<br/>Numar din tabel: ".$str;
echo "<br/>Scriptul ruleaza de pe: ".$box=php_uname('n');
echo "<br/>IP Server: ".$_SERVER['HTTP_HOST'];
echo "<br/>Adresa MAC: ".$mac;
echo "<br/><br/>";
?>

Figura 3.a. Rulare script pe server

Tot în acest script am folosit funcția microtime() la începutul și sfârș itul scriptului
pentru a putea afișa timpul în care se încarcă pagina.
Pagina am realizat -o cât mai simplu și să arate cateva infro mații cu privire la
operațiile efectuate de scriptul php. Am folosit o interfață simplă , nu prea încărcată cu culori
cât mai adecvate, care “de asemenea ajută la citirea mai ușoară a textelor și creează o
atmosferă de ansamblu aerisită și user -friendly ” [cls]

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Proiectarea de detaliu

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 27
Capitolul 4
Proiectarea de detaliu
4.1. Arhitectura aplica ției

Structura cluster -ului de servere cuprinde:
– trei servere web
– un server cu rol de load balancer
– un calculator cu rol de client
Pe fiecare server web din cele trei am instalat și configur at în linux server prin
intermediul unui terminal, î n linia de comanda Apach e, MySQL ș i PHP:
sudo apt -get install apache2
sudo apt -get install php5 libapache2 -mod-php5
sudo /etc/init.d/apache2 restart
sudo gedit /var/www/test.php
sudo apt -get install mysql -server
mysql -u root
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('test');
Pe calculatorul de tip cl ient am instalat ssh pentru a mă putea conecta la serverele web
și la serveru l de balansare a traficului fără a încă rca o interfa ță grafică pentr u a consuma cât
mai puț in din resursele serverelor web. Ssh a fost folosit d oar până am configurat î ntreaga
testare.
Exemplu de conectare prin ssh la serverele web:
sudo ssh server1@192.168.2.108
sudo ssh server2@192.168.2.109
sudo ssh server3@192.168.2.10 7
sudo ssh loadbalancer@192.168.2.106

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Proiectarea de detaliu

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 28
În final s erverele vor fi configurate după următoarea structură :
3 servere web
 lamp (Linux Apache MySQL PHP)
 script pagină web
 bază de date
1 server de balansare a traficului
 crossroads
 haproxy
 nginx
1 claculator cli ent
 ApacheBench

Figura 4.a. Arhitectura cluster -ului de servere

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Proiectarea de detaliu

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 29
Am ales s ă testez metoda Round -Robin de oarece aceasta poate fi folosită de că tre
toate soft -urile de balansare a traficului.
Soft-urile de echilibrare a încărcării au fost alese în a șa fel încât să fie diferen țe între
planificarea algoritmilor pe care le folosesc sau la pot folosi acestea:
HAProxy – este o abreviere pentru High -Availability Proxy. Este un event driven , un
program cu un singur proces care poate echilibra încărcarea unui numă r foarte mare de
conexiuni simultane pe nivelul 4 și 7. Aceasta înseamnă că poate fi configurat să func ționeze
pe TCP sau pe HTTP. Câteva dintre caracteristici sunt verificarea diponibilit ății grupului de
servere și persisten ța sesiunii. Se spune că poate echilibra încărcările pe 10Gbit, și că
HAProxy niciodată nu s -a defectat într -un mediu de produc ție.
Algoritmii de planificare pe care acest program îi poate folosi sunt:
 Round -Robin
 Least -Connection
 Source -Hashing
 Destination -Hashing

NginX (engine x) – este un program de echilibrare a încărcării de nivelul 7, care poate
echilibra încărcarea HTTP și mail. Este scris ca un program cu mai mu lte procese, un proces
de bază ș i mai mult e procese ajutătoare. Una dintre caracteristicile Nginx este că poate fi
configurat fără a întrerupe clien ții. Pentru mai multe caracteristici se pot folosi module și
addon -uri.
Cei de la Nginx au început să scrie aplica ția în jurul anului 2003 și până la sfâr șitul
anului 2007 aceasta a fost vizibilă în Netcraft.
Nginx nu suport ă mul ți algoritmi de planificare:
 Round -Robin
 Weighted Round -Robin

Crossroads – este cel mai putin cunoscut program de echilibrare a încărcărilor pe care
l-am testat. Este un program cu un singur proces, multi threaded . Acesta poate echilibra

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Proiectarea de detaliu

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 30
încărcările pe nivelul 4 și 7, deci poate precum HAProxy echilibra pe TCP dar și pe HTTP.
Cu HTTP acesta poate persista o sesiune prin intermediul injectării de cookie -uri.
Crossroads suportă următorii algoritmi de planificare:
 Round -Robin
 Least -Connection
 First Av ailable
 Source -Hashing
 Destination -Hashing

4.2. Descrierea func ționalită ții

Func ționarea î ntregului proces de balansare a traficului este destul de simplă . Clientul
care intră pe internet accesează o pagină web. Cand prea multa lume accesează aceeași
pagină se fac prea multe cereri către server. Acesta necesită tot mai mult timp pentr u a
rezolva cererile și astfel apare fenomenul de încă rcare greoaie a paginii web sau chiar
blocarea paginii. Pentru a evita acest lucru, dupa structura din figura 4. a din s ubcapitolul
anterior se introduce un server ce are instalat un program de balansa re a traficului. Astfel
acum când clientul intră pe o pagină web, cererea facută către serverul web este direcționată
de că tre programul de balansare a traficului pe primul se rver. Când un alt client intră pe
aceeaș i pagina web programul de balansare a tra ficului nu mai redirecționează cererea către
același server, ci către al doilea server și asa mai departe, până câ nd se ajunge la ultimul
server din cluster -ul de servere pe c are structura il deț ine. Câ nd se ajunge la ultimul server,
cererile vor fi redire cționate din nou către primul server și astfel ciclul se repetă. Astfel se
evită o supra aglomerare a unui server și se evită blocajele pe rețea precum ș i o accesare
greoaie a unei pagini web. Această metodă de distribuire a cererilor către servere î ntr-o
anumită ordine dată de către cel care configurează programul de balansare a traficului se
numeste Round -Robin.

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Realizarea testelor

Investigarea și testarea meto delor de balansare a traficului pentru baze de date 31
Capitolul 5
Realizarea testelor
5.1. Descrierea procesului de realizare a testelor

Folosind unealta ab(ApacheBench ) am realizat următoarele teste:
– Laten ța introdusă de către fiecare load balancer
– Performan ța transferului pentru fiecare load balancer
– Cereri rezolvate pe secundă pentru fiecare load balancer
– Tiparul de scalare atunci când se introduc noi servere
– Măsurarea performan ței a balansării traficului atunci când unele dintre
servere sunt foarte încărcate din punct de vedere al traficului
– Comportamentul balansării traficului cu privire la e șecul/oprirea unui
server
Testele pe care le -am făcut pentru a măsura laten ța, lărgimea de bandă ș i
cererile/secundă au fost repetate de 100 de ori iar rata acestor teste este repreyentată în
subcapitolele următoare.

5.2. Laten ța introdusă

În primul set de teste am măsurat l atența introdusă de programele de echilibrare a
încărcării și am comparat -o cu timpul pe care îl necesită serverul web să răspundă unei cereri
fără nici un program de echilibrare a încărcării. Pe scurt, am măsurat latența cand un client se
conectează direc t iar apoi, pe rând, când se introduce câte un program de balansare a
traficului. Prin latență am calculat de fapt durata de când un client trimite o cerere către
server și până când acesta primește un răspuns.

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Realizarea testelor

Investigarea și testarea meto delor de balansare a traficului pentru baze de date 32
Dure ază aproximativ 0 .3ms pentru a se executa scriptul paginii web și a rezolva
cererea în testul conectării directe făfă nici un program de balansare a traficului.
După ce am introdus programele de balansare a traficului și am efectuat testele am
constatat că c ea mai mare laten ță este de 2.5 ms și a fost introdusă de Crossroads, dupa care
urmează Nginx cu o laten ță de 1.1 ms. Cea mai bună laten ță am ob ținut-o cu HAProxy și
anume de 0.6 ms. Poate aceste numere par a fi foarte mici, dar când un program de
echilibrare a încărcării se confruntă cu câte va mii de cereri pe r secundă, aceste întârzieri se
pot aduna și pot face o diferen ță semnificativă în performan ța de ansamblu.
Ambele programe Crossroads și Nginx au o performan ță destul de bună în această
categorie, dar HAProxy a dat cele mai bune rezult ate. Întârzierea are o influență mai mare
asupra performanței generale atunci câ nd există mai multe c ereri mici care sunt rezolvate
într-o cantitate relativ mică de timp comparativ cu cazul în care cererile necesită o perioadă
mai lungă de timp pentru a fi rezolvate de că tre serverul web.

Figura 5.a. Lantența introdusă

Scriptul utilizat pentru măsurarea latenț ei:
#!/bin/bash
#Pentru rularea apachebench .

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Realizarea testelor

Investigarea și testarea meto delor de balansare a traficului pentru baze de date 33
tests=$1
#Contor
i=0
#Crearea unui fișier nou și gol pentru a stoca temporar rezultatele
echo "" > r ezultate .tpr
while [ $i -lt $tests ];
do
#Golirea variabilei timp per cerere
tpr=""
#Trimiterea ratei de transfer de la ieșirea apachebench către fișier
tpr=‘ab -n $3 -c $4 -d -S http://$2/ind ex.html | grep " Timp per cerere :" | \
grep "(mean, across all c oncurrent requests)" | awk -F: ’{print $2}’ | \
awk ’{print $1}’‘
echo $tpr >> rezultate .tpr
#Pentru debug ging, arată rata de transfer a testului
echo " Timp per cerere test $i: $tpr"
#Contor + 1
let i=i+1
done
#Șterge spațiile libere din fișier
cat rez ultate.tpr | sed ’s/[ \t]*$//’ | sed ’/^$/d’ > rezultate 2.tpr
#Creează o linie pentru a calcula cu bc
exec 3<&0

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Realizarea testelor

Investigarea și testarea meto delor de balansare a traficului pentru baze de date 34
exec 0< rez ultate2.tpr
while read line
do
total=${total}+${line}
done
#Șterge caracterul “+” de la începutul liniei și calcule ază cu trei decimale î nainte de
#punct
all=‘echo "$total" | sed -e ’s/^[+]*//’ | bc‘
avarage=‘echo "scale=3;(${all}) / $1" | bc‘
#Salvează datele în fișier
echo "##############################" >> latency
echo "‘date‘" >> latency
echo "##############################" >> latency
echo "Server: $2" >> latency
echo "Teste : $1" >> latency
echo "Total cereri per test: $3" >> latency
echo " Cereri per secu ndă: $4" >> latency
echo " Rata este de $avarage ms" >> latency
echo ""
echo " Rata este de $avarage ms"
[cij]

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Realizarea testelor

Investigarea și testarea meto delor de balansare a traficului pentru baze de date 35
5.3. Capacitatea de tra nsmisie

Prin urmatorul set de te ste pe care le -am realizat , am măsurat lărgimea de bandă pe
care o are fiecare program de balansare a traficului cu câte unu, două ș i trei servere web. Mai
exact, am măsurat viteza cu care distribuie programul de balansare a traficului cererile către
unu, două sau trei servere; și timpul în care acesta primește un răspuns înapoi . Perfo rmanța ar
putea părea mică pentru toate programele de balansare a traficului, da r motivul pentru aceasta
este ră spunsul http de dimensiuni mic i care es te generat de serverele web. Deș i scriptul p hp
pe care l -am realizat durează ceva timp până se execută , acesta returnează doar câ teva string –
uri precum ș i timpul pe care l -a necesitat server -ul să genereze pagina.

Figura 5.b. Lărgimea de bandă

• Nginx – 1 server: 32.2 KB/s, 2 servere : 31.2 KB/s, 3 servere 53 KB/s
• HAProx y – 1 server: 38 KB/s, 2 servere: 49.8 KB/s, 3 servere : 59.9 KB/s
• Crossroad s – 1 server: 6.2 KB/s, 2 severe: 3.7 KB/s, 3 servere : 12 KB/s

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Realizarea testelor

Investigarea și testarea meto delor de balansare a traficului pentru baze de date 36
Din nou HAProxy a dat cele mai bun e rezultate, l ățimea de bandă rezultată fiind de
aproximativ 60KB/s. Nginx are de asemenea o performa nță destul de bună când foloseș te trei
servere, dar cea mai slabă performan ță am obț inut-o cu Crossroads pe toate trei teste în care
folosind două servere a scos doar 3.7KB/s.

Scriptul utilizat pentru a mă sura rata de transfer:
#!/bin/bash
#Pentru rularea apachebench
tests=$1
#Contor
i=0
#Crează un fișier nou și gol pentru a stoca temporar rezultatele
echo "" > re zultate .tfr
#While the counter is less than the amount of
while [ $i -lt $tests ];
do
#Golește variabila ratei de transfer
tfr=""
#Trimiterea ratei de transfer de la iesirea/rezultatul ab
tfr=‘ab -n $3 -c $4 -d -S http://$2 |
awk -F: ’{print $2}’ | awk ’{print $1}’‘
echo $tfr >> rezultate .tfr
#Pentru debugging arată rata de transfer a testului
echo " Rata de transfer test $i: $tfr"

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Realizarea testelor

Investigarea și testarea meto delor de balansare a traficului pentru baze de date 37
#Contor + 1
let i=i+1
done
grep " Rata de transfer " | \
test
#Șterge spațiile libere din fișier
cat rezultate .tfr | sed ’s/[ \t]*$//’ | sed ’/^$/d’ > rezultate 2.tfr
#Creaz ă o linie pentru a calcula cu bc
exec 3<&0
exec 0< rezultate 2.tfr
while read line
do
total=${total}+${line}
done
#Remove the "+" character at the beginning of the line and calculate with
#three decimals behind the dot.
#Șterge caracterul “+” de la începutu l liniei și calculează cu trei decimale înainte de
#punct.
all=‘echo "$total" | sed -e ’s/^[+]*//’ | bc‘
avarage=‘echo "scale=3;(${all}) / $1" | bc‘
#Salvează datele în fișier
echo "##############################" >> transfer_rate
echo "‘date‘" >> transfer _rate

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Realizarea testelor

Investigarea și testarea meto delor de balansare a traficului pentru baze de date 38
echo "##############################" >> transfer_rate
echo "Server: $2" >> transfer_rate
echo "Test e: $1" >> transfer_rate
echo "Total cereri per test: $3" >> transfer_rate
echo " Cereri per sec undă: $4" >> transfer_rate
echo " Rata este de $avarage K B/s" >> transfer_rate
echo ""
#Afișează pentru debugging
echo " Rata este $avarage KB/s"

5.4. Solicit ări/cereri pe r secund ă

Prin intermediul celui de -al treil ea set de teste pe care le -am făcut, am mă surat
numarul de cereri /solicitări per secundă care po t fi transmise când sunt folosite pe rând unul,
două ș i trei servere web și câte cereri poate să returneze . De obicei acest test este cel mai
reprezentativ pentru programele de balansare a traficului deoa rece se poate observa
performanța funcționalității d e bază a acestora, schimb ând un număr cât mai mare de
cereri/solicitări făcute că tre server.
De data aceasta cea mai bună performanță am obț inuit-o cu Nginx cu 263 de solicitări
per secundă având în spatele să u tre i servere web. Cu HAProxy am obținut o pe rformanță
medie, ș i anume de 245 de cereri per secund ă pe toate trei configurații de servere. Atât Nginx
cât și HAProxy distribuie un număr similar de cereri când folosesc unul sau două servere.

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Realizarea testelor

Investigarea și testarea meto delor de balansare a traficului pentru baze de date 39

Figura 5.c. Solicitări/ cereri per secundă

Performanța de bază pe care am obț inut-o când m -am conectat direct la un server fără
a folosi un program de balansare a traficu lui a fost de 160 cereri/secundă .

• Nginx – 1 server: 171.6 req/s, 2 servers: 174.6 req/s, 3 serverss: 263.1req/s
• HAProxy – 1 server: 142.7 req/s, 2 servers: 154 req/s, 3 servers 245 req/s
• Crossroads – 1 server: 121.9 req/s, 2 severs: 191.4 req/s, 3 servers: 205.8 req/s

Scriptul utilizat pentru a testa cererile pe r secundă :
#!/bin/bash
#Pentru rularea apachebench
tests=$1
#Contor
i=0
#Crea ză un fișier nou și gol pentru a stoca temporar rezultatele
echo "" > re zultate .reqps

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Realizarea testelor

Investigarea și testarea meto delor de balansare a traficului pentru baze de date 40
#Când contorul este mai mic decât suma testelor, se execută ab
while [ $i -lt $tests ];
do
#Golirea variabilei de cereri per secundă
reqps=""
#Trimiterea cererilor per se cundă de la ieșirea ab către fișier
reqps=‘ab -n $3 -c $4 -d -S http://$2 | grep " Cereri per sec undă" | \
awk -F: ’{print $2}’ | awk ’{print $1}’‘
echo $reqps >> rezultate .reqps
#Pentru debugging, arată cererile per secundă pentru testul care tocmai a rula t
echo " Cereri per sec undă test $i: $reqps"
#Contor +1
let i=i+1
done
#Șterge spațiile albe din fișier pentru a putea calcula rata direct din fișier
cat re zultate .reqps | sed ’s/[ \t]*$//’ | sed ’/^$/d’ > re zultate 2.reqps
#Crează o linie pentru a rula bc p e ea
exec 3<&0
exec 0< re zultate 2.reqps
while read line
do
total=${total}+${line}
done

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Realizarea testelor

Investigarea și testarea meto delor de balansare a traficului pentru baze de date 41
#Șterge caracterul “+” de la începutul liniei și calculează cu trei decimale înainte de
#punct.
all=‘echo "$total" | sed -e ’s/^[+]*//’ | bc‘
avarage=‘echo "scale=3;(${a ll}) / $1" | bc‘
#Salvează datele în fișier
echo "##############################" >> requests_per_seconds
echo "‘date‘" >> requests_per_seconds
echo "##############################" >> requests_per_seconds
echo "Server: $2" >> requests_per_seconds
echo "T este: $1" >> requests_per_seconds
echo "Total cereri per test: $3" >> requests_per_seconds
echo " Cereri per sec undă: $4" >> requests_per_seconds
echo " Rata este de $avarage" >> requests_per_seconds
echo ""
#Afișare pentru debugging
echo " Rata este $avarage "

5.5. Scalarea

Înainte de a î ncepe t estele m -am așteptat ca performanța să scaleze linear de fiecare
dată când am adăugat un alt server web în timpul testelor. Din păcate nu a fost așa, și mai
mult decât atâ t, tiparele de scalare sunt destul de inconsi stente pentru toate programele de
balansare a traficului. Singuru l rezultat acceptabil a fost obținut cu HAProxy în timpul testării

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Realizarea testelor

Investigarea și testarea meto delor de balansare a traficului pentru baze de date 42
lărgimii de bandă, unde performanța a scalat î ntr-un mod constant de fiecare dată câ nd am
adăugat un server web. Nginx și C rossroads au avut îmbunătăț iri de performan ță doar atunci
când au trebuit să distribuie traficul pe toate cele trei servere.

5.6. Performanța la supraîncă rcare

În acest test am dorit să văd dacă performanța este influențată de utilizarea mai multor
tipuri diferite de algoritmi de balansare a traficului. Am testat acest lucru folosind HAProxy
pe toate cele trei servere web ș i doi algoritmi de balansare a traficului:
 round -robin – unde distribuirea se face î n mod egal
 least-connection – unde d istribuirea se face pe baza numă rului conexiuni deschise pe
fiecare server din spatele serverului de balansare a traficului
Pentru a realiza acest test, am simulat o supraî ncarcare pe unul dintre cele trei servere web.
Astfel că pentru f iecare algoritm am testat o dat ă când serverul nu este încărcat și o dată când
serverul era supus supraîncărcă rii. Dup ă cum era de a șteptat ambii algoritmi au avut acela și
nivel de performan ță(280 cereri/sec) c ând nici un server nu era supra încărcat. Situa ția însă s-a
schimbat c ând unul dintre servere a fost supus unei încărcări, moment în care algoritmul
least-connection a dep ășit algoritmul round -robin cu aproximativ 25 cereri/sec. Motivul
principal care st ă la baza acestei difere țe de performanță , const ă în faptul c ă în timpul test ării
algoritmului round -robin , o treime dintre cereri au durat mai mult p ână să fie rezolvate, în
timp cu testarea least -connection, acea treime a fost redistribuită către celelalte două servere
care au rez olvat cererile mult mai rapid.
Deși util în unele s ituații, algoritmul least -connection nu este bun în fiecare caz. În
cazurile în care timpul pe care îl necesită pentru a rezolva o cerere variază foarte mult, poate
inrăutăți performanța deoarece serverele care au cereri intensive pentru CPU de rezolvat
durează mai mult chiar dacă acestea nu sunt foarte multe.

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Realizarea testelor

Investigarea și testarea meto delor de balansare a traficului pentru baze de date 43

Figura 5.d. Performanța la supraîncărcare

5.7. Protec ția împotriva defec țiunilor

Un aspect foarte important al programelor de balansare a traficului este
comportamentul acestora c ând un server p e care îl au în spatele lor nu r ăspunde cererilor sau
nu mai func ționeaz ă deloc. C ând un server din cluster -ul de servere întârzie s ă răspund ă sau
refuz ă conexiunile întru totul, programul de balansare a traficului are datoria de a scoate
serverul respecti v din cluster -ul de servere pentru c ă altfel , toate conexiunile ce vor merge
înspre server -ul respectiv nu vor mai func ționa, sc ăzând foarte mult performan ța general ă a
întregului sistem.
Toate trei solu ții de balansare a traficului pe care le -am testat d etecteaz ă dacă un
server din grupul de servere nu mai accept ă conexiuni deloc și redirecteaz ă tot traficul c ătre
celelalte servere. În practic ă de cele mai multe ori serverele nu mai vor s ă răspund ă la cereri
deloc sau r ăspund dar dup ă foarte mult timp. În aceste cazuri conexiunile se întrerup în timp
ce utilizatorii sau programul de balansare a traficului a șteapt ă după un răspuns. Pentru a
îndeparta acest tip de probleme, programele de balansare a traficului trebuie s ă verifice

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Realizarea testelor

Investigarea și testarea meto delor de balansare a traficului pentru baze de date 44
disponibilitatea tuturor ser verelor din cluster -ul de servere și să exclud ă pe acelea care nu mai
răspund într-un anumit interval de timp.
 Nginx – nu dispune de verificare a disponibilității serverelor
 HAProxy – dispune de verificare a disponibilității serverelor
 Crossroads – dispun e de verificare a disponibilității serverelor

HAProxy și Crossroads pot s ă monitorizeze pe servere un URL specific, iar dac ă acel
URL returneaz ă un string specific într-un anumit interval de timp, atunci înseamn ă că
serverul este disponibil și poate r ămâne în continuare în cluster -ul de servere. Dac ă server -ul
nu răspunde în acel interval de timp atunci acesta va fi scos din grupul de servere. Numai
Nginx nu ofer ă nici un mecanism de verificare a disponibilit ății, ci acesta trebuie implementat
pe supliment ar.

5.8. Persisten ța sesiunii

Un alt aspect important al programelor de balansare a traficului este persisten ța
sesiunii. Sunt situa ții când un utilizator trebuie s ă păstreze o sesiune pe durata c ât acesta
utilizeaz ă o aplicat țe web. Astfel, din cauza felului în care programele de balansare a
traficului func ționeaz ă, unele cereri venite din partea utilizatorului pot fi distribuite pe alte
servere din cluster -ul de servere. În mod evident este faptul c ă acesta va pierde și sesiunea
deschis ă pe serverul a nterior odat ă cu schimbarea noului server, cu excep ția cazului în care
sunt luate unele m ăsuri suplimentare pentru a p ăstra oarecum sesiunea respectiv ă.
Așadar pot ap ărea aici dou ă abord ări:
 sincronizarea sesiunii între serverele web
 trimiterea cererilor de la acela și utilizator c ătre acela și server
Opțiunea a doua am luat -o în considerare pentru c ă aceasta poate fi realizat ă prin
intermediul programelor de balansare a traficului. Prin diverse tehnici programele de
balansare a traficului pot ob ține sursa i p, un parametru URL, cookie -uri.

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Realizarea testelor

Investigarea și testarea meto delor de balansare a traficului pentru baze de date 45
IP source – un hash este calculat din sursa IP și stocat în memorie. Astfe c ând se face
o cerere de pe aceea și adres ă IP, hash -ul va fi recalculat și comparat cu cel stocat în memorie.
Dacă acestea corespund, atunci cerere a va fi trimis ă către acela și server. Aceasta solu ție însă
poate cauza și probleme în cazul în care un utilizator i și schimb ă adresa IP ( întreruperea
conexiunii).
URL parameter – programul de balansare a traficului pune id -ul unui utilizator în
parametrii url și îl scoate afar ă atunci c ând trimite cererea c ătre un server din spatele s ău.
Cookies – programul de balansare a traficului pune un cookie în raspunsul HTTP pe
care îl trimite clientului. C ând cererea ajunge înapoi atunci cookie -ul este scos afar ă iar
cererea se trimite mai departe c ătre server. Problema cu aceast ă solutie este c ă nu toate
browserele web acept ă cookie -uri.
Nginx este capabil de a monitoriza sesiunile utiliz ând sursa ip, iar Crossroads folosind
cookie -uri. Dintre toate toate cele tre i programe de balansare a traficului pe care le -am testat
doar HAProxy poate utiliza toate cele trei metode.

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Utilizarea aplicației

Investigarea și testarea meto delor de balansare a traficului pentru baze de date 46
Capitolul 6
Utilizarea aplica ției
6.1. Probleme întâmpinate la realizarea testelor

În cadrul realiză rii testelor, am avut ne placuta placere de a constata că nu toate
programele d e balansare a traficului suportă aceleaș i metode de distribuire a ce rerilor către
servere. O singură metodă este comună pentru toate programele, ș i anume Ro und-Robin.
Astfel că am decis să realizez testele doar cu această metodă. Desigur că sunt mai multe
metode de distribuire precum: Least -Connection, Locality -Based Least -Connecti on,
Destination -Hashing, etc.; însă nu toate sunt suportate de că tre programele de balansare a
traficului. Datorită acestui lucru nu se poat e fac e o testare a programelor î n paralel deoarece
nu este posibilă o comparație î ntre acestea.

6.2. Compara ția testelor cu alte teste similare

În urma unei investigări pe internet am constatat că sunt ș i alte rezultate similare cu
cele obținute de mine, da r au fost și multe diferite. Diferența poate fi datorată și faptului că
testele fă cute de mine au fost r ealizate pe mașini virtuale și nu pe calculatoare obiș nuite cum
ar fi normal. Desigur că cel mai bine este ca testele să ruleze pe servere web și nu pe mașini
virtuale, dar eu am ales să fac aceste teste pe maș ini virtuale din cauza costurilor mult mai
reduse și a faptului că nu am dispus de servere dedic ate. Astfel prin testarea pe mașini
virtuale nu se pot obține performanțe așa de mari ca și câ nd test ele ar fi fost realizate pe
servere web dedicate.

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Ca lculatoare
Avantaje

Investigarea și testarea metodelor de balansare a traficului pentru baze de date 47
Capitolul 7

Avantaje ale utilizării acestor sisteme

Avantajele utilizării metodelor de balansare a traficului de către aplicatiile web cu un
trafic mare sunt atât de partea utilizatorilor cât și de partea administratorilor sau deț inătorilor
de pagini web.
Aceste avantaje constau în:
 timp de răspuns foarte scăzut la cererile făcute către paginile web
 încarcare foare rapidă și ușoară, ceea ce prezintă un avantaj foarte mare atat pentru
utilizatori cât și pentru administratorii de aplica ții web
 costuri de întreținere scăzute ( deținători i de aplica ții web scutesc astfel o mare parte
din bugetul alocat pentru achizi ționarea de hardware de capacită ți mai mari și mai
performante )
 evitarea supraîncărcării serverelor ceea ce duce la o încarcare greoaie sau chiar
blocaje pe re țea, lucru neplacut atât pentru utilizatori cât și pentru administratori.
 programele de balansare a trafi cului sunt de tip sursa deschisă și oferă o soluț ie mult
mai eficientă ș i din punct ul de vedere al costurilor mult mai reduse comparativ cu
achiziț ioanrea de hardware mai performant.

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Concluzii

Investigarea și testarea m etodelor de balansare a traficului pentru baze de date 48
Concluzii

Din moment ce publicarea de informații pe Internet a devenit ușoară, populară și
ieftină, utilizarea în mod efectiv a informațiilor accesibile a devenit tot mai greoaie. Astfel,
sistemele de informații actuale – serverele Web – se confruntă cu o supraîncărcare și avem de –
a face cu încărcări greoaie, întreruperi și chiar blocaje pe rețea, din cauza numărului tot mai
mare de utilizatori care încear că să acceseze informații disponibile pe Internet. O modalitate
pentru a îndepărta acest inconvenient este utilizarea programel or de balansare a traficului .

Prin utilizarea metodelor de balansare a traficului de către aplicatiile web cu un trafic
mare, ut ilizatorii dispun de:
 timp de răspuns foarte scăzut la cererile făcute către paginile web
 încarcare foare rapidă și ușoară, ceea ce prezintă un avantaj foarte mare atat pentru
utilizatori cât și pentru administratorii de aplica ții web.
Pe de altă parte, de ținătorii aplica țiilor web scutesc o mare parte din bugetul alocat pentru
achizi ționarea de hardware de capacită ți mai mari și mai performante, și evită supraîncărcarea
serverelor ceea ce ar fi dus la o încarcare greoaie sau chiar blocaje pe re țea, lucru n eplacut
atât pentru utilizatori cât și pentru administratori.
În urma testării programelor Nginx, HAProxy ș i Crossroads, de balansare a tra ficului
am ajuns la concluzia că HAProxy are o performanță foarte bună per general și pe langă acest
lucru mai ofer ă și o gamă foarte mare și bună de opțiuni pentru configurare. Opț iunile precum
TCP connecti on splicing face ca programul să fie o soluție foarte bună chiar și în medii cu
încărcă ri foarte mari de trafic. De perfomanț e similare se aprop ie și Nginx.

Să spe răm că aceste unelte se vor perfec ționa tot mai mult și le vom putea utiliza,
astfel încât să găsim informa țiile pe care le căutăm, cu un efort minim și într -un timp cât mai
scurt dispunând de aplica ții cu performan țe foarte mari.

Universitatea “Politehnica” din Timi șoara
Facultatea de Automatică și Calculatoare
Bibliografie

Investigarea și testarea metodelor de balansare a traficului pentru baze de d ate 49
Bibliografie
Internet
 http://en.wikipedia.org/wiki/Load_balancer
 http://www.byte.ro/byte97 -08/caut.htm
 http://www.webopedia.com/TERM/L/load_balancing.html
 http://www.wisegeek.com/what -is-load-balancing.htm
 http://www.f5.com/glossary/load -balancer.html
 http://searchcio -midmarket. techtarget.com/definition/load -balancing
 http://en.wikipedia.org/wiki/OSI_model
 [http://crossroads.e -tunity.com/ ]

Cărți
 [phpbr] – PHP 5 Power Programming
Bruce Perens’ Open Source Series
 [hpmysql] – High Performance MySQL
Jeremy Zawodny, Derek J. Ba lling

Cursuri și Laboratoare
 [chc] – Tehnici de programare
Prof.Dr. Ing. Horia Cioc ârlie
 [cif] – Programare Web
Prof.Dr.Ing. Ioan Filip
 [cij] – Sisteme de Operare
Prof.Dr.Ing. Ioan Jurc ă
 [cls] – Proiectarea interfe țelor utilizator
Prof.Dr.Ing. L ăcrăm ioara Stoicu -Tivadar