Magistrsko delo. Organizacija in management informacijskih sistemov MODEL OBLAČNIH STORITEV Z OPENSTACK

Transcription

1 Organizacija in management informacijskih sistemov MODEL OBLAČNIH STORITEV Z OPENSTACK Mentor: red. prof. dr. Robert Leskovar Kandidatka: Blažka Globačnik Kranj, september 2014

2 ZAHVALA Zahvaljujem se mentorju red. prof. dr. Robertu Leskovarju za vso pomoč, napotke in predloge pri izdelavi diplomske naloge. Hvala tudi vsem zaposlenim podjetij M, d.o.o in Čisto življenje, d.o.o za pomoč pri preizkusu in analiziranju tehnologije OpenStack. Zahvaljujem se tudi svoji družini, ki mi je čez vsa leta študija stala ob strani in me podpirala pri mojih odločitvah in dejanjih.

3 POVZETEK Raziskava obravnava oblačne storitve, ki jih omogoča odprtokodni nabor programskih orodij OpenStack. Ta orodja so namenjena gradnji in upravljanju javnih in zasebnih oblačnih platform. Kratko so predstavljeni modeli oblačnih storitev HuaaS (humans as a service), SaaS (software as a service), PaaS (platform as a service) in IaaS (infrastructure as a service). Povzete so značilnosti operacijskega sistema Linux, računalniških omrežij in glavnih komponent OpenStack. Preliminarni preizkus delovanja OpenStack je bil izveden z DevStack. Glavni preizkus je obsegal namestitev arhitekture z dvema vozliščema. Virtualne strežnike, na katerih so bili nameščeni celoviti informacijski sistemi Dollibar in OpenBravo ter sistem za upravljanje odnosov s kupci EspoCRM smo preizkusili v dveh konkretnih in enem namišljenem malem podjetju. Za prvo namestitev brez predhodnih izkušenj in brez DevStack smo porabili približno 75 ur, za naslednje pa približno 36 ur. Komponente OpenStack so delovale zanesljivo, na manjšo razpoložljivost pa je najbolj vplivala komponenta pregledna plošča (Dashboard). OpenStack je primeren za izvajanje SaaS ali PaaS v majhnih in srednjih podjetjih. KLJUČNE BESEDE računalništvo v oblaku, odprta koda, OpenStack, ERP, CRM.

4 ABSTRACT The research addresses cloud services supported in open source OpenStack set of software tools. These tools are intended for the construction and management of public and private cloud platforms. Briefly are presented cloud service models HuaaS (humans as a Service), SaaS (software as a service), PaaS (platform as a service) and IaaS (infrastructure as a service). Characteristics of the Linux operating system, computer networks and main components of OpenStack are summarized. We preliminarly test OpenStack with DevStack. The main test included deployment on two node architecture. Later were deployed virtual servers with enterprise resource planning systems (ERP) Dollibar and OpenBravo and customer relationship management system (CRM) EspoCRM. We conducted tests in two real and one imaginary small company. For the first installation with no previous experience and no DevStack approximately 75 hours was spent and for the next installation approximately 36 hours. OpenStack components operated reliably. Decrease of availability was caused primary by Dashboard component. OpenStack is suitable for the implementation of SaaS or PaaS in small and medium-sized enterprises. KEYWORDS cloud computing, open source, OpenStack, ERP, CRM.

5 KAZALO 1 UVOD METODOLOGIJA Definicija problema Definicija ciljev in raziskovalnih vprašanj Metode, tehnike in uporabljena orodja Omejitve raziskave STORITVE V OBLAKU Računalništvo v oblaku Vrste modelov računalništva v oblaku in modeli storitev Virtualizacija, storitveno-orientirana arhitektura in spletne storitve Prednosti in slabosti računalništva v oblaku Obnovitev po izpadu Upravljanje identitet ODPRTOKODNI OPERACIJSKI SISTEM LINUX Zgodovina odprtokodnih sistemov Sestava GNU/Linux RAČUNALNIŠKA OMREŽJA IP naslov IP Prefix Subnet Gateway OPENSTACK Predstavitev tehnologije OpenStack Komponente tehnologije OpenStack Konceptualna arhitektura Koncept skladišč Koncept procesiranja (Compute) Koncept omrežja (Network) Koncept pregledne plošče (Dashboard) Klasična namestitev in konfiguracija Arhitektura Priprava okolja Najpogostejše težave in napake... 34

6 6.3 Razpoložljivost sistema Primeri dobre prakse Intel CERN Cisco WebEx enovance EKSPERIMENT Namestitev in konfiguracija OpenStack v različnih testnih okoljih Namestitev in preizkus sistema OpenStack s sistemom DevStack Namestitev na 2 fizična stroja Izgradnja virtualnih strojev Testirni primeri v različnih okoljih in z različnimi konfiguracijami Podjetje M, d.o.o Podjetje Čisto življenje, d.o.o Imaginarno podjetje Sodeluj Rezultati testiranja DISKUSIJA Model ponudnika storitev v oblaku Model naročnika storitev v oblaku ZAKLJUČEK LITERATURA IN VIRI KAZALO SLIK KAZALO TABEL KRATICE IN AKRONIMI PRILOGE Priloga A - Preizkus odprtokodnega ERP sistema Dolibarr Priloga B Preizkus ERP sistema Openbravo Priloga C Preizkus CMR sistema espocrm

7 1 UVOD Koncept računalništva v oblaku se je začel razvijati v 50. letih prejšnjega stoletja, z izgradnjo centralnih računalniških sistemov z lahkimi odjemalci (ang. thin clients). Uporabniki teh sistemov so razdelili vire centralnega računalnika (pomnilnik, procesorski čas ipd.), s čimer so povečali izkoristek strojne opreme. V 70-tih letih so se začele pojavljati ideje o vedno dostopnih sistemih, ki bi uporabnikom omogočale dostop do»neskončnih virov«. Zametki računalništva v oblaku so torej vidni že zelo zgodaj, vendar pa so prve oblačne storitve bile predstavljene po letu Sprva samo s preprostimi spletnimi formularji. Večji mejnik v dobi oblačnih storitev je postavilo podjetje Amazon, ki je leta 2006 uvedla storitev Elastic Compute Cloud, s katero so uporabnikom omogočili najem računalniških virov za poganjanje lastnih aplikacij (Mohamed, 2012). Računalništvo v oblaku (ang. cloud computing) lahko razumemo kot inovativno tehnologijo ali naslednjo generacijo interneta ali pa kot temelj sprememb IT okolja in kot možnost vpeljave novih poslovnih idej (Baun, Kunze, Nimis, & Tai, 2011, str. V). Računalništvo v oblaku je strokovno precej nedefiniran izraz (Baun, Kunze, Nimis, & Tai, 2011), vendar pa temelji na modelu oz. ideji, ki omogoča nenehen in priročen dostop v skupen bazen računalniških virov, kot so na primer strežniki, skladišča, aplikacija in storitve (Brian, in drugi, 2012). Glede na ta model lahko izluščimo definicijo, ki pravi:»računalništvo v oblaku, s pomočjo virtualiziranega računalništva in skladiščenja ter novodobnih internetnih tehnologij, omogoča prilagodljive, mrežno centralizirano IT infrastrukturo, platforme in aplikacije ter storitve na zahtevo, ki se obračunavajo glede na uporabo«(baun, Kunze, Nimis, & Tai, 2011, str. 3). Konzorcij OpenStack je bil ustanovljen v letu 2010 za izgradnjo istoimenske oblačne storitve. Ima močno podporo podjetij, posebej izstopata NASA in Rackspace. Ustanovni člani konzorcija so: Jonathan Bryce (tudi ustanovni član Rackspace oblaka), Mark Collier, Lauren Sell, Heidi Bretz, James Blair, Todd Morey, Jeremy Stanley, Stefano Maffulli, Margie Callard in Claire Massey. Njegov cilj je ustvariti ekosistem, ki služi razvijalcem in uporabnikom ter zagotavlja sklop skupnih virov za rast javnih in zasebnih oblakov. S svojo filozofijo je ustanovnim članom uspelo pritegniti več kot 9500 individualnih članov in 850 različnih organizacij iz 100 držav, s čimer so zaslužili več kot 10 milijonov ameriških dolarjev. S pomočjo individualnih članov, od katerih je pričakovano redno sodelovanje v OpenStack skupnosti (na tehničnem ali organizacijskem področju), in organizacij, ki financirajo projekt, postaja OpenStack splošno prisotna oblačna platforma. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 1

8 2 METODOLOGIJA 2.1 Definicija problema Poslovna okolja, posebej večja, se zavedajo pomena kakovosti storitev v oblaku. Mala in srednja podjetja so pri uporabi storitev v oblaku previdnejša, zato te storitve uporabijo manj pogosto in v manjšem spektru. Le-ta podjetja so po celem svetu zelo pomemben gospodarski dejavnik, v Sloveniji, v obdobju recesije pa še posebej. V raziskavi se bomo osredotočili na tehnologijo OpenStack v kontekstu uporabe za mala in srednja podjetja. Preizkus OpenStack, ki je skupek odprtokodnih tehnologij za zelo prilagodljivo programje v oblačnih storitvah, predstavlja zahteven problem. Kljub izboljšanim navodilom in posebej razvitim orodjem je že sama pravilna namestitev zelo zahtevna. Tehnologija OpenStack je parcialno preizkušena v podjetjih, kot so: PayPal, Cisco WebEx, CERN, Harvard University idr. Preliminarni pregled literature kaže, da ni razvitega modela oblačnih storitev, ki bi temeljil na OpenStack in bil prilagojen za mala in srednja podjetja v vlogi ponudnikov ali uporabnikov oblačnih storitev. Nekateri ponudniki virtualnih strojev kot npr. Bitnami ali Turnkey omogočajo add-hoc kreiranje različnih odprtokodnih okolij, ki so potencialno zelo primerna za mala in srednja podjetja. V raziskavi bomo zato morali poiskali tipične odprtokodne sisteme, kot so ERP in CRM ter preskusili namestitev in delovanje njihovih virtualnih strojev v testnem okolju OpenStack. 2.2 Definicija ciljev in raziskovalnih vprašanj Cilji magistrskega dela so: 1. pregledati literaturo o tehnični sestavi in uporabi tehnologije OpenStack ter primerih dobre prakse; 2. namestiti tehnologije OpenStack v testno okolje; 3. preizkusiti delovanje tehnologije s tipičnimi virtualnimi stroji za poslovna okolja (ERP in CRM rešitve); 4. oceniti potrebne informacijske in človeške vire za uporabo OpenStack v vlogi ponudnika oz. naročnika storitve v oblak; 5. sintetizirati model oblačnih storitev z OpenStack za ponudnika in naročnika storitve v oblaku. Glavna raziskovalna vprašanja so: 1. Kakšni so potrebni informacijski in človeški viri za uporabo storitev v oblaku v okolju OpenStack? Blažka Globačnik: Model oblačnih storitev z OpenStack stran 2

9 2. Kakšen je tipičen napor, potreben za namestitev okolja OpenStack, za ponudnika in za naročnika storitev? 3. Kakšna je karakteristika odziva izbranih virtualnih strojev oz. na njih nameščenih poslovnih aplikacij ob naraščanju števila uporabnikov, števila virtualnih strojev v okolju OpenStack in števila zahtev po podatkih na spletnih straneh in bazah podatkov? 2.3 Metode, tehnike in uporabljena orodja V prvi fazi izdelave magistrskega dela bomo preučili literaturo s področja računalništva v oblaku in konkretno o tehnologiji OpenStack. Komponente OpenStack bomo po namestitvi testirali po metodi črne škatle. Preizkusili bomo tudi v dokumentaciji in literaturi opisane možne načine namestitve. Izbrali bomo nekaj tipičnih paketov ERP in CRM ter njihove virtualizirane implementacije. Tako pripravljene virtualne strežnike z nameščenimi poslovnimi rešitvami bomo testirali v omrežju z lokalnimi, zasebnimi IP naslovi kot tudi z javnimi IP naslovi. V dogovoru s konkretnimi malimi podjetji bomo za njih oblikovali portfelj oblačnih storitev, ki jim najbolj ustreza. Ocena primernosti tehnologije OpenStack bo temeljila pretežno na razpoložljivosti oblačnih storitev. Vse te aktivnosti sodijo v kontekst sistemskega in programskega inženiringa. 2.4 Omejitve raziskave Raziskavo bomo izvajali v okolju več osebnih računalnikov, ki jim bomo dodelili vlogo strežnikov. V testnem okolju bomo izvajali testiranje z manjšim številom realnih in virtualnih uporabnikov ter z odprtokodnimi aplikacijami. Zaradi manjšega števila uporabnikov bo tudi močno omejena količina povratnih informacij glede samega delovanja oblačnih storitev, kar lahko vodi v daljše faze testiranja in ožji pogled na problematiko v primerjavi s tem, če bi imeli na voljo več uporabnikov za testiranje. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 3

10 3 STORITVE V OBLAKU 3.1 Računalništvo v oblaku V uvodu smo predstavili zgodovino in koncept računalništva v oblaku, katerega zgradbo prikazuje slika 1. Poleg dostopa do določenih virov brez omejitev in boljšega izkoristka strojne opreme so pomembne tudi naslednje karakteristike (Baun, Kunze, Nimis, & Tai, 2011, str. 3; Mell & Grance, 2011; Jadeja & Modi, 2012): za izgradnjo potrebujemo manj znanj o informacijskih tehnologijah, širok spletni dostop (viri so dosegljivi preko internetne povezave), združevanje virov (ang. resource pooling; omogoča vzporedne storitve večih uporabnikov naenkrat), elastičnost oz. hitra prilagodljivost (omogoča uporabniku iluzijo neomejenih virov), merljiva kvaliteta storitve, nižji stroški infrastrukture, izboljšana varnost podatkov. Slika 1: Konceptualni model računalništva v oblaku (vir: Vivod, 2013, str. 3) Blažka Globačnik: Model oblačnih storitev z OpenStack stran 4

11 3.1.1 Vrste modelov računalništva v oblaku in modeli storitev Jadeja in Modi (2012) navajata, da lahko sistem računalništva v oblaku razdelimo na 2 sekciji, in sicer ospredje in ozadje. Ospredje predstavlja vse kar uporabnik vidi pri uporabi (aplikacije), ozadje pa je dejanski oblak s strežniki in podatkovnimi skladišči. Računalništvo v oblaku se je razvilo v štirih namestitvenih modelih, ki obravnavajo načine dostopanja do fizičnih strežnikov in njihovih lokacij. Modeli so naslednji (Mell & Grance, 2011; Vivod, 2013, str. 7-9; Baun, Kunze, Nimis, & Tai, 2011, str ): javni oblačni sistem, zasebni oblačni sistem, hibridni oblačni sistem in skupnostni oblačni sistem. Javni oblačni sistem je namenjen za odprto uporabo javnosti. Ta sistem lahko naročijo, si ga lastijo, upravljajo tako podjetja kot tudi izobraževalne ustanove in uprava (Mell & Grance, 2011). Javni oblačni sistem je tudi edini, ki predstavlja prave karakteristike računalništva v oblaku, saj uporabniki ne potrebujejo lastne infrastrukture, vsi viri pa so deljeni med različne kliente (Vivod, 2013, str. 9). Model zasebnega oblačnega sistema ima najboljšo zmožnost prilagajanja in je pripravljen glede na želje uporabnika (npr. podjetje). Pri zakupu zasebnih oblačnih sistemov, uporabniki navadno gostijo infrastrukturo v lastnih prostorih, ponudnik storitev pa skrbi za vzdrževanje. Pri uporabi zasebnega oblačnega sistema kontrola nad podatki ostane v rokah uporabnikov, kar pomeni tudi višjo raven varnosti. Na voljo so tudi drugačne oblike zasebnih sistemov, pri katerih pa uporabnik ne gosti infrastrukture v svojih prostorih, temveč se le-ta nahaja v centrih ponudnika. Govorimo o t. i. navideznih zasebnih oblakih, katerih najbolj znan ponudnik je Amazon s storitvijo Virtual Private Cloud (Vivod, 2013, str. 7-8; Mell & Grance, 2011; Baun, Kunze, Nimis, & Tai, 2011, str. 15). Hibridni sistem je sestavljen iz dveh ali več ločenih oblačnih infrastruktur (npr. zasebni-javni, zasebni-skupnostni, skupnostni-javni), ki ostanejo kot edinstveni subjekti, vendar pa so povezani s standardnimi tehnologijami za prenos podatkov in aplikacij (Mell & Grance, 2011). Hibridni modeli se uporabljajo tudi za blaženje preobremenitev sistemov, saj se lahko, ob preobremenitvi primarnega sistema, uporabnike preusmeri v oblačne storitve (Vivod, 2013, str. 8). Skupnostni oblačni sistem je podoben zasebnemu sistemu, vendar je namenjen uporabnikom enakih skupnosti (npr. organizacije, društva, podjetja), ki si delijo podobne oz. iste cilje (Mell & Grance, 2011; Vivod, 2013, str. 9). Takšni modeli so navadno uporabljeni pri javnih organizacijah, katerih podatki morajo biti dostopni različnim enotam (npr. zdravstveni podatki pacientov, bančni podatki, ipd.) (Vivod, 2013, str. 9). Slika 2 prikazuje razliko med javnim, zasebnim in hibridnim oblakom. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 5

12 Slika 2: Prikaz razlik med vrstami oblakov (vir: lasten) Namestitveni modeli oblakov definirajo lokacijo infrastrukture in dostop do infrastrukture, ne definirajo uporabe le-te infrastrukture. Klasični sistem namestitve zahtevajo tako strojno opremo kot tudi skrb za delovanje le-te. Računalništvo v oblaku pa uporabnikom omogoča izbiro med storitvenimi modeli, ki so na neki način prilagojene željam uporabnika (Vivod, 2013). Baun in drugi (2011, str. 17) navajajo, da obstajajo 4 različni storitveni modeli, in sicer: model HuaaS (ang. humans as a service), model SaaS (ang. software as a service), model PaaS (platform as a service) in model Iaas (infrastructure as a service). Navadno avtorji ne upoštevajo modela HuaaS in govorijo o modelih SaaS, PaaS in IaaS (Brian, in drugi, 2012, str. 8; Mell & Grance, 2011; Chappell, 2008). Model HuaaS dokazuje, da oblačne storitve niso omejene samo na IT storitve, temveč lahko vključujejo tudi ljudi kot vire podatkov. Tipična storitev pri HuaaS modelu je zunanje izvajanje storitev (ang. outsourcing), kjer podjetje ponudnika omogoča izvajanje IKT storitev v podjetju naročnika (Baun, Kunze, Nimis, & Tai, 2011, str ). Model SaaS predstavlja drugo plast v piramidi računalništva v oblaku (oz. prvo, če ne upoštevamo modela HuaaS) (Baun, Kunze, Nimis, & Tai, 2011, str. 20). SaaS preko interneta dostavi aplikacijo k uporabniku, s čimer uporabniku ni treba namestiti dotične aplikacije (Jadeja & Modi, 2012, str. 878; Baun, Kunze, Nimis, & Tai, 2011, str. 20). SaaS model je npr. uporabil tudi Google pri Google Apps (Jadeja & Modi, 2012, str. 878). Paas predstavlja model, kjer uporabnik zakupi celotno izvajalno okolje (Vivod, 2013, str. 13). Pri modelu PaaS storitev vsebuje popolno platformo in razvojna orodja (Brian, in drugi, 2012, str. 9), kar pomeni, da Blažka Globačnik: Model oblačnih storitev z OpenStack stran 6

13 uporabniku ni treba kupiti in naložiti strojne ter programske opreme (Jadeja & Modi, 2012, str. 878). Zadnjo plast pa tvori model Iaas. Ta model uporabnikom omogoča najem navidezne infrastrukture oz. računalniških virov, ki zajema samo fizično infrastrukturo in mehanizme za upravljanje virtualnih strojev. Uporabniki tako sami izberejo operacijski sistem in drugo programsko opremo (Vivod, 2013, str. 12; Baun, Kunze, Nimis, & Tai, 2011, str. 18). Prednost IsaaS modela je tudi v tem, da uporabniki plačajo samo čas uporabe storitve (Jadeja & Modi, 2012, str. 878). Predstavitev modelov prikazuje slika 3, kjer zelena barva prikazuje s čim upravljajo organizacije in rdeča barva s čim upravlja ponudnik storitve. Slika 3: Predstavitev oblačnih modelov (vir: Brian, in drugi, 2012, str. 8; Vivod, 2013, str. 15) Virtualizacija, storitveno-orientirana arhitektura in spletne storitve Računalništvo v oblaku pa je predvsem odvisno od tehnologij virtualizacije, storitveno-orientirane arhitekture (SOA) in spletnih storitev (Baun, Kunze, Nimis, & Tai, 2011). V nadaljevanju bomo tako predstavili te tri tehnologije in prednosti ter slabosti računalništva v oblaku. Virtualizacija Virtualizacija virov predstavlja bistvo večine oblačnih arhitektur. Koncept virtualizacije omogoča abstraktni in logični pregled virov, hkrati pa vključuje tudi strežnike, podatkovna skladišča, omrežja in programsko opremo. Prvotna ideja predstavlja izgradnjo mesta, kjer bi se lahko zbirali fizični viri in bi jih bilo mogoče upravljati kot celoto (Baun, Kunze, Nimis, & Tai, 2011, str. 5). Preprosto rečeno, virtualizacija je posnemanje strojne opreme znotraj programskih platform, kar enemu računalniku omogoča simulacijo večih računalnikov hkrati (Yuusuf & Vidalis, 2012, str. 270), kar pomeni, da je virtualizacija učinkovita raba danih virov, ki omogoča hitro zmanjšanje stroškov (Portnoy, 2012, str. xv). Blažka Globačnik: Model oblačnih storitev z OpenStack stran 7

14 Virtualizacija nudi številne prednosti (Baun, Kunze, Nimis, & Tai, 2011, str. 5-6; Yuusuf & Vidalis, 2012, str. 270), kot so: boljša izraba virov, avtomatizirani menedžment (možno je avtomatsko upravljanje oz. menedžiranje bazena virov in tvorbe virtualnih strojev), konsolidacija (različni razredi aplikacij se lahko združijo v manjše število fizičnih sestavnih komponent), manjša poraba energije (s pomočjo konsolidacije zmanjšamo število fizičnih komponent, kar zmanjša porabo energije), manj prostora (z virtualizacijo lahko zmanjšamo število strežnikov in prihranimo prostor), boljša varnost in boljše načrtovanje nujnih primerov (virtualne stroje je možno premikati iz enega bazena virov v drugega), dinamično obnašanje pri zahtevah (vse zahteve so lahko izpolnjene takoj, ko so le-te»izrečene«, brez strahu pred ozkim grlom (ang. bottleneck)), visoka razpoložljivost (storitve so nenehno dostopne, tudi kadar se izvajajo nadgradnje strojne opreme, saj je selitev virtualnih strojev možna brez večjih težav), dostopnost z različnimi vlogami (virtualizacija izolira vsak virtualni stroj med seboj in od fizičnega stroja, kar pripomore k lažji delitvi vlog in posledično boljše upravljanje s strankami) in manjši stroški (zaradi manjše porabe prostora, energije, hlajenja in strojne ter programske opreme). Slabosti, ki se lahko pojavijo ob virtualizaciji, so naslednje (Yuusuf & Vidalis, 2012, str. 271): slabša varnost na fizičnem gostitelju (npr. v primeru virusa na gostitelju, ki okuži vse podatke, bodo okužene tudi vsi virtualni stroji, ki tečejo na tem gostitelju), pomanjkljivo spremljanje virov (ob virtualizaciji se navadno preračuna koliko virtualnih strojev lahko teče na fizičnem stroju, nato pa se na preverjanje fizičnih strojev pozabi), neavtorizirani dostop (virtualne stroje je zelo lahko skopirati, kar lahko povzroči težave, če isti virtualni stroj uporabljajo različni ljudje, kar lahko povzroči nedovoljene dostope do podatkov drugih uporabnikov), pomanjkanje menedžmenta (pri virtualizaciji se vloge nadzornikov strojne opreme in nadzornikov programske opreme rahlo premešajo in velikokrat se zgodi, da strokovnjaki ne vedo kdo točno bi moral neko napako odpraviti). Virtualizacija kot pojem predstavlja več različnih konceptov in tehnologij, ki se razlikujejo predvsem po načinu implementacije, možnosti in pogostosti uporabe. Poznamo naslednje koncepte virtualizacije (Baun, Kunze, Nimis, & Tai, 2011, str. 7): Blažka Globačnik: Model oblačnih storitev z OpenStack stran 8

15 virtualizacija operacijskega sistema (ang. operating system virtualization), virtualizacija platform (ang. platform virtualization), virtualizacija omrežja (ang. network virtualization), virtualizacija aplikacij (ang. application virtualization) in virtualizacija podatkovnega skladišča (ang. storage virtualization). Virtualizacija operacijskega sistema Virtualizirani operacijski sistemi (imenovani tudi zabojniki, ang. container) tečejo na isti strojni opremi in istem gostitelju (kernel). Operacijski sistemi so videti kot avtonomni sistemi in ne kot virtualizirani sistemi. Z virtualizacijo operacijskih sistemov se rešijo težave varnosti in zaupnosti podatkov. Ta tip virtualizacije uporabljajo ponudniki spletnih storitev (ang. Internet service providers, ISPs), ki uporabnikom ponujajo virtualne strežnike. S tem načinom se zmanjša sama fleksibilnost virtualiziranja, saj lahko hkrati tečejo samo isti operacijski sistemi (Baun, Kunze, Nimis, & Tai, 2011, str. 7). Slika 4 prikazuje koncept virtualizacije operacijskega sistema. ZABOJ 1 APLIKACIJE ZABOJ 2 APLIKACIJE GOSTITELJ (KERNEL) STROJNA OPREMA Slika 4: Koncept virtualizacije operacijskega sistema (vir: Baun, Kunze, Nimis, & Tai, 2011, str. 7) Virtualizacija platform Virtualizirane platforme dovoljujejo izvajanje različnih operacijskih sistemov in aplikacij v virtualnem okolju. Obstajata 2 modela, in sicer (Baun, Kunze, Nimis, & Tai, 2011, str. 8): polna virtualizacija in paravirtualizacija. Polna virtualizacija je osnovana na simulaciji celotnega virtualnega računalnika z virtualnimi viri (CPU, RAM, pogoni, omrežni adapterji, BIOS), kar omogoča večjo operativno hitrost gostujočega operacijskega sistema, ki je primerljiva s klasičnim ne-virtualiziranim strojem. Paravirtualizacija ne dovoljuje posnemanja plasti strojne opreme v gostujočem operacijskem sistemu, temveč samo posnema vmesnik aplikacije, kar pomeni, da je treba gostujoči operacijski sistem spremeniti, saj je direkten dostop do strojne opreme nemogoč, mogoč pa je dostop do nadzornika. Oba modela pa sta implementirana v bazo nadzornika (ang. hypervisor) virtualnega stroja. Nadzornik je meta-operacijski sistem, ki se uporablja za porazdelitev strojnih virov med gostujočimi sistemi in za usklajevanje dostopov. Nadzornik tipa 1 je vgrajen Blažka Globačnik: Model oblačnih storitev z OpenStack stran 9

16 neposredno na strojno opremo, nadzornik tipa 2 pa teče pod tradicionalnim osnovnim operacijskim sistemom (Baun, Kunze, Nimis, & Tai, 2011, str. 8). Nadzornik virtualnega stroja mora kazati 3 lastnosti v naslednjem vrstnem redu (Portnoy, 2012, str. 2): zvestoba (okolje, ki ga ustvarimo z virtualnimi stroji mora biti enako fizičnemu stroju), osamitev ali varnost (nadzornik mora imeti popolni nadzor nad sistemom virov) in delovanje (delovanje virtualnega stroja se ne sme razlikovati od delovanja fizičnega stroja z enakimi karakteristikami). Slika 5 prikazuje koncept virtualizacije platform z nadzornikom tipa 1. VIRTUALNI STROJ APLIKACIJE GOSTUJOČI OS VIRTUALNI STROJ APLIKACIJE GOSTUJOČI OS NADZORNIK VIRTUALNEGA STROJA STROJNA OPREMA Slika 5: Koncept virtualizacije platform z nadzornikom tipa 1 (vir: Baun, Kunze, Nimis, & Tai, 2011, str. 8) Virtualizacija omrežja Virtualizacija omrežja se uporablja za uravnoteženje obremenitev in avtomatski preklop v primeru okvare, kar je mogoče s tehnologijo grozda (ang. cluster technology). Prav tako pa se uporablja tudi za virtualna lokalna omrežja (VLANs) in virtualna stikala (ang. virtual switch). V tem primeru se oblačni viri pojavijo v omrežju uporabnika. Tehnologija VLAN ima naslednje prednosti (Baun, Kunze, Nimis, & Tai, 2011, str. 9): transparentnost (distribuirane naprave so lahko združene v enotno logično omrežje) in varnost (določene sisteme se lahko skrije v ločeno virtualno omrežje). Virtualizacija aplikacij Virtualizacija aplikacij je programski prodajni model, kjer so preko omrežja uporabnikom ponujene centralno upravljanje aplikacije. Prednosti virtualizacije aplikacij so (Baun, Kunze, Nimis, & Tai, 2011, str. 10): lažja administracija, avtomatično upravljanje z nadgradnjami in novimi verzijami, Blažka Globačnik: Model oblačnih storitev z OpenStack stran 10

17 vsi uporabniki uporabljajo enak nabor programske opreme, dostop do aplikacij na globalnem nivoju. Obstajata 2 različni metodi za uvajanje virtualizacije aplikacij, in sicer (Baun, Kunze, Nimis, & Tai, 2011, str. 10): gostujoča aplikacija (aplikacija je na voljo na internetu in uporabnik jo lahko prenese preko t. i. pretočnega protokola (ang. streaming protocol)) ali virtualna naprava (aplikacijo je možno prenesti z neke spletne strani in naložiti na osebni računalnik). V oblačnem okolju virtualizacija aplikacij predstavlja pomemben tempelj koncepta SaaS (ang. Software as a Service), ki je zadolžen za dinamično zagotavljanje programskih komponent (Baun, Kunze, Nimis, & Tai, 2011, str. 10). Virtualizacija skladišč Virtualizacija skladišč kot pojem predstavlja koncept logične predstavitve različnih podatkovnih bazenov (Wolf & Halter, 2005, str. 435). Ideja razvoja virtualnih skladišč temelji na združevanju različnih bazenov podatkov, ki večinoma tečejo na fizičnih strežnikih. Virtualizirana skladišča pa bazene podatkov dinamično združujejo in upravljajo. Navadno so podatki v oblakih nudeni kot spletni objekti, ki se lahko prenesejo oz. manipulirajo kar preko spleta. Za same prenose podatkov se navadno uporabljajo bodisi SAN (ang. storage area network) omrežje bodisi LAN (ang. local company network) omrežje (Baun, Kunze, Nimis, & Tai, 2011, str. 9). Wolf in Halter (2005, str. 435) navajata, da je k razvoju virtualiziranih skladišč pripomogla predvsem RAID tehnologija (ang. redundant array of independent disks), ki omogoča konfiguracijo dveh ali več fizičnih diskov v en sam logični disk, s čimer pridobimo toleranco v primeru okvar. Najpogostejše stopnje RAID tehnologije so (Wolf & Halter, 2005, str. 435): RAID 0, RAID 1, RAID 5, RAID 0+1, RAID 1+0 in RAID 5+0. RAID 0 je načeloma edini izmed RAID-ov, ki nima tolerance za okvare. Vsi diski, ki so povezani v RAID 0, so nujni, saj so podatki razporejeni na dva ali več diskov (slika 6 levo zgoraj). V primeru, da pride do okvare enega izmed povezanih diskov, se podatki izgubijo in nimamo možnosti ponovnega pridobivanja le-teh. Prednosti RAID 0 so v tem, da je ta tehnologija zelo hitra. Uporabna je v primeru podatkov, ki se načeloma lahko izgubijo oz. začasnih ali dinamičnih podatkov. Slabost je zagotovo nična toleranca za okvare. RAID 1 je na voljo v 2 oblikah, in sicer z zrcaljenjem diskov ali s podvajanjem diskov. Ne glede na obliko, pa RAID 1 deluje z Blažka Globačnik: Model oblačnih storitev z OpenStack stran 11

18 »odvečnimi«diski, kar omogoča toleranco za okvare. V povezavi so dva ali več diskov in kar se zapiše na 1 disk se nato kopira oz. zrcali tudi na naslednja dva (slika 6 levo spodaj). V primeru okvare enega diska, tako ne izgubimo vseh podatkov. Slabost RAID 1 je, da je počasnejši kot RAID 0 in da za samo izvedbo potrebujemo vsaj dvakrat več diskov kot jih lahko na koncu dejansko uporabljamo. RAID 5 deluje podobno kot RAID 0, vendar RAID 5 za delovanje potrebuje minimalno 3 diske ter vključuje pariteto za varovanje podatkov. Zaradi uporabe paritete lahko RAID 5 preživi odpoved enega izmed minimalno treh diskov, vendar pa večjih izgub ne zmore. RAID 5 je dobra izbira za vse, ki želijo hitra skladišča in toleranco za okvare, saj so podatki na voljo tudi ob izgubi enega izmed diskov. RAID 0+1 lahko poimenujemo kar zrcaljeni model (ang. mirrored stripes), saj so podatki najprej razporejeni v RAID 0 in nato je to polje zrcaljeno v»odvečni«raid 0 (slika 6 desno). Pri konfiguraciji RAID 0+1, najprej nastavimo 2 polji RAID 0, nato ustvarimo zrcaljeni sliki teh polj. Toleranca za okvare je enaka kot pri RAID 1, kar pomeni izgubo največ 1 disk. Prednosti te konfiguracije so boljše delovanje od RAID 0, vendar pa potrebujemo veliko število fizičnih diskov. RAID 1+0 oz. RAID 10 nastaja podobno kot RAID 0+1, vendar pa najprej ustvarimo zrcalne pare diskov (RAID 1) in jih nato združimo v RAID 0. Ta princip omogoča dostop do podatkov ob izgubi vseh razen enega fizičnega diska v določeni vrstici (ang. stripe). V primeru izgube celotne vrstice, so podatki izgubljeni. Na enak princip deluje tudi RAID 5+0, kjer lahko izgubimo en disk v vsaki skupini in še zmeraj dostopamo do podatkov (Wolf & Halter, 2005, str ). Blažka Globačnik: Model oblačnih storitev z OpenStack stran 12

19 Slika 6: Prikaz RAID 0, RAID 1 in RAID 0+1 tehnologije (vir: Wolf & Halter, 2005, str ) Storitveno orientirana arhitektura SOA SOA predstavlja tako koncept oblikovanja kot tudi arhitekture. SOA je arhitektura, kjer so aplikacije zasnovane tako, da zagotavljajo grobo strukturirane storitve, ki se jih uporablja za integracijo aplikacij ali poslovnih procesov. Koncept oblikovanja pa temelji na načrtovanju aplikacij oz. sistemov z natančno opredeljenimi vmesniki za dostopanje in storitvami, ki se združujejo v poslovne procese (Jurič & Ramesh Sarang, 2007, str. 57). Navadno so komponente SOA vgrajene kot neodvisne storitve, ki pa jih lahko fleksibilno povežemo skupaj (komunicirajo lahko že v ohlapnih konfiguracijah) (Baun, Kunze, Nimis, & Tai, 2011, str. 10). Slika 7 prikazuje odnos med ponudnikom storitev, uporabnikom storitev in imenikom storitev. Uporabnik lahko poišče določeno storitev v imeniku storitev ali s pomočjo posrednika storitev (ang. service broker). Če je bila storitev najdena, uporabnik prejme podatke, kje lahko le-to najde. Nato je lahko storitev klicana in ponudnik lahko le-to storitev pošlje uporabniku (Baun, Kunze, Nimis, & Tai, 2011, str. 11). Blažka Globačnik: Model oblačnih storitev z OpenStack stran 13

20 Slika 7: Igralci in aktivnosti SOA (vir: Baun, Kunze, Nimis, & Tai, 2011, str. 11) Storitve so lahko vgrajene v SOA na 2 načina, in sicer (Baun, Kunze, Nimis, & Tai, 2011, str. 12): s povezavo od točke do točke (ang. point-to-point connection) ali z načinom»razdeli in komuniciraj«(ang. hub-and-spoke approach). Povezava od točke do točke individualno povezuje ponudnika in uporabnika pri vsaki zahtevani storitvi. Pri tem načinu povezovanja mora uporabnik poznati IP oz. URL naslov ponudnika storitve, saj je zahteva poslana neposredno k ponudniku. Pri načinu»razdeli in komuniciraj«pa razdelilnik (ang. hub) deluje kot posrednik med ponudnikom in uporabnikom storitev, kar prikazuje slika 8 (Baun, Kunze, Nimis, & Tai, 2011, str. 12). STORITEV A STORITEV B STORITEV A STORITEV B P O S R E D N I K STORITEV C STORITEV D STORITEV C STORITEV D Slika 8: Povezava od točke do točke (levo) in način razdeli in komuniciraj (desno) (vir: Baun, Kunze, Nimis, & Tai, 2011, str. 12) Spletne storitve Spletne storitve spadajo v SOA tehnologijo in so zaželene predvsem zaradi uporabe odprtih protokolov, kot so HTTP (ang. hypertext transfer protocol) in XML (ang. extensible markup language) (Ramos de Oliveira, Vieira Sanchez, Estrella, Pontin de Blažka Globačnik: Model oblačnih storitev z OpenStack stran 14

21 Mattos Fortes, & Brusamolin, 2013, str. 40). Spletne storitve opisujejo tako standarde za oblikovanje in procesiranje sporočil kot tudi standarde za vmesnike. V osnovi spletne storitve opisujejo samo osnovne zahteve za izmenjavo podatkov med ponudnikom in uporabnikom (Baun, Kunze, Nimis, & Tai, 2011, str. 13). Spletne storitve sestojijo iz storitve in opisa storitve. Storitev je programski modul, ki se naloži na računalniško platformo z uporabo internetne povezave. Opis storitev pa vsebuje podrobnosti o vmesnikih, navodila za vgradnjo storitve, podatkovne tipe in aktivnosti, načrt združevanja podatkov in omrežne lokacije (Ramos de Oliveira, Vieira Sanchez, Estrella, Pontin de Mattos Fortes, & Brusamolin, 2013, str. 41). Storitve so najpogosteje zasnovane v razredih SOAP/WSDL (ang. simple object access protocol/ web services description language) ali REST (ang. representational state transfer) (Baun, Kunze, Nimis, & Tai, 2011, str. 13). 3.2 Prednosti in slabosti računalništva v oblaku Kot že omenjeno je računalništvo v oblaku slabo definiran pojem. Definicijam je skupno dejstvo, da računalništvo v oblaku omogoča dostop do nekih podatkov z uporabo spleta. Podjetja se navadno odločajo za računalništvo v oblaku zaradi nižjih stroškov in manjše potrebe po fizični infrastrukturi. Vivod (2013) prav tako navaja naslednje prednosti računalništva v oblaku: boljša izkoriščenost virov, ki jih ima podjetje na voljo; za delovanje oblaka ne potrebuje lastne strojne opreme; nižji stroški obratovanja, kadrovanja in nakupa ter vzdrževanja strojne in programske opreme; oblačni sistem je lahko geografsko razpršen (oblak lahko sestavlja več podatkovnih centrov, ki niso na istem mestu); visoka odpornost na katastrofalne dogodke; elastičnost storitve (hitro spreminjanje količine virov) in lažje izvedljivost filozofije BYOD (ang. bring your own device). Slabosti računalništva v oblaku, kot navaja Vivod (2013) so naslednje: uporabnik lahko»čez noč«izgubi vse podatke;»priklenjenost«(ang. vendor lock-in) na enega uporabnika; izbris varnostnih kopij podatkov po preteku naročniškega razmerja; lastništvo podatkov (podatki so v rokah ponudnika in ne lastnika) in varnost storitve in podatkov zaradi najema oblaka. Med slabosti računalništva v oblaku se štejejo tudi (Shagin, 2012): delovanje je odvisno od internetne povezave; težave pri izgradnji hibridnih sistemov in centralizacija podatkov (v primeru shranjevanja podatkov pri enem ponudniku). Blažka Globačnik: Model oblačnih storitev z OpenStack stran 15

22 3.3 Obnovitev po izpadu Dandanes podjetja vedno bolj uporabljajo informacijske tehnologije za svoje delo. Tako so podatki shranjeni v fizičnih ali oblačnih podatkovnih centrih in so tako nenehno na voljo. Zaradi te odvisnosti od informacijskih tehnologij lahko vsak nenavadni in nenadni dogodek povzroči kopico težav. To pa lahko razumemo kot katastrofalni dogodek. Katastrofalni dogodki so torej nepredvideni dogodki, ki povzročijo kratkoročno ali dolgoročno prekinitev delovanja podjetja (Varghese, 2002, str. 2). Katastrofalni dogodki so lahko DOS (ang. denial-of-service) napadi, človeške napake, okvara strojne opreme, naravne nesreče (Cummins, 2011, str. 7), pomanjkanje električne energije in internetne povezave, nove IT tehnologije ipd (Sanhu, 2002, str. 3-4). Navadno podjetja, ki uporabljajo javne oblačne storitve, pozabijo na zaščito pred katastrofalnimi dogodki oz. vzpostavitev stanja po katastrofalnih dogodkih, saj so svoje podatke poslali v oblak, ki se verjetno ne bo»pokvaril«. Problem nastane, kadar ponudnik oblačnih storitev prav tako nima plana za reševanje podatkov po katastrofalnih dogodkih. Brandon (2011) navaja primere uporabe različnih oblačnih ponudnikov, kjer nekdo skrbi za redno delovanje storitev, drugi pa skrbi samo za varnostno kopiranje podatkov. Čas, ko osnovni in varovalni sistem ne delujeta lahko povzroči padec prihodkov, zmanjšano verodostojnost, kazni zaradi kršenja pogodb, stroške ponovne vzpostavitve sistema in ponovno pridobivanje podatkov, itd (vmware, 2013). V brošuri podjetja Vmware (2013) je zavedeno, da kar 40 % podjetij, ki ne pridobijo vseh podatkov v 24 urah, izgubijo posel in prenehajo delovati. Fizični čas, ki se ga uporabi za vzpostavitev normalnega stanja po katastrofalnem dogodku je dolg. Velikokrat se tudi zgodi, da podjetja zaradi velikih stroškov, kompleksnosti in neavtomatiziranih postopkov nimajo načrta kako ponovno pridobiti izgubljene podatke. Z uporabo virtualnih strojev lahko čas, potreben za vzpostavitev normalnega stanja skrajšamo za približno 10-krat (vmware, 2013), kar prikazuje slika 9. Tehnologija virtualiziranih skladišč ščiti in integrira različno strojno opremo ter orodja v povezano celoto, kar omogoča enemu viru izgradnjo več različnih podatkovnih skladišč, ki predstavljajo bistvo varnostnega kopiranja podatkov (Li, Sun, Zheng, & Shen, 2012, str. 111). Blažka Globačnik: Model oblačnih storitev z OpenStack stran 16

23 Slika 9: Prikaz razlike med fizičnim in virtualnim»okrevanjem«po katastrofalnem dogodku (vir: vmware, 2013, str. 3) Za vzpostavitev normalnega stanja po katastrofalnem dogodku sta možna dva načina, in sicer (vmware, 2013, str. 11): nadomestni način delovanja (ang. Failover) in izpostavitven način delovanja (ang. Failback). Z nadomestnim načinom delovanja v primeru katastrofalnega dogodka avtomatsko preklopimo na nadomestni strežnik, sistem ali omrežje in tako sistem deluje s pomočjo varnostnih kopij. Pri izpostavitvenem načinu delovanja pa proces obsega obnavljanje sistema ali sredstev v prvotno stanje pred katastrofo (vmware, 2013, str. 11). 3.4 Upravljanje identitet Preden lahko začnemo govoriti o upravljanju identitet, moramo ugotoviti kaj razumemo pod pojmom identiteta. Takahashi in Bertino (2011, str ) opredeljujeta različne definicije identitete. Pravita, da lahko identitete opisujemo iz različnih pogledov, saj identiteta na splošno vključuje vse od sociologije, psihologije in filozofije do računalniških znanosti. Avtorja razmišljata v smeri, da je identiteta posameznika sestavljena iz več različnih manjših identitet, ki predstavljajo posameznika in mu določajo specifično vlogo. Identiteta je torej prikaz atributov, ki predstavljajo posameznika in nam dajejo splošne informacije o posamezniku (Takahashi & Bertino, 2011, str ). Upravljanje identitet (ang. identity management) ali upravljanje istovetnosti se tako navezuje na sistem izdelovanja, spreminjanja in brisanja različnih entitet (Slovensko društvo Informatika, 2014). Takahashi in Bertino (2011, str. 23) menita, da je upravljanje identitet proces, pri katerem se zagotavlja neokrnjenost podatkov za nemoteno delovanje življenjskega cikla. Naloga sistemov za upravljanje identitet je torej upravljanje celotnega spektra delovanja uporabnika v sistemu, od ustvarjanja uporabniškega računa do postavljanja Blažka Globačnik: Model oblačnih storitev z OpenStack stran 17

24 pravic dostopanja ipd. (Cör, 2009, str. 5). Namen upravljanja identitet uporabnikov je torej enoten dostop in izboljšanje storitev (npr. enotne prijave, enoten način spreminjanja gesel ipd.), povečana varnost pred zlorabami in boljše varovanje osebnih podatkov ter znižanje stroškov upravljanja in integracije (Upravljanje identitet, 2012). Uporabniki oblaka potrebujejo dostop do vmesnika za upravljanje oblaka, kar pa predstavlja šibko točko v varnosti oblačnih storitev. Za dobro varnost oblačnih storitev je treba poznati in uporabljati 5 temeljnih funkcij, in sicer (Ahmed & Alexandrov, 2011, str. 115): zagotavljanje identitete, odstranjevanje identitet, preverjanje istovetnosti in poenotenost identitet, avtorizacija in upravljanje uporabniških računov ter podpora skladnosti. Eden glavnih izzivov, s katerimi se podjetja srečujejo, je zagotavljanje identitete tako, da so le-te varne, časovno ustrezne in prenosljive v oblačne storitve. Med najpomembnejše izzive organizacij se štejejo tudi vsi izzivi, ki so povezani s preverjanjem istovetnosti uporabnikov. Med le-te izzive štejemo, upravljanje povernic, močno overjanje identitet, razdeljevanje avtentikacij in upravljanje zaupanja oblačnih storitev. Pomembno je tudi, da so identitete poenotene oz. da se sklene dogovor o določanju identitete med ponudnikom oblačnih storitev in ponudnikom identitet, saj lahko tako podjetja uporabijo identitete izbranega ponudnika identitet in s pomočjo le-teh ustvarijo identitete v oblačnih storitvah (Kumaraswamy, Lakshminarayanan, Reiter, Stein, & Wilson, 2010, str. 6). Pri izbiri sistema za upravljanje identitet pomembno vlogo igra sama arhitektura oblaka. V primeru arhitekture SaaS bo sistem potreboval samo dostop do aplikacij, v primeru arhitekture PaaS ali IaaS pa bo zahteval tako dostop do aplikacij kot tudi do sistema. V vseh primerih pa mora sistem omogočati integracijo z oblačnim sistemom (za poenotenje identitet) (Gopalakrishnan, 2009). Blažka Globačnik: Model oblačnih storitev z OpenStack stran 18

25 4 ODPRTOKODNI OPERACIJSKI SISTEM LINUX Namestitev OpenStacka predvideva uporabo operacijskega sistema Linux oz. različne distribucije le-tega sistema. V nadaljevanju bomo tako predstavili zgodovino ter zgradbo operacijskega sistema Linux. 4.1 Zgodovina odprtokodnih sistemov Kadar govorimo o odprtokodnih sistemih prvo pomislimo na Linux. Vendar pa se je razvoj odprtih operacijskih sistemov začel še pred razvojem Linuxa. V 70-ih letih prejšnjega stoletja je bila programska oprema brezplačna (leta 1969 se je razvil UNIX), saj so jo pisali inženirji oz. skrbniki računalniških sistemov, ki so si tako vzajemno olajševali vsakodnevne naloge. Kmalu pa je ta kooperativni duh izginil in začelo se je skrivanje izvorne kode ter dodatnih rešitev. Leta 1983 je Richard Stallman, veliki borec za odprto kodo, objavil načrte za GNU operacijski sistem na ARPAnet in USENET poštnih listinah. 2 leti kasneje je izdal tudi GNU manifest, s katerim je definiral in razložil cilje GNU projekta. Želel je ustvariti brezplačni operacijski sistem, ki bo združljiv z operacijskimi sistemi UNIX, vendar pa bi bil brez ene same vrstice kode iz UNIX-a. Stallman je tako skozi razvijanje svojega operacijskega sistema spoznal programsko jedro razvojnega kolega Linusa Torvardsa, Linux, ki se je sprva imenoval Freax (Globačnik, 2007, str. 9-11). 4.2 Sestava GNU/Linux Linux, kot programsko jedro ustvarjeno leta 1991, se zgleduje po operacijskem sistemu MINIX (Globačnik, 2007, str. 10). Kernel je programsko jedro, ki upravlja s strojno opremo ter omogoča komunikacijo med programi. Prav tako skrbi za določanje potrebnega spomina in CPU porabo (Smith, 2012, str. 2). Sestavo programskega jedra prikazuje slika 10. Licenca, pod katero spada Linux se imenuje GPL licenca verzije 2, kar pomeni, da lahko sistem razširjamo, razmnožujemo, spreminjamo, prilagajamo in izboljšujemo. Vse to lahko počnemo pod pogojem, da so vse spremembe, izboljšave ali nadgradnje izdane pod GPL licenco (Globačnik, 2007, str. 11). Blažka Globačnik: Model oblačnih storitev z OpenStack stran 19

26 Slika 10: Sestava programskega jedra Linux (vir: prirejeno po dokumentaciji GNU/Linux) GNU/Linux sestavljajo kernel in večja množica knjižnic in storitev, ki, zanašajoč na kernel, omogočajo interakcijo med uporabniki, kar prikazuje slika 11. Operacijski sistem GNU/Linux je na voljo v več različnih distribucijah, ki za delovanje uporabljajo specifična jedra in programje. Med priljubljene distribucije se štejejo: Arch, CentOS, Debian, Fedora, opensuse, Red Hat, Ubuntu idr (Smith, 2012, str. xvii-9). Slika 11: Sestava operacijskega sistema GNU/Linux (vir: prirejeno po dokumentaciji GNU/Linux) Blažka Globačnik: Model oblačnih storitev z OpenStack stran 20

27 5 RAČUNALNIŠKA OMREŽJA Slovensko društvo informatika (2014a) prevaja angleški termin»networking«kot»načrtovanje, izgradnja in uporaba omrežja, ki vključuje fizični nivo, kot so povezave, stikala, usmerjevalniki ter prenosne protokole, nadzorne sisteme in vzpostavitev obratovalnih politik«. Za razumevanje te definicije, pa je treba prvo definirati kaj omrežje (ang. network) je. Omrežje lahko razumemo kot povezavo dveh ali več sistemov za izmenjavo podatkov in lažjo komunikacijo. Poznamo več vrst povezovanja, npr. povezujemo sisteme direktno med seboj (računalnik tiskalnik), ali pa uporabljamo različne razdelilnike in vozlišča. Sistemi, ki se povezujejo s pomočjo razdelilnikov in vozlišč, se povezujejo v LAN (ang. local area network), MAN (ang. metropolitan area network) ali WAN (ang. wide area network) omrežja. V LAN oz. lokalnem omrežju so naprave medsebojno povezane na majhnem geografskem območju (npr. v stanovanjih, v pisarnah ipd.), medtem ko MAN oz. mestno omrežje povezuje sisteme na večjem geografskem območju. WAN oz. prostrano omrežje pa omogoča povezave sistemov na večjem geografskem območju (npr. čezmejne, regijske povezave) (Ciccarelli & Faulkner, 2004, str. 1-8). Ko govorimo o prostranih omrežjih najprej pomislimo na svetovni povezovalni sistem, internet. Internet omogoča povezavo različnih omrežij s pomočjo standardnega internetnega protokola TCP/IP. Za boljše razumevanje delovanja omrežij, je treba podrobneje spoznati pojme, kot so IP naslov, podomrežja, prefix in gateway. V nadaljevanju bomo predstavili pojme, ki so pomembni tako za razumevanje omrežij kot za samo nastavitev le-teh. 5.1 IP naslov IP naslov je logični naslov omrežnega vmesnika nekega sistema, pri katerem poteka komunikacija skladno s protokolom TCP/IP. Edinstven IP naslov gradi 32 bitov, ki so razdeljeni na 2 dela, in sicer: omrežni (ang. network) del in vozliščni (ang. host) del. Omrežni del se uporablja za usmerjanje podatkovnih paketov med omrežji, vozliščni del pa določa lokacijo sistema v omrežju. Na voljo je več razporeditev IP naslovov, in sicer glede na število bitov, ki so v omrežnem delu in število bitov, ki so v vozliščnem delu. Tabela 1 prikazuje razporeditev IP naslovov glede na število bitov (Ciccarelli & Faulkner, 2004, str. 203; Tanenbaum & Wetherall, 2011, str. 442). Blažka Globačnik: Model oblačnih storitev z OpenStack stran 21

28 Tabela 1: Razporeditev IP naslovov glede na število bitov. (vir: Ciccarelli & Faulkner, 2004, str. 203) Razred IP naslovi Omrežni del [bit] Vozliščni del [bit] A B C D E IP Prefix IP Prefix je predpona oz. določeno število bitov v omrežnem delu IP naslova. IP naslovi so v osnovi zapisani v s piko ločenih decimalnih blokih, kar pomeni, da je vsak blok 4 bitov zapisan s številom od 0 do 255. Na primer, šestnajstiško zapisani IP naslov 80D00297 lahko decimalno zapišemo Če prefix vsebuje 2 8 naslovov, potem v omrežnem delu ostaja še 24 bitov, in IP naslov se zapiše: /24 (Tanenbaum & Wetherall, 2011, str. 443). 5.3 Subnet Subnet oz. po definiciji Slovenskega društva informatika se podomrežje razume kot»del omrežja, lahko fizično samostojen segment, ki si z drugimi deli omrežja deli omrežni naslov, loči pa se po številki podomrežja«(slovensko društvo Informatika, 2014c). IP naslovi, predvsem razredov A in B, se navadno delijo v manjša omrežja, t. i. podomrežja. Za izgradnjo podomrežij administrator uporabi vozliščni del IP naslova. Tako se ustvari podomrežna maska (ang. subnet mask) (Ciccarelli & Faulkner, 2004, str. 204), ki je po definiciji»bitna maska, ki označuje, kateri biti v naslovu IP ustrezajo omrežnemu naslovu«(slovensko društvo informatika, 2014b). Sama sestava IP naslova podomrežij je naslednja: <omrežni del><podomrežni del><vozliščni del> (Ciccarelli & Faulkner, 2004, str. 204), kar na primeru razreda C podrobneje prikazuje slika 12. Slika 12: Primer statičnega podomrežja v povezavi z IP naslovom C razreda (Vir: Ciccarelli & Faulkner, 2004, str. 204) Blažka Globačnik: Model oblačnih storitev z OpenStack stran 22

29 5.4 Gateway Gateway ali prehod je medomrežni sistem za združevanje dveh ali več omrežij, ki za delovanje uporabljajo različne protokole. Uporaba prehodov je težko namestiti in konfigurirati, hkrati pa tudi upočasni delovanje omrežja. V splošnem prehodi delujejo na tri načine, in sicer (Ciccarelli & Faulkner, 2004, str. 169): povezovanje omrežij, ki uporabljajo iste protokole ter različne storitve za upravljanje s sporočili, povezovanje omrežij, ki uporabljajo različne protokole, s prevajanjem protokola prihajajočega vira, s prevajanjem spletnega formata za elektronsko pošto v format, ki ga strežnik lahko razume. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 23

30 6 OPENSTACK Fundacija OpenStack (kot projekt lansirana leta 2010, s strani podjetij NASA in Rackspace (Baun, Kunze, Nimis, & Tai, 2011, str. 55)) verjame v odprto kodo, odprte dizajne, odprt razvoj in odprto skupnost za sodelovanje. Dolgoročna vizija fundacije je ustvariti odprtokodno oblačno računalniško platformo, ki zadosti vsem zahtevam javnih in zasebnih oblakov različnih velikosti (Fifield, in drugi, 2014, str. xv). Projekt OpenStack je globalno sodelovanje razvijalcev in tehnologov računalništva v oblaku za razvoj odprtih standardiziranih javnih in zasebnih oblačnih platform (OpenStack, 2013, str. 4). Tehnologijo OpenStack lahko uporabljajo različna podjetja, ponudniki storitev, raziskovalci, ponudniki podatkovnih centrov ipd. (OpenStack Grizzly, 2014). OpenStack uporabljajo podjetja in združbe, kot so: PayPal, Cisco WebEx, CERN, Harvard University, Intel, IBM, Sierra Wireless, SUSE, CloudUp, Sony Network Entertainment idr (OpenStack UserStories, 2014). 6.1 Predstavitev tehnologije OpenStack OpenStack je skupek odprtokodnih tehnologij, ki zagotavljajo močno prilagodljivo programsko opremo v oblačnih storitvah (OpenStack Grizzly, 2014, str. 1). OpenStack je oblačni operacijski sistem za nadzor velikih bazenov procesov, skladišč in mrežnih virov, ki ga izvaja s pomočjo podatkovnih središč in nadzorne plošče (OpenStack, 2013, str. 4). Je odprtokodna platforma, ki omogoča izgradnjo oblačne arhitekture kot storitev (IaaS) (Fifield, in drugi, 2014) Komponente tehnologije OpenStack OpenStack povezuje 5 storitvenih stebrov, ki omogočajo lažje delo z oblakom. Stebri, ki združujejo različne komponente se imenujejo (OpenStack Software, 2014): Compute (sl. procesiranje), Object Storage (sl. skladišče objektov) in Block Storage (sl. skladišče blokov), Network (sl. omrežje), Dashboard (sl. pregledna plošča) in deljene storitve (identiteta, slike, telemetrija, orkestracija). Teh 5 storitev pa predstavlja 7 najpomembnejših komponent tehnologije OpenStack. Komponente tehnologije OpenStack so naslednje (OpenStack Grizzly, 2014, str. 2-3): Object Storage (sl. pomnilnik objektov; razvojno ime»swift«), Image (sl. storitev za slike; razvojno ime»glance«), Compute (sl. procesiranje; razvojno ime»nova«), Blažka Globačnik: Model oblačnih storitev z OpenStack stran 24

31 Dashboard (sl. pregledna plošča; razvojno ime»horizon«), Identity (sl. identifikacija; razvojno ime»keystone«), Network (sl. omrežje; razvojno ime»quantum«) in Block Storage (sl. blokovno skladišče; razvojno ime»cinder«). Pomnilnik objektov razpolaga s skladiščem objektov, ki omogoča shranjevanje in pridobitev datotek. Storitev za slike (ang. image) zagotavlja katalog in bazo slik virtualnih diskov, ki so najpogosteje uporabljeni v komponenti procesiranja. Komponenta procesiranje zagotavlja virtualne strežnike na zahtevo. Pregledna plošča predstavlja modularni spletni uporabniški vmesnik za vse OpenStack storitve. S pomočjo spletnega GUI-ja lahko uporabnik izvede večino operacij v oblaku. Identifikacija omogoča overjanje in avtorizacijo vseh storitev. Hkrati pa zagotavlja katalog storitev znotraj določenega oblaka. Omrežje zagotavlja»omrežno povezavo kot storitev«med vmesniki, ki jih upravljamo s pomočjo komponente Compute (Nova). Storitev deluje tako, da uporabniku dovoli ustvariti lastno omrežje in temu priključi različne vmesnike. Blokovno skladišče zagotavlja nenehno skladiščenje podatkov gostov virtualnih strojev (OpenStack Grizzly, 2014, str. 2-3) Konceptualna arhitektura Tehnologija OpenStack je kot celota zasnovana za zagotavljanje močno razširljivega oblačnega operacijskega sistema. Za dosego le-tega cilja so vse storitve namenjene medsebojni podpori in delovanja v sožitju, kar omogoča zagotavljanje popolne IaaS storitve. To povezovanje je omogočeno prek programskih vmesnikov (ang. API), ki jih zagotavlja vsaka storitev (in ji lahko tudi uporabi), kar uporabnikom dovoljuje preskakovanje iz ene v drugo storitev (OpenStack Grizzly, 2014, str. 3). Pri predpostavki, da uporabnik storitev uporablja vse storitve hkrati in najosnovnejšo konfiguracijo oblaka, bi bila shema delovanja naslednja: Pregledna plošča predstavlja spletni vmesnik in omogoča prikaz ostalih storitev. Komponenta procesiranja shranjuje navidezne diske (t. i. slike) in pridobiva omrežje preko komponente omrežja Prostor za shranjevanje omogoča blokovno skladišče. Storitev za slike omogoča shranjevanje dejanskih virtualnih diskovnih datotek v pomnilnik objektov. Vse prej naštete storitve pa se dostopne pooblaščenim uporabnikom, ki jih upravljamo s storitvijo identitete (OpenStack Grizzly, 2014, str. 4). Konceptualno arhitekturo tehnologije OpenStack predstavlja slika 13. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 25

32 Slika 13: Prikaz konceptualne arhitekture tehnologije OpenStack (Vir: povzeto po OpenStack Grizzly, 2014, str. 4) Koncept skladišč Sistem skladišč tehnologije OpenStack lahko najdemo v različnih nivojih same tehnologije. Obstajajo tri vrste skladišč, in sicer (OpenStack Grizzly, 2014, str. 10): kratkotrajno, blokovno in objektno skladišče. Objektno skladišče tehnologije OpenStack se ne uporablja kot klasični trdi disk. Objektno skladišče skrbi za omilitev nekaterih omejitev datotečnega sistema POSIX (ang. portable operating system interface) (OpenStack Grizzly, 2014). Blokovno skladišče omogoča prikaz blokovnih naprav uporabniku, ki komunicirajo z blokovnim skladiščem s pomočjo instanc. Blokovna skladišča ostanejo nedotaknjena, četudi jih prestavljamo iz ene instance na drugo (Fifield, in drugi, 2014, str. 48). Nadaljnje razlike med tremi vrstami skladišč predstavlja tabela 2. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 26

33 Lastnost Uporaba Tabela 2: Vrste skladišč tehnologije OpenStack (vir: OpenStack Grizzly, 2014, str ; Fifield, in drugi, 2014, str. 47) Delovanje Skladišče Dostopno iz Dostop / namestitev Velikost Primer Upravljan skozi Kratkotrajno skladišče Uporabljen za tek operacijskega sistema Deluje do uničenja virtualnega stroja Dostop možen z uporabo virtualnega stroja Vgrajen kot datotečni sistem Administrator določi velikost glede na želje Prvi disk 10 GB, jedrni drugi disk 30 GB OpenStack Compute (Nova) Blokovno skladišče (Cinder) Uporabljen za dodajanje dodatnih skladišč v virtualne stroje Deluje do izbrisa skladišča Dostop možen z uporabo virtualnega stroja Montiran s pomočjo protokola za OpenStack blokovna skladišča (npr. iscsi) Velikost odvisna od potrebe 1 TB»trdega diska«openstack Block Storage (Cinder) Objektno skladišče (Swift) Uporabljen za shranjevanje slik virtualnih strojev in podatkov Deluje do izbrisa skladišča Neodvisen dostop REST API Velikost je preprosto prilagodljiva 10 S od TBs skladišča za nabor podatkov OpenStack Object Storage (swift) Koncept procesiranja (Compute) Komponenta procesiranje oz. z razvojnim imenom imenovana Nova predstavlja bistvo OpenStack-a (OpenStack Grizzly, 2014, str. 6). Ta komponenta omogoča organizacijo oblaka (delovanje instanc, upravljanje z omrežji, upravljanje z dostopi do oblaka ipd.). OpenStack Compute ne vključuje programja za virtualizacijo, temveč definira gonilnike, ki komunicirajo z osnovnimi virtualizacijskimi mehanizmi, ki tečejo na operacijskem sistemu gostitelja (OpenStack Grizzly, 2014, str. 12). Za delovanje virtualnih strojev sodeluje večje število procesov, katerih glavni moduli so zapisani v programskem jeziku Python (OpenStack Grizzly, 2014, str. 6). Blažka Globačnik: Model oblačnih storitev z OpenStack stran 27

34 Nadzornik Za delovanje komponente procesiranja je nujen nadzornik, ki se ga nadzira skozi API strežnik. Izbira nadzornika navadno temelji na proračunu in omejitvah sredstev ter seznamu podpornih funkcij in tehničnih specifikacij. Za razvoj tehnologije navadno uporabljajo nadzornike, ki so bazirani na KVM (ang. Kernel-based Virtual Machine) in Xen (Xen, Citrix XenServer, Xen Cloud Platform (XCP)) tehnologijah (OpenStack Grizzly, 2014, str. 12). Uporabniki in najemniki Sistem lahko uporabljajo različni uporabniki in najemniki tako, da se jim določi vloga, ki jim omogoča dostop do različnih storitev. Dostop uporabnika do določene točke je odvisen od najemnika, uporabniško ime in geslo pa se določa vsakemu uporabniku posebej. Najemniki so osamljeni kontejnerji virov, ki formirajo osnovno organizacijsko strukturo znotraj komponente procesiranja. Najemnike sestavljajo ločeni VLAN, logične enote, instance, slike, ključi in uporabniki (OpenStack Grizzly, 2014, str ). Slike in instance Slike so posnetki diskov, ki predstavljajo predloge datotečnih sistemov virtualnih strojev. Storitev slik, Glance, je odgovorna za shranjevanje in upravljanje s temi posnetki. Instance so samostojni virtualni stroji, ki so upravljani s strani komponente procesiranja Nova. Iz ene slike lahko nastane večje število instanc, saj instance nastanejo kot kopija osnovne slike. Pri pripravi instanc je treba določiti set virtualnih virov (t. i. arom, ang. flavor), ki definirajo koliko virtualnih CPU-jev, količino RAMa in velikost kratkotrajnega diska neki virtualni stroj potrebuje. OpenStack omogoča uporabo različnih predlog (setov virov), ki jih je možno poljubno urejati in spreminjati (OpenStack Grizzly, 2014, str ). Sistemska arhitektura OpenStack Compute (komponenta procesiranje) je sestavljena iz več glavnih komponent, in sicer: nadzornik oblaka, API strežnik, nadzornik procesiranja, objektno skladišče, storitev identifikacije, nadzornik omrežja in načrtovalec. Nadzornik oblaka predstavlja globalno stanje in komunicira z ostalimi komponentami. API strežnik deluje kot spletni vmesnik za nadzornika oblaka. Nadzornik procesiranja omogoča vire procesnih strežnikov. Objektno skladišče navadno skrbi za storitve skladiščenja. S pomočjo storitve identifikacije vodja avtorizacije poskrbi za preverjanje istovetnosti in avtorizacijo uporabnikom. Nadzornik omrežja skrbi za virtualna omrežja in omogoča procesnim strežnikom medsebojno komunikacijo in komunikacijo z javnim omrežjem. Načrtovalec pa poišče najprimernejši prostor za nastajajočo instanco (OpenStack Grizzly, 2014, str. 16). OpenStack Compute uporablja asinhrone klice in za interno komuniciranje uporablja HTTP (ang. hyper text transfer protocol) protokol, vendar pa za komunikacijo z Blažka Globačnik: Model oblačnih storitev z OpenStack stran 28

35 načrtovalcem, nadzornikom omrežja in nadzornikom obstojnih nosilcev datotek komunicira s pomočjo AMQP (ang. advanced message queue protocol) (OpenStack Grizzly, 2014, str. 16). Blokovno skladišče OpenStack omogoča 2 razreda blokovnega skladišča, in sicer: kratkotrajno skladišče (ang. ephemeral storage) in obstojne nosilce datotek (ang. persistent volumes). Kratkotrajno skladišče, katerega velikost je vezana na izbiro arome, je vezano na eno samo instanco, obstaja tako dolgo, dokler obstaja matična instanca. Obstojni nosilci datotek so blokovne naprave in so neodvisne od instanc, vendar pa je en nosilec lahko priključen na eno instanco, kjer deluje kot zunanji disk (OpenStack Grizzly, 2014, str ) Koncept omrežja (Network) OpenStack Network je na API-ju baziran vtičnik ter prilagodljiv sistem za upravljanje omrežij in IP naslovov. Tako kot drugi vidiki oblačnih operacijskih sistemov lahko omrežje pripomore k povečanju vrednosti obstoječih podatkovnih centrov (OpenStack Networking, 2014). Priprava virtualnih omrežij se izvaja kot priprava klasičnega omrežja. Pri virtualnih omrežjih je treba načrtovati število IP naslovov, ki jih bodo potrebovali uporabniki ter upravljalna infrastruktura (Fifield, in drugi, 2014, str. 55). Fifield in drugi (2014, str. 55) predlagajo, da omrežje za upravljanje z infrastrukturo deluje na ločenem stikalu in omrežni kartici, saj se tako preprečijo motnje v delovanju administratorskega sistema in nadzornega sistema. Avtorji prav tako predlagajo izgradnjo VLAN omrežij za komunikacijo med različnimi vozlišči. Pri pripravi omrežij avtorji prav tako predlagajo plan razvrščanja IP naslovov, in sicer predlagajo razvrstitev, ki jo predstavlja tabela 3. Fifield in drugi (2014, str ) predlagajo, da v primeru največ 100 projektov pri konfiguraciji uporabimo prosto VLAN omrežje. Omrežje komponente Nova ima možnost delovanja v načinu multi-gostovanja ali enojnega gostovanja. Oba načina imata svoje prednosti, vendar pri enojnem gostovanju komunikacije med komponentami ne more potekati, če oblačni nadzornik ni na voljo. To pri multigostovanju ne drži, vendar pa pri le-tem gostovanju potrebujemo javne IP naslove, brez katerih multi-gostovanje ni mogoče. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 29

36 Sektor Usmerjevalnik podomrežij Javni vmesniki za nadzor storitev Medsebojna komunikacija med posameznimi komponentami grozda objektne shrambe Komunikacije med procesi in skladišči Zunanje oddaljeno upravljanje Medobmočno oddaljeno upravljanje Rezervni prostor Tabela 3: Plan razvrščanja IP naslovov (vir: Fifield, in drugi, 2014, str. 56) Opis Paketi, ki zapuščajo podomrežje, gredo čez ta naslov. Javni dostopi do swift-proxy, nova-api, glanceapi uporabljajo te naslove. Komunikacija med objekti ali računi poteka preko tega zasebnega omrežja. Uporaba tega podomrežja poteka kadar so kratkotrajna ali blokovna skladišča zunaj računalniškega vozlišča. Potrebuje se ga, kadar je nadzornik oddaljenega upravljanja vključen v strežnik. Ti naslovi omogočajo administratorju dostop do gostitelja brez uporabe javnih vmesnikov. Dobra izbira za primer širitve storitve Koncept pregledne plošče (Dashboard) Pregledna plošča storitve OpenStack je vgrajena kot spletna aplikacija programskega jezika Python Django, ki teče na Apache strežnikih (Fifield, in drugi, 2014, str. 30). Pregledna plošča omogoča administratorjem in uporabnikom grafični dostop do oblačnih virov. Razširljiva zasnova omogoča enostavno priključitev dodatnih izdelkov ali storitev, kot so orodja za računovodstvo, nadzor in upravljanje (OpenStack Dashboard, 2014). Prav tako je možno spreminjanje pregledne plošče, tako da so primerne za različne strani (OpenStack Icehouse, 2013, str. 11). Blažka Globačnik: Model oblačnih storitev z OpenStack stran 30

37 6.2 Klasična namestitev in konfiguracija V tem poglavju bomo na kratko predstavili teoretično namestitev in konfiguracijo oblačne storitve OpenStack. Ključni projekti sistema OpenStack lahko delujejo vzajemno, vendar pa so namestitve ločene druga od druge (OpenStack Grizzly, 2014, str. 18). V nadaljevanju bomo predstavili namestitev in konfiguracijo v primeru uporabe CentOS distribucije ter stabilne verzije OpenStack Icehouse Arhitektura OpenStack omogoča 2 različni namestitveni arhitekturi, in sicer (OpenStack Icehouse, 2014): tri-vozliščno arhitekturo z vozliščem za mreženje in dvo-vozliščno arhitekturo z vgrajenim mreženjem. Tri-vozliščna arhitektura vsebuje vozlišče za nadzor (ang. controller node), za omrežje (ang. network node) in procesiranje (ang. compute node). Osnovne storitve vozlišča za nadzor so storitve za upravljanje z identitetami, za upravljanje s slikami, storitev za upravljanje procesiranja in mreženje, vtičnik za mreženje in pregledno ploščo. Med podporne storitve so vključene podatkovna baza, komunikacijski posrednik in NTP (ang. network time protocol). Na vozlišču za nadzor lahko tečejo tudi storitve blokovnega skladišča, objektnega skladišča, storitev za podatkovne baze, orkestracija in telemetrija. Vozlišče za mreženje poganja vtičnike za mreženje in agente za raven 2 (omogoča oblikovanje virtualnih omrežij in predorov), raven 3 (omogoča usmerjanje povezav in prevajanje omrežnih naslovov NAT) ter DHCP. To vozlišče tudi skrbi za zunanjo povezavo (internet) za naročnike virtualnih strojev ali instanc. Na vozlišču za procesiranje teče nadzornik procesiranja (privzeto KVM), ki nadzoruje naročnike virtualnih strojev, vtičnik za mreženje in agenta za raven 2, ki vključujejo omrežja naročnikov v varnostne skupine. Pri eni namestitvi je možno naložiti več vozlišč za procesiranje (OpenStack Icehouse, 2014). Slika 14 prikazuje grafični prikaz tri-vozliščne arhitekture. Dvo-vozliščna arhitektura z vgrajenim mreženjem nima posebnega vozlišča za mreženje, temveč vsebuje samo vozlišče za nadzor in vozlišče za procesiranje. Osnovne storitve vozlišča za nadzor so storitve za upravljanje z identitetami, za upravljanje s slikami, storitev za osnovno upravljanje procesiranja in pregledna plošča. Podporne storitve so podatkovna baza, komunikacijski posrednik in NTP. Med neobvezne storitve so vključene blokovno skladišče, objektno skladišče, storitev za podatkovno bazo, orkestracijo in telemetrijo. Osnovne storitve vozlišča za procesiranje vključujejo nadzornika procesiranja (privzeto KVM) in skrb za omrežja naročnikov. Neobvezno lahko na vozlišču za procesiranje teče tudi agent za telemetrijo, ki omogoča dodatne funkcije v OpenStack okolju (OpenStack Icehouse, 2014). Slika 15 prikazuje grafični prikaz dvo-vozliščne arhitekture. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 31

38 Slika 14: Grafični prikaz tri-vozliščne arhitekture (vir: OpenStack Icehouse, 2014) Slika 15: Grafični prikaz dvo-vozliščne arhitekture (vir: OpenStack Icehouse, 2014) Blažka Globačnik: Model oblačnih storitev z OpenStack stran 32

39 6.2.2 Priprava okolja Razvijalci sistema OpenStack kot minimalne zahteve za namestitev priporočajo (OpenStack Icehouse, 2014): za vozlišče za nadzor: 1 procesor, 2 GB pomnilnika in 5 GB prostora; za vozlišče omrežja: 1 procesor, 512 MB pomnilnika, 5 GB prostora; za vozlišče za procesiranje: 1 procesor, 2 GB pomnilnika in 10 GB prostora. Prav tako predlagajo minimalno namestitev 64-bitne Linux distribucije. Po namestitvi operacijskega sistema za vsako vozlišče (2 ali 3) je treba pripraviti omrežne vmesnike. Pri tem je dobro onemogočiti privzeta orodja za upravljanje z omrežji in ročno pravilno konfigurirati distribucijo. V primeru RedHat distribucij so ukazi za onemogočanje orodja za upravljanje z omrežji naslednji: # service NetworkManager stop # service network start # chkconfig NetworkManager off # chkconfig network on OpenStack omogoča 2 različni arhitekturi. Ker je odvisno ali uporabimo vozlišče za omrežje ali ne, bomo nastavitve OpenStack Networking (razvojno ime neutron) in vključenega omrežja (ang. Legacy Networking, razvojno ime nova-network) predstavili skupaj. Razvijalci tehnologije (OpenStack Icehouse, 2014) OpenStack predlagajo naslednji način namestitve. V primeru uporabe vozlišča za omrežje je najprej treba nastaviti omrežje na vozlišču za nadzor in kot prvi vmesnik nastavimo vmesnik za upravljanje (ang. management interface). Nastavimo IP naslov (npr ), omrežno masko (npr ) in privzet prehod (npr ) ter nastavimo ime vozlišča (npr. controller). Nato nastavimo vozlišče za omrežje. Nastavimo prvi vmesnik za upravljanje (IP naslov (npr ), omrežno masko in prehod, nato sledi nastavitev tunelov (povezava med vozliščem za omrežje in procesiranje), kjer nastavimo IP naslov (npr ) ter omrežno masko (npr ). Kot tretji vmesnik nastavimo vmesnik za zunanjo povezovanje. Uredimo datoteko ifcfg-ime_vmesnika z naslednjimi nastavitvami: DEVICE=IME_VMESNIKA TYPE=Ethernet ONBOOT="yes" BOOTPROTO="none" Sledi še ponovni zagon omrežja in dodelitev imena vozlišču (npr. network). Za ponovni zagon omrežja uporabimo ukaz: # service network restart Blažka Globačnik: Model oblačnih storitev z OpenStack stran 33

40 Nato sledi konfiguracija vozlišča za procesiranje. Nastavimo vmesnik (IP naslov npr ) za upravljanje, nato nastavimo tunele ter določimo ime vozlišča (npr. compute1). Po nastavitvi preverimo povezljivost - preko vseh vozlišč»pingamo«dodeljene IP naslove (spletno stran in imena vozlišč). V primeru uporabe že vključenega mreženja (dvo-vozliščna arhitektura) postopamo tako kot pri konfiguraciji tri-vozliščne arhitekture, vendar izpustimo konfiguracijo vozlišča za omrežje. Ne glede na to, ali uporabimo dvo- ali tri-vozliščno arhitekturo je treba omogočiti NTP na vsa vozlišča, saj le-ta omogoča sinhronizacijo storitev na več strojih hkrati. Najprej namestimo NTP paket, nato nastavimo NTP strežnik na vozlišču za nadzor ter ponovno zaženemo storitev. Ukazi za namestitev in nastavitev so naslednji: # yum install ntp # service ntpd start # chkconfig ntpd on V nadaljevanju nastavimo gesla za bazo podatkov in komunikacijski strežnik. V konfiguraciji IceHouse OpenStack za RedHat distribucije se uporablja MySQL, ki teče na vozlišču za nadzor. Na vozlišče za nadzor je tako treba namestiti MySQL (klienta, strežniške pakete in knjižnico Pythona za to bazo), na ostala vozlišča pa knjižnico MySQL Python. Po nastavitvi baz podatkov prenesemo in namestimo pakete OpenStack ter ponovno zaženemo sistem. Zadnji korak priprave okolja je namestitev strežnika za sporočilne vrste. OpenStack omogoča uporabo različnih posrednikov sporočil (MQ, message queuing) kot so RabbitMQ, Qpid, ZeroMQ, vendar pa vsaka Linux distribucija navadno privzeto podpira točno določene komunikacijske posrednike. Razvijalci tako za RedHat distribucije priporočajo Qpid. Z namestitvijo in nastavitvijo MQ posrednika se zaključi osnovna priprava okolja in se lahko začne nalaganje storitev OpenStack Najpogostejše težave in napake Med najpogostejše težave pri namestitvi in uporabi OpenStack so napake, povezane s spletnimi storitvami. Med te težave se štejejo težave z avtorizacijo uporabnikov. To so napake 40x (napake od 400 do 409). Napaka 400 pomeni, da storitev za upravljanje z identitetami ne more pravilno razčleniti zahteve, zaradi napačnih ali pomanjkljivih atributov. Pri prikazu napake 401 so navadno napačno vpisani podatki za avtorizacijo in avtentikacijo. Napaka 403 pa predstavlja t. i. prepovedano napako, ki nastane zaradi manjkajočih podatkov za avtentikacijo uporabnika. Obe napaki sta rešljivi s pomočjo pregleda datoteke novarc, vendar pa se lahko težave pojavijo tudi pri pripravi le-te datoteke. Zato je treba v primeru napak 40x preveriti tudi nastavitve posredovalnega strežnika (ang. proxy). Prav tako je pogosta napaka pomeni, da storitvi ni uspelo najti želene entitete zaradi pomanjkljivega identifikacijskega zapisa (ID). Pogoste napake so tudi napake 50x (od 500 do 509), kar pomeni, da se je zgodila napaka, ki preprečuje dostop do želene storitve ali pa je prišlo do napake, Blažka Globačnik: Model oblačnih storitev z OpenStack stran 34

41 kjer storitev napačno razume zahtevo in samodejno preneha delovati. Napaka 500 tako pomeni, da se je pojavila napaka pri namestitvi storitve za upravljanje z identitetami - storitev moramo ponovno namestiti. Zelo pogosta napaka 501, kjer storitev za upravljanje z identitetami ni sposobna izpolniti zahteve zaradi pomanjkljive namestitve programskega vmesnika (ang. API). Ena pogostejših napak je prav tako napaka 503, ki se pojavi, kadar storitev za upravljanje z identitetami ni dosegljiva. Najboljša rešitev za napake vrednosti 50x je ponovni zagon vseh storitev (OpenStack Grizzly, 2014; Jackson, 2014; OpenStack Idnetity API v3, 2014). Ena izmed pogostejših težav pri sami namestitvi sistema je težava z namestitvijo paketov na vozlišče za procesiranje, in sicer sistem ne najde najpomembnejših paketov za delovanje vozlišča (slika 16). Težavo je mogoče odpraviti tako, da administrator ponovno namesti repozitorije RDO in EPEL (Install openstack-novacompute problem, 2014). Slika 16: Težave pri namestitvi paketov na vozlišče za procesiranje (vir: Install openstack-nova-compute problem, 2014) Pogosto se pojavi tudi težava pri odpiranju pregledne plošče. Uporabniški vmesnik javi napako»something went wrong!«. Pri takšni splošni težavi je dobro pregledati dnevnik delovanja (ang. log). Eden izmed pogostih zapisov opisuje napako pri konfiguraciji strežnika. Pri takšni napaki je treba preveriti konfiguracijo datoteke local_settings, in sicer vpise glede shranjevanja v predpomnilniku (ang. cache) ter IP naslove dovoljenih gostiteljev sistema (OpenStack Icehouse, 2014). Kljub pogostim napakam in težavam ob namestitvi in samem delovanju sistema, pa je rešitve razmeroma enostavno poiskati, saj skupnost OpenStack skrbi za sprotno objavo vseh rešitev za različne težave in napake. Prav tako deluje tudi forum skupnosti, kjer številni moderatorji in administratorji skrbijo za hitre in natančne opise težav ter rešitev le-teh napak. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 35

42 6.3 Razpoložljivost sistema Sistem za zagotavljanje visoke razpoložljivosti omogoča zmanjšanje časa izpadov sistema ter izgube podatkov zaradi nenamernega izbrisa oz. uničenja le-teh. Večina sistemov za zagotavljanje visoke razpoložljivosti zagotavlja zaščito pred izpadi sistemov in izgubo podatkov samo pri eni napaki in ne pri več napakah hkrati. Najpomembnejši vidik visoke razpoložljivosti sistema je zmanjšanje izpadov sistemov zaradi kritične točke odpovedi (ang. SPOF, single point of failure). Zato je treba preveriti ali obstajajo odvečni mehanizmi pri omrežnih komponentah (stikala in usmerjevalniki), pri aplikacijah in storitvah avtomatične selitve sistemov, pri komponentah skladišč in pri osnovni infrastrukturi, kot so električna energija, ventilacija in klimatizacija prostorov ter varovanje pred požari. OpenStack zagotavlja 99,99 % razpoložljivost infrastrukturnih storitev, vendar pa enak odstotek ne velja za individualno gostujoče instance (Haas, 2014, str. 1). Preprečevanje kritičnih točk odpovedi je prav tako odvisno od spremenljivosti storitev (spremenljive (ang. stateless) ali stalne (ang. stateful)). Spremenljive storitve so tiste storitve, ki priskrbijo odgovor na poslano zahtevo in ne zahtevajo nobene potrditve. Za izgradnjo spremenljivih storitev visoke razpoložljivosti se potrebne podvojene (redundantne) in uravnotežene instance. Spremenljive storitve OpenStack vključujejo nova-api, nova-conductor, glance-api, keystone-api, neutron-api in novascheduler. Stalne storitve so tiste storitve, ki pošljejo zahtevo storitvi glede na zahtevo, ki so jo prejele. Stalne storitve je težje upravljati, predvsem zaradi večjega števila zahtev, ki se izvedejo za eno samo operacijo. OpenStack stalne storitve uporablja pri bazi podatkov OpenStack in sporočilne vrste (ang. message queue). Visoka razpoložljivost stalnih storitev pa je velikokrat odvisna od konfiguracije sistema, ki je lahko aktivna/pasivna ali aktivna/aktivna (Haas, 2014, str. 1-2). Pri aktivno/pasivni konfiguraciji sistemov se viri dodatno shranjujejo na spletu in se v primeru izgube matičnih virov lahko uporabijo za obnovitev stanja po katastrofalnih dogodkih. Navadno se pri aktivno/pasivni konfiguraciji spremenljivih storitev viri zapisujejo v odvečne instance, ki jih lahko poljubno shranimo. Pri aktivno/pasivni konfiguraciji stalnih storitev pa le-te storitve skrbijo za varnostne kopije, ki se lahko dodatno varujejo s pomočjo ločenih aplikacij (npr. Pacemaker) in jih tako shranjujemo na spletu. OpenStack aktivno/pasivno konfiguracijo uporablja pri skupinah oblačnega nadzornika, API vozlišča, nadzornika omrežja in Pacemakerja. Pri aktivno/aktivni konfiguraciji sistem ustvarja varnostne kopije, vendar hkrati upravlja tako z glavnimi viri kot z varnostnimi kopijami, kar omogoča nemoteno delovanje sistema, saj uporabnik navadno ne opazi nobenih težav pri delovanju sistema. Varnostne kopije se pri tem sistemu samodejno shranjujejo na spletu in v primeru okvare glavnih virov samodejno tečejo s spleta, dokler glavni viri niso popravljeni. Pri tipični aktivno/aktivni konfiguraciji za stalne storitve so vse instance (glavne in varnostne) identične. V primeru nadgradnje ene instance, se bodo samodejno nadgradile tudi ostale instance, kar pomeni, da so zahteve za vse instance enake in za delovanje ne potrebujejo dodatnih zahtev. Aktivno/aktivno konfiguracijo Blažka Globačnik: Model oblačnih storitev z OpenStack stran 36

43 OpenStack uporablja pri konfiguraciji podatkovne baze, agentu za komuniciranje, Haproxy vozlišču, vozliščih za nadzor in omrežnih vozliščih (Haas, 2014). 6.4 Primeri dobre prakse V tem poglavju bomo na kratko predstavili štiri primere dobrih praks, ki uporabljajo različne vrste oblakov ponudnika OpenStack. Predstavili bomo Intel, ki uporablja odprt zasebni oblak ter CERN, ki uporablja hibridni oblak, in Cisco WebEx, ki uporablja zasebni oblak, ter enovace, ki uporablja javni oblak (OpenStack UserStories, 2014) Intel Intel, podjetje s sedežem v Santa Clari v Kaliforniji, se ukvarja z informacijsko tehnologijo in zaposluje približno zaposlenih po celem svetu (Intel Corporation, 2014). Leta 2010 je Intel začel uporabljati prvi zasebni oblak, ki je omogočal varno posredovanje storitev in podatkov uporabnikom. Zaradi želje po večjem uspehu se je Intel odločil za razširitev svojega oblaka s pomočjo odprtokodnih sistemov. S pomočjo OpenStack-a so tako ustvarili odprti zasebni oblak, ki je izboljšal posredovanje storitev, in je hkrati temelj oblačnega sistema v podjetju Intel. Podjetje uporablja odprti oblak, saj so uporabniki le-tega zahtevali dostop do virov in podatkov tako od doma kot tudi na delovnem mestu. Za izgradnjo hibridnega oblaka so uporabili OpenStack Compute, OpenStack Storage, OpenStack Dashboard, OpenStack Image Service, OpenStack Block Storage, OpenStack Network, Openstack Identity Service in Telemetry Service Ceilometer. Podjetje pravi, da so s pomočjo oblačnih storitev skrajšali čas posredovanja storitev in poskrbeli za samodejno reševanje manjših težav. Prav tako pravijo, da s pomočjo oblaka ponujajo bogatejše in uporabniku prijaznejše storitve, ki so temeljne storitve vrhunskih razvijalcev programskega orodja (Intel Uses OpenStack, 2013) CERN CERN je evropska organizacija za nuklearno raziskovanje, ki se ukvarja s temeljnimi vprašanji o strukturi vesolja (CERN, 2014). Zaradi velikega števila podatkov, ki so nujni za analize in izdelovanje modelov, v podatkovnem centru v Ženovi teče strežnikov z trdimi diski, ki shranjujejo več 100 PB podatkov. Zaradi preseženega limita pri shranjevanju podatkov in ohlajevanju strežnikov je organizacija postavila nov podatkovni center v Budapešti, vendar pa tudi le-ta ni predstavljal dobre rešitve za rastoče število shranjenih podatkov. Po raziskovanju in testiranju različnih možnosti, so leta 2011 začeli sodelovati z OpenStack organizacijo, katere sistem je dovolj fleksibilen in se je uspešno prilagodil vsem zahtevam organizacije. Za izgradnjo oblaka so uporabili Scientific Linux (operacijski sistem, ki temelji na RedHat distribuciji in sta ga razvila CERN in Fermilab) ter komponente Compute, Image, Identity in Dashboard. S pomočjo oblaka lažje Blažka Globačnik: Model oblačnih storitev z OpenStack stran 37

44 obvladujejo milijone IP naslovov, DNS vnose, certifikate ipd. Leta 2012 je organizacija začela z dvoletno nadgradnjo LHC (ang. Large Hadron Collider). Uporabljajo nadzornike OpenStack, storitev za preverjanje pristnosti, dve vozlišči za procesiranje in vozlišče za storitev slik. Za izgradnjo podatkovnih baz so uporabili MySQL, za komuniciranje RabbitMQ ter za nadzornika KVM. V CERNu uporabljajo večje število oblakov (kot del storitev OpenStack) za rekonstrukcijo trkov delcev (CERN Uses OpenStack, 2013) Cisco WebEx Cisco WebEx, podjetje s sedežem v San Jose v Kaliforniji, se ukvarja z informacijskimi tehnologijami in zaposlujejo več zaposlenih. Vse od ustanovitve podjetja leta 1996, podjetje pomaga pri ustvarjanju SaaS produkta za zagotavljanje aplikacij preko interneta. Danes podjetje ponuja aplikacije za spletne konference, takojšno komuniciranje, družbeno programje za podjetja idr. Pri gradnji oblačne arhitekture so razvijalci stremeli k odprti in API uporabljajoči platformi, ki bo agilna, prožna in razpoložljiva. Pomembno jim je tudi bilo, da ima ponudnik veliko in odprto skupnost, ki lahko pomaga pri reševanju različnih težav. Zaradi pomembnosti delovanja njihove storitve se je podjetje odločilo za zasebni oblak. Ekipa razvijalcev je tako namestila OpenStack Essex s komponentami Compute, Network, Identity Service, Block Storage, Dashboard in Image Service. Quelle (razvijalec v WebEx) je zapisal:»in ta oblak smo uspeli namestiti kot da bi bil javni oblak, vendar imamo poln nadzor in prednosti zasebnega oblaka«(cisco WebEx Uses OpenStack, 2013) enovance enovance, podjetje s sedežem v Parizu, se ukvarja z informacijskimi tehnologijami, natančneje so ponudniki oblačnih storitev. Podjetje se predstavlja kot pionir na področju odprtokodnega računalništva v oblaku in kot strokovnjaki za upravljanje z multi-oblaki. Za zagotavljanje hibridnih oblakov so se odločili za izgradnjo lastnega javnega oblaka s pomočjo OpenStack. Za OpenStack je to pomenilo izgradnjo prvega javnega oblaka v Evropi. Za pripravo le-tega so uporabili komponente Compute, Dashboard, Image Service, Object Storage, Identity Service in Ceilometer. Ker je bil leta 2011 OpenStack še neznana tehnologija, se je enovance odločil za predstavitev le-te tehnologije in hkrati tudi obvestil javnost, da bo lansiral beta verzijo javnega oblaka. Za testiranje oblaka se je javilo 60 podjetij iz različnih panog, ki so testirale ter pomagale pri izboljšanju samega oblaka. Danes je enovance najpomembnejši ponudnik oblačnih storitev na francoskih tleh (enovace Uses OpenStack, 2013). Blažka Globačnik: Model oblačnih storitev z OpenStack stran 38

45 7 EKSPERIMENT V nadaljevanju bomo predstavili eksperimente, ki smo jih izvedli pri preizkušanju tehnologij OpenStack. V prvi fazi bomo predstavili sistem DevStack, ki nam omogoča enostaven preizkus delovanja OpenStack tehnologije. V drugi fazi pa bomo predstavili namestitev tehnologije OpenStack na fizične računalnike ter izdelavo virtualnih strojev ter izvedli preizkus sistema s pomočjo realnih in imaginarnih podjetij. 7.1 Namestitev in konfiguracija OpenStack v različnih testnih okoljih Sistem OpenStack smo preizkusili s pomočjo sistema DevStack, ki omogoča namestitev celotnega sistema na en stroj oz. vozlišče. Preizkusili smo tudi namestitev sistema na dve vozlišči. Namestitev je potekala v domačem okolju na različnih osebnih računalnikih Namestitev in preizkus sistema OpenStack s sistemom DevStack Za osnovni preizkus delovanja OpenStack-a smo uporabili sistem DevStack. DevStack je skriptna lupina, ki omogoča pripravo razvojnega okolja OpenStack in tudi ni namenjena namestitvi za resno uporabo. Primarno se uporablja za enostavno spoznavanje in preizkušanje razvojnih aplikacij. DevStack smo namestili na računalnik z Intel Q6600 2,4 GHz procesorjem in 8 GB pomnilnika ter 1,8 TB prostora. Kot osnovni operacijski sistem smo namestili Linux distribucijo CentOS 6.5. Slika 17 prikazuje končano namestitev DevStack sistema. Razvidno je, da DevStack določi IP naslov za dostopanje do prijavne strani ter uporabniško ime z geslom. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 39

46 Slika 17: Namestitev sistema DevStack Slika 18 in slika 19 prikazujeta osnovni vmesnik, ki se odpre ob prijavi. Pri prijavi kot administrator (uporabniško ime admin) se primarno odpre zavihek Admin System Panel Overview, ki razpolaga s podatki o projektih na ustvarjenih virtualnih strojih. Pri prijavi kot uporabnik (uporabniško ime demo) se primarno odpre zavihek Project Compute Overview, ki v osnovi prikazuje s koliko instancami, pomnilniki, skladišči razpolagamo. Slika 18: Osnovni vmesnik OpenStack ob prijavi administratorja Blažka Globačnik: Model oblačnih storitev z OpenStack stran 40

47 Slika 19: Osnovni vmesnik OpenStack ob prijavi uporabnika Za delovanje sistema mora administrator najprej ustvariti navidezne diske oz. virtualne stroje. Slika 20 prikazuje princip izdelave navideznega diska. Pri izdelavi se določijo naziv diska, opis, tip, velikost, vir in dostopnost diska. Na sliki lahko vidimo, da obrazec za izdelavo diskov prav tako prikazuje mejne vrednosti pri dovoljeni velikosti in številu diskov. Slika 20: Izdelava navideznih diskov - uporabnik Po izdelavi diska za instanco začnemo s pripravo instance. Pri pripravi instance smo pozorni na zavihek Details, kjer določimo dostopnost, ime, aromo (OpenStack ima na voljo nekaj različnih arom), zaporedno število, zagonski vir instance ter sliko, s katero povemo kaj naj instanca zrcali. Vendar pa ne smemo pozabiti na zavihek Access & Security, kjer določimo primarni ključ za izgradnjo instance. Obrazec za izdelavo instanc prikazuje slika 21. Prav tako, kot pri obrazcu za izdelavo navideznih Blažka Globačnik: Model oblačnih storitev z OpenStack stran 41

48 diskov, obrazec za izdelavo instanc omogoča pregled mejnih vrednosti ter podrobnosti izbrane arome. Slika 21: Izdelava instanc - uporabnik OpenStack omogoča spreminjanje velikosti instance, kar naredimo tako, da spremenimo aromo instance. Slika 22 prikazuje spremembo velikosti iz arome nano na aromo medium. Slika 22: Sprememba velikosti instance z uporabo arom - uporabnik Blažka Globačnik: Model oblačnih storitev z OpenStack stran 42

49 V nadaljevanju smo izdelali kopijo instance. Kopija instance oz. izdelava slike se izdela tako, da izberemo meni Images in poiščemo gumb Create Images. Sistem nato vpraša katero instanco želimo spremeniti v sliko ter zahteva novo ime slike. Po izdelavi slike se v vmesniku pojavijo podrobnosti izdelane slike (slika 23), ki jo moramo pred uporabo zagnati. Po zagonu slike lahko izdelamo instanco, ki je kopija prej izdelane instance (katere tehnične podrobnosti, smo shranili v sliko). Pregled poskusno izdelanih instanc prikazuje slika 24. Slika 23: Podrobnosti izdelane slike - uporabnik Slika 24: Pregled izdelanih instanc - uporabnik Namestitev na 2 fizična stroja Stabilno verzijo OpenStack Icehouse smo namestili na 2 fizična računalnika z naslednjo konfiguracijo: Intel Q6600 2,4 GHz z 8 GB pomnilnika ter 1,8 TB prostora, Pentium dualcore atom N330 z 2 GB pomnilnika ter 750 GB prostora. Kot osnovni operacijski sistem smo naložili CentOS 6.5. Vsak računalnik predstavlja svoje vozlišče OpenStack sistema. Odločili smo se za dvo-vozliščno arhitekturo, kar pomeni, da smo namestili in konfigurirali vozlišča compute in controller. Pri dvovozliščni arhitekturi se omrežje vzpostavi s pomočjo dedovanega omrežja (ang. legacy networking) in ne s storitvijo omrežja (razvojno ime neutron). Slednje se uporablja pri tri-vozliščni arhitekturi. Po namestitvi upravitelja omrežja (ang. network manager) in nastavitvah IP naslovov in prehodov smo preverili dosegljivost vozlišč. Najprej smo preverili dosegljivost oz. povezljivost vsakega vozlišča s Blažka Globačnik: Model oblačnih storitev z OpenStack stran 43

50 svetovnim spletom, nato smo preverjali povezljivost vozlišč med seboj. Za preverjanje povezljivosti smo uporabili ukaz ping c 4 [ime], pri čemer smo [ime] zamenjali z imenom vozlišča in URL naslovom. Slika 25 prikazuje preverjanje dosegljivosti, ki smo ga izvedli na vozlišču compute. Slika 25: Preverjanje dosegljivosti vozlišča Compute Po pripravi omrežij sledi priprava baze podatkov, ki jo namestimo na vozlišče Controller. Namestimo MySQL, MySQL strežnik in knjižnico MySQL Python. Namestitev na vozlišče Controller poteka z ukazom: # yum install mysql mysql-server MySQL-python. V nadaljevanju uredimo datoteko my.cnf, kjer nastavitvam dodamo IP naslov vozlišča, ki omogoča dostop do drugih vozlišč, ter ključe, ki omogočijo uporabo nabor znakov UTF-8. Sledi odstranjevanje anonimnih uporabnikov in nastavitev glavnih gesel za dostopanje do baze. Za delovanje obeh vozlišč je treba na vozlišče Compute namestiti knjižnico MySQL Python. V nadaljevanju na vsa vozlišča namestimo pakete OpenStack. V prvi fazi namestimo vtičnike za določanje prioritet (yum-plugin-priorities plug-in), nato repozitorij RDO. Sledi namestitev paketov EPEL (ang. extra packages for enterprise Linux) ter pomožnih programov, ki olajšajo namestitev in konfiguracijo sistema. V drugi fazi preverimo nadgradnje za pakete, jih namestimo ter nato izvedemo ponovni zagon vozlišč. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 44

51 Sledi namestitev druge podporne storitve na vozlišču Controller, in sicer namestitev posrednika sporočil. Operacijski sistem CentOS privzeto podpira namestitev posrednika Qpid. Zaradi lažje namestitve in konfiguracije okolja smo v datoteki qpidd.conf izklopili avtorizacijo. Z namestitvijo posrednika sporočil se zaključi osnovna namestitev in priprava OpenStack okolja. V nadaljevanju sledi namestitev različnih storitev, kot so storitev identitete, slik, procesiranja, pregledne plošče ipd. Konfiguracija storitve za upravljanje z identitetami (Identity Service) Storitev upravljanja z identitetami omogoča dve funkciji, in sicer: a) sledenje uporabnikov ter njihovih dovolilnic, ter b) vpogled v katalog nameščenih storitev s končnimi točkami API. Pri namestitvi storitve za upravljanje z identitami se srečamo s pojmi, kot so: uporabnik (ang. user; digitalna predstavitev osebe/sistema/storitve, ki uporablja OpenStack oblačne storitve), prijavni podatki (ang. credentials; podatki uporabnika, s katerimi se le-ta identificira), avtentikacija (ang. authentication; proces potrjevanja identitete uporabnika), avtorizacijski žeton (ang. token; naključno izbran set znakov, ki se uporablja za dostop do virov), kontejner t. i. najemnikov (ang. tenant; kontejner se uporablja za združevanje ali izolacijo virov in/ali identifikacijskih objektov), storitev (ang. service; OpenStack storitve z razvojnimi imeni Nova, Glance, itd.), končna točka (ang. endpoint; mrežno dostopen naslovs katerim lahko dostopamo do storitve) in vloga (ang. role; pravice in privilegiji osebnosti, ki jo uporabnik prevzame, za opravljanje določenega sklopa operacij). Namestitev te storitve poteka na vozlišču Controller vzporedno z namestitvijo python-keystoneclient, ki je nujen za delovanje. Kot skladišče podatkov storitev za upravljanje z identitetami uporablja bazo. V predhodno nameščeni podporni storitvi baze podatkov ustvarimo bazo z imenom keystone (tudi razvojno ime storitve za upravljanje z identitetami). Po namestitvi osnovnih paketov, izgradnji baze ter dodajanju tabel sledi pridobivanje avtorizacijskega žetona za komunikacijo med storitvami, ki ga zapišemo v konfiguracijsko datoteko storitve keystone. S tem se zaključi prva faza namestitve storitve za upravljanje z identitetami. V drugi fazi najprej definiramo administratorja in ostale uporabnike, najemnike in vloge. Pri ustvarjanju novih uporabnikov določimo ime, geslo in e-poštni naslov. Nato določimo vlogo ter skupino uporabnika. Zaporedje ukazov prikazuje slika 26. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 45

52 Slika 26: Ustvarjanje uporabnikov, skupin in vlog na primeru uporabnika admin Vse storitve OpenStack potrebujejo uporabniško ime, skupino in vlogo za dostopanje do drugih storitev. Zato v storitvi keystone ustvarimo še kontejner t. i. najemnikov, ki ga nato uporabimo pri ustvarjanju vseh nadaljnih storitev. Slika 27 prikazuje pripravo skupine Service. Slika 27: Priprava kontejnerja t. i. najemnikov za storitve Storitev za upravljanje z identitetami mora vedeti katere storitve so nameščene in kje v omrežju se nahajajo, zato je treba ob namestitvi storitve le-to registrirati. To naredimo tako, da storitev opišemo (ukaz keystone service-create) in določimo končno točko (ukaz keystone endpoint-create), s katerim določimo URL naslove za javni API, interni API in administratorski API. Registracija storitve prikazuje slika 28. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 46

53 Slika 28: Registracija storitve z opisovanjem in določanjem končnih točk Kot zadnji korak pri namestitvi storitve za upravljanje z identitetami je preverjanje delovanja storitve. V prejšnjih fazah, ko še nismo ustvarili uporabnika oz. klienta keystone, smo za avtentikacijo uporabili avtorizacijski žeton in končno točko storitve. Z registracijo storitve pa lahko v nadaljevanju nameščamo in konfiguriramo z uporabo uporabniškega imena, gesla, skupine in URL naslova. Zaradi lažje in hitrejše avtentikacije lahko nastavimo datoteke okolja (ang. environment file), kamor zapišemo prijavne podatke in končno točko izbranega uporabnika. Večino časa pri pripravi in namestitvi okolja ter storitev OpenStack uporabljamo administratorske prijavne podatke, zato ustvarimo [ime]-openrc.sh, kjer[ime]zamenjamo z izbranim uporabnikom, vsebina ukazne datoteke pa je naslednja: export OS_USERNAME=admin export OS_PASSWORD=ADMIN_GESLO export OS_TENANT_NAME=admin export OS_AUTH_URL= Po pripravi datoteke admin-openrc.sh preverimo delovanje storitve za upravljanje z identitetami. Najprej pokličemo seznam vseh uporabnikov, nato pokličemo seznam ustvarjenih uporabniških vlog in preverimo vloge administratorja. Preverjanje delovanja prikazuje slika 29. Slika 29: Preverjanje delovanja storitve za upravljanje z identitetami Blažka Globačnik: Model oblačnih storitev z OpenStack stran 47

54 Konfiguracija storitve slike (Image Service) Storitev slik (razvojno ime glance) uporabnikom omogoča iskanje, registracijo in pridobivanje slik virtualnih strojev, kar je omogočeno z REST API. Storitev je sestavljena iz dveh komponent, in sicer API del (glance-api) skrbi za prenos zahtev o iskanju, pridobivanju in iskanju slik, registracijski del (glance-registry) pa shranjuje, procesira in pridobiva meta podatke o slikah, ki vsebujejo tudi tip in velikost slike. Kot podporne komponente storitve slik so pomembne še baza, ki shranjuje meta podatke o slikah, ter skladišče za datoteke slik, ki podpira različne načine shranjevanja to so navadni podatkovni sistemi in objektna skladišča. Sama namestitev storitve Slik poteka na vozlišču Controller, kjer namestimo klienta Python ter paket OpenStack glance. Sledi konfiguracija API in registracijskega dela ter določitev gesla za dostopanje do baze storitve glance. Šele nato ustvarimo bazo te storitve ter glavnega uporabnika storitve glance. Sledi konfiguracija, ki storitvi slik omogoča avtentikacijo s pomočjo storitve identitet. Po namestitvi in nastavitvi storitve še preverimo ali smo le-to storili pravilno - namestimo testno sliko ter preverimo prisotnost le-te na vozlišču (slika 30). Slika 30: Preverjanje delovanja storitve slik Konfiguracija storitve procesiranja (Compute Service) Storitev procesiranja (razvojno ime nova) predstavlja bistvo sistema, saj s pomočjo le-te uporabnikom omogočamo uporabo oblačnega sistema. Storitev procesiranja sodeluje s storitvijo identitete za avtentikacijo, s storitvijo slik za delo s slikami in pregledno ploščo za delovanje spletnih vmesnikov. Procesiranje je torej skupek storitev, ki omogočajo zagon virtualnih strojev. Način namestitve te storitve poteka na vozlišču Controller in je v osnovi enak namestitvi katerekoli druge storitve. Pridobimo in namestimo pakete OpenStack ter kliente za delovanje teh paketov. Nato sledi nastavitev gesla baze storitve ter IP naslovov za dostopanje. Sledi izgradnja baze (geslo smo ustvarili že prej) ter uporabnika storitve nova. Določimo končne točke (slika 31) ter preverimo pravilnost namestitve storitve procesiranja. Storitev procesiranja, ki teče na vozlišču Controller, sodeluje z vozliščem Compute, kar pomeni, da je treba ustvariti povezavo med storitvijo ter vozliščem. To storimo tako, da spremenimo konfiguracijsko datoteko storitve nova - določimo povezavo do glavne baze, avtorizacijske podatke in naslov ter uporabnika storitve procesiranja z geslom. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 48

55 Slika 31: Priprava storitve procesiranja Priprava pregledne plošče (Dashboard) Namestitev pregledne plošče (razvojno ime horizon) je smiselna predvsem zaradi lažjega ustvarjanja in urejanja instanc. Pregledna plošča je grafični spletni vmesnik, ki omogoča komunikacijo z nadzornikom komponente OpenStack Compute. Za delovanje pregledne plošče so zahteve naslednje: nameščena storitev za procesiranje in storitev za upravljanje z identitetami. Namestiti je treba tudi Phyton 2.6 ali 2.7, ki podpirata Django. Med namestitvijo pregledne plošče smo se odločili za namestitev visoko sposobnega sistema za distribucijo spominskih objektov memcached. Z namestitvijo pregledne plošče lahko do vmesnika dostopamo preko spleta, in sicer za lokalni dostop uporabimo IP naslov vozlišča za nadzor controller. V nadaljevanju bomo predstavili izgradnjo instanc oz. virtualnih strojev s pomočjo pregledne plošče. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 49

56 7.2 Izgradnja virtualnih strojev Za izgradnjo virtualnih strojev oz. instanc so pomembni: javni ključ (generiran s ssh-keygen), aroma, slika, omrežje in varnostna skupina. Javni ključ predstavlja prijavne podatke ssh (secure shell), ki jih uporabljajo slike med zagonom virtualnega stroja. OpenStack omogoča 5 prednastavljenih arom z različnimi velikostmi pomnilnika in diska. Pri namestitvi storitve slik smo naložili prvo sliko (cirros), vendar smo jih brez večjih težav namestili še več. Za namen te raziskave smo preizkusili in namestili naslednje slike: RHEL 7, Fedora 20 in Ubuntu (slika 32). Pri namestitvi vsakega virtualnega stroja tudi določimo kateremu omrežju bomo instanco priključili ter varnostno skupino, ki jih lahko tudi poljubno spreminjamo in dodajamo. V prvi fazi pripravimo javni ključ, ki ga uporabimo pri izgradnji več virtualnih strojev. Nato uredimo arome in naložimo slike za zagon novih virtualnih strojev. Nastavimo omrežje ter določimo razpon IP naslovov, ki jih bodo virtualni stroji zasedli. V nadaljevanju lahko ustvarimo novo varnostno skupino ali pa uredimo privzete nastavitve. V drugi fazi pa lahko ustvarimo instanco, ki predstavlja svoj oblačni sistem. Slika 33 prikazuje ustvarjene instance, za katere smo uporabili aromo z 2 GB pomnilnika in 20 GB diska, javni ključ prvi in področje dostopnosti nova. Slika 34 prikazuje zagon in delovanje virtualnega stroja Fedora_20. Slika 32: Nameščene slike za zagon virtualnih strojev Slika 33: Prikaz nameščenih virtualnih strojev Blažka Globačnik: Model oblačnih storitev z OpenStack stran 50

57 Slika 34: Prikaz delujočega virtualnega stroja Fedora_ Testirni primeri v različnih okoljih in z različnimi konfiguracijami Delovanje sistema OpenStack smo preverili s pomočjo realnih in tudi imaginarnih podjetij. Tako smo ustvarili instance za podjetje M (ime je prikrito na željo lastnikov), podjetje Čisto življenje ter imaginarno podjetje Sodeluj. Podjetja M in Čisto življenje sta preizkusila različna odprtokodna ERP sistema, medtem ko smo v imaginarnem podjetju Sodeluj preizkušali odprtokodni CRM sistem Podjetje M, d.o.o Podjetje M d.o.o je mlado podjetje, ki se ukvarja s programiranjem in grafičnim oblikovanjem spletnih ter mobilnih aplikacij. Lastniki podjetja so zelo dobro seznanjeni z oblačnimi storitvami in so tako želeli preizkusiti odprtokodni sistem, ki bi jim omogočal lažje urejanje finančnih zadev ter upravljanje s projekti. Po skupnem pregledu odprtokodnih sistemov smo se odločili za ERP (ang. Enterprise resource planning) sistem Dolibarr. Na virtualni stroj z operacijskim sistemom Ubuntu smo namestili Dolibarr 3.5.4, ki samostojnim podjetnikom in majhnim podjetjem omogoča upravljanje kontaktov, pogodb, naročil, skladišč, projektov, kadrovanja itd. Dolibarr za delovanje potrebuje MySQL (pri 100 vpisanih kupcih je velikost približno 1 MB) in komponente za delovanje PHP. Za namestitev sistema pa je treba pripraviti najmanj 80 MB prostora na disku. Slika 35 prikazuje glavno okno orodja Dolibarr po prvi prijavi super uporabnika (admin). Blažka Globačnik: Model oblačnih storitev z OpenStack stran 51

58 Slika 35: Domača stran orodja Dolibarr po prvi prijavi super uporabnika Prijava administratorja poteka s prednastavljenim administratorskim geslom. V prvi fazi smo nastavili podatke o podjetju ter izbrali module (slika 36), ki omogočajo delo na finančnem nivoju podjetja in upravljanju projektov. Ker želi ostati podjetje anonimno, smo za logotip podjetja vnesli logotip projekta, v okviru katerega se preizkus izvaja, ter zakrili vse uradne podatke. Lastniki podjetja so v nadaljevanju preizkušali sistem (Priloga A), ki je za uporabo zelo enostaven ter so z samo dostopnostjo Dolibarr zadovoljni, saj je bil dostop hiter in stalen. Iz teh pogovorov lahko izpeljemo sklep, da je sistem OpenStack deloval brez prekinitev in težav. Slika 36: Priprava modulov v odprtokodnem ERP sistemu Dolibarr Podjetje Čisto življenje, d.o.o Podjetje Čisto življenje, d.o.o se ukvarja s svetovanjem na računalniškem področju ter programiranjem različnih sistemov. Podjetje je preizkusilo odprtokodni ERP sistem Openbravo 3, fleksibilno in razširljivo platformo za poslovanje. Sistem smo namestili na strežnik z distribucijo Ubuntu Openbravo v osnovi ponuja paket za lažjo namestitev sistema na Ubuntu in kot osnovo za delovanje zahteva najmanj 1,5 GB pomnilnika. To smo upoštevali pri izgradnji virtualnega stroja. Uspešno Blažka Globačnik: Model oblačnih storitev z OpenStack stran 52

59 namestitev in prijavo v sistem prikazujeta sliki 37 in 38. V nasprotju s podjetjem M, smo konfiguracijo sistema prepustili zaposlenim podjetja Čisto življenje, d.o.o. Osnovno pripravo orodja prikazuje Priloga B. Ugotovljeno je bilo, da je bil dostop v času testiranja sistema Openbravo neprekinjen, vendar pa tudi zelo počasen. Ugotovili smo tudi, da se je sistem zelo napreden in posledično težaven za uporabo v majhnih podjetjih. Sklepamo, da ERP sistem Openbravo ni primeren za majhna podjetja. Slika 37: Uspešna namestitev odprtokodnega ERP sistema Openbravo Slika 38: Domača stran odprtokodnega ERP sistema Openbravo Imaginarno podjetje Sodeluj Imaginarno podjetje Sodeluj se ukvarja z marketingom in analiziranjem marketinških kampanj in potez. Za potrebe urejanja projektov in lažje upravljanje s strankami smo se odločili za preizkus odprtokodnega CRM sistema. Uporabili smo CRM sistem EspoCRM 2.3.0, ki smo ga namestili na virtualni stroj z Linux distribucijo Ubuntu. Namestitev sistema je potekala na strežniku Apache2 s podporo za PHP 5.4 in MySQL 5.1. Po osnovni pripravi sistema sledi priprava okolja EspoCRM (slika 39). Ugotovljeno je bilo, da sistem deluje hitro, brez večjih težav in je kot tak primeren tako za majhna kot srednje velika podjetja. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 53

60 Slika 39: Prvotni pogled uporabnika v sistemu EspoCRM Rezultati testiranja Pri preizkusu smo poleg predstavljenih preizkusov tudi simulirali uporabo enakih sistemov ter s tem povečali število instanc in uporabnikov. Ugotovili smo, da se z večanjem števila uporabnikov sistemi začnejo odzivati počasneje, prav tako počasneje deluje tudi nadzorna plošča in dostop do tehnologije OpenStack je otežen. Ugotovili smo tudi, da se odprtokodni sistemi za poslovanje dobro obnesejo na strežnikih z Linux distribucijam. Kot kandidate za uporabo v majhnih ali srednje velikih podjetjih predlagamo odprtokodni ERP sistem Dolibarr in odprtokodni CRM sistem EspoCRM. Menimo, da je odprtokodni ERP sistem Openbravo preveč napreden za uporabo v majhnih podjetjih, temveč je bolj uporaben v večjih podjetjih. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 54

61 8 DISKUSIJA 8.1 Model ponudnika storitev v oblaku Ponudnik oblačnih storitev tehnologije OpenStack si mora poleg dobre strojne opreme priskrbeti tudi možnost pridobitve večjega števila IP naslovov, saj je število virtualnih strojev oz. instanc odvisna od števila možnih IP naslovov, ki jih lahko pripišemo instancam. Kot ponudnik oblačnih storitev tehnologije OpenStack smo tudi omejeni na SaaS ali PaaS storitvene modele, saj ne moremo nuditi virtualnih strojev oz. instanc brez predhodno nameščenega operacijskega sistema. Tako lahko naročnikom ponudimo prostor za shranjevanje datotek, strežnik za samostojno nameščanje različnih sistemov in dostop do že nameščenih aplikacij. Ponudnik storitve tako točno ve, kaj ponuja in tudi približno ve, kaj je na določeni instanci. Vseskozi ima nadzor nad strojno opremo, hkrati pa ima tudi dostop do programske opreme, kar je iz vidika varnosti za ponudnika dobro. OpenStack omogoča izgradnjo instanc le z operacijskimi sistemi za strežnike, z največjo podporo Linux distribucij. Ponudnik storitve je tako primoran poznati nameščanje sistemov z uporabo terminala. 8.2 Model naročnika storitev v oblaku Naročnik oblačnih storitev pri ponudniku, ki uporablja Openstack, lahko naroči storitvena modela SaaS ali PaaS, kar pomeni, da se lahko odloči za: nameščen operacijski sistem, nameščen operacijski sistem z aplikacijami. Naročnik storitve tako lahko delno skrbi le za nameščeno programsko opremo, saj ima ponudnik možnost neprestanega nadzorovanja, kaj se dogaja z neko instanco. S strani ponudnika je sicer dobro, da nadzoruje dogajanje na njegovi strojni opremi, s strani naročnika pa lahko to privede do resnih vprašanj glede varnosti shranjenih podatkov. Če se naročnik odloči za instanco samo z operacijskim sistemom, se mora zavedati, da te instance predstavljajo strežnike, kar pomeni, da za delo na njih potrebuje znanja za uporabo konzole - terminala. OpenStack sicer omogoča namestitev različnih strežnikov, vendar ima največjo podporo ravno v Linux distribucijah, kar lahko naročniku prinese precej težav. Pri izbiri operacijskega sistema z že nameščenimi aplikacijami naročnik skrbi le za aplikacije. Se pa lahko pojavijo težave v primeru nenameščenih ali slabo nameščenih posodobitev ali nadgradenj strežnika, saj naročnik nima dostopa do operacijskega sistema. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 55

62 9 ZAKLJUČEK Pri preverjanju zahtev za delovanje tehnologije smo ugotovili, da za samo namestitev potrebujemo najmanj 2 računalnika, saj za osnovno delovanje tehnologije nujno potrebujemo nadzorno vozlišče in vozlišče za procesiranje. Zahtev po posebni strojni opremi ni, vsako vozlišče za nadzor in upravljanje potrebuje najmanj 1 procesor, 2 GB pomnilnika in 10 GB prostora. Med preizkušanjem tehnologije je bilo ugotovljeno, da je za namestitev potrebno odlično znanje odprtokodnih distribucij Linux-a (v našem primeru predvsem RedHat in CentOS) ter tudi poznavanje programskega jezika Python. Sama navodila za namestitev so namreč izčrpna, vendar tudi predvidevajo, da uporabnik le-teh navodil dobro razume delovanje sistemov. Informacijski viri za OpenStack, v smislu strojne in programske opreme, niso veliki in so tudi cenovno ugodni. Za testiranje tehnologije lahko uporabimo osebne računalnike, kot osnovni operacijski sistem pa katerokoli Linux distribucijo. Sklepamo lahko tudi, da je uporaba človeških virov visoka, v kolikor uporabniki nimajo predznanja o terminalnem pisanju v Linux distribucijah ter programskem jeziku Phyton. Med eksperimentom smo tudi merili čas, ki smo ga porabili za osnovno namestitev tehnologije, brez izgradnje virtualnih strojev. Za osnovno namestitev nekdo brez kakršnegakoli predznanja potrebuje približno 40 ur več kot nekdo, ki odlično pozna nameščanje sistemov v Linux terminalu. Prvo namestitev smo izvedli brez predznanja, za kar smo porabili približno 75 ur, drugo testno namestitev pa smo izvedli s potrebnim predznanjem, za kar smo porabili približno 36 ur. Kot ponudniki storitve smo tako potrebovali veliko predznanja za namestitev, za samo pripravo virtualnih strojev pa to predznanje ni nujno. Naročnik storitve s samo namestitvijo OpenStack okolja nimajo stika. Tako smo prišli do drugega sklepa, da je tipičen napor, potreben za namestitev okolja OpenStack, v primeru ponudnika odvisen od predznanja, ki ga ponudnik ima. Ugotovili smo tudi, da naročnik ne sodeluje pri namestitvi okolja, sodeluje le pri pripravah ter uporabi virtualnih strojev. V eksperimentu smo večinoma nudili SaaS storitveni model, in sicer smo namestili različne sisteme za pomoč pri poslovanju. Tako smo večino virtualnih strojev uredili ponudniki, podjetja so samo preizkusila dostopnost, dosegljivost in delovanje nameščenih sistemov (npr. ERP). V tem primeru naročnik storitve nima druge naloge kot znanje o uporabi nameščenih sistemov, ki jih uporabljajo. Tehnologija OpenStack ne omogoča izdelave virtualnih strojev brez operacijskega sistema, kar pomeni, da lahko ponudnik nudi samo SaaS ali PaaS modele, vendar pa so tudi tu omejitve. Na virtualne stroje se lahko namestijo samo operacijski sistemi, ki so namenjeni strežnikom in ne namizni uporabi. Virtualni stroji tehnologije OpenStack namreč ne predstavljajo t. i. klasične virtualne stroje, kjer postavimo»fizični«stroj v virtualnem okolju. V okolju OpenStack se ti virtualni stroji zavedajo, da so virtualizirani in se ne obnašajo kot fizični stroji. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 56

63 Ugotovili smo, da v pripravljenem testnem okolju v primeru delovanja več virtualnih strojev hkrati nadzorna plošča deluje počasneje in tudi dostop do samih virtualnih strojev je malenkost počasnejši. Sklepamo, da se naraščanje števila uporabnikov in virtualnih strojev ter zahtev izrazito pozna v testnem oz. domačem okolju, v primeru boljših računalnikov in internetne povezave pa teh težav ne predvidevamo. Kljub vsemu pa menimo, da tehnologija OpenStack zahteva za velika produkcijska okolja znatna vlaganja v zanesljive in podvojene podsisteme. Brez nadzorne plošče v primeru upravljanja s pomočjo terminala, sama tehnologija ne predstavlja težav in tudi nima ugotovljenih izpadov. Vendar pa so možni izpadi in nepravilno delovanje v primeru uporabe nadzorne plošče. Tehnologijo OpenStack smo preizkusili v domačem oz. manjšem testnem okolju. Menimo, da nam rezultati kažejo, da je OpenStack primeren za domačo okolje, za nudenje strežnikov za testiranje storitev ali nudenje odprtokodnih sistemov za samostojne podjetnike ali manjša podjetja. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 57

64 LITERATURA IN VIRI Ahmed, K. E., & Alexandrov, V. (2011). Identity and Access Management in Cloud Computing. V Z. Mahmood, & R. Hill (Ured.), Cloud Computing for Enterprise Architectures (str ). London: Springer Verlag. doi: / _6 Baun, C., Kunze, M., Nimis, J., & Tai, S. (2011). Cloud Computing: Web-Based Dynamic IT Services. Verlag-Berlin-Heidelberg: Springer. doi: / _2 Brandon, J. (23. junij 2011). How to Use the Cloud as a Disaster Recovery Strategy. Prevzeto 11. april 2014 iz Inc.: Brian, O., Brunschwiler, T., Dill, H., Christ, H., Falsafi, M., Gatziu Grivas, S.,... et al. (2012). Cloud Computing [White Paper]. Zürich: Swiss Academy of Engineering Sciences. Prevzeto 25. februar 2014 iz 06_2_SATW_White_Paper_Cloud_Computing_EN.pdf CERN. (2014). About CERN. Prevzeto 9. maj 2014 iz CERN: CERN Uses OpenStack. (2013). Prevzeto 9. maj 2014 iz OpenStack Cloud Software: Chappell, D. (2008). A short introduction to cloud platforms. Prevzeto 27. februar 2014 iz Ciccarelli, P., & Faulkner, C. (2004). Networking Foundations. San Francisco, London: Sybex. Cisco WebEx Uses OpenStack. (2013). Prevzeto 9. maj 2014 iz OpenStack Cloud Software: Cör, M. (2009). Načrtovanje in strategija sistema za upravljanje z digitalnimi identitetami [diplomsko delo]. Ljubljana: Fakulteta za računalništvo in informatiko. Pridobljeno iz eprints.fri.uni-lj.si/948/1/coer_m-vs.pdf Cummins, S. (2011). Pro SharePoint 2010 Disaster Recovery and High Availability. Apress. enovace Uses OpenStack. (2013). Prevzeto 9. maj 2014 iz OpenStack Cloud Software: Fifield, T., Fleming, D., Gentle, A., Hochstein, L., Proulx, J., Toews, E., & Topjian, J. (2014). OpenStack Operations Guide [Early Release Raw & Unedited]. United States of America: O'Reilly Media, Inc. Globačnik, G. (2007). Odprtokodna programska oprema za elektrotehnike [diplomsko delo]. Maribor: FERI. Gopalakrishnan, A. (2009). Cloud Computing Identity Management. SETLabs Briefings, 7(7), Blažka Globačnik: Model oblačnih storitev z OpenStack stran 58

65 Haas, F. (2014). OpenStack High Availability Guide. Prevzeto 15. april 2014 iz OpenStack Documentation: Install openstack-nova-compute problem. (19. junij 2014). Pridobljeno iz Ask OpenStack: Intel Corporation. (2014). Intel Facts. Prevzeto 9. maj 2014 iz Intel: Intel Uses OpenStack. (2013). Prevzeto 9. maj 2014 iz OpenStack Cloud Software: Jackson, K. (2014). Troubleshooting in OpenStack cloud computing. Pridobljeno iz Packt Publishing: Jadeja, Y., & Modi, K. (2012). Cloud Computing - Concepts, Architecture and Challenges. International Conference on Computing, Electronics and Electrical Technologies, (str ). Jurič, M. L., & Ramesh Sarang, P. (2007). SOA Approach to Integration. Birmingham: Packt Publishing Ltd. Kumaraswamy, S., Lakshminarayanan, S., Reiter, M., Stein, J., & Wilson, Y. (2010). Domain 12: Guidance for Identity and Access Management V2.1. Prevzeto 28. april 2014 iz Li, Y., Sun, J., Zheng, Z., & Shen, H. (2012). Research of University Disaster Recovery System Based on Virtualization Technology. Third International Conference, ICICA 2012 (str ). Chengde, China: Springer Berlin Heidelberg. doi: / _16 Mell, P., & Grance, T. (2011). The NIST Definition of Cloud Computing. National Institute of Standards and Technology, Information Technology Laboratory. Prevzeto 27. februar 2014 iz Mohamed, A. (2012). A history of cloud computing. Prevzeto 25. februar 2014 iz ComputerWeekly.com: OpenStack. (29. oktober 2013). OpenStack Community Welcome Guide. Prevzeto 4. april 2014 iz OpenStack Dashboard. (2014). Prevzeto 15. april 2014 iz OpenStack Cloud Software: OpenStack Grizzly. (17. marec 2014). OpenStack Compute Administration Guide. Prevzeto 4. april 2014 iz OpenStack Cloud Software: Blažka Globačnik: Model oblačnih storitev z OpenStack stran 59

66 OpenStack Icehouse. (12. november 2013). OpenStack Cloud Administrator Guide. Prevzeto 15. april 2014 iz OpenStack Documentation: OpenStack Icehouse. (16. april 2014). OpenStack Installation Guide for Red Hat Enterprise Linux, CentOS, and Fedora - Icehouse. Pridobljeno iz OpenStack Cloud Software: OpenStack Idnetity API v3. (2014). Pridobljeno iz 3.pdf OpenStack Networking. (2014). Prevzeto 15. april 2014 iz OpenStack Cloud Software: OpenStack Software. (2014). Prevzeto 15. april 2014 iz OpenStack Cloud Software: OpenStack UserStories. (2014). Prevzeto 11. april 2014 iz OpenStack Cloud Software: Portnoy, M. (2012). Virtualization Essentials. Indiana: John Wiley & Sons, Inc. Ramos de Oliveira, R., Vieira Sanchez, R. V., Estrella, J. C., Pontin de Mattos Fortes, R., & Brusamolin, V. (2013). Comparative evaluation of the maintainability of RESTful and SOAP-WSDL web services. 7th International Symposium on the Maintenance and Evolution of Service- Oriented and Cloud-Based Systems (MESOCA), (str ). Eindhoven. doi: /mesoca Sanhu, R. J. (2002). Disaster Recovery Planning. USA: Premier Press. Shagin, A. (25. oktober 2012). The Risks And Benefits Of Cloud Computing. Prevzeto 9. april 2014 iz SAP Business Innovation: Slovensko društvo Informatika. (2014). Upravljanje identitete. Prevzeto 13. maj 2014 iz islovar: Slovensko društvo informatika. (2014a). Omreženje. Prevzeto 17. maj 2014 iz islovar: Slovensko društvo informatika. (2014b). podomrežna maska. Prevzeto 19. maj 2014 iz Slovensko društvo Informatika. (2014c). Podomrežje. Pridobljeno iz islovar: Smith, R. W. (2012). Linux Essentials. Indianapolis, Indiana: John Wiley & Sons, Inc. Takahashi, K., & Bertino, E. (2011). Identity Management: Concepts, Technologies and Systems. Norwood, MA, ZDA: Artech House. Tanenbaum, A. S., & Wetherall, D. J. (2011). Computer Networks [5th edition]. Boston: Prentice Hall. Blažka Globačnik: Model oblačnih storitev z OpenStack stran 60

67 Upravljanje identitet. (2012). Prevzeto 13. maj 2014 iz Računalniški center Univerze v Mariboru: Varghese, M. (2002). Disaster Recovery. Boston: Course Technology / Cengage Learning. Vivod, N. (2013). Pristopi za ziniževanje stroškov uporabe oblačnih storitev [magistrsko delo]. Maribor: FERI. vmware. (2013). A Guide To Modern IT Disaster Recovery: How to prepare for and mitigate the "Black Swan Events" in your data center. Pridobljeno iz aster_recovery.pdf. Wolf, C., & Halter, E. M. (2005). Virtualization: From the Desktop to the Enterprise. New York: Springer. Yuusuf, H., & Vidalis, S. (2012). On the road to virtualized environment. Third International Conference on Emerging Intelligent Data and Web Technologies (str ). IEEE Computer Society. doi: /eidwt Blažka Globačnik: Model oblačnih storitev z OpenStack stran 61

68 KAZALO SLIK Slika 1: Konceptualni model računalništva v oblaku... 4 Slika 2: Prikaz razlik med vrstami oblakov... 6 Slika 3: Predstavitev oblačnih modelov... 7 Slika 4: Koncept virtualizacije operacijskega sistema... 9 Slika 5: Koncept virtualizacije platform z nadzornikom tipa Slika 6: Prikaz RAID 0, RAID 1 in RAID 0+1 tehnologije Slika 7: Igralci in aktivnosti SOA Slika 8: Povezava od točke do točke (levo) in način razdeli in komuniciraj (desno) 14 Slika 9: Prikaz razlike med fizičnim in virtualnim»okrevanjem«po katastrofalnem dogodku Slika 10: Sestava programskega jedra Linux Slika 11: Sestava operacijskega sistema GNU/Linux Slika 12: Primer statičnega podomrežja v povezavi z IP naslovom C razreda Slika 13: Prikaz konceptualne arhitekture tehnologije OpenStack Slika 14: Grafični prikaz tri-vozliščne arhitekture Slika 15: Grafični prikaz dvo-vozliščne arhitekture Slika 16: Težave pri namestitvi paketov na vozlišče za procesiranje Slika 17: Namestitev sistema DevStack Slika 18: Osnovni vmesnik OpenStack ob prijavi administratorja Slika 19: Osnovni vmesnik OpenStack ob prijavi uporabnika Slika 20: Izdelava navideznih diskov - uporabnik Slika 21: Izdelava instanc - uporabnik Slika 22: Sprememba velikosti instance z uporabo arom - uporabnik Slika 23: Podrobnosti izdelane slike - uporabnik Slika 24: Pregled izdelanih instanc - uporabnik Slika 25: Preverjanje dosegljivosti vozlišča Compute Slika 26: Ustvarjanje uporabnikov, skupin in vlog na primeru uporabnika admin Slika 27: Priprava kontejnerja t. i. najemnikov za storitve Slika 28: Registracija storitve z opisovanjem in določanjem končnih točk Slika 29: Preverjanje delovanja storitve za upravljanje z identitetami Slika 30: Preverjanje delovanja storitve slik Slika 31: Priprava storitve procesiranja Slika 32: Nameščene slike za zagon virtualnih strojev Slika 33: Prikaz nameščenih virtualnih strojev Slika 34: Prikaz delujočega virtualnega stroja Fedora_ Slika 35: Domača stran orodja Dolibarr po prvi prijavi super uporabnika Slika 36: Priprava modulov v odprtokodnem ERP sistemu Dolibarr Slika 37: Uspešna namestitev odprtokodnega ERP sistema Openbravo Slika 38: Domača stran odprtokodnega ERP sistema Openbravo Slika 39: Prvotni pogled uporabnika v sistemu EspoCRM Blažka Globačnik: Model oblačnih storitev z OpenStack stran 62

69 KAZALO TABEL Tabela 1: Razporeditev IP naslovov glede na število bitov Tabela 2: Vrste skladišč tehnologije OpenStack Tabela 3: Plan razvrščanja IP naslovov KRATICE IN AKRONIMI API BIOS BYOD CPU CRM DHCP DNS EPEL ERP HTTP HuaaS Iaas IP IT KVM LAN NAT NTP OS PaaS RAID RAM REST SaaS SAN SOA SOAP URL VLAN Application program interface, programski vmesnik Basic input/output system, osnovni vhodno-izhodni sistem Bring your own device, prinesi svojo napravo (računalnik/tablica/telefon) Central processing unit, centralna procesna enota Customer relationship managment, upravljanje odnosov s strankami Dynamic Host Configuration Protocol; protokol, ki omogoča dinamično dodeljevanje naslova IP napravi v omrežju IP Domain name system, sistem domenskih imen Extra Packages for Enterprise Linux, dodatni paketi za Linux distribucije Enterprise resource planning, celovita programska rešitev za načrtovanje virov podjetja Hypertext transfer protocol, protokol za izmenjavo hiperteksta ter grafičnih, zvočnih in drugih večpredstavnostnih vsebin na spletu Humans as a Service, ljudje kot storitev Infrastructure as a Service, infrastruktura kot storitev Internet protocol, internetni protokol Information technology, informacijske tehnologije Kernel-based virtual machine, virtualen stroj temelječ na kernelu Local company network, lokalno oz. krajevno omrežje Network Address Translator, prevajalnik omrežnih naslovov Network time protocol, omrežna priključna točka Operational system, operacijski sistem Platform as a Service, platforma kot storitev Redundant array of independent disks, redundantno diskovno polje Random acess memory, pomnilnik z naključnim dostopom REpresentational State Transfer, predstavitveni prenos stanja Software as a Service, programje kot storitev Storage area network, omrežje za shranjevanje podatkov oz. omrežje pomnilniških naprav Service-oriented architectures, storitveno-orientirane arhitekture Simple object access protocol, protokol enostavnega dostopa do objekta Uniform resource locator, internetni naslov, na katerem je vsebina Virtual local area network, virtualno lokalno omrežje Blažka Globačnik: Model oblačnih storitev z OpenStack stran 63

70 WSDL XML Web Services Description Language, opisni jezik spletnih storitev Extensible markup language, format podatkov za izmenjavo strukturiranih dokumentov na spletu Blažka Globačnik: Model oblačnih storitev z OpenStack stran 64

71 PRILOGE Priloga A - Preizkus odprtokodnega ERP sistema Dolibarr Slika 1: Vpogled na odprti odprtokodni ERP sistem Dolibarr Slika 2: Vpogled na pripravljeno predstavitveno kartico podjetja Blažka Globačnik: Model oblačnih storitev z OpenStack stran 65

72 Slika 3: Vpogled na spremenjeno delovno okno Slika 4: Vpogled na primer izdanega in plačanega računa Blažka Globačnik: Model oblačnih storitev z OpenStack stran 66

73 Priloga B Preizkus ERP sistema Openbravo Slika 5: Prijavno okno v odprtokodni ERP sistem Openbravo Slika 6: Priprava modulov v odprtokodnem ERP sistemu Openbravo Blažka Globačnik: Model oblačnih storitev z OpenStack stran 67

74 Slika 7: Ustvarjanje dodatnih uporabnikov Slika 8: Pogled uporabnikove domače strani Blažka Globačnik: Model oblačnih storitev z OpenStack stran 68

75 Priloga C Preizkus CMR sistema espocrm Slika 9: Priprava okolja v espocrm sistemu Slika 10: Sistem za urejanje uporabnikov Blažka Globačnik: Model oblačnih storitev z OpenStack stran 69

76 Slika 11: Obrazec za urejanje kontaktov Blažka Globačnik: Model oblačnih storitev z OpenStack stran 70