Utilizarea Tehnologiei Grid Computing In Dezvoltarea Bazelor de Date

LUCRARE DE LICENȚĂ

UTILIZAREA TEHNOLOGIEI GRID COMPUTING IN DEZVOLTAREA BAZELOR DE DATE

INTRODUCERE

Cercetătorii au visat dintotdeauna să aibă la dispoziție spații uriașe de stocare a datelor, putere de calcul nelimitată, să poata colabora cu diverse instituții din diverse părți ale globului, să utilizeze și să partajeze împreună resurse, date, programe și rezultate. Epoca supercomputerelor, a serverelor și a mainframe-urilor gigantice a trecut. Apărut în anii 90, conceptul de megacomputing, prin care erau descrise proiectele în care erau interconectate toate centrele care dețineau superservere, în ideea de a cumula puterea acestora de procesare, este perimat . Un calculator mediu din ziua de astăzi este mai puternic decât un superserver de acum 10 ani.

Conceptul de Grid Computing a trecut din lumea științifică și a cercetărilor științifice în lumea business-ului, mari companii precum IBM, Oracle, HP, Dell, Microsoft etc investesc în această tehnologie de viitor, existând la ora actuală mai multe proiecte diferite. La baza acestui concept stau multe idei excelente și inovatoare, bineînțeles unele dintre acestea existând mai înainte ca termenul Grid să apară. Ideea de bază este crearea unei resurse comune la nivel global. O altă prioritate este sistemul de securitate, crucial în vederea reușitei Gridului. Crearea unei resurse comune la această scară implică multe dificultăți la nivelul implementării și al securității, mai ales dacă ținem cont de faptul că resursele aparțin unor persoane și instituții diferite și că au diverse domenii administrative, rulează software diferit și au politici de acces și de securitate diferite. O altă noutate este managementul eficient al resurselor prin care să se evite blocarea traficului în rețea și implicit timpii morți.

Gridul se poate dezvolta acum în condițiile în care s-au facut câțiva pași tehnologici foarte importanți într-un timp foarte scurt. După apariția Internetului la sfârșitul anilor 60, la începutul anilor 1990 au aparut și World Wide Web-ul precum și sistemul de operare Linux, limbajul de programare Java etc, Grid Computing apare ca o continuare firească a evoluției. În ultimii 2-3 ani comunitatea Grid Computing a crescut rapid pe plan mondial. Multe tehnologii, componente și proiecte noi apar spre a fi discutate și puse în practică. Acest fapt, alăturat popularității crescânde și utilizării din ce în ce mai frecvente a Internetului și a diferitelor servicii bazate pe Web, va schimba felul în care folosim calculatorul și facem afaceri.

Termenul de „grid” se referă la o infrastructură computațională distribuită capabilă să pună la dispoziție resursele în funcție de necesitățile specifice fiecărui client, așa cum poate fi utilizată rețeaua (eng. grid) de electricitate. Tehnologia grid poate spori în mare măsură productivitatea și eficiența organizațiilor (virtuale) care trebuie să facă fața provocărilor, prin optimizarea proceselor și resurselor, partajarea acestora în rețea și colaborare. Soluțiile grid vin în întâmpinarea organizațiilor ce doresc dezvoltarea unei arhitecturi orientate pe servicii care să faciliteze managementul și integrarea proceselor afacerii. Pe piață există un număr mare de ofertanți de astfel de soluții, dintre aceștia putând fi amintiți: Oracle, IBM, DataSynspse, GreenTeaSoft, Sun, Hewlett-Packard, United Devices, etc.

O definiție pentru Grid ar putea fi cea dată de Wolfgang Gentzsch în “The Grid, The Time Machine of the 21st Century”: grid-ul “reprezintă o infrastructura software/hardware/ de instrumente care furnizează acces nelimitat, dependent, consistent și omniprezent la resurse de tip computational și date”. De fapt, grid-ul poate fi văzut ca cea mai recentă și completă evoluție a procesării distribuite, în tabelul de mai jos fiind prezentată o comparatie cu alte tehnologii.

Tabelul 1: Comparație ale tehnologiei GRID cu alte tehnologii distribuite

Grid-urile de pe piață sunt, de fapt, combinații ale tipurilor principale de grid, și anume:

▪ grid-uri computaționale (computational grids) – orientate pe furnizarea accesului la un fond comun de putere de calcul. Grid-urile computaționale exploatează capacitatea de procesare agregată a calculatoarelor eterogene, incluzând în general cluster-e de calculatoare dedicate, supercalculatoare;

▪ grid-uri de date ( data grids) – se concentrează pe management, distribuție și replicarea eficientă a unor mari cantități de date, asigurând accesul la date pentru organizațiile din grid. Utilizatorii nu sunt interesați de locația în care sunt stocate datele, ci au nevoie de disponibilitatea datelor pentru a-și putea îndeplini sarcinile de lucru;

▪ grid-uri colaborative ( Scavenging grids) – se folosesc în sistemele cu un număr mare de desktop-uri, acestea fiind folosite(eng. scavenging) pentru a determina ciclii CPU neutilizați precum și alte resurse. Proprietarii resurselor au controlul atunci când resursele lor sunt disponibile pentru a participa la grid (Condor, Entropia).

Ținând cont de aplicațiile ce vor rula în grid, trebuie ales tipul potrivit de pentru organizație. Cu toate că există numeroase modele de servicii grid, sunt implementate cu succes în cadrul sistemelor grid arhitecturi de sistem de tip protocoale stratificate (e.g. Globus) și de tip mașină virtuală ( Legion). În cadrul arhitecturii de tip protocoale stratificate, straturile sistemului sunt succesiv construite pe funcționalitatea nivelurilor inferioare. Stratificarea sistemului facilitează independența resurselor și aplicațiilor din grid, componentele eterogene putând interacționa utilizând interfețele definite de protocol. În mod similar, arhitecturile de tip mașină virtuală abstractizează eterogenitatea resurselor din grid. Totuși, abstractizarea arhitecturii mașinii virtuale este realizată la un nivel superior, componentele și resursele grid-ului fiind integrate într-o singură entitate de calcul ce poate fi adresată global. Prin comparație, sistemele stratificate abstractizează domeniul de aplicație și resursele ce stau la baza grid-ului pentru a furniza o interfață comună independentă de diferitele componente hardware și software conținute în grid. În general, arhitecturile grid de tip protocoale stratificate sau mașină virtuală suportă aceleași funcționalități de bază, ca alocarea resurselor, managementul proceselor, servicii de informare, securitate, comunicare, managementul datelor, replicare, toleranța la defecte, precum și parametri legați de calitatea serviciilor. Aceste mecanisme nu sunt specifice sistemelor grid, ci ele au fost adaptate pornind de la sistemele paralele și distribuite astfel încât să răspundă cerințelor sistemelor grid.

Există și încercări de standardizare, proiectul celor de la Global Grid Forum urmărind să organizeze protocoalele sub Open Grid Services Architecture (OGSA), arhitectură de sistem grid bazată pe conceptele și tehnologiile serviciilor Web.

Termenul GRID computațional este o analogie la termenul de GRID electric, care oferă acces transparent și consistent la electricitate fără a conta sursa de unde provine acesta.GRID-urile permit agregarea și selectarea unei varietăți de resurse precum supercomputere, sisteme de stocare a datelor și aparaturi specializate, aflate în diferite locații geografice și care aparțin diferitelor organizații, în scopul de a rezolva probleme computaționale de mari proporții din diferite domenii.

Tehnologia Grid Computing reprezintă un ansamblu de tehnici si metode aplicate pentru utilizarea coordonată a mai multor servere specializate care acționează ca un singur sistem, integrat logic, foarte puternic. Resursele de calcul de la nivelul unei organizații sunt folosite, in mod optim, în comun,obtinându-se astfel un supercalculator virtual. Câteva tehnologii informatice, care existau deja, au pregătit terenul pentru apariția tehnologiei GC la începutul anilor 2000: Intranet, Extranet, Internet, rețele de calculatoare evoluate, sisteme de baze avansate etc.

Figura 1. Rețea Grid Computing

CAPITOLUL 1

CONCEPTE GENERALE

1.1 Tehnologii care au stat la baza Grid Computing [7]

1.1.1. Intranet

Conceptul de Intranet se referă la utilizarea tehnologiilor Internet pentru legarea într-un tot unitar al resurselor informaționale ale unei organizații: texte, baze de date, documente etc.

Se poate spune ca Intranet este un Internet privat, care reprezintă rețeaua de transmisii de date private a unei companii deosebindu-se conceptual de Extranet, care este privit ca partea din rețeaua de transmisii de date comună cu partenerii agreați. Acest lucru înseamnă o rețea de calculatoare internă unei organizații deci protejată de lumea exterioară, adică o arie relativ autonomă, cu administrare internă, dar care acceptă protocoalele de comunicație din Internet.

Componentele rețelei Intranet pot fi grupate în două mari categorii:hardware si software.

Hardware – componentele care asigură echipamentele necesare funcționării rețelei: servere Intranet(microcalculatoare, minicalculatoare), medii de comunicație (cabluri coaxiale, fibră optică, radio), arhitectură de rețea LAN(Ethernet), echipamente de rutare(hub, switch etc).

Software – componentele care asigură produsele program necesare funcționării rețelei: sisteme de operare(Windows, OS2,Mac etc), software de rețea(Unix, Windows xxServer, Novell etc), protocoale de rețea(TCP/IP, DECnet etc), software specializat(SGBD, navigatoare, Platforma Java, CASE etc).

Caracteristicile Intranet rezultă din definirea și din structurarea acestui tip de rețea:

este un concept flexibil pentru că nu are un șablon de implementare prestabilit, ce trebuie respectat pas cu pas, ci poate fi modelat în funcție de cerințele organizatiei;

este realizat pe baza protocoalelor Internet, adică respectă standardele de comunicație din tehnologia Internet și de aceea poate fi rapid actualizat, funcționând ca un sistem deschis;

reprezintă soluția ideală pentru organizațiile cu un număr mare de utilizatori, adică se justifică soluția Intranet dacă sunt peste 1000 de utilizatori, iar localizarea lor este distribuită pe o suprafață geografică mare;

are la bază conceptul de server Web, deoarece configurarea serverului Web se face pe o rețea locală, iar funcțiile sale pot fi extinse cu alte facilități: accesul la baze de date, apelul unor aplicații etc.;

nu implică în mod obligatoriu conectarea la Internet, dar această posibilitate oferă o mulțime de avantaje.

Serviciile oferite de către orice rețea Intranet utilizatorilor săi pot fi grupate în opt categorii. Decizia de a implementa o rețea de Intranet va fi fundamentată, în mare măsură, pe numărul și calitatea serviciilor pe care le va asigura pentru organizație.

Serviciile de transport permit transferul informației de la un punct la altul in cadrul Intranet și se referă la următoarele operații:

-transferul de date într-o rețea locală, respectând protocoalelor de comunicație ;

-accesul de la distanță la date și la produsele software, care apartin sistemului informatic integrat al organizației;

-accesul la Internet pentru comunicarea organizației cu exteriorul;

-interconexiunea între rețelele LAN și cele globale WAN.

2. Serviciile de administrare a rețelei sunt operaționale în număr de trei:

-supervizarea rețelei Intranet permite supravegherea tuturor componentelor hardware și software ale ansamblului , având la bază standardul SNMP – Simple Network Management Protocol din Internet;

-administrarea Intranet este realizată de persoane specializate care au la dispoziție instrumente software specializate. Acestea asigură administratorilor de rețea o viziune unitară asupra întregii rețele a organizației și le permite gestionarea eficientă a resurselor de calcul;

-serverele de filtrare (cache/proxy), care au fost folosite mai întâi în Internet și apoi în Intranet , au rolul de a reduce fluxul informațional (traficul) prin sistemul de comunicație. Aceste servere dețin mecanisme ce le permite o selectare a cererilor de regăsire formulate și a răspunsurilor primate.

3. Serviciile de securitate au rolul de a proteja Intranetul prin asigurarea securitații serverului Web, a securității serviciilor TCP/IP, a securității navigatoarelor client. Metodele de securitate aplicate în Intranet se referă la urmatoarele aspecte;

-autentificarea – este utilizată pentru a verifica dacă utilizatorul are drept de acces. Sistemele de autentificare dețin atât mecanisme simple(parole) cât și mecanisme mai complexe(ActiveCard, SecureID etc.);

-criptarea – are drept scop garantarea confidențialității fluxului de informații din Intranet, prin folosirea unor algoritmi specifici pentru codificarea si decodificarea informațiilor transmise prin rețea;

-filtrarea – se realizează prin mecanisme de tip bariere(firewall), care autorizează anumite tipuri de pachete(servicii, adrese, conținut) conform setului de reguli stabilite prin politica de securitate a rețelei.

4. Serviciile de partajare a datelor din Intranet sunt destinate stocării și interogării datelor pe care le memorează, simultan,pentru mai multi utilizatori. Sistemele de baze de date asigură astfel de servicii, care se referă la:

-stocarea si accesul datelor sunt asigurate de: serverele de fisiere(fisiere clasice ale S.O. utilizat, de exemplu,protocoalele FTP, NFS din Intranet), serverele de date(asigurate în special de SGBD relaționale si este necesară o interfața între BD si serverul Web pentru navigarea unui browser), serverele de documente(sunt în general serverele Web, dar și SGBD, si permit utilizatorului să caute și să consulte documentele produse în organizație);

-producerea si publicarea informațiilor sunt asigurate de către sistemul informatic integrat al organizației. Aceste sisteme sunt realizate cu soluții de baze de date, datorită volumului mare de informații și datorită complexității acestora.

5. Serviciile de comunicație între diferitele persoane din organizație sunt importante pentru succesul afacerii, pentru că informația este în acest moment, în societatea cunoașterii, cea mai importantă resursă. Câteva forme de comunicare în Intranet sunt:

-poșta electronică(E-mail) are la bază mecanismele din Intranet: SMTP- Simple Mail Transfer Protocol, POP3- Post Office Protocol, IMAP- Interactive Mail Access Protocol;

-circulația documentelor(Workflow) este o extensie a poștei electronice și permite circulația unui document în rețea, după o schemă prestabilită;

-videoconferințele pentru care se folosesc produse software specializate;

-lucrul în comun în timp partajat este o extensie a circulației documentelor și permite mai multor persoane, situate la distanță unele de altele,să vizualizeze(Net Meeting) sau să prelucreze împreună același document;

-forumul permite utilizatorilor de Intranet să schimbe idei, mesaje și poate fi în timp real(Internet Relay Chat-IRC) sau în timp diferit.

Serviciile de statistici (anuare) sunt necesare pentru că în Intranet fiecare utilizator apelează la servicii diferite, pe calculatoare diferite. Câteva dintre aceste tipuri de statistici se referă la: utilizatori, servere, servicii, aplicații, date etc.

Serviciile pentru dezvoltarea aplicațiilor se referă la tot felul de interfețe și instrumente(limbaje de programare, generatoare, medii de dezvoltare etc.), care sunt adaptate mediului rețea și sunt utilizate în laboratoarele de software pentru dezvoltarea aplicațiilor Intranet.

Serviciile de acces la informații și la aplicațiile Intranet presupun folosirea produselor tip navigator(browsers) care acționeză în rețea: Internet Explorer, Netscape Navigator, Mozilla Firefox, Google Chrome, Opera etc. Pe lângă afișarea documentelor, serviciile de acces pot regăsi imagini, sunet, video si aplicații de la server, dacă acestea nu se găsesc în document. Ceea ce a condus la utilizarea acestei tehnologii în Intranet, care inițial s-a folosit în Intranet, este faptul că se permite ca un document să fie alipit/legat(link) cu un alt document. Acest lucru presupune că un anumit utilizator nu trebuie să cunoască localizarea unui anumit document sau sursele de informații, accesul fiind permis doar prin selectarea unei opțiuni dintr-o pagină de ecran. Pentru serviciile de acces la informații, serverele HTTP sunt disponibile pentru toate tipurile de platforme hardware si software. Practic, un server Web transmite informația către o execuție exterioară. Acesta este modul în care se pot accesa date și aplicații exterioare. De exemplu, se pot accesa baze de date, ceea ce înseamnă că se va integra un server Web cu o aplicație cu baze de date.

Organizarea din Intranet respectă anumite modele, de care trebuie să țină cont echipa de proiectare. Factorii de care depinde modul de alegere a unui model de Intranet sunt: controlul resurselor, responsabilitatea resurselor, mărimea organizației, numărul resurselor.

În funcție de modul de utilizare a resurselor, sunt trei modele de organizare a Intranetului:

-centralizat, care presupune că toate resursele de calcul se găsesc într-o singură locație din rețea, iar utilizatorii din diferite locații le accesează. Avantajul este ca se folosesc mai puține resurse de calcul, iar dezavantajul este că va fi o mare concurență la resurse;

-descentralizat, care presupune că resursele de calcul sunt răspândite în organizație și sunt dependente de departamentul în care se găsesc calculatoarele. Avantajul este că va fi o concurență mai slabă la resurse, iar dezavantajul este că se folosesc mai multe resurse;

-mixt, care presupune că există un centru în care se stabilesc politici generale, iar departamentele lucrează în concordanță cu aceste politici. Acesta este cel mai utilizat model, pentru că aduce avantajele și dezavantajele celor două modele de mai sus, la un nivel mediu.

Proiectarea Intranet este o activitate care ține cont de cerințele beneficiarullui(organizației) și este precedată de activitatea de organizare a Intranetului. Aceste activitați sunt realizate de către o echipă de dezvoltare a proiectului de Intranet, care lucrează conform unei anumite metodologii. Indiferent de metodologia utilizată se vor parcurge niște pași de lucru conform managementului de proiect. Sintetizând pașii anumitor metodologii de realizare a proiectului Intranet și realizând similitudini între ei, se poate ajunge la un set de șase activități după cum urmează.

Obținerea acordului de principiu la nivelul organizației, atât din partea conducerii, cât și din partea nivelurilor de execuție pentru alocarea resurselor necesare, organizarea proiectului, sprijinul pe toate planurile.

Planificarea strategiei de realizare a Intranetului presupune: identificarea structurii organizaționale existente, descrierea nivelului tehnicii de calcul existente in organizație, definirea modelului de comunicație a informației în organizație cu specificarea avantajelor și dezavantajelor, identificarea sistemelor existente in organizație și evaluarea modului de funcționare al lor.

Stabilirea obiectivelor proiectului înseamnă precizarea a ceea ce trebuie să facă Intranetul. În acest sens, se colectează informațiile de la angajați și de la informaticieni și se elaborează o listă a cerințelor și specificațiilor de funcționare.

Recrutarea echipei de dezvoltare a Intranetului trebuie să vizeze reprezentați ai diferitelor departamente ale organizației: informatică(specialiști în rețele, sisteme informatice, sisteme de baze de date, programare, grafică, administrare), resurse umane, gestiune documente, organizarea întreprinderii, serviciul vânzari etc.

Dezvoltarea proiectului de Intranet presupune gruparea conținutului pe subiecte și categorii principale, după care se vor adăuga alte informații corelate după departamente. Categoriile de informații comune paginilor de Intranet sunt: noutățile, știrile, prezentarea organizației, contractele, asistența tehnică, resursele,vânzările, clienții, contactele(telefon,E-mail etc.) .

După gruparea informațiilor, acestea sunt structurate pe niveluri conform cerințelor utilizatorilor și într-o formă agreată de aceștia(liniar, ierarhic, grilă etc.).

Definirea interfeței cu utilizatorul trebuie să țină cont de forma și conținutul acesteia: prietenoasa, lizibilă, ușor de utilizat, relevantă,precisă.

Programarea în Intranet este o parte a serviciilor pentru dezvoltarea aplicațiilor. O caracteristică a Intranetului este aceea că presupune flexibilitatea software, adică oferă posibilitatea de ajustare și de modificare în funcție de cerințele noi care apar. De obicei, acest lucru este realizabil prin completarea sistemelor software cu secvențe scrise în limbajele de scenarii(script), conform cerințelor utilizatorului. Dintre serviciile Intranet, cel care necesită personalizare, adică activitate de programare flexibilă este site-ul Web. Celelalte servicii(poștă electronică, transfer de fișiere etc.) beneficiază, de regulă, de un software care acoperă toate problemele care pot apărea. Serviciul Web presupune programarea intensă pentru două aspecte principale: interfața cu utilizatorul și interfața cu bazele de date.

Interfața cu utilizatorul oferă posibilitatea ca acesta să completeze formulare tip sau să selecteze opțiuni în timpul navigării. Luând în considerare locul unde rulează programul script, există două variante de implementare:

-pe serverul SSS(Server Side Script) și rezultă module tip servlets, care se pot realiza cu JavaScript, JSP, ASP, PHP. Serverul execută un anumit modul de program script de la care preia ieșirile și le trimite clientului.

-pe client CSS(Client Side Script) și rezultă module tip applets care se pot realiza cu JavaScript, VBScript, applet Java, controale ActiveX.

Pentru utilizarea acestor tehnologii există navigatoare specializate: Internet Explorer care permite lucrul cu: VBScript, controale ActiveX, applet Java, Jscript(subset JavaScript); Netscape Navigator care permite lucrul cu JavaScript, applet Java etc.

Interfața cu bazele de date presupune ca serviciul de Web să țină cont că indiferent de mărimea organizației, aceasta folosește una sau mai multe BD.

Acest lucru a dus la apariția unor motoare de BD(software optimizat care știe să execute anumite comenzi asupra unui tip de BD) și la utilizarea limbajului de interogare a BDR(SQL). Motoarele de căutare respectă o serie de standarde(ODBC, JDBC etc), ceea ce reprezintă un aspect important pentru programatori, deoarece acesta nu mai este obligat să învețe să lucreze cu fiecare dintre motoarele de baze de date utilizate în cadrul organizației.

În cadrul interfeței cu BD administratorul BD realizează modelul conceptual al BD, ajută la implementarea acestuia și asigură apoi protecția datelor, utilizând un SGBD adecvat. Uneori, el trebuie să țină cont de specificul interfeței Web și de problemele de securitate suplimentare care apar în acest caz.

Din punct de vedere al programatorilor, se consideră că aceștia trebuie să se concentreze atât pe soluțiile de programare pe partea de server,cât și pentru partea de client. Acest lucru este necesar deoarece la o BD mare, necesită multe programe script pentru împărțirea sarcinilor și apare astfel necesitatea lucrului în echipă. Produsele software pe care programatorii le pot utiliza sunt diverse: limbaje de programare universale(C, Pascal, Java etc.), interfețe standard(CGI, JSP,ASP etc.), produse tip bariere de acces – gateway(dbWeb, ColdFusion etc), limbaje de script(HTML, JavaScript, PHP etc.).

Avantajele utilizării rețelei Intranet la nivelul organizației rezultă din aspectele prezentate mai sus și pot fi rezumate astfel:

-comunicațiile mai rapide între utilizatori și între aplicațiile la nivelul organizației;

-managementul de rețea și de BD se realizează mai simplu și mai rapid;

-accesul la bazele de date este protejat și simplificat la nivelul organizației;

-sursa de date este integrată si gestionată în mod unic la nivelul organizației;

-productivitatea beneficiarilor de Intranet este crescută prin folosirea serviciilor oferite;

-se realizează economii importante de resurse financiare privind circulatia informației, a documentelor, a timpului de raspuns etc.;

-se realizează economie de timp privind documentarea și fundamentarea deciziei.

1.1.2 Extranet

Conceptul de Extranet reprezintă a treia etapă majoră în evoluția rețelelor de calculatoare, având ca punct de vedere organizația, după Intranet și Internet, realizând legatură între acestea. Conceptul a fost introdus de Jim Barkdale(la Netscape Communications) pentru a descrie produsele software care facilitează colaborarea între organizații.

Extranet reprezintă utilizarea tehnologiilor Internet în vederea conectării resurselor informaționale a mai multor organizații, între care există legături de colaborare. În contextul de Extranet, informația poate fi accesată doar de părțile care colaborează sau poate fi făcuta publică.

Așadar, rețeaua Extranet poate fi privită ca:

-partea din Intranetul unei organizații care este accesibilă și altor organizații;

-partea comună a două sau mai multor Intraneturi;

-o conexiune de colaborare pe Internet între două sau mai multe organizații.

Categoriile de aplicații de la nivelul organizațiilor, care se pretează la soluția de rulare în contextul de Extranet sunt pentru:

-grupurile de comunicare private, ale unor organizații, care au rolul de a difuza idei, experimente etc.;

-echipele de lucru ale unor organizații care devoltă proiecte comune;

-programele de instruire și educaționale care sunt dezvoltate în mod partajat de către mai multe organizații;

-cataloagele cu produsele accesibile doar pentru un anumit grup de clienți;

-managementul proiectelor care se desfășoară în comun pentru mai multe organizații.

1.2 Tehnologia Grid Computing si aplicabilitatea sa [7]

1.2.1 Inițiere în tehnologia Grid Computing (GC)

În acest moment, în lume, tehnica de calcul din organizații este insuficient folosită. Sistemele de calcul, de multe ori, sunt greu de schimbat, scump de întreținut și de dezvoltat. Schimbările în orice organizație apar în permanență,nevoia de informație este din ce în ce mai mare și din aceste motive adaptarea trebuie să se facă cât mai repede, cu un efort cât mai mic pentru a rămâne competitive. Cerințele pentru performanță cresc continuu, în timp ce bugetele pot rămâne neschimbate și de aceea organizațiile, de multe ori, fie dezvoltă serverele(upgrade) pe care le are, fie achiziționează altele noi mai performante.

Soluția pentru rezolvarea problemelor de mai sus este un model nou de abordare, denumit Grid Computing – GC(Grilă de calculatoare). Noua tehnologie are diferite alte denumiri: Oracle 10g, Adaptive Computing, Utility Computing, Organic Computing, Computing on Demand, Hosted Computing etc.

Pentru utilizatori și pentru aplicații, în tehnologia GC nu mai contează: unde sunt stocate datele, unde sunt stocate aplicațiile, ce calculatoare procesează cererea de regăsire, ce resurse sunt folosite în rețea. Așadar, pe scurt, putem defini tehnologia GC ca fiind utilizarea coordonată a mai multor servere mici, care acționează ca un singur sistem foarte puternic(Grilă de Calculatoare). GC a fost concepută ca o tehnologie informatică pentru:

-crearea unui mediu de tehnică de calcul dinamic care să împartă în mod optim resursele și rezultatele;

-mărirea capacității de stocare a datelor și protecția acestor date în caz de incidente;

-menținerea unor costuri cât mai mici pentru exploatarea întregului sistem.

Prima aplicație științifică a tehnologiei GC a fost proiectul Search for extraterestrial intelligence,seti@home. În acest proiect semnalele de la telescoape, de la receptoarele radio și de la alte surse care monitorizau spațiul au fost distribuite pe microcalculatoare prin Internet. Această rețea de microcalculatoare prelua informația primită căutând semnale despre viața extraterestă. După modelul Intranet, organizațiile își vor dezvolta tehnologia GC pentru resursele lor de calcul, fără să se expună Internetului.

Pentru prima dată, tehnologia GC este adaptată la baza de date de firma Oracle, prin lansarea versiunii Oracle 10g. Principalele tehnologii informatice care, prin integrare, au făcut posibilă apariția noii versiuni de Oracle au fost: GC, Intranet, Internet, servere multiple(Mail, aplicații, rețea, date, SGBD etc.), arhitectura Network Computing, Inteligența Afacerii, SBD distribuite. Progresul tehnologic a putut avea loc datorită tehnologiilor informatice de mai sus, datorită apariției unor componente tot mai puternice și mai ieftine și datorită posibilității integrării tehnologiilor informatice(hardware, software, date, comunicatii). Câteva idei privind aplicabilitatea tehnologiei GC în context de baze de date sunt prezentate în continuare.

Rețeaua Grid Computing

Într-o economie bazată pe cunoaștere, cum este cea actuală, avem nevoie de o rețea, denumită Grid Computing, care să alimenteze uriașa putere de calcul, precum și nevoia de informații, într-un mod eficient. Caracteristicile rețelei GC sunt prezentate în continuare.

O nouă paradigmă de calcul. Rețeaua GC funcționează prin conectarea unei mari varietați de: calculatoare, baze de date, software, utilizatori, modele etc. Conectarea acestor resurse nu este nouă, ea fiind deja prezentă în Internet, Intranet, Extranet. Însă, față de acestea rețeaua GC permite o serie de facilități suplimentare:

-se poate aloca puterea de calcul în mod dinamic, de la diferitele procesoare de rețea, care aparțin altor calculatoare decât cel la care se lucrază. În acest fel, utilizatorii vor putea folosi din rețea puterea de calcul a unui supercalculator virtual,doar atunci când au nevoie, fără să fie obligați să cumpere un supercalculator fizic(computational grid);

-se poate împărți o sarcină primită de un calculator cu alte calculatoare conectate în rețea, astfel încât să se obțină un timp de răspuns mai mic;

-calculatorul la care se lucrează devine o poartă spre un supercalculator virtual, iar utilizatorul va plăti doar pentru puterea de care are nevoie, atunci când va avea nevoie;

-se pot accesa cantități uriașe de date, fie că sunt stocate pe echipamentele periferice ale diferitelor calculatoare conectate în rețea, fie că provin de la echipamentele speciale de citire(data grid);

-se pot rula noi tipuri de aplicații informatice, care vor avea acces la cunoștințele din rețea și vor putea construi răspunsuri ad-hoc(knowledge grid);

-se permite lucrul la proiecte în echipă, compusă din membri care au localizare geografică diferită, pentru diferite organizații. Această arhitectură este denumită Service Grid și creează astfel, în mod dinamic, o organizație virtuală care lucrează în laboratoare virtuale(service grid).

Tehnologii si aplicații revoluționare. Rețelele GC vor revoluționa informatica la fel de mult pe cât au revoluționat poșta electronică și tehnologia Web comunicațiile. Primele rețele GC au fost proiectate pentru Organizația Europeană pentru Cercetări Nucleare din Geneva, de unde a pornit și realizarea WWW – World Wide Web. Acum, rețelele GC pătrund în practică și schimbă modalitatea de structurare a afacerilor și felul în care oamenii trăiesc, învață sau lucrează. Furnizând utilizatorilor putere de calcul uriașă și cantități uriașe de informații, rețelele GC vor îmbunătăți competivitatea afacerilor existente și vor deschide piețe și servicii care până acum se credeau a fi imposibile. Impactul lor asupra calității vieții noastre va fi profund, permițându-ne să urmărim și să modelăm mai bine orice: schimbările climaterice de pe Pământ, evoluția piețelor financiare etc. Rețelele GC vor permite cercetătorilor și oamenilor de afaceri să folosească mai bine resursele de toate felurile pe care le dețin sau la care au acces. Tehnologia GC este un obiectiv strategic în cercetarea din societatea bazată pe cunoștințe, fondată și pusă la punct de UE prin programele cadru pentru cercetare și dezvoltare tehnologică.

Domenii de aplicabilitate. Rețelele GC au fost concepute inițial pentru rezolvarea problemelor care includeau cantități mari de informație și calcule imense. De aceea, primele astfel de rețele au fost dezvoltate la nivel global pentru proiecte științifice și de cercetare, acestea necesitând puterea de calcul a unor supercalculatoare și echipe de lucru cu o înaltă pregătire tehnică, echipe răspândite în mai toate universitățile lumii, centrele de cercetare și companii. Impactul tehnologiei GC asupra afacerilor este deja simțit, iar în viitor va fi masiv. Practic, majoritatea sectoarelor de activitate sunt supuse unor schimbări radicale, dinamice, iar soluția informatică optimă pentru organizații va presupune tehnologia GC.

Rețelele GC permit utilizatorului, pe de o parte, să acceseze resursele de care are nevoie – date, aplicații, software, hardware- iar, pe de altă parte, dau voie utilizatorului să-și pună la dispoziție propriile resurse pentru alți utilizatori. Acest lucru înseamnă că utilizatorii pot lucra la proiecte comune, chiar dacă sunt în diferite organizații, din diferite locații geografice. De exemplu, pentru proiectarea unui nou tip de produs. Activitatea va fi coordonată de o anumită organizație, dar proiectul va mai include și alti specialiști: proiectanți, economiști, ingineri, informaticieni, furnizori. Din punctul de vedere al securității, managerul de proiect nu va permite accesul tuturor membrilor, la întregul proiect. Rețeaua GC va asigura integrarea informațiilor într-o manieră ușoară, la timp, păstrându-se securitatea proiectului.

Informațiile obținute în urma testelor de încercare la impact pot fi văzute de fiecare furnizor, care poate folosi puterea de calcul a rețelei Grid pentru a analiza performanțele componentelor. Rezultatul va fi un proiect bun, obținut cu un efort mai mic și mai puțin costisitor. Rezultă astfel: competivitate, locuri de muncă, produse de calitate.

Companiile din sectoare diferite – afaceri, bănci, asigurări, media, servicii – vor putea folosi mediul de lucru virtual creat prin rețeaua GC, pentru a-și folosi eficient propriile resurse de calcul și pentru a colabora mai eficient cu partenerii lor. De exemplu, bibliotecile și arhivele din presă, sunt în prezent indexate semantic în baze de date uriașe localizate pe întregul glob. Cu tehnologia GC, redactorii vor putea să caute în aceste arhive, să extragă informațiile, să le prelucreze și să trimită rezultatul acolo unde doresc, într-un mod rapid și flexibil. Comerțul electronic, va putea să se reorganizeze și să funcționeze mai bine din punctul de vedere al furnizorilor și al clienților. Băncile, asigurările, bursele de valori vor putea face analize statistice mai complexe si eficiente, care să le permită atragera de cât mai mulți clienți. De altfel, așa cum se știe, marketingul actual este orientat pe client și nu pe produs așa cum era până acum. Acest lucru înseamnă că orice activitate care are printre actori clientul va profita de rețeaua GC.

Rețeaua Grid se poate aplica eficient în sistemele ale caror procese pot fi ușor divizate și alocate pe echipamente. De exemplu, utilizarea unui portal Web permite agregarea și partajarea informațiilor, a aplicațiilor, a serviciilor la nivelul mai multor organizații. Acest lucru înseamnă că prin intermediul unei aplicații unice se pot accesa mai multe aplicații. Când un utilizator transmite o cerere, aceasta este pusă într-o coadă de așteptare, fiind alocată ulterior unui procesor în funcție de resursele cerute și de un mecanism de priorități. Un mecanism de tip Grid are în vedere cerințele de execuție: viteza de procesare, memoria necesară, aplicațiile disponibile etc. Includerea unei cereri se face diferențiat în diferitele cozi de așteptare, iar execuția se face în ordinea priorităților. Secvența de execuție a unei cereri și întoarcerea răspunsului in cadrul tehnologiei GC este prezentată în figura de mai jos.

Execuția cererii – de la stânga la dreapta. Utilizatorul formulează o cerere către Grid prin intermediul unui navigator(browser). Acesta accesează portalul prin mecanisme de autorizare și autentificare. Dacă are dreptul de accesare a mecanismelor grid, acesta va adresa o sarcină(cerere). Portalul va cere informații suplimentare procesării cererii, iar după ce acestea sunt furnizate, procesul este transmis(submit). Serverul de tip portal procesează cererea și o transmite modulului servlet responsabil de execuție. De asemenea, cererea este transformata într-o comandă care poate fi înțeleasă de mecanismul grid(grid engine). Acesta recepționează mesajul și îl pune într-o coadă de așteptare, realizându-se o listă de planificare a proceselor.

Figura 1.1 Secvența de execuție a unei cereri

Primirea răspunsului – de la dreapta la stânga. Mecanismele de execuție realizează agregarea rezultalelor, transmițându-le mecanismului grid pentru a procesa răspunsul procesului respectiv. În funcție de starea în care se află procesul, utilizatorului i se va afișa o pagină HTML.

Sistemele de baze de date. Toate aspectele de mai sus care privesc tehnologia GC au ca rezultat, pentru utilizator, obținerea unor informații care să-l ajute să-și fundamenteze deciziile operative sau de conducere și să-și desfășoare activitățile curente. Ori această cantitate mare de informații, nu poate fi stocată și apoi accesată corespunzător decât dacă se lucrează cu un sistem de baze de date evoluat, care să funcționeze în arhitectură GC. Din acest motiv, SBD actuale au început să integreze tot ce este mai nou ca tehnologii informatice, inclusiv tehnologia GC. Primul SGBD care poate lucra cu un astfel de tehnologie este Oracle versiunea 10g(litera g vine de la grid).

Avantajele. Până la rețelele GC, singurele organizații care-și puteau permite supercalculatoare erau acelea cu bugete mari și cu necesități de tehnică de calcul semnificative, permanente. Rețelele Grid schimbă radical situația pentru că orice organizație conectată la o astfel de rețea își va putea permite utilizarea unui supercalculator virtual, atunci când are nevoie, plătind o taxă de acces. De exemplu, un utilizator se poate conecta la o rețea GC pentru a analiza informații culese din mii de senzori montați în bazinele râurilor, în vârful munților, în spațiu. Se poate astfel analiza, modela si compara aceste informații în timp util pentru a previziona catastrofele naturale: inundații, avalanșe, uragane, cutremure, erupții vulcanice.

Acest lucru este posibil pentru că rețeaua GC pate furniza oricând comunicarea și puterea de procesare necesare precum și informațiile dorite la prețuri accesibile.

1.2.3 Enterprise Grid Computing(EGC)

EGC înseamnă procesul de punere la lucru împreună a mai multor calculatoare existente la nivelul unei organizații și funcționarea ca un sistem integrat. EGC presupune existența unui produs software care:

face eficientă folosirea mai multor servere;

asigură stocarea modulară a datelor;

permite comutarea lucrului;

permite suplimentarea capacității de lucru la cerere.

Aducând noi servere în această grilă de calculatoare, mai mari sau mai mici, obținem performanță la un preț scăzut, deoarece gestiunea resurselor de calcul se face unificat, simplu , eficient, ieftin. Tratând orice GC ca un serviciu virtual, sistemele inteligente(business intelligence) pot optimiza utilizarea resurselor de calcul la nivelul întregii organizații. Pentru implementarea EGC se combină două concepte care sunt în legatură unul cu celălalt:

implementare de tip unul din mulți (one from many), adică folosirea mai multor clustere(fizice) pentru a crea o singură entitate logică(exemplu pentru o bază de date). Deoarece o singură entitate logică este implementată peste mai multe calculatoare, dar se pot adăuga noi capacităti în mod incremental(on-line) sau la cerere(on-demand), obținându-se astfel flexibilitate;

administrarea de tip mai mulți ca unul(many as one) = administrarea mai multor calculatare ca un grup, adică o singură entitate logică(exemplu un grup de instanțe a unei BD se administrează ca o entitate logică – tabela).

Capabilitatea unui server de aplicații de a distribui sarcini unui nou server, fără a opri activitatea sa necesită un software inteligent. În acest sens, Inteligența Afacerii ca tehnologie a existat în SGBD înainte de GC și a produs software inteligent. În acest scop, organizația ar trebui să aibă în vedere următoarele aspecte:

integrarea informațiilor în centre de date, a datelor în BD, a aplicațiilor în Server de aplicații:

Standardizarea în două variante: standard de producător(promovează produsele proprietar), standard internațional(promovează interoperabilitatea – open standard);

expertiza în Unix care este un sistem de operare perfect pentru o configurație de GC.

În context de EGC pot fi aplicate mai multe tipuri de tehnici grid, în funcție de aria de cuprindere:

cluster grid(tip departamental) este cea mai simplă și mai utilizată tehnică, putând fi implementată la nivelul unui departament al organizației. Ea necesită realizarea unui ansamblu de sisteme care lucrează împreună, având un singur punct de acces, cu posibilitatea procesării paralele;

campus grid(tip intreprindere) combină mai multe cluster grid la nivelul unei organizații, pentru a oferi o capacitate sporită de procesare. Această tehniă poate fi aplicată în mod dispersat sau centralizat, oferind următoarele facilități: execuția unor procese mari consumatoare de resurse de calcul, extragerea de date(data mining) pe BD complexe, optimizarea distribuției proceselor etc.

Global grid(tip interorganizațional) se utilizează în special în proiecte de integrare a mai multor aplicații, din mai multe organizații și de partajare a resurselor prin Internet. Este creat din mai multe campus grid, prin folosirea unor politici și protocoale globale.

1.3 Avantajele Grid Computing [7]

Contextul informatic în care funcționează bine un sistem în arhitectură GC este format din: suportul hardware și software în rețea de calculatoare, suportul organizațional și informațional. Într-un astfel de context, pot fi evidențiate câteva dintre cele mai importante avantaje ale tehnologiei GC. Acestea sunt utile, în special, în procesul de studiu preliminar care poate fundamenta, printre altele, decizia de a dezvolta o soluție de baze de date în arhitectura GC.

Virtualizarea(virtualization) este asigurată de un serviciu de introducere în GC(discuri, procesoare, BD, aplicații etc.) să se integreze firesc fără a induce fragilitate în sistem. În afară de faptul că stabilește diferite legături între componentele GC, virtualizarea permite fiecărei componente GC să reacționeze mai repede la schimbarea contextului de lucru și să se adapteze repede dacă unele componente au căzut, fără a compromite performanțele sistemului în ansamblu. Noțiunea de virtualizare este mai veche în informatică, dar ea a fost adaptată și dezvoltată pentru arhitectura GC.

Furnizarea dinamică a resurselor(dynamic provisioning) înseamnă distribuirea resurselor acolo unde este nevoie de ele. În contextul GC, resursele pot semnifica: cererile adresate serverului – care trebuie tratate, datele – care trebuie accesate și prelucrate, calculele – care trebuie rezolvate. Există un serviciu de administrare(broker service grid)care cunoaște necesitățile componentelor GC și resursele disponibile, le asociază logic în mod dinamic, făcând astfel eficient întregul sistem. Ulterior, el pote ajusta aceste asocieri la schimbările contextuale. Rețelele de calculatoare folosesc de mai multă vreme alocarea dinamică a resurselor. În arhitectura GC sunt însă diversificate tipurile de resurse furnizate și sunt, de asemenea, utilizate noi tehnici de alocare dinamică a resurselor, atunci când este nevoie și acolo unde este nevoie.

Punerea în comun a resurselor(resource pooling) este necesară în GC pentru a obține o mai bună utilizare a resurselor și pentru a realiza costuri mai mici. Prin plasarea unor spații de memorie externă sau a unor servere într-un ansamblu comun, procesele executabile ale GC au o mare flexibilitate în optimizarea relației nevoi-resurse. Partajarea resurselor se realizează prin software. Mecanismul, folosit anterior în sistemele distribuite, este adaptat și dezvoltat pentru arhitectura GC.

Adaptarea automată a sistemelor (self adaptive systems) are ca efect automatizarea(reducere) și simplificarea sarcinilor administratorilor. O infrastructura GC ar fi impracticabilă dacă fiecare nod din grilă ar necesita intervenție manuală în mod constant. Multe din sarcinile care erau executate de administratori acum sunt tratate de software. Tendința de automatizare a sarcinilor administratorului de BD se manifestă de câțiva ani, ea fiind prezentă, de exemplu, în Oracle începând cu versiunea 9i. Odată cu versiunea 10g automatizarea administrării BD este cuvânt de ordine, componenta Grid Control jucând un rol esențial în acest sens.

Managementul unificat(unified management) pentru întreținerea EGC semnifică faptul că sarcinile administratorilor sunt simplificate și integrate într-un singur instrument care poate monitoriza, furniza și administra fiecare componentă din grilă. Un astfel de instrument evaluează disponibilitatea și performanțele fiecărui nod, astfel încât la orice problemă din sistem sau pentru orice componentă indisponibilă, se emite un mesaj. În GC administratorul tratează grupuri de componente ca pe o singură entitate logică, astfel încât sarcinile sunt definite o dată și executate de mai multe ori. Managementul unificat implementează cele două concepte prezentate mai sus la EGC: unul din mulți(îmbină facilitățile: virtualizare, furnizare dinamică, punerea în comun a resurselor), mulți ca unul(îmbină facilitățile: adaptarea automată a sistemelor, management unificat). În Oracle managementul unificat este realizat prin pachetul Enterprise Manager.

CAPITOLUL 2

ARHITECTURA GRID COMPUTING

2.1 Componentele unei arhitecturi Grid [7]

Arhitectura GC evidențiază grafic diferitele componente și legăturile dintre ele. Structurarea componentelor se face pe patru niveluri(aplicații, server de aplicații, baze de date, echipamente), conectate prin mecanismele de interfață de servicii si monitorizare(control). Arhitectura de tip GC presupune o multitudine de echipamente și de produse software care comunică prin intermediul rețelelor de Intranet sau Internet, realizând o structura de tip portal, cu asigurarea certificării, autorizării, autentificării și a auditării proceselor. Se ajunge practic la un portal, care permite în mod transparent accesul utilizatorilor la serviciile grid, fără ca acesta să identifice resursele care îi procesează operațiile, într-un mod unitar. De cele mai multe ori, portalele de tip grid se realizează folosind componente Java, care permit portabilitatea pe orice tip de platformă. Portalul poate interacționa cu orice grid prin intermediul interfețelor de tip API(Application Program Interfaces).

Prezentăm în continuare componentele unei astfel de arhitecturi, precum și funcționalitatea lor. Se observă că o parte dintre aceste componente se regăsesc într-un sistem de baze de date distribuite, iar o altă parte în arhitectura Network Computing – NC. Ambele arhitecturi sunt respectate de sistemul Oracle și de aceea el s-a putut adapta ușor la GC.

Figura 2.1 Arhitectura GC

Interfața de servicii/comunicare(grid service interface). Conexiunea între cele patru straturi ale arhitecturii GC este dinamică, ajustându-se la momentul execuției, optimizând performanțele și adaptându-se căderilor unor componente. Interfața presupune un mecanism de comunicare între toate componentele GC, care cunoaște sau descoperă nevoile consumatorilor de resurse și rezolvă aceste nevoi, asociindu-le cu furnizorii de resurse.

Monitorul(grid control). Monitorul este un produs de management puternic care permite administratorului să supravegheze toate activitățile din GC. El are un mecanism integrat care intervine atunci când este necesar, oriunde și oricând in GC.

Echipamentele(hardware). Resursele hardware(discuri, procesoare, componente de rețea etc.)pot fi alocate în mod dinamic de către un SGBD conform anumitor politici și programări, folosind un mecanism orientat pe servicii(service-orientated). Nivelurile înalte ale GC, ca de exemplu BD sau Serverele de aplicații, nu trebuie să se preocupe de amănunte(unde se face stocarea, unde se face conectarea etc.). interfața de comunicare tratează detaliile legate de conectarea serverelor și BD cu echipamentele de care au nevoie.

Baza de date(database). Bazele de date sunt atât consumatori de resurse cât și furnizori de resurse într-o arhitectură GC. Pentru resursele hardware, BD sunt consumatori de resurse, iar pentru serverele de aplicații sunt furnizoare de resurse. La nivelul BD în arhitecturi GC, punerea la un loc a resurselor duce la existența unei singure BD, integrate la nivel logic, sau unui număr mic de BD, fiecare putând consta în mai multe instanțe care se execută pe clustere. Sarcinile sunt împărțite optim pe instanțele BD, separate pe calculatoare diferite. BD se adaptează în mod automat la căderea unei instanțe sau la adăugarea unei noi instanțe pe un cluster.

Serverul de aplicații(application server). Serverele de aplicații sunt consumatoare de resurse hardware și sunt resurse pentru BD, furnizând mediul de execuție al aplicațiilor. În GC resurserele de tip server de aplicații sunt puse în comun, similar cu BD. Un singur Server de aplicații constă dintr-o multitudine de instanțe care rulează pe calculatoare diferite, dar având lucrul coordonat și folosind algoritmi specifici. Dacă o instanță cade atunci clientul este dirijat spre altă instanță disponibilă.

Aplicațiile(applications). Pentru a beneficia de tot avantajul tehnologiei GC, aplicațiile ar trebui să-și facă cunoscut comportamentul lor către alte aplicații, prin intermediul interfețelor standard, astfel încât funcționalitatea de la alte aplicații să se poată combina ușor pentru implementarea logicii afacerii. Serviciul de Web este termenul folosit pentru acest nivel, care permite folosirea coordonată a diferitelor aplicații.

2.2 Baze de date în arhiectura Grid Computing [3,7]

Tehnologia GC oferă servicii prin care se concentrează puterea de calcul de la nivelul unei organizații, în mod eficient și sigur, inclusiv stocarea datelor, în rețeaua de calculatoare conectată la Internet. Tehnologia GC a apărut în SUA la sfârșitul anilor '90 și a fost preluată, pentru prima dată în 2003, pentru baze de date, în infrastructura Oracle. Rolul acesteia este de a concentra, la nivelul unei organizații, o putere de calcul foarte mare, pe care niciun calculator,oricât de puternic ar fi, nu o poate asigura. Mai mult, această putere de calcul este monitorizată eficient de infrastructura software pentru baze de date, evitându-se timpii morți și sugrumarea traficului de rețea. În acest fel, resursele de calcul vor fi uriașe, inclusiv spațiul de stocare pentru date, de ordinul petabytes(PB), gestionat eficient de SGBD. Apariția și dezvoltarea tehnologiei GC s-a bazat pe existența altor tehnologii informatice: bazele de date avansate, Internet, platforma Java, tehnologia orientată obiect etc.

Grid Computing oferă o infrastructură care presupune utilizarea integrată și colaborativă a resurselor de calcul, a datelor, a rețelelor de calculatoare la nivelul organizației. Acest lucru presupune o investiție mare, iar astfel de proiecte sunt acum realitate în toată lumea, inclusiv în Europa. Folosirea în comun a resurselor de calcul la nivelul unei companii, în mod eficient și sigur, este o prioritate în condițiile globalizării economiei. În acest sens, în anii 2000 au dezvoltat proiecte de cercetare majoritatea marilor firme de informatică: Oracle, IBM, Microsoft etc.

Aplicațiile cu baze de date în arhitectura GC țin cont de urmatoarele aspect:

– asigură un management distribuit efficient;

– menține controlul integrat asupra resurselor de calcul;

– asigură disponibilitatea comună a datelor;

– identifică soluțiile optime de acces la date;

– crește productivitatea de lucru pentru beneficiar;

– asigură un mediu de lucru prietenos cu acces la numeroase facilități.

Domeniile de aplicabilitate ale aplicațiilor cu baze de date cu un mare grad de integrare a tehnologiilor informatice, așa cum sunt și cele de tip GC, sunt dintre cele mai numeroase. Acest lucru este posibil datorită interferenței tehnologiilor informatice care oferă aplicațiilor rezultate: o mare deschidere, o flexibilitate deosebită, interoperabilitate, eficiență în utilizarea și gestionarea resurselor de calcul, o putere de calcul uriașă. Astfel, marketingul orientat pe client are o influență deosebită privind dezvoltarea aplicațiilor informatice cu baze de date pentru afacerile organizațiilor.

Gradul de raspândire al tehnologiei GC în lume este aproximativ același pe zonele geografice America de nord, Europa, Asia Pacific și anume în jur de 5, pe o scară de la 0 la 10. Studiul popularității tehnologiei GC a fost făcut de organismul Oracle Grid Index – OGI. Un rol important în răspândirea acestei tehnologii l-au avut aplicațiile cu baze de date support pentru afaceri: Enterprise Resource Planning – ERP, Customer Relationship Management – CRM, Business Intelligence – BI etc.

Enterprise Grid Alliance – EGA este unul dintre oganismele care promovează tehnologia GC. El sprijină două clase de aplicații cu baze de date în arhitectură GC:

• aplicații comerciale, care sunt fundamentale pentru informatizarea oricărei organizații(ERP, CRM, BI);

• aplicații specific, care au un rol important privind eficiența organizației(analiza financiară, analiza datelor etc.).

producătorii de aplicații în arhitectură GC, în special cei din grupul EGA(în frunte cu Oracle care a furnizat prin versiunea 10g primul SGBD ce funcționează și în arhitectură GC), au dezvoltat în comun proiecte în acest sens, datorită interfernței de numeroase tehnologii informatice, dar și datorită costurilor ridicate. Un astfel de proiect este MegaGrid în care fiecare companie participantă pune la dispoziție propriile tehnologii pentru construirea uneiinfrastructuri GC: Oracle oferă infrastructura Oracle 10g, Dell oferă servere, Intele oferă procesoare, EMC sisteme de stocare. Se pot astfel dezvolta și rula aplicații informaticecu baze de date performante și sigure în arhitectură GC.

În țara noastră sunt mai multe proiecte GC dezvoltate și promovate în mediul universitar informatics și sprijinite de CNCSIS. Scopul este de a se dezvolta și exploata o infrastructura eScience în România, care să colaboreze cu infrastructurile similar din Uniunea Europeană.

Toate aceste tipuri de proiecte pot fi grupate în două categorii:

– dezvoltarea GC ca infrastructură cu hardware, software corespunzător, precum și cu un mecanism administrative corespunzător;

– cercetarea GC ca middleware ce investighează platformele ce pot monitoriza efficient resursele de calcul la nivelul organizației.

Rezultă că GC presupune, prin definiție, integrare și interoperabilitate de tehnologii informatice. În aceste condiții, pentru ca tehnologia să funcționeze practice și să se poate dezvolta ca un sistem deschis este necesară o cât mai mare standardizare. Informatica suferă încă de lipsa unor standard și de aceea noile tehnologii țin cont de acest lucru. Pentru tehnologia GC eforturile de standardizare sunt coordonate de organismul Global Grid Forum – GGF. În plus, marii furnizori de aplicații informatice în arhitctură GC (Oracle, EMC, HP, Dell, Intel etc.) au înființat în 2004 Enterprise Grid Alliance – EGA, care promovează tehnologia GC dar și emit standard și specificații în domeniu. EGA se preocupă și de securitatea aplicațiilor informatice în arhitectură GC, formulând în acest sens un set de reguli pe care să le respecte producătorii și utilizatorii acestor aplicații. O parte dintre reguli sunt valabile și pentru aplicațiile în arhitectura client-sever sau în arhitectura centrealizată, dar problemele de securitate sunt mai numeroase pentru aplicațiile în arhitectura GC pentru că sunt mai multe posibilități de acces, din mai multe aplicații, la aceleași resurse.

Bazele de date distribuite, cu exemplul elocvent de implementare în Oracle 10g și 11g RAC(Real Application Cluster), se pare că vor evolua, alături de rețelele distribuite, prin integrarea tehnologiei GC. Dacă tehnologia bazelor de date o integrează acum pe cea GC, aceasta integrează la rândul ei mai multe metode privind evoluția tehnologiei calculului:

– calculul distribuit – pentru a avea o putere de calcul suficient de mare se conectează resursele de calcul într-o rețea de calculatoare utilizată cao resursă unică, integrată;

– metacalculul – legarea centrelor de supercalculatoare în rețele de mare viteză, ca un caz particular de calcul distribuit;

– calcul cluster – conectarea unor calculatoare eterogene între ele, obținând o putere de calcul mai mare decât a unui calculator mare(main-frame). Avantajul major este scalabilitatea: pot fi adaugate la un cluster existent alte calculatoare;

– calcul Pee to Peer – prin descărcarea unei aplicații dintr-o rețea pe calculatorul personal, un utilizator se va conecta cu toți utilizatorii care au aceeași aplicație. Utilizatorii vor specifica ce informații sunt publice și acestea vor fi partajate între ei. Astfel, se pot partaja informații în rețea între utilizatori fără să existe un server central;

– calcul Internet – cu ajutorul Internetului se pot construe supercalculatoare virtual care lucrează cu nodurile (grid) simultan, pe mai multe părți ale problemei de rezolvat. Aceste noduri descarcă datele necesare de pe Internet, le procesează și apoi le încarcă în sistemul central, pentru post-procesare;

– grid computing local – un produs software de tip middleware, care nu este nici aplicație informatică, nici sistem de operare, ci ceva intermediar. Produsul verifică ce calculatoare din rețea sunt disponibile pentru rularea, în mod optim, a unei aplicații.

CAPITOLUL 3

TEHNICI DE IMPLEMENTARE A TEHNOLOGIEI GC

Pentru a analiza principalele direcții de cercetare în domeniul tehnologiei Grid Computing s-a plecat de la studiul activităților curente atât din cadrul proiectelor de dezvoltare middleware Grid, cât și de implementare a infrastructurii Grid. S-a investigat o tehnologie care prezintă atât caracteristici comune cât și complementare, respectiv sistemele mult-agent. Totodată s-au identificat principalele evoluții actuale care sunt legate de virtualizarea resurselor de calcul și implicațiile acestora în transformarea tehnologiei Grid Computing. În continuare s-au studiat interoperabilitatea și federalizarea infrastructurilor de calcul, mediile de execuție pentru aplicații, toleranța la defecte și monitorizarea și managementul infrastructurii de calcul. Componentele acestei analize sunt prezentate pe larg în cele ce urmează.

3.1 Conexiune cu sistemele multi-agent [1]

Analizând tehnologia Grid Computing și sistemele agent, se poate afirma că acestea dezvoltă concepte și mecanisme pentru sisteme distribuite din perspective diferite. Tehnologia Grid s-a concentrat pe infrastructură, instrumente, aplicații pentru utilizarea resurselor într-un cadru partajat și într-un mod sigur în cadrul Organizațiilor Virtuale . În contrast, sistemele multi-agent s-au concentrat pe inteligență: rezolvarea problemelor în mod autonom și funcționare flexibilă în medii dinamice cu elemente incerte. Există o convergență a intereselor celor două comunități: sistemele agent necesită o infrastructură robustă, iar sistemele Grid necesită un comportament flexibil și autonom.

3.2 Virtualizarea resurselor de calcul [1]

Pentru a beneficia de avantajele virtualizării este necesar să se definească un model pentru crearea mașinilor virtuale în cadrul unei infrastructuri Grid ce permite definirea de resurse virtuale. Astfel, o modalitate de a instanția mașini virtuale în cadrul unei infrastructuri Grid este bazată pe instrumentele Globus Toolkit și GridWay. Un alt exemplu de utilizare propune un model pentru crearea de servicii Grid în cadrul unor containere virtuale izolate .

Un sistem care se integrează complet în cadrul unui sistem local de management al resurselor poate fi o soluție pentru virtualizarea resurselor computaționale și oferirea lor prin intermediul unor interfețe disponibile în mediul Grid sau Cloud .

Pentru eficientizarea utilizării instanțelor virtuale este necesară însă existența unui sistem de fișiere distribuit, care să permită accesul eficient la resursele virtuale. Spre exemplu, datorită performanțelor deosebite în cadrul WAN, Global File System este un candidat serios pentru a suporta atât tehnologia Grid cât și virtualizarea resurselor. Global File System poate fi dat ca exemplu pentru evoluția sa de la stadiul de concept, la cel de prototip și în final la cel de implementare pentru producție . De asemenea se poate utiliza Lustre ca sistem de fișiere ce are potențialul să ofere utilizatorilor performanțe deosebite.

Disponibilitatea unui sistem I/O scalabil și de mare performanță este o cerință majoră și pentru aplicațiile specifice domeniului High Performance Computing (HPC) și pentru aceasta se studiază viabilitatea tehnologiei Xen ca o soluție de virtualizare pentru domeniul HPC din punct de vedere al I/O.

3.3 Definirea și utilizarea clustere-lor virtuale[1]

Utilizând virtualizarea ca abstractizare a resurselor de calcul, clusterele virtuale se pot descrie ca fiind un grup de mașini virtuale (VM-uri) proiectate să execute în comun o anumită funcție.

Conceptul de Cluster dedicat unei Organizații Virtuale (VOC) reprezintă un nou model de execuție a aplicațiilor unui utilizator în cadrul unei infrastructuri de calcul distribuit de tip Grid. VOC oferă un mediu de execuție omogen și adaptat cerințelor unui utilizator, fără a necesita construirea unui cluster fizic sau crearea de containere virtuale pentru fiecare aplicație.

Administrarea și utilizarea unui VOC este permisă doar Organizațiilor Virtuale care sunt interesate, acest sistem fiind complet transparent utilizatorilor sau altor Organizații Virtuale care nu îl accesează. Sistemele VOC se auto-instalează și se auto-administrează pe baza unor politici de utilizare care sunt configurabile. Acestea reprezintă un nou mecanism pentru suprapunerea unui cluster dedicat peste infrastructura Grid; astfel clusterele virtuale pentru Organizații Virtuale (VOC) sunt sisteme compuse din mașini virtuale ce furnizează clustere de calcul dedicate pentru o

Organizație Virtuală . Mașinile virtuale individuale sunt independente de resursele fizice astfel încât clusterele virtuale se pot extinde chiar pe mai multe site-uri Grid.

O problemă importantă pentru utilizarea VOC drept abstracție pentru Grid este legată de nevoia de a planifica și instanția mașinile virtuale în cadrul resurselor fizice. Spre exemplu, un mod de implementare al unui planificator pentru clustere virtuale este bazat pe sistemul Condor.

Cozile de execuție pentru job-uri sunt monitorizate iar mașinile virtuale care sunt dedicate executării de aplicații în cadrul unei Organizații Virtuale sunt create și pornite astfel încât job-urile care aparțin unei VO sunt executate pe aceste mașini virtuale. Astfel se creează un cluster de execuție de aplicații dedicat unei Organizații Virtuale.

După finalizarea aplicațiilor, mașinile virtuale sunt oprite și distruse astfel încât resursele fizice sunt disponibile din nou pentru a executa alte mașini virtuale. Acest sistem este eficient pentru aproape toate tipurile de aplicații, mai puțin cele cu un timp scurt de execuție. De asemenea, un nou mecanism pentru managementul resurselor în cadrul unui cluster în mod dinamic se bazează pe conceptul denumit Cluster-on-Demand (COD) . COD poate să aloce noi servere în clustere virtuale ce au configurate medii de execuție pentru aplicații independente. Pentru aceasta se folosește Sun Grid Engine ca sistem de management al resurselor locale.

Clusterele virtuale sunt o abstractizare ce permite gestionarea resurselor într-un mod avansat, aceasta fiind utilă pentru infrastructuri Grid. Acestea suportă alocarea resurselor în mod dinamic și conform cu o politică de alocare, rezervarea resurselor și crearea lor în funcție de necesități.

3.4 Interoperabilitatea și federalizarea infrastructurilor de calcul [1]

Un alt domeniu de cercetare pentru tehnologia Grid este cel referitor la federalizarea infrastructurilor Grid. Obiectivul este de a se construi infrastructuri Grid complexe, capabile să susțină cererile oricărui tip de serviciu sau aplicație, și sunt studiate metode și tehnici pentru realizarea interoperabilității infrastructurilor Grid .

Spre exemplu, pentru a se asigura interoperabilitatea între middleware-ul Grid UNICORE și componenta CREAM-BES din cadrul middleware-ului gLite, se utilizează standarde precum OGSA-BES și JSDL .

Sistemul UNICORE – Uniform Interface to Computing Resources a fost dezvoltat cu scopul de a oferi utilizatorilor centrelor de calcul de mare performanță din Germania o interfață simplă, intuitivă și sigură de acces la resursele eterogene de calcul existente în aceste centre .

În același timp sunt investigate și mecanisme ce ar putea fi folosite pentru a asigura un nivel de calitate pentru servicii (QoS). Aceste mecanisme implică extinderea elastică a infrastructurii Grid utilizând resurse oferite de furnizori de infrastructură Cloud, care pot fi comerciali (Amazon EC2) sau din mediul academic și de cercetare (Globus Nimbus).

3.5 Medii de execuție pentru aplicații [1]

Aplicațiile executate în cadrul unei infrastructuri Grid pot fi simple job-uri sau fluxuri complexe de sarcini care au dependențe. Pentru a putea satisface aceste cerințe este necesar să se analizeze middleware-ul Grid și serviciile disponibile în cadrul infrastructurii Grid, precum și să se analizeze modul prin care aplicațiile pot interacționa cu acesta.

De asemenea, este necesar să existe un sistem care corectează dinamic execuția paralelă a unor aplicații în mediul Grid în concordanță cu modificările de încărcare ale resurselor utilizate

3.6 Toleranța la defecte[1]

Toleranța la erori reprezintă o problemă semnificativă în cadrul unei infrastructuri Grid. Numeroase tehnici au fost investigate pentru a detecta și corecta erorile în cadrul unor medii distribuite, iar unele dintre cele mai eficiente metode se bazează pe detectarea nesigură a erorilor.

Globus Toolkit, ca sistem care administrează resursele de calcul, folosește pentru detectarea și raportarea defectelor de funcționare a componentelor metode bazate pe această tehnică .

O platformă Grid tolerantă la defecte ce se bazează atât pe detectori nesiguri de defecte cât și pe serviciul de detectare a defectelor din componența Globus Toolkit, poate oferi strategii efective de răspuns pentru probleme care pot apare în executarea aplicațiilor utilizatorilor sau chiar a componentelor de middleware. Componentele individuale pot avea defecte care le împiedică funcționarea corectă, însă problemele unei componente în cadrul unui sistem distribuit nu trebuie să afecteze funcționarea acestuia.

Astfel, o strategie pentru obținerea toleranței la defecte constă în crearea de sisteme redundante ce pot fi migrate, iar design-ul și implementarea unor mecanisme pentru aceasta și pentru restabilirea fluxurilor complexe de aplicații în mediul Grid reprezintă o temă importantă de cercetare.

Problema realizării de servicii Grid fiabile prin replicarea acestora pe două sau mai multe sisteme în configurația primar-backup este extrem de importantă . Pentru aceasta se poate utiliza un protocol pentru obținerea configurației primar-backup utilizând Open Grid Services Infrastructures (OGSI), care a fost implementat utilizând toolkit-ul Globus.

3.7 Monitorizarea și managementul infrastructurii de calcul[1,5]

Una din principalele probleme cu care se confruntă sistemele distribuite de mare performanță o reprezintă monitorizarea scalabilă a stării sistemelor . Software-ul pentru monitorizare trebuie să fie capabil să identifice foarte repede erorile astfel încât acestea să poată fi reparate automat.

Un sistem de monitorizare oferă o imagine globală a stării infrastructurii ce poate fi de folos pentru identificarea problemelor de performanță și poate ajuta la planificarea capacității de calcul.

Spre exemplu, MonALISA (Monitoring Agents in A Large Integrated Services Architecture) oferă un serviciu de monitorizare distribuită. MonALISA se bazează pe o arhitectură bazată pe servicii, fiind distribuită, scalabilă și dinamică.

Prin definirea unor protocoale standard pentru descoperirea, accesarea, monitorizarea și gestionarea resurselor de calcul, a sistemelor de stocare sau a rețelelor, tehnologiile Grid fac posibilă alocarea dinamică a resurselor pentru aplicațiile care solicită aceasta.

Cu toate acestea, deși tehnologiile Grid oferă posibilitatea utilizatorilor de a accesa resurse diverse, acestea nu pot garanta faptul că o dată ce o resursă a fost accesată se poate oferi o calitate a serviciilor (QoS) la nivelul așteptat.

Acesta se datorează și faptului că majoritatea platformelor Grid nu oferă facilitatea de garantare a performanțelor: activitățile asociate cu un utilizator sau o Organizație Virtuală pot influența performanțele unor procese executate de un alt utilizator într-un mod necontrolat.

De asemenea, middleware-ul Grid are limitările sale, respectiv arhitectura sa nu oferă suport pentru crearea de sisteme distribuite care se auto-administrează, fiind deci potrivită pentru sistemele tradiționale de management ce sunt de tip ierarhic și care oferă capacități rudimentare de auto-management prin intermediul buclelor de control.

Grid middleware este un nivel software care furnizează funcționalitățile necesare partajării de resurse eterogene și crearea unei organizații virtuale. El este format din 5 niveluri(fig. )

Figura 3.7.1 Grid middleware- nivele

Fabric – furnizează interfețe la resursele fizice(de calcul, de stocare, retea,etc) pentru care accesul partajat este mediat de protocoalele Grid-ului și oferă componente care implementează operațiile locale, specifice fiecărui tip de resursă.

Protocoale& API-uri

Include protocoale & API-uri oferind acces la resurse partajate

Viziune logica asupra resurselor și nu una fizică

Connectivity este un nivel al protocoalelor de comunicare si de autentificare pentru tranzacțiile de rețea din interiorul Grid-ului.

Servicii minimale pentru comunicare: transport (e.g. protocoale pentru transferul datelor între resurse, accesarea de la distantă a unei resurse), dirijare și numire.

Soluții de autentificare: suport pentru single sign on, delegare, integrarea cu soluții de securitate locală, relații bazate pe încredere(trust).

Protocoale& API-uri

•Protocoalele Internet standard

•Protocoale privind securitatea:

Grid Security Infrastructure (GSI)–Autentificare, autorizare& protejare

Resource are ca scop utilizarea protocoalelor pentru comunicare si asigurarea securității(definite in Connectivity) pentru negocieri sigure, monitorizare, control, contabilitate și plata operațiilor de partajare a resurselor individuale.Protocoalele se concentrează asupra resurselor individuale ignorându-se problemele legate de starea globală.

Exemplu de protocoale:

Protocoale de informare: folosite pentru obținerea informațiilor despre structura si starea unei resurse(e.g. configurație, încărcare, politica de utilizare);

Protocoale de management/administrare: folosite pentru negocierea accesului la resursele partajate și pentru verficări privind utilizarea resurselor în concordanță cu regulile după care au fost partajate .

Protocoale& API-uri

Protocoale pentru ințierea și controlul partajării resurselor locale

Managementul alocării resurselor Grid-ului: Grid Resource Allocation Management (GRAM)

Alocarea, rezervarea, monitorizarea si controlul de la distantă al resurselor

Grid FTP–acces și transport eficient al datelor

Serviciu de informare privind resursele Grid:

Grid Resource Information Service (GRIS)

Acces la structura si starea unui nod al Grid-ului

Collective oferă protocoale și servicii care privesc global resursele Grid-ului, precum facilitarea interacțiunilor dintre seturi de resurse.

Totodată acest nivel implementează servicii diverse de partajare:

-catalogare(directory),

-co-alocare, planificaresiintermediere(brokering services)

-monitorizare și diagnosticare(de exemplu:supraîncărcarea)

-replicare și descoperire

-cuantificare și plată

Application cuprinde aplicațiile utilizator care operează în Grid:

Medii de programare + biblioteci de nivel înalt

Aplicații Grid-enable (sau gridified) – aplicații proiectate să ruleze în paralel și să utilizeze procesoare multiple în Grid.

Funcționalități principale oferite de Grid:

Virtualizarea și integrarea de resurse autonome eterogene

Furnizarea de informații privind resursele și disponibilitatea lor

Management flexibil și dinamic privind alocarea resurselor

Securitate (autentificare si autorizare) și incredere

Managmentul licențelor

Facturare si plată

Furnizarea de QoS

Grid computing furnizează avantaje companiilor astfel: la nivel de mangment IT și la nivel de business.

Avantaje la nivel de mangment IT:

-Grid înglobează resurse eterogene – disponibilitatea unei puteri mai mare de calcul și utilizarea eficientă a resurselor;

-Scăderea costurilor achizițiilor;

– Scalabilitatea infrastructurii prin reducerea granițelor între departamente;

-Eficiența în calcul și acces la resursele alocate;

-În combinație cu Utility Computing, Grid Computing permite transformarea de cheltuieli de capital pentru infrastructura IT în cheltuieli operaționale și oferă posibilitatea de scalabilitate sporită și flexibilitate.

Avantaje la nivel de business:

– Costuri mai mici si venituri mai mari;

– Posibilitatea mai ușoară de colaborare;

– Posibilitatea de a crea o Organizație virtuala cu parteneri de afaceri.

3.8 Grid Computing – Inițiative [5]

GridPP (UK Computing Grid for Particle Physics – http://www.gridpp.ac.uk/ ) contribuie cu peste 40.000 PC-uri ca parte integrantă a celui mai mare Grid din lume: LCG (LHG Computing Grid).

LHG = Large Hadron Collinder (CERN, din 2007)

GridPP face parte din cadrul proiectului EuroGrid.

Fraunhofer Grid Alliance are ca scop oferirea unui Grid computațional pentru acces facil la resursele Grid-ului via un portal Web. Este bazat pe Globus Toolkit si funcționează în mediul academic și industrial(www.fhrg.fhg.de).

Jgrid (http://jgrid.jini.org) este un framework pentru Grid-uri compuse din component hardware/software vazute ca servicii. Se bazează pe tehnologia Jini – infrastructura și model programatic pentru crearea de sisteme distribuite dinamice în Java. Aplicațiile jGrid pot fi dezvoltate via P-Grade (mediu de dezvoltare grafic).

Alchemi este sistem Grid bazat pe .NET Framework și asigură interoperabilitatea cu alte sisteme Grid via Gridbus Grid Service Broker.

3.9 Grid Computing-Clasificare [5]

În raport cu tipul de resurse preponderent administrate:

– Compute Grid – folosit pentru partajarea resurselor computationale (CPU) – Exemple: procesări grafice intensive;

– Data Grid – concentrat pe stocare, management si partajare de date distribuite si eterogene;

– Application Grid – concentrat pe mangmentul aplicațiilor si furnizarea de acces în mod transparent la soft și biblioteci la distanță. Exemplu: grid-uri în domeniul bioinformaticii sau științelor pământului;

– Service Grid – rezultat din convergența Grid și SOA (Service-oriented Computing), oferă suport pentru partajarea eficientă a serviciilor.

În raport cu domeniul de partajare a resurselor:

– Cluster Grid

– Enterprise Grid

– Utility Grid Services

– Partner/Community Grids

1.Cluster Grid

Cluster Grid este un tip de sistem distribuit si paralel și constă dintr-o colecție de calculatoare autonome, interconectate folosite (și văzute) ca o resursă unică la nivel de departament/grup.El face posibilă utilizarea la maxim a resurselor colecției de calculatoare (mainframe-uri, PC-uri, laptop-uri, smartphone-uri, etc).

Cluster = ansamblu de calculatoare dintr-un LAN, care formează o resursă unică de calcul.Clusterele nu oferă implicit partajare de resurse(îmbunătățește capacitatea de calcul și de stocare), și poate fi considerat primul pas spre Grid Computing .

Figura 3.9.1 Cluster Grid

Enterprise Grid facilitează partajarea de resurse între mai multe departamente și colective din cadrul unei organizații (virtuale).Mai este numit și intra grid ori campus grid.

Exemplu: Compania Farmaceutica Novartis

-Deținea în 2003 o infrastructura formată din câteva mii de PC-uri desktop;

-Initial Grid Pilot: 2003, Basel (Elveția), 50 PC-uri “Grid enabled” conectate la nodurile existente(Scop: determinarea structurii proteinelor);

-În fiecare nod există un agent care verifică încarcarea sistemului;

-Rezultat: o săptămâna de rulare în Enterprise Grid a condus la rezultate care se puteau obține în 3,18 ani;

-2700 PC-uri (Basel, Viena, Cambridge) .

Figura 3.9.2 Enterprise Grid

3.Utility Grid este un Grid dezvoltat și administrat de un furnizor de servicii, și utilizarea capacității de calcul și/sau stocare se face în maniera pay-per-user.Figura 3.9.3 Utility Grid

Funcționalitate: utilizatorul nu deține un astfel de Grid și nu deține controlul asupra operațiilor; sunt transmise datele și cereri de calcul și apoi se așteaptă rezultatul. Se întâlnsc probleme de securitate si privacy și probleme de reliability. Nu sunt necesare investiții în infrastructura IT și totodată Utility Computing oferă scalabilitate și flexibilitate la cerere.

Exemplu: Sun Grid Compute Utility din 2006:

Pay-per-use: 1$/CPU –ora

A oferit mai apoi si suport pentru aplicatii

HP Labs oferă Utility Computing companiei DreamWorks .

3. Partener/Community Grid oferă support pentru construirea de Organizații Virtuale bazate pe infrastructura IT de partajare de resurse.Arhitectura poate fi vazută ca o colecție de resurse independente(ex. Cluster Grids) interconectate de un Grid middleware global.

Partener grids se stabilesc între companii sau universități ce au un scop comun. Community Grids se bazează pe donația de resurse (deseori de la personae private).

Exemplu: SETI@HOME

Figura 3.9.3 Partener Grid

CAPITOLUL 4

PROIECTAREA APLICAȚIILOR GRID

Acest capitol tratează aspectele ce trebuie luate în considerare în construirea unei aplicații grid, precum: analiza problemei, arihitectura aplicației și design-ul aplicației. Unele dintre aceste aspecte nu se aplică pentru fiecare proiect.

4.1 Construim de la început sau re-folosim cod? [4]

Dezvoltarea unei aplicații grid începe prin examinarea problemei și prima întrebare adresată este: Unde începe proiectul? Primul pas este o analiză de calificare a sistemului pentru a vedea dacă are sens să fie încadrat în grid. Dacă sistemul rezultă satisfăcator, se merge mai departe, trecându-se prin fazele standard de dezvoltare ale unui software de stabilire a cerințelor, design, implementare, testare, lansare și întreținere.

4.1.2 Construirea unei aplicații grid prin re-utilizarea de cod existent

Un task mai greu de realizat pentru dezvoltatori este să încadreze un sistem deja existent într-un sistem grid. Aceasta acțiune este în general numită împachetare (wrappering) și poate întâlni următoarele dificultăți, iar sistemul are o șansă mare să eșueze dacă acestea nu sunt depășite.

Codul existent este scris în Java.

Atunci când sistemul existent este codat în Java, integrarea este ușor de făcut pentru că necesită scrierea unei noi clase Java ce prezintă una sau mai multe metode publice.

Codul existent nu este scris în Java.

Dacă sistemul existent nu este scris în Java, atunci se pot folosi tehnicile Java Native Interface (JNI), dar există o restricție cu privire la sistemul de operare pe care serviciul grid poate fi lansat. De exemplu, un serviciu ce apelează direct Windows DLL poate fi lansat doar în Windows. Aceasta nu este o problemă majoră dacă grid-ul este omogen, dar cele mai multe grid-uri sunt de natură heterogenă ce limiteză potențialul de dezvoltare al unui serviciu grid.

Codul existent este mic și înglobat.

Aceasta este cea mai bună situație deoarece este posibilă construirea unui serviciu bine-definit, bazat pe o singură sarcină. Acest serviciu se folosește intens de procesor, acceptă un input, prelucrează și întoarce un rezultat.

Codul existent este mare și/sau prezintă multiple conexiuni

Dacă sistemul existent prezintă aceste caracteristici, acestea îl transformă într-un candidat suspicios pentru un serviciu grid. Nodurile grid-ului trebuie să fie foarte puternice pentru a putea face față sarcinilor mari și complexe. Dacă prin codul existent se fac multiple conexiuni cu alte sisteme și/sau o cantitate mare de date este transferată este foarte probabilă crearea de blocaje.

4.2 Calificarea unei aplicații [4]

Este foarte important ca o aplicație să fie întai analizată pentru a vedea dacă este bună pentru a rula într-un grid. Nu toate aplicațiile se dovedesc a fi de succes sau eficiente din punctul de vedere al costurilor. O aplicație este analizată din punctul de vedere a mai multor factori. În următoarele, o listă de criterii de considerat în analiza unei aplicații potențială pentru un sistem grid, este prezentată. Lista include atribute ale unei aplicații sau cerințe ce pot împiedica o aplicație de a deveni un bun candidat pentru a fi executată într-un mediu grid. Lista poate să nu fie completă, acest lucru depinzând de circumstanțele locale ale resurselor și de infrastructură. O schema de calificare a unei aplicații grid poate fi găsită la: http://developerWorks®.ibm.com/.

Lista următoare cuprinde cele mai critice aspecte ce pot dăuna sau chiar exclude o aplicație din a fi folosită într-un grid:

– Comunicare între procesele unui job ridicată, fără a avea o viteză mare de schimbare a conexiunii (de exemplu, MPI); în general aplicațiile multi-threaded necesită să le fie verificată nevoia de comunicare între procese.

– Cerințe stricte de planificare a job-urilor (job scheduling) ce depind de o furnizare necontrolată de date.

– Obstacole nerezolvate în stabilirea unei lățimi de bandă suficiente în rețea.

– Dependențe ce limitează mult mediul sistemului.

– Cerințe pentru tranzacții de tip business (commit și roll-back) sigure prin sisteme de tip grid. În momentul de față nu există standard pentru prelucrarea tranzacțiilor în grid.

– Inter-dependențe mari între job-uri, ce pot cauza o comunicare între procese crescută.

– Protocoale de rețea nerecunoscute folosite de diverse job-uri pot duce la interzicerea executării task-urile datorită regulilor firewall-ului.

4.3 Înțelegerea cerințelor [4]

Odată ce punctul de pornire al unui proiect a fost stabilit, următorul pas este examinarea cerințelor unui proiect. Cerințele sunt cheia unui design de succes, a implementării și a lansării în execuție a unui sistem. Orice programator este conștient de faptul ca fără un set detaliat de cerințe, nici un sistem nu va putea fi gata la timp și cu totală funcționalitate.

În ziua de astăzi există zeci de metodologii aplicate în definirea cerințelor. Ideea este de a convinge dezvoltatori să folosească o metodologie, fără a face o comparație a celor mai bune metodologii. Majoritatea proiectelor necesită ca 50% din efortul total să fie depus în analiza cerințelor, arhitectură și design, înainte ca prima linie de cod să fie scrisă. De aceea este foarte important a se folosi o metodologie în definirea cerințelor, indiferent care.

Una dintre metode, care a fost folosită cu succes în trecut presupune definirea tuturor cerințelor și a use-case-urilor corespunzătoare. Apoi, fiecare parte participantă la proiect semnează o scrisoare de acceptare. Odată ce fiecare membru a semnat, se poate asuma că cerințele întrunesc obiectivele finale ale sistemului și nu vor apărea surprize sau diferențe de scopuri. Orice schimbare substanțială adusă în timpul dezvoltării este vazută ca Change Request (cerere de schimbare) și este fie realizată prin adaos de timp sau buget, fie întârziată până la dezvoltarea următoarei versiuni.

4.3.1 Cerințe funcționale

Cerințele funcționale captează comportamentul ce se intenționeză ca sistemul sa-l manifeste, privind serviciile pe care sistemul intenționează să le ofere. Câteva exemple sunt:

– User login

– User logoff

– Customer Data Entry and Validation

– Transaction

– Print Monthly Report

– Overnight Batch Process

– Pulling Data from Business Partner

Un mijloc foarte comun de a determina cât de complete și corecte sunt cerințele este construirea de „use-case-uri”. „Use-case”-urile sunt un set de descrieri pas cu pas ale proceselor unui sistem cu referință la toate componentele interne și externe afectate. Use-case-urile pot fi folosite de echipa de testare pentru a verifica dacă cerințele au fost îndeplinite.

Use-case-urile sunt în mod general descrise în UML (Unified Modeling Language). Pe lângă use-case-uri, UML prezintă și alte tipuri de design orientat pe obiecte, precum:

› Diagrama de tip Clasă: definiția claselor și a relațiilor dintre clase; majoritatea uneltelor UML pot genera cod Java din aceste diagrame;

› Diagrama de Interacțiune: secvența obiectelor unui sistem în timp;

› Diagrama de Stare: secvențe de stări prin care un obiect trece în ciclul sau de viață;

› Diagrama de Activitate: o clasă specială de Diagrama de Stare.

UML a devenit o metodologie de modelare predominantă deoarece există multe produse ce le permit arhitecților și programatorilor să construiască un model întreg al sistemului, apoi să genereze cod Java direct din model. Un exemplu de familie de astfel de produse este IBM Rational Rose®.

4.3.2 Cerințe non-funcționale

1. Scalabilitate: Cu cât utilizarea resurselor crește cu atât sistemul nu mai poate suporta sarcini adiționale. Astfel, un sistem poate ceda din mai multe motive. Obiectivul unui sistem bine modelat este capabilitatea de a adăuga mai multe resurse să rezolve sarciniile adiționale, asigurând astfel o performanță aproape liniară și nevoia de a nu remodela sistemul.

2. Factori pentru o mai bună interfață a utilizatorului: Programatorii tind să neglijeze anumiți factori atunci când construiesc interfețele utilizatorilor, precum:

– Distribuția obiectelor într-o fereastră. O bară de meniuri în partea de sus, o bară de butoane sub, o bară de parcurgere în partea dreaptă a ecranului și uneori și în partea de jos, iar în centru conținutul aplicației este standardul fiecărui sistem de operare modern, în ceea ce privește așezarea în pagină.

– Meniurile. Structura clasică File-Edit-View-…-Help este bine înțeleasă de către utilizatori. Mai mult, aceștia sunt obișnuiți cu butoanele OK, Cancel și Help.

– Taste de accelerare. Combinațiile de taste permit efectuarea de operații fără a folosi mouse-ul, preferate de mulți și deloc costisitoare pentru dezvoltatori.

– Wizard-uri de multi-dialog. Constau într-o secvență de ferestre de dialog cu scopul de a colecta informații complexe de la utilizatori. Un button Previous este esențial pentru corectarea erorilor.

– Help. Majoritatea ferestrelor și dialogurilor prezintă pop-up-uri de ajutor, dar este necesar să se asigure că ajutorul furnizat este într-adevăr de ajutor, permițându-i utilizatorului să înțeleagă un concept, să rezolve o problemă sau să fie condus către o sursă externă.

– Internaționalizare. O aplicație va reuși sa-și satisfacă utilizatorii și să câștige unii noi, daca aceștia vor putea folosi aplicația în limba lor maternă.

– Accesibilitate. Utilizatorilor cu dizabilități trebuie să li se permită să folosească aplicația în mod eficient.

Scopul general este ca utilizatorii, de orice fel, să poată folosi o aplicație cât mai repede și mai eficient.

3. Tratarea erorilor: Atunci când o eroare apare și nu este rezolvată cu succes de către aplicație, este una dintre cele mai frustrante situații pentru utilzator.

4. Securitate: Securitatea este un domeniu complex și de aceea de cele mai multe ori nu este tratată suficient în contextul unei aplicații. Dezvoltatorii trebuie să țină cont de următoarele: – Autentificarea utilizatorului;

– Autorizarea utilizatorului;

– Criptarea datelor;

– Înregistrarea și alertarea evenimentelor.

5. Flexibilitatea aplicației: Un sistem nu este niciodată scris, lansat și neatins ulterior. Sistemul este restructurat și rescris de fiecare dată când apar probleme sistemul trebuie consolidat. Pentru o consolidare mai ușoară a sistemului există câteva aspecte de luat în cosiderare:

– Separarea codului și a datelor. Obiectele de tip dată nu trebuie să fie prea strâns legate de cod. Structurile de date ale unei aplicații trebuie să poată fi modificate fără a schimba codul.

– Definirea interfețelor de tip published. Codul unei aplicații poate fi modificat fără a crea niciun efect asupra modulelor externe.

– Design Plug-in. Sistemul trebuie definit ca un set de module independente ce se conectează la o bază și nu afectează codul acesteia.

6. Platforma server și client: Oricine este implicat în sistem trebuie să înțeleagă minimul platformelor hardware precum și o listă de pre-recuzite software pentru a evita apariția surpizelor în timpul dezvoltării, testării și executării. De exemplu comun este un sistem Web, ce așteaptă ca utilizatorul să folosească un browser Web.

7. Conexiuni externe: Aproape orice aplicație necesită conexiuni externe pentru a citi și/sau scrie date. Înainte ca dezvoltarea să înceapă este critic să fie listate toate sistemele externe împreună cu metodele de comunicare, formatele pachetelor de date, autentificare, autorizare, metode de conectare, proceduri de recuperare, performanțe așteptate și numele persoanelor de contact.

8. Performanță: Când intenționăm să executăm o aplicație într-un mediu grid, trebuie să considerăm performanța grid-ului precum și cerințele de performanță ale aplicației. Obiectivele performanței pot fi discutate din mai multe perspective.

– Din perspectiva furnizorului de servicii, obiectivul performanței este ca infrastructura grid să atingă utilizarea maximă a diverselor resurse din grid.

– Din perspectiva solicitantului de servicii, timpul de răspuns al unei aplicații executate în grid este important.

Timpul de răspuns este afectat de o multitudine de factori precum: întârzieri în comunicare, întârzieri în accesul datelor, deficiențe în optimizarea aplicației la resursele grid, fiabilitatea rețelei.

9. Fiabilitate: Fiabilitatea este mereu o problemă în calcul și nici calculul grid nu este o excepție. Cea mai bună metodă de a trata această problemă este de a anticipa toate eșecurile posibile și de a furniza un mijloc de a le rezolva.

– Checkpoint-restart. Când un job este executat, imagini de tip checkpoint sunt înregistrate la intervale regulate de timp. Dacă sistemul cedează în timpul execuției unui job, acel job este reluat de la cel mai recent checkpoint.

– Persistant storage. Starea relevantă a fiecarui job este memorată persistent de un grid manager.

– Heartbeat monitoring. Un mesaj de probă este trimis unui proces și procesul răspunde. Dacă procesul nu răspunde, un proces alternativ poate fi probat. Acesta poate determina statusul primului proces și îl poate chiar restarta.

10. Managementul sistemului: Orice design necesită un set de unelte de bază pentru management pentru a determina disponibilitatea și performanța în grid.

11. Topologie:

– Topologia rețelei poate lua diferite forme. Responsabilitatea rețelei este să furnizeze o lățime de bandă adecvată pentru oricare dintre sistemele grid.

– Topologia datelor. De preferat este ca job-urile ce trebuie executate să fie alocate mașinilor cele mai apropiate din punct de vedere fizic de datele de care este nevoie pentru execuție. În așa fel, traficul în rețea ar fi redus precum și limitele scalabilității.

12. Medii cu platforme diverse: Un sistem grid constă într-o colecție de host-uri heterogene cu sisteme de operare și software-uri variate. Pentru a rula o aplicație, infrastructura grid are nevoie să găsească host-ul din grid corespunzător aplicației. Pentru a face ca o aplicație să fie executată, infrastructura grid trebuie să considere anumiți factori despre:

– Timpul execuției. Cerințele despre timpul de execuție al unei aplicații trebuie să corespundă mediilor de execuție ale host-urilor unui grid.

– Portabilitate. Executabilele anumitor aplicații sunt specifice platformei. De exemplu, o aplicație scrisă în C sau C++ trebuie recompilată pe o platformă înainte să fie executată pe platforma respective.

– Sistemul de operare. Un grid este o colecție de resurse de calcul heterogene. Dacă aplicația are anumite dependențe sau cerințe specifice sistemului de operare, aplicația trebuie să verifice dacă mediul corect este disponibil și să rezolve problemele diferitelor medii.

13. Formatele fișierelor: Atunci când rezultatul unei aplicații ce rulează pe un grid este versat de o aplicație executată pe un grid diferit, este nevoie de cunoștiințe despre formatul fișierelor din sistem. Cele două host-uri grid pot avea platforme diferite. XML poate fi formatul folosit în schimbul datelor.

14. Licență software: Există multe produse și soluții de management al licențelor software:

– Licențe software comerciale. Un număr insuficient de licențe pot afecta grav expansiunea sau pot chiar exclude anumite programe sau aplicații din a fi folosite în sistemul grid.

Gama de modele pentru software-urile comerciale se extinde de la restrictiv la permisiv. Între aceste două extreme există numeroase modele. Licențele software sunt plătite o singură dată sau pe baza unei taxe lunare. Pot include update-uri sau pot solicita cumpărarea de noi licențe. Toate aceste aspecte variază în funcție de vendor, de situația clientului, depinzând de acorduri individuale sau de alte criterii. Licențele pot permite migrarea software-ului de la un server la altul sau pot fi legate de un singur calculator. Câteva dintre modelele de licențe sunt enumerate mai jos:

– Licența provider-ului de servicii: Subscriber Access Licenses (SALs);

– Open source licensing;

– FreeBSD, MIT, Apache (licențe permisive);

– LGPL (licența persistentă): Lesser General Public License

– Licențele publice GNU General Public License și IBM Public License (licențe persistente și virale).

4.4 Dezvoltarea unui design de nivel înalt [4]

Odată cu stabilirea cerințelor, design-ul la nivel înalt poate fi finalizat. Prima parte a design-ului este definirea interfeței serviciilor grid-ului.

4.4.1 Definirea interfețelor

Interfața serviciului grid privește toate aspectele publice furnizate precum metode (împreună cu parametrii și rezultatele lor), datele serviciului și strategia de notificare. Definirea unui serviciu grid este similară cu definirea unui serviciu Web, dar dezvoltatorii de servicii grid au ceva mai multe caracteristici de considerat.

4.4.2 Definirea tipurilor parametrilor și a rezultatelor unei metode

Fiecare serviciu grid cuprinde una sau mai multe metode. În codul serviciului pentru client, prin intermediul unui număr mic de clase ajutătoare Globus, un obiect proxy local este creat. Acesta reprezintă serviciul grid rulând altundeva în rețea. Metodele definite ca publice sunt disponibile în acest obiect proxy local.

În plus față de lista de nume a metodelor, un designer trebuie să definească în întregime metoda, incluzând orice parametru de intrare și valori returnate.

Programatorii pot defini interfața unui serviciu grid în două feluri:

– Printr-o abordare top-down (de sus în jos): definiția descrierii unui serviciu grid este scrisă într-un limbaj XML, numit GWSDL, care este o extensie a limbajului WSDL pentru servicii Web; sau,

– De jos în sus (bottom-up), prin crearea unei clase de interfață de tip Java, ce definește metoda în Java.

Avantajele și dezavantajele fiecărei dintre cele două abordări vor fi discutate mai târziu.

4.4.3 Definirea datelor unui serviciu și a strategiei de notificare

Serviciile grid sunt scrise ca extensii ale standardelor serviciilor Web. Două dintre extensiile majore pe care serviciile grid le oferă serviciilor Web sunt datele serviciului și strategia de notificare.

Datele serviciului

SDE (Service Data Elements) este o colecție de obiecte ce pot fi direct accesate de clienți. Acest tip de acces al datelor diferă de cel bazat pe metode deoarece obiectul în sine este public și orice client îl poate accesa simplu, după nume. Interfața serviciului poate plasa restricții la datele serviciului, precum definirea de atribute precum minimul sau maximul de instanțe ale SDE, scrierea în obiecte (în plus față de accesul clienților la citire) și existența obligatorie sau nulitatea unui obiect.

Notificarea

Datele serviciului și notificarea sunt strâns legate. Primele poti fi folosite pentru a implementa procesarea asincronă, dar cum va știi un client dacă operația este completă și dacă datele în așteptare sunt SDE? Răspunsul este notificarea. Notificarea acționează ca un model de subscriere: când clientul dorește notificare asupra unui SDE, folosește metode de ajutor GT3 pentru a subscrie, dat fiind numele simbolic al SDE. Când serviciul grid plasează un rezultat într-un SDE, folosește metode GT3 pentru a trimite notificări către toți clienții subscriși. Notificarea poate fi de două feluri:

– Push: SDE-ul este trimis către client odată cu notificarea;

– Pull: un SDE provizoriu este trimis către client odată cu notificarea, iar clientul trebuie să trimită o cerere înapoi către SDE pentru a primi valoarea actualizată.

Designerii aleg stilul de notificare în funcție de nevoile aplicației.

Pentru a rezuma, datele serviciului și notificarea, din punctul de vedere al designer-ului:

– Determină ce date se vor a fi expuse într-o manieră ce nu solicită apelarea unei metode. Metoda datelor unui serviciu este în general folosită pentru a expune starea unui serviciu, calcule intermediare etc. Acestea pot fi expuse și prin apelarea unei metode, dar în anumite aplicații SDE este mai potrivit.

– Determină dacă vor fi furnizate notificări despre unul sau mai multe SDE-uri, și ce stil de notificare va fi folosit. Notificarea este în general folosită pentru a furniza notificare asincronă a schimbării de stare a SDE. Nu există nici un alt fel de a furniza acest tip de funcționalitate.

4.4.4 Definirea life cycle-ului (ciclului de viață)

Ciclul de viață al unui serviciu grid începe cu instanțierea, continuă cu execuția și se oprește odată cu terminarea acestuia.

Instanțierea unui serviciu grid. Există mai multe feluri de a instanția un serviciu grid:

– Unelte pentru linii de comandă furnizate de GT3: comande ajutătoare precum ogsi-create-service pot fi folosite pentru a iniția un serviciu grid. Aceasta este un mijloc de inițializare potrivit în timpul dezvoltării și al testării dar în producție este recomandat ca inițializarea să se producă în mod automat.

– Începerea automată de către unu container de servicii grid. Un serviciu grid poate fi marcat pentru inițiere automată atunci când container-ul de servicii grid este pornit.

– Crearea programatică folosind clasele ajutătoare GT3. Cea mai comună metodă este folosirea claselor GT3 pentru a crea instanțe.

Execuția. În timpul execuției, o instanță a unui serviciu răspunde la apelarea de metode, actualizează SDE-urile și trimite notificări când este nevoie.

Terminarea unui serviciu grid. La fel ca în cazul pornirii unui serviciu, pentru oprirea acestuia există mai multe metode:

– Unelte pentru linii de comandă furnizate de GT3: comande ajutătoare precum ogsi-destroy-service pot fi folosite pentru a termina un serviciu grid. Aceasta este un mijloc de finalizare potrivit în timpul dezvoltării și al testării dar în producție este recomandat ca terminarea să se producă în mod automat.

– Terminarea automată, de către un container de servicii grid. O instanță grid are o durată de viață ce tinde la infinit, dar îi poate fi atribuită o durată mai scurtă în timpul creării. Când acea perioadă de timp expiră, container-ul serviciului grid automat oprește instanța. Oricărui client ce va încerca sa acceseze serviciul după ce acestă a fost terminat, îi vor fi returnate excepții.

– Distrugerea programatică folosind clasele GT3 este cea mai comună metodă de a distruge instanțele care nu mai sunt folositoare.

4.4.5 Definirea securității

Securitatea este un subiect foarte răspândit, dar la acest punct în design nu este nevoie decât sa fie identificate acele componente ce prezintă o sensibilitate la siguranță. Această sensibilitate poate fi exprimată prin nevoia de criptare a datelor, de autentificare a utilizatorilor sau de verificare a autorizațiilor, etc.

4.4.6 Rularea de scenarii pentru a asigura îndeplinirea cerințelor

Arhitectura trebuie verificată din punctul de vedere al cerințelor funcționale și non-funcționale pentru a asigura lipsa problemelor.

4.5 Dezvoltarea unui design de nivel jos [4]

La acest punct, design-ul de nivel înalt este detaliat până în momentul în care poate fi dat mai departe dezvoltatorilor. Această fază poate dura puțin mai mult deoarece trebuie asigurat că toate detaliile design-ului sunt suficient definite.

4.5.1 Cursul unei aplicații în grid

Întâi este nevoi de a defini câțiva termeni ce vor fi folosiți în număr repetat în acest sub-capitol:

– Aplicație grid = o colecție de unități de lucru ce folosesc o infrastructură grid pentru a rezolva o anumită problemă sau a atinge un rezultat dorit. O aplicație grid poate să consiste într-un număr de job-uri care împreună îndeplinesc un anumit obiectiv.

– Job = este considerat o singură unitate de lucru dintr-o aplicație grid.

– Producător și consumator de date = job-uri ce produc date se numesc producători, iar cele ce primesc date ca input-uri se numesc consumatori de date.

O aplicație grid constă în executarea mai multor job-uri. Avantajul unei aplicații grid este acela de a folosi mai mute resurse în mod concurent. Pentru aceasta, un aspect ce nu trebuie neglijat este procesarea datelor: în paralel sau în serie.

Cursul unei aplicații vs. cursul unui job

Înțelegem cursul unei aplicații ca fiind cursul lucrului între job-urile ce compun aplicația grid. Cursul intern al lucrului în interiorul unui job se numește cursul unui job. Există trei tipuri de bază ale cursului unei aplicații:

– În paralel. Dacă o aplicație constă în mai multe job-uri ce pot fi toate executate în paralel, un grid poate fi foarte adecvat pentru executarea eficientă în anumite noduri, în special în cazul în care nu este solicitat (deloc sau în cantitate foarte limitată) schimb de date între sarcini.

Începând cu o sarcină ințială, un anumit număr de job-uri sunt lansate execuției în noduri pre-selectate și dinamic alocate ale grid-ului. Rezultatul fiecărui job este colectat de către un job final și salvat.

Figura 4.5.1 – Cursul paralel al unei aplicații

Pentru o anumită problemă sau aplicație, poate fi necesar spargerea acesteia în mai

multe unități independente. Pentru a profita de execuția în paralel în grid, este important ca respectiva aplicație sau problemă să fie analizată spre a vedea dacă poate fi ruptă în unități de lucru independente ce pot fi executate precum job-uri individuale.

Acest tip de curs poate fi folosit cu succes atunci când nici unul dintre job-uri nu necesită ca input rezultatul altui job.

– În serie. În cursul paralel, fiecare job, cu excepția celui inițial, trebuie să aștepte ca predecesorul său să-și termine execuția pentru a putea returna un rezultat ce servește ca intrare pentru următorul job. În alte cuvinte, fiecare job este consumatorul predecesorului sau – producatoru de date.

Figura 4.5.2 – Cursul serial al unei aplicații

În acest caz, avantajul executării într-un sistem grid nu este acela de a accesa sisteme multiple în paralel, ci abilitatea de a folosi oricare dintre resursele potrivite și disponibile.

Această proprietate de a rula job-urile pe oricare dintre resurse contribuie la creșterea disponibilității și fiabilității aplicației. În plus, face o aplicație să fie mult mai scalabilă prin faptul ca în orice moment pot fi folosite resurse mai mari și mai rapide.

În orice caz, de preferat este întotdeauna să se verifice dacă job-urile sunt dependente unul de celălalt, sau dacă, prin natura lor, pot fi împărțite sau nu în unități executabile în paralel.

Acest procedeu se numește paralelizare.

– În rețea. Aceasta este poate cea mai comună situație, dar și cea mai complexă.

Anumite job-uri într-o aplicație sunt executate în paralel, dar totuși există interdependențe între ele.

Figura 4.5.3- Cursul job-urilor în rețea

Decuplarea. Într-un grid, decuplarea job-urilor solicită serviciului de management al cursului job-urilor să asigure sincronizarea rezultatelor individuale. Pentru a decupla, trebuie întâi realizată o analiză într-u a decide cum este cel mai bine ca o aplicație să fie despărțită în așa fel încât paralelismul să fie maxim. Asta înseamnă a a adăuga mai multe dependențe serviciilor infrastructurii grid, dar odată ce infrastructură este aranjată, aplicația poate beneficia de flexibilitatea și utilizarea unui mediu de calcul virtual.

Job-uri și sub-job-uri. O altă abordare este a ușura management-ul job-urilor într-o aplicație grid prin a introduce un sistem ierarhic de sub-job-uri. Un job se poate folosi de serviciile mediului grid pentru a lansa unul sau mai multe sub-job-uri. Pentru un astfel de mediu, o aplicație ar fi partiționată și creată în așa fel încât joburile de nivel înalt ar include logică de a obține resurse și de a lansa sub-job-uri. Aceasta ar putea aduce beneficii pentru aplicațiile de mărime foarte mare.

Figura 4.5.4 – Job-uri și sub-job-uri

4.5.2 Criterii de clasificare a job-urilor

Un job, ca parte a unei aplicații grid, teoretic poate să fie: de tip batch (lot), aplicație standard, aplicație paralelă sau/și interactivă.

Batch: Poate fi un job tradițional de tip batch invocat printr-o comandă din Windows, Linux sau Unix.

Aplicație paralelă: Sunt aplicațiile care au deja un curs paralel de execuție. Dar pentru a le folosi la maxim, server-ul grid trebuie să identifice și să acceseze funcțiile/job-urile interne ale acestora. Altfel, aplicațiile paralele vor fi văzute ca un întreg și tratate precum cele standard.

Aplicație standard: Un mediu grid poate fi aplicabil și pentru o aplicație standard, de exemplu pentru foi de calcul sau sisteme de redare video. O aplicație standard necesită o procedură de instalare specială și nu poate fi executată în rețea precum un job de tip batch.

Aplicație interactive: Interacțiunea cu o aplicație grid este de cele mai multe ori facută prin intermediul unui portal grid sau a unei interfețe de server grid. Aceasta implică nici o interacțiune să aibă loc între utilizator și job, cu excepția celei de lansare a unui job.

4.5.3 Considerații despre limbajul de programare

Când o aplicație este dezvoltată apare întrebarea limbajului de programare. Mediul grid poate aduce lucruri în plus de luat în vedere în alegerea limbajului de programare.

Job-uri făcute pentru calculul de înaltă performanță sunt de obicei scrise în limbaje de programare precum C sau Fortran. Acele job-uri ale căror timp de execuție individual nu joacă cel mai important rol în aplicație, dar ale căror conținut și activități sunt mai importante, pot fi scrise în alte limbaje precum Java sau Perl.

În funcție de cerințele pentru job-urile individuale și resursele disponibile, într-o aplicație grid este posibil ca diferite părți să fie scrise în limbaje diferite. Câteva lucruri cheie de considerat în alegerea limbajului, însă sunt:

– Portabilitatea pe o varietate de platforme. Portabilitatea include și compatibilitatea binară, unde limbaje precum Java constituie un avantaj. Perl tinde să fie și el portabil, deoarece permite executarea aplicației independent de platformă. De asemenea, portabilitatea codului sursă trebuie considerată.

– Librăriile/modulele din timpul execuției. În funcție de limbaj și de cum porgramul este conectat, poate să apară cerința ca librăriile sau alte module să fie disponibile.

– Interfețele către infrastructura grid. Dacă un job trebuie să comunice cu infrastructura grid-ului atunci alegerea limbajului depinde de legăturile disponibile

4.5.4 Dependențele job-ului de mediul sistemului

Pentru orice job dintr-o aplicație grid, există o serie de factori de mediu ce îi pot afecta execuția. În design-ul unei aplicații acești factori trebuie considerați, iar aplicația trebuie construită pe cât mai independentă de acești factori pe cât posibil.

– Trebuie luate în considerare versiunea sistemului de operare, nivelul de serviciu și setările parametrilor sistemului de operare necesare pentru execuția unui job. Trebuie văzut dacă o aplicație grid va fi capabilă să-și ruleze job-urile pe orice nod cu sisteme de operare diferite sau dacă execuția va fi restricționată unui singur sistem de operare.

– Mărimea memoriei solicitată de un job poate limita nodurile posibile pe care acest job poate rula. Capacitatea memoriei disponibilă depinde nu numai de prezența ei fizică la un nod ci și de cat de multă memorie este sistemul de operare dispus să asigure la momentul execuției.

– DLL-uri ce urmează să fie conectate pentru execuție trebuie să fie disponibile pe resursa țintă sau pot fi transferate pe resursă înainte ca job –ul să fie executat.

– Setările compiler-ului influențează deoarece flag-urile și locațiile compiler-ului pot fi diferite. De exemplu, mici diferențe precum ordinea bits-ilor și numărul de bytes folosiți pentru numerele reale și întregi pot cauza căderi atunci când un job este executat pe un nod sau sistem de operare diferit.

– Mediul de execuție trebuie să fie gata să primească un job pentru execuție.

– Trebuie luate în vedere standardul și versiunea server-ului aplicației, precum și capacitatea acestuia și cerințele de accesare și serviciile folosite.

– Pentru anumite job-uri poate fi nevoie de diverse dispozitive hardware. De exemplu, cerințe de depozitare, dispozitive de măsurare și alte periferice trebuie considerate în construcția aplicației și în planificarea arhitecturii grid.

2.5.5 Plasarea de date de intrare/ieșire

Orice job într-o aplicație grid plasează date de intrare și de ieșire devenind astfel în același timp producător și consumator de date, după cum a fost definit mai devreme.

Există numeroase moduri în care se realizează această plasare de date, ce trebuie considerate în timpul arhitecturii și al design-ului aplicației:

– Interfața linie de comandă este un mod natural de a primi date pentru job-urile de tip batch și aplicații standard. În acest caz, datele de intrare nu vor fi de natură complexă, însă vor fi compuse din anumiți parametrii de control al cursului intern al job-ului. Transferul de date către job are loc imediat, la momentul lansării job-ului, iar cantitatea de date intrate este în mod normal mică. Pentru cantități mai mari, pot exista argumente ce specifică fișierul sau sursa datelor.

– Date stocate, de orice fel pot servi ca intrare precum și ca ieșire. Transferul datelor de intrare se poate face oricând înainte de execuție, iar cel al datelor de ieșire oricând după ce job-ul a terminat.

– Cozi de mesaje, precum cele furnizate de WebSphere MQSeries®, sunt potrivite pentru activități asincrone dintr-o aplicație grid, în special atunci când livrarea de date furnizate job-ului și generate de către acesta este de o deosebită importanță. Un job poate accesa datele dintr-o coadă în mai multe feluri, în mod normal folosind API-uri specifice pentru a plasa și extrage datele.

– Valoarea returnată de către sistem (System return value) este un caz ce corespunde interfeței linie de comandă și în mod normal mijlocul prin care un job de tip batch sau orice program invocat prin interfața linie de comandă va returna date, sau cel puțin status-ul job-ului terminat. Astfel îi este indicat server-ului grid status-ul fiecărui job. Datele rezultate pot fi plasate unui depozit de date sau cozi de mesaje spre a fi procesate sau prezentate.

– Alte API-uri. Comunicând cu serviciile Web, orice sistem extern trebuie să îndeplinească anumite condiții pentru plasarea și preluarea de date. În astfel de cazuri, pot fi folosite HTTP, HTML, XML, SOAP sau alte protocoale sau API-uri de nivel înalt.

Pentru o aplicație grid este posibil să nu existe numai un mod în care datele sunt plasate pentru un job. Combinații de mecanismele enumerate mai sus pot fi folosite. Soluția optimă depinde însă de mediul și de cerințele propuse în faza de arhitectură și design a aplicației.

CAPITOLUL 5

APLICAȚII GRID COMPUTING

5.1 BOINC ( Berkeley Open Infrastructure for Network Computing)

Arhitectura de tip grid BOINC ( Berkeley Open Infrastructure for Network Computing) este o formă de calcul distribuit în care voluntarii procesează și stochează datele unor proiecte de cercetare științifică. Aceasta permite punerea capacității de calcul nefolosită a calculatoarelor la dispoziția unor experimente stiințifice care au nevoie de putere de calcul imensă și resurse ce nu pot fi obținute prin folosirea unui singur calculator.

Componentele funcționale ale clientului sunt:

• Aplicațiile

• Runtime sistem

• Biblioteci runtime

Componentele serverului sunt:

1. Baza de date MySql care conține: platforma, aplicațiile, versiunile, utilizatorii, gazdele, unitățile de lucru și rezultatele.

2. Planificatorul este un script cgi contactat de către client. Fiecare client are instanța sa. Instanța găsește un job adecvat și îl trimite clientului

3. Încărcătorul ia joburile gata de rulare și le plasează într-o coadă de așteptare, coadă utilizată de planificator. Prezintă eficiență prin realizarea unei conexiuni unice cu baza de date.

4. Tranziționerul realizează gestiunea stărilor unităților de lucru și creează noi unități. Acesta marchează stările pentru : validarea rezultatelor, asimilare și ștergere .

5. Componenta de validare este o componentă furnizată de proiect care procesează rezultatele obținute de unitățile de lucru: copierea rezultate în baza de date, extragerea datelor din rezultate și face un calcul bazat pe acestea, poate genera joburi noi pe baza datei din rezultat .

6. Asimilatorul este furnizat de proiect. El procesează rezultatele, poate genera noi joburi pe baza rezultatelor obținute și marchează rezultatele.

7. Componenta ștergere fișiere. Odată jobul efectuat se șterg unitățile de lucru și fișierele de intrare și rezultat. Fișierele se pot menține dacă se marchează ca atare.

8. Componenta curățare baza de date șterge sau face un back-up într-un fișier XML datelor vechi sau de care nu există nevoie. Șterge de asemenea rezultatele și tabelele de unități de lucru.

Dupa descarcărea și instalarea componentei BOINC Manager va apărea varianta de vizualizare simpla ca în figura 5.1.

Figura 5.1.1 Vizualizare simplă a BOINC Manager

De la opțiunea Unelte se setează preferințele în funcție de care vor fi folosite memoria, resursele, puterea de calcul a calculatorului pe care este instalat BOINC.

Figura 5.1.2 BOINC Preferințe

Pentru conectarea la un nou proiect, din secțiunea Unelte se selectează Adaugă proiect, se selectează proiectul din lista de proiecte, apoi apăsând butonul Următorul calculatorul se conectează la gridul din care face parte proiectul. După conectare este necesară înrgistrarea sau logarea într-un cont pentru proiectul respectiv, iar după logare browser-ul va ncărca o pagină unde se pot seta numele contului și preferințele.

Figura 5.1.3 Selectarea proiectelor Figura 5.1.4 Logarea în contul proiectului

Din fereastra Vizualizare avansată pot fi afișate lista cu proiectele la care este conectat computerul, sacinile de lucru care rulează pe server în momentul respectiv,statisticile și utilizarea discului, dar si anunțuri care conțin noutăți cu privire la starea și modificările aduse proiectelor rulate.

Figura 5.1.5 Afișarea proiectelor

Prin selectarea unui proiect din listă pot fi efectuate diferite operații asupra acestuia precum: actualizare, ștergere, vizualizarea proprietăților proiectului. Totodată sunt afișate contul, resursele partajate și starea în care se afla proiectul: în curs de rulare sau suspendat de utilizator.

Figura 5.1.6 Afișarea sarcinilor preluate de client

În acestă fereastră sunt afișate sarcinile cu proprietațile care ne interesează: progresul, starea (rulează, suspendat, finalizat), timpul scurs de când rulează sarcina, timpul limită pana când clientul poate finaliza sarcina, aplicația din care face parte sarcina de lucru și numele unic al sarcinii.

Figura 5.1.7 Utilizarea discului

În această secțiune este vizualizat spațiul ocupat pe disc de fiecare proiect BOINC în parte, spațiul ramas liber, disponibil pentru proiecte BOINC, dar și indisponibil pentru astfel de proiecte, precum si spațiul pe care rulează alte programe deschise.

Jurnalul de evenimente poate fi deschis din fereastra Avansat, print-un click pe Log Evenimente sau prin combinația de taste CTRL+SHIFT+E. Aici apar toate modificările apărute în starea tuturor proiectelor, a sarcinilor de lucru ale acestora, mesajele cu privire la noutățile despre proiecte.

Figura 5.1.8 Jurnalul de Evenimente

Exemple de proiecte BOINC:

1.SETI (Search for Extraterrestrial Intelligence) este un proiect din domeniul științific al cărui scop este acela de a detecta viață in afara Pamântului. O încercare a acestuia, cunoscută ca radio SETI, folosește telescoape radio pentru a asculta semnale radio de bandă scazută din spațiu. Asemenea semnale nu sunt cunoscute ca fiind frecvente, astfel încat o detecție a acestora ar fi însemna dovada exitenței unei tehnologii extraterestre.

Semnalele telescoapelor radio sunt formate în mod special din zgomot (din surse naturale și din componentele eletronice ale emițătoarelor) și semnale produse de om precum stații TV, radare și sateliți. Proiectele moderne de radio SETI analizează datele digital. O putere de calcul mai mare permite căutărilor să acopere un rang de frecvență mai mare cu multă sensibilitate. De aceea, radio SETI are nevoie de cât mai multă putere de calcul.

În 1995, David Gedye a propus realizarea radio SETI folosind un supercalculator virtual format dintr-un număr mare de calculatoare conectate la Internet, și el a organizat proiectul SETI@home să dezvolte această idee.

Infrastructura Grid a proiectului SETI@home înregistrează o creștere din ce în ce mai mare a gazdelor conectate la grid, după cum poate fi observat în figura 5.1.9.

Figura 5.1.9 Numarul de gazde care participă la proiect din 2004 până în prezent

Folosind aplicația BOINC Manager pentru a fi conectat la proiect cu scopul ca acesta să folosească resursele calculatorului pot fi vizualizate din ferastra Sarcini, accesând butonul Afișează grafice, graficele corespunzătoare sarcinilor trimise de serverul principal și rulate de către client.

Figura 5.1.10 Grafic obținut prin rularea sarcinii de lucru 26mr08ai.4559.1708.438086664199.12.198_0 timp de 1h si 37 min cu un progres de 45%

2. The Quake-Catcher Network este o inițiativă colaborativă pentru dezvoltarea celei mai mari rețele seismice cu cel mai scazut cost din lume, utilizând sezori in interiorul sau atașați mai multor computere conectate prin Internet. The Quake-Catcher Network poate asigura o înțelegere mai bună a cutremurelor, să ofere avertismente școlilor, sistemelor de urgență, spitalelor. The Quake-Catcher Network asigură, de asemenea, un software educațional care are scopul de a oferi informații despre cutremure.

Figura 5.1.11 Grafic. obținut prin rularea sarcinii de lucru qcn_066161_0

BOINC este un sistem client-server tip middleware în care:

• Clientul : sistemul migrează între aplicațiile rulate și componentele de control

• Serverul : are mai multe componente specializate pentru o fază a prelucrării datelor.

5.2 The Frontier Grid Platform

Fie ca este folosit pentru rularea aplicatiilor care conțin baze de date imense, care au nevoie de putere de calcul mare sau de comandă și control distributiv, Parabon's Frontier® Grid Platform ajută la rezolvarea problemelor computaționale rapid și ieftin.

The Frontier Grid Platform este un software care îmbină capacitatea computațională a resurselor IT existente și o livrează ca pe o utilitate flexibilă și scalabilă. Frontier poate fi dezvoltat intern, adunând excesul de putere computațională a componentelor unei organizații; poate fi de asemenea dezvoltat într-un centru de date virtual, iar în plus, clienții pot accesa Parabon Computation Grid, serviciul HPC online al companiei.

Indiferent de locul în care este dezvoltat, Frontier profită la maxim de resursele disponibile ale oricărui calculator. Poate fi configurat să ruleze atât pe computere dedicate, cât și nededicate. Infrastructura grid Frontier este compusa din mai multe componente software și oferă un software ca și strat de serviciu, accesibil din orice browser prin Frontier Dashboard.

Frontier Dashboard este un browser- interfață cu componente complexe care ofera controlul asupra contului de servicii Frontier Grid. Fie că se folosește Frontier Enterprise cu rețeaua proprie sau Parabon Computation Grod online, Frontier Dashboard poate lansa job-uri, instanția servicii, să țină evidența utilizării resurselor sau să întoarcă rezultate.

După logarea în contul Frontier și accesarea ferestrei Dashboard pot fi observate mai multe secțiuni precum: spațiul de lucru, aplicațiile, colaborările, motoarele din grid, setările user-ului.

Figura 5.2.1 Secțiuni Dashboard

Aplicațiile rulate în Frontier pot fi împărțite în orice număr dorit de task-uri. Task-urile sunt trimise la serverul Frontier, care apoi le distribuie gazdelor din grid. Când gazda termină calculele, rezultatele sunt trimise înapoi la server care le redirecționează către aplicație.

Exemplu: Parabon Traveling Salesman

În timp ce o aplicație rulează putem accesa fereastra în care sunt afișate detaliile job-lui:

-id-ul job-ului

– numărul de iterații

– timpul de execuție al task-ului

– numărul de taskuri înmânate de sever

– numărul de task-uri efectuate

– data când a fost creat task-ul

-rezultatul obținut.

Figura 5.2.2 Detaliile unui job

Figura 5.2.3 Rezultatul obținut în urma rulării a 10 task-uri în aplicația Traveling Salesmans

Concluzii

Dacă Web-ul este serviciul prin care se realizează schimbul de informații, Grid Computing este serviciul prin care se cumulează puterea de calcul și stocarea datelor prin Internet. Gridul nu este doar o simplă cale de comunicare între computere, scopul său este de a transforma rețeaua globală într-o singură vasta resursă de calcul în care să fie cuprinse toate cele 650 de milioane de calculatoare existente la ora actuală în lume. Să ne imaginam cateva milioane de computere situate peste tot în lume. Ele sunt desktop-uri, servere, etc. aparțin unor oameni diferiți și unor instituții diverse și sunt conectate toate la Internet. Până aici nimic nou. O tehnologie magică permite tuturor acestor echipamente să se comporte ca un singur, gigantic, puternic computer. Este vorba de Grid Computing, creată prin cercetare și aparută prima oară în America, la mijlocul anilor 90. Astăzi, numeroase centre de cercetare, precum Argonne National Laboratory în Statele Unite sau CERN (European Centre for Nuclear Research) în Europa, lucrează la dezvoltarea acestei tehnologii.

Știința este imposibil de conceput fără ajutorul computerului în zilele noastre. Oamenii de știință se confruntă cu probleme din ce în ce mai complicate, probleme care necesită mult mai mult decât o tabla de scris. De foarte multe ori un calculator sau chiar un superserver nu sunt de ajuns pentru multitudinea de calcule pe care oamenii de știință le doresc. Desigur, puterea și performanțele PC-urilor cresc într-un ritm alert, ajungându-se până acolo încât puterea procesoarelor se dublează o data la aproximativ 18 luni. Totuși toate acestea nu sunt îndeajuns, nevoile de calcul cer și consumă din ce în ce mai multe resurse, iar comunitatea științifică cât si cea economică au nevoie de cât mai multa putere de calcul, din aceasta nevoie nascându-se conceptul de Grid Computing. Acesta va asigura conexiunea între mii de calculatoare, dispozitive de stocare și unități de rețea, ce acționează ca un tot unitar, ca un singur sistem gigantic ce dispune de resurse inepuizabile.

Într-un fel, conceptul de Grid Computing se aseamană cu cel al Internetului. Spre deosebire de acesta, care formează o rețea mondială de date și informații, Grid-ul intenționează să formeze o putere de procesare fantastică, disponibilă de oriunde de pe glob, astfel încât puterea de procesare să devină o utilitate de tipul electricității.

Impulsionată atât de dezvoltarea rețelelor de mare viteză cât și de creșterea puterii de calcul a microprocesoarelor, procesarea grid are un impact remarcabil nu numai la nivel academic, ci din ce în ce mai mult și la nivelul întreprinderilor din toate domeniile de activitate.

Cu tot avansul tehnologic însă, mai puțin de 5% din puterea de procesare a serverelor Windows și calculatoarelor desktop, respectiv 15-20% pentru server-ele UNIX este utilizată. Întreprinderile realizează că procesarea grid oferă rate ale profitului extraordinare, cu o perioadă de înapoiere mica și cu un cost total scăzut față de alte soluții tehnologice.

Grid‐ul reprezintă o aplicație reală, implicând un set larg de resurse eterogene, cu scopul de a realiza calcul de înaltă performantă sau de a oferi acces transparent la un volum mare de cunoștințe indiferent de localizarea lor în cadrul rețelelor/Internetului. Tehnologiile și aplicațiile pentru Grid implică rezolvarea unor probleme de scalabilitate, flexibilitate, performanță și securitate.

BIBLIOGRAFIE

[1] Alexandru Stanciu, O analiză a tehnologiei Grid Computing, Institutul Național de Cercetare- Dezvoltare în Informatică, ICI – București

[2]Dan Căpriță, Revista Informatica Economică, nr.4 (40)/2006

[3]Jacob, B. Introduction to Grid Computing Editura Vervante, 2005

[4] http://cs.ucv.ro/staff/dmancas/ApSG.pdf

[5] Lenuța Alboaie, Rețele de calculatoare

[6] Revista Market Watch, nr 72, Grid Computing- Ultima Frontieră

[7] Velicanu, M. si altii Sisteme de baze de date evaluate Editura ASE, 2009

BIBLIOGRAFIE

[1] Alexandru Stanciu, O analiză a tehnologiei Grid Computing, Institutul Național de Cercetare- Dezvoltare în Informatică, ICI – București

[2]Dan Căpriță, Revista Informatica Economică, nr.4 (40)/2006

[3]Jacob, B. Introduction to Grid Computing Editura Vervante, 2005

[4] http://cs.ucv.ro/staff/dmancas/ApSG.pdf

[5] Lenuța Alboaie, Rețele de calculatoare

[6] Revista Market Watch, nr 72, Grid Computing- Ultima Frontieră

[7] Velicanu, M. si altii Sisteme de baze de date evaluate Editura ASE, 2009