TEZĂ DE DOCTORAT - mobcomm.pub.ro · Teza de doctorat își propune să analizeze metode de...

FONDUL SOCIAL EUROPEAN Investeşte în oameni!

Programul Operaţional Sectorial pentru Dezvoltarea Resurselor Umane 2007 – 2013 Proiect POSDRU/107/1.5/S/76909 – Valorificarea capitalului uman din cercetare prin burse doctorale (ValueDoc)

UNIVERSITATEA POLITEHNICA DIN BUCUREŞTI

Facultatea de Electronică Telecomunicații și Tehnologia Informației Departamentul Telecomunicații

Nr. Decizie Senat 226 din 28.11.2013

TEZĂ DE DOCTORAT REZUMAT

Contribuții la teoria și implementarea aplicațiilor de comunicații pe

platformă Cloud Computing

Contributions to the theory and implementation of communication applications on cloud computing platforms

Autor: Ing. George SUCIU Conducător de doctorat: Prof.dr.ing. Simona HALUNGA

COMISIA DE DOCTORAT

Preşedinte Prof.dr.ing. Gheorghe Brezeanu de la Universitatea Politehnica București

Conducător de doctorat Prof.dr.ing. Simona Halunga de la Universitatea Politehnica București

Referent Prof.dr.ing. Ioan Nicolaescu de la Academia Tehnică Militară

Referent Prof.dr.ing. Gheorge Gavriloaia de la Universitatea din Pitești

Referent Prof.dr.ing. Ion Marghescu de la Universitatea Politehnica București

Bucureşti

Contribuții la teoria și implementarea aplicațiilor de comunicații pe platformă Cloud Computing

2

CUPRINS

GLOSAR TERMENI ......................................................................................................................... 3 Capitolul 1. INTRODUCERE ...................................................................................................... 5

1.1 Obiectivele și structura tezei .............................................................................................. 5 1.2 Motivația alegerii temei – Provocări și posibile soluții ...................................................... 6 1.3 ACKNOWLEDGEMENT ................................................................................................. 6

Capitolul 2. TEHNOLOGII ȘI SISTEME CLOUD COMPUTING ............................................ 7 2.1 Necesitatea existenţei unor soluții de tip cloud computing ................................................ 7 2.2 Tehnologii .......................................................................................................................... 7

2.2.1 Virtualizare ................................................................................................................... 7 2.2.2 SOA și Web 2.0 Services ............................................................................................. 9 2.2.3 IPv6 ............................................................................................................................ 10 2.2.4 Sisteme distribuite și decentralizate ........................................................................... 11 2.2.5 Sisteme P2P ................................................................................................................ 11

Capitolul 3. ARHITECTURI ȘI ALGORITMI CLOUD COMPUTING .................................. 13 3.1 Modele de implementare .................................................................................................. 13

3.1.1 Sistemele cloud publice .............................................................................................. 13 3.1.2 Sistemele cloud private .............................................................................................. 13 3.1.3 Sistemele cloud de tip comunitate .............................................................................. 14 3.1.4 Sisteme cloud hibride ................................................................................................. 14

3.2 Managementul resurselor ................................................................................................. 15 3.3 Algoritmi pentru managementul resurselor ...................................................................... 15

3.3.1 Algoritmi de tip control .............................................................................................. 16 3.3.2 Algoritmi bazați pe funcții de utilitate ....................................................................... 18 3.3.3 Algoritmi de tip învățare automată (”machine learning”).......................................... 19 3.3.4 Algoritmi de tip licitație ............................................................................................. 19 3.3.5 Algoritmi genetici ...................................................................................................... 20

Capitolul 4. SERVICII CLOUD COMPUTING ....................................................................... 21 4.1 Atribute ale serviciilor cloud ............................................................................................ 21 4.2 Niveluri de livrare servicii în sistemele de calcul bazate pe cloud................................... 22

Capitolul 5. ALEGEREA UNEI PLATFORME EXPERIMENTALE DE TIP CLOUD .......... 23 5.1 Simularea aplicațiilor în cloud ......................................................................................... 23

5.1.1 Analiza aplicațiilor de simulare pentru sisteme cloud ................................................ 23 5.1.2 Exemplu de simulare pentru aplicații cloud în domeniul rețelelor de tip Cognitive

Radio 23 5.2 Cerințele impuse platformei experimentale ..................................................................... 25 5.3 Descrierea comparativă a variantelor considerate ............................................................ 25

5.3.1 Sisteme de tip cloud public ........................................................................................ 25 5.3.2 Sisteme cloud private ................................................................................................. 26 5.3.3 Justificarea alegerii platformei SlapOS ...................................................................... 26

Capitolul 6. PLATFORMA CLOUD CU SURSĂ DESCHISĂ SLAPOS ................................ 28 6.1 Arhitectura SlapOS .......................................................................................................... 28 6.2 Nodul Master SlapOS ...................................................................................................... 28 6.3 Nodul Slave ...................................................................................................................... 29 6.4 Modulele nucleu SlapOS ................................................................................................. 30 6.5 Protocolul SLAP .............................................................................................................. 31 6.6 Partiții de calcul ............................................................................................................... 31

Capitolul 7. IMPLEMENTAREA UNUI NOD DE TIP CLOUD PENTRU APLICAȚII DE COMUNICAȚII 34

7.1 Caracteristicile hardware și software ale platformei cloud .............................................. 34 7.2 Metodologia de instalare și configurare a unui nod SlapOS ............................................ 34

Capitolul 8. CONCLUZII .......................................................................................................... 36 8.1 Concluzii generale ............................................................................................................ 36 8.2 Contribuţii originale ......................................................................................................... 38 8.1 Perspective de dezvoltare ulterioară ................................................................................. 40

BIBLIOGRAFIE .............................................................................................................................. 41 PUBLICAȚII PROPRII ................................................................................................................... 43


3

GLOSAR TERMENI

AJAX Asynchronous JavaScript and XML Metode asincrone pentru JavaScript și XML API Application Programming Interface Interfață de programare a aplicațiilor AWS Amazon Web Services Servicii web Amazon BYOD Bring Your Own Device Aducerea propriului dispozitiv CDN Content Distribution Network Rețea de distribuție conținut CRM Customer Relationship Management Sistem pentru gestionarea relației cu clienții CSS Cascading Style Sheets Etichete de tip stil cascadă folosite pentru

formatarea paginilor web DHCP Dynamic Host Configuration Protocol Protocol de configurare dinamică a

calculatoarelor de tip gazdă DHCPv6 Dynamic Host Configuration Protocol

version 6 Protocol de configurare dinamică a calculatoarelor de tip gazdă versiunea 6

DHT Distributed Hash Table Tabelul ordonat pe baza unei funcţii de dispersie

DiffServ Differentiated Services Servicii diferențiate DMTF Distributed Management Task Force Grupul operativ pentru management distribuit DNS Domain Name System Sistem nume domenii DoS Denial of Service Refuzul, blocarea serviciului DVFS Dynamic Voltage and Frequency

Scaling Ajustarea dinamică a frecvenței și tensiunii

EBS Elastic Block Storage Stocare de tip bloc elastic ERP Enterprise Resource Planning Sistem de planificare a resurselor unei

întreprinderi FP7 Framework Programme 7 for Research

and Technological Development Programul Cadru 7 pentru Cercetare și Dezvoltare Tehnologică

HPC High Performance Computing Sisteme de calcul cu performanțe ridicate din punct de vedere al capacității de procesare

HTC High Throughput Computing Sisteme de calcul cu rate efective de transmisie ridicate

IaaS Infrastructure as a Service Infrastructură ca serviciu IDS Intrusion Detection System Sistem de detectare a intruziunilor IoT Internet of Things Internetul obiectelor IoE Internet of Everything Internetul pentru orice IPv6 Internet Protocol version 6 Protocol Internet versiunea 6 ITU International Telecommunication Union Uniunea Internaţională a Telecomunicaţiilor JRE Java Runtime Environment Mediu de rulare Java JSON JavaScript Object Notation Notarea obiectelor de KVM Kernel-based Virtual Machine Mașină virtuală la nivel de nucleu tip kernel LAN Local Area Network Rețea locală M2M Machine to Machine Comunicații dispozitiv la dispozitiv MPI Message Passing Interface Interfață de transmitere a mesajelor NaaS Network as a Service Rețea ca serviciu NAS Network Attached Storage Rețele de memorare externe (dispozitive de

stocare concepute pentru a fi atașate nu la câte un calculator particular din rețea, ci direct la rețea, putând astfel fi puse la dispoziția tuturor calculatoarelor rețelei)

NAT Network Address Translation Translatarea adreselor de rețea NIST National Institute of Standards and

Technology Institutul Național pentru Standarde și Tehnologii

OSI Open Systems Interconnection Interconectare între sisteme deschise OMG Object Management Group Grupul pentru gestionarea obiectelor P2P Peer-to-peer Sisteme punct la punct în care nodurile au


4

atribuțiuni egale PaaS Platform as a Service Platformă ca serviciu PHP PHP: Hypertext Pre-processor Tehnologie de preprocesare hipertext (acronim

recursiv) PUE Power Usage Effectiveness Eficiența utilizării puterii QoS Quality of Service Calitatea serviciului RAID Redundant Array of Independent Disk Sistem de discuri independente redundante REST REpresentational State Transfer Model de descriere a arhitecturii software

pentru interconectarea componentelor pe baza rolurilor, constrângerilor și interpretării stărilor

RSS Rich Site Summary Sumar format de fluxuri site web SaaS Software as a Service Software ca serviciu SAN Storage Area Networks Rețele de arii de memorare / Rețea pentru

stocare date (o rețea dedicată interconectării eficiente a dispozitivelor de stocare a datelor)

SDK Software Development Kit Kit pentru dezvoltare de aplicații software SDN Software Defined Networking Rețele definite software SDN Software Defined Radio Echipament radio definit prin software SLA Service Level Agreement Acord nivel servicii SOA Service Oriented Architecture Arhitectură orientată către servicii STP Spanning Tree Protocol Protocol de tip arbore extins TLS Transport Layer Security Securitate la nivel de transport UDDI Universal Description, Discovery and

Integration Protocol universal pentru descrierea, descoperirea și integrarea a serviciilor web

URI Uniform Resource Identifier Identificator pentru resursă uniformă VLAN Virtual LAN Rețea locală VPN Virtual Private Network Rețea virtuală privată WAN Wide Area Network Rețea de arie largă WSDL Web Service Description Language Limbaj de descriere a serviciilor web WSPA Web Services Platform Architecture Arhitectură pentru platforme de servicii web WLAN Wireless Local Area Network Rețea locală fără fir XML eXtensible Markup Language Limbaj pentru marcare extensibilă


5

Capitolul 1. INTRODUCERE

Lucrarea de față își propune o abordare teoretică și aplicativă pentru cercetarea

platformelor cloud computing, cu scopul de a realiza implementarea aplicațiilor de comunicații pe o astfel de platformă.

Noțiunea de cloud computing are mai multe definiții, printre care cea mai cunoscută este aceea, de accesare a puterii de calcul și a spațiului de stocare ca un serviciu de către o comunitate de utilizatori [1]. În limba română, termenul ”cloud computing” poate fi tradus ca ”procesare computerizată în nor”, fiind însă utilizată varianta în limba engleză, deoarece într-o lume dominată în domeniul tehnologiei informației de limba engleză, adesea în mediile de specialitate din România se utilizează acest termen provenit din terminologia anglo-saxonă.

Sistemele de cloud computing sunt structurate în mod tradițional pe trei niveluri de livrare a serviciilor: infrastructură ca serviciu – IaaS (Infrastructure as a Service), platformă ca serviciu - PaaS (Platform as a Service) și software ca serviciu - SaaS (Software as a

Service). Pentru a înțelege provocările aplicațiilor de comunicații în cloud este necesară înțelegerea acestor diferite niveluri de livrare a serviciilor cloud computing. Cel mai cunoscut nivel de livrare este SaaS, unde un utilizator achiziționează accesul la un serviciu găzduit în cloud. PaaS se referă la accesul la platforme care permit clienților să dezvolte aplicații proprii în cloud, iar IaaS este un nivel mai jos de accesare, a sistemelor, dispozitivelor de stocare, rețea și a managementului sistemului de operare/virtualizare.

1.1 Obiectivele și structura tezei

Teza de doctorat își propune să analizeze metode de implementare a aplicațiilor de comunicații, folosind principii caracteristice conceptului de cloud computing. În contextul arhitecturilor cloud computing, și al obiectivelor sale declarate de a asigura accesul flexibil la resurse de calcul, obiectivul major al acestei lucrări este oferirea de mijloace avansate de implementare a aplicațiilor clasice de comunicații ca servicii, împreună cu asigurarea calității și securității accesului la aceste servicii. Pentru propunerea unei soluții realiste din punct de vedere al implementării comerciale, este necesară o întreagă arhitectură capabilă să se extindă între domenii multiple cloud și care să includă mecanisme de virtualizare în planul de management, de control precum și în cel de aplicații [2].

Obiectivul general poate fi compus din două obiective. Într-o primă fază, sunt analizate soluții existente de tip cloud și sunt discutate perspectivele de dezvoltare ale acestora pentru implementarea aplicațiilor de comunicații. Pentru atingerea acestui obiectiv este realizată întâi o analiză a stadiului actual al tehnologiilor și sistemelor cloud, precum și o examinare a proiectelor de cercetare și standardizare. Pe baza unui astfel de proiect european de cercetare, numit “Cloud Consulting” [3], în colectivul căruia autorul a adus contribuții la activitățile de cercetare și dezvoltare, au fost analizate principalele probleme întâmpinate în implementarea unui sistem cloud cu sursă deschisă și evaluate posibile soluții. În plus, în această teză sunt analizate relațiile dintre un sistem cloud și alte tehnologii, precum și definite caracteristicile generale și specifice ale unei rețele cloud, fiind propusă o arhitectură de tip cloud hibrid și dezvoltați algoritmi de îmbunătățire a performanțelor în planificarea și alocarea resurselor.

Într-o a doua etapă, se urmărește simularea și implementarea diferitelor aplicații de comunicații folosind o platformă cloud. Este demonstrată necesitatea modelării matematice a caracteristicilor principale ale unei platforme cloud și propusă întâi simularea unei aplicații de comunicații în cloud. În urma unei analize a aplicațiilor de simulare pentru sisteme cloud, este ales un cadru de simulare pentru sisteme distribuite și propusă implementarea unei aplicații de calcul paralel, evaluând performanțele acesteia, cu scopul de a determina cerințele impuse platformei experimentale. Este realizată o descriere comparativă a diferitelor sisteme cloud, și


6

pe baza îndeplinirii criteriilor stabilite anterior, este justificată alegerea platformei cloud cu sursă deschisă SlapOS. Astfel, este propusă implementarea unei arhitecturi de tip cloud decentralizat, care să permită implementarea protocoalelor IPv6 și P2P pentru aplicații de comunicații. De asemenea, sunt implementate, utilizând platforma SlapOS, aplicații de comunicații ca servicii cloud, cu ajutorul cărora vor fi validate arhitecturile și algoritmii propuși. Ca structură a tezei, acest prim capitol constituie o introducere în domeniul sistemelor cloud, prezentând obiectivele și structura lucrării, precum și motivația alegerii temei, dar și provocări și posibile soluții. În cadrul celui de-al doilea capitol este justificată actualitatea conceptului propus de comunicații în cloud și este prezentat un scurt sumar al proiectelor care au avut ca scop dezvoltarea unor soluții de tip cloud computing. Astfel, sunt prezentate tehnologii și sisteme pentru realizarea unei soluții hardware și software cloud computing, precum și rolul rețelelor de comunicații în cadrul unor astfel de soluții. Capitolul 3 tratează în detaliu subiectul arhitecturilor cloud computing și al mecanismelor de gestionare a resurselor, fiind analizate caracteristicile generale pe care algoritmii pentru managementul resurselor trebuie să le îndeplinească. De asemenea, a fost realizată o analiză comparativă a unor algoritmi existenți și propuse îmbunătățiri pentru a realiza o planificare și alocare optimă a resurselor. Diferitele tipuri de servicii cloud sunt prezentate pe larg în cadrul capitolului 4, fiind descrise mai multe exemple de aplicații de comunicații bazate pe sisteme de tip cloud computing. Este analizat modul în care serviciile oferite de către un sistem de calcul cloud pot fi grupate, în funcție de categoria de resurse oferite, în anumite niveluri. Capitolul 5 conține o trecere în revistă a diferitelor sisteme de simulare și platforme cloud computing. Scopul este de a determina cerințele unei platforme experimentale cloud și de a realiza întâi o simulare a aplicațiilor ce vor fi rulate în cloud, înainte de a trece la implementarea unui sistem. De asemenea, este realizat un studiu comparativ al diferitelor platforme cloud, și justificată alegerea platformei cu sursă deschisă SlapOS. În capitolul 6 este prezentată în detaliu platforma cloud SlapOS, analizând arhitectura sistemului, precum și structura componentelor, inclusiv aspectele legate de performanță și securitate. Capitolul 7 descrie implementarea unui nod cloud SlapOS, și realizarea unor scenarii conceptuale de validare a platformei cloud pentru aplicații de comunicații. În cadrul ultimului capitol sunt concluzionate aspectele esențiale, sintetizate contribuțiile și expuse direcțiile de cercetare viitoare.

1.2 Motivația alegerii temei – Provocări și posibile soluții

Arhitectura tradițională a unui sistem cloud, încercând o analogie cu nivelurile OSI, implică implementarea unui nivel fizic IaaS în centre de date mari prin intermediul unui model de implementare tip cloud public, cu presupusă operare optimală datorită eficienței economice și a automatizărilor.

În domeniul aplicațiilor de comunicații, cercetările recente s-au concentrat pe implementarea unor nivele de servicii SLA (Service Level Agreement) pentru operarea sistemelor cloud computing în marile centre de date [4]. Problema este însă că, în cazul unei forțe majore, precum dezastre naturale, greve, acte de terorism, accidente neprevăzute, etc., condițiile de tip SLA nu mai sunt aplicabile. Este propusă o posibilă soluție, de a utiliza un model de tip cloud computing decentralizat, prin agregarea resurselor dintr-o rețea de calculatoare standard situate în case, birouri, universități sau mici centre de date, spre deosebire de centralizarea resurselor în mari centre de date. Lucrarea evaluează posibilitatea unui astfel de scenariu și problemele legate de performanță, eficiență și securitate.

1.3 ACKNOWLEDGEMENT

Rezultatele prezentate în această teză de doctorat au fost obţinute cu sprijinul financiar al Ministerului Muncii, Familiei şi Protecţiei Sociale prin Fondul Social European, Programul Operaţional Sectorial Dezvoltarea Resurselor Umane 2007-2013, Contract nr. POSDRU/107/1.5/S/76909.


7

Capitolul 2. TEHNOLOGII ȘI SISTEME CLOUD COMPUTING

În cadrul acestui capitol sunt prezentate tehnologiile și sistemele care stau la baza unei

soluții de tip cloud computing, precum și rolul rețelelor de comunicații în cadrul unor astfel de soluții. Este justificată actualitatea conceptului propus de comunicații în cloud și prezentat un scurt sumar al proiectelor care au avut ca scop dezvoltarea unor soluții de tip cloud computing. De asemenea, sunt evaluate tehnologii precum grid computing, sisteme de virtualizare și aspectele de comunicații IPv6 pentru interconectare.

2.1 Necesitatea existenţei unor soluții de tip cloud computing

Dezvoltarea exponențială a sistemelor de comunicații fără fir în primul deceniu al acestui secol a condus la necesitatea reconsiderării unor anumite aspecte legate de administrarea resurselor limitate, pe care astfel de sisteme le au la dispoziție.

Termenul de cloud computing a încercat să fie definit din mai multe puncte de vedere, principalele două direcții fiind de definire ca o evoluție a conceptului de grid computing, virtualizare și calcul distribuit sau, din contră, ca o revoluție disruptivă în care paradigmele clasice ale sistemelor de operare, nivelele de rețea și aplicațiile web sunt unificate într-un nou model ”orice aplicație X ca serviciu” - XaaS (X as a Service) [1], [5]. Astfel, teza de față propune o soluție care combină avantajele tehnologiei de tip cloud computing și utilizarea IPv6, creând astfel o platforma pentru implementarea aplicaţiilor de comunicații de tip SaaS și CaaS (Communication as a Service) [6], [7].

Conceptul de cloud computing accentuează, de asemenea, faptul că domeniul calculatoarelor și cel al comunicațiilor sunt interconectate foarte strâns. Într-adevăr, atunci când unul dintre cele două domenii avansează, progresul poate să fie critic pentru celălalt. De exemplu, cloud computing a devenit o alternativă pentru soluțiile de tip grid computing sau high-performance computing în momentul în care Internetul a început să ofere capacități de transfer de bandă largă cu latență redusă, garanții de calitate și costuri mici. În același timp, rețelele actuale de comunicații nu ar putea funcționa fără sisteme de gestionare performante sau comutatoare controlate de către controlere software.

2.2 Tehnologii

În cadrul acestui sub-capitol vor fi discutate tehnologiile pe care se bazează sistemele cloud computing pentru a oferi nivelurile de abstractizare și serviciile către utilizatori și dezvoltatori. Totodată, se examinează complexitatea tehnologică, care este adesea ascunsă de către cloud computing, și constă în interconectarea nivelurilor de virtualizare, a interfețelor de tip SOA și Web 2.0 Services. Este analizat și rolul tehnologiilor grid computing, precum și a rețelelor de date în dezvoltarea unei platforme cloud computing.

2.2.1 Virtualizare

Virtualizarea resurselor reprezintă nucleul oricărei arhitecturi cloud computing, permițând utilizarea unei interfețe abstracte logic pentru accesarea resurselor fizice (servere, rețele, medii de stocare). Printre metodele de simulare a interfeței către obiectele fizice sunt: (a) Multiplexarea - crearea mai multor obiecte virtuale dintr-o singură instanță a unui obiect fizic, de exemplu un procesor este multiplexat pentru a prelucra mai multe procese înlănțuite (thread-uri), (b) Emularea - construirea unui obiect virtual dintr-un obiect fizic de alt tip, de exemplu un hard disk fizic poate emula memorie RAM (prin intermediul unui fișier sau partiții interschimbabile - de tip swap), (c) Agregarea - crearea unui singur obiect virtual din mai multe obiecte fizice, de exemplu un număr de hard disk-uri pot forma un disk agregat RAID,

(d) Multiplexare combinată cu emulare – de exemplu protocolul TCP emulează un canal de


8

comunicații sigur și multiplexează transferul de date între canalul de comunicații fizic și procesor.

Conceptul de virtualizare se aplică pentru a grupa resurse fizice sub formă omogenă și de a le gestiona ca un tot unitar, oferind aceste resurse în funcție de cereri. La baza acestei abordări a fost definit conceptul de mașină virtuală, înlocuind mașina reală fizică. Este definit conceptul de hypervisor (denumit și VMM – Virtual Machine Monitor), care gestionează resursele de calcul pentru mașinile virtuale, simplificând procedurile de alocare și monitorizare a resurselor fizice, de exemplu starea unei mașini virtuale poate fi salvată și mutată pe un alt server. Astfel, un hypervisor este o entitate hardware, software sau middleware care creează și rulează mașini virtuale. Un calculator fizic pe care rulează un hypervisor este denumit calculator gazdă (denumit în engleză host) iar fiecare calculator virtualizat care rulează pe calculatorul gazdă este denumit mașină virtuală vizitator (denumit în engleză guest). Pentru fiecare mașină virtuală este nevoie să fie oferit suport pentru virtualizarea componentelor hardware (procesor, memorie, stocare, dispozitive I/O, comunicații) și partajarea acestora între diferitele aplicații.

Clasificarea tehnologiilor de tip hypervisor se face în următoarele categorii, în funcție de nivelul la care rulează pe hardware, după cum este prezentat și în Fig. 2.1 (a) tip 1 - nativ (denumit și bare metal) unde modulul de tip hypervisor rulează direct pe sistemul hardware al calculatorului gazdă și gestionează resursele pentru mașinile virtuale, (b) tip 2 – găzduit (denumit și hosted) unde modulul de tip hypervisor rulează pe un sistem de operare convențional.

Hardware

Aplicații

Hypervisor

Sistem

operare

guest 1

Mașină

virtuală 1

Aplicații

Sistem

operare

guest N

Mașină

virtuală N

Sistem operare host

Hardware

Aplicații

Hypervisor 1

Sistem

operare

guest 1

Mașină

virtuală

1

Aplicații

Sistem

operare

guest N

Mașină

virtuală

N

Aplicații

Hypervisor K

Sistem

operare

guest 1

Mașină

virtuală

1

Aplicații

Sistem

operare

guest N

Mașină

virtuală

M

(a) (b)

Fig. 2.1. Comparație între tehnologiile de tip hypervisor: (a) nivel 1 – nativ și (b) nivel 2 – găzduit (hosted)

Pentru un modul de tip hypervisor de nivel 1 exemple tipice sunt Citrix XenServer [8] sau VMWare ESX [9], iar pentru un hypervisor de nivel 2 cele mai des utilizate sunt VMWare

Workstation și VirtualBox [10]. Există de asemenea și sisteme de tip hypervisor pentru care este mai dificil de aplicat această clasificare, de exemplu pentru KVM (Kernel-based Virtual

Machine) [11] care permite programului kernel Linux să funcționeze ca un modul de tip hypervisor de nivel 1. Totuși, Linux fiind un sistem de operare în sine și conform clasificării anterioare, orice modul de tip hypervisor, ce rulează peste acest sistem, este considerat de nivel 2. De asemenea Microsoft Hyper-V [12] a fost considerat un sistem de tip hypervisor de nivel 2, deși versiunea actuală din Windows Server 2008 și mai recent Windows Server 2012 sunt încărcate înaintea rulării sistemului de operare. Se impune astfel definirea unei a treia categorii de sisteme de virtualizare hibride, în care modulul de tip hypervisor partajează resursele cu un sistem de operare, ca în Fig. 2.2.

Sunt prezentate modalitățile de virtualizare și analizate modurile în care sistemele de tip hypervisor controlează utilizarea resurselor hardware de către sistemele de tip invitat, pentru a nu a afecta alte mașini virtuale: � Virtualizarea sistemelor de operare, � Virtualizarea platformelor, � Virtualizarea stocării, � Virtualizarea rețelei, � Virtualizarea aplicațiilor


9

Hardware

Aplicații

Hypervisor

Sistem

operare

guest 1

Mașină

virtuală 1

Aplicații

Sistem

operare

guest N

Mașină

virtuală N

Sistem operare host

Aplicații

Aplicații

Aplicații

Fig. 2.2. Exemplu de modul de tip hypervisor hibrid

De asemenea, sunt analizate funcțiile unui modul de tip hypervisor, de a partaja platforma fizică pentru mai multe aplicații sau servicii, și posibilitatea migrării unei mașini de la o platformă la cealaltă.

2.2.2 SOA și Web 2.0 Services

Alături de virtualizare, conceptele de arhitectură orientată pe servicii (SOA) și servicii Web 2.0 sunt tehnologii fundamentale pentru crearea unui sistem cloud. Acestea două din urmă, pot fi interconectate și coordonate împreună, SOA reprezentând arhitecturi ale căror componente sunt implementate ca servicii independente, care comunică prin mesaje, nefiind însă necesară neapărat tehnologia de servicii web.

În sistemele de calcul bazate pe cloud, tehnologiile prezentate anterior de infrastructuri, platforme sau aplicații virtualizate, sunt implementate ca și servicii (de obicei web), și oferite utilizatorilor sub forma unor sisteme cu arhitecturi orientate către servicii.

Majoritatea sistemelor cloud publice, oferă accesul la servicii prin intermediul unor interfețe și protocoale standardizate, fiind descrise în continuare serviciile de tip Web 2.0 și RESTful (REpresentational State Transfer – un model de descriere a arhitecturii software bazat pe HTTP) [13].

În Fig. 2.3 este prezentat un model simplificat de arhitectură orientată pe servicii pentru cloud computing. În practică s-a constatat, că încercările de a standardiza și cataloga serviciile, ca de exemplu UDDI (Universal Description, Discovery and Integration) nu au avut succes, fiind adesea utilizată comunicarea directă prin mesaje între diferitele entități, ceea ce permite și o compunere dinamică a serviciilor ad-hoc. Deoarece există multiple modalității de implementare SOA, precum Web Service Description Language (WSDL – un limbaj de descriere a interfețelor pentru servicii web), SOAP (SOA Protocol – un protocol de mesagerie), RESTful (REpresentational State Transfer – un model de descriere a arhitecturii software bazat pe HTTP), un rol important în alegerea unei anumite tehnologii, îl are nivelul de integrare și tipul de comunicații între utilizatorii și ofertanții de servicii.

Serviciile pot fi implementate, din punctul de vedere al comunicațiilor, ca și conexiuni punct la punct, sau într-un model de tip hub. În cazul unei comunicații punct la punct, este necesară stabilirea unei conexiuni individuale între client și operator, fiind obligatorie cunoașterea punctelor terminale (adresă IPv4/v6 sau URL și port) pentru a adresa direct serviciul. Spre deosebire, așa cum s-a prezentat în Fig. 2.3, în cazul abordării de tip hub, un broker acționează ca intermediar pentru găsirea unui anumit serviciu, iar clientul nu trebuie să știe adresa exactă a operatorilor de resurse.

Pentru localizarea serviciilor se utilizează nume simbolice, de exemplu Uniform

Resource Identifier (URI) iar în cazul SOA, brokerul este denumit Enterprise Service Bus

(ESB). Sarcinile acestui broker sunt de a administra catalogul cu servicii, precum și de a ruta și transforma mesajele dintr-un format în altul, de exemplu între platforme de 32 biți și 64 biți sau diferite standarde XML.


10

Internet

Publicare servicii

Utilizare servicii

Utilizare serviciiOperator

platformă

Ofertant

servicii

Utilizatori

Operator

infrastructură

Agregare servicii

Broker / Catalog

serviciiCăutare și

cerere servicii

Referință către

serviciu

Utilizare servicii

Publicare servicii

Utilizare servicii

Publicare servicii

Fig. 2.3. Model simplificat de arhitectură orientată pe servicii (SOA)

Astfel, este necesară adaptarea unei rețele cloud la dezavantajele pe care le implică conexiunile de tip WAN la Internet, precum latențe mari, viteze reduse și disponibilitate variabilă, fiind adoptate protocoale de comunicații asincrone și bazate pe mesaje de tipul Web

service. Un serviciu Web 2.0 este definit ca o aplicație software, identificată printr-un URI, și ale cărei interfețe și capabilități sunt descrise și căutabile prin intermediul XML, suportând interconectarea cu alte aplicații software prin XML sau protocoale web [14]. De asemenea, Web 2.0 a fost definit ca un sistem de procesare în care rețeaua este platforma de calcul [15], fiind un precursor al conceptului NaaS (Network as a Service).

2.2.3 IPv6

Adresarea unor resurse prin Internet reprezintă una din caracteristicile principale ale unei rețele de tip cloud, de aceea migrarea la IPv6 reprezintă unul din subiectele importante, după cum se va arăta în continuare. Spațiul de adresare pentru protocolul IPv4 este de 232 (4,3 miliarde de adrese) un număr care s-a dovedit a fi insuficient, în data de 11 ianuarie 2011 fiind anunțat oficial ca fiind epuizate [16]. Spre deosebire, IPv6 folosind 128 biți, are o capacitate de adresare de până la 2128 (3,4 x 1038 adrese).

Avantajele unui sistem de rutare virtual, bazat pe mașini virtuale ca în Fig. 2.4 sunt: posibilitatea de a izola între ele diferitele instanțe (fiind stocate în fișiere sau imagini ale sistemelor de operare), posibilitatea de a realiza operații uzuale cu ușurință (pornire, oprire, creare, ștergere, copiere, mutare), posibilitatea de a realiza operațiuni suplimentare (întoarcere la o salvare instantanee anteriore, salvare și restaurare din salvarea instantanee), și nu în ultimul rând, utilizarea simultană a unor stive de protocol diferite (IPv4 și IPv6).

Hardware

Stivă

protocol 1

Sistem

operare

guest 1

Stivă

protocol 2

Hypervisor

Sistem

operare

guest 2

Router 1 Router 2

Router 3 Router 4

VR 1-1 VR 2-1

VR 3-1 VR 4-1

VR 1-2 VR 2-2

VR 3-2 VR 4-2

(a) (b) (c)

Fig. 2.4. Migrarea la IPv6: (a) virtualizare rutere, (b) topologie reală și (c) migrarea la topologie virtuală


11

Topologiile virtuale pot fi diferite de cele reale, fiind posibilă crearea unui subset al acestora, sau combinarea de topologii multiple, precum și schimbarea dinamică a topologiei (modificări, porniri, opriri, schimbări ale caracteristicilor unor conexiuni). În acest fel, pe lângă spațiul de adresare de dimensiune mărită, se elimină problemele introduse de NAT.

2.2.4 Sisteme distribuite și decentralizate

Cercetarea de-a lungul mai multor decenii în domeniul calculului paralel și distribuit a constituit baza pentru dezvoltarea sistemelor de calcul bazate pe cloud, fiind rezolvate multe din problemele descoperite la nivelul algoritmilor de gestionare a resurselor, sau evitate probleme la nivel de implementare. Astfel, sistemele cloud reprezintă o evoluție a sistemelor de calcul distribuite, ce extind următoarele paradigme: (a) Sistemele de calcul de tip grid, (b) Utility computing (Sisteme de procesare computerizată ca utilități), (c) Internet Computing (Sisteme de calcul folosind Internet), (d) Sisteme de calcul autonome, (e) Edge computing (Sisteme de calcul de perimetru), (f) Green computing (Sisteme de calcul cu impact redus asupra mediului).

Un alt aspect important este problema comunicării și modificării aplicațiilor existente pentru a le converti la modelul de oferire ca servicii. După cum se va arăta în sub-capitolul următor, paradigmele P2P și a calculatoarelor participante în mod voluntar într-un sistem, au contribuit la dezvoltarea aplicațiilor pe sisteme de calcul distribuit și decentralizat. În cadrul acestora, resursele (inclusiv serviciile) pot fi partajate liber, dar prezintă aceleași probleme ca și în cazul sistemelor de calcul de tip grid legate de compatibilitatea și standardizarea unor interfețe la resurse. În plus, nu sunt implementate mecanisme de tip QoS sau contorizare, acestea nefiind considerate a fi necesare în cazul soluțiilor bazate pe resurse contribuite în mod voluntar. Analizând aplicabilitatea soluțiilor de calcul de tip grid, s-a constatat că două presupuneri legate de eterogenitatea sistemelor individuale interconectate, respectiv a domeniilor administrative diferite care trebuiau să coopereze, s-au dovedit a fi greșite în dezvoltarea acestora. În cazul eterogenității s-a constatat că folosirea unor structuri hardware și software diferite a pus în dificultate gestionarea funcțiilor critice, precum optimizarea resurselor, balansarea traficului, dar și dezvoltarea și transferul (portarea) aplicațiilor, fiind rezolvate de sistemele cloud prin virtualizarea și definirea unor interfețe standardizate web de oferire a serviciilor.

2.2.5 Sisteme P2P

Așa cum a fost prezentat în sub-capitolul anterior, sistemele distribuite permit accesul la resurse într-un mediu strict determinat, fiind aplicate reguli de control și securitate pentru accesul și alocarea resurselor. De asemenea, s-a pus accentul pe managementul resurselor fizice în locul celor virtuale, fiind specific modelului de sistem în care utilizatorul gestionează direct aplicațiile și datele aflate pe noduri distante în rețea. Acest model centrat pe utilizator a fost revoluționat în anii 1990 de către modelul P2P, fiind puse în discuție probleme de complexitate în gestionarea sistemelor actuale, a necesității unor noi idei de gestionare automată și auto-reparare, precum și de migrare la o abordare nedeterministă a acestor sisteme complexe. Modelul P2P poate fi privit ca un precursor al sistemelor cloud actuale, fiind o variantă de sistem distribuit care avea ca bază accesul cât mai flexibil și la costuri cât mai reduse la resurse de stocare și procesare oferite de participanții din sistem (aflați însă în domenii administrative diferite). Ca definiție, P2P (peer-to-peer) reprezintă un sistem cu o arhitectură de rețea distribuită și decentralizată, în care nodurile rețelei sunt denumite peer (de obicei punctul terminal al unui utilizator). Aceste noduri au sarcini și atribuțiuni egale, și funcționează totodată ca și consumator, dar și ca sursă de date, prin oferirea unei părți din capacitatea de procesare și stocare pentru utilizarea de către alte noduri, astfel degrevând rețeaua de anumite sarcini [17]. Pentru realizarea unei rețele cloud se propune transformarea structurii protocolului Chord [18] din inel, într-o structură de tip master-slave multi-inel. De


12

asemenea, se iau în considerare factori precum performanța și reputația unui nod în cloud pentru a gestiona mai eficient resursele eterogene, fiind detaliate în secțiunea următoare protocolul Chord, și mecanismul de adaptarea a acestui pentru utilizarea în rețelele cloud.

Totodată, au fost analizate mai multe probleme ale acestei abordări, în comparație cu modelul client-server, în care nodurile utilizatorilor accesează resurse oferite de servere centrale: � un timp mai lung de pornire sau de adaptare în cazul unor schimbări în rețea; � probleme de extindere a sistemului pentru servicii multimedia de tip streaming în timp real; �rate de transfer asimetrice în cazul rețelei de acces a utilizatorilor, în special în cazul capacității de upload, ce poate deveni un punct de congestie pentru sistem; � întârzierea capăt-la-capăt poate deveni foarte mare datorită numărului de noduri prin care este redirecționat conținutul; � comportamentul nodurilor este imprevizibil, fiind libere să se conecteze sau să părăsească sistemul în orice moment, chiar abandonând nodurile descendente lor, în special în cazul unor rețele de mari dimensiuni [19]; � implementarea unei rețele virtuale de control (de tip overlay), introduce un volum suplimentar de sarcini de procesare, precum stocarea locală a unor structuri de date - de exemplu tabelul ordonat pe baza unei funcţii de dispersie (DHT - distributed hash table) [20], care conține informații de tipul (cheie,valoare) referitoare la ce fișiere sunt stocate pe un anumit nod, sau schimbul de informații despre starea nodurilor cu algoritmi de eficientizare specifici (pentru a determina nodurile să nu se comporte egoist, fiind cunoscută problema freeloader care doar utilizează resurse și nu oferă); � datorită arhitecturii flexibile, și adesea nestructurate, sistemele P2P prezintă riscuri de securitate (atacuri de tip refuzarea serviciului - denial of service, falsificarea unor rute, coruperea datelor, etc.) și de desfășurare a unor activități ilegale, precum partajarea de conținut ce contravine drepturilor de proprietate intelectuală sau distribuire de viruși [21].

În Fig. 2.5 este propus un model de adaptare a protocolului Chord pentru o rețea cloud, fiind transformată structura originală de tip inel într-o topologie master-slave multi-inel, cu ajutorul mecanismelor de grupare a adreselor IPv6 pentru nodurile dintr-o rețea cloud.

Fig. 2.5. Model de adaptare Chord pentru sisteme cloud

Pentru calcularea reputației și a performanței unui nod se folosește în cazul P2P mecanismul Credence [22], fiind propus pe baza acestuia un algoritm decentralizat prin care fiecare nod folosește informația stocată local pentru a evalua alte noduri și a partaja evaluările de performanță și reputație cu nodurile vecine. Reputația este foarte importantă în cazul acestor sisteme, în care pot apare noduri instabile sau chiar malițioase, aceasta fiind calculată pentru fiecare nod pe baza potrivirii cu voturile proprii și a voturilor unor noduri dintr-un grup cu criterii de votare asemănătoare.

Astfel, în sistemele cloud se pot utiliza mecanismele anterioare, de adaptare a unor topologii și metrici P2P, împreună cu o funcție de rutare pe bază de cheie K(n0,k) pentru afla calea prin graful G de la nodul n0 către nodul care conține cheia k (o anumită resursă). Printre algoritmii eficienți în cazul rețelelor nestructurate și eterogene se numără cei de tip licitație, epidemici sau genetici, în capitolul 3 fiind detaliată aplicabilitatea acestora.


13

Capitolul 3. ARHITECTURI ȘI ALGORITMI CLOUD COMPUTING

Arhitecturile de tip cloud pot fi analizate din două perspective diferite, din punct de

vedere organizatoric și din punct de vedere tehnic. În cadrul acestui capitol va fi discutat în prima secțiune punctul de vedere organizatoric, ceea ce presupune o distincție a domeniului în care utilizatorii și ofertanții de servicii sunt organizați și modul în care sunt separați. În secțiunile următoare va fi dezbătut din punctul de vedere al funcționalității tehnice și al algoritmilor pentru gestionarea resurselor unui sistem cloud.

3.1 Modele de implementare

Conceptul de sisteme de calcul bazate pe cloud, se referă la diferite tipuri de infrastructuri, de diferite dimensiuni, precum și la diferite sisteme de management și grupuri de utilizatori. Astfel vor fi tratate aspectele organizatorice ce corespund modelelor de implementare din definiția NIST [23] în funcție de următoarele domenii: � sisteme cloud publice – infrastructura este construită și deținută de către operatorii de mari centre de date, care pun la dispoziția publicului larg sau organizațiilor resursele sub forma unor servicii; �- sisteme cloud private – infrastructura este dedicată pentru o singură organizație, poate fi gestionată de către organizație sau de către o terță parte și poate exista atât în centrul de date propriu cât și în afara organizației; �- sisteme cloud tip comunitate – infrastructura este partajată de către mai multe organizații și operată de o comunitate cu preocupări comune (obiective, cerințe de securitate, politici de audit, etc.). Resursele pot fi gestionate de către organizații sau de către o terță parte și pot exista atât în centrul de date propriu cât și în afara organizației; �- sisteme cloud hibride – acest model de implementare combină două sau mai multe din modelele de implementare anterioare (privat, public, comunitate), care rămân entități de sine stătătoare, dar sunt legate între ele prin interfețe sau tehnologii, fie standardizate sau proprietare, permițând portabilitatea datelor și a aplicațiilor (inclusiv, de exemplu, echilibrarea traficului).

3.1.1 Sistemele cloud publice

Acest model este denumit și ca ”sistem cloud extern”, și se referă la resursele care sunt puse la dispoziție, de către ofertanți specializați, unor utilizatori care nu aparțin aceluiași domeniu organizațional. Astfel, ofertanții au interese comerciale, deși majoritatea ofertelor existente includ și pachete gratuite, oferind un portal web, unde utilizatorii pot să solicite anumite resurse sau servicii. Utilizatorii pot specifica anumite caracteristici pentru performanțele și calitatea serviciilor, pentru aceasta fiind reglementate și anumite prevederi contractuale. Aceștia plătesc doar pentru resursele consumate într-o anumită perioadă de timp, și nu au costuri cu achiziționarea, operarea și întreținerea unor echipamente.

3.1.2 Sistemele cloud private

Din punct de vedere administrativ, infrastructura fizică a unui sistem cloud privat poate fi implementată intern, în centrul de date al organizației, sau poate fi externalizată, într-un centru de date specializat [24]. Astfel modelul de sistem cloud privat poate fi discutat separat în funcție de perimetrul de securitate, ce cuprinde un anumit domeniu. În cadrul sistemelor cloud private interne, perimetrul de securitate include resursele interne ale unei organizații precum și infrastructura sistemului cloud privat. Sistemul cloud privat intern poate fi centralizat într-un singur centru de date al clientului, sau poate fi distribuit între mai multe sedii [7]. Un al doilea model de implementare, cel al unui cloud privat externalizat, mai este denumit și sistem cloud privat extern (virtual) sau ”outsourced”, și constă în implementarea a două perimetre de securitate, unul pentru organizația care utilizează serviciile cloud, și unul


14

pentru operatorul de servicii cloud. Cele două perimetre de securitate sunt conectate prin intermediul unei legături de comunicație securizate. Nivelul de securitate general al unui sistem cloud privat externalizat este dat de siguranța și disponibilitatea celor două perimetre de securitate, precum și a conexiunii dintre ele. Astfel, operatorul unui sistem cloud privat externalizat asigură perimetrul de securitate din domeniul său în cadrul sistemului cloud, asigurându-se ca resursele protejate să fie separate de alte resurse din rețeaua cloud.

3.1.3 Sistemele cloud de tip comunitate

Acest model de implementare s-a impus în urma unor probleme remarcate la primele modele, în special al controlului și limitărilor exercitate de anumiți operatori, și a lipsei de sustenabilitate din punct de vedere energetic. Astfel, sistemele cloud de tip comunitate combină alocarea de resurse distribuite din modelul sistemelor de calcul tip grid, cu controlul distribuit și eficiența energetică a sistemelor cu impact redus asupra mediului, împreună cu posibilitatea managementului automat al resurselor [25]. Sistemele cloud de tip comunitate reprezintă o paradigmă pentru implementarea rețelelor cloud într-o comunitate, utilizând calculatoarele personale din rețelele interconectate și resursele neutilizate, pentru a obține o decentralizare față de modelul concentrat al unui sistem cloud tradițional. Din punct de vedere tehnic, acest model este mai dificil de implementat, datorită problemelor de coordonare a capacității de calcul distribuite, cu noduri eterogene, QoS diferite și condiții de securitate diferite.

3.1.4 Sisteme cloud hibride

Acest model de implementare este compus din două sau mai multe tipuri de rețele cloud descrise anterior, având, conform definiției, numeroase variante de realizare și fiind denumit și rețea cloud virtuală [5]. Posibilitățile de compunere a unei rețele cloud hibride se realizează în funcție de cerințele de performanță, disponibilitate, securitate și nu în ultimul rând, de cost. În Fig. 3.1 este prezentată o variantă care include toate variantele de sisteme cloud anterior analizate, cu scopul de a evidenția flexibilitatea acestui model de implementare. Acest model este cel mai dinamic și poate fi modificat prin adăugarea sau deconectarea diferitelor sisteme cloud în rețea, putând deveni, în funcție de numărul de componente, foarte complex. O variantă simplificată este cea a unei interconectări între o rețea cloud privată ce deservește traficul normal și o rețea cloud externă, conectată pentru rezolvarea situațiilor în care apar vârfuri de trafic [5]. Modelul poate fi utilizat și pentru a asigura redundanța unei rețele cloud în cazul unor forțe majore sau pentru backup [4], respectiv medii de lucru multi-cloud [26].

Cloud privat

intern

Cloud privat

internControlor de

perimetru

Controlor de

perimetru

Controlor de

perimetru

Cloud privat

externalizat

Controlor de

perimetru

Controlor de

perimetru

Cloud de tip

comunitate

externalizatControlor de

perimetru

Cloud de tip

comunitate

intern Controlor de

perimetru

Cloud

public

Fig. 3.1. Model de implementare a unei rețele cloud hibrid


15

3.2 Managementul resurselor

Rețelele de calcul bazate pe cloud oferă teoretic posibilitatea de a gestiona resurse aproape nelimitate de putere de calcul, memorie de procesare și spațiu de stocare, clienții având capacitatea de a-și ajusta nevoia de consum dinamic în timp foarte scurt, în mod uzual câteva minute [5].

Pentru gestionarea serviciilor în rețeaua cloud au fost definiți cinci factori caracteristici [24], care vor fi detaliați în următoarele capitole: � autoservire în funcție de nevoie; � accesibilitate în rețea; � resurse utilizate în comun; � elasticitate rapidă; � servicii măsurabile.

În plus, o a șasea caracteristică este definită de către Cloud Security Alliance [27] ca fiind conceptul de ”multi-tenancy” care se referă la utilizarea unor resurse sau infrastructuri în comun de către utilizatorii din aceeași sau diferite organizații, cu implicații asupra vizibilității datelor reziduale sau a urmelor operațiilor de către alți utilizatori sau operatorul de cloud.

În Fig. 3.2 sunt prezentați factorii care contribuie la complexitatea sistemelor de calcul și comunicații, modul de adaptare a unui cloud la acești factori, precum și legăturile de cauzalitate. De exemplu, constrângerile fizice sunt cele impuse de legile fizice, precum disiparea de căldură sau viteza finită a luminii, determinând optimizarea consumului de resurse.

Noi aplicații

Noi

componente

Constrângeri

fizice

Constrângeri

de timp

Adaptabilitatea

sistemelor de calcul și

comunicații

Optimizare consum

de resurse

Folosirea sistemului de

către un număr mare

de utilizatori

Interconectare și

mobilitate

Fig. 3.2. Modul de adaptare la factorii care contribuie la complexitate unui sistem de calcul și comunicații

Principalii factori, la care un cloud trebuie să se adapteze, sunt, în primul rând, dezvoltările tehnologice și disponibilitatea unor componente noi, mai eficiente și mai ieftine, precum procesoare cu mai multe nuclee, diferiți senzori, medii de stocare cu densitate și viteză de acces ridicată.

3.3 Algoritmi pentru managementul resurselor

Managementul resurselor reprezintă nucleul funcționării oricărui sistem de calcul, și este condiționat de trei criterii de bază pentru evaluarea unui sistem: performanță, funcționalitate și cost.

Pentru managementul resurselor este necesară determinarea politicilor, care reprezintă principiile după care se iau deciziile, și mecanismele care reprezintă punerea în aplicare a politicilor. Astfel, politicile pentru managementul resurselor în cloud se pot grupa în cinci clase: � Controlul accesului – reprezintă restricționarea accesului la un sistem, în sensul de a accepta sarcini de procesare noi, conform politicii de control, dar și de a finaliza sarcinile aflate deja în lucru, limitarea necesitând cunoașterea stării globale a sistemului; � Alocarea eficientă a capacității – se referă la alocarea resurselor pentru fiecare instanță activă a unui serviciu în cloud, fiind o problemă de optimizare globală, ce necesită căutarea unor resurse într-un spațiu cu anumite constrângeri și schimbări frecvente ale sistemelor componente. � Echilibrarea încărcării rețelei (Load balancing) – se poate realiza la nivel local, împreună cu optimizarea energetică, pentru a distribui sarcinile de procesare în mod egal într-un grup de


16

servere, fiind însă dificilă la nivel global. �Optimizarea energetică – este unul din obiectivele principale pentru a reduce costurile serviciilor, și se poate realiza prin concentrarea sarcinilor de procesare pe cel mai redus număr posibil de servere, și comutarea celorlalte servere în modul stand-by, fiind însă dificilă gestionarea QoS în acest context. �Garantarea QoS – poate fi tratată ca o problemă de optimizare a resurselor, însă modelele necesită calcule complexe, ce nu pot fi realizate eficient într-un interval de timp suficient de scurt pentru luarea deciziilor de gestionare și alocare a resurselor

Implementarea politicilor pentru managementul resurselor se poate realiza prin patru categorii de mecanisme, care se bazează pe o abordare bine determinată în loc de metode ad-hoc (a) Teoria controlului – utilizează principiul feedback-ului pentru a garanta stabilitatea sistemului și a prezice tranziții [28], însă poate prezice doar comportamentul local, și nu cel global, existând modele simplificate, dar nerealiste de utilizare a filtrelor Kalman pentru aceasta (b) Modelul utilităților – este necesar un model de performanță și un mecanism de atribuire a costurilor și coordonare a acestuia cu performanța la nivel de utilizator [29] (c) Sistemele de învățare automată (Machine learning) – sunt o ramură a tehnicilor de inteligență artificială prin care un sistem poate învăța din datele procesate. Un avantaj îl reprezintă faptul că aceste tehnici nu necesită un model de performanță a sistemului [26], și pot fi aplicate pentru coordonarea mai multor noduri care sunt la rândul lor manageri ale unor sisteme autonome (d) Mecanisme economice – sunt mecanisme ce țin cont de principiile funcționării unei piețe libere de tranzacționare a resurselor și nu necesită un model al sistemului, utilizând de exemplu licitații combinatorii pentru pachete de resurse [30].

3.3.1 Algoritmi de tip control

Teoria controlului a fost utilizată pentru a proiecta algoritmi de management adaptiv al resurselor pentru diferite clase de aplicații, printre care cele pentru managementul alimentării electrice, a planificării de operații (task-uri), stabilirea mecanismelor QoS și echilibrarea încărcării rețelei (load balancing) pentru servere web.

Metodele clasice de control cu reacție inversă (feedback), sunt utilizate pentru a optimiza parametrii principali ai unui sistem, pe baza măsurătorilor efectuate la ieșirile sistemului, fiind în general metode ce presupun modele de sisteme liniare, invariabile în timp, și un controlor, cu buclă închisă. Mecanismul de control se referă la optimizarea funcției specifice sistemului prin satisfacerea unor constrângeri.

De asemenea, există tehnici de realizare a sistemelor care se auto-gestionează pe baza conceptelor din teoria controlului [31], fiind aplicabile serverelor de tip distribuit pentru aplicații web sau baze de date. Acestea, după cum va fi arătat în continuare, permit exprimarea unor constrângeri de alocare a resurselor și obiective de tip QoS prin folosirea unei funcții de tip cost.

O astfel de funcție convexă de cost are ca argumente x(k), starea la pasul k, și vectorul de control u(k). Funcția de cost este minimizată conform condițiilor de dinamică a sistemului. În cazul rezolvării problemei de control optim în timp discret, se caută secvența de variabile de control u(i), u(i+1), …, u(n-1) pentru a minimiza expresia: �� = ��, �� +∑ ��, �� (3.1)

unde Φ��, �� este funcția de cost de la ultimul pas (n), și ��, �� este o funcție de cost variabilă în timp, la pasul k în limitele [i,n]. Minimizarea se realizează în condițiile: �� + 1� = ��, �� (3.2)

unde x(k+1), starea sistemului la momentul k+1, este în funcție de x(k), starea sistemului la momentul k, și u(k), intrarea la momentul k. În general funcția �� este variabilă în timp, față de momentul k. Se folosește una din tehnicile de rezolvare a acestei probleme pe baza metodei multiplicatorului Lagrange de a găsi extreme, în acest caz maximul unei funcții


17

cu anumite constrângeri. Pentru găsirea maximului unei funcții g(x,y) având constrângerile h(x,y)=k se introduce multiplicatorul Lagrange �. Se definește funcția: Λ�x, y, λ� = g�x, y� + λ × [ℎ�, $� − �] (3.3)

O condiție necesară pentru ca să găsim un optim (maxim global) este studierea condițiilor de ordin întâi: ∇(,),*Λ�x, y, λ� = 0 (3.4)

adică:

,-.�(,),/�-0 , -.�(,),/�-1 , -.�(,),/�-/ 2 = 0 (3.5)

Soluția se obține utilizând teoria optimizărilor convexe [32], considerând că multiplicatorul Lagrange la pasul k este λ3 și rezolvarea ecuației de sus ca o problemă de optimizare fără constrângeri. Se definește o funcție de cost adjunctă ce include constrângerile inițiale ca funcția Hamiltoniană H, și se construiește un sistem adjunct din ecuațiile stării inițiale și ecuațiile multiplicatorului Lagrange.

Pentru a calcula parametrii optimi de intrare dintr-un anumit set finit, este prezentat în Fig. 3.3 un controlor optimal [28] ce folosește feedback-ul referitor la starea curentă, precum și o estimare a perturbațiilor viitoare datorită mediului extern. Problema de control este rezolvată ca o problemă de actualizare a stărilor inițiale și finale dintr-o mulțime finită.

Filtru

predictiv

Controlor

optimal

Coadă de

procesareTrafic extern

Perturbații

Predicție

u*(k)

Reacție stare q(k)

ω(k)

r s λ(k)

Fig. 3.3. Sistem de control optimal pentru calculul timpului de răspuns 4��

În cadrul acestui sistem, frecvența de operare a procesorului u(k), este variabila care este controlată, și ieșirea sistemului de control optimal este timpul de procesare 4��, care include timpul de așteptare a cererilor și timpul de procesare pe un procesor P. Parametrii r și s fiind factori de ponderare pentru parametrii funcției cost, fiind aplicați funcției care modelează consumul energetic, respectiv funcției de tip utilitate, după cum se va arăta în continuare. Se utilizează un model de coadă simplă pentru a estima timpul de răspuns și cererile de servicii la un procesor P să fie procesate pe bază FIFO (First In First Out), nefiind presupuse distribuții apriori ale sosirii sarcinilor de procesare sau ale timpului de procesare. Se utilizează Λ5(k) pentru estimarea ratei de sosire Λ�� la momentul k. De asemenea, se definește frecvența de funcționare a procesorului u(k) în intervalul u(k) ∈ [umin, umax] în care procesorul poate funcționa.

Tehnicile cu scalare dinamică a tensiunii și frecvenței de tip Dynamic Voltage and

Frequency Scaling (DVFS), precum Intel SpeedStep și AMD PowerNow [33], permit scăderea, respectiv creșterea tensiunii de operare sau a frecvenței unui procesor, pentru a scădea consumul de energie, respectiv pentru a crește rata de execuție a instrucțiunilor. Această dependență, a puterii disipate în funcție de frecvența și tensiunea de operare, rezultă din ecuația:

P= CL × V2 × f (3.6)

unde P – puterea disipată totală în regim dinamic al CMOS, CL – Capacitatea de sarcină, V – variația tensiunii în timpul unei tranziții, f – frecvența tranzițiilor. Funcția de economisire a consumului a fost dezvoltată inițial pentru dispozitive mobile, fiind inclusă în prezent în toate procesoarele, inclusiv pentru cele utilizate în servere de tip HPC.

Se definește o funcție de utilitate de tip treaptă ca în Fig. 3.4, în care se specifică penalități sau recompense în funcție de SLA pentru timpul de răspuns [28].


18

Timp de răspuns (ω)

Utilitate U(ω)

Pena

lizar

eRe

com

pens

ă

ω0 ω1 ω2

0

Fig. 3.4. Funcția de utilitate U(4) reprezentată ca funcție de tip treaptă în funcție de timpul de răspuns 4

Pentru aplicarea conceptelor teoretice ale controlului optimal prezentate anterior, este proiectată o platformă cloud în care managementul automat al resurselor este realizat prin două niveluri de controlere, la nivel de aplicație și la nivel de cloud. În Fig. 3.5 este prezentat un astfel de model de arhitectură în care sunt interconectate următoarele elemente principale ale unui sistem de control: � - intrări: sarcinile de procesare, politicile de alocare a resurselor, tehnicile de echilibrare a încărcării rețelei (load balancing), optimizare energetică, parametrii SLA și QoS. � - componentele sistemului de control: senzori care estimează sau măsoară parametrii de performanță și controlere care implementează diferitele politici de control. �- ieșiri: alocarea resurselor pentru fiecare aplicație

Applicație 1

VM VM

Applicație N

VM VM

SLA 1 SLA N

Monitorizare

Decizie

Actuator

Controler

aplicație 1

Controler cloud

Monitorizare

Decizie

Actuator

Controler

aplicație N

Platformă cloud

Fig. 3.5. Model de arhitectură cu două nivele de control – controlul aplicațiilor și al mașinilor virtuale dintr-o platformă

cloud

Deoarece schimbările mari pot determina o instabilitate a sistemului, controlerele folosesc feedback-ul primit de la senzori pentru a asigura stabilitatea, aceasta fiind observabilă prin parametrii de la ieșiri.

3.3.2 Algoritmi bazați pe funcții de utilitate

O funcție de utilitate se referă la beneficiile unei activități, sau a unui serviciu, în contextul în care există un cost pentru a oferi serviciul. De exemplu, beneficiul poate fi venitul unui operator de cloud, și costul se poate referi la consumul de energie electrică. Scopul este de a maximiza profitul total, calculat ca diferența dintre beneficiile din garantarea unui SLA, și costul total al serviciilor oferite. Pentru formularea modelului într-un sistem cloud, se consideră K clase diferite de servicii, fiecare clasa k implicând Nk aplicații [34]. Se definește 7� ca și beneficiul sau penalizarea pentru un timp de răspuns 8� și un model liniar al funcției de utilitate ca în Fig. 3.4, de forma:

7� = 7�9:0 ;1 − 8� 8�9:0< = (3.7)

Unde >� = −8� 8�9:0< reprezintă panta funcției de utilitate. Această abordare prezintă

dezavantajul că nu poate fi extinsă la sisteme cloud cu un număr foarte mare de servere [34],


19

fiind neaplicabilă în cazul unor strategii de management al resurselor pentru sistemele cloud reale. Se constată că modelele analitice sunt prea complexe pentru sistemele cu multe noduri din cauza numărului mare de variabile de decizie și a parametrilor necesari pentru modelare.

3.3.3 Algoritmi de tip învățare automată (”machine learning”)

În cazul unei rețele cloud este necesară cooperarea mai multor sisteme autonome, cu diferite mecanisme de gestiune a resurselor, pentru a oferi serviciile la un anumit nivel SLA și totodată să optimizeze consumul de energie electrică.

După cum am prezentat în capitolele anterioare, procesoarele moderne utilizează funcția DVFS pentru a economisi energie electrică, puterea disipată fiind proporțională cu pătratul tensiunii de alimentare a procesorului. De asemenea, funcțiile pentru managementul energiei la nivelul procesorului ajustează frecvența de lucru a acestuia, și astfel rata de execuție a instrucțiunilor. În funcție de tipul sarcinilor de procesare, pe de-o parte performanța poate scădea liniar cu frecvența procesorului pentru aplicațiile care utilizează intensiv procesorul; pe de altă parte, pentru anumite operații, scăderea frecvenței procesorului are un efect minor asupra performanței.

O abordare pentru coordonarea autonomă a gestionării performanței și energiei consumate, prin ajustarea frecvenței de lucru la nivelul programelor software de bază (firmware), de mai multe ori în intervalul de o secundă, se poate aplica pe arhitecturi de tip servere blade [35], ca în Fig. 3.6.

În acest sens se utilizează o funcție compusă de tip utilitate pentru performanță și consum electric ?@A�B, C�, unde R este timpul de răspuns și P energia consumată. Exemple de astfel de funcții pot fi: ?@A�B, C� = ?�B�– E × C (3.8) sau ?@A�B, C� = ?�B�/P (3.9) unde ?�B� este funcția de tip utilitate ce depinde doar de timpul de răspuns și E un factor de ponderare a celor doi parametrii timp și energie.

Management

performanță

Management

consum electric

Server 1

Server N

Alocare

sarcini de

procesare

Alocare

consum

electric

ControlControl

Comunicare între entitățile

autonome de management

Date performanțe

servere

Date consum

electric

ElectricitateSarcini de

procesare

Fig. 3.6. Cooperarea între sisteme autonome de management pentru a asigura performanța definită în SLA și

optimizarea consumului electric

Pentru comunicarea între cele două entități de management autonome este necesară identificarea unui set comun minimal de parametrii. Acești parametrii se determină astfel încât o entitate existentă de management a performanței să poată fi modificată pentru a aplica o limitare a consumului electric, pe baza funcției de tip utilitate.

3.3.4 Algoritmi de tip licitație

Algoritmii de tip licitație provin din teoria jocurilor, reprezentând o modalitate de studiu a algoritmilor de luare a deciziilor strategice. Teoria jocurilor a fost aplicată pentru studiul comportamentului uman, dar și pentru a studia interacțiunile din rețele de comunicații,


20

fiind utilizată o abordare interdisciplinară ce implică domeniile științifice ale matematicii și economiei [36]. În cazul licitațiilor combinatoriale, jucătorii pot depune oferte pentru combinații de produse sau servicii, fiind specifice pentru comerțul de tip B2B (Business to

business) [37]. Spre deosebire de licitațiile tradiționale, în care participanții licitează pentru elemente individuale sau cantități continue, participanții la licitații combinatoriale optează pentru pachete de elemente discrete. Licitațiile combinatoriale oferă o soluție simplă, ușor de extins și de contorizat pentru problemele de alocare a resurselor în cloud [38].

O categorie specială de licitații combinatoriale sunt licitațiile pe bază de prețuri crescătoare cu ceas (”Ascending Clock Auction”) în care prețul actual pentru fiecare resursă este reprezentat de un ”ceas” văzut de toți participanții la licitație [30]. Acestea sunt o variațiune a licitațiilor pe bază de ceas simultan (”Simultaneous clock auction”) ce aparține categoriei de licitații pe bază de prețuri crescătoare simultane (”Simultaneous ascending

auction”), cu diferența că ofertanții răspund doar cu o cantitate dorită la un preț stabilit de către operator, fiind eficiente în special pentru cantități mari din bunuri divizibile.

În concluzie, algoritmii de tip licitație sunt potriviți pentru cerințele de management a unor pachete de resurse în cloud, fără a fi necesară existența unui model a sistemului. Totodată, este dificilă implementarea practică având în vedere că în cazurile licitațiilor ofertanții răspund în același timp, sau se pot sincroniza prin intermediul unui intermediar de tip proxy, spre deosebire de cererile de servicii în cloud ce sosesc aleatoriu. Din această cauză trebuie organizate licitații periodice, ceea ce însă adaugă o întârziere la timpul de răspuns și nu corespunde cu principiul elasticității unui cloud ce presupune disponibilitatea imediată a unui set de resurse.

3.3.5 Algoritmi genetici

În domeniul tehnologiei informației, algoritmii genetici reprezintă o modalitate inovativă de a implementa metode euristice din domeniul inteligenței artificiale, modelând procesele evoluției naturale. Aceștia sunt numiți și meta-euristici, fiind utilizați pentru generarea de soluții aproximative pentru probleme de optimizare și căutare, care altfel prin metode clasice ar avea o durată de rezolvare prea mare sau nu se poate găsi o soluție exactă.

După cum s-a utilizat și pentru algoritmii anteriori, se definește o funcție obiectiv și se urmărește minimizarea costului total exprimat de funcția: HIJI:K�� = ∑ L��M�� × N�� (3.10) unde L�� este costul pentru o anumită alocare de resurse din categoria � (de exemplu consumul de energie electrică în kWh) și N�� este penalizarea adimensională, dar care poate fi exprimată pentru multe categorii ca o sumă de bani.

Pentru realizarea migrării unei mașini virtuale s-a constatat dependența QoS de gradul de utilizare al acesteia în cazul unei migrări live. În plus, două direcții viitoare de cercetare sunt reprezentate de dezvoltarea unor scenarii de cost detaliate și de reducere a similarității populației. Funcția cost poate fi extinsă prin includerea tuturor pierderilor ale diferitelor mașini virtuale eterogene și de a implementa anumite priorități de eficientizare energetică, sau de a penaliza existența a două mașini virtuale specifice pe același server cu scopul ca anumite mașini virtuale să nu ruleze împreună din motive de performanțe, izolarea clienților, etc. Ca și soluții inovative se pot utiliza algoritmi de tip epidemic (infecție/imunitate) pentru reproducerea prin clonare în loc de încrucișare, și aplicarea a cel puțin unei mutații fiecărui individ din populație, rezultând o selecție a celor mai buni indivizi și o pierdere a diversității de sub 70%, față de 90% pentru algoritmii genetici.

Astfel, această abordare prevede că în viitor se vor utiliza servere de o performanță normalizată, legături de comunicații uniforme și centre de date compuse din componente modulare, ușor inter-schimbabile pe măsură ce anumite module sunt disponibile ca și tehnologii îmbunătățite.


21

Capitolul 4. SERVICII CLOUD COMPUTING

În cadrul acestui capitol vor fi prezentate serviciile oferite de către un sistem de calcul

bazat pe cloud, și modul în care acestea pot fi grupate în funcție de categoria de resurse oferite în anumite niveluri.

Este subliniată diferența între serviciile cloud și atributele acestora, și conceptul de cloud computing descris în capitolele anterioare, acesta din urmă reprezentând de fapt tehnologiile și sistemele ce permit crearea de servicii cloud.

După cum a fost prezentat în capitolele anterioare, sistemele cloud permit implementarea de sisteme și tehnologii eterogene, mecanisme de alocare de resurse și aplicații ca și servicii web. În consecință, nu este de mirare faptul că și domeniul de servicii cloud este corespunzător foarte divers, și la o primă analiză foarte eterogen din punct de vedere al funcționalităților și utilizării.

Pe baza arhitecturilor conceptuale prezentate anterior se va construi întâi o comparație între cloud computing și serviciile oferite de acesta, pentru ca apoi să se realizeze o diagramă ce va ajuta în categorisirea diferitelor niveluri de servicii. Aceasta va permite compararea instanțelor din fiecare categorie și este utilă pentru a determina clasele de echivalență precum și a găsi anumite servicii cloud complementare pentru a realiza soluții optime pentru diferite scenarii de utilizare.

4.1 Atribute ale serviciilor cloud

În Capitolul 2 am constatat că există numeroase inițiative de standardizare pentru definirea tipurilor și claselor de servicii cloud, și structurarea acestora în niveluri de livrare servicii, cele mai cunoscute fiind IaaS, PaaS și SaaS. Strategiile de gestionarea pentru aceste niveluri sunt diferite, dar ca și proprietate comună este fluctuația foarte mare de cereri de resurse, pentru care operatorii de servicii în cloud trebuie să eficientizeze alocarea de resurse prin implementarea mecanismelor de tip elasticitate. În unele cazuri, vârfurile de trafic pot fi prevăzute, de exemplu pentru servicii web ce au vârfuri sezoniere, dar pentru situațiile neprevăzute trebuie implementate mecanisme de alocare automată. Aceasta presupune faptul că există o rezervă de resurse, care pot fi eliberate sau alocate în funcție de cerere și că există un sistem de monitorizare, cu un mecanism de control pentru a decide în timp real realocarea resurselor.

Nivelurile într-o rețea cloud nu sunt organizate strict ierarhic, de exemplu un nivel superior poate utiliza serviciile de la toate nivelurile inferioare, nu numai de la nivelul imediat inferior, așa cum este prezentat simplificat în Fig. 4.1.

SaaS

PaaS

IaaS

Utilizatori

Tehnologii și sisteme (hardware și software)

Serviciu operator cloud - utilizator

Serviciu infrastructură – operator cloud

Serviciu între operatori cloud

Fig. 4.1. Model simplificat al relației între diferite niveluri ale unui cloud

După cum se poate observa, nivelurile principale sunt cele ale tehnologiilor și sistemelor hardware și software discutate anterior (tehnologii de virtualizare, SOA, Web Service, etc.) și nivelurile serviciilor oferite de operatorii de cloud (IaaS, PaaS, SaaS).


22

4.2 Niveluri de livrare servicii în sistemele de calcul bazate pe cloud

În continuare sunt detaliate nivelurile IaaS, PaaS și SaaS [39]. Infrastructura ca

serviciu (IaaS) este una dintre cele mai cunoscute modalități de a oferi resurse ca serviciu, cunoscută și sub denumirea Hardware as a Service (HaaS). Aceasta poate fi împărțită în mai multe categorii, cele mai importante fiind: (a) Calcul ca serviciu (CaaS) prin care mașini virtuale sunt închiriate și tarifate în funcție de consumul de resurse într-o anumită unitate de timp, în principal memorie, procesor, caracteristici tehnice ale acesteia, sistem de operare sau aplicații pre-instalate; (b) Date ca serviciu (DaaS), cunoscut și ca Storage as a Service

(STaas), prin care spațiu de stocare virtual nelimitat este oferit pentru stocarea fișierelor, indiferent de dimensiunea și tipul acestora, fiind tarifat volumul de date stocat sau transferat; (c) Rețea ca serviciu (Network as a Service – NaaS) se referă la servicii în cloud care pun la dispoziție conexiuni sau rețele virtuale, precum VPN sau MVNO, prin partajarea infrastructurii ce poate aparține de exemplu unor terți operatori de comunicații.

Serviciile oferite la nivelul Platformă ca serviciu (PaaS) sunt în principal utilizate de dezvoltatorii de aplicații pentru utilizatori, și mai puțin accesate direct de către aceștia din urmă. Platforma reprezintă în principal un middleware care oferă un mediu de programare și rulare, prin care diferite aplicații, scrise în diferite limbaje de programare, pot fi oferite ca servicii.

Aplicațiile software care sunt oferite ca servicii în cloud compun nivelul Software ca

serviciu (SaaS), fiind așezate din perspectiva nivelurilor de livrare servicii deasupra PaaS și IaaS. Acest model prezintă avantajul că utilizatorii nu trebuie să mai instaleze aplicațiile software pe echipamente locale limitate în resurse, ci pot fi accesate și configurate cu ușurință prin intermediul unor interfețe web.

În literatura științifică recentă au fost introduse noi concepte de alte aplicații oferite ca

servicii (XaaS), culminând cu nivelul cel mai de sus al oamenilor, oferiți ca serviciu deasupra stivei de calcul bazate pe cloud, așa numitul Human as a Service (HuaaS). Această abordare evidențiază faptul că paradigma ”cloud computing” nu se limitează doar la resursele tehnologice, ci poate fi extinsă pentru a oferi și servicii prin participarea de ființe umane ca și resurse.

Ca și subcategorie a HuaaS este cunoscut termenul de crowdsourcing, ce descrie un serviciu oferit de un grup de oameni interconectați ce efectuează anumite sarcini sau rezolvă probleme de o anumită complexitate, inclusiv pentru situații de criză [40].

În [41] autorii propun un serviciu pentru gestionarea informației contextuale în sisteme distribuite de mari dimensiuni. Acest serviciu propune un concept de ”raționament” ca serviciu (Reasoning as a Service - RaaS) și se bazează pe mesaje XML pentru configurarea unor servicii M2M, ce se adaptează în funcție de schimbarea contextului. În plus, în [42] se propune un sistem de management al comunicațiilor, ce utilizează serviciile de gestionare contextuală a informației în cadrul unei platforme de comunicații cu scopul de a eficientiza interacțiunile utilizatorilor.

Aceste servicii reprezintă, de asemenea, bazele pentru noile paradigme de Internet, dintre care amintim: � - Internet of Things (IoT): o infrastructură globală de rețele de senzori și dispozitive, bazată pe protocoale interoperabile de comunicații ce interconectează obiecte fizice și virtuale într-o rețea informațională; �- Internet of Services (IoS): interfețe standardizate, deschise și configurabile oferă posibilitatea diferitelor aplicații să funcționeze ca servicii interoperabile, utilizând semantici specifice pentru înțelegerea, agregarea și procesarea informației ce provine din diferite surse, formate sau alte niveluri de servicii; �- Internet of People (IoP): după cum s-a arătat prin conceptul de HuaaS, oamenii devin parte a unor rețele eterogene inteligente, având posibilitatea de a se conecta, interacționa și schimba informații cu ușurință între aceștia și contextul social sau mediu; �- Internet of Everything

(IoE): posibilitatea de a interconecta orice dispozitiv capabil de a oferi servicii web și accesarea acestora prin interfețe de interacționare naturale om-mașină.


23

Capitolul 5. ALEGEREA UNEI PLATFORME EXPERIMENTALE DE

TIP CLOUD

În cadrul acestui capitol se vor analiza mai multe platforme pentru simularea și

realizarea unui sistem cloud. Se vor analiza în continuare mai multe abordări pentru simularea aplicațiilor în cloud și se vor cerceta criteriile pentru alegerea unei platforme cloud.

5.1 Simularea aplicațiilor în cloud

În continuare se va realiza o analiză a abordărilor pentru modelarea și simularea aplicațiilor în cloud, ce va ajuta în alegerea unei soluții tehnice pentru implementarea unei platforme experimentale. Din punctul de vedere al elasticității au fost elaborate mai multe modele, fiind unul din criteriile cele mai importante în alegerea unui sistem cloud din punct de vedere al utilizatorului. De exemplu, se poate modela fiecare resursă (procesor, memorie, rețea, stocare, etc.) ca o unitate ce poate fi alocată și monitorizată de către utilizator pentru a respecta metricile definite de tip QoS [43]. Pentru modelarea SLA se poate stabili o relație matematică simplă, în urma analizei corelației între nivelul SLA necesar pentru aplicații și numărul de servere utilizate pentru a rula aplicațiile respective. Se poate ține cont, de exemplu, și de numărul de mașini virtuale și frecvențele la care acestea trebuie să ruleze, pentru a minimiza consumul de energie electrică [44], această modelare fiind strâns legată cu abordarea prezentată în secțiunea următoare. Eficiența energetică a unui sistem cloud a fost analizată în secțiunea dedicată managementului resurselor, fiind studiate soluțiile pentru mai multe tipuri de probleme de optimizare, precum minimizarea funcției de tip cost pentru diferite resurse (energie, mașini virtuale, lățime de bandă) sau reducerea emisiilor de CO2, respectând anumite constrângeri de tip QoS.

5.1.1 Analiza aplicațiilor de simulare pentru sisteme cloud

Modelele matematice prezentate anterior se referă în principal la optimizarea mecanismelor de gestionare a resurselor, pe baza algoritmilor de management al resurselor discutați în secțiunea dedicată acestora. Deși astfel de modele matematice sunt disponibile pentru algoritmi de alocare a resurselor pentru sisteme de tip grid, cluster sau P2P [45], acestea nu se pot utiliza ca atare pentru modelarea unui sistem cloud, datorită arhitecturii bazate pe mașini virtuale a acestuia din urmă. În plus, în cazul sistemelor cloud reale, este necesară studierea aspectelor legate de comunicații și comportamentul utilizatorilor, fiind mai indicată abordarea de a utiliza aplicații de simulare precum cele descrise comparativ în secțiunile următoare: GreenCloud [46], MDCSim [47], iCanCloud [48], GDCSim [49], DCSim [50], CloudSim [51], CDOSim [52], TeachCloud [53].

5.1.2 Exemplu de simulare pentru aplicații cloud în domeniul rețelelor de tip

Cognitive Radio

Pentru a demonstra utilitatea în cazul unei rețele de tip Cognitive Radio (CR), unde mai mulți emițători concurează pentru canale de comunicații libere, este propusă extinderea unui simulator cloud (CloudSim) [51], cu un model de rețea scalabilă, și un model generalizat de aplicație de gestiune a încrederii, pe baza unui algoritm de prelucrare a datelor istorice. Această abordare permite evaluarea mai corectă a politicilor de planificare și alocare a resurselor, pentru a optimiza performanțele unei infrastructuri cloud pentru aplicații de tip CR.

Pentru a depăși limitările date de simulatoare actuale cloud, propunem dezvoltarea unui cadru de simulare pe baza NetworkCloudSim [54], care suportă modelarea de centre de date cloud reale și aplicații generice, cum ar fi aplicații de tip HPC, e-commerce și fluxuri de


24

procesare multimedia. În cazul CR sunt definite noduri primare, ce au drepturi de acces exclusiv la domenii determinate ale spectrului, și noduri secundare, ce au acces dinamic la spectru, având posibilitatea de a utiliza orice canal în cazul în care nodul primar, care are licența pentru utilizarea acestuia, nu îl utilizează. Atunci când un nod primar începe transmisiunea, nodul secundar care utilizează un canal licențiat, trebuie să îl elibereze și să caute un alt canal liber. Astfel, rețele CR se bazează pe o strategie de cooperare pentru analiza spectrului, fiecare nod determinând ocuparea spectrului pe baza măsurătorilor proprii și a informațiilor primite de la nodurile vecine, partajând apoi aceste informații. Partajarea informațiilor este necesară pentru că un singur nod nu poate să determine adevărata ocupare spectrală, având o capacitate limitată de emisie și recepție, iar problemele tipice ale canalelor radio (zgomot, multi-path fading) precum și mobilitatea nodurilor adăugă dificultăți în culegerea unor informații reale. Nodurile individuale ale unei infrastructuri centralizate CR trimit rezultatele măsurătorilor legate de ocuparea spectrului, sub forma unui raport, către o entitate centrală (stații de bază, puncte de acces), care la rândul ei agregă datele și le distribuie nodurilor din jurisdicția sa.

Algoritmul MPI propus pentru rezolvarea acestei probleme calculează încrederea unui nod 1 ≤ i ≤ n pentru orice nod j din vecinătatea Vi. Pașii executați pentru nodul i la momentul de timp t sunt următorii: (1). Stabilirea variantei nodului i pentru raportul de ocupare a spectrului, prin măsurarea puterii pentru fiecare din canalele k:

Si(t) = {si,1(t), si,2(t), …, si,k(t)} (1) (2). Determinarea setului Vi(t) prin transmiterea unui mesaj de tip difuzare (broadcast) către nodurile din apropiere și fiecare nod răspunde cu NodeId (3) Determinarea distanței până la fiecare nod j ∈ Vi(t), deducerea puterii măsurate de fiecare nod pe fiecare canal k și utilizarea acestor parametrii pentru a determina starea fiecărui canal

O�,�,PQ:KQRK:I = S 0TULă�WT�XOYL��TU8ZTYL�TYLU�UX�X�X�[Y81TULă�WT�XOYL��TU8ZTYL�TYLU�UX�X�WL�NU\

TULă��OYNWU\Y�ULY��L�WTY\Y8>��U8Y ] (4) Se recepționează informațiile de la nodurile vecine O�,�,P^AQA@ț�J�:I

. (5) Se compară setul de

informații recepționate de la nodul vecin j ∈Vi cu cel calculat de nodul i despre nodul j. (6) Se determină numărul de potriviri `, numărul de nepotriviri a și numărul de cazuri b în care nu se poate face nici o determinare.(7) Se calculează gradul de încredere, fiind propusă formula

c�,P�\� = �1 + b�,P�\�� × `�,P�\�`�,P�\� + a�,P�\�

Pentru a valida acuratețea rezultatelor de simulare a aplicației bazate pe NetworkCloudSim, s-a comparat executarea unei cereri MPI pe o infrastructură reală într-un cloud open source, cu executarea simulată în NetworkCloudSim. Pentru experimentare, s-au utilizat trace-uri ale unui program MPI pe o scara mică a infrastructurii reale utilizând instrumentul mpilog si folosind metodologia dată de Miguel-Alonso [55]. În aplicația MPI, principalul proces calculează algoritmul prezentat anterior pentru un nod din rețeaua CR, și apoi trimite datele la toate celelalte procese ale celorlalte noduri. Fiecare calculator gazdă are 2 mașini virtuale, fiecare cu 2 nuclee și 4 GB RAM. Toate calculatoarele gazdă sunt conectate printr-un switch de 100 Mbps iar fiecare proces al aplicației MPI este executat pe o mașină virtuală individuală. Pentru comparație, aceleași configurații sunt utilizate pentru simularea pe baza NetworkCloudSim. Pentru evaluare, sunt avute în vedere două scenarii experimentale: a) un număr de 50 noduri cu procese MPI comunicante b) variind cantitatea de date transferate prin creșterea rețelei la 200 noduri. În Fig. 5.1 sunt prezentate cele două scenarii simulate.

Rezultatele de la executarea reală sunt prezentate ca "măsurate", în timp ce rezultatele simulate cu NetworkCloudSim ca "simulate" în Tabelul 2.1.


25

Tabelul 5.1 - Timpul de execuție pentru algoritmul de stabilire a încrederii

Parametrii Număr de noduri (n) n=50 n=200

Durată simulată (ms) 124 277 Durată măsurată (ms) 145 285

Încredere mediată simulată 0,56 0,70 Încredere mediată măsurată 0,67 0,75

Rezultatele evaluării arată că aplicația bazată pe NetworkCloudSim este capabilă să simuleze rețeaua unui centru de date cloud și aplicații cu task-uri comunicante, cum ar fi MPI, cu un grad ridicat de precizie.

(a) (b)

Fig. 5.1. Performanța algoritmului MPI pentru CR în cazul (a) 50 noduri (b) 200 noduri

5.2 Cerințele impuse platformei experimentale

Cerințele specifice unei platforme cloud sunt enumerate în cele ce urmează:� Să permită rularea pe diferite platforme de virtualizare și sisteme de operare; � Existența unei platforme de dezvoltare care să permită adăugarea de aplicații scrise în diferite medii de programare; � Utilizarea unui limbaj de programare ușor de învățat, și care permite portabilitatea pe alte platforme; � Capacitatea de a oferi resursele în cloud, indiferent de topologia de rețea în care se află nodurile din cloud, inclusiv în rețele IPv6; � Posibilitatea specificării cât mai detaliate a resurselor necesare (procesor, memorie, rețea, stocare, etc.); � Să fie cu sursă deschisă (open source) pentru a permite modificări și optimizări ale algoritmilor de management al resurselor.

5.3 Descrierea comparativă a variantelor considerate

5.3.1 Sisteme de tip cloud public

În această secțiune este prezentată o sinteză a principalelor sisteme de tip cloud public, și analizate caracteristicile acestora.

Amazon Web Serives (AWS) [56] este numele comercial al serviciilor de cloud oferite de Amazon fiind lansate oficial în anul 2006. Printre cele mai cunoscute servicii sunt Amazon

EC2 [57] și S3 [58], acestea provenind din surplusul de resurse ale companiei, aceasta fiind cunoscută ca un magazin online ce necesita un volum mare de resurse în perioada de vârf a cumpărăturilor, iar în restul anului resursele stăteau nefolosite. Sistemul cloud Google, spre deosebire de sistemul cloud Amazon, oferă servicii de tip PaaS prin Google AppEngine

(mediu de programare și execuție Python și Java) [59] sau de tip SaaS (servicii de bază și compuse prin mecanisme de tip mashup) construite peste nivelul PaaS [60]. Sistemul cloud


26

Windows Azure [61] este platforma de cloud computing, ce permite rularea de aplicații în centrele de date Microsoft. De asemenea, Microsoft oferă varianta SaaS a diferitor alte aplicații software, cele mai cunoscute fiind programele de tip Office, cu o disponibilitate de peste 99,9% [62]. Spre deosebire de sistemele anterioare, platforma Azure nu oferă suport pentru rularea unor aplicații distribuite de calcul paralel precum MapReduce sau MPI

(Message Passing Interface), având doar funcții de bază pentru rularea unor cozi sau batch-uri de comenzi [63].

5.3.2 Sisteme cloud private

În această secțiune sunt descrise diferite soluții pentru platforme cloud de tip privat, fiind analizate soluții cu sursă deschisă. O serie de sisteme cloud private sunt cercetate comparativ: OpenStack [64], CloudStack [65], Eucalyptus [66], OpenNebula [67], Nimbus [68], OpenCirrus [69] și SlapOS [70].

5.3.3 Justificarea alegerii platformei SlapOS

Motivele care au dus la alegerea platformei SlapOS pentru experimentări rezultă din îndeplinirea cerințelor enumerate în secțiunea anterioară.

Acesta este un sistem cloud cu sursă deschisă, prin care se poate automatiza implementarea și configurarea de aplicații într-un mediu eterogen și distribuit. SlapOS este conceput să ruleze peste orice sistem de operare ce suportă modulele GNU glibc și supervisord [71], acestea fiind incluse în pachetul de bază GNU/Linux, FreeBSD, MacOS/X,

Solaris sau AIX. De asemenea, platforma poate rula pe sisteme Windows, ca și sisteme de operare de tip invitat (guest), și se află în dezvoltare o versiune pentru a suporta Windows și ca sistem de operare gazdă, prin portarea glibc și supervisord. SlapOS este bazat pe o arhitectură Master-Slave distribuită, după cum este prezentat în Fig. 5.2. În secțiunile următoare vor fi detaliate de asemenea nivelurile PaaS și SaaS, propunând analiza diferitelor componente open source și crearea unei astfel de platforme open source cloud.

Slave

Slave

Birou

Acasă

Slave

Centru de

date

Slave

Dispozitiv

mobil

Master

Client

Fig. 5.2. Arhitectură de tip Master-Slave distribuită a sistemului SlapOS

Astfel, din punctul de vedere al compatibilității cu diferite sisteme de operare, aspect considerat cel mai important în implementarea unei platforme cloud decentralizate, SlapOS poate utiliza orice sistem de operare sau virtualizare, inclusiv pe terminale mobile de tip Android. Mai mult, SlapOS poate furniza servicii la oricare din nivelurile SaaS, PaaS și IaaS, astfel încât poate funcționa indiferent dacă folosește propria infrastructură hardware privată sau publică, deoarece poate găzdui diversitatea resurselor cloud și le poate gestiona ca și cum ar fi ale sale.

Din punctul de vedere al platformei de dezvoltare, se observă că SlapOS este cu sursă deschisă și oferă suport gratuit pentru dezvoltarea de aplicații, mediile de programare fiind


27

cele suportate de sistemele de operare compatibile POSIX. Astfel, Linux este una dintre cele mai utilizate platforme de dezvoltare, care poate fi folosită pentru a adăuga aplicații scrise în majoritatea mediilor de programare.

Întrucât limbajul de programare folosit pentru dezvoltarea SlapOS este Python, acesta asigură portabilitatea, fiind însă posibilă includerea de module scrise și în alte limbaje precum C sau Ruby [72]. Python este un limbaj de programare ușor de învățat, dar în același timp un limbaj foarte puternic. Acesta cuprinde structuri de date de nivel înalt și o abordare simplă, dar eficientă a programării orientate pe obiecte. În scrierea unui program în Python, nu este nevoie de detaliile de nivel jos, cum ar fi gestionarea memoriei utilizate de către program. De asemenea, Python nu are nevoie de compilarea programului în cod binar, ci rulează programul direct din codul sursă [73]. Pe plan intern, Python convertește codul sursă într-o formă intermediară numită bytecodes, și apoi traduce acest lucru în limbajul nativ de programare al calculatorului și apoi îl rulează. Toate acestea, de fapt, contribuie la folosirea cu ușurință a limbajului Python, din moment ce nu trebuie decât să se asigure că bibliotecile corespunzătoare sunt referențiate și încărcate. Acest lucru face ca programele în Python sa fie mult mai portabile, deoarece se pot copia de pe un alt calculator pe altul, funcționând fără modificări.

În ceea ce privește topologia de rețea, SlapOS atribuie fiecărei partiții de stocare o adresă IPv6 dedicată și o adresă IPv4 privată, fiind posibilă alocarea opțională a unei adrese IPv4 publice. Deși utilizarea IPv6 nu este obligatorie, aceasta simplifică crearea unor modele de implementare de tip cloud privat sau hibrid, prin interconectarea nodurilor SlapOS găzduite în rețele interne acasă sau în diferitele organizații, fără a fi nevoie de configurarea unor tunele sau redirecționări complexe de porturi.

Din punctul de vedere al specificării cât mai detaliate a resurselor, acestea se pot configura modular, pentru fiecare din cei 14 parametrii ai unei resurse existând o granularitate în alegerea caracteristicilor: tipul resursei (publică, privată, grup), grup de rețea cloud, grup de sistem de virtualizare (Amazon, RackSpace, VMware, etc.), număr nuclee procesor, frecvență procesor, tip procesor (ARM, Intel x86, Intel x64, etc.), tip rețea (Ethernet, WiFi, GSM, etc.), capacitate rețea, dimensiuni memorie (1 – 256 GB), tip memorie (DDRx, frecvență), regiune (Africa, Europa, etc.), stocare (finită 8GB-4TB, infinită), interfață stocare (NAS, SAN, SATA, etc.), redundanță stocare (RAID 0-6).

De asemenea, fiind o platformă cu sursă deschisă, există o comunitate foarte activă de dezvoltatori și sunt publicate constant noi versiuni și informații legate de dezvoltarea acestei platforme. Nu în ultimul rând, costurile de achiziție și operare reprezintă un avantaj, fiind realizat un studiu asupra eficienței implementării unui astfel de sistem pentru aplicații de comunicații și colaborare de tip groupware [74].


28

Capitolul 6. PLATFORMA CLOUD CU SURSĂ DESCHISĂ SLAPOS

În cadrul acestui capitol sunt prezentate aspecte legate de arhitectură și principalele caracteristici ale platformei SlapOS, ce a fost aleasă pentru construirea unei platforme cloud în urma cercetării prezentate în cadrul capitolului anterior.

6.1 Arhitectura SlapOS

SlapOS este un sistem cloud distribuit cu sursă deschisă, care permite crearea de servicii la oricare din nivelurile de livrare SaaS, PaaS sau IaaS. Astfel, SlapOS poate funcționa peste orice infrastructură hardware privată sau publică partajată, gestionând diferitele resurse eterogene ca și cum ar fi ale sale. Din aceasta rezultă că sistemul poate fi folosit, de asemenea, pentru optimizarea utilizării resurselor între diferiți furnizori cloud.

Arhitectura SlapOS este bazată pe conceptul de Master și Slave, după cum s-a arătat în Fig. 5.2, care va fi detaliată în continuare din punct de vedere software și al funcționalităților pentru crearea unei platforme cloud distribuite. Nodurile Master sunt un director central pentru nodurile din sistemul cloud, având rolul de a aloca procese către nodurile Slave și de a ține o evidență a situației fiecărui nod Slave și a aplicațiilor software care sunt instalate pe fiecare nod. Nodurile Slave pot fi instalate pe orice calculator, atât în centre de date, cât și în rețele private, iar rolul lor este de a instala aplicații software și de a rula procese.

Din punct de vedere al virtualizării, SlapOS reprezintă o paradigmă inovativă, de a nu folosi tehnologiile de virtualizare uzuale, precum mașini virtuale, VMware, etc., și nici resurse din centre de date. Astfel, are loc distribuirea sistemului cloud peste calculatoare uzuale, aflate în birouri sau case, în plus contribuind la optimizarea resurselor deja existente și la economisirea de energie. O modalitate de realizare a unui sistem cloud cu impact redus asupra mediului, este de a reutiliza căldura disipată a serverelor pentru încălzirea spațiilor și de a găzdui servere în țări unde nu este nevoie de instalații de răcire. Această arhitectură distribuită este în contrast cu arhitecturile tradiționale, pe mai multe niveluri, unde nivelul IaaS este implementat pentru un sistem cloud public în centre de date de dimensiuni, ce se presupune că oferă o eficiență optimă datorită volumului mare de resurse și automatizări, sau pentru un sistem cloud privat ce folosește un nivel IaaS găzduit pe tehnologii scumpe SAN. Pe lângă avantajele enumerate anterior legate de eficientizarea resurselor și reducerea impactului asupra mediului, este creată și posibilitatea de a proteja libertatea de expresie și a elimina cenzura, prin construirea unor sisteme cloud de tip comunitate hibride trans-naționale.

6.2 Nodul Master SlapOS

Nodul Master are rolul de a ține evidența tuturor entităților care sunt implicate în solicitarea de resurse din sistemul cloud, precum și de a contoriza și taxa resursele folosite. Aceste entități pot fi persoane ca și consumatori de resurse cloud, sau organizațiile acestora, dar și furnizori de resurse cloud, care pun la dispoziție așa numite partiții pe calculatoarele acestora, în cadrul nodurile Slave, după cum este prezentat în Fig. 6.1.

Astfel, SlapOS Master primește notificările de la nodurile Slave pentru serviciile disponibile publicate și solicitările de resurse care trebuie alocate, și poate transmite automat, fără intervenție umană, ce aplicații software să fie instalate și rulate ca servicii cloud. Cererile sunt prelucrate și transformate în căutări, în încercarea de a găsi un nod Slave care îndeplinește toate condițiile care au fost specificate. Astfel, SlapOS trebuie să știe ce resurse sunt disponibile la un moment dat, la ce preț și cu ce caracteristici. În cele din urmă, nodul SlapOS Master trebuie, de asemenea, să știe ce software poate fi instalat, pe care nod Slave și în ce condiții.


29

Internet

Utilizare servicii

Utilizatori Nod SlapOS

Slave

Alocare servicii

Cereri

alocări

servicii

Căutare și

cerere servicii

Referință către

serviciu

Utilizare servicii

Publicare servicii

Catalog

softwareCapacitate

disponibilă

și preț

Nod SlapOS

Master

Fig. 6.1. Arhitectura unui sistem SlapOS cu detalierea rolurilor unui nod Master

Nodul SlapOS Master rulează aplicația ERP5 Cloud Engine, care se bazează pe o aplicație de gestionare a resurselor ERP5 [75], al cărei model de referință a fost derivat dintr-o implementare pentru o Bancă Centrală. Ideea de bază este că procedurile de compensare pe piața financiară, și modalitățile de gestionare a resurselor dintr-un sistem cloud, sunt foarte asemănătoare, și pot fi implementate prin intermediul unei arhitecturi software asemănătoare [76]. ERP5 a fost deja implementat pentru o Banca Centrală în 8 țări, și, mai mult decât atât, a demonstrat fiabilitatea pentru aplicații de tip CRM de mari dimensiuni, datorită NEOPPOD [77], baza sa de date distribuită de tip NoSQL, care poate oferi suportul necesar pentru tranzacțiile cu memorarea stărilor (stateful) din diferite categorii de piețe.

Pentru a asigura securitatea, în SlapOS s-a implementat un mecanism care generează pentru fiecare entitate din Fig. 3.1 un certificat de autentificare de tip X.509. Astfel, pentru un nod Master cu un singur Slave și 20 partiții de calcul, ce corespund la 20 de instanțe software, ce trimit solicitări sau notificări către nodul Master, este nevoie de 22 certificate X.509. Nodurile Master memorează starea fiecărei schimbări, și conțin toate informațiile necesare pentru a reconstrui un nod Slave, în timp ce nodurile Slave nu conțin informații de stare, funcționând în modul fără memorarea stărilor (stateless). De aceea, este foarte important, ca datele despre starea nodurilor Slave, salvate pe nodul Master, să fie protejate prin mecanisme de redundanță a infrastructurii. Refacerea unui nod Slave se poate realiza prin includerea unei adrese de tip URL unde se poate ține o copie în timp real a nodului, ce se poate reconstrui în caz de avarie cu aceleași date. În cazul nodului Master, acesta poate fi distribuit la rândul său chiar pe noduri Slave, localizate în diferite regiuni, pentru a asigura redundanța geografică. Astfel, se pune în evidență arhitectura reflexivă a SlapOS, prin care un nod Master este de fapt o instanțiere a aplicației software SlapOS Master, și poate fi la rândul său instalat și rulat pe un grup de noduri Slave. În concluzie, un nod SlapOS Master poate instanția un nod Master, care la rândul lui poate aloca un alt nod Master, asigurând astfel o redundanță completă a sistemului cloud.

6.3 Nodul Slave

În comparație cu nodurile Master, nodurile Slave au o structură mult mai simplă, fiecare nod fiind împărțit într-un număr de partiții, în care fiecare nod Slave rulează aplicațiile software cerute de către nodul Master.

Astfel, pe partițiile din nodurile Slave se instalează aplicațiile software, iar pentru a economisi spațiu pe disc, este instalat doar software-ul necesar pentru rularea acestor aplicații. O partiție este de fapt un container virtual securizat, bazat pe mecanismele Unix de gestionare a utilizatorilor și directoarelor de fișiere. Această abordare prezintă avantaje de eficientizare a resurselor și reducere a costurilor, față de utilizarea unor mașini virtuale, fiind posibilă crearea de până la 100 partiții pe un calculator uzual, ceea ce înseamnă rularea de 100 de aplicații de


30

comunicații, fiecare cu bază de date independentă. În cazul unor servere, în funcție de configurația hardware, se poate ajunge la configurații cu până la 500 de partiții. Totodată, este posibilă și rularea de module de tip hypervisor pentru utilizarea imaginilor de mașinilor virtuale, ceea ce permite funcționarea în paralel a mai multor tipuri de virtualizări. Aceasta conduce, de asemenea, la economie de resurse, și permite în același timp rularea unor aplicații, care altfel nu pot fi portate către un model SaaS.

Software-ul Slave SlapOS are un nucleu care constă într-o arhitectură ierarhică formată dintr-un sistem de operare POSIX, și modulele SLAPGrid, Supervisord [71] și Buildout [78], după cum este prezentat în Fig. 3.2.

POSIX (GNU/Linux)

SLAPGrid

Buildout

Supervisord

Fig. 6.2. Arhitectura software a nucleului unui nod SlapOS Slave

SlapOS este proiectat să ruleze peste orice sistem de operare compatibil POSIX, care suportă modulele GNU Glibc și Supervisord, ca de exemplu sistemele de operare GNU / Linux, FreeBSD, MacOS / X, Solaris, AIX, etc. Modulele Buildout și Supervisord fac parte din distribuțiile de bază Linux, fiind tehnologii mature. Totodată, se lucrează la portarea acestor module pe platforme Microsoft Windows, ceea ce va permite rularea ca și gazdă a nodurilor SlapOS.

6.4 Modulele nucleu SlapOS

Modulul Supervisord [71] este o componentă de tip daemon Linux, ce poate fi folosit pentru a programa pornirea și oprirea unor procese ce rulează cu drepturile de la diferiți utilizatori, precum și pentru a prelua rezultatele proceselor, fișierele jurnal și eventualele mesaje de eroare. Supervisord este un modul care nu introduce un nivel intermediar complex de gestiune a resurselor, și este considerat ca o tehnologie matură pentru controlul proceselor. Ca și arhitectură, Supervisord este un sistem client/server, compus din serverul supervisord și clientul în linie de comandă supervisorctl. Spre deosebire de alte modalități de a gestiona procese pe sisteme de tip UNIX, acesta oferă o mai mare flexibilitatea decât tradiționalul sysinit, fiind o îmbunătățire a init.d cu control de la distanță, și elimină inconvenientul de a scrie script-uri rc.d pentru fiecare instanță de proces. Totodată, scripturile rc.d nu pot reporni automat anumite procese care s-au blocat, multe aplicații nepornind corect după ce un sistem se oprește forțat. Spre deosebire, supervisord pornește procesele ca sub-procese ale sale, cu posibilitatea de a fi configurate să pornească automat în funcție de anumite reguli.

Buildout [78] este folosit în SlapOS pentru a specifica aplicațiile software ce trebuie să fie executate pe un nod Slave. Acesta este un sistem bazat pe Python pentru crearea, asamblarea și instalarea aplicațiilor din surse multiple, ce pot să fie scrise și în alte limbaje de programare decât Python. Astfel, Buildout poate fi folosit pentru a instanția aplicații scrise în Java, Perl, Ruby, C, C++, etc. pe sisteme Linux, MacOS sau Windows. După cum s-a menționat anterior, Python este un limbaj de programare ce asigură portabilitatea aplicațiilor, cuprinzând structuri de date de nivel înalt, fără a avea nevoie de detaliile de nivel jos, precum gestionarea memoriei utilizate de către program. De fiecare dată când SLAPGrid primește o cerere de la SlapOS Master să instaleze un software, acesta descarcă o descriere a acestei aplicații sub forma unui profil Buildout, și apoi demarează procesul de instalare prin intermediul modului Buildout. Pe de altă parte, când SLAPGrid primește o cerere de la SlapOS Master pentru a rula o aplicație software ca un proces, întâi apelează Buildout pentru a crea toate fișierele de configurare, și apoi deleagă controlul execuției procesului către


31

Supervisord. Totodată, Buildout permite actualizarea de aplicații distribuite, care rulează pe sisteme cloud, precum aplicații pentru rețele de socializare, aplicații de gestionare a unei întreprinderi sau baze de date care necesită optimizări de performanță când depășesc anumite dimensiuni [74].

6.5 Protocolul SLAP

SlapOS funcționează pe baza protocolului SLAP, care este un acronim pentru “Simple

Language for Accounting and Provisioning” (limbaj simplu pentru contorizare și planificare). Acesta este independent de limbajul de programare, funcționând în cazul platformei experimentale implementat prin Python în SLAPGrid implementat în nodul Slave, și modulul corespunzător Python ERP5 Cloud Engine în nodul SlapOS Master.

Pentru simulare, protocolul SLAP a fost implementat în Java, fiind descris în Fig. 3.3.

Nod MasterNod Slave

http: set-capacity

O dată

http: get-sr-list

5 min

http: get-cp-list

5 min

1 sec

websocket

http: post-accounting

1 zi

Fig. 6.3. Protocolul SLAP

Acest protocol este de tip polling, fiecare nod SlapOS Slave conectându-se la nodul SlapOS Master prin HTTP, pentru a transmite unul din cele 4 mesaje XML: � definirea capacității prin comanda set-capacity; � descărcarea listei de aplicații software care trebuie instalate prin comanda get-sr-list; � descărcarea listei cu partiții care trebuie configurate pentru anumite servicii prin comanda get-cp-list; � transmiterea informațiilor de contorizare prin comanda post-accounting

Din punctul de vedere al performanței acestui protocol, s-a considerat că frecvența de interogare de tip polling nu este o problemă, dar în urma simulării pentru noduri Slave cu multe partiții, s-a constatat necesitatea de a face sistemul mai reactiv și a eficientiza conexiunile către nodul Master prin mecanisme de tip websocket sau noi metode HTTP (long

polling, push). Pentru validarea protocolului, în implementarea sa curentă HTTP, s-a folosit o

platformă de test din noduri cloud aflate geografic apropiate, ce va fi descrisă în detaliu în capitolul dedicat implementării platformei. Însă, pentru a crește siguranța platformei, este necesară mărirea numărului de noduri și distribuirea nodurilor pe continente diferite, ceea ce conduce la modelarea de noi scenarii pentru rețele intercontinentale, cu frecvente întreruperi.

6.6 Partiții de calcul

Această abordare a rezultat în urma experimentării cu alte abordări, precum mașini virtuale, sisteme de fișiere ce utilizează chroot sau containere de tip vserver-jail. Din punctul de vedere al securității, utilizarea de mașini virtuale prezintă cea mai sigură izolare între aplicații, fiind însă posibilă rularea de mașini virtuale în cadrul unei partiții. Pe de altă parte, din punctul de vedere al performanței, mașinile virtuale sau containerele de tip vserver-jail necesită un sistem de fișiere complet pentru fiecare instanță, rezultând că o parte din resursele nodului cloud vor fi utilizate pentru gestionarea acestor sisteme de fișiere. Astfel, în cazul unor noduri cu sute de sisteme de fișiere, este mult mai rentabilă abordarea containerelor de tip partiție de calcul, ce necesită doar un sistem de fișiere, și permite rularea de sute de aplicații ca servicii cloud. Implicit, prin utilizarea mai eficientă a resurselor, se realizează o cerință esențială a conceptului de sisteme cloud cu impact redus asupra mediului.


32

Din punct de vedere al implementării, Buildout este programat să utilizeze partițiile în funcție de două variante de profil: un profil pentru instalarea unei aplicații într-un director partajat, și un profil pentru instanțierea aplicației într-un director, conform fișierelor de configurare, cu legătură la directorul partajat. După un anumit timp, un nod SlapOS Slave va conține mai multe aplicații software instalate, și pentru fiecare aplicație, mai multe instanțieri ale acesteia, fiecare rulând ca un proces separat, după cum este prezentat în Fig. 6.4.

POSIX (GNU/Linux)

SLAPGrid

Buildout

Supervisord

Partiție

Aplicație 1

Partiție

Aplicație N

Partiții

instanțiere

aplicații

Director

utilizator

Director

partajat

Nucleu nod

SlapOS

Slave

Fig. 6.4. Schema bloc a unui nod tipic SlapOS

După cum este prezentat în Fig. 6.5, o partiție de calcul N are asociat un utilizator dedicat (slapuserN), respectiv un director dedicat (/srv/slapgrid/slappartN), precum și mai multe adrese pe partea de conexiune la rețea: o adresă IPv6 globală, o adresă IPv4 privată și o interfață Ethernet emulată (slaptapN). În plus, poate fi alocată o adresă IPv4 publică, sau un disc de stocare de tip bloc (/dev/sdaN). Fiecare partiție de aplicație, sau partiție de instanțiere a unei aplicații, are un director dedicat, și un utilizator alocat, care are drepturi exclusive asupra acestui director. Utilizatorii sunt creați conform politicii de securitate UNIX, și sunt denumiți de la slapuser0 la slapuserN, iar fiecare utilizator are acces doar asupra directorului său, respectiv slapuserN are acces doar la slappartN. În plus, fiecare utilizator slapuserN are acces la interfața virtuală de rețea slaptapN. Pentru anumite aplicații este nevoie să fie atașat un spațiu de stocare separat de tip bloc, existând posibilitatea de a aloca pentru fiecare partiție un astfel de disc virtual prin intermediul mecanismelor UNIX de gestionare a directoarelor (/dev/sdaN). Aceasta poate crește performanțele de tip I/O pentru accesarea sistemelor de fișiere atunci când se utilizează tehnologii de virtualizare KVM, sau în cazul accesului la discuri criptate. De asemenea, unele aplicații necesită pe lângă adresa IPv6 globală și IPv4 privată și o adresă IPv4 publică, pentru aplicații de tip portaluri web cu balansare de trafic sau mecanisme de distribuire a conținutului de tip CDN. Aceste aspecte legate de rețea, precum și cele legate de securitate și performanță, vor fi detaliate în secțiunea următoare.

Partiție Aplicație N

Director dedicat

(/srv/slapgrid/

slappartN)

Utilizator dedicat

(slapuserN)

Disc de stocare de tip

bloc (/dev/sdaN)

Ethernet emulat

(slaptapN)

IPv6

global

IPv4

privat

IPv4

public

Fig. 6.5. Schema bloc a unei partiții de calcul SlapOS Slave


33

Așa cum s-a arătat în capitolul dedicat tehnologiilor care stau la baza sistemelor cloud, IPv6 simplifică realizarea unui model de implementare a unei rețele cloud de tip private, publice sau hibride. Astfel, IPv6 este o componentă configurată standard în nodurile SlapOS slave, fiind însă posibilă o implementare strict pe IPv4. Totuși, IPv6 permite interconectarea nodurilor cloud aflate în diferite rețele, fără a fi nevoie să fie configurate tuneluri sau reguli de redirecționare a porturilor, ceea ce contribuie la securitatea și siguranța unor sisteme cloud publice sau private, ce folosesc această modalitate de adresare. De asemenea, utilizatorii care accesează procesele SlapOS prin intermediul unei interfețe web, se pot conecta și prin intermediul unei adrese IPv4, care este conectată la partiții de calcul speciale care au implementate adrese IPv4 și IPv6. Astfel, este creată o modalitate transparentă pentru un utilizator, ce poate accesa resurse IPv6 din cadrul sistemului cloud. O altă posibilitate este de a crea tuneluri IPv6, ceea ce permite accesarea proceselor din cloud de pe orice conexiune Internet, inclusiv GSM 3G sau ADSL, sau în ultimă instanță, de a crea o mașină virtuală în rețeaua SlapOS, și de a o accesa la distanță prin IPv4 și HTTP.

Ca și topologie de rețea, SlapOS implementează o arhitectură plată de adresare în rețea, deoarece singura legătură din nodurile sistemului cloud este adresa IPv6, făcând abstracție de protocoale de rutare precum BGP sau alte protocoale pentru managementul rețelei. Astfel, spre deosebire de alte soluții cloud, nu este nevoie să fie gestionate mecanisme de tip VLAN sau QoS. Totodată, la nivel de nucleu SlapOS nu sunt implementate mecanisme de securitate sau criptare, aceste aspecte fiind lăsate la nivelul aplicației, de a folosi metode de încapsulare, pentru a fi transferate peste rețeaua nesigură și imprevizibilă IP.

În cazul implementării securității la nivel de aplicație, pentru protocolul HTTP, serverul Apache oferă modulele de firewall la nivel de aplicație prin modulul mod_security, precum și criptarea de tip TLS. În cazul altor protocoale, pentru a rezolva problemele menționate mai sus, se utilizează serviciul Stunnel [79], care creează un tunel între două aplicații, ori de câte ori este nevoie de un canal de comunicații securizat, pe baza certificatelor X.509. Astfel, se pot converti aplicații existente, care nu suportă IPv6, în servicii cloud, fără a schimba codul sursă.

După cum s-a precizat în secțiunea dedicată structurii unei partiții de calcul, pe aceasta se poate instala o aplicație completă, ce poate conține mai multe module sau procese UNIX. De exemplu, dacă se instalează o aplicație web ce conține și o aplicație de comunicații (de exemplu Etherpad), cel puțin 2 procese sunt pornite: un proces pentru serverul Apache, ce are și funcția de securitate prin mod_security și mod_ssl, și un proces pentru aplicația de comunicații. În plus, dacă se adaugă o bază de date, atunci mai sunt pornite 2 procese: unul pentru baza de date în sine, și unul pentru securizarea și convertirea IPv6 la IPv4 prin Stunnel.

La limita extremă de performanță, o partiție de calcul poate include mai multe instanțe ale aceleiași aplicații, consumând toate resursele nodului cloud. Pentru a crește performanța, este recomandată respectarea principiul instalării de aplicații elementare pe fiecare partiție de calcul, ceea ce permite extinderea rețelei și optimizarea resurselor, datorită granularității în alocarea acestora.

Prin rularea instanțelor de aplicații ca procese, în loc de a crea o mașină virtuală pentru fiecare aplicații, așa cum este modelul altor sisteme cloud precum Amazon AWS EC2, a fost demonstrat că SlapOS permite utilizarea resurselor hardware mai eficient.

În concluzie, SlapOS este platforma recomandată pentru dezvoltatorii de aplicații cu sursă deschisă, pentru a-și transforma aplicațiile după modelul SaaS, inclusiv de a realiza migrarea acestora către IPv6.


34

Capitolul 7. IMPLEMENTAREA UNUI NOD DE TIP CLOUD PENTRU

APLICAȚII DE COMUNICAȚII

În cadrul acestui capitol se va prezenta metodologia de implementare a unui nod de tip cloud utilizând platforma SlapOS. De asemenea, se va realiza descrierea unor scenarii conceptuale de validare a platformei cloud pentru aplicații de comunicații.

7.1 Caracteristicile hardware și software ale platformei cloud

Au fost folosite pentru construirea infrastructurii sistemului cloud privat prezentat în această lucrare două servere Fujitsu Siemens și trei servere HP cu specificații hardware standard. Pe lângă acestea, au fost utilizate diferite alte calculatoare care rulau sistemul de operare Linux nativ, sau în cadrul unor mașini virtuale, precum și o mașină virtuală găzduită pe o instanță de tip mini în sistemul cloud Amazon AWS. Pe fiecare server din grupul ”BEIA DMZ” s-a utilizat câte una din tehnologiile de virtualizare Citrix Xen, Hyper-V și VMWare

vSphere ESXi, și tehnologia VirtualBox s-a utilizat pe calculatoarele uzuale (denumite BCI-CalculatorX) din interiorul unei rețele private, pe calculatoare din rețele mobile, și pe serverele din grupul ETTI.

În Fig. 7.1 este prezentată structura rețelei cloud folosită pentru implementarea sistemului cloud SlapOS.

82.78.81.171

10 Partiții

82.78.81.172

20 Partiții

82.78.81.173

20 Partiții

141.85.151.166

20 Partiții

Ec2-176-34-68-121.eu-west-1.compute.amazonaws.com

10 Partiții

BCI – Calculator 5

20 Partiții


20 Partiții


20 Partiții

BCI-Utilizator 1

BCI-Utilizator 2

BCI-Utilizator 3

BCI – Utilizator 4

Master SlapOS.org

141.85.151.167

20 Partiții

Fig. 7.1. Rețeaua cloud pentru implementarea sistemului SlapOS

Dezvoltarea sistemului de operare Ubuntu în paralel cu rețelele cloud a reprezentat unul din motivele alegerii acestuia ca și sistem de operare pentru implementarea nodurilor SlapOS. Amândouă versiunile Ubuntu Server, cea recentă 13.10 pe 64 biți și 12.04 LTS pe 64 biți, au fost folosite pe serverele din grupurile ETTI și BEIA pentru a găzdui nodurile cloud. Astfel, arhitectura utilizată în implementarea sistemului SlapOS constă dintr-o rețea distribuită de noduri cloud, ce pot avea unul din cele două roluri de Master sau Slave. Se utilizează serverele mai sus menționate și calculatoarele unor voluntari pentru rularea aplicațiilor SlapOS, fie de sine stătătoare, sau în paralel cu alte tehnologii de virtualizare. Metodologia de instalare și configurare a unui nod SlapOS este prezentat în cadrul următoarei secțiuni.

7.2 Metodologia de instalare și configurare a unui nod SlapOS

Ca abordare generală, întâi este instalat un sistem de operare de tip UNIX, fiind preferat Ubuntu Linux, după cum a fost argumentat anterior. Următorul pas constă în configurarea parametrilor de rețea și descărcarea surselor pentru instalare, după care se vor


35

instala modulele nucleu Buildout, Supervisord și SLAPGrid. În final, se vor configura partițiile și se vor aloca diferite aplicații pentru a testa sistemul cloud. Pentru un nod Slave SlapOS compus din mai multe partiții de calcul, se va implementa protocolul SlapOS și se vor demonstra următoarele: modul de creare a directoarelor pe un nod Slave, alocarea interfețelor de rețea la fiecare partiție, crearea fișierelor de configurare Buildout în funcție de alocarea și instanțierea aplicațiilor, controlarea proceselor prin Supervisord.

Nodul SlapOS Master va fi utilizat apoi pentru solicitarea unei instanțe pentru diferite aplicații de comunicații, iar SlapOS Master va căuta o partiție liberă în funcție de parametrii de tip SLA specificați. Nodul SlapOS Slave ales va instala aplicația software pe partiția de calcul liberă și va porni o instanță a aplicației, iar în momentul în care nu mai este nevoie de aceasta, va fi ștearsă. Pentru instalarea nodului Slave se vor utiliza mai multe scripturi Python, ce vor fi utilizate și pentru gestionarea nodului SlapOS, cele mai importante fiind: � slapformat – pentru crearea de utilizatori, directoare, interfețe de rețea de tip slaptapN și adrese IPv6 pentru fiecare partiție de calcul; � slapgrid – pentru implementarea procedurilor din protocolul SLAP și pentru comunicarea cu nodul SlapOS Master (cererile de instalare software, de instanțiere, de contorizare și ștergere); � slapconsole – pentru comunicarea cu SlapOS Master în linie de comandă; � slapgrid-supervisorctl – pentru accesul la lista cu procesele care rulează în toate partițiile de calcul

În cazul în care nodul SlapOS nu are acces la o rețea IPv6 globală rutabilă, se poate realiza un tunel IPv6 prin OpenVPN. În crontab sunt implementate secvențele protocolului SLAP prin comenzi Linux. Dintre acestea, cel mai frecvent utilizată este comanda slapformat, care realizează reconfigurările instanței și notifică nodul Master în cazul în care sunt modificări ale parametrilor de rețea. Pentru a adăuga un server nou ca nod Slave SlapOS, acesta trebuie înregistrat în nodul Master prin intermediul unei interfețe web sau linii de comandă. În plus trebuie obținut un certificat X.509 și o cheie, pentru a configura accesul securizat în cloud. Se va utiliza modul de lucru web, fiind posibilă autentificarea prin mai multe metode, inclusiv prin intermediul unui cont de socializare online. În cazul unui nod care trebuie reconfigurat, se rulează comanda slapprepare, care automatizează configurarea manuală a fișierului slapos.cfg. Această metodă este utilă și în cazul în care se utilizează o imagine de mașină virtuală predefinită, care poate fi copiată și reinițializată prin specificarea parametrilor. Pentru instalarea unei noi aplicații software, se selectează aplicația software de pe lista de servicii disponibile pe nodul SlapOS Master, precum și versiunea dorită. Nodul Slave folosește metoda de cerere aplicație (request), iar nodul Master încearcă să găsească o partiție disponibilă pentru a găzdui instanța. După cum s-a arătat, instanțierea unei aplicații se realizează prin intermediul interfeței web a nodului SlapOS Master, iar în momentul în care instanța se instalează complet, în interfața SlapOS Master se pot găsi parametrii de conectare: adresa de tip URL pentru serviciu, eventuale adrese de tip backend pentru procesele componente (bază de date, administrare server web).

Pentru crearea unei noi aplicații este necesară construirea unui script de tip Buildout,

aceasta fiind posibilă în linie de comandă sau interfață web. Aceeași posibilitate de editare, rulare și verificare există și pentru procedura de instanțiere a unei aplicații software. Instanțierea este un proces mult mai scurt ca durată, utilizând un profil simplu de instanțiere, iar în momentul finalizării este pornită partiția. Urmează apoi Supervisord să preia controlul instanței și să gestioneze starea partiției, precum și contorizarea resurselor consumate. Nodul Master SlapOS permite o interfață de monitorizare generală a nodurilor, aplicațiilor software instalate și a instanțelor ce rulează.

Pentru o monitorizare mai detaliată, inclusiv a altor echipamente din rețeaua cloud, se poate utiliza de exemplu Zabbix, care se poate instala prin intermediul slapconsole pe nodul pe care dorim să aibă rol de monitorizare. Se vor trece ca parametrii adresa IPv6 a Zabbix master iar datele colectate de clientul Zabbix (temperatura, capacitate RAM, etc.), sunt considerate non confidențiale și pot fi făcute publice, ca o consecință a nivelurilor de securitate SlapOS de a nu rula orice proces cu drepturi de superutilizator.


36

Capitolul 8. CONCLUZII

8.1 Concluzii generale

În cadrul tezei au fost analizate conceptele teoretice ale sistemelor de tip cloud computing, în vederea implementării unei platforme cloud pentru aplicații de comunicații.

� A fost cercetat stadiul actual al proiectelor care au avut ca scop dezvoltarea unor soluții de tip cloud, iar în urma analizei principalelor probleme întâmpinate în proiectele anterioare au fost propuse și evaluate posibile soluții. � S-a analizat actualitatea și necesitatea existenței unor soluții de tip cloud pentru interconectarea unui număr mare de componente eterogene prin Internet și s-au definit posibile aplicații de comunicații care pot fi implementate ca servicii (SaaS). Această abordare permite accesul la resursele de comunicații din orice locație conectată la Internet, precum și o flexibilitate la adăugare de servicii noi, prin interconectarea unor aplicații existente. Sistemele cloud au fost studiate din două puncte de vedere diferite, ca evoluție tehnologică dar și ca o evoluție a organizării sistemelor de calcul existente, fiind considerate ca bază pentru conceptele viitoare de IoT / IoE. � A fost constatată tendința cercetărilor actuale de a se concentra pe implementarea unor niveluri de servicii de tip SLA pentru asigurarea calității serviciilor cloud în marile centre de date. Totuși, în cazul unei forțe majore, condițiile de tip SLA nu mai sunt aplicabile, fiind propusă o posibilă soluție, de a utiliza un model de tip cloud computing decentralizat pentru agregarea resurselor dintr-o rețea de calculatoare standard situate în case, birouri, universități sau mici centre de date. Această abordare aduce o rezolvare inovativă și pentru aspectele legate de eficiența energetică, nodurile unui cloud decentralizat având posibilitatea să fie utilizate în funcție de anotimp și pentru încălzirea încăperilor unde sunt găzduite. � Au fost analizate și aspectele legate de securitate, fiind binecunoscut faptul că reprezintă probleme de securitate protocoalele de comunicații, în care nodurile sistemului cloud raportează resursele consumate, sau mecanismele ce se bazează pe încrederea că elementele de tip client transmit corect valorile de contorizare. În consecință, pentru soluția propusă sunt dezvoltate mecanisme de securitate ce previn ca nodurile să falsifice valorile de contorizare raportate, precum și utilizate conexiuni criptate, fiind implementată o schemă de autentificare cu certificate X.509, ce împiedică noduri neautorizate să se conecteze la sistemul cloud, și să intercepteze date. �O altă problemă ce frânează dezvoltarea sistemelor de tip cloud computing este reprezentată de gradul scăzut de adopție IPv6, la nivel global fiind sub 2%. Surprinzător, România este la începutul anului 2013 situată pe prima poziție la nivel mondial în privința disponibilității conexiunilor IPv6 (8,55%, următoarea clasată fiind Franța cu 5,09%), reprezentând un suport semnificativ pentru implementarea unei soluții cloud ce utilizează avantajele IPv6. � S-a accentuat faptul că domeniul calculatoarelor și cel al comunicațiilor sunt interconectate foarte strâns - când unul dintre cele două domenii avansează, atunci progresul poate să fie critic pentru celălalt. Astfel, sistemele cloud au devenit o alternativă pentru soluțiile de tip grid sau HPC în momentul în care Internetul a început să ofere capacități de transfer de bandă largă cu latență redusă, garanții de calitate și la costuri mici. În același timp, rețele actuale de comunicații nu ar putea funcționa fără sisteme de gestionare performante sau comutatoare controlate de către controlere software. � A fost măsurată eficacitatea unei paralelizări la nivelul sarcinilor de procesare prin definirea parametrului de accelerare a vitezei de procesare. Așa cum oamenii au învățat să se unească în grupuri pentru a lucra mai eficace în paralel pentru obținerea unui rezultat comun, la fel o rețea de entități se poate organiza pentru a îndeplini sarcini complexe și rezolva probleme ce nu pot fi rezolvate de o entitate individuală. � Din punctul de vedere al standardizării, au fost cercetate mai multe organizații și inițiative în acest sens, majoritatea provenind din domeniul sistemelor grid sau al stocării în rețea. Notabile sunt și contribuțiile românești la eforturile de standardizare, prin diferitele proiecte de cercetare colaborativă cu finanțare Europeană, pe tema serviciilor cloud sau a componentelor tehnologice pe care se bazează sistemele cloud. � Au fost prezentate


37

tehnologii și sisteme pentru realizarea unei soluții hardware și software cloud computing, precum și rolul rețelelor de comunicații în cadrul unor astfel de soluții. Au fost evaluate tehnologii precum grid computing, sisteme de virtualizare și aspectele de comunicații IPv6 pentru interconectarea resurselor într-o rețea cloud. În urma studierii tehnologiilor pe care se bazează sistemele cloud pentru realizarea nivelurile de abstractizare, și implicit pentru a oferi serviciile cloud către utilizatori și dezvoltatori, s-a remarcat necesitatea utilizării unor tehnologii de virtualizare a sistemelor de operare, platformelor, sistemelor de stocare, rețelei și aplicațiilor. Totodată, a fost examinată complexitatea tehnologică care este adesea ascunsă de către serviciile cloud, și constă în interconectarea nivelurilor de virtualizare și a interfețelor de tip SOA și Web 2.0 Services. � Evoluția sistemelor cloud din sistemele distribuite și decentralizate a fost argumentată enumerând caracteristicile comune și evaluând aplicabilitatea soluțiilor din aceste sisteme pentru problemele constatate în sistemele cloud, precum și modalități de integrare între sisteme. Lucrarea susține și evoluția sistemelor de tip P2P (peer-to-peer) în sisteme de tip cloud, fiind descrise avantajele și dezavantajele acestora, dar și arhitecturi, aplicații și tipuri de rețele ce pot fi aplicate pentru sistemele cloud. Deși nu sunt de neglijat, rețelele pur P2P ne-structurate sau structurate au anumite dezavantaje. De aceea, rețele care combină modelul P2P cu modelul client-server pentru managementul centralizat și serviciile de coordonare, sunt considerate că asigură o gestionare a resurselor și un nivel QoS, fără a încărca rețeaua cu mesaje de difuzare de tip broadcast, și păstrând robustețea prin faptul că toate nodurile au același rol în rețea. A fost propus un model de adaptare a unui protocol P2P pentru sisteme cloud decentralizate, precum și un algoritm de calculare a reputației și performanței într-o topologie cloud de tip master-slave multi-inel. A fost analizată posibilitatea adaptării unor topologii și metrici P2P pentru sistemele cloud, printre algoritmii eficienți în cazul rețelelor nestructurate și eterogene fiind considerați cei de tip licitație, epidemici sau genetici. Aceștia sunt considerați deja în stadiul de tehnologii care se îndreaptă spre etapa de maturitate, fiind justificată actualitatea conceptului propus de comunicații în cloud. � A fost realizat un studiu al arhitecturilor și algoritmilor cloud, care să permită implementarea aplicațiilor de comunicații sub forma diferitelor niveluri de servicii cloud. Arhitecturile de tip cloud au fost analizate din două perspective diferite, din punct de vedere organizatoric și din punct de vedere tehnic. Luând în considerare aspectele organizatorice, au fost studiate modelele de implementare, ce presupun o distincție a domeniului în care utilizatorii și ofertanții de servicii sunt organizați și modul în care sunt separați. S-a realizat un studiu comparativ al diferitelor modele de implementare sub forma unor sisteme cloud publice, private, de tip comunitate sau hibride, fiind de asemenea introdus conceptul de cloud de perimetru. A fost ales modelul de implementare hibrid, care combină două sau mai multe din modelele de implementare (privat, public, comunitate), care rămân entități de sine stătătoare, dar sunt legat între ele prin interfețe sau tehnologii, fie standardizate sau proprietare, permițând portabilitatea datelor și a aplicațiilor (inclusiv de exemplu echilibrarea traficului). În plus, față de acest model este propusă o arhitectură inovativă de organizare a resurselor unui cloud pe trei niveluri, realizând o rețea cloud de perimetru ce oferă servicii de calcul, stocare și rețea între dispozitive și centrele de date tradiționale (cloud central), nefiind însă localizată exclusiv la perimetrul rețelei, ci și la nivel de dispozitiv (cloud local). �A fost tratat în detaliu subiectul managementului resurselor în sisteme cloud, fiind determinate caracteristicile specifice și propuși algoritmi pentru gestionarea resurselor unui astfel de sistem. Pentru gestionarea serviciilor în rețeaua cloud, au fost definiți și analizați cinci factori caracteristici, iar separat au fost analizați șase factori suplimentari care se referă la managementul general al unor resurse cloud. �Implementarea politicilor pentru managementul resurselor în sisteme cloud se poate realiza prin patru categorii de mecanisme, care se bazează pe o abordare bine determinată în loc de metode ad-hoc: teoria controlului, modelul utilităților, sisteme de învățare automată și mecanisme economice. Algoritmii de implementare corespunzători au fost evaluați conform politicilor de management grupate în următoarele clase: controlul accesului, alocarea eficientă a capacității, echilibrarea încărcării


38

rețelei, optimizarea energetică și garantarea QoS. S-au propus algoritmi de tip control, bazați pe funcții de tip utilitate, de tip învățare automată, de tip licitație și genetici. � În cazul primului algoritm, scopul a fost de a demonstra o metodologie ce se poate aplica pentru gestionarea optimă a resurselor, bazată pe conceptele teoriei controlului optimal, fiind apoi analizată posibilitatea extinderii la un număr mai mare de servere. S-a constat că extinderea tehnicii, de la un singur sistem, la un număr mare de servere într-un sistem cloud prezintă o complexitate ridicată de calcul, fiind mai dificil cazul în care aplicațiile într-o rețea cloud necesită alte modele de prelucrare a cererilor, decât cea de procesare a unei stive de cereri. Algoritmii de tip licitație sunt potriviți în cazul cerințelor pentru managementul unor pachete de resurse în cloud, fără a fi necesară existența unui model a sistemului, însă este dificilă implementarea practică pentru cererile de servicii în cloud ce sosesc aleatoriu, deoarece algoritmul a fost conceput pentru cazul licitațiilor în care ofertanții răspund în același timp. Pentru a rezolva această problemă este propusă sincronizarea prin intermediul unui intermediar de tip proxy, din această cauză fiind necesară organizarea de licitații periodice, ceea ce însă adaugă o întârziere la timpul de răspuns și nu corespunde cu principiul elasticității unui cloud ce presupune disponibilitatea imediată a unui set de resurse. Algoritmii genetici propuși reprezintă o modalitate inovativă de a implementa metode euristice din domeniul inteligenței artificiale, modelând procesele evoluției naturale în sistemele cloud. � Diferitele tipuri de servicii cloud au fost prezentate pe larg, fiind analizat modul în care acestea pot fi grupate în funcție de categoria de resurse oferite în anumite niveluri. Au fost analizate atributele serviciilor cloud și subliniată diferența între diferitele niveluri de livrare servicii, fiind detaliate nivelurile de tip IaaS, PaaS, SaaS dar și XaaS. Au fost descrise mai multe exemple de aplicații de comunicații ce pot fi implementate ca servicii utilizând o platformă cloud. � A fost realizată o analiză comparativă atât între diferitele sisteme de simulare cât și între principalele platforme cloud. Scopul a fost de a determina cerințele unei platforme experimentale cloud și de a realiza întâi o simulare a aplicațiilor ce vor fi rulate în cloud, înainte de a trece la implementarea unui sistem. De asemenea, a fost realizată o simulare pentru implementarea unei aplicații de comunicații de tip calcul paralel și evaluate rezultatele de performanță. Pe baza îndeplinirii criteriilor impuse pentru o platformă experimentală cloud, a fost justificată alegerea platformei cu sursă deschisă SlapOS. � Ca și platformă experimentală a fost prezentat în detaliu sistemul cloud SlapOS, analizând arhitectura rețelei, precum și structura componentelor, inclusiv aspectele legate de performanță și securitate. A fost implementat conceptul de arhitectură master-slave într-o topologie inel și detaliată modalitatea de funcționare a protocolului pentru controlul resurselor din nodurile rețelei. � În final, a fost descrisă implementarea unui nod cloud SlapOS într-o arhitectură de tip hibrid, și realizate scenarii conceptuale de validare a platformei cloud pentru aplicații de comunicații.

8.2 Contribuţii originale

Autorul propune în cadrul acestei lucrări o platformă experimentală cloud cu sursă deschisă pentru implementarea aplicațiilor de comunicații. Printre obiectivele îndeplinite în această teză se numără: � Sinteza diverselor aspecte ale conceptului cloud computing, care implică tehnologii și sisteme, arhitecturi și modele de implementare, managementul resurselor și niveluri de livrare servicii; � Efectuarea unui studiu al relației între sistemele cloud și principalele tehnologii care stau la baza unui astfel de sistem ce este compus dintr-un număr mare de componente eterogene conectate prin Internet; � Studierea proiectelor de cercetare și standardizare curente referitoare la arhitecturile pentru sistemele de tip cloud și elaborarea unor cerințe pentru o platformă cloud; � Analiza stadiului actual al tehnologiilor și sistemelor pentru realizarea unei soluții hardware și software cloud computing, precum și analiza rolului rețelelor de comunicații în cadrul unor astfel de soluții; � Propunerea unei posibile soluții, de a utiliza un model de tip cloud computing decentralizat, prin agregarea resurselor dintr-o rețea


39

de calculatoare standard situate în case, birouri, universități sau mici centre de date, spre deosebire de centralizarea resurselor în mari centre de date; � Evaluarea tehnologiilor precum grid computing, sisteme de virtualizare și aspectele de comunicații IPv6 pentru interconectarea nodurilor unui sistem cloud decentralizat; � Studiul tehnologiilor pe care se bazează sistemele cloud computing pentru a oferi nivelurile de abstractizare și serviciile către utilizatori și dezvoltatori; � Examinarea complexității tehnologice, care este adesea ascunsă de către cloud computing, și constă în interconectarea nivelurilor de virtualizare, a interfețelor de tip SOA și Web 2.0 Services; � Propunerea a două abordări ale evoluției sistemelor de tip cloud computing: evoluție tehnologică și evoluție a organizării sistemelor de calcul; � Clasificarea diferitelor modele de implementare a sistemelor cloud și analiza acestora din punct de vedere al securității și performanței; � Propunerea de mecanisme de securitate pentru a preveni ca nodurile să falsifice valorile de contorizare raportate, precum și utilizarea de conexiuni criptate, și a unei scheme de autentificare cu certificate X.509 pentru a evita ca noduri neautorizate să se conecteze în cloud și să intercepteze date; � Studiul mai multor algoritmi de management al resurselor în sisteme cloud și propunerea de îmbunătățiri/adaptări pentru algoritmi de tip control optim; � Propunerea unui model de adaptare a protocolului P2P Chord pentru o rețea cloud, fiind transformată structura originală de tip inel într-o topologie master-slave multi-inel, cu ajutorul mecanismelor de grupare a adreselor IPv6 pentru nodurile dintr-o rețea cloud; � Propunerea unui algoritm pentru calcularea reputației și a performanței unui nod pe baza mecanismului P2P Credence, rezultând un algoritm decentralizat prin care fiecare nod folosește informația stocată local pentru a evalua alte noduri și a partaja evaluările de performanță și reputație cu nodurile vecine; � Determinarea politicilor pentru managementul resurselor în cloud, care reprezintă principiile după care se iau deciziile, și a mecanismelor care reprezintă punerea în aplicare a politicilor; � Compararea a patru categorii de mecanisme pentru gestionarea resurselor și dezvoltarea algoritmilor corespunzători implementării acestor politici, precum și evaluarea algoritmilor conform celor cinci clase de politici definite; � Realizarea unui model de control optimal pentru parametrii QoS și consum energetic și un model de arhitectură cu două niveluri de control – controlul aplicațiilor și al mașinilor virtuale dintr-o platformă cloud; � Propunerea unui model de cooperare între sisteme autonome de management pentru a asigura performanța definită în SLA și optimizarea consumului electric; � Implementarea unui algoritm de tip licitație pentru cerințele de management a unor pachete de resurse în cloud, fără a fi necesară existența unui model al sistemului, și rezolvarea problemei de sincronizare prin intermediul unui proxy; � Demonstrarea faptului că o întârziere a timpului de răspuns, chiar dacă nu corespunde cu principiul elasticității unui cloud ce presupune disponibilitatea imediată a unui set de resurse, poate fi benefică în reducerea riscului unor atacuri de tip speculativ asupra resurselor disponibile în sistemul cloud, în special când se utilizează algoritmi de tip licitație; � Realizarea unui studiu al nivelurilor de livrare servicii IaaS, PaaS și SaaS; � Definirea nivelurilor de servicii cloud și delimitarea responsabilității între utilizator și operatorul de servicii cloud, precum și propunerea unui model simplificat al relației între diferite niveluri ale unui cloud; � Descrierea unui număr de 5 aplicații de comunicații ce pot fi implementate ca servicii utilizând o platformă cloud, validate prin implementare și articole publicate; � Demonstrarea necesității modelării matematice a caracteristicilor principale ale unei platforme cloud și realizarea unei analize a aplicațiilor de simulare pentru sisteme cloud; � Dezvoltarea unui nou cadru de simulare cloud pe baza simulatorului CloudSim, cu modele de aplicații realiste pentru comunicații de tip CR (Cognitive Radio). Componentele cadrului de simulare sunt implementate pentru a oferi suport în simularea aplicațiilor de comunicații, cum ar fi MPI (Message Passing Interface) sau alte protocoale de comunicații; � Proiectarea unui model de flux de date pentru simulatorul de rețele din centrele de date, ce oferă servicii cloud prin partajarea lățimii de bandă, și controlează latențele pentru a permite simulări realiste. Cei mai mulți dintre parametrii simulatorului sunt configurabili, permițând simularea diferitelor topologii de rețea; � Prezentarea unei evaluări experimentale, pentru a arăta importanța


40

modelării în dezvoltarea unui sistem distribuit de gestiune a încrederii într-o rețea de tip radio cognitiv, realizând implementarea acestuia prin diferite mecanisme de planificare și gestionare a resurselor în cloud, cu posibilitatea de a fi extins și pentru diferite alte aplicații de comunicații în cloud. � Stabilirea unor cerințe pentru alegerea unei platforme experimentale și realizarea unei descrieri comparative a principalelor platforme cloud existente pe baza criteriilor impuse; � Implementarea unei platforme cloud cu sursă deschisă și validarea acesteia pentru aplicații de comunicații; � Participarea în proiectele de cercetare circumscrise tezei CLOUD CONSULTING (E*6021-305E; durata 2011-2013; coordonator Franța – Nexedi, coordonator România – BEIA Consult Int.), SARAT-IWSN (PN-II-PT-PCCA-2011-3.2-1030; durata 2012-2015; coordonator – UPB, partener – BEIA Consult Int.) și eWALL (FP7‐ICT‐2013‐10/Grant no. 610658, durata 2013-2016, coordonator Danemarca – Aalborg Universitet, coordonator România – UPB), activitatea fiind concretizată prin publicarea unui număr de 10 livrabile și 2 referate de cercetare; � Validarea rezultatelor obținute printr-un număr de 7 articole în volumele unor conferințe internaționale cotate ISI, 10 articole publicate în jurnale internaționale de specialitate și peste 20 de articole publicate în volumele unor conferințe internaționale indexate BDI (IEEE, ACM, etc.), totalizând peste 40 de citări; � Depunerea unei cereri de brevet (”Sistem de telemonitorizare”, număr depozit OSIM A00544/2013) pentru o aplicație de comunicații de tip M2M ce a fost experimentată pe platforma cloud propusă în cadrul acestei lucrări.

8.1 Perspective de dezvoltare

Autorul a participat în cadrul echipelor de propunere a mai multor proiecte de cercetare cu temă cloud, iar o bună parte din această teză s-a desfășurat prin încadrarea în proiectul de cercetare internațional, CloudConsulting, ce și-a propus crearea de noi tehnologii care automatizează configurarea unui sistem software de planificare a resurselor de tipul „Enterprise Resource Planning” (ERP) şi a unui sistem software de management al relaţiilor cu clienţii de tipul „Customer Relationship Management” (CRM) pentru beneficiul companiilor mici şi mijlocii (IMM). Lucrarea conține contribuții directe ale autorului la acest proiect. O posibilă continuare a acestui proiect o reprezintă îmbunătățirea securității și a disponibilității acestei platforme, precum și adăugarea de noi mecanisme pentru gestionarea resurselor.

Deoarece domeniul sistemelor de calcul bazate pe cloud este caracterizat de o evoluție extrem de dinamică, a fost realizată clasificarea actuală a tehnologiilor și serviciilor cloud la momentul scrierii acestei lucrări, fără a avea pretenția de a fi o descriere completă, ci mai degrabă o abordare arhetipală. Astfel, teza poate constitui un punct de plecare pentru dezvoltarea și implementarea unor noi arhitecturi și algoritmi pentru sisteme cloud.

Ca și perspective de dezvoltare se va cerceta modalitatea de utilizare a platformei cloud în scenarii de implementare pentru orașe inteligente și aplicații de tip Internetul obiectelor, cu aplicativitate în domeniul rețelelor mobile, monitorizării surselor de energii regenerabile și a mediului înconjurător, dar și pentru domenii precum agricultură sau sănătate.


41

BIBLIOGRAFIE

[1] L. M. Vaquero, L. Rodero-Merino, J. Caceres și M. Lindner, „A break in the clouds: towards a cloud definition,” ACM SIGCOMM

Computer Communication Review, vol. 39, nr. 1, pp. 50-55, 2008.

[2] „Cloud Computing Layers,” Cloud Consulting, [Interactiv]. Available: http://www.cloudconsulting.com/layers/.

[3] G. Suciu, O. Fratu, S. Halunga, C. G. Cernat, V. A. Poenaru și V. Suciu, „Cloud Consulting: ERP and Communication Application Integration in Open Source Cloud Systems,” în 19th Telecommunications Forum - TELFOR 2011, IEEE Communications Society, Belgrade, 2011.

[4] G. Suciu, C. G. Cernat, G. Todoran, V. Suciu, V. A. Poenaru, T. L. Militaru și S. Halunga, „A solution for implementing resilience in open source Cloud platforms,” în Proceedings of 2012 9th International Conference on Communications (COMM), IEEE

Communications Society, Bucharest, 2012.

[5] M. Armbrust, A. Fox, R. Griffith, I. Stoica și M. Zaharia, „Above the Clouds: A Berkeley View of Cloud,” Electrical Engineering and Computer Sciences, California, 2009.

[6] Google Inc., „Per-Country IPv6 adoption,” [Interactiv]. Available: http://www.google.com/ipv6/statistics.html#tab=per-country-ipv6-adoption. [Accesat March 2013].

[7] G. Suciu, E. G. Ularu și R. Craciunescu, „Public versus Private Cloud Adoption – a Case Study based on Open Source Cloud Platforms,” în 20th Telecommunications Forum - TELFOR 2012, IEEE Communications Society, Belgrade, 2012.

[8] Citrix Systems, Inc, „Citrix XenServer - Efficient Server Virtualization Software,” [Interactiv]. Available: http://www.citrix.com/xenserver . [Accesat August 2013].

[9] VMware, Inc, „vSphere ESX and ESXi Info Center,” [Interactiv]. Available: http://www.vmware.com/products/esxi-and-esx/overview. [Accesat August 2013].

[10] Oracle Corp., „Oracle VM VirtualBox,” [Interactiv]. Available: https://www.virtualbox.org/. [Accesat August 2013].

[11] KVM, „Kernel Based Virtual Machine,” [Interactiv]. Available: http://www.linux-kvm.org. [Accesat August 2013].

[12] Microsoft Corp., „Microsoft Hyper-V Server 2012 - Virtualization,” [Interactiv]. Available: http://www.microsoft.com/hyper-v-server. [Accesat August 2013].

[13] L. Richardson și S. Ruby, RESTful web service, Sebastopol: O'Reilly Media, Inc, 2008.

[14] L. Wang, J. Tao, M. Kunze, A. C. Castellanos, D. Kramer și W. Karl, „Scientific cloud computing: Early definition and experience,” în 10th IEEE International Conference on High Performance Computing and Communications (HPCC'08), 2008.

[15] T. O'Reilly, „What Is Web 2.0,” 30 September 2005. [Interactiv]. Available: http://oreilly.com/web2/archive/what-is-web-20.html. [Accesat August 2013].

[16] L. Smith și I. Lipner, „Free Pool of IPv4 Address Space Depleted,” Number Resource Organization, Montevideo, 2011.

[17] C. G. Cernat, V. A. Poenaru și G. Suciu, „Multimedia content distribution between core network routers using Peer-to-Peer (P2P),” în 19th Telecommunications Forum, TELFOR, Belgrade, 2011.

[18] I. Stoica, R. Morris, D. Liben-Nowell, D. R. Karger și M. F. Kaashoek, „Chord: a scalable peer-to-peer lookup protocol for internet applications,” IEEE/ACM Transactions on Networking, vol. 11, nr. 1, pp. 17-32, 2003.

[19] S. Agarwal, „A case study of large scale P2P video multicast,” în International Conference on IP Multimedia Subsystem Architecture

and Applications, Bangalore, 2007.

[20] J. Li, J. Stribling, T. M. Gil, R. Morris și M. F. Kaashoek, „Comparing the performance of distributed hash tables under churn,” în Peer-to-Peer Systems III - Lecture Notes in Computer Science Volume 3279, Berlin, Springer Berlin Heidelberg, 2005, pp. 87-99.

[21] R. S. R. Ku, „The creative destruction of copyright: Napster and the new economics of digital technology,” The University of Chicago

Law Review , vol. 69, nr. 1, pp. 263-324, 2002.

[22] K. Walsh și E. G. Sirer, „Experience with an object reputation system for peer-topeer filesharing,” în Proc. 3rd Symp. on Networked

Systems Design and Implementation, 2006.

[23] NIST, „National Institute of Standards and Technology,” [Interactiv]. Available: www.nist.gov. [Accesat August 2013].

[24] P. Mell și T. Grance, „The NIST Definition of Cloud Computing - Recommendations of the National Institute of Standards and Technology,” NIST, Gaithersburg, 2011.

[25] A. Marinos și G. Briscoe, „Community cloud computing,” în Cloud Computing - Lecture Notes in Computer Science Volume 5931, Berlin, Springer Berlin Heidelberg, 2009, pp. 472-484.

[26] E. G. Ularu, F. C. Puican, G. Suciu, A. Vulpe și G. Todoran, „Mobile Computing and Cloud maturity - Introducing Machine Learning for ERP Configuration Automation,” Informatica Economică, vol. 17, nr. 1, pp. 40-52, 2013.

[27] CSA, „Cloud Security Alliance,” [Interactiv]. Available: https://cloudsecurityalliance.org. [Accesat August 2013].

[28] D. Kusic, J. O. Kephart, J. E. Hanson, N. Kandasamy și G. Jiang, „Power and performance management of virtualized computing environments via lookahead control,” Cluster computing, vol. 12, nr. 1, pp. 1-15, 2009.

[29] R. Buyya, C. S. Yeo, S. Venugopal, J. Broberg și I. Brandic, „Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5th utility,” Future Generation computer systems, vol. 25, nr. 6, pp. 599-616, 2009.

[30] M. Stokely, J. Winget, E. Keyes, C. Grimes și B. Yolken, „Using a market economy to provision compute resources across planet-wide clusters,” în IEEE International Symposium on Parallel & Distributed Processing, IPDPS, Rome, 2009.

[31] H. C. Lim, S. Babu, J. S. Chase și S. S. Parekh, „Automated control in cloud computing: challenges and opportunities,” în Proceedings of the 1st workshop on Automated control for datacenters and clouds, ACM, New York, 2009.

[32] S. P. Boyd și L. Vandenberghe, Convex optimization, Cambridge: Cambridge university press, 2004.

[33] C. Y. Tu, W. C. Kuo, W. H. Teng, Y. T. Wang și S. Shiau, „A power-aware cloud architecture with smart metering,” în 39th International Conference on Parallel Processing Workshops (ICPPW), San Diego, 2010.

[34] K. Appleby, S. Fakhouri, L. Fong, G. Goldszmidt și M. Kalantar, „Oceano-SLA based management of a computing utility,” în International Symposium on Integrated Network Management Proceedings, IEEE/IFIP , Seattle, 2001.

[35] F. Fargo, C. Tunc, Y. Al-Nashif și S. Hariri, „Autonomic performance-per-watt management (APM) of cloud resources and services,” în Proceedings of the 2013 ACM Cloud and Autonomic Computing Conference, 2013.


42

[36] Z. Han, D. Niyato, W. Saad, T. Basar și A. Hjorungnes, Game theory in wireless and communication networks, Cambridge University Press, 2012.

[37] V. Litoiu, A. Badica și C. Etegan, „Intelligent Agents in E-Commerce,” Revista Informatica Economică, vol. 3, nr. 39, pp. 64-68, 2006.

[38] P. Cramton, Y. Shoham și R. Steinberg, Combinatorial Auctions, MIT Press, 2006.

[39] P. Stingley, „Cloud architecture,” [Interactiv]. Available: http://sites.google.com/site/cloudarchitecture/. [Accesat August 2013].

[40] M. N. K. Boulos, B. Resch, D. N. Crowley și J. G. Breslin, „Crowdsourcing, citizen sensing and sensor web technologies for public and environmental health surveillance and crisis management: trends, OGC standards and application examples,” journal of health

geographics, vol. 10, nr. 67, pp. 1-29, 2011.

[41] B. Chihani, E. Bertin și N. Crespi, „Enhancing M2M communication with cloud-based context management,” în IEEE 6th International Conference on Next Generation Mobile Applications, Services and Technologies (NGMAST).

[42] B. Chihani, E. Bertin, I. S. Suprapto, J. Zimmermann și N. Crespi, „Enhancing Existing Communication Services with Context Awareness,” Journal of Computer Networks and Communications, 2012.

[43] S. Islam, K. Lee, A. Fekete și A. Liu, „How a consumer can measure elasticity for cloud platforms,” în Proceedings of the third joint

WOSP/SIPEW international conference on Performance Engineering, ACM, Boston, 2012.

[44] H. S. Abdelsalam, K. Maly, R. Mukkamala, M. Zubair și D. Kaminsky, „Analysis of energy efficiency in clouds,” în Future Computing, Service Computation, Cognitive, Adaptive, Content, Patterns - Computation World, IEEE, Athens, 2009.

[45] H. Casanova, A. Legrand și M. Quinson, „Simgrid: A generic framework for large-scale distributed experiments,” în Tenth

International Conference on Computer Modeling and Simulation, UKSIM 2008., Cambridge, 2008.

[46] D. Kliazovich, P. Bouvry și S. U. Khan, „GreenCloud: a packet-level simulator of energy-aware cloud computing data centers,” The

Journal of Supercomputing, vol. 62, nr. 3, pp. 1263-1283, 2013.

[47] S. H. Lim, B. Sharma, G. Nam, E. K. Kim și C. R. Das, „MDCSim: A multi-tier data center simulation, platform,” în IEEE International Conference on Cluster Computing and Workshops, CLUSTER'09., New Orleans, 2009.

[48] A. Núñez, J. L. Vázquez-Poletti, A. C. Caminero, G. G. Castañé, J. Carretero și I. M. Llorente, „iCanCloud: A flexible and scalable cloud infrastructure simulator,” Journal of Grid Computing , vol. 10, nr. 1, pp. 185-209, 2012.

[49] S. K. Gupta, R. R. Gilbert, A. Banerjee, Z. Abbasi, T. Mukherjee și G. Varsamopoulos, „GDCSim: A tool for analyzing green data center design and resource management techniques,” în International Green Computing Conference and Workshops (IGCC), Orlando, 2011.

[50] M. Tighe, G. Keller, M. Bauer și H. Lutfiyya, „DCSim: A data centre simulation tool for evaluating dynamic virtualized resource management,” în 8th International Conference on Network and Service Management (CNSM), IEEE, Las Vegas, 2012.

[51] R. N. Calheiros, R. Ranjan, A. Beloglazov, C. A. De Rose și R. Buyya, „CloudSim: A Toolkit for Modeling and Simulation of Cloud Computing Environments and Evaluation of Resource Provisioning Algorithms,” Software: Practice and Experience , vol. 41, nr. 1, pp. 23-50, 2011.

[52] F. Fittkau, S. Frey și W. Hasselbring, „CDOSim: Simulating cloud deployment options for software migration support,” în 6th

International Workshop on Maintenance and Evolution of Service-Oriented and Cloud-Based Systems (MESOCA), IEEE , Trnto, 2012.

[53] Y. Z. Jararweh, M. Jarrah, M. Kharbutli și M. Alsaleh, „Teachcloud: a cloud computing educational toolkit,” în Proceedings of the 1st International IBM Cloud Academy Conference (ICA CON 2012), North Carolina, 2012.

[54] S. K. Garg și R. Buyya, „NetworkCloudSim: modelling parallel applications in cloud simulations,” în Fourth IEEE International

Conference on Utility and Cloud Computing (UCC), Victoria, 2011.

[55] J. Miguel-Alonso, J. Navaridas și F. J. Ridruejo, „Interconnection network simulation using traces of MPI applications,” International

Journal of Parallel Programming, vol. 37, nr. 2, pp. 153-174, 2009.

[56] Amazon Web Services Inc., „Amazon Web Services (AWS),” [Interactiv]. Available: http://aws.amazon.com/. [Accesat August 2013].

[57] Amazon Web Services (AWS), „Amazon Elastic Compute Cloud (Amazon EC2),” [Interactiv]. Available: http://aws.amazon.com/ec2/. [Accesat August 2013].

[58] Amazon Web Services (AWS), „Amazon Simple Storage Service (Amazon S3),” [Interactiv]. Available: http://aws.amazon.com/s3/. [Accesat August 2013].

[59] Google Inc., „Google App Engine,” [Interactiv]. Available: https://developers.google.com/appengine. [Accesat August 2013].

[60] Google Inc., „Google Cloud Platform,” [Interactiv]. Available: https://developers.google.com/cloud/. [Accesat August 2013].

[61] Microsoft Corp., „Windows Azure: Microsoft's Cloud Platform,” [Interactiv]. Available: http://www.windowsazure.com. [Accesat August 2013].

[62] Microsoft Corp., „Cloud services you can trust: Office 365 availability,” [Interactiv]. Available: http://blogs.office.com/b/office365tech/archive/2013/08/08/cloud-services-you-can-trust-office-365-availability.aspx. [Accesat August 2013].

[63] B. Calder, J. Wang, A. Ogus, N. Nilakantan, A. Skjolsvold, S. McKelvie și Y. Xu, „Windows Azure Storage: a highly available cloud storage service with strong consistency,” în Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles, ACM, Cascais, 2011.

[64] OpenStack Project, „Open Source Cloud Computing Software,” [Interactiv]. Available: http://www.openstack.org/. [Accesat August 2013].

[65] The Apache Software Foundation, „Apache CloudStack™ - Open Source Cloud Computing™,” [Interactiv]. Available: http://cloudstack.apache.org/. [Accesat August 2013].

[66] Eucalyptus Systems, Inc, „Open Source AWS Compatible Private Clouds,” [Interactiv]. Available: http://www.eucalyptus.com/. [Accesat August 2013].

[67] OpenNebula Project, „Flexible Enterprise Cloud Made Simple,” [Interactiv]. Available: http://www.opennebula.org. [Accesat August 2013].

[68] University of Chicago, „Nimbus - cloud computing for science,” [Interactiv]. Available: http://www.nimbusproject.org/. [Accesat August 2013].

[69] A. I. Avetisyan, R. Campbell, I. Gupta, M. T. Heath, S. Y. Ko, G. R. Ganger și M. A. Kozuch, „Open cirrus: A global cloud computing testbed,” Computer, IEEE Computer Society, vol. 43, nr. 4, pp. 35-43, 2010.


43

[70] Vifib, „SlapOS - decentralized Cloud Computing technology,” [Interactiv]. Available: https://www.slapos.org/. [Accesat August 2013].

[71] Agendaless Consulting and Contributors, „Supervisor: A Process Control System,” [Interactiv]. Available: http://supervisord.org. [Accesat August 2013].

[72] J. P. Smets, „Beyond Clouds: Open Source Edge Computing in Python with SlapOS,” în EuroPython Conference, Florence, 2012.

[73] C. H. Swaroop, A Byte of Python, 2013.

[74] SlapOS Team, „SlapOS Economic Rationale,” SlapOS R&D, Paris, 2012.

[75] J. P. Smets-Solanes și R. Atem de Carvalho, „ERP5: a next-generation, open-source ERP architecture,” IT professional , vol. 5, nr. 4, pp. 38-44, 2003.

[76] R. M. Monnerat, R. A. de Carvalho și R. de Campos, „Enterprise systems modeling: the ERP5 development process,” în Proceedings of the 2008 ACM symposium on Applied computing, ACM, 2008.

[77] R. A. de Carvalho, R. de Campos și R. M. Monnerat, „Quality Assurance in the ERP5 Development Process,” Research and Practical

Issues of Enterprise Information Systems, Springer, vol. 1, nr. 2, pp. 677-687, 2008.

[78] Zope Foundation, „Buildout - software build system reloaded,” [Interactiv]. Available: http://www.buildout.org. [Accesat August 2013].

[79] M. Trojnara, „Stunnel universal SSL wrapper,” [Interactiv]. Available: https://www.stunnel.org. [Accesat August 2013].

PUBLICAȚII PROPRII

[1] G. Suciu, O. Fratu, S. Halunga, et.al. „Cloud Consulting: ERP and Communication Application Integration in Open Source Cloud Systems”, 19th Telecommunications Forum - TELFOR 2011, IEEE Communications Society, ISBN 978-1-4577-1499-3, Belgrade, Serbia, 22-24 Nov. 2011, pp. 578-581. (IEEEXplore)

[2] C.G. Cristian, V. A. Poenaru, G. Suciu, „Multimedia content distribution between core network routers using Peer-to-Peer (P2P)”,19th Telecommunications Forum - TELFOR 2011, IEEE Communications Society, ISBN 978-1-4577-1499-3, Belgrade, Serbia, 22-24 Nov. 2011, pp. 254-257 (IEEEXplore)

[3] G. Suciu, S. Halunga, “Cloud Collaboration - Platform for online collaboration in open source distributed cloud systems”, Proceedings of Second International Students Conference on Informatics - Imagination, Creativity, Design, Development (ICDD 2012), ISSN 2069-964X, 26 - 28 April 2012, Sibiu, Romania, pp. 179-187.

[4] G. Suciu, V. A. Poenaru, C. G. Cernat, G. Todoran, L. Militaru “ERP and e-business application deployment in open source distributed cloud systems”, The 11th International Conference on Informatics in Economy (IE 2012), Bucharest University of

Economic Studies Press, ISSN 2284-747, București, Romania, 10-11 May 2012, pp. 12-17 (ISI Thomson) [5] L. Militaru, G. Suciu, G. Todoran “The evaluation of the e-learning applications’ quality”, The 11th International Conference on

Informatics in Economy (IE 2012)”, Bucharest University of Economic Studies Press, ISSN 2284-747, București, Romania, 10-11 May 2012, pp. 373-377 (ISI Thomson)

[6] G. Suciu, V. Poenaru, C. Cernat, L. Militaru, G. Todoran "A Study of Security in Open Source Cloud Platforms". “Proceedings of the

5th International Conference on Security for Information Technology and Communications (SECITC 2012)”, Bucureşti, Romania, 31 May - 1 June 2012, pp. 125-130.

[7] G. Suciu, C. Cernat, G. Todoran, V. Suciu, V. Poenaru, L. Militaru, S. Halunga, “A solution for implementing resilience in open source Cloud platforms”, Proceedings of 2012 9th International Conference on Communications (COMM)”, IEEE Communications

Society, București, Romania, 21-23 Jun. 2012, Ed. Curran Associates, Inc., New York, 2012, pp. 335-338 (ISI Thomson, IEEEXplore)

[8] C. G. Cristian, V. A. Poenaru, and G. Suciu, ”Metric model for IPTV video streaming services distribution in content aware networks”, Proceedings of 2012 9th International Conference on Communications (COMM)”, IEEE Communications Society, București, Romania, 21-23 Jun. 2012, Ed. Curran Associates, Inc., New York, 2012, pp. 285-288 (ISI Thomson, IEEEXplore)

[9] G. Suciu, O. Fratu, et.al. “Cloud systems for environmental telemetry - A case study for ecological monitoring in agriculture”, XLVII

International Scientific Conference on Information, Communication and Energy Systems and Technologies, ICEST 2012, Proceedings of Papers, Vol. 1”(online), Ed. Faculty of Telecommunications, Technical University of Sofia, Veliko Tarnovo, Bulgaria, 28-30 Jun. 2012, pp. 273-276.

[10] V.A. Poenaru, G. Suciu, C.G. Cernat, G. Todoran, L. Militaru “Attacking the cloud”. “XLVII International Scientific Conference on Information, Communication and Energy Systems and Technologies - ICEST 2012, Proceedings of Papers, Vol. 1”(online), Ed.

Faculty of Telecommunications, Technical University of Sofia, Veliko Tarnovo, Bulgaria, 28-30 Jun. 2012, pp. 175-177. [11] G. Suciu, C. G. Cernat, and G. Todoran, “Cloud Research - Implementing Scientific Research Information Systems in Open Source

Cloud Platforms”, Fifth Romania Tier 2 Federation "Grid, Cloud & High Performance Computing Science", RO-LCG 2012, IEEE,

ISBN: 978-1-4673-2242-3, Cluj-Napoca, Romania, 25-27 Oct. 2012, pp. 31-34 (ISI Thomson, IEEEXplore) [12] L. Militaru, G. Suciu, G. Todoran “The Evaluation of the e-Learning Applications’ Quality”, 54th International Symposium -

Proceedings ELMAR 2012, Croatian Society Electronics in Marine, IEEE Communications Society, Zadar, Croatia, 12-14 Sep. 2012, pp. 165-170 (IEEEXplore)

[13] G. Suciu, L. Militaru, C.G. Cernat, V.A. Poenaru “Platform for online collaboration and elearning in open source distributed cloud systems”, 54th International Symposium - Proceedings ELMAR 2012”, Croatian Society Electronics in Marine, IEEE

Communications Society, Zagreb, 12-14 Sep. 2012, pp. 337-340 (ISI Thomson, IEEEXplore) [14] G. Suciu, R. Cheveresan, M. Cealera, G. Todoran, “Sisteme informatice Open Source pentru gestiunea companiilor din domeniul

energetic”, Simpozionul National de Informatica, Automatizari si Telecomunicatii in Energie, SIE2012, Sinaia, Romania, 24 - 26 Oct. 2012, pp. 1-4.

[15] G. Suciu, L. Militaru, G. Todoran “ERP and E-Business Application Deployment in Open Source Distributed Cloud Systems”. “Database Systems Journal - DBJournal”, Vol. III, No. 3 / 2012 (online), Editura ASE, București, 2012, pp. 3-12, indexat BDI (Google Scholar, RePEc)

[16] L. Militaru, G. Suciu, G. Todoran “The Use of Automated Software Tools in Evaluating an e-Learning Platform Quality”. “Journal of

Mobile, Embedded and Distributed Systems - JMEDS”, Vol. 4, No. 3, 2012 (online), pp. 150-158, indexat BDI (Google Scholar, IndexCopernicus)


44

[17] G. Suciu, V. Poenaru, C.Cernat, L. Militaru, G. Todoran “A Study of Implementing an Information Security Management System for Open Source Cloud Computing”. “Journal of Mobile, Embedded and Distributed Systems - JMEDS”, Vol. 4, No. 3, 2012 (online), pp. 168-174, indexat BDI (Google Scholar, IndexCopernicus)

[18] L. Militaru, G. Suciu, G. Todoran “The use of expert systems in evaluating the quality of universities websites”.“Asigurarea calităţii”, numărul 72, vol. XVIII (2012), Editura Tehnică, București, Oct. 2012, pp. 19-25.

[19] G. Suciu, L. Militaru, G. Todoran “Cloud systems for monitoring environmental parameters - Case study for telemetry of nuclear weapon radiation”, Proceedings of UN Youth Student Conference on International Relations, Security and Economy” (online), 26 - 28 Oct. 2012, pp. 1-12.

[20] G. Suciu, V. A. Poenaru, L. Nae , A. Florescu , L. Militaru, G. Todoran “Data mining in distributed cloud systems - an open source test platform for automated ERP configurations”.“Scientific Bulletins of Politehnica University”(propus spre publicare)

[21] L. Militaru, G. Suciu, G. Todoran “The use of expert systems in building the quality model of a web-based learning platform”, 11th

International Conference Advances in Web-Based Learning – ICWL 2012”, Ed. seria “Lecture Notes in Computer Science”, vol.

7558, Springer, Heidelberg, ISBN 978-3-642-33641-6, Sinaia, Romania, 2-4 Sep. 2012, pp. 318-327, indexat BDI (Google Scholar) [22] L. Militaru, G. Suciu, G. Todoran ”The use of expert systems in designing the quality evaluation of an e-learning platform”.

“Proceedings of The International Conference INnovation and Collaboration in Engineering Research (INCER) 2012” (online),

Universitatea Politehnica din Bucureşti, 2-4 Jul. 2012 [23] L. Militaru, G. Suciu, et.al. “Rule based expert systems running over the cloud”. “Proceedings of The International Conference

‘INnovation and Collaboration in Engineering Research’ (INCER) 2012” (online), Universitatea Politehnica din Bucureşti, 2-4 Jul. 2012

[24] G. Suciu, L. Militaru, G. Todoran “Data Mining in Distributed Cloud Systems - An open source test platform for automated ERP configurations”. “Proceedings of The International Conference ‘INnovation and Collaboration in Engineering Research’ (INCER)

2012” (online), Universitatea Politehnica din Bucuresti, 2-4 Jul. 2012. [25] L. Militaru, G. Suciu, G. Todoran, “The use of expert systems in designing the quality evaluation of an e-learning platform”.

“Proceedings of the 2012 Fourth International Conference on INtelligent Networking and COllaborative Systems - INCOS”

(electronic), Universitatea Politehnica din Bucureşti, IEEE Computer Society, Bucharest, Romania,19-21 Sep. 2012, pp. 495-496 (IEEEXplore)

[26] L. Militaru, G. Suciu, G. Todoran “Rule based expert systems over cloud”. “Volumul Simpozionului Studenţesc de Electronică și

Telecomunicaţii, ediţia a VIII-a”(electronic), Universitatea Tehnică din Cluj-Napoca, 2012. [27] G. Suciu, L. Militaru, G. Todoran “Cloud e-Business – A Case Study for ERP Application Deployment in Open Source Distributed

Cloud Systems”. “Volumul Simpozionului Studenţesc de Electronică și Telecomunicaţii, ediţia a VIII-a”(electronic), Universitatea

Tehnică din Cluj-Napoca, 2012. [28] J. Cropotova, G. Suciu, “A novel approach to the monitoring of agri-food supply chain through Cloud Computing in developing

countries”, 1-st Conference «Physics for Development», Brussels, Belgium, 11-12 Oct. 2012, pp. 1-4. [29] G. Suciu, E. G. Ularu, R. Craciunescu „Public versus Private Cloud Adoption – a Case Study based on Open Source Cloud

Platforms”, 20th Telecommunications Forum - TELFOR 2012, IEEE Communications Society, ISBN 978-1-4673-2983-5 , Belgrade, Serbia, 20-22 Nov. 2012, pp. 494 – 497. (ISI Thomson, IEEEXplore)

[30] G. Suciu, S. Halunga, “Cloud Content Distribution Networks for DVB Applications”, Constanța Maritime University Annals, vol. 13, no. 18 (online), ISSN: 1582-3601, Dec. 2012, pp. 205-208, indexat BDI (Google Scholar)

[31] E.G. Ularu, F.C. Puican, G. Suciu, A. Vulpe, G. Todoran, ”Mobile Computing and Cloud maturity - Introducing Machine Learning for ERP Configuration Automation”, Informatica Economică, vol. 17, no. 1 (online), doi: 10.12948/issn14531305/17.1.2013.04, Jan. 2013, pp. 40-52, indexat BDI (Google Scholar, IndexCopernicus, INSPEC, RePEc, CNCSIS B+)

[32] E.G. Ularu, F.C. Puican, A. Apostu, G. Suciu, A. Vulpe, ”Analytical Databases for the Cloud and Virtualization”, 12th International

Conference on Informatics in Economy (IE 2013), ISSN 2284-7472, Bucharest, Romania, 25-28 Apr. 2013, pp. 337-341 (ISI Thomson)

[33] A. Apostu, F. Puican, G. Ularu, G. Suciu, G. Todoran, “Study on advantages and disadvantages of Cloud Computing – the advantages of Telemetry Applications in the Cloud”, 13th International Conference on Applied Computer Science (ACS13) - Recent Advances in Applied Computer Science and Digital Services, 978-1-61804-179-1, Morioka City, Iwate, Japan, 23-25Apr. 2013, pp. 118-123, indexat BDI (Google Scholar)

[34] A. Apostu, F. Puican, G. Ularu, G. Suciu, G. Todoran, “New classes of applications in the Cloud. Evaluation of advantages and disadvantages of Cloud Computing for Telemetry Applications”, International Journal of Computers and Communications (online), 2013, pp. 1-6, indexat BDI (Google Scholar)

[35] G. Suciu, A. Vulpe, S. Halunga, O. Fratu, G. Todoran, V. Suciu, “Smart Cities Built on Resilient Cloud Computing and Secure Internet of Things”, 19th International Conference on Control Systems and Computer Science (CSCS), IEEE, ISBN 978-0-7695-4980-4, Bucharest, Romania, 25-28 May 2013, pp. 513-518 (IEEEXplore)

[36] G. Suciu, A. Vulpe, G. Todoran, G.; Cropotova, J.; Suciu, V., “Cloud Computing and Internet of Things for Smart City Deployments”, 7th International Conference Challenges of the Knowledge Society (CKS 2013), ISSN 2068-7796, Bucharest, Romania, 17-18 May 2013, pp. 1409-1416 (Index Copernicus Journals Master List ICV 3.86)

[37] G. Suciu, S. Halunga, O. Fratu, A. Vasilescu, V. Suciu, “Study for Renewable Energy Telemetry using a Decentralized Cloud M2M System”, 15th International Symposium on Wireless Personal Multimedia Communications (WPMC), IEEE, ISBN 978-87-92982-52-0, Atlantic City, SUA, 24-28 Jun. 2013, pp. 1-5 (IEEEXplore)

[38] G. Suciu, S. Halunga, A. Vulpe, V. Suciu, "Generic Platform for IoT and Cloud Computing Interoperability Study", 2013 11th

International Symposium on Signals, Circuits and Systems (ISSCS), ISBN 978-1-4673-6143-9, Iasi, Romania, 10-12 Jul 2013, pp.1-4 (IEEEXplore)

[39] A. Apostu, G. Suciu, A. Ochian, A. Vulpe, „Cloud Computing as a key enabler for pricing optimization in Small and Medium Sized Enterprises,” 6th International Conference “Small and Medium Sized Enterprises in a Globalized World”, ISBN 978-606-526-155-6, Cluj-Napoca, 25-28 Sept. 2013, pp. 231-241.

[40] G. Suciu, ”Cloud Communication Applications”, invited presentation, CTiF PhD Meeting, Aalborg University, Denmark, 4 Nov. 2013.

[41] G. Suciu, A. Vulpe, ”Cloud, Big Data and M2M/IoT for Smart Data in 4G Networks”, ICT 2013, Vilnius, 6-8 Nov. 2013. [42] G. Suciu, G. Todoran, ”Cloud M2M Platform For Renewable Energy Tele-Monitoring”, Scientific Bulletin UPB, nr. special, seria C,

2013 (propus spre publicare) [43] G. Suciu, G. Todoran, A. Apostu, F. C. Puican, G. Ularu ”Mobile Cloud for Telemetry Applications”, Acceptat Journal of Electrical

Engineering and Computer Science, ISSN 0013-5852, Ljubljana, Slovenia, 2013, indexat BDI (INSPEC, COMPENDEX) [44] G. Suciu, C. Voicu, G. Todoran, A. Martian, S. Halunga, C. Butca, ”Network Cloud Simulator for Modelling Trust in Cognitive

Radio Applications”, Acceptat 21st Telecommunications Forum TELFOR, IEEE, 2013 (IEEEXplore)

TEZĂ DE DOCTORAT - mobcomm.pub.ro · Teza de doctorat își propune să analizeze metode de...

Documents

Transcript of TEZĂ DE DOCTORAT - mobcomm.pub.ro · Teza de doctorat își propune să analizeze metode de...