Specializarea Matematică-Informatică [306303]

Ministerul Educației Naționale și Cercetării Științifice

Universitatea „OVIDIUS” [anonimizat]:

Conf. Univ. Dr. Eugen Petac

Absolvent: [anonimizat]

2016

Abstract

Lucrarea este o sinteză și o cercetare a soluției fog computing.

În capitolul 1 se realizează o sinteză a conceptelor Internet of Things (IoT), [anonimizat] (cap 1.4). Tot în capitolul 1 se arată că soluția fog computing reiese ca o soluție necesară în anumite situații în care cloud computing devine insuficientă. [anonimizat], [anonimizat] o [anonimizat] o soluție de reducere a costurilor, sau ca o soluție de green computing.

Capitolul 2 [anonimizat], [anonimizat]. În a doua parte a [anonimizat]-ului de modelare și simularea software CloudSim ca o soluție premergătoare sau alternativă pentru proiectarea și testarea de soluții fog și cloud computing.

Capitolul 3 prezintă aplicația BikeDetector ca o aplicație cu cerințe specifice de fog computing. Sunt prezentate 3 scenarii de lucru (soluții) fog, edge și cloud. Este prezentată schema logică generală de funcționare a [anonimizat], precum și criteriile de analiză ale celor 3 scenarii. [anonimizat]. [anonimizat].

Cuprins

Introducere 1

Capitolul 1. Noțiuni de teorie 3

1.1 Internet of Things (IoT) 3

1.2 Cloud computing 10

1.3 Fog computing 13

1.4 Aplicații fog computing 18

1.5 Alte paradigme 22

Capitolul 2. Elemente de implementare a soluțiilor fog computing 27

2.1 Noduri fog 27

2.2 Dezvoltarea aplicațiilor 29

2.3 Platforma de simulare Cloudsim 31

Capitolul 3. Aplicația BikeDetector 39

3.1 Argument 39

3.2 Scenarii de lucru 39

3.3 Pregătirea mediului de simulare a proiectului BikeDetector 44

3.4 Explicarea codului de simulare pentru BikeDetector 56

3.5 Ipotezele de lucru și datele simulării 61

3.6 Criterii de analiză 64

3.7 Rezultatele simulării 66

3.8 Dezvoltări ulterioare 75

Concluzii 76

Bibliografie 78

Lista Figurilor

Fig. 1 Podul ”inteligent” [anonimizat] [3] 3

Fig. 2 “Internetul lucrurilor a apărut deja”, Michael Enescu, 2014 [4] 4

Fig. 3 [anonimizat] 6

Fig. 4 Conceptul Smart Grid 7

Fig. 5 Arhitectura cloud computing vs client server 10

Fig. 6 Stratul Fog între dispozitive și cloud 14

Fig. 7 [anonimizat] 15

Fig. 8 Fog computing în smart grid 20

Fig. 9 Fog computing în aplicația smart city 21

Fig. 10 [anonimizat] 23

Fig. 11 Dew Computing 25

Fig. 12 Arhitectura IOx [18] 27

Fig. 13 [anonimizat] – Iaas 30

Fig. 14 [anonimizat]oudSim 32

Fig. 15 Schema logică de funcționare a nodului fog 42

Fig. 16 Crearea proiectului BikeDetector în Eclipse 45

Fig. 17 Configurarea JDK în Eclipse 47

Fig. 18 Configurarea JDK în Eclipse – Pas 2 48

Fig. 19 Configurarea JDK în Eclipse – Pas 3 48

Fig. 20 Configurarea JDK în Eclipse – Pas 4 49

Fig. 21 Importarea framework-ului CloudSim în Eclipse 50

Fig. 22 Importarea bibliotecii commons-math3-3.2.jar 52

Fig. 23 Importarea bibliotecii commons-math3-3.2.jar – Pas 2 53

Fig. 24 Mutarea folderului examples în zona de compilare ”src” 55

Fig. 25 Exemplu de output de cod scris pentru simulatorul CloudSim 56

Fig. 26 Costul sistemului de identificare pentru cele 3 scenarii 65

Fig. 27 Costul sistemului de identificare pentru cele 3 scenarii (Oy logaritmic) 65

Fig. 28 Simulare F1 69

Fig. 29 Simularea F2 cu suficientă memorie, dar insuficient mips 70

Fig. 30 Simularea F3 cu număr excedentar de VM-uri 71

Fig. 31 Simularea F4 – număr redus de VM-uri 72

Fig. 32 Simulare F5 – simularea spaceshared 73

Fig. 33 Simulare F6 – spaceshared cu număr optim de VM-uri 73

Fig. 34 Simularea C – a scenariului cloud 75

Lista Tabelelor

Tabel 1 Comparația Cloud Computing – Fog Computing 18

Tabel 2 Comparația puncte terminale (ex. senzori) cu noduri fog 18

Tabel 3 Comparația grid – cloud 24

Tabel 4 Direcționarea datelor în ierarhia de noduri fog [19] 28

Introducere

Modelul de interconectare IoT (Internet of Things) este un model al realității ultimilor ani, în care numărul dispozitivelor inteligente conectate la internet a crescut, raportat la populația globale, cu o rată nemaiîntâlnită la nici o tehnologie în istorie. Se preconizează că până în 2020 vor fi peste 50 de miliarde de dispozitive, iar multe dintre acestea vor fi critice din punct de vedere al stocării de date și timpilor de răspuns în rețea.

Aplicațiile IoT acoperă o varietate extrem de largă de domenii, de la grija față de mediu la un marketing țintă și de la controlul infrastructurii de teren și a rețele de distribuție electrică la o viață de zi cu zi cu posibilități mult mai mari de informare în timp real, în orașele inteligente. Interconectarea dispozitivelor și intersectarea domeniilor creează și premisele unei explozii de aplicații neprevăzute inițial.

Modelul de interconectare al prezentului, cloud computing, nu va putea face față singur cerințelor IoT, deoarece serverele centrale și rețeaua în sine vor fi depășite cantitativ de noile cerințe. Se impune așadar o nouă soluție, care să degreveze modelul cloud de cât mai mult trafic de date și cereri, de procesare și chiar de decizie.

Prin împingerea deciziilor către marginea rețelei prin automatizare și prin filtrarea datelor la nivel de noduri locale, fog computing vine ca o soluție arhitecturală la cerințele IoT. O serie de arhitecturi mai vechi se intersectează cu principiile fog computing și au fost amintite la finalul primului capitol: distributed computing, on-demand computing, cloud computing, ubiquiteous computing sau reprezintă rafinări similare cu fog: dew computing.

În capitolul al 2-lea se prezintă câteva elemente ale implementării arhitecturii fog computing de către CISCO, inițiatorul și promovatorul acestui concept, cum ar fi sistemul IOx, se dau câteva detalii despre tipurile de date din punct de vedere al timpului de răspuns și de tipuri de noduri fog/cloud pe care pot ajunge. Ulterior se argumentează necesitatea utilizării unui simulator software precum CloudSim (care în plus este și gratuit) și se prezintă pe larg arhitectura entităților pe care acesta le simulează, clasele Java care corespund acestor entități și modul lor de utilizare.

Aplicarea de modele matematice și simularea acestora se justifică odată în plus în cazul modelului IoT și soluției fog computing, deoarece IoT presupune un număr mare de elemente care evoluează în timp. Simularea se poate face cu o precizie relativ mare, modelul IoT având un grad mare de predictibilitate, deoarece presupune comunicarea directă a obiectelor inteligente fără intervenția omului.

În capitolul 3 se prezintă aplicația BikeDetector, care întrunește o multitudine de caracteristici ale unei aplicații tipice de IoT și fog computing, și anume un număr mare de noduri, automatizare, distribuție geografică și eterogenitate, volum mare de date, necesități ridicate de procesare, timp de răspuns critic. Sunt prezentate trei scenarii de lucru, fog, cloud și edge, fiecare prezentând anumite avantaje. Se prezintă schema logică internă a unui nod fog, care trebuie să realizeze alocarea resurselor (unități de procesare, stocare, bandă de transfer) astfel încât să se îndeplinească condițiile minime de calitate și fiabilitate ale sistemului de detecție în același timp cu minimizarea informației transmise mai departe către cloud.

Se simulează scenariile în CloudSim. Este indicată pregătirea platformei CloudSim folosind mediul de dezvoltare Eclipse, structura codului de simulare, ipotezele privind datele de simulare, criteriile de analiză și rezultatele simulării. Sunt variați parametrii de simulare: număr de camere și cantitatea de resurse din nodurile fog și cloud (număr de unități de procesare, putere de procesare, memorie etc.), pentru a se conveni asupra scenariilor care produc timpi de răspuns satisfăcători.

Noțiuni de teorie

Internet of things (IoT)

Noțiunea de Internet of things (Internet al lucrurilor) prescurtat IoT, este, conform , “o rețea de obiecte fizice, ce conțin electronica necesară pentru a colecta și transmite date”, așadar obiecte inteligente ce comunică între ele fără intervenția umană. Acest lucru duce la integrarea mai bună a lumii fizice în sistemele computerizate cu efecte științifice și economice rapide.

Un interesant exemplu în acest sens este podul din Minnesota care, în urma dezastrului din 2007 când s-a prăbușit în râul Mississippi făcând mai multe victime, a fost reconstruit anul următor și prevăzut cu un ciment ”inteligent” . Acest ciment conține senzori de monitorizare a tensiuniilor și crăpăturilor, dar și de temperatură pentru detectarea formării gheții pe carosabil. Datele din acești senzori pot avertiza șoferii în timp real asupra riscurilor aferente, iar mașinile inteligente ar putea chiar să încetinească automat, dacă șoferul nu ia nicio măsură. Mai mult, infomațiile de trafic date de senzori pot fi folosite și pentru a adapta semafoarele la intensitatea traficului, etc., aplicațiile mergând așadar către ceea ce se numește o rețea de ”oraș inteligent” (eng. smart city grid).

Fig. 1 Podul ”inteligent” din Minnesota – sursa

Așadar, să detaliem mai întâi originea și definiția termenului de IoT și definițiile elementelor conexe pentru a înțelege mai bine atât mecanismele interne cât și aplicațiile posibile ale acestui concept.

Termenul IoT a fost lansat de Kevin Ashton in 1999 . Ca angajat al Auto-ID Labs, acesta s-a referit la origine la ”rețea globală de obiecte conectate prin RFID.” Termenul s-a îndreptat încă de la început spre o varietate largă de tehnologii de conectare, a ceea ce numim ”obiecte inteligente”, adică obiecte capabile de comunicare. Conectarea acestora permite aplicații avansate precum, de exemplu, rețele inteligente de distribuția energiei (eng. smart grid) sau orașe inteligente (eng. smart city).

Conform lui Michael Enescu, CTO al Open Source Initiatives, care a ținut o prezentare la conferința LinuxCon din 2014, IoT ar fi apărut deja din anul 2008, când numărul dispozitivelor conectate la Internet a depășit populația mondială, conform graficului de mai jos.

Fig. 2 “Internetul lucrurilor a apărut deja”, Michael Enescu, 2014

Se estimează că până în 2020 numărul acestor obiecte inteligente va fi de 50 sau chiar 250 de miliarde, această creștere fiind de 5 ori mai rapidă decât în cazul adoptării altor tehnologii din istorie precum electricitatea sau telefonia.

Obiecte inteligente

Noțiunea de obiect inteligent cuprinde astăzi o varietate largă de obiecte capabile să achiziționeze și să transmită date, de exemplu:

Implanturi de monitorizare a bătăilor inimii

Biochip-uri implantate animalelor din ferme

Automobile cu senzori integrați

Dispozitive de analiză ADN pentru monitorizare mediu/mâncare/elemente patogene

Dispozitive folosite de pompieri în timpul intervențiilor

Mașini de spălat/uscătoare cu monitorizare WiFi

Dispozitive de pe teren care pot raporta starea lor, primi comenzi etc (de ex. sonde de petrol, macarale)

Aplicații IoT

Aplicațiile IoT sunt totuna cu aplicațiile obiectelor inteligente, deși posibilitățile de interconectare sunt limitate doar de imaginație. Ele cuprind:

Un marketing mai targetat

De exemplu o așezare a produselor în magazin în funcție de felul în care se constată că se plimbă clienții prin acesta. Informațiile legate traseul clienților pot proveni de la telefonul mobil al acestora, care între altele poate avea încărcate și informații provenite de la frigiderul inteligent, care a comunicat telefonului ce conține și, automat, ce lipsește.

Monitorizare de mediu

Prin senzori se pot monitoriza calitatea apei, starea solului, mișcările animalelor în sălbăticie și habitatele lor naturale,

Infrastructură

Controlul podurilor, căilor ferate, al morilor de vânt, etc. atât activ, cât și din punct de vedere al stării de funcționare și deci al riscurilor, al planificării reparațiilor, etc.

Transport

De exemplu, modelul ITS (Intelligent Transport System) care presupune monitorizarea traficului dintr-un oraș prin senzori wireless și supraveghere video și transmite informații pe mobilele utilizatorilor luând în calcul coordonatele GPS, astfel încât aceștia să poată evita traficul și accidentele.

Orașe inteligente (eng. smart city)

Servicii Wifi, parcări, iluminat, siguranță, transport etc. O adevărată explozie de concepte inteligente, așa cum indică figura de mai jos.

Fig. 3 Smart city, aplicație IoT

Fabricație

Eficiență crescută a produselor, folosirea mai bună a activelor și accesul securizat la procesul de producție.

Energie (eng. smart grid)

Atât zona de consum cât și cea de producție pot beneficia de avantajele interconectării pentru o distribuție mai bună a energiei, contorizări automate, detectarea scurgerilor, etc.

Fig. 4 Conceptul Smart Grid

Extrapolări

Există aplicații pe care nici nu le bănuim în momentul proiectării obiectelor inteligente, care provin din interconexiunile ulterioare. De exemplu, la introducerea de către Facebook a facilității de check-in, aceasta a fost concepută pentru a da o indicație asupra poziției geografice a abonatului. Ulterior s-a descoperit că funcția poate fi folosită și, de exemplu, pentru a indica la care dintre restaurante este o coadă mai lungă de clienți.

Cerințe IoT

Caracteristicile principale ale modelului IoT, legate de necesitățile care se impun, sunt:

Se conectează un număr mare de obiecte (între 50 și 100 bilioane )

Se generează cantități foarte mari de date din diverse locații (conform , 90% din datele generate în lume au fost generate doar în ultimii 2 ani). Aceste date trebuie:

agregate, indexate

stocate

procesate rapid

Soluții tehnice

Provocările noi ale IoT sunt cele care impun o nouă abordare tehnologică, care să integreze de asemenea rețelele existente și să suporte noile cerințe.

De exemplu domeniul de adrese IPv4 este limitat la 4.3 miliarde de adrese, de aceea IoT se va baza pe IPv6, a cărui adoptare generalizată în viitor este critică. Pentru conectarea dispozitivelor la rețelele IP, se poate folosi, de exemplu, standardul 6LoWPAN (IPv6 over Low power Wireless Personal Area Networks), elaborat de organizația IEFT (Internet Engineering Task Force). Acest standard a fost gândit în ideea că IP (Internet Protocol) poate și trebuie folosit pe dispozitive oricât de mărunte.

O mare problemă o reprezintă nu atât numărul obiectelor IoT, cât cantitatea de date generate de acestea. Site-ul IoT Agenda prezintă într-o publicație online câteva aspecte generale ale circulației datelor în IoT:

1. Raportarea

Datele sunt prioritizate, astfel încât, atunci când latența rețelei este ridicată, trec doar pachetele cu prioritate ridicată. Când latența scade, se trimit și pachete cu prioritate 2. Pachetele cu prioritate foarte redusă, 3 sau 4, vor fi trimise abia când dispozitivul ajunge acasă, de exemplu.

2. Agregarea

Agregarea datelor venind de la foarte multe dispozitive, depășește viteza de răspuns a unei baze de date relaționale clasice. Se propune folosirea bazelor de date NoSQL, care au condiții mai relaxate privind legăturile datelor, dar viteză și capacitate crescuta, sau folosirea clusterelor Hadoop, care răspund mai bine blocurilor mari de date.

3. Analiza

Diferența în instrumentele de analiză o face faptul că ele trebuie să fie compatibile și cu noile platforme de agregare (Hadoop, cloud warehouse, tool-uri Amazon WebServices, baze de date NoSQL).

Dacă vorbim despre volumul mult prea mare de date ce vor fi generate în viitor, acestea nu vor mai putea fi nici transportate și nici stocate doar prin soluțiile de cloud computing actuale. Discuția se mută de la transportul datelor către inteligența despre date, analiză și decizii înaintea oricărui transport. Cu alte cuvinte, trebuie schimbată însăși arhitectura rețelei, și aici intervin modelele de tip edge computing (cum este și fog computing), detaliate în lucrare. Practic, dacă în paradigma cloud computing, datele vin către servere pentru a fi stocate și analizate, în edge computing, aplicațiile vin către date, în zona în care acestea sunt generate, sau cu alte cuvinte, datele capătă o mai mare greutate în mișcarea ascendentă către Internet și sisteme cloud, fenomen etichetat și drept gravitația datelor (eng. data gravity) , multe dintre date rămânând într-un final la nivel edge, unde sunt fie stocate fie eliminate periodic.

Alte aspecte legate de IoT

Termenul IoT este uneori asimilat cu M2M, adică comunicații mașină-mașină, indicând lipsa necesității curente a intervenției umane.

Site-ul wired.com avertiza într-un articol din noiembrie 2014 că veștile mari, în genul IoT, rețeaua de comunicare directă între tot felul de senzori “inteligenți”, sunt adesea despre lucruri pe care le știm deja, care erau deja în jurul nostru, dar pe care nu le observam în trecut, și că revoluția IoT nu s-ar referi doar la comunicațiile mașină-mașină M2M, despre care toată lumea vorbește ci într-o mare măsură la senzori. Senzorii, așa cum bine remarcă autorul articolului, nu sunt mașini, și marea realizare a IoT este tocmai interconectarea acestora cu mașinile (dispozitivele inteligente) astfel încât datele acumulate de aceștia să poată fi exploatate în timp real și să nu se ”piardă” în rețele locale, baze de date, etc. Articolul menționat pune accent pe aceste ”leveraged data”(trad. date consolidate) și menționează aplicațiile cloud ca fiind instrumentele principale de gestionare a acestor date.

Internet of Everything (IoE)

Cisco extinde termenul de IoT la IoE atunci când îl asociază cu tehnologia Fog Computing pe care o promovează, incluzând următoarele:

Oameni (pe care îi interconectează într-un mod mai relevant)

Date (care devin leveraged data, adică date inteligente capabile de decizii)

Procese (se furnizează informația care trebuie la punctul care trebuie în timpul care trebuie)

Lucruri (sau obiecte inteligente) din paradigma IoT

De fapt acesta fiind doar un alt mod de a privi aceeași realitate, un soi de termen de marketing pentru aceeași realitate.

Tipurile de comunicații se extind și ele la mai multe categorii:

M2M (Machine to Machine), adică mașină-mașină

M2P (Machine to Person), adică mașină-persoană

P2P (Person to Person), adică persoană-persoană

Cloud computing

Istoric vorbind, arhitectura cloud-computing este o evoluție față de modelul client-server care folosea o singură conexiune la Internet și domină acest model datorită democratizării conexiunilor la Internet, a conexiunilor în bandă largă și a conectivității Wireless.

Fig. 5 Arhitectura cloud computing vs client server

Conform , cloud computing este un stil de programare în care resurse scalabile dinamic sunt oferite ca un serviciu pe Internet.

Conform definiției , scopul oferirii acestor resurse pe Internet este de a putea oferi utilizatorilor capacitate de stocare și procesare la cerere (eng. on demand computing) pe o durată oarecum limitată, după care resursele vor fi realocate parțial sau total unui cu totul alt task.

Beneficii

Vorbim așadar nu doar despre scalabilitate, ci și despre reutilizare, ambele traducăndu-se în eficiență economică în comercializarea de resurse, dar și în eficiență în consumul energie global în scopul satisfacerii acelorași nevoi.

Conform , aceste resurse, care cuprind rețele, servere, stocare, aplicații și servicii oferă utilizatorului avantajul principal al flexibilității accesului prin interfața Web de oriunde și de pe diverse dispozitive, dar și al unei flexibilități de business în acțiunea de vânzare-cumpărare de resurse IT. Din acest punct de vedere, modelul cloud computing ar corespunde modelului din lumea reală al închirierii de resurse, spre deosebire de modelul mai greoi al vanzării. și în plus, acestă închiriere de resurse se face în mare parte automat.

În multe dintre cazuri vorbim și despre avantajul unor resurse de cloud net superioare unor resurse locale. De exemplu, dacă vorbim despre stocare, hard disk-ul virtual numit Google Drive, oferă în 2016 o capacitate de 15GB în mod gratuit, în timp ce un device precum un smartphone, căruia nu i se adaugă, să zicem, o memorie SD, are un spațiu de stocare liber care se umple rapid după instalarea câtorva aplicații, ajungând la căteva sute de MB. Dacă vorbim despre procesare, o operație de filtrare a e-mail-urilor din căsuța poștală durează mult mai mult pe smarphone decât pe cloud, deoarece puterea de procesare a smarphone-ului, și chiar cea a unui PC, este net inferioară vitezei de procesare și paralelismelor care se realizează pe serverele unui cloud.

Un alt beneficiu ține de ușurința în utilizare a interfețelor Web, cu un oarecare grad de universalitate, și eliberarea utilizatorilor de necesitatea învățării unor specificații și detalii.. Folosirea unei căsuțe poștale ”online”, de exemplu, capabilă să și stocheze e-mail-uri și furnizănd aplicații pentru prelucrarea acestora este mai facilă decât instalarea, învățarea și utilizarea unor aplicații client specifice (de tip MS Outlook).

Tehnologii

Istoric vorbind, cloud computing a apărut ca o evoluție firească, conform , în contexul următoarelor:

rețelelor de mare capacitate

computerelor și device-urilor ieftine cu putere de calcul mai scăzută

adoptării virtualizării hardware

arhitecturilor orientate server

programării autonome și la cerere (eng. autonomic computing, utility computing)

Cloud computing nu exclude tehnologii mai vechi de rețea, cum ar fi:

programarea distribuită

programarea paralelă (eng. parallel computing)

programarea la cerere (eng. utility computing)

tehnologii de stocare în rețea

virtualizare

echilibrarea sarcinii (eng. load balance) etc.

În sprijinul ideii de cloud computing, marile companii precum Google, Microsoft, Yahoo și IBM creează imense noduri de date prin întreaga lume (eng. data centers) care să deservească această tehnologie.

Provocări și probleme

Conform aceluiași articol , provocările principale cărora trebuie să le facă față tehnica de alocare a resurselor, unul din elementele cheie ale cloud computing, sunt următoarele:

echilibrarea sarcinii în rețea

durata de viață a pachetelor de date

calitatea serviciilor

consumul de energie

În viitor se consideră că evoluția numărului de obiecte din IoT va depăși capacitatea modelului Cloud, care nu va putea rezolva singur această evoluție datorită următoarelor aspecte:

prea multe date

latență ridicată

cost de transport prea mare

rezistență de ansamblu a sistemului scăzută

Așa cum amintește articolul , calitatea serviciilor are de suferit deoarece sunt prea multe date, rutele datelor sunt lungi, există și o neomogenitate ridicată a sistemelor și se vor produce în consecință întârzieri în rețea și ”gâtuiri” (eng. bottlenecks) ale rețelei. Aceste efecte se traduc la clienți prin fenomenele de latență în rețea (eng. network latency) și/sau limitarea fluxului de date (eng. limited bandwidth), care în anumite situații nu se mai referă doar la calitatea serviciilor, ci sunt chiar critice (benzi de producție, simulatoare, etc. și orice aplicații critice d.p.d.v. al timpilor de ordinul fracțiunilor de secundă). Așadar, principala problemă care apare este fiabilitatea și supraviețuirea sistemului cloud în sine.

Comparândul cu modelul fog, putem vorbi și despre aspecte strict calitative, cum ar fi costul ridicat al transportului datelor (distanțe mai lungi) sau despre faptul că marile data center-uri create de Google, etc. fiind foarte mari și deservind foarte mulți clienți sunt ineficiente energetic datorită distanțele pe care le deservesc și complexității lor.

O altă problemă a datelor în cloud computing, care traversează distanțe mari, este securitatea și dreptul la intimitate , modelul fog aducând și aici îmbunătățiri.

Articolul de exemplu, conchide cu nevoia de soluții alternative, precum ”green cloud computing”, care rezolvă o parte din aceste probleme, în special cea a eficienței energetice. O soluție mai completă este reprezentată de noua arhitectură promovată de Cisco Systems sub numele de fog computing.

Fog computing

Fog computing este un termen introdus de Flavio Bonomi, vicepreședinte al Cisco Systems la o prezentare a ACM International Workshop on Vehicular Inter-Networking (VANET) în Septembrie 2011, ca ”un model de facilitare a transferurilor de date fără fir către dispozitivele distribuite ale IoT”. Cisco mai definește fog computing și ca ”o paradigmă ce extinde cloud computing către marginea rețelei”. În timp ce ”Cisco Fog Computing” este o marcă înregistrată, ”fog computing” este lăsat comunității pentru a fi folosit în ideea analogiei cu arhitectura cloud, adică în ideea că ceața nu reprezintă altceva decât un nor aflat mai aproape de pământ.

Fig. 6 Stratul Fog între dispozitive și cloud

Conform , fog computing oferă servicii de date, procesare, stocare și aplicații în dispozitive aflate mai aproape de client, cum ar fi routerele de rețea, practic gestionând datele la nivel de rețea pe dispozitive inteligente și dispozitive mobile, fără a mai trimite datele la distanță către noduri centrale (cloud) pentru stocare sau procesare. Pe scurt, așa cum menționează și , principalul job al Fog Computing este să poziționeze informațiile mai aproape de client.

Așa cum se observă în Fig. 7, fog computing intervine ca strat intermediar în arhitectura cloud existentă, între dispozitive (”device” în fig.) fără putere de calcul sau stocare suficientă și cloud. Principalul job acestui strat este de filtrare a datelor, dar și acela de a degreva cloud-ul de acțiuni de analiza sau procesarea datelor sensibile la timp / în timp real.

Fig. 7 Procesarea datelor pe dispozitiv, fog și cloud

Această poziționare mai aproape de client este marketată de CISCO ca având beneficii de business imediate. Thorsten Shaefer, CEO Azeti și important implementator al Cisco Fog Services, declară într-un interviu din ianuarie 2016, că folosește servicii fog pentru a evita aglomerarea cloud-ului și în ultimă instanță pierderi datorate latenței în rețea și imposibilității de a lua decizii la timp. Prin serviciile fog, se iau ”decizii automome la nivel edge, controlate de pe cloud”, sau, mai pe scurt, ”configurarea se face pe cloud, iar execuția se face pe edge”, sau, așa cum s-a exprimat Vikas Butaney, GM IoT Systems la Cisco, în același interviu ”se setează politica la nivel de cloud, dar se execută la nivel edge”, care va lua decizii locale automate.

De asemenea, implementarea soluției Fog Computing este vândută, în special către zona industrială și de afaceri, și sub umbrela beneficiilor paradigmei IoT și a controlului de la distanță în general, ca o soluție ce nu necesită mari costuri suplimentare, pentru că nu presupune înlocuirea dispozitivelor, ci doar transformarea lor în obiecte inteligente. Pentru multe companii, din domeniul producției, de exemplu, este vorba despre a privi vechile active într-o lumină nouă și a le interconecta la un sistem. O macara de exemplu poate fi integrată în sistemul IoT prin Fog Computing pentru a i se cunoaște în timp real starea de funcționare, etc. și pentru a se evita mai bine oprirea producției. Se vorbește și despre transformarea produselor în sine, în servicii, deoarece prin controlul exact în timp real, ”se va putea vinde, de exemplu, aer comprimat, în loc să se vândă pompele care îl produc”, care ar putea rămâne doar închiriate de către client, precizează același interviu .

O altă definiție a fog computing ce pune accent pe latura de colaborare automată (IoT) și de închiriere de resurse (utility computing), larg citată în articolele de specialitate, definește fog computing drept ”un scenariu în care un număr imens de dispozitive eterogene (wireless și uneori autonome), omniprezente și descentralizate, comunică și cooperează potențial între ele și cu rețeaua pentru a efectua sarcini de stocare și procesare fără intervenția vreunui terț. Aceste sarcini pot fi destinate unor funcții de bază ale rețelei sau noi servicii și aplicații care rulează într-un mediu sandbox. Utilizatorii închiriază o parte a dispozitivelor lor pentru a găzdui aceste servicii și primesc stimulente pentru a face asta.”.

Caracteristici Fog

Conform , , dar și cf. articolului „Fog Computing and the internet of things” , publicat de Cisco Systems în 2012, noua paradigmă are următoarele caracteristici:

Proximitatea față de utilizatori, prin latență scăzută și localizare exactă

Distribuție geografică largă (și densă cf. ).

Nodurile fog trebuie plasate în multe locuri, aproape de orice aplicație și de asemenea trebuie să aibă o oarecare densitate (de ex. din loc în loc de-a lungul unei autostrăzi inteligente).

Mobilitate

Multe din aplicațiile Fog comunică cu dispozitive mobile și implementează tehnică mobilă, precum protocolul LISP, care decuplează identitatea de locație

Număr mare de noduri

Rol predominant al accesului wireless

Prezență puternică a fluxurilor și aplicaților în timp real

Neomogenitate (sau eterogenitate)

Fog computing este o platformă puternic virtualizată care oferă procesare, stocare și servicii de rețea pentru o varietate mare de dispozitive finale, iar plasarea sa la marginea rețelei o transformă într-o extensie netrivială a cloud-ului.

Interoperabilitate și standardizare

Este necesară cooperarea furnizorilor pentru anumite servicii și acestea trebuie standardizate de-a lungul mai multor domenii (de ex. pentru serviciul de streaming).

Avantajele prezentate de modelul Fog Computing sunt (cf. ):

reducerea traficului de date, așadar

reducerea costurilor

reducerea congestiilor

reducerea latenței

consum mai mic de bandă

consum mai mic de energie

eliminarea congestiilor produse de modelul centralizat

creșterea securității datelor care rămân mai aproape de client

edge computing cu avantajele aferente față de cloud, adică scalabilitate, fiabilitate și toleranță la erori

Comparația cu alte modele

Comparația Fog Computing cu modelul din care derivă, Cloud Computing, este sintetizată în următorul tabel:

Tabel 1 Comparația Cloud Computing – Fog Computing

Totuși, nodurile Fog nu vor fi implementate nici la limita de jos a rețelei, pe dispozitive finale (de exemplu în senzori), ci la un nivel intermediar, care oferă anumite avantaje, sintetizate în tabelul de mai jos:

Tabel 2 Comparația puncte terminale (ex. senzori) cu noduri fog

Alte aspecte

Arhitectural, se atrage atenția că în ciuda avantajelor pe care le are, Fog Computing nu va înlocui Cloud Computing în totalitate, ci doar pentru un anumit set de aplicații și pentru anumite verticale economice, și de asemenea nu își dorește să reinventeze o tehnologie, ci doar să îmbunătățească ceea ce există deja.

Aplicații fog computing

Pentru o mai clară conturare a termenului fog, s-a considerat necesară o trecere în revistă a aplicațiilor sale posibile, pe care le-am împărțit în câteva categorii importante: aplicații provenind din zona cloud (din limitările cloudului), aplicații provenind din zona edge (computational offloading) și aplicații provenind din alte surse.

Uneori aceeași aplicație poate aparține mai multor categorii, cum este de exemplu smart city, care deopotrivă depășește limitările privind latența mare din cloud și de asemenea realizează degrevarea dispozitivelor edge de anumite operații intensive pe imagine video de exemplu.

În final am detaliat sumar câteva aplicații concrete.

Aplicații provenite din limitări ale cloud

Cloud-ul a fost gândit pentru a elibera utilizatorul de detalii de implementare cu privire la locul unde are loc exact procesarea sau stocarea. Această libertate, utilă în multe cazuri, devine o problemă la aplicațiile în care latența sau sincronizarea este importantă. Fog computing a fost gândit pentru a se adresa aplicațiilor și serviciilor care nu se potrivesc din acest punct de vedere paradigmei cloud:

aplicații care necesită latență scăzută sau previzibilă: gaming, video, conferințe, aparatură de diagnoză sau antrenament medical conectate la internet care necesită feedback în timp real

aplicații geo-distribuite: monitorizarea rețelelor de conducte, rețele de senzori de monitorizarea a mediului

aplicații mobile rapide: automobile inteligente, transport feroviar

sisteme mari distribuite de control: smart grid, transport feroviar, sisteme de semafoare inteligente, smart city

Aplicații provenite din limitări edge

O altă direcție de dezvoltare a aplicațiilor fog este degrevarea dispozitivelor IoT de operații de procesare sau stocare care le depășesc momentan capacitățile, temen cunoscut în limba engleză drept computational offloading.

Dintre aplicațiile care necesită latență scăzută amintim de exemplu augmented reality (AR) și analiza video în timp real. În domeniul AR există aplicații de smartphone, tabletă, etc. cât și proiecte precum Google Glass, Sony SmartEyeglass și Microsoft HoloLens. Toate aplicațiile AR necesită putere mare de procesare care ar putea fi găsită în noduri fog din apropiere.

Un alt exemplu este smart city, unde video-ul poate fi trimis către noduri fog cu capacitate de stocare și procesare superioare. Procesare superioară poate fi necesară, de exemplu, pentru recunoașterea obiectelor, urmărire, data mining etc. Ulterior se vor trimite către clienți, baze de date etc. doar notificări, rezumate video, etc.

Aplicații provenite din alte surse

Aplicații noi apar și din trăsătura de edge computing a paradigmei fog. Apropierea de clienți permite o mai bună cunoaștere a condițiilor locale ale traficului în rețea și o mai bună optimizare locală a streamingului, cache-ului necesar etc. pentru livrarea de conținut web.

Studiu de caz: Aplicația smart grid

Aplicațiile de echilibrare a sarcinii în rețeaua de distribuție a energiei pot să se bazeze pe dispozitive edge cum ar fi contoare inteligente (eng. smart meters) și structuri micro-grid. În funcție de cererea de energie, disponibilitate și preț minim, aceste dispozitive pot să comute automat către surse mai ieftine de energie precum energia solară sau eoliană. Așa cum arată Fig. 8, colectoarele din fog apropiate de marginea rețelei procesează datele generate de senzori și dispozitive ale grid-ului și emit comenzi către dispozitivele de acționare.

Fig. 8 Fog computing în smart grid

De asemenea nodurile fog filtrează datele de interes local și trimit restul datelor mai sus pentru vizualizare, rapoarte în timp real și analiză tranzacțională. Arhitectura fog suportă stocarea efemeră în partea de jos (terminală) a rețelei și stocare semipermanentă în partea superioară.

Acoperirea globală este oferită de cloud care efectuează și analize de business.

Studiu de caz: aplicația smart city

Deoarece conceptul smart city este vast, vom exemplifica folosind doar două dispozitive IoT, sistemul de semaforizare inteligent (eng. smart traffic lights) și autovehiculele inteligente (eng. smart vehicle).

Camerele video care sesizează girofarul unei ambulanțe pot modifica semafoarele astfel încât să se creeze un culoar de circulație continuu pentru aceasta. Sistemul de iluminare inteligent se aprinde pe măsură ce sesizează mișcare, adică pietoni, bicicliști, mașini și se stinge la dispariția traficului.

Fig. 9 Fog computing în aplicația smart city

Se crează practic o rețea cu comunicare wireless între puncte de acces WiFi, 3G, unități de pe marginea drumului, semafoare sau stâlpi inteligenți etc. La rândul ei, această rețea fixă comunică cu vehiculele mobile inteligente. Vehiculele pot primi avertizări de la rețeaua de puncte fixe sau de la alte vehicule aflate în mișcare etc., de exemplu cu privire la traficul în timp real, posibilitatea unui traseu liber etc.

Alte paradigme

Pentru înțelegerea locului în care se plasează modelul Fog Computing în lumea tehnologiei, prezentăm câteva modele similare.

Distributed computing

În esență, reprezintă rezolvarea unei probleme pe mai multe calculatoare, în paralel. Sistemul distribuit nu are un ceas global, calculatoarele sunt independente, fiecare cu ceasul propriu și memoria proprie și comunică între ele prin mesaje. Sistemul este de asemenea tolerant la dispariția unui calculator.

Modelele, mare parte prezentate în continuare, grid, cluster, p2p și ubiqutous computing în sens strict, dar și cloud, fog și dew în sensul colaborării dintre client și cloud, respectiv nod fog etc., în rezolvarea unei probleme sunt exemple de distributed computing.

Utility computing

Reprezintă alături de mai noile grid computing sau cloud computing, un model de furnizare de resurse de calcul la cerere (eng. on demand computing). Principiul utility computing este că aceste resurse – putere de procesare, capacitate de stocare și servicii sunt măsurate și tarifate în consecință în momentul livrării. Analog principiului închirierii oricăror resurse, se încearcă maximizarea folosirii acestora în sensul rentabilizării lor. Utility computing are sens pentru client deoarece nu presupune o investiție inițială.

Modele grid/cluster și cloud computing au fost construite având la bază conceptul de închiriere a resurselor numit utility computing.

Grid computing

Model de interconectare a mai multor puncte de calcul într-un sistem distribuit, cu proprietatea că fiecare nod se ocupă de rezolvarea unei sarcini distincte astfel încât împreună, grid-ul este capabil să rezolve sarcini mai mari, în stilul unui super computer virtual. Punctele de calcul sunt eterogene, atât hardware, cât și software și se pot afla în rețele diferite. De asemenea managementul job-urilor nu este neapărat centralizat.

Fig. 10 Grid computing, model de calcul distribuit

Grid computing este într-un fel o evoluție a unui model anterior, mai simplu, de împărțire a unei sarcini, numit cluster computing, în care punctele de calcul se află într-o rețea locală și împart aceleași resurse, sau conform altor definiții, punctele de calcul sunt omogene atât hardware cât și software și au un management al job-urilor centralizat.

Dacă este să comparăm cu modelul cloud computing, unde avem un singur proprietar și mai mulți utilizatori, precum și resurse centralizate, modelul grid computing este mai descentralizat, i.e. există mai mulți proprietari și utilizatori care beneficiază în moduri diverse de o aceeași rețea, iar resursele în sine sunt distribuite în diverse puncte de calcul în mai multe rețele. Modelele sunt chiar opuse, dacă ne gândim că grid computing rezolvă o singură problemă pe mai multe computere, în timp ce cloud computing rezolvă mai multe probleme printr-un același punct central. Diferențele grid-cloud sunt sintetizate și în tabelul de mai jos:

Tabel 3 Comparația grid – cloud

Modelul grid computing are aspecte comune cu fog computing, în sensul că ambele sunt folosite pentru sporirea resurselor de calcul și stocare, doar că grid computing nu pune accentul pe viteză ci pe rezolvarea unor probleme de dimensiuni mari din cercetare, modelare, design, vizualizare etc care sunt rare în raport cu dimensiunea rețelei, în timp ce fog computing vine în sprinjinul realității numită IoT pentru a evita aglomerare rețelei și pune accentul pe viteză și pe rezolvarea a mai multor probleme de dimensiuni mai mici, cât mai aproape posibil de originea lor.

Peer to peer

Este o arhitectură computațională și de rețea care presupune colaborarea de pe poziții egale a două sau mai multe unități (eng peers, trad. colegi), fără arbitrajul unui server, prin comunicare directă. Modelul este opus celui server-client. Ambele unități într-o relație P2P pot fi pe rând server sau client, adică furnizori și consumatori de resurse. Sistemul a fost popularizat în 1999 de Napster, un sistem de distribuire a fișierelor, prin care calculatoare conectate la internet puteau primi și emite la rândul lor fișiere .mp3 și nu numai.

Modelul fog computing împărtășește cu modelul p2p ideea de descentralizare și de comunicare la nivel local.

Ubiquitous computing

Paradigmă a calculatorului omniprezent, care extinde desktop computing la orice device cu capacitate de calcul, de la telefon la un frigider inteligent. Mai este numit și pervasive computing (trad. procesare generalizată), inteligență ambientală sau everyware. Termenul a fost inițiat de Mark Weiser de la Xerox în 1998 și vine dintr-o zonă filosofică.

Ubiquitous computing ridică probleme legate de intimitate și de definire exactă a conținutului, din moment ce acesta ia forme extrem de diverse, pe o varietate largă de interfețe.

Modelul IoT și fog computing se intersectează cu paradigma ubiquitous computing prin noțiunea de obiect inteligent.

Dew computing

Dew computing, ca și fog computing, este o tot o paradigmă apărută post cloud computing, care are ca țintă dispozitivele locale (PC, laptop, tabletă, smartphone) și are un dublu scop:

oferirea de microservicii independente de cloud pe dispozitivele locale

echilibrarea sarcinii între dispozitivele locale și nivelul cloud

Fig. 11 Dew Computing

La origine, în 2011, paradigma Dew oferea site-uri web fără obligația unei conexiuni în timp real la Internet, ulterior dezvoltându-se. Într-un articol comparativ din 2015, Yingwei Wang observă că în timp ce fog computing se referă mai mult la dispozitive automatizate (senzori, routere, servere) deoarece are la bază modelul IoT, dew computing implică mai mult dispozitivele acționate uman (calculatoare, smartphone etc) și se află chiar la capătul rețelei (la cel acționat uman) spre deosebire de fog computing, care se află în apropierea capătului.

Tehnologia dew computing pe dispozitive mobile introduce și termenul de cloudlet (”norișor”).

Edge computing

Edge computing presupune descentralizarea modelului cloud computing către marginea rețelei, idee cuprinsă în toate paradigmele care fac acest lucru: fog computing, dew computing, cloudlet.

Elemente de implementare a soluțiilor fog computing

Noduri fog

Ideea nodurilor fog și a fog computing pleacă și de la resursele pe care routerele comerciale au început să le ofere, cum ar fi viteza procesorului, numărul de nuclee, capacități de stocare în rețea. Generalizând ceea ce oferă aceste dispozitive, s-au definit nodurile fog, ca fiind elemente de infrastructură capabile să ofere resurse pentru servicii la marginea rețelei.

Nodurile fog pot fi reprezentate de dispozitive cu resurse puține, cum ar fi set-top box, access point, router, switch, dispozitive finale – sau de dispozitive bogate în resurse – Cloudlet sau IOx. Cloudlet-ul este, conform , un computer bogat în resurse de tipul ”cloud in a box”, utilizabil de către dispozitivele mobile din apropiere și este o tehnologie concurentă, dar perfect asemănătoare cu IOx, care este o platformă produsă de Cisco.

IOx funcționează prin găzduirea de aplicații într-un Sistem de Operare Gazdă (GOS) care, la rândul său, funcționează într-un hypervisor direct pe routerul CGR.

Fig. 12 Arhitectura IOx

Decizii la nivel de noduri fog

Pentru implementarea soluțiilor Fog Computing, ”trebuie portate sau scrise aplicații care să funcționeze la nivel de noduri fog” . Rolul principal al acestor aplicații este de a ”direcționa datele către locurile optime pentru analiză”, adică de a lua decizii în privința datelor acumulate de la dispozitive și de trimitere către nodurile optime, mai sus de acestea datele fiind puternic filtrate.

Directarea datelor mai jos sau mai sus în ierarhie depinde de tipul acestora, astfel:

datele sensibile d.p.d.v. al timpului în care trebuie procesate (fracțiuni de secundă) vor fi păstrate cât mai aproape de obiectul inteligent, pentru a evita orice latențe nepermis de mari

datele care pot aștepta secunde sau minute sunt pasate către nodurile de agregare pentru analiză și acțiune

datele mai puțin sensibile la timp sunt trimise în cloud pentru analize istorice, analize pe volume mari de date și stocare pe termen lung. Poate fi vorba doar despre rezumate ale datelor, nu despre date integrale.

Alegerea tipului de nod către care se trimit datele este sintetizată de următorul tabel:

Tabel 4 Direcționarea datelor în ierarhia de noduri fog

Rolul nodurilor fog este:

să primească date de la obiectele IoT folosind orice protocol, în timp real

să execute aplicații compatibile IoT pentru controlul și analiza în timp real, cu timp de răspuns de ordinul milisecundelor

să ofere stocare temporară, adesea 1-2 ore

să trimită rapoarte de date (eng. data summaries) periodic către cloud

Rolul care revine cloudului:

primește și agreghează rapoartele de date de la mai multe noduri fog

analizează datele IoT și alte date pentru a dezvolta decizii de business

poate trimite noi reguli nodurilor fog pe baza analizelor

Implementare

Din punct de vedere al CISCO, de exemplu, nodurile fog pot rezita pe rutere, switch-uri, puncte de acces wireles, camere de supraveghere video și servere Cisco Unified Computing System (UCS). Toate aceste noduri trebuie să aibă capacitate de:

procesare

conectivitate

stocare

Dezvoltarea aplicațiilor

Cloud și fog computing au apărut ca tehnologii de vârf pentru furnizarea de servicii de calcul fiabile, sigure, tolerante la erori, durabile și scalabile, care sunt prezentate ca ”Software, Infrastructură, sau Platformă ca și servicii” (SaaS, IaaS, PaaS). Mai mult decât atât, aceste servicii pot fi oferite în centre de date private (nori privați), pot fi oferite în scop comercial pentru clienți (nori publici), sau este posibil ca norii publici și privați să fie combinați în nori hibrizi.

Aceleași aplicații scrise odată trebuie să poată fie executate pe diverse noduri, fără modificări.

Pentru a dezvolta mai ușor aplicații în fog, Cisco replică modelul de dezvoltare al aplicațiilor folosit pe cloud, folosind SaaS, care cuprinde IaaS și PaaS.

Conform IaaS , aplicațiile scrise folosind API-urile Cisco IOx pot comunica cu obiecte IoT care folosesc orice protocol și transmite datele provenite din protocoale ne-standard, către cloud, care folosește IP.

Conform, PaaS, folosind Cisco DSX dezvoltarea aplicațiilor se ușurează astfel

abstractizarea obiectelor fizice

suport pentru diferite medii de dezvoltare

management al aplicațiilor fog

Fig. 13 Servicii SaaS – PaaS – Iaas

Mai mult, conform MaaS, se poate vinde o mașină cu doar un subset de funcții activate dintre cele de care mașina este deja capabilă.

Pentru a gestiona volumele, diversitatea și viteza datelor, Cisco oferă Cisco Fog Data Services, ca și API-uri REST. Aceste API-uri oferă:

analiză date pentru limitarea lor la nivel edge (data thresholding) și pentru analiza fluxului (streaming analytics)

securitate

controlul unificat al senzorilor

Deocamdată, conform site-ului Cisco, serviciile Fog Data Services sunt suportate pe platforme fizice cum ar fi serverele Cisco UCS C/E sau router-ele Cisco 800.

Aceste API-uri și platformele fizice care le suportă sunt soluții contra-cost.

Ecosistemul larg de arhitecturi cloud, împreună cu cererea tot mai mare pentru tehnologii IT eficiente energetic, necesită utilizarea unor metodologii rapide, repetabile și controlabile pentru evaluarea algoritmilor, a aplicațiilor și a politicilor înainte de dezvoltarea efectivă a produselor de cloud. Deoarece utilizarea unor bancuri de lucru reale limitează experimentele la scara acestor bancuri de lucru și face reproducerea rezultatelor destul de dificilă, au apărut abordări alternative pentru testarea și experimentarea avantajelor noilor tehnologii de tip cloud, fog, etc.

O alternativă la folosirea de bancuri de lucru reale în testarea aplicațiilor cloud, care prezintă o serie de avantaje de scalabilitate, cost etc. este utilizarea unor simulări software prin intermediul unor instrumente software de simulare de tipul CloudSim. Aceste instrumente deschid posibilitatea de a evalua o ipoteză privind avantajele modelului cloud, fog, etc. înainte de dezvoltarea propriu-zisă de aplicații software, care este costisitoare și de durată, oferă scalabilitatea care lipsește într-un banc de lucru real și un mediu suficient de complex în care se poate reproduce o serie de teste.

Platforma de simulare Cloudsim

Obiectivul declarat al platformei de simulare CloudSim este acela de a oferi un cadru de simulare generalizat și extensibil, care să permită modelarea, simularea și experimentarea infrastructurilor emergente de cloud computing și serviciilor de aplicații. Prin utilizarea CloudSim, cercetătorii și dezvoltatorii din industrie se pot concentra pe probleme specifice de proiectare a sistemelor pe care le doresc să investigheze, fără a fi preocupați de detaliile de nivel scăzut legate de infrastructurile și serviciile din cloud.

În plus, în cazul cloud computing, accesul la infrastructura necesită costuri mari, iar abordările bazate pe simulare oferă beneficii semnificative, precum:

permit clienților cloud să testeze serviciile lor în medii repetabile și controlabile, precum și să regleze performanța și să elimine anumite blocaje înainte de a dezvolta în medii cloud reale

sunt mai scalabile decât un mediu real

sunt mai rapide decât testarea clasică prin dezvoltarea software propriu-zisă, deci sunt mai rentabile ca timp

sunt libere de cost

pe partea furnizorului, mediile de simulare permit evaluarea diferitelor tipuri de scenarii de închiriere de resurse în diferite distribuții de sarcină și de stabilire a prețurilor.

Entitățile principale ale framework-ului CloudSim

Principalele entități din framework-ului software al instrumentului de simulare CloudSim sunt CIS (Cloud Information Service), DataCenter, Broker și Cloudlet (vezi Fig. 14)

Fig. 14 Entitățile framework-ului CloudSim

CIS (Cloud Information Service) este, așa cum îl prezintă autorii CloudSim, un fel de registru de evidență al resurselor, o interfață pentru resursele care există în mediul cloud.

Resursele cloud sunt modelate de o serie de elemente abstracte:

un DataCenter, care conține la rândul său entități abstracte precum

un host (sau mai multe), care la rândul său conține

un set de mașini virtuale (virtual machines sau VM).

Elementul host abstractizează resursele computaționale reale, adică:

un număr de elemente de procesare (processing elements sau PE)

o anumită cantitate de memorie RAM (512MB, 1GB, 4GB etc.)

o anume lățime de bandă de transfer (bandwidth)

Conform paradigmei distributed computing, prezentă în cloud și fog computing, resursele sunt virtualizate prin elemente VM. Elementele VM împart la nivel abstract resursele reale, după necesități, astfel încât o unitate VM poate cuprinde mai multe resurse computaționale reale, sau mai multe unități VM pot împărtăși aceeași resursă.

Unitățile VM reprezintă așadar resursele din perspectiva necesităților aplicației, în timp ce unitățile host și datacenter le prezintă din punct de vedere al resurselor reale.

Funcționarea generală a framework-ului

Framework-ul se bazează pe interacțiunea dintre entități astfel încât să fie furnizate caracteristici de scalabilitate din distributed computing, virtualizare, etc. Practic tot acest framework are ca scop alocarea de VM (mașini virtuale) aplicațiilor cloudlet.

Dacă studiem interacțiunile din framework-ul în direcția top-down, plecând de la aplicații (cloudlet), acestea interacționează cu resursele doar prin broker, care are rolul de a masca gestionarea resurselor.

Broker-ul se adresează mai întâi registrului de resurse reprezentat de CIS (Fig. 14) pentru a afla detalii asupra resurselor disponibile în DataCenter și pentru a comunica noi cerințe.

Brokerul, în faza a doua, în baza informațiilor schimbate cu CIS despre DataCenter, va ocoli CIS și va comunica direct cu DataCenter-ul, alocând VM-urile cerute fiecărui cloudlet. În acest fel el maschează alocarea resurselor față de cloudlet.

Există o serie de politici aplicabile în fazele de alocare a resurselor și programare în timp a utilizării resurselor și respeciv de programare a aplicațiilor pe resurse, care țin cont de caracteristica de utility computing inclusă în cloud computing, și anume de gestionarea la comun timpului și spațiului, sau altfel spus aceste politici folosesc timesharing și spacesharing:

DataCenter-ul folosește o politică de alocare a VM-urilor pe resurse (VM allocation policy).

Host-ul folosește o politică de programare a VM-urilor (VM Scheduler policy)

VM-ul folosește o politică de programare în timp a Cloudlet-urilor (Cloudlet Scheduler policy)

Clasele framework-ului CloudSim

Framework-ul CloudSim este scris în Java și organizat în clase. Aceste clase reprezintă entități și funcționalități ale framework-ului prezentate la capitolul anterior și pot fi împărțite în diverse categorii. Vom prezenta cele mai importante categorii de clase, cu câteva exemple concrete din fiecare.

Clase pentru entități principale

Clasa DataCenter (centru de date) este derivată din clasa CloudResource și are o listă de host-uri (hostList) virtualizată. Clasa se ocupa cu prelucrarea de interogări VM (adică, gestionarea mașinilor virtuale), în loc de interogări legate de Cloudlet. Deci, chiar dacă va fi instanțiată o politică de alocare (AllocPolicy), în metoda de inițializare a superclasei (metoda init() din superclasă), nu va fi folosită, deoarece prelucrarea cloudlet-urilor este gestionată de către CloudletScheduler și prelucrarea mașinilor virtuale (obiecte VirtualMachines) este realizată de către clasa VmAllocationPolicy.

Clasa Host (gazdă) execută acțiuni legate de gestionarea mașinilor virtuale (de exemplu, creație și distrugere). O gazdă are o politică bine definită pentru furnizarea de memorie și de lățime de bandă, precum și o politică de alocare pentru PE (unități de procesare) la mașinile virtuale. O gazdă este asociată unui datacenter. Acesta poate găzdui mașini virtuale.

Clasa Vm reprezintă o mașină virtuală (VM): Ea rulează in interiorul unui clase Host și partajează hostList cu alte Vm, respectiv procesează aplicații cloudlet. Această procesare se întâmplă în conformitate cu o politică definită de clasa CloudletScheduler. Fiecare VM are un proprietar, care poate înainta cloudlet-uri la VM ca să fie executate.

DatacenterBroker reprezinta un broker care acționează în numele unui utilizator. Se ascunde partea de management al mașinilor virtuale (Vm), si crearea Vm, înscrierea cloudlet-urilor acestor Vm-uri și distrugerea de Vm-uri.

Clasa Cloudlet este o extensie a cloudlet-ului. Acesta stochează, pe langă toate informațiile încapsulate în cloudlet, ID-ul VM-ului pe care rulează cloudlet-ul.

O clasă CloudInformationService (CIS) corespunde unei entități care furnizează servicii de înregistrare, indexare și descoperire de resurse cloud. Resursele din lista hostList își declină disponibilitatea lor de a procesa aplicații cloudlet prin înregistrare în entitatea CIS. Alte entități, cum ar fi brokerul de resurse, pot contacta această clasă pentru serviciul de descoperire de resurse, care returnează o listă de ID-uri de resurse înregistrate. Pe scurt, acesta acționează ca un serviciu de tip carte de telefoane, furnizând. Această clasă va fi creată de clasa CloudSim la inițializarea simulării. Prin urmare, nu este nevoie să ne facem griji cu privire la crearea unui obiect al acestei clase.

CloudSim, clasa principală care lansează simulatorul, permite simularea rețelei în CloudSim. De asemenea, ea poate dezactiva toate modelele de rețea de la CloudSim, pentru a oferi o simulare mai simplă de rețea. In modelul de rețea utilizat de CloudSim, pentru a descrie rețeaua, este folosit un fișier de topologie scris în format BRITE. Mai târziu, nodurile dintr-un astfel de fișier sunt mapate la entități CloudSim. Întârzierile calculate din modelul BRITE sunt adăugate la mesajele trimise prin CloudSim. Mesajele care utilizează modelul vechi sunt convertite la metodele apropriate cu parametrii corecți.

Clase pentru entități secundare

Clasa Pe (element de procesare) utilizată de Host, reprezintă unitatea de CPU, definită în termenii de Milioane de instrucțiuni pe secundă (MIPS).

Interfața Storage definește funcționalitatea dorită a unui sistem de stocare într-un cloud de date (Data Cloud). Clasele care implementează această interfață ar trebui să simuleze caracteristicile diferitelor sisteme de stocare prin stabilirea capacității de stocare și a vitezei maxime de transfer. Rata de transfer definește timpul necesar pentru a executa anumite operațiuni comune privind stocarea, de exemplu stocarea unui fișier, obținerea unui fișier și ștergerea unui fișier.

Clasa HarddriveStorage este o implementare a interfeței Storage. Ea simulează comportamentul unui suport de stocare pe un hard disc tipic. Valorile implicite pentru acest spațiu de stocare sunt cele ale unui hard disk Maxtor DiamondMax 10 ATA cu următorii parametri.

latență = 4.17 ms

timp mediu de căutare = 9 ms

rată maximă de transfer = 133 MB/sec

Clasa SANStorage (adică Storage Area Network Storage) este o altă implementare a interfeței Storage. Ea reprezintă o rețea cu stocare distribuită compusă dintr-un set de hardiscuri conectate într-o rețea LAN. Capacitatea discurilor individuale este abstractizată, prin urmare, este considerată doar capacitatea totală a sistemului SAN. ATENȚIE: Această clasă nu este încă pe deplin funcțională. Efectele stocării în rețea nu sunt luate în considerare în simulare. Așa că, timpul necesar pentru transferul de fișiere este subestimat în prezența unei încărcări mari a rețelei.

Clasa File este o clasă pentru reprezentarea unui fișier fizic într-un mediu de date de tip cloud.

Clase pentru comportamentul entităților

VmAllocationPolicy este o clasă abstractă, care reprezintă politica de furnizare a gazdelor pentru mașini virtuale într-un Datacenter, în cazul existenței a mai multe gazde, desigur. Aceasta suportă rezervarea în două etape a gazdei: în prima etapă, se rezervă gazda și, odată acest lucru asumat de către utilizator, această gazdă este alocată efectiv pentru utilizatorul respectiv.

VmAllocationPolicySimple este o implementare concretă a clasei VmAllocationPolicy care alege, în calitate de gazdă pentru VM, gazda cu mai puțin PE-uri ocupate.

VmScheduler este o clasă abstractă, care reprezintă politica utilizată de un VMM (VM monitor) pentru a partaja puterea de procesare între mașinile virtuale (VM-urile) care se execută pe o gazdă.

VmSchedulerSpaceShared este o implementare a clasei abstracte VmScheduler și reprezintă o politică de alocare a VMM care alocă una sau mai multe PE-uri la un VM, și nu permite utilizarea în comun a PE-urilor. În cazul în care nu există niciun PE liber pentru VM, alocarea eșuează.

VmSchedulerTimeShared este o politică de alocare a VMM care alocă una sau mai multe PE-uri la un VM și permite partajarea PE-urilor de către mai multe VM-uri. Această clasă implementează, de asemenea, o degradare de performanță de 10% din cauza migrației VM.-urilor. Acest planificator nu suportă supraînscriere.

Interfața UtilizationModel trebuie să fie implementată, în scopul de a asigura un control fin asupra utilizării resurselor de către un cloudlet.

Clasa UtilizationModelFull este un model simplu, potrivit căruia cloudlet utilizează întotdeauna toată capacitatea disponibilă a procesorului. Alte implementări ale interfeței UtilizationModel rafinează acest lucru, de exemplu UtilizationModelPlanetLab, sau UtilizationModelStochastic care simulează un model conform căruia un cloudlet generează o utilizarea aleatorie a procesorului la fiecare unitate de timp.

Clasa CloudletScheduler este o clasă abstractă, care reprezintă politica de planificare realizată de către o mașină virtuală. Astfel, clasele care extind această clasă trebuie să execute Cloudlets. De asemenea, interfața pentru managementul cloudlet-urilor este, de asemenea, pusă în aplicare în această clasă.

Clasa CloudletSchedulerDynamicWorkload este o implementare a interfeței CloudletScheduler. Ea pune în aplicare o politică de planificare realizată de către o mașină virtuală, presupunând că există doar un singur nouraș care funcționează ca un serviciu online.

Clasa CloudletSchedulerSpaceShared este o implementare a interfeței CloudletScheduler. Ea pune în aplicare o politică de planificare realizată de către o mașină virtuală și consideră că va exista doar un singur nouraș pe VM. Alte cloudlets vor fi într-o listă de așteptare. Se consideră că transferul de fișiere de la cloudlets de așteptare se întâmplă înainte de execuția cloudlet-ului. Adică, chiar dacă cloudlets trebuie să aștepte pentru CPU, transferul de date se întâmplă mai repede, de îndată ce sunt înscrise cloudlet-urile.

Clasa CloudletSchedulerTimeShared este o implementare a interfeței CloudletScheduler. Ea pune în aplicare o politică de planificare realizată de către o mașină virtuală. Cloudlet-urile se execută în VM prin partajarea timpului acestuia.

Pașii principali în scrierea codului de simulare

Pas 1. Se convine numărul de utilizatori, care va fi același cu numărul de brokeri

Pas 2. Inițializarea variabilelor comune, înaintea (sau odată cu) creării CIS

Pas 3. Crearea CIS

Pas 4. Crearea Datacenter împreună cu Host-urile și caracteristicile aferente

Caracteristicile aferente sunt PE, RAM, Bw exprimate în MIPS (milioane de instrucțiuni pe secundă) și MB (Megabytes).

Datacenterul trebuie înregistrat la CIS.

Pas 5. Crearea Datacenter broker

Acesta este răspunzător pentru comunicarea dintre Datacenter, cloudlet-uri și VM-uri

Pas 6. Crearea de VM-uri (mașini virtuale)

Acestea vor avea același tip de caracteristici cu Datacenter-ul, valorile lor fiind stabilite în funcție de felul în care divid resursele acestuia (Timeshared, Spaceshared etc.)

Pas 7 Lista de VM-uri este înscrisă la Datacenter broker

Pas 8 Crearea de cloudlet-uri cu necesarul lor de PE, Bw etc.

Pas 9. Lista de cloudlet-uri este înscrisă la Datacenter broker

Cloudlet-urile vor fi mapate la VM-uri de către broker (de ex. c1 la vm1, c2 la vm2 etc.)

Pas 10. Start simulare

Pas 11. Stop simulare

Pas 12. Se afișează status-ul simulării (timpul de simulare etc.)

Aplicația BikeDetector

Argument

Aplicația BikeDetector își propune identificarea rapidă a bicicletelor dintr-un oraș în scopuri de evidență sau antifurt. Pentru a fi identificate/detectate, bicicletele trebuie să treacă prin fața a cel puțin una dintre camerele de video de supraveghere ale unui oraș inteligent. Se presupune așadar că orașul dispune de o rețea de supraveghere video publică, sau există acces la o serie de camere video de supraveghere private care filmează spații publice.

S-a ales această problemă, deoarece în acest caz datele (informațiile video) au un volum mare, prezintă necesități mari de putere de calcul (algoritmi de identificare în imagine), provin din surse distribuite geografic, au potențial de automatizare, provin din surse cu caracteristici de rețea potențial foarte diferite (arhitectură, viteză, protocoale diferite etc), deci prezintă toate trăsăturile unei probleme de IoT și fog computing.

În particular ne vom adresa problemelor de timp de răspuns și rată de transfer, etc în cazul acestor volume foarte mari de date. Problema timpului de răspuns înseamnă că răspunsul trebuie să survină aproape în timp real, sau în interval de câteva secunde, altfel bicicletelor aflate în mișcare li s-ar pierde urma și nu ar putea exista o reacție în timp util din partea autorităților etc. Problema ratei de transfer sau problema blocajului rețelei înseamnă de fapt felul că este necesar ca datele nesemnificative să fie filtrate către marginea rețelei, pentru a evita aglomerarea rețelei cu fluxuri mari de date video în timp real de la un număr de zeci, sute sau chiar mii de camere video din oraș.

Scenarii de lucru

Propunem studiul a trei scenarii de lucru: fog, cloud și edge.

Primul scenariu, scenariul fog, presupune noduri intermediare în rețea (noduri fog) care colectează și analizează informațiile video la nivel local, trimițând rapoarte către serverele cloud în anumite momente cheie sau luând decizii automate în funcție de politica setată. Ne așteptăm ca acest scenariu să funcționeze bine pentru orice număr de camere instalate și să fie o soluție de compromis viabilă cost-performanță. Ne interesează gradul de aglomerare al rețelei (timpi de răspuns, rată de transfer) și în consecință limita în ceea ce privește numărul de camere utilizabile în sistem.

Cel de-al doilea scenariu, numit scenariul edge, presupune existența unor camere inteligente capabile să integreze puterea computațională (analiză de imagini video). Ca și în scenariul fog se încearcă degrevarea cloud-ului de o serie de decizii care se pot lua automat în anumite situații prin implementarea unor politici de decizie automată la nivel edge, controlabile la nivel cloud . Ne așteptăm ca acest scenariu să fie foarte costisitor (deoarece nu se poate adapta o rețea video existentă, trebuie camere speciale etc), și ideal din punct de vedere tehnic (rețeaua este aglomerată foarte puțin doar cu informații relevante – alarme și imagini asociate). Ne interesează gradul de aglomerare al rețelei și al cloud-ului în cazul unui număr mare și foarte mare de camere (mii, zeci de mii).

Cel de-al treilea scenariu, numit scenariul cloud, presupune camere care comunică direct cu cloud-ul, pasându-i acestuia întreaga informație pentru analiză, fără intermedierea vreunui nod. Acest scenariu, nepractic pentru un număr mare de camere cu imagini de calitate, este totuși utilizabil în ideea capitalizării performanțelor conexiunilor la Internet. Este cel mai ieftin de implementat și extrem de scalabil la infrastructura video existentă – practic oricine poate trimite imagini video doar instalând o aplicație client – însă este extrem de costisitor în ceea ce privește resursele – necesită o conexiune la Internet de mare viteză – și folosește resurse create în alte scopuri, confiscându-le pentru un scop particular și menținându-le ocupate. Ne așteptăm ca acest scenariu să solicite la maxim rețeaua și să necesite conexiuni Internet dedicate. Ne interesează gradul de aglomerare al cloud-ului în cazul conectării unui număr relativ mic de camere și calitatea video maximă suportată având în vedere capacitatea Intenetului actual.

Scenariul fog

În scenariul fog, nodurile fog realizează cea mai mare parte a analizei și opțional și a stocării de date. Logica de prelucrare a datelor în nodurile fog este explicată mai jos mai jos în schema logică din Fig. 15. Nodul fog parcurge următorii pași:

primește informații de conectare de la n camere

analizează disponibilul de resurse (stocare – bytes, procesare – nr de mașini virtuale)

alocă resursele astfel încât sa facă față stocării/procesării datelor.

face un calcul teoretic pentru necesarul de resurse și daca acest prag minim nu este trecut, împreună cu cloud-ul, va lua următoarele decizii:

de eliberare resurse (șterge informații video mai vechi la nivelul nodului, alocă noi mașini virtuale);

de prioritizare camere (pe principiul că un sistem de supraveghere este mai bine să poată funcționa cu mai puține camere, decât deloc cu toate camerele)

face un test de stocare/procesare (numit în ”test streaming” în schemă) la o calitate și viteză minime admise a informațiilor video pentru scopul propus. Dacă la acest nivel de prag minim de calitate testul eșuează se iau următoarele măsuri:

face frame-skipping, dacă streamul este de calitate și permite, in vederea reducerii stocării/procesării). Dacă nivelul de frame skipping este acceptabil, intră în modul normal de lucru și face alocarea resurselor, altfel întră în modul eroare și trimite un raport eroare către cloud. Dacă din partea cloud nu vine vreo decizie (de ex. reducerea numărului de camere), după un timp de așteptare maxim, se încearcă din nou alocarea resurselor.

citește date de la camere (”streaming”)

analizează datele inteligent (după schimbări imagine), extrage un număr de frame-uri cheie, si încearcă identificarea cu un algoritm si o baza de date a elementelor din acele frame-uri (i.e. biciclete).

daca identifică ceva similar cu informațiile căutate din baza de date (într-un anumit procent de similitudine) intră in starea ”suspect”, trimite către cloud imaginile împreună cu un raport al analizei, și așteaptă o decizie un timp dat. Intre timp, dacă a făcut până atunci vreo optimizare frame-skipping, poate comuta intrarea de date în modul ”lock on camera”, adică va ignora alte camere prin logica de ”prioritizare camere” și se va concentra doar pe camera cu imagini suspecte; va cere toate imaginile din camera respectivă (daca se mai poate retroactiv, dintr-o memorie buffer a camerei, daca nu in continuare) pana la apariția unei decizii din partea cloud. Dacă expiră timpul alocat modului ”suspect” si cloud-ul nu emite o decizie de menținere a prioritizării, se revine la modul normal.

Fig. 15 Schema logică de funcționare a nodului fog

De remarcat în schema din Fig. 15 că în toate momentele când se trece prin logica cloud, nodului fog i se asociază un contor de timp de așteptare. În cazul în care de pe cloud nu survine o decizie, se va lua o decizie automată la expirarea timpului de așteptare.

Scenariul edge

În acest scenariu toată logica de detecție este controlată de camera inteligentă conform unei politici transmisă acesteia de către cloud (de exemplu similitudine a elementelor detectate în imagine de 75%), iar către cloud se transmit doar frame-urile suspecte conform acestei politici.

În consecință nu mai este nevoie de un nod intermediar care să preia informații video brute și să le analizeze și filtreze, așa cum se făcea în scenariul fog, deoarece acest lucru se face pe cameră (la nivel edge). De asemenea dispare necesitatea de a aloca resurse, deoarece se presupune că o cameră inteligentă are suficiente resurse pentru îndeplini funcționalitățile de stocare și analiză a datelor video, iar mai departe către cloud se trimit informații filtrate, deci relativ puține și gradul de ocupare al rețelei este mic până la un anumit număr foarte mare de camere.

Practic, în scenariul edge, rețeaua se va încărca mult mai puțin comparativ cu scenariul fog.

Ea se poate încărca totuși nu numai prin creșterea la un număr foarte mare de camere dintre care un anumit procent statistic raportează imagini ”suspecte”, ci și prin relaxarea criteriilor ”suspect”, ceea ce înseamnă o posibilă creștere a nivelului de detecție a aplicației BikeDetector și deci a performanțelor ei practice. Trebuie avut în vedere acest compromis între creșterea numărului de camere și relaxarea criteriilor de detecție în utilizarea resurselor rețelei.

Scenariul cloud

În scenariul cloud, logica de alocare a resurselor este invizibilă utilizatorului și se face pe cloud. Acesta ia toate deciziile privind eliberarea memoriei de stocare de informații video mai vechi, prioritatea camerelor, frame-skipping și pot apărea elemente noi, precum prioritatea analizelor de imagine etc. Rolul clientului rămâne doar acela de a furniza un stream video de încărcare constant.

Pregătirea mediului de simulare a proiectului BikeDetector

Platforma de modelare și simulare CloudSim este de fapt un framework software, mai exact o colecție de clase Java care prezintă entități și funcționalități ce simulează mediul de dezvoltare a aplicațiilor cloud, fog, etc, si care pot constitui o bază de simulare pentru utilizator. Se poate scrie cod Java care să utilizeze CloudSim, iar platforma în sine poate fi extinsă sau chiar modificată dacă aplicația o cere, deoarece există acces la sursele acesteia.

Cu platforma Cloudsim se poate lucra folosind un mediu minimal de execuție, iar dacă se dorește scrierea de cod cu un mediu normal de editare și compilare (Eclipse) sau minimal de compilare (Ant), toate prezentate în continuare.

Mediul minimal de execuție

Framework-ul CloudSim este scris în Java așadar necesită un JVM (Java Virtual Machine), disponibil în pachetul JRE (Java Runtime Environment). Astfel este posibilă execuția unor programe gata compilate care folosesc bibliotecile simulatorului, cum ar fi exemplele gata compilate furnizate împreună cu acesta, simulatorul BikeDetector, etc. Pentru compatibilitate cu versiunea folosită de Eclipse s-a folosit JRE versiunea 7.

Comanda de execuție a programelor java gata compilate (.jar) care utilizează biblioteca gata compilată CloudSim are structura generală:

java -classpath cloudsim-<VERSION>.jar:cloudsim-examples-<VERSION>.jar org.c-loudbus.cloudsim.examples.CloudSimExample<EXAMPLE NUMBER>

Un exemplu concret de utilizare folosit este:

java –classpath cloudsim-3.0.3.jar:cloudsim-examples-3.0.3.jar org.cloudbus.cloudsim.e-xamples.CloudSimExample1

Mediul normal de editare și compilare a codului

Pentru modificarea codului, sau pentru creare de cod nou trebuie să existe un compilator de fisiere .java instalat. S-a folosit pachetul JDK (Java Development Kit) de la Sun (versiunea 7 testată în lucrare s-a dovedit compatibilă cu versiunea Eclipse utilizată).

Fig. 16 Crearea proiectului BikeDetector în Eclipse

Pentru editarea facilă a codului este util un mediu de dezvoltare (IDE) care să suporte limbajul Java. În cazul acestei lucrări a fost folosit Eclipse.

Pasul 1. Crearea proiectului în Eclipse

Se crează un proiect Java pentru a importa în el sursele simulatorului CloudSim, care sunt accesibile gratuit și pentru a scrie codul de simulare al aplicației BikeDetector. Dialogul de creare a proiectului (Fig. 16) este accesibil prin comanda:

Eclipse – File – New – Java Project

Se are în vedere în fereastra de dialog ca mediul de execuție folosit să fie ”JavaSE-1.7” și se apasă ”Finish”.

Ne vom referi la acest proiect în continuare ca la ”proiectul BikeDetector”, ”proiectul Java”, sau pur și simplu ”proiect”.

Pasul 2 Verificarea prezenței JDK în Eclipse

Mediul de dezvoltare Eclipse permite desigur, pe lângă editare, de asemenea, compilarea codului, dacă este asociat cu instalarea compilatorului JDK. Asocierea se face la instalarea Eclipse prin precizarea directorului JDK, sau, dacă JDK a fost instalat ulterior, prin adăugarea lui în Eclipse. accesând proprietățile proiectului creat anterior:

Fig. 17 Configurarea JDK în Eclipse

Practic se accesează

Eclipse – Properties – Java Build Path – Libraries

ca în Fig. 17 și se apasă “Edit” pe mediul JRE existent (sau Add Library dacă din diferite motive acesta nu apare), ajungându-se la fereastra din Fig. 18.

Fig. 18 Configurarea JDK în Eclipse – Pas 2

Se selectează JDK-ul în drop-down-ul ”Alternate JRE”, sau dacă nu există, se apasă ”Installed JREs”, ajungându-se în fereastra din Fig. 19.

Fig. 19 Configurarea JDK în Eclipse – Pas 3

În această fereastră se selectează JDK-ul.

Dacă nici în Fig. 19 nu apare JDK,-ul, se apasă ”Add” pentru a se localiza instalarea JDK pe hard disk, se trece printr-un dialog în care se selectează ”Standard VM” și se ajunge în Fig. 20, unde se localizează JDK prin intermediul butonului ”Directory” și selectarea folder-ului unde a fost instalat JDK-ul, de exemplu:

C:\Program Files\Java\jdk1.7.0_79

Selecția folderului va completa automat toate câmpurile necesare din Fig. 20

Fig. 20 Configurarea JDK în Eclipse – Pas 4

Pasul 3 Importarea framework-ului CloudSim

Se dorește prezența în proiect a codului CloudSim sursă, pentru a putea citi ușor clasele și pentru o depanare ușoară, sau pentru a face eventuale modificări framework-ului în sine.

Se apasă click-dreapta pe eticheta proiectului din subfereastra Navigator și se alege opțiunea ”Import…” din meniul contextual.

Fig. 21 Importarea framework-ului CloudSim în Eclipse

În fereastra apărută se selectează ”File System”.

În următoarea fereastră se catută cu ”Browse” folder-ul în care au fost dezarhivate sursele framework-ului CloudSim. Se selectează integral toate aceste surse marcându-se bifa de pe eticheta ”cloudsim-3.0.3” apărută, ca în Fig. 21, și se apasă ”Finish”.

Modificări în proiect pentru includerea corectă a CloudSim

Framework-ul CloudSim necesită două modificări pentru a se compila.

Prima modificare se referă la modificarea denumirii ”sources” în ”src”, specifică mediului Eclipse, care va căuta în folder-ul ”src” sursele de compilat.

Dacă compilăm workspace-ul (compilare care se face automat în Eclipse la orice modificare de proiect datorită bifei ”Project – Build Automatically”), vom observa o serie de erori. Acestea se rezolvă prin a doua modificare.

A doua modificare se referă la adăugarea bibliotecii „commons-math3-3.2.jar” în proiect și adăugarea ca librarie în proprietățile proiectului.

Se dă click dreapta pe folder-ul ”jars” și se alege ”Import..”, selectându-se în ferestrele care urmeză ”FileSystem” și apoi folder-ul care conține biblioteca. Se ajunge la dialogul de importare bibliotecă din Fig. 22 în care se selectează ”commons-math3-3.2.jar”.

În continuare trebuie selectat

Project – Properties – Add JARS…

și selectat din fișierul ”commons-math3-3.2.jar” din structura proiectului, pentru a ajunge într-o configurație de librării asemănătoare cu cea din Fig. 23.

Fig. 22 Importarea bibliotecii commons-math3-3.2.jar

Fig. 23 Importarea bibliotecii commons-math3-3.2.jar – Pas 2

În această fază, proiectul devine compilabil (se va compila automat în Eclipse fără erori), și se poate începe scrierea codului.

Mediul minimal de compilare

Pentru compilarea proiectului se poate folosi și utilitarul separat Ant, astfel:

1) se setează variabila de sistem JAVA_HOME în comand prompt, de exemplu:

set JAVA_HOME=C:\Program Files\Java\jdk1.7.0_79

2) se execută ant din directorul proiectului, de exemplu:

c:\users\user_name\workspace\BikeDetector> ant

În urma compilării se generează fișierele compilate cu extensia .class din folder-ul

C:\Users\user_name\workspace\BikeDetector\classes\org\cloudbus\cloudsim

Scrierea și execuția codului

Vom prezenta în continuare mediul normal de scriere și execuție a codului, folosind Eclipse.

Pentru aceasta vom folosin exemplele de execuție din framework-ul CloudSim. Acestea vor fi luate din folder-ul

examples – org – cloudbus – cloudsim – examples

și mutate cu tot cu folder-ul examples în care se află, prin drag-and-drop, în folder-ul

src – org – cloudbus – cloudsim

așa cum este prezentat în Fig. 24.

Aici exemplele pot fi executate prin click-dreapta pe fișierul exemplu și comanda

RunAs – Java application..

Fig. 24 Mutarea folderului examples în zona de compilare ”src”

Fișierul CloudSimExample1, de exemplu, trebuie să producă în subfereastra Console un output asemănător cu cel din

Fig. 25 Exemplu de output de cod scris pentru simulatorul CloudSim

Explicarea codului de simulare pentru BikeDetector

Structura codului de simulare respectă pașii principali descriși în subcapitulul 2.3 ”Platforma de simulare Cloudsim”.

Pașii 1,2,3 sunt realizați prin declararea și inițializarea obiectului CloudSim. Procedura CloudSim.init(..) crează un obiect de tipul CloudInformationService și se inițializează o serie de variabile globale (cele din parametrii funcției de mai jos).

CloudSim.init(num_user, calendar, trace_flag);

Pasul 4 este realizat într-o procedură separată, numită createDatacenter(), apelată în main(), astfel:

Datacenter datacenter0 = createDatacenter("Datacenter_0");

Această procedură pregătește o serie de elemente pentru crearea unui obiect DataCenter. Mai întăi crează o listă de host-uri.

Fiecare host primește o listă de PE-uri (procesoare), cu anumite viteze de procesare exprimate în mips (milioane de instrucțiuni pe secundă), viteză care reprezintă unul din parametrii configurabili ai simulării și se referă la resursele fizice ale nodului fog.

int mips = 1000;

peList.add(new Pe(0, new PeProvisionerSimple(mips)));

De asemenea, fiecare host primește și valorile resurselor disponibile de RAM, stocare (storage) și lățime de bandă (bandwidth), care reprezintă alți 3 parametrii fizici configurabili ai nodului fog, după care este adăugat la lista de host-uri.

int hostId=0;

int ram = 2048; //host memory (MB)

long storage = 1000000; //host storage

int bw = 10000;

hostList.add(

new Host(

hostId,

new RamProvisionerSimple(ram),

new BwProvisionerSimple(bw),

storage,

peList,

new VmSchedulerTimeShared(peList)

)

); // This is our machine

În instrucțiunea anterioară de inițializare a host-ului se observă inițializarea parametrului VmScheduler cu un obiect de tipul VmSchedulerTimeShared, deoarece aceasta a fost politica aleasă de programare a VM-urilor pe host (VM Scheduler policy).

Ulerior host-urilor, trebuie pregătite și o serie de caracteristici globale pentru Datacenter, cum ar fi, de exemplu, cele care se referă la costul de utilizare per unitate al resurselor etc. Aceste caracteristici sunt reunite în obiectul de tip DatacenterCharacteristics:

String arch = "x86"; // system architecture

String os = "Linux"; // operating system

String vmm = "Xen";

double time_zone = 10.0; // time zone this resource located

double cost = 3.0; // the cost of using processing in this resource

double costPerMem = 0.05; // the cost of using memory in this resource

double costPerStorage = 0.001; // the cost of using storage in this resource

double costPerBw = 0.0; // the cost of using bw in this resource

LinkedList<Storage> storageList = new LinkedList<Storage>(); //we are not adding SAN devices by now

DatacenterCharacteristics characteristics = new DatacenterCharacteristics(

arch, os, vmm, hostList, time_zone, cost, costPerMem,

costPerStorage, costPerBw);

În final se crează obiectul Datacenter. Constructorul acestei clase va asocia Datacenter-ului lista de host-uri și caracteristicile generale din obiectul de tip DatacenterCharacteristics (lista de host-uri o preia indirect din obiectul DatacenterCharacteristics)

datacenter = new Datacenter(name, characteristics, new VmAllocationPolicySimple (hostList), storageList, 0);

Se observă că, în momentul creării obiectului Datacenter, se setează și politica de alocare a VM-urilor la nivel de datacenter (VM allocation policy) pentru care s-a ales varianta VmAllocationPolicySimple, adică VM-urile vor fi alocate acelui host care are un număr maxim de PE-uri libere.

Pasul 5 reprezintă crearea DataCenterBroker care va intermedia legătura dintre Datacenter, lista de VM-uri și lista de cloudlet-uri:

DatacenterBroker broker = createBroker();

int brokerId = broker.getId();

Pașiil 6,7. crează lista de mașini virtuale și o asociază obiectului DataCenterBroker. În inițializarea mașinilor virtuale apar o serie de parametrii care din nou pot fi configurați în simulare. Acești parametrii reprezintă următoarele resursele virtuale:

putere de procesare (exprimată în Mips),

dimensiune a imaginii (MB),

RAM (MB)

lațime de bandă (MB)

numărul de PE-uri necesar execuției VM

//Fourth step: Create one virtual machine

vmlist = new ArrayList<Vm>();

//VM description

int vmid = 0;

int mips = 250;

long size = 10000; //image size (MB)

int ram = 512; //vm memory (MB)

long bw = 1000;

int pesNumber = 1; //number of cpus

String vmm = "Xen"; //VMM name

//create VM

Vm vm1 = new Vm(vmid, brokerId, mips, pesNumber, ram, bw, size, vmm, new CloudletSchedulerTimeShared());

//add the VM to the vmList

vmlist.add(vm1);

//submit vm list to the broker

broker.submitVmList(vmlist);

În codul de mai sus se observă inițializarea atributului de tip CloudletScheduler al VM-ului, atribut care specifică o politică de programare a cloudleturilor pe VM (Cloudlet Scheduler policy, inițializarea făcându-se printr-un obiect de tip CloudletSchedulerTimeShared, adică mai multe cloudlet-uri pot împărți resursele unui VM în timp, dacă numărul lor îl depășește capacitatea resurselor virtuale.

Pașii 8,9 crează lista de cloudlet-uri care va fi și ea înscrisă la DataCenterBroker. Cloudlet-urile reprezintă task-urile video venite de la camerele din sistemul BikeDetector. Ele se configurează cu ceea ce putem numi al treilea set de parametrii configurabili de utilizator în simularea de față. Acești parametrii sunt:

cloudletLength (MI, adică milioane de instrucțiuni de executat) reprezintă cantitatea de instrucțiuni de executat a task-ului

cloudletFileSize (bytes), adică dimensiunea fișierului de intrare și a soft-ului task-ului

cloudletOutputSize (bytes), adica dimensiunea fișierului la ieșire, după efectuarea task-ului

Codul de inițiere a cloudlet-urilor și de înscriere a lor la DataCenterBroker este următorul:

cloudletList = new ArrayList<Cloudlet>();

//Cloudlet properties

int id = 0;

long length = 40000;

long fileSize = 300;

long outputSize = 300;

UtilizationModel utilizationModel = new UtilizationModelFull();

Cloudlet cloudlet1 = new Cloudlet(id, length, pesNumber, fileSize, outputSize, utilizationModel, utilizationModel, utilizationModel);

cloudlet1.setUserId(brokerId);

//add the cloudlet to the list

cloudletList.add(cloudlet1);

//submit cloudlet list to the broker

broker.submitCloudletList(cloudletList);

Pas 9+ Este un pas opțional de stabilire a topologiei de rețea pentru anumite entități, pentru a apropia și mai mult simularea de condițiile reale ale unor entități distribuite, integrând latențe de rețea etc.

Pașii 10,11,12 sunt standard pornesc, opresc simularea și afișează rezultatele.

CloudSim.startSimulation();

List<Cloudlet> newList = broker.getCloudletReceivedList();

CloudSim.stopSimulation();

printCloudletList(newList);

Ipotezele de lucru și datele simulării

Pregătirea datelor de simulare va ține cont de cele trei scenarii propuse; fog, cloud, edge.

Vom fixa ca date generale

viteza maximă de upload 4Mbps

Rata maximă de transfer a infomațiilor video de la camere către punctele de analiză și decizie trebuie să fie supotată de conexiunile Intenet actuale. Am considerat că o viteză de upload de 4Mbps este o viteză de upload medie pentru standardele actuale.

rezoluția camerelor = 720p (24bit/pixel)

Rezoluția acceptabilă (minimă) a camerelor și a imaginilor video transmise de acestea trebuie să satisfacă necesitățile algoritmiilor de identificare de forme, culori, etc. și trebuie să conțină suficiente detalii astfel încât să se poată efectua identificarea bicicletelor aflate la 3-30m de obiectivul camerei (de exemplu bicicletele să nu fie punctiforme etc.). Deși rezoluții mai mari de 720p sunt suportate de multe camere deja existente și aflate în funcțiune ca și camere de supraveghere, ele sunt prea mari pentru a putea fi transmise în timp real pe o conexiune de Internet și sunt destinate mai degrabă sistemelor de supraveghere închise sau transmit mai departe informația prin Internet la o rezoluție redusă. Rezoluția 720p = 1280 x 720 generează, conform youtube, o rată de transfer la streaming video în format comprimat MP4 de 1,5-4Mbps, care este suportată la limită de viteza maximă de upload pe care ne-am propus-o. Formatul puternic comprimat nu este ideal, dar este preferat unui format de rezoluție inferioară. Practic algoritmii de identificare cer o rezoluție minimă de 720p, iar vitezele conexiunilor Intenet actuale fac ca aceasta să fie și maximă, chiar și cu compromisul folosirii unui algoritm cu o rată mare de compresie (și în consecință distorsiuni).

fps minim al camerelor = 15 fps

Considerăm că dacă cerințele de rezoluție trebuie să fie ridicate, cele de fps pot fi mai moderate. În fond, ele pot fi și foarte scăzute, dacă satisfac algoritmii de identificare Având în vedere însă că bicicletele sunt obiecte în mișcare, trebuie luate în considerare ca minim 3-4 frame-uri să apară în filmare la o trecere prin fața camerelor cu viteză maximă. Dacă considerăm viteza maximă a bicicletelor de 30km/h = 8,33 m/s și segmentul minim surprins de cameră dintr-o traiectorie a bicicletei de 4,25m (obținută din distanța minimă de filmare de 3m și o deschidere orizontală a obiectivului minimă de cca 45*, deci o traiectorie de 3m), înseamnă că timpul minim pe care bicicleta îl petrece în cadru este de cca. 0.5 s, iar pentru a obține 6 cadre cu bicicleta (deci 4 cadre cu bicicleta intreagă) este nevoie de o viteză a filmării de 12fps. Standardul de 15fps este acoperitor.

dimensiunea unui calup video = dimensiunea unui task de procesare (cloudlet) = 1s de video = maxim 0,5MB = (aprox.) max 500.000.000 bytes

Considerăm că pentru identificare, algoritmii au nevoie de un timp de filmare în care să poată sesiza mișcarea sau staționarea, determina viteza sau direcția bicicletei, etc. În același timp s-a stabilit în ipotezele anterioare că timpul minim pe care bicicleta îl petrece în cadru este de 0.5 secunde. Așadar un calup de 1s este acoperitor. În format necomprimat acesta ar ocupa 15fps x 1280 x 720 x 3 = 31,64 MB/s = cca 200Mbps ceea ce nu poate fi trimis pe Internet în momentul de față în timp real decât cu o conexiune foarte scumpă la Internet, deci este necesară o compresie. Conform surselor citate la determinarea anterioară a rezoluției camerelor, cu un algoritm de compresie MP4 se poate obține o rată acceptabilă de transfer de maxim 4Mbps. Aceasta înseamnă că 1s de video are maxim 0,5 MB.

timpul maxim de identificare = 30s

Timpul de identificare este considerat timpul scurs între finalizarea filmării datelor video (a unui calup video) și răspunsul algoritmilor de identificare. Operațiile cele mai costisitoare ca timp petrecute între aceste două momente sunt:

transmiterea datelor (doar în scenariile fog și cloud) în cazul aglomerării rețelei

procesarea datelor de către algoritmii de identificare

Se consideră că există un timp maxim permis pentru identificare, deoarece un timp mai lung ar fi nepractic pentru intervenții rapide.

necesarul de procesare pentru 1s de video = 8000 MI (milioane de instrucțiuni de procesor

Necesarul de procesare este exprimat în MI, deoarece puterea PE este exprimată în MIPS. S-a considerat pur empiric că ar fi necesare cca. 200 de instrucțiuni per pixel pentru decomprimare, identificare forme și alte analize. 200 x 1280 x 720 x 15 x 3 = cca. 8000 MI

Numărul de camere

Propunem un număr variabil de camere video în cele trei scenarii. Vom considera un interval de 10 – 10000 de camere ca fiind de interes pentru aplicația propusă, iar ca număr de referință 500 de camere.

Criterii de analiză

Criteriul de analiză economic

Primul criteriu de analiză al celor 3 scenarii ar fi cel economic. Vom face abstracție de costurile de instalare ale sistemului de supraveghere, pe care le vom considera aproximativ identice în cele trei scenarii și vom considera doar costul camerelor propriu-zise.

În scenariile cloud și fog, avem de-a face cu camere video obișnuite de supraveghere cu posibilitate de streaming live pe internet. Aici sunt incluse și camere web cu fir sau wireless și toate tipurile de camere cu o rezoluție 720p cu posibilitate de compresie MP4. Costul per cameră este considerat a fi de cca. 100$/buc.

În scenariul edge, trebuie considerate camere video speciale, însoțite de putere de procesare și de algoritmi de identificare. Am considerat estimativ costul de 10000$/camera.

În scenariile fog și cloud, necesitățile de procesare externe camerelor sunt aceleași, doar că sunt distribuite diferit. Este necesară investiția în servere cu o putere mare de procesare, și chiar de stocare, dacă se doresc funcții suplimentare de arhivă etc. Se consideră că este necesar un procesor de ultimă generație (i7) la cca. 10 camere. Costul sistemului extern per 10 camere este estimat la cca. 1000$ în scenariul fog (costul aproximativ al unui sistem desktop) și la cca. 500$ în cloud (unde am considerat o reducere de cost datorată scalabilității sistemului de 50%).

Fig. 26 Costul sistemului de identificare pentru cele 3 scenarii

În graficul din Fig. 26 se observă că diferența de cost între scenariul edge și celelalte crește foarte mult în valoare absolută pentru un număr mare de camere. Scenariile fog și cloud aproape că se confundă. Pentru a fi observată diferența fină dintre ele, prezentăm același grafic și în Fig. 27, dar având o scală logaritmică și pe axa Oy.

Fig. 27 Costul sistemului de identificare pentru cele 3 scenarii (Oy logaritmic)

În practică, putem lua în calcul că în scenariile cloud și fog, costul sistemului poate fi chiar mai mic dacă considerăm că avem deja o parte din camere existente, care doar trebuie conectate la sistem.

Criteriul timpului de răspuns

La datele generale am prezentat un timp maxim de identificare de 30s a unui calup de 1s de video din punct de vedere al utilizatorului sistemului. În realitate, sistemul produce un flux continuu de task-uri, furnizând un stream video în calupuri de 1s. Dacă ar fi necesar mai mult de 1s pentru identificare, task-urile ar aglomera tot mai mult o coadă de așteptare. În consecință procesarea trebuie să poată fi făcută de sistem în timp real, deci timpul critic de procesare pentru un calup este egal cu durata calupului (1s).

Rezultatele simulării

Scenariul fog

Scenariul fog a fost simulat pentru 10 camere și un nod fog cu 1 procesor quad-core

Nod fog: 1 procesor Quad Core cu performanțe asemănătoare Intel i7 (>1.000.000 mips per core)

(așadar 1 datacenter, 1 host, 4 PE-uri)

Număr de camere aferente unui nod: 10

Număr de cloudlet-uri: 10

Necesar procesare cloudlet: 8000 mips

Dimensiune cloudlet: 0.25 MB (1s de video comprimat)

Simularea F1

Nunmăr VM-uri: 8

RAM VM = 512 MB

RAM nod fog (host) = 2048 MB

Rezultatul simulării este următorul listing:

Starting BikeDetector fog scenario…

Initialising…

Starting CloudSim version 3.0

Datacenter_0 is starting…

Broker is starting…

Entities started.

0.0: Broker: Cloud Resource List received with 1 resource(s)

0.0: Broker: Trying to Create VM #0 in Datacenter_0

0.0: Broker: Trying to Create VM #1 in Datacenter_0

0.0: Broker: Trying to Create VM #2 in Datacenter_0

0.0: Broker: Trying to Create VM #3 in Datacenter_0

0.0: Broker: Trying to Create VM #4 in Datacenter_0

0.0: Broker: Trying to Create VM #5 in Datacenter_0

0.0: Broker: Trying to Create VM #6 in Datacenter_0

0.0: Broker: Trying to Create VM #7 in Datacenter_0

[VmScheduler.vmCreate] Allocation of VM #4 to Host #0 failed by RAM

[VmScheduler.vmCreate] Allocation of VM #5 to Host #0 failed by RAM

[VmScheduler.vmCreate] Allocation of VM #6 to Host #0 failed by RAM

[VmScheduler.vmCreate] Allocation of VM #7 to Host #0 failed by RAM

0.1: Broker: VM #0 has been created in Datacenter #2, Host #0

0.1: Broker: VM #1 has been created in Datacenter #2, Host #0

0.1: Broker: VM #2 has been created in Datacenter #2, Host #0

0.1: Broker: VM #3 has been created in Datacenter #2, Host #0

0.1: Broker: Creation of VM #4 failed in Datacenter #2

0.1: Broker: Creation of VM #5 failed in Datacenter #2

0.1: Broker: Creation of VM #6 failed in Datacenter #2

0.1: Broker: Creation of VM #7 failed in Datacenter #2

0.1: Broker: Sending cloudlet 0 to VM #0

0.1: Broker: Sending cloudlet 1 to VM #1

0.1: Broker: Sending cloudlet 2 to VM #2

0.1: Broker: Sending cloudlet 3 to VM #3

0.1: Broker: Sending cloudlet 4 to VM #0

0.1: Broker: Sending cloudlet 5 to VM #1

0.1: Broker: Sending cloudlet 6 to VM #2

0.1: Broker: Sending cloudlet 7 to VM #3

0.1: Broker: Sending cloudlet 8 to VM #0

0.1: Broker: Sending cloudlet 9 to VM #1

165888.1: Broker: Cloudlet 2 received

165888.1: Broker: Cloudlet 6 received

165888.1: Broker: Cloudlet 3 received

165888.1: Broker: Cloudlet 7 received

248832.09999999998: Broker: Cloudlet 0 received

248832.09999999998: Broker: Cloudlet 4 received

248832.09999999998: Broker: Cloudlet 8 received

248832.09999999998: Broker: Cloudlet 1 received

248832.09999999998: Broker: Cloudlet 5 received

248832.09999999998: Broker: Cloudlet 9 received

248832.09999999998: Broker: All Cloudlets executed. Finishing…

248832.09999999998: Broker: Destroying VM #0

248832.09999999998: Broker: Destroying VM #1

248832.09999999998: Broker: Destroying VM #2

248832.09999999998: Broker: Destroying VM #3

Broker is shutting down…

Simulation: No more future events

CloudInformationService: Notify all CloudSim entities for shutting down.

Datacenter_0 is shutting down…

Broker is shutting down…

Simulation completed.

Simulation completed.

========== OUTPUT ==========

Cloudlet ID STATUS Data center ID VM ID Time Start Time Finish Time

2 SUCCESS 2 2 165888 0,1 165888,1

6 SUCCESS 2 2 165888 0,1 165888,1

3 SUCCESS 2 3 165888 0,1 165888,1

7 SUCCESS 2 3 165888 0,1 165888,1

0 SUCCESS 2 0 248832 0,1 248832,1

4 SUCCESS 2 0 248832 0,1 248832,1

8 SUCCESS 2 0 248832 0,1 248832,1

1 SUCCESS 2 1 248832 0,1 248832,1

5 SUCCESS 2 1 248832 0,1 248832,1

9 SUCCESS 2 1 248832 0,1 248832,1

BikeDetector fog scenario finished!

Fig. 28 Simulare F1

În prima parte a list-ingului se observă că mașinile virtuale VM4-VM8 nu putut fi alocate pe host datorită insuficienței RAM-ului. Așadar în OUTPUT se observă utilizarea doar a lui VM1-4. VM0 și VM 1 au primit fiecare câte 3 cloudlet-uri, în timp ce VM2 și VM3 au primit doar câte 2 cloudlet-uri spre execuție. Având în vedere cele 8000+ mips per cloudlet rezultă și timpii de execuție ai acestora pe respectivele VM-uri, exprimați în cicluri de procesor. Prin împărțirea la frecvență procesor, rezultă un timp maxim de sub o secundă, care satisface criteriul timpului de răspuns pe care ni l-am propus.

Concluzia acestei prime simulări este că cu aceste date de intrare chiar dacă unele VM-uri nu pot fi alocate din diverse motive, cele care totuși pornesc preiau mai multe sarcini pe care le distribuie conform Cloudlet Scheduler policy și se respectă timpii de răspuns ceruți.

Vom modifica parametrii de simulare astfel încât să observăm și alte rezultate interesante.

Simulare F2

S-au corectat valorile RAM pentru Host și VM-uri astfel încât toate VM-urile să poată fi pornite pe Host (pe nodul fog) din punct de vedere al necesarului lor de RAM.

Nunmăr VM-uri: 8

RAM VM = 512 MB

RAM nod fog (host) = 8192 MB

În cadrul listingului se observă că VM-urile 4-7 nu pornesc de data aceasta din cauza cerințelor de mips care trebuiesc alocate simultan pe host.

…

[VmScheduler.vmCreate] Allocation of VM #4 to Host #0 failed by MIPS

[VmScheduler.vmCreate] Allocation of VM #5 to Host #0 failed by MIPS

[VmScheduler.vmCreate] Allocation of VM #6 to Host #0 failed by MIPS

[VmScheduler.vmCreate] Allocation of VM #7 to Host #0 failed by MIPS

0.1: Broker: VM #0 has been created in Datacenter #2, Host #0

0.1: Broker: VM #1 has been created in Datacenter #2, Host #0

0.1: Broker: VM #2 has been created in Datacenter #2, Host #0

0.1: Broker: VM #3 has been created in Datacenter #2, Host #0

…

Fig. 29 Simularea F2 cu suficientă memorie, dar insuficient mips

Rezultatele de timp de execuție sunt aceleași cu Simularea F1, având același număr de mașini virtuale funcționale (4), cu aceiași parametrii.

Simularea F3

În această simulare se micșorează puterea de procesare a VM-urilor, pentru a putea fi toate alocate.

Număr VM-uri: 8

RAM VM = 512 MB

RAM nod fog (host) = 8192 MB

CPU Host = 100.000 mips per core (deci 400.000 total)

CPU vm = 50.000 (astfel încât încap 8 vm-uri pe host în același timp)

========== OUTPUT ==========

Cloudlet ID STATUS Data center ID VM ID Time Start Time Finish Time

2 SUCCESS 2 2 165888 0,1 165888,1

3 SUCCESS 2 3 165888 0,1 165888,1

4 SUCCESS 2 4 165888 0,1 165888,1

5 SUCCESS 2 5 165888 0,1 165888,1

6 SUCCESS 2 6 165888 0,1 165888,1

7 SUCCESS 2 7 165888 0,1 165888,1

0 SUCCESS 2 0 331776 0,1 331776,1

8 SUCCESS 2 0 331776 0,1 331776,1

1 SUCCESS 2 1 331776 0,1 331776,1

9 SUCCESS 2 1 331776 0,1 331776,1

BikeDetector fog scenario finished!

Fig. 30 Simularea F3 cu număr excedentar de VM-uri

Se observă folosirea tuturor VM-urilor. VM-urile 0 și 1 execută câte 2 cloudlet-uri, iar VM-urile 2-7 execută câte un cloudlet.

Timpul maxim de execuție însă crește, deoarece am folosit VM-uri cu jumătate din puterea de procesare reală, reducând inutil perfomanțele.

Concluzia simulării este că trebuie folosite VM-uri cu puterea de procesare reală a host-ului, și trebuie lăsată în sarcina lor distribuția cloudlet-urilor. Adică nu trebuie alocate atâtea VM-uri câte cloudlet-uri, ci atâtea VM-uri câte permite host-ul, deoarece altfel simulatorul fie nu le va putea porni pe toate pe host (Simularea F1 și F2), fie vor avea un caracter limitativ al performanțelor reale ale host-ului (Simularea F3).

Practic pentru acest host, numărul optim de VM-uri este de 4, egal cu numărul de PE-uri de pe host.

Simularea F4

Pentru această simulare, ne propunem să testăm simulatorul, dacă micșorăm numărul de VM-uri sub numărul de PE-uri, lasând distribuția task-urilor pe PE-uri în sarcina VM-urilor.

Număr VM-uri: 1

RAM VM = 512 MB

RAM nod fog (host) = 8192 MB

CPU Host = 100.000 mips per core (deci 400.000 total)

CPU vm = 100.000

Rezultatul este dezamăgitor, VM-ul nu rezolvă mai multe sarcini simultan, practic executând cloudlet-urile alternativ pe același PE.

========== OUTPUT ==========

Cloudlet ID STATUS Data center ID VM ID Time Start Time Finish Time

0 SUCCESS 2 0 829440 0,1 829440,1

1 SUCCESS 2 0 829440 0,1 829440,1

2 SUCCESS 2 0 829440 0,1 829440,1

3 SUCCESS 2 0 829440 0,1 829440,1

4 SUCCESS 2 0 829440 0,1 829440,1

5 SUCCESS 2 0 829440 0,1 829440,1

6 SUCCESS 2 0 829440 0,1 829440,1

7 SUCCESS 2 0 829440 0,1 829440,1

8 SUCCESS 2 0 829440 0,1 829440,1

9 SUCCESS 2 0 829440 0,1 829440,1

BikeDetector fog scenario finished!

Fig. 31 Simularea F4 – număr redus de VM-uri

Așadar, această alternativă nu a adus îmbunătățiri.

Simularea F5

Ne propunem să schimbăm politica de programare a cloudlet-urilor din timeshared în spaceshared pentru a observa comportamentul simulatorului.

========== OUTPUT ==========

Cloudlet ID STATUS Data center ID VM ID Time Start Time Finish Time

0 SUCCESS 2 0 82944 0,1 82944,1

1 SUCCESS 2 0 82944 82944,1 165888,1

2 SUCCESS 2 0 82944 165888,1 248832,1

3 SUCCESS 2 0 82944 248832,1 331776,1

4 SUCCESS 2 0 82944 331776,1 414720,1

5 SUCCESS 2 0 82944 414720,1 497664,1

6 SUCCESS 2 0 82944 497664,1 580608,1

7 SUCCESS 2 0 82944 580608,1 663552,1

8 SUCCESS 2 0 82944 663552,1 746496,1

9 SUCCESS 2 0 82944 746496,1 829440,1

BikeDetector fog scenario finished!

Fig. 32 Simulare F5 – simularea spaceshared

Timpul de execuție per cloudlet este minim, mai mic decât în varianta timeshared (în care numărul de task-uri depășea puterea de procesare simultană), insă deoarece nu există concurență în timp a execuției, timpul total de execuție al tuturor task-urilor este egal cu suma timpilor de execuție per task, atingând 829440 de cicluri de procesor, ca și în Simularea F6.

Simularea F6

Concurența temporală poate fi obținută și în politica de programare spaceshared a VM-urilor, prin mărirea numărului de VM-uri.

Nr. de VM-uri = 4

Politică de programare a cloudlet-urilor: Spaceshared.

========== OUTPUT ==========

Cloudlet ID STATUS Data center ID VM ID Time Start Time Finish Time

0 SUCCESS 2 0 82944 0,1 82944,1

1 SUCCESS 2 1 82944 0,1 82944,1

2 SUCCESS 2 2 82944 0,1 82944,1

3 SUCCESS 2 3 82944 0,1 82944,1

4 SUCCESS 2 0 82944 82944,1 165888,1

5 SUCCESS 2 1 82944 82944,1 165888,1

6 SUCCESS 2 2 82944 82944,1 165888,1

7 SUCCESS 2 3 82944 82944,1 165888,1

8 SUCCESS 2 0 82944 165888,1 248832,1

9 SUCCESS 2 1 82944 165888,1 248832,1

BikeDetector fog scenario finished!

Fig. 33 Simulare F6 – spaceshared cu număr optim de VM-uri

Avantajul acestei simulări față de simulările timeshared (de ex. față de simularea 1, care are același timp total de execuție), este că există cloudlet-uri care se termină mai repede, deci dacă este nevoie de o prioritizare a cloudlet-urilor în aplicație, această politică o poate susține mai bine.

Scenariul cloud

Scenariul cloud a fost simulat pentru un singur nod cloud cu 500 de camere conectate și cu 200 procesoare single-core. S-a încercat astfel echivalarea puterii de procesare din scenariului fog raportată la problema de rezolvat (adică cloudlet / resurse CPU = 5 / 2).

Nod cloud: 200 procesoare single core de 100.000 mips fiecare (echivalente Intel i7)

Număr de camere aferente nodului cloud: 200

Număr de cloudlet-uri: 500

Necesar procesare cloudlet: 8000 mips

Dimensiune cloudlet: 0,25MB (1s de video comprimat)

Simularea C

În simularea nodului cloud s-au considerat un număr de VM-uri egal cu numărul de PE-uri cu caracteristici similare resurselor pe care le virtualizează (mips, RAM).

Nr host-uri: 200 (egal cu nr procesoare)

Nr VM-uri: 200 (din experiența simulărilor Fx, numărul de VM-uri este bine să fie egal cu cel al host-urilor)

Rezultatele sunt prezentate pe sărite în listingul următor:

========== OUTPUT ==========

Cloudlet ID STATUS Data center ID VM ID Time Start Time Finish Time

0 SUCCESS 2 0 82944 0,1 82944,1

1 SUCCESS 2 1 82944 0,1 82944,1

2 SUCCESS 2 2 82944 0,1 82944,1

3 SUCCESS 2 3 82944 0,1 82944,1

…

494 SUCCESS 2 94 82944 165888,1 248832,1

495 SUCCESS 2 95 82944 165888,1 248832,1

496 SUCCESS 2 96 82944 165888,1 248832,1

497 SUCCESS 2 97 82944 165888,1 248832,1

498 SUCCESS 2 98 82944 165888,1 248832,1

499 SUCCESS 2 99 82944 165888,1 248832,1

Fig. 34 Simularea C – a scenariului cloud

Având în vedere că am folosit același raport problemă/resurse și nu am considerat supraaglomerat nodul cloud, iar acesta a fost în întregime la dispoziția aplicației, performanțele sunt identice cu cele din scenariul F1, cu un timp maxim de rezolvare a cloudlet-urilor de 248832,1 cicluri procesor.

Dezvoltări ulterioare

În practică, pentru a simula un sistem real, se pot defini:

mai multe datacenter-uri

host-uri cu performanțe diverse

Quad-core, dual-core etc.

diverse capacități RAM

bandwidth

mai mulți utilizatori

cloudlet-urile pot la rândul lor varia, așa cum și informațiile video comprimate variază ca dimensiune și necesități de procesare

topologii de rețea cu întârzieri/costuri aferente

alți utilizatori care exploatează și ei resursele cloud în alte scopuri (alte tipuri de task-uri)

De asemenea se pot testa și alte resurse ca bottleneck

capacitatea RAM

lâțimea de bandă

capacitatea de stocare (imaginând un scenariu al aplicației în care stocarea să fie necesară)

Concluzii

Modelul IoT (Internet of Things) redă foarte bine atât evoluția explozivă a dispozitivelor conectate la Internet (numite generic obiecte inteligente), cât și tendințele de creștere suplimentară a acestora odată cu implementarea conectivității diverșilor senzori (senzori inteligenți) în aplicații moderne cum ar fi smart grid, smart city, monitorizarea mediului etc sau în aplicații existente din industria extractivă, construcții agricultură etc. în scopul eficientizării, controlului etc. Oricare ar fi aplicațiile, capacitatea de procesare și stocare aflată la periferia rețelei este limitată, iar datele trebuiesc oricum sintetizate și integrate la centru pentru analiză și decizie. Realitatea IoT aduce o serie de cerințe pentru care arhitecturile mai vechi de internet nu sunt pregătite.

Soluția implementată actual la realitatea paradigmei IoT este numită Cloud Computing și se bazează pe servere centrale bogate în resurse dar limitate în comparație cu explozia IoT. Soluția cloud oferă unele avantaje față de modele descentralizate, cum ar fi flexibilitatea, dar se dovedește ineficientă în unele situații, de exemplu în toate aplicațiile în care timpul de răspuns este critic. În plus, datorită drumurilor lungi parcurse de date în rețea de la marginea rețelei (edge) la centru (cloud), soluția cloud este considerată mai costisitoare și mai puțin ecologică decât o soluție mai descentralizată.

O alternativa care rezolvă o parte din limitările cloud computing este promovată de CISCO Systems începând din anii 2010 sub poartă numele de fog computing. Această paradigmă de dezvoltare viitoare a Intenet-ului propune exploatarea unor resurse aflate către periferia rețelei precum routere, servere locale, etc., pentru constituirea unor noduri fog. Aceste nod-uri au rolul de a filtra o parte din datele produse de obiectele inteligente aflate la periferia rețelei, degrevând cloud-ul de o mare parte din date și de task-uri de procesare, reducând aglomerarea cloud-ului și a rețelei, iar pe de altă parte furnizând o soluție viabilă pe termen lung pentru aplicațiile critice ca timp de răspuns.

În dezvoltarea aplicațiilor din lumea IoT, configurația nodurilor de cloud sau fog, împreună cu resursele bogate ale acestora nu sunt atât de disponibile. În plus, testele software se pot face pe un set limitat de configurații aflate la dispoziție. Pentru a reduce costurile și a crește portabilitatea soluțiilor în faza premergătoare dezvoltării aplicațiilor, o unealtă extrem de utilă este un framework de simulare de tipul framework-ului CloudSim utilizat în lucrare, capabil să emuleze entitățile implicate și să modeleze și simuleze sisteme complexe ce implică aceste entități.

Aplicația BikeDetector. o aplicație de detecție a bicicletelor într-un oraș inteligent prezintă trăsăturile unei aplicații tipice de fog computing, deoarece necesită un timp de răspuns rapid în vederea intervenției rapide a autorităților în cazul bicicletelor furate, este distribuită geografic și primește inputul a multe obiecte inteligente (camere video) care produc un volum mare de date și necesități mari de procesare.

Simularea unui sistem atât de complex și costisitor precum cel presupus de aplicația BikeDetector se impune ca o necesitate înaintea dezvoltării. Au fost elaborate 3 scenarii fog, edge și cloud și s-au setat o serie de date generale de simulare, privind perfomanțele așteptate ale sistemului. Ipotezele de performanță ale resurselor (procesoare și rată de transfer) au fost raportate la tehnologii prezente.

S-a convenit că criteriul economic elimină scenariul edge al unor camere inteligente, în ciuda performanțelor. Ulterior scenariile fog și cloud au fost simulate în CloudSim, fiind supuse criteriului timpului de răspuns. Odată acest criteriu satisfăcut pentru un anumit raport cerere – ofertă de resurse, s-a observat funcționarea simulatorului în diverse combinații de parametrii, cum ar fi varierea numărului și performanțelor mașinilor virtuale. Fiecare simulare a fost analizată și s-au tras concluziile aferente privitoare la funcționarea simulatorului și viabilitatea configurațiilor propuse.