PREDLOG VPELJAVE RAČUNALNIŠKEGA OBLAKA V JAVNOIZOBRAŽEVALNO OMREŽJE

Transcription

1 UNIVERZA V LJUBLJANI NARAVOSLOVNOTEHNIŠKA FAKULTETA ODDELEK ZA TEKSTILSTVO, GRAFIKO IN OBLIKOVANJE PREDLOG VPELJAVE RAČUNALNIŠKEGA OBLAKA V JAVNOIZOBRAŽEVALNO OMREŽJE DIPLOMSKO DELO MARKO VRAN LJUBLJANA, november 2015

2 UNIVERSITY OF LJUBLJANI FACULTY OF NATURAL SCIENCES AND ENGINEERING DEPARTMENT OF TEXTILES, GRAPHIC ARTS AND DESIGN PROPOSITION OF CLOUD COMPUTING IMPLEMENTATION IN THE PUBLIC EDUCATION NETWORK DIPLOMA THESIS MARKO VRAN LJUBLJANA, November 2015

3 PODATKI O DIPLOMSKEM DELU Število listov: 96 Število strani: 84 Število slik: 29 Število preglednic: 5 Število literaturnih virov: 75 Število prilog: 3 Študijski program: visokošolski strokovni študijski program Grafična tehnika Komisija za zagovor diplomskega dela: Predsednica: doc. dr. Dejana Javoršek Mentor: Mihael Lazar, u.d.i.e. Član: v. pred. mag. Andrej Iskra Ljubljana,...

4 ZAHVALA Zahvaljujem se vsem, ki so me ob pisanju diplomskega dela spodbujali in mi stali ob strani. ii

5 IZVLEČEK V diplomskem delu je predstavljen življenjski cikel projekta uvedbe sistema za upravljanje vsebin (CMS) za digitalno pripravo, soočenje z infrastrukturnimi težavami in navezavo na potencialne prednosti, ki bi jih računalniški oblak v javno izobraževalnem omrežju lahko projektu nudil ter s tem podaljšal njegovo življenjsko dobo. V teoretičnem delu je predstavljeno računalništvo v oblaku, zgodovina in razvoj, tipične lastnosti, razlaga različnih modelov z značilnostmi, prednosti in pomanjkljivosti ter ekonomski vidiki. V praktičnem delu je predstavljen projekt CMS, razlogi za nastanek, lastnosti postavitve, operativne težave in pomanjkljivosti ter ostali dejavniki, ki so botrovali prenehanju delovanja. Praktični del hkrati podaja potencialno rešitev pri vzpostavitvi primerne ITinfrastrukture in opredeli možnost vpeljave ter okvirno arhitekturo računalniškega oblaka v javnoizobraževalnem omrežju, obenem pa oriše tudi stanje vpeljave. Računalniški oblak je podan kot logična evolucija zagotavljanja IT-storitev v izobraževalnem okolju ter kot učinkovit pristop k reševanju podhranjenosti in pomanjkanju sredstev izobraževalnih ustanov za vpeljavo peskovnikov, inkubatorjev ter potencialno tako izobraževalno kot finančno zanimivih projektov. Teza sloni na predpostavki, da posamezne izobraževalne ustanove ne morejo zagotavljati niti takšnega obsega niti kakovosti sredstev, ki jih ponudnik IT-storitev lahko zagotovi v oblaku. Izsledki kažejo, da računalniški oblak v ustrezni obliki lahko predstavlja osnovno ogrodje IT-infrastrukture in storitev v izobraževalnem omrežju. Zaključek ovrednoti tezo, da ni vprašljiva potreba po računalniškem oblaku, temveč način vpeljave, uporabe ter zavedanje o njegovem potencialu. Ključne besede: računalniški oblak, javnoizobraževalno omrežje, CMS, TikiWiki iii

6 ABSTRACT Proposition of Cloud computing implementation in the public education network The thesis follows the lifecycle of a content management system (CMS) project used for the study of digital prepress workflow, outlining the impact and potential benefits cloud computing in public education network could have had on the project and thus extending its usability and life. Theoretical part addresses cloud computing in general, its history, development, typical properties, expanding on different types and models, benefits and drawbacks, outlined with economic benefits. Practical part focuses on the CMS project, the reasons and requirements behind it and its configuration. While displaying issues, drawbacks and other factors that led to its demise, it presents potential solution in adoption of a suitable IT infrastructure and presents the idea of a cloud architecture framework in an educational environment. The cloud is presented as a logical evolution of public education IT service provisioning and as an efficient solution to overutilization of computing resources. The thesis is based on the assumption, that individual educational institutions cannot procure the volume, nor quality of resources comparable to the levels provided by a dedicated service provider in the cloud. The findings show that properly applied computer cloud can successfully host the basic IT infrastructure and services needed in a public education network. Findings show that it is not the need for a computer cloud that is in question, but its application, usage and awareness of its potential. Keywords: cloud computing, public education network, CMS, TikiWiki iv

7 KAZALO VSEBINE PODATKI O DIPLOMSKEM DELU... I ZAHVALA... II IZVLEČEK... III ABSTRACT... IV KAZALO VSEBINE... V SEZNAM SLIK... VIII OKRAJŠAVE... IX SLOVAR... X 1 UVOD TEORETIČNI DEL O OBLAKIH OSNOVNE KARAKTERISTIKE RAČUNALNIŠKIH OBLAKOV KORENINE IN GRADNIKI OBLAKOV SOA in spletne storitve Web 2.0,»mashup«in širokopasovni dostop do interneta Virtualizacija NIVOJI IN MODELI STORITEV V OBLAKU TIPI OBLAKOV PREDNOSTI UPORABE OBLAKOV TVEGANJA IN PASTI EKONOMSKI VIDIK TEHNIČNE ZAHTEVE ZA POSTAVITEV RAČUNALNIŠKEGA OBLAKA PODATKOVNI CENTER Električno napajanje Hlajenje Nadzor in upravljanje okolja Protipožarni sistem Fizična varnost VARNOSTNO KOPIRANJE Naprave za varnostno kopiranje Programska oprema za varnostno kopiranje v

8 STROJNA OPREMA Strežniški sistem Diskovni podsistem Omrežne komponente Varnostna oprema Podvojenost komponent Visoka razpoložljivost Okrevanje po katastrofi PROGRAMSKA OPREMA EKSPERIMENTALNI DEL PROJEKT "TIKIWIKI CMS" TEHNIČNE LASTNOSTI POSTAVITVE Tehnične zahteve TikiWiki CMS Postopek osnovne namestitve zahtevane programske opreme Postopek namestitve programske opreme TikiWiki CMS Prikaz delovanja TikiWiki CMS iz uporabniškega vidika RAZPRAVA O REZULTATIH TEŽAVE PRI PRODUKCIJI Varnost Zanesljivost strojne opreme Napajanje Fizični dostop Varnostno kopiranje PROJEKT TIKIWIKI CMS V OBLAKU ZAČETNA POSTAVITEV VARNOST ZANESLJIVOST STROJNE OPREME Podvojenost komponent Visoka razpoložljivost Okrevanje po katastrofi PODATKOVNI CENTER VARNOSTNO KOPIRANJE Naprave za varnostno kopiranje Programska oprema za varnostno kopiranje PROGRAMSKA OPREMA PREDLOG VPELJAVE OBLAKA vi

9 PREHOD V OBLAK Prenos virtualiziranega fizičnega strežnika v oblak Namestitev in povrnitev podatkov v oblaku Načrt prehoda Predlog tehničnega postopka za prehod z namestitvijo in povrnitvijo podatkov v oblaku AKTUALNO STANJE ZAKLJUČEK LITERATURA IN VIRI PRILOGA A PRILOGA B PRILOGA C vii

10 SEZNAM SLIK Slika 1: Referenčni model oblaka NIST (3)... 3 Slika 2: Shema hipervizorja VMware (13)... 6 Slika 3: Arhitektura oblaka VMware vcloud... 8 Slika 4: Arhitektura oblaka OpenStack (50)... 8 Slika 5: Tipi in nivoji storitev v oblaku (15)... 9 Slika 6: Shema Lampertz varnega podatkovnega centra (23) Slika 7: Primerjava maksimalne količine virov med različnimi tipi strežnikov na omaro Slika 8: Primerjava cen na enoto CPE (jedro) in pomnilnika (10 GB) Slika 9: Primerjava razmerja med stroški in številom jeder na omaro Slika 10: Integrirana mrežna arhitektura s priklopom na stikala EoR preko delilcev Slika 11: Povezava naprav z Open vswitch stikalu v OpenStack (44) Slika 12: Razlika med varnostnimi mehanizmi v fizičnem in virtualnem omrežju (47) Slika 13: TikiWiki CMS Privzet izgled (57) Slika 14: NTF TikiWiki CMS - predloga domače strani Slika 15: NTF TikiWiki CMS - spisek pripravljenih generičnih uporabnikov z gesli Slika 16: NTF TikiWiki CMS - primer wiki strani predmeta Tipografsko oblikovanje Slika 17: NTF TikiWiki CMS - primer galerije datotek za izmenjavo vsebin Slika 18: NTF TikiWiki CMS - primer pripete vsebine na strani wiki Slika 19: NTF TikiWiki CMS - prikaz diskusije članov skupine na forumu Slika 20: NTF TikiWiki CMS - uporaba zasebnega sporočilnega sistema Slika 21: NTF TikiWiki CMS - primer operacije dodajanja vsebin člana skupine v galerijo datotek Slika 22: NTF TikiWiki CMS - primer upravljanja z različicami dokumenta Slika 23: Sovisnost varnosti in uporabnosti rešitve Slika 24: Primer dnevnika napada s surovo silo na storitev SSH Slika 25: Izsek napake»kernel panic«v dnevniku strežnika Slika 26: Osnovna enonivojska arhitektura TikiWiki Slika 27: Shema podvojene večnivojske arhitekture TikiWiki Slika 28: Shema privatnega oblaka v javnoizobraževalnem omrežju Slika 29: Razlike med posameznimi paketi glede vzdrževanja in podpore (74) viii

11 OKRAJŠAVE API Application Programming Interface programski vmesnik CMP Cloud Management Platform upravljalno okolje oblaka CMS Content Management System sistem za upravljanje vsebin CPS Cloud Printing Service tiskanje v oblaku DMZ DeMilitarized Zone demilitarizirano območje, cona EoR End of Rack končna/zadnja omara GaaS Gaming-as-a-Service igranje kot storitev I/O Input/Output vhodno/izhodni [promet] IaaS Infrastructure-as-a-Service infrastruktura kot storitev IDPS Intrusion Detection and Prevention System sistem za zaznavanje in preprečevanje vdorov IDS Intrusion Detection System sistem za zaznavanje vdorov IP Internet Protocol internetni protokol LAN Local Area Network lokalno omrežje L(C)MS Learning (Content) Management System sistem za upravljanje učenja MPS Managed print service upravljana storitev tiska PaaS Platform-as-a-Service okolje kot storitev ROI Return Of Investment donosnost naložbe SaaS Software-as-a-Service programska oprema kot storitev SOA Service Oriented Architecture storitveno usmerjena arhitektura SLA Service Level Agreement sporazum o ravni storitve TCO Total Cost of Ownership celotni stroški lastništva ToR Top of Rack na vrhu omare UPS Uninterruptible Power Supply brezprekinitveno napajanje VLAN Virtual LAN navidezno lokalno omrežje VoIP Voice over IP klic preko IP-omrežja VPN Virtual Private Network navidezno privatno omrežje WAN Wide Area Network prostrano omrežje ix

12 SLOVAR anti-malware appliance backend backward compatibility business continuity cluster compute controller converged [network] crash consistent dashboard datacenter disaster recovery downtime end user support enterprise ESX(i) failback fault tolerance hacker latency load balancer mainframe multipathing multitenancy object store obsolete online outsourcing pass-through patch panel performance port proprietary proxy risk mitigation Single Point of Failure self-service sizing snapshot thin-provisioning uptime utility computing zaščitno programje namenska naprava zaledje povratna združljivost neprekinjeno poslovanje gruča procesiranje, procesne [naprave] krmilnik konvergirano [omrežje] konsistentno s sesutjem nadzorna plošča podatkovni center okrevanje po katastrofi čas izpada delovanja podpora za končnega uporabnika poslovno produkt VMware, hipervizor vzpostavitev prvotnega stanja odpornost ob napaki oz. izpadu vdiralec latenca, zakasnitev izenačevalnik obremenitve osrednji računalnik večpotnost večnajemništvo objektna shramba zastarel dostop na daljavo izdvajanje, zunanje izvajanje posrednik delilnik, priključna omarica zmogljivost vrata lastniško [tehnologija] posredniški strežnik zmanjševanje tveganja kritična točka odpovedi samopostrežba določanje velikosti posnetek skopo dodeljevanje čas neprekinjenega delovanja storitveno računalništvo x

13 1 UVOD»Spet ne morem na naš wiki,«je bil najbolj pogost stavek mojih sovrstnikov v času oddaje seminarskega dela proti koncu semestra. V imenu pilotskega projekta vpeljave dokumentnega sistema»tikiwiki«oz.»wikifikacije«učnega procesa smo namreč skupaj z dr. Bojanom Petkom leta 2006 integrirali nadbesedilni sistem wiki z osnovami dokumentnega in skupinskega programja (»Groupware«,»Collaborative software«). Projekt je v okviru naše skupine dokaj hitro zaživel in kmalu se je pojavila odvisnost od delovanja storitve, ker je naša rešitev neposredno odgovarjala na probleme, s katerimi se študenti srečujemo ob vsakdanjem delu. Žal nam zaradi omejenih virov ni uspelo zagotoviti zanesljivosti delovanja in storitev je bila zaradi pomanjkanje sredstev ukinjena. V okviru diplomskega dela imamo namen predstaviti ovire, na katere študenti naletimo ob vpeljavi študijskih projektov, novih IT-storitev, z željo po posodobitvi učnih procesov. Hkrati bom predstavil tudi eno izmed možnih rešitev, vpeljavo centralnega modela zagotavljanja ITstoritev, konkretno računalniškega oblaka (»cloud computing«) v javnoizobraževalnem omrežju. Predstavili bomo vrste oblakov, se dotaknili njihovih sistemskih gradnikov in na grobo zastavili predlog vpeljave z morebitnimi prednostmi in pomanjkljivosti na podlagi trenutnih trendov na tržišču in lastnih izkušenj, pridobljenih pri delu in implementaciji oblaka v podjetju SRC d.o.o.. V nalogi smo se poskusili direktno navezati na potencialne tehnične in ekonomske prednosti ter pomanjkljivosti oblaka glede na zahteve študentskih projektov, konkretno, projekta TikiWiki CMS. Teza, ki jo želimo potrditi, je, da lahko pravilno vpeljan centralni sistem zagotavljanja ITstoritev v javnoizobraževalnem okolju omogoča trenutno najbolj smotrn, praktičen in ekonomičen dostop do osnovnega ogrodja računalniških virov. Izobraževalne ustanove bi s tem namreč lahko tvorile digitalne peskovnike, inovacijske inkubatorje za kreativne in inovativne rešitve in hkrati okolje, kjer lahko dozorjene in uveljavljene rešitve služijo svojem namenu izboljšavi učnih in delovnih procesov in po drugi strani kot odskočna deska za širšo vpeljavo. 1

14 2 TEORETIČNI DEL 2.1. O OBLAKIH Računalniški oblaki oz. t.i.»cloud computing«je zelo širok pojem, ki v najbolj preprosti obliki opisuje princip ponujanja računalniških storitev preko interneta. Če bi želeli bolj natančno in kompleksno opisati ta pojem, bi po besedah Buyya et al. (1) oblak lahko bil»...paralelni in distribuiran računalniški sistem, ki vsebuje izbor dinamično priskrbljenih, med seboj povezanih virtualiziranih računalnikov, vidnih kot eno ali več združenih računalniških sredstev, baziranih na SLA (»Service-Level Agreement«, dogovor o ravni storitev), dogovoru med ponudnikom storitev in odjemalcem«. Ker pa računalniški viri niso nujno virtualizirani ter SLA mogoče ne obstaja v ekonomskem vidiku, bi se najbolj strinjal z definicijo ameriškega Nacionalnega inštituta za standarde in tehnologijo, NIST (2), ki definira računalništvo v oblaku kot»...plačaj-po-uporabi (»pay-per-use«) model za omogočanje dosegljivega, priročnega mrežnega dostopa do akumuliranih računalniških sredstev (npr. omrežje, strežniki/procesorska moč, diskovna polja, aplikacije, storitve...) na zahtevo, ki se lahko priskrbijo ali sprostijo takoj, z minimalnim administrativnim vložkom in/ali interakcijo ponudnika storitev«. 2

15 Slika 1: Referenčni model oblaka NIST (3) Računalništvo v oblaku (v nadaljevanju oblak) mogoče na prvi pogled deluje kot revolucionarna sprememba v IT-ju, dejansko pa samo združuje koncepte virtualizacije strojne opreme, avtomatizacije IT-operacij in standardizacije procesov oz. storitev in programskih vmesnikov (API) (4). Oblak predstavlja nabor določenih računalniških virov, ki jih lahko ponudnik storitev, kot bi sklepali po imenu, ponuja kot storitve. Zaradi močne konkurence, nasičenosti tržišča ter nastopa globalne krize se je v IT-ju začelo prestrukturiranje z željo po preobrazbi IT-ja v t. i.»utility computing«, orodno računalništvo, s končnim ciljem ustvariti ekonomski model, ki sloni na periodičnem obračunavanju ter ekonomiji obsega. Z malce satiričnim poimenovanjem se ta model imenuje tudi vse-kot-storitev,»everything-as-a-service«, z namigom, da se vse možne ideje, aplikacije, infrastruktura lahko obravnavajo in seveda zaračunajo kot storitev Osnovne karakteristike računalniških oblakov NIST (2) definira naslednje osnovne karakteristike oblaka: 3

16 - Samopostrežba na zahtevo: uporabnik si lahko sam dodeljuje računalniške vire, brez posredovanja ponudnika storitev. - Širok nabor dostopa: storitve so dostopne preko mreže z uporabo standardnih mehanizmov in protokolov ter so na voljo za uporabo širokemu naboru odjemalcev. - Združevanje virov: ponudnikovi viri združeno strežejo uporabnikom po večnajemniškem modelu, z možnostjo dinamične razporeditve fizičnih in navideznih oz. virtualnih virov po potrebi. - Hitra odzivnost: viri in funkcionalnosti se lahko, do neke mere tudi avtomatično, prožno dodeljujejo in sproščajo v skladu s potrebami uporabnikov, ki te vire vidijo kot neomejene. - Merjene storitve: storitve se merijo na podlagi porabe spodaj ležečih virov. Poraba se lahko spremlja, nadzira in poroča, kar - omogoča transparentnost tako uporabniku kot ponudniku storitve Korenine in gradniki oblakov Oče računalništva v oblaku bi lahko bil Joseph Carl Robnett Licklider (5), eden od razvijalcev ARPANET-a (»Advanced Research Projects Agency Network«, prvo TCPIP omrežje in prekurzor Interneta), ki je v 60-ih predstavil idejo»intergalaktične računalniške mreže«. Njegova ideja o vsesplošnem, svetovnem omreženju in dostopanju do programja, vsebin in podatkov od koderkoli je v današnjem času zelo podobna definiciji oblaka. Kot alternativni izvor ideje o oblaku strokovnjaki omenjajo tudi znanstvenika Johna McCarthyja (5), ki je prav tako v divjih 60. predlagal, da se računalništvo lahko ponuja kot javna storitev, vendar je ideja na globalni ravni zaživela šele z razširitvijo uporabe širokopasovnega dostopa do interneta. Izvor poimenovanja»oblak«ni natančno znan, beseda pa po vsej verjetnosti izhaja iz prvotne simbolične predstavitve interneta v arhitekturnih dokumentih, kjer je zaradi nedoločene lokacije, obsega in izvora uporabnikov ali računalniških virov v internetu uporabljen simbol oblaka (6). 4

17 Dasiravno se javnosti oblak predstavlja kot revolucijo v računalništvu s skoraj magičnim elementom niza treh ali več devetk (99, %) zanesljivosti (7), z navidezno neomejenimi sistemskimi sredstvi in podobnim, gre v osnovi za formalno obliko že implementiranih konceptov, dobrih praks v računalništvu, ki pa je z dosegljivostjo in razširjenostjo potrebnih gradnikov zaživel v polnem razcvetu šele v zadnjih nekaj letih. Osnovni gradniki, pomembni za razvoj, širitev ter splošno sprejetje oblak0v, so: - SOA in spletni servisi, - Web 2.0,»mashup«in širokopasovni dostop do interneta, - virtualizacija SOA in spletne storitve SOA ali»service Oriented Architecture«(storitvam usmerjena arhitektura) in spletne storitve (»Web Services«) so že uveljavljeni koncepti, a predstavljajo temeljne tehnologije za računalniške oblake. Storitve v oblaku se tipično načrtujejo in kreirajo kot spletne storitve, ki sledijo standardom, kot so»soap«(»simple Object Access Protocol«),»WSDL«(»Web Services Description Language«) in»uddi«(»universal Description, Discovery and Integration«), kreirane pa so na obstoječih vseprisotnih tehnologijah, kot so HTTP/S, HTML, XML,.... SOA organizira in upravlja spletne storitve v oblaku. V SOA so programski viri preoblikovani v»storitve«, natančno definirane in celovite (»self-contained«) module, ki nudijo standardno poslovno funkcionalnost in so neodvisni od statusa ostalih storitev Web 2.0,»mashup«in širokopasovni dostop do interneta Web 2.o je novejši koncept in predstavlja uporabo spletnih tehnologij in oblikovanja za razvoj večpredstavnosti, kreativnosti, izmenjave informacij in sodelovanja med uporabniki.»mashup«oz. hibridna ali prepletena storitev je koncept spletne aplikacije, ki črpa podatke iz enega ali več virov in jih združi v eno podatkovno orodje. Uporabo kompleksnih spletnih aplikacij na masovni ravni pa je omogočila razširitev širokopasovnega dostopa do interneta v 9o. letih (5). 5

18 Virtualizacija Virtualizacija ni ravno nov termin, kajti že v sredini 60. let so IBM-ovi strokovnjaki takratnim izredno dragim računalnikom»mainframe«pripojili t. i. funkcionalnost»time sharing«, najbolj preprost koncept virtualizacije, ki je omogočala dodeljevanje določenega števila CPUciklov v izbranem časovnem intervalu različnim uporabnikom (8), (9). Zaradi zahteve po veliki koncentraciji logično ločenih strežnikov je ogromen potencial za oblak pomenil razvoj strojne virtualizacije (10) na razširjeni platformi x86. Velik napredek na tej platformi je omogočil prihod procesorskih tehnologij Intel VT-x in AMD-V za strojno podporo virtualizaciji, ki sta zmanjšala kompleksnost virtualizacijske kode in podporo ter povečala učinkovitost rabe sistemskih sredstev in zmogljivost virtualiziranih sistemov (11). Dodatno napredovanje v zmogljivosti pa je posledica razvoja večjedrnih procesorjev, ki so omogočila hipervizorjem (Slika 2) vzporedno porazdelitev bremena po posameznih jedrih v gostiteljskem strežniku (12). Slika 2: Shema hipervizorja VMware (13) V oblaku pa najdemo nekaj tipičnih elementov: - kontrolno programje, upravljalno ploščo (»dashboard«), ki služi kot glavni uporabniški grafični vmesnik za nastavitev, upravljanje ter dodeljevanje virtualnih virov in funkcionalnosti, 6

19 - procesiranje (»compute«), glavni element IaaS-a, ki omogoča deljenje strežniške procesorske moči in pomnilnika v uporabo kot storitev ter hkrati zagotavlja uporabnikom nadzor in upravljanje, - objektno ter blokovno shrambo (»object, block store«), storitvi, dosegljivi preko spletnih API-jev, namenjeni učinkovitem shranjevanju podatkov v oblaku. V objektni shrambi se za razliko od blokovne shranjujejo podatki kot objekti in eksplicitno ločujejo metapodatki od podatkov, - omrežni del storitev (»networking«), sistem za upravljanje omrežja in omrežnih ter varnostnih funkcionalnosti. Podpira večnajemniški sistem, izolacijo posameznih uporabnikov in ponuja ogrodje za postavitev dodatnih varnostnih mehanizmov, kot so IDS, požarne pregrade, VPN, izenačevalniki obremenitve... - zaledne storitve, kot so upravljanje uporabnikov, predlog strežnikov in sistemov za merjenje ter zaračunavanje porabljenih storitev. Poimenovanje gradnikov se sicer od proizvajalca do proizvajalca (ponudnika) programske opreme lahko razlikuje, funkcionalnost pa ostaja v osnovi enaka. Za primerjavo sta spodaj prikazani arhitekturi OpenStack (Slika 4) ter VMware vcloud (Slika 3). 7

20 Slika 3: Arhitektura oblaka VMware vcloud Slika 4: Arhitektura oblaka OpenStack (50) 8

21 Nivoji in modeli storitev v oblaku Storitve v oblaku so razdeljene na tri osnovne nivoje glede na abstrakcijski nivo ponujenih funkcionalnosti ter storitvenega modela ponudnika (1) (14) (Slika 5). Slika 5: Tipi in nivoji storitev v oblaku (15) Ti nivoji abstrakcije so hierarhični in nižji nivoji se lahko uporabijo kot gradniki višjih: - Infrastruktura kot storitev (»Infrastructure-as-a-Service«, v nadaljevanju IaaS) predstavlja osnoven nivo storitev v oblaku, ponujanje virtualiziranih virov (procesna moč, pomnilnik, diskovni podsistem, pasovna širina...) na zahtevo. IaaS ponudnik lahko tako nudi stranki prosto izbiro VM-strežnikov, operacijskih sistemov (OS) in njihovih komponent, lahko pa zgradi že paket predizbranih in prednastavljenih OS in/ali programja z namenskim delovanjem. Primer take storitve je Amazon EC2 (»Elastic Compute Cloud«), kjer so uporabniku na voljo proste roke pri kreiranju lastne rešitve, hkrati pa je na voljo množica že prednastavljenih programskih rešitev. 9

22 - Platforma kot storitev (»Platform-as-a-Service, v nadaljevanju PaaS) je višji abstrakcijski nivo in ponuja razvojno okolje, ki omogoča razvoj in postavitev aplikacij brez potrebe po vnaprejšnjem določanju obsega. Razvojniki se ukvarjajo s sistemskimi zahtevami, hkrati pa so jim na voljo lahko tudi že vnaprej pripravljeni splošni moduli za avtentifikacijo, avtorizacijo, plačilni sistem, dostop do podatkovne zbirke... Primer PaaS je Google AppEngine in IBM PureCloud, ki omogočata razvojnikom dostop do določenih razvojnih okolij (Python, J2EE) ter uporabo lastniško strukturiranih objektnih hramb. - Programska oprema kot storitev (»Software-as-a-Service«, v nadaljevanju SaaS) leži na vrhu hierarhije oblaka. Storitve, ki jih ponudniki nudijo po principu SaaS, so tipično dosegljive preko spletnega vmesnika oz. brskalnika. Oblaki tako sledijo trendu migracije tradicionalnih namiznih, lokalnih aplikacij na spletne vmesnike. Tipični primer SaaS je spletni portal Salesforce.com, ki nudi aplikacijo CRM (»Customer Relationship Management«) preko spleta, uporabnikom pa omogoča prilagoditve in uporabo na zahtevo v terminu 24/7 (24 ur na dan, 7 dni v tednu). Prav tako sta primer SaaS Google Apps, Microsoft Office 360, ki nudita poslovne aplikacije, in TrendMicro Cloud Security, ki ponuja storitev protivirusne zaščite preko njihovih lastnih vmesnih (»proxy«) strežnikov. Obstaja še nekaj modelov, ki so v osnovi razširjeni nivo SaaS ali pa združujejo lastnosti več različnih nivojev. Najbolj pogosti so MaaS,»Monitoring-as-a-Service«ali nadzor kot storitev, BaaS,»Backup-as-a-Service«ali varnostno kopiranje kot storitev, ter CaaS,»Communicationas-a-service«ali komunikacije kot storitev. Relativno nov pojem je tudi MBaaS,»Mobile- Backend-as-a-Service«ali mobilno zaledje kot storitev. MaaS omogoča nadzor nad IT-komponentami: storitvami, strojno ter programsko opremo, brez potrebe po načrtovanju in vpeljavi kompleksnih lokalnih nadzornih rešitev. CaaS nudi uporabnikom dostop do celovitih komunikacijskih rešitev, vključno z dostopom do tehnologij, kot so VoIP (»Voice over IP«),»Unified Communications«, VPN... BaaS ali bolj pogosto»cloud Backup«ali»Remote Backup«zaradi potencialne zamenjave z»backend-as-a-service«omogoča uporabnikom izvajanje varnostnega 10

23 kopiranja na oddaljene lokacije v oblaku. Tako uporabniki ne potrebujejo osnovne infrastrukture za varnostno kopiranje, strežnikov, specializiranega programja, tračnih knjižnic ipd., temveč samo agente na ščitenih strežnikih, ki se povezujejo na centralni strežnik za varnostno kopiranje v oblaku. Tak primer rešitve ponuja na primer Asigra Cloud Backup. Termin»Cloud backup«v navezi s klasično programsko opremo za varnostno kopiranje, kot je na primer Symantec BackupExec, CA ArcServe, ipd., je malce zavajajoč, saj ne gre za dejansko varnostno kopiranje kot storitev, kjer je uporabnik lastnik licenc in je zadolžen za vpeljavo in delovanje programja, temveč samo za dodatno programsko funkcionalnost, ki omogoča shranjevanje podatkov v oblaku (»Cloud Storage«) preko Amazon EC2 združljivih veder ali»buckets«ali preko lastniških formatov. MBaas nudi splošne, generične zaledne strežniške storitve mobilnim aplikacijam. Pred kratkim sta začela vzpon nova in potencialno zelo atraktivna modela storitev, namenjena predvsem končnim uporabnikom: tiskanje v oblaku kot storitev (»Cloud printing Service«, CPS) ter igre v oblaku (»Gaming-as-a-Service«, Gaas ali tudi»cloud Gaming«) Tipi oblakov Poznamo več različnih tipov vpeljave oblaka. Trenutno so najbolj pogosti štirje: javni, skupnostni, privatni in hibridni (14) (2) (Slika 5). Javni oblak predstavlja najbolj znan tip oblaka, na voljo je tako posameznikom kot podjetjem, dostop je mogoč preko interneta z uporabo spletnih aplikacij. Ponudniki so tretje osebe, podatkovni centri so na poljubnih lokacijah po svetu, na isti strojni opremi pa so lahko aplikacije oz. storitve drugih uporabnikov. Skupnostni oblak je namenjen ekskluzivni rabi za specifično skupino uporabnikov iz različnih organizacij z enakimi potrebami, kot so na primer specifične varnostne in regulacijske zahteve ter politike. Privatni ali interni oblak je za razliko od javnega na voljo le na lokalnem ali navideznem privatnem omrežju (VPN). Zgrajen je ekskluzivno, po meri, za eno stranko, ki ima tako lahko nadzor nad celotnim okoljem, vsemi podatki, varnostjo. 11

24 Privatne oblake lahko stranke zgradijo s pomočjo lastne IT-ekipe ali pa oblak izdvajajo in jim ga zgradi ponudnik storitev v oblaku. Hibridni oblak združuje dva ali več različnih modelov oblakov v transparentno, enovito celoto, s pomočjo standardnih ali lastniških tehnologij, ki omogočajo medsebojni prenos podatkov in programja po potrebi Prednosti uporabe oblakov Osnovne karakteristike, opisane v poglavju 2.1.1, samopostrežba, vsesplošen preprost dostop in uporaba, učinkovita izraba virov, prožnost in dinamičnost ter zaračunavanje po porabi, so hkrati tudi neposredne, splošno znane prednosti uporabe oblaka. Oglaševane splošne prednosti ponujajo vsaj osnovna izhodišča za gradnjo nadaljnjih pričakovanj. Večina proizvajalcev in ponudnikov tehnologij, vezanih na oblake, ima de facto pristranske poglede na lastne produkte, zato povzemamo NIST (16), JISC (17) ter angleško konzultantsko IT-podjetje IT Governance (18), ki omenjajo naslednje prednosti: - takojšen dostop do velike izbire programja, brez dodatnih namestitev in prenosov, - dostop do programja je mogoč od praktično koderkoli po svetu, s kateregakoli računalnika (ne upoštevajoč morebitne varnostne politike in/ali omejitve), - uporaba storitev je na zahtevo, brez predhodnih investicij oz. stroškov za strojno in programsko opremo, - delitev razpoložljivih sredstev in virov, - zaračunavanje storitev po dejanski porabi, - skalabilnost z uporabo virov»na zahtevo«(»on-demand«), kar omogoča skoraj neomejeno, transparentno širitev kapacitet, skladno z zahtevami in potrebami uporabnikov in/ali organizacij. Pri primerjavi oblaka z gostovanjem (»hosting«), ki omogoča fizično izdvajanje (»outsourcing«) podatkovnega centra zunanjemu ponudniku, so glavne razlike naslednje: - storitve v oblaku se kupujejo/prodajajo na zahtevo, - uporabniki imajo popoln nadzor nad porabo storitev, 12

25 - storitve upravlja ponudnik. Posebej je treba poudariti zadnjo postavko, ki je po mojem mnenju ena izmed glavnih prednosti uporabe oblaka. Prenos izvedbe operativnih storitev (inicialna postavitev, migracije, oskrbovanje, operativna vzdrževanja, nadgradnje, varnostni pregledi...) od končnega uporabnika do ponudnika pomeni poleg razbremenitve izvajanja zamudnih skrbniških opravil tudi potencialno višjo kakovost izvedbe zaradi strokovnih znanj, ki jih ponudnik (ponavadi) ima Tveganja in pasti Navkljub mnogo prednostim oblaka obstaja kar nekaj pomanjkljivosti in tveganj, ki kot dvorezni meč izhajajo direktno iz prednosti samih. IT Governance (18) omenja sledeča tveganja: - podatki niso v fizični posesti uporabnikov, temveč ponudnika, - uporabniki lahko postanejo vezani, odvisni od ponudnika, - zagotavljanje neprekinjenega poslovanja in okrevanje po katastrofi je v rokah ponudnika, - migracija podatkov ob menjavi ponudnika pomeni dodaten strošek in aktivnosti, - zagotavljanje delovanja in dostopa do podatkov v primeru prenehanja poslovanja ponudnika. Buyya et al. (1) ter Fuhrt et al. (14) poleg naštetega omenjajo še dodatne izzive, kot so: - varnost: storitve, do katerih dostopajo uporabniki, so na voljo preko interneta, zunaj lastnih požarnih pregrad in varnostnih politik, - zasebnost: podatki in storitve so na skupnih virih, ki si jih uporabniki delijo med seboj, - zmogljivost: zaradi skupne uporabe so viri deljeni, kar povzroča potencialne težave pri zagotavljanju popolne neodvisnosti obremenitve okolij gostujočih organizacij. Prav tako pa je treba upoštevati, da vsi tipi obremenitev, kot so recimo I/O, transakcijsko intenzivne podatkovne baze, niso primerni za gostovanje v oblaku, - internetna povezava in pasovna širina: dokler se poslovno kritične storitve organizacij nahajajo znotraj lokalnega omrežja, pasovna širina internetnega dostopa navadno ni 13

26 kritična komponenta. Z migracijo v oblak povezava postane kritična, hkrati pa zahteva razmislek glede pasovne širine ter oddaljenosti ponudnika zaradi poslovnih in tehničnih zahtev organizacije, kot so recimo način, vrsta dela in število uporabnikov, količina dnevno pretočenih podatkov, zahtevana odzivnost programja oz. latenca povezave... Oblak ni univerzalna rešitev, primerna za vsakega uporabnika IT-storitev, poudarja NIST (16), in kot vse ostale nove, napredne tehnologije vsebuje obilo unikatnih pomislekov, odprtih točk, ki jih mora posameznik predelati pred prehodom. Poleg že naštetega NIST omenja še sledeče: - latenca, ki jo povzroči čas povratne poti od uporabnikove internetne povezave do ponudnika oblaka je odvisna od množice faktorjev (oddaljenost, vrsta povezave, obremenjenost linij, napake, izpadi,..), ki niso pod njegovim nadzorom. Uporaba aplikacij mora te faktorje upoštevati, - sinhronizacija podatkov je problematična, ko je uporabnik storitev brez povezave in nima dostopa do podatkov v oblaku. Če uporabnik potrebuje dostop do podatkov tudi brez internetne povezave, je treba upoštevati sinhronizacijske mehanizme, nadzor nad verzijami dokumentov, postopke kolaboracije v skupini - pregled in primerjava SLA-pogodb (niso standardizirane, vsaka ima po svoje definirane termine, na kar je treba biti pozoren), - okrevanje po katastrofi, ki ga lahko povzročijo tako strojne kot programske težave uporabnika in so lahko posledica vrste dejavnikov, zakomplicira dejstvo, da uporaba ponudnikovih geogruč (»geocluster«) ne jamči okrevanja po katastrofi, ker uporabnik nima vedno možnosti ročne izbire fizične lokacije za izvajanje lastne delovne obremenitve, - skladnost ponudnika z regulatornimi zahtevami uporabnika Ekonomski vidik Če se spomnimo na izvor zahtev po oblaku, storitvenem modelu zaračunavanja računalniških storitev, ugotovimo, da so stroški oz. nižanje le-teh gonilna sila evolucije oblaka: 14

27 zaračunavanje storitev po dejanski uporabi. Na oder stopi ROI, finančna metrika, ki pove razmerje med stroški investicije in pričakovano donosnostjo. ROI (»Return Of Investment«, donosnost naložbe), TCO (»Total Cost of Ownership«, celotni stroški lastništva) sta sicer zelo zguljeni in vsebinsko pogosto zlorabljeni med menedžerji in v marketingu (19), podata pa lahko povsem uporabno oceno donosnosti, na podlagi katere se lažje odločimo za investicijo (20). [%] = ( č š ž ) š ž ROI pomaga pridobiti samo oceno donosnosti naložbe, ne upošteva pa verjetnost realizacije donosnosti ali rizikov, povezanih z dotično investicijo. TCO pomaga ugotoviti razliko med ceno investicije in njenimi dolgoročnimi stroški = + + ž + + š Za praktičen izračun ROI oblaka nam pomaga izračun njegovega TCO (celotnega stroška naložbe) : Tako je ROI oblaka: ( ) = č š + š + š ( ) = ( + ) ( ( )) ( ) Otipljive oz. prednosti, ki jih lahko izmerimo, so: - zmanjšanje stroškov dela (zmanjšanje števila ljudi v IT), programske opreme (v modelu SaaS), licenc in vzdrževanja, tehnične in uporabniške podpore, vzdrževanja opreme (nadgradnje, posodobitve, popravki ), gostovanja (fizična lokacija, elektrika, hlajenje ), - zvišanje produktivnosti: mobilnost uporabnikov in dostop z različnih lokacij lahko zviša produktivnost, - učinkovita raba virov: uporaba virov po potrebi, 15

28 - izboljšana varnost/skladnost: ponudniki oblakov lahko ponujajo varnostne rešitve po najboljši praksi, - strokovnost in usposobljenost: dostop do visokousposobljenega in izkušenega strokovnega kadra pri ponudniku brez lastnih stroškov za zaposlovanje, - skalabilnost: širitev virov na zahtevo, brez kupovanja kapacitet»na zalogo«, - agilnost: hitrejša postavitev in pričetek uporabe programja oz. storitve (pri modelih SaaS/PaaS/IaaS/ ), - zadovoljstvo strank: učinkovita uporaba storitev v oblaku lahko poveča odzivnost, - zanesljivost: vprašanja brezprekinitvenega poslovanja in okrevanja po katastrofi rešujejo ponudniki z uporabo podvojenih lokacij, - čas delovanja: z uporabo nadzornih orodij ponudniki spremljajo in skrbijo za visok čas neprekinjenega delovanja. Neotipljive ali strateške prednosti pa so lahko: - nove poslovne priložnosti: storitev v oblaku je lahko kritičen element za pridobitev novih poslov ali širitev na druge trge, - osredotočenje na osnovno dejavnost: viri, porabljeni za obrobne IT-dejavnosti, se lahko sprostijo in uporabijo za podporo osnovne dejavnosti, - zadovoljstvo zaposlenih: mobilnost in hitrejše delovanje lahko izboljša zadovoljstvo zaposlenih in poveča inovativnosti, - kolaboracija: interaktivna komunikacija lahko poveča kakovost dela, - prenos odgovornosti: določene odgovornosti, kot so izpad delovanja, varnostni incidenti, okrevanje po katastrofi se lahko prenesejo na ponudnika. Stroški vpeljave oblaka se lahko razdelijo na tri tipe: začetne, operativne in enkratne. Začetni stroški pred pričetkom uporabe storitev v oblaku so lahko: - tehnična priprava: nadgradnja potrebne infrastrukture (internetna povezava, mrežne naprave ) za dostop do storitev v oblaku, - vpeljava: prehod v oblak lahko zahteva dodatne storitve, - integracija: prikrojitev nastavitev lahko zahteva dodatne storitve, 16

29 - izobraževanje: IT-kader lahko potrebuje izobraževanje za delo z upravljavskimi orodji oblaka. Izobraževanje uporabnikov je prav tako lahko potrebno za uporabo novega programja, - organizacijske spremembe: določeni poslovni procesi se bodo mogoče morali prilagoditi oblaku. Operativni oz. ponavljajoči se stroški so vezani na uporabo storitev v oblaku: - naročnina: pogodbeno periodično zaračunani stroški za uporabo storitev, - upravljanje s spremembami: stroški, vezani na spremembo procesov in zahtev po spremembah sistema, - administracija: stroški, povezani z nadzorom in uveljavljanjem SLApogojev, usklajevanje s ponudnikom, nadzor nad njegovimi aktivnostmi in storitvami, - usklajevanje oblakov: uporabniki večje množice storitev v oblaku lahko potrebujejo koordinacijo in usklajevanje za zagotavljanje integracije in konsistence, - podpora za končnega uporabnika: nekatere dele stroškov sicer pokriva naročnina, druge dele pa uporabnik storitev, - zmanjševanje tveganja: potrebna vpeljava protiukrepov za obvladovanje tveganja, ki jih prinaša oblak, - zmanjševanje/zviševanje obsega: nekateri ponudniki lahko zaračunavajo stroške ob spremembi obsega storitev in/ali virov. Enkratni stroški, stroški, povezani s prekinitvijo uporabe storitev, zajemajo ali povrnitev delovne obremenitve na izvorno lokacijo ali pa premestitev v okolje drugega ponudnika: - prečrpavanje podatkov iz oblaka, preverjanje vsebine, - strošek varnega brisanja podatkov v oblaku, - načrtovanje in izdelava lokalnih storitev za zamenjavo storitev v oblaku, - stroški pogodbenih kazni v primeru prezgodnje prekinitve pogodbe, - sprememba namembnosti oz. nakup računalniških in človeških virov, potrebnih za podporo delovanja storitev. Z določitvijo vrednosti posameznih elementov potencialnih prednosti in stroškov, nastalih pri prehodu v oblak, lahko uporabnik pride do vrednosti TCO, na podlagi katere lahko 17

30 izračuna tudi ROI. Odločitev o prehodu v oblak mora biti tehtna, podkrepljena ne samo s tehničnimi, ampak tudi z ekonomskimi argumenti, v izogib potencialnim nevšečnostim zaradi nerealnih pričakovanj TEHNIČNE ZAHTEVE ZA POSTAVITEV RAČUNALNIŠKEGA OBLAKA Podatkovni center Centralni podatkovni centri, grajeni po standardu ANSI/TIA-942 (21) ali po priporočilih inštituta»uptime«(22), so glede na zanesljivost definirani po nivojih (»Tiers«). Nivo 1 predvideva najbolj osnovno okolje, brez ali z minimalno redundanco napajanja, hlajenja, ITkomponent, s pričakovanim 99,67 % neprekinjenega delovanja (»uptime«), po drugi strani pa nivo 4, ki je primeren oz. zahtevan za najbolj kritična okolja, predvideva več podvojenih komponent, povezav, napajanja, hlajenja in s tem predvideva 99,99 % neprekinjenega delovanja. Slika 6: Shema Lampertz varnega podatkovnega centra (23) 18

31 Če upoštevamo obseg celotnega javnoizobraževalnega omrežja, ocenjujemo, da bi moral podatkovni center za javnoizobraževalni oblak poleg osnovnih lastnosti, kot so dvignjen pod, fizično varovanje, kontrola dostopa in zadostna površina za strežniške omare, zagotavljati vsaj nivo 2 redundance Električno napajanje Napajanje mora zagotavljati 2N 1 -redundanco, kar prepreči možnost ene kritične točke odpovedi in s tem izpad delovanja oblaka. Podatkovni center mora za delovanje zagotavljati dovolj skupne električne moči, v primeru izpada električne energije pa mora delovanje prevzeti generator. Za vmesni čas med preklopom na redundančno napajanje mora biti za ločeno vejo napajanja doveden neodvisen UPS-sistem ustreznih kapacitet. Do strežniških omar tako vodijo po dve povsem ločeni napajalni poti Hlajenje Veliki podatkovni centri vse bolj pogosto uvajajo vodno hlajenje, navadno preko zadnjih vrat strežniških omar, vendar so ti sistemi dragi in nepraktični v primeru izpusta tekočine, zato so zračne klimatske naprave trenutno najcenejša alternativa. Strežniške omare je treba razporediti po prostoru tako, da se ustvarijo neprekinjene tople in hladne cone za izboljšanje učinkovitosti hlajenja. Za samo hlajenje morata biti prisotni vsaj dve enoti za zagotavljanje redundance N+1 ali 2N. Moč klimatskih naprav mora biti vsaj enaka maksimalni električni porabi podatkovnega centra Nadzor in upravljanje okolja Relativno vlago, temperaturo različnih con in porabo električne energije je treba spremljati in nadzirati sproti. V primeru presega določenega praga se definira alarmno obveščanje preko standardnih, uveljavljenih protokolov (SMTP, SMS, SNMP/TRAP). 1 N+1, N+2, 2N, 2N+1, 2N+2 so oznake različnih stopenj redundance za povečano odpornost na napake; N+1 pomeni potrebno opremo in en dodaten kos, 2N, kot v našem primeru, pa pomeni dvakrat toliko opreme, kot je potrebno. Več informacij na»

32 Protipožarni sistem Pri gradnji podatkovnega centra je smotrno upoštevati evropske standarde za protipožarno gradnjo v IT-centrih; - SIST EN :2009 +A1: Varnostne shranjevalne enote - Klasifikacija in metode preskušanja odpornosti proti ognju - 2. del: Prostori in vsebniki za shranjevanje podatkov (24), - SIST EN : Preskusi požarne odpornosti - 1. del: Splošne zahteve (25), - SIST EN : Preskusi požarne odpornosti in dimotesnosti vrat, zapor in oken, ki se odpirajo, ter elementov stavbnega okovja - 1. del: Preskus požarne odpornosti za vrata, zapore in okna, ki se odpirajo (26). V skladu s SIST EN :2009 +A1:2013 je zahtevan minimalni razred za protipožarno zaščito vrat in kletke R 60 D. Standard UL 72,»Tests for Fire Resistance of Record Protection Equipment«(27), narekuje minimalni razred 150 za zaščito magnetnih medijev Fizična varnost Za zaščito pred vlomi se upošteva standard SIST EN 1627: Vrata, okna, obešene fasade, mreže in polkna - Protivlomna odpornost - Zahteve in klasifikacija (28). Varnostne kamere in protivlomni alarmi morajo biti prisotni v celotnem objektu, s povezavo do varnostno-operativnega centra. Standard ANSI/TIA-942 (21) nivo 3 zahteva varnostno kompartmentizacijo podatkovnega centra v varnostne cone z avtentifikacijo in avtorizacijo dostopa Varnostno kopiranje Čeprav smo omenili, da virtualizacija omogoča varnostno kopiranje preko posnetkov stanj ( ), je ta mehanizem preveč potraten in rigiden za vsakodnevno uporabo brez dodatnih orodij in naprav. Varnostno kopiranje pravzaprav ni de facto standardna funkcija v oblaku, je pa dodatna storitev, ki jo ponavadi izvaja ponudnik infrastrukturnih storitev v oblaku. 20

33 Naprave za varnostno kopiranje V osnovi je možno izvajati varnostno kopiranje na dodaten, ločen disk ki služi kot odlagališče za varnostne kopije. Tak način izvajanja varnostnega kopiranja v oblaku je stroškovno neučinkovit, ker uporabnik najema dodaten primaren diskovni prostor za hrambo podatkov obrobnega pomena. Najhitreje se sicer izvedejo varnostne kopije kar na obstoječem, hitrem diskovju, kar pa je potratno, ker se diskovni mediji cenovno razlikujejo predvsem po hitrosti, hitrost medija pa narekuje njegovo uporabo; najhitrejši mediji so namenjeni pogosti izmenjavi podatkov, počasnejši pa bolj arhivskemu tipu podatkov 2. Možna je uporaba tretje poti, uporaba prednosti obeh medijev po principu»d2d2t«(»disk-to-disk-to-tape«); zmogljivostno najbolj zahtevna in pogosta varnostna kopiranja se izvajajo najprej začasno na (cenejše) diskovne medije, potem pa z manjšo frekvenco za daljši čas ali celo kot arhiv na tračne enote. Tako z uporabo samo delčka celotne diskovne kapacitete omogočimo izvedbo varnostnih kopij v zelo majhnih časovnih okvirjih in hkrati poskrbimo za varno in cenovno dosegljivo trajno hrambo podatkov Programska oprema za varnostno kopiranje Ročno izvajanje varnostnega kopiranja brez namenske programske je seveda možno in je tudi zelo pogosto (29) ter praktično, se pa uporaba zaplete pri: - standardizaciji postopkov zaradi množice različnih orodij, - usklajevanju urnikov za izvajanje operacij na različnih sistemih, - nadzoru nad statusi varnostnih kopiranj pri veliki količini strežnikov, - združljivosti z različnimi napravami za varnostno kopiranje, - izvajanju varnostnega kopiranja med delovanjem aplikacije, 2 Diski tipa SSD (»Solid State Disks«) in SAS (»Serial Attached SCSI«) s RPM (obratov na minuto) so namenjeni podatkovnim bazam, transakcijskim dnevnikom in zahtevnim aplikacijam, diski z RPM operacijskim sistemom in manj zahtevnim aplikacijam, najpočasnejši diski s RPM hrambi podatkov, trakovi pa za varnostno kopiranje in arhiv. Trenutno se sicer na tržišču odvija dvoboj med tračnimi in diskovnimi mediji za varnostno kopiranje (49). Oba medija imata svoje prednosti in pomanjkljivosti, da pa ne zaidemo izven okvirjev osnovne teme, bi lahko posplošili, da so tračni mediji bolj prenosljivi, v osnovi cenejši in bolj obstojni, vendar počasnejši. 21

34 V okoljih, kjer so takšni pomisleki tehtni, pride v poštev namenska programska oprema za varnostno kopiranje, ki omogoča centralen vpogled nad celotnim okoljem za varnostno kopiranje, s podporo množici naprav za varnostno kopiranje in izvajanju varnostnega kopiranja med samim delovanjem. Če izhajamo iz potreb skrbnika storitve, sta osnovni zahtevi oz. možnosti varnostnega kopiranja storitev v izobraževalnem oblaku minimalno dve: - varnostno kopiranje slik generičnih virtualnih strežnikov, kar omogoča hitro varnostno kopiranje in konsistentno restavriranje datotečnega sistema ter hitro okrevanje po katastrofi, - varnostno kopiranje z agenti za zahtevne aplikacije, kot so predvsem podatkovne baze, ki zahtevajo posebne postopke za izvedbo konsistentnega kopiranja podatkov v predpomnilniku. Gartner trenutno omenja štiri igralce v vrhu svojega magičnega kvadranta (30): CommVault, EMC, IBM in Symantec, ki imajo prvovrstne produkte za zahtevna poslovna okolja. Za namen povrnitve delovanja storitve v izobraževalnem oblaku ima večina produktov veliko več funkcionalnosti, kot bi jih potrebovali, so pa zanimivi produkti treh ostalih omenjenih podjetij: NetApp, Veeam ter Asigra. NetApp ima širok repertoar programskih rešitev za varnostno kopiranje, ki se tesno integrirajo z njihovo strojno opremo in delujejo transparentno z večino virtualizacijskih produktov. Veeam trži produkt Backup & Replication, ki je trenutno ena izmed vodilnih rešitev za varnostno kopiranje in replikacijo v virtualnem okolju. Asigra je dokaj nov igralec na tržišču, ponuja pa svojevrstno programsko rešitev za ponudnike storitve varnostnega kopiranja v oblaku (»BaaS«oz»Cloud Backup«) Strojna oprema V grobem bi strojno opremo lahko ločili na strežniški, diskovni in omrežni del. Za vsak posamezen del je na podlagi zahtev po virih treba določiti zmogljivost opreme. Zahteve se seveda definirajo na podlagi prej opravljene analize, študije, ki mora obsegati čim širši spekter končnih potencialnih uporabnikov. Čeprav je za končnega uporabnika oblak sicer 22

35 baziran na modelu»pay-as-you-go«(1), je ponudnik 3 v osnovi omejen z obstoječimi računalniškimi viri, sledenje rasti potreb na zahtevo pa lahko ovirajo nabavni procesi. Tako je pri analizi treba upoštevati tudi nabavne postopke in roke za opremo, kajti nakup»na zalogo«ni ekonomičen, po drugi strani pa so javni razpisi dolgotrajni postopki, povsem odvisni od zunanjih dejavnikov Strežniški sistem Če povzamem zahteve in izsledke iz poglavij ter , potrebuje strežniški sistem v grobem: - podporo virtualizaciji, - podvojenost komponent za zagotavljanje visoke razpoložljivosti. Strežniški sistem mora dodatno zagotavljati ekonomično ravnovesje med razpoložljivo procesorsko močjo, pomnilniškimi kapacitetami ter porabo energije za napajanje in hlajenje. Prav tako mora zagotavljati dovolj vhodno/izhodne prepustnosti za mrežno in diskovno povezljivost. Glede na najbolj tipične zahteve strežnikov v oblaku (13) (31) so tehnične zahteve za strežniški sistem : - najvišja možna gostota procesorske moči in pomnilnika glede na višino v strežniški omari (32), - največja možna količina pomnilnika glede na ceno, - dovolj procesorske moči za toliko virtualnih strežnikov, kolikor jih omogoča kapaciteta pomnilnika, - mrežna povezljivost visoke propustnosti, - diskovna povezljivost visoke propustnosti, - redundantnost kritičnih komponent, - nizki stroški nakupa in vzdrževanja (porabe električne energije za pogon in hlajenje). Kot primer razlikovanja v razmerju tipskih značilnosti med različnimi tipi strežnikov gostota virov, vrednosti investicije in stroški vzdrževanja smo kreirali konfiguracije štirih različnih 3 Pri vpeljavi privatnega oblaka v izobraževalno okolje bi bila to lahko na primer strokovno usposobljena organizacija, kot je npr. Arnes, ki pokriva širok spekter izobraževalnih ustanov. 23

36 strežniških sistemov, sicer proizvajalca IBM, vendar osnovne karakteristike lahko držijo tudi za druge proizvajalce. Izsledki kažejo, da je pri planiranju obsežnejših implementacij za zagotavljanje rentabilnosti rešitve treba upoštevati namenskost opreme ter zato odluščiti čim več funkcionalnosti, torej komponent, ki zvišujejo ceno, ne ponujajo pa neposredne koristi za osnovni namen. 1U-strežnik predstavlja tipični dvoprocesorski strežnik višine 1U (4,445 cm), katerega namen je gostovanje virtualiziranih okolij, zahtevnih spletnih storitev, tudi v oblaku, ali manj zahtevnih, lokalnih, kritičnih aplikacij in podatkovnih baz (33). Podrobne specifikacije strežnika se nahajajo v prilogi A. 2U-strežnik predstavlja tipične štiriprocesorske strežnike višine 2U (8,89 cm), ki omogoča širjenje delovne obremenitve navznoter (»scale-in workload«), tako virtualizacije kot zahtevnih, kritičnih aplikacij (34). Podrobne specifikacije strežnika se nahajajo v prilogi A. Rezinski strežniki (»blade«) predstavljajo strežnike s konsolidiranimi komponentami, kot so napajanje, hlajenje, komunikacijska oprema, nadzor, upravljanje v t. i. rezinskih ohišjih ali centrih (»blade center«). Rezinska arhitektura omogoča optimalno razmerje med učinkovito izrabo energije in dostopnostjo strežniških kapacitet z nižjimi operativnimi stroški upravljanja. Uporabljen dvoprocesorski rezinski strežnik predstavlja kategorijo rezinskih strežnikov visoke gostote (dva strežnika velikosti ene rezine). Optimizirani so predvsem za izvajanje virtualnega delovnega bremena (35). Podrobne specifikacije strežnika se nahajajo v prilogi A. Strežniki visoke gostote predstavljajo namenske, dvoprocesorske strežnike polovične višine 1U (dva na 1U velikost), preproste in poceni gradnike oblakov večjih razsežnosti (36). Njihova glavna prednost je preprostost, zmogljivost ter cena ob visoki skalabilnosti (37). Podrobne specifikacije strežnika se nahajajo v prilogi A. Četudi je namembnost strežnikov v osnovi podobna, se pri večjih postavitvah lahko opazijo velike razlike med učinkovitostjo, ekonomičnostjo in skalabilnostjo. Za lažji pregled razlik smo na primeru ene standardne računalniške omare, bruto višine 42U (~2 m), napolnjene s strežniki do višine 38U, v pregledinici B.1 v prilogi B prikazali razlike med maksimalnimi kapacitetami, ceno investicije, operativnimi stroški (poraba elektrike za delovanje in hlajenje) za 3 leta in primerjali cene glede na enoto, jedro pomnilnika CPE ali 10GB. 24

37 Grafična ponazoritev izsledkov (Slika 7) iz preglednice B.1 prikazuje razlike med maksimalnimi kapacitetami števila jeder in GB-pomnilnika izbrane specifikacije strežnikov skupaj pomn. (GB) skupaj jeder 576 1U strežniki 2U strežniki rezinski strežniki strežniki visoke gostote Slika 7: Primerjava maksimalne količine virov med različnimi tipi strežnikov na omaro 25

38 1.006,44 704,08 649,31 689,30 626,64 cena/jedro 502,92 536,35 502,83 cena/pomn. (10 GB) 1U strežniki 2U strežniki rezinski strežniki strežniki visoke gostote Slika 8: Primerjava cen na enoto CPE (jedro) in pomnilnika (10 GB) , , , ,00 cena investicije3 operativni stroški (3 leta) skupaj jeder , , , ,56 1U strežniki 2U strežniki rezinski strežniki strežniki visoke gostote Slika 9: Primerjava razmerja med stroški in številom jeder na omaro 26

39 Diskovni podsistem Diskovni podsistem kot temelj oblaka mora biti skalabilen in odziven, sposoben ustreči konicam uporabe, a hkrati ne sme biti predimenzioniran. Trenutni trend na področju diskovnih polj je transparentna uporaba flash tehnologije (38), kar sicer zvišuje začetno investicijo zaradi trenutno visokih cen SSD/flash komponent, a v končni fazi povečuje zmogljivost in podaljšuje uporabno dobo diskovnih polj. Tehnologija SSD/flash omogoča izredno hitre naključne dostope do podatkov, ker so ti hranjeni v NAND-pomnilniškem čipu, in ne nekje na vrteči se plošči, do koder so mora fizično premakniti glava (39). Zaradi visoke cene flash pomnilnika na GiB se še vedno uporablja kot začasni pomnilni medij predpomnilnik. Poimenovanje te funkcionalnosti se razlikuje med produkti in/ali proizvajalci, glavni primeri pa so (38): -»Tiering«, ki omogoča premik t. i. vročih točk, najbolj uporabljenih blokov iz vrtljivih diskov, na SSD, -»Caching«, bralno ali pisalno predpomnjenje podatkov na flash pomnilniku. Diskovna tehnologija SAS prevladuje nad FC (»FibreChannel«) tako glede dostopnosti kot cene (40), zato izbor diskovnega polja s FC-zaledjem cenovno ni upravičljiva tudi performančno več ne. FC kot ogrodje SAN-omrežja prav tako ni več nujno najbolj učinkovita izbira za oblak. Prednosti, ki jih nudi konvergirano omrežje FCoE (»FibreChannel-over- Ethernet«) ne gre spregledati: - cena (ni potrebna investicija v ločene komponente LAN ter SAN), - hitrost (10Gbit povezave, 40Gbit»uplink«), - majhen odtis (en vmesnik za povezavi SAN in LAN), - poenostavljene povezave (omrežji SAN in LAN o preko enega fizičnega kabla), - virtualizacija vmesnikov (preprost nadzor in upravljanje vmesnikov) Omrežne komponente Povezljivost, ožilje oblaka, zaradi kompleksnosti in poudarka na varnosti zahteva posebno pozornost. Mrežno arhitekturo je zaradi velikih stroškov, težav in potencialnega izpada storitev ob naknadnih spremembah treba ustrezno zastaviti že v začetku ter planirati 27

40 potencialno rast sorazmerno s širitvijo storitev v oblaku. Gostota strežnikov in uporaba virtualizacije zahtevata tudi večjo gostoto mrežnih priključkov in robnih naprav (14). Trenutno najbolj razširjeni načini povezovanja v podatkovnem centru so EoR (»End of Row«) (Slika 10), mrežna oprema na koncu vrste ToR (»Top of Rack«), na vrhu stikala ter integrirano in konvergirano omrežje4. Vsak izmed pristopov ponuja svoje prednosti in pomanjkljivosti, izbor specifičnega pristopa je odvisen od več dejavnikov, kot so investicijski ter vzdrževalni budžet, lokacija, sposobnost in potrebe po spremljanju in vpeljavi novih tehnologij, količina ter usposobljenost kadra (41). Slika 10: Integrirana mrežna arhitektura s priklopom na stikala EoR preko delilcev Konvergirana infrastruktura združuje več IT-komponent, strežniške, mrežne in podatkovne vire, diskovne sisteme ter programsko opremo v celoto, z enotno točko upravljanja, avtomatizacije in orkestracije vseh virov. Konvergirano omrežje odpravlja potrebe po fizično ločenih omrežjih LAN in SAN ter naprav z združitvijo omrežij IP in FC. Prav tako lahko 4 Integrirano in konvergirano omrežno opremo predstavljajo stikala, integrirana v rezinske centre, ki zbližujejo oz. konvergirajo omrežja LAN in SAN prek konvergiranih omrežnih kartic (»CNA«,»Converged Network Adapter«). 28

41 zmanjša stroške investicije z zmanjševanjem števila potrebnih stikal ter povezav in kablov. Z avtomatizacijo podpornih procesov in konsolidacijo mrežnih in diskovnih ekip pa se dodatno zmanjšajo še operativni stroški vzdrževanja konvergirane infrastrukture (42). Z uporabo navideznih stikal (»vswitch«) pa se srečamo s programsko definiranim omrežjem (»Software-defined networking«). Navidezna stikala omogočajo virtualizacijo celotnih omrežij v programski opremi in služijo dinamičnem zagotavljanju ter upravljanju povezljivosti med virtualnimi viri (43). Open vswitch distribuirano navidezno stikalo, kot del sistema OpenStack Neutron, omogoča povezovanje navideznih virov sistema OpenStack Nova (Slika 11). Slika 11: Povezava naprav z Open vswitch stikalu v OpenStack (44) Varnostna oprema Varnost v oblaku mora naslavljati celo goro vprašanj (45) in obravnava tako ponudnikove postopke, procedure, arhitekturo rešitve kot znanja ter uporabljene tehnološke rešitve. JISC je glede varnosti v oblaku povzel (46) priporočila NIST (16), ki opozarja na različne nivoje kompleksnosti pri uporabi in vpeljavi različnih tipov oblaka. Tehnološki in arhitekturni aspekt varnosti v oblaku mora upoštevati specifične lastnosti oblaka, kot so uporaba internetnih povezav, večnajemništvo (»multitanency«), komunikacije 29

42 med virtualnimi komponentami Za zagotavljanje funkcionalnosti, definiranih v točki 4.2.2, je možno vpeljati t. i. statične ali klasične varnostne elemente, vendar je zaradi dinamičnosti okolja v oblaku bolj smotrno uporabiti elemente, ki»razumejo«in upoštevajo arhitekturo in prednosti oblaka ter njegove komponente. Statični oz. klasični varnostni elementi so vsi varnostni elementi, ki se uporabljajo za zaščito fizičnih (klasičnih) okolij. Primeri so klasični požarni zidovi, posredniški strežniki, sistemi za zaznavanje in/ali preprečevanje vdorov, zaščitno programje Takšni elementi lahko povsem zadostno služijo namenu v fizičnem okolju, v virtualnem svetu pa se pojavi potencialen problem zaradi omejitev fizičnega okolja. Virtualni strežniki namreč komunicirajo med seboj, česar fizične varnostne naprave niti ne ugotovijo (Slika 12). Slika 12: Razlika med varnostnimi mehanizmi v fizičnem in virtualnem omrežju (47) Rešitev je v uvedbi dinamičnih varnostnih elementov, ki se namestijo na nivoju hipervizorja in virtualnih mrežnih naprav ter tako zagotavljajo enak nivo nadzora kot v fizičnem svetu. Primeri takih elementov so: - virtualne robne varnostne komponente, - virtualni požarni zidovi, ki izolirajo večnajemniška okolja, 30

43 - virtualne ID/PS-naprave, ki čistijo promet med virtualnimi okolji in znotraj njih potencialno škodljivih aktivnosti ter po potrebi izvajajo preprečevalne akcije, - zaščitno programje, ki kot vtičniki v samem hipervizorju transparentno pregledujejo promet in izvajajo ustrezne akcije ob zaznavi škodljivega programja. Ostale varnostne komponente so nadzorna orodja s pregledom nad vsemi elementi oblaka ter orodja za upravljanje varnostnih informacij in dogodki (»SIEM«, Security Information and Event Management (48)), ki skrbijo za pregled nad varnostnimi dogodki v sistemu, skladno z varnostnimi zahtevami in priporočili (49) Podvojenost komponent Sistemska arhitektura načeloma povsod narekuje neprekinjeno delovanje ob izpadu posamezne komponente, še posebej v oblaku, kjer je gostota uporabnikov na komponento večja. Takšna arhitektura brez kritične točke odpovedi (»no single point of failure«) zahteva podvojenost kritičnih komponent oz. komponent, katerih izpad je kritičen za delovanje sistema in storitev, tako na mrežnem kot na strežniškem in diskovnem nivoju. Podvojene ali redundantne komponente so tako tipično: - napajalniki, - diski z uporabo RAID-funkcionalnosti, - diskovni krmilnik ob uporabi zunanje pomnilniške naprave, - komunikacijske poti in naprave, - posamezni strežniki Visoka razpoložljivost Z eliminiranjem kritične točke odpovedi pridobimo sicer zanesljivost delovanja strojne opreme in posredno raven delovanja storitve. Žal pa nam to ne koristi, če pride do izpada več kritičnih komponent na enem sistemu ali okvare hipervizorja, napake v operacijskem sistemu ter aplikativni programski opremi. Zanesljivost prav tako nima vpliva na prekinitve delovanja zaradi rednih ali izrednih vzdrževalnih posegov na strojni opremi (7). 31

44 Z uporabo virtualizacije in funkcionalnosti, ki jih le-ta prinaša, lahko na infrastrukturni ravni izvajamo: - migracijo virtualnih strežnikov v živo (»Live migration«), ki omogoča prenos VM na drugega gostitelja, brez izpada delovanja same VM, - migracijo diskov v živo (»Disk migration«), ki omogoča prenos podatkovnega dela VM na drugo lokacijo brez izpada delovanja, - visoko razpoložljivost virtualnih strežnikov v gostiteljski gruči, ki skrbi za minimalen izpad delovanja virtualnih strežnikov ob izpadu enega izmed gostiteljev v gruči, - odpornost ob napakah (»Fault Tolerance«), ki jo trenutno sicer nudi samo produkt VMware vsphere, pomeni pa nadgradnjo visoke razpoložljivosti z neprekinjenim delovanjem virtualnih strežnikov, tudi ob izpadu gostiteljskega strežnika v gruči, - posnetke virtualnih strežnikov (»snapshot«) za hitro varnostno kopiranje in povrnitve v prvotno stanje celih virtualnih strežnikov, - kloniranje virtualnih strežnikov za hitro postavitev novih strežnikov, raznih testnih okolij ali celotnih novih storitev. Visoko razpoložljivost lahko dosegamo tudi na aplikativnem nivoju z uporabo podvojenih komponent v večnivojski arhitekturi storitve; več spletnih strežnikov stoji za izenačevalniki obremenitev (»load balancer«) in komunicirajo s samostojnimi ali gručnimi aplikativnimi strežniki. Podatki iz aplikativnih strežnikov pa se shranjujejo v gruči podatkovnih strežnikov Okrevanje po katastrofi Da bi zagotovili delovanje storitve tudi v primeru katastrofalnega izpada, bi potrebovali možnost povrnitve delovanja v najkrajšem možnem času. Katastrofalni izpad pomeni izpad ene ali več vej (četudi visokorazpoložljivih) komponent, kar v oblaku praviloma pomeni izpad delovanja ene ali več ponudnikovih storitev. Ker so ponudniki v SRS (Sporazum o Ravni Storitve ali»sla«,»service Level Agreement«) pogodbeno vezani na zagotavljanje določene ravni zanesljivosti delovanja, je glede na vpliv izpada na poslovanje treba razmišljati tudi o okrevanju po katastrofi (»disaster recovery«). Okrevanje navadno vključuje dodatno, sekundarno lokacijo z dovolj sistemskih virov za prenos in delovanje storitev ob izpadu primarne lokacije. Velikost in število okrevalnih lokacij (»disaster recovery site«) je odvisna 32

45 od zahtevane stopnje delovanja oz. kritičnosti izpada za poslovne procese. Najbolj osnovne okrevalne lokacije so lahko že»raztegnjeni«podatkovni centri»metro«razdalje (do 50km), brez visokorazpoložljivih sistemskih virov na oddaljenem delu, ki v primeru izpada primarne lokacije zagotavljajo delovanje le najnujnejših storitev. Napredni scenariji pa po drugi strani lahko predvidevajo samozadostne, aktivne geogruče (»geocluster«), ki služijo tako za razdelitev bremena po geolokacijah kot za okrevalno lokacijo za prevzem bremena vseh izpadlih. Razlika v vpeljavi okrevanja po katastrofi tiči lahko tudi v samih postopkih, scenarijih povrnitve. Lahko predvidevajo povsem ročne preklope, kar pomeni dodatne akcije in čas za zagon storitve na okrevalni lokaciji. Taki scenariji so tipični za aktivno/pasivne okrevalne arhitekture, kjer je v vsakem trenutku aktivna le ena lokacija in zajema kompleksne postopke za vzpostavitev prvotnega stanja (»failback«) in preklop delovanja nazaj na primarno lokacijo. Aktivne gruče, ki poleg zagotavljanja okrevanja po katastrofi v osnovi omogočajo tudi delitev obremenitve, praviloma zagotavljajo praktično transparenten preklop ob izpadu ene lokacije, z minimalnim časom izpada delovanja storitve. Kot si je moč misliti, so glavna omejitev vpeljave višjih nivojev zanesljivosti pravzaprav samo finančne zmožnosti ponudnika/naročnika. Aktivne gruče namreč na oddaljeni lokaciji zahtevajo podvojene računalniške kapacitete, ustrezno hitre povezave med lokacijami ter ustrezne tehnologije, ki omogočajo sinhrono replikacijo podatkov s podprtimi mehanizmi ob minimalni latenci Programska oprema Programska oprema, namenjena podpori delovanja vseh nivojev oblaka, mora podpirati odprto standardno strojno opremo, različne, najbolj razširjene hipervizorje in vsebovati vse pomembne komponente, naštete v poglavju OpenStack je CMP-projekt, licenciran po Apache License 2.0, upravljavec je OpenStack Foundation. S projektom sta začela Rackspace Hosting in NASA julija 2010, glavni namen pa je organizacijam omogočiti ponujanje storitev v oblaku na standardni strojni opremi (50). Funkcionalno podpira zahteve iz poglavja z moduli oz. projekti (Slika 4) (51): 33

46 - OpenStack Compute (Nova); upravlja in avtomatizira računalniške vire preko podprtih hipervizorjev XEN, KVM, QEMU, vsphere, Hyper-V, ali pa direktno s strojno opremo (52), - OpenStack Object Storage (Swift); objektna shramba, omogoča redundaten zapis podatkov na več strežnikov v podatkovnem centru in skrbi za replikacijo ter integriteto podatkov, - OpenStack Block Storage (Cinder); omogoča shranjevanje podatkov na nivoju blokov za performančno zahtevne scenarije. Z uporabo gonilnikov na podprtih diskovnih podsistemih je Cinder sposoben direktno izvajati diskovne operacije, kot so kreiranje, brisanje, širjenje diskov, manipulacija diskovnih posnetkov, ipd. (53), - OpenStack Networking (Neutron); sistem za upravljanje z omrežjem. Omogoča izolacijo okolja, uporabo dodatnih varnostnih mehanizmov (IDS, LB, požarni zidovi, VPN), - OpenStack Dashboard (Horizon); nadzorna konzola, ki omogoča uporabnikom grafični dostop za upravljanje najetih virov. Podpira integracijo z zunanjimi produkti in servisi preko OpenStack API ali EC2 kompatibilnem API, - OpenStack Orchestration (Heat); orodje, ki orkestrira upravljanje nad infrastrukturrnimi viri in omogoča hitre postavitve uporabniških okolij. Podpira OpenStack REST API in CloudFormation Query AP, za upravljanje s predlogami in gradnjo storitev uporavlja zunanja orkestracijska orodja kot so Puppet, Chef, Ansible ali Salt, - OpenStack Identity Service (Keystone) ponuja globalno avtentifikacijo in avtorizacijo uporabnikov preko centralnega imenika čez vse OpenStack storitve, - OpenStack Image Service (Glance) je poseben servis za manipulacijo z diskovnimi slikami in predlogami. Za shranjevanje podatkov zna uporabljati več različnih zalednih storitev, med drugim tudi Swift, - OpenStack Metering Service (Ceilometer), storitev za merjenje in zaračunavanje uporabe vseh OpenStack modulov. 34

47 3 EKSPERIMENTALNI DEL 3.1. PROJEKT "TikiWiki CMS" Projekt CMS (krat., ang. Content Management System, sistem za upravljanje vsebine) TikiWiki ( smo začeli kot seminarsko nalogo v okviru predmeta digitalne priprave pod mentorstvom dr. Bojana Petka leta Ideja je bila vzpostaviti sistem, ki bo primarno omogočal hrambo in izmenjavo dokumentov, večjih od 10 MB, ki so pri digitalni pripravi, komunikaciji med naročnikom in izvajalcem, pogosti; pomanjkanje primernih tehničnih rešitev pa je v tistem časovnem obdobju povzročalo nepotrebne zamike in zapletenost delovnih procesov. Pošiljanje in prejemanje večjih datotek je nezanesljivo zaradi morebitnih omejitev velikosti sporočil na vmesnih poštnih strežnikih (»MTA«) (54). Prav tako se lahko pojavijo časovni zamiki zaradi zaščite pred nezaželeno pošto, uporabe sivega seznama, ki začasno zavrne sporočilo in zahteva ponovno pošiljanje po določenem zamiku (55). Zaradi trenda rasti uporabe socialnih medmrežij pa smo dodatno želeli v dokumentni sistem integrirati tudi socialne elemente, kot so forum, klepetalnice, blog, galerije in ostali»groupware«, orodja za skupinsko delo skupinski koledar, pošto... Glede na razmerje med zahtevnostjo postavitve in prisotnostjo dodatnih, že integriranih socialnih funkcij, je bila takrat najbolj logična izbira TikiWiki CMS. TikiWiki CMS Groupware (Slika 13) je odprtokodni CMS, baziran na programski opremi MediaWiki. Pisan je v programskem jeziku PHP, za zaledje (ang.»backend«) uporablja podatkovno bazo MySQL. Za dodatne funkcionalnosti integrira druge, specializirane odprtokodne projekte, kot so DHTML Calendar, FeedCreator, Graphviz, HAWHAW, jquery, Morcego, phpcas, Smarty, Zend Framework (56). Za uporabniški in administrativni dostop se uporablja spletni grafični vmesnik, ki omogoča centralno upravljanje uporabnikov in skupin ter delitev privilegijev glede na vloge. TikiWiki je CMS»vse-v-enem«, za razliko od ostalih, ki omogočajo širitev funkcionalnosti z uporabo vtičnikov oz. razširkov (ang.»plugins«,»extensions«). Z uporabo vnaprej integriranega sistema smo se izognili vsem morebitnim težavam ob ročni integraciji dodatnih funkcionalnosti, nadgradnjah in uporabi uradno nepodprtih vtičnikov drugih proizvajalcev ter tako skrajšali čas postavitve. Slaba stran takšnega integriranega sistema pa je prav ta tesna integracija, kar pomeni omejenost z 35

48 obstoječimi funkcionalnostmi, brez možnosti nadgradnje funkcionalnosti ali zamenjave s potencialno boljšimi, specializiranimi produkti. Slika 13: TikiWiki CMS Privzet izgled (57) Četudi je pri izgradnji spletnih storitev izgled skoraj bolj pomemben kot funkcionalnost (58), TikiWiki pa je navkljub podpori temam CSS (»Cascading Style Sheet«) na izgled precej utilitaren, je sistem zaradi razmeroma uspešne zadovoljitve specifičnih uporabniških potreb in velike podpore dr. Petka zaživel. Nastajali so dokumenti, raslo je število wiki člankov, vezanih na temo grafične tehnike v skladu s smernicami ostalih profesorjev, nalagale so se multimedijske vsebine, vezane na seminarske naloge, prav tako je rasla skupnost in s pomočjo dr. Petka se je razširila uporaba tudi med druge skupine študentov. Ključni besedi za širitev storitve sta bili odprtost in pragmatičnost; odprtost v pomenu možne uporabe sistema brez administrativnih omejitev, dosegljivosti storitve študentom z vseh lokacij, nalagale so se lahko vse (legalne) vsebine 5, bralni vpogled v vsebine je bil omogočen vsem itn.; pragmatičnost pa v smislu uporabnosti storitve z reševanjem jasno specificiranih, vidnih težav, apliciranjem ustrezne rešitve čim širšemu spektru uporabnikov. 5 Omejitve so sicer obstajale na velikost vsebin zaradi omejenih strežniških kapacitet. 36

49 Izhajali smo namreč iz prepričanja, da je študentom treba olajšati delo z omogočanjem dostopa do orodji, ki manjšajo režijsko delo, brez birokratskih zapletov, čakanja na odobritve uporabe, omejitev pri dostopu Tehnične lastnosti postavitve Strežnik TikiWiki smo postavili na operacijskem sistemu OpenSUSE Linux 10.1 zaradi preprostejšega upravljanja (59), podporo novejšim paketom Apache2, MySQL, PHP, brez potrebe bo dodatnem prevajanju izvorne kode, kar posledično prinaša standardizirano okolje in s tem preproste nadgradnje programske opreme in operacijskega sistema. Za strežnik smo uporabili delovno postajo, ki je bila takrat na voljo; z 1 Ghz AMD procesorjem, 2 GB pomnilnika, enim SATA 160 GB trdim diskom in enim napajalnikom. TikiWiki CMS je z URL naslovom 6 zaživel V začetku je bila omogočena prosta samoregistracija, kasneje smo zaradi varnosti dodali»captcha«mehanizem za prepoznavo človeških uporabnikov in potrjevanje prijav po e-pošti. Za operativno delo upravljanja z uporabniki, tj. spremembe gesel, avtorizacij, pravic dostopa, moderiranje foruma in izmenjevanih datotek,..., sem v začetku skrbel sam, ko pa se je zaradi števila uporabnikov količina takšnega dela povečala, smo rekrutirali za pomoč še dve študentki, sošolki Petro Ožbolt in Petro Vurušič. V končni fazi smo sistem operativno in administrativno vzdrževali dve operaterki in dva administratorja Tehnične zahteve TikiWiki CMS 13.1 TikiWiki CMS za delovanje zahteva (60): spletni strežnik (Apache HTTPD, Windows IIS, lighthttpd) s 100 MB prostega prostora in 512 MB pomnilnika, MySQL ali MariaDB podatkovni strežnik (različice 5+), PHP (različice 5.5+). 6 Na tem naslovu NTF TikiWiki ne obstaja več, konceptualen ogled delovanja TikiWiki CMS pa je možen na strani 37

50 Za pravilen prikaz vsebin potrebuje tudi knjižnice libxml, mbstring, ctype, fileinfo, calendar in iconv. Za preprost ter hiter prikaz vseh manjkajočih zahtev in parametrov lahko uporabimo program»tiki-check.php«, ki je na voljo na spletnem naslovu» Postopek osnovne namestitve zahtevane programske opreme Na novo postavljen operacijski sistem OpenSUSE Linux 13.2 namestimo zahtevano programsko opremo: - Spletni strežnik Apache HTTPD, - programsko okolje PHP, - podatkovni strežnik MariaDB (ali MySQL), - dodatne knjižnice libxml, mbstring, ctype in iconv smo namestili, manjkajo še knjižnice fileinfo ter calendar. Ob osnovni namestitvi podatkovnega strežnika MariaDB moramo nastaviti geslo za uporabnika»root«, izbrisati uporabnika»anonymous«in podatkovno zbirko»test«. Uporabniku»root«omogočimo dostop le z lokalnega strežnika. TikiWiki CMS zahteva že pripravljeno podatkovno zbirko z naborom UTF-8 in uporabnika z geslom. Ustvarimo ju lahko preko spletnega vmesnika»phpmyadmin«ali»webmin«, lahko pa tudi z ukazno vrstico Postopek namestitve programske opreme TikiWiki CMS Programsko opremo TikiWiki CMS prenesemo s spletne strani» Arhiv raztegnemo v svoj podimenik v imeniku»documentroot«spletnega strežnika. V našem primeru je absolutna pot namestitve»/srv/www/htdocs/tikiwiki«. Namestitev TikiWiki CMS zahteva še pravilno dodelitev pravic na datotečnem sistemu. V ta namen uporabimo priloženo ukazno datoteko»setup.sh«. 38

51 Za nadaljevanje namestitve uporabimo spletni vmesnik tako, da brskalnik napotimo na naslov» 7 ]/[ime_tikiwiki_podimenika]/tiki_install.php«. V našem primeru je naslov» V prazna polja vnesemo vrednosti, ki smo jih določili ob namestitvi podatkovnega strežnika v poglavju in za podatkovni pogon izberemo InnoDB 8. Po končani namestitvi se prijavimo z uporabnikom in geslom»admin«. Geslo po prvi prijavi zamenjamo Prikaz delovanja TikiWiki CMS iz uporabniškega vidika TikiWiki CMS ponuja veliko možnosti za prilagoditev izgleda in funkcionalnosti po meri. Vsi namestitveni, uporabniški, skrbniški priročniki so na voljo na spletnem mestu» Kot smo že menili (1, 3.1.1), izvirnega spletišča NTF TikiWiki ni več voljo. Za prikaz in lažje razumevanje uporabljenih funkcionalnosti smo rekonstruirali spletišče na naslovu (61) (Slika 14). 7 Ime strežnika je ime, na katero se nam strežnik odziva na daljavo. 8 InnoDB podpira transakcijski način zapisovanja podatkov, kar omogoča večjo zanesljivost. MyISAM se uporablja predvsem za podatkovno skladiščenje. Več informacij o razlikah med InnoDB in MyISAM je na voljo na strani 39

52 Slika 14: NTF TikiWiki CMS - predloga domače strani TikiWiki CMS podpira razdeljevanje vlog glede na vrsto uporabnika. Za osnovno podporo delovnim procesom na NTF smo definirali 4 tipične skupine uporabnikov in njihove vloge: - Anonimneži: neprijavljeni uporabniki, z omejeno možnostjo branja vsebin, - Registrirani uporabniki(študenti): prijavljeni uporabniki, neomejeno možnostjo branja vsebin, dostop do vseh bralnih funkcij, omejene možnosti dodajanja vsebin, - Moderatorji(študenti, profesorji): registrirani uporabniki z dodatnimi moderatorskimi pravicami za moderiranje diskusij, komentarjev, prejetih vsebin, - Administratorji(študenti, profesorji): peščica registriranih uporabnikov z administrativnimi pravicami nad celotnim CMS. Na rekonstruiranem sistemu smo že pripravili slednje generične uporabnike s tipičnimi vlogami (Slika 15): 40

53 Uporabnik Skupine Geslo 9 admin SubAdmins Included Editors Included Registered Included Admins mare SubAdmins Included Editors Included Registered Admins (default) moderator1 Registered Editors Moderatorjevo1Geslo profesor1 Editors Included Registered SubAdmins Profesorjevo1Geslo student1 Editors Included Registered studenti Studentovo1Geslo Slika 15: NTF TikiWiki CMS - spisek pripravljenih generičnih uporabnikov z gesli 9 Za prijavo z uporabnikom moderato1, profesor1 ali student1 se uporabi ustrezna gesla v tabeli, ki se po prijavi ne menjajo. Možna je tudi registracija novega uporabnika, vendar je pred uporabo potrebna ročna odobritev uporabniškega računa ter umestitev v ustrezne skupine. Za pridobitev administrativnih pravic je potrebno kontaktirati avtorja diplomskega dela. 41

54 Tipičen primer uporabe NTF TikiWiki CMS je oddaja (seminarskih) nalog in izdelkov. Postopek je lahko sledeč: - Na wiki strani predmeta, katerega skrbnik je lahko profesor ali asistent, so zapisani vsi pomembni podatki za študente, med drugim tudi navodila za oddajo nalog (Slika 16), Slika 16: NTF TikiWiki CMS - primer wiki strani predmeta Tipografsko oblikovanje 42

55 - skladno z navodili lahko študenti posredujejo svoje vsebine preko galerije datotek (»File Gallery«) (Slika 17) ali pa jih pripnejo na wiki stran (Slika 18). Slika 17: NTF TikiWiki CMS - primer galerije datotek za izmenjavo vsebin 43

56 Slika 18: NTF TikiWiki CMS - primer pripete vsebine na strani wiki Delo v skupini (koordinacija med člani in mentorjem, izmenjava gradiva, upravljanje z različicami dokumentov,.. ) je podprto ob uporabi funkcionalnosti: -»Forum«za javno komunikacijo, koordinacijo, izmenjavo informacij (Slika 19), 44

57 Slika 19: NTF TikiWiki CMS - prikaz diskusije članov skupine na forumu -»Messaging«za zasebno komunikacijo, koordinacijo, izmenjavo informacij (Slika 20), 45

58 Slika 20: NTF TikiWiki CMS - uporaba zasebnega sporočilnega sistema -»File Gallery«repozitorij za izmenjavo, prenos vsebin znotraj skupine (Slika 21), 46

59 Slika 21: NTF TikiWiki CMS - primer operacije dodajanja vsebin člana skupine v galerijo datotek -»Revision history«za upravljanje z različicami dokumentov (Slika 22) 47

60 Slika 22: NTF TikiWiki CMS - primer upravljanja z različicami dokumenta Z uvedbo in uporabo teh postopkov ter funkcionalnosti smo poenostavili, poenotili ter pohitrili izmenjavo gradiva med učenci in učitelji. Z vpeljavo osnovne podpore skupinskem delu smo zmanjšali obseg režijskega dela, vpeljali sledljivost in izboljšali komunikacijo znotraj in med skupinami. 48

61 4 RAZPRAVA O REZULTATIH 4.1. TEŽAVE PRI PRODUKCIJI Varnost V IT-ju obstaja pravilo, da uporabnost in varnost ne gresta premočrtno skupaj (Slika 23) (62). Kot smo že omenili, je bila ena izmed osnovnih smernic projekta zagotoviti neomejen dostop študentom, ne glede na njihovo lokacijo, zato prvotno nismo uvedli dodatnih varnostnih omejitev dostopa. Omejili smo število delujočih servisov, nastavili kompleksna gesla. Slika 23: Sovisnost varnosti in uporabnosti rešitve Kmalu pa se je ob rutinskem pregledu delovanja strežnika izkazalo, da je treba malce bolj premišljeno uvesti varnostne mehanizme, ker je strežnik v roku nekajtedenskega delovanja že postal tarča napadov s surovo silo (»brute-force attack«) 10 prek SSH-protokola. Informacijski sistem NTF namreč ni imel požarnih pregrad za strežnike v t. i.»dmz«(»demilitarized Zone«; območje, namenjeno internetnim strežnikom, ločenim od lokalnega omrežja), kar pomeni, da je bil strežnik dostopen direktno, preko vseh protokolov. Žal je 10 Napad s surovo silo je eden izmed najbolj preprostih in pogostih napadov, vključuje pa enega ali več oddaljenih gostiteljev, ki se poskuša/-jo prijaviti na storitev z ugibanjem gesel znanih uporabnikov z uporabo slovarja ali pa kar z ugibanjem kombinacije alfanumeričnih znakov. 49

62 univerzitetni nabor IP-številk že bil v seznamu, ki ga vdiralci uporabljajo za slepo skeniranje TCP-vrat. Ker se je TikiWiki oglašal na ICMP, kot SSH- in HTTP/S-promet, je takoj postal tarča SSH-napadov s surovo silo (Slika 24). May 29 13:05:53 tux sshd[15365]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost= May 29 13:05:56 tux sshd[15365]: Failed password for invalid user matt from port ssh2 May 29 13:05:57 tux sshd[15367]: reverse mapping checking getaddrinfo for rdsnet.ro [ ] failed - POSSIBLE BREAK-IN ATTEMPT! May 29 13:05:57 tux sshd[15367]: Invalid user matt from May 29 13:05:57 tux sshd[15367]: pam_unix(sshd:auth): check pass; user unknown May 29 13:05:57 tux sshd[15367]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost= May 29 13:05:58 tux sshd[15367]: Failed password for invalid user matt from port ssh2 May 29 13:05:59 tux sshd[15369]: reverse mapping checking getaddrinfo for rdsnet.ro [ ] failed - POSSIBLE BREAK-IN ATTEMPT! May 29 13:05:59 tux sshd[15369]: Invalid user monica from May 29 13:05:59 tux sshd[15369]: pam_unix(sshd:auth): check pass; user unknown May 29 13:05:59 tux sshd[15369]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost= May 29 13:06:01 tux sshd[15369]: Failed password for invalid user monica from port ssh2 May 29 13:06:02 tux sshd[15371]: reverse mapping checking getaddrinfo for rdsnet.ro [ ] failed - POSSIBLE BREAK-IN ATTEMPT! May 29 13:06:02 tux sshd[15371]: Invalid user monica from May 29 13:06:02 tux sshd[15371]: pam_unix(sshd:auth): check pass; user unknown May 29 13:06:02 tux sshd[15371]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost= May 29 13:06:04 tux sshd[15371]: Failed password for invalid user monica from port ssh2 May 29 13:06:04 tux sshd[15373]: reverse mapping checking getaddrinfo for rdsnet.ro [ ] failed - POSSIBLE BREAK-IN ATTEMPT! May 29 13:06:04 tux sshd[15373]: Invalid user monica from May 29 13:06:04 tux sshd[15373]: pam_unix(sshd:auth): check pass; user unknown May 29 13:06:04 tux sshd[15373]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost= May 29 13:06:06 tux sshd[15373]: Failed password for invalid user monica from port ssh2 May 29 13:06:07 tux sshd[15375]: reverse mapping checking getaddrinfo for rdsnet.ro [ ] failed - POSSIBLE BREAK-IN ATTEMPT! May 29 13:06:07 tux sshd[15375]: Invalid user nicole from May 29 13:06:07 tux sshd[15375]: pam_unix(sshd:auth): check pass; user unknown Slika 24: Primer dnevnika napada s surovo silo na storitev SSH Za zaščito sistema smo zato vpeljali standardno rešitev za požarni zid na operacijskem sistemu Linux, paket»iptables«, s privzetim pravilom»dovoli promet na TCP vratih 443 in «. Za varno oddaljeno administracijo strežnika preko šifrirane povezave smo vpeljali programsko opremo»webmin«(63), ki z uporabo prikrojenih, prednastavljenih funkcij omogoča preprost in varen dvig pravic dostopa do strežnika preko SSH-protokola. Hkrati smo dodali časovno opravilo»cron«, ki na požarnem zidu, brez dodatnega skrbniškega posega, vsako uro preventivno onemogoči dvignjen dostop. 50

63 Alternativno bi sicer lahko omejili dostop preko SSH-protokola samo izbranim IP-naslovom, vendar bi bila rešitev lahko potencialno problematična zaradi dinamičnega dodeljevanja IPnaslovov internetnih ponudnikov, kar bi lahko posredno pomenilo oviro ob nujnih dostopih iz nepredvidenih lokacij, po drugi strani pa odobritev dostopa celotnem IP-segmentu slovenskih internetnih ponudnikov pomeni potencialno varnostno tveganje Zanesljivost strojne opreme Zaradi težav s strojno opremo je strežnik nekajkrat padel v t. i.»kernel-panic«(slika 25). Glede na simptome, občasne in naključne izpade, bi lahko sklepali na težave s pomnilnikom, vendar vzroka zaradi redke ponovljivosti in pomanjkanja sredstev za popravilo niti nismo iskali. Strežnik oz. delovna postaja je bila namreč že izven garancije, sredstev za popravilo ali nakup novega pomnilnika pa ni bilo na voljo. VFS: cannot open root device "" or 08:05 kernel panic; VFS: Unable to mount root FS on 08:05. Slika 25: Izsek napake»kernel panic«v dnevniku strežnika Napajanje Strežnik je iz delovne postaje poleg nezanesljivega drobovja podedoval tudi standarden napajalnik. Dasiravno je za namen delovne postaje to v večini primerov povsem dovolj, sta za strežniško uporabo 24/7 potrebna dva napajalnika z vsaj enim vodom na sistemu za neprekinjeno napajanje (UPS). Večkrat se je namreč zgodilo, da se je strežnik zaradi izpada električnega napajanja ugasnil sredi delovanja, kar je pomenilo izpad delovanja storitve in reševanje podatkov zaradi okvare datotečnega sistema. Ko gre za nenaden izpad delovanja, se v sistemskih dnevnikih ne zapišejo nobene dodatne informacije o izpadu. Ker delovna postaja nima dodatne opreme za diagnostiko delovanja internih komponent, ne moremo konkretno ugotoviti pravih vzrokov izpadov, podvojeno električno napajanje pa bi rešilo te težave Fizični dostop Strežnik je bil lociran v računalniškem laboratoriju, zato je bil prosto izpostavljen vsem uporabnikom prostora, profesorjem, asistentom, študentom. Najbolj pogost izpad se je 51

64 zgodil zaradi»vestnosti«mimoidočih, ki so v imenu skrbne porabe električne energije predvsem pred vikendi ali prazniki, ko je bil dostop do lokacije in strežnika najbolj otežen, vse računalnike ugašali, pogosto tudi naš strežnik. Nastavitev, da se strežnik ob pritisku na gumb za vklop/izklop samodejno ugasne, je omogočila beleženje vseh ugasnitev v sistemskem dnevniku; če pa bi tipko onemogočili, bi lahko strežnik bil ugasnjen na silo, kar je seveda slabše in pomeni enake težave kot v prejšnji točki Varnostno kopiranje Varnostno kopiranje je vedno obrobnega pomena, dokler ne pride do izgube podatkov. Preventivno smo izvedi začetno varnostno kopiranje na USB-disk za: - podatkovno bazo MySQL: izvoz v tabel v tar.gz datoteko, - datotečni sistem: arhiviranje /opt, /home, /data, /etc, /root, /var v.tar.gz. Za inicialno varnostno kopiranje smo vse datoteke tar.gz ali t. i.»tarball«prekopirali na zunanjo USB-enoto, kar pa se je izkazalo za mukotrpen, dolgotrajen podvig zaradi prisotnega vmesnika USB 1.1, ki je sposoben pretočiti maksimalno le 12 Mibit/s. Zaradi nepraktičnosti take procedure za vsakdanje varnostno kopiranje ter težav, opisanih v točki 4.1.4, smo bili primorani izvesti varnostno kopiranje na lokalni datotečni sistem. To samo po sebi ne predstavlja problema, če ima strežnik več fizičnih diskov, povezanih v RAID-polje (»Redundant Array Of Inexpensive Disks«) (64), ki ščiti podatke v primeru izpada delovanja fizičnega diska in datotečni sistem za varnostno kopiranje, ločen od virov. V našem primeru smo varnostne kopije sicer odlagali na ločen datotečni sistem in s tem ščitili varnostne kopije pred morebitno okvaro datotečnega sistema ob nenadnem izpadu delovanja strežnika, več fizičnih diskov in/ali RAID-polja pa nismo imeli. Prav tako ni bilo na voljo ne dodatnega strežnika, na katerega bi lahko odlagali varnostne kopije, ne obstoječe centralne rešitve za varnostno kopiranje. V končni fazi smo tako lahko sistem povrnili v prvotno stanje v primeru okvare datotečnega sistema in/ali baze podatkov, nismo pa ščitili podatkov na drugih fizičnih medijih, kar se je izkazalo za največjo pomanjkljivost sistema. Po dobrem letu in pol delovanja, polnjenju portala z vsebino članki, razpravami, dokumenti, predstavitvami in seminarskimi nalogami se je strežnik v času poletnih počitnic prenehal odzivati. Po pregledu delovanja sistema je bilo ugotovljeno, da je bil zaradi potreb strežnik ponovno nameščen in funkcionalno 52

65 spremenjen v delovno postajo. Podatkov tako ni bilo več, prav tako ni bilo več varnostnih kopij, ki bi omogočile restavriranje strežnika v prejšnje stanje PROJEKT TikiWiki CMS V OBLAKU V poglavju 2.1 smo predstavili računalniški oblak in njegove značilnosti, v poglavju 2.2 pa tehnične zahteve za njegovo postavitev. Kako bi nam pa oblak dejansko koristil v izobraževalnem okolju, katere lastnosti bi lahko rešile CMS-projekt TikiWiki ali konec koncev katerikoli drug podoben študentski projekt ali storitev? Dognanja se namreč lahko po večini aplicirajo tudi na druge projekte ali rešitve. V osnovi bi lahko večino težav rešili z močnejšo podporo računalniški infrastrukturi na fakulteti, vendar je treba upoštevati, da so sredstva tako za računalniške kot človeške vire na fakultetah omejene. Nakupovati strojno opremo na zalogo za vsak slučaj in nuditi kakovostne podporne storitve je za vse organizacije, ki to ni njihova primarna dejavnost, nesmotrno in pri tem izobraževalne ustanove niso izjema Začetna postavitev TikiWiki CMS bi v začetku vpeljavi, kot je bil postavljen tudi že prej, kot enotno, samostojno aplikacijo (Slika 26). 53

66 Slika 26: Osnovna enonivojska arhitektura TikiWiki S časom, ko naraste število uporabnikov in s tem potrebe po sistemskih sredstvih, aplikacijo razdelimo po principu tri-nivojske arhitekture; spletni ali»front-end«strežnik, aplikacijski strežnik in podatkovni ali»back-end«strežnik. Prednost več-nivojske arhitekture je v možnosti ločitve posameznih delov aplikacije v zmogljivostno in varnostno izolirane segmente. Spletni strežnik se loči zaradi varnostne izolacije v demilitariziranem območju ter, v primeru zaključevanja SSL sej, zmogljivosti. Aplikacijski in podatkovni strežnik, ki sta oba zaradi varnosti v notranjem omrežju, sta ločena zaradi zahtev po zmogljivosti, ki jih terja logika same aplikacije in podatkovnega strežnika. V primeru, da aplikacija dostopa do zaupnih podatkov, je smotrno ločiti podatkovni in aplikacijski strežnik s požarno pregrado. 54

67 Varnost Glede na težave z varnostjo, opisane v poglavju 4.1.1, bi postavitev naše storitve z uporabo ustrezne varnostne opreme (poglavje ) v oblaku z varnostnega vidika omogočila: - izolirano okolje z namenskimi VLAN-i za potrebe lokalnih skupin, kar ščiti različne storitve pred medsebojnimi vplivi, - robne varnostne komponente, ki nudijo transparentno varnostno zaščito pred vdori in napadi. Kot smo omenili (2.2.4) OpenStack takšno funkcionalnost omogoča s komponento neutron (65), VMware vcloud pa s produktom vshield Edge (66), - integrirano zaščitno programje v samem jedru hipervizorja (vshield Endpoint), - preprosto integracijo z dodatnimi, prenastavljenimi namenskimi virtualnimi napravami, kot so razni posredniški strežniki, IDS in požarni zidovi za vpeljavo dodatnih varnostnih mehanizmov in politik. Treba je upoštevati, da oblak narekuje visoko strežniško gostoto, ki zahteva medsebojno prepustnost; de facto dostopen je preko interneta, zato zahteva povezljivost in varnost; vsebuje ogromno različnih, med seboj nepovezanih okolij, kar zahteva nadzor ter možnost upravljanja vseh varnostnih komponent Zanesljivost strojne opreme Podvojenost komponent Z uporabo arhitekture brez kritične točke odpovedi ( ) in opreme bi se izognili večini težav z delovanjem storitve TikiWiki CMS zaradi nezanesljivega delovanja strojne opreme (4.1.2) Visoka razpoložljivost Z uporabo mehanizmov za visoko razpoložljivost bi lahko našo storitev iz osnovne, enonivojske arhitekture razdružili po nivojskih sklopih v večnivojsko storitev (Slika 27). S tem bi poleg večje zanesljivosti zaradi podvojenosti dosegli tudi večjo zmogljivost in varnost. Po 55

68 razdružitvi nivojev lahko posamezne nivoje v obliki navideznih strežnikov (VM) preselimo na različne gostitelje in tako zagotovimo, da delovanje enega fizičnega gostitelja ne vpliva na delovanje naše celotne storitve. Hkrati s tem dosežemo tudi večje zmogljivosti, ker si posamezni nivoji ne delijo in/ali kradejo sistemskih virov. Za dodatno varnost nam lahko vpeljava dodatnih požarnih pregrad med posameznimi nivoji omogoči omejevanje prometa in njegov pregled med nivoji. Slika 27: Shema podvojene večnivojske arhitekture TikiWiki 56

69 Okrevanje po katastrofi Storitev TikiWiki CMS ni kritična za opravljanje osnovnega dela na fakulteti, zato se povrnitev delovanja v primeru katastrofalnega izpada primarnega podatkovnega centra lahko rešuje v sekundarnem planu. Kljub temu pa morajo obstajati vsaj osnovni mehanizmi Visoka razpoložljivostza vzpostavitev prvotnega stanja ( ), da lahko v doglednem času povrnemo delovanje storitve Podatkovni center Čeprav bi težave z napajanjem strežnika TikiWiki (4.1.3) lahko delno rešili z ustrezno zanesljivo strojno opremo ( ), pa ta vseeno ne bi zadostovala ob izpadu električnega toka in ob neželenih posegih v delovanje strojne opreme (4.1.4). Ti težavi celostno odpravlja samo ustrezna lokacija, podatkovni center (2.2.1) Varnostno kopiranje Čeprav smo omenili, da virtualizacija omogoča varnostno kopiranje preko posnetkov stanj ( , ), je ta mehanizem preveč potraten in rigiden za vsakodnevno uporabo brez dodatnih orodij in naprav. Za reševanje naše storitve in povrnitev sistema ter podatkov (4.1.5) bi pravočasna povrnitev posnetka prejšnjega stanja po vsej verjetnosti bila dovolj, za širšo uporabo in povrnitev za daljša obdobja pa bi potrebovali vpeljavo namenske rešitve za varnostno kopiranje. Varnostno kopiranje pravzaprav ni de facto standardna funkcija v oblaku, je pa dodatna storitev, ki jo ponavadi izvaja ponudnik infrastrukturnih storitev v oblaku Naprave za varnostno kopiranje Za ustrezno odpravo pomanjkljivosti našega obstoječega sistema za varnostno kopiranje (4.1.5) bi potrebovali možnost odlaganja varnostnih kopij na fizično ločeni medij. 57

70 Z uporabo varnostnega kopiranja po principu»d2d2t«( ) bi z ustrezno programsko opremo ( ) ustrezno lahko ščitili in po izbrisu tudi v kratkem času povrnili delovanje storitve CMS Programska oprema za varnostno kopiranje Za učinkovito rabo namenske naprave za varnostno kopiranje ( , ) potebujemo vpeljavo namenske programske opreme, ki ustreza zahtevam za varnostno kopiranje storitev v oblaku ( ). S tem bi hkrati pridobili neodvisen sistem, ki bo omogočal hitro in zanesljivo povrnitev podatkov v zadnje stanje Programska oprema Upoštevaje trenutni trend rasti uporabe, popularnosti (67) in široke podprtosti (68) smo za predlagano platformo»cloud management«predvideli odprtokodni projekt OpenStack (2.2.4). Poleg skladnosti s tehničnimi zahtevami ( , 2.2.4) in predlagano strojno opremo (2.2.3), nam Openstack z vpeljavo vgrajenih varnostnih komponent (2.2.4, 4.2.2) in mehanizmov za zagotavljanje redundance ter visoke razpoložljivosti ( ), že v sami osnovi rešuje opisane težave z varnostjo (4.1.1) in zanesljivostjo (4.1.2) PREDLOG VPELJAVE OBLAKA Kakšen naj bi oblak v javnoizobraževalnem omrežju sploh bil? Komu je namenjen? Glede na zahteve in potrebe je najbolj logična izbira privatni oblak (Slika 28). Nivoji storitev, ki naj jih zagotavlja, so lahko: - IaaS, kot osnovni gradnik vseh dodatnih nivojev storitev ali kot orodje za proste raziskave/projekte, - (m)paas, namenjen hitremu razvoju spletnih, mobilnih rešitev za vse, ki nimajo pripravljenega svojega razvojnega okolja, 58

71 - SaaS, za hitro vpeljavo že uveljavljenih, preverjenih storitev, kot so CMS, L/CMS (»Learning/Content Management System«edu podpora skupinskem delu, konferenčni sistemi ) Slika 28: Shema privatnega oblaka v javnoizobraževalnem omrežju V osnovi bi bil oblak namenjen tako izobraževalnemu kadru, profesorjem, učiteljem, pedagogom, ter tudi učencem, dijakom, študentom. Doprinos oblaka je v množični 59

72 posvojitvi, torej pri oblaku, ki bo pokrival univerze, če ne celo vse izobraževalne ustanove. Ne vidimo prednosti v izgradnji lokalnih, izoliranih oblačkov, temveč v izgradnji enega privatnega oblaka, ki pokriva vse slovenske izobraževalne ustanove. Prav tako ne vidimo prednosti pri lokalni, izolirani uporabi javnega oblaka v režiji posameznih ustanov. Računalniški oblak mora biti privaten, namenjen izključno izobraževalnemu okolju, logično enoten, v skladu z zahtevami v poglavju 4.2. Razlogi za to tičijo v prednostih in tveganjih oblakov, opisanih v poglavjih in Lokaciji za primarni in sekundarni podatkovni center bi lahko zagotovile ali ustanove, ali ponudnik računalniškega oblaka. Operativno delo, nadzor, upravljanje oblaka prevzame ponudnik, skrbništvo nad storitvami pa bi vsaj na prvem nivoju prevzeli uporabniki. V primeru razširitve uporabnikov storitev bi upravljanje eventualno lahko prevzel ponudnik. Reševanje težav na višjem nivoju bi prevzeli zunanji specialisti. Dodeljevanje virov bi se vršilo v obliki kvote, ki jih prejme posamezna ustanova na podlagi lastnih potreb oz. zahtev. Ocene večjih potreb bi bilo treba pripraviti toliko vnaprej, da lahko ponudnik pravočasno planira razporeditev in nadgradnje infrastrukture. Prednosti predlagane rešitve so v: - ekonomičnosti: cenejše od gostovanja, lastne režije, zaradi zaračunavanja dejanske porabe virov, deljenja uporabe infrastrukture, - varnosti: za razliko od javnega oblaka so podatki v izoliranem, namenskem okolju, ponudnik je znan, lokalen in (načeloma) zaupanja vreden, - zanesljivosti: namesto lastne režije je upravljanju določena namenska ekipa s strokovnim znanjem in izkušnjami Izboru posameznih tehnologij in produktov, ki sicer ustvarjajo temelje oblaka, se na tem mestu poskušamo izogniti, ker produkti niso najbolj časovno obstojni zaradi dinamike sprememb in razvoja IT-ja. Ker pa smo prepričani, da so oprijemljiva dejstva pomembna za lažjo predstavo tako arhitekture kot obsega projekta, se jih bomo posluževali v omejenem obsegu. 60

73 Prehod v oblak Kot smo že omenili v poglavju 2.1.7, so postopki in s tem stroški prehoda v oblak večinoma odgovornost uporabnika storitev. Dasiravno ne gre za strokovno zelo zahtevna opravila, so pa lahko vsekakor kompleksna in časovno zahtevna. Pri prehodu je zato smotrno uporabiti projektni pristop; z definicijo namena, cilja, obsega dela, tveganja, potrebnih virov in nenazadnje tudi postopkov. Če predpostavimo, da selimo fizični (nevirtualiziran) strežnik, lahko v grobem definiramo dva tipična načina prehoda v oblak: - Prenos virtualiziranega fizičnega strežnika v oblak (»P2V 2 Cloud«;»Physical-To- Virtual-To-Cloud«) - Namestitev in povrnitev podatkov v oblaku (»Clean install & restore to Cloud«) Obstajajo seveda tudi spletne storitve (kot je recimo Mover 11 ), ki nudijo razmeroma preproste, a plačljive prenose, zato jih za naš namen ne bomo posebej opisovali Prenos virtualiziranega fizičnega strežnika v oblak Pomeni pretvorbo obstoječega fizičnega strežnika v virtualnega z uporabo namenskega orodja za pretvorbo, kot so npr. odprtokodni virt-p2v 12 ali VMware vcenter Converter 13, ter prenos in uvoz virtualiziranega strežnika (VM) v oblak. Prednosti: - razmeroma preprost in hiter način prehoda. Pomanjkljivosti: - virtualiziran operacijski sistem (OS) ni nujno optimiziran za delovanje v virtualnem okolju (in oblaku), verter_standalone/5_5 61

74 - prisotnost balasta (neuporabni gonilniki, dodatna, namenska programska oprema za podporo delovanja strojne opreme) v OS-u zasede dodatne kapacitete (pomnilnik, procesor, disk), kar pomeni višje stroške obratovanja, - prenos v oblak je časovno potraten zaradi prenosa tudi podatkov, ki niso kritični za storitev, - čas izpada delovanja storitve je v osnovi enak količini časa za prenos VMja. Če želimo čas izpada zmanjšati, moramo dodatno prenesti in izvesti povrnitev iz varnostnih kopij Namestitev in povrnitev podatkov v oblaku Pomeni prenos najbolj kritičnih podatkov v že postavljen, optimiziran virtualni strežnik v oblaku. Za olajšanje dela pri novi postavitvi OS in programskega sklopa (httpd, php, mysqld, ) lahko uporabimo že obstoječe predloge (če so le-te na voljo). Prednosti: - hiter prenos (prenaša se samo najbolj kritične podatke), - optimiziran, osvežen programski sklop (operacijski sistem in programje), - manjši odtis, nižji stroški obratovanja, - minimalen čas izpada delovanja storitve (po našem postopku do 5 minut). Pomanjkljivosti: - če je treba postaviti ves programski sklop iz nič, je lahko prehod časovno zahtevno opravilo, - ob prehodu na višje/novejše različice programja lahko pride do težav s skladnostjo, - uporaba že pripravljenih predlog lahko pomeni varnostno tveganje. Iz lastnih izkušenj raje izberemo svežo namestitev in povrnitev v oblaku, ker je optimalno delovanje v oblaku dolgoročno veliko pomembnejše kot pa čas, potreben za enkraten prenos Načrt prehoda Načrt prehoda naj vsebuje vsaj: 62

75 - oceno potrebnih virov, stroškov, časa, - oceno tveganj: pripravo varnostnih kopij in scenarijev v skladu z zahtevami delovanja storitve, - časovne termine za izpad delovanja, usklajene z uporabniki in/ali moderatorji vsebin, - tehnične postopke za prehod, navodila za uporabo in/ali namestitve, - obstoječo tehnično dokumentacijo Predlog tehničnega postopka za prehod z namestitvijo in povrnitvijo podatkov v oblaku Predlog tehničnega postopka je podrobneje opisan v prilogi C. 63

76 4.4. AKTUALNO STANJE Ker javnoizobraževalno okolje nudi plodna tla za vpeljavo novih tehnologij, se je na področju računalniških oblakov že pojavilo nekaj rešitev. Tako je že pred časom, leta 2009, fakulteta za elektrotehniko in računalništvo v Mariboru (FERI) v sodelovanju z IBM Slovenija postavila pilotski oblak v okviru projekta»center za računalništvo v oblaku«, z namenom»spoznavanja najnovejših tehnologij«(69) (70), nekaj let kasneje, leta 2011, odkar se v izobraževalne programe bolj aktivno vpeljuje IKT (informacijske in komunikacijske tehnologije), pa se je k uvedbi oblaka zavezal tudi Arnes (71). Uporabniških zahtev, kot so večja dinamika pri izbiri operacijskih sistemov, svoboda upravljanja strežnikov, dotedanja storitev»gvs«(»gostovanje virtualnih strežnikov«) namreč ni učinkovito pokrivala 14. Po podrobni analizi zahtev in potreb se je leta 2012 začelo testiranje programske opreme. Testno obliko oblaka je Arnes ponudil v uporabo marca 2013, z decembrom 2013 pa je storitev prešla v polno produkcijo.»ablak«je zgrajen na programski opremi Ovirt (72), sloni na operacijskih sistemih CentOS (73) s KVM-hipervizorji. Strojno ogrodje sestavljajo standardni»rack«strežniki z Intel CPE, s po 4 GiB pomnilnika na jedro, diskovno polje SAN s 30 do 50 TiB kapacitete in komunikacijsko opremo. Varnostni mehanizmi so sicer vpeljani za zaščito fizičnih gostiteljev in nadzornega okolja, medtem ko je zaščita uporabniških strežnikov prepuščena uporabnikom. Oblak v okviru funkcionalnosti same programske opreme sicer omogoča visoko razpoložljivost, izenačevanje obremenitve, prav tako so zagotovljeni ustrezna fizična varnost, dodatno napajanje in hlajenje v podatkovnem centru, ni pa še vpeljanih mehanizmov za okrevanje po katastrofi zaradi pomanjkanja virov in realnih potreb. Število uporabnikov storitve Ablak počasi, a zanesljivo narašča. Trenutno storitev Ablak kot IaaS uporablja okoli 40 organizacij, predvsem za gostovanje spletnih strani, arhivov, 14 Kranjc, Jure. O storitvi Arnes Ablak. [interv.] Marko Vran. Pogovor s sistemskim administratorjem Ablaka

77 varnostnega kopiranja ter pretočnih strežnikov 15. Vir najpogostejših težav je pomanjkljivo znanje pri upravljanju strežnikov in uporabi grafičnega vmesnika. Izpada delovanja storitve do sedaj še ni bilo. Poleg storitve IaaS Arnes v svoji ponudbi gostovanja nudi SaaS z uporabo prednastavljenih strežnikov CMS in LCMS, baziranih na programski opremi Joomla CMS (74) (Slika 29). Slika 29: Razlike med posameznimi paketi glede vzdrževanja in podpore (74) 15 Ker imajo pri storitvi IaaS uporabniki popoln nadzor nad svojimi strežniki, Arnes natančnega pregleda nad funkcionalnostjo vrste gostujočih storitev nima. 65