UNIVERZA V LJUBLJANI
FAKULTETA ZA RA ˇ CUNALNIˇ STVO IN INFORMATIKO
Miha Grohar
Integracija hibridnega oblaka z virtualnim laboratorijem
DIPLOMSKO DELO
NA UNIVERZITETNEM ˇSTUDIJU
Mentor: doc. dr. Mojca Ciglariˇc
Ljubljana, 2011
Besedilo je oblikovano z urejevalnikom besedil LATEX.
Spodaj podpisani Miha Grohar, z vpisno ˇstevilko 63040045,
sem avtor diplomskega dela z naslovom: Integracija hibridnega oblaka z virtualnim laboratorijem
S svojim podpisom zagotavljam, da:
• sem diplomsko delo izdelal samostojno pod mentorstvom doc. dr. Mojce Ciglariˇc
• so elektronska oblika diplomskega dela, naslov (slov., angl.), povzetek (slov., angl.) ter kljuˇcne besede (slov., angl.) identiˇcni s tiskano obliko diplomskega dela
• soglaˇsam z javno objavo elektronske oblike diplomskega dela v zbirki
”Dela FRI”.
V Ljubljani, dne 15.09.2011 Podpis avtorja:
Zahvala
Za pomoˇc pri diplomskem delu se zahvaljujem mentorici doc. dr. Mojci Ci- glariˇc in celotni ekipi Laboratorija za raˇcunalniˇske komunikacije. Z njihovimi nasveti in konstruktivnimi kritikami so pripomogli k boljˇsemu konˇcnemu iz- delku diplomske naloge. Posebej bi se rad zahvalil tudi Tinetu Lesjaku, ki mi je na podlagi lastnih izkuˇsenj pomagal premagati zaˇcetne ovire pri spoznava- nju okolja VCL in asistentoma Matjaˇzu in Andreju, ki sta preverila delovanje konˇcnega izdelka diplomskega dela.
Kazalo
Povzetek 1
Abstract 2
1 Uvod 3
1.1 Motivacija . . . 3
1.2 Zgradba diplomskega dela . . . 5
2 Raˇcunalniˇstvo v oblaku 7 2.1 Namestitveni modeli oblakov . . . 8
2.2 Modeli storitev raˇcunalniˇstva v oblaku . . . 8
2.3 Primerjava modelov . . . 9
2.4 Nevarnosti javnega oblaka . . . 11
2.4.1 Izpadi delovanja . . . 11
2.4.2 Zaˇsˇcita pred izpadi . . . 12
3 VCL - Virtual Computing Lab 13 3.1 Ozadje VCL . . . 13
3.2 Visokonivojska arhitektura VCL . . . 13
3.3 Uporabnik . . . 15
3.4 Nizkonivojska arhitektura VCL . . . 16
3.4.1 Okolja za oskrbovanje s fiziˇcnimi ali virtualnimi viri . . . 17
3.4.2 Upravljalec VCL . . . 18
3.4.3 Odprtokodni spletni streˇznik Apache . . . 18
3.4.4 Odprtokodna podatkovna baza MySQL . . . 19
3.4.5 Slike . . . 19
3.5 Strojna oprema v VCL . . . 20
3.6 Varnost v VCL . . . 20
3.7 Visoko zmogljivo raˇcunalniˇstvo in VCL . . . 22
3.8 Prednosti uporabe VCL v laboratorijih . . . 22
4.2.1 Amazon Machine Images in instance . . . 25
4.2.2 Regije in razpoloˇzljiva obmoˇcja . . . 26
4.3 Shranjevanje podatkov . . . 27
4.4 Varnost v EC2 . . . 29
4.4.1 OS gostitelja (ang. host OS) . . . 29
4.4.2 Gostujoˇci OS (ang. guest OS) . . . 29
4.4.3 Poˇzarni zid . . . 30
4.4.4 Klici vmesnika API . . . 31
4.5 Virtualizacijsko okolje - hipervizor Xen . . . 32
5 Integracija hibridnega oblaka 34 5.1 Arhitektura hibridnega oblaka . . . 35
5.2 Povezava z javnim oblakom . . . 36
5.2.1 Vmesnik API Amazon EC2 . . . 36
5.2.2 Perlova knjiˇznica VM::EC2 . . . 37
5.3 Namestitev okolja VCL za potrebe razvoja . . . 40
5.4 Modularna arhitektura VCL . . . 40
5.4.1 Ozadje . . . 40
5.4.2 Objektna usmerjenost in dedovanje . . . 41
5.5 Razvoj modula za oskrbovanje . . . 42
5.5.1 Vmesnik modula za oskrbovanje . . . 44
5.5.2 Potek nalaganja nove slike . . . 46
5.5.3 Potek zajema nove slike . . . 46
5.6 Primer uporabe konˇcnega uporabnika . . . 47
5.6.1 Rezervacija virtualnega raˇcunalnika . . . 47
5.6.2 Zajem nove slike . . . 48
5.7 Prednosti in slabosti hibridnega oblaka . . . 50
6 Zakljuˇcki in nadaljnje delo 54 6.1 Zakljuˇcki . . . 54
6.2 Nadaljnje delo in izkuˇsnje . . . 55
Seznam slik 57
Seznam izvorne kode 58
Literatura 59
Seznam uporabljenih kratic in simbolov
VCL (ang. Virtual Computing Lab) - Odprtokodna programska oprema, ki omogoˇca oskrbovanje z raˇcunalniˇski viri
EC2 (ang. Elastic Compute Cloud) - Amazonova spletna storitev, ki nudi razˇsirljivo raˇcunalniˇsko infrastrukturo v javnem oblaku
S3 (ang. Simple Storage Solution) - Amazonova reˇsitev za shranjevanje po- datkov v medmreˇzju
AWS (ang. Amazon Web Services) - Amazonove spletne storitve
NCSU (ang. North Carolina State University) - drˇzavna univerza Severne Karoline v ZDA
API (ang. Application programming interface) - Programski vmesnik, ki za- gotavlja, da ima raˇcunalniˇski program na razpolago funkcije drugega raˇcunalniˇskega programa
SSH (ang. Secure Shell) - varen protokol za upravljanje raˇcunalnika na da- ljavo
RDP (ang. Remote Desktop Protocol) - protokol za upravljanje raˇcunalnika z operacijskim sistemom Windows na daljavo.
HTTP (ang. Hyper Text Transfer Protocol) - Protokol za izmenjavo nadbe- sedil ter grafiˇcnih, zvoˇcnih in drugih veˇcpredstavnostnih vsebin na spletu REST (ang. Representational State Transfer) - Tip spletne arhitekture v porazdeljenem sistemu, kjer gre za komunikacijo med streˇznikom in od- jemalcem
delo s podatkovnimi bazami
XML (ang. Extensible Markup Language) - Razˇsirljivi oznaˇcevalni jezik, ki oznaˇcuje format podatkov za izmenjavo strukturiranih dokumentov v spletu
WSDL (ang. Web Services Description Language) - Oznaˇcevalni jezik za opis funkcionalnosti spletnih storitev
IaaS (ang. Infrastructure as a Service) - storitveni model oblaka, ki ponuja infrastrukturo
PaaS (ang. Platform as a Service) - storitveni model oblaka, ki ponuja plat- formo na kateri lahko izvajamo aplikacije
SaaS (ang. Software as a Service) - storitveni model oblaka, ki ponuja pro- gramsko opremo
xCAT (ang. Extreme Cloud Administration Toolkit) - zbirka orodij za upra- vljanje streˇzniˇskih gruˇc
HPC (ang. High-Performance Computing) - visoko zmogljivo raˇcunalniˇstvo AMI (ang. Amazon Machine Image) - slika virtualnega okolja v EC2, zajema
programski sklad operacijskega sistema in aplikacij
EBS (ang. Elastic Block Store) - Amazonova storitev, ki zagotavlja virtualne diskovne enote
Povzetek
V Laboratoriju za raˇcunalniˇske komunikacije trenutno uporabljamo okolje Vir- tual Computing Lab (VCL) za potrebe izvajanja vaj pri razliˇcnih predmetih.
Sistem ˇstudentom omogoˇca dostop do virtualnih okolij, na katerih ˇstudentje izvajajo svoje naloge. Sestavljen je iz zasebnega oblaka 11 streˇznikov, ki s pomoˇcjo virtualizacijske tehnologije VMware omogoˇcajo oskrbovanje z virtu- alnimi raˇcunalniki. Zasebni oblak je veˇcino ˇcasa slabo izkoriˇsˇcen, ob doloˇcenih obdobjih pa se pojavljajo poveˇcane potrebe po virih, ki preobremenijo sis- tem. Za omenjeni problem v diplomskem delu predlagamo reˇsitev v obliki hibridnega oblaka. Obstojeˇc zasebni oblak bi normalno deloval ˇse naprej, v primerih preobremenjenosti pa bi imeli moˇznost uporabe virov javnega oblaka.
V ta namen smo razvili modul VCL za oskrbovanje z viri javnega oblaka Ama- zon EC2. S hibridnim oblakom reˇsimo problem preobremenjenosti obstojeˇcega zasebnega oblaka in doseˇzemo boljˇso izkoriˇsˇcenost virov. Pri javnem oblaku plaˇcujemo le dejansko porabo raˇcunskih ciklov in prostora, ki ga zasedamo. S tem doseˇzemo boljˇso stroˇskovno uˇcinkovitost v primerjavi z nakupom dodatne fiziˇcne strojne opreme oziroma nadgradnjo obstojeˇcega zasebnega oblaka. Za razumevanje delovanja hibridnega oblaka smo v diplomskem delu predstavili podroˇcje raˇcunalniˇstva v oblaku, opisali arhitekturo odprtokodnega sistema VCL in obravnavali delovanje javnega oblaka EC2. Za naˇso reˇsitev smo izbrali slednjega, saj je Amazon EC2 trenutno eden izmed vodilnih ponudnikov. Na koncu se seznanimo z naˇcinom integracije preko vmesnika javnega oblaka in predlagamo arhitekturo hibridnega oblaka. Kot dokaz o uspeˇsni integraciji hi- bridnega oblaka, njegovo delovanje prikaˇzemo z razvijalˇcevega vidika in vidika konˇcnega uporabnika.
Kljuˇ cne besede:
raˇcunalniˇstvo v oblaku, Virtual Computing Lab, Amazon EC2, oskrbovanje z viri, hibridni oblak
1
Virtual Computing Lab (VCL) environment at Computer communications lab enables students remote access to virtual environments, in which they fulfill their course assignments. It is comprised of 11 physical servers with VMware hardware virtualization that allows provisioning of virtual machines. Most of the time the private cloud in underutilizated, while it gets overutilizated during usage peaks at the end of semester or around deadlines for certain student assignments. In this thesis we suggest a solution for the overutilization problem in form of a hybrid cloud. Current private cloud could still be used as it was untill now, but we would have a possibility to expand available resources with public cloud during usage peaks. To address this issue we have developed a new VCL provisioning module for provisioning Amazon EC2 public cloud resources.
Hybrid cloud solution expands capabilites of VCL environment during usage peaks and provides optimal resource utilization. With public cloud’s “pay- as-you-go” model we only pay for resources (compute cycles, storage) that we actually use. With hybrid cloud we achieve better cost efficency, than we would have with investments into new physical infrastructure to meet the demand for resources during usage peaks. To really understand how hybrid cloud solution works, we discuss cloud computing, describe open-source VCL environment and EC2 public cloud. In the end we explain how to integrate hybrid cloud with connecting via public cloud’s API interface and suggest hybrid cloud’s architecture in case of Computer communications lab. The result of this thesis is a working proof-of-concept hybrid cloud solution for VCL environment.
Key words:
cloud computing, Virtual Computing Lab, Amazon EC2, resource provisio- ning, hybrid cloud
2
Poglavje 1 Uvod
1.1 Motivacija
Laboratorij za raˇcunalniˇske komunikacije trenutno sestoji iz zasebnega oblaka, ki zaenkrat zadostuje potrebam za izvajanje laboratorijskih vaj. Oblak je sestavljen iz prilagojenega odprtokodnega sistema VCL (ang. Virtual Compu- ting Lab), ki omogoˇca oskrbovanje z raˇcunalniˇski viri. ˇStudentom in osebju omogoˇca rezerviranje virtualnih okolij z enim ali veˇc virtualnimi raˇcunalniki, do katerih lahko dostopajo od doma oziroma s fakultete. Sistem poganja 11 fiziˇcnih streˇznikov, ki skupaj zagotavljajo pribliˇzno 300 virtualnih raˇcunalnikov.
Njegove kapacitete so omejene. Sistem je veliko ˇcasa slabo izkoriˇsˇcen, pred- vsem med poletnimi meseci, ko so ˇstudijske poˇcitnice. Preobremenjen pa je v obdobjih tik pred koncem semestrov in pred roki za oddajo seminarskih na- log. Prav tako se v ˇcasu laboratorijski vaj poveˇcajo zakasnitve sistema, ko mnoˇzica ˇstudentov istoˇcasno zaˇzene veˇcje ˇstevilo virtualnih raˇcunalnikov. V diplomskem delu poizkuˇsamo najti reˇsitev za omenjene probleme. Ali fakul- teta investira v nakup nove fiziˇcne strojne opreme in s tem zveˇca zmogljivost virtualnega laboratorija ter zmanjˇsa izkoriˇsˇcenost virov ali pa sistem poveˇze z javnim oblakom in plaˇcuje le najemnino za uporabo virov. Odloˇcili smo se za slednje in predlagali reˇsitev v obliki hibridnega oblaka. Obstojeˇc zasebni oblak bi normalno deloval ˇse naprej, v primerih preobremenjenosti pa bi imeli moˇznost uporabe virov javnega oblaka.
Osnovna motivacija je bila kako zadostiti poveˇcanim potrebam po virih ob konicah, ki se pojavljajo nekajkrat na leto. S povezavo z javnim oblakom pa se nam odpre ˇse mnogo drugih moˇznosti, ki pridejo prav tudi v izobraˇzevalnih ustanovah. Javni oblaki ponujajo navidezno neomejene raˇcunalniˇske zmoglji- vosti. Hibridni oblak omogoˇca raziskovalcem, da zahtevno procesiranje pre-
3
selijo v javni oblak in tako hitreje pridejo do reˇsitev. Fakulteta za reˇsevanje nekaterih raˇcunsko zahtevnih nalog enostavno nima zadostnih zmogljivosti, oziroma bi bila investicija v drago strojno opremo nesmiselna, v kolikor ta ne bi bila polno izkoriˇsˇcena. Javni oblaki se neprestano razvijajo in so zaˇceli ponujati tudi visoko zmogljivostne raˇcunalnike ter virtualne oblake. Odveˇc je poudariti, da je taka oprema izjemno draga, raziskovalcu pa neprecenljivo, ˇce mu fakulteta omogoˇci dostop do omenjenih virov, ˇceprav zgolj za omejen ˇcas.
Prav tako se zdi smiselna uporaba javnega oblaka za varnostne kolokacije.
Fakulteta bi lahko svojo infrastrukturo podvojila z virtualnimi viri z minimal- nimi kapacitetami javnega oblaka, v primeru izpada lastne infrastrukture bi enostavno preusmerila promet v javni oblak in poveˇcala zmogljivost virtual- nih virov ter s tem zadostila dejanskim potrebam. Tako bi med obdobjem izpada lastne infrastrukture najeli veˇc kapacitet, po vzpostavitvi sistema na- zaj v prvotno stanje pa bi le-te zmanjˇsali na nivo, ki je potreben za varnostno preslikavanje.
Dodano vrednost hibridnega oblaka vidimo tudi v primeru laboratorijskih vaj, ki temeljijo na programski opremi doloˇcenega proizvajalca. Trenutno to poteka tako, da si ˇstudentje namestijo programsko opremo na svoje la- stne raˇcunalnike oziroma uporabijo raˇcunalnike v laboratoriju, na katere je orodja namestil administrator. Namestitve so lahko dolgotrajne in mnogo- krat ˇstudentje nimajo dovolj zmogljive strojne opreme za poganjanje zahtevnih programskih orodij. Veliko bolj enostavno bi bilo, da bi se fakulteta s proi- zvajalcem programske opreme (npr. IBM, Microsoft) dogovorila za uporabo njihovega javnega oblaka, kjer so okolja ˇze vzpostavljena. Fakulteta ima s pro- izvajalci dogovor glede licenc, tako da bi lahko obstojeˇc dogovor le nadgradili z uporabo njihovih virtualnih virov iz javnega oblaka.
Kljuˇcna prednost vpeljave hibridnega oblaka v okolje VCL pa je v tem, da poteka oskrbovanje z viri javnega in zasebnega oblaka centralizirano preko enotnega sistema. Ne glede na to ali gre za ˇstudente, pedagoge, raziskovalce ali osebje za vzdrˇzevanje raˇcunalniˇske infrastrukture. VCL omogoˇca sofisticiran naˇcin dodeljevanja pravic razliˇcnim uporabnikov, kar omogoˇca da raziskoval- cem dodelimo pravico za uporabo visoko zmogljivih virtualnih raˇcunalnikov za neomejen ˇcas, ˇstudentom pa omogoˇcimo dostop do standardnih zmogljivosti in dodamo ˇcasovno omejitev uporabe. Prav tako imamo moˇznost, da fakulteta za vse porabljene vire od ponudnika javnega oblaka prejme enoten raˇcun.
1.2 Zgradba diplomskega dela 5
1.2 Zgradba diplomskega dela
Namen diplomskega dela je dokazati koncept uporabe hibridnega oblaka v izobraˇzevalni ustanovi. Zato smo obstojeˇce okolje VCL v Laboratoriju za raˇcunalniˇske komunikacije razˇsirili z javnim oblakom ponudnika Amazon. Raz- vili smo nov modul za oskrbovanje z viri javnega oblaka Amazon EC2 in pre- izkusili delovanje. Za razumevanje delovanja hibridnega oblaka je potrebno predstaviti ˇsiroko podroˇcje raˇcunalniˇstva v oblaku.
Na zaˇcetku bomo obravnavali temo raˇcunalniˇstva v oblaku, ki je razmeroma novo podroˇcje in se neprestano razvija. Opisali bomo razliˇcne tipe oblakov in modele storitev v oblaku. Za podrobnejˇso predstavitev bomo naredili primer- javo razliˇcnih modelov konkretnih ponudnikov javnega oblaka. Spoznali se bomo z nekaterimi nevarnostmi javnih oblakov in naˇcini, kako se zavarovati pred njimi.
V 3. poglavju predstavimo okolje VCL. VCL je odprtokodni sistem za oskr- bovanje z raˇcunalniˇskimi viri. Omogoˇca rezervacije fiziˇcnih raˇcunalniˇskih virov, virtualnih raˇcunalnikov in visoko zmogljivih raˇcunalnikov. Preko spletnega vmesnika konˇcnim uporabnikom omogoˇca rezervacije virov in administracijo celotnega sistema. Sistem je modularen in prilagodljiv. Razvit je bil na drˇzavni univerzi Severne Karoline v ZDA (NCSU [http://vcl.ncsu.edu/]), leta 2008 pa so izvorno kodo predali odprtokodni skupnosti Apache Software Foundation (ASF). Predstavili bomo njegovo arhitekturo in opisali reˇsitve za shranjevanje podatkov, varnostne vidike sistema in primere uporabe.
Okolje VCL predstavlja zasebni oblak, namen diplomskega dela pa je raz- ˇsiritev v hibridni oblak. Kot najprimernejˇsega ponudnika javnega oblaka za in- tegracijo hibridnega oblaka smo izbrali Amazon Elastic Compute Cloud (EC2).
V 4. poglavju obravnavamo njegovo delovanje, orodja za upravljanje z viri javnega oblaka in na kratko predstavimo, katere tipe instanc ponuja. Posebno pozornosti posvetimo varnosti, saj je ta v javnem oblaku zelo pomembna.
Bralec je po 4. poglavju seznanjen s kljuˇcnima elementoma za integracijo hibridnega oblaka, zasebnim in javnim oblakom. Zato sledi poglavje, kjer podrobno predstavimo konkretno realizacijo hibridnega oblaka okolja VCL in oblaka EC2. Poglavje je bolj tehniˇcne narave in opisuje predlagano arhitekturo hibridnega oblaka. Opiˇsemo naˇcin, kako preko vmesnika API poveˇzemo javni in zasebni oblak, predstavimo podrobnosti namestitve okolja VCL ter naˇcin gradnje modulov. Obravnavamo konkretno delovanje modula z razvijalˇcevega vidika in vidika konˇcnega uporabnika. Na koncu kritiˇcno ocenimo naˇso reˇsitev in predstavimo prednosti in slabosti hibridnega oblaka.
Zakljuˇcke diplomskega dela predstavimo v zadnjem poglavju in predlagamo
smernice za nadaljnje delo s hibridnim oblakom.
Poglavje 2
Raˇ cunalniˇ stvo v oblaku
Koncept raˇcunalniˇstva v oblaku spreminja naˇcine vzpostavljanja infrastrukture IT v podjetjih, izobraˇzevalnih ustanovah, raziskovalnih zavodih in javni upravi.
Zanimanje za tehnologijo se je zadnja leta poveˇcevalo in na trgu so se pojavile razliˇcne reˇsitve. Oblak je dosegel ˇsiroko skupino uporabnikov, od katerih se marsikdo sploh ne zaveda, da uporablja storitve raˇcunalniˇstva v oblaku.
Definicija po ameriˇskem Nacionalnem inˇstitutu za standarde in tehnologijo [3]:
Raˇcunalniˇstvo v oblaku je model, ki omogoˇca primeren omreˇzni dostop na zahtevo iz katerekoli lokacije do deljene mnoˇzice nasta- vljivih raˇcunalniˇskih virov (npr. omreˇzij, streˇznikov, sistemov za shranjevanje podatkov, aplikacij in storitev), ki jih lahko hitro pri- dobimo in sprostimo z minimalnim upravljalnim trudom oziroma minimalno interakcijo ponudnika storitve. Model oblaka zagotavlja razpoloˇzljivot virov in je sestavljen iz petih osnovnih karakteristik, treh storitvenih modelov in ˇstirih namestitvenih modelov.
Osnovne karakteristike so: dostop na zahtevo, omreˇzni dostop za ˇsirok raz- pon naprav, dinamiˇcno dodeljevanje virov, elastiˇcnost in merljivost uporabe storitve. Namestitvene in storitvene modele oblaka obravnavamo v naslednjih podpoglavjih. Podobno kot naravni oblak se tudi sam tehnoloˇski izraz spremi- nja tako hitro, da mu je vˇcasih izjemno teˇzko slediti. Vsekakor bo tehnologija pustila globoke posledice v industriji IT. Raˇcunalniˇstvo v oblaku je termin, ki se je mnogo let poˇcasi razvijal na hrbtih drugih tehnologij in je naravni re- zultat evolucije teh tehnologij. Zanimanje za tehnologijo je vedno veˇcje, prav tako pa se pojavlja vedno veˇc uporabnikov storitev raˇcunalniˇstva v oblaku.
7
2.1 Namestitveni modeli oblakov
Oblaki se med seboj razlikujejo glede na naˇcin namestitve. Poznamo zasebni, javni in hibridni oblak. Na sliki [2.1] so prikazana razmerja med posameznimi modeli. Zasebni oblak zajema infrastrukturo, ki jo koristi in upravlja doloˇcena organizacija. Ponavadi se vsi viri nahajajo na isti lokaciji. Javni oblak upra- vljajo ponudniki in svoje vire nudijo zainteresiranim strankam. Toˇcna lokacija infrastrukture konˇcnemu uporabniku ni znana. Hibridni oblak je sestavljen iz obeh, javnega in zasebega oblaka. Oblaka sta ˇse vedno loˇceni entiteti, vendar preko vmesnikov omogoˇcata vzajemno delovanje.
Oblak Javni
oblak Zasebni
oblak
Hibridni oblak
Zunanja infrastruktura Zasebni prostori
CC-BY-SA 3.0bySam Johnston
Slika 2.1: Namestitveni modeli oblaka
2.2 Modeli storitev raˇ cunalniˇ stva v oblaku
Osnovni modeli storitev raˇcunalniˇstva v oblaku so:
• Infrastructure as a Service (IaaS) – dostop na zahtevo do uporabniˇsko definiranih strojnih zmogljivosti, povezljivosti in pomnilniˇskih kapacitet.
Storitve se lahko izvajajo na poljubni fiziˇcni strojni opremi, ki konˇcnemu uporabniku ni znana.
2.3 Primerjava modelov 9
• Platform as a Service (PaaS) – dostop na zahtevo do uporabniˇsko defi- niranega nabora virtualizacijskega okolja, operacijskega sistema in vme- snega sloja programske opreme (ang. middleware), ki zagotavlja delova- nje uporabniˇskih aplikacij in storitev. PaaS se lahko izvaja nad plastjo HaaS oziroma IaaS. Konˇcni uporabnik dobi nadzor nad operacijskim sis- temom.
• Software as a Service (SaaS) – konˇcni uporabnik uporablja programsko opremo in shranjuje podatke, samo delovanje storitve pa ga ne zanima.
Pojavljajo se tudi izrazi:
• Hardware as a Service (HaaS) – dostop na zahtevo do toˇcno doloˇcene strojne opreme na toˇcno doloˇceni lokaciji. Strojna oprema lahko zajema streˇznike, sisteme za shranjevanje podatkov, mreˇzno opremo itd. Konˇcni uporabnik se zaveda, kakˇsno fiziˇcno strojno opremo hoˇce uporabljati in pozna njeno lokacijo.
• Application as a Service (AaaS) – dostop na zahtevo do aplikacij.
• Cloud as a Service (CaaS), Security as a Service, Portabilitiy as a Service, Storage as a Service.
2.3 Primerjava modelov
Z virtualizacijo virov doseˇzemo elastiˇcnost in iluzijo o neskonˇcni zmogljivosti raˇcunalniˇskih virov, sama implementacija deljenja in multipleksiranja virov pa je lahko skrita pred razvijalcem-uporabnikom. Razliˇcne ponudbe raˇcunalniˇstva v oblaku se razlikujejo glede na stopnjo abstrakcije in naˇcina upravljanja z viri [1].
Amazon EC2 je predstavnik prvega dela spektra. Ena instanca EC2 je z vidika uporabnika zelo podobna obiˇcajni strojni opremi. Nadzorujemo celoten programski sklad od jedra operacijskega sistema navzgor. Na instanci lahko gostimo katerikoli tip aplikacije. Nizek nivo virtualizacije omogoˇca razvijalcem, da uporabljajo instance na enak naˇcin, kot to poˇcnejo z obiˇcajnimi fiziˇcnimi streˇzniki. Na drugi strani pa to Amazonu onemogoˇca, da bi ponudili samodejno skalabilnost, saj je ta odvisna predvsem od aplikacijske plasti.
Amazon sicer ponuja tudi storitve na viˇsjih nivojih abstrakcije, ki jih lahko uporabljamo v kombinaciji z EC2, vendar se te ne uporabljajo v taki meri, predvsem zaradi zakasnitev in nestandardnih vmesnikov API. Amazon EC2 je tipiˇcen predstavnik modela IaaS.
Na drugi strani spektra storitvenih modelov raˇcunalniˇstva v oblaku pa sta domensko specifiˇcni platformi Google AppEngine in Force.com. AppEngine je namenjen izkljuˇcno tradicionalnim spletnim aplikacijam, ki morajo temljiti na
“zahteva-odziv” (ang. request-response) arhitekturi. Te omejitve omogoˇcajo AppEngine-u in sistemu za shranjevanje podatkov BigTable1 samodejno ska- liranje in visoko razpoloˇzljivost. Prav zaradi teh omejitev pa AppEngine ni primeren za sploˇsnonamenske aplikacije.
Microsoft Azure je nekje vmes med omenjenima modeloma. Azure apli- kacije uporabljajo .NET knjiˇznice in se izvajajo v okolju Common Language Runtime. Sistem podpira sploˇsnonamenske aplikacije in ne le neko specifiˇcno kategorijo. Uporabniki si lahko izberejo poljuben programski jezik (ki ga pod- pira CLR), ne morejo pa vplivati na operacijski sistem in izvajalno okolje.
Knjiˇznice omogoˇcajo doloˇceno mero skalabilnosti, vendar mora razvijalec to definirati v aplikaciji. To naredi z opisom nekaterih lastnosti aplikacije. Azure je vmesna postaja med popolnoma aplikacijskim ogrodjem (AppEngine) in virtualnimi raˇcunalniki (Amazon EC2), saj vsebuje lastnosti obeh.
Kateri model je najboljˇsi? Vpraˇsanje je analogno vpraˇsanju programskih jezikov. Nizkonivojski jeziki, kot so C in assembler, omogoˇcajo zelo natanˇcen nadzor, vendar za razvijanje spletnih aplikacij niso primerni. Na drugi strani visokonivojski jezik, na primer Ruby on Rails2, zakrije podrobno delovanje in je uporaben le za spletne aplikacije. Za vsak odklon od obiˇcajne uporabe, bi bilo potrebno poseˇci v samo ogrodje, kar pa ni zaˇzeljeno. Noben razvijalec Rubya ne bi ugovarjal hitrosti in zmogljivosti jezika C in obratno, razvijalec Cja ne bi oporekal Rubyu. Prav tako se bodo na podroˇcju raˇcunalniˇstva v oblaku obdrˇzali razliˇcni modeli glede na potrebe in povpraˇsevanje.
Ce nadaljujemo z analogijo s programskimi jeziki, prav tako kot lahko vi-ˇ sokonivojske jezike implementiramo z nizkonivojskimi, bi lahko viˇsjenivojske modele oblaka gostovali na niˇzjenivojskih. Na primer, AppEngine bi lahko gostoval na platformah Azure in EC2, Azure bi lahko gostoval na EC2. Vsekar pa ima vsak model svoje prednosti in slabosti. Konˇcna odloˇcitev, katerega izbrati pa je na strani uporabnika.
1BigTable - distribuirana podatkovna baza podjetja Google
2Ruby on Rails - je odprtokodna spletna platforma, ki omogoˇca hiter in enostaven razvoj spletnih aplikacij [http://rubyonrails.si/]
2.4 Nevarnosti javnega oblaka 11
2.4 Nevarnosti javnega oblaka
Pri uporabi javnega oblaka smo glede zanesljivosti popolnoma odvisni od ponu- dnika storitev. V SLA (ang. Service Licence Agreement) so ponavadi zapisana stroga pravila glede delovanja in dostopnosti storitev, vseeno pa lahko pride do izpadov delovanja. Ostale nevarnosti javnega oblaka so ˇse: podraˇzitve cene storitev, vkleˇsˇcenje podatkov v posamezen oblak (ang. data lock-in), slaba interoperabilnost med oblaki zaradi nestandardiziranih vmesnikov. Najbolj oˇcitni pa so izpadi delovanja, v zadnjih ˇcasih smo bili veˇckrat priˇce spletnim mrkom, ki so bili posledica nedelovanja javnih oblakov. Vedno veˇc podjetij za svoje storitve uporablja infrastrukturo javnega oblaka, zato so v javnosti taki izpadi delovanja zelo odmevni.
2.4.1 Izpadi delovanja
Amazon svoj javni oblak deli na med seboj neodvisne enote regije in zno- traj njih manjˇsa, bolj soodvisna razpoloˇzljiva obmoˇcja. V regiji ZDA vzhod je 21. aprila 2011 zaradi nepravilne izvedbe naˇcrtovane nadgradnje izpadel eden izmed nosilcev podatkov, ki ni mogel izvajati zahtev po pisanju ali bra- nju podatkov [15]. Pred nadgradnjo sistema bi bili morali preusmeriti promet s pomoˇznih usmerjevalnikov na glavno omreˇzje, a so pomotoma storili ravno nasprotno. Pomoˇzno omreˇzje obremenitve ni zdrˇzalo in priˇslo je do izpada delovanja. Napaka se je potem kaskadno razˇsirila znotraj regije ˇse na ostala razpoloˇzljiva obmoˇcja, saj so delujoˇci podatkovni nosilci poizkuˇsali sinhroni- zirati svojo vsebino na nove lokacije (postopek se imenuje preslikavanje in se izvede, ko primarna varnostna kopija postane nedosegljiva), kar je preobreme- nilo celotno omreˇzje. Napaka je povzroˇcila nedostopnost 13 odstotkov zapisov v regiji ZDA vzhod.
Amazon se je opraviˇcil vsem prizadetim stranem in jim ponudili kompen- zacijo v viˇsini zneska, ki ga plaˇcujejo za 10-dnevni najem Amazonovih storitev.
Hkrati so sprejeli ukrepe za izboljˇsanje omreˇzja in prepreˇcitev podobnih teˇzav v prihodnosti. Predvsem bodo strankam olajˇsali delo z veˇc razpoloˇzljivimi obmoˇcji in regijami, tako da bodo imele veˇcjo redundanco. Izpad je povzroˇcil ˇcloveˇski faktor. ˇCeprav je ˇslo za kombinacijo nesreˇcnih nakljuˇcij in slabe kon- figuracije omreˇzja, je celotno kaskado sproˇzila napaˇcna poteza pri nadgradnji sistema.
2.4.2 Zaˇ sˇ cita pred izpadi
Podjetje Rightscale ponuja platforme za upravljanje aplikacij pri razliˇcnih po- nudnikih raˇcunalniˇstva v oblaku. Ob nedavnem izpadu Amazonovega EC2 oblaka so zaznali naslednje ugotovitve in jih zapisali v spletnem dnevniku [10].
Varnostne kopije in repliciranje podatkov je potrebno vzeti resno. V pri- meru EC2 to pomeni repliciranje preko razliˇcnih razpoloˇzljivh obmoˇcij. Prav tako je treba v primeru izpada poveˇcati zmogljivosti replik, da prenesejo obre- menitve ob izpadih glavnih streˇznikov. Primer dobre prakse: aplikacijo na- mestimo na streˇzniˇske instance na treh razpoloˇzljivih obmoˇcjih in nastavimo samodejno skaliranje na 30-60% izkoriˇsˇcenosti virov. S tem doseˇzemo dovolj zmogljivosti za obremenitvene konice. ˇCe odpove eno razpoloˇzljivo obmoˇcje, se zviˇsa izkoriˇsˇcenost virov na 90%. Verjetnost, da odpove veˇc razpoloˇzljivih obmoˇcij hkrati, je majhna, a vseeno ne niˇcna. Izpad delovanja storitev shranje- vanja podatkov (AWS S3) se je zgodil 20. junija 2008, ko storitev ni delovala celo na razliˇcnih regijah (ZDA in Evropa). Veliko lahko doseˇzemo z replicira- njem podatkov v oblaku, vseeno pa je ˇse vedno priporoˇceno imeti varnostne kopije na lastni infrastrukturi.
Poglavje 3
VCL - Virtual Computing Lab
3.1 Ozadje VCL
Projekt VCL je leta 2004 zrasel iz preproste ideje, kako zagotoviti dostop do mnoˇzice raˇcunalniˇskih okolij za ˇstudente in raziskovalce iz katerekoli oddaljene lokacije povezane v omreˇzje. Na drˇzavni univerzi Severne Karoline v ZDA (NCSU) so hoteli izboljˇsati izkoriˇsˇcenost svojih virov IT in se lotili razvoja sistema za upravljanje z raˇcunalniˇskimi viri. Uspeˇsno so razvili sistem, ki je temeljil predvsem na oskrbovanju s fiziˇcnimi raˇcunalniki. Z razvojem virtuali- zacije in raˇcunalniˇstva v oblaku, pa so sistem ˇse razˇsirili z novimi tehnologijami.
Univerza je leta 2008 izvorno kodo okolja VCL predala odprtokodni skupnosti Apache Software Foundation (ASF) in s tem razˇsirila krog uporabnikov VCL ter pospeˇsila razvoj. Sama ˇse vedno sodeluje pri razvoju sistema in ga tudi aktivno uporablja. Naslednja poglavja so povzeta po[4, 5, 6].
3.2 Visokonivojska arhitektura VCL
Visokonivojska arhitektura VCL je v osnovi namenjena naˇcrtovanju in nameˇsˇcanju oblaka, ki bo sluˇzil izobraˇzevalnim in raziskovalnim namenom univerz na ˇcim bolj ekonomiˇcen naˇcin. VCL ponuja veliko funkcionalnosti in storitev, ki so- vpadajo s priˇcakovanji in zahtevami raˇcunalniˇstva v oblaku. Glavne kompo- nente VCL arhitekture so prikazane na sliki [3.1].
• spletni grafiˇcni vmesnik za konˇcnega uporabnika
• podatkovna baza
• upravljalec z viri (upravljalec VCL) 13
• slike: programski sklad, ki zajema operacijski sistem in prednameˇsˇceno programsko opremo, slike so shranjene v skladiˇsˇcu slik
• strojna oprema: fiziˇcni streˇzniki, reˇsitve za shranjenje podatkov, omreˇzna oprema, visoko zmogljivi raˇcunalniki, namizni raˇcunalniki
• varnost
Slika
Strežniki, namizni računalniki, skladišče slik, HPC OS: Linux, Windows, ostali
Aplikacije:
WebSphere...
Virtualizacijska plast:
VMware, KVM, XEN, oblak EC2 OS: Linux, Windows, ostali
Aplikacije: WebSphere, AutoCAD...
Dostop za končnega uporabnika:
SSH, RDP, VNC, X-WIN, odjemalci
xCAT Koda VCL
MySQL Apache
PHP drugo
Okolje VCL
Slika 3.1: Visokonivojska arhitektura VCL
3.3 Uporabnik 15
3.3 Uporabnik
Prvi stik uporabnika z VCL je preko spletnega vmesnika, kjer si izbere ˇzeljeno kombinacijo programske opreme, ki jo ˇzeli uporabljati. Vmesnik je prikazan na sliki [3.2]. V primeru, da uporabniku ne ustreza nobena od ponujenih slik, si jo lahko prilagodi, ˇce ima ustrezne pravice. Izbira lahko iz obstojeˇcih komponent, ki jih ponuja VCL, in sliko povsem prilagodi svojim potrebam ter jo shrani za ponovno uporabo. Rezervira okolje z doloˇcenim operacijskim sistemom, nanj naloˇzi svoje aplikacije in novo sliko shrani. Naslednjiˇc si izbere prilagojeno sliko in mu ni potrebno ponovno nameˇsˇcati programske opreme.
Ko uporabnik izbere in rezervira sliko, upravljalec VCL obdela uporabniˇsko zahtevo in sliko naloˇzi na ustrezne strojne vire ter rezervirano okolje pripravi za takojˇsno uporabo oziroma rezervira za kasnejˇso.
Slika 3.2: Nova rezervacija
Naˇcin dostopa do rezerviranih virov je odvisen od tipa slike, ki smo jo izbrali. Za okolja Windows se uporablja protokol RDP oziroma VNC, za okolja Linux pa protokol SSH oziroma X-WIN, ki omogoˇcata dostop do oddaljenega streˇznika. Uporabnik ob uspeˇsni rezervaciji prejme dostopne podatke in lahko zaˇcne uporabljati rezervirano okolje. Na sliki [3.3] je prikazan seznam trenutnih rezervacij ter povezava do okolja Linux preko protokola SSH in povezava do okolja Windows preko protokola RDP.
Slika 3.3: Trenutne rezervacije in povezava do rezerviranih virov
3.4 Nizkonivojska arhitektura VCL
Tipiˇcno delovanje okolja VCL vkljuˇcuje preverjanje aktivnih okolij, upravlja- nje z virtualnimi in fiziˇcnimi raˇcunalniki ter upravljanje s slikami. Prav tako skrbi za interakcijo s konˇcnimi uporabniki in vodi zgodovino rezervacij. Niz- konivojska arhitektura sestoji iz komponent, ki so predstavljene v naslednjih
3.4 Nizkonivojska arhitektura VCL 17
podpoglavjih.
3.4.1 Okolja za oskrbovanje s fiziˇ cnimi ali virtualnimi viri
VCL lahko poveˇzemo z okoljem za oskrbovanje s fiziˇcnimi ali virtualnimi viri.
Za fiziˇcne vire je v VCL previdena uporaba odprtokodne programske opreme Extreme Cloud Administration Toolkit (xCAT). Okolje xCAT je zbirka skrip- tnih orodij za izdelavo, nastavljanje, upravljanje in vzdrˇzevanje streˇzniˇskih gruˇc [14]. VCL uporablja xCAT za nalaganje slik na fiziˇcne streˇzniˇske rezine.
Za oskrbovanje z virtualnimi viri je predvidena uporaba virtualizacijskih teh- nologij VMware, moˇzno pa je uprabiti tudi druge (npr. Oracle VirtualBox ali KVM). Za druge tehnologije je seveda potreben dodaten razvoj modulov, ˇcesar smo se lotili v diplomskem delu in omogoˇcili oskrbovanje z virtualnimi viri javnega oblaka.
V samem zaˇcetku razvoja VCL (2004) je bil sistem preteˇzno usmerjen pred- vsem na fiziˇcne raˇcunalnike, saj se je virtualizacija raˇcunalniˇskih virov ˇsele zaˇcela razvijati. Danes VCL omogoˇca tako nalaganje slik na fiziˇcne raˇcunalnike, kot tudi na virtualne raˇcunalnike. Pomembno se je zavedati, da imajo v nekaterih primerih fiziˇcni raˇcunalniki ˇse vedno nekaj prednosti pred virtual- nimi, zato VCL tudi omogoˇca oboje. Predvsem na podroˇcju visoko zmogljivih raˇcunalnikov se opazijo razlike, ki so v prid fiziˇcnimi virom.
VCL na podlagi uporabniˇske zahteve sproˇzi postopek zagona doloˇcene slike.
V primeru, da ne najde razpoloˇzljivega fiziˇcnega ali virtualnega streˇznika, ki bi ˇze imel prednaloˇzeno zahtevano sliko, sam izbere najprimernejˇsega pro- stega kandidata, ki ustreza zahtevam obravnavane slike. Dinamiˇcno naloˇzi sliko preko xCAT oziroma sistema za virtualizacijo virov. Na drˇzavni univerzi Severne Karoline v ZDA (NCSU) fiziˇcne slike nalagajo preko xCAT orodja, virtualne pa pa preko virtualizacijskih tehnologij VMware, predvsem sistema ESXi. V Laboratoriju za raˇcunalniˇske komunikacije prav tako uporabljamo VMware ESXi tehnologijo za virtualne raˇcunalnike, oskrbovanja s fiziˇcnimi viri pa nismo implementirali, saj ni bilo potrebe.
V primeru, da so vsi viri zasedeni in ni mogoˇce naloˇziti zahtevane slike, VCL preko spletnega vmesnika uporabniku predlaga alternativne ˇcasovne termine, v katerih so ustrezni viri prosti.
3.4.2 Upravljalec VCL
Jedro upravljalca VCL je demonska storitev VCLd, ki skrbi za oskrbovanje virov in nalaganje slik. Storitev je napisana v programskem jeziku Perl. Pri praktiˇcnem delu tega diplomskega dela smo se osredotoˇcili predvsem na delo- vanje omenjene storitve, zato dobro poznavanje jezika Perl in njegovih knjiˇznic ni bilo odveˇc. Glede na zahtevano okolje, bodisi gre za fiziˇcno sliko bodisi za virtualno, VCLd zagotavlja, da se slika ustrezno naloˇzi in omogoˇci dostop do nje.
Naloge storitve VCLd so:
• Komunikacija s spletnim vmesnikom in podatkovno bazo za pridobitev podatkov o rezervacijah virov, ki jih uporabniki vnesejo preko spletnega vmesnika. Ti so osnova za procesiranje rezervacij in upravljanje s slikami.
• Zaganjanje ukazov xCAT in VMware za izvrˇsevanje uporabniˇskih zah- tev. Gre predvsem za nalaganje slik, zaganjanje virtualnih in fiziˇcnih raˇcunalnikov, ugaˇsanje raˇcunalnikov, ki jih ne potrebujemo itd.
• Nadziranje postopkov zajemanja novih slik, na katere namestimo novo programsko opremo.
• Vzdrˇzevanje sistema za oskrbovanje z viri.
• Nastavljanje in administracija nameˇsˇcenih slik glede na zahtevano upo- rabo.
3.4.3 Odprtokodni spletni streˇ znik Apache
Spletna aplikacija je napisana v programskem jeziku PHP in nameˇsˇcena na spletni streˇznik Apache. Predstavlja srce VCL in zagotavlja orodja za zah- tevanje, upravljanje in obvladovanje vseh virov VCL. Spletni vmesnik skrbi za avtentikacijo uporabnikov, prikaˇze seznam vseh aplikacij, za katere je po- samezen uporabnik avtoriziran in mu omogoˇci rezervacijo raˇcunalniˇskih okolij bodisi za takojˇsnjo bodisi za kasnejˇso rabo. Razpon ˇcasovnega obdobja (kdaj lahko rezerviramo vire ter samo trajanje rezervacije) je popolnoma prilagodljiv in se lahko razlikuje glede na uporabnikove pravice. Glavne funkcionalnosti spletnega vmesnika so:
• Ustvarjanje slik: vmesnik uporabniku omogoˇca ustvarjanje prilagojenih slik. Za osnovo uporabi obstojeˇce osnovne slike.
3.4 Nizkonivojska arhitektura VCL 19
• Nadzor verzij slik: vmesnik uporabniku z ustreznimi pravicami omogoˇca ustvarjanje razliˇcnih verzij posamezne slike.
• Upravljanje z uporabniki: omogoˇca nastavljanje razliˇcnih nivojev pravic posameznim skupinam uporabnikov.
• Upravljanje z viri: omogoˇca naˇcin ˇcasovnega razporejanja vseh virov, ki so na voljo. Virom lahko doloˇcimo urnike s ˇcasovnimi obdobji, v katerih so na voljo za uporabo.
3.4.4 Odprtokodna podatkovna baza MySQL
Podatkovna baza hrani stanja vsakega raˇcunalniˇskega vira, vzdrˇzuje meta- podatke o slikah in virih, implementira sistem uporabniˇskih pravic. Vse re- zervacije se beleˇzijo in imamo natanˇcen pregled na dogajanjem v sistemu VCL. Na podlagi podatkov lahko analiziramo uporabo, kar nam omogoˇcajo orodja znotraj spletnega vmesnika. Podatkovni model je dobro zasnovan in razˇsirljiv, tako da omogoˇca tudi nadaljni razvoj funkcionalnosti, kot je na primer zaraˇcunavanje oziroma vodenje uporabe virov po posameznih uporab- nikih. Podatkovna baza temelji na odprtokodnem sistemu za upravljanje s podatkovnimi bazami MySQL [12], ki zagotavlja ustrezno okolje za transak- cijsko intenzivno delovanje sistema VCL. Za dostop do baze VCL uporablja module, ki omogoˇcajo enostavno zamenjavo sistema za upravljanje s podat- kovnimi bazami in razvijalcu nudijo uˇcinkovit dostop do podatkov. Razvijalcu se ni potrebno ukvarjati s podrobnostmi dostopanja do baze, za to poskrbijo metode modulov.
3.4.5 Slike
VCL sliko definira kot programski sklad, ki vsebuje naslednje plasti:
• Osnovni operacijski sistem
• Nameˇsˇcene aplikacije in predvneˇseni podatki
• Reˇsitev za dostop konˇcnega uporabnika, ki ustreza operacijskemu sistemu (protokol SSH za Linux, protokol RDP za Windows)
Slike lahko nalagamo na fiziˇcne raˇcunalnike ali na katerokoli virtualno okolje.
Na NCSU in FRI se za virtualizacijsko okolje uporablja VMware ESXi, lahko pa bi uporabili tudi drugo, na primer Oracle VirtualBox. Namen diplomskega
dela pa je poganjati slike v javnem oblaku, in sicer v Amazon EC2 virtualiza- cijskem okolju. Uporabnik z ustreznimi pravicami, si programski sklad lahko poljubno prilagodi. Kot osnovo vzame sliko z nameˇsˇcenim osnovnim operacij- skim sistemom (Linux ali Windows), poljubno spremeni sistemske nastavitve in naloˇzi svoje aplikacije. Sliko shrani in omogoˇci dostop skupini uporabnikov, katerim je namenjena.
3.5 Strojna oprema v VCL
Virtualizacija pripelje abstrakcijo stojne opreme do te mere, da lahko program- ski sklad poljubno nalagamo na virtualne raˇcunalnike, ne da bi bili vezani na toˇcno doloˇceno strojno opremo. Streˇzniki VCL zagotavljajo ˇsiroko mnoˇzico virov, ki jih lahko ponudijo na zahtevo uporabnika. Viri se dodelijo glede na aplikacijske zahteve, raˇcunsko intenzivne slike dobijo veˇc procesorske moˇci in veˇcje pomnilniˇske kapacitete, slike, ki jih uporabljamo samo za testiranje ko- munikacij med raˇcunalniki, pa take moˇci ne potrebujejo in prejmejo ustrezno manjˇse zmogljivosti. Omreˇzni viri in sistemi za shranjevanje podatkov morajo biti razˇsirljivi ter ustrezati obremenitvam in uporabniˇskih zahtevam. V pri- meru pomanjkanja kapacitet oziroma zmogljivosti jih enostavno nadgradimo.
Zasebni oblak ponavadi dopolnjuje ˇse sistem za shranjevanje podatkov, ki je na voljo vsem virtualnim raˇcunalnikom. VCL omogoˇca, da lahko vse vire uporabimo tako za izvajanje aplikacij kot tudi za shranjevanje podatkov. Pri shranjevanju podatkov pa moramo paziti, da je okolje nastavljeno na trajni naˇcin. Strojne vire lahko predstavljajo streˇzniˇske rezine, skupine namiznih raˇcunalnikov ali delovnih postaj, visoko zmogljivi raˇcunalniki itd.
Tipiˇcna namestitev VCL sestoji iz ene ali veˇc streˇzniˇskih ˇsasij, ponavadi je ena streˇzniˇska rezina posveˇcena upravljalnemu vozliˇsˇcu. Na NCSU uporabljajo eno upravljano vozliˇsˇce za oskrbovanje s pribliˇzno 100 raˇcunalniki. Vsaka rezina mora imeti najmanj dva mreˇzna vmesnika – enega za povezavo z javnim omreˇzjem in drugega za zasebno omreˇzje, ki omogoˇca upravljanje z lokalnimi raˇcunalniˇskimi viri in nalaganje slik. Sistemi za shranjevanje podatkov so prikljuˇceni s pomoˇcjo optiˇcnih vlaken oziroma mreˇznih povezav. Struktura tipiˇcne namestitve VCL je prikazana na sliki [3.4].
3.6 Varnost v VCL
Teˇzko je podati definicijo, kaj pomeni varnost v oblaku. Glavno merilo pri porazdeljenih sistemih je urejen postopek avtentikacije in avtorizacije posa-
3.6 Varnost v VCL 21
G o st u jo či O S G o st u jo či O S G o st u jo či O S G o st u jo či O S
Fizični strežnik Hipervizor Strežnik in
skladišče slik CentOS
MySQL VCLd
PHP Apache
Fizični strežnik xCAT Programski sklad fizičnih računalnikov
Slika 3.4: Struktura tipiˇcne namestitve VCL
meznih storitev v oblaku. VCL v osnovi implementira naslednja varnostna mehanizma:
Avtentikacija LDAP: avtentikacija VCL temelji na storitvi LDAP. Za razliˇcne uporabniˇske skupine omogoˇca razliˇcne storitve LDAP za loˇcen upo- rabniˇski dostop.
Avtentikacija na nivoju okolja: tak naˇcin avtentikacije je odvisen od okolja do katerega dostopamo. Ponavadi je doloˇcen ob zagonu slike. V oko- lju Windows privzeto uporabimo geslo za enkratno uporabo, ki se ustvari ob zaˇcetku rezervacije in poteˇce, ko konˇcamo z uporabo. V okolju Linux lahko vzpostavimo obstojeˇc sistem avtentikacije ali pa prav tako ustvarimo enkratna gesla za toˇcno doloˇceno rezervacijo. Na NCSU praviloma za okolja Windows uporabljajo enkratna gesla, za okolja Linux pa obstojeˇc centraliziran sistem za avtentikacijo, ki omogoˇca dostop do vseh virov univerze z enotnim upo- rabniˇskim imenom in geslom. Razlog za to pa je predvsem v tem, da okolju Linux bolj zaupajo kot okolju Windows.
Poleg omenjenih mehanizmov avtentikacije lahko sistem dodatno zavaru- jemo z omejitvami na poˇzarnem zidu. VCL omogoˇca prepreˇcevanje dostopa
do rezerviranih virov glede na izvorni naslov IP. Uporabniku lahko omogoˇcimo dostop do rezerviranih virov le prek IP naslova, preko katerega je tudi rezervi- ral vire. Tako lahko vire uporablja le iz lokacije, preko katere je oddal zahtevek za rezervacijo in s tem izboljˇsamo varnost sistema.
3.7 Visoko zmogljivo raˇ cunalniˇ stvo in VCL
Na univerzah se vedno bolj pojavlja potreba po visoko zmogljivem raˇcunalniˇstvu (ang. High-Performance Computing - HPC). Potrebuje se za reˇsevanje raˇcunsko zelo zahtevnih problemov, kjer so v praksi fiziˇcni raˇcunalniki ˇse vedno bolj uˇcinkoviti od virtualnih. VCL je bil sprva naˇcrtovan za oskrbovanje s fiziˇcnimi viri, ta funkcionalnost pride prav ravno v primeru virov HPC, ki so seveda fiziˇcni. Osnovni model delovanja HPC in VCL je razmeroma enostaven. Prika- zan je na sliki [3.5]. Uporabnik preko vstopnega vozilˇsˇca dostopa do virov HPC, s katerimi upravlja VCL. Z orodjem xCAT naloˇzi slike na proste streˇzniˇske re- zine, namenjene HPC, prav tako v omreˇznih nastavitvah omogoˇci povezljivost rezin znotraj virtualnega zasebnega omreˇzja (VLAN). V okolju HPC je za var- nost ˇse bolje poskrbljeno in se za dostop preko javnih omreˇzij uporablja temu namenjena vstopna vozliˇsˇca. VCL vzpostavi okolje HPC vkljuˇcno s kompo- nentami, kot sta na primer izenaˇcevalnik obremenitve in razvrˇsˇcevalnik HPC.
Vsaka HPC slika ima dostop do velike koliˇcine prostora v sistemih za shranje- vanje (v TB), kot tudi do lastnih prostorskih kapacitet in sistemov za varno- stne kopije. Ko se slika HPC naloˇzi, razvrˇsˇcevalnik VCL to zazna in ji zaˇcne predajati delo. Integracija HPC in VCL moˇcno poveˇca izkoriˇsˇcenost virov z izboljˇsanjem dodeljevanja rezin HPC. Tak naˇcin omogoˇca skupno rabo infra- strukture med veˇc uporabniki, kar vodi v boljˇso razpoloˇzljivost in izkoriˇsˇcenost virov. HPC in VCL sta podrobneje obravnavana v [7].
3.8 Prednosti uporabe VCL v laboratorijih
Naˇsteli smo nekatere glavne zmogljivosti okolja VCL. Na univerzah so tipiˇcni uporabniki ˇstudentje, raziskovalci in pedagogi. Oblak za tako vrsto uporabni- kov mora zagotavljati vsaj naslednje zmogljivosti:
• storitve in podporo za ˇsirok razpon uporabnikov
• veliko podpornih orodij za pedagoge in univerzitetno osebje
• primerne raˇcunalniˇske sisteme in storitve, ki sluˇzijo raziskovalni dejav- nosti
3.8 Prednosti uporabe VCL v laboratorijih 23
Vstopno vozlišče
Vir HPC
Vir HPC
Internet
Sistem za shranjevanje podatkov HPC
Delo HPC Razvrščevalnik
HPC
Slika 3.5: Osnovni model delovanja HPC in VCL
Poleg upoˇstevanja omenjenih zahtev so glavni izzivi pri planiranju oblaka za izobraˇzevalne in raziskovalne namene naslednji:
• ˇcimboljˇsa izkoriˇsˇcenost virov glede na uporabniˇske zahteve
• raznovrstna storitvena okolja
• vzdrˇzevanje in upravljanje infrastrukture mora bo ekonomiˇcno in stroˇskovno uˇcinkovito
Na univerzah se potrebe po virih spreminjajo glede na ˇstudijski koledar. Ob koncih semestrov se zahteve po virih moˇcno poveˇcajo, prav tako narastejo ob rokih za oddajo razliˇcnih nalog, ki jih morajo opraviti ˇstudentje. Razi- skovalno usmerjena dela potekajo skozi celo leto. Da zagotovimo stroˇskovno uˇcinkovitost univerzitetnega oblaka, moramo vzpostaviti dober mehanizem razporejanja virov, ki spremlja zahteve in se jim prilagaja. VCL omogoˇca dobro razporejanje in prepoznavanje konic v uporabi med razliˇcnimi tipi upo- rabnikov.
Z opazovanjem okolja VCL na NCSU smo ugotovili pomembno prednost sistema, ki poleg obiˇcajnih streˇznikov in namiznih raˇcunalnikov omogoˇca ˇse izkoriˇsˇcanje infrastrukture HPC. Tako VCL omogoˇca uˇcinkovito izkoriˇsˇcanje vseh razpoloˇzljivih virov na NCSU. Z deljeno uporabo vseh streˇzniˇskih rezin,
namiznih raˇcunalnikov in delovnih postaj ter virtualnih okolij ponuja eko- nomiˇcno rabo virov in njihovo optimalno zasedenost.
S tem lahko zakljuˇcimo, da je VCL odprtokodni spletni sistem za dinamiˇcno oskrbovanje z viri in dodeljevanje oddaljenega dostopa do raˇcunalniˇskih okolij na zahtevo uporabnika. Oblak VCL omogoˇca izjemno raˇcunsko moˇc s pomoˇcjo odprte programske opreme in primerne strojne opreme, ki sluˇzi vsem univer- zitetnim projektom in izobraˇzevalnim programom.
Poglavje 4
Javni oblak Amazon EC2
4.1 Kaj je EC2
Amazon Elastic Compute Cloud (Amazon EC2) je spletna storitev, ki nudi razˇsirljivo raˇcunalniˇsko infrastrukturo. EC2 je predstavnik storitvenega mo- dela IaaS. Javni oblak zagotavlja streˇzniˇske instance, na katerih lahko gradimo in gostujemo svoje aplikacije. Infrastrukturne vire EC2 upravljamo s pomoˇcjo programskega vmesnika API, spletnega grafiˇcnega vmesnika oziroma raznih orodij.
Pri EC2 uporabljamo in plaˇcujemo le za zmogljivosti, ki jih dejansko upo- rabimo. To izniˇci potrebo po nakupih drage in prostorsko potratne strojne opreme, zmanjˇsa potrebo po napovedovanju prometa in omogoˇca avtomat- sko skaliranje virov IT in s tem prilagajanje konicam v prometu. Podrobno delovanje in naˇcini uporabe javnega oblaka EC2 so opisani v Amazonovi do- kumentaciji [9], glavni deli so povzeti v tem poglavju.
4.2 Osnovne komponente
4.2.1 Amazon Machine Images in instance
Amazon Machine Image (AMI) je slika, ki vsebuje operacijski sistem in pred- nameˇsˇcene aplikacije. Iz slike lahko zaˇzenemo instance, ki so aktivna virtualna okolja. Iz slike lahko zaˇzenemo veˇc instanc, kot je razvidno v sliki [4.1]. In- stance so aktivne, dokler jih ne ustavimo oziroma odpovedo zaradi napake. ˇCe posamezna instanca odpove, lahko iz predloge zaˇzenemo novo. V oblaku lahko shranimo poljubno ˇstevilo razliˇcnih slik. Slika ni omejena s tipom instance.
Tip instance predstavlja kombinacijo virtualne strojne opreme, ki je doloˇcena 25
Slika (AMI)
Računsko zmogljiva
instanca Standardna
instanca
Visoko zmogljiva
instanca
Slika 4.1: Slika na razliˇcnih tipih instanc
s koliˇcino pomnilnika, raˇcunsko moˇcjo in diskovnim prostorom. Podrobna ta- bela s tipi instanc in njihovimi zmogljivostmi je na voljo v dokumentaciji EC2 [9]. Isto sliko AMI lahko naloˇzimo na katerikoli tip instance, odvisno od zahtev programske opreme, ki jo ˇzelimo izvajati na njej.
Amazon ponuja mnogo prednastavljenih slik AMI z najbolj pogostimi pro- gramskim nastavitvami. Predloge so proste dostopne in na voljo takoj. Do- datne slike ponuja tudi odprtokodna skupnost, ki redno objavlja najnovejˇse verzije operacijskih sistemov in programske opreme. Uporabljamo lahko pro- sto dostopne predloge in ustvarimo skripte, ki ob zagonu instance nastavijo sistem po naˇsih ˇzeljah. Lahko pa ustvarimo povsem svoje prilagojene slike AMI, ki zajemajo vse plasti programske sklada od operacijskega sistema nav- zgor. Svoje slike lahko prav tako delimo z ostalimi uporabniki oblaka EC2.
4.2.2 Regije in razpoloˇ zljiva obmoˇ cja
Amazon ima svoje podatkovne centre v razliˇcnih regijah sveta (Severna Ame- rika, Evropa, Azija itd.). Uporabnik lahko sam izbere, v kateri regiji bo upo- rabljal instance in se tako ˇcim bolj pribliˇzal konˇcni stranki, ki bo uporabljala njegove storitve oziroma zadostil zakonskim predpisom, ki veljajo v nekaterih drˇzavah. Cena najema instanc se razlikuje glede na regije.
Vsaka regija vsebuje veˇc razliˇcnih razpoloˇzljivih obmoˇcij. Vsako obmoˇcje je zasnovano tako, da je izolirano pred odpovedmi drugih obmoˇcij znotraj regije, vseeno pa zagotavlja poceni in hitro medsebojno omreˇzno povezavo z minimalnimi zakasnitvami. Z uporabo razliˇcnih razpoloˇzljivih obmoˇcij znotraj
4.3 Shranjevanje podatkov 27
regij, lahko zaˇsˇcitimo svojo aplikacijo pred odpovedmi doloˇcenih lokacij in tako zagotovimo neprestano razpoloˇzljivost svojih storitev. Za laˇzje razumevanje so regije in razpoloˇzljiva obmoˇcja prikazana na sliki [4.2].
Razpoložljivo
območje Razpoložljivo
območje Razpoložljivo
območje Razpoložljivo
območje Razpoložljivo
območje Razpoložljivo
območje Razpoložljivo
območje Regija:
us-east-1
Regija:
eu-west-1
Druga regija
Amazon EC2
Slika 4.2: Regije in razpoloˇzljiva obmoˇcja Amazon EC2
4.3 Shranjevanje podatkov
Virtualni disk, ki pripada aktivni instanci, v osnovi ne zagotavlja trajnega shranjevanja podatkov in moramo za to poskrbeti sami. Podatki obstajajo, dokler ne ugasnemo instance. Zato moramo v teh primerih najprej shraniti podatke s pomoˇcjo naslednjih storitev AWS:
Amazon S3 Amazon S3 (Simple Storage Solution) je storitev shranjeva- nja podatkov za celotno medmreˇzje. Preko enostavnega spletnega vmesnika
Instanca B Instanca A
Enota EBS Nova enota
EBS
Posnetek EBS v Amazon S3 Ustvari
posnetek
Ustvari enoto
Slika 4.3: Posnetek EBS
lahko shranjujemo in pregledujemo kakrˇsnekoli koliˇcine podatkov iz katerekoli lokacije v medmreˇzju.
Amazon EBS Amazon EBS je novejˇsa storitev in zagotavlja trajno bloˇcno shranjevanje podatkov. Enote EBS so virtualni diski, ki jih lahko priklopimo na aktivne instance. Enote so posebej primerne za aplikacije, ki za svoje delovanje potrebujejo podatkovno bazo, datoteˇcni sistem ali dostop do surovih podatkov na nivoju bloka. Na eno instanco lahko priklopimo veˇc enot EBS.
Zelo uporabna funkcionalnost storitve EBS so posnetki (ang. snapshot).
Posnetki so trenutna stanja virtualnih diskovnih enot. Ko prviˇc zajamemo posnetek, se v sistem za trajno shranjevanje podatkov (npr. Amazon S3) prenese celotna vsebina virtualnega diska. Ob naslednjem zajemu pa se pre- nesejo le razlike, glede na prejˇsnje stanje. Tako je vsak posnetek sestavljen iz osnovne kopije virtualnega diska (alfe) in enega ali veˇc odsekov podatkov (delt), ki se razlikujejo od vsebine osnovne kopije. Tak naˇcin varnostnega kopi- ranja je bolj uˇcinkovit in izboljˇsa performanse, saj prenaˇsamo manjˇse koliˇcine podatkov. Prav tako varˇcuje s prostorom in poslediˇcno zmanjˇsa stroˇsek na- jema pomnilniˇskih kapacitet. Za varnostne kopije virtualnega diska lahko torej uporabimo posnetke, ki se shranjujejo v sistem S3. Iz posnetkov lahko hitro in enostavno ustvarimo novo enoto EBS in jo priklopimo na novo instanco.
Prav tako lahko instanci odklopimo enoto EBS in jo priklopimo novi instanci.
Delovanje je prikazano na sliki [4.3].
4.4 Varnost v EC2 29
4.4 Varnost v EC2
Za varnost je pri EC2 poskrbljeno na veˇc nivojih:
• Na nivoju operacijskega sistema gostitelja (ang. host OS)
• Na virtualni instanci ali gostujoˇcem operacijskem sistemu (ang. guest OS)
• Na poˇzarnem zidu
• Varnih podpisanih klicih API
Vsak od teh elementov gradi na zmogljivostih drugih. Kljuˇcni cilj je prepreˇciti, da bi podatke znotraj oblaka EC2 prestregel neavtoriziran uporabnik ali sistem in omogoˇciti instancam EC2 ˇcim veˇcjo varnost, brez da bi ˇzrtvovali prilago- dljivost in uporabniˇsko svobodo pri nastavljanju sistema. Varnostni vidiki so povzeti po ˇclanku [2].
4.4.1 OS gostitelja (ang. host OS)
Administratorji znotraj Amazona za dostop do gostitelja virtualnih instanc uporabljajo veˇcnivojsko avtentikacijo preko posebej za to vzpostavljenih orodij za vzdrˇzevanje. Ta orodja so zasnovana z namenom, da zavarujejo glavno upravljalno jedro oblaka. Vsak tak administratorski dostop je zabeleˇzen in pregledan. Ko Amazonov administrator ne potrebuje veˇc dostopa do jedra gostiteljevega operacijskega sistema za toˇcno doloˇceno nalogo, se mu pravice za dostop do obravnavanih sistemov odvzamejo.
4.4.2 Gostujoˇ ci OS (ang. guest OS)
Virtualne instance so popolnoma pod nadzorom konˇcnega uporabnika. Upo- rabniki imajo polni administratorski (ang. root) dostop do gostujoˇcega opera- cijskega sistema in s tem nadzor nad uporabniˇskimi raˇcuni, storitvami in apli- kacijami. Amazonovi administratorji nimajo dostopa do uporabniˇskih instanc in se zato ne morejo prijaviti v gostujoˇci operacijski sistem. Amazon predlaga uporabo dobrih varnostnih praks, kot so izkljuˇcitev moˇznosti dostopa samo na podlagi uporabniˇskega imena in gesla. Za dostop do instanc priporoˇcajo neko obliko veˇc nivojske avtentikacije, ali vsaj uporabo certifikatov in protokol SSH verzije 2 (SSHv2). Prav tako je priporoˇceno, da si uporabniki nastavijo sistem z razliˇcnimi nivoji pravic za razliˇcne skupine uporabnikov instanc. V primeru,
da je gostujoˇci operacijski sistem Linux, je priporoˇcljivo prepreˇciti oddaljen administratorski dostop in do instance dostopati le s kombinacijo certifikata in neadministratorskega (ang. non-root) raˇcuna. ˇCe nato potrebujemo admini- stratorski dostop do gostujoˇcega OS, lahko pravice pridobimo z ukazom sudo.
Uporabniki morajo ustvariti svoje pare kljuˇcev za dostop do instance in s tem zagotoviti, da je par edinstven in ni deljen z drugimi strankami oblaka EC2.
4.4.3 Poˇ zarni zid
Amazon EC2 omogoˇca uporabo celovitega poˇzarnega zidu. Obvezen poˇzarni zid je privzeto nastavljen na naˇcin “prepreˇci vse” (ang. deny-all) , ki prepreˇcuje ves vhodni promet do instance. Uporabniki morajo eksplicitno odpreti vrata, ki jih uporabljajo za dostop do instance. Promet lahko omejimo glede na protokol in vrata, prav tako tudi glede na izvorni naslov IP, od koder prihaja promet. Doloˇcimo lahko posamezen IP ali razred naslovov IP iz katerih lahko dostopamo do instance.
Pravila poˇzarnega zidu lahko shranimo v skupine, ki jih nato dodeljujemo razliˇcnim instancam. Za primer predstavimo klasiˇcno tri-nivojsko spletno apli- kacijo v porazdeljenem sistemu streˇznikov v javnem oblaku. Skupina spletnih streˇznikov bi imela odprta vrata 80 (HTTP) in vrata 443 (HTTPS), ˇce potre- bujemo varno povezavo. Skupina aplikacijskih streˇznikov bi imela odprta vrata 8000 (doloˇceno v aplikaciji) in omejen dostop na podlagi izvornih naslovov IP.
Skupini podatkovnih streˇznikov pa bi odprli vrata 3306 (MySQL) in dostop dovolili le skupini aplikacijskih streˇznikov. Vse tri skupine bi imele odprta vrata 22 (SSH), a le iz uporabnikovih naslovov IP. S takim mehanizmom za- gotovimo visoko stopnjo varnosti spletne aplikacije. Delovanje poˇzarnega zidu je prikazano na sliki [4.4].
Poˇzarni zid deluje loˇceno od gostujoˇcega OS, za nastavljanje potrebujemo uporabniˇski certifikat X.509 in geslo za dostop do storitev AWS (Amazon Web Services), kar ˇse zviˇsa stopnjo varnosti.
Poˇzarni zid AWS omogoˇca podrobne nastavitve in s tem uporabniku po- nudi enostaven naˇcin za zagotovitev varnosti svojih instanc. Privzeta nasta- vitev poˇzarnega zidu prepreˇcuje ves vhodni promet, uporabnik pa mora sam premisliti, katera vrata in za kakˇsne namene bo odprl pot do svojih instanc.
Vseeno pa se priporoˇca ˇse dodane nastavitve varnosti na nivoju posameznih instanc. Primerne so uporabe poˇzarnih zidov na gostujoˇcih operacijskih sis- temih kot npr. IPtables ali Windows Firewall ali VPN. S tem lahko omejimo vhodni in izhodni promet na vsaki instanci.
4.4 Varnost v EC2 31
Slika 4.4: Poˇzarni zid EC2
4.4.4 Klici vmesnika API
Klici vmesnika API EC2 za zaganjanje in ugaˇsanje instance, za spreminjanje nastavitev poˇzarnega zidu in klici podobnih funkcij morajo biti podpisani z uporabnikovim zasebnim kljuˇcem, ki ga prejmemo ob odprtju uporabniˇskega raˇcuna za dostop do Amazonovih storitev. Brez tega zasebnega kljuˇca ni mogoˇce izvajati klicev programskega vmesnika v imenu lastnika kljuˇca. Do- datno so klici API zavarovani s kriptirano povezavo SSL, ki zagotavlja zaseb- nost. Priporoˇceno je, da za klice API vedno uporabljamo s protokolom SSL zaˇsˇcitene konˇcne toˇcke. Storitev AWS IAM1 dodatno omogoˇca nastavljanje uporabniˇskih pravic za klice API. Uporabniku lahko torej onemogoˇcimo klice za nastavljanje poˇzarnega zidu ali za zaganjanje in ugaˇsanje instanc, dovolimo pa vse ostalo.
1AWS IAM (AWS Identity and Access Management) - dodatna storitev, ki omogoˇca ustvarjanje uporabniˇskih raˇcunov znotraj osnovnega raˇcuna AWS
4.5 Virtualizacijsko okolje - hipervizor Xen
Amazon EC2 trenutno temelji na moˇcno prilagojeni verziji hipervizorja Xen [16], ki izkoriˇsˇca prednosti paravirtualizacije (v primeru gostovanja Linux).
Paravirtualizacija virtualnim raˇcunalnikom preko vmesnika omogoˇca dostop do sistemskih virov gostitelja. Hipervizor skrbi za optimalno razporejanje vi- rov med virtualnimi raˇcunalniki in tako zagotovi boljˇso izkoriˇsˇcenost strojne opreme. Gostujoˇci virtualni raˇcunalniki nimajo polnega dostopa do CPE in se v primerih, ko to potrebujejo, zanaˇsajo na hipervizorja. CPE zagotavlja 4 razliˇcne naˇcine pravic (ang. privilege modes): Ring 0-3. Naˇcin Ring 0 je najviˇsja stopnja priviligiranosti, Ring 3 pa najmanjˇsa. Gostiteljev OS se iz- vaja v najbolj priviligiranem naˇcinu Ring 0. Gostujoˇci OS se izvaja v manj priviligiranem naˇcinu Ring 1, konˇcne aplikacije pa v najmanj priviligiranem Ring 3 naˇcinu. Taka ekplicitna virtualizacija fiziˇcnih virov zagotavlja izolacijo gosta in gostitelja – hipervizorja, kar ˇse dodatno pripomore k varnosti med obema.
Loˇ citev instanc
Razliˇcne instance, ki se izvajajo na istem fiziˇcnem streˇzniku, so med seboj izolirane s pomoˇcjo hipervizorja Xen. Amazon je prisoten v odprtokodni sku- pnosti, kar omogoˇca nenehno spremljanje in sodelovanje pri razvoju. Poˇzarni zid AWS deluje tudi znotraj plasti hipervizorja, med fiziˇcnim omreˇznim vme- snikom in virtualnim vmesnikom, ki ga uporablja instanca. Vsak paket mora preˇckati plast poˇzarnega zidu. S tem zagotovimo, da imajo sosednje instance, ki gostujejo na istem fiziˇcnem streˇzniku, popolnoma enak dostop med seboj, kot ga ima katerakoli druga omreˇzna naprava v medmreˇzju. Virtualni omreˇzni vmesnik lahko obravnavamo kot fiziˇcnega prikljuˇcenega v medmreˇzje. Na po- doben naˇcin je izoliran tudi fiziˇcni pomnilnik.
Uporabnikove instance nimajo neposrednega dostopa do fiziˇcnih diskovnih naprav, dodeljeni so jim virtualni diski. Plast diskovne virtualizacije za vsak blok uporabniˇskih podatkov samodejno poskrbi, da ni nikoli viden ostalim uporabnikom EC2. Seveda obstaja moˇznost, da podatke delimo z ostalimi, ˇce to ˇzelimo. Amazon za varnostno kritiˇcne podatke priporoˇca ˇse dodatne varnostne ukrepe. Primerna reˇsitev za dodatno zaˇsˇcito podatkov je uporaba kriptiranega datoteˇcnega sistema na virtualni diskovni enoti.
4.5 Virtualizacijsko okolje - hipervizor Xen 33
Slika 4.5: Loˇcitev instanc
Integracija hibridnega oblaka
V tem poglavju bomo predstavili tehniˇcno osnovo, ki je potrebna za razume- vanje delovanja modula za oskrbovanje z viri iz javnega oblaka. Na primeru Laboratorija za raˇcunalniˇske komunikacije bomo opisali arhitekturo hibridnega oblaka, ki vsebuje zasebni in javni oblak. Trenutno stanje sestoji le iz zaseb- nega oblaka, predlagali bomo reˇsitev hibridnega oblaka s povezavo v javni oblak Amazon EC2. Za povezavo med zasebnim in javnim oblakom bomo uporabili vmesnik API javnega oblaka Amazon EC2. Na kratko bomo pred- stavili naˇcin uporabe vmesnika in predstavili knjiˇznico, ki smo jo uporabili za namen povezovanja z EC2.
Za razvoj novega modula za oskrbovanje z viri javnega oblaka smo naj- prej namestili testno okolje VCL, pojasnili bomo podrobnosti namestitve in arhitekturo razvojnega okolja, ki sestoji iz treh enot: spletnega vmesnika, po- datkovne baze in upravljalca VCL. Seznanili se bomo z modularno arhitekturo in objektnim pristopom upravljalnega dela VCL, kar je osnova za razumevanje naˇcina gradnje novih modulov VCL. Z razrednim diagramom bomo predsta- vili strukturo modulov in v diagram umestili naˇse nove module, ki so potrebni za integracijo hibridnega oblaka. Ogledali si bomo podrobno zgradbo modula in opisali njegove metode ter potek delovanja procesa nalaganja in zajemanja slike. Prikazali bomo primer uporabe z vidika konˇcnega uporabnika. Na koncu poglavja kritiˇcno ocenimo naˇso reˇsitev in predstavimo prednosti in slabosti hi- bridnega oblaka.
34
5.1 Arhitektura hibridnega oblaka 35
5.1 Arhitektura hibridnega oblaka
Za integracijo hibridnega oblaka smo morali najprej oceniti trenutno stanje zasebnega oblak, ki poganja okolje VCL. V Laboratoriju za raˇcunalniˇske ko- munikacije imamo 11 streˇznikov z VMware ESXi 4 virtualizacijsko tehnologijo, ki omogoˇca zaganjanje virtualnih raˇcunalnikov. Na dodaten 12. streˇznik je nameˇsˇceno okolje VCL s spletnim vmesnikom, podatkovno bazo in upravljal- cem VCL. Vsak streˇznik ima 4-jedrni procesor in 8 GB delovnega pomnilnika.
Trenutno je okolje nastavljeno tako, da na enem streˇzniku poganjamo pri- bliˇzno 30 virtualnih raˇcunalnikov s 256 MB delovnega pomnilnika. Ker imajo streˇzniki omejeno koliˇcino delovnega pomnilnika, bi se ob poveˇcanju zmoglji- vosti virtualnih raˇcunalnikov ˇstevilo moˇznih instanc zmanjˇsalo (npr. 15 virtu- alnih raˇcunalnikov s 512 MB delovnega pomnilnika). To omejitev bomo na- videzno odpravili s povezavo z javnim oblakom, kjer so kapacitete neomejene.
Slike virtualnih raˇcunalnikov so shranjene v skladiˇsˇcu slik, ki se na nahaja na omreˇzno priklopljenem pomnilniku (ang. Network Attached Storage - NAS).
Pri vajah uporabljamo mnoˇzico slik, ki zajemajo operacijske sisteme Windows Server 2003, FreeBSD in Debian. ˇStudenti prejmejo polni administratorski do- stop do virtualnih okolij, po koncu rezervacije pa se okolja zbriˇsejo in morajo ˇstudentje sami poskrbeti za shranjevanje lastnih podatkov.
Predlagana reˇsitev arhitekture hibridnega oblaka je prikazana na sliki [5.1].
Za povezovanje z javnim oblakom na obstojeˇce vozliˇsˇce z upravljalcem VCL namestimo nov modul za oskrbovanje z viri javnega oblaka in s tem omogoˇcimo moˇznost zaganjanja virov v javnem oblaku. Kot ponudnika javnega oblaka smo izbrali Amazon EC2, ki je trenutno med vodilnimi na podroˇcju raˇcunalniˇstva v oblaku in ponuja storitveni model IaaS, ki ustreza potrebam Laboratorija za raˇcunalniˇske komunikacije, saj ˇzelimo, da se ˇstudentje spoznajo z niˇzje- nivojskim delovanjem raˇcunalnikov, kar model SaaS ne omogoˇca. Zasebni in javni oblak sta povezana preko vmesnika API EC2, ki omogoˇca nadziranje virtualnih raˇcunalnikov (zaganjanje, ugaˇsanje, preverjanje) in ustvarjanje slik.
Obstojeˇce slike lahko razmeroma enostavno preselimo v javni oblak, ki ima za to predvideno svoje skladiˇsˇce slik. Slednje je smiselno, saj je prenaˇsanje slik iz zasebnega v javni oblak dolgotrajno, ker gre za veˇcje koliˇcine podatkov, ki se prenaˇsajo preko medmreˇzja. Ko pa se slike nahajajo v javnem oblaku, je manipulacija z njimi hitra in enostavna. Z javnim oblakom odpravimo omejitve zasebnega, saj lahko uporabljamo navidezno neomejeno koliˇcino virov in plaˇcujemo najemnino za dejansko porabo.
Vmware ESXi VCL@fri.uni-lj.si
Skladišče slik VCL
EC2@aws.amazon.com
Skladišče slik
Zasebni oblak Javni oblak
API EC2
Hibridni oblak
Slika 5.1: Arhitektura hibridnega oblaka v Laboratoriju za raˇcunalniˇske ko- munikacije
5.2 Povezava z javnim oblakom
5.2.1 Vmesnik API Amazon EC2
Vmesnik API Amazon EC2 je spletna storitev, ki omogoˇca zaganjanje in upra- vljanje virtualnih raˇcunalnikov z operacijskimi sistemi Linux oziroma Windows v Amazonovih podatkovnih centrih. V skladu s storitveno usmerjeno arhitek- turo uporabnikom zagotavlja popoln nadzor nad raˇcunalniˇskimi viri v javnem oblaku. Virtualne raˇcunalnike lahko preko spletnih storitev zaganjamo, usta- vljamo, ustvarjamo slike, shranjujemo trenutna stanja itd. Amazon pa nam izda raˇcun na podlagi dejanske uporabe njihovih virov.
Amazon EC2 zagotavlja dva vmesnika API na podlagi dveh protokolov:
SOAP in REST. Vmesnika se razlikujeta le po klicih, saj oba vraˇcata enake dokumente XML. Amazon vmesnika stalno nadgrajuje in dodaja nove funkci- onalnosti. Opis vseh funkcionalnosti lahko najdemo v dokumentu WSDL, ki je na voljo na spletu (EC2 WSDL). Podroben opis vseh funkcionalnosti vmesnika API najdemo v dokumentaciji [11], spodaj pa povzamemo le kljuˇcne.
PRIMER UPORABE vmesnika API na podlagi protokola REST Poizvedbeni zahtevki so zahteve HTTP oziroma HTTPS, ki jih poˇsljemo z GET ali POST naˇcinom s parametrom “action”, ki definira metodo. Ne glede na to, kateri protokol uporabimo, mora biti vsak klic API podpisan z uporab-
5.2 Povezava z javnim oblakom 37
nikovim zasebnim kljuˇcem. Podpis se izraˇcuna na podlagi vsebine zahtevka in zasebnega kljuˇca. V klic API ga dodamo z atributom ’Signature’. Varnost vmesnika API smo obravnavali tudi v poglavju 4.4.4.
Struktura zahtevka GET
Konˇcna toˇcka – dostopna toˇcka spletne storitve (npr. ec2.amazonaws.com, ki je privzeto nastavljeno na regijo us-east-1 )
Akcija – metoda, ki jo ˇzelimo izvesti (npr. zaˇzeni virtualni raˇcunalnik (Ru- nInstance) ali opiˇsi sliko (DescribeImage))
Atributi – atributi, ki jih podamo z metodo (npr. identifikator virtualnega raˇcunalnika (InstanceID) ali ˇstevilo virtualnih raˇcunalnikov, ki jih ˇzelimo zagnati (MaxCount))
Primer zahtevka GET za opis aktivnih instanc je prikazan v izvorni kodi [5.1].
Primer odziva XML na omenjeni zahtevek pa v [5.2].
Izvorna koda 5.1Primer zahtevka GET za opis aktivnih instanc h t t p s : // e c 2 . amazonaws . com/
? AWSAccessKeyId=AKIAICSEUY3YGJHGNK4Q
&S i g n a t u r e=boKPO0gHNFL0p3uSy%2B3IhMjXV6jP3SVnuj9%2FK9HR
&V e r s i o n =2010−06−15
&Timestamp=2011−08−22T17%3A22%3A38 . 0 0 0 Z
&A c t i o n=D e s c r i b e K e y P a i r s
&S i g n a t u r e M e t h o d=HmacSHA256
&S i g n a t u r e V e r s i o n =2
5.2.2 Perlova knjiˇ znica VM::EC2
Komunikacijo z oblakom EC2 si lahko olajˇsamo s knjiˇznicami, ki implemen- tirajo vmesnik Amazon EC2 API. Namesto, da sami piˇsemo zahtevke REST ali SOAP, uporabimo knjiˇznice, ki omogoˇcajo enostavnejˇsi dostop do vme- snika in pospeˇsijo razvoj. Amazon zagotavlja knjiˇznice za vse najbolj pogoste programske jezike, prav tako pa knjiˇznice najdemo v odprtokodni skupnosti.
Pri izdelavi modula za oskrbovanje z viri EC2 smo se omejli na knjiˇznice v programskem jeziku Perl, saj je celoten upravljalni del okolja VCL spisan v
