Contributii la proiectarea aplicatiilor paralele pe ... · Pe o arhitectura paralel a,...

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

http://www.iccc.univagora.ro/

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


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


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


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


• 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


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


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


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


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


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


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


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


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


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


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



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



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


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


β

-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


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


β

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


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


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


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


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


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


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


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


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

http://dx.doi.org/10.3923/jas.2011.932.942

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

http://www.linuxhq.com/

kernel/v2.6/24-rc3/Documentation/cgroups.txt

kernel/v2.6/24-rc3/Documentation/cgroups.txt

http://diffserv.sourceforge.net

http://diffserv.sourceforge.net

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.


81

https://www.facultyresourcecenter.com/curriculum

https://www.facultyresourcecenter.com/curriculum

/pfv.aspx?ID=6594&Login=

/pfv.aspx?ID=6594&Login=

http://www.ietf.org/rfc/rfc1323.txt

http://www.ietf.org/rfc/rfc1323.txt

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

http://www.kernel.org/pub/

linux/libs/pam/Linux-PAM-html/Linux-PAM_SAG.html

linux/libs/pam/Linux-PAM-html/Linux-PAM_SAG.html

http://www.netperf.org/netperf/NetperfPage.html

http://www.netperf.org/netperf/NetperfPage.html

http://www.scl.ameslab.gov/netpipe/

http://www.scl.ameslab.gov/netpipe/

http://www.itl.nist.gov/div898/handbook/

pri/section3/pri3.htm

pri/section3/pri3.htm

http://dx.doi.org/10.1177/1094342004046056

http://doi.acm.org/10.1145/1276958.1276979

http://doi.acm.org/10.1145/1276958.1276979

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.


[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

http://www.rocksclusters.org

http://www.rocksclusters.org

http://dx.doi.org/10.1109/88.481664

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

http://www-iepm.slac.stanford.edu/bw/iperf res.html

http://www-iepm.slac.stanford.edu/bw/iperf res.html

http://doi.acm.org/10.1145/1089444.1089472

http://doi.acm.org/10.1145/1089444.1089472

http://doi.acm.org/10.1145/844128.844151

http://doi.acm.org/10.1145/844128.844151

http://dx.doi.org/10.1109/TPDS.2004.1264781

http://dx.doi.org/10.1109/TPDS.2004.1264781

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

Contributii la proiectarea aplicatiilor paralele pe ... · Pe o arhitectura paralel a,...

Documents

Transcript of Contributii la proiectarea aplicatiilor paralele pe ... · Pe o arhitectura paralel a,...