Elasticitatea în cloud computing este capacitatea acelui cloud de a se adapta cât mai repede la nevoile aplicației. Există mai multe definiții conform autorilor, unii considerând noțiunile de scalabilitate și elasticitate ca fiind identice, altele ca fiind distincte. Sosirea unor astfel de sisteme distribuite (a se vedea Calculul distribuit ) implică inevitabil probleme tehnice care trebuie reglementate sau limitate. Din punct de vedere economic, sosirea elasticității a avut un impact asupra clienților și furnizorilor de cloud. De exemplu, furnizorii au creat un sistem de plată „ pay-as-you-go ” pentru a plăti resursele utilizate la cerere. Astfel, un client poate închiria un server pentru o perioadă scurtă de timp și la dimensiunea dorită.
Mulți furnizori precum Amazon Web Services , Microsoft Azure sau chiar Google App Engine au creat servere cloud la cerere. Dar fiecare furnizor de cloud are specificul său în ceea ce privește viteza, elasticitatea, latența etc.
Este obișnuit să ne gândim la elasticitate și scalabilitate ca sinonime. Elasticitatea în nor poate fi comparată cu proprietatea fizică a elasticității unui material, care este capacitatea sa de a reveni la forma inițială după deformarea pe care a suferit-o. Astfel, elasticitatea poate fi calculată ca raportul dintre presiunea pe care o poate suferi norul asupra presiunii pe care o suferă.
Cu toate acestea, alții precum NR Herbst și Doaa M. Shawky fac două definiții foarte distincte:
Scalabilitate Scalabilitatea este capacitatea unui sistem de a satisface cerințele de resurse, fără a lua în considerare viteza, timpul, frecvența sau granularitatea acțiunilor sale. Elasticitate Elasticitatea este gradul în care un sistem este capabil să se adapteze cerințelor prin aprovizionarea și dezaprovizionarea resurselor în mod automat, astfel încât resursele furnizate să corespundă cererii sistemului.Prin urmare, scalabilitatea este o condiție prealabilă pentru elasticitate. Timpul este o legătură importantă între elasticitate și scalabilitate: cu cât sistemul durează mai puțin timp pentru a se adapta, cu atât este mai elastic.
Întregul punct de elasticitate din cloud este de a răspunde cât mai precis la cererea de resurse a unei aplicații. Pentru aceasta, sistemele se pot adapta în câteva minute.
Există două abordări ale elasticității. Primul se numește elasticitate orizontală. Această formă de elasticitate se realizează prin adăugarea sau eliminarea mașinilor virtuale din instanța client. A doua abordare, numită verticală, nu se mai realizează prin adăugarea de servere, ci prin adăugarea de resurse la mașină, precum RAM , CPU etc.
Ca regulă generală, elasticitatea orizontală are un cost de timp mai mare decât elasticitatea verticală, deoarece trebuie să așteptați ca mașina virtuală să fie creată și pornită. Astfel, pentru o performanță mai bună, va fi utilizată elasticitatea verticală. Problema este că acest tip de abordare este mult mai limitat decât scalabilitatea orizontală. Într-adevăr, scalabilitatea verticală nu se poate extinde asupra resurselor din afara mașinii fizice. Astfel, este necesar să se definească clar pe ce mașină va porni mașina virtuală la început, pentru a putea scala pe verticală cât mai mult posibil.
În articolul său, Chien-Yu Liu definește un algoritm care, potrivit lui, este cel mai eficient, combinând scalabilitatea aproape infinită a elasticității orizontale și viteza elasticității verticale: Pentru a crește resursele mașinii virtuale, atunci când mașina virtuală nu este suficient de mult, este necesar să se creeze altele noi pe același nor (elasticitate orizontală). Dacă un singur nor nu poate satisface cerințele de resurse, trebuie adăugate mașini virtuale din alte nori (elasticitate orizontală). Când norul nu mai îndeplinește cerințele, trebuie să treceți la următoarea aplicație.
NR Herbst, în articolul său, ne prezintă o modalitate de a calcula elasticitatea de sus în jos și de jos în sus, dar și acuratețea unui sistem cloud supraprovizionat și subprovizionat. Astfel, elasticitatea ascendentă (respectiv descendentă) este invers proporțională cu timpul mediu petrecut de un sistem subalimentat (respectiv supraalimentat) la o stare optimă (respectiv ) de media cantității acumulate de resurse subalimentate (respectiv supra-aprovizionare) pe perioada testului (respectiv ):
Precizia crescătoare (respectiv descendentă) este raportul dintre cantitatea acumulată a resurselor subprovizionate (respectiv supraprovizionate) (respectiv ) și perioada de testare :
Flexibilitatea sistemelor cloud creează unele provocări pentru furnizori. Prima este că există mai multe configurații de bază, de obicei este destul de dificil să știi pe care să o alegi. Scopul este de a avea cea mai bună configurație, fiind în același timp cea mai ieftină. Odată ce acest pas este finalizat, aplicația va avea cereri mai mult sau mai puțin importante pentru momentul respectiv. Cum și când să provizionați / dezafectați sistemul? În acest pas, obiectivul este de a minimiza costurile în infrastructură (euro) și în tranziție (timp).
Una dintre cele mai mari provocări din cloud este depanarea erorilor în sistemele distribuite foarte mari. Fiind probleme legate de sisteme foarte mari, este imposibil să le rezolvi pe sisteme mai mici, astfel încât testele se fac direct pe mediile de producție. Utilizarea mașinilor virtuale poate fi o soluție. Într-adevăr, este posibil să captați informații valoroase pe o mașină virtuală , unde nu este posibilă pe mașinile fizice. Din păcate, toți furnizorii și-au dezvoltat oferta fără a utiliza o mașină virtuală, fie pentru că au început înainte de era virtualizării, fie pentru că au simțit că nu își permit.
O altă provocare este de a gestiona flexibilitatea stocării. S-au făcut multe încercări de a răspunde la această întrebare, variind în ceea ce privește bogăția cererilor și API-urile de stocare, garanțiile de performanță oferite. Ideea este să nu îndeplinească doar așteptările programatorilor în ceea ce privește durabilitatea, disponibilitatea ridicată și capacitatea de a gestiona și interoga date, păstrând în același timp avantajele flexibilității cloud.
Există, de asemenea, provocări care leagă elasticitatea și ecologia norilor . Într-adevăr, este important ca aplicațiile găzduite în cloud să elibereze cât mai mult posibil resursele neutilizate. În primul rând, deoarece un computer în regim de așteptare consumă „doar” două treimi din resursele sale, ceea ce economisește multă energie, iar în al doilea rând, deoarece acest lucru implică un impact mai pozitiv asupra mediului, în timp ce sectorul este foarte sărac. Văzut de opinia publică. Pentru aceasta, furnizorii au creat sistemul de facturare cu granulație fină ( pay-as-you-go ) pentru a încuraja utilizatorii să elibereze resurse cât mai curând posibil.
Licențele software sunt, de asemenea, o problemă. Într-adevăr, unii furnizori de software nu au încă oferte pentru cloud, ceea ce implică costuri astronomice de licență pentru software. Pentru a rezolva această problemă, open source este o soluție foarte populară. Din fericire, unii furnizori, cum ar fi Amazon sau Microsoft, încep să ofere oferte de licențiere software „ pay-as-you-go ”. Deși instanțele rulează pe o structură software plătită, rămâne o alternativă foarte interesantă la soluțiile open source (respectiv 0,15 USD / oră contra 0,10 USD / oră).
Deoarece elasticitatea face posibilă achiziționarea sau eliberarea dinamic a resurselor de calcul ca răspuns la cerere, este important să existe o monitorizare și un control al acestora. Datele care urmează să fie monitorizate sunt clasificate în trei dimensiuni: cost, calitate și resurse. Cadrul ca MELA pentru a monitoriza și analiza elasticitatea serviciilor cloud . Pentru controlul acesteia, instrumente precum SYSBL (Limbaj simplu dar frumos), fac posibilă controlul pe trei niveluri: la nivelul aplicației, la nivelul componentei și la nivelul programării și de asemenea, să îndeplinească cerințele de elasticitate.
O altă problemă de care trebuie să știți este timpul de pornire al mașinilor virtuale. Într-adevăr, acestea trebuie să fie disponibile la timp și gata de utilizare pentru utilizatori. Acest timp de pornire poate lua în considerare diferiți factori: ora din zi, dimensiunea imaginii sistemului de operare, tipul instanței, locația centrelor de date și numărul de instanțe solicitate în același timp.
Fiecare sistem are limitele sale. În cazul norului , una dintre primele identificabile a elasticității sale este numărul de resurse disponibile, au fost găsite alte limite.
Conform testelor lui Doaa M. Shawky, cu cât alocați mai multe mașini la un moment dat, cu atât este mai puțin elastic sistemul. Într-adevăr, în timpul unui experiment, el a comparat două sisteme cu aceleași valori ale stresului, unul crescând numărul de mașini pe pachet cu 10, al doilea pe loturi cu 20. S-a dovedit că timpul mediu d Extinderea celor două experimente este de 4427.2 secunde și respectiv 6334,4 secunde. În același timp, elasticitatea medie a fost de 0,0036 și respectiv 0,0028. În cazul în care elasticitatea sistemului se face orizontal, elasticitatea este, de asemenea, scăzută pe măsură ce crește numărul de mașini alocate. Acest lucru se datorează faptului că timpul de extindere crește. Această limită este cu atât mai adevărată pentru elasticitatea orizontală, deoarece este necesar să așteptați inițializarea și pornirea fiecărei mașini virtuale pentru a crea o instanță.
Datorită elasticității cloud-ului , sistemele furnizorilor au o rată de utilizare a sistemelor lor între 5% și 20%. Ca urmare, există întotdeauna resurse disponibile în cazul în care o cerere puternică de resurse ar trebui să sosească de la unul sau mai mulți clienți.
Furnizorii își permit să își varieze prețurile prin variații ale costurilor cloud : acestea includ achiziționarea și întreținerea de hardware, cum ar fi procesoare, memorie, hard disk și rețea. Dimensiunea memoriei, dimensiunea spațiului pe disc utilizat și costul transmiterii datelor sunt luate în considerare și la închirierea de către client.
Amazon EC2 oferă două modele de afaceri clienților săi:
Datorită cazuri la fața locului oferă , Amazon încurajează clienții săi să utilizeze lor nor în timpul perioadelor afara orelor de vârf, în cele din urmă compania vrea să aplatiza curba de utilizare a nor lor, ceea ce va reduce costurile de întreținere.
Utilizarea norului poate, datorită elasticității sale, să aibă mai multe avantaje pentru un client:
De exemplu, un start-up care trebuia să facă calcule mari ar plăti același preț pentru a utiliza 1000 de mașini Amazon EC2 pentru o oră ca 1 mașină pentru 1000 de ore.
La fel, în cazul unei utilizări care variază foarte mult în timp, este interesant să folosiți cloud-ul. Datorită elasticității ofertei „pay-as-you-go” oferită de mulți furnizori, clientul plătește doar pentru ceea ce folosește. De exemplu, în cazul unui client care folosește 500 de servere în timpul orelor de vârf, dar numai 100 în perioadele de vârf, cu o medie de 300 de servere în timpul zilei. Fără cloud, clientul ar trebui să aibă 500 de servere sau 500 x 24 = 12.000 de servere-oră. Datorită cloud-ului și a elasticității sale, folosește doar 300 x 24 = 7.200 ore-server.
Dar această analiză nu ține cont de faptul că cloud-ul permite adaptarea rapidă la o cerere pentru o resursă neobișnuită, de exemplu, site-urile de vânzare online din decembrie. Impactul aici este foarte minim, în timp ce dacă clientul și-ar găzdui singur site-ul, comandarea și instalarea de noi servere ar fi putut dura câteva săptămâni, ca să nu mai vorbim de faptul că odată ce sărbătorile au trecut, serverele lor nu ar fi avut ar fi fost mai utile .
În 2010, s-a făcut o comparație între furnizorii de cloud public: Amazon AWS, Azure, AppEngine și CloudServers Acești furnizori au fost evaluați în jurul a 4 criterii: elasticitate cluster , stocare persistentă, rețea intra-cloud și rețele vaste.
Din motive juridice, identitatea furnizorilor de cloud public este anonimizată pe rezultate și este desemnată de la C1 la C4.
Dimensiunea serverului | configurare | Cost / oră | cost / bază |
---|---|---|---|
Amazon EC2 | |||
mic | 1 ECU, 1,7 GB RAM, 160 GB spațiu pe disc | 0,085 USD | 0,085 USD |
înalt | 4 ECU, 7,4 GB RAM, 850 GB spațiu pe disc | 0,34 dolari | 0,085 USD |
mediu - rapid | 5 ECU, 1,7 GB RAM, 350 GB spațiu pe disc | 0,17 USD | 0,034 USD |
XL | 8 ECU, 15 GB RAM, 1,7 TB spațiu pe disc | 0,68 dolari | 0,085 USD |
XL- rapid | 20 ECU, 7 GB ram, 1,7 TB spațiu pe disc | 0,68 dolari | 0,034 USD |
Cloud privat | |||
mic | 1 nucleu, 2,8 GHz , 1 GB RAM, 36 GB spațiu pe disc | 0,11 USD | 0,11 USD |
cale | 2 nuclee, 3,2 GHz , 2 GB RAM, 146 GB spațiu pe disc | 0,17 USD | 0,085 USD |
înalt | 4 nuclee, 2 GHz , 4 GB RAM, 250 GB spațiu pe disc | 0,25 USD | 0,063 USD |
rapid | 4 nuclee, 3 GHz , 4 GB RAM, 600 GB spațiu pe disc | 0,53 USD | 0,133 dolari |
XL | 8 nuclee, 2 GHz, 8 GB RAM, 1 TB spațiu pe disc | 0,60 USD | 0,075 USD |
Furnizor | Tipul instanței | Numărul de nuclee | Preț |
---|---|---|---|
C1 | C1.1 | 1 | 0,085 USD / oră |
C1.2 | 2 | 0,34 USD / oră | |
C1.3 | 4 | 0,68 USD / oră | |
C2 | C2.1 | 4 | 0,015 USD / oră |
C2.2 | 4 | 0,03 USD / oră | |
C2.3 | 4 | 0,06 USD / oră | |
C2.4 | 4 | 0,12 USD / oră | |
C3 | în mod implicit | n / A | 0,10 USD / oră CPU |
C4 | C4.1 | 1 | 0,12 USD / oră |
C4.2 | 2 | 0,24 USD / oră | |
C4.3 | 4 | 0,48 $ / oră | |
C4.4 | 8 | 0,96 USD / oră |
Un grup de servere este încărcat pentru fiecare utilizare. Există două tipuri de modele de încărcare între furnizori: IaaS (AWS, Azure și CloudServers) o încărcare bazată pe timpul alocat rămas, indiferent dacă instanța este utilizată pe deplin sau nu; PaaS (AppEngine), încărcare bazată pe consumul de CPU în exces al aplicației utilizatorului pe zi.
Clusterele de servere sunt, de asemenea, „elastice” în sensul că un utilizator poate crește sau micșora dinamic numărul de instanțe utilizate. AppEngine efectuează această modificare în mod transparent, spre deosebire de AWS, Azure și CloudServer, care acceptă „scalarea opacă”.
Pentru a evalua elasticitatea clusterelor , au fost efectuate 3 teste:
Timp de execuție de referință similar cu arhitecturile tradiționale de evaluare comparativă pentru aceasta măsoară timpul de executare a sarcinilor de referință. Sarcinile de referință efectuează un test de stres pe toate resursele mașinii ( CPU , memorie și disc) Cost costul efectuării fiecărei sarcini de referință Latența „Scalare” acesta este timpul scurs între clientul care solicită resursa și alocarea unei noi instanțe. Latența „scalării” poate afecta performanța și costul implementării unei aplicații.Pentru teste, sunt comparate performanțele clusterelor ( benchmark , cost pe benchmark și latență de scalare ).
Serviciu | Interventie chirurgicala |
---|---|
Masa | obține, pune, interogă |
Blob | descarca incarca |
Coadă | Trimite primește |
Serviciile de stocare mențin starea și datele unei aplicații și sunt accesibile instanțelor prin apeluri API. Există 2 modele economice pentru operațiunile de depozitare. Serviciile oferite de Amazon AWS și Google AppEngine se bazează pe ciclurile procesorului consumate pentru a efectua o operație de stocare, ceea ce face ca cererile complexe să fie mai scumpe. Azure și CloudServers au un cost fix pe operațiune, indiferent de complexitatea cererii.
Pentru a compara furnizorii în ceea ce privește stocarea, au fost efectuate 3 teste:
timpul de răspuns al operațiilor măsoară timpul de execuție al unei operațiuni de stocare. Operațiunile efectuate sunt susținute de toți furnizorii și utilizate frecvent de clienți. Acestea sunt operații simple de citire / scriere, interogări SQL pentru a testa performanța bazelor de date.Furnizor | obține | a pune | interogare |
---|---|---|---|
C1 | 0,13 | 0,31 | 1,47 |
C3 | 0,02 | 0,23 | 0,29 |
C4 | 0,10 | 0,10 | 0,10 |
Furnizor | instanță mai mică | cea mai mare instanță |
---|---|---|
C1 | 773.4 | 782.3 |
C2 | 235,5 | 265,7 |
C4 | 327.2 | 763.3 |
Pentru a compara performanța furnizorilor la nivel de rețea, au fost efectuate teste pe rețeaua intra-cloud și pe rețelele cu suprafață largă.
Rețeaua intra-cloud conectează instanțele unui client între ele și serviciile partajate de un cloud . Pentru a compara performanța unei rețele intra-cloud , sunt luate măsurători ale capacității și latenței căii .
Rețeaua extinsă conectează centrele de date într-un nor între ele și gazdele externe de pe internet. Furnizorii oferă mai multe zone pentru a găzdui aplicațiile unui client pentru a reduce latența. AppEngine oferă un serviciu DNS pentru a alege automat un centru de date aproape la cerere, în timp ce alți furnizori necesită configurare manuală. Latența optimă pentru o rețea de zonă largă este definită de latența minimă dintre o poziție optimă și orice centru de date al unui furnizor. Prin urmare, criteriul pentru compararea testelor va fi numărul de centre de date disponibile într-un punct optim.
: document utilizat ca sursă pentru acest articol.