Universitatea Tehnică „Gheorghe Asachi” din Iaşi Facultatea de Automatică şi Calculatoare
2011
Contribuţii la proiectarea aplicaţiilor paralele
pe clustere de calculatoare
ing. Cristian Mihai Amarandei
- REZUMATUL TEZEI DE DOCTORAT -
Conducător ştiinţific:
prof. dr. ing. Vasile-Ion Manta
Cuprins
Cuprins i
1 Introducere 1
1.1 Motivatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Structura tezei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Diseminarea rezultatelor . . . . . . . . . . . . . . . . . . . . . . . . 5
Partea I: PROIECTAREA APLICATIILOR PARALELE 7
2 Metodologii de proiectare a aplicatiilor paralele 9
2.1 Introducere ın proiectarea aplicatiilor paralele . . . . . . . . . . . . 10
2.1.1 Definirea problemei . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Modelarea aplicatiilor paralele . . . . . . . . . . . . . . . . 11
2.2 Modele de proiectare a aplicatiilor paralele . . . . . . . . . . . . . . 14
2.3 Analiza cantitativa si calitativa a algoritmilor paraleli . . . . . . . 16
2.3.1 Parametrii cantitativi . . . . . . . . . . . . . . . . . . . . . 16
2.3.1.1 Accelerarea . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1.2 Eficienta . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.1.3 Supraıncarcarea . . . . . . . . . . . . . . . . . . . 17
2.3.1.4 Costul . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Parametrii calitativi . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2.1 Granularitatea . . . . . . . . . . . . . . . . . . . . 18
2.3.2.2 Scalabilitatea . . . . . . . . . . . . . . . . . . . . . 19
2.4 Problema echilibrarii ıncarcarii ın proiectarea aplicatiilor paralele . 19
2.4.1 Echilibrarea ıncarcarii ın aplicatiile paralele . . . . . . . . . 19
2.4.2 Echilibrarea dinamica a ıncarcarii . . . . . . . . . . . . . . . 20
2.4.2.1 Echilibrarea centralizata . . . . . . . . . . . . . . 21
2.4.2.2 Echilibrarea descentralizata . . . . . . . . . . . . . 21
2.4.3 Echilibrarea dinamica a ıncarcarii ın sistemele de agenti
mobili si sisteme message passing . . . . . . . . . . . . . . . 23
i
ii CUPRINS
2.4.4 Rezultate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3 Model de proiectare a aplicatiilor paralele folosind proiectarea statis-
tica a experimentelor 29
3.1 Modelul propus pentru ımbunatatirea proiectarii apli-catiilor par-
alele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.1 Analiza unei aplicatii paralele folosind modelul propus . . . 34
3.2 Analiza cu DOE a unei aplicatii paralele ce utilizeaza metoda de-
scompunerii domeniului de date: sort last parallel rendering . . . 36
3.2.1 Planul experimental . . . . . . . . . . . . . . . . . . . . . . 37
3.2.2 Analiza statistica a modelului . . . . . . . . . . . . . . . . . 38
3.2.2.1 Analiza volumului de date procesat . . . . . . . . 40
3.2.2.2 Analiza timpului de procesare . . . . . . . . . . . 41
3.2.2.3 Analiza timpilor de comunicatie . . . . . . . . . . 43
3.2.3 Interpretarea rezultatelor . . . . . . . . . . . . . . . . . . . 45
3.3 Concluzii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Partea a II-a: SOLUTII DE IMPLEMENTARE A INFRASTRUCTURII
PENTRU SISTEMELE GRID SI A CLUSTERELOR COMPONENTE 49
4 Clustere si sisteme grid 51
4.1 Arhitecturi de tip Grid . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2 Arhitectura clusterelor . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.3 Studiu de caz - Gridul GRAI . . . . . . . . . . . . . . . . . . . . . 55
4.3.1 Implementarea infrastructurii GRAI . . . . . . . . . . . . . 56
4.3.1.1 RocksClusters - Cluster Deployment and Manage-
ment Tool in Grid Systems . . . . . . . . . . . . . 56
4.3.1.2 Suportul pentru instalarea multi-site si securitatea
ın RocksClusters . . . . . . . . . . . . . . . . . . . 57
4.3.2 Concluzii . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5 Un nou model de optimizare a comunicatiilor ın clustere 59
5.1 Definirea problemei . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.2 Modelul de optimizare a comunicatiilor . . . . . . . . . . . . . . . 60
5.3 Implementarea modelului . . . . . . . . . . . . . . . . . . . . . . . 62
5.4 Rezultate si concluzii . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6 Tehnici de gestiune a resurselor ın clustere 67
6.1 Definirea problemei . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.2 Arhitectura sistemului de management a resurselor . . . . . . . . . 68
6.3 Implementare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.4 Rezultate si concluzii . . . . . . . . . . . . . . . . . . . . . . . . . 70
CUPRINS iii
7 Concluzii, contributii si directii viitoare de cercetare 73
7.1 Concluzii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
7.2 Contributii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
7.3 Directii viitoare de cercetare . . . . . . . . . . . . . . . . . . . . . . 77
Bibliografie 79
Capitolul 1
Introducere
1.1 Motivatie
Aceste ultime evolutii ale sistemelor de calcul paralel duc inevitabil la prezenta tot
mai pregnanta a paralelismului ın aplicatiile software utilizate. Desi hardware-ul ieftin
este disponibil oricui, dezvoltarea de software pentru aceste sisteme de calcul paralel
constituie un obstacol pentru majoritatea programatorilor. Astfel, producerea de
software care sa foloseasca eficient un sistem de calcul paralel ramane o problema ce
se adreseaza specialistilor ın domeniu.
In dezvoltarea aplicatiilor pentru un sistem uniprocesor, programatorul se con-
centreaza asupra algoritmului, luand ın considerare aspecte precum complexitatea
calculelor si necesarul de memorie pentru a produce programe eficiente. Migrarea
spre o arhitectura paralela pune noi probleme precum distributia taskurilor pe mai
multe fire de executie, partitionarea datelor si colaborarea dintre taskuri sau opti-
mizarea resurselor utilizate.
Pe o arhitectura paralela, aplicatiile trebuie sa aiba posibilitatea de a executa
portiuni de cod simultan, iar ın acest scop este necesara ımpartirea sarcinilor de
lucru. Acest concept de partitionare a problemelor complexe ın subprobleme ce se
pot executa ın paralel pe mai multe procesoare pare extrem de intuitiv. Pentru ca o
aplicatie paralela sa fie eficienta, trebuie analizate problemele legate de granularitate
(ın vederea minimizarii comunicatiilor ıntre procese), de suprapunere a calculelor si a
comunicatiilor sau reducerea numarului operatiilor de sincronizare dintre procesoare.
Mai mult, cresterea numarului de procese implicate ın rezolvarea unei probleme poate
duce la aparitia complicatiilor ın rezolvarea sincronizarii.
Pe de alta parte, implementarile optimale devin foarte complexe si sunt, astfel,
predispuse la erori. Reducerea numarului de operatii de sincronizare poate conduce la
aparitia problemelor specifice aplicatiilor paralele: blocajele (apar atunci cand exista
concurenta asupra accesului la o resursa si unul sau mai multe procese nu pot rula)
1
1. Introducere
si/sau concurenta ıntre mesaje (atunci cand ordinea livrarii mesajelor schimba rezul-
tatele furnizate de aplicatie). Aceste erori pot fi dificil de prevazut si de ınteles, atat
datorita faptului ca se pot manifesta doar ın anumite configuratii de intrare cat si da-
torita metodelor de analiza a erorilor. Mai mult, o aplicatie paralela trebuie analizata
si din punct de vedere al performantelor. Trebuie avute ın vedere masina paralela pe
care va rula aplicatia, resursele ocupate si conditiile ın care ruleaza. Performantele
unei aplicatii paralele sunt puternic influentate si de ıncarcarea clusterului pe care
ruleaza.
In domeniul calculului de mare performanta, ıncepand de la sfarsitul anilor ’90
se depun eforturi pentru dezvoltarea sistemelor Grid. Aceste sisteme furnizeaza
cercetatorilor accesul la resurse de calcul ce depasesc performantele unui cluster de
tip Beowulf construite din componente disponibile utilizatorilor comuni. Inca de la
ınceputuri, scopul fundamental al tehnologiilor Grid a fost acela de a realiza sisteme
dinamice ce interconecteaza facilitati distribuite geografic pentru accesul la unitati
de procesare, medii de stocare, senzori, instrumente si multe altele. Un rol impor-
tant ın cadrul sistemelor Grid ıl joaca clusterele de calculatoare si supercalculatoarele,
acestea reprezentand principala resursa partajata. Dezvoltarea sistemelor Grid a dus
la cresterea interesului cercetatorilor din diverse domenii. Existenta unor aplicatii ce
rezolvau problemele la care acestia cautau solutii, a impus necesitatea utilizarii noilor
resurse puse la dispozitie de sistemele Grid. Fiind eterogene prin natura lor, sistemele
Grid au impus cautarea de solutii pentru a putea rula aplicatii paralele scrise initial
pentru un anumit tip de masina paralela ıntr-un mediu complet nou. Cercetarile ın
acest domeniu dinamic au impus dezvoltarea de noi modele si tehnici de proiectare a
aplicatiilor paralele, de noi tehnici de programare, precum si la adaptarea acestora la
diverse configuratii hardware.
In acesta teza sunt prezentate solutii care adreseaza aceste probleme. Sunt des-
crise metode destinate proiectarii si analizarii performantelor aplicatiilor paralele si a
sistemelor paralele pe care acestea pot rula. Predictia performantelor aplicatiei para-
lele ajuta la identificarea problemelor aparute ın proiectarea acesteia si a factorilor
ce influenteaza performantele. Performantele clusterelor pe care ruleaza aplicatiile
paralele reprezinta un factor important de luat ın considerare atunci cand se anal-
izeaza o aplicatie paralela. In lucrarea de fata sunt tratate atat probleme legate de
constructia clusterelor, cat si solutii legate de ımbunatatirea performantelor acestora.
Tinand cont de evolutia sistemelor de calcul de mare performanta, un capitol impor-
tant este adresat proiectarii si implementarii unei infrastructuri Grid si a clusterelor
componente.
1.2 Structura tezei
Aceasta lucrare, organizata sub forma a sase capitole, prezinta aportul autorului adus
ın cadrul temei Contributii la proiectarea aplicatiilor paralele pe clustere de cal-
2
1.2. Structura tezei
culatoare, atentia fiind focalizata asupra dezvoltarii unei noi metode de proiectare a
aplicatiilor paralele si de analiza a performantelor de rulare ale acestora ın clustere.
Primul capitol al acestei lucrari justifica abordarea temei propuse si puncteaza prin-
cipalele obiective atinse. De asemenea, tot ın cadrul acestui prim capitol este detaliat
si modul ın care contributiile aduse temei au fost validate prin publicarea rezultatelor
obtinute.
In continuare, lucrarea este organizata ın doua parti. Prima parte trateaza pro-
blematica proiectarii si analizei performantelor unei aplicatiilor paralele.
Capitolul 2 detaliaza pe larg problemele implicate ın proiectarea aplicatiilor para-
lele. Sunt prezentate pe rand etapele de proiectare, de analiza cantitativa si calitativa
a unei aplicatii si problema echilibrarii ıncarcarii.
In capitolul al 3-lea este prezentata o noua metoda de proiectare a aplicatiilor
paralele tinand cont de factorii care pot influenta atat performantele aplicatiei, cat
si performantele retelei, ıncarcarea procesoarelor, memoria disponibila, etc. Analiza
acestor factori este realizata utilizand proiectarea statistica a experimentelor (De-
sign of Experiments: DOE ). Sunt descrise pe scurt tehnicile folosite ın analiza
statistica: analiza dispresionala (analysis of variance: ANOVA) si analiza de regresie.
Utilizarea tehnicilor specifice DOE ın proiectarea unei aplicatii paralele permite de-
scrierea comportamentului acestei aplicatii ın functie de factorii care o influenteaza.
Astfel, modelul propus permite testarea riguroasa a unei aplicatii paralele atat prin
definirea setului de teste, cat si prin prezicerea performantelor obtinute de aplicatie.
In functie de numarul parametrilor de intrare si de raspunsul urmarit, se pot identifica
mult mai usor erorile aparute ın cadrul fiecarei etapa de proiectare. Totodata analiza
statistica a permis eliminarea factorilor care nu au nici un efect asupra raspunsului
aplicatiei analizate si permite proiectantului sa verifice performantele pentru parametri
de intrare reali, fara a rula efectiv aplicatia. Estimarile obtinute din analiza statistica
pot fi utilizate la optimizarea gradului de ocupare a resurselor la un moment dat de
aplicatie si la ımbunatatirea acesteia ın sensul modificarii dinamice a modului de lucru
ın functie de datele de intrare/iesire.
Partea a doua a tezei este dedicata dezvoltarii unei infrastructuri de tip Grid si a
clusterelor componente. Rularea aplicatiilor paralele pe clustere de calculatoare sau
ın sisteme Grid presupune existenta unei infrastructuri hardware si software adecvate.
Capitolul 4 este dedicat prezentarii arhitecturii clusterelor, a sistemelor Grid si a
unui studiu de caz asupra arhitecturii Gridului GRAI, dezvoltat ın cadrul proiectului
de cercetare ”GRID ACADEMIC PENTRU APLICATII COMPLEXE”, contract Nr.
74 CEEX-II03 (2006-2008), director prof. dr. Mitica Craus. In cadrul acestui proiect
au fost studiate tehnologiile de proiectare si implementare a clusterelor si a sistemelor
Grid. Capitolul include, pe langa prezentarea infrastructurii hardware si software a
Gridului GRAI, si o justificare a alegerii tehnologiilor utilizate.
Odata dezvoltata infrastructura gridului GRAI, cercetarile ulterioare s-au axat pe
ımbunatatirea performantelor clusterlor ınglobate de acest sistem Grid. Astfel, au
3
1. Introducere
fost avute ın vedere optimizarea comunicatiilor si partajarea resurselor disponibile
ın clusterele membre ale gridului GRAI. Capitolul 5 este dedicat prezentarii unui
model de optimizare a comunicatiilor ın reteaua interna a clusterelor. Implementarea
acestui model pe un cluster al gridului GRAI a condus la reducerea timpilor de transfer
a datelor ıntre nodurile din cluster. Spre deosebire de solutiile existente, avantajul
modelului propus este ca rezolva aceasta problema utilizand doar facilitatile oferite de
nucleul sistemului de operare Linux. Pentru implementarea acestui model este propus
si un algoritm de analiza a performantlor si de optimizare a comunicatiilor. Cercetarile
incluse ın acest capitol au fost ıncununate de obtinerea premiului Best Paper la
International Conference on Computers, Communications & Control (ICCCC) 2010.
Capitolul 6 este dedicat problemei de partajare a resurselor unui cluster. Parta-
jarea resurselor reprezinta o problema cu implicatii multiple ın managementul task-
urilor si a retelei de comunicatii a clusterului. In mod uzual, politicile de rezervare a
resurselor utilizate de job manager -e iau ın considerare pentru fisierele de descriere
a job-ului doar numarul de procesoare, memoria disponibila si arhitectura sistemului.
Pentru aplicatiile de tip data intensive, timpul de acces la fisiere/date si timpii de
transfer al acestor date sunt timpi critici. Performantele si rezultatele acestui tip de
aplicatii sunt puternic dependente de acesti timpi. In mod uzual, ın cazul unui cluster
partajat de mai multi utilizatori, task-urile sunt acceptate pentru rulare de catre un
job manager daca acestea satisfac un anumit set de restrictii. In astfel de cazuri,
job manager -ele nu iau ın considerare resurse precum latimea de banda disponibila ın
reteaua clusterului sau resursele consumate de alte aplicatii ce ruleaza ın cluster. In
acest capitol sunt prezentate o serie de tehnici alternative de management eficient al
resurselor, precum CPU si latime de banda, si implementarea acestor solutii ın clus-
tere. Spre deosebire de cazurile uzuale, aceste tehnici noi permit o alocare dinamica
de resurse ın functie de politicile de rezervare ale acestora impuse de administratorii
sistemului.
In capitolul 7 sunt prezentate sintetic rezultatele obtinute si sunt evidentiate
contributiile aduse pentru domeniile abordate. Finalul capitolului contine propunerile
de cercetare ce deriva din rezultatele obtinute.
4
1.3. Diseminarea rezultatelor
1.3 Diseminarea rezultatelor
Articolele stiintifice ce stau la baza acestei lucrari au fost publicate ın reviste (2), vol-
ume de specialitate (3), carti (1) sau prezentate la conferinte internationale (6).
Contributiile aduse ın cadrul temei abordate s-au conturat ın jurul urmatoarelor
directii de cercetare:
• proiectarea aplicatiilor paralele
Cristian-Mihai Amarandei, Daniel Lepdatu, Simona Caraiman. Im-
proving the Design of Parallel Applications Using Statistical Meth-
ods, Journal of Applied Science, 2011 (jurnal indexat SCOPUS,
Thomson Reuters Master Journal List)
I. Sova and C.M. Amarandei and I. Gavrila, Dynamic Load Balanc-
ing in Tree-Topology Distributed Mobile Agents System, Proceed-
ings of the Eighth International Symposium on Automatic Control
and Computer Science, 2004
T. Teodoru and C.M. Amarandei, Load Balancing in a Mobile
Agent System, Proceedings of 9th International Symposium on Au-
tomatic Control and Computer Science, 2007
• proiectarea si implementarea unei infrastructuri Grid
C.M. Amarandei, A. Rusan, A. Archip and S. (Caraiman) Arustei,
On the Development of a GRID Infrastructure, In H.N. Teodorescu
and M. Craus, editors, Scientific and Educational Grid Applications,
pages 13 - 23, Iasi, Romania, 2008, Ed. Politehnium.
C.M. Amarandei, A. Archip, and S. (Caraiman) Arustei, Perfor-
mance Study for MySql Database Access Within Parallel Applica-
tions, Buletinul Institutului Politehnic din Iasi, Automatic Control
and Computer Science Section, LVI(LII):127 - 134, 2006.
A. Archip, C.M. Amarandei, S. (Caraiman) Arustei, and M. Craus,
Optimizing Association Rule Mining Algorithms Using C++ STL
Templates, Buletinul Institutului Politehnic din Iasi, Automatic Con-
trol and Computer Science Section, LVII(LIII):123 – 132, 2007.
C. Aflori and M. Craus and I. Sova and F. Leon, C. Butincu and
C.M. Amarandei, GRID - Tehnologii si aplicatii, Ed. Politehnium,
2005
S. (Caraiman) Arustei, A. Archip, and C.M. Amarandei, Parallel
RANSAC for Plane Detection in Point Clouds, Buletinul Institutului
Politehnic din Iasi, Automatic Control and Computer Science Sec-
tion, LVII(LIII):139 - 150, 2007.
5
1. Introducere
S. (Caraiman) Arustei, A. Archip and C.M. Amarandei, Grid Based
Visualization Using Sort-Last Parallel Rendering, In H.N. Teodorescu
and M. Craus, editors, Scientific and Educational Grid Applications,
pages 101 - 109, Iasi, Romania, 2008, Ed. Politehnium.
A. Archip, S. (Caraiman) Arustei, C.M. Amarandei and A. Rusan,
On the design of Higher Order Components to integrate MPI appli-
cations in Grid Services, In H.N. Teodorescu and M. Craus, editors,
Scientific and Educational Grid Applications, pages 25 - 35, Iasi,
Romania, 2008, Ed. Politehnium.
• optimizarea comunicatiilor si partajarea resurselor ın clustere.
Cristian-Mihai Amarandei and Andrei Rusan, Techniques for effi-
cient resource management on shared clusters, Proceedings ECIT2010
- 6th European Conference on Intelligent Systems and Technologies
Iasi, Romania, 2010
Andrei Rusan and Cristian-Mihai Amarandei, A New Model for
Cluster Communications Optimization, International Journal of Com-
puters, Communications & Control, Vol. 5, Issue 5, ISSN 1841-9836,
Oradea, Romania, 2010 - ”Best Paper Authored By a PhD Stu-
dent” http://www.iccc.univagora.ro/ , (ISI Impact factor =
0.373)
O parte din cercetarile si rezultatele obtinute ın aceasta lucrare au fost efectuate
ın cadrul urmatoarelor proiecte de cercetare:
• ”GRID academic pentru aplicatii complexe”, contract Nr. 74 CEEX-II03 (2006-
2008), director Mitica Craus;
• ”Sistem de informare distribuit pe o arhitectura GRID, dotat cu agenti inteligenti
pentru constructia si actualizarea automata a fondului documentar si cu in-
strumente de extragere de cunostinte”, Contract de cercetare CNCSIS cod 442
(2005 - 2006);
• ”Sisteme de calcul paralel si distribuit. Tehnologii si aplicatii.”, Grant Banca
Mondiala nr. 44058 (1998 - 2002), grant tip D.
6
Partea I: PROIECTAREA
APLICATIILOR PARALELE
7
Capitolul 2
Metodologii de proiectare a
aplicatiilor paralele
Utilizatorii sistemelor de calcul sunt interesati sa beneficieze din plin de performan-
tele oferite de procesoarele multicore. Daca acest lucru poate fi atins, utilizatorii se
asteapta ca programele lor sa fie din ce ın ce mai rapide si sa includa din ce ın ce mai
multe facilitati ce nu au putut fi introduse ın versiunile anterioare ale software-ului
datorita cerintelor ridicate din punct de vedere al puterii de calcul. Pentru a atinge
acest deziderat, este necesar fie suportul din partea sistemului de operare, fie rularea
mai multor programe ın paralel. Atunci cand este furnizat un procesor multicore este
necesara executia unui singur program pe mai multe nuclee. In cel mai bun caz,
pentru dezvoltatorii de aplicatii ar fi utila existenta unor instrumente care, plecand
de la codul secvential sa genereze un program paralel ce va rula eficient pe noua
arhitectura. Daca astfel de instrumente ar fi disponibile, dezvoltarea de software s-ar
desfasura ca pana acum [Rauber 10]. Din nefericire, experienta cercetarilor din ultimii
20 de ani ın paralelizarea compilatoarelor arata ca pentru foarte multe programe
secventiale este imposibila o paralelizare complet automata [Rauber 10]. Interventia
programatorului este ın continuare necesara pentru a reorganiza corespunzator codul
unei aplicatii secventiale. Pentru dezvoltatorul de software, provocarile apar din
perspectiva restructurarii codului existent pentru a beneficia de avantajele sistemelor
multicore. Programatorul nu se mai poate astepta ca performantele aplicatiei sale sa
creasca automat odata cu cresterea puterii de calcul a procesorului. Este necesar un
efort suplimentar pentru ca aceasta putere de calcul sa poata fi folosita.
Exista cercetari ın domeniul mediilor si limbajelor de programare paralela cu scopul
de a usura scrierea codului paralel prin furnizarea unui anumit nivel de abstractizare
fata de arhitectura masinii.
Stadiul actual al dezvoltarii aplicatiilor paralele poate fi descris pe scurt astfel
9
2. Metodologii de proiectare a aplicatiilor paralele
[Skillicorn 05]: programarea specifica unei anumite arhitecturi (masini paralele) a
ajuns la un anumit nivel de maturitate si beneficiaza de utilitare din ce ın ce mai
sofisticate; ın timp ce programarea paralela independenta de arhitectura sistemului
de calcul este ın continua dezvoltare. Din punct de vedere al arhitecturii sistemelor
paralele, idei noi apar la un interval regulat, idei ce se concretizeaza ın noi tipuri de
procesoare si ın arhitecturi paralele cu diferite grade de parelelism si caracteristici.
Modele de programare paralela au fost dezvoltate rapid pentru fiecare tip de
arhitectura aparuta: executii sincronizate la nivel de instructiune pentru masinile
SIMD (lockstep execution), instructiuni de tip test-and-set pentru gestiunea accesului
la memorie ın cazul masinilor paralele bazate pe partajarea memoriei, precum si mesaje
si canale de comunicatie pentru masinile bazate pe principiul memoriei distribuite
[Skillicorn 05].
Limbaje, algoritmi, compilatoare si ın unele cazuri pentru suite ıntregi de aplicatii
paralele au aparut ın jurul fiecarui tip de arhitectura paralela ın parte.
Utilizatorii sistemelor de calcul de mare performanta doresc sa beneficieze de
software-ul ce exploateaza paralelismul unei anumite arhitecturi chiar daca apar schim-
bari la nivelul hardware-ului. Acest tip de software nu este portabil pe orice tip de
arhitectura. Uneori, nu este portabil nici chiar pe variante extinse ale aceluiasi sistem
[Skillicorn 05]. De aceea, aplicatiile scrise pentru un anumit tip de sistem de calcul
pot fi migrate pe alta arhitectura doar dupa un important efort de rescriere. Uneori
este necesra rescrierea completa a software-ului pentru o anumita arhitectura. Nu-
cleul acestei probleme ıl reprezinta legatura stransa dintre modelul de programare si
arhitectura tinta; ceea ce implica ınvatarea unor noi metode si paradigme de progra-
mare.
2.1 Introducere ın proiectarea aplicatiilor paralele
2.1.1 Definirea problemei
Proiectarea aplicatiilor paralele si a algoritmilor paraleli introduce un plus de complexi-
tate fata de cazul aplicatiilor si algoritmilor secventiali. In cazul proiectarii aplicatiilor
si algoritmilor paraleli, trebuie dezvoltate metodologii care sa conduca la produce-
rea unor coduri paralele eficiente si scalabile. Au fost propuse mai multe astfel
de metodologii, care adreseaza fie cautarea modelului de executie paralela cel mai
potrivit, pe baza descrierii problemei de rezolvat, fie parcurgerea a patru etape pen-
tru crearea programului paralel (partitionarea, comunicarea, aglomerarea si maparea)
[Foster 95], [Cole 89], [Hammond 99].
O prima metoda de realizare a programelor paralele a constat ın paralelizarea
programelor secventiale cu volumul de calcul cel mai mare. Aparent, toate buclele
din program exprima un paralelism intrinsec, care poate fi exploatat prin ımpartirea
lor ın mai multe activitati de calcul simultane. Acest lucru nu poate fi realizat daca
exista dependente de date ıntre iteratiile succesive. In plus, pentru multe probleme,
10
2.1. Introducere ın proiectarea aplicatiilor paralele
solutiile paralelele eficiente nu sunt obtinute prin simpla paralelizare a celui mai bun
algoritm secvential. Astfel, se poate observa aparitia unor compilatoare specializate
care erau puternic legate de modelul sistemului de calcul. Acest fapt a facut aproape
imposibila portarea unui program de pe un sistem cu memorie partajata pe unul cu
memorie distribuita [Grigoras 00].
O alta posibilitate este de a pleca de la problema de rezolvat si de a proiecta
de la ınceput varianta paralela cea mai buna, pentru tipul de sistem de calcul pe
care se va executa. In acest caz trebuie sa se tina cont de tipul de paralelism al
aplicatiei [Hammond 99]. Un alt tip de aplicatii (numite ın literatura de specialitate
aplicatii ”stanjenitor de paralele” – embarassingly parallel) constau ın activitati de
calcul complet diferite (nu necesita comunicatii intermediare) si care pot fi alocate
unor procesoare distincte.
Principala problema ın proiectarea aplicatiilor paralele, este de a obtine un cod
paralel eficient si scalabil. Nu exista o solutie unica, general valabila. In majoritatea
cazurilor, cade ın seama proiectatului sa aleaga o solutie convenabila ın raport cu
diferite criterii, precum natura aplicatiei de paralelizat si tipul de resurse necesare,
tipul masinii paralele, s.a.m.d.
2.1.2 Modelarea aplicatiilor paralele
O prima etapa ın proiectarea aplicatiilor paralele, consta ın definirea activitatilor
paralele, prin exploatarea la maximum a potentialului de paralelizare. Dupa definirea
acestor activitati paralele, trebuie sa se analizeze necesarul de comunicatii, pentru a
se determina care este granularitatea optima a aplicatiei ın raport cu sistemul paralel
tinta, deoarece de dimensiunea optima a granulei depinde eficienta sistemului. Se
observa o contradictie ıntre tendinta de a crea cat mai multe activitati paralele (pana
la numarul maxim dat de numarul procesoarelor din sistem) si aceea de a avea un
numar mai mic de activitati paralele, dar o granularitate mai mare (o eficienta mai
buna). Urmatoarea etapa consta ın planificarea executiei activitatilor paralele pe
procesoare. Spre deosebire de planificarea proceselor ın sistemele secventiale, trebuie
specificat atat momentul lansarii ın executie cat si procesorul pe care se executa.
Daca aplicatia are o structura dinamica (apar noi activitati de calcul), poate deveni
utila abordarea unor algoritmi de echilibrare dinamica a ıncarcarii [Grigoras 00].
Conform lui [Gergel 06], dezvoltarea unei aplicatii paralele implica urmatoarele
etape:
• Analiza activitatilor de calcul si ımpartirea lor ın subactivitati cu un grad ridicat
de independenta ce pot fi procesate separat.
• Realiazarea interactiunilor dintre subactivitatile de calcul pentru rezolvarea
problemei initiale.
• Definirea sistemului de calcul necesar ce poate rezolva problema si distribuirea
subactivitatilor pe procesoare.
11
2. Metodologii de proiectare a aplicatiilor paralele
Aceste activitati, definite la modul general, presupun ca volumul de calcule alocat unui
procesor este aproximativ acelasi, iar interactiunile dintre subactivitati sunt minime.
Un prim model de dezvoltare a aplicatiilor paralele, propus de Ian Foster [Foster 95],
presupune crearea de mecanisme care sa permita discutia explicita ıntre task-uri cu
privire la operatiile paralele si cele locale. Acest model de dezvoltare permite re-
alizarea unor aplicatii scalabile si modulare, daca sunt satisfacute urmatoarele cerinte
[Gergel 06]:
• Aplicatiile paralele trebuie sa fie formate dintr-unul sau mai multe task-uri care
se executa ın paralel. Numarul task-urilor poate varia ın timpul executiei.
• Un task trebuie sa contina cod secvential si memorie locala (o masina von
Neumann virtuala). In plus, un task este interfatat cu exteriorul prin intermediul
unui set de porturi de intrare/iesire.
• Un task trebuie sa poata realiza patru operatii de baza: trimitere/primire de
mesaje, creare de task-uri noi, terminare.
• Operatia de trimitere de mesaje trebuie sa fie asincrona: se termina imediat.
Operatia de primire a mesajului trebuie sa fie sincrona: task-ul se blocheaza
pana cand este disponibil mesajul.
• Porturile de I/O trebuie sa fie conectate prin cozi de mesaje numite canale de
comunicatie. Aceste canale de comunicatie pot fi create sau sterse, iar referinte
catre ele pot fi incluse ın mesaje.
• Task-urile pot fi mapate pe procesoare fizice ın mai multe moduri, maparea nu
trebuie sa afecteze semantica programului. In particular, mai multe task-uri
pot fi mapate pe un singur procesor.
Acest model furnizeaza un mecanism numit dependenta de date: pentru a-si putea
continua executia, un task poate avea nevoie de datele localizate ın memoria locala
a altor task-uri. Alte proprietati ale acestui model, identificate de [Foster 95], sunt:
• Performanta: procedurile si structurile de date din programarea secventiala
sunt eficiente deoarece pot fi mapate simplu si eficient pe masina von Neumann.
Acest lucru este posibil si ın cazul task-urilor si canalelor de comunicatie. Un
task reprezinta codul care poate fi executat secvential pe un singur procesor.
Daca doua task-uri care partajeaza acelasi canal de comunicatie sunt mapate
pe procesoare diferite, atunci canalul de comunicatie este implementat ca o
comunicatie inter-procesor. Daca sunt mapate pe un acelasi procesor, atunci
pot fi utilizate alte mecanisme mai eficiente.
• Independenta fata de maparea pe procesoare. Deoarece task-urile uti-
lizeaza acelasi mecanism (canale de comunicatie) privind localizarea task-urilor,
rezultatele furnizate de aplicatie nu depind de locul executiei task-ului. Asadar,
algoritmii pot fi implementati fara a se tine cont de numarul de procesoare pe
care se executa; de fapt, algoritmii ar trebui realizati astfel ıncat sa poata crea
mai multe task-uri decat numarul de procesoare.
• Modularitatea. In programarea modulara, numeroase componente sunt reali-
12
2.1. Introducere ın proiectarea aplicatiilor paralele
zate separat si apoi combinate pentru a realiza programul complet. Interactiu-
nea dintre module este restrictionata de interfete bine definite. Asadar, mo-
dulele implementate pot fi modificate fara alterarea altor componente, iar pro-
prietatile programului pot fi aflate din specificatiile modulelor si din codul care
leaga aceste module. Aplicata cu succes, programarea modulara duce la redu-
cerea complexitatii programului si faciliteaza reutilizarea codului.
• Determinismul. Un algoritm sau un program se numeste determinist daca
executia pentru o intrare particulara produce ıntotdeauna acelasi rezultat si
nedeterminist daca pentru aceeasi intrare se obtin iesiri diferite. Programele
deterministe sunt usor de ınteles, fiind de dorit un model de programare paralela
care permite dezvoltarea acestui tip de aplicatii. Verificarea corectitudinii unui
algoritm/program determinist poate fi realizata mai usor: un model determinist
permite identificarea rapida a tuturor cazurilor de executie posibile. Modelul
task/canale de comunicatie faciliteaza obtinerea unor algoritmi/aplicatii deter-
ministe.
Alte modele de programare au fost propuse, diferenta dintre ele fiind data de
flexibilitate, mecanismele de interactiune dintre task-uri, granularitatea task-urilor,
suport pentru pozitionare, scalabilitate si modularitate:
• Transmitere de mesaje (Message passing). Acest model de programare pa-
ralela este, probabil, cel mai utilizat. Programele dezvoltate dupa acest model,
creeaza task-uri multiple si ıncapsuleaza datele conform modelului task/canale
de comunicatie. Task-urile sunt identificate de un nume unic si interactioneaza
ıntre ele prin transmitere de mesaje. Din acest punct de vedere, modelul mes-
sage passing poate fi privit ca o particularizare a modelului task/canale de
comunicatie. Modelul nu exclude crearea dinamica a task-urilor, executia mai
multor task-uri pe un procesor sau executia a diferite programe de task-uri
diferite. Unele versiuni ale sistemelor message passing creeaza un numar fix de
task-uri identice la pornirea programului si nu permit crearea sau distrugerea
task-urilor ın timpul rularii programului. Despre aceste sisteme se spune ca
implementeaza un model de executie SPMD (Single Program Multiple Data)
deoarece acelasi program opereaza asupra mai multor seturi de date diferite.
• Paralelismul de date (Data Parallelism). Acest model de programare ex-
ploateaza paralelismul care deriva din aplicarea unei aceleiasi operatii asupra
mai multor elemente ale structurilor de date. Un program care foloseste acest
model consta ın secvente de astfel de operatii. Granularitatea acestui model
este redusa deoarece, ın foarte multe cazuri, operatia efectuata asupra unui
singur element de date este privita ca task independent. Trebuie tinut cont si
de faptul ca localizarea datelor poate fi un impediment ın calea implementarilor
eficiente ce urmaresc modelul de dezvoltare ın discutie. Compilatoarele pen-
tru acest model cer programatorului informatii despre modul ın care datele
13
2. Metodologii de proiectare a aplicatiilor paralele
sunt distribuite procesoarelor sau, altfel spus, cum sunt ımpartite datele ıntre
task-uri.
• Memoria partajata (Shared Memory). In acest model de programare parale-
la task-urile partajeaza un spatiu de adrese comun asupra caruia au drept de
scriere/citere ın mod asincron. Pentru a controla accesul la memoria comuna
sunt folosite diverse mecanisme de sincronizare. Un posibil avantaj al acestui
model este absenta notiuni de proprietate a datelor (data ownership). In acest
context nu este necesara specificarea explicita a comunicatiilor de date ıntre
task-uri, simplificandu-se astfel procesul de dezvoltare al aplicatiilor. Cu toate
acestea, ıntelegerea si manipularea localizarii datelor, precum si scrierea unor
programe deterministe este mai dificila.
O sinteza a modelelor de programare paralela, ın functie de gradul de abstractizare
a fost realizata ın [Skillicorn 96]. Modelele sunt grupate ın sase categorii, dupa cum
urmeaza:
1. Modele ce abstractizeaza complet paralelismul.
2. Modele ın care paralelismul este explicit, dar descompunerea domeniului este
implicita, ceea ce atrage dupa sine faptul ca maparea, comunicatiile si operatiile
de sincronizare sunt, la randul lor, implicite.
3. Modele ın care paralelismul si descompunerea sunt prezentate explicit, iar ma-
parea, comunicatiile si operatiile de sincronizare sunt implicite.
4. Modele ın care paralelismul, descompunerea si maparea sunt explicite, iar
comunicatiile si operatiile de sincronizare sunt implicite.
5. Modele ın care paralelismul, descompunerea, maparea si comunicatiile sunt
explicite, iar operatiile de sincronizare sunt implicite.
6. Modele ın care totul este explicit. Programatorul trebuie sa precizeze toate
detaliile de implementare.
Aceste categorii nu acopera toate modelele existente, dar includ pe cele ce in-
troduc idei semnificative si ofera o privire de ansamblu asupra stadiului actual al
tehnicilor de programare paralela existente.
2.2 Modele de proiectare a aplicatiilor paralele
O majoritate covarsitoare de probleme de programare pot fi paralelizate prin inter-
mediul mai multor metode. Sunt, de asemenea, situatii ın care solutiile paralele efi-
ciente difera de paralelizarile induse de algoritmii secventiali existenti. Metodologia de
proiectare pe care o vom descrie intentioneaza sa ıncurajeze o abordare a proiectarii
ın care considerentele independentei de masina si concurenta sa fie luate ın consider-
are ınaintea aspectelor legate de specificul masinii pe care va rula aplicatia (aspectele
legate de arhitectura de rulare fiind ın acest context implicate spre finalul procesului
de proiectare). Aceasta metodologie ımparte proiectarea aplicatiilor ın patru etape
distincte: partitionare, comunicatii, aglomerare si mapare (partitioning, communica-
14
2.2. Modele de proiectare a aplicatiilor paralele
tion, agglomeration, and mapping – PCAM)[Foster 95]. In primele doua etape, se va
pune accent pe paralelism, scalabilitate si descoperirea algoritmului care ındeplineste
aceste cerinte. In etapa a treia si a patra, se va pune accent pe performante. Astfel,
pornind de la specificatiile problemei, se realizeaza partitionarea calculelor, sunt de-
terminate cerintele de comunicatie, se realizeaza aglomerarea task-urilor, iar, ın final,
acestea sunt alocate procesoarelor (Figura 2.1) [Rauber 10].
• Partitionarea: Calculele care vor trebui realizate si datele asupra carora se
lucreaza sunt descompuse ın task-uri mai mici. Probleme practice, precum
numarul de procesoare de pe masina tinta, sunt ignorate si atentia este con-
centrata asupra recunoasterii posibilitatilor de obtinere a paralelismului.
• Proiectarea comunicatiilor : Sunt determinate comunicatiile necesare pentru
coordonarea executiei task-urilor si este definita structura comunicatiilor si al-
goritmii necesari.
• Aglomerarea: Task-urile si structura comunicatiilor definite ın prima parte a
proiectarii sunt evaluate luand ın considerare cerintele de performanta si cos-
turile de implementare. Daca este necesar, task-urile pot fi grupate ın task-uri
mai mari pentru a creste performantele si a reduce costurile de dezvoltare.
• Maparea: Fiecare task este alocat spre executie unui procesor astfel ıncat sa
fie satisfacute cerintele de utilizare maxima a procesoarelor si minimizare a
costurilor de comunicatie. Maparea poate fi definita static sau determinata la
rularea aplicatiei prin intermediul unor algoritmi de echilibrare a ıncarcarii.
Partiţiona
re
Aglomera
re
Comunicaţii
Mapare
Problemă
Figura 2.1: Metodologie de proiectare a aplicatiilor paralele (adaptare dupa[Rauber 10] si [Quinn 04])
Rezultatul acestui proces de proiectare poate fi un program care porneste si
opreste task-uri dinamic, utilizand algoritmi de echilibrare a ıncarcarii pentru con-
trolul maparii task-urilor pe procesoare. O alternativa ar fi un program SPMD care
creeaza cate un singur task pentru fiecare procesor. Acelasi proces de realizare a
15
2. Metodologii de proiectare a aplicatiilor paralele
algoritmului se aplica ın ambele cazuri, dar, ın cazul unui program SPMD, actunile
asociate maparii sunt incluse ın etapa aglomerarii.
Proiectarea algoritmilor paraleli este prezentata ca o activitate secventiala. In
practica, este un proces paralel, cu multe preocupari privind simultaneitatea. De
asemenea, desi se ıncearca evitarea backtracking-ului, evaluarea partiala sau com-
pleta a rezultatului proiectarii poate duce la aparitia unor schimbari ale etapelor de
proiectare realizate ın pasii anteriori.
2.3 Analiza cantitativa si calitativa a algoritmilor paraleli
O aplicatie paralela este bine proiectata daca optimizeaza timpul de executie, cerintele
de memorie, costurile de implementare si de ıntretinere, etc. Aceste ıncercari de
optimizare implica, ın mod uzual, compromisuri ıntre simplitate, performanta, porta-
bilitate si alti factori. Deciziile referitoare la ce metoda de rezolvare trebuie aleasa
pentru o anumita problema trebuie luate considerand diferitele costuri implicate de
fiecare metoda ın parte. In acest context devine utila dezvoltarea unor modele ma-
tematice pentru analiza performantelor. Aceste modele pot fi folosite pentru a face
o comparatie eficienta ıntre diversi algoritmi, pentru evaluarea scalabilitatii si pentru
identificarea diverselor deficiente (un exemplu de acest fel este ”gatuirea” executiei
– bottlenecks) ınainte de investi un efort substantial ın implementare. Modelele de
performanta pot ajuta eforturile de implementare pentru a indica eventualele opti-
mizari posibile [Foster 95].
2.3.1 Parametrii cantitativi
2.3.1.1 Accelerarea
Accelerarea, notata cu Sp, reprezinta raportul ıntre timpul de executie al celui mai
bun program secvential (t1) si timpul de executie al programului paralel echivalent
(tp) pe un sistem paralel cu p procesoare:
Sp =t1tp
(2.3.1)
Daca, fie nu se cunoaste timpul de executie al celui mai bun algoritm secvential,
fie varianta paralela difera foarte mult de cea secventiala, comparatia nu-si mai are
rostul. Din acest motiv se accepta mai multe variante de definitie pentru cei doi
timpi si vom avea cinci alternative la definitia accelerarii [Sahni 4]:
• relativa, atunci cand t1 este timpul de executie al variantei paralele pe un singur
procesor al sistemului paralel; depinde de problema de rezolvat si de numarul
de procesoare;
• reala, atunci cand se compara timpul de executie paralel cu timpul de executie
pentru varianta secventiala cea mai rapida, pe un procesor al sistemului paralel.
Este posibil ca cel mai rapid algoritm ce rezolva problema sa nu fie cunoscut,
16
2.3. Analiza cantitativa si calitativa a algoritmilor paraleli
sau un singur algoritm nu este cel mai rapid pentru toate dimensiunile posibile
ale problemei, motiv pentru care se alege ca referinta varianta secventiala cea
mai rapida;
• absoluta, atunci cand se compara timpul de executie al algoritmului paralel cu
timpul de executie al celui mai rapid algoritm secvential, executat pe procesorul
serial cel mai rapid;
• asimptotica, atunci cand se compara timpul de executie al celui mai bun algo-
ritm secvential cu functia de complexitate asimptotica a algoritmului paralel,
ın ipoteza existentei numarului necesar de procesoare;
• relativ asimptotica, atunci cand se foloseste complexitatea asimptotica a algo-
ritmului paralel executat pe un procesor.
Daca p este numarul de procesoare ale sistemului paralel, atunci, ıntr-un caz ideal,
are loc urmatoarea relatie:
tp =t1p. (2.3.2)
Utilizand 2.3.2, conform ecuatiei 2.3.1, se obtine Sp = p. Intrucat apelurile functiilor
sistem determina o diminuare a accelerarii, ın cazurile reale se obtine:
1 ≤ Sp ≤ p (2.3.3)
2.3.1.2 Eficienta
Eficienta masoara modul ın care sunt utilizate procesoarele din sistem:
Ep =Spp. (2.3.4)
Acest parametru exprima penalitatea platita pentru nivelul de performanta atins.
[Grigoras 00]. In cazul ideal acest parametru are valoare 1, dar ın cazurile reale
0 < Ep < 1.
Timpul de executie paralela se mai poate exprima si ın functie de gestiunea pro-
ceselor paralele (creare/distrugere, planificare, sincronizare), comunicatiile dintre ele,
echilibrarea ıncarcarii si realizarea de calcule suplimentare. Aceste operatii consuma
un timp numit timp de overhead, care se aduna la timpul executiei paralele si depinde
de volumul de calcule si de numarul de procesoare [Kwiatkowski 02].
2.3.1.3 Supraıncarcarea
Daca eficienta este privita ca o functie dependenta de dimensiunea problemei (n)
si de numarul de procesoare (p), notata E(n, p), atunci supraıncarcarea se poate
defini ca [Petcu 01]:
f(n, p) =1
E(n, p)− 1 (2.3.5)
Supraıncarcarea (overhead) include costurile implicate de startarea unui proces, de
comunicare a datelor, de diversele sincronizari si eventuale calcule suplimentare. In
general supraıncarcarea poate fi [Petcu 01]:
17
2. Metodologii de proiectare a aplicatiilor paralele
• software: calcule aditionale descompunerii datelor si atribuirii acestora catre
procesoare;
• datorata dezechilibrului ıncarcarii : fiecare proces ar trebui sa primeasca acelasi
volum de calcule;
• datorata comunicatiilor : ın cazurile ın care este imposibila suprapunerea co-
municatiilor si a calculelor, accesarea datelor aflate la distanta poate introduce
timpi suplimentari considerabili sau ın cazul ın care volumul de calcule dintre
comunicatii succesive este redus (granularitate redusa).
2.3.1.4 Costul
Costul unui program paralel (Cp) se defineste ca fiind produsul dintre timpul de calcul
(tp) si numarul de procesoare (p). Daca se presupune ca toate procesoarele executa
acelasi numar de instructiuni, atunci:
Cp = p · tp (2.3.6)
Deoarece o aplicatie paralela poate fi simulata pe un sistem secvential, caz ın care
procesorul executa de p ori instructiunile executate de un procesor al sistemului para-
lel, atunci aplicatia paralela este optima din punct de vedere al costului daca valoarea
acestuia este egala cu timpul de executie al celei mai bune variante secventiale.
2.3.2 Parametrii calitativi
2.3.2.1 Granularitatea
Granularitatea (grain size) indica volumul de calcule alocate procesoarelor ın valori
minime acceptabile.
Granularitatea aplicatiei - reprezinta dimensiunea minima a unei unitati secventiale
dintr-un program, exprimata ın numar minim de instructiuni, ın care nu se executa
operatii de sincronizare sau de comunicare cu alte procese (G = Tcalcule/Tcomunic)
[Kwiatkowski 02] Deoarece un proces este compus din unitati secventiale de granula-
ritati diferite, atunci granularitatea unui proces este granularitatea unitatii secventiale
celei mai mici [Grigoras 00].
Granularitatea sistemului - valoarea minima a granularitatii sub care performanta
unui sistem paralel dat scade semnificativ si este justificata de timpul de overhead
(comunicatii, sincronizari) care poate fi comparabil cu timpul de calcul paralel. Gra-
nularitatea sistemului paralel este definita ca raportul dintre timpul consumat pentru o
operatie fundamentala de comunicatie si timpul consumat de o operatie fundamentala
de calcul.
Granularitatea este folosita ın [Kwiatkowski 02] pentru a calcula eficienta si im-
plicit accelerarea plecand de la formula urmatoare:
E =G
G+ 1(2.3.7)
18
2.4. Problema echilibrarii ıncarcarii ın proiectarea aplicatiilor paralele
Este de dorit ca un calculator paralel sa aiba o granularitate mica, astfel ıncat sa poata
executa eficient o gama larga de programe, iar aplicatiile sa aiba o granularitate cat
mai mare.
2.3.2.2 Scalabilitatea
Scalabilitatea reprezinta posibilitatea de a asigura cresterea accelerarii odata cu
cresterea numarului de procesoare pornind de la ipoteza ca programul executat are o
granularitate suficient de mare. Daca se obtine o crestere liniara a accelerarii, avem
un sistem scalabil liniar. La nivelul aplicatiei este necesar sa fie asigurata flexibilitatea
si adaptabilitatea la dinamica arhitecturii.
Factorii ce influenteaza scalabilitatea unei aplicatii sunt legati de echipamentele
hardware si/sau de bibliotecile si aplicatiile folosite: dimensiunea memoriei, dezechi-
librele arhitecturale, performantele sistemului de I/O, accesul concurent la resurse,
comunicatii sau echilibrarea ıncarcarii. Optimizarea performantelor si ımbunatatirea
calitatii unui sistem multiprocesor se bazeaza pe exploatarea paralelismului la nivelul
proceselor care alcatuiesc aplicatiile si ınsusi a sistemului de programe de baza.
2.4 Problema echilibrarii ıncarcarii ın proiectarea aplicatiilor
paralele
2.4.1 Echilibrarea ıncarcarii ın aplicatiile paralele
Un rol important ın proiectarea aplicatiilor paralele cu efect imediat asupra performan-
telor ıl are echilibrarea ıncarcarii. Scopul echilibrarii ıncarcarii poate fi formulat ın
felul urmator: avand o colectie de task-uri care realizeaza un calcul si un set de
computere pe care aceste task-uri pot rula, sa se gaseasca o mapare de task-uri
la computere astfel ıncat fiecare computer sa aiba o cantitate aproximativ egala de
sarcini. O mapare care echilibreaza ıncarcarea procesoarelor va mari eficienta pe
ansamblu a calculului. Marirea eficientei pe ansamblu va reduce timpul de executie
al calculului, care este de fapt un scop al calculului paralel. Dar uneori o tratare
simplista a echilibrarii ıncarcarii nu conduce ın mod necesar la un calcul mai rapid.
Daca aplicatia este statica (adica timpul asociat unui anumit task poate fi determinat
apriori), problema echilibrarii ıncarcarii se reduce la maparea grafului aplicatiei pe
reteaua de procesoare. Daca aplicatia este dinamica (adica ıncarcarea unui procesor
poate varia ın decursul unui calcul si nu poate fi estimata ınainte), exista un numar
de strategii (SID, DASUD, difuzie) care pot fi folosite pentru a varia ıncarcarea unui
procesor. Majoritatea strategiilor de echilibrare a ıncarcarii au cel putin unul din
urmatoarele neajunsuri:
• Nu se poate face o estimare dinamica a ıncarcarii. Majoritatea tehnicilor dez-
voltate pana ın prezent se bazeaza pe cunoasterea globala a volumului de lucru.
19
2. Metodologii de proiectare a aplicatiilor paralele
• Eficienta lor nu poate fi analizata teoretic. Desi intuitiv, multe tehnici pot avea
un potential destul de mare, implementate practic pot genera multe dezechilibre
ın distributia sarcinilor.
• Sunt specifice aplicatiilor. Multe dintre aceste tehnici au fost proiectate si
implementate numai pentru anumite aplicatii
• Aplicabilitatea lor a fost studiata la o scara redusa. O parte din aceste tehnici au
fost studiate pe masini cu un numar mic de procesare sau pe task-uri generice.
• Sunt prea complicatii pentru implementari optimale. Modalitatea relativ com-
plexa ın care sunt prezentati acesti algoritmi ın lucrarile de specialitate duce la
aparitia erorilor ın implementarea acestora.
• Ingreuneaza foarte mult comunicatiile ıntre procese si nu se reuseste estimarea
costului acestor comunicatii.
• Sunt sincroni. Multe dintre aceste tehnici sunt concepute astfel ıncat toate
unitatile de procesare sa execute ın acelasi timp faza de echilibrare a ıncarcarii.
O solutie practica pentru problema echilibrarii ıncarcarii dinamice implica cinci faze
distincte:
• Evaluarea ıncarcarii: o estimare a ıncarcarii procesorului trebuie realizata pentru
a determina daca exista un eventual dezechilibru.
• Determinarea profitabilitatii: odata ce ıncarcarea procesoarelor a fost evaluata,
prezenta dezechilibrului poate fi detectat? Daca costul dezechilibrului depaseste
costul echilibrarii ıncarcarii, atunci echilibrarea ıncarcarii poate fi initiata.
• Calcularea vectorului de transfer al ıncarcarii: pe baza masuratorilor facute ın
prima faza, se calculeaza vectorul de transfer al ıncarcarii pentru a echilibra
procesoarele.
• Selectia task-urilor: Task-urile sunt selectate pentru transfer ın acord cu vec-
torul de transfer calculat ın faza anterioara.
• Migrarea task-urilor: Odata selectat, task-urile sunt transferate de la un com-
puter la altul.
2.4.2 Echilibrarea dinamica a ıncarcarii
In cazul echilibrarii dinamice a ıncarcarii, task-urile sunt alocate procesoarelor ın
timpul executiei programului. Echilibrarea poate fi centralizata sau descentralizata.
In primul caz, task-urile sunt remise dintr-o locatie centrala. Exista o structura clara
master-slave, ın care procesul master controleaza direct fiecare proces slave. In al
doilea caz, task-urile sunt pasate ıntre procese arbitrare. O colectie de procese de
lucru opereaza asupra problemei si interactioneaza, raportand ın final unui singur
proces. Un proces poate primi task-uri de la alte procese si poate trimite la randul
sau task-uri altor procese.
20
2.4. Problema echilibrarii ıncarcarii ın proiectarea aplicatiilor paralele
2.4.2.1 Echilibrarea centralizata
In echilibrarea centralizata, procesul master poseda colectia de task-uri care urmeaza
a fi executate. Task-urile sunt trimise proceselor slave. Cand un proces slave termina
un task, el cere un altul de la procesul master. Acest mecanism este trasatura
esentiala a abordarii denumite work-pool. Aceasta tehnica poate fi usor aplicata pro-
blemelor simple de tip divide-and-conquer. Poate fi de asemenea aplicata problemelor
ın care task-urile sunt sensibil diferite si cu dimensiuni inegale. In general, este bine
sa fie trimise mai ıntai task-urile cele mai mari si mai complexe. Daca un task mai
mare este trimis mai tarziu, task-urile mai mici pot fi terminate de catre procesele
slave, care vor sta apoi inactive ın asteptarea terminarii task-ului mai mare.
task
task
Cerere task
Trimitere task
task
task
Procese
slavetask
Task-uri
Proces
Master
(a)
task
task
task
task
task
Task-
uri
Proces M0
Proce
se
slav
e
task
task
task
task
task
Task-
uri
Proce
se
slav
e
Proces Mn-1
task Task-
uri iniţia
le
Proces Master
Trimitere task
Cerere task
(b)
Figura 2.2: Work-pool centralizat (a) si distribuit (b) (adaptare dupa[Wilkinson 99])
Tehnica mai poate fi aplicata cand numarul de task-uri se modifica ın timpul
executiei. In unele aplicatii, mai ales algoritmi de cautare, executia unui task poate
genera noi task-uri, desi ın final numarul task-urilor trebuie sa se reduca la 0, sem-
nalizand terminarea procesului de calcul. Pentru memorarea task-urilor ın asteptare
poate fi folosita o coada, Figura 2.2a. Daca toate task-urile sunt de dimensiune si
importanta egale, poate fi acceptata o coada simpla FIFO. Daca unele task-uri sunt
mai importante decat altele (de exemplu, pot conduce mai repede catre o solutie),
acestea vor fi pasate primelor procese slave. Procesul master poate detine si alte
informatii, cum ar fi solutia optima curenta [Wilkinson 99].
2.4.2.2 Echilibrarea descentralizata
Desi utilizata pe scara larga, echilibrarea centralizata are un dezavantaj semnificativ:
procesul master poate trimite un singur task la un anumit moment, iar dupa ce task-
urile initiale au fost trimise, el poate raspunde la o singura cerere de noi task-uri la un
moment dat. De aici rezulta potentialul unui blocaj, atunci cand exista multe procese
21
2. Metodologii de proiectare a aplicatiilor paralele
slave care pot face simultan cereri. Echilibrarea centralizata este satisfacatoare daca
exista putine procese slave si task-urile sunt intensiv computationale. Pentru task-
uri cu granularitate mai fina si procese slave mai numeroase, este mai potrivita
distribuirea volumului de lucru ın mai multe locatii (Figura 2.2b). Procesul master
divizeaza volumul de lucru initial ın mai multe paarti si trimite fiecare parte unei
multimi de procese ”mini-master” (M0 . . .Mn−1). Fiecare mini-master controleaza
un grup de procese slave. Pentru o problema de optimizare, procesele mini-master
pot gasi un optim local pe care sa-l trimita ınapoi la master si acesta va selecta cea
mai buna solutie. Este clar ca aceasta abordare poate fi dezvoltata astfel ıncat sa
cuprinda mai multe nivele de descompunere; poate fi format un arbore cu procesele
slave ın calitate de frunze iar nodurile interne sa divida volumul de lucru. Acesta este
metoda de baza pentru descompunerea unui task ın sub-task-uri egale. La fiecare
nivel din arbore, procesul paseaza jumatate din task-uri unui sub-arbore si cealalta
jumatate celuilalt sub-arbore, daca avem ın vedere un arbore binar.
O alta abordare distribuita ar fi ca procesele slave sa detina o portiune a volumului
de lucru si sa rezolve problema pentru aceasta [Wilkinson 99]. Odata ce sarcinile sunt
distribuite proceselor, exista posibilitatea ca acestea sa interschimbe task-uri (Figura
2.3). Task-urile pot fi transferate prin:
proces
proces
proces
proces
proces
Cereri taskuri
Figura 2.3: Work-pool descentralizat (adaptare dupa [Wilkinson 99])
• metoda initializarii de catre receptor (receiver-initiated): un proces solicita
task-uri de la alte procese pe care le selecteaza. In general, un proces solicita
task-uri de la alte procese atunci cand are putine sarcini de ındeplinit (sau
nici una). S-a demonstrat ca metoda functioneaza bine la ıncarcari mari ale
sistemului.
• metoda initializarii de catre transmitator (sender-initiated): un proces trimite
task-uri altor procese pe care le selecteaza. Un proces cu o ıncarcare mare
paseaza unele task-uri altor procese care sunt dispuse sa le accepte.
S-a demonstrat ca aceasta metoda este potrivita sistemelor cu ıncarcari reduse. O alta
optiune este combinarea celor doua metode. Din pacate, determinarea ıncarcarilor
proceselor poate fi costisitoare. In sisteme cu ıncarcari foarte mari, echilibrarea
ıncarcarii poate fi de asemenea dificila datorita lipsei proceselor disponibile. Echili-
22
2.4. Problema echilibrarii ıncarcarii ın proiectarea aplicatiilor paralele
brarea ıncarcarii ın contextul metodei initializarii de catre receptor poate fi adaptata
si pentru metoda initializarii de catre transmitator. Fara constrangerile (si avanta-
jele) unui anumit tip de retea, toate procesele sunt candidati egali, care pot selecta
orice alt proces. Pentru operatiile distribuite, fiecare proces trebuie sa aiba propriul
algoritm de selectie ca ın Figura 2.4.
Listă taskuri
Alg
oritm
de
se
lecţie
loca
lă
Alg
oritm
de s
ele
cţie
locală
Listă taskuri
cereri
cereri
Proces Pi
Proces Pj
Figura 2.4: Algoritm de selectie descentralizat (adaptare dupa [Wilkinson 99])
2.4.3 Echilibrarea dinamica a ıncarcarii ın sistemele de agenti mobili
si sisteme message passing
Vom considera o clasa de calculatoare paralele echipate cu o multime finita de proce-
soare omogene interconectate printr-o retea de interconectare directa. Procesoarele
comunica prin transmiterea de mesaje. Canalele de comunicatie se considera full-
duplex, astfel ıncat o pereche de procesoare conectate direct pot primi si trimite
simultan mesaje unul altuia. In continuare este prezentat studiul asupra algorit-
milor SID (Sender Initiated Diffusion) si DASUD (Diffusion Algorithm Searching
Unbalanced Domains) de echilibrare dinamica a ıincarcarii implementati pe o plat-
forma de agenti mobili PASIBC (Platforma Agent pentru dezvoltarea Sistemelor In-
formatice Bazate pe Cunostinte) [Sova 06] si pe un mediu message passing (MPI)
[Sova si Amarandei 04].
Algoritmul SID, propus ın [Willebeek-LeMair 93], porneste de la premisa ca task-
urile sunt infinit divizibile si ıncarcarea unui procesor este reprezentata de un numar
real. Presupunerea este valida ın programele paralele care folosesc paralelismul ın
task-urile cu granularitate mica. Pentru taskurile cu granularitate medie sau mare
algoritmul trebuie sa poata lucra cu taskuri indivizibile. Algoritmul DASUD descris de
[Cortes 98] se bazeaza pe algoritmul SID, care a fost ımbunatatit pentru a ıncorpora
caracteristici noi, care detecteaza daca un domeniu (toti vecinii imediati ai unui
23
2. Metodologii de proiectare a aplicatiilor paralele
procesor) este echilibrat sau nu. Daca domeniul nu este echilibrat, excesul de ıncarcare
este distribuit vecinilor dupa diferite criterii, depinzand de distributia ıncarcarii lor.
In mediile distribuite traditionale programele sunt proiectate astfel ıncat sa ac-
cepte cat mai multi clienti posibili. Procesele client ruleaza de obicei pe calculatoare
aflate la distanta si comunica cu procesele server pentru a-si putea ındeplini sarcinile.
Aceasta abordare poate genera un nivel ridicat de trafic ın retea si, ın functie de
aceasta, pot sa apara ıntarzieri semnificative. Tehnologia agenttilor mobili, prin pro-
cesul de migrare a codului executabil, aduce clientul mai aproape de sursa si astfel
se obtine o reducere majora a traficului necesar. Totusi, ınlocuirea sistemelor client-
server cu agentii mobili nu este ıntotdeauna o idee foarte buna. De exemplu, agentii
mobili trebuie sa transporte cu ei datele, ın timp ce sistemele client-server trimit
datele imediat ınapoi catre client. Astfel, ın cazul sistemelelor client-server, se poate
reduce traficul ın retea. Platforma de agenti mobili descrisa ın [Sova 06] pe care au
fost implementati si testati algoritmii de echilibrare a ıncarcarii este PASIBC imple-
mentata folosind tehnologii .NET. Platformele de agenti mobili au fost interconectate
pentru a forma topologia de tip hipercub, dar sistemul poate fi utilizat ssi ın cazul
altor topologii cum ar fi, de exemplu, topologii inel, stea, mesh sau combinatii ale
acestora.
1 1
1 1
1 1
1 1
S01
S05 S07
S03
S00
S04 S06
S02
S09
S13 S15
S11
S08
S12 S14
S10
1 1
1 1
1 1
1 1 100 tasks
12 9
9 1
12 12
12 8
S01
S05 S07
S03
S00
S04 S06
S02
S09
S13 S15
S11
S08
S12 S14
S10
9 1
2 1
12 8
8 1
(a)
1 1
1 1
1 1
1 1
S01
S05 S07
S03
S00
S04 S06
S02
S09
S13 S15
S11
S08
S12 S14
S10
1 1
1 1
1 1
1 1 100 tasks
8 8
7 7
8 8
8 7
S01
S05 S07
S03
S00
S04 S06
S02
S09
S13 S15
S11
S08
S12 S14
S10
8 1
7 7
8 9
7 8
(b)
Figura 2.5: Echilibrarea ıncarcarii pe o topologie de tip hipercub (n=4)folosind platforma PASIBC -Agenti de echilibrare SID (a) si DASUD (b)[Sova si Amarandei 04]
In cadrul simularii pe topologia de tip hipercub cu 4 dimensiuni au fost injectate
100 de unitati de ıncarcare ın nodul S00. O unitate de ıncarcare este de fapt un agent
mobil ce poate migra ıntre diferite platforme, iar injectarea unitatilor de ıncarcare
consta ın crearea agentilor task. Injectarea task-urilor poate fi facuta ın orice moment,
ın orice nod al sistemului si ın oricate noduri. Pentru topologia hipercub am ales nodul
S00, deoarece alegerea oricarui alt nod nu ar fi influentat complexitatea situatiei.
Migrarea unui astfel de agent este initiata de catre platforma agent pe care rezida
24
2.4. Problema echilibrarii ıncarcarii ın proiectarea aplicatiilor paralele
acesta. Fiecare platforma PASIBC dispune de un agent de echilibrare a ıncarcarii
astfel ıncat, la nivelul nodului S00, avem 101 agenti ce trebuie distribuiti ın cadrul
sistemului ca ın Figurile 2.5a si 2.5b. Suplimentar am ales cazul, defavorabil, ın care
este supraıncarcat nodul S00 cu 100 si respectiv 150 task-uri.
Pentru testarea implementarii algoritmilor de echilibrare a ıncarcarii SID si DA-
SUD folosind MPI s-a folosit acelasi set de date initiale (ıncarcarea initiala) ca cel de
la platforma PASIBC, rezultatele fiind prezentate ın Figurile 2.6a si 2.6b.
1 1
1 1
1 1
1 1
S01
S05 S07
S03
S00
S04 S06
S02
S09
S13 S15
S11
S08
S12 S14
S10
1 1
1 1
1 1
1 1 100 tasks
11 11
7 7
13 7
11 4
S01
S05 S07
S03
S00
S04 S06
S02
S09
S13 S15
S11
S08
S12 S14
S10
4 4
7 7
7 1
11 4
(a)
1 1
1 1
1 1
1 1
S01
S05 S07
S03
S00
S04 S06
S02
S09
S13 S15
S11
S08
S12 S14
S10
1 1
1 1
1 1
1 1 100 tasks
7 8
7 7
8 7
8 7
S01
S05 S07
S03
S00
S04 S06
S02
S09
S13 S15
S11
S08
S12 S14
S10
7 7
7 7
8 6
8 7
(b)
Figura 2.6: Echilibrarea ıncarcarii pe o topologie de tip hipercub (n=4) folosindMPI - Algoritm de echilibrare SID (a) si DASUD (b) [Sova si Amarandei 04]
2.4.4 Rezultate
Din rezultatele obtinute ın cazul echilibrarii ıncarcarii pe platforma de agenti mobili si
pe sistemul de tip message-passing se observa ca ın cazul algoritmului SID se obtine
doar o echilibrare locala iar sistemul pe ansamblu este dezechilibrat. O ımbunatatire
substantiala se observa ın cazul utilizarii algoritmului DASUD - o echilibrare locala si
globala. Totusi, ın ambele cazuri apar probleme (dezechilibre) din cauza configuratiei
hardware si software pe care au fost facute testele - incompatibilitati cu software-ul
instalat. Testele efectuate cu platforma PASIBC a fost rulate pe o retea alcatuita
din statii cu WindowsXP, iar testele folosind MPI au fost rulate pe un cluster Linux.
Implementarea algoritmilor fiind aproximativ aceeasi, diferenta apare datorita modului
ın care sunt implementate cele 2 sisteme de test. Mai exact, varianta de MPI ce
ruleaza pe Linux beneficiaza de modul de lucru cu procese al acestui sistem de operare;
ın timp ce platforma PASIBC fiind implementata folosind platforma .NET, nu a fost
posibila folosirea acelorasi mecanisme de comunicatii [Sova si Amarandei 04].
Pe de alta parte, utilizarea platformelor de agenti mobili ofera urmatoarele avan-
taje [Teodoru si Amarandei 07]:
25
2. Metodologii de proiectare a aplicatiilor paralele
Figura 2.7: Rezultatele algoritmilor SID si DASUD cu primul set de date[Sova si Amarandei 04]
• reducerea traficului pe retea – numai codul agentului si datele finale sunt mutate
de pe un nod pe altul, nu si datele intermediare.
• adaptabilitate – agentii mobili au abilitatea de a-si schimba comportamentul
functie de mediul ın care ruleaza.
• robustete si toleranta la defecte – platformele de agenti mobili sunt mult mai
robute decat alte modele de sisteme distribuite. Daca o platforma se de-
fecteaza, alta poate prelua agentii cu task-urile aferente.
• arhitectura distribuita si flexibila – sistemele de agenti mobili sunt foarte flexibile
datorita posibilitatii de migrare a codului.
Performantele sistemelor distribuite ce utilizeaza agenti mobili pot fi crescute prin
utilizarea algoritmilor de echilibrare a ıncarcarii, datorita faptului ca agentii pot utiliza
mai bine puterea de procesare a sistemului [Teodoru si Amarandei 07].
26
2.4. Problema echilibrarii ıncarcarii ın proiectarea aplicatiilor paralele
Figura 2.8: Rezultatele algoritmilor SID si DASUD cu al doilea set de date[Sova si Amarandei 04]
Figura 2.9: Rezultatele algoritmilor SID si DASUD cu al treilea set de date[Sova si Amarandei 04]
27
Capitolul 3
Model de proiectare a aplicatiilor
paralele folosind proiectarea
statistica a experimentelor
Suportul disponibil pentru rularea aplicatiilor paralele (sistemele multicore, hyper-
threading, GPU etc.) precum si arhitecturile ın care sunt integrate (sisteme paralele,
distribuite etc.) sunt din ce ın ce mai complexe. Acest lucru face deosebit de dificila
construirea de modele analitice care sa permita studiul performantelor unei aplicatii
sau predictia acestora. Prin urmare se ridica problema validarii aplicatiilor paralele
propuse ca solutii pentru rezolvarea problemelor din diverse domenii. Precum ın cazul
altor domenii stiintifice, raspunsul ıl constitue validarea prin experimente. Cu toate
acestea, experimentele ın domeniul stiintei calculatoarelor este un subiect ce ridica
mai multe probleme deca rezolva: Ce poate valida un experiment? Ce reprezinta
un ”experiment bine realizat”? Cum se poate construi un mediu experimental ce
permite realizarea unui ”experiment bun”? Cum se poate realiza acest lucru ın cazul
calculului de mare performanta? [Gustedt 09].
Realizarea unei aplicatii paralele presupune si analiza parametrilor cantitativi si
calitativi ce o descriu: timpi de raspuns, scalabilitate etc. Acest lucru se transpune
ın realizarea unor teste de performanta pe baza carora se pot trage concluzii privind
modul ın care a fost proiectata si implementata aplicatia ın cauza. Proiectarea apli-
catiilor paralele conform [Foster 95] si [Quinn 04] presupune patru etape: partiti-
onarea datelor, definirea comunicatiilor, aglomerarea si maparea. Chiar daca acest
model este urmarit cu atentie ın faza de proiectare, aplicatia rezultata nu functioneaza
la parametrii de performanta asteptati. Acest lucru este posibil nu numai datorita
unor verificari superficiale ale cerintelor suplimentare propuse de Foster, cat datorita
conditiilor ın care ruleaza aplicatia. Pentru a depasi aceste neajunsuri este definit un
29
3. Model de proiectare a aplicatiilor paralele folosindproiectarea statistica a experimentelor
model analitic de investigare a performantei, model bazat pe metoda de proiectare
descrisa ın capitolul anterior.
Abordarile eficiente din punct de vedere al costurilor se obtin rareori avand baze
exclusiv teoretice. Acest lucru se datoreaza nevoii de flexibilitate si de usurinta ın
mentenanta software-ului pe de o parte si datorita complexitatii sistemelor de calcul
paralel, pe de alta parte. Datorita numarului mare de strategii de proiectare si a
posibililor factori ce le influenteaza, studiile experimentale trebuie realizate tinand
cont de urmatoarele [Amarandei 11]:
• factorii ce influenteaza anumite metrici de performanta;
• existenta interactiunilor dintre acesti factori;
• cuantificarea efectului fiecarui factor si a interatiunilor dintre acestia;
• valorile pentru care factorii furnizeaza raspunsul optim;
• limitarile impuse de conditiile de rulare asupra aplicatiei.
Un factor important, care adesea nu este luat ın considerare, este faptul ca pe un
anumit cluster nu ruleaza, ın mod uzual, o singura aplicatie paralela. Astfel, ın functie
de datele transferate ıntre noduri la un moment dat, gradul de ocupare al retelei
interne a clusterului este diferit. De asemenea, utilizarea clusterului poate fi rezervata
pentru mai multe scopuri (de exemplu academice, de cercetare sau comerciale). O
aplicatie proiectata fara a tine cont de acesti factori poate avea variatii drastice
de performanta. In timpul proiectarii nu se poate cunoaste cu exactitate pentru ce
dimensiuni ale problemei va fi rulata aplicatia de catre beneficiar. Astfel, ın cazurile ın
care proiectarea aplicatiilor paralele se realizeaza folosind descompunerea domeniului,
datele sunt separate ın blocuri distincte ce pot fi procesate separat. Dupa stabilirea
modului de partitionare a domeniului de date este necesara definirea comunicatiilor,
sarcina ce poate reprezenta o adevarata provocare.
Pentru a veni ın sprijinul proiectantului se poate dezvolta un model statistic al
aplicatiei. Utilizand acest model, dupa implementarea unui prototip al aplicatiei,
proiectantul trebuie sa poata urmari evolutia parametrilor de calitate ai aplicatiei si
sa poata identifica mai usor eventualele erori.
In realizarea testelor, ın mod deliberat sunt schimbate una sau mai multe variabile
(factori) pentru a observa efectul pe care aceste schimbari ıl au asupra raspunsului.
Tehnica proiectarii statistice a experimentelor (Design of experiments – DOE)
reprezinta o metoda eficienta de planificare a testelor astfel ıncat rezultatele obtinute
pot fi analizate pentru a trage concluzii valide si obiective [NIST/SEMATECH 06].
Metodologia DOE poate fi aplicata cu succes ın cazurile de tip blackbox, atunci
cand se cauta optimizarea unei caracteristici de calitate (raspuns al sistemului) prin
reglarea factorilor de intrare. Datele de intrare sunt cunoscute ın literatura de spe-
cialitate cu numele de factori/variabile care pot fi cunoscuti sau controlati. Pot exista
ınsa si factori care influenteaza sistemul, dar care nu pot fi gestionati, fiind o sursa de
incertitudine – se numesc ın mod uzual factori necunoscuti sau necontrolati. Datele
de iesire ale sistemului se numesc raspunsuri sau variabile de iesire care sunt de fapt
30
caracteristici de calitate ce urmeaza a fi studiate si optimizate.
Un plan experimental este o schema de realizare a experimentelor prin care
[Isaic-Maniu 06]:
• sunt organizate, desfasurate si executate experimentele;
• sunt culese si ınregistrate datele de observatie si felul ın care sunt raportate aces-
tea, astfel ıncat sa se poata investiga influenta factorilor controlati asupra vari-
abilei de interes, estimand cantitativ si calitativ magnitudinea acestei influente
si stabilind care dintre factorii controlati au o importanta deosebita;
• sunt decantate sursele de variabilitate prezente ın datele stranse – cea destinata
factorilor controlati si cea atribuita variatiilor aleatoare provenite din actiunea
factorilor necontrolati.
Realizarea planului experimental ıncepe cu determinarea obiectivelor unui experiment
si selectarea factorilor ce vor fi studiati.
Un plan experimental bine ales maximizeaza cuantumul de informatii care poate fi
obtinut pentru un anumit efort depus ın realizarea experimentului. Trebuie precizat
ca se evita folosirea termenului de ”planificare” a experimentului, deoarece nu se
planifica nimic ın sensul de a obtine ceva dinainte scontat. ”Planificarea” nu se refera
decat la conditiile ın care se desfasoara experimentul, pentru a asigura obiectivitatea
acestuia [Isaic-Maniu 06].
Analiza statistica folosind planul experimental ofera o cale de a determina ce con-
figuratie specifica trebuie simulata pentru ca informatiile dorite sa fie obtinute dupa
un numar redus de simulari [Law 99]. Suplimentar, planul experimental realizat si
analizat corespunzator: (1) faciliteaza identificarea efectului factorilor (variabilelor)
care pot determina modifiari ale performantei; si (2) ajuta ın a determina daca un
anumit factor are efect semnificativ sau daca diferentele observate sunt rezultatul
unor erori aleatorii rezultate din masuratori si din paramatri ce nu pot fi controlati
[Jain 91].
Ruthruff, ın [Ruthruff 06], arata ca utilizarea tehnicii planului experimental poate
ajuta cercetatorii si dezvoltatorii de software sa identifice limitarile tehnicilor de
analiza, sa ımbunatateasca tehnicile de analiza experimentala existente si sa creeze
noi tehnici de analiza a programelor. Aceste tehnici pot fi capabile sa creioneze
concluzii despre proprietatile sistemelor software ın cazul ın care utilizarea metodelor
traditionale nu are succes [Ruthruff 06].
De exemplu, ın [Rao 08], tehnica planului experimental este utilizata pentru
testarea performantelor masinii virtuale Java pe sisteme embedded. Autorii con-
struiesc un model de regresie care utilizeaza relatii ıntre parametrii de performanta
ai masinii virtuale Java cu diverse metrici corespunzatoare arhitecturilor embedded.
Modelul dezvoltat este usor de interpretat si precizia este apropiata de erorile de
masurare. Prin aceasta metoda, proiectantul aplicatiilor este sfatuit sa modifice
parametrii masinii virtuale Java pentru a obtine performantele optime.
Utilizarea metodei de proiectare statistica a experimentelor ın proiectarea aplicati-
31
3. Model de proiectare a aplicatiilor paralele folosindproiectarea statistica a experimentelor
ilor secventiale reprezinta o buna politica de selectare a componentelor unei aplicatii,
ce ofera cele mai bune rezultate pentru o anumita problema. O astfel de abordare este
descrisa ın [Stewardson 02] pentru selectarea unui numar redus de combinatii de algo-
ritmi genetici pentru rezolvarea problemelor de planificare. Deoarece selectia trebuie
sa acopere ın egala masura fiecare tip de parametru si combinatiile acestora, autorii
utilizeaza metoda planului experimental pe post de metoda de reducere a incertitu-
dinii si complexitatii. Tehnica planului experimental este utilizata si ın [Ridge 07],
unde este construit un model predictiv al performantelor ce combina tehnicile euristice
de optimizare asupra unui set de parametri si caracteristicile problemei studiate. Alte
abordari statistice de analiza a performantelor aplicatiilor paralele au fost propuse
recent de [Zheng 10], [Barnes 08] si [Whiting 04].
Analiza comportamentului unui program prin intermediul paradigmelor de design
experimental poate ajuta cercetatorii si dezvoltatorii de aplicatii sa identifice limitarile
tehnicilor de analiza, sa ımbunatateasca modelul si sa creeze noi tehnici de analiza.
Aceste tehnici sunt capabile sa creeze o imagine asupra proprietatilor sistemului
ın cazurile ın care tehnicile traditionale esueaza [Ruthruff 06].
Un numar semnificativ de factori si strategii de proiectare conduc la numeroase
ıntrebari: Care factori influenteaza o anumita metrica de performanta? Exista in-
teractiuni ıntre factori? Este posibila cuantificarea efectului fiecarui factor si a
interactiunilor dintre acestia? Daca da, modificarea carui factor furnizeaza per-
formante maxime si care este comportamentul acestora? Aceste modificari impun
limitari pentru programe?
Avantajele utilizarii tehnicilor statistice bazate pe DOE sunt semnificative. Un
plan experimental bine construit permite proiectantilor de aplicatii sa obtina maximum
de informatii cu un numar minim de experimente [Totaro 05]. Planul experimental
ofera o metoda de indentificare a configuratiilor specifice de simulare ınaintea rularii
efective. Astfel, informatiile dorite sunt obtinute cu un numar minim de simulari
[Jain 91].
Tehnici detaliate de folosire a DOE si de construire a modelelor empirice se pot
gasi ın detaliu ın [Box 78], [Jain 91], [Montgomery 06] si [Kleijnen 04]. Cateva idei
si metodologii de investigare empirica ce pot fi utilizate ın ingineria software sunt
prezentate ın [Kitchenham 02] si in [Ivan 04].
3.1 Modelul propus pentru ımbunatatirea proiectarii apli-
catiilor paralele
In continuare este prezentat un model de analiza si verificare a unei aplicatii para-
lele. Modelul ia ın considerare factorii ce pot influenta comportamentul aplicatiei,
furnizand indicii asupra erorilor ce pot apare ın etapele de proiectare. Este prezentata
modalitatea ın care strategiile statistice bazate pe DOE pot fi folosite pentru analiza
performantelor unei aplicatii paralele ın scopul de a trage concluzii obiective privind
32
3.1. Modelul propus pentru ımbunatatirea proiectarii apli-catiilor paralele
erorile de proiectare. De asemenea, se pot obtine informatii legate de conditiile de
rulare pe baza parametrilor de performanta luati ın considerare.
Modelul propus ın [Amarandei 11] pentru proiectarea aplicatiilor paralele pre-
supune parcurgerea a trei etape (Figura 3.1).
Astfel prima etapa reprezinta pasii clasici de proiectare a unei aplicatii paralele,
pasi descrisi ın [Foster 95] si [Quinn 04]. Conform acestui model, la sfarsitul fiecarei
etape, proiectantul unei aplicatii paralele trebuie sa analizeze rezultatul obtinut printr-
o serie de verificari. Rezultatul acestei etape ıl reprezinta prototipul aplicatiei par-
alele sau a algoritmului paralel. Cu acest prototip se fac masuratori legate de
functionalitatea si performantele aplicatiei: timpii de procesare, timpii de comunicatie,
cantitatea de date transferata ıntre procese, etc.
Etapa 2:
Analiza statistică bazată pe DOE
Etapa 1:
Proiectarea aplicaţiei paralele
Partiţionarea
problemei
Proiectarea
comunicaţiilor
Aglomerarea
Maparea
pe procesoare
Definirea planului
experimental
Rularea prototipului
aplicaţiei
Analiza statistică
NU Rezultatele sunt satisfăcătoare?
Etapa 3:
Implementarea soluţiei
DA
Figura 3.1: Modelul de proiectare al aplicatiilor paralele utilizand DoE[Amarandei 11]
Dupa proiectarea aplicatiei paralele, un rol important ıl au modelele de perfor-
manta descrise ın [Foster 95] si mai pe larg ın sectiunea 2.3. Informatii importante
pot fi obtinute prin compararea datelor masurate si a celor prezise. Aceste valori
sunt rareori identice datorita gradului de idealizare utilizat ın timpul proiectarii. Daca
sunt discrepante majore, acestea apar fie datorita modelului incorect, fie datorita
implementarii defectuoase. In cazul unui model incorect, rezultatele empirice pot fi
utilizate pentru a determina deficientele modelului si a reevalua compromisurile facute
pentru a justifica deciziile de proiectare. In al doilea caz, putem utiliza modelul pentru
a identifica unde anume poate fi ımbunatatita implementarea.
Etapa a doua presupune realizarea unui plan experimental cu efectuarea expe-
rimentelor, analiza statistica si interpretarea rezultatelor. Analiza statistica poate
furniza informatii legate de performantele aplicatiei si pot ajuta la eliminarea factorilor
care nu au o influenta directa. De asemenea, asa cum se va indica ın continuare, se
poate realiza modelul aplicatiei pe baza setului de date obtinut, precum si o predictie
33
3. Model de proiectare a aplicatiilor paralele folosindproiectarea statistica a experimentelor
asupra valorilor variabilelor raspuns pe baza factorilor de intrare considerati.
Primele doua etape sunt reiterate pana cand rezultatele experimentale valideaza
metricile de performanta impuse. In acest punct se poate trece la ultima etapa si
anume implementarea solutiei.
Astfel, cu ajutorul acestui model se poate raspunde la ıntrebarile de verificare
descrise ın [Quinn 04] si se pot face aprecieri asupra dimensiunii datelor transfer-
ate functie de parametrii de intrare asa cum se va arata ın studiul de caz de mai
jos. In cadrul acestei analizei statistice, daca informatiile obtinute nu sunt sat-
isfacatoare, se pot lua decizii de refacere a unei etape de proiectare a aplicatiei:
de exemplu comunicatiile sunt corecte, dar partitionarea datelor nu este bine facuta,
etc [Amarandei 11].
Pentru verificarea modelului au fost realizate urmatoarele etape: realizarea unei
aplicatii paralele ce utilizeaza tehnica descompunerii domeniului de date (domain
decomposition), realizarea unui plan experimental de tip multifactorial pentru anal-
iza performantelor aplicatiei, interpretarea rezultatelor din ANOVA si din analiza de
regresie pentru identificarea unor eventuale erori de proiectare.
3.1.1 Analiza unei aplicatii paralele folosind modelul propus
Utilizand analiza statistica a datelor obtinute ın urma simularilor, prin intermediul
ANOVA, cercetatorii pot identifica efectele produse de factorii de intrare precum
si interactiunea dintre acestia pentru a explica metricile de performanta [Totaro 05].
Pasii care trebuie urmati pentru realizarea experimentului sunt urmatorii [Amarandei 11]:
1. Definirea obiectivelor: Scopul acestui model este demonstrarea eficientei
strategiei bazate pe DOE ın evaluarea performantelor unei aplicatii paralele
si identificarea erorilor de proiectare. Pentru atingerea acestui scop, obiec-
tivele specifice sunt cuantificarea efectelor unor potentiali factori ce influenteaza
performantele unei aplicatii paralele. Utilizand aceste efecte, se dezvolta un
model empiric, ce poate fi folosit pentru a prezice performantele aplicatiei pa-
ralele ın momentul rularii cu date de intrare diferite de cele examinate.
2. Selectarea factorilor de intrare: Pasul urmator ın realizarea planului experi-
mental este selectia factorilor de intrare potentiali ce pot influenta performan-
tele aplicatiei paralele.
3. Selectarea viariabilelor raspuns: Dupa alegerea factorilor de intrare, functie
de obiectivele urmarite sunt selectate variabilele raspuns – ca de exemplu timpul
de procesare sau timpul de comunicatie.
4. Selectarea metodei de analiza: Exista libertate deplina ın a alege o metoa de
analiza ın functie de numarul factorilor si de obiectivele urmarite (Tabelul 3.1),
motivarea alegerii si metodele disponibile nu fac obiectul acestei teze, fiind
prezentate pe larg ın [NIST/SEMATECH 06]. Pentru simplitatea calculelor,
este utilizata o codare a factorilor folosind, de obicei, valori +/- sau 0/1.
34
3.1. Modelul propus pentru ımbunatatirea proiectarii apli-catiilor paralele
5. Rularea aplicatiei si colectarea datelor: In acest pas se efectueaza testarea
aplicatiei. In functie de numarul factorilor de intrare, aplicatia trebuie rulata
de n ori (la fiecare rulare pentru factorii de intrare trebuie utilizate valorile din
planul experimental si adunate rezultatele.
6. Analiza statistica: In acest pas, se analizeaza efectele principale si cele de
interactiune. Efectele principale sunt modificarile asupra unei variabile raspuns
la variatia unui factor de intrare. Efectele de interactiune sunt efectele com-
binate ale factorilor de intrare asupra unei variabile raspuns. Dupa rularea
aplicatiei, pentru setul de date de intrare ales, se analizeaza influenta acestora
asupra raspunsului urmarit.
7. Construirea modelului empiric pentru raspunsurile considerate: Dupa ru-
larea aplicatiei utilizand factorii de intrare selectati, se analizeaza influenta
acestora asupra variabilelor raspuns. Se construieste un model empiric pe baza
datelor obtinute utilizand metoda planului experimental. Pasii ce trebuie urmati
sunt urmatorii: selectia modelului, ajustarea si validarea acestuia. Acesti trei
pasi sunt utilizati iterativ pana cand se obtine un model cat mai apropiat de
rezultatele obtinute. In etapa de selectie a modelului, efectele factorilor si a
interactiunilor dintre acestia sunt determinate din tabelul ANOVA pentru a afla
modul ın care modelul poate fi adaptat la date. Dupa acest pas, folosind mod-
elul selectat si datele disponibile, se verifica daca acest model descrie cat mai
bine posibil parametrii necunoscuti ai modelului. Dupa estimarea parametrilor,
modelul este evaluat pentru a afla daca nu cumva presupunerile facute pe
parcursul analizei sunt plauzibile. Daca se dovedeste ca presupunerile sunt
corecte, modelul poate fi folosit pentru a raspunde ıntrebarilor care au dus la
realizarea lui. Daca pe parcursul validarii modelului sunt descoperite probleme,
se repeta etapele parcurse folosind informatiile deja obtinute pentru a selecta
si/sau adapta un model ımbunatatit.
8. Interpretarea rezultatelor: In aceasta ultima etapa se coreleaza efectele facto-
rilor de intrarea considerati cu analiza variabilelor raspuns ale aplicatiei paralele
pentru a valida sau invalida modelul aplicatiei rezultat din analiza statistica ın
functie de restrictiile impuse asupra parametrilor de performanta.
Dupa analiza statistica asupra factorilor ce influenteaza variabilele raspuns se
construieste un model empiric pe baza datelor colectate utilizand diverse modele
de tip regresie descrise pe larg ın [NIST/SEMATECH 06]. Acest model defineste
relatia functionala ıntre factorii de intrare si metricile de performanta urmarite. Pe
baza acestui model se pot face optimizari asupra modelului, se pot calcula si estima
performantele aplicatiei.
35
3. Model de proiectare a aplicatiilor paralele folosindproiectarea statistica a experimentelor
3.2 Analiza cu DOE a unei aplicatii paralele ce utilizeaza
metoda descompunerii domeniului de date: sort last
parallel rendering
Pentru a demonstra utililtatea modelului propus vom analiza o aplicatie de randare
paralela. Sinteza unei imagini 3D este o operatiune complexa, care se desfasoara ın
doua etape mari: procesarea geometriei (transformari, decupari, iluminare etc.) si
rasterizarea (transformarea de rastru - umbrire, determinarea vizibilitatii). Procesarea
geometriei este de obicei paralelizata prin asignarea fiecarui procesor a unui subset din
primitivele grafice (obiecte) din scena. Rasterizarea este paralelizata prin asignarea
fiecarui procesor a unei portiuni din calculele pixelilor.
Esenta sarcinii de randare o reprezinta calcularea efectului fiecarei primitive asupra
fiecarui pixel. Datorita naturii arbitrare a transformarilor de modelare si vizualizare,
o primitiva se poate afla oriunde ın spatiul ecran (sau ın afara lui). Din acest motiv
randarea poate fi privita ca o problema de sortare a primitivelor pe ecran [Molnar 08].
Pentru sisteme complet paralele aceasta sortare implica o redistributie a datelor ıntre
procesoare, deoarece responsabilitatea pentru fiecare primitiva si fiecare pixel este
distribuita.
Proces masterDistribuţie task-uri (NP/n)
Date de intrare (NP)
IM2 IM3 IMnIM1
WP1 WP2 WP3 WPn
Procesare
date
Procesare
date
Procesare
date
Procesare
date
Proces masterAdună rezultatele şi
compune imaginea finală Imaginea finală
Legendă:
WPi – procese worker
NP – dimesciunea datelor de intrare
IMi – imaginea procesată de workerul i
Figura 3.2: Aplicatia paralela de randare a unei imagini [Amarandei 11]
In randarea paralela de tip sortare-dupa, cunoscuta si sub numele de randare
paralela ın spatiul obiect, fiecare nod de procesare este responsabil cu randarea unui
bloc de date, indiferent daca acestea sunt sau nu vizibile la momentul respectiv
(Figura 3.2).
Aplicatia paralela analizata implementeaza modelul de randare paralela sortare-
dupa utilizand modelul de programare message passing. Implementarea aplicatiei
paralele urmareste modelul descris ın Figura 2.1. De aici, utilitatea modelului pro-
pus ın subcapitolul anterior este imediata. Aplicatia poate suferi dezechilibre ale
36
3.2. Analiza cu DOE a unei aplicatii paralele ce utilizeaza metodadescompunerii domeniului de date: sort last parallel rendering
sarcinilor de randare, si din acest motiv se preteaza analizei utilizand modelul propus.
Scopul acestei analize este extragerea de informatii despre performantele aplicatiei si
identificarea eventualelor erori de proiectare si/sau de implementare.
3.2.1 Planul experimental
Deoarece obiectivul nostru este ilustrarea eficientei metodei de analiza statistica
bazata pe DOE, sunt selectati doar trei factori: dimensiunea datelor de intrare (X1),
dimensiunea imaginii finale (X2) si numarul de procesoare (X3). Valorile pe care le
pot lua acesti factori sunt date ın tabelul 3.1 [Amarandei 11]:
Denumire Codificare Valoare minima Valoare maxima
Nr. puncte X1 100000 4000000
Rezolutia imaginii X2 480000 50000000
Nr. procesoare X3 6 8
Tabelul 3.1: Factorii de intrare [Amarandei 11]
Consideram urmatoarele variabile raspuns pentru aplicatie: dimensiunea datelor
schimbate ıntre procese (Y1), timpul de procesare (Y2) si timpul de comunicatii (Y3).
Pentru analiza vom utiliza un plan multifactorial (full factorial) pe doua niveluri.
Pentru simplitatea calculelor, este utilizata o codare a factorilor folosind valori de 0
si 1.
rulare X1 X2 X3
1 0 0 0
2 1 0 0
3 0 1 0
4 1 1 0
5 0 0 1
6 1 0 1
7 0 1 1
8 1 1 1
Tabelul 3.2: Planul experimental codificat [Amarandei 11]
Mediul de testare a aplicatiei consta ıntr-un cluster al gridului GRAI ( descris ın
capitolul 4.3) avand urmatoarea configuratie: front-end cu procesoare 4 x 3.66 GHz
Intel Xeon, 4 x 146 GB discuri si 8GB RAM ; 12 computing nodes cu 1 x 2.33GHz Intel
Core2 Duo CPU, 1 x 160GB disk, 2GB RAM interconectate folosind placi de retea
Gigabit Ethernet si cabluri CAT6 prin intermediului unui switch Gigabit. Aplicatia
este scrisa in C++ iar paralelismul (vezi Figura 3.2 si [Molnar 08]) este obtinut prin
utilizarea implementarii LAM 7.1.2/7.1.4 a standardului MPI-2. Chiar daca randarea
este un proces de apel invers, ın cazul nostru este urmarita posibilitatea de a analiza
37
3. Model de proiectare a aplicatiilor paralele folosindproiectarea statistica a experimentelor
Y1 Y2 Y37500 2.40813 0.661006
7500 20.8237 2.288
781250 177.86 65.7456
781250 199.783 66.1748
7500 3.02641 0.880815
7500 21.7683 2.55107
781250 243.713 89.9857
781250 264.943 90.3144
Tabelul 3.3: Valorile furnizate de aplicatie pentru variabilele raspuns urmariteconform planului experimental [Amarandei 11]
comportamentul aplicatiei la producerea unor imagini foarte mari utilizand dimensiuni
foarte mari ale setului de date.
Dupa rularea aplicatiei, pentru setul de date de intrare ales, se analizeaza influenta
acestora asupra raspunsului urmarit, ın cazul de fata timpul de comunicatii, timpul de
procesare si dimensiunea datelor interschimbate, asa cum se va prezenta ın continuare.
3.2.2 Analiza statistica a modelului
Pentru analiza statistica a modelului au fost realizate Tabelele ANOVA pentru cazul
cu planul multifactorial pe doua niveluri descris anterior. Pentru acest plan tabelele
ANOVA au fost calculate utillizand instrumentele statistice puse la dispozitie de
mediul Matlab.
In urma rularii aplicatiei paralele pe un numar variabil de procesoare (6 si 8 ın
cazul de fata), s-a constatat ca raspunsul Y1 (volumul de date transferat de aplicatie)
depinde doar de factorul X2 (rezolutia imaginii finale) iar factorul X1 nu are nici o
influenta (Tabloul ANOVA din Tabelul 3.4 - confirma observatia). Este important de
remarcat faptul ca acest comportament este consistent cu analiza metodei de randare
paralela din [Molnar 08].
Source Sum sq. d.f. Mean Sq. F Prob > F
X1 0.0005 1 0.0005 0 0.5X2 1.19738E+12 1 1.19738E+12 2.45223E+15 1.34E-8X3 -0.0005 1 -0.0005 -1 1X1X2 -0.0005 1 -0.0005 -1 1X1X3 -0.0005 1 -0.0005 -1 1X2X3 -0.0005 1 -0.0005 -1 1Error 0.0005 1 0.0005Total 1.19738E+12 7
Tabelul 3.4: Tabelul ANOVA pentru raspunsul Y1 [Amarandei 11]
38
3.2. Analiza cu DOE a unei aplicatii paralele ce utilizeaza metodadescompunerii domeniului de date: sort last parallel rendering
Source Sum sq. d.f. Mean Sq. F Prob > F
X1 806.2 1 806.2 6207.59 0.0081X2 87837.6 1 87837.6 676315.45 0.0008X3 2197 1 2197 16916.4 0.0049X1X2 4.5 1 4.5 34.6 0.1072X1X3 0.0168 1 0.0168 0.13 0.7802X2X3 2094.7 1 2094.7 16128.12 0.005Error 0.1298 1 0.1298Total 92940.2 7
Tabelul 3.5: Tabelul ANOVA pentru raspunsul Y2 [Amarandei 11]
Source Sum sq. d.f. Mean Sq. F Prob > F
X1 2.1 1 2.1 795.67 0.0226X2 11692.2 1 11692.2 4525903.49 0.0003X3 298.4 1 298.4 115523.57 0.0019X1X2 0.8 1 0.8 312.01 0.036X1X3 0.00004 1 0.00004 0.16 0.7588X2X3 286.8 1 286.8 111002.1 0.0019Error 0.0026 1 0.0026Total 12280.3 7
Tabelul 3.6: Tabelul ANOVA pentru raspunsul Y3 [Amarandei 11]
Metoda analizei variantei (ANOVA) este utilizata pentru a testa ipotezele cu
privire la influenta factorilor considerati X1, X2, X3 si a interactiunii lor ( X1X2,
X1X3 si X2X3) asupra raspunsului. In exemplul considerat, sunt sase ipoteze ce
trebuie testate pentru fiecare raspuns: daca efectul factorilor X1, X2, X3 este sau nu
semnificativ pentru variatia raspunsului; daca interactiunea acestora X1X2, X1X3,
X2X3 este sau nu prezenta. De exemplu, pentru efectul factorului X1, ipoteza nula
reprezinta faptul ca nu este suficienta variatie a raspunsului indiferent daca setul
de date de intrare are 100000 sau 4000000 puncte. Pentru efectul interactiunilor,
ipoteza nula semnifica faptul ca cei doi factori sunt independenti. O modalitate
de a prezenta rezultatul testului asupra ipotezei este de a specifica daca rezultatul
ipotezei nule este sau nu respins la o valoare specificata a P − value sau la un nivel
de importanta. Campul P − value (ultima coloana din Tabelul 3.3) este cel mai mic
nivel de semnificatie ce duce la respingerea ipotezei nule. Daca orice P-value este
aproape zero, ridica ındoieli asupra ipotezei nule asociate, adica, exista influenta din
partea acelui factor. Pentru a determina daca un rezultat este semnificativ din punct
de vedere statistic, trebuie alese limite pentru valoare lui P −value. In mod uzual se
considera semnificativ un rezultat daca P − value este mai mic decat 0.05 sau 0.01
[Montgomery 06].
39
3. Model de proiectare a aplicatiilor paralele folosindproiectarea statistica a experimentelor
3.2.2.1 Analiza volumului de date procesat
Rezultatele obtinute la rularea aplicatiei paralele pe 6 si 8 procesoare arata faptul
ca raspunsul Y1 depinde doar de factorul X2 (dimensiunea finala a imaginii), ın
timp ce factorii X1 si X3 nu au influenta asupra acestei variabile raspuns. Tabelul
ANOVA anterior (Tabelul 3.4) confirma aceasta observatie: ipoteza nula H0 : β2 = 0
este respinsa. Este important de precizat ca acest comportament este consistent cu
analiza metodei de randare furnizata de [Molnar 08]. Urmarind aceste observatii,
putem deduce ca Y1 este dependent liniar de factorul X2, si poate fi definit astfel:
Y1 = β0 + β2x2 + ε , (3.2.1)
unde ε este eroarea experimentala, iar β0 si β2 pot fi determinate folosind valorile
din Tabelul 3.1, 3.2 si 3.3 ca intrari pentru factorul X2 si valorile corespunzatoare
pentru raspunsul Y1. Se obtin urmatoarele valori pentru coeficientii ecuatiei 3.2.1:{β0 = 0
β2 = 0.15625 ,(3.2.2)
ceea ce duce la urmatoarea forma a ecuatiei pentru descrierea comportamentului
raspunsului Y1:
Y1 = 0.15625 x2 , (3.2.3)
unde x2 reprezinta numarul de puncte din imaginea finala.
Astfel, asa cum era de asteptat, volumul de date tansferat este o functie liniara
de numarul de pixeli (rezolutia pe axele x si y) din imagine indiferent de numarul
de procesoare si dimensiunea datelor de intrare. In tabelul urmator este prezentata
evolutia raspunsului Y1 conform ecuatiei 3.2.3. Factorul X1 (numarul de puncte) nu
influenteaza volumul de date transferat, ci doar timpul de calcul.
Rezolutia imaginii Y1 Date comunicate (KB) Y1 Date comunicate (KB)nr pixeli dat de aplicatie calculate
480000 7500 7500
1000000 15625 15625
10000000 156250 156250
25000000 390625 390625
50000000 781250 781250
100000000 1562500 1562500
120000000 1875000 1875000
150000000 2343750 2343750
160000000 2500000 2500000
179000000 2796875 2796875
Tabelul 3.7: Evolutia raspunsului Y1 [Amarandei 11]
40
3.2. Analiza cu DOE a unei aplicatii paralele ce utilizeaza metodadescompunerii domeniului de date: sort last parallel rendering
3.2.2.2 Analiza timpului de procesare
Conform tabloului ANOVA prezentat ın Tabelul 3.5, raspunsul Y2 este influentat de
toti factorii de intrare. Astfel, functia ce descrie comportamentul raspunsului Y2 are
valori din Tabelul 3.8 si sub forma generala poate fi scrisa:
Y2 = β0 +
p∑i=1
βixi +
p∑i<j
βij · xi · xj + ε , (3.2.4)
unde p este numarul de variabile (factori) si ε este eroarea reziduala (diferenta dintre
rezultatul obtinut experimental si rezultatul prezis).
X1 X2 X3
100000 480000 6
4000000 480000 6
100000 50000000 6
4000000 50000000 6
100000 480000 8
4000000 480000 8
100000 50000000 8
4000000 50000000 8
Tabelul 3.8: Planul experimental pentru timpul de procesare [Amarandei 11]
Asa cum se observa din Tabelul 3.5 cel mai important efect asupra raspunsului
Y2 ıl au factorii X1, X2, X3 si interactiunea X2X3. Alegerea valorii de 0.01 pentru
cea mai mic nivel de semnificatie ce duce la respingerea ipotezei nule pentru datele
existente, modelul de regresie utilizat pentru obtinerea valorilor prezise este:
Y2 = β0 + β1x1 + β2x2 + β3x3 + β23x2x3 + ε . (3.2.5)
Utilizand valorile din Tabelele 3.1, 3.2 si 3.3, se calculeaza coeficientii de regresie β,
unde consideram variabila raspuns ca fiind Y2. Acesti coeficienti pot fi calculati prin
minimizarea erorii reziduale utilizand metoda regresiei liniare [Barnes 08]. Valorile
obtinute pentru coeficientii de regresie sunt prezentati ın Tabelul 3.9, iar valorile
masurate si cele calculate pentru raspunsul Y2 sunt prezentate ın Tabelul 3.10.
41
3. Model de proiectare a aplicatiilor paralele folosindproiectarea statistica a experimentelor
β
-6.52E-01
4.92E-06
-3.75E-07
1.25E-01
1.60E-14
-2.35E-08
6.54E-07
Tabelul 3.9: Coeficientii β ai ecuatiei pentru Y2 [Amarandei 11]
Y2 Y2 ε ε(%)
real prezis
2.40813 2.29 0.11 4.57%
20.8237 21.49 -0.66 -3.17%
177.86 177.92 -0.06 -0.03%
199.783 197.12 2.67 1.34%
3.02641 3.17 -0.15 -4.96%
21.7683 22.36 -0.59 -2.71%
243.713 243.53 0.19 0.08%
264.943 262.72 2.22 0.84%
Tabelul 3.10: Timpii de calcul masurati si calculati cu ajutorul ecuatiei pentru
Y2 (6-8 procesoare) [Amarandei 11]
Ecuatia 3.2.5, pe baza tabelului 3.5 si utilizand coeficientii β obtinuti, devine
[Amarandei 11]:
Y2 = −6.52 · 10−1 + 4.92 · 10−6x1 − 3.75 · 10−7x2 + (3.2.6)
+1.25 · 10−1x3 + 6.54 · 10−7x2x3 + ε .
Utilizand functia ce descrie raspunsul Y2, determinam comportamentul sistemului
(Tabelul 3.12) pentru cazul ın care numarul de procesoare se modifica (Tabelul 3.11).
Cu valorile coeficientilor β determinati folosind ecuatia 3.2.4 pentru rularea pe 6 si 8
procesoare se ıncearca calcularea timpului de procesare pentru cazul ın care se ruleaza
aplicatia paralela pe 10 si 12 procesoare folosind datele din Tabelul 3.11. Timpii de
procesare calculati pentru raspunsul Y2 si eroarea reziduala se pot observa ın Tabelul
3.12.
42
3.2. Analiza cu DOE a unei aplicatii paralele ce utilizeaza metodadescompunerii domeniului de date: sort last parallel rendering
X1 X2 X3
100000 480000 10
4000000 480000 10
100000 1.79E+08 10
4000000 1.79E+08 10
100000 480000 12
4000000 480000 12
100000 1.79E+08 12
4000000 1.79E+08 12
Tabelul 3.11: Valorile factorilor de intrare pentru predictia raspunsului Y2[Amarandei 11]
Y2 Y2 ε ε(%)
real prezis
3.62407 4.05 -0.43 -11.87%
22.1726 23.24 -1.07 -4.83%
1111.68 1103.87 7.81 0.70%
1131.72 1123.06 8.66 0.77%
4.27239 4.93 -0.66 -15.45%
23.2734 24.12 -0.85 -3.65%
1359.53 1338.08 21.45 1.58%
1374.250 1357.27 16.98 1.24%
Tabelul 3.12: Timpii de calcul masurati si prezisi cu ajutorul functiei ce descrie
Y2 (cazul 10-12 procesoare)[Amarandei 11]
3.2.2.3 Analiza timpilor de comunicatie
Pentru analiza timpului de comunicatie (raspunsul Y3), se foloseste acelasi rationa-
ment ca pentru raspunsul Y2. Din tablelul Anova (Tabelul 3.6) se poate observa ca
raspunsul Y3 depinde de factorii X2, X3 si de interactiunea X2X3. In acest caz,
urmatoarea ecuatie poate fi utilizata pentru modelarea raspunsului Y3:
Y3 = β0 + β2x2 + β3x3 + β23x2x3 + ε . (3.2.7)
Coeficientii de regresie β determinati pentru raspunsul Y3 sunt prezentati ın Tabelul
3.13. Utilizand ecuatia 3.2.7 si coeficientii β determinati se realizeaza predictia asupra
timpului de comunicatie ın cazul rularii pe 10-12 procesoare. Tabelul 3.14 si, respectiv
Tabelul 3.15, prezinta valorile masurate si prezise pentru raspunsul Y3 ın cazul rularii
pe 6-8 si, respectiv, 10-12 procesoare.
43
3. Model de proiectare a aplicatiilor paralele folosindproiectarea statistica a experimentelor
β
-1.04E-01
4.52E-07
-1.35E-07
1.22E-02
-7.00E-15
-3.67E-09
2.42E-07
Tabelul 3.13: Coeficientii β ai ecuatiei pentru Y3 [Amarandei 11]
Ecuatia 3.2.7, pe baza tabelului 3.6 si utilizand coeficientii β obtinuti, devine
[Amarandei 11]:
Y3 = −1.04 · 10−1 + 1.35 · 10−7x2 − 1.22 · 10−2x3 + 2.42 · 10−7x2x3 + ε . (3.2.8)
Y3 Y3 ε ε(%)real prezis
0.661006 0.6004 0.0606 9.17%
2.288 0.6004 1.6876 73.76%
65.7456 65.7535 -0.0079 -0.01%
66.1748 65.7535 0.4213 0.64%
0.880815 0.8569 0.0239 2.71%
2.55107 0.8569 1.6942 66.41%
89.9857 89.9584 0.0273 0.03%
90.3144 89.9584 0.3560 0.39%
Tabelul 3.14: Timpii de comunicatie masurati si prezisi cu ajutorul functiei cedescrie Y3 - cazul 6-8 procesoare [Amarandei 11]
Y3 Y3 ε ε(%)real prezis
1.11392 1.1134 0.0006 0.05%
2.79507 1.1134 1.6817 60.17%
407.274 408.6592 -1.3852 -0.34%
408.065 408.6592 -0.5942 -0.15%
1.34075 1.3698 -0.0291 -2.17%
3.03985 1.3698 1.6700 54.94%
493.946 495.2499 -1.3039 -0.26%
494.171 495.2499 -1.0789 -0.22%
Tabelul 3.15: Timpii de comunicatie masurati si prezisi cu ajutorul functiei cedescrie Y3 - cazul 10-12 procesoare [Amarandei 11]
44
3.2. Analiza cu DOE a unei aplicatii paralele ce utilizeaza metodadescompunerii domeniului de date: sort last parallel rendering
3.2.3 Interpretarea rezultatelor
Pentru aplicatia de randare considerata, am urmarit realizarea unui model care sa o
descrie si cu ajutorul caruia sa verificam performantele prototipului utilizand tehni-
cile DoE. Mai mult, modelul matematic obtinut ın ecuatiile 3.2.3 si 3.2.4), permite
studierea rezultatelor ın cazul rularii pe un numar variabil de procesoare sau pe alte di-
mensiuni ale problemei. Astfel, predictia realizata asupra comportamentului aplicatiei
asa cum se poate observa din Tabelele 3.7, 3.10 si 3.12, a fost realizata cu o eroare
acceptabila.
Scopul urmarit ın analiza prezentata ın sectiunea anterioara este gasirea combina-
tiei de valori ale factorilor de intrare pentru care erorarea de predictie este mare. Astfel
modelul de analiza propus permite identificarea cazurilor ın care modelul empiric al
aplicatiei nu descrie corect un anumit raspuns. Daca, folosind planul experimental, se
obtin erori mari numai pe o anumita combinatie de valori de intrare (cazul expus ın
Tabelele 3.14 si 3.15), se evidentiaza comparativ erorile modelului ın raport cu unul
dintre parametri sau erorile la nivel de aplicatie ın raport cu acelasi parametru. In
functie de scopul analizei, trebuie luate decizii legate de modalitatea de implementare
a aplicatiei. In Tabelele 3.14 3.15 se pot observa erori foarte mari pentru o combinatie
a factorilor de intrare din planul experimental din Tabelul 3.11. Acest lucru inseamna
ca, fie modelul nu descrie corect aplicatia, fie exista probleme ın implementarea
aplicatiei.
Relatia dintre numarul de puncte, dimensiunea imaginii si timpul de comunicatii
este descrisa de ecuatia 3.2.3. Astfel, indiferent de numarul de puncte folosite la
randarea imaginii ( ıntre 100000 si 4 mil. puncte) dimensiunea imaginii nu se modifica,
ajungand la ordinul 2,5GB pentru o rezolutie maxima a imaginii de 17 mil. puncte.
Acest maxim pentru care au fost realizate testele experimentale se datoreaza memoriei
disponibile.
Proiectarea unei aplicatii paralele nu este o sarcina usoara. In unele cazuri, al-
goritmii secventiali existenti pot fi transformati ın algoritmi paraleli, ın timp ce ın
altele trebuie dezvoltati algoritmi noi. Indiferent de originea lor, majoritatea algo-
ritmilor paraleli introduc ıncarcari suplimentare ce nu se regasesc ın corespondentul
lor secvential. Aceste supraıncarcari apar datorita: comunicatiilor inter-procesor,
dezechilibrelor din ıncarcarea procesoarelor, calcule suplimentare sau redundante,
cresterea cererilor legate de stocarea structurilor de date secundare sau a dupli-
catelor. O parte din aceste concepte sunt specifice algoritmilor paraleli ın timp
ce altele (coerenta datelor, maparea din spatiul imaginii ın spatiul obiectelor) sunt
specifice problemei de randare considerate. Pentru aplicatia de randare paralela am
urmarit descrierea comportamentului aplicatiei cu ajutorul ecuatiilor si sa utilizam
aceste ecuatii pentru studierea (si prezicerea) performantelor aplicaiei paralele atunci
cand variaza numarul unitatilor de procesare [Amarandei 11].
Utilizand modele empirice construite pentru cele trei raspunsuri urmarite, observam
ca timpii de procesare si de comunicatii depind de rezolutia imaginii finale si de
45
3. Model de proiectare a aplicatiilor paralele folosindproiectarea statistica a experimentelor
numarul de procesoare. Acest lucru se datoreaza faptului ca ultima etapa a aplicatiei
implica comunicarea rezultatelor locale de pe fiecare procesor pe care s-a realizat
randarea catre nodul ce compune imaginea finala. Cu cat este mai mare rezolutia
imaginii finale cu atat mai mult timp dureaza sa fie transmise. Mai mult, acest lucru
reprezinta o sursa de ıntarzieri (bottleneck) pentru aplicatia paralela. O alta concluzie
importanta priveste numarul de procesoare utilizate pentru distribuirea taskurilor de
randare. Utilizarea unui numar larg de procesoare de randare nu furnizeaza neaparat
un timp de procesare total mai bun. Aceasta problema de scalabilitate poate fi
ımbunatatita prin ınlocuirea etapei de compunere finala a imaginii cu un mecanism
mai eficient, de exemplu rutarea mesajelor ın retea utilizand topologii de tip plasa
sau arbore binar, sau o compunere planificata a imaginii. Considerand observatiile
anterioare, ın eventualitatea executarii simultane a aplicatiei de catre mai multi uti-
lizatori sau daca este impusa un maxim de alocare a memoriei, aplicatia devine rapid
extrem de limitata si se pot observa rezultate slabe ale acesteia daca o parte nu este
reproiectata.
3.3 Concluzii
In acest capitol a fost propus un model de testare a unei aplicatii paralele prin
definirea unui set eficent de teste. Un plus al acestui model este posibilitatea es-
timarii performantelor aplicatiei la rularea ın alte conditii si cu alti parametri fata
de conditiile ın care au fost realizate testele initiale. Aceste obiective pot fi atinse
utilizand metode de analiza statistica ce permit o identificare mai usoara a erorilor
ce apar ın fiecare etapa de proiectare. Metoda propusa faciliteaza eliminarea facto-
rilor care nu au influenta asupra raspunsului analizat al aplicatiei, oferind ın acelasi
timp o mai buna perspectiva asupra factorilor care au cel mai mare impact asupra
performantelor aplicatiei paralele.
Tehnica planului experimental permite proiectantului unei aplicatii paralele ce uti-
lizeaza descompunerea domeniului de date sa testeze performantele cu parametri de
intrare reali fara a rula efectiv aplicatia. Estimarile obtinute prin analiza statistica pot
fi apoi utilizate pentru optimizarea resurselor necesare aplicatiei ın sensul adaptarii
dinamice, ın timpul executei, la dimensiunea datelor de intrare sau de iesire. Daca
mediul de programare permite, ar fi utila modificarea dinamica a numarului de pro-
cese sau procesoare utilizate de aplicatia paralela. Utilizarea metodei propuse poate
aduce o noua perspectiva asupra anumitor conditii de rulare ce poate fi obtinuta
pe baza parametrilor considerati. Acest lucru este util ın special pentru estimarea
resurselor necesare unei aplicatii paralele. Un considerent important, rareori luat ın
considerare, este faptul ca aplicatia nu este singura ce ruleaza pe un cluster. Astfel,
ıncarcarea retelei interne a clusterului variaza datorita datelor transferate de toate
aplicatiile. Mai mult, resursele unui cluster pot fi rezervate ın diverse scopuri (de
exemplu: academice, de cercetare sau comerciale). Este util ın astfel de situatii ca
46
3.3. Concluzii
cererile de resurse realizate de catre aplicatii sa fie formulate considerand acest aspect
dinamic. In caz contrar, performantele aplicatiilor pot varia ıntr-o maniera complet
necontrolata si nu se pot obtine rezultate satisfacatoare. Modelul propus ın cadrul
acestui capitol ajuta la detectia si eliminarea acestor neajunsuri.
47
Partea a II-a: SOLUTII DE
IMPLEMENTARE A
INFRASTRUCTURII PENTRU
SISTEMELE GRID SI A
CLUSTERELOR COMPONENTE
49
Capitolul 4
Clustere si sisteme grid
Calculul pe Grid (Grid computing) implica utilizarea de programe organizate pe com-
ponente care ruleaza pe un numar foarte mare de calculatoare. Astfel calculul pe Grid
poate fi gandit ca o forma de calcul paralel pe un cluster de dimensiuni foarte mari
conectate pe principiul rolurilor egale. Ian Foster si colaboratorii propun ın [Foster 02]
trei criterii pentru caracterizarea sistemelor Grid [Aflori si Amarandei 05]:
• Coordonarea resurselor : Resursele sunt coordonate, dar nu sunt controlate
ıntr-o maniera centralizata – un sistem Grid integreaza resurse si utilizatori
care apartin de domenii diferite, resurse si utilizatori ce sunt administrate local.
• Utilizarea standardelor, a protocoalelor si a interfetelor deschise, general vala-
bile: Intr-un sistem Grid trebuie sa existe protocoale si interfete pentru auten-
tificare, autorizare, descoperirea si accesul la resurse. Este foarte important ca
aceste protocoale sa fie standardizate si deschise.
• Furnizarea de servicii netriviale: Conceptul de Grid presupune avantajele resur-
selor de grup, dar si participare activa la dezvoltarea acestor resurse. Din acest
motiv, ıntr-un sistem Grid exista doua categorii de participanti: consumatorii
si furnizorii de servicii. Pentru ca sistemul sa functioneze, serviciile trebuie sa
fie de calitate, altfel consumatorii se orienteaza spre alte sisteme.
4.1 Arhitecturi de tip Grid
Conform [Foster 01] ın definirea unei arhitecturi Grid se pleaca de la principiul ca
o organizatie virtuala eficienta trebuie sa poata integra noi membri, care sa puna
la dispozitie resursele proprii si sa acceseze resursele partajate. Astfel, arhitectura
Grid este o arhitectura de protocoale care definesc mecanismele prin care utilizatorii
organizatiilor virtuale negociaza, implementeaza, administreaza si utilizeaza resursele
partajate [Aflori si Amarandei 05].
51
4. Clustere si sisteme grid
Sistemele Grid pot fi clasificate ın 3 categorii (vezi Figura 4.1): departamentale
(sau Cluster Grid), de ”ıntreprindere” (Campus Grid) si globale (Global Grid). Aceste
categorii ar corespunde unei firme care, initial, ısi foloseste resursele ın cadrul unui
singur grup, de exemplu departamentul de ingineri. Se extinde apoi la resursele
de calcul ale personalului ne-tehnic (pentru utilizarea puterii de calcul nefolosite si
a capacitatii de stocare), ca ın final sa se ajunga la un Grid gobal (ceea ce implica
resursele distribuite geografic ale firmei) care sa poata fi folosit ıntr-un mod comercial
sau colaborativ.
Cluster Grid Campus Grid Global Grid
Figura 4.1: Grid departamental(Cluster Grid), de ıntreprindere (Campus Grid)si global (Global Grid) [Aflori si Amarandei 05]
Principala resursa a unui Grid computational o reprezinta puterea de calcul ma-
terializata prin clusterele de calculatoare. Notiunile de Cluster computing si Grid
Computing sunt notiuni complementare; sistemele Grid expun sub forma de resurse
partajate si clustere de calculatoare. De fapt, pentru un utilizator al unui sistem Grid
folosirea unui cluster de calculatoare este total transparenta, clusterul fiind vazut ca
o resursa de calcul pentru sistemele de management ale resurselor.
In cele ce urmeaza este prezentata arhitectura clusterelor atat datorita importan-
tei acestora ın cadrul stratului de baza al sistemelor Grid, cat si datorita influentei pe
care proiectarea acestora o poate avea asupra performantelor aplicatiilor tinta.
4.2 Arhitectura clusterelor
Intr-o definitie simpla, clusterele reprezinta un grup de calculatoare interconectate ce
lucreaza ımpreuna pentru rezolvarea unei probleme. Acestea nu pot fi confundate
cu modelele din sistemele client-server ın care aplicatiile sunt ımpartite logic ın unul
sau mai multi clienti care cer informatii sau acceseaza servicii furnizate de unul sau
mai multe servere. Ideea principala din spatele functionarii unui cluster este de a
aduna puterea de calcul a sistemelor componente pentru a furniza scalabilitate sau
52
4.2. Arhitectura clusterelor
pentru a crea sisteme redundante ın scopul oferirii unei disponibilitati ridicate (high
availability).
In general clusterele sunt ımpartite ın doua mari categorii:
• clustere HA (High availability sau Failover Clusters) – construite pentru a
oferi disponibilitate ridicata, echilibrare a ıncarcarii, redundanta pentru un data
center ;
• clustere HPC (High Performance Computing) – construite pentru a ınlocui
supercalculatoarele si a furniza putere mare de calcul, ıncorporand si facilitati
oferite de clusterele HA.
Scopul clusterelor HPC este acela de a oferi suport pentru rularea aplicatiilor
intesiv computationale. O prima abordare ın implementarea unei astfel de solutii a fost
utilizarea calculatoarelor personale, abordare ce are si avantajul unor costuri reduse.
Realizarea unui astfel de cluster impune furnizarea unei imagini unice a sistemului prin
mecanisme ce gestiuneaza un numar mare de noduri distincte. Trebuie, de asemenea,
solutionate urmatoarele probleme:
• instalarea si ıntretinerea sistemului de operare si a aplicatiilor pe toate nodurile;
• managementul nodurilor si gestionarea erorilor hardware si software ce pot
aparea;
• accesul concurent si ın paralel la acelasi sistem de fisiere;
• comunicatiile interproces pentru coordonarea lucrului ın paralel pe nodurile
disponibile.
Anterior avantajele clusterelor sunt evidente. In ciuda acestui fapt, costurile
aferente realizarii si mentinerii ın functiune pot fi ridicate. De exemplu, pentru a
implementa cel mai simplu cluster HA (sistem complet redundant cu rezerve pasive)
se pot atinge costuri duble pentru hardware si software fata de cazul clusterelor simple.
Pentru cazul clusterelelor HPC, se doreste minimizarea costurilor legate de hardware
si licente software. Scopul unui astfel de cluster este acela de a oferi unui mediu
de calcul cat mai simplu si eficient posibil, pentru a exploata la maxim resursele
computationale ale nodurilor individuale; si a scadea costurile legate de licentele
software. Desi aproape toate nodurile unui cluster HPC sunt identice din punct de
vedere hardware, pot exista diferente – mai multe functii logice ale unui nod din
cluster pot exista pe acelasi nod fizic (Figura 4.2) [Amarandei 08]:
In cadrul unui cluster HPC, calculele efective sunt realizate pe nodurile de calcul
(compute nodes), iar distributia task-urilor este realizata de un planificator (SGE,
Condor, PBS). Gestiunea ıntregului cluster este realizat prin intermediul unui nod de
management, nod ce ofera servicii de monitorizare individuala a fiecarei componente
a clusterului (Ganglia) si de transmidere de comenzi (C3, GXP Shell, parallel shell).
Un astfel de cluster trebuie sa includa si un nod de control ce va furniza servicii
precum DHCP, DNS, planificare, etc. In cazul majoritatii clusterelor reconfigurarea
sau reinstalarea nodurilor de calcul cu o noua imagine este o actiune frecventa. In
consecinta, este absolut necesara integrarea unui nod de instalare care sa furnizeze
53
4. Clustere si sisteme grid
Nod de management
Nod de instalare
Nod de stocare
Nod de control
Frontend
DHCP, DNS, Sheduler , etc
Noduri de calcul
Imaginile nodurilor pentru instalare
rapida
Management , power on /off, event handing , etc.
Acces rapid la un sistem de fisiere
User nodeOfera acces utilizatorilor
Cluster
Figura 4.2: Structura logica a unui cluster [Amarandei 08]
imaginile nodurilor. Acesta trebuie sa ofere mecanisme de instalare rapida a ima-
ginilor de sistem pe nodurile tinta sau a aplicatiilor necesare. Pentru o mare parte
a aplicatiilor care ruleaza ın cluster, nodurile de calcul au nevoie de acces rapid,
stabil si simultan la un sistem de stocare. Acest lucru poate fi rezolvat ın diverse
moduri ın functie de specificul fiecarei aplicatii: sistem de fisiere distribuit/partajat
sau baze de date. In cazul accesului la un sistem de fisiere se pot folosi dispozitive
de stocare performante atasate direct nodurilor printr-o interfata dedicata, separata
complet de cea utilizata pentru comunicatiile dintre noduri. In cazul accesului la baze
de date se poate folosi un cluster independent, capabil sa furnizeze date la o rata de
transfer satisfacatoare (MySQL Cluster, Oracle, etc.). Pentru cresterea performantei
se poate folosi acelasi tip de conectare ca la un sistem de stocare specializat. Un
astfel de sistem de stocare poate fi de asemenea conectat si prin intermediul unui nod
specializat. Acesta trebuie sa fie capabil sa deserveasca cererile nodurilor de calcul (un
exemplu ın acest sens este MySQL Cluster: exista noduri distincte pentru stocarea
datelor si pentru interfatarea cu exteriorul). In mod uzual, nodurile unui cluster sunt
conectate prin intermediul unei retele interne, private, si nu pot fi accesate direct
din exterior. Interfata cu utilizatorii trebuie realizaa prin intermediul unui nod de tip
frontend. Acest nod este special configurat pentru a furniza utilizatorilor o interfata
de acces la resursele de calcul, pentru a rula un task sau pentru a vizualiza rezultatele
produse de un task ce a rulat anterior.
Din punct de vedere al administratorului, pentru o astfel de structura a unui
cluster, sunt rezolvate urmatoarele probleme:
• configurarile de securitate si mijloacele pentru managementul acestora;
• modalitati de a instala/reinstala nodurile prin intermediul unui singur nod ce
furnizeaza imaginile necesare;
• gestiunea aplicatiilor instalate ın cluster.
Structura logica a unui cluster, prezentata ın Figura 4.2, poate fi extinsa la nivelul
54
4.3. Studiu de caz - Gridul GRAI
sistemelor Grid: noduri de control, de stocare, de management, de instalare si de
interfata cu utilizatorul situate ın locatii distincte ale sistemului Grid.
Serviciile furnizate de organizatiile membre ale unui sistem Grid sunt diferite, dar
software-ul care furnizeaza partea de control si management este acelasi ın toate
locatiile sau exista aplicatii specializate care ofera posibilitatea de interconectare.
Gradul de adoptare de utilizator al sistemelor Grid si performanta acestora sunt di-
rect influentate de disponibilitatea serviciilor furnizate de site-urile membre. Deoarece
clustere HPC trebuie sa includa si facilitatile oferite de clusterele HA ca cele din figura
urmatoare, acestea se extind si influeteaza sistemul Grid din care fac parte.
4.3 Studiu de caz - Gridul GRAI
Grid-ul GRAI este organizat pe 4 nivele: nivelul resurselor de calcul, nivelul servicii-
lor, nivelul aplicatiilor si nivelul de informare. La nivelul resurselor de calcul a fost
construita o retea de calculatoare complexa distribuita geografic ın 5 locatii (Fig.
4.3):
• UTI-C - Faculatatea de Automatica si Calculatoare, Catedra de calculatoare
• UTI-E & AR-IIT - Facultatea de Electronica si Telecomunicatii si Institutul de
Informatica Teoretica Iasi,
• UAIC-I - Facultatea de Informatica,
• UMF-B - Facultatea de Bioinginerie si
• USAMV-H - Facultatea de Horticultura.
Nivelul serviciilor contine un set de servicii Grid de baza, suport pentru aplicatii,
ın urmatoarele domenii: Descoperirea de cunostinte ın baze de date, Procesare de
imagini, Platforme multi-agent, Optimizare combinatoriala, Rezolvarea problemelor
de programare bazata pe constrangeri (CSP), Web semnatic, Metode ale calculului
evolutiv, Bioinformatica, E-learning.
Datorita specificului amplasarii acestor noduri, modul de conectare al acestora
s-a realizat pe infrastructura existenta, utilizandu-se retelele de comunicatii ale Uni-
versitatii Tehnice ”Gheorghe Asachi” Iasi, ale Universitatii ”Alexandru Ioan Cuza”
Iasi, ale Universitatii de Stiinte Agronomice si Medicina Veterinara ”Ion Ionescu de
la Brad” Iasi, Universitatii de Medicina si Farmacie ”Gr. T. Popa” Iasi, precum
si reteaua metropolitana academica ieseana. Sistemele frontend aflate ın dotarea
membrilor GRAI sunt ın urmatoarea configuratie:
• Nodurile UTI-AC, UAIC-I si UTI-E & AR-IIT au ın dotare sisteme IBM x3800
fiecare cu 4 procesoare 3.66 GHz Intel Xeon, 4 x 146 GB SAS HDD, configurate
ın RAID 6 si 8 GB RAM.
• Nodul USAMV-H are ın dotare un sistem: IBM x3650, 2x146GB SAS HDD,
1GB RAM
• Nodul UMF-B are ın dotare sistem: IBM x346, 4x146GB SAS HDD, 1GB RAM.
55
4. Clustere si sisteme grid
Nodurile din clustere sunt ın urmatoarea configuratie pentru toti partenerii: Dell
Optiplex 755, Dual Core (Intel Core 2 Duo) 2,33GHz, 2 GB DDR2 Non-ECC SDRAM
667MHz, 160GB 7200RPM High Reliability SATA 3.0Gb/s, 8MB DataBurst Cache.
FrontendUSAMVWorkstations
Frontend
CCTI-UTI
RoEduNet
IASI
INTERNET
FrontendUAIC
UTI - AC
UAIC - CS
Agrosoft
CCTI-UTI
FrontendUTI-ETCWorkstations
FrontendWorkstationsAR-IIT
FrontendUMF
OF
OF
OF
OF
OF
UTP
UTP
UTP
Legend:
OF – optical fiber
UTP – CAT5e ethernet
OF
OF
OF
Figura 4.3: Arhitectura retelei GRAI [Amarandei 08]
4.3.1 Implementarea infrastructurii GRAI
Software-ul de management al clusterului este un aspect deosebit de important ce
trebuie considerat de un administrator de sistem, iar solutiile disponibile sunt nu-
meroase: RocksClusters, Platform Open Cluster, RedHat Cluster Suite, Linux Cluster
Manager, OSCAR (Open Source Cluster Application Resources), BOINC, Compute-
Mode, Clustermatic sau Perceus/Warewulf Cluster (daca sunt utilizate statii fara
disk ın constructia clusterului). In continuare, vom prezenta solutia aleasa pentru
implementarea infrastructurii GRAI cu RocksClusters.
4.3.1.1 RocksClusters - Cluster Deployment and Management Tool in Grid
Systems
NPACI Rocks reprezinta o distributie de Linux completa, avand la baza RedHat
Linux la care au fost adaugate aplicatii suplimentare pentru configurarea si instalarea
automataa clusterelor si sistemelor de calcul de mare performanta. Distributia RedHat
Linux a fost aleasa din cauza prezentei a doua mecanisme cheie: sistemul de ma-
nagement al pachetelor (RPM) s utilitarele de instalare a aplicatiilor ce pot descrie
configuratia software pentru nodurile clusterului (kickstart) [Papadopoulos 04].
56
4.3. Studiu de caz - Gridul GRAI
RocksClusters funizeaza mecanisme pentru instalarea complet automata a noduri-
lor din cluster folosind RPM si fisiere kickstart pentru a asigura scalabilitatea instalarii.
Procesul deinstalare se desfasoara ın doua etape: instalarea pachetelor software si
configurarea pachetelor instalate. La configurarea pachetelor software de cele mai
multe ori se accepta setarile standard ın cazul unui sistem de tip desktop, sau au
diferite configuratii ce trebuie modificate ın cazul unei retele cu diferite cerinte .
RocksClusters simplifica acest proces prin tratarea separata a etapei deinstalare a
software-ului de etapa de configurare a acestuia. Instalarea si configurarea pachetelor
software este realizata sub forma unui pachet ce este instalat dupa functionalul
fiecarui nod ın parte si este privita ca un ıntreg si referita sub numele de appliance
[Papadopoulos 04].
Pentru a veni ın ajutorul proiectatului unui cluster sa realizeze un nou appliance
si sa reutilizeze configuratia sistemului, RocksClusters furnizeza un framework simplu
ce este descris prin fisiere XML. Pentru a integra acest framework cu distributiile
de tip Red Hat Linux, este furnizata o aplicatie denumita rocks-dist. Aceasta
aplicatie adunainformatii legate de componentele software din distributia Linux de
baza, aplicatii dezvoltate de comunitatea Rocks si de catre dezvoltatori independenti.
Aceste informatii sunt utilizate pentru a crea o distributie de Linux actualizata, com-
patibila cu Red Hat Linux [rocksclusters 02].
Prin gestionarea pachetelor software independent de configurarea lor, aceeasi
configuratie poate fi folsita pentru diverse variante ale aplicatiilor
[Papadopoulos 04].
4.3.1.2 Suportul pentru instalarea multi-site si securitatea ın RocksClusters
Urmatorul pas ın construirea unei infrastructuri Grid GRAI, este instalarea clusterelor
din locatiile partenere. Instalarea acestora a fost realizata tot cu RocksClusters uti-
lizand facilitatile acestuia de instalare pe WAN (wide area networks). Utilizarea
RocksCluster presupune crearea unui server central de instalare ce va stoca software-
ul necesar pentru a putea fi utillizate de front-end-uri. Arhitectura unui RocksClusters
pentru WAN este prezentata ın [Sacerdoti 04].
Facilitatile WAN utilizate, permit instalarea rapida a unei infrastructuri Grid prin
instalarea ıntregii suite de aplicatii de la distanta, simplificand astfel operatiile de ad-
ministrare. Daca o anumita locatie are nevoie de configurari specifice si de pachete
software suplimentare, structura interna a RocksClusters permite administratorului sa
contruiasca un pachet de aplicatii denumit roll, pachet ce va fi instalat pe frontend-
ul corespunzator locatiei si de acolo pe noduri. Instalarea aplicatiilor, a fisierelor de
configurare si a informatiilor de autentificare ale utilizatorilor constitue o potentiala
problema de securitate pentru intreg sistemul Grid. Pentru a evita acest tip de
probleme, RocksClusters distribuie fisierele de parole, configuratiile pentru utiliza-
tori si grupuri utilizand un serviciu numit 411 Secure Information Service. Serviciul
411 furnizeaza un serviciu asemanator cu NIS (Network Information Service) pentru
57
4. Clustere si sisteme grid
Rocks, imitand functionalitatea NIS la care adauga Public Key Cryptography pentru
a proteja continutul fisierelor. Serviciul lucreaza la nivelul fisierelor spre deosebire
de NIS care utilizeaza RPC (Remote Procedure Call). Deoarece nu are la baza
RPC, 411 distribuie fisierele utilizand servicii web. Principala sarcina a serviciului 411
este pastrarea si securizarea fisierelor cu utilizatori si parole pe nodurile clusterelor.
Acest lucru este realizat prin implementarea unei baze de date distribuite de fisiere
[rocksclusters 02].
Complexitatea unui sistem Grid aduce multe provocari administratorilor. Uti-
lizarea RocksCluster ın gridul GRAI faciliteaza stabilirea unui plan de instalare si
ıntretinere a aplicatiilor, permitand extinderea sistemului prin adaugarea de hardware
si software cu un efort minim. Pachetele software cerute de GRAI includ: middle-
ware, sistem de management al job-urilor si aplicatii de monitorizare a sistemelor.
RocksClusters furnizeaza suite de aplicatii a caror instalare si configurare este sau
poate fi automatizata complet:
• GlobusToolkit 4 - middleware Grid;
• Condor, SunGrid Engine osau Torque - managere de resurse;
• OpenPBS - planificarea taskurilor;
• Ganglia, OpenSCE - utilitare de monitorizare.
Impreuna cu suitele de aplicatii furnizate de distributia RedHat Linux, Rocks
Clusters a fost ales pentru implementarea infrastructurii gridului GRAI.
4.3.2 Concluzii
In acest capitol, dupa trecerea ın revista a arhitecturii generice a unui site Grid
si a unui cluster este prezentata arhitectura gridului GRAI implementat la nivelul
universitatilor din centrul universitar Iasi.
Cerintele impuse ın implementarea conceptului de sistem Grid ın general, si al
sistemului Grid GRAI ın particular, ridica provocari pentru care exista diverse solutii.
Construirea unei infrastructurii Grid presupune combinarea ıntr-o maniera complexa a
experientelor cu diferite sisteme de operare, middleware si instrumente de instalare si
configurare. Este necesara alegerea dispozitivelor hardware adecvate, a infrastructurii
de retea, proiectarea clusterelor si instalarea sistemului de operare si a instrumentelor
de administrare, inglobarea tehnologiilor de securitate, testarea diferitelor instrumente
si aplicatii disponibile. Dezvoltarea gridului GRAI a ınceput cu proiectarea retelei de
comunicatii si a clusterelor membre, continua cu instalarea sistemelor de operare si a
softului de management si se ıncheie cu tratarea problemelor de securitate.
In construirea clusterelor si ale sistemelor Grid, o problema importanta o reprezinta
variatia echipamentelor hardware si a retelei de comunicatii. Alegerea cu grija a
acestora se traduce ın reducerea timpului necesar mentenantei si dezvoltarii ulterioare
a infrastructurii [Amarandei 08], dar si ıntr-o exploatare eficienta [Amarandei 06].
58
Capitolul 5
Un nou model de optimizare a
comunicatiilor ın clustere
5.1 Definirea problemei
Performantele unui cluster depind de peformantele componentelor acestuia: nodurile
de calcul si infrastructura de comunicatii. Infrastructura de comunicatii a unui cluster
este construita folosind interfete de comunicatii ale caror performante pot fi modi-
ficate doar prin modificarea echipamentelor hardware (de exemplu ınlocuirea unui
switch cu altul ce are performante superioare) si din acest motiv aceasta compo-
nenta a clusterului este neglijata. Performanta unui nod de calcul este definita de
performantele hardware-ului si ale software-ului. Performanta hardware-ului poate
fi considerata o valoare constanta si depinde doar de schimbarile ce se pot face
ın hardware. Software-ul poate fi separat ın doua componente: aplicatiile si sis-
temul de operare. Performantele clusterului pot depinde de ambele componente.
Imbunatatirea performantelor clusterului prin modificarea aplicatiilor este o tinta di-
ficil de atins, unele aplicatii ar trebui rescrise complet. Exista si exceptii, ca de
exemplu aplicatiile network-aware, construite special ın acest scop si care nu necesita
modificari. Ultima componeta care poate modifica performantele clusterului este sis-
temul de operare prin configurarile kernelului sau optimizarile la nivelul subsistemului
de retea [Rusan si Amarandei 10].
Tinand cont ca un cluster contine un numar mare de noduri, ımbunatatirea
performantelor clusterului trebuie facuta cu modificari minime la nivelul sistemului de
operare instalat. Aceasta cerinta este necesara pentru a usura operatiile de mentine
ıntretinere a clusterului. Solutiile existente implica modificarea fie a sistemului de
operare, fie a aplicatiilor.
Cercetarile existente, prin proiecte precum WAD (Work Around Daemon) sau
59
5. Un nou model de optimizare a comunicatiilor ın clustere
ENABLE nu ındeplinesc cerintele impuse - WAD cere kernel modificat; ENABLE
cere rescrierea aplicatiilor.
Proiectul WAD furnizeaza o serie de mecanisme care trateaza transparent proble-
mele legate de retea, icluzand TCP buffer size, MTU size si reordonarea pachetelor
[Dunigan 02]. Scopul proiectului este eliminarea interventiei administratorului pentru
ajustarea manuala a parametrilor retelei. Pentru aceasta, este nevoie de un kernel
modificat ce poate fi obtinut de pe site-ul proiectului Web100. Aceasta solutie nu
este aplicabila clusterelor membre ale gridului GRAI datorita faptului ca exista patch
disponibil ıncepand cu versiunea 2.6.12 a kernel-ului Linux. Datorita unei versiuni
diferite de kernel, pot apare probleme de incompatibilitate cu versiunile sistemului de
operare instalat (CentOS 4.5), iar una din cerintele exprese este utilizarea kernelului
existent.
In continuare este prezentat modelul de auto-optimizare a comunicatiilor din clus-
ter pentru a-i ımbunatati performantele prin scurtarea timpului de transfer a datelor.
Modelul propus nu presupune modificarea aplicatiilor sau a structurii kernelului ci
utilizeaza doar facilitatile oferite de sistemul de operare.
5.2 Modelul de optimizare a comunicatiilor
Modelul propus presupune calcularea celor mai bune valori posibile pentru un set
dat de parametri ai sistemului de operare. In Figura 5.1 sunt prezentate cele trei
module componente: modulul de control (Contro Logic - CL), modulul de calcul a
parametrilor (Parameter Computation - PC) si modulul de testare a retelei (Network
test tool - NTT). Prima componenta este responsabila de transmiterea valorilor catre
modulul PC si controleaza ıntregul sistem. Al doilea modul, calculeaza seturi de valori
pe baza unor date cunoscute initial si a rezultatelor curente primite de la modulul
NTT si le transmite kernelului pentru a seta valorile corespunzatoare ın subsistemul
de retea. Modulul NTT este responsabil de rularea testelor si de transmitere a
rezultatelor catre modulul PC. Procesul de optimizare a comunicatiilor este pornit
de modulul CL, care transmite valorile de start setate ın kernel catre modulul PC
ti primul set de teste prin intermediul NTT este pornit. Dupa terminarea testelor,
rezultatele produse sunt transmise catre modulul PC ce calculeaza un nou set de
parametri pana la ıntalnirea conditiei de terminare [Rusan si Amarandei 10].
Modelul furnizeaza auto optimizarea parametrilor kernelului pentru subsistemul
de retea, singura interactiune cu aplicatia fiind fisierul de configurare ce contine val-
orile necesare pornirii aplicatiei. Aceste valori pot fi setate de catre administratorul
clusterului ın functie de necesitati. Pentru implementarea functionalitaii modelu-
lui, propunem urmatorul algoritm (Algoritmul ??). Algoritmul realizeaza masurarea
latimii de banda si modifica parametrii kernelului pentru a obtine latimea de banda
maxima pentru fiecare caz ın parte.
Pentru l, numarul de teste ce trebuie realizate, fie N = {n1, n2, . . . , nk}setul de
60
5.2. Modelul de optimizare a comunicatiilor
Compute node Compute node
Network test
tool
Network
subsystem
Network
device
Compute node
Network test
tool
Network
subsystem
Application
Kernel
Hardware
Control logic
Parameter
computation
Network
device
Network
infrastructure
Network test
tool
Network
subsystem
Network
device
Figura 5.1: Modelul de optimizare a comunicatiilor ın clustere[Rusan si Amarandei 10]
noduri din cluster, T = {t1, t2, . . . , tl} setul de variabile (de exemplu tcp_rmem,
tcp_wmem, tcp_window_scalling), I = {i1, i2, . . . , il} valorile de start pentru
parametrii kernel ai subsistemului de retea si E = {e1, e2, . . . , el} setul de valori
ce trebuie calculat pentru fiecare test ti. Fiind dat m numarul de mesaje, definim
MS = {ms1,ms2, . . . ,msm} ca setul de mesaje utilizat de aplicatia de testare a
performantelor retelei, X = {x1, x2, . . . , xm} setul celor mai bune valori calculate
pentru fiecare test tt, setul de rezultate Ri = {r1, r2, . . . , rk}i pentru fiecare nod din
cluster, S = {s1, s2, . . . , sm}, unde si =∑k
j=i rij si B = {b1, b2, . . . , bm} este setul
celor mai bune valori obtinute pentru fiecare test ti.
Algoritmul de calcul este urmatorul:
Algoritmul are doua componente:
• o componenta pentru testarea retelei corespunzator modulului ”Network test
61
5. Un nou model de optimizare a comunicatiilor ın clustere
tool” din Figura 5.1 si este implementata ın liniile 3-19 ale algoritmului,
• o componenta corespunzatoare modulului ”Parameter Computation” din Figura
5.1 si implementat ın liniile 20-30.
Functiile utilizate ın acest algoritm implementeaza urmatoarele actiuni:
• generate set: genereaza un nou set de parametri utilizati ın testarea retelei;
• start remote testing program: lanseaza ın executie componenta de testare
(NetPIPE) aflata pe nodurile din cluster;
• prepare local testing program: pregateste componentele locale ale aplicatiei
de testare - functie necesara pentru a asigura acuratetea rezultatelor;
• execution of local testing programs: ruleaza aplicatia de testare;
• get max count: pentru parametrii considerati extrage valorile corespunzatoare
ratei de transfer maxime.
Linia 31 a algoritmului seteaza parametrii nucleului cu cele mai bune valori cal-
culate pe toate nodurile din cluster.
5.3 Implementarea modelului
Pentru testarea modelului propus, urmatorii parametri de kernel au fost folositi:
tcp_window_scalling, tcp_rmem si tcp_wmem. Modelul a fost testat pe un cluster
gridului GRAI prezentat ın Capitolul 4.3. Prima implementare a algoritmului a fost
realizata ın Bash, dar a fost rescris ın Perl datorita dificultatilor ıntampinate la lucrul
cu structuri de date. Desi nu este explicit prezentat ın algoritm, rezultatele obtinute
ın timpul rularii au fost salvate ın fisiere.
Protocolul TCP transmite date noi ın retea atunci cand pachetele deja trimise
destinatarului indica receptia. Rata de transmisie este depinde de dimensiunea fere-
strei glisante si este limitat din aplicatie, de dimensiunea bufferului de transmisie si
a celui de receptie precum si de congestion window. TCP modifica dinamic dimen-
siunea congestion window pentru a afla rata de transfer dintre sursa si destinatie.
Pachetele lipsa sau corupte sunt reparate prin retransmiterea din bufferul de trans-
misie. Acest proces presupune ca datele se ıncadreaza ın dimensiunea bufferelor de
receptie si transmisie. [Dunigan 02]
Dimensiunea maxima a ferestrei este de 216 = 65KB deoarece headerul TCP
utilizeaza 16 biti pentru a raporta catre expeditor dimensiunea ferestrei care o poate
primi destinatarul. Optiunea window scale a fost introdusa pentru a defini factorul
de scalare implicit pentru multiplicarea dimensiunii ferestrei din headerul TCP si
a-i obtine dimensiunile reale [Jacobson 92]. Bufferele au valori implicite ce pot fi
modificate fie de catre aplicatie prin apeluri sistem ori prin utilizarea utilitarelor puse
la dispozitie de sistemul de operare, ca de exemplu utilitarul sysctl din Linux/Unix.
Optimizarile propuse de model au loc la nivelul subsistemului de retea al nucleului
Linux. Incepand cu versiunea 2.4 a nucleului Linux, sunt implementate tehnici de auto
reglare pentru a realiza managementul memoriei.
62
5.3. Implementarea modelului
Aceste tehnici cresc sau reduc dinamic dimensiunea memoriei alocate bufferelor.
Prin cresterea dimensiunii bufferelor, conexiunile TCP pot creste dimensiunea feres-
trei, cresterea performantelor retelei fiind un efect secundar intentionat [Tierney 01].
Pe de alta parte, acest lucru se face ın limitele memoriei disponibile, resursa deosebit
de valoroasa pe un cluster.
Subsistemul de retea al nucleului Linux trebuie reglat pentru a putea obtine max-
imum de performanta. Pentru aceasta, modificari se pot face la nivelul interfetei de
retea sau la nivelul parametrilor de kernel. Parametrii de kernel se pot regla pentru a
determina schimbari ın performanta retelei prin modificarea urmatoarelor fisiere din
/proc/sys/net:
/proc/sys/net/core/rmem_max
/proc/sys/net/core/rmem_default
/proc/sys/net/core/wmem_max
/proc/sys/net/core/wmem_default
/proc/sys/net/ipv4/tcp_stack
/proc/sys/net/ipv4/tcp_timestamps
/proc/sys/net/ipv4/tcp_keepalive_time
/proc/sys/net/ipv4/tcp_mem
/proc/sys/net/ipv4/tcp_rmem
/proc/sys/net/ipv4/tcp_wmem
/proc/sys/net/ipv4/tcp_window_scaling
La nivelul interfeei de retea se pot face reglari prin modificarea setarilor legate de
viteza, modul de lucru (duplex) si a dimensiunii MTU (maximum transmission unit).
La configurarea unui cluster, trebuie tratate doua probleme:
• setarile implicite ale kernelului nu furnizeaza cele mai bune performante pentru
diverse cazuri particulare, si
• numarul cartelelor de retea ce trebuie configurate.
Deoarece soluitile care sa trateze aceasta problema lipsesc, modelul furnizeaza
valorile optime pentru fiecare nod din cluster. Utilizand utilitare adecvate furnizate de
sistemul de operare Linux, aceste valori necesare modificarii parametrilor retelei sunt
disponibile imediat, algorimtul prezentat anterior bazandu-se pe acest lucru. Astfel,
valorile pentru dimensiunea bufferele de send/receive (tcp_rmem si tcp_wmem) pot
fi modificate prin specificarea dimensiunii minime, a celei initiale si a celei maxime
dupa cum urmeaza:
sysctl -w net.ipv4.tcp_rmem="4096 87380 8388608"
sysctl -w net.ipv4.tcp_wmem="4096 87380 8388608"
A treia valoare trebuie sa fie cel mult egala cu wmem_max si rmem_max. Prima valoare
poate fi crescuta pentru retelele de mare vitea pentru ca dimensiunea initiala ferestrei
63
5. Un nou model de optimizare a comunicatiilor ın clustere
sa fie suficient de mare [NetPIPE ]. De asemenea, activarea opinii de scalare a
ferestrei (window scaling) duce la cresterea ferestrei transferate.
Masurarea performantelor retelei clusterului se poate face cu o gama larga de
utilitare ca Iperf [Tirumala ], Netperf [Netperf ] sau NetPIPE (Network Protocol
Independent Performance Evaluator). Deoarece trebuie testate atat performantele
pentru TCP cat si pentru MPI, a fost ales NetPIPE. NetPIPE foloseste pentru testare
transmiterea de mesaje ıntre doua noduri. Pentru a funiza informatii complete, Net-
PIPE modifica dimensiunea mesajului la un interval constant de timp si masoara
perfromantele comunicaiilor punct-la-punct dintre noduri [Turner 03]. Deoarece se
doreste determinarea setarilor pentru diverse cazuri de utilizare, modificarea dimen-
siunii pachetelor utilizate este obligatorie. Acesta este motivul principal pentru care
este utilizat NetPIPE ın implementarea modului de testare. O descriere detaliata a
acestei aplicatii se gaseste ın [Turner 03], [Turner 02] si [Snell 96].
5.4 Rezultate si concluzii
Rezultatele testelor de performanta pentru cei trei parametri kernel utilizati (TCP
windows scaling, TCP read buffer si TCP write buffer). Pentru fiecare parametru
ın parte, graficele au pe coordonata X dimensiunea mesajului iar pe coordonata Y ,
latimea de banda obtinuta.
Linia rosie continua din reprezentarile grafice corespunde latimii de banda disponi-
bile pentru valorii implicite din nucleu. Dimesiunea bufferelor pleaca de la 4KB si la
fiecare pas a algoritmului este dublata fata de valoarea utilizata anterior.
Verificarea acestor rezultate a fost realizata prin transferarea unui fisier de 512
MB ıntre nodurile din cluster. Pentru a nu apare ıntarzieri suplimentare de la disc,
a fost utilizat un ramdrive. Dimensiunea fisierului transferat este de 512 MB din
cauza memoriei disponibile pe noduri de 2GB. Cel mai bun timp de transfer a fost
obtinut atunci cand valorile tcp_rmem si tcp_wmem sunt de 16, respectiv 32KB. In
timpul realizarii testelor de performanta, modelul furnizeaza toate valorile pentru
parametrii de kernel considerati, valori ce pot fi folosite si ın alte scenarii de utilizare
a clusterului. Imbunatatirea utilizarii latimii de banda este prezentata ın Figura 5.2.
Doar folosirea valorilor implicite ale sistemului de operare, latimea de banda disponi-
bila pentru nodurile clusterului nu este optim utilizata, cu efecte imediate asupra
performantelor aplicatiilor. Utilizand modelul propus, comunicatiile dintre nodurile
clusterului sunt sensibil ımbunatatite. Rezultatele prezentate ın figurile anterioare
sunt specifice clusterului din gridul GRAI, unde un volum de date important este
transferat ıntre noduri. Pentru alte cazuri, ca de exemplu utilizarea clusterului ca un
web server farm, rezultatele pot fi diferite. Prin ajustarea parametrilor utilitarului de
test, mdelul propus poate furniza date optime pentru acest scenariu.
64
5.4. Rezultate si concluzii
+32%724
547
+48%715
480
+87%695
371
0
100
200
300
400
500
600
700
800
before after
Ban
dwid
th
wscalling wmem rmem
Figura 5.2: Avantajele utilizarii modelului propus [Rusan si Amarandei 10]
65
Capitolul 6
Tehnici de gestiune a resurselor
ın clustere
6.1 Definirea problemei
Aplicatiile de management a resurselor precum Condor, SGE sau PBS sunt orientate
ın special pe optimizarea globala ın privinta unor metrici de performanta precum
timpul de terminare, gradul de utilizare a sistemelor etc. Pe un cluster partajat, unde
numarul de aplicatii este semnificativ mai mare decat numarul de noduri, este necesara
o partajare a resurselor ıntre aplicatii. Aceste clustere, de obicei, sunt utilizate de
grupuri de utilizatori (de exemplu un colectiv de cercetare al unui departament dintr-o
universitate) pentru a rula diverse aplicatii, simulari, compilari distribuite etc. Cand
mai multe servicii partajeaza acelasi server, fiecare primeste o parte din resursele
disponibile. Fiecare serviciu trebuie sa fie capabil sa-si utilizeze partea de resurse
primite ca si cum ar rula singur ın cluster [Amarandei 10].
Abordarile solutiilor de management de resurse traditionale prezinta doua pro-
bleme. Un prim neajuns ar fi faptul ca aplicatiile sunt trate ın mod egal la realizarea
optimizarilor. Aceste solutii ignora cererile variate de resurse ale utilizatorilor pe baza
nevoilor imediate sau a importantei acestora. Al doilea neajuns este ca ın sistemle
unde cererile depasesc resursele disponibile, probabilitatea ca resursele clusterului sa
fie suprasolicitate este ridicata [Chun 00].
Daca consideram urmatorul scenariu ([Amarandei 10]), ın care un cluster dintr-o
universitate are numerosi utilizatori, profesori si studenti, cu urmatoarele restrictii de
utilizare:
• utilizarea resurselor precum procesor si memorie trebuie alocate profesorilor
(50%), studenilor (30%) si pentru sistem (20%);
• numarul maxim de procese permise trebuie sa fie distincte ıntre grupurile de
utilizatori ( de exemplu maxim 50 procese pentru fiecare cont de student);
67
6. Tehnici de gestiune a resurselor ın clustere
• utilizarea latimii de banda disponibila din reteaua clusterului trebuie repartizata
astfel ıncat sistemul de fisiere (NFS) partajat ın retea sa aiba alocat ıntre 40 si
60% din disponibil, 5% sa fie alocat sistemului de operare si pentru middleware,
iar restul sa fie disponibil pentru aplicatiile utilizatorilor. Daca ramane latime
de banda neutilizata, aceasta trebuie safie disponibila aplicatiilor utiliatorilor.
Implementari ale tehnicilor de alocare a resurselor includ sistemul Sharc
[Urgaonkar 04], un sistem de management proportional bazat pe cereri descris ın
[Chun 00], partajarea si izolarea ın cadrul sistemelor multiprocesor cu memorie co-
muna [Urgaonkar 02] si Control Groups [cgroups ].
Pentru rezolvarea acestor probleme, vom prezenta ın continuare un model de
proiectare a politicilor de rezervare a resurselor si implementarea acestora ın clustere.
6.2 Arhitectura sistemului de management a resurselor
Modelul propus pentru managementul resurselor, descris ın Figura 6.1, are doua
componente majore [Amarandei 10]: Management Control Unit (MCU) instalat pe
nodul de management al clusterului sau pe front-end (Figura 4.2) si agentii de control
(Control Agent - CAg).
Instalarea acestor componete este realizata prin intermediul softului de manage-
ment al clusterului. Management Control Unit este componenta principala a mode-
lului si controleaza agentii de control, politicile de alocare a resurselor prin modulule
Resource Reservation policy (RR) si Rule Management (RM), iar pentru a determina
latimea de banda disponibila realizeaza testele de performanta folosind modulul de
optimizare a comunicatiilor (Communications Optimization module - CO). Acest ul-
Distributed/shared filesystem
Clu
ster
mid
dle
war
e
Manage filesystems
MCU
LAD module
Comm module
CLAM module
RR policy
RM logic
Cluster CO
module
Cluster management
Cluster Node(s)
User application
CAg
OS kernel
No. of processes
CPU time
Memory limit
Disk quota
Process priority
Network bandwidth
Resource reservation module
Local application detection module
Communication module
Communications optimization
module
Deploy CAg
Deploy Management Control Unit
Legend: CAg – Control Agent RR – Resource Reservation RM – Rule Management CO – Communications Optimization Comm – Communications CLAM – Control Logic & Agent Monitor LAD – Local Application Detection MCU – Management Control Unit
CA comm
Figura 6.1: Arhitectura sistemului de management a resurselor [Amarandei 10]
tim modul este prezent si ın cadrul agentilor de control iar functionalitatea a fost
descrisa in Capitolul 5.2 si ın [Rusan si Amarandei 10]. Acest modul este utilizat de
68
6.3. Implementare
fiecare data cand configuratia hardware sau scopul ın care este utilizat clusterul se
schimba.
Un modul de realizare a comunicatiilor ( Communication Module - CM ) este
prezent ın ambele componente MCU si CAg pentru a realiza comunicatiile dintre
acestea. Pentru detectarea aplicatiilor pornite de utilizatori, un modul denumit Local
Application Detection (LAD) este folosit de ambele componente.
Politicile de utilizare a resurselor sunt stocate ın fisiere de configurare si dis-
tribuite la nodurile clusterului de catre MCU. Agentii de control sunt responsabili de
implementarea acestor politici prin ıncarcarea lor din fisierele de configurare si mon-
itorizarea activitatii de pe noduri. MCU utilizeaza modulul Control Logic & Agent
Monitor (CLAM) pentru urmarirea starii agentilor si notificarea acestora ın cazul
schimbarii politicilor de alocare.
6.3 Implementare
Implementarea prototipului solutiei propuse ın paragraful anterior presupune utilzarea
unor tehnologii ce sunt prezentate ın cele ce urmeaza.
Un set de mecanisme este utilizat pentru restrictionarea traficului ıntr-o retea de
calculatoare si aplicarea lui ıl reprezita TC(Traffic Control). Este utilizat cu predilectie
pentru a acorda prioritate unui anumit tip de trafic, pentru a limita rata de transfer
folosita sau pentru a bloca un anumimt tip de trafic [Almesberger 02]. O descriere de-
taliata a arhitecturii TC ın cadrul nucleului Linux poate fi gasita ın [Almesberger 02],
[Almesberger 99] si [diffserv ].
Pe un sistem Linux, majoritatea utilizatorilor au acces nelimitat la resurse pre-
cum CPU si memorie. Daca nu sunt aplicate restrictii, utilizatorii pot rula cod rau
intentionat (malicious code) ce poate duce exploatarea unor brese de securitate sau
chiar pot provoca un atac de tip refuzare serviciu (Denial of Service). Deoarece
scrierea unor programe de acest tip nu necesita cunostinte avansate de programare,
pot cauza blocarea sistemului sau pot aduce ıntarzieri semnificative ın raspunsul
acestuia la alte aplicatii. Resursele alocate utilizatorilor sau grupurilor pot fi limitate
folosind fisierul /etc/security/limits.conf disponobil pe orice sistem Linux si
controlat prin modulul PAM (Pluggable Authentication Modules) numit pam_limits
a carui descriere detaliata se gaseste ın [Morgan 10].
Adaugarea politicilor pentru utilizarea procesorului, a memoriei si a numarului
de procese pe care un utilizator le poate rula pe fiecare nod din cluster reprezinta o
tinta usor de atins. Cu toate acestea, modulele Local Application Detection, Resource
Reservation andsi Rule Management Logic sunt cel mai dificil de implementat datorita
faptului ca aplicatiile care utilizeaza reteaua trebuie detectate ın timp real. Acelasi
lucru este valabil si ın cazul schimbarii politicilor. De asemenea, este posibil ca
aplicatiile care au alocate resurse sa nu suporte mecanisme de tip checkpoint precum
69
6. Tehnici de gestiune a resurselor ın clustere
un transfer de fisiere. Aceste aplicatii trebuie sa ruleze ın continuare, dar ın noile
conditii stabilite de politicile de alocare [Amarandei 10].
De exemplu, daca pentru grupul studenttilor este alocata 25% din latimea de
banda disponibila, toate aplicatiile pornite de utilizatorii acestui grup trebui sa se
ıncadreze ın aceasta restrictie. Prezenta acestei restrictii seminifica faptul ca utiliza-
torii vor obtine performante diferite pentru aplicatiile lor ın functie de numarul utiliza-
torilor din grup activi si de aplicatiile rulate de acestia. Presupunem ın cadrul aces-
tui scenariu, ca administratorul clusterului schimba politicile de alocare a latimii de
banda pentru grupul studentilor la 20% din disponibil cu un maxim de 30% daca este
banda neutilizata. ın acest caz, aplicatiile vor continua rularea, dar ın conditiile noilor
politici. Aceste politici de alocare sunt luate ın considerare de kernelul Linux imediat,
iar utilizatorii pot observa fluctuatii ale parametrilor de performanta ai aplicatiilor
pana cand noile politici devin active ın tot clusterul [Amarandei 10].
Resource K
1st reservation y1%
Default x%
Nth reservation yn%
Inst
ance
1 (
x/n
%)
Inst
ance
n (
x/n
%)
Inst
ance
1 (
y n/n
%)
Inst
ance
n (
y n /n
%)
Resource 1
1st reservation y1%
Default x%
Nth reservation yn%
Inst
ance
1 (
x/n
%)
Inst
ance
n (
x/n
%)
Inst
ance
1 (
y n/n
%)
Inst
ance
n (
y n /n
%)
Resource 1
1st reservation y1%
Default x%
Nth reservation yn%
Inst
ance
1 (
x/n
%)
Inst
ance
n (
x/n
%)
Inst
ance
1 (
y n/n
%)
Inst
ance
n (
y n /n
%)
Figura 6.2: Partitionarea resurselor [Amarandei 10]
Pentru implementarea politicilor de alocare, resursele sunt ımpartite ın clase de
prioritati definite separat pentru fiecare utilizator. O clasa speciala, numita Default,
este creata pentru fiecare tip de resursa ın parte (CPU, memorie, latimer de banda
etc) asa cum se poate observa ın Figura 6.2. Cererile care nu se ıncadreaza ın una
din clasele de prioritate definite explicit, sunt alocate clasei Default. Cererile de
resurse ale utilizatorilor care se ıncadreaza ıntr-o anumita clasa, partajeaza ın mod
egal resursele rezervate de clasa respectiva.
6.4 Rezultate si concluzii
Testarea modelului propus a fost realizata pe clusterul AC al gridului GRAI descris
ın Capitolul 4.3. Pe acest cluster, aplicatiile rulate de utilizatori sunt urmarite si
politicile definite sunt aplicate asupra acestora. A fost aleasa urmarirea si limitarea
70
6.4. Rezultate si concluzii
accesului la latimea de banda disponibila. Se considera cazul transferului unui fisier
cu dimensiunea 330MB iar utilizatorii trebuie sa partajeze ın mod egal latimea de
banda disponibila.
Pentru analiza modelului ın cazul unui mediu de lucru real, au fost realizate
teste cu 18 conturi pentru studensi active la un moment dat. Datorita faptului ca
reprezentarea rezultatelor pentru toate cele 18 conturi concurente active nu poate fi
citita, ın Figurile 6.3a si 6.3b sunt prezentate doar rezultatele pentru doar 4 utilizatori.
Pentru cazul ın care nu se aplica nici o politica de rezervare, timpul de transfer
este ıntre 25 si 27 secunde (Figura 6.3a). Fiecare utilizator ocupa cat mai mult posibil
din latimea de banda disponibila. Dupa definirea restrictiilor si aplicarea acestora,
timpul de transfer se modifica corespunzator iar rata de transfer a celor 4 utilizatori
nu depaseste 250Mb/sec (Figura 6.3b). Pentru cazul celor 18 utilizatori, rata de
transfer este de aproximativ 50Mb/sec [Amarandei 10].
O alocare echitabila a resursei alese a fost obtinuta ın urma utilizarii modelului
propus. Politicile de rezervare, odata definite, pot fi usor aplicate ın tot clusterul.
Datorita adoptarii Control Groups ın nucleul ce este furnizat ıncepand cu Red Hat
Enterprise Linux 6, dezvlotarea ulterioara a modelului propus include compatibilitatea
cu aceasta noua facilitate.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
0
5000000
10000000
15000000
20000000
25000000
30000000
35000000
40000000
45000000
50000000
Client 1 Client 2 Client 3 Client 4
transfer time (sec)
tran
sfer
rat
e (M
b/se
c)
(a)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
0
5000000
10000000
15000000
20000000
25000000
30000000
Client 1 Client 2 Client 3 Client 4
transfer time (sec)
tran
sfer
rat
e (M
b/se
c)
(b)
Figura 6.3: Utilizarea latimii de banda de catre 4 utilizatori cu (a) si fara (b)restrictii asupra ratei de transfer [Amarandei 10]
71
Capitolul 7
Concluzii, contributii si directii
viitoare de cercetare
7.1 Concluzii
Domeniul calculului de ınalta performanta vizeaza optimizarea aplicatiilor prin adop-
tarea unor solutii eficiente de paralelizare/distribuire, solutii ce urmaresc ın special
reducerea timpilor de raspuns si, eventual, cresterea acuratetii raspunsurilor oferite.
Rezultatele cercetarilor aferente acestui domeniu influenteaza dramatic performantele
celorlalte domenii ce se bazeaza pe tehnologii de calcul paralel/distribuit. Reduce-
rea timpului de calcul ın rezolvarea unei probleme reprezinta principala motivatie ce
ghideaza nevoia de paralelizare/distribuire eficienta a solutiilor secventiale existente.
Mai mult, odata cu evolutia tehnologiilor hardware si software suport, apar noi opor-
tunitati de ımbunatatire a solutiilor existente sau de dezvoltare a unor solutii noi, mai
eficiente. Regasirea informatiilor ın domeniul economic, regasirea de informatii pe
Web, cercetarile ın domeniul geneticii, procesarea imaginilor medicale, bioingineria,
meteorologia sunt doar cateva dintre cele mai importante domenii ce pot beneficia
din plin de aceste schimbari. Astfel, cercetatorii implicati ın aceste domenii utilizeaza
cele mai noi tehnologii din domeniul calculului de mare performanta pentru a rezolva
probleme din ce ın ce mai complexe, ın timp cat mai scurt.
Aparitia tehnologiilor suport a dus la cresterea asteptarilor privitoare la perfor-
mantele instrumentelor software si hardware. Se urmareste realizarea de aplicatii
care sa ofere solutii ıntr-un timp acceptabil la probleme de o complexitate din ce ın
ce mai ridicata. Pentru atingerea acestui obiectiv, nu este suficienta doar cresterea
performantelor sistemului de calcul. In mod uzual se recurge una din urmatoarele
doua abordari: fie se reproiecteaza integral aplicatia, fie, ın cazul unor costuri foarte
mari de reproiectare, se urmareste dezvoltarea unor solutii destinate sistemelor de cal-
cul paralel/distribuit. Ambele abordari solicita din partea dezvoltatorului de aplicatii
73
7. Concluzii, contributii si directii viitoare de cercetare
sa studierea unor tehnici noi de implementare si proiectare. Solutiile oferite trebuie
sa fie proiectate astfel ıncat sa ruleze pe arhitecturi hardware din ce ın ce mai com-
plexe, cu un pronuntat caracter dinamic. Mai mult, trebuie considerata posibilitatea
integrarii rapide a tehnologiilor noi, ceea ce confera un grad ridicat de complexitate
acestui domeniu.
In acest context, prima parte a Capitolului 2 este dedicata analizei tehnicilor
de dezvoltare a unei aplicatii paralele. Accentul cade pe etapele de proiectare si
pe cele de analiza cantitativa si calitativa a acestui tip de aplicatii. Modelele exis-
tente de proiectare implica parcurgerea urmatoarelor etape: analiza problemei si a
activitatilor de calcul; ımpartirea activitatilor ın subactivitati cu un grad ridicat de
independenta; identificarea interactiunilor dintre subactivitati si definirea sistemului
de calcul ce poate fi utilizat pentru rezolvarea problemei. Un model descris ın acest
capitol, ce permite realizarea unor aplicatii scalabile si modulare este modelul de tip
task-canale de comunicatii. Acest model furnizeaza mecanismul numit dependenta
de date, mecanism ce presupune ca un task, pentru a-si putea continua executia,
poate avea nevoie de acces la datele aflate ın memoria locala ce apartine altor task-
uri. O serie de alte modele de programare sunt trecute ın revista: transmitere de
mesaje, paralelism de date, memorie partajata. Diferentele dintre aceste modele
sunt date de mecanismele de interactiune dintre task-uri, granularitatea acestora,
suportul pentru pozitionare si modularitate. Pentru a putea trece de la modelele
de aplicatii paralele, la scrierea efectiva a codului, trebuie parcurse o serie de etape
de proiectare. Metodologia de proiectare, ın prima faza, pune accent pe paralelism,
scalabilitate si descoperirea algoritmului ce ındeplineste aceste cerinte. Se urmareste
ca, pornind de la problema data, sa se identifice posibilitatile de paralelizare si sa
determinae necesarul de comunicatii dintre activitatile paralele rezultate. Faza a
doua, este axata pe probleme legate de performanta solutiei gasite si pe identificarea
modalitatilor de ımbunatatire a acestora. Se pune accent pe evaluarea rezultatelor
obtinute ın prima faza, considerand costurile implicate. Daca este posibil se trece la
gruparea activitatilor de calcul astfel ıncat sa fie satisfacute si cerintele de utilizare
maxima a procesoarelor si de minimizare a costurilor de comunicatie. In finalul aces-
tui capitol este tratata si problema echilibrarii ıncarcarii ın sistemele de calcul de mare
performanta. Sunt detaliate tehnicile existente de solutionare a acestei probleme, pre-
cum si posibilitatile de implementare. In acest context sunt analizate performantele
unor algoritmi de echilibrare a ıncarcarii ce au fost implementati utilizand o platforma
de agenti mobili. Pentru comparatie, aceiasi algoritmi au fost implementati si ın medii
de tip message passing.
Odata ce a fost dezvoltata o aplicatie paralela, validarea parametrilor ce afecteaza
performanta aplicatiei si rezultatele produse este deosebit de importanta. O posibila
solutie ın acest sens este reprezentata de validarea prin metode experimentale. In
Capitolul 3 a fost propus un model propriu de proiectare si testare a unei aplicatii
paralele, model care extinde abordarile existente prin tehnici de proiectare a experi-
74
7.1. Concluzii
mentelor. Un plus al abordarii propuse este posibilitatea estimarii performantelor unei
aplicatii ın cazul rularii ın conditii diferite si/sau cu alti parametri fata de cazurile
particulare ale testelor initiale. Aceste obiective pot fi atinse utilizand metode de
analiza statistica ce permit o identificare mai usoara a erorilor ce apar ın fiecare etapa
de proiectare. Metoda propusa faciliteaza eliminarea factorilor care nu au influenta
asupra raspunsului analizat al aplicatiei, oferind ın acelasi timp o mai buna perspec-
tiva asupra factorilor care au cel mai mare impact asupra performantelor. Modelul
prezentat permite proiectantului unei aplicatii paralele sa estimeze performantele cu
parametri de intrare reali fara a rula efectiv aplicatia.
Solicitarile legate de performantele unui sistem de calcul au dus la apatia unor
concepte si modele noi, precum sistemele Grid sau tehnologiile de tip Cloud com-
puting. Aceste modele ofera solutii pentru rezolvarea unor probleme ce depasesc
puterea de calcul a unui calculator sau a unui cluster de calculatoare. Capitolul 4
este dedicat cerintelor impuse ın implementarea conceptelor sistemelor Grid. Este
prezentat cazul particular al gridului GRAI, ımpreuna cu provocarile ridicate de im-
plementarea acestuia. Construirea unei infrastructuri Grid presupune ımbinarea de
sisteme de operare, middleware-uri si instrumente de instalare si configurare diferite.
Problemele adresate ın cursul implementarii solutiei vizeaza alegerea dispozitivelor
hardware adecvate, a infrastructurii de retea, proiectarea clusterelor, instalarea sis-
temului de operare si a instrumentelor de administrare, ınglobarea tehnologiilor de
securitate, testarea diferitelor instrumente si aplicatii disponibile.
Sistemele Grid sunt sisteme de calcul de mare performanta eterogene, fapt ce
poate atrage dupa sine diferite probleme legate de exploatarea lor eficienta. Nu-
cleul acestor sisteme este reprezentat de clusterele destinate calculului sau stocarii de
date. Capitolul 5 este dedicat ımbunatatirii performantelor aplicatiilor care ruleaza
pe un cluster. Este abordata problematica legata de performantele retelelor de inter-
conectare interne clusterelor, scopul principal fiind reducerea timpilor de comunicatii.
In mod normal, aplicatiile intensive computational genereaza foarte putin trafic si
dependenta de performantele retelei de comunicatii este minima. Pe de alta parte,
o aplicatie de tip data intensive poate genera un volum mare de trafic. Astfel,
eficienta acestui tip de aplicatii este direct dependenta de performantele retelei de
comunicatii. In acest scop, a fost proiectat si implementat un model de ımbunatatire
a performantelor retelei de interconectare a unui cluster. Problema adresata de acest
model este reducerea timpului de transfer dintre noduri. Solutia oferita nu implica
modificarea sau reproiectarea aplicatiilor existente, fapt ce constituie un atu deosebit
de important al modelului propus: practic sunt eliminate costurile suplimentare im-
plicate de adaptarea aplicatiei la eventualele modificari hardware ce pot aparea ın
sistem.
Dupa cum a fost mentionat anterior, sistemele Grid intra ın categoria sistemelor
neomogene de calcul distribuit. Pentru utilizatorii finali este importanta identifi-
carea, ın cadrul acestor sisteme, a unor resurse care sa ofere un timp acceptabil de
75
7. Concluzii, contributii si directii viitoare de cercetare
rezolvare al problemelor. Urmarind aceasta idee, ın Capitolul 6, sunt prezentate o
serie de probleme care apar la partajarea resurselor de calcul. O atentie deosebita
este acordata tehnicilor de management a resurselor si a implementarii acestora ın
clustere. In prezent, solutiile existente ce rezolva aceste probleme se bazeaza pe
functii de biblioteca ce presupun modificarea aplicatiilor, pe introducerea unor noi
module de nucleu, pe utilizarea unor versiuni personalizate ale nucleului sistemului
de operare sau pe modificarea planificatorului. Versiunile recente ale nucleului Linux
includ mecanisme noi pentru partitionarea resurselor (Control Groups), mecanisme
ce sunt utilizate cu precadere ın virtualizarea resurselor de calcul, precum si ın sis-
temele de tip Cloud. Aceste tehnici nu pot fi ınsa utilizate pe clustere unde nu se pot
instala, din diverse motive, aceste versiuni noi. Solutia propusa ın acest capitol se
adreseaza direct acestei situatii, destul de frecvent ıntalnita. Este introdus un sistem
de management al resurselor, implementat folosind o arhitectura de tip client-server.
Utilizand acest sistem, sunt propuse o serie de tehnici de alocare dinamica de resurse,
pe baza unor politici de rezervare, ın functie de tipul utilizatorilor. Folosirea acestor
tehnici nu implica decat simpla definire a unor politici de alocare/rezervare de resurse.
Avantajele acestei abordari deriva din faptul ca se utilizeaza software-ul deja instalat
pe cluster si nu se solicita modificari la nivelul sistemului de operare sau al aplicatiilor.
7.2 Contributii
Contributiile aduse ın cadrul acestei lucrari s-au conturat ın jurul urmatoarelor directii
de cercetare:
1. Furnizarea unui model de proiectare si analiza a aplicatiilor paralele cu
ajutorul metodei de proiectare statistica a experimentelor.
• Analiza metodelor clasice de proiectare a aplicatiilor paralele, de analiza
a performantelor acestora si problema echilibrarii ıncarcarii
[Sova si Amarandei 04], [Teodoru si Amarandei 07].
• In vederea ımbunatatirii metodelor de proiectare a aplicatiilor paralele,
a fost propusa o metoda de descriere a unei aplicatii si de analiza a
performantelor acesteia. Rezultatele obtinute au demonstrat atat eficenta
acestei metode ın detectarea erorilor de proiectare cat si posibilitatea
studierii comportamentului real al aplicatiei pe un set redus de teste
[Amarandei 11].
2. Proiectarea si implementarea unei infrastructuri Grid
• Proiectarea si implementarea infrastructurii hardware si software pentru
site-ul grid GRAI ([Amarandei 08]).
• Analiza tehnicilor de implementare a clusterelor si diverse sisteme Grid
ın scopul realizarii infrastructurii hardware si software a gridului GRAI
([Aflori si Amarandei 05], [Amarandei 06], [Teodoru si Amarandei 07],
[Archip si Amarandei 08], [Arustei si Amarandei 07],
76
7.3. Directii viitoare de cercetare
[Archip si Amarandei 07]).
3. Definirea unui nou model de optimizare a comunicatiilor ın clusterele
membre ale sistemelor grid
• Definirea unui model de optimizare a comunicatiilor
([Rusan si Amarandei 10]).
• Realizarea unui algoritm ce implementeza modelul propus.
4. Definirea si implementarea unor technici eficiente de gestionare a resur-
selor ın clustere
• Analiza tehnicilor de gestionare a resurselor disponibile ın clustere
([Amarandei 08], [Rusan si Amarandei 10]).
• Definirea arhitecturii unui sistem de gestiune a resurselor si partitionarea
acestora ([Amarandei 10]).
7.3 Directii viitoare de cercetare
Clusterele de calculatoare reprezinta ın continuare nucleul ultimelor tendinte ın dome-
niul calculului de mare performanta. Tehnologiile de tip Grid si cloud computing
se bazeaza pe clustere cat mai performante pentru a putea asigura un nivel core-
spunzator al serviciilor. Furnizarea unor servicii de calitate presupune atat proiectarea
corespunzatoare a aplicatiilor care vor oferi aceste servicii, cat si utilizarea eficienta a
sistemelor de calcul. Asa cum am amintit ın Capitolul 3, ın proiectarea aplicatiilor par-
alele trebuie considerata identificarea factorilor care au o influenta deosebita asupra
performantlor. Simpla implicarea proiectantului si a programatorului de aplicatii par-
alele nu este uneori suficienta ın realizarea modelului ce descrie comportamentul
aplicatiei. La testarea fuctionalitatii si performantelor unei aplicatii paralele trebuie
avute ın vedere si posibile influente din partea mediului ın care aceasta ruleaza. Din
acest motiv, ın modelul unei aplicatii ar putea fi inclusi factori ce tin posibilitatile
oferite de compilatoare pentru optimizarea codului, de optimizarile ce se pot face
la nivelul bibliotecilor utilizate (de expemplu MPI sau OpenMP) sau chiar la nivelul
sistemului de operare. In cazurile ın care rescrierea/adaptarea unei aplicatii par-
alele existente implica un set suplimentar de costuri ridicate, o posibila abordare este
reprezentata de adaptarea dinamica a mediului ın care ruleaza aplicatia. In acest
context metodele de analiza a aplicatiilor bazate pe DoE pot fi extinse prin consider-
area unor factori externi aplicatiei ın sine. De exemplu, pentru aplicatiile MPI se pot
include ın modelul de analiza parametrii de configurare ai middleware-ului MPI suport
sau chiar parametrii subsistemului de comunicatii al sistemului de operare gazda.
Asa cum s-a aratat ın Capitolul 5, performantele unui cluster sunt direct influentate
de parametrii sistemului de operare care ruleaza pe nodurile componente. Valorile
acestor parametri pot fi luate ın considerare la realizarea modelului unei aplicatii para-
lele. Sistemul de management al resurselor, prezentat ın Capitolul 6, poate beneficia
de utilizarea tehnicilor de proiectare statistica a experimentelor. Aceste tehnici pot
77
7. Concluzii, contributii si directii viitoare de cercetare
furniza un model de performanta al parametrilor sistemului de operare.
In cadrul Capitolului 6, a fost mentionat faptul ca sistemele de management
al joburilor iau ın considerare pentru stabilirea politicilor de rezervare a resurselor
informatii precum numarul de procesoare solicitate, memoria disponibila, ıncarcarea si
arhitectura sistemelor de calcul din clustere. Acest lucru poate reprezenta o problema
datorita faptului ca nu toti utilizatorii unui cluster folosesc sistemul de management
al job-urilor. Este frecvent cazul ın care utilizatorii unui cluster au cont cu acces la
shell si prefera sa utilizeze aceste facilitati pentru a rula aplicatii ocolind job man-
ager -ul. Aceste cazuri introduc ıncarcari suplimentare pe nodurile unui cluster, ce
pot ıngreuna activitatea planificatoarelor de job-uri. O posibila directie de dezvoltare
pentru solutia propusa ar fi extragerea informatiilor de la job manager -ul ce ruleaza
ın cluster si utilizarea lor ın rezervarea dinamica de resurse. Majoritatea planifica-
toarelor de job-uri pot fi interogate prin intermediul DRMAA (Distributed Resource
Management Application API ). Plecand de la acest lucru, posibilitatea de extindere
este imediata. Se poate interoga job managerul prin intermediul DRMAA pentru a
extrage informatii despre job-urile planificate si resurele socilitate. Aceste date pot
fi utilizate pentru a revizui politicile de rezervare de resurse existente. Desi metoda
propusa se adreseaza managementului clusterelor, avantajul pentru sistemele de tip
Grid sau Cloud computing sunt imediate. Administratorul poate defini politici de
rezervare a resurselor pentru clusterul pe care ıl gestioneaza si ın functie de cerintele
pe care trebuie sa le ındeplineasca ın cadrul sistemului Grid sau Cloud din care face
parte.
78
Bibliografie
[Aflori si Amarandei 05] C. Aflori, M. Craus, I. Sova, C. Butincu F. Leon & C.M. Amarandei.
Grid - tehnologii si aplicatii. Politehnium, 2005. [citat la p. 51, 52, 76]
[Almesberger 99] W. Almesberger. Linux Network Traffic Control - Implementation
Overview. In roceedings of 5th Annual Linux Expo, pages 153–164,
Raleigh, NC, May 1999. [citat la p. 69]
[Almesberger 02] Werner Almesberger. Linux Traffic Control - Next Generation. In
Proceedings of the 9th International Linux System Technology Con-
ference, pages 95–103, September 2002. [citat la p. 69]
[Amarandei 06] C.M. Amarandei, A. Archip & S. (Caraiman) Arustei. Performance
Study for MySQL Database Access within Parallel Applications.
Buletinul Institutului Politehnic din Iasi, Automatic Control and
Computer Science Section, vol. LVI, no. LII, pages 127–134, 2006.
[citat la p. 58, 76]
[Amarandei 08] C.M. Amarandei, A. Rusan, A. Archip & S. (Caraiman) Arustei.
Scientific and educational grid applications, chapitre On the Devel-
opment of a GRID Infrastructure, pages 13–23. Politehnium, Iasi,
Romania, 2008. [citat la p. 53, 54, 56, 58, 76, 77]
[Amarandei 10] C. M. Amarandei & A. Rusan. Techniques for effcient resource
management on shared clusters. In Proceedings of ECIT2010 - 6th
European Conference on Intelligent Systems and Technologies, Iasi,
Romania, October 2010. [citat la p. 67, 68, 70, 71, 77]
[Amarandei 11] C. M. Amarandei, D. Lepdatu & S. Caraiman. Improving the De-
sign of Parallel Applications Using Statistical Methods. Journal of
Applied Sciences, vol. 11, no. 6, pages 932–942, January 2011.
http://dx.doi.org/10.3923/jas.2011.932.942. [citat la p. 30,
33, 34, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 76]
[Archip si Amarandei 07] A. Archip, C.M. Amarandei, S. (Caraiman) Arustei & M. Craus.
Optimizing Association Rule Mining Algorithms using C++ STL
Templates. Buletinul Institutului Politehnic din Iasi, Automatic Con-
trol and Computer Science Section, vol. LVII, no. LIII, pages 123–
132, 2007. [citat la p. 77]
79
Bibliografie
[Archip si Amarandei 08] A. Archip, S. (Caraiman) Arustei, C.M. Amarandei & A. Rusan.
Scientific and educational grid applications, chapitre On the de-
sign of Higher Order Components to integrate MPI applications
in Grid Services, pages 25–35. Politehnium, Iasi, Romania, 2008.
[citat la p. 76]
[Arustei si Amarandei 07] S. (Caraiman) Arustei, A. Archip & C.M. Amarandei. Parallel
RANSAC for Plane Detection in Point Clouds. Buletinul Institu-
tului Politehnic din Iasi, Automatic Control and Computer Science
Section, vol. LVII, no. LIII, pages 139–150, 2007. [citat la p. 76]
[Barnes 08] Bradley J. Barnes, Barry Rountree, David K. Lowenthal, Jaxk
Reeves, Bronis de Supinski & Martin Schulz. A regression-based ap-
proach to scalability prediction. In ICS ’08: Proceedings of the 22nd
annual international conference on Supercomputing, pages 368–377,
New York, NY, USA, 2008. ACM. [citat la p. 32, 41]
[Box 78] G. E. P. Box, W. G. Hunter & J. S. Hunter. Statistics for experi-
menters: An introduction to design, data analysis, and model build-
ing. John Wiley and Sons, New York, NY, USA, 1978. [citat la p. 32]
[cgroups ] cgroups. cgroups. Website. http://www.linuxhq.com/ kernel/
v2.6/24-rc3/Documentation/cgroups.txt. [citat la p. 68]
[Chun 00] Brent N. Chun & David E. Culler. Market-based Proportional Re-
source Sharing for Clusters. Technical Report CSD-00-1092, Uni-
versity of California at Berkeley, 2000. [citat la p. 67, 68]
[Cole 89] M. Cole. Algorithmic skeletons: structured management of parallel
computation. MIT Press, 1989. [citat la p. 10]
[Cortes 98] A. Cortes, A. Ripoll, M.A. Senar, F. Cedo & E. Luque. On the con-
vergence of SID and DASUD load-balancing algorithms. Technical
report, Universitat Autonoma de Barcelona, 1998. [citat la p. 23]
[Sova si Amarandei 04] I. Sova, C.M. Amarandei & I. Gavrila. Dynamic Load Balancing in
Tree-Topology Distributed Mobile Agents System. In Proceedings
of the Eighth International Symposium on Automatic Control and
Computer Science, 2004. [citat la p. 23, 24, 25, 26, 27, 76]
[Sova 06] I. Sova. Aplicatii ale agentilor inteligenti ın sisteme informatice
bazate pe cunostinte. Tehnopress, 2006. [citat la p. 23, 24]
[diffserv ] diffserv. Differentiated Services on Linux. Website. http://
diffserv.sourceforge.net. [citat la p. 69]
[Dunigan 02] T. Dunigan, M. Mathis & B. Tierney. A TCP tuning daemon. In
Proceedings of the 2002 ACM/IEEE conference on Supercomputing,
2002. [citat la p. 60, 62]
[Foster 95] I. Foster. Designing and building parallel programs. Addison-Wesley,
1995. [citat la p. 10, 12, 15, 16, 29, 33]
80
Bibliografie
[Foster 01] I. Foster, C. Kesselman & S. Tuecke. The Anatomy of the Grid:
Enabling Scalable Virtual Organizations. International Journal of
High Performance Computing Applications, vol. 15, no. 3, pages
200–222, 2001. [citat la p. 51]
[Foster 02] I. Foster. What Is the Grid? A Three Point Checklist. Grid Today,
vol. 1, no. 6, 2002. [citat la p. 51]
[Gergel 06] Victor P. Gergel. Introduction to Parallel Programming.
University of Nizhni Novgorod, November 2006. https:
//www.facultyresourcecenter.com/curriculum /pfv.aspx?
ID=6594&Login=. [citat la p. 11, 12]
[Grigoras 00] D. Grigoras. Calcul paralel. de la sisteme la programarea aplicatiilor.
Agora, 2000. [citat la p. 11, 17, 18]
[Gustedt 09] Jens Gustedt, Emmanuel Jeannot & Martin Quinson. Experimental
Methodologies for Large-Scale Systems: a Survey. Parallel Process-
ing Letter, vol. 19, no. 3, pages 399–418, Sept 2009. [citat la p. 29]
[Hammond 99] K. Hammond & G. Michaelson (editors). Research directions in par-
allel functional programming. Springer-Verlag, 1999. [citat la p. 10,
11]
[Isaic-Maniu 06] Alexandru Isaic-Maniu & Viorel Voda Gh. Proiectarea statistica a
experimentelor: fundamente si studii de caz. Editura Economica,
2006. [citat la p. 31]
[Ivan 04] I. Ivan & C. Boja. Metode statistice in analiza software. Editura
ASE, 2004. [citat la p. 32]
[Jacobson 92] V. Jacobson, R. Braden & D. Borman. RFC1323 TCP Extensions
for High Performance. Website, May 1992. http://www.ietf.
org/rfc/rfc1323.txt. [citat la p. 62]
[Jain 91] R. Jain. The art of computer system performance and analysis. John
Wiley and Sons, New York, NY, USA, 1991. [citat la p. 31, 32]
[Kitchenham 02] Barbara A. Kitchenham, Shari Lawrence Pfleeger, Lesley M. Pickard,
Peter W. Jones, David C. Hoaglin & Khaled El Emam. Preliminary
Guidelines for Empirical Research in Software Engineering. IEEE
Transactions on Software Engineering, vol. 28, no. 8, pages 721–
734, 2002. [citat la p. 32]
[Kleijnen 04] J.P.C. Kleijnen, S.M. Sanchez, T.W. Lucas & T.M. Cioppa. A
User’s Guide to the Brave New World of Designing Simulation Ex-
periments. INFORMS Journal on Computing, vol. 17, no. 3, pages
263–289, 2004. [citat la p. 32]
[Kwiatkowski 02] Jan Kwiatkowski. Evaluation of Parallel Programs by Measurement
of Its Granularity. In PPAM ’01: Proceedings of the th Interna-
tional Conference on Parallel Processing and Applied Mathematics-
Revised Papers, pages 145–153, London, UK, 2002. Springer-Verlag.
[citat la p. 17, 18]
81
Bibliografie
[Law 99] Averill M. Law & David M. Kelton. Simulation modeling and anal-
ysis. McGraw-Hill Higher Education, 1999. [citat la p. 31]
[Molnar 08] Steven Molnar, Michael Cox, David Ellsworth & Henry Fuchs. A
sorting classification of parallel rendering. In ACM SIGGRAPH ASIA
2008 courses, SIGGRAPH Asia ’08, pages 35:1–35:11, New York,
NY, USA, 2008. ACM. [citat la p. 36, 37, 38, 40]
[Montgomery 06] Douglas C. Montgomery. Design and analysis of experiments. John
Wiley & Sons, 2006. [citat la p. 32, 39]
[Morgan 10] Andrew G. Morgan. The Linux-PAM System Administrator’s Guide.
Website, 2010. http://www.kernel.org/pub/ linux/libs/
pam/Linux-PAM-html/Linux-PAM_SAG.html. [citat la p. 69]
[Netperf ] Netperf. Netperf homepage. Website. http://www.netperf.org/
netperf/NetperfPage.html. [citat la p. 64]
[NetPIPE ] NetPIPE. NetPIPE. Website. http://www.scl.ameslab.gov/
netpipe/. [citat la p. 64]
[NIST/SEMATECH 06] NIST/SEMATECH. e-Handbook of Statistical Methods. Web-
site, 2006. http://www.itl.nist.gov/div898/handbook/ pri/
section3/pri3.htm. [citat la p. 30, 34, 35]
[Papadopoulos 04] Philip M. Papadopoulos, Caroline A. Papadopoulos, Mason J.
Katz, William J. Link & Greg Bruno. Configuring Large High-
Performance Clusters at Lightspeed: A Case Study. Int. J. High
Perform. Comput. Appl., vol. 18, no. 3, pages 317–326, 2004.
http://dx.doi.org/10.1177/1094342004046056. [citat la p. 56,
57]
[Petcu 01] D. Petcu. Procesare paralela. Editura Eubeea, 2001. [citat la p. 17]
[Quinn 04] M. J. Quinn. Parallel programming in c with mpi and openmp.
Higher Education. McGraw-Hill, SEPT 2004. [citat la p. 15, 29, 33,
34]
[Rao 08] Pradeep Rao & Kazuaki Murakami. Using Statistical Models for
Embedded Java Performance Analysis. International Conference on
High Performance Computing (HiPC 2008): December 17-20, 2008
: Bangalore, India, December 2008. [citat la p. 31]
[Rauber 10] Thomas Rauber & Gudula Runger. Parallel programming for multi-
core and cluster systems. Software Engineering. Springer Verlag, 1
edition, 2010. [citat la p. 9, 15]
[Ridge 07] Enda Ridge, Daniel Kudenko & Yo Dd England. Analyzing Heuristic
Performance with Response Surface Models: Prediction, Optimiza-
tion and Robustness. In GECCO ’07: Proceedings of the 9th annual
conference on Genetic and evolutionary computation, pages 150–
157, New York, NY, USA, 2007. ACM. http://doi.acm.org/10.
1145/1276958.1276979. [citat la p. 32]
82
Bibliografie
[rocksclusters 02] rocksclusters. Rocks Cluster Distribution manuals: Users Guide,
Introduction to Clusters and Rocks Overview. Website, 2002. http:
//www.rocksclusters.org. [citat la p. 57, 58]
[Rusan si Amarandei 10] A. Rusan & C. M. Amarandei. A New Model for Cluster Commu-
nications Optimization. International Journal of Computers, Com-
munications & Control, vol. V, no. 5, 2010. [citat la p. 59, 60, 61, 65,
68, 77]
[Ruthruff 06] Joseph R. Ruthruff, Sebastian Elbaum & Gregg Rothermel. Ex-
perimental Program Analysis: A New Program Analysis Paradigm.
In Proceedings of the 2006 international symposium on Software
testing and analysis, pages 49–60, Portland, Maine, USA, 2006.
[citat la p. 31, 32]
[Sacerdoti 04] F. D. Sacerdoti, S. Chandra & K. Bhatia. Grid systems deployment
& management using Rocks. In CLUSTER ’04: Proceedings of the
2004 IEEE International Conference on Cluster Computing, pages
337–345, Washington, DC, USA, 2004. IEEE Computer Society.
[citat la p. 57]
[Sahni 4] Sartaj Sahni & Venkat Thanvantri. Performance Metrics: Keeping
the Focus on Runtime. IEEE Parallel Distrib. Technol., vol. 1996,
no. 1, pages 43–56, 4. http://dx.doi.org/10.1109/88.481664.
[citat la p. 16]
[Skillicorn 96] David B. Skillicorn & Domenico Talia. Models and Languages for
Parallel Computation. ACM Computing Surveys, vol. 30, pages
123–169, 1996. [citat la p. 14]
[Skillicorn 05] D. B. Skillicorn. Foundations of parallel programming, volume 6 of
Cambridge International Series on Parallel Computation. Cambridge
University Press, August 2005. [citat la p. 10]
[Snell 96] Quinn O. Snell, Armin R. Mikler & John L. Gustafson. NetPIPE:
A Network Protocol Independent Performance Evaluator. In in
IASTED International Conference on Intelligent Information Man-
agement and Systems, 1996. [citat la p. 64]
[Stewardson 02] D.J. Stewardson, C. Hicks, P. Pongcharoen, S.Y. Coleman & P.M.
Braiden. Overcoming complexity via statistical thinking: optimising
Genetic Algorithms for use in complex scheduling problems via de-
signed experiments. Tackling Industrial Complexity: the ideas that
make a difference, pages 275–290, April 2002. [citat la p. 32]
[Teodoru si Amarandei 07] Tudor Teodoru & C.M. Amarandei. Load Balancing in a Mobile
Agent System. In Proceedings of 9th International Symposium on
Automatic Control and Computer Science. Editura POLITEHNIUM,
2007. [citat la p. 25, 26, 76]
83
Bibliografie
[Tierney 01] B.L Tierney, D. Gunter, J. Lee, M. Stoufer & J.B. Evans. Enabling
network-aware applications. In Proceedings of the 10th IEEE Inter-
national Symposium on High Performance Distributed Computing,
pages 281–288, 2001. [citat la p. 63]
[Tirumala ] A. Tirumala & L. Cottrell. Iperf Quick Mode. Web-
site. http://www-iepm.slac.stanford.edu/bw/iperfres.
html. [citat la p. 64]
[Totaro 05] Michael W. Totaro & Dmitri D. Perkins. Using statistical design of
experiments for analyzing mobile ad hoc networks. In MSWiM ’05:
Proceedings of the 8th ACM international symposium on Modeling,
analysis and simulation of wireless and mobile systems, pages 159–
168, New York, NY, USA, 2005. ACM. http://doi.acm.org/10.
1145/1089444.1089472. [citat la p. 32, 34]
[Turner 02] Dave Turner & Xuehua Chen. Protocol-Dependent Message-Passing
Performance on Linux Clusters. In CLUSTER ’02: Proceedings
of the IEEE International Conference on Cluster Computing, pages
187–194, Washington, DC, USA, 2002. IEEE Computer Society.
[citat la p. 64]
[Turner 03] D. Turner, A. Oline, X. Chen & T. Benjegerdes. Integrating New
Capabilities into NetPIPE. In Lecture Notes in Computer Science,
pages 37–44. Springer-Verlag, September 2003. [citat la p. 64]
[Urgaonkar 02] B. Urgaonkar, P. Shenoy & T. Roscoe. Resource overbooking and
application profiling in shared hosting platforms. SIGOPS Oper.
Syst. Rev., vol. 36, no. SI, pages 239–254, 2002. http://doi.
acm.org/10.1145/844128.844151. [citat la p. 68]
[Urgaonkar 04] B. Urgaonkar & P. Shenoy. Sharc: Managing CPU and Network
Bandwidth in Shared Clusters. IEEE Transactions on Parallel and
Distributed Systems, vol. 15, no. 1, pages 2–17, 2004. http://dx.
doi.org/10.1109/TPDS.2004.1264781. [citat la p. 68]
[Whiting 04] David Whiting, Quinn Snell, Rebecca R. Nichols, Megan L. Porter,
Kevin Tew, Keith A. Crandall, Michael F. Whiting & Mark Clement.
Complex Performance Analysis Through Statistical Experimental
Design: An Evaluation of Parameters Associated with Speed in Par-
allel Phylogenomics. Hawaii International Conference on Computer
Science, pages 615–629, January 2004. [citat la p. 32]
[Wilkinson 99] B. Wilkinson & M. Allen. Parallel programming. Prentice-Hall,
1999. [citat la p. 21, 22, 23]
[Willebeek-LeMair 93] M. Willebeek-LeMair & A.P. Reeves. Strategies for Dynamic Load
Balancing on Highly Parallel Computers. IEEE Transactions on Par-
allel and Distributed Systems, vol. 4, no. 9, pages 979–993, 1993.
[citat la p. 23]
84
Bibliografie
[Zheng 10] Gengbin Zheng, Gagan Gupta, Eric Bohm, Isaac Dooley &
Laxmikant V. Kale. Simulating Large Scale Parallel Applications
using Statistical Models for Sequential Execution Blocks. In Pro-
ceedings of the 16th International Conference on Parallel and Dis-
tributed Systems (ICPADS 2010), pages 10–15, Shanghai, China,
December 2010. [citat la p. 32]
85