Calcul Cloud Descentralizat

Rezumatul Tezei

Orchestration Service

Cloud 1

PUBLIC BLOCKCHAIN

Physical Resources

Hypervisor Layer

OpenStack Marathon Bare Metal

Registry

Cloud 2 Cloud 3

Cloud1 Cloud2 Cloud3App1 App2 App3

SOSM SOSM SOSM

Gateway Service

OrchestratorUIService

OptimizationEngine

ComponentAdministration

Network

PnP PnP PnP

Cuvinte cheie: Sisteme distribuite, Orchestrarea Serviciilor Cloud, Blockchain,Contracte Inteligente

Florin-Adrian Spataru

Timisoara si Pisa

2021

Cuprins

1 Introducere 1

2 Context 3

2.1 Calcul Cloud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Sisteme Peer-to-peer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 Registre Distribuite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Serviciul Gateway 6

3.1 Motorul de optimizare a serviciilor . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2 Interfat,a utilizator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 Experient,a utilizatorului . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Auto-organizare s, i auto-administrare ın managementul resurselor 11

4.1 Sistemul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4.2 Strategii de formare a Coalit, iilor . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 Evaluare experimentala asupra sistemului CloudLightning 15

6 Planificarea resurselor folosind contracte inteligente Ethereum 17

6.1 Metode de planificare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

6.2 Evaluare experimentala . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

6.3 Discut, ii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

7 Cloud descentralizat rezistent la defect, iuni 21

7.1 Ret,ele de administrare a componentelor . . . . . . . . . . . . . . . . . . . . . . . 22

7.2 Orchestrare rezistenta la defect, iuni . . . . . . . . . . . . . . . . . . . . . . . . . . 23

7.3 Discut, ii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

8 Concluzii 26

i

ii

Capitolul 1

Introducere

La ınceputurile internetului cercetatorii au intuit conectarea sistemelor de calcul ıntr-o ret,eapeer to peer, unde fiecare este capabil sa-s, i faca cont, inutul accesibil de catre ceilalt, i fara prezent,aunui server centralizat. Des, i acest lucru ramane valabil, majoritatea serviciilor prezente ıninternetul de astazi sunt concepute ca aplicat, ii centralizate, care stocheaza s, i proceseaza cantitat, iimpresionante de date ın centre de calcul de dimensiunea depozitelor de marfa. Acest lucru afost avansat de domeniul calculului Cloud, unde resursele din centre de date mari sunt ınchiriateutilizatorilor. Furnizorii de servicii Cloud sunt ın general considerat, i actori de ıncredere careofera mecanisme de asigurare a calitat, ii serviciului.

In acest context, sistemele peer-to-peer au continuat sa fie utilizate pentru servicii de parta-jare de fis, iere s, i aplicat, ii de calcul voluntar. Mai mult, domeniul Internet of Things a introduso nevoie de infrastructura de stocare s, i de calcul care trebuie sa fie aproape de dispozitivelede la marginea ret,elei. Utilizarea unei ret,ele peer to peer pentru a acoperi aceste nevoi poateajuta senzorii s, i dispozitivele sa acceseze resursele de calcul s, i de stocare mai aproape de locat, ialor. Acest lucru reduce congestia ret,elei daca datele sunt transmise aproape de sursa pentrupreprocesare, mai degraba decat trimiterea lor direct ın cloud. In plus, o astfel de solut, ie poateoferi o rentabilitate economica proprietarului infrastructurii care gazduies,te astfel de servicii.

Aparit, ia tehnologiilor Blockchain, cum ar fi BitCoin [15] s, i Ethereum [4], a generat stimulieconomici pentru participarea ıntr-o ret,ea de calculatoare distribuita la nivel global. Blockchain-urile construiesc un registru public, imutabil, de tranzact, ii care serves,te doua scopuri principale:transparent, a s, i auditabilitate. Ret,eaua Ethereum este formata din peste 25, 000 noduri carecolaboreaza pentru a stoca s, i actualiza mas, ina virtuala Ethereum - un automat finit replicatglobal, capabil sa execute instruct, iuni arbitrare asamblate ıntr-un contract inteligent (eng.Smart Contract). Automatul finit este actualizat prin tranzact, ii care sunt organizate ın blocuripe un Blockchain. Acest lucru necesita ca fiecare nod care participa la ret,ea sa execute toatetranzact, iile dintr-un bloc la nivel local, ceea ce scade performant,a sistemului. Avantajul este cafiecare nod poate accesa starea automatului local.

Un Blockchain nu poate fi utilizat ca mijloc de stocare a unor cantitat, i mari de date, ci maidegraba pentru a stoca informat, iile strict necesare pentru a asigura logica aplicat, iei. Chiar dacaparadigma Blockchain ofera un mecanism descentralizat pentru avansarea starii sale, utilizatoriitrebuie sa se bazeze pe componente externe pentru a crea o aplicat, ie descentralizata, de cele maimulte ori alegand o solut, ie Cloud. Putem observa nevoia pentru o piat, a libera pentru furnizareastocarii s, i puterii de calcul necesare pentru a crea o aplicat, ie complet descentralizata.

Aceasta teza propune o platforma Cloud descentralizata, unde instant,ele mas, inilor virtuale,containerele s, i acceleratoarele precum unitat, ile de procesare grafica (GPU, eng. Graphuc Pro-cessing Unit), unitat, i cu multiple nuclee integrate (MIC, eng. Many Integrated Cores) sau proce-soarele de flux de date (DFE, eng. Data Flow Engines) pot fi furnizate dintr-o ret,ea peer-to-peerutilizand contracte inteligente pe un Blockchain public. Aceasta platforma este implementata

1

2 CAPITOLUL 1. INTRODUCERE

folosind tehnologii open-source pentru orchestrarea serviciilor Cloud, proiectand un mecanismdescentralizat de select, ie a resurselor s, i protocoale pentru planificarea acestora. Software-ul deochestrare ofera facilitat, i pentru definirea s, i executarea serviciilor care au dependint,e legate deinfrastructura s, i disponibilitatea altor servicii.

Mecanismul descentralizat de atribuire a resurselor este facilitat de un contract inteligentpe un blockchain public s, i un sistem de gestionare a resurselor auto-organizat. Contractulinteligent expune operat, iuni pentru ınregistrarea/detas,area nodurilor de calcul s, i pentru creareacontractelor de aplicat, ie. Pentru ınceput, inspectam constrangerile operat, ionale s, i costurileasociate cu externalizarea logicii de select, ie catre Contractul inteligent. Apoi, concepem unmecanism de select, ie care are loc ın afara Contractului inteligent, care accepta o atribuire bazatape promisiunile de rezervare a resurselor semnate de managerul de resurse.

Principalele contribut, ii ale acestei teze sunt:1. Implementarea Gateway Service, care grupeaza mai multe componente care permit definirea,

compozit, ia, optimizarea s, i executarea serviciilor Cloud care utilizeaza infrastructura HPCprecum GPU-uri, MIC-uri sau DFE-uri. In plus, flexibilitatea furnizorului de serviciiCloud este ımbunatat, ita, permit, and utilizatorului sa proiecteze o aplicat, ie compusa dinservicii abstracte, pentru care se alege o implementare pe baza starii actuale a resurselorgestionate de Cloud.

2. Proiectarea unui mecanism de gestionare a resurselor care permite autoorganizarea com-ponentelor de management colaborativ. Acest mecanism de auto-organizare s, i auto-administrare (SOSM, eng. Self-Organizing Self-Managing) permite stabilirea s, i actu-alizarea obiectivelor globale care sunt transmise ın ierarhie, influent, and comportamentulcomponentelor subordonate pentru a se alinia obiectivului global. Sistemul este evaluatexperimental pentru a investiga implicat, iile procesului de optimizare a atribuirii resurselor.

3. Proiectarea unei platforme Cloud descentralizate care gestioneaza resurse private s, i asiguratolerant,a ın caz de defect, iune a unor servicii sau componente. Tolerant,a la defect, iuni acomponentelor este pusa ın aplicare printr-un concept nou, acela de ret,ea de administrarea componentelor (eng. Component Administration Network), care este responsabila demonitorizarea starii componentelor, atribuirea pachetelor de lucru s, i salvarea punctelor decontrol legate de activitatea lor. Tolerant,a la defect, iuni a serviciilor este gestionata de ocomponenta Orchestrator care salveaza puncte de control legate de starea serviciilor.

Teza este organizata dupa cum urmeaza. Capitolul 2 prezinta un sondaj al literaturii legatede serviciile Cloud, ret,elele Peer to Peer, protocoalele de consens s, i tehnologia Blockchain.Sect, iunea 2.3 prezinta efortul ın aceeas, i direct, ie ca s, i teza noastra.

Capitolul 3 prezinta componentele serviciului Gateway s, i ofera o comparat, ie cu abordarileactuale pentru furnizarea serviciilor Cloud. Capitolul 4 prezinta mecanismul SOSM s, i douametode predictive pentru a crea coalit, ii de resurse care pot fi utilizate pentru a us,ura procesul deselect, ie a resurselor. Capitolul 5 prezinta o evaluare experimentala a sistemului CloudLightningla scara mica.

Capitolul 6 investigheaza constrangerile operat, ionale asociate cu externalizarea mecanismuluide selectare a resurselor catre un contract inteligent. Acesta ofera atat o analiza statica acostului, cat s, i o analiza dinamica a costurilor s, i a latent,ei, utilizand acelas, i set de date opensource. Capitolul 7 defines,te o platforma Cloud descentralizata, toleranta la defect, iuni, pebaza rezultatelor capitolului anterior. Acesta defines,te conceptul de ret,ele de administrare acomponentelor s, i prezinta protocoale pentru aderarea s, i monitorizarea ret,elei s, i componentelorcare sunt gestionate de ret,ea. In cele din urma, concluziile sunt prezentate ın Capitolul 8.

Capitolul 2

Context

Acest capitol prezinta tehnologiile s, i literatura de specialitate ın stransa legatura cu aceastateza. In primul rand, prezinta paradigma Cloud Computing s, i sistemele Peer to Peer care oferafunct, ionalitat, i similare, fara garant, iile oferite de Cloud. Domeniul registrelor distribuite (eng.Distributed Ledger) este analizat ın cautarea unui mecanism de consens care sa poata fi utilizatpentru validarea s, i securizarea unui set de operat, ii de care un sistem Cloud are nevoie pentru afunct, iona. In cele din urma, sunt prezentate eforturile care se deplaseaza ın aceeas, i direct, ie cateza de fat, a.

2.1 Calcul Cloud

NIST defines,te Cloud Computing ca un model care permite accesul la cerere, nelimitat s, iconvenabil, la un set de resurse de calcul configurabile (de exemplu, ret,ele, servere, unitat, ide stocare, aplicat, ii s, i servicii) care pot fi rapid furnizate s, i lansate cu efort minim de gestionaresau interact, iune cu furnizorul de servicii. [13].

Calculul Cloud a condus la progrese ın domeniul aplicat, iilor informatice, reducand timpulde lansare pe piat, a prin us,urint,a implementarii, gestionarii s, i reducerii costurilor. FurnizoriiCloud extind spectrul de capabilitat, i pe care le ofera, adaugand GPU-uri, MIC-uri, iar ınultima perioada circuite programabile (FPGA, eng. Field Programmable Gate Arrays). Cutoate acestea, aceste resurse sunt disponibile ın cea mai mare parte utilizatorilor experimentat, i,deoarece necesita o configurare complexa.

In Tabelul 2.1 prezentam facilitat, ile de calcul oferite de Furnizorii de Servicii Cloud (CSP,eng. Cloud Service Provider) pentru a fi integrate ın aplicat, iile client, ilor. Amazon Web Services(AWS), Google Compute s, i Microsoft Azure sunt lideri ın ceea ce prives,te numarul de client, i,infrastructura s, i varietatea de servicii.

Tabelul 2.1: Infrastructura de calcul disponibila ın Cloud

Tip Comun Detalii

Mas, inavirtuala

Foartecomuna

Mas, ina virtuala este cea mai comuna infrastructura de calcul,incluzand un sistem de operare separat decat gazda.

Container Comun Un proces care ruleaza izolat de alte procese care ruleaza pe aceeas, igazda.

GPU Comun GPU-urile pot fi atas,ate instant,elor de mas, ina virtuala sauContainerelor.

FPGA AWS AWS ofera un set de unelte pentru a scrie cod FPGA

Serverless Comun Paradigma de calcul Serverless permite utilizatorilor sa declans,ezecod ca raspuns la evenimente, fara inchirierea prealabila.

3

4 CAPITOLUL 2. CONTEXT

Docker [14] este o tehnologie care foloses,te nucleul Linux pentru a limita interact, iuneacu sistemul de operare. Opus mas, inilor virtuale, care includ un sistem de operare separat,Containerele sunt construite pe straturi care pot fi partajate de aplicat, ii similare. Kubernetes[3] este o platforma open-source de gestionare a containerelor oferita ca serviciu de majoritateafurnizorilor de Cloud. Mesos [11] este o tehnologie similara, dar nu ofera caracteristici deorchestrare, spre deosebire de Kubernetes.

2.2 Sisteme Peer-to-peer

Conceptul de Peer-to-Peer (P2P) a fost popularizat de serviciile de partajare a fis, ierelor, ıncepandcu Napster ın 1999. In general, o ret,ea peer-to-peer este compusa din noduri care joaca atatrolul de un client cat s, i rolul unui server, contribuind cu resursele acestora (stocare, lat, imede banda, calcul) la ret,ea. In Tabelul 2.2 enumeram mai multe aplicat, ii peer-to-peer s, i catevadintre scenariile lor de utilizare.

Tabelul 2.2: Aplicat, ii Peer-to-peer

Aplicat, ie Exemple Utilizare

Partajare defis, iere

Bittorrent,Gnutella,IPFS

Ret,ele pentru livrarea de cont,inut, distribuirea de pachete software

Anonimizare I2P, Tor Anonimizarea transmisiilor de date prin criptarea cont,inutului la fiecarepas din ret,ea

Ret,ele decalcul

BOINC[1],XtremWeb[8]

Partajarea voluntara resurselor de calcul pentru execut,ia experimentelors, tiint,ifice la scara larga.

Registre dis-tribuite

BitCoin,Ethereum,etc.

Evolut,ia monedelor virtuale ofera oricarui participant posibilitatea de aimpune ordinea tranzact,iilor (a mina un bloc) s, i de a-l adauga la registruldistribuit.

2.3 Registre Distribuite

Dezvoltarea algoritmilor pentru construirea de sisteme distribuite prin replicare ıncepe cu lu-crarea lui Lamport referitoare la acordul bizantin [12, 17], evolut, ia fiind bine rezumata ın [6].Problema obt, inerii consensului ıntr-un grup de noduri se poate baza pe doua part, i: (1) unautomat finit (determinist) care implementeaza logica serviciului care urmeaza sa fie replicat;s, i (2) un protocol de consens pentru a disemina cererile ıntre noduri, astfel ıncat fiecare nod saexecute aceeas, i secvent,a de cereri asupra instant,ei proprii a serviciului distribuit. [5]

Un Registru Distribuit este un automat finit care este replicat ıntr-o ret,ea de catre participant, i.Automatul finit avanseaza utilizand un Protocol de Consens, fara a fi nevoie de stocare saugestionare centralizata. Cel mai popular exemplu de registru distribuit este un Blockchain, undetranzact, iile sunt organizate ın blocuri care sunt ınlant,uite prin hashuri criptografice. Majoritateaimplementarilor Blockchain sunt legate de o moneda virtuala s, i permit doar transferul de bani s, i,eventual, un limbaj de scriptare simplu pentru a aborda operat, ii aritmetice s, i condit, ionale. UnContract Inteligent este o secvent, a de instruct, iuni care permite calcule arbitrare asupra stariiautomatului finit, inclusiv folosirea de bucle s, i apelarea funct, iilor din acelas, i sau alte contracteinteligente.

2.3. REGISTRE DISTRIBUITE 5

In funct, ie de cine are voie sa adauge blocuri, distingem trei tipuri de Blockchain: Permis-sionless (fara permisiune), Permissioned (cu permisiune) s, i private. Protocoalele BlockchainPermissionless permit oricui sa se alature ret,elei s, i sa ruleze un nod care sa transmita tranzact, iis, i sa contribuie la evolut, ia sistemului prin minarea blocurilor. In schimb, blockchain-urilePermissioned sunt gestionate de part, i cunoscute, ceea ce le permite sa aleaga nodurile caresa modifice starea registrului. Daca un Blockchain este gestionat de o singura entitate, acesta senumes,te Blockchain privat. In Tabelul 2.3 prezentam registre distribuite cunoscute s, i indicamtipul acestora s, i daca accepta executarea de contracte inteligente.

Tabelul 2.3: Popular Blockchain platforms

Ledger Type Smart Contracts

BitCoin Permissionless No

Ethereum Permissionless Yes

HyperLedger Sawtooth Permissionless No

HyperLedger Fabric Permissioned Future

Ripple Permissioned Future

Sistemele Permissioned pot beneficia de vasta literatura privind consensul, replicarea starii,tranzact, iile emise ın ret,ele asincrone cu conectivitate incerta, s, i tolerant,a la situat, iile de defect, iunesau manipulare. Cu toate acestea, exista multe start-up-uri care dezvolta protocoale Blockchainbazate pe intuit, ie pura, fara a se baza pe cercetari stabilite. Cachin s, i Vukolic [5] ofera o analizacomprehensiva asupra protocoalelor de consens ce pot fi folosite ın context cu permisiune, undenodurile au ıncredere ın ceilalt, i participant, i.

Companiile ce ofera de servicii Cloud prin intermediul Blockchain-urilor sunt prezentate ınTabelul 2.4. Ethereum este considerat un computer global, des, i capacitat, ile de stocare a datelors, i de execut, ie sunt drastic limitate de pret,ul contractelor inteligente. Astfel, tehnologiile sebazeaza pe utilizarea Ethereum Blockchain pentru a crea monede pentru platforma lor s, i pentrua strange fonduri de investit, ii prin oferta monetara init, iala (ICO, eng. Initial Coin Offerring).Logica complexa a planificarii s, i verificarii aplicat, iilor are loc pe un Blockchain lateral.

Tabelul 2.4: Tehnologii pentru servicii Cloud bazate pe Blockchain

Nume Blockchain Piat, a Stocare Servicii

Golem Ethereum Nu Nu SaaS

SONM Ethereum Da Da IaaS

iExec Ethereum Da Da PaaS

Enigma Extern Da Criptat PaaS

Decenter Ethereum Da Nedefinit IaaS

Eforturile actuale decupleaza infrastructura Blockchain de logica de planificare, folosind unoracol de ıncredere s, i contracte inteligente care joaca rolul de planificatori. Participant, ii ar puteaavea tendint,a de a se alatura grupurilor acolo unde plat, ile sunt mai bune, fapt ce poate determinacentralizarea ın cateva grupuri mari de participant, i. In acest scenariu, logica de planificare artrebui sa poata fi scalate cu numarul alternativelor de atribuire. Aceasta teza investigheazacostul s, i latent,a asociate cu un astfel de sistem s, i ofera recomandari de proiectare. In cele dinurma, se propune o arhitectura descentralizata pentru gestionarea tipurilor arbitrare de resurses, i pentru asigurarea tolerant,ei la defect, iuni a serviciilor s, i componentelor de management.

Capitolul 3

Serviciul Gateway

Serviciul Gateway este o colect, ie de componente care permite definirea, compozit, ia, opti-mizarea s, i execut, ia serviciilor HPC folosind paradigma Cloud. Contribut, iile cheie sunt:

• modelarea infrastructurii (mas, ini virtuale, containere, servere Bare Metal, acceleratoarehardware), serviciilor s, i relat, iilor dintre acestea utilizand specificat, ia TOSCA

• modelarea serviciilor abstracte care pot fi instant, iate prin diferite implementari expliciteprin procesul de optimizare a serviciilor

• implementarea unei interfet,e grafice prin extinderea platformei Alien4Cloud cu pluginuricare permit procesul de optimizare a serviciilor s, i execut, ia lor

• proiectarea specificat, iei s, i protocolului, precum s, i implementarea procesului de optimizarea serviciilor, permit, and comunicarea ıntre Gateway s, i managerul de resurse.

• implementarea CloudLightning Orchestrator, care este capabil sa execute aplicat, ii compusedin servicii folosind resurse eterogene (de exemplu, un serviciu VM conectat la un serviciude containere care utilizeaza un accelerator hardware).

O versiune preliminara a acestei lucrari a fost publicata anterior [7]. Aceasta este revizuitas, i ımbogat, ita pentru a prezenta versiunea definitiva a acestor componente. Serviciul Gatewaypermite dezvoltatorilor de aplicat, ii sa publice definit, iile s, i cerint,ele serviciilor. Clientul poateselecta s, i conecta mai multe dintre aceste servicii ıntr-o aplicat, ie. In funct, ie de parametriiales, i client (cost, performant, a) s, i de starea sistemului (sarcina, eficient, a energetica), un sistemde planificare va recomanda plasarea serviciilor pe infrastructura. Gateway-ul continua apoicu execut, ia serviciilor aplicat, iei s, i informeaza utilizatorul despre valorile operat, ionale: stareaserviciului, puncte de acces ale serviciului, instruct, iuni de conectare.

O serie de componente sunt necesare pentru a gestiona ciclul de viat, a al unei aplicat, ii.Interfat,a grafica permite gestionarea definit, iilor serviciilor s, i a execut, iei aplicat, iei. Un Porto-foliu ofera mijloacele pentru stocarea definit, iilor serviciilor (ex., cerint,e, dependent,e) s, i adefinit, iilor topologiilor aplicat, iilor, care consta ın unul sau mai multe Servicii s, i relat, iile dintreacestea. Un Dezvoltator de Applicat,ii (AD) foloses,te aceasta componenta pentru a stoca astfelde definit, ii, care pot fi utilizate ulterior de un Operator de Aplicat,ii (AO) pentru a crea o nouaTopologie sau pentru a executa o versiune proiectata de dezvoltator.

Conceptul inovator de Abstractizare a Aplicat,iei permite unui utilizator al platformei sadefineasca o topologie a aplicat, iei constand din Servicii Abstracte. Acest tip de definit, ii de serviciisunt abstract, ii ale implementarilor explicite, care definesc doar dependent,e de alte servicii, darnu impun cerint,e privind tipul de hardware sau acceleratoare. Motorul de Optimizare aServiciilor (SOE, eng. Service Optimization Engine) permite inspect, ia portofoliului de serviciiın cautarea implementarilor explicite s, i ofera sistemului de planificare o Schema (eng. Blueprint)

6

7

Figura 3.1: Interact, iunea componentelor din Serviciul Gateway

a tuturor combinat, iilor de implementari pentru aplicat, ie. Dupa alegerea celor mai potriviteresurse pentru o Schema, utilizatorului ıi este prezentata topologia explicita a aplicat, iei. Aceastatopologie este executata de un Orchestrator, care gestioneaza ciclul de viat, a al aplicat, iei.

Definit, ii pentru entitat, i

TOSCA (TOpology Specification for Cloud Applications) [16] este o specificat, ie proiectata deOASIS care permite modelarea ıntregii stive de software pentru o aplicat, ie, cu scopul de aproiecta aplicat, ii portabile care au un comportament reproductibil atunci cand migreaza de la oplatforma Cloud la alta. Specificat, ia detaliaza un meta-model pentru definirea atat a structurii,cat s, i a gestionarii aplicat, iilor. Serviciile care compun o aplicat, ie s, i relat, iile dintre acesteas, i infrastructura sunt definite utilizand o entitate Topologie. Serviciile s, i infrastructura suntreprezentate ca noduri, iar relat, iile trebuie sa aiba o sursa s, i un nod t, inta; ın plus, relat, iile potavea parametri care pot fi de folos pentru motorul de Orchestrare.

Figura 3.2 prezinta exemple de relat, ii pentru diferite noduri. In general, un CLService s, i unAccelerator sunt gazduite pe o resursa CLResource. Un GPUSoftware s, i un GPU sunt gazduitepe o resursa CLResource, iar GPU-ul satisface cerint,ele GPUSoftware. Un MICContainer s, i ounitate MIC sunt gazduite pe un DockerHost, iar MIC satisface cerint,a MICConainer pentruun MIC. Relat, ia AcceleratedBy este afis,ata printr-o linie verde subt, ire.

8 CAPITOLUL 3. SERVICIUL GATEWAY

Figura 3.2: Exemple de Servicii accelerate

Exista doua tipuri de topologie a aplicat, iei: abstracta s, i explicita. O topologie abstractadefines,te cel put, in un serviciu abstract ın constituentele sale. O topologie explicita este compusanumai din servicii s, i resurse explicite. Motorul de optimizare a serviciilor ofera instant, ierea uneitopologii abstracte cu servicii explicite bazate pe starea actuala a sistemului de gestionare aresurselor. Utilizatorul poate crea totus, i o aplicat, ie explicita ın care SOE solicita doar resurselenecesare, dar nu are voie sa modifice topologia. Nodurile, capabilitat, ile, s, i relat, iile furnizateın aceasta teza ofera un punct de plecare pentru definirea serviciilor Cloud eterogene, care potutiliza acceleratoare pentru a-s, i ımbunatat, i performant,a.

3.1 Motorul de optimizare a serviciilor

Un utilizator nu trebuie sa aiba cunos,tint,e despre caracteristicile hardware atunci cand proiecteazasau utilizeaza o topologie de aplicat, ie. Poate face acest lucru prin intermediul definit, iilor deservicii abstracte. Motorul de optimizare a serviciilor este responsabil pentru ıncapsulareatuturor implementarilor posibile, iar sistemul de planificare o selecteaza pe cea mai potrivitaavand ın vedere un set de constrangeri.

O Schema este construita din topologia TOSCA. Fiecare serviciu este ınsot, it de o Cererede Serviciu corespunzatoare. SOE va aduna toate implementarile unui serviciu dat s, i va crea oCerere de Resurse urmand definit, iile TOSCA (de exemplu, tipul de resursa, tipul acceleratorului,nucleele procesorului, cantitatea RAM). Sistemul de gestionare a resurselor este responsabil saselecteze o singura cerere de resursa pentru a satisface o cerere de serviciu.

Figura 3.3 prezinta conexiunea a doua noduri abstracte care denota o interfat, a grafica s, i unmotor de trasare a razelor de lumina.

Figura 3.3: Exemple de instant, ieri pentru o aplicat, ie abstracta

3.2. INTERFAT, A UTILIZATOR 9

Exista doua implementari pentru interfat,a grafica s, i doua implementari pentru motor, ınsumand4 instant, ieri posibile pentru aceasta aplicat, ie. Este prezentata doar implementarea tip Containerpentru interfat,a grafica, pentru brevitate. In partea stanga avem implementarea ContainerSimpleRayTracingEngine fara cerint,e specifice pentru gazda sa, lasand atribuirea resurselor lalatitudinea Orchestratorului. In partea dreapta avem implementarea Container PhiRayTracin-gEngine. Aceasta implementare necesita execut, ia pe o anumita gazda care are atas,at un MICcare satisface cerint,a motorului de trasare.

3.2 Interfat,a utilizator

O interfat, a prietenoasa a fost dezvoltata pentru a ajuta utilizatorii Cloud sa defineasca vizualServiciile CloudLightning s, i sa ruleze aplicat, ii. Pluginurile implementate ajuta utilizatorul saproiecteze, sa optimizeze, sa implementeze s, i sa monitorizeze starea unei aplicat, ii. Interfat,aComponente permite ıncarcarea s, i inspect, ia definit, iilor TOSCA. Toate tipurile de baza Cloud-Lightning sunt ambalate ca o arhiva zip, utilizand formatul CSAR (Cloud Service ARchive)[2], care este ıncarcat folosind aceasta interfat, a. Exista alte doua interfet,e: S, abloane topologices, i Aplicat,ii. Interfat,a s,abloanelor permite proiectarea unui s,ablon Topologic s, i salvarea luiın Portofoliul aplicat, iilor pentru utilizarea ulterioara. Interfat,a Aplicat, ii permite crearea uneiTopologii de la zero sau folosind un s,ablon definit ın interfat,a descrisa anterior. Mai mult,interfat,a Aplicat, ii cont, ine, de asemenea, un panou asociat procesului de optimizare a serviciilors, i ofera mijloacele pentru execut, ia s, i monitorizarea aplicat, iei.

Pluginul Orchestrator trimite succesiv cereri pentru execut, ia serviciilor, verificand stareafiecaruia ınainte de a continua cu orice serviciu care depinde de acesta. De exemplu, se as,teaptaca motorul de trasare sa fie disponibil s, i accesibil pe portul expus ınainte de a executa interfat,a deutilizare, care depinde de aceste informat, ii ce trebuie furnizate ın timpul pornirii containerului.Acest proces poate fi observat folosind panoul Runtime, prezent ın bara de navigare a interfet,eiAplicat,ii. Figura 3.4a prezinta pornirea motorului s, i interfat,a ın as,teptare. Odata ce motoruleste accesibil, Orchestratorul poate prelua informat, iile despre gazda s, i port s, i le poate folosipentru a configura cererea de pornire a interfet,ei de utilizare. In figura Figura 3.4b aratammotorul de redare sanatos s, i pornirea UI.

(a) Pornirea motorului (b) Pornirea interfet,ei

Figura 3.4: Execut, ia aplicat, iei de trasare a razelor

3.3 Experient,a utilizatorului

Execut, ia tradit, ionala

Execut, ia tradit, ionala a serviciilor implica accesul la o infrastructura HPC ın care utilizatorul seconecteaza la un nod principal s, i este capabil sa trimita o descriere a aplicat, iei la coada unui

10 CAPITOLUL 3. SERVICIUL GATEWAY

manager de resurse. De obicei, aplicat, ia ruleaza pe sistemul de operare gazda s, i, prin urmare,toate bibliotecile s, i stiva software trebuie instalate la acest nivel. O alternativa la aceasta este saruleze aplicat, ia ca VM sau Container s, i sa avet, i toate dependent,ele incluse ın imaginea aplicat, iei.

Majoritatea utilizatorilor de aplicat, ii HPC sunt de obicei expert, i ın utilizarea aplicat, iei pecare o executa, dar nu ın configurat, ia acesteia s, i, cel mai probabil, nu expert, i ın gestionareainfrastructurii eterogene. Prin urmare, pentru a facilita migrarea aplicat, iei HPC ın Cloud,experient,a utilizatorului final nu ar trebui sa implice configurarea s, i instalarea aplicat, iei, ci maidegraba proiectarea aplicat, iei s, i unele constrangeri la nivel logic (ex. performant, a, cost). Inplus, disponibilitatea acceleratoarelor eterogene este strict limitata la expertul tehnic, cu unaccent redus asupra utilizatorului final, care va beneficia de fapt de ımbunatat, irea performant,ei.

Clusterele HPC tradit, ionale necesita un departament IT cu pregatire de specialitate ıngestionarea infrastructurii s, i configurarea software-ului. Chiar s, i atunci, se depun eforturisubstant, iale ın configurat, ie, asigurandu-se ca toate dependent,ele sunt ındeplinite fara a distrugedependent,ele altor aplicat, ii. In schimb, utilizand sistemul CloudLightning, aplicat, iile pot ficonfigurate folosind un limbaj de nivel ınalt, as,a cum este descris ın sect, iunea 2.3, iar personalultehnic se poate concentra pe experimentarea cu diferite configurat, ii pentru a asigura cea maibuna performant, a.

Abordarea noastra

Migrarea serviciilor HPC catre Cloud a introdus provocari cu privire la performant,a, ıncapsulareas, i definit, ia acestora. Exista put, ina asistent, a pentru aplicat, iile care utilizeaza resurse eterogenes, i implica, de obicei, selectarea unei versiuni specifice de software care funct, ioneaza cu unmodel specific de accelerator hardware. Clientul este responsabil pentru gestionarea atat asoftware-ului, cat s, i a select, iei resurselor, ceea ce poate duce la supra-aprovizionare s, i conflicteın comunicarea software-la-software s, i software-la-hardware.

Serviciul Gateway prezentat ın acest capitol ofera unificarea solut, iilor la provocarile identifi-cate. Acesta ofera un portofoliu de servicii, pentru stocarea definit, iilor serviciilor, s, i o specificat, iedefinita de tipurile de baza CloudLightning, care defines,te linia directoare pentru definireaserviciilor de tip HPC ıntr-un mod portabil. Serviciul faciliteaza proiectarea aplicat, iilor s, ia s,abloanelor de aplicat, ii printr-o interfat, a us,or de utilizat s, i gestioneaza execut, ia Serviciiloreterogene atat ın ceea ce prives,te hardware-ul (mas, ini convent, ionale, acceleratoare), cat s, iıncapsularea (adica Bare Metal, VM s, i Container).

Provocarile sunt depas, ite prin mai multe procese. In primul rand, serviciile s, i biblioteciledependente sunt ımpachetate ca imagini VM sau Container de catre un dezvoltator de aplicat, ii,care poate experimenta diferite configurat, ii s, i poate determina caracteristicile hardware adecvatepentru un anumit nivel de performant, a. In al doilea rand, folosim portabilitatea specificat, ieiTOSCA pentru a defini relat, iile dintre servicii, infrastructura convent, ionala s, i acceleratoriihardware. In al treilea rand, prin intermediul proceselor de descoperire a resurselor s, i deoptimizare a serviciilor, ımbunatat, im flexibilitatea proiectarii s, i performant,ei aplicat, iei (pentruutilizatorul final) s, i flexibilitatea select, iei resurselor (pentru furnizorul de servicii Cloud).

Capitolul 4

Auto-organizare s, i auto-administrare ın

managementul resurselor

Motivat, ia pentru proiectarea unui sistem ierarhic este ımpart, irea spat, iului de cautare pentrugasirea unui subset de componente specifice la nivelul inferior al ierarhiei. Acest nivel estereprezentat de infrastructura de calcul, iar scopul componentelor de management (la nivelurileintermediare) este de a reduce spat, iul pentru gasirea resurselor de calcul specifice. Fiecare com-ponenta de management poseda doua tipuri de Strategii: auto-management s, i auto-organizare,care dicteaza act, iunile necesare pentru a evolua componenta mai aproape de un obiectiv indi-vidual. Contribut, iile cheie ale acestui capitol sunt:

• proiectarea unui sistem nou, generic, pentru autoorganizare s, i auto-management ın sis-temele ierarhice; acesta include mecanisme pentru comunicarea dorint,ei componentelor denivel superior ın josul ierarhiei s, i pentru a evalua starea s, i eficient,a componentelor de nivelinferior.

• proiectarea s, i implementarea a doua strategii de formare predictiva a coalit, iilor de lanivelul inferior al ierarhiei, pentru satisfacerea cerint,elor serviciilor

• evaluarea experimentala a unui prototip folosind date de urmarire open source; sistemulnostru atribuie resursele ıntr-un mod mai eficient energetic.

Sect, iunea 4.1 revizuies,te s, i extinde cu noi exemple o lucrare publicata anterior [9]. Sect, iunea 4.2revizuies,te, extinde s, i integreaza doua lucrari publicate anterior [21, 19] cu platforma anteriorment, ionata.

4.1 Sistemul

Sistemul nostru propus este reprezentat vizual ın Figura 4.1. In general, act, iunile ıntreprinse deo componenta de management vor afecta starea componentelor la nivelurile ınvecinate. Uneleact, iuni sunt comunicate catre o componenta din josul ierarhiei pentru a-i actualiza obiectiveleindividuale cu scopul de a le alinia la obiectivul global. O astfel de act, iune este denumita ıncontinuare Impuls (lat. Impetus), iar procesul de transmitere a Impuls este denumit Evolut, ieDirect, ionata. Intrucat componentele poseda obiective individuale, Impulsul va fi ın generalintegrat luandu-le ın considerare. Impulsul este transmis ca un vector de Ponderi.

O componenta de management evalueaza act, iunile ıntreprinse de componentele subiacenteprimind un vector de Metrici, care ofera componentei de management o Percept, ie a evolut, ieicare are loc la nivelurile subiacente. Aceste valori vor influent,a ın continuare act, iunile Evolut, ieidirect, ionate. In cele din urma, proprietat, ile s, i starea infrastructurii de calcul trebuie evaluatede componentele administrative. Arhitectura noastra ia ın considerare utilizarea Funct, ii de

11

12 CAPITOLUL 4. MANAGEMENT DE RESURSE SOSM

Figura 4.1: Sistemul propus

evaluare care pot fi ponderate corespunzator obiectivului unei componente individuale s, i astfeldetermina performant,a infrastructurii de la baza.

Componentele de management se angajeaza ın auto-organizare pentru a minimiza costurilede management ale nivelului din care fac parte. Procesul de auto-organizare are loc ıntr-un singurnivel s, i poate avea ca rezultat oricare dintre urmatoarele operat, iuni: crearea, distrugerea,spargerea s, i unirea componentelor, respectiv transferul de noduri sau componente subiacenteıntre componentele de pe acelas, i nivel. Definim un obiectiv individual al componentelor degestionare ca atingerea unei stari de echilibru. Aceasta stare este atinsa atunci cand act, iunileEvolut, iei Direct, ionate, transmise de la un nivel superior, nu au ca rezultat nicio variat, ie semni-ficativa a Percept, iei componentelor inferioare. Pentru a determina valoarea contribut, iei pe careo ofera o componenta, folosim not, iunea de Index de adecvare (SI, eng. Suitability Index).Prin urmare, obiectivul individual al fiecarei componente de gestionare este de a maximizaindicele de adecvare s, i de a ıntreprinde act, iuni care duc la un indice de adecvare mai marepentru componentele gestionate.

4.2 Strategii de formare a Coalit, iilor

In Figura 4.2 prezentam un mecanism pentru a agrega date istorice de execut, ie s, i a crea coalit, iicare ar putea fi utile pentru satisfacerea cererilor viitoare. Un agregator va consuma istoriculsarcinilor s, i va crea histograme specifice unei strategii de formare a coalit, iei. O alta instant, aa Agregatorului va consuma istoricul de utilizare a sarcinilor s, i va determina utilizarea pentrufiecare mas, ina de calcul. Resursele sunt apoi filtrate s, i mas, inile care au sloturi disponibile potparticipa ın coalit, ii pentru urmatoarea epoca. Cand o cerere de resursa atinge o componentade nivel inferior, se cauta o solut, ie ın cadrul coalit, iilor formate. Daca nu se gases,te nicio solut, ieadecvata, atunci coalit, iile pot fi extinse cu resurse din alte coalit, ii.

4.2. STRATEGII DE FORMARE A COALIT, IILOR 13

Figura 4.2: Procesarea datelor pentru formarea coalit, iilor

Similitudinea marimii este o strategie de formare a coalit, iei care foloses,te dimensiuneacoalit, iilor create anterior pentru a determina cea mai frecventa cardinalitate a coalit, iei. Cu catdimensiunea unei coalit, ii este mai frecventa, cu atat vor fi create mai multe coalit, ii de aceastadimensiune. Presupunem ca un server se poate alatura unei singure coalit, ii ıntr-o anumitaepoca. Cu toate acestea, avand ın vedere containerizarea / virtualizarea resurselor dintr-ocoalit, ie, acesta poate atribui mai multe servicii pe aceeas, i coalit, ie, dat fiind ca cerint,ele nudepas,esc capacitatea niciunui server. Pentru a realiza acest lucru, strategia trebuie sa utilizezeproceduri de formare s, i select, ie a coalit, iei care sa agrege informat, ii de utilizare pentru a filtraserverele indisponibile.

In mod similar, clusterele pot fi construite luand ın considerare similitudinea frecvent,eiconstrangerilor ın raport cu constrangerile solicitate recent ın sarcini. De exemplu, ıntr-un setde date care descrie o mas, ina fizica dintr-un centru de date Google, resursele prezinta 42 deatribute, al caror subset are valori ın domeniul sutelor [18]. Utilizarea tuturor acestora pentrua calcula similitudinea se va dovedi nu numai ineficienta a calculului, ci va produce s, i clusteremici s, i foarte similare, care nu reprezinta o ımbunatat, ire ın gasirea unei coalit, ii adecvate pentruanumite execut, ia sarcinilor.

Folosind un set de date de urmarire liber (open-source), simularea experimentala a aratat caacest mecanism este capabil sa potriveasca ın mod eficient interogarile de resurse cu coalit, iileprezise, cu except, ia cazului ın care dimensiunea jobului depas,es,te capacitatea componentei degestionare curente. Metoda propusa este capabila sa realizeze o utilizare mai buna a resurselorpe ansamblul de mas, ini. Acest lucru se realizeaza considerand serverele neutilizate drept inactives, i prelungind momentul cand acestea sunt pornite, ımpachetand cat mai multe servicii pe carele poate gestiona o resursa ınainte de a trece la urmatorul.

In cadrul ierarhic, sarcinile care sunt trimise catre Managerul de Celula, care alege unpRouter (eng. prescription router) pentru a conduce sarcina ın ierarhie, urmand pSwitch (eng.prescription switch), apoi vRM (eng. virtual Rack Manager), alegand ıntotdeauna componentacu cel mai mare indice de adecvare. Cand un vRM atribuie sarcina unui set de resurse, face acestlucru aplicand o strategie de compactare, preferand servere care au deja instant,e care ruleazacelor care sunt inactive. Daca nu sunt gestionate suficiente resurse, atunci o act, iune de fuzionarepoate fi efectuata cu un alt vRM sub acelas, i pSwitch pentru a obt, ine setul necesar de servere.Aceasta act, iune poate strabate ierarhia, ducand la fuzionarea a doua pSwitch-uri sub acelas, i

14 CAPITOLUL 4. MANAGEMENT DE RESURSE SOSM

pRouter.In Figura 4.3a prezentam utilizarea medie a sistemului. Ea este ımbunatat, ita considerabil

ın comparat, ie cu utilizarea init, iala calculata din datele de urmarire. Cel mai important aspectcare duce la acest rezultat este strategia de compactare, care pastreaza serverele inactive panacand nu exista alta solut, ie decat sa fie selectate.

(a) Utilizarea resurselor normalizata la numarul deservere pornite

(b) Evolut, ia numarului de vRM

Figura 4.3: Utilizarea resurselor folosind SOSM

Figura 4.3b prezinta evolut, ia numarului de manageri de resurse de la baza ierarhiei pentrufiecare dintre cele 8 tipuri de resurse identificate. Cres,terea numarului de astfel de componentese datoreaza profilului sarcinilor solicitate. Deoarece majoritatea cererilor sunt pentru un numarmic de servere, vRM-urile vor folosi o cantitate mica de servere aflate sub controlul lor. Deoarecenici un alt vRM nu ar fi dispus sa transfere unele resurse utilizate, cea mai buna solut, ie pentrucres,terea indicelui de adecvare este reducerea numarului de servere gestionate. Acest lucrudetermina o ımpart, ire a unui vRM ın aceasta situat, ie. Procesul este continuat pana cand vRM-urile vor semana cu profilurile de activitate.

Capitolul 5

Evaluare experimentala asupra sistemului

CloudLightning

Sistemul CloudLightning a fost evaluat prin intermediul experimentelor pe un banc de testarela scara mica instalat la Universitatea Norvegiana de S, tiint, a s, i Tehnologie (NTNU). Contribut, iaacestui capitol este dubla:

• prezinta o vizualizare detaliata a funct, ionarii interne a sistemului prezentate ın capitolul 4,la scara mica; aceasta este omis ın acest rezumat datorita complexitat, ii experimentului

• prezinta dovezi ca sistemul nu are impact asupra executarii Serviciilor ın niciun aspectsemnificativ al performant,ei acestora.

Serviciile studiate au fost evaluate s, i profilate pe resurse, iar valorile lor de performant, aau fost stocate ın portofoliul de servicii. Ambele implementari Genomics ruleaza ın containereDocker. Prima este o implementare CPU, ın timp ce a doua necesita un accelerator DFE pentru afi atas,at la nodul de calcul. In ceea ce prives,te accelerarea, a doua implementare a fost profilatacu o ımbunatat, ire de 8, 78. Upscale este serviciul asociat cazului de studiere a petrolului s, igazului. Ambele implementari ruleaza ın containere, ınsa versiunea GPU nu arata o cres,teresemnificativa a performant,ei. Cazul de utilizare RayTracing are 4 implementari de servicii.Primele doua reprezinta front-end-ul, care poate fi executat ca VM, Container sau Bare Metal.Urmeaza implementarile back-end, ambele ruland ın containere. Primul ruleaza folosind doarCPU, ın timp ce PhiRayTracingEngine necesita atas,area unei unitat, i MIC, aratand o cres,tere aperformant,ei de 4, 0. In cele din urma, multiplicarile de matrici dense sunt efectuate utilizandbibliotecile OpenBLAS sau cuBLAS. O implementare a containerului CPU este linia de baza s, iexista doua implementari GPU, una ruleaza ın containere s, i cealalta pe serverele Bare Metal.Ambele implementari GPU arata o cres,tere a performant,ei de 4, 0.

RayTracing: MIC and CPU execution

Pentru aceasta aplicat, ie, zece imagini 3D cu dimensiunea cadrului de 765x512 sunt redate lapuncte de vedere selectate aleatoriu folosind un model de biserica 3D open-source. Figura 5.1prezinta utilizarea procesorului principal (Fig. 5.1a) s, i a nucleelor specializate din interiorulcardului MIC. Profilele de peste 20 de execut, ii arata ca impactul general al sistemului nostrueste nesemnificativ. Figura 5.1b prezinta raportul mediu (%) al nucleelor utilizate pentru redareaimaginilor.

De asemenea, a fost verificat consumul de energie al aplicat, iei RayTracing. Figura 5.2a s, iFigura 5.2b prezinta consumul de energie ın cele doua scenarii de implementare. In general, pebaza graficelor de utilizare, putem concluziona ca performant,a aplicat, iei RayTracing nu prezintanicio degradare semnificativa. Mai multe grafice ın profunzime pot fi inspectate ın depozitulBitbucket [10].

15

16 CAPITOLUL 5. EVALUARE LA SCARA MICA

(a) Utilizarea CPU pentru versiunea CPU (b) Utilizarea MIC pentru versiunea MIC

Figura 5.1: Comparat, ie ıntre execut, iile celor doua versiuni ale aplicat, iei de trasare a razelor

(a) versiunea CPU (b) versiunea MIC

Figura 5.2: Utilizarea energiei pentru cele doua versiuni ale aplicat, iei de trasare a razelor

Concluzie

O inspect, ie detaliata a valorilor indicelui adecvarii ın spatele deciziilor luate de sistemul SOSMreleva flexibilitatea sistemului ın ceea ce prives,te furnizarea serviciilor. Evaluarea a aratatcapacitatea sistemului de a maximiza cerint,ele utilizatorului pentru performant, a, optimizand ınacelas, i timp obiectivul sistemului de a gestiona eficient resursele s, i consumul de energie.

Pentru a rezuma experimentele efectuate, singurul impact generat de sistemul CloudLight-ning este ıntarzierea datorata furnizarii resurselor, care reprezinta aproximativ 8 secunde (pebancul de testare la scara mica), indiferent de ce serviciu este executat. Consideram ca aceastaıntarziere este un cost mic ın comparat, ie cu facilitat, ile oferite de platforma noastra, s, i anume:selectarea s, i implementarea automata a unei varietat, i de implementari, aprovizionarea (s, i ges-tionarea) resurselor s, i descoperirea serviciilor. Solut, iile alternative, ın general, solicita clientuluisa furnizeze manual resursele, sa execute serviciile s, i sa le conecteze (ın cazul mai multor serviciidependente).

Cu except, ia ıntarzierii de aprovizionare (care poate fi experimentata s, i pe alte platformeCloud), platforma noastra nu are niciun alt efect negativ asupra performant,ei aplicat, iei (timpulde execut, ie) sau a consumului de energie, atunci cand rulam aplicat, iile ın Containere.

Capitolul 6

Planificarea resurselor folosind contracte inteligente

Ethereum

In acest capitol proiectam s, i implementam un mecanism de planificare descentralizat bazatpe contracte inteligente Ethereum s, i investigam constrangerile operat, ionale s, i costul pentrugestionarea alocarilor de resurse. Acest capitol revizuies,te s, i extinde o lucrare publicata anterior[20] s, i are urmatoarele contribut, ii:

• o arhitectura pentru o platforma Cloud descentralizata care foloses,te serviciul Gatewayprezentat ın capitolul 3 care se conecteaza la un contract inteligent Ethereum pentruselectarea s, i plata resurselor.

• un studiu privind impactul a patru metode de planificare ın ceea ce prives,te costul tranzact, iilors, i latent,a.

• o investigat, ie a constrangerilor sub care poate avea loc interact, iunea asincrona cu contrac-tul inteligent, respectiv principii de proiectare pentru ment, inerea acesteia.

• o evaluare experimentala utilizand un scenariu construit din trasari de utilizare a Cloud-ului, care permite o investigat, ie mai profunda a costurilor s, i a latent,ei ıntr-un cadru real.

6.1 Metode de planificare

Sunt luate ın considerare patru metode pentru planificarea unui serviciu:

1. First Match - tabloul de resurse este iterat pana cand este atribuita prima resursadisponibila care corespunde cerint,elor serviciului. Aceasta este cea mai simpla forma dealocare prin contracte inteligente care poate fi efectuata.

2. Best Match - tabloul de resurse este complet iterat s, i este selectata resursa cu cea maibuna potrivire din punct de vedere al cerint,elor s, i pret,ului. Alegem aceasta varianta caarhetip pentru orice problema de minimizare sau maximizare a parametrilor.

3. Offline Selected - tabloul de resurse este investigata citind Contractul Cloud s, i aplicandfunct, ia de optimizare offline; apoi, resursa este atribuita prin id.

4. Offline Synchronized - resursa este selectata ca ın metoda anterioara, dar client, ii potinteroga o componenta de sincronizare pentru a evalua daca resursa a fost deja solicitatade un alt client

17

18 CAPITOLUL 6. PLANIFICAREA RESURSELOR PRIN CONTRACTE INTELIGENTE

Finalizare s, i mentenant, a

Gestionarea serviciilor curente care ruleaza este mediata de structura Schedule. Instant,eleServiciilor pot fi organizate ıntr-un dict, ionar, atribuind o valoare incrementala pentru fiecarenoua instant, a solicitata. Cu toate acestea, ın acest mod, limitam numarul maxim de serviciicare pot fi rulate pentru un utilizator, deoarece, dupa terminarea serviciului, nu exista niciomodalitate de a reutiliza spat, iul pe care l-au ocupat, ın afara de a det, ine o serie de indicineutilizat, i. Deoarece aceasta implica o manipulare suplimentara a datelor, consideram ca estemai bine sa organizam instant,ele de serviciu ıntr-un tablou, de la ınceput. Cand este finalizata,locul utilizat pentru aceasta instant, a poate fi refolosit utilizand una dintre cele doua abordari:

• Eliminare ordonata: ment, inerea ordinii instant,elor prin deplasarea tuturor instant,elorurmatoare cu o pozit, ie la stanga;

• Eliminare prin mutare: ınlocuirea instant,ei finalizate cu cea de pe ultima pozit, ie.

Eficient,a primei abordari este scazuta s, i se degradeaza odata cu cres,terea dimensiunii tabloului.Pentru o instant, a, eficient,a depinde de pozit, ia acestei instant,e ın tablou. Suma operat, iunilorde copiere care trebuie facute este C = n− i, unde n este dimensiunea tabloului s, i i este pozit, iaServiciului care necesita finalizare. Atunci cand aplicat, iile compuse din mai multe servicii trebuiesa fie ıncheiate, toate instant,ele de serviciu trebuie sa fie ıncheiate individual. Efectul este caunele instant,e vor fi copiate de una sau mai multe ori ınainte de a fi terminate.

Costul tranzact, iilor

O analiza statica este prezentata ın tabelul 6.1. Costul de baza pentru planificare este similarpentru cele trei metode. Coloana +1R exprima costul suplimentar generat de fiecare resursaınregistrata. Coloana +1S exprima costul suplimentar pentru fiecare serviciu care ruleaza.Metoda First Match consuma un surplus de 772 de unitat, i pentru fiecare serviciu care ruleaza,adica fiecare resursa care nu este disponibila. Acesta este costul pentru verificarea disponibilitat, iiunei resurse. In plus, metoda Best Match adauga 7295 unitat, i pentru fiecare resursa ınregistratas, i disponibila. Acesta este costul pentru calculul scorului unei resurse s, i stocarea scorului minim.

Tabelul 6.1: Cost ın unitat, i de gaz (ETH)

Metoda Cost de baza +1 R +1 S

Offline Selected 159740 (0.0035) 0 0

First Match 159740 (0.0035) 0 772

Best Match 159740 (0.0035) 7295 (0.00016) 772

Finish 49826 (0.0011) 0 27880

Respingere Offline 21268 (0.0004) 0 0

Costul de baza pentru tranzact, ia de finalizare (Finish) este de 49.826 unitat, i s, i cres,te cumai mult de jumatate din aceasta suma cu fiecare Instant, a care trebuie copiata pentru a umplegolul. Putem observa costul mutarii a 100 de instant,e ajunge la 3 milioane de unitat, i s, i putemdeduce ca rezilierea unui Serviciu urmata de mai mult de 250 instant,e va atinge limita de gaz aunui bloc.

De asemenea, evaluam costul respingerii pentru metoda Offline Selected, ın cazul ın careresursa a devenit indisponibila ıntre timp. Acest cost este de aproximativ 13% din costultranzact, iei reus, ite.

6.2. EVALUARE EXPERIMENTALA 19

Putem calcula costul total pentru executarea unui serviciu S utilizand urmatoarea ecuat, ie:

C(S) = C(T sS) + C(T f

S ) +R∑

k=1

C(T rkS ), (6.1)

unde T s reprezinta tranzact, ia de planificare, T f reprezinta tranzact, ia finala, iar T rk reprezintaa k tranzact, ie de planificare care a fost respinsa, cu R ∈ {1, 2, .., Rmax} reprezentand numarulde tranzact, ii de planificare respinse, ıntr-o limita stabilita, Rmax.

6.2 Evaluare experimentala

Figura 6.1 arata costul total (ın ETH) datorat tranzact, iilor. Sub o jumatate din cererile Offlineau fost respinse, iar acest cost este destul de mic pentru ıntregul experiment. Metoda BestMatch prezinta un cost foarte mare pentru rezilierea serviciului, ın principal datorita numaruluiredus de alocari care ar putea fi efectuate ıntr-un singur bloc, ducand la mai multe copii candun serviciu este finalizat.

17.24

2.55 2.12 2.12

2.58

1.53 1.17 1.07

0.00

0.000.21

0.00

0

2

4

6

8

10

12

14

16

18

20

BEST FIRST OFFLINE OFFLINE_SYNC

ASSIGN FINISH REJECT

Figura 6.1: Costul pentru tranzact, ii de planificare acceptate (albastru), respinse (ros,u), s, itranzact, ii de finalizare (oranj)

In ceea ce prives,te latent,a, luam ın considerare doua masuri: makespan s, i finish. Latent,amakepan masoara perioada de timp de la trimiterea tranzact, iei de atribuire pana la primireachitant,ei. Latent,a de finalizare masoara perioada de timp de la trimiterea tranzact, iei definalizare pana la primirea chitant,ei.

Figura 6.2 arata latent,a makepan (start) s, i finish pentru cele patru metode. Latent,a definalizare a primelor trei metode este similara. Deoarece metoda Offline are s,anse mai mari dea porni Servicii ın acelas, i bloc, este capabila sa reduca costul pentru tranzact, ia de finalizares, i sa se ıncadreze mai multe ıntr-un singur bloc. Offline Synchronized obt, ine rezultate s, i maibune; deoarece majoritatea serviciilor care apart, in unei aplicat, ii sunt planificate ın acelas, i bloc,acestea pot fi ıncheiate ın ordine inversa, reducand costul acestei tranzact, ii. La randul sau,acest lucru maximizeaza numarul de tranzact, ii de finalizare care se pot ıncadra ıntr-un bloc. Olatent, a de finalizare mai mica se traduce printr-o plata mai echitabila pentru resurse, reducanddurata totala de rulare pentru un serviciu.

20 CAPITOLUL 6. PLANIFICAREA RESURSELOR PRIN CONTRACTE INTELIGENTE

Start Finish

Dela

y (s)

0

10

20

30

40

50

60

BEST FIRST OFFLINE OFFLINE_SYNC

Figura 6.2: Box-Plot pentru latent,a de planificare s, i finalizare; interval minare = 4s

6.3 Discut, ii

Cea mai eficienta abordare este de a citi informat, iile despre resurse din Contractul inteligents, i aplicarea unei funct, ii de optimizare a select, iei Offline. Aceasta metoda este ımbunatat, itasemnificativ daca client, ii ıs, i sincronizeaza deciziile pentru a limita s,ansa de a selecta aceeas, iresursa. Aplicarea unei funct, ii simple de optimizare ın Contractul inteligent se dovedes,te de 6, 21de ori mai scumpa decat varianta sincronizata Offline, ın experimentele noastre. Intr-adevar, ınfunct, ie de dimensiunea setului de resurse, varianta Contract poate costa de pana la 50 de ori maimult decat versiunea Offline, pentru 800 de resurse. Acest lucru cres,te, de asemenea, latent,asistemului, deoarece put, ine tranzact, ii sunt minate ın fiecare bloc. Inconvenientul metodei Offlineeste ca pot aparea conflicte cu ceilalt, i utilizatori care selecteaza aceeas, i resursa. In evaluareaexperimentala, numarul de tranzact, ii respinse din acest motiv este mai mult de jumatate dintoate tranzact, iile. Acesta poate fi atenuat sincronizand deciziile printr-o componenta externa.

Pentru a maximiza numarul de tranzact, ii care pot fi trimise asincron, ordinea trebuiement, inuta ın tabloul instant,elor fiecarui utilizator. Cu toate acestea, acest lucru implica uncost ridicat pentru terminarea instant,elor, deoarece toate instant,ele urmatoare trebuie copiatepentru a umple golul. Am identificat ca acest cost cres,te cu 27880 unitat, i (reprezentand 0, 0006ETH = 0, 06 USD) pentru fiecare instant, a care trebuie copiata. Mai mult, eliminarea inversareduce impactul acestui cost omit, and copierea instant,elor daca acestea trebuie eliminate ınacelas, i interval de timp.

Daca ret,eaua publica Ethereum este utilizata pentru implementarea sistemului prezentat,costul pentru rularea unui serviciu va consta ın 0, 53 USD pentru costul tranzact, iilor plus pret,ulresursei pentru o anumita perioada de timp. Numai pret,ul tranzact, iilor reprezinta echivalentulınchirierii unei mas, ini virtuale n1-standard-1 (1 vCPU, 3,75 GB) pe Google Compute Enginepentru 12 USD de ore. Daca consideram ca pret,ul unei resurse de pe platforma noastra estejumatate din pret,ul Google, atunci un serviciu trebuie sa aiba un timp de execut, ie de cel put, in24 de ore ınainte de a ıncepe sa beneficieze de pret,ul redus oferit. Serviciile cu un timp defunct, ionare mai scurt vor plati mai mult pentru tranzact, ii decat pentru utilizarea efectiva aresurselor. Latent,a va fi, de asemenea, substant, ial mai mare, deoarece rata de minare este mailenta, iar numarul altor tranzact, ii este mai mare. O varianta mai buna este crearea unei noiret,ele ın care singurele tranzact, ii sunt legate de platforma Cloud. Latent,a acestui sistem va fimai mare decat ın experimentele noastre, ın funct, ie de numarul de resurse s, i de contracte Cloud.

Capitolul 7

Cloud descentralizat rezistent la defect, iuni

Investigat, ia facuta ın capitolul anterior a relevat implicat, iile costurilor s, i ale latent,ei utilizariiunui contract inteligent pentru optimizarea resurselor. Prin urmare, o solut, ie mai buna esterezolvarea cerint,elor Serviciului ın afara Blockchain s, i utilizarea Contractul inteligent numaipentru verificarea acestui acord. Acest acord este folosit ulterior pentru a executa aplicat, ias, i pentru a evalua starea ei. In acest capitol prezentam o arhitectura pentru gestionareadescentralizata a unei platforme publice publice care agrega resurse proprietate privata, careasigura continuitatea aplicat, iei ın prezent,a es,ecurilor serviciului, continuitatea componentelorın caz de es,ec al componentei de management s, i asigura plata unui pret, corect ın caz de es,ec.Acest capitol revizuies,te o lucrare publicata anterior [22], iar contribut, iile cheie sunt:

• o arhitectura care permite descentralizarea ınregistrarii s, i alocarii resurselor, utilizandcontracte inteligente

• proiectarea ret,elelor de administrare a componentelor s, i a protocoalelor corespunzatoareale acestora, care act, ioneaza ca o punte ıntre lumea contractelor inteligente s, i lumeasoftware-ului s, i asigura continuitatea componentelor prin atribuirea unitat, ilor de lucru,salvarea punctelor de control s, i monitorizarea disponibilitat, ii acestora.

• un model tolerant la defect, iuni pentru Orchestrarea aplicat, iei, utilizand ret,ele de admin-istrare a componentelor, care asigura ca utilizatorul este taxat numai pentru perioada detimp ın care un Serviciu a fost executat;

In Figura 7.1 prezentam arhitectura propusa. Central este un Blockchain public capabilsa execute contracte inteligente. Des, i orice astfel de Blockchain poate fi utilizat, construimprotocoalele noastre pentru ret,eaua Ethereum. Urmatoarele contracte inteligente urmeaza safie executate pe Blockchain:

1. Registry Contract - acesta este punctul de intrare ın sistemul nostru. Cont, ine informat, iidespre Cloud-uri ınregistrate s, i starea lor, precum s, i definit, ii de servicii s, i aplicat, ii.

2. Cloud Contract - cont, ine informat, ii despre resurse, pret, , s, i puncte acces ale planificatoruluis, i serviciului Plug & Play

3. App Contract - se creeaza unul pentru fiecare aplicat, ie trimisa spre execut, ie s, i este utilizatpentru a urmari starea s, i plat, ile.

Serviciul Gateway nu trebuie sa det, ina cunos,tint,e a priori despre nicio instant, a de planificare.Poate citi ce Cloud-uri sunt ınregistrate ın Registry s, i le poate contacta. Cataloagele de servicii s, iaplicat, ii sunt, de asemenea, stocate ın contractul Registry. Acest lucru permite oricarei instant,eGateway sa aiba acces la aceleas, i informat, ii, ceea ce permite la randul sau descentralizarea

21

22 CAPITOLUL 7. CLOUD DESCENTRALIZAT REZISTENT LA DEFECT, IUNI

Orchestration Service

Cloud 1

PUBLIC BLOCKCHAIN

Physical Resources

Hypervisor Layer

OpenStack Marathon Bare Metal

Registry

Cloud 2 Cloud 3

Cloud1 Cloud2 Cloud3App1 App2 App3

SOSM SOSM SOSM

Gateway Service

OrchestratorUIService

OptimizationEngine

ComponentAdministration

Network

PnP PnP PnP

Figura 7.1: Arhitectura descentralizata

acestei componente. Utilizatorul nu este obligat sa ajunga la un nod ın care se afla Gateway-ul,deoarece el/ea ıl poate rula local.

Procesul de orchestrare este decuplat de Gateway. Nodurile care executa serviciul de Orches-trare utilizeaza un mecanism de stocare a datelor replicat, furnizat de o ret,ea de administrare acomponentelor (CAN, eng. Component Administration Network) care asigura disponibilitateaprocesului de orchestrare s, i continuitatea etapelor de execut, ie. Nodurile CAN sunt responsabilepentru disponibilitatea serviciului de orchestrare.

Serviciul Plug and Play utilizat pentru ınregistrarea resurselor este augmentat cu capacitat, ide citire s, i scriere Blockchain, act, ionand ca o interfat, a ıntre resurse s, i Blockchain. Managerulde resurse este, de asemenea, capabil sa radieze o resursa daca este considerata indisponibila.

7.1 Ret,ele de administrare a componentelor

O ret,ea de administrare a componentelor are un scop dublu. In primul rand, conecteaza taramulcontractelor inteligente cu taramul componentelor software. In al doilea rand, ofera mijloacelepentru monitorizarea s, i aplicarea unui set de replici pentru a tolera defect, iunile. Ret,eaua denoduri implementeaza un automat finit replicat care are doua funct, ii. In primul rand, ment, ineun registru de tranzact, ii legate de ret,eaua de noduri s, i componentele supravegheate, diferit deregistrul Ethereum. In al doilea rand, nodurile executa un sistem de fis, iere replicat pentru astoca datele asociate componentelor supravegheate.

Figura 7.2 prezinta arhitectura stratificata a acestei propuneri. Pe stratul inferior, existaret,eaua peer-to-peer care colaboreaza pentru ment, inerea Blockchain-ului Ethereum, unde esteexecutat Contractul Registry. Unele dintre aceste noduri pot face parte din ret,eaua de admin-istrare a componentelor.

Stratul de mijloc se refera la operat, iunile de gestionare a nodurilor. Acesta este primul stratın care identificam liderul ret,elei, care este responsabil pentru validarea tuturor tranzact, iilorlegate de CAN. Nodurile-replica vor accepta orice actualizare de la lider. Pentru acest nivelpropunem urmatoarele protocoale:

• Join - protocol pentru ca un nou nod sa se alature ret,elei

• RemoveNode - protocol pentru eliminarea unui nod care a fost descoperit a fi defect

7.2. ORCHESTRARE REZISTENTA LA DEFECT, IUNI 23

Figura 7.2: Arhitectura stratificata a unei ret,ele de administrare a componentelor

• LeadElect - protocol pentru alegerea unui nou lider daca s-a descoperit ca cel curent estedefect

Nivelul superior este preocupat de administrarea componentelor. Din nou, liderul CAN esteresponsabil pentru validarea actualizarilor la acest nivel. Acest nivel se refera la urmatoareleprotocoale:

• Register - o componenta este ınregistrata ın ret,ea

• Deregister - o componenta este indisponibila s, i este radiata

• AssignWork - unei componente i se atribuie o unitate de lucru

• CheckpointWork - o componenta solicita ret,elei sa stocheze un punct de control

• ReassignWork - o componenta a fost radiata s, i lucrarea este reatribuita alteia

• FinishWork - o componenta este solicitata sa ınceteze executarea unei anumite lucrari(ıncetarea unei aplicat, ii Cloud).

7.2 Orchestrare rezistenta la defect, iuni

Folosind conceptele definite ın sect, iunea anterioara, Orchestratorii sunt componente care seınregistreaza la ret,eaua de administrare a componentelor. Munca este reprezentata de con-tractele de aplicat, ie, pe care Orchestratorul le va citi s, i va efectua execut, ia.

Figura 7.3 prezinta continuitatea implementarii unei aplicat, ii compuse din doua servicii(de ex. Ray Tracing UI s, i Engine) ın prezent,a es,ecului Orchestratorului. Dupa procesuluide descoperire a resurselor, utilizatorul final solicita contractului Cloud sa creeze un contractde aplicat, ie. Liderul Orchestration CAN (OCAN) este apoi informat despre acest contract.Alternativ, liderul se poate abona la evenimentele Ethereum s, i poate fi notificat atunci cand estecreat un nou Contract de aplicat, ie. In ambele cazuri, liderul va selecta o replica Orchestrator,va emite o tranzact, ie AssignWork s, i va informa Orchestratorul atribuit.

24 CAPITOLUL 7. CLOUD DESCENTRALIZAT REZISTENT LA DEFECT, IUNI

Figura 7.3: Exemplu de continuitate a execut, iei ın prezent,a defect, iunilor Orchestratorului

Orchestratorul cites,te cont, inutul contractului de aplicat, ie s, i pornes,te execut, ia. Dupa fiecareexecut, ie, Orchestratorul va init, ia mecanismul punctului de control s, i va salva informat, ii desprerelat, ia unei definit, ii a serviciilor (din Contractul de aplicat, ie) cu o instant, a de serviciu (identi-ficator unic utilizat de Hypervisor). In acest mod, daca Orchestratorul atribuit nu es,ueaza intimpul execut, iei serviciilor, o alta replica poate folosi punctele de control.

In plus, Orchestratorul va emite un punct de control la intervalele stabilite ın Contractulde aplicat, ie. Acest punct de control este utilizat pentru colectarea plat, ilor, dovada ca toateServiciile au fost executate pentru intervalul stabilit. Cand un serviciu es,ueaza, se face un punctde control s, i se ıncearca un numar stabilit de reexecutari. Daca serviciul poate fi executat,atunci se face un punct de control. Daca serviciul nu poate fi executat, atunci trebuie sa fie

7.3. DISCUT, II 25

o problema cu Cloud-ul, iar liderului i se cere ınchiderea fort,ata a aplicat, iei. Liderul va apelafunct, ia corespunzatoare din Contractul de aplicat, ie.

Liderul OCAN este responsabil sa actualizeze Contractul de aplicat, ie cu proprietat, ile punc-tului de control, cum ar fi tipul punctului de control, marca temporala, propunatorul; dateleconcrete ale punctului de control pot fi solicitate de la ret,eaua OCAN. Liderul OCAN poate so-licita, de asemenea, plata punctelor de control ınregistrate periodic. Pentru aceasta, Contractulde aplicat, ie trebuie ıncarcat cu valuta de catre client. Cu toate acestea, clientul va plati doarpentru timpul efectiv pe care serviciile l-au rulat, pe baza punctelor de control.

In timpul executarii aplicat, iei, mai multe entitat, i ıs, i dedica resursele pentru a impunerezistent,a la defect, iuni a sistemului s, i a aplicat, iei s, i, prin urmare, trebuie rambursate. Entitat, ilesunt resursele, Cloud-ul care gestioneaza resursele, ret,eaua de administrare a componentelor s, iorchestratorii. Consideram o metoda de efectuare a plat, ilor intermediare pentru a reduce sarcinade calcul a tuturor plat, ilor ıntr-o singura tranzact, ie care poate depas, i limita unui bloc.

7.3 Discut, ii

Acest capitol a prezentat un mecanism descentralizat, rezistent la defect, iuni, pentru rulareaaplicat, iilor Cloud pe resurse private. Plecam de la arhitectura CloudLightning s, i o augmentampentru a realiza descentralizarea s, i tolerant,a la defect, iuni a aplicat, iilor s, i orchestratorilor. UnBlockchain capabil sa execute contracte inteligente este considerat pentru plat, i intermediare s, imentenant,a informat, iilor despre entitat, ile sistemului.

Am introdus conceptul de ret,ele de administrare a componentelor, care ofera o punte dinlumea contractelor inteligente ın lumea software-ului s, i asigura tolerant,a la defect, iuni a ret,elei s, ia componentelor supravegheate. Am aratat, prin simulare, ca ratele de es,ec de pana la f = .75pot fi tolerate daca sunt suficiente noduri care doresc sa se alature ret,elei periodic. Aceste nodurisunt ıncurajate sa se alature unei astfel de ret,ele pentru a colecta plat, i de la utilizatorii careruleaza aplicat, ii. In cele din urma, am aratat modul ın care aceasta ret,ea este utilizata pentrua asigura tolerant,a la defect, iuni a orchestratorilor s, i aplicat, iilor s, i am furnizat o metoda pentruplat, i intermediare catre toate entitat, ile care asigura executarea unei aplicat, ii.

Consideram ca solut, ia noastra are urmatoarele beneficii: creeaza o piat, a libera, descen-tralizata, pentru resurse private, pentru a satisface cerint,ele pentru aplicat, ii Cloud; permitegestionarea eficienta a resurselor ın conformitate cu metrici la nivel ınalt, prin utilizarea mecan-ismului SOSM; impune tolerant,a la defect, iuni legata de execut, iei aplicat, iei s, i asigura plataechitabila.

Capitolul 8

Concluzii

Avantajele solut, iilor prezentate ın aceasta teza sunt multiple. In primul rand, utilizatorulfinal al Cloud-ului este scutit de sarcina de a selecta dintre diferite implementari software s, itipuri de hardware s, i configurat, ia acestora. Protocolul de optimizare a serviciilor poate fiimplementat de planificatorii de resurse pentru a selecta flexibil resursele pe baza propriilormetrici, asigurandu-se ca sunt ındeplinite constrangerile stabilite de utilizator. In al doilea rand,modularitatea designului nostru permite descentralizarea componentelor sistemului. La randulsau, aceasta deschide calea pentru crearea unei piet,e libere, descentralizate, pentru resurseprivate, pentru a satisface cerint,ele aplicat, iilor Cloud. In al treilea rand, platforma noastradescentralizata Cloud asigura plata echitabila s, i continuitatea aplicat, iilor ın prezent,a es,ecurilorserviciilor sau Orchestratorilor.

Impact

Modelul de livrare al serviciilor Cloud a evoluat rapid de la aprovizionarea mas, inilor virtualela gestionarea containerelor la cerere. O cantitate vasta de software s, i utilitat, i au imaginiDocker disponibile ın depozitul oficial. Orchestratorul prezentat ın capitolul 3 este primul carepermite orchestrarea aplicat, iilor hibride, compuse din software mixt: mas, ini virtuale, containeres, i server Bare Metal. Progresele ın domeniile Fog s, i Edge Computing introduc un nivel ridicat deeterogenitate ın proiectarea aplicat, iilor, nivel anticipat de specificat, iile s, i instrumentele descriseın capitolul 3.

Blockchain-urile Proof of Work s-au dovedit a fi o solut, ie viabila la problema generalilorbizantini, cu o cres,tere masiva a dimensiunii ret,elei datorita numarului redus de mesaje necesarepentru a atinge consensul. In plus, este lipsit de permisiuni, ceea ce ınseamna ca nu este nevoieca nodurile participante sa cunoasca anterior un propunator de blocuri, dar totus, i aces,tia potconveni asupra validitat, ii tranzact, iilor s, i a dovezii de minare. Blocurile sunt reproduse pe toatenodurile s, i ofera un jurnal de evenimente transparent s, i rezistent la manipulare, fara a fi nevoiea avea ıncredere a priori ın vreunul dintre cei care propun blocuri. Unul dintre factorii limitativiai debitului unor astfel de sisteme este ca dovada trebuie sa fie suficient de dura pentru a evitaun numar mare de bifurcat, ii al unui Blockchain, ceea ce reduce rata de product, ie a blocurilor.

Analiza furnizata ın Capitolul 6 nu se limiteaza la un anumit sistem Blockchain, deoareceabordeaza o problema fundamentala pentru gestionarea informat, iilor. De exemplu, Ethereum2.0 este ın tranzit, ie catre un algoritm consens Proof of Stake, pentru a cres,te rata de product, ie ablocurilor. Cu toate acestea, limitele de calcul vor fi ment, inute, deoarece ramane un sistem publics, i trebuie sa fie prevenite atacurile de refuz de serviciu (eng. Denial of Service). Consideramconstrangerile operat, ionale s, i costurile investigate de noi, precum s, i recomandarile facute, ca fiindde mare valoare pentru orice cercetare viitoare ın direct, ia alocarii resurselor utilizand contracteinteligente folosind Blockchain fara permisiune (eng. Permissionless). Protocoalele descrise ın

26

27

capitolul 7 au fost concepute pentru a minimiza numarul de operat, ii care trebuie efectuata ıncontractul inteligent, permit, and un numar mai mare de tranzact, ii care pot fi minate ıntr-unbloc.

Volatilitatea criptomonedei Ethereum poate fi atenuata prin utilizarea unei ret,ele proprii,independenta de fluctuat, iile piet,ei. Propunerea noastra permite rambursarea nodurilor din ret,eapentru responsabilitat, i diferite de minat, cum ar fi replicarea punctelor de control s, i orchestrareaserviciilor. Acest lucru are ca efect o concurent, a redusa pentru minat, ceea ce reduce dificultateadovezii s, i, prin urmare, cantitatea de energie consumata minand un bloc.

Blockchain-urile Permissioned permit doar unui grup de autorizat de noduri sa participela procesul de creare a blocurilor. In general, acestea asigura un consens mai rapid s, i un fluxmai mare de tranzact, ii. Deoarece nodurile autorizate trebuie sa aiba ıncredere unul ın celalaltınainte de consens, este mai us,or ca acest tip de sisteme sa devina centralizate, daca nu pornescpe acest drum de la ınceput. Cercetarile efectuate ın aceasta teza sunt totus, i aplicabile oricaruiBlockchain capabil sa execute contracte inteligente, optimizand complexitatea sincronizarii.

Intrebari deschise

Utilizarea Blockchain-ului Proof of Work asigura o ordonare s, i validare transparenta s, i siguracriptografic a tranzact, iilor. Acest lucru are o mare valoare pentru activele stocate pe Blockchain,dar nu este ıntotdeauna posibil sa se asocieze activul cu obiectul din lumea reala pe careıl descrie. O asociere slaba face ca un sistem sa fie vulnerabil la diferite tipuri de atacuri.In arhitectura noastra propusa, activele sunt resursele de calcul s, i componentele implicate ıngestionarea sistemului Cloud. Des, i am investigat doar tolerant,a la defect, iuni a sistemului propus,masurile noastre descurajeaza un adversar bizantin sa ıncerce anumite tipuri de atacuri, cumar fi atacul Sybil. Exemplificam posibilitat, ile de atac ın cele ce urmeaza s, i consideram ca suntaspecte importante care necesita formalizare ın domeniul securitat, ii sistemelor distribuite.

Intr-un atac Sybil, un adversar rau intent, ionat ar ıncerca sa ınregistreze aceeas, i resursasub identitat, i diferite, cu scopul de a i se planifica mai multe cereri, astfel obt, inand mai multerambursari. In primul rand, atacatorul ar trebui sa treaca testul de ınregistrare al planificatoruluide resurse, implicand un suita de teste. Suita poate implica citirea unor informat, ii desprehardware pentru a preveni ınregistrarea duplicata a hardware-ului, dar un atacator determinatpoate interfera cu suita s, i poate furniza valori diferite. Daca atacatorul trece acest test, pot fiselectate mai multe instant,e ale aceleias, i resurse pentru a rula servicii diferite. Orchestratoriialocat, i aleatoriu vor monitoriza diferitele servicii, astfel ıncat atacatorul are nevoie fie sa rulezeun serviciu, fie sa controleze Orchestratorul care monitorizeaza serviciul.

Daca atacatorul nu controleaza niciun Orchestrator, atunci executarea tuturor serviciiloratribuite tuturor copiilor Sybil ale unei resurse va duce, la un moment dat, la indisponibilitate.Acest lucru va fi detectat de Orchestratori s, i resursa nu va fi platita. Pentru fiecare Orchestratorcontrolat, atacatorul poate simula executarea serviciului pentru a primi rambursarea. Cu toateacestea, Orchestratorul controlat trebuie sa act, ioneze corespunzator protocolului pentru toatecelelalte planificari, pentru a nu ridica suspiciuni s, i a fi radiat din ret,eaua de administrare. Dacaatacatorul ıncearca sa creeze copii Sybil ale Orchestratorilor, risca sa devina indisponibil ın cazulunui numar mare de servicii gestionate. Cu cat un atacator face mai multe copii Sybil, cu atateste mai mare riscul de defect, iune s, i de a pierde astfel oportunitatea de a cas,tiga.

La prima vedere, atacul Sybil nu poate avea succes fara ca atacatorul sa det, ina fie controlulunor orchestratori, fie sa intervina ın procesul de monitorizare; o condit, ie prealabila pentru acestscenariu este ca atacatorul sa pacaleasca init, ial Managerul de resurse. Cu toate acestea, scenariuleste complex s, i necesita o investigat, ie aprofundata asupra diferitelor niveluri de granularitate.

Bibliografie

[1] David P Anderson. “Boinc: A system for public-resource computing and storage”. In:proceedings of the 5th IEEE/ACM International Workshop on Grid Computing. IEEEComputer Society. 2004, pp. 4–10.

[2] G Breiter, Frank Leymann, and T Spatzier. “Topology and orchestration specification forcloud applications (TOSCA): Cloud service archive (CSAR)”. In: International BusinessMachines Corporation (2012).

[3] Brendan Burns, Brian Grant, David Oppenheimer, Eric Brewer, and John Wilkes. “Borg,Omega, and Kubernetes”. In: Queue 14.1 (Jan. 2016), 10:70–10:93. issn: 1542-7730. doi:10.1145/2898442.2898444. url: http://doi.acm.org/10.1145/2898442.2898444.

[4] Vitalik Buterin et al. Ethereum white paper. 2013. url: https://github.com/ethereum/wiki/wiki/White-Paper.

[5] Christian Cachin and Marko Vukolic. “Blockchains Consensus Protocols in the Wild”. In:arXiv preprint arXiv:1707.01873 (2017).

[6] Bernadette Charron-Bost, Fernando Pedone, and Andre Schiper. “Replication”. In: LNCS5959 (2010), pp. 19–40.

[7] Ioan Dragan, Teodor-Florin Fortis, , Marian Neagul, Dana Petcu, Teodora Selea, and AdrianSpataru. “Application Blueprints and Service Description”. In: Heterogeneity, High Per-formance Computing, Self-Organization and the Cloud. Springer, 2018, pp. 89–117.

[8] Gilles Fedak, Cecile Germain, Vincent Neri, and Franck Cappello. “Xtremweb: A genericglobal computing system”. In: Cluster Computing and the Grid, 2001. Proceedings. FirstIEEE/ACM International Symposium on. IEEE. 2001, pp. 582–587.

[9] Christos Filelis-Papadopoulos, Huanhuan Xiong, Adrian Spataru, Gabriel G Castane,Dapeng Dong, George A Gravvanis, and John P Morrison. “A generic framework sup-porting self-organisation and self-management in hierarchical systems”. In: Parallel andDistributed Computing (ISPDC), 2017 16th International Symposium on. IEEE. 2017,pp. 149–156.

[10] Adrian Spataru Gabriel Gonzales Castane. CloudLightning Use Case evaluation BitbucketRepository - Ray Tracing. https://bitbucket.org/cloudlightning/evaluation_use_cases/src/09ff4fcd0176/raytracer/?at=master. [Last accessed: 15-08-2020]. 2018.

[11] Benjamin Hindman, Andy Konwinski, Matei Zaharia, Ali Ghodsi, Anthony D Joseph,Randy H Katz, Scott Shenker, and Ion Stoica. “Mesos: A Platform for Fine-GrainedResource Sharing in the Data Center.” In: NSDI. Vol. 11. 2011, pp. 22–22.

[12] Leslie Lamport, Robert Shostak, and Marshall Pease. “The Byzantine generals problem”.In: ACM Transactions on Programming Languages and Systems (TOPLAS) 4.3 (1982),pp. 382–401.

[13] Peter Mell and Tim Grance. The NIST definition of cloud computing. 2011.

28

BIBLIOGRAFIE 29

[14] Dirk Merkel. “Docker: lightweight linux containers for consistent development and deploy-ment”. In: Linux Journal 2014.239 (2014), p. 2.

[15] Satoshi Nakamoto. “Bitcoin: A peer-to-peer electronic cash system”. In: URL https://bitcoin.com/bitcoin.pdf (2008).

[16] OASIS. Topology and Orchestration Specification for Cloud Applications (TOSCA) PrimerVersion 1.0. OASIS Standard. Accessed Jan 26, 2017. Jan. 2013. url: http://docs.oasis-open.org/tosca/tosca-primer/v1.0/cnd01/tosca-primer-v1.0-cnd01.pdf.

[17] Marshall Pease, Robert Shostak, and Leslie Lamport. “Reaching agreement in the presenceof faults”. In: Journal of the ACM (JACM) 27.2 (1980), pp. 228–234.

[18] Charles Reiss, John Wilkes, and Joseph L Hellerstein. “Google cluster-usage traces: for-mat+ schema”. In: Google Inc., White Paper (2011), pp. 1–14.

[19] Teodora Selea, Adrian Spataru, and Marc Frincu. “Reusing Resource Coalitions forEfficient Scheduling on the Intercloud”. In: Cluster, Cloud and Grid Computing (CCGrid),2016 16th IEEE/ACM International Symposium on. IEEE. 2016, pp. 621–626.

[20] Adrian Spataru, Laura Ricci, Dana Petcu, and Barbara Guidi. “Decentralized CloudScheduling via Smart Contracts. Operational constraints and costs”. In: The InternationalSymposium on Blockchain Computing and Applications (BCCA2019). 2019.

[21] Adrian Spataru, Teodora Selea, and Marc Frincu. “Online Resource Coalition Reor-ganization for Efficient Scheduling on the Intercloud”. In: International Conference onAlgorithms and Architectures for Parallel Processing. Springer. 2016, pp. 143–161.

[22] Adrian Spataru. “Decentralized and fault tolerant Cloud Service Orchestration”. In:Scalable Computing: Practice and Experience 21.4 (2020), pp. 709–725.