Embed Size (px)
Citation preview
FAKULTETA ZA INFORMACIJSKE ŠTUDIJE
V NOVEM MESTU
D I P L O M S K A N A L O G A
UNIVERZITETNEGA ŠTUDIJSKEGA PROGRAMA PRVE STOPNJE
DEJAN MAROLT
FAKULTETA ZA INFORMACIJSKE ŠTUDIJE
V NOVEM MESTU
DIPLOMSKA NALOGA
DOSEGANJE VISOKE RAZPOLOŽLJIVOSTI
RAČUNALNIŠTVA V OBLAKU IN NJEN VPLIV
NA PREHOD S TRADICIONALNEGA
RAČUNALNIŠTVA: ŠTUDIJA PRIMERA
Mentor: doc. dr. Tomaž Aljaž
Novo mesto, september 2015 Dejan Marolt
IZJAVA O AVTORSTVU
Podpisani Dejan Marolt, študent FIŠ Novo mesto, izjavljam:
da sem diplomsko nalogo pripravljal samostojno na podlagi virov, ki so navedeni v
diplomski nalogi,
da dovoljujem objavo diplomske naloge v polnem tekstu, v prostem dostopu, na
spletni strani FIŠ oz. v elektronski knjižnici FIŠ,
da je diplomska naloga, ki sem jo oddal v elektronski obliki, identična tiskani verziji,
da je diplomska naloga lektorirana.
V Novem mestu, dne _________________ Podpis avtorja ______________________
POVZETEK
Računalništvo v oblaku (angl. Cloud Computing) je nov pogled na računalništvo, pri katerem
uporabniki dostopajo do deljenih virov računalništva. Vsak izpad delovanja ima negativen
vpliv na uporabnike, zato je doseganje visoke razpoložljivosti (angl. High Availability) nujno
potrebno. V diplomski nalogi smo predstavili koncept računalništva v oblaku, njegov razvoj,
lastnosti, storitvene in nadzorne modele, prednosti in priložnosti ter slabosti in tveganja.
Pozornost smo namenili tudi visoki razpoložljivosti, poiskali nekaj primerov izpadov
delovanja, njihove vzroke in vpliv ter rešitve za doseganje visoke razpoložljivosti. Kako
visoka razpoložljivost vpliva na prehod s tradicionalnega računalništva na računalništvo v
oblaku, smo analizirali na primeru manjšega IT podjetja, za katerega smo naredili tudi
primerjavo rešitve doseganja visoke razpoložljivosti z uporabo tradicionalnega računalništva
in računalništva v oblaku.
KLJUČNE BESEDE: računalništvo v oblaku, visoka razpoložljivost, izpad delovanja,
storitve v oblaku, študija primera
ABSTRACT
Cloud Computing is a new aspect of computing where users have access to a shared
computing resources. Any operation failure has a negative effect on the users, therefore
achieving high availability is essential. The thesis presents the concept of cloud computing, its
development, features, service and deployment models, advantages and opportunities, as well
as disadvantages and risks. A special attention has been paid to high availability. Not only
have we found some examples of operation failure, its causes and effect, but also solutions for
achieving high availability. The way high availability affects the transition from a traditional
computing to cloud computing has been analysed on the example of a small IT company, for
which we have prepared a comparison of the solutions for archieving high availability
between the traditional and cloud computing usage.
KEY WORDS: cloud computing, high availability, operation failure, cloud services, case
study
KAZALO
1. UVOD ................................................................................................................................. 1
1.1 Raziskovalno vprašanje in cilji raziskave .................................................................... 1
1.2 Metodologija ................................................................................................................ 2
1.3 Pričakovani rezultati .................................................................................................... 3
2. RAČUNALNIŠTVO V OBLAKU ..................................................................................... 3
2.1 Razvoj .......................................................................................................................... 3
2.2 Opredelitev ................................................................................................................... 4
2.3 Lastnosti ....................................................................................................................... 5
2.4 Storitveni modeli .......................................................................................................... 6
2.4.1 Infrastruktura kot storitev ..................................................................................... 8
2.4.2 Platforma kot storitev ........................................................................................... 9
2.4.3 Programska oprema kot storitev .......................................................................... 9
2.4.4 Karkoli kot storitev ............................................................................................. 10
2.5 Nadzorni modeli ........................................................................................................ 11
2.5.1 Zasebni oblak ...................................................................................................... 12
2.5.2 Javni oblak .......................................................................................................... 12
2.5.3 Hibridni oblak .................................................................................................... 13
2.5.4 Skupnostni oblak ................................................................................................. 13
2.5.5 Ostali nadzorni modeli ....................................................................................... 13
2.6 Prednosti in priložnosti .............................................................................................. 14
2.7 Slabosti in tveganja .................................................................................................... 16
3. VISOKA RAZPOLOŽLJIVOST ..................................................................................... 20
3.1 Opredelitev ................................................................................................................. 21
3.2 Sporazum o ravni storitve .......................................................................................... 23
3.2.1 Opredelitev ......................................................................................................... 23
3.2.2 Razpoložljivost v sporazumu o ravni storitve ..................................................... 24
3.2.3 Razpoložljivost v sporazumu o ravni storitve ponudnikov ................................. 25
3.2.4 Dejanska razpoložljivost ponudnikov ................................................................. 30
3.3 Primeri izpadov delovanja ......................................................................................... 32
3.4 Vzroki izpadov delovanja in njihov vpliv .................................................................. 33
3.5 Rešitve za doseganje visoke razpoložljivosti ............................................................. 34
4. ŠTUDIJA PRIMERA PODJETJA X ............................................................................... 37
4.1 Predstavitev podjetja .................................................................................................. 38
4.2 Informacijska tehnologija v podjetju ......................................................................... 38
4.3 Računalništvo v oblaku in vpliv visoke razpoložljivosti ........................................... 38
4.4 Primerjava rešitve lokalno in v oblaku ...................................................................... 40
4.4.1 Podatkovni strežnik v lokalnem okolju ............................................................... 41
4.4.2 Shramba kot storitev v oblaku ............................................................................ 42
4.4.3 Primerjava .......................................................................................................... 43
5. ZAKLJUČEK ................................................................................................................... 46
6. LITERATURA IN VIRI ................................................................................................... 49
KAZALO SLIK
Slika 2.1: Storitveni modeli in podrejenost virov lastnostim ..................................................... 7
Slika 2.2: Sestava hibridnega oblaka ........................................................................................ 13
Slika 3.1: Rast prihodkov ponudnikov ..................................................................................... 25
Slika 3.2: Osnovna konfiguracija za doseganje visoke razpoložljivosti .................................. 36
Slika 4.1: Primerjava stroškov shrambe lokalno in v oblaku ................................................... 41
Slika 4.2: Arhitektura lokalne rešitve z varnostnim kopiranjem .............................................. 42
Slika 4.3: Arhitektura rešitve v oblaku ..................................................................................... 43
KAZALO TABEL
Tabela 3.1: Dovoljen čas nedosegljivosti v primeru različnih ciljev stopnje razpoložljivosti . 23
Tabela 3.2: Cilj razpoložljivosti ponudnikov in dovoljena nedosegljivost storitve ................. 29
Tabela 3.3: Dejanska razpoložljivost........................................................................................ 31
Tabela 4.1: Primerjava stroškov različnih rešitev podatkovne shrambe .................................. 45
1
1. UVOD
Računalništvo v oblaku je nov način dobave storitev informacijske tehnologije, ki postopoma
zamenjuje tradicionalno računalništvo. Računalniški viri so na voljo kot storitev, do njih pa
dostopamo preko spleta. Z uporabo storitev računalništva v oblaku se izognemo velikim
naložbam v lastno strojno in programsko opremo, saj jo najamemo in plačamo po porabi.
Visoka razpoložljivost je stopnja razpoložljivosti storitve 99,999 % ali več. Izhaja iz
tradicionalne telefonije, v kateri je bilo neuspešnih le nekaj klicev. Ne glede na uporabljeno
tehnologijo računalništva si uporabniki želijo, da so storitve dosegljive ves čas in brez
izpadov delovanja. To je pomembno tako za podjetja kot tudi posameznike, saj za te storitve
plačujejo. Uporaba računalništva v oblaku naj bi poleg znižanja stroškov zagotavljala tudi
visoko stopnjo razpoložljivosti.
V prvem delu diplomske naloge bomo predstavili računalništvo v oblaku, njegov razvoj,
lastnosti, storitvene in nadzorne modele, prednosti in priložnosti ter slabosti in tveganja
uporabe storitev računalništva v oblaku. V nadaljevanju bomo predstavili pojem
razpoložljivosti oziroma visoke razpoložljivosti in za računalništvo v oblaku pomemben
sporazum o ravni storitve med ponudnikom in uporabnikom. Pregledali bomo tudi
odmevnejše primere izpadov storitev, njihove vzroke in vpliv, ki ga imajo na uporabnike, ter
opisali nekatere rešitve za doseganje visoke razpoložljivosti. V zadnjem delu diplomske
naloge bomo analizirali intervju, ki smo ga opravili s podjetjem, ki se ukvarja z razvojem
strojne in programske opreme. Ugotovili bomo, kako doseganje visoke razpoložljivosti vpliva
na njihov prehod s tradicionalnega računalništva na računalništvo v oblaku. S približno oceno
stroškov zagotavljanja določene stopnje razpoložljivosti z uporabo tradicionalnega
računalništva in primerjavo s stroški prehoda na računalništvo v oblaku bomo ugotovili tudi
smiselnost prehoda podjetja na storitve računalništva v oblaku.
1.1 Raziskovalno vprašanje in cilji raziskave
Raziskovalno vprašanje "Kako doseganje visoke razpoložljivosti vpliva na prehod s
tradicionalnega računalništva na računalništvo v oblaku?" je eno izmed glavnih vprašanj
2
podjetij, ki se odločajo o prehodu. V pomoč pri odgovoru na to vprašanje smo si zastavili
dodatni vprašanji glede doseganja visoke razpoložljivosti, in sicer "Kolikšno stopnjo visoke
razpoložljivosti obljubljajo ponudniki storitev računalništva v oblaku?" ter "Ali ponudniki
storitev računalništva v oblaku dosegajo obljubljene stopnje visoke razpoložljivosti?". Z
odgovorom na raziskovalno vprašanje "Ali je prehod podjetja X s tradicionalnega
računalništva na računalništvo v oblaku smiseln, v kolikor zanemarimo vse izzive z izjemo
visoke razpoložljivosti?" pa bomo na realnem primeru izvedeli, kako pomembno je doseganje
visoke razpoložljivosti.
Na podlagi raziskovalnih vprašanj smo opredelili cilje raziskave:
- opisati računalništvo v oblaku,
- ugotoviti, katere so prednosti in priložnost ter slabosti in izzivi računalništva v oblaku,
- ugotoviti, kaj je visoka razpoložljivost,
- ugotoviti, kolikšno stopnjo razpoložljivosti zagotavljajo ponudniki,
- ugotoviti, ali ponudniki dosegajo visoko razpoložljivost zagotavljanja storitev,
- ugotoviti vzroke in vpliv izpadov delovanja,
- ugotoviti, kakšne rešitve zagotavljanja visoke razpoložljivosti obstajajo,
- ugotoviti, kako doseganje visoke razpoložljivosti vpliva na prehod s tradicionalnega
računalništva na računalništvo v oblaku in
- ugotoviti smiselnost prehoda s tradicionalnega računalništva na računalništvo v oblaku
podjetja X.
1.2 Metodologija
Diplomska naloga je sestavljena iz teoretičnega in empiričnega dela. Teoretični del je
sestavljen na podlagi pregleda relevantne literature in virov s preiskovanega področja. Opisani
so ključni koncepti računalništva v oblaku in visoke razpoložljivosti, ki so potrebni za
razumevanje pomembnosti teh področij. Empirični del diplomske naloge sestavlja študijo
primera na podlagi analize izvedenega intervjuja. Intervju je bil opravljen v mikro podjetju, ki
za končne naročnike razvija strojno in programsko opremo. Vprašanja intervjuja so bila
deloma pripravljena vnaprej, zato gre za obliko polstrukturiranega intervjuja.
3
1.3 Pričakovani rezultati
Računalništva v oblaku se poslužuje čedalje več podjetij, saj jim to prinaša poslovno prednost
pred ostalimi podjetji. Pričakujemo, da je podjetjem doseganje visoke razpoložljivosti
pomembno in da jim to predstavlja enega izmed ključnih dejavnikov pri odločitvi o prehodu,
vendar ni na prvem mestu po pomembnosti. Menimo, da bo v prihodnosti računalništvo v
oblaku zamenjalo tradicionalno računalništvo. Podjetja, ki bodo želela ostati v stiku s
tehnologijo, bodo prisiljena v prehod, zato bo tudi vpliv doseganja visoke razpoložljivosti
postal manj pomemben, prav tako lahko z napredkom tehnologije pričakujemo doseganje še
višje razpoložljivosti. V primeru, da bi jim trenutno doseganje visoke razpoložljivosti
predstavljalo veliko oviro, se bodo taka podjetja soočila z višjimi stroški, zato bodo težje
tekmovala s podjetji, ki se bodo odločila za prehod. Prav tako pričakujemo, da tradicionalno
računalništvo ne dosega veliko boljših rezultatov, predvsem glede na stroške, ki nastanejo z
doseganjem višje razpoložljivosti v primeru tradicionalnega računalništva.
2. RAČUNALNIŠTVO V OBLAKU
2.1 Razvoj
Koncept računalništva v oblaku ni nov. Ob stoletnici univerze MIT (Massachusetts Institute
of Technology) je John McCarthy predstavil idejo računalništva kot javne dobrine. Napovedal
je, da bo v prihodnosti postala osnova nove in pomembne industrije, ki bo preko omrežja
ponujala računalništvo kot storitev (Cafaro in Aloisio v Oredo in Njihia 2014, str. 151).
Začetki povezovanja IT infrastrukture in njene nadaljnje distribucije segajo v 80. leta 20.
stoletja. Takrat so se pojavila podjetja, ki so svoje aplikacije oddajala kot storitev. Primer take
storitve je elektronska pošta Hotmail (Owens v Venters in Whitley 2012, str. 180). Zgodnji
poskusi zagotavljanja aplikacij kot storitev (angl. Application Service Provision) so bili zaradi
pomanjkanja pasovne širine in zmogljivosti nezadostni (Kern in drugi v Venters in Whitley
2012, str. 180; Susarla in drugi v Venters in Whitley 2012, str. 180). Kasneje, v 90. letih in na
prelomu tisočletja, sta se začela uveljavljati še dva pomembna koncepta za računalništvo v
oblaku, in sicer koncept povezovanja računalnikov v omrežje (angl. Networking) in mrežno
4
računalništvo (angl. Grid Computing) (Dimitrios in Dimitrios v Aleem in Sprott 2012, str. 8),
močno pa je napredovalo tudi področje virtualizacije (angl. Virtualization) (Vance v Aleem in
Sprott 2012, str. 8). Izraz računalništvo v oblaku naj bi se prvič pojavil leta 1997 (Lijun Mei
in drugi v Oredo in Njihia 2014, str. 151), dve leti kasneje je bilo ustanovljeno podjetje
Salesforce.com, ki je preko enostavne spletne strani začelo ponujati programsko opremo kot
storitev. Temu je sledilo podjetje Amazon, ki je leta 2006 dalo na trg oblačno storitev
Amazon Elastic Compute Cloud (Amazon EC2) (Aleem in Sprott, 2012). Računalništvo v
oblaku je bilo leta 2008 navedeno kot eno izmed desetih najvplivnejših tehnologij (Gartner v
Aleem in Sprott 2012, str. 8), s čimer se je uresničila prvotna napoved Johna McCarthyja. To
je bilo tudi leto, v katerem so izraz računalništvo v oblaku začela množično uporabljati
podjetja, kot so HP, Intel in Yahoo, ki so hkrati oznanila ustanovitev odprtega globalnega
računalniškega laboratorija, poimenovanega Cloud Computing Test Bed (Arutyunov, 2012).
V letih 2011 in 2012 je računalništvo v oblaku veljalo za eno izmed tehnologij z velikim
napredkom (Luftman in Zadeh v Oredo in Njihia 2014, str. 150; Luftman in drugi v Oredo in
Njihia 2014, str. 150). Prihodki ponudnikov storitev računalništva v oblaku so leta 2010
presegli 21,5 milijard dolarjev (IDC Cloud v Oredo in Njihia 2014, str. 150), samo prihodki
ponudnika Amazon pa so bili ocenjeni med 500 in 700 milijonov dolarjev (The Economist v
Venters in Whitley 2012, str. 180). Za leto 2012 so bili prihodki ocenjeni na 61 milijard
dolarjev (Kirsker v Venters in Whitley 2012, str. 180), za leto 2015 pa na 72,9 milijard
dolarjev (IDC Cloud v Oredo in Njihia 2014, str. 150). V prihodnosti naj bi vrednost
računalništva v oblaku še rasla, za leto 2020 je vrednost ocenjena na 241 milijard dolarjev
(Dignan v Venters in Whitley 2012, str. 180). Razvoj računalništva v oblaku se nadaljuje z
gradnjo ogromnih podatkovnih centrov podjetij, kot so Google, Amazon in Microsoft (Boss in
drugi v Venters in Whitley 2012, str. 180–181; Da Rold v Venters in Whitley 2012, str.
180−181).
2.2 Opredelitev
Računalništvo v oblaku je uveljavljajoča tehnologija, ki bi lahko v prihodnosti nadomestila
tradicionalno računalništvo (Frantsvog in drugi, 2012). Velja za enega izmed
najpomembnejših tehnoloških premikov zadnjega desetletja (Wang in drugi, 2011). Ko
govorimo o računalništvu v oblaku, mislimo na eni strani na aplikacije, ki so nam kot storitev
na voljo preko spleta, na drugi strani pa na računalniške sisteme podatkovnih centrov
(Armbrust in drugi, 2010). Računalništvo v oblaku vsakdo vidi in uporablja na drugačen
5
način, nekateri kot nadomestek običajnih programskih rešitev, drugi kot orodje z dodatno
zmogljivostjo obdelovanja in skladiščenja podatkov (Marshall v Rose 2011, str. 59).
Enostavno ga lahko opredelimo kot pristop do deljene infrastrukture, v kateri povezani fondi
(angl. Fonds) računalniških sistemov zagotavljajo storitve (Ganek v Rose 2011, str. 59).
Omenjene računalniške sisteme sestavljajo strojna in programska oprema ter storitve, ki jih
zagotavljajo ponudniki oblačnih storitev (Frantsvog in drugi, 2012).
Pristop do deljene infrastrukture preko spleta je tudi središče splošno sprejete tehnične
opredelitve ameriškega inštituta za standarde in tehnologijo NIST (angl. National Institute of
Standards and Tecnology). Računalništvo v oblaku opredeljuje kot model, ki na zahtevo
omogoča vseprisoten in priročen dostop do deljenega fonda nastavljivih računalniških virov.
Do virov, kot so omrežja, strežniki, podatkovne shrambe, aplikacije in storitve, dostopamo
preko spletnega dostopa. Viri so lahko hitro zagotovljeni oziroma sproščeni z najmanjšim
naporom oziroma sodelovanjem s strani ponudnika storitev (Mell in Grance, 2011).
Model računalništva v oblaku, kot ga opredeljuje NIST, je sestavljen iz petih ključnih
lastnosti, treh storitvenih modelov in štirih nadzornih modelov. V naslednjih poglavjih jih
bomo predstavili skupaj s ključnimi ugotovitvami drugih avtorjev.
2.3 Lastnosti
Zagotavljanje storitev računalništva v oblaku je mogoče zaradi nekaterih lastnosti (Oredo in
Njihia, 2014). Ključne lastnosti, kot jih opredeljuje NIST, so (Mell in Grance, 2011):
- samopostrežba na zahtevo,
- širok mrežni dostop,
- združevanje virov,
- elastičnost in
- merjena storitev.
Računalniške zmogljivosti računalništva v oblaku so uporabniku na voljo na zahtevo, do njih
pa lahko dostopamo brez posredovanja oziroma sodelovanja osebja ponudnika storitev. Na
voljo so nam preko omrežja in so dosegljive širokemu naboru uporabniških naprav, ki imajo
sposobnost povezovanja na splet. Viri so združeni v homogeno celoto, do katere lahko hkrati
6
dostopa več uporabnikov. Različni fizični in navidezni viri so nato dinamično dodeljeni glede
na uporabnikove zahteve, pri čemer večinoma ne vemo, kje natančno se nahajajo, niti nimamo
nadzora nad tem. Za uporabnika se zdi zmogljivost teh virov neskončna, saj so lahko
dodeljeni v kakršnikoli količini. Zmogljivost virov je lahko elastično nastavljiva, dodeljevanje
in sproščanje virov pa je odvisno od potreb posameznega uporabnika. Uporaba virov je
nadzorovana in optimizirana, tako ponudnik kot uporabnik ves čas vesta, koliko virov je bilo
uporabljenih. Na podlagi teh podatkov so storitve tudi zaračunane, običajno pa se jih plača po
porabi (angl. Pay-per-use) (Mell in Grance, 2011).
Poleg teh lastnosti so za storitve računalništva v oblaku značilne še nekatere druge lastnosti,
med katere sodijo tudi (Catteddu in Hogben v Farah 2013, str. 20):
- zelo abstraktni viri (angl. Highly Abstract Resources),
- skoraj takojšna razširljivost (angl. Scalability) in prilagodljivost (angl. Flexibility),
- skoraj takojšnje zagotavljanje virov oziroma oskrba z viri (angl. Provisioning) in
- načrtno upravljanje (angl. Programmatic Management).
2.4 Storitveni modeli
Računalništvo v oblaku ponuja različne tipe storitev, na podlagi teh pa jih uvrščamo v
storitvene modele.
Splošno sprejeti so trije storitveni modeli, in sicer (Mell in Grance, 2011):
- infrastruktura kot storitev (angl. Infrastructure as a Service),
- platforma kot storitev (angl. Platform as a Service) in
- programska oprema kot storitev (angl. Software as a Service).
Če gledamo na storitvene modele kot na stopnje, najdemo model infrastrukture kot storitve na
najnižji stopnji, model platforme kot storitve na srednji stopnji in model programske opreme
kot storitve na najvišji stopnji. Infrastruktura kot storitev zagotavlja uporabniku osnovno
infrastrukturo. Na srednji stopnji platforma kot storitev zagotavlja okolje za gostovanje
aplikacij uporabnika, programska oprema kot storitev pa je namenjena zagotavljanju celotnih
aplikacij kot storitve na zahtevo (Bhadauria in drugi, 2014).
7
Za katerega izmed storitvenih modelov računalništva v oblaku gre, lahko določimo tudi na
podlagi količine IT virov, ki delujejo v okviru petih ključnih lastnostih, omenjenih v
prejšnjem poglavju (glej Sliko 2.1). O modelu infrastrukture kot storitve govorimo, če se
lastnostim podredijo računski, shranjevalni in omrežni viri. To pomeni, da imamo te vire na
voljo za uporabo, da dobimo delujočo storitev, pa moramo v oblak prinesti platforme,
aplikacije in podatke. Če se poleg teh virov podredijo tudi platforme, kot so operacijski
sistemi in programski vmesniki (angl. Application Program Interfaces), govorimo o modelu
platforme kot storitve. Za delujočo storitev v tem storitvenem modelu moramo v oblak
prinesti aplikacije in podatke. Ko se lastnostim podredijo tudi aplikacije, govorimo o modelu
programske opreme kot storitve, v katerem moramo za delujočo storitev v oblak prinesti samo
podatke. V primeru tradicionalnega računalništva vse te vire zagotavlja uporabnik sam
(Bervar, 2013).
Slika 2.1: Storitveni modeli in podrejenost virov lastnostim
Vir: Prirejeno po Bervar (2013, str. 4)
Ponudniki storitev računalništva v oblaku najpogosteje ponujajo storitveni model programske
opreme kot storitve. Med 127 ponudniki storitev računalništva v oblaku je ta storitveni model
v letu 2013 ponujalo 55 % vprašanih. Temu sledi model infrastrukture kot storitve, ki ga je
8
ponujalo 34 % vprašanih, najmanj, 11 %, vprašanih ponudnikov pa je ponujalo model
platforme kot storitve (Ponemon v Srinivasan 2013, str. 49). Pogostost teh storitvenih
modelov je podobna tudi med uporabniki storitev računalništva v oblaku. V raziskavi med
200 IT strokovnjaki jih je kar 72,6 % uporabljalo oziroma načrtovalo uporabo programske
opreme kot storitve. 44,3 % uporabnikov je uporabljalo infrastrukturo kot storitev, najmanj
uporabnikov pa je bilo pri platformi kot storitev, ki jo je uporabljalo oziroma načrtovalo
uporabo 34,9 % vprašanih IT strokovnjakov (Aleem in Sprott 2012, str. 12).
2.4.1 Infrastruktura kot storitev
Model infrastrukture kot storitve je spremenil način, kako podjetja vlagajo v IT infrastrukturo.
Podjetjem daje možnost, da se namesto na upravljanje infrastrukture osredotočijo na posel.
Značilno se model infrastrukture kot storitve uporablja, ko podjetje ne želi vlagati v lastno IT
infrastrukturo in osebje, ki jo bo vzdrževalo. Tako se podjetje izogne veliki naložbi, strošek pa
jim predstavljajo le uporabljeni viri (Fernandes in drugi, 2014), ki so običajno izraženi v
procesorskih urah (Kupferman in drugi, 2009). Običajno so ti viri na voljo z uporabo
virtualizacije (Bhadauria in drugi, 2014).
V modelu infrastrukture kot storitve je uporabnikom zagotovljena osnovna infrastruktura, ki
vključuje računske, shranjevalne, omrežne in ostale temeljne vire. Z uporabo teh virov ima
uporabnik možnost postaviti in upravljati s programsko opremo. Nad osnovno infrastrukturo
uporabnik nima nadzora, upravlja pa z operacijskim sistemom, shrambo in postavljenimi
aplikacijami, omejen nadzor ima tudi nad nekaterimi omrežnimi komponentami (Mell in
Grance, 2011). To pomeni, da ima uporabnik možnost postavitve kateregakoli operacijskega
sistema in aplikacij (Aguiar in drugi, 2014).
Primeri infrastrukture kot storitve so spletne storitve Amazon (Kamar in Lauter v AlZain in
drugi 2012, str. 51), med katerimi najdemo storitvi Amazon Simple Storage Solution
(Amazon S3) in Amazon Elastic Compute Cloud (Amazon EC2) (Chakravarthy in Kannan,
2014), pri čemer slednja velja za referenčno storitev tega modela (D'Agostino in drugi, 2013).
Ostali primeri so Go-Grid, IBM Computing on Demand (COD), Rackspace (Chakravarthy in
Kannan, 2014) in HP Flexible Computing Services (Mendes in drugi, 2013).
9
2.4.2 Platforma kot storitev
Model platforme kot storitve deluje kot razvojna platforma za aplikacije (Chakravarthy in
Kannan, 2014). Uporabnikom daje možnost nameščanja in poganjanja lastnih aplikacij (Dutta
in drugi, 2013). Platformo kot storitev večinoma uporabljajo razvijalci programske opreme, ki
potrebujejo platformo, na kateri lahko v kratkem času testirajo aplikacijo pod različnimi
pogoji (Srinivasan, 2013). Aplikacije so izdelane z uporabo programskih jezikov, ki jih
podpira ponudnik storitve, običajno pa so to aplikacije, ki omogočajo istočasno sodelovanje
pri delu (Ghilic-Micu in drugi, 2014). Za upravljanje se uporablja ponudnikov programski
vmesnik, zato je selitev aplikacij od enega ponudnika k drugemu zelo otežena (Frantsvog in
drugi, 2012; Hurwitz in drugi v Aleem in Sprott 2012, str. 10). Prav tako ni mogoče
programiranje platforme v kateremkoli programskem jeziku. Google App Engine na primer
ponuja možnost uporabe programskih jezikov Python, Java in Go (Google v Fernandes in
drugi 2014, str. 118−119), ni pa izključena uporaba združljivih programskih jezikov, knjižnic,
storitev in orodij iz drugih virov (Mell in Grance, 2011).
Uporabnik ima nadzor nad postavljenimi aplikacijami in nekaterimi nastavitvami okolja, na
katerem gostujejo aplikacije, ne upravlja pa osnovne infrastrukture in operacijskega sistema
(Mell in Grance, 2011). Za razvijalce programske opreme je to velika prednost, saj se z
uporabo platforme kot storitve izognejo zahtevnemu upravljanju strojne opreme in znižajo
stroške (Oredo in Njihia, 2014).
Primeri platforme kot storitve so Akamai Edge, Google App Engine, Microsoft Azure in
Yahoo! open Strategy (Y!oS) (Chandramohan in Baskaran v Chakravarthy in Kannan 2014,
str. 1224). Te storitve vključujejo upravljanje s podatkovnimi bazami, zaščito in upravljanje
poteka dela (angl. Workflow Management) (Ahuja in Mani, 2012).
2.4.3 Programska oprema kot storitev
Osnovna zamisel modela programske opreme kot storitve je najem programske opreme
(Ahuja in Mani, 2012), kar pomeni, da je ni potrebno namestiti na lokalnem računalniku. Z
najemom odpravimo tudi potrebo po vzdrževanju programske opreme (Bhadauria in drugi,
2014). Do najete programske opreme običajno dostopamo z uporabo spletnih brskalnikov.
Dostop je mogoč z velikega števila naprav ali programskega vmesnika (Mell in Grance,
10
2011). Med uporabniki je najpogosteje širša javnost oziroma so to končni uporabniki teh
aplikacij (Han, 2013).
V modelu programske opreme kot storitve je uporabnikom zagotovljena programska oprema
ponudnika. Uporabnik si ne lasti in ne upravlja osnovne infrastrukture, operacijskega sistema
ali shrambe. Prav tako nima nadzora nad postavljenimi aplikacijami, spreminja lahko le
nekatere za uporabnika specifične nastavitve (Mell in Grance, 2011), ki so običajno omejene
na izgled aplikacije (Yoo, 2011).
Primeri programske opreme kot storitve so elektronska pošta, pisarniške aplikacije in
računovodski sistemi (Dutta in drugi, 2013), torej programska oprema, ki je specifična za
poslovanje. Mednjo prištevamo tudi Google Aplikacije (angl. Google Apps) (Chakravarthy in
Kannan, 2014) in aplikacije za upravljanje odnosov s strankami (angl. Customer Relationship
Management) Salesforce.com (Subashini in Kavitha v AlZain in drugi 2012, str. 51; Takabi in
drugi v AlZain in drugi 2012, str. 51).
2.4.4 Karkoli kot storitev
Računalništvo v oblaku ni omejeno samo na omenjene modele (Frantsvog in drugi, 2012). V
obliki storitev podpira in ponuja karkoli, vse od zagotavljanja ogromnih virov, do posebnih in
osebnih zahtev (Fernandes in drugi, 2014). Temu storitvenemu modelu pravimo tudi karkoli
kot storitev (angl. Anything as a Service) (Banerjee in drugi v Fernandes in drugi 2014, str.
119; Rimal in drugi v Fernandes in drugi 2014, str. 119). Storitveni model karkoli kot storitev
je skupni termin za različne komponente, ki so z uporabo računalništva v oblaku na voljo kot
storitev (Digital Agenda for Europe, 2014).
Storitve, ki jih avtorji ne navajajo v sklopu treh splošno sprejetih storitvenih modelov, so:
- podatkovna baza kot storitev (angl. Database as a Service) (AlZain in drugi, 2012;
Arutyunov, 2012; Iyer in Mehrotra v Mendes in drugi 2013, str. 96; Nicho in Hendy,
2013; Ghilic-Micu in drugi, 2014),
- usmerjanje kot storitev (angl. Routing as a Service) (Chen in drugi, 2014),
- varnost kot storitev (angl. Security as a Service) (Al-Aqrabi in drugi v Fernandes in
drugi 2014, str. 119),
11
- poslovni proces kot storitev (angl. Business Process as a Service) (Ghilic-Micu in
drugi, 2014),
- delovno mesto kot storitev (angl. Workplace as a Service) (Arutyunov, 2012),
- namizje kot storitev (angl. Desktop as a Service) in
- zavarovanje podatkov kot storitev (angl. Data Protection as a Service) (Ghilic-Micu
in drugi, 2014).
Podatkovno bazo kot storitev ponujajo vsi večji ponudniki storitev računalništva v oblaku, in
sicer Amazon s storitvijo SimpleDB, Google z BigTable in Microsoft s storitvijo SSDS
(Mendes in drugi, 2013). Uporabnikom je na voljo prostor za njihove podatke (Arutyunov,
2012). Usmerjanje kot storitev omogoča posameznemu uporabniku (angl. Tenant) deljenih
virov, da programsko določi, kam gredo zahtevki za njihove storitve. Tradicionalno je
posameznim uporabnikom usmerjanje (angl. Routing) zagotovljeno skozi proces vozovnic
(angl. Ticketing Process). Proces se prične, ko uporabnik izda zahtevek za prilagoditev
usmerjanja. Lastnik storitve odpre vozovnico in obravnava zahtevek. Ko sta obe strani
zadovoljni s spremembo, se vozovnica zapre, zahtevek pa je odobren (Chen in drugi, 2014).
Za varnost računalništva v oblaku v prvi vrsti skrbita ponudnik in uporabniki. Dodatno naj bi
za varnost poskrbela ločena storitev varnosti kot storitve, v katero bi bilo zajeto predvsem
filtriranje elektronske pošte in vsebine na spletu ter upravljanje z ranljivostjo. Poleg tega
vzpostavlja nov storitveni model identitete kot storitve (angl. Identity as a Service) (Mangiuc,
2012). Ko se podjetje odloči za namestitev in konfiguracijo programske opreme, s katero za
svoje zaposlene organizirajo delovno mesto, govorimo o delovnem mestu kot storitvi
(Arutyunov, 2012). Namizje kot storitev omogoča varen dostop do podatkov. Do njih lahko
dostopamo s katerekoli naprave in od koderkoli, na namizje pa se povežemo s pomočjo
virtualnega strežnika (Žnidar, 2015).
2.5 Nadzorni modeli
Poleg ključnih lastnosti in storitvenih modelov so za računalništvo v oblaku značilni tudi štirje
nadzorni modeli, ki se delijo glede na zahteve uporabnika (Mell in Grance, 2011). Ločimo jih
glede na način gostovanja in koriščenja računalništva v oblaku (Frantsvog in drugi, 2012),
mednje pa štejemo (Mell in Grance, 2011):
- zasebni oblak (angl. Private Cloud),
12
- javni oblak (angl. Public Cloud),
- hibridni oblak (angl. Hybrid Cloud) in
- skupnostni oblak (angl. Community Cloud).
Večina podjetij uporablja javni oblak, in sicer 88 %, medtem ko zasebni oblak uporablja 63 %
podjetij. Podjetja so najbolj naklonjena k strategiji uporabe tako javnega kot zasebnega oblaka
hkrati, torej hibridnega oblaka, katerega se poslužuje 82 % podjetij (RightScale 2015, str. 2).
2.5.1 Zasebni oblak
V zasebnem oblaku je infrastruktura oblaka na voljo za uporabo enemu podjetju. Storitve
takega oblaka so na voljo preko zasebnega podatkovnega centra, ki je v lasti tega podjetja
(Yoo, 2011). Zasebnega oblaka se poslužujejo predvsem podjetja, ki želijo izkoristiti prednost
računalništva v oblaku, zahtevajo več nadzora nad njihovimi podatki, naložba v infrastrukturo
pa jim ne predstavlja ovire (Aleem in Sprott, 2012). Z infrastrukturo običajno upravlja
podjetje, ki uporablja oblak (Frantsvog in drugi, 2012), v nekaterih primerih je za to zadolžen
zunanji ponudnik (Bhadauria in drugi, 2014; Ghilic-Micu in drugi, 2014), ali pa jo upravljata
oba hkrati. Fizično se infrastruktura lahko nahaja v okolju podjetja oziroma pri ponudniku
računalništva v oblaku (Mell in Grance, 2011), potrebna pa je višja naložba in bolj
usposobljeno IT osebje (Fernandes in drugi, 2014).
2.5.2 Javni oblak
Podjetja lahko namesto zasebnega oblaka uporabljajo javni oblak in vse njegove
funkcionalnosti. To pomeni, da uporabljajo storitve drugega podjetja, ki ponuja svoje storitve
tudi uporabnikom izven podjetja. Javni oblak predstavlja možnost znižanja stroškov, saj za
svoje storitve izkoriščajo zunanje vire (angl. Outsourcing) (Frantsvog in drugi, 2012). Do teh
virov lahko hkrati dostopa več različnih podjetij, za uporabo pa plačujejo glede na količino
uporabljenih virov (Bhadauria in drugi, 2014). Zaradi lokacije infrastrukture, ki se nahaja
izven podjetja, ki ga uporablja, se zmanjša varnost podatkov (Fernandes in drugi, 2014).
13
2.5.3 Hibridni oblak
Hibridni oblak je sestavljen iz dveh ali več nadzornih modelov računalništva v oblaku (glej
Sliko 2.2). Prenašanje podatkov med njimi nima medsebojnega vpliva (Bhadauria in drugi,
2014). Z uporabo hibridnega oblaka podjetje doseže sporazum med prihrankom in nadzorom,
pri čemer so večkrat vprašljivi kritični podatki. Le ti se nahajajo na lokalnih zasebnih oblakih
(Frantsvog in drugi, 2012).
Slika 2.2: Sestava hibridnega oblaka
Vir: Marolt, lastni prikaz (2015)
2.5.4 Skupnostni oblak
V nekaterih primerih bi podjetja lahko pridobila prednost z uporabo skupnega oblaka. Oblak
bi si delilo več podjetij, v katerega bi vsako prispevalo svoj del infrastrukture. Skupnostni
oblak je lahko sestavljen iz skupka javnih oblakov ali namenskih infrastruktur virov.
Razlikujemo med zasebnim in javnim skupnostnim oblakom. Primer zasebnega skupnostnega
oblaka je skupnostni oblak nekaj manjših podjetij, primer javnega pa fond virov računalništva
v oblaku različnih ponudnikov, iz katerega bi neko podjetje nudilo najem storitev v oblaku
(Frantsvog in drugi, 2012). Skupnostni oblak upravlja skupnost oziroma neko zunanje
podjetje (Ghilic-Micu in drugi, 2014).
2.5.5 Ostali nadzorni modeli
Bervar (2013, str. 5) navaja še dve posebni obliki nadzornega modela, in sicer model
posredovanja do ponudnikov računalništva v oblaku (angl. Cloud Brokerage) in model
14
razširjanja v javni oblak (angl. Cloudbursting). Pri posredovanju do ponudnikov računalništva
v oblaku posrednik (angl. Cloud broker) posreduje storitve najprimernejšega ponudnika
storitev v oblaku. V primeru razširjanja v javni oblak uporabnik uporablja javni oblak kot
rezervo v primeru, ko primanjkuje virov v zasebnem oblaku. Pogosto je to kar običajen
hibridni oblak, pri katerem je zasebnemu oblaku dodan javni oblak (Heckel v Ghormley 2012,
str. 20).
V literaturi je omenjen tudi model navideznega zasebnega oblaka, ki je ustvarjen s
povezljivostjo navideznega zasebnega omrežja (angl. Virtual Private Network). Uporabniku je
s to tehnologijo mogoče dodeliti izolirane vire (Fernandes in drugi, 2014).
2.6 Prednosti in priložnosti
Podjetja se odločajo za prehod s tradicionalnega računalništva zaradi številnih konkurenčnih
prednosti računalništva v oblaku (Corkern in drugi, 2015). Z razvojem računalništva v oblaku
in zrelostjo uporabnikov so te prednosti še izrazitejše. Med ključnimi prednostmi so
največkrat omenjene boljša razširljivost, hitrejši dostop do infrastrukture, višja
razpoložljivost, hitrejši čas do splavitve produkta na trg, učinkovitost IT osebja, geografski
doseg, neprekinjenost poslovanja, višja zmogljivost, znižanje stroškov in prehod iz naložbenih
v operativne izdatke. Prav slednja prednost je v primerjavi z letom 2014 največ pridobila
(RightScale 2015, str. 19). Velika začetna naložba v zanesljivo IT storitev je ustavila mnoge
perspektivne podjetnike še pred začetkom poslovanja. Računalništvo v oblaku jim ponuja
možnost preizkusiti ideje brez velikih naložbenih izdatkov v infrastrukturo (Srinivasan, 2013)
in znižuje ovire do sprememb. To so dobro izkoristile nekatere spletne aplikacije, kot sta
Facebook in Youtube (Marston in drugi, 2011). V nasprotju s tradicionalnim računalništvom
podjetjem ni potrebno plačevati neuporabljenih virov (Hofman in Woods, 2010). To lahko
izkoristijo predvsem zagonska podjetja (angl. Startup Companies), za katere je lahko ena
izmed prednosti tudi ta, da v ozadju ne potrebujejo razumevanja infrastrukture (Frantsvog in
drugi, 2012). Prav tako jim ni potrebno vzdrževati infrastrukture, zanjo namreč skrbi
ponudnik storitev računalništva v oblaku. IT osebje podjetja se lahko osredotoči na
pomembnejše procese, kar dviguje učinkovitost (Muir v Ahuja in drugi 2012, str. 13). Z
uporabo računalništva v oblaku se zmanjša tudi potreba po izkušenemu IT osebju, ki bi
vzdrževalo infrastrukturo, kar je pomembno predvsem za podjetja na območjih, kjer je
primanjkljaj takega osebja (Luftman in Zadeh v Venters in Whitley 2012, str. 182). Ponudniki
15
storitev ves čas nadgrajujejo svojo opremo, zato se zmanjša tudi tveganje tehnološke
zastarelosti virov, obenem pa ohranja konkurenčnost (Vaquero in drugi v Trigueros-Preciado
in drugi 2013, str. 107; Velte in drugi v Trigueros-Preciado in drugi 2013, str. 107; Marston in
drugi v Trigueros-Preciado in drugi 2013, str. 107; Ma v Trigueros-Preciado in drugi 2013,
str. 107).
Vsi nadzorni modeli ne ponujajo vseh prednosti. Prednosti, ki so značilne tako za javni kot
zasebni oblak, so visoka učinkovitost, visoka razpoložljivost, elastična razširljivost in hitra
uvedba. Samo za javni oblak so značilni nizki začetni stroški oziroma naložbeni stroški,
ekonomija obsega, lažje upravljanje in prehod iz naložbenih v operativne stroške. Na drugi
strani je samo za zasebni oblak značilen večji nadzor nad varnostjo, skladnostjo in kakovostjo
storitev, lažje povezovanje in manjši celotni stroški lastništva (angl. Total Cost of Ownership)
(Arutyunov, 2012).
Sommer in Subramanian (2013, str. 62) sta v raziskavi štirih uveljavljajočih podjetij ugotovila
naslednje ključne prednosti:
- zmanjšanje stroškov,
- izboljšanje razširljivosti virov,
- hitra namestitev,
- izboljšana prilagodljivost,
- povezljivost in upravljanje na voljo 24/7,
- izboljšana varnost,
- povečana možnost sodelovanja pri delu,
- razpoložljivost redundantnih (angl. Redundant) podatkovnih baz na zahtevo,
- boljša učinkovitost in
- razpoložljivost ponudnikov računalništva v oblaku.
Lixăndroiu in Maican (2014, str. 40−41) navajata naslednje prednosti:
- zmanjšanje začetnega vložka v infrastrukturo,
- zmanjšanje stroškov za licence programske opreme,
- plačilo glede na porabo,
- povečana storilnost osebja,
16
- zmanjšanje potrebe po osebju in izobraževanju osebja,
- povečano sodelovanje,
- učinkovitejše nadzorovanje načrtov,
- poenostavitev procesov,
- dostopnost do virov od koderkoli in kadarkoli,
- mobilnost osebja,
- izboljšana prilagodljivost,
- izboljšana varnost,
- možnost izdelave varnostnih kopij in
- večja konkurenčnost zaradi uporabe boljših virov.
Največkrat omenjene prednosti in priložnosti so zmanjšanje stroškov, izboljšana varnost in
doseganje visoke razpoložljivosti. Primere podjetij, ki bi s prehodom lahko zmanjšala stroške
informacijske tehnologije, najdemo v vseh panogah. Tako bi na primer zdravstvena podjetja z
medsebojnim sodelovanjem in deljenjem informacij skozi skupnostni oblak zmanjšala stroške
in obenem izboljšala svoje storitve (Ahuja in drugi, 2012). O zmanjšanju stroškov razmišljajo
tudi države. Velika Britanija je leta 2011 ocenila, da bi s prehodom na računalništvo v oblaku
prihranila 1,4 milijarde angleških funtov (Maude v Venters in Whitley 2012, str. 180).
Najdemo tudi podjetja, ki so prehod že opravila in dosegla zmanjšanje stroškov. Primer
uspeha na področju zmanjšanja stroškov je spletna podatkovna baza z informacijami o filmih
IMDB (Internet Movie Database), ki je po prehodu zmanjšala stroške, obenem pa pohitrila
delovanje storitve (IMDB v Aleem in Sprott 2012, str. 9). Govora je tudi o izboljšanju
varnosti, kjer je mišljeno varovanje podatkov. Podjetja se pogosto srečujejo s težavo
zagotavljanja ohranitve podatkov pri podjetju. Podatki se običajno nahajajo na mnogo
različnih napravah, ki jih uporabljajo zaposleni, zato je prednost računalništva v oblaku tudi
centralizacija podatkov (Chakravarthy in Kannan, 2014). Kot ena izmed glavnih prednosti se
omenja tudi visoka razpoložljivost storitev. Ponudniki običajno dosegajo visoke
razpoložljivosti, kar pomeni razpoložljivost nad 99,999 % časa, kar je za podjetja pomembno,
saj lahko izpadi delovanja ogrozijo celoten poslovni proces podjetja (Corkern in drugi, 2015).
2.7 Slabosti in tveganja
Kljub mnogim prednostim, ki jih prinaša računalništvo v oblaku, se je potrebno zavedati tudi
tveganj ob prehodu s tradicionalnega računalništva. Tveganje predstavljajo dogodki, ki imajo
17
nezaželene posledice oziroma učinek na podjetje (Dutta in drugi, 2013). Podjetja morajo še
pred prehodom na storitve računalništva v oblaku razmišljati in razumeti kakšna tveganja in
izzive poleg prednosti prinaša prehod s tradicionalnega računalništva (Corkern in drugi,
2015).
Tveganja lahko v grobem razvrstimo v štiri kategorije, in sicer med (Dutta in drugi, 2013):
- organizacijska tveganja (angl. Organisational Risks),
- operativna tveganja (angl. Operational Risks),
- tehnična tveganja (angl. Tehnical Risks) in
- pravna tveganja (angl. Legal Risks).
Prehod na računalništvo v oblaku lahko močno vpliva na različne organizacijske vidike, med
katerimi so predvsem način upravljanja z informacijsko tehnologijo, doseganje skladnosti s
predpisi, ki jih narekuje industrija, obstoječe IT osebje, doseganje neprekinjenosti poslovanja
in načrtovanje v primeru težav (Dutta in drugi, 2013). Tveganja, ki se navezujejo na
organizacije, so:
- izguba nadzora nad IT infrastrukturo,
- nezagotavljanje skladnosti z industrijskimi predpisi (Chaput in Ringwood v Dutta in
drugi 2013, str. 41),
- nezmožnost načrtnega pregleda IT (Onwubiko v Dutta in drugi 2013, str. 41),
- neupoštevanje varnostnih predpisov uporabnika s strani ponudnika (Williams v Dutta
in drugi 2013, str. 41),
- zmanjšanje potrebe po notranjem IT osebju,
- nesposobnost prilagoditve IT osebja novim nalogam,
- izguba izkušenih IT strokovnjakov,
- pomanjkanje nadzora nad IT strokovnjaki ponudnika (Bannerman v Dutta in drugi
2013, str. 41),
- možnost prenehanja obratovanja ponudnika zaradi stečaja (Onwubiko v Dutta in drugi
2013, str. 41),
- težko prehajanje med ponudniki oziroma omejitev na ponudnika (Armbrust in drugi,
2010),
18
- pomanjkanje učinkovitih orodij za oceno tveganj (Fito in Guitart v Dutta in drugi
2013, str. 41) in
- pomanjkanje načrta obnove po katastrofi in načrta kriznega stanja v primeru
nepričakovanih tehničnih težav (Rochwerger in drugi v Dutta in drugi 2013, str. 41).
Operativna tveganja so tveganja, ki vplivajo na vsakodnevno poslovanje podjetja. Kažejo se v
obliki vprašanj o sporazumu o ravni storitev (angl. Service Level Agreement), o financah,
podatkih, uporabnikih in zanesljivosti storitev (Dutta in drugi, 2013). Operativna tveganja so:
- slabo opredeljen sporazum o ravni storitev med ponudnikom in uporabnikom,
- nezmožnost zagotavljanja dogovorjene ravni storitev (Rochwerger in drugi v Dutta in
drugi 2013, str. 41),
- povečanje skritih stroškov,
- proračunski primanjkljaj (Mather in drugi v Dutta in drugi 2013, str. 41),
- nezmožnost premeščanja podatkov med ponudniki (Goyal v Dutta in drugi 2013, str.
41),
- zahtevna vrnitev z računalništva v oblaku na tradicionalno računalništvo (Armbrust in
drugi, 2010),
- nasprotovanje zaposlenih prehodu na računalništvo v oblaku (Ali v Dutta in drugi
2013, str. 41),
- pomanjkanje usposabljanja uporabe storitev računalništva v oblaku (Hayes v Dutta in
drugi 2013, str. 41),
- nedosegljivost storitev (Williams v Dutta in drugi 2013, str. 41) in
- dodeljevanje neprimernih količin virov (Mather in drugi v Dutta in drugi 2013, str.
41).
Do tehničnih tveganj prihaja zaradi zapletene infrastrukture in predhodnega pomanjkanja
informacijske tehnologije v podjetju. Največ vprašanj se pojavlja v povezavi s kakovostjo,
vzdrževanjem, zmogljivostjo in varnostjo (Dutta in drugi, 2013), in sicer :
- razdrobljenost in možnost izgube podatkov zaradi uporabe več aplikacij (Armbrust in
drugi, 2010),
- težave z obdelavo podatkov zaradi zapletenih metod upravljanja s podatki (Goyal v
Dutta in drugi 2013, str. 41),
19
- pomanjkanje nadzora nad odpravljanjem napak (angl. Debugging) in preizkušanjem
aplikacij (Rimal v Dutta in drugi 2013, str. 41),
- manjša zmogljivost zaradi vpliva hitrosti omrežja, velikosti podatkovne baze in
sposobnosti strojne opreme (Mather in drugi v Dutta in drugi 2013, str. 41),
- prehod vodi v višjo uporabo virov in višje operativne stroške obstoječih aplikacij,
- starejši sistemi in aplikacije niso ustrezno podprte v novih aplikacijah v oblaku
(Bannerman v Dutta in drugi 2013, str. 41),
- podatki in aplikacije so izolirane in neustrezno integrirane (Govindarajan v Dutta in
drugi 2013, str. 41),
- nepooblaščen dostop do podatkov in aplikacij podjetja (Morrow v Dutta in drugi 2013,
str. 41),
- ponudniki uporabljajo neučinkovite metode kodiranja za zaščito podatkov (Mather in
drugi v Dutta in drugi 2013, str. 41) in
- pojavijo se lahko napadi zavrnitve storitve (angl. Denial of Service) (Armbrust in
drugi v Dutta in drugi 2013, str. 41).
Zadnja kategorija tveganj so pravna tveganja, ki se navezujejo na zasebnost podatkov,
intelektualno lastnino in pogodbo med ponudnikom in uporabnikom (Dutta in drugi, 2013).
Gre za sledeča tveganja:
- ogroženost zasebnosti podjetja in uporabnikovih podatkov,
- razlike v zakonih varovanja podatkov v različnih državah, kjer se nahajajo podatki
(Armbrust in drugi, 2010),
- arhitektura oblaka ni sposobna zagotoviti zahtevanih predpisov zasebnosti in zaščite
podatkov (Abadi v Dutta in drugi 2013, str. 41),
- neustrezno deljenje IT virov preko oblaka povečuje vprašanja glede intelektualne
lastnine (Jaeger in drugi v Dutta in drugi 2013, str. 41),
- pravni spori glede lastništva intelektualne lastnine (npr. podatkov in programske
opreme) med ponudnikom in uporabnikom (Catteddu in Hogben v Dutta in drugi
2013, str. 41),
- slabo sestavljena pogodba, ki ne odraža vseh podrobnosti sporazuma o ravni storitev
(Mather in drugi v Dutta in drugi 2013, str. 41) in
- težave z vračilom podatkov in ponovno vzpostavitvijo po koncu pogodbe s trenutnim
ponudnikom (Joint in Baker v Dutta in drugi 2013, str. 41).
20
Tudi o tveganjih računalništva v oblaku je bilo izvedenih več raziskav. Leta 2009 je bila
izvedena raziskava, v kateri je 244 IT strokovnjakov kot največja tveganja opredelilo varnost
(87,5 % vprašanih), razpoložljivost (83,3 %), zmogljivost (82,9 %), možnost višjih stroškov
(81 %), pomanjkanje standardov združljivosti (80,2 %), zahtevna vrnitev na tradicionalno
računalništvo (79,8 %), zahtevna integracija z obstoječo infrastrukturo (76,8 %) in premalo
možnosti prilagajanja (76 %) (Balding v Nicho in Hendy 2013, str. 161). V raziskavi leta
2013, v kateri je sodelovalo 39 IT strokovnjakov, so se za največja tveganja izkazali
ogroženost zasebnosti podjetja in uporabnikovih podatkov, razlike v zakonih varovanja
podatkov v različnih državah, težko prehajanje med ponudniki (angl. Vendor Lock-in),
pomanjkanje načrta obnove po katastrofi (angl. Disaster Recovery plan), pomanjkanje načrta
kriznega stanja (angl. Contingency plan), težave z vračilom podatkov in ponovno
vzpostavitvijo po koncu pogodbe, pomanjkanje usposabljanja uporabe storitev, nedosegljivost
storitev, povečanje skritih stroškov, napadi zavrnitve storitve in nepooblaščen dostop do
podatkov in aplikacij podjetja (Dutta in drugi 2013, str. 44). V poročilu ponudnika storitev
računalništva v oblaku RightScale so se za največja tveganja izkazali varnost (28 %
vprašanih), pomanjkanje virov in strokovnega znanja (27 %), skladnost (angl. Compilance)
(25 %), upravljanje s številnimi storitvami oblaka (25 %), upravljanje s stroški (24 %),
upravljanje (angl. Governance) oziroma nadzor (23 %) in zmogljivost (17 %). Večina izmed
teh tveganj je pridobila na pozornosti v primerjavi z letom 2015. Z zrelostjo uporabe
računalništva v oblaku tveganja ostajajo, znižuje pa se njihova pomembnost (RightScale
2015, str. 20).
3. VISOKA RAZPOLOŽLJIVOST
Uporaba računalništva v oblaku v primerjavi s tradicionalnim računalništvom prinaša tako
prednosti kot tudi slabosti. V nekaterih primerih lahko lastnost označimo kot prednost in
slabost hkrati, saj nismo prepričani, kako jo zagotoviti v praktični uporabi. Ena izmed večkrat
omenjenih prednosti, pri kateri se sprašujemo, kako jo zagotoviti in ali tudi v praksi prinaša
prednost, je zagotavljanje visoke razpoložljivosti storitev računalništva v oblaku. Literatura
omenja visoko razpoložljivost kot prednost (Arutyunov, 2012; Corkern in drugi, 2015;
Balding v Nicho in Hendy 2013, str. 161) in kot slabost (Williams v Dutta in drugi 2013, str.
21
41). Ko se odločamo o prehodu na novejšo tehnologijo, jo primerjamo z obstoječo in si
želimo, da je v vseh pogledih boljša ali pa vsaj enakovredna trenutni. Podjetja ob vsakem
izpadu poslovanja beležijo izpad prihodka, posledično izpad dobička in navsezadnje lahko
izgubijo tudi stranke. Doseganje visoke razpoložljivosti je zato pomembno za podjetja, prav
tako pa mora biti glavna skrb ponudnikov storitev računalništva v oblaku.
V naslednjem poglavju bomo opredelili pojma razpoložljivost in visoka razpoložljivost.
Seznanili se bomo s sporazumom o ravni storitve in ciljih ravni storitve na področju
razpoložljivosti. Pregledali bomo cilje ravni storitve glede razpoložljivosti storitev pri štirih
ponudnikih z največjim tržnim deležem in dveh ponudnikih, ki imata opredeljene posebne
cilje razpoložljivosti. Za te ponudnike bomo pregledali, kolikšno stopnjo razpoložljivosti
dosegajo v praksi. Nato bomo pregledali odmevnejše izpade delovanja, opisali njihove vzroke
in ugotovili, kako ti izpadi delovanja vplivajo na vpletene. Na koncu bomo pregledali možne
rešitve za doseganje visoke razpoložljivosti.
3.1 Opredelitev
Ko govorimo o razpoložljivosti računalništva v oblaku, mislimo na to, koliko časa so
dosegljivi sistemi ter strojna in programska oprema, ki zagotavljajo storitve računalništva v
oblaku (Ahuja in Mani, 2012). Razpoložljivost je lastnost dostopnosti in uporabnosti na
zahtevo pooblaščenega uporabnika. Je ena izmed ključnih lastnosti, saj opisuje, ali so storitve
računalništva v oblaku na voljo in uporabne (Digital Agenda for Europe, 2014),
razpoložljivost storitev ponudnika pa vpliva na razpoložljivost produktov uporabnika (Shah in
Anandane, 2013). Visoka razpoložljivost je torej sposobnost zagotavljanja neprekinjenega
delovanja storitev računalništva v oblaku (Zimory, 2012). Predvsem je pomembno, da storitev
ostane razpoložljiva ob prisotnosti programske ali strojne okvare (Minhas, 2013). Izpadi
delovanja storitev imajo negativen učinek na uporabnike (Yoo, 2011), saj jim prinašajo
zmanjšanje prihodkov. Manjša in srednja podjetja zaradi izpadov delovanja na leto izgubijo
približno 1 % prihodka (Infonetics v Minhas 2013, str. 2), med 40 in 50 % podjetij pa se
nikoli ne vrne v stanje pred velikim izpadom delovanja (Dell v Minhas 2013, str. 2). V letu
2007 je bila skupna izguba podjetij zaradi prekinitev delovanja ocenjena na 140 milijard
ameriških dolarjev (Rackspace, 2010). V nekaterih primerih lahko nekajurna prekinitev
delovanja prinese izgubo več sto tisoč dolarjev (Ahuja in Mani, 2012), za storitve ponudnika
Amazon pa je bila za vsako sekundo nedosegljivosti storitev ocenjena izguba več kot 1000
22
dolarjev (King, 2013). Da je področje doseganja razpoložljivosti potrebno raziskovati, kažejo
tudi novosti v računalništvu v oblaku, saj je to področje eno izmed tistih, kjer je premalo
novosti (Khansa in Zobel, 2014).
Pojavlja se tudi razkorak med ponudnikom in uporabnikom storitve glede pričakovanj o
razpoložljivosti. Zaradi nezadostne raziskave trga ima lahko ponudnik napačno predstavo o
pričakovanju uporabnikov. Ponudnik poskuša zadovoljiti določeno razpoložljivost, medtem
ko je dejanska skrb uporabnikov največji možen čas nedosegljivosti storitve (Mendes in drugi,
2013). Pogostost prekinitev delovanja naj ne bi bil ključni dejavnik za odločitev proti prehodu
na storitve v oblaku, dokler je sprejemljiva. Vprašanje ni, kateri je najboljši ponudnik, temveč
kakšna meja te pogostosti je še sprejemljiva za uporabnike (Berkholz v Butler 2015).
Uporabniki morajo biti prepričani, da je doseganje visoke razpoložljivosti ključna skrb
ponudnikov (Venters in Whitley, 2012).
Običajno je razpoložljivost storitev računalništva v oblaku izražena s številčno vrednostjo
(Digital Agenda for Europe, 2014). O visoki razpoložljivosti govorimo, če so storitve na voljo
99,999 % časa, kar izhaja iz klasične telefonije. Ožičena telefonska infrastruktura je
zagotavljala 99,999 % razpoložljivost, kar je v praksi pomenilo, da je bilo neuspešnih le nekaj
klicev, med seboj pa niso bili povezani. Razpoložljivosti 99,999 % pravimo tudi
razpoložljivost »petih devetk« (Agapi in drugi, 2011). Potrebno je razumeti, koliko časa je
lahko storitev v primeru nenapovedanega izpada delovanja nedosegljiva. Primer 99 % stopnje
razpoložljivosti pomeni, da je lahko storitev nedosegljiva največ 1 % časa. Na letni ravni je
lahko storitev nedosegljiva največ 3,65 dneva, v enem tednu največ 1,68 ure in največ 14,4
minute na dan (Prasad, 2012). V Tabeli 3.1 so prikazani dovoljeni časi nedosegljivosti na
letni, tedenski in dnevni ravni v primeru različnih ciljev razpoložljivosti.
23
Tabela 3.1: Dovoljen čas nedosegljivosti v primeru različnih ciljev stopnje razpoložljivosti
Stopnja
razpoložljivosti
Dovoljena
nedosegljivost na
leto
Dovoljena
nedosegljivost na
teden
Dovoljena
nedosegljivost na
dan
90 % 36,5 dneva 16,8 ure 2,4 ure
95 % 18,25 dneva 8,4 ure 1,2 ure
98 % 7,3 dneva 3,36 ure 28,8 minute
99 % 3,65 dneva 1,68 ure 14,4 minute
99,5 % 43,92 ure 50,4 minute 7,2 minute
99,8 % 17,52 ure 20,16 minute 2,9 minute
99,9 % 8,76 ure 10,1 minute 1,4 minute
99,95 % 4,38 ure 5,04 minute 42,3 sekunde
99,99 % 52,26 minute 1,01 minute 8,7 sekunde
99,999 % 5,26 minute 6,05 sekunde 0,86 sekunde
99,9999 % 31,5 sekunde 0,605 sekunde 0,086 sekunde
Vir: Prirejeno po Prasad (2012, str. 38)
Uporabniki storitev računalništva v oblaku se močno zanašajo na ponudnike, da jim
zagotavljajo računalniške zmogljivosti. V namen zagotavljanja storitev uporabnik s
ponudnikom podpiše sporazum o ravni storitve, v katerem je običajno navedena tudi stopnja
razpoložljivosti (Ahuja in Mani, 2012).
3.2 Sporazum o ravni storitve
3.2.1 Opredelitev
Sporazum o ravni storitve (angl. Service Level Agreement) je pravni dogovor med
ponudnikom in uporabnikom storitve računalništva v oblaku (Kandukuri in drugi v Alam in
drugi 2013, str. 118). Uporabnikom prinaša jamstvo o zagotavljanju storitve (Okezie in drugi,
2012), dobro sestavljen sporazum pa je koristen tako za uporabnike kot ponudnika (ICASA v
Farah 2013, str. 21). Na sporazum o ravni storitve lahko gledamo kot na mehanizem, ki
zagotavlja najmanjše zahteve, med drugim zahtevano razpoložljivost storitve in osnovne
varnostne postopke (Kandukuri in drugi v Gonzalez in drugi 2012, str. 3).
24
V sporazumu o ravni storitve najdemo cilje ravni storitve (angl. Service Level Objective) na
področjih zmogljivosti, varnosti, upravljanja s podatki in zaščite osebnih podatkov. Na
področju zmogljivosti so zapisane informacije o razpoložljivosti, odzivnosti in zmogljivosti
storitve. Omenjena je tudi podpora s strani ponudnika in možnost dostopa do podatkov
uporabnika. Na področju varnosti najdemo podatke o zanesljivosti storitve, njenem
spremljanju in nadzorovanju, postopkih potrjevanja verodostojnosti, šifriranju podatkov,
upravljanju in poročanju o varnostnih incidentih, preverjanju varnosti in upravljanju
ranljivosti. V delu sporazuma, kjer so zapisani cilji upravljanja s podatki, so informacije o
razvrščanju, zrcaljenju, varnostni kopiji ter obnovi podatkov, njihovem življenjskem ciklu in
prenosljivosti. V kolikor je ponudnik tudi pogodbeni obdelovalec podatkov, so običajno
zapisani tudi cilji zaščite osebnih podatkov. Med njimi najdemo različne kodekse ravnanja,
standarde in mehanizme potrjevanja, opredelitev namena obdelave in zmanjšanje količine
podatkov takoj, ko niso več relevantni. Zapisan mora biti tudi cilj o odgovornosti in
geografski lokaciji podatkov (Digital Agenda for Europe, 2014).
3.2.2 Razpoložljivost v sporazumu o ravni storitve
Razpoložljivost je v sporazumu o ravni storitve zajeta na splošni ravni. Sporazum mora čim
natančneje opredeliti razpoložljivost, saj je lahko storitev na voljo in je dosegljiva, vendar je
lahko zmogljivost tako slaba, da storitev ni uporabna, prav tako pa se lahko pojavijo napake.
Z obzirom na možnosti, ko je storitev lahko razpoložljiva, vendar neuporabna, lahko
opredelimo naslednje relevantne cilje ravni storitve:
- raven dosegljivosti (angl. Uptime),
- odstotek uspešnih zahtevkov in
- odstotek pravočasno obdelanih zahtevkov (Digital Agenda for Europe, 2014).
Raven dosegljivosti je velikokrat opredeljen kot razpoložljivost in opisuje odstotek časa, ko je
bila v določenem obdobju storitev dosegljiva. Potrebno je vedeti, da v ta čas ni zajeto
obdobje, ko potekajo vzdrževalna dela. Raven dosegljivosti lahko zato izračunamo kot celoten
možen čas dosegljivosti storitve brez celotnega časa, ko storitev ni bila dosegljiva in brez
časa, ko storitev ni bila dosegljiva zaradi vzdrževanja. Odstotek uspešnih zahtevkov opisuje
odstotek uspešno in brez napak obdelanih zahtevkov, odstotek pravočasno obdelanih
25
zahtevkov pa odstotek zahtevkov, ki so bili obdelani v vnaprej določenem časovnem obdobju
(Digital Agenda for Europe, 2014).
3.2.3 Razpoložljivost v sporazumu o ravni storitve ponudnikov
V pogodbi med ponudnikom in uporabnikom storitve, torej sporazumu o ravni storitve, imajo
ponudniki običajno zapisano tudi razpoložljivost, ki jo ponujajo. V večini zagotavljajo
razpoložljivost nad 99 % časa, pri tem pa imajo navedene tudi različne pogoje o času
razpoložljivosti, predvsem kakšne so posledice v primeru nedoseganja obljubljenih stopenj
razpoložljivosti.
Največ pozornosti na vseh področjih storitev računalništva v oblaku so deležni ponudniki z
največjim tržnim deležem. V letu 2014 je bil z 28 % tržnim deležem na vrhu Amazon, sledili
pa so mu Microsoft z 10 %, IBM s 7 % in Google s 5 % (Synergy Research, 2015a). V letu
2015 se njihova rast nadaljuje, skupaj pa so v drugem četrtletju leta 2015 obvladovali 54 %
trga (glej Sliko 3.1), več kot vsi preostali ponudniki (Synergy Research, 2015b). V
nadaljevanju bomo opisali nekaj njihovih storitev, cilje razpoložljivosti v sporazumu o ravni
storitve in posledice neizpolnjevanja postavljenih ciljev. Zajete so storitve, za katere so na
voljo podatki o dejanski razpoložljivosti, podatki pa so pridobljeni s strani neodvisnega
podjetja CloudHarmony.
Slika 3.1: Rast prihodkov ponudnikov
Vir: Synergy Research (2015b)
26
Amazon Elastic Compute Cloud oziroma Amazon EC2 je spletni servis, ki zagotavlja
računske zmogljivosti v oblaku. V smislu razpoložljivosti zagotavlja 99,95 % razpoložljivost
med vsakim mesečnim obračunskim obdobjem. V primeru neizpolnjevanja cilja
razpoložljivosti so uporabniki v naslednjem obračunskem obdobju upravičeni do povrnitve
določenega odstotka stroška. V primeru razpoložljivosti, nižje od zagotovljenih 99,95 % in
višje ali enake 99 %, so uporabniki upravičeni do povrnitve 10 % stroškov, v primeru, ko je
dosežena razpoložljivost nižja od 99 %, pa so upravičeni do povrnitve 30 % stroškov. V čas
nedosegljivosti storitve se ne šteje, če je uporabnik kršil pogoje in mu je bila zaradi tega
storitev začasno onemogočena, če so bili za nedosegljivost krivi zunanji dejavniki ali oprema
uporabnika ter obdobje rednega in napovedanega vzdrževanja opreme ponudnika. V čas
nedosegljivosti se šteje čas, ko vse delujoče instance nimajo zunanje povezljivosti, pri tem pa
mora biti nedosegljivo več kot eno razpoložljivostno območje (angl. Availability Zone), v
katerem delujejo zakupljene instance (Amazon EC2).
Amazon Simple Storage Service oziroma Amazon S3 zagotavlja shrambo. Storitev lahko
uporabljamo kot samostojno oziroma jo uporabljamo v povezavi z ostalimi storitvami
ponudnika Amazon. V sporazumu o ravni storitve je zagotovljena 99,9 % razpoložljivost med
vsakim mesečnim obračunskim obdobjem, prav tako pa so uporabniki upravičeni do
povrnitve v primeru neizpolnjevanja cilja razpoložljivosti. V kolikor je razpoložljivost nižja
od zastavljene in hkrati enaka ali višja od 99 %, so uporabniki upravičeni do 10 %, v primeru
nižje od 99 % pa do 25 % povrnjenih stroškov. Čas nedosegljivosti je izračunan na podlagi
stopnje napak v petminutnih obdobjih, v katere se ne štejejo napake zaradi zunanjih
dejavnikov, na katere ponudnik nima vpliva (Amazon S3).
Microsoft Azure Virtual Machines je storitev, ki ponuja poganjanje virtualnih naprav z
operacijskim sistemom Windows ali Linux. Storitev zagotavlja 99,95 % razpoložljivost. V
primeru razpoložljivosti, nižje od zagotovljenih 99,95 % in višje ali enake 99 %, so
uporabniki upravičeni do povrnitve 10 % stroškov, v primeru, ko je dosežena razpoložljivost
nižja od 99 %, pa so upravičeni do povrnitve 25 % stroškov. Da je uporabnik upravičen do
povračila, mora poganjati dve ali več napravi na različnih lokacijah, ki jih ponuja ponudnik,
nedosegljivost pa se šteje, ko ni mogoča zunanja povezljivost. Prav tako kot ostali ponudniki
tudi Microsoft iz časa nedosegljivosti izključuje čas, ko so za to krivi zunanji dejavniki
(Microsoft Azure Virtual Machines).
27
Microsoft Azure Object Storage zagotavlja uporabnikom shrambo. Cilj glede razpoložljivosti
se razlikuje glede na to, za katero možnost redundance se odloči uporabnik. Najnižja stopnja
razpoložljivosti, ki jo zagotavlja storitev, je 99,9 % za branje in pisanje, pri geografski
redundanci, kjer so podatki na sekundarnem podatkovnem centru na voljo za branje in
pisanje, pa je stopnja razpoložljivosti 99,9 % za pisanje podatkov in 99,99 % za branje
podatkov. V vseh primerih so uporabniki upravičeni do povračila stroškov. Uporabnikom je
povrnjenih 10 % stroškov, v kolikor je razpoložljivost storitve nižja od zagotovljene in hkrati
višja ali enaka 99 %. Če je razpoložljivost storitve nižja od 99 %, je povrnjenih 25 % stroškov
(Microsoft Azure Object Storage).
Microsoft Azure Web Apps je storitev za ustvarjanje in nameščanje spletnih aplikacij, katerih
obseg je mogoče spreminjati. Za preizkušanje platforme je mogoče uporabiti brezplačno ali
deljeno stopnjo storitve, ki ne zagotavljata visoke razpoložljivosti oziroma za njiju ni
opredeljen sporazum o ravni storitve. V osnovni in standardni stopnji storitve je zagotovljena
razpoložljivost 99,95 %. V čas nedosegljivosti se štejejo minute, ko povezljivost med spletno
aplikacijo in omrežnim prehodom Microsofta ni mogoča. Če je razpoložljivost nižja od
zagotovljene in višja ali enaka kot 99 %, so uporabniki upravičeni do 10 % povrnjenih
stroškov, v kolikor pa je razpoložljivost nižja od 99 %, so upravičeni do 25 % povrnjenih
stroškov (Microsoft Azure Web Apps).
IBM Bluemix je odprtokodna platforma kot storitev, ki omogoča ustvarjanje, nameščanje in
upravljanje z aplikacijami v oblaku. V sporazumu o ravni storitve razpoložljivost ni
opredeljena (IBM Bluemix).
Google Compute Engine je storitev, ki omogoča uporabnikom, da ustvarijo in poganjajo
navidezne naprave. V sporazumu o ravni storitve je navedena razpoložljivost 99,95 %, enako
kot pri Amazonovi storitvi EC2. V razpoložljivost prav tako niso vključene načrtovane
prekinitve delovanja zaradi vzdrževanja opreme, prav tako pa ne prekinitve krajše od petih
zaporednih minut. V primeru, da je razpoložljivost storitve nižja od zastavljene in hkrati višja
oziroma enaka 99 %, so uporabniki upravičeni do povrnitve 10 %, če je razpoložljivost višja
ali enaka 95 % so upravičeni do 25 %, sicer pa do 50 % povrnjenih stroškov (Google
Compute Engine).
28
Google Cloud Storage ponuja uporabnikom shrambo. Cilj razpoložljivosti je odvisen od
možnosti, ki si jo uporabnik izbere, saj Google ponuja tri različne ravni te storitve. V
standardni obliki je navedena 99,9 % razpoložljivost, v cenejših možnostih pa 99 %.
Uporabniki so z zakupom standardne možnosti storitve upravičeni do 10 % povračila stroškov
v primeru, da je bila storitev razpoložljiva med 90 % in 99,9 %. V primeru razpoložljivosti
med 95 % in 99 % je uporabniku povrnjenih 25 % stroškov, če je razpoložljivost manjša od
95 %, pa do povrnitve polovice stroškov. Pri cenejših možnostih so meje za povrnitev istih
deležev stroškov med 98 % in 99 %, med 95 % in 98 % in pri razpoložljivosti nižje od 95 %
(Google Storage).
Storitev Rackspace Cloud Servers ponuja uporabnikom infrastrukturo, skupaj z vso podporo,
ki jo potrebujejo. V smislu zagotavljanja razpoložljivosti imajo drugačno politiko kot ostali
ponudniki. Zagotavljajo, da bodo storitve na voljo ves čas, prekinitve delovanja pa bodo
trajale manj kot eno uro. Uporabniki so do povračila stroškov upravičeni samo v primeru, da
napaka ni bila odpravljena v eni uri. Če odprava napake traja dlje od ene ure, so uporabniki
upravičeni do povračila 5 % stroškov za vsako dodatno uro nedosegljivosti storitve, povrnjeni
pa so lahko celotni stroški. Eno uro nedosegljivosti na mesečni ravni si lahko predstavljamo
kot 99,861 % razpoložljivost, vendar je lahko tudi manjša, če je teh prekinitev delovanja več.
V primeru petih okvar, od katerih bi vsaka trajala eno uro, bi bila mesečna razpoložljivost
samo 99,3 %, vendar uporabniki zaradi trajanja posamezne prekinitve delovanja ne bi bili
upravičeni do povračila stroškov (Rackspace Cloud Servers).
Finsko podjetje UpCloud je eno redkih, ki s svojo infrastrukturo kot storitvijo zagotavlja 100
% razpoložljivost navideznih strežnikov in omrežja. Uporabniki so upravičeni do povračila
stroškov, v kolikor je storitev nenapovedano nedosegljiva več kot 5 minut. Poleg zagotovitve
delovanja ves čas je posebnost tudi v tem, da je povračilo za čas nedelovanja 50-kratnik
stroška storitve. Za eno obdobje nedosegljivosti je uporabnik upravičen do največ 100 %
povračila stroškov, v celotnem mesečnem obdobju pa do največ 250 % povračila stroškov
(UpCloud). V Tabeli 3.2 so še enkrat zbrani cilji razpoložljivosti v sporazumu o ravni storitve
teh ponudnikov in podatki o tem, koliko časa so lahko storitve nedosegljive v enem dnevu,
mesecu oziroma letu.
29
Tabela 3.2: Cilj razpoložljivosti ponudnikov in dovoljena nedosegljivost storitve
Storitev SLA Dovoljena
nedosegljivost
na leto
Dovoljena
nedosegljivost
na mesec
Dovoljena
nedosegljivost
na dan
Amazon EC2 99,95 % 4,38 ure 5,04 minute 42,3 sekunde
Amazon S3 99,9 % 8,76 ure 10,1 minuta 1,4 minute
Microsoft Azure Virtual
Machines
99,95 % 4,38 ure 5,04 minute 42,3 sekunde
Microsoft Azure Object
Storage
99,9 % 8,76 ure 10,1 minuta 1,4 minute
Microsoft Azure Web
Apps
99,95 % 4,38 ure 5,04 minute 42,3 sekunde
IBM Bluemix / / / /
Google Compute Engine 99,95 % 4,38 ure 5,04 minute 42,3 sekunde
Google Cloud Storage 99,9 % 8,76 ure 10,1 minuta 1,4 minute
Rackspace Cloud Servers 99,861 % 12 ur 1 ura 2 minuti
UpCloud 100 % 0 ur 0 minut 0 sekund
Vir: CloudHarmony (24. avgust 2015)
Na tej točki lahko odgovorimo na eno izmed raziskovalnih vprašanj. Na vprašanje "Kolikšno
stopnjo visoke razpoložljivosti obljubljajo ponudniki storitev računalništva v oblaku?" težko
odgovorimo z enotno številko, saj se obljubljene stopnje visoke razpoložljivosti razlikujejo od
ponudnika do ponudnika in med različnimi storitvami. Za največje ponudnike storitev
računalništva v oblaku, med katere prištevamo Amazon, Microsoft, IBM in Google, lahko
rečemo, da so si dokaj enotni. Pri storitvah, kjer so v ospredju računske zmogljivosti, torej
Amazon EC2, Microsoft Azure Virtual Machines in Google Compute Engine, ponujajo 99,95
% razpoložljivost. To pomeni, da so lahko storitve nedosegljive največ 4,38 ure na letni, 5,04
minute na mesečni in 42,3 sekunde na dnevni ravni. Storitve, v katerih je ponujana shramba,
torej Amazon S3, Microsoft Azure Object Storage in Google Cloud Storage, lahko ponovno
vidimo enotnost med temi ponudniki, vsi trije namreč zagotavljajo 99,9 % razpoložljivost, kar
lahko pretvorimo v 8,76 ur nedosegljivosti na leto. Nekateri drugi ponudniki ne zagotavljajo
visoke razpoložljivosti (IBM), zagotavljajo razpoložljivost njihovih storitev ves čas, ali pa
imajo posebne pogoje. Rackspace ima posebne pogoje, pri čemer ne zagotavlja stopnje
30
razpoložljivosti, ampak obljublja, da so storitve lahko nedosegljive največ eno uro na okvaro,
kar lahko prevedemo v 99,861 % razpoložljivost.
3.2.4 Dejanska razpoložljivost ponudnikov
V sporazumu o ravni storitev je naveden cilj razpoložljivosti, ki si ga je zadal ponudnik
računalništva v oblaku. V primeru neizpolnjevanja zastavljenega cilja ponudniki običajno
ponujajo povrnitev določenega odstotka stroškov storitve (D'Agostino in drugi, 2013). V
kolikor uporabnik resnično potrebuje visoko razpoložljivost, mu povrnjeni stroški ne bodo
dovolj, da se mu povrne izgubljen prihodek v času nedosegljivosti (Hofmann in Woods,
2010).
Kakšna je razpoložljivost v praksi, lahko preverimo pri podjetjih, ki se ukvarjajo z nadzorom
nad storitvami v oblaku. Eno izmed teh podjetij je podjetje CloudHarmony. Razpoložljivost in
tudi nekatere druge parametre spremljajo preko lastnih storitev, ki jih imajo postavljene pri
ponudnikih storitev računalništva v oblaku. Podatki v nadaljevanju so pridobljeni 27. 8. 2015
ob 12.52 in veljajo za obdobje preteklih 30 in 365 dni. Ponudniki svoje storitve ponujajo po
celem svetu, kjer imajo postavljene podatkovne centre. CloudHarmony zbira podatke za vsak
podatkovni center, imamo pa možnost pridobiti tudi podatek o povprečju, kjer so vsi
podatkovni centri iz različnih regij združeni v celoto. Število izpadov in čas nedosegljivosti v
zadnjih 365 dneh veljata za vse njihove regije in vse podatkovne centre v teh regijah skupaj.
Ker ponudniki zagotavljajo razpoložljivost na mesečni ravni, so zanimivi predvsem podatki o
razpoložljivosti v zadnjih 30 dneh, zbrane pa so tudi stopnje razpoložljivosti na letni ravni
(glej Tabelo 3.3).
31
Tabela 3.3: Dejanska razpoložljivost
Storitev Razpoložljivost
v zadnjih 30
dneh
Razpoložljivost
v zadnjih 365
dneh
Število izpadov
v zadnjih 365
dneh
Nedosegljivost v
zadnjih 365
dneh
Amazon EC2 99,9963 % 99,9985 % 15 1,3 ure
Amazon S3 99,9925 % 99,9954 % 57 3,66 ure
Microsoft Azure
Virtual
Machines
99,9968 % 99,9715 % 77 38,61 ure
Microsoft Azure
Object Storage
99,9985 % 99,9914 % 104 9,82 ure
Microsoft Azure
Web Apps
99,997 % 99,9702 % 409 21,82 ure
IBM Bluemix 99,999 % 99,9847 % 40 3,97 ure
Compute Engine
99,9875 % 99,9642 % 103 9,42
Google Cloud
Storage
99,999 % 99,9998 % 13 10,17 minute
Rackspace
Cloud Servers
100 % 99,9832 % 22 9,92 ure
UpCloud
UpCloud
99,9991 % 99,9997 % 2 1,53 minute
Vir: CloudHarmony (24. avgust 2015)
Iz podatkov lahko razberemo, da podjetja dosegajo in presegajo razpoložljivost, zapisano v
sporazumu o ravni storitve. Amazon z obema storitvama dosega razpoložljivost "štirih
devetk", Google pa s storitvijo shrambe Cloud Storage celo razpoložljivost "petih devetk", kar
lahko označimo kot visoko razpoložljivost. Izmed nadzorovanih storitev je Rackspace s
storitvijo Cloud Servers v zadnjih 30 dneh od meritve dosegel 100 % razpoložljivost,
UpCloud pa v zadnjih 365 dneh razpoložljivost višjo kot 99,999 %.
S podatki o razpoložljivosti lahko odgovorimo na raziskovalno vprašanje "Ali ponudniki
storitev računalništva v oblaku dosegajo obljubljene stopnje visoke razpoložljivosti?". Noben
32
ponudnik, tudi največji oziroma tisti z največjim tržnim deležem, ne dosega visoke
razpoložljivosti z vsemi svojimi storitvami. S tem je mišljena visoka razpoložljivost,
opredeljena kot razpoložljivost, ki izhaja iz tradicionalne telefonije, torej razpoložljivost
99,999 %. Izmed raziskanih ponudnikov jo na letni ravni dosegata Google s storitvijo Google
Cloud Storage in UpCloud. Če gledamo razpoložljivost zadnjih 30 dni od dneva pridobitve
podatkov, dosegata visoko razpoložljivost poleg omenjenih tudi IBM s storitvijo Bluemix in
Rackspace s Cloud Servers. Zbrani podatki o stopnji razpoložljivosti so povprečje vseh
podatkovnih centrov ponudnikov v vseh regijah oziroma na vseh lokacijah. Čeprav skupno
gledano kateri izmed ponudnikov ne dosega določene stopnje razpoložljivosti, to ne pomeni,
da niso vsaj nekateri njihovi podatkovni centri zelo visoko razpoložljivi. Z nekaterimi
storitvami v nekaterih podatkovnih centrih dosegajo višje razpoložljivosti kot 99,999 %. V
kolikor gledamo obljubljene stopnje visoke razpoložljivosti v sporazumih o ravni storitve, le
te dosegajo vsi ponudniki, razen UpCloud, ki v sporazumu obljublja 100 % razpoložljivost.
Čeprav je ne dosega, ima na letni ravni razpoložljivost 99,9997 %, kar lahko štejemo kot
visoko razpoložljivost.
3.3 Primeri izpadov delovanja
Prekinitve delovanja storitev niso omejene izključno na računalništvo v oblaku (Gonzalez in
drugi, 2012). Visoki standardi razpoložljivosti, ki so jih postavili ponudniki nekaterih storitev,
so privedli do tega, da vsaka prekinitev delovanja pritegne veliko pozornost s strani medijev
(Hickey v Venters in Whitley 2012, str. 185).
Med najodmevnejše prekinitve delovanja štejemo prekinitve ponudnika storitev Amazon. Z
večjimi prekinitvami delovanja se soočajo od vzpostavitve storitve. Za izgubo podatkov
uporabnikov njihove storitve EC2 leta 2007 je bila kriva programska oprema za upravljanje,
ki je prisilno zaustavila delovanje instanc uporabnikov. Te so bile za uporabnike izgubljene, s
tem pa tudi podatki, ki niso bili ustrezno varnostno kopirani (Miller, 2007), kar je ponudnike
privedlo do tega, da so vzpostavili sporazum o ravni storitve za svojo drugo storitev, Amazon
S3. Naslednja večja prekinitev delovanja je februarja 2008 prizadela storitvi Amazon EC2 in
Amazon S3. Uporabniki so lahko do storitev postopoma dostopali po več kot 3 urah
nedosegljivosti, Amazon pa uporabnikom ni sporočil vzroka nedosegljivosti (Miller, 2008). V
letu 2009 je sledila še ena večja prekinitev delovanja. Zaradi udara strele je bila storitev
Amazon EC2 za del uporabnikov nedosegljiva več kot 4 ure (Miller, 2009), napad
33
porazdeljene zavrnitve storitve (angl. Distributed Denial of Service) pa je za 19 ur
onemogočil uporabo spletne storitve Bitbucket, ki infrastrukturo najema pri Amazonu (Shah
in Anandane, 2013). Ena izmed odmevnejših prekinitev storitve Amazon EC2 se je zgodila
aprila 2011 (Amazon v Srinivasan 2013, str. 59). Vzrok nedosegljivosti storitve je bila napaka
na strani ponudnika, natančneje napaka na programski opremi, ki skrbi za nadzor. Le ta je
nepravilno ocenila, da obstaja pomanjkanje redundance strežnikov in podatkovnih shramb za
zagotavljanje delovanja. Sproženo je bilo avtomatsko premikanje instanc po omrežju. Zaradi
tega je bilo omrežje močno zasedeno s prometom, kar je privedlo do nedosegljivosti storitev,
odprava napake pa je za vse uporabnike trajala 6 dni (Winterford, 2011). Amazon ni edini, ki
se je spopadal s prekinitvami delovanja storitev. Prva prekinitev delovanja storitve
računalništva v oblaku Microsoft je trajala 22 ur (Clarke, 2009). Veliko pozornost je pridobil
tudi ponudnik Google, katerega storitvi AppEngine in Gmail sta bili v letu 2008 nedosegljivi
5 oziroma 1,5 ure (Armbrust in drugi 2010, str. 55).
3.4 Vzroki izpadov delovanja in njihov vpliv
Najpogostejši vzroki za izpade delovanja so (Staplefoote, 2014):
- okvare in prekoračitve zmogljivosti sistemov neprekinjenega napajanja (angl.
Uninterruptible Power Supply),
- nenamerne človeške napake,
- spletni napadi,
- okvare opreme,
- poplave in
- ostale z vremenom povezane razmere.
Glede na omrežje lahko vzroke delimo na notranje in zunanje. Med zunanje vzroke štejemo
okvare omrežja ali napajanja podatkovnih centrov, okvare omrežja, preko katerih se
uporabniki povezujejo s podatkovnim centrom, nepričakovane spremembe nastavitev
uporabnikov, okvara varnostnih kopij izven podatkovnega centra in varnostna vprašanja.
Notranji vzroki se dotikajo okvar strojne opreme strežnikov, spletnih aplikacij, podatkovnih
baz, varnostnih kopij in lokalnega omrežja ter varnostnih vprašanj. Ko pogledamo vzroke
podrobneje, se izpadi delovanja pojavljajo ob raznih okvarah strojne in programske opreme
ter zaradi izkoriščanja varnostnih lukenj. Med okvarami strojne opreme se pojavljajo
34
predvsem okvare centralnih procesnih enot, trdih diskov, sistemov neprekinjenega napajanja,
sistemov za hlajenje, požarnih zidov, stikal in ostalih ključnih komponent. Okvare na
programski opremi se pojavljajo tako na spletnih aplikacijah kot tudi na operacijskih sistemih,
pojavijo pa se tudi človeške napake. V smislu varnostnih vprašanj se lahko pojavijo izpadi
delovanja zaradi izkoriščanja varnostnih lukenj aplikacij, podatkovnih baz in operacijskih
sistemov (Prasad, 2012). V raziskavi zanesljivosti usmerjevalnikov je bila ugotovljena manj
kot 99,9 % razpoložljivost. Glavni vzroki za nedosegljivost usmerjevalnikov so bile napačne
nastavitve, okvare IP usmerjanja in okvare fizične povezave (Agapi in drugi, 2013). Spletni
napadi so širok pojem, največkrat pa se kot glavni vzrok za izpade delovanja zaradi njih
omenja napad porazdeljene zavrnitve storitve (Shah in Anandane, 2013).
Izpadi delovanja vplivajo na končne uporabnike in IT strokovnjake, povzročajo
nezadovoljstvo, prav tako pa vplivajo na stroške. Pogosto vplivajo na stroške, povezane z
zmanjšanjem ugleda, prav tako pa vplivajo na stroške iskanja vzrokov za nedosegljivost in
povrnitev stanja ter stroške, povezane z neupoštevanjem skladnosti. Izpadi delovanja
prinašajo tudi znižanje prihodkov in zmanjšanje storilnosti v podjetju (Staplefoote, 2014).
Vplivajo na pretok denarja, podjetja lahko izgubijo tudi nekatere popuste, v kolikor njihove
storitve niso dosegljive, svoje uporabnike in strateške partnerje. Zaposleni v takem podjetju
niso samo manj storilni, ampak lahko hkrati izgubijo tudi zaupanje v tehnologijo (Dines,
2013).
3.5 Rešitve za doseganje visoke razpoložljivosti
Podatkovni centri so visoko razpoložljivi, ker zagotavljajo redundantnost električne napeljave
in učinkovito hlajenje. Poleg tega sta pomembni elastičnost, kar pomeni, da so viri pravilno
razdeljeni, in redundanca podatkov, ki je narejena s podvajanjem podatkov na drugem
podatkovnem centru ponudnika (Fernandes in drugi, 2014). Nekateri večji ponudniki, kot sta
Google in Amazon, redundanco podatkov zagotavljajo s podatkovnimi centri, ki se nahajajo v
različnih državah oziroma regijah (Zhou in drugi v Fernandes in drugi 2014, str. 130). Izpadi
delovanja v oblaku kažejo na to, da je še vedno potrebno načrtovani za primere katastrof
(KPMG v Oredo in Njihia 2014, str. 157). Vsekakor je potrebno tudi vzpostaviti sporazum o
ravni storitve, ki služi kot garancija, da ponudnik zagotavlja določeno stopnjo razpoložljivosti
(Buyya in drugi v Oredo in Njihia 2014, str. 157).
35
Doseganje visoke razpoložljivosti se začne pri strojni opremi, ki je podlaga računalništva v
oblaku. Če ne deluje strojna oprema, je vseeno kako optimizirano programsko opremo
uporabljamo. Zimory (2012, str. 6−7) predlaga nekaj osnovnih napotkov na poti k visoki
razpoložljivosti:
- blaženje posameznih točk odpovedi,
- uporaba dokazanih komponent,
- izogibanje komponentam brez podpore,
- uporaba na okvaro neobčutljivih komponent ter
- shranjevanje in vzdrževanje nadomestnih komponent.
Čeprav je uporaba enega samega ponudnika storitev računalništva v oblaku vprašljiva v
smislu posameznih točk odpovedi (Armbrust in drugi, 2010), je blaženje le teh vseeno
pomembno. Pomembno je, ker lahko vse vitalne komponente prej ali slej odpovejo.
Posamezne komponente morajo zato biti redundantne. Za grajenje visoko razpoložljivih
sistemov je priporočeno, da se uporablja dokazane komponente, za kar običajno veljajo
komponente, ki so že dlje v uporabi in so zanje napake že znane. Od proizvajalcev teh
komponent potrebujemo daljšo podporo, vsaj za čas življenjske dobe komponent, prav tako pa
tudi nadomestne komponente. Višjo razpoložljivost dosežemo tudi, če je komponente mogoče
zamenjati brez prekinitve delovanja celotnega sistema. Za vitalne komponente potrebujemo
nadomestne komponente, saj jih je v primeru napake potrebno zamenjati v čim krajšem času
(Zimory, 2012).
Visoko razpoložljivost lahko dosežemo na različnih nivojih, na nivoju infrastrukture,
aplikacij, podatkovnih centrov in geografske redundance. Osnovna konfiguracija na nivoju
infrastrukture je sestavljena iz dveh ali več spletnih strežnikov (angl. Web Server), dveh ali
več strežnikov s podatkovno bazo (angl. Database Server) in dveh ali več naprav za
uravnavanje obremenitev (angl. Load Balancer) (glej Sliko 3.2). Naprave za uravnavanje
obremenitev so načrtovane tako, da v primeru odpovedi ene takoj začne z delovanjem druga
naprava. Nastavitev spletnih strežnikov je enostavna, potrebno je le paziti, da je na vseh
spletnih strežnikih zadnja različica spletnih vsebin. Strežniki s podatkovno bazo so lahko
načrtovani na več načinov. Visoko razpoložljivost dosežemo z uporabo podvajanja nadrejeni
– podrejeni (angl. Master-Slave), kjer sta ločena strežnika s podatkovno bazo, pri čemer je en
strežnik za operacije pisanja, drug pa za operacije branja. Pri tem lahko izboljšamo tudi
36
zmogljivost pri zelo prometnih straneh, kjer je veliko branja in pisanja v podatkovno bazo. Z
uporabo takega načina podvajanja podatkovnih baz je običajno potrebno spremeniti tudi nekaj
programske kode obstoječih aplikacij, kar rešuje drug način, ki prav tako uporablja
podvajanja nadrejeni – podrejeni, vendar si pomaga s posredovalnikom (angl. Proxy).
Uporaba tega načina ne dosega načel visoke razpoložljivosti, saj posredovalnik postane
posamezna točka odpovedi. Strežnike s podatkovno bazo lahko postavimo tudi v
konfiguracijo, kjer jr nadrejena podatkovna baza večkrat replicirana, pri tem pa lahko pride do
težav s sinhronizacijo med njimi. Ista težava nas pričaka pri repliciranju med nadrejeno in
podrejeno podatkovno bazo. Pri načinih z repliciranjem se lahko zgodi, da ni možna
sinhronizacija, pri tem repliciranje ne deluje, popravilo take napake pa povzroči
nedosegljivost storitve (Rackspace, 2010).
Slika 3.2: Osnovna konfiguracija za doseganje visoke razpoložljivosti
Vir: Rackspace (2010)
Posamezno podjetje težko odstrani vse posamezne točke odpovedi (angl. Single Point of
Failure), mora prepoznati vsa tveganja in se jih lotiti na pravi način. Prvi korak upravljanja s
tveganji je prepoznava točk, kjer gre lahko kaj narobe. V prejšnjem poglavju so bili našteti
nekateri vzroki izpadov, ki so bili razdeljeni na notranje in zunanje glede na omrežje. Prasad
37
(2012, str. 39−41) navaja, da jih lahko ublažimo s testiranjem, zagotovilom kakovosti,
varnostnimi kopijami, avtomatskim samodejnim preklopom, upravljanjem nadzora nad
dostopom do programske opreme, pregledom programske kode, pogostimi namestitvami
popravkov, zavarovanim objektov, redundantnimi sistemi neprekinjenega delovanja,
nadzorovanjem sistemov, virtualizacijo, redundanco in avtomatskimi opozorili o okvarah
(Prasad, 2012).
Omenjene rešitve za doseganje visoke razpoložljivosti običajno uporabljajo ponudniki storitev
računalništva v oblaku. V kolikor je dosegljivost storitev pomembno za posamezno podjetje,
morajo upoštevati nekatere smernice, s katerimi lahko močno zmanjšajo vpliv izpadov
delovanja (King, 2013):
- potrebno je podpisati sporazum o ravni storitve,
- zavedati se je potrebno obstoja tradicionalnega računalništva, ki je lahko v nekaterih
primerih boljša rešitev od računalništva v oblaku,
- potrebno je načrtovati za primer izpada,
- ovrednotiti je potrebno stroške izpada,
- po izpadu je potrebno ravnati spodbudno, odgovorno in odzivno,
- po izpadu je potrebno oceniti obstoječe IT procese,
- nadzorovati je potrebno notranje in zunanje storitve,
- odstraniti je potrebno zapletenost,
- potrebno je slediti najboljšim praksam in
- potrebno je razumeti tveganja.
4. ŠTUDIJA PRIMERA PODJETJA X
Z vnaprej pripravljenimi okvirnimi vprašanji smo izvedli intervju z zaposlenim in dobili več
podatkov o njihovem podjetju, informacijski tehnologiji, pogledu na računalništvo v oblaku in
vplivu doseganja visoke razpoložljivosti. Intervju smo opravili osebno v podjetju, in sicer z
zaposlenim, ki ima pregled nad celotnim poslovanjem podjetja in celotno informacijsko
tehnologijo, ki jo potrebujejo za poslovanje.
38
4.1 Predstavitev podjetja
Podjetje se ukvarja z razvojem strojne in programske opreme za končnega naročnika. Sedež
podjetja se nahaja v jugovzhodni Sloveniji in velja za mikro podjetje z manj kot 10
zaposlenimi. Strojno in programsko opremo izdelujejo tako za domače kot tudi tuje končne
naročnike.
4.2 Informacijska tehnologija v podjetju
Informacijska tehnologija, ki jo potrebujejo oziroma uporabljajo v podjetju, vključuje
namizne računalnike oziroma prenosnike z nameščenim operacijskih sistemom Windows.
Prav tako uporabljajo paket orodij Microsoft Office, v katerem najdemo tudi orodje Microsoft
Outlook, ki ga uporabljajo za delo z elektronsko pošto. Strežnik za elektronsko pošto imajo v
najemu pri slovenskem ponudniku, pri katerem imajo postavljeno tudi spletno stran podjetja.
Poslovni informacijski sistem, ki ga uporabljajo, je Pantheon in deluje v mreži na eni izmed
naprav v podjetju. Poleg tega imajo v mreži postavljen tudi podatkovni strežnik NAS (angl.
Network Attached Storage), v katerem je več diskov. Da ne bi izgubili podatkov, delujejo v
enem izmed načinov RAID (angl. Redundant Arrray of Independent Disks), kjer se kopije
podatkov hkrati nahajajo na več trdih diskih. Podatkovni strežnik se nahaja v podjetju, vsako
noč pa se izvede tudi zrcaljenje podatkov na tretjo lokacijo, na podatkovni strežnik
partnerskega podjetja. To se nahaja v drugi geografski regiji, kar pomeni tudi geografsko
redundanco, ki je pomembna za primere naravnih ali kakšnih drugih nesreč.
4.3 Računalništvo v oblaku in vpliv visoke razpoložljivosti
V podjetju najamejo strežnik za spletno gostovanje in elektronsko pošto, sicer pa uporabljajo
tradicionalno računalništvo, vključno s podatkovnim strežnikom, ki je postavljen v podjetju.
Za računalništvo v oblaku so že slišali in poznajo njegove prednosti in slabosti. O celotnem
prehodu na računalništvo v oblaku niso nikoli razmišljali, saj imajo zadržke o deljenju
pomembnih podatkov izven podjetja. Ti podatki vključujejo predvsem podatke o poslovanju
in seznam faktur. Za lažje sodelovanje s partnerskimi podjetji so se za del manj občutljivih
podatkov že odločili, da jih delijo na brezplačnih rešitvah. Tudi v nadaljevanju ostajajo
mnenja, da občutljivih podatkov ne bi preselili na oblak, ostale stvari pa bi preselili, v kolikor
bi se izkazala potreba po tem.
39
Kar zadeva razpoložljivost storitev, je zanje najpomembnejše, da so storitve in podatki
razpoložljivi znotraj rednega delavnika. Pomembna je predvsem razpoložljivost ob odpiranju
novih faktur, saj jih pogosto zanimajo pretekle fakture kupca, za kar potrebujejo delovanje
podatkovnega strežnika. Omenili smo, da ponudniki računalništva v oblaku običajno
zagotavljajo določen odstotek razpoložljivosti v sporazumu o ravni storitve. Zanimalo nas je,
ali bi na odločitev o prehodu kakorkoli vplivale obljubljene vrednosti ponudnikov, ki se
večinoma nahajajo v območju 99,9 % oziroma 99,95 % stopnje razpoložljivosti. Podjetje tako
majhnih izpadov, kot sta 1,4 minute na dan pri 99,9 % ter 42,3 sekunde pri 99,95 %
razpoložljivosti, sploh ne bi zaznalo, zato na končno odločitev o prehodu stopnja običajnih
razpoložljivosti ne bi vplivala. Neznatno bi pri odločitvi vplivala tudi razlika med 99,9 % in
100 % razpoložljivostjo, takrat bi postali pomembnejši ostali dejavniki. Za ponudnika, ki v
sporazumu o ravni storitve nima določene stopnje razpoložljivosti, se v podjetju ne bi odločili.
Ker omenjeni ponudnik, ki ne zagotavlja določene stopnje razpoložljivosti na letni ravni,
dosega visoko razpoložljivost 99,999 %, bi zanj pričakovali, da bo imel takšen podatek v
sporazumu.
Običajno bi daljši izpad delovanja za podjetje pomenil resno motnjo, za njihovo podjetje pa
ne bi bil pogubna motnja. Prav tako se v primeru spodrsljaja ponudnika računalništva v
oblaku ne bi takoj odločili za prekinitev pogodbe, saj njihove mrežne povezave niso niti
približno tako zanesljive kot storitve računalništva v oblaku. Če bi zanemarili vse druge
slabosti in tveganja in bi se o prehodu odločali samo na podlagi omenjenih stopenj
razpoložljivosti in primerov daljših izpadov storitve, bi se odločili za prehod na računalništvo
v oblaku, z izjemo občutljivih podatkov. Pravijo tudi, da zanje prehod trenutno ne bi bil
smiseln, saj delujejo krajevno in niso razpršeni na več lokacij. V kolikor bi se podjetje širilo
na več oddaljenih enot, bi se odločili za prehod. Med njihovimi produkti najdemo tudi
avtomate za prodajo različnih izdelkov, ki za delovanje izrablja povezovanje na centralno
bazo. V podjetju so se za primere izpadov delovanja tretjih ponudnikov (naprave namreč
izkoriščajo povezavo z mobilnim spletom) zavarovali tako, da naprava med izpadom deluje
avtonomno. S prehodom na računalništvo v oblaku centralne baze tako ne bi pridobili veliko v
smislu visoke razpoložljivosti, saj so za izpade večinoma krivi dejavniki, na katere ponudniki
storitev računalništva v oblaku nimajo vpliva.
S tem lahko odgovorimo tudi na glavno raziskovalno vprašanje ”Kako doseganje visoke
razpoložljivosti vpliva na prehod s tradicionalnega računalništva na računalništvo v oblaku?”,
40
in sicer doseganje visoke razpoložljivosti vpliva na prehod le v nekaterih primerih. V primeru
intervjuvanega podjetja doseganje oziroma nedoseganje visoke razpoložljivosti ne bi imelo
večjega vpliva na njihovo poslovanje. Razmišljanje o tem bi se v podjetju v prihodnosti
spremenilo, v kolikor bi se podjetje odločilo za širitev. V podjetju trenutno analizirajo, kaj s
poslovnega stališča pomeni prehod v računalništvo v oblaku. Vstopna točka uporabe storitve
računalništva v oblaku se nanaša na potrebe shranjevanja neobčutljivih podatkov. V
nadaljevanju je na osnovi tega narejena stroškovna analiza med lokalno rešitvijo in dvema
rešitvama v oblaku. Prehod ostalih možnosti uporabe storitev računalništva v oblaku je
predmet nadaljnjih analiz in poslovnih korakov.
4.4 Primerjava rešitve lokalno in v oblaku
V podjetju niso občutljivi na občasne izpade delovanja, zato doseganje visoke razpoložljivosti
zanje ni pomembno. Trenutno v podjetju ne dosegajo niti ne potrebujejo visoke
razpoložljivosti. Dovolj jim je razpoložljivost med “dvema devetkama” in “tremi devetkami”,
kar pomeni razpoložljivost med 99 % in 99,9 %. Podjetje bi s selitvijo na storitve
računalništva v oblaku dosegalo in presegalo svoje zahteve glede doseganja stopnje
razpoložljivosti, saj le te za storitve shrambe na oblaku zagotavljajo vsaj 99,9 %
razpoložljivost, v praksi pa dosegajo še višjo stopnjo. V kolikor bi podjetje v prihodnosti
potrebovalo doseganje visoke razpoložljivosti svojih podatkov, jih čaka odločitev, ali
nadaljevati z uporabo tradicionalnega pristopa ali narediti prehod na računalništvo v oblaku.
V nadaljevanju bomo predstavili eno izmed možnih rešitev postavitve podatkovnega strežnika
v lokalnem okolju. Nato bomo ocenili strošek nakupa opreme in ostale stroške, povezane z
delovanjem in vzdrževanjem, ter naredili primerjavo z rešitvijo uporabe računalništva v
oblaku.
Pri izračunu celotnih stroškov lastništva podatkovnega strežnika, ki ga gostimo lokalno, ni
pomembna samo cena samega podatkovnega strežnika, ampak je potrebno upoštevati tudi
nekatere druge dejavnike. Hitra primerjava cene rešitve lokalno in v oblaku nam da samo
približno oceno (glej Sliko 4.1), ki pa je lahko zelo napačna (Reichman, 2011).
41
Slika 4.1: Primerjava stroškov shrambe lokalno in v oblaku
Vir: Prirejeno po Forrester Research, Inc. v Reichman (2011, str. 4)
Upoštevati moramo še ostale dejavnike, ki vplivajo na končno ceno in tudi pripomorejo k višji
razpoložljivosti v lokalni postavitvi podatkovnega strežnika. Ob enaki predpostavki 100 TB
podatkov in treh kopijah podatkov za zagotavljanje čim krajših izpadov delovanja je potrebno
imeti za 300 TB podatkov shrambe. Ker je za uporabo in zagotavljanje kopiranja potrebno
rezervirati še nekaj več prostora, celotni stroški za nakup diskov narastejo na 1.680.000
dolarjev, vračunati pa je potrebno še strošek administratorja, električne energije, prenosa
podatkov in vzdrževanja. Natančnejši izračun za 100 TB podatkov, ocenjen na 955.500
dolarjev, pokaže, da je lahko hiter izračun zelo napačen, cenovno ugodnejša pa postane
rešitev v oblaku (Forrester Research, Inc. v Reichman 2011, str. 8)
V primeru intervjuvanega podjetja so stroški nakupa, vzdrževanja in ostalih dejavnikov
mnogo manjši, saj je tudi potreba po prostoru za podatke manjša kot v prej omenjenem
primeru.
4.4.1 Podatkovni strežnik v lokalnem okolju
Za doseganje visoke razpoložljivosti podatkovnega strežnika v lokalnem okolju je potrebno
podvajanje nekaterih komponent strojne opreme. Konfiguracija predlaganega podatkovnega
strežnika je sestavljena iz dveh NAS sistemov (glej Sliko 4.2). V vsakem izmed njih so
postavljeni trije diski velikosti 1 TB, ki delujejo v RAID 1 načinu povezovanja in upravljanja
z diski. Podatki se zrcalijo na vse tri diske, za nemoteno delovanje sistema pa lahko hkrati
prenehata z delovanjem dva diska, pri čemer je potrebno pokvarjene diske zamenjati čim prej.
42
Sistem NAS omogoča izdelavo varnostne kopije na tretjo lokacijo, ki v tem primeru ostaja v
dogovoru partnerskega podjetja. Ker lahko preneha z delovanjem tudi sam NAS sistem,
zajema konfiguracija dodaten NAS sistem z istim številom diskov, na katerega se ves čas
zrcalijo podatki. V primeru izpada električne energije skrbi za nemoteno delovanje
podatkovnega strežnika sistem za neprekinjeno napajanje UPS, ki je pomemben predvsem za
to, da se podatkovni strežnik pravilno zaustavi in ne pride do izgube podatkov. Razen v
primeru, da celotna informacijska tehnologija v podjetju deluje na takih sistemih, UPS ne
pripomore k doseganju visoke razpoložljivosti, saj samo delovanje podatkovnega strežnika ni
v pomoč, če ne delujejo naprave, ki dostopajo do teh podatkov.
Slika 4.2: Arhitektura lokalne rešitve z varnostnim kopiranjem
Vir: Marolt, lastni prikaz (2015)
4.4.2 Shramba kot storitev v oblaku
V primerjavi s tradicionalnim pristopom prinaša računalništvo v oblaku manj začetnih
stroškov, izdatki pa iz naložbenih preidejo v operativne. V smislu shrambe za podatke v
oblaku plačamo le toliko, kolikor porabimo, obračuna pa se realna velikost podatkov in ne
velikost podatkov, ki je dejansko potrebna za doseganje visoke razpoložljivosti v lokalnem
okolju. Da zagotovimo visoko razpoložljivost lokalno, potrebujemo podvajanje naprav, pri
čemer se na vsakem dodatnem disku nahajajo identični podatki, kar pomeni, da so dodatne
43
podatkovne kapacitete neuporabne za nove podatke. Lokalno ne potrebujemo podatkovnega
strežnika, potrebujemo samo kliente, s katerimi preko spleta dostopamo do podatkovne
shrambe v oblaku ponudniku (glej Sliko 4.3). Na strani ponudnika nas ne zanima, kako je
rešena visoka razpoložljivost. Rešitev shrambe v oblaku bo v nadaljevanju izvedena pri dveh
ponudnikih, in sicer pri ponudniku Amazon s storitvijo Amazon Simple Storage Service in pri
ponudniku Google s storitvijo Google Cloud Storage. Končna cena shrambe v oblaku pri obeh
ponudnikih je sestavljena iz cene shrambe na GB uporabljenega prostora, cene zahtevkov za
osveževanje, kopiranje, nalaganje in pridobivanje podatkov ter cene prenosa podatkov. Cena
uporabljenega prostora se pri obeh ponudnikih razlikuje glede na nivo storitve, pri Amazonu
pa se cena spreminja tudi glede na izbrano regijo, v kateri shranjujemo podatke.
Slika 4.3: Arhitektura rešitve v oblaku
Vir: Marolt, lastni prikaz (2015)
4.4.3 Primerjava
Omenjena lokalna konfiguracija je sestavljena iz dveh podatkovnih strežnikov NAS, in sicer
Infortrend EonNAS Pro 510. Okvirna cena posameznega sistema je okoli 700 evrov. Za
doseganje višje razpoložljivosti in boljše zanesljivosti so izbrani trdi diski, namenjeni za
naprave NAS. Podjetju zadostuje 1 TB oziroma 1000 GB prostora za podatke, okvirna cena
posameznega izbranega diska Western Digital Red pa je 86 evrov. Potreben je tudi sistem za
neprekinjeno napajanje. Obstajajo vsaj 3 vrste teh sistemov, za doseganje visoke
razpoložljivosti pa moramo poseči po vrsti »online«. Za to konfiguracijo je izbran sistem
AEG Protect C. 1000, ki z dodatno baterijo dosega avtonomijo 165 minut pri obremenitvi 200
W. Okvirna cena sistema UPS je 360 evrov, dodatna baterija za doseganje višje avtonomije pa
stane 187 evrov. Posamezni del podatkovnega strežnika je sestavljen iz enega sistema NAS,
44
treh diskov in enega sistema za neprekinjeno delovanje UPS. Okvirni strošek nakupa
posameznega dela je 1505 evrov, podvojene opreme pa 3010 evrov. Upoštevati je potrebno
tudi strošek električne energije. Z maksimalno porabo 250 W električne energije in
delovanjem 24 ur na dan celo leto, bi poraba električne energije enega podatkovnega strežnika
znašala 2190 kWh. Z upoštevanjem cene kWh električne energije 0,07197 evra in 99,9 %
razpoložljivosti skozi leto bi bil okvirni strošek električne energije enega podatkovnega
strežnika 157,5 evra. To pomeni, da bi bil strošek električne energije obeh podatkovnih
strežnikov skozi celo leto 315 evrov. Rednega vzdrževanja NAS sistemi praviloma ne
potrebujejo, potrebna je le menjava trdih diskov v primeru odpovedi katerega izmed njih. Prav
tako je v ceni samega sistema NAS vključena tudi podpora s strani proizvajalca. Celoten
strošek lastništva lokalne rešitve je tako ocenjen na 3325 evrov, pri čemer večji del stroškov
nosijo začetni stroški. Za celotno življenjsko dobo sistema, ki je 3 leta, in s predpostavko o
nespremenljivi ceni električne energije so stroški lokalne rešitve ocenjeni na 3955 evrov.
V nadaljevanju sta izračuna končne cene rešitve v oblaku pri posameznem ponudniku
podatkovne shrambe v oblaku izdelana na podlagi cene storitev na dan 7. 9. 2015. Tako kot v
primeru rešitve lokalno je zahtevana količina podatkov 1 TB oziroma 1000 GB. Amazon S3
ponuja tri različne nivoje storitve, prav tako pa se cene razlikujejo glede na izbrano regijo, v
kateri se nahajajo podatki. Najcenejša možnost se uporablja samo za arhiviranje na dolgi rok,
drugi dve možnosti pa se razlikujeta v stopnji redundance. V izračunu je uporabljena dražja
možnost in najbližja regija Evropa (Frankfurt). Strošek shrambe podatkov za prvi 1 TB na
mesec je 0,0324 dolarja na GB podatkov. Za 1 TB oziroma 1000 GB podatkov je strošek
shrambe 32,4 dolarja (tj. 29,06 evra). Ceno oblikujejo tudi zahtevki, pri čemer je brisanje
podatkov brezplačno. Cena nalaganja podatkov je 0,0054 dolarja na 1000 zahtevkov, za
pridobivanje podatkov pa 0,0043 dolarja na 10000 zahtevkov, kar je v primeru obravnavanega
podjetja zanemarljivo malo. Prenos podatkov iz shrambe v oblaku je brezplačno za 1 GB,
nato pa 0,090 dolarja za vsak GB do 10 TB na mesec. V izračunu je uporabljena ocena 25 %
prenosa vseh podatkov, torej 250 GB, kar lahko pretvorimo v približno 22,41 dolarja oziroma
20,11 evra. Ker so podatki, ki se prenašajo v oblak, brezplačni, sta to edina dva stroška,
skupno torej 49,17 evra na mesec. V enem letu je strošek shrambe pri ponudniku Amazon
590,04 evra, v treh letih pa 1770,12 evra. Tudi ponudnik Google s storitvijo Google Cloud
Storage ponuja tri različne nivoje storitve, v izračunu pa je uporabljena najdražja možnost.
Strošek shrambe podatkov za prvi 1 TB na mesec je 0,026 dolarja na GB podatkov. Za 1 TB
oziroma 1000 GB podatkov je strošek shrambe 26 dolarjev (tj. 23,23 evra). Cena nalaganja
45
oziroma pridobivanja podatkov je 0,01 dolarja na 1000 oziroma 10000 zahtevkov, kar je za
podjetje zanemarljivo malo, brisanje podatkov pa je brezplačno. Cena prenosa podatkov iz
shrambe za prvi 1 TB na mesec je 0,12 dolarja na GB. V izračunu je prav tako kot v primeru
Amazona uporabljena ocena 25 % prenosa vseh podatkov, torej 250 GB, kar lahko pretvorimo
v približno 30 dolarjev oziroma 26,81 evra. Celoten strošek shrambe in prenosa podatkov je
okvirno 50,04 evra na mesec. V enem letu to pomeni strošek 600,48 evra, v treh letih pa
1801,44 evra.
S primerjavo stroškov ene in druge rešitve lahko vidimo, da je shramba v oblaku cenejša kot
lokalna rešitev (glej Tabelo 4.1). Pri tem se je potrebno zavedati, da so omenjene ocene
posameznih rešitev narejene za obdobje enega oziroma treh let. Zaradi višjih operativnih
stroškov rešitev v oblaku bi pričakovali, da bo celoten strošek lokalne rešitve sčasoma nižji,
vendar je potrebno razmišljati o strošku menjave komponent po preteku treh let oziroma
garancijske dobe. Na te stroške ni potrebno razmišljati pri rešitvi podatkovne shrambe v
oblaku. Prav tako so izbrane komponente nižjega cenovnega razreda, z izbiro boljših in
zanesljivejših komponent pa bi naložbeni stroški lahko močno narasli. V kolikor bi se v
podjetju pojavila potreba po doseganju visoke razpoložljivosti podatkovnega strežnika, bi
vsekakor to najhitreje dosegli s prehodom na računalništvo v oblaku. Prav tako bi se izognili
večji začetni naložbi v opremo in tako tudi zmanjšali celotne stroške lastništva. Vendar pa
doseganje visoke razpoložljivosti ni največja skrb podjetja, pomembnejša jim je varnost
podatkov, zato se za prehod na računalništvo v oblaku še ne bi odločili.
Tabela 4.1: Primerjava stroškov različnih rešitev podatkovne shrambe
Lokalna rešitev Amazon S3 Google Cloud Storage
Naložbeni stroški 3010 € / /
Operativni stroški na mesec 26,25 € 49,17 € 50,04 €
Operativni stroški v enem letu 315 € 590,04 € 600,48 €
Operativni stroški v treh letih 945 € 1770,12 € 1801,44 €
Stroški skupaj v treh letih 3955 € 1770,12 € 1801,44 €
Vir: Marolt, lastna raziskava (2015)
46
5. ZAKLJUČEK
Na začetku pisanja diplomske naloge smo postavili glavno raziskovalno vprašanje "Kako
doseganje visoke razpoložljivosti vpliva na prehod s tradicionalnega računalništva na
računalništvo v oblaku?". S pomočjo dodatnih raziskovalnih vprašanj "Kolikšno stopnjo
visoke razpoložljivosti obljubljajo ponudniki storitev računalništva v oblaku?" ter "Ali
ponudniki storitev računalništva v oblaku dosegajo obljubljene stopnje visoke
razpoložljivosti?", na kateri smo odgovorili s pomočjo pregleda ustreznih virov in literature,
smo poiskali izhodišče za izvedbo intervjuja s podjetjem in odgovorili tudi na glavno
raziskovalno vprašanje. Pri pregledu literature smo v teoretičnem delu naredili pregled
računalništva v oblaku, njegov razvoj, lastnosti, storitvene in nadzorne modele, prednosti in
priložnosti ter slabosti in tveganja uporabe storitev računalništva v oblaku. V nadaljevanju
smo predstavili pojem razpoložljivosti oziroma visoke razpoložljivosti, za računalništvo v
oblaku pomemben sporazum o ravni storitve med ponudnikom in uporabnikom, pregledali
smo odmevnejše primere izpadov storitev, njihove vzroke in vpliv ter opisali nekatere rešitve
za doseganje visoke razpoložljivosti. V zadnjem delu diplomske naloge smo nato analizirali
intervju s predstavnikom podjetja in odgovorili na glavno raziskovalno vprašanje. Izdelali in
primerjali smo tudi različne rešitve shrambe podatkov lokalno in v oblaku, pri čemer so
morale rešitve dosegati visoko razpoložljivost.
Računalništvo v oblaku bo čedalje bolj oblikovalo poslovanje podjetij, zato je pomembno, da
se slabosti oziroma tveganja odpravljajo. V smislu razpoložljivosti kljub občasnim večjim
izpadom delovanja smo ugotovili, da dosegajo obljubljene stopnje razpoložljivosti, hkrati pa
se čedalje bolj približujejo stopnji 99,999 %, ki velja za točko visoke razpoložljivosti.
Doseganje visoke razpoložljivosti lahko prav tako vpliva na prehod s tradicionalnega
računalništva. V primeru nedosegljivosti ponudniki ponujajo povračilo nekaj odstotkov
stroškov, vendar kdor dejansko potrebuje zelo visoko razpoložljivost, mu ne povrne dejanskih
stroškov oziroma izgub. Ostala podjetja morajo premisliti o prednostih in slabostih, ki jih
prehod prinaša, ter preračunati, ali je prehod zanje smiseln. V kolikor je potrebno doseganje
visoke razpoložljivosti, so že sedaj rešitve v oblaku boljše, tako z vidika same visoke
razpoložljivosti kot tudi celotnega stroška lastništva. Podjetja, ki si želijo večjega nadzora nad
podatki, se bodo še naprej raje odločala za nakup in postavitev opreme v lokalnem okolju.
47
Ugotovili smo, da je v primeru obravnavanega podjetja lokalna postavitev podatkovnega
strežnika dražja kot rešitev v oblaku, kljub uporabi naprav nižjega cenovnega razreda.
Primerjava rešitve v oblaku dveh različnih ponudnikov je pokazala, da med njima ni ključnih
razlik, niti v celotnih stroških lastništva niti v doseganju visoke razpoložljivosti.
48
49
6. LITERATURA IN VIRI
1. AGAPI, ANDREI, BIRMAN, KEN, BROBERG, ROBERT M., COTTON, CHASE,
KIELMANN, THILO, MILLNERT, MARTIN, PAYNE, RICK, SURTON, ROBERT in
VAN RENESSE, ROBBERT (2011) Routers for the Cloud: Can the Internet Achieve 5-
nines Availability? IEEE Internet Computing, 15 (5), str. 72−76.
2. AGUIAR, EVERALDO, ZHANG, YIHUA in BLANTON, MARINA (2014) An
Overview of Issues and Recent Developments in Cloud Computing and Storage Security.
High Performance Cloud Auditing and Applications, str. 3−33.
3. AHUJA, SANJAY P. in MANI, SINDHU (2012) Availability of Services in the Era of
Cloud Computing. Network and Communication Technologies, 1 (1), str. 2−6.
4. AHUJA, SANJAY P., MANI, SINDHU in ZAMBRANO, JESUS (2012) A Survey of the
State of Cloud Computing in Healthcare. Network and Communication Technologies, 1
(2), str. 12−19.
5. ALAM, BASHIR, DOJA, M. N., ALAM, MANSAF in MALHOTRA, SHWETA (2013)
Security Issues Analysis for Cloud Computing. International Journal of Computer
Science and Information Security, 11 (9), str. 117−125.
6. ALEEM, AZEEM in SPROTT, CHRISTOPHER RYAN (2012) Let Me in the Cloud:
Analysis of the Benefit and Risk Assessment of Cloud Platform. Journal of Financial
Crime, 20 (1), str. 6−24.
7. ALZAIN, MOHAMMED A., SOH, BEN in PARDEDE, ERIC (2012) A New Model to
Ensure Security in Cloud Computing Services. Journal of Service Science Research, 4 (1),
str. 49−70.
8. AMAZON EC2. Dostopno prek: https://aws.amazon.com/ec2/ (25. 8. 2015).
9. AMAZON S3. Dostopno prek: https://aws.amazon.com/s3/ (25. 8. 2015).
10. ARMBRUST, MICHAEL, FOX, ARMANDO, GRIFFITH, REAN, JOSEPH,
ANTHONY D., KATZ, RANDY, KONWINSKI, ANDY, LEE, GUNHO, PATTERSON,
DAVID, RABKIN, ARIEL, STOICA, ION in ZAHARIA, MATEI (2010) A View of
Cloud Computing. Communications of the ACM, 53 (4), str. 50−58.
11. ARUTYUNOV, V. V. (2012) Cloud Computing: Its History of Development, Modern
State and Future Considerations. Scientific and Technical Information Processing, 39 (3),
str. 173−178.
50
51
12. BERVAR, JAN (2013) NIL-ov vodnik po storitvah računalništva v oblaku. Dostopno
prek: http://www.nil.si/assets3554/wp-content/uploads/2013/04/nil-ov-vodnik-po-
oblaku.pdf (17. 8. 2015).
13. BHADAURIA, ROHIT, CHAKI, RITUPARNA, CHAKI, NABENDU in SANYAL,
SUGATA (2014) Security Issues in Cloud Computing. Acta Technica Corviniensis -
Bulletin of Engineering, 7 (4), str. 159−177.
14. BUTLER, BRANDON (2015) Which Cloud Providers Had the Best Uptime Last Year?
Dostopno prek: http://www.networkworld.com/article/2866950/cloud-computing/which-
cloud-providers-had-the-best-uptime-last-year.html (24. 8. 2015).
15. CHAKRAVARTHY, M. HEMANTH in KANNAN, E. (2014) A Review on Secured
Cloud Computing Environment. American Journal of Applied Sciences, 11 (8), str.
1224−1228.
16. CHEN, CHAO-CHIH, YUAN, LIHUA, GREENBERG, ALBERT, CHUAH, CHEN-NEE
in MOHAPATRA, PRASANT (2014) Routing-as-a-service (RaaS): A Framework for
Tenant-Directed Route Control in Data Center. Networking, IEEE/ACM Transactions on,
22 (5), str. 1401−1414.
17. CLARKE, GAVIN (2009) Microsoft's Azure Cloud Suffers First Crash. Dostopno prek:
http://www.theregister.co.uk/2009/03/16/azure_cloud_crash (27. 8. 2015).
18. CLOUDHARMONY. Dostopno prek: https://cloudharmony.com (24. 8. 2015).
19. CORKERN, SHEREE M., KIMMEL, SARA B. in MOREHEAD, BILLY (2015)
Accountants Need to be Prepared for the Big Question: Should I Move to the Cloud?
International Journal of Management & Information Systems, 19 (1), str. 13−20.
20. D'AGOSTINO, DANIELE, GALIZIA, ANTONELLA, CLEMATIS, ANDREA,
MANGINI, MATTEO, PORRO, IVAN in QUARATI, ALFONSO (2013) A QoS-Aware
Broker for Hybrid Clouds. Computing. Archives for Informatics and Numerical
Computation, 95 (1), str. 89−109.
21. DIGITAL AGENDA FOR EUROPE (2014) Cloud Service Level Agreement
Standardisation Guidelines. Dostopno prek: http://ec.europa.eu/information_society/
newsroom/cf/dae/document.cfm?action=display&doc_id=6138 (22. 8. 2015).
22. DINES, RACHEL (2013) Quantifying the Impact of Downtime: What We Can Learn
from Recent New Your Times, Google and Amazon Outages. Dostopno prek: http://
blogs.forrester.com/rachel_dines/13-08-19-quantifying_the_impact_of_downtime_
what_we_can_learn_from_recent_new_york_times_google_and_amazon_out (30. 8.
2015).
52
53
23. DUTTA, AMAB, PENG, GUO CHAO ALEX in CHOUDHARY, ALOK (2013) Risks in
Enterprise Cloud Computing: The Perspective of IT Experts. The Journal of Computer
Information Systems, 53 (4), str. 39−48.
24. FARAH, BADIE N. (2013) A Model for Managing Uncertainty on the Cloud. Journal of
Management Policy and Practice, 14 (6), str. 19−24.
25. FERNANDES, DIOGO A. B., SOARES, LILIANA F. B., GOMES, JOÃO V., FREIRE,
MÁRIO M. in INÁCIO, PEDRO R. M. (2014) Security Issues in Cloud Environments: A
Survey. International Journal of Information Security, 13 (2), str. 113−170.
26. FRANTSVOG, DEAN, SEYMOUR, TOM in JOHN, FRENEYMON (2012) Cloud
Computing. International Journal of Management & Information Systems, 16 (4), str.
317−324.
27. GHILIC-MICU, BOGDAN, STOICA, MARIAN in USCATU, CRISTIAN RÃZVAN
(2014) Cloud Computing and Agile Organization Development. Informatica Economică,
18 (4), str. 5−13.
28. GHORMLEY, YVETTE (2012) Two's Company, Three's a Cloud: Challenges to
Implementing Service Models. Journal of Service Science, 5 (1), str. 19−28.
29. GONZALEZ, NELSON, MIERS, CHARLES, REDÍGOLO, FERNANDO, SIMPLÍCIO,
MARCOS, CARVALHO, TEREZA, NÄSLUND, MATS in POURZANDI, MAKAN
(2012) A Quantitative Analysis of Current Security Concerns and Solutions for Cloud
Computing. Journal of Cloud Computing, 1 (1), str. 1−18.
30. GOOGLE COMPUTE ENGINE. Dostopno prek: https://cloud.google.com/compute/ (25.
8. 2015).
31. GOOGLE STORAGE. Dostopno prek: https://cloud.google.com/storage/ (25. 8. 2015).
32. HAN, YAN (2013) IaaS Cloud Computing Services for Libraries: Cloud Storage and
Virtual Machines. OCLC Systems & Services: International Digital Library Perspectives,
29 (2), str. 87−100.
33. HOFMANN, PAUL in WOODS, DAN (2010) Cloud Computing: The Limits of Public
Clouds for Business Applications. Internet Computing, IEEE, 14 (6), str. 90−93.
34. IBM BLUEMIX. Dostopno prek: http://www.ibm.com/cloud-computing/bluemix/ (26. 8.
2015).
35. KHANSA, LARA in ZOBEL, CHRISTOPHER W. (2014) Assessing Innovations in
Cloud Security. The Journal of Computer Information Systems, 54 (3), str. 45−56.
36. KING, BRIAN (2013) 10 Steps to Minimizing the Impact of Cloud Downtime. Dostopno
prek: http://cloudtimes.org/2013/12/02/10-steps-to-minimizing-the-impact-of-cloud-
downtime/ (29. 8. 2015).
54
55
37. KUPFERMAN, JONATHAN, SILVERMAN, JEFF, JARA, PATRICIO in BROWNE,
JEFF (2009) Scaling into the Cloud. CS270 - Advanced Operating Systems. Dostopno
prek: http://www.cs.ucsb.edu/~jbrowne/files/ScalingIntoTheClouds.pdf (17. 8. 2015).
38. LIXĂNDROIU, RADU in MAICAN, CĂTĂLIN (2014) A Model for Comparing Free
Cloud Platforms. Informatica Economica, 18 (4), str. 40−49.
39. MANGIUC, DRAGOS-MARIAN (2012) Security Issues of Cloud Based Services - A
Guide for Managers. Revista de Management Comparat International, 13 (3), str.
468−477.
40. MARSTON, SEAN, LI, ZHI, BANDYOPADHYAY, SUBHAJYOTI, ZHANG,
JUHENG in GHALSASI, ANAND (2011) Cloud Computing - The Business Perspective.
Decision Support Systems, 51 (1), str. 176−189.
41. MELL, PETER in GRANCE, TIMOTHY (2011) The NIST Definition of Cloud
Computing. NIST Special Publication 800-145. Dostopno prek: http://csrc.nist.gov/
publications/nistpubs/800-145/SP800-145.pdf (14. 8. 2015).
42. MENDES, CARLOS, ALMEIDA MÁRIO in MIRA DA SILVA, MIGUEL (2013)
Applying DEMO-Based SLAs to Cloud Services. Journal of Service Science Research, 5
(2), str. 95−123.
43. MICROSOFT AZURE OBJECT STORAGE. Dostopno prek:
http://azure.microsoft.com/en-us/services/storage/ (25. 8. 2015).
44. MICROSOFT AZURE VIRTUAL MACHINES. Dostopno prek:
http://azure.microsoft.com/en-us/services/virtual-machines/ (25. 8. 2015).
45. MICROSOFT AZURE WEB APPS. Dostopno prek: http://azure.microsoft.com/en-
us/services/app-service/web/ (25. 8. 2015).
46. MILLER, RICH (2007) Amazon EC2 Outage Wipes Out Data. Dostopno prek:
http://www.datacenterknowledge.com/archives/2007/10/02/amazon-ec2-outage-wipes-
out-data/ (27. 8. 2015).
47. MILLER, RICH (2008) Amazon Outage for Amazon S3 and EC2. Dostopno prek:
http://www.datacenterknowledge.com/archives/2008/02/15/major-outage-for-amazon-s3-
and-ec2/ (27. 8. 2015).
48. MILLER, RICH (2009) Lightning Strike Triggers Amazon EC2 Outage. Dostopno prek:
http://www.datacenterknowledge.com/archives/2009/06/11/lightning-strike-triggers-
amazon-ec2-outage/ (27. 8. 2015).
56
57
49. MINHAS, UMAR FAROOQ (2013) Scalable and Highly Available Database Systems in
the Cloud. Waterloo: University of Waterloo. Dostopno prek: https://cs.uwaterloo.ca/
~ashraf/theses/MinhasPhD12.pdf (23. 8. 2015).
50. NICHO, MATHEW in HENDY, MAHMOUD (2013) Dimensions of Security Threats in
Cloud Computing: A Case Study. Review of Business Information Systems, 17 (4), str.
159−170.
51. OKEZIE, CHRISTIANA C., CHIDIEBELE, UDEZE C. in KENNEDY, OKAFOR C.
(2012) Cloud Computing: A Cost Effective Approach to Enterprise Web Application
Implementation (A Case for Cloud ERP Web Model). Academic Research International, 3
(1), str. 432−443.
52. OREDO, JOHN OTIENO in NJIHIA, JAMES (2014) Challenges of Cloud Computing in
Business: Towards New Organizational Competencies. International Journal of Business
and Social Science, 5 (3), str. 150−160.
53. PRASAD, DILIP K. (2012) High Availability Based Migration Analysis to Cloud
Computing for High Growth Businesses. International Journal of Computer Networks, 4
(2), str. 35−52.
54. RACKSPACE (2010) Architecting High Availability Linux Environments Within the
Rackspace Cloud. Dostopno prek: http://www.rackspace.com/knowledge_center/sites/
default/files/whitepaper_pdf/High_Availibilty_Cloud_Feb_16_0.pdf (23. 8. 2015).
55. RACKSPACE CLOUD SERVERS. Dostopno prek: http://www.rackspace.com/cloud/
servers (27. 8. 2015).
56. REICHMAN, ANDREW (2011) File Storage Costs Less in the Cloud Than In-house.
Dostopno prek: http://media.amazonwebservices.com/Forrester_File_Storage_Costs_
Less_ In_The_Cloud.pdf (5. 9. 2015).
57. RIGHTSCALE (2015) RightScale 2015 State of the Cloud Report. Dostopno prek: http://
assets.rightscale.com/uploads/pdfs/RightScale-2015-State-of-the-Cloud-Report.pdf (22. 8.
2015).
58. ROSE, CHRIS (2011) A Break in the Cloud? The Reality of Cloud Computing.
International Journal of Management and Information Systems, 15 (4), str. 59−63.
59. SHAH, HARIT in ANANDANE, SHARMA SHANKAR (2013) Security Issues on Cloud
Computing. International Journal of Computer Science and Information Security, 11 (8),
str. 25−34.
58
59
60. SOMMER, THOMAS in SUBRAMANIAN, RAMESH (2013) Implementing Cloud
Computing in Small and Mid-Market Life-Sciences: A Mixed-Method Study. Journal of
International Technology and Information Management, 22 (3), str. 55−76.
61. SRINIVASAN, S. (2013) Is Security Realistic in Cloud Computing? Journal of
International Technology and Information Management, 22 (4), str. 47−66.
62. STAPLEFOOTE, LIZETTA (2014) How Downtime Impacts the Bottom Line 2014
[Infographic]. Dostopno prek: http://www.rackspace.com/blog/how-downtime-impacts-
the-bottom-line-2014-infographic/ (30. 8. 2015).
63. SYNERGY RESEARCH (2015a) AWS Market Share Reaches Five-Year High Despite
Microsoft Growth Surge. Dostopno prek: https://www.srgresearch.com/articles/aws-
market-share-reaches-five-year-high-despite-microsoft-growth-surge (26. 8. 2015).
64. SYNERGY RESEARCH (2015b) The Big Four Cloud Providers are Leaving the Rest of
the Market Behind. Dostopno prek: https://www.srgresearch.com/articles/ big-four-cloud-
providers-are-leaving-rest-market-behind (26. 8. 2015).
65. TRIGUEROS-PRECIADO, SARA, PÉREZ-GONZÁLEZ, DANIEL in SOLANA-
GONZÁLEZ, PEDRO (2013) Cloud Computing in Industrial SMEs: Identification of the
Barriers to Its Adoption and Effects of Its Application. Electronic Markets, 23 (2), str.
105−114.
66. UPCLOUD. Dostopno prek: https://www.upcloud.com/ (27. 8. 2015).
67. VENTERS, WILL in WHITLEY, EDGAR A. (2012) A Critical Review of Cloud
Computing: Researching Desires and Realities. Journal of Information Technology, 27
(3), str. 179−197.
68. ZIMORY (2012) High Availability in Cloud Computing. Dostopno prek: http://
www.zimory.com/fileadmin/zimory/Downloads/Whitepaper/Product-
HighAvailabilityinCloudComputing-270813-1611-134.pdf (23. 8. 2015).
69. ŽNIDAR, TAMARA (2015) DaaS - namizje kot storitev. Dostopno prek: http://
blog.zabec.net/daas-namizje-kot-storitev/ (22. 8. 2015).
70. WANG, WILLIAM YU CHUNG, RASHID, AMMAR in CHUANG, HUAN-MING
(2011) Toward the Trend of Cloud Computing. Journal of Electronic Commerce
Research, 12 (4), str. 238−242.
71. WINTERFORD, BRETT (2011) Amazon EC2 Suffers Huge Outage. Dostopno prek:
http://www.crn.com.au/~/News/255586,amazon-ec2-suffers-huge-outage.aspx/0 (27. 8.
2015).
60
61
72. YOO, CHRISTOPHER S. (2011) Cloud Computing: Architectural and Policy
Implications. Review of Industrial Organization, 38 (4), str. 405−421.
