SVEUILITE U SPLITU FAKULTET ELEKTROTEHNIKE, STROJARSTVA I BRODOGRADNJE

DIPLOMSKI RAD

UPRAVLJANJE ZNANJEM U SAMOPRILAGODLJIVIM CLOUD SUSTAVIMA

Mario Volf

Split, rujan 2010.

SVEUILITE U SPLITU FAKULTET ELEKTROTEHNIKE, STROJARSTVA I BRODOGRADNJE Raunarstvo

Diplomski studij: Smjer/Usmjerenje: Oznaka programa:

250

Akademska godina: 2009/10 Ime i prezime: Broj indeksa: MARIO VOLF 801-2008

ZADATAK DIPLOMSKOG RADA

Naslov: UPRAVLJANJE ZNANJEM U SAMOPRILAGODLJIVIM CLOUD SUSTAVIMA Zadatak: U radnji je potrebno opisati trendove u raunarstvu koji omoguuju korisniku smanjenje administriranja infrastrukture. Analizirati prednosti cloud raunarstva. Opisati utjecaje interakcije korisnika sa sustavom i SLA ugovore. Prikazati metode za upravljanje znanjem za koje se smatra da su pogodne za implementaciju u cloudu i tehnologije za njihovu implementaciju na cloud infrastrukturama. Opisati tehnologije i istraivanja vezane za implementaciju metode uobiajene logike. Prikazati koncept i implementaciju za realizaciju baze znanja koritenjem metode rasuivanja temeljenog na sluajevima (case based reasoning).

Prijava rada: Rok za predaju rada:

25.03.2010. 15.10.2010.

Rad predan:

Predsjednik Odbora za diplomski rad:

Mentor:
Dr. sc. Stipo elar, doc.

Komentor:

Dr. sc. Sven Gotovac, red. prof.

Dr. sc. Ivona Brandic, izv. prof.

Vienna University of Technology, Austria

I would like to thank the dean of the Faculty of electrical engineering, mechanical engineering and naval architecture prof.dr.sc. Tomislav Kili and colleagues Ivona Brandi, Michael Maurer and Vincent C. Emeakaroha from Vienna university of technology for all their cooperation, support and help in the process of making this master thesis

SADRAJ 1 2 3 SAETAK I KLJUNE RIJEI ........................................................................................ 3 UVOD ................................................................................................................................. 4 CLOUD RAUNARSTVO I SERVICE LEVEL AGREEMENT (SLA) ......................... 6 3.1 Izgradnja na postojeim trendovima............................................................................ 6 3.1.1 Virtualne maine kao standardni objekti za distribuiranje ................................... 7 3.1.2 On-demand, self-service, pay-by-use model ........................................................ 7 3.1.3 Dostavljanje usluga preko mree ....................................................................... 11 3.1.4 Uloga softvera otvorenog koda .......................................................................... 12 3.2 Infrastrukturni modeli cloud raunarstva .................................................................. 12 3.2.1 Javni, privatni i hibridni cloud ........................................................................... 12 3.2.2 Arhitekturni slojevi cloud raunarstva ............................................................... 16 3.2.3 Suelja za programiranje cloud aplikacije ......................................................... 18 3.3 Dobrobiti cloud raunarstva ...................................................................................... 18 3.3.1 Smanjenje vremena izvravanja i odziva ........................................................... 19 3.3.2 Minimiziranje infrastrukturnog rizika ................................................................ 19 3.3.3 Manji poetni trokovi ....................................................................................... 19 3.3.4 Poveani tempo inovacija................................................................................... 20 3.4 Service Level Agreement (SLA) ............................................................................... 20 3.4.1 Uobiajene metrike ............................................................................................ 22 3.4.2 SLA u cloud raunarstvu .................................................................................... 22 ZNANJE I UPRAVLJANJE ZNANJEM ......................................................................... 24 4.1 Prikazivanje znanja .................................................................................................... 25 4.1.1 Logiko prikazivanje znanja .............................................................................. 25 4.2 Upravljanje znanjem .................................................................................................. 27 4.2.1 Povijest ............................................................................................................... 28 4.2.2 Istraivanja ......................................................................................................... 29 4.2.3 Znaajke ............................................................................................................. 29 4.2.4 Strategije............................................................................................................. 30 4.2.5 Tehnologije......................................................................................................... 31 4.2.6 Upravljanje znanjem i kolaboracija.................................................................... 32 4.2.7 Metode upravljanja znanjem .............................................................................. 32 UPRAVLJANJE ZNANJEM U SAMOPRILAGODLJIVIM CLOUDIMA ................... 33 5.1 Pregled FoSSI infrastrukture ..................................................................................... 34 5.1.1 Primjer koritenja ............................................................................................... 35 5.2 Metode upravljanja znanjem za upravljanje SLA ugovorima ................................... 38 5.2.1 Rule based system (baze pravila) ....................................................................... 38 5.2.2 Default logics (uobiajena logika) ..................................................................... 40 5.2.3 Situation calculus ............................................................................................... 46 5.2.4 Case-based reasoning (rasuivanje temeljeno na sluajevima) ......................... 48 ZAKLJUAK ................................................................................................................... 58 PRILOZI ........................................................................................................................... 60 7.1 Kazalo slika i tablica.................................................................................................. 60 7.1.1 Kazalo slika ........................................................................................................ 60 7.1.2 Kazalo tablica ..................................................................................................... 60 7.2 Popis oznaka i kratica ................................................................................................ 60 1

6 7

LITERATURA ................................................................................................................. 62

SAETAK I KLJUNE RIJEI

Saetak Najnoviji trendovi u raunarstvu ukljuuju ostvarivanje autonomnih udaljenih sustava kod kojih se korisnik ne mora brinuti o infrastrukturnim i administracijskim problemima i rizicima. Najnoviji sustav u nizu je cloud (oblak) raunarstvo koje je nastalo na temeljima Grid-a, ali ukljuuje nove i kljune tehnologije poput virtualizacije. Najvee prepreke ka ostvarenju autonomnog cloud sustava su vezane za samostalno upravljanje SLA ugovorima koji se koriste za osiguravanje kvalitete usluge zahtijevane od strane korisnika. Potrebne su samoupravljajue cloud infrastrukture kako bi se postila potrebna razina flaksibilnosti. Cilja se na autonomno upravljanje SLA ugovorima koje mora sprijeiti sva eventualna krenja ugovora. U tu svrhu je prikazan teorijski koncept upravljanja znanjem. Nadalje su prikazane i opisane etiri metode upravljanja znanjem za koje se smatra da su primjenjive i efikasne kod upravljanja SLA ugovorima i resursima cloud sustava. Metode su baze pravila (rule based system), uobiajena logika (default logics), situation calculus i rasuivanje temeljeno na sluajevima (case based reasoning). Detaljnije su opisana istraivanja tehnologija i mogunosti za implementaciju metode uobiajene logike, te je prikazana implementacija i evaluacija metode rasuivanja temeljenog na sluajevima. Na kraju rada su doneseni zakljuci vezani uz gore navedene metode i oekivanja u mogunostima daljnjeg razvoja. Kljune rijei Cloud, Service Level Agreement (SLA), upravljanje znanjem, autonomno raunarstvo, baze pravila (rule based system), uobiajena logika (default logics), situation calculus, rasuivanje temeljeno na sluajevima (case based reasoning)

UVOD

Sa znatnim napretkom u informacijskoj tehnologiji tokom zadnjih godina sve se vie razvija vizija da e raunarstvo jednog dana postati peta komunalija (voda, struja, plin, telefon). Ovakvo raunarstvo bi, kao i preostale etiri komunalije, nudilo osnovni nivo usluge koji se smatra neophodnim za svakodnevne potrebe ope zajednice. U svrhu ostvarivanja ove vizije je razvijen vei broj raunarskih paradigmi, meu kojima je posljednja poznata kao cloud raunarstvo koje predstavlja konvergenciju i evoluciju nekoliko koncepta (virtualizacija, distribuirani dizajn aplikacija, Grid i poduzetno IT upravljanje). Cloud je novonastala infrastruktura koja predstavlja nadogradnju najnovijih postignua u raznolikim podrujima istraivanja poput Grid raunarstva, pruanja softvera kao usluge (SaaS), upravljanja poslovnim procesima (BPM) i virtualizacije. Da bi se ostvario potreban nivo fleksibilnosti cloud sustava resursi se softveru koji eka na izvravanje moraju dodjeljivati ne samo dinamiki, ve i na autonoman nain. Resursi se dodjeljuju prema predefiniranim Service Level Agreement-ima (SLA) koji se sastoje od SLA parametara poput vremena odziva, dostupnosti ili prostora za spremanje podataka. Service Level Objective (SLO) za svaki SLA parametar definira cilj koji je potrebno postii (npr. dostupnost > 98%). Meutim, uslijed raznih kvarova na sustavu i promjena u uvjetima optereenja utvreni SLA ugovori mogu biti prekreni. Da bi se izbjeglo krenje ugovora potrebne su fleksibilne i prilagodljive strategije definiranja SLA ugovora. U svrhu ostvarivanja ovih strategija koriste se mogunosti autonomnog raunarstva, upravljanja znanjem i slinih tehnologija. Tema ovog rada su samostalno upravljane cloud infrastrukture koje omoguavaju odreen nivo fleksibilnosti i pridravanje korisnikim zahtjevima definiranim pomou SLA ugovora. Ovakve infrastrukture bi trebale automatski reagirati na promjenu komponenti, optereenja i okolinskih uvjeta. Ovako se minimizira potreba za interakcijama korisnika sa sustavom i smanjuje mogunost krenja uspostavljenih ugovora. Da bi se ovakva infrastruktura ostvarila, istrauju se mogunosti trenutno poznatih metoda za upravljanje znanjem. U ovom radu je dan pregled cloud raunarstva koji e sadravati najee koritene definicije, podjele i mogunosti. Nakon toga slijedi uvod u neke od metoda za upravljanje znanjem. Glavni dio rada se odnosi na mogunosti primjene pojedinih metoda na cloudu kako bi se ostvarilo autonomno praenje i upravljanje promjenama u svrhu sprjeavanja krenja SLA ugovora, te eventualne promjene postojeih ugovora u dozvoljenim sluajevima. Bit e dan pregled tehnologija koje su dostupne i pogodne za implementaciju metoda upravljanja znanjem na cloud infrastrukturama. 4

Glavni doprinosi rada su: (i) osvrt i rasprava o autonomnom rjeavanju problema SLA ugovora u cloud raunarstvu koritenjem upravljanja znanjem; (ii) prikaz i opis metoda za upravljanje znanjem za koje se smatra da su pogodne za implementaciju u cloudu; (iii) pregled tehnologija dostupnih i pogodnih za implementaciju metoda upravljanja znanjem na cloud infrastrukturama; (iv) opis tehnologija i istraivanja vezanih za implementaciju metode uobiajene logike; (v) koncept i implementacija za realizaciju baze znanja koritenjem metode rasuivanja temeljenog na sluajevima [8]. Rad je organiziran na slijedei nain: poglavlje 3 sadri openiti prikaz i uvod u cloud raunarstvo te SLA ugovore. U poglavlju 4 je dan teorijski osvrt na znanje i upravljanje znanjem. Poglavlje 5 obuhvaa opis metoda za upravljanje znanjem koje su odabrane za implementaciju u samoprilagodljivim cloudima. Ovo poglavlje, takoer, sadri prikaz istraivanja vezanog za metodu uobiajene logike i implementaciju metode rasuivanja temeljenog na sluajevima. Posljednje, esto poglavlje sadri zakljuke donesene tokom istraivanja i pisanja rada.

CLOUD RAUNARSTVO I SERVICE LEVEL AGREEMENT (SLA)

Cloud raunarstvo jo uvijek nema standardnu definiciju, ali bi se moglo rei da cloud ili klasteri distribuiranih raunala nude raunalne resurse i usluge na zahtjev preko mrene infrastrukture, najee Interneta, sa skalabilnosti i pouzdanosti podatkovnog centra. Cloud je novi trend u raunarstvu gdje su dostupni resursi izloeni kao usluga. Preciznija definicija bi bila: cloud je vrsta paralelnog i distribuiranog sustava koji se sastoji od meusobno povezanih i virtualiziranih raunala koja se dinamiki pruaju i predstavljaju kao jedan ili vie objedinjenih raunalnih resursa zasnovanih na SLA ugovorima koji se utvruju dogovorima izmeu pruatelja i korisnika usluga. [4] Povrnim promatranjem se ini da je cloud kombinacija klastera i Grid-a. Meutim, ovo bi bila pogrena pretpostavka. cloud predstavlja novu generaciju podatkovnih centara sa virtualiziranim vorovima koji se dinamiki pruaju kao personalizirani skup resursa u svrhu ispunjavanja specifinih SLA ugovora. Generalno se moe rei da je cloud nova generacija mrenog raunarstva. Ukratko reeno, ono to razlikuje cloud od prijanjih modela je koritenje informacijske tehnologije kao usluge preko mree. Usluge koje se pruaju su striktno definirane, imaju API te su dostupne preko mree. Ovakva definicija obuhvaa koritenje procesorskih i resursa za pohranu podataka kao usluge.

3.1 Izgradnja na postojeim trendovima

Cloud raunarstvo nastavlja razvoj uspostavljenih trendova koji smanjuju trokove dostavljanja, dok poveavaju brzinu i agilnost dostavljanja usluga. Uvelike smanjuje vrijeme potrebno od osmiljavanja aplikacijske arhitekture do same instalacije. Cloud obuhvaa virtualizaciju, dostavljanje usluge na zahtjev, dostavljanje usluga putem Interneta i softver otvorenog koda. Iz jedne perspektive cloud ne nudi nita novo jer koristi pristupe, koncepte i najbolje prakse koje su ve odavno uspostavljene. Iz druge perspektive nudi mnogo novog jer mijenja nain na koji se osmiljavaju, razvijaju, dostavljaju, skaliraju, auriraju, odravaju i plaaju aplikacije te infrastruktura na kojoj se izvravaju.

3.1.1 Virtualne maine kao standardni objekti za distribuiranje Tokom nekoliko proteklih godina virtualne maine su postale standardni objekti za distribuiranje. Virtualizacija poveava fleksibilnost jer apstrahira hardver do toke u kojoj se aplikacije mogu distribuirati bez vezivanja za specifini fiziki server. Virtualizacija omoguava dinamike podatkovne centre gdje serveri pruaju udruene resurse koji se iskoritavaju po potrebi, te gdje se veza izmeu aplikacija, prostora za pohranu i mrenih resursa dinamiki mijenja u svrhu ostvarivanja potrebnog radnog optereenja i poslovnih potreba. Budui da je distribuiranje aplikacija odvojeno od distribuiranja servera, aplikacije se mogu rapidno distribuirati i skalirati, bez potreba za prethodnim pribavljanjem fizikih servera. Virtualne maine su postale prevladavajui oblik apstrakcije (i jedinice za distribuiranje) jer su najvie odgovarale i pruateljima i razvijateljima usluga. Koritenje virtualnih maina kao objekata za distribuiranje je dostatno u 80% sluajeva, te pomae u zadovoljavanju potreba za rapidnom implementacijom i skaliranjem aplikacija. Virtualni ureaji su virtualne maine koje sadre softver koji je dijelom ili u potpunosti konfiguriran za izvravanje specifinog zadatka. Oni nadalje poveavaju sposobnost sustava za rapidnim stvaranjem i distribuiranjem aplikacija. Kombinacija virtualnih maina i ureaja kao standardnih objekata za distribuiranje je jedno od kljunih svojstava cloud raunarstva. Cloud-ovi za procesiranje podataka se najee upotpunjuju sa cloudima za pohranu podataka koji pruaju virtualizirani prostor za pohranu podataka pomou API-ja koji olakava pohranu slika virtualnih maina, izvorinih datoteka, podataka sa aplikacijskim stanjima i openitih poslovnih podataka. 3.1.2 On-demand, self-service, pay-by-use model Cloud takoer proiruje postojee trendove koritenjem on-demand, self-service i pay-by-use modela. Sa poduzetne perspektive on-demand priroda clouda pomae podravanju aspekata performansi i kapaciteta ciljeva na razini usluge. Samoposluna priroda clouda omoguava organizacijama stvaranje elastinih okruja koja se ire i smanjuju ovisno o radnom optereenju. Naposljetku, pay-by-use priroda clouda moe poprimiti formu iznajmljivanja opreme koja garantira minimalnu razinu usluge od strane pruatelja usluga.

Virtualizacija je kljuno svojstvo ovog modela. IT organizacije su odavno zakljuile da virtualizacija omoguava brzo i jednostavno stvaranje kopija postojeih okruja (koja ponekad ukljuuju viestruke virtualne maine) u svrhu podrke testiranju, razvijanju i izvravanju. Troak ovakvih okruja je minimalan jer ona mogu koegzistirati na istim serverima sa produkcijskim okrujima. Na isti nain, nove aplikacije mogu biti razvijane i distribuirane na novim virtualnim mainama na postojeim serverima, otvorene za koritenje na Internetu i po potrebama skalirane. Ovaj model "laganog" distribuiranja je ve doveo do "Darwinistikog" pristupa poslovnog razvoja u kojem se objavljuju beta verzije softvera, te trite odreuje koje se aplikacije trebaju skalirati i dalje razvijati. Cloud raunarstvo nadograuje ovaj trend pomou automatizacije. Umjesto pregovaranja sa IT organizacijom oko resursa na koje distribuirati aplikacije, cloud za procesiranje podataka predstavlja samoposlunu komponentu u kojoj kreditna kartica moe kupiti cikluse za obradu podataka. Web suelje ili API se koristi za stvaranje virtualnih maina i uspostavljanje mrenih odnosa meu njima. Umjesto uspostavljanja dugoronog ugovora za usluge sa IT organizacijom ili pruateljem usluga cloudi rade po modelu plati koliko koristi u kojem aplikacija moe biti aktivna za izvravanje zadatka nekoliko minuta, sati ili dugorono. Cloud-ovi za procesiranje podataka su osmiljeni sa pretpostavkom da su aplikacije privremene, a naplata je zasnovana na potronji resursa:

koritenju CPU sati koliini prenesenih podataka koliini pohranjenih podataka...

Mogunost koritenja i plaanja samo iskoritenih resursa pomie rizik odluivanja o kupovini potrebne infrastrukture sa organizacije koja razvija aplikaciju na pruatelja cloud usluga. Takoer pomie odgovornost za arhitekturne odluke sa arhitekata aplikacija na razvijatelje.

3.1.2.1 Programabilna infrastruktura Pomak arhitekturne odgovornosti ima bitne posljedice. Prije bi arhitekti aplikacija odreivali kako razliite komponente aplikacije raspodijeliti na niz servera, kako ih meusobno povezati, osigurati i skalirati. Sada razvijatelj aplikacije moe koristiti API pruatelja cloud usluga kako bi stvorio ne samo poetnu kompoziciju aplikacije na virtualnim mainama, ve i odredio skaliranje i evoluiranje aplikacije u svrhu zadovoljavanja promjena u radnom optereenju. Mogunost dinamikog programiranja aplikacijske arhitekture daje razvijateljima aplikacija ogromnu mo kojoj je proporcionalna koliina odgovornosti. Da bi se cloud iskoristio najefikasnije razvijatelj aplikacije mora biti i arhitekt koji mora biti u mogunosti stvoriti aplikaciju koja se sama kontrolira i po potrebi proiruje. Razvijatelj/arhitekt mora razumjeti kada je odgovarajue kreiranje nove niti, a kada nove virtualne maine zajedno sa arhitekturnim uzorcima za njihovo meusobno povezivanje. 3.1.2.2 Modularne aplikacije Dodatna posljedica self-service, pay-by-use modela su aplikacije koje se osim programiranjem razvijaju sastavljanjem i konfiguracijom postojeih servisa i softvera otvorenog koda. Aplikacije i arhitekture koje je mogue rastaviti na module kako bi se ostvarila najvea mogua iskoristivost standardnih komponenti e najbolje moi iskoristiti snagu clouda. Stoga bi se aplikacije trebale razvijati modularno. Ovo zahtjeva jednostavne, iste funkcije i dobro dokumentirane API-je. Razvijanje velikih, monolitskih aplikacija je stvar povijesti, jer se sa vremenom biblioteke postojeih alata koji se mogu direktno koristiti brzo poveavaju.

3.1.2.3 Primjer distribuiranja Web aplikacije Kao primjer kako kombinacija virtualizacije i samoposluivanja olakava distribuiranje aplikacije u obzir e se uzeti distribuiranje dvoslojne Web aplikacije na cloud (Slika 3-1): 1. Razvijatelj moe izabrati Web server i bazu podataka iz biblioteke unaprijed konfiguriranih slika virtualnih maina. 2. Razvijatelj konfigurira svaku komponentu kako bi stvorio vlastite, prilagoene slike. Softver za balansiranje optereenja bi se podesio, Web server napunio sa statikim sadrajem stavljanjem podataka na cloud za pohranu podataka i baza podataka bi se napunila dinamikim sadrajem za stranicu. 3. Razvijatelj vlastiti kod razlae u slojeve za novu arhitekturu, te osigurava da komponente zadovoljavaju specifine aplikacijske zahtjeve. 4. Razvijatelj bira uzorak koji uzima slike za svaki sloj, te ih distribuira vodei rauna o mrei, sigurnosti i skalabilnosti.

Slika 3-1 Primjer distribuiranja aplikacije na dvoslojni Web server arhitekturni uzorak

10

5. Sigurna, visoko dostupna Web aplikacija je distribuirana i aktivna. U sluaju potrebe za auriranjem aplikacije, auriraju se virtualne maine, kopiraju kroz lanac razvijanje-testiranje-koritenje, te se cijela infrastruktura ponovno distribuira. Cloud pretpostavlja da je sve privremeno, te je ponovno distribuiranje cijele aplikacije jednako jednostavno kao i runo ispravljanje grupe individualnih virtualnih maina. U ovom primjeru apstraktna priroda slika virtualnih maina podrava pristup razvijanju zasnovan na "sastavljanju" aplikacija. Podjelom problema mogue je koristiti standardni niz komponenti kako bi se aplikacija brzo distribuirala. Sa ovakvim modelom zahtjevi u tvrtkama se mogu brzo rijeiti bez potrebe za kupovinom, instalacijom, kabliranjem i konfiguracijom servera, skladita podataka i mrene infrastrukture. 3.1.3 Dostavljanje usluga preko mree Cloud raunarstvo proiruje postojei trend omoguavanja dostupnosti aplikacija preko mree. Gotovo je svaka ozbiljna tvrtka u svijetu prepoznala vanost suelja baziranog na Web-u za svoje aplikacije. Ovakva suelja mogu biti javno dostupna svim korisnicima ili predstavljati interne aplikacije koje su dostupne autoriziranim zaposlenicima, partnerima, dobavljaima i konzultantima. Najvea vrlina dostavljanja usluga baziranom na Internetu je, naravno, dostupnost aplikacija u bilo koje vrijeme i sa bilo kojeg mjesta. Dok su velike tvrtke svjesne mogunosti sigurne komunikacije koritenjem SSL (Secure Socket Layer) enkripcije zajedno sa jakom autentikacijom, pokretako povjerenje u cloud okruju zahtjeva paljivo razmatranje razlika izmeu poslovnog raunarstva i cloud raunarstva. Kada je propisno arhitekturno osmiljeno, dostavljanje usluga preko Interneta nudi fleksibilnost i sigurnost dostatnu tvrtkama svih veliina.

11

3.1.4 Uloga softvera otvorenog koda Softver otvorenog koda igra vanu ulogu u cloud raunarstvu omoguavajui kreiranje osnovnih softverskih elemenata (slike virtualnih maina) iz lako dostupnih komponenti. Jedna od najvanijih znaajki softvera otvorenog koda je striktno koritenje slubenih, vrsto ustanovljenih svjetskih standarda. Ovo ima pojaavajui uinak: Razvijatelji aplikacija npr. mogu kreirati servise baze podataka uslojavanjem nekog softvera otvorenog koda (MySQL, PostgreSQL,...) na instancu Linux ili Unix (FreeBSD, OpenSolaris,...) operacijskog sustava. Ovakvi servisi omoguavaju kreiranje, distribuiranje i dinamiko skaliranje cloud aplikacija na zahtjev. Kao primjer se moe uzeti Animoto aplikacija (alat za kreiranje videa iz niza slika i glazbenih datoteka) raena uz pomo softvera otvorenog koda koja je u roku od samo nekoliko dana skalirana na 3500 instanci. Jednostavnost sa kojom se komponente otvorenog koda mogu koristiti za sastavljanje veih aplikacija generira jo vie komponenti otvorenog koda. Zauzvrat, ovo ini ulogu softvera otvorenog koda jo vanijom. Na primjer potreba za MapReduce algoritmom koji se moe izvravati u cloud okruju je bio jedan od faktora koji je stimulirao njegov razvoj. Sada kada je alat kreiran koristi se kako bi jo vie podigao nivo na kojem razvijatelji programiraju cloud aplikacije.

3.2 Infrastrukturni modeli cloud raunarstva

Raunalni arhitekti moraju uzeti u obzir brojna razmatranja pri premjetanju sa standardnog modela distribuiranja aplikacija na model zasnovan na cloudu. Postoje javni i privatni cloudi koji nude dodatne beneficije, postoje tri osnovna modela usluga za razmatranje, te se mora donijeti odluka o koritenju vlasnikih API-ja ili API-ja otvorenog koda. 3.2.1 Javni, privatni i hibridni cloud IT organizacije mogu distribuirati aplikacije na javne, privatne ili hibridne cloudove, od kojih svaki ima svoje vrline i mane. Pojmovi javni, privatni i hibridni ne diktiraju lokaciju. Iako su javni cloudi najee "vani" na Internetu, a privatni smjeteni na odreenoj, poznatoj lokaciji, to ne mora nuno biti tako.

12

Tvrtke moraju uzeti u obzir brojna razmatranja povezana sa odabranim cloud modelom za koritenje, te mogu, takoer, koristiti vie od jednog modela kako bi rijeili odreene probleme. Aplikacija koja je privremeno potrebna je najbolja za distribuiranje na javni cloud jer pomae pri izbjegavanju potrebe za kupovinom dodatne opreme kako bi se rijeila privremena potreba. Sa druge strane, stalna aplikacija ili aplikacija koja ima specifine zahtjeve na kvalitetu usluge ili lokaciju podataka je najbolji kandidat za privatni ili hibridni cloud. 3.2.1.1 Javni cloud Javni cloud se odrava od strane neovisnih pruatelja usluga, te se najee aplikacije od razliitih korisnika meusobno mijeaju na cloud serverima, sustavima za pohranu podataka i mrei (Slika 3-2).

Slika 3-2 Javni cloud sa udaljenih lokacija prua usluge viestrukim korisnicima Javni cloud se najee nalazi na lokaciji udaljenoj od prostorija korisnika. Nudi nain reduciranja korisnikih trokova i rizika fleksibilnim i po mogunosti privremenim proirenjem korisnike infrastrukture. Kada je javni cloud implementiran sa performansama, sigurnosti i lokalitetom podataka u vidu postojanje drugih aplikacija bi trebalo biti transparentno i arhitektima clouda i krajnjim korisnicima. Jedna od dobrobiti javnog clouda je injenica da mogu biti mnogo vei od 13

mogueg privatnog clouda tvrtke. Nude mogunost skalabilnosti na zahtjev i pomiu rizike vezane uz infrastrukturu sa tvrtke na pruatelja cloud usluga. Dijelovi javnog clouda se mogu odijeliti za iskljuivo koritenje jednog korisnika stvarajui virtualni privatni centar podataka. Umjesto da je virtualni privatni centar podataka ogranien na distribuiranje slika virtualnih maina na javni cloud, on korisnicima prua vei uvid u svoju infrastrukturu. U ovakvom sluaju korisnici mogu manipulirati ne samo slikama virtualnih maina, ve i serverima, sustavima za pohranu podataka, mrenim ureajima i mrenom topologijom. Stvaranje virtualnog privatnog centra podataka sa svim komponentama smjetenim na istoj lokaciji pomae pri smanjivanju problema vezanih uz lokalitet podataka, jer je mrena propusnost velika i najee besplatna pri spajanju elemenata unutar iste lokacije. 3.2.1.2 Privatni cloud Privatni cloud se implementira za iskljuivo koritenje jednog korisnika nudei najvii stupanj kontrole nad podacima, sigurnosti i kvaliteti usluge (Slika 3-3). Tvrtka posjeduje infrastrukturu i ima kontrolu nad nainom izvoenja aplikacija na njoj. Privatni cloud se moe implementirati unutar podatkovnog centra tvrtke ili na udaljenoj lokaciji.

Slika 3-3 Primjer privatnog clouda koji se nalazi u podatkovnom centru tvrtke

Privatni cloud se moe implementirati i odravati od strane vlastitog IT odjela unutar tvrtke ili od strane pruatelja cloud usluga. U drugom modelu neka cloud tvrtka moe instalirati, 14

konfigurirati i upravljati infrastrukturom kako bi se uspostavio privatni cloud unutar podatkovnog centra tvrtke. Ovakav model daje tvrtkama veliku koliinu kontrole nad koritenjem cloud resursa, dok se trea strana brine o strunosti potrebnoj za uspostavljanje i upravljanje okrujem. 3.2.1.3 Hibridni cloud Hibridni cloud kombinira modele javnog i privatnog clouda (Slika 3-4). Hibridni model pomae pri omoguavanju sustava koji je dostupan na zahtjev i pruen od tree strane. Mogunost obogaivanja privatnog clouda sa resursima javnog se moe koristiti kako bi se odravale razine usluga u svrhu dostizanja brzih fluktuacija u radnom optereenju. Ovakav model se najee via u koritenju clouda za pohranu podataka sa Web 2.0 aplikacijama. Hibridni cloud se takoer moe koristiti za manipuliranje planiranih iljaka u radnom optereenju. U ovom modelu se javni cloud moe koristiti za izvravanje periodikih zadataka koji se mogu na njega jednostavno distribuirati.

Slika 3-4 Hibridni cloud kombinira modele javnog i privatnog clouda

Hibridni cloud uvodi kompleksnost odreivanja kako distribuirati aplikacije preko javnog i privatnog clouda. Meu spornim pitanjima na koje treba odgovoriti je odnos izmeu resursa 15

za obradu i pohranu podataka. U sluaju kada su podaci mali hibridni cloud moe biti puno uspjeniji nego u sluaju kada se velike koliine podataka moraju slati na javni cloud za malu koliinu obrade. 3.2.2 Arhitekturni slojevi cloud raunarstva Moe se rei da cloud raunarstvo obuhvaa pruanje usluga koje obuhvaaju bilo koji od tradicionalnih slojeva od hardvera do aplikacija (Slika 3-5). U praksi pruatelji cloud usluga tee ka ponudi usluga koje se mogu grupirati u tri skupine: 1. Softver kao usluga (SaaS) 2. Platforma kao usluga (PaaS) 3. Infrastruktura kao usluga (IaaS) Ove skupine grupiraju razliite slojeve prikazane na slici 3-5 sa odreenim preklapanjem.

Slika 3-5 Cloud raunarstvo predstavlja koritenje IT infrastrukture kao usluge (od hardvera do API-ja)

16

3.2.2.1 Softver kao usluga (SaaS) Softver kao usluga se sastoji od potpune aplikacije koje se prua kao usluga na zahtjev. Jedna instanca softvera se izvrava na cloudu i prua uslugu viestrukim krajnjim korisnicima. Najpoznatiji primjer softvera kao usluge je salesforce.com, iako su brojni drugi primjeri prisutni na tritu, poput Google Apps koji nudi osnovne poslovne usluge. Iako salesforce.com prethodi definiciji cloud raunarstva nekoliko godina sada djeluje iskoritavanjem svog pratioca force.com koji se moe definirati platformom kao uslugom. 3.2.2.2 Platforma kao usluga (PaaS) Platforma kao usluga obuhvaa sloj softvera i nudi ga kao uslugu koja se moe koristiti za izradu usluga vieg sloja. Postoje barem dvije perspektive na PaaS ovisno o perspektivi proizvoaa ili korisnika usluga: Razvijatelj PaaS-a moe razviti platformu integriranjem OS-a, meusoftvera, aplikacijskog softvera te ak i razvojnog okruja koje se onda prua korisniku kao usluga. Korisnik PaaS-a moe vidjeti obuhvaene usluge koje su prikazane preko API-ja. Korisnik pristupa platformi preko API-ja, a platforma izvrava potrebne akcije kako bi se odravala i skalirala u svrhu pruanja odreene razine usluge. Virtualni ureaji se mogu klasificirati kao instance PaaS-a. PaaS moe nuditi usluge za svaku fazu razvoja i testiranja softvera ili moe biti specijaliziran oko odreenog podruja poput upravljanja sadrajem. Komercijalni primjeri PaaS-a su Google Apps Engine koji prua aplikacije na Google-ovoj infrastrukturi. Ovakve PaaS usluge nude mone temelje za distribuiranje aplikacija, meutim mogu biti ograniene mogunostima koje nudi pruatelj cloud usluga. 3.2.2.3 Infrastruktura kao usluga (IaaS) Infrastruktura kao usluga prua osnovne mogunosti pohrane i obrade podataka u obliku standardiziranih usluga preko mree. Serveri, sustavi pohrane podataka, prospojnici, usmjernici i ostali sustavi se grupiraju i pruaju u svrhu rukovanja radnim optereenjima koja se kreu od aplikacijskih komponenti do aplikacija visokih performansi. Komercijalni 17

primjeri IaaS-a su Joyent iji je glavni proizvod linija virtualiziranih servera koji pruaju visoko dostupnu infrastrukturu na zahtjev. 3.2.3 Suelja za programiranje cloud aplikacije Jedna od kljunih karakteristika koja razlikuje cloud od standardnog poslovnog raunarstva je injenica da je sama infrastruktura programabilna. Umjesto fizikog razmjetaja servera, sustava za pohranu podataka i mrenih resursa razvijatelji specificiraju kako su odgovarajue virtualne komponente konfigurirane i meusobno povezane. U ovom procesu se i odreuje kako se slike virtualnih maina i aplikacije pohranjuju i dohvaaju sa clouda za pohranu podataka. Specificira se kako i kada se komponente distribuiraju pomou API-ja kojeg nudi pruatelj cloud usluga. Analogija je nain rada FTP-a: FTP serveri odravaju kontroliranu povezanost sa klijentom koji je aktivan za vrijeme trajanja sesije. Kada se podaci trebaju prenijeti, koristi se kontrolirana veza koja serveru nudi ime odredine ili izvorine datoteke te se koristi za pregovaranje o izvorinom i odredinom portu za sami transfer. Moe se rei da je cloud API poput FTP kontroliranog kanala: aktivan je za vrijeme koritenja cloud sustava, te kontrolira kako se cloud iskoritava kako bi osigurao krajnje usluge koje je razvijatelj imao u vidu. Postoji zamka kod koritenja API-ja za definiranje kako se infrastruktura clouda iskoritava: za razliku od FTP protokola, cloud API-jevi jo nisu standardizirani te svaki pruatelj cloud usluga ima vlastiti API za upravljanje uslugama. Ovo stanje je svojstveno za mlade industrije i tehnologije, kada svaki isporuitelj ima svoju vlasniku tehnologiju kojoj je jedna od svrha zadravanje korisnika, jer vlasniki API-ji oteavaju promjenu pruatelja usluga.

3.3 Dobrobiti cloud raunarstva

Da bi se cloud raunarstvo najvie iskoristilo, razvijatelji moraju biti u mogunosti razloiti aplikacije kako bi one mogle maksimalno iskoristiti arhitekturne i distribucijske paradigme koje cloud podrava. Dobrobiti distribuiranja aplikacija koritenjem clouda obuhvaaju smanjenje vremena izvravanja i odziva, minimiziranje rizika pri distribuiranju fizike infrastrukture, smanjivanje poetnih trokova i poveavanje tempa inovacija.

18

3.3.1 Smanjenje vremena izvravanja i odziva Za aplikacije koje koriste cloud najvie za izvravanje serijske obrade velike koliine podataka cloud omoguava jednostavno koritenje npr. 1000 servera za zavravanje zadatka u 1000 puta kraem vremenu nego da se zadatak izvrava na jednom serveru. Za aplikacije koje moraju imati dobro vrijeme odziva prema korisnicima vri se podjela na module tako da se svaki CPU intenzivan zadatak alje "radnikim" virtualnim mainama. Ovo pomae u optimizaciji vremena odziva, te omoguava skaliranje na zahtjev kako bi se ostvarili zahtjevi korisnika. 3.3.2 Minimiziranje infrastrukturnog rizika IT organizacije mogu koristiti cloud kako bi smanjile rizik prisutan pri kupovini fizikih servera. Hoe li nova aplikacija biti uspjena? Ako hoe, koliko je servera potrebno i mogu li se distribuirati jednakom brzinom kojom e rasti radno optereenje? Ako nee, hoe li velika investicija na servere propasti? Ako je uspjeh aplikacije kratkotrajan hoe li IT organizacija uloiti u veliku koliinu infrastrukture koja e veinu vremena biti neiskoritena? Pri distribuiranju aplikacije na cloud skalabilnost i rizik kupovine previe ili premalo infrastrukture postaje problem pruatelja cloud usluge. U velikom broju sluajeva pruatelj cloud usluge posjeduje ogromnu koliinu infrastrukture koja moe podrati rast i iljke u radnom optereenju pojedinih korisnika. Drugi nain na koji cloud minimizira infrastrukturne rizike je omoguavanje surge raunarstva u kojem poslovni centar podataka (moda neki na kojem je implementiran privatni cloud) pospjeuje svoju mogunost podravanja iljaka u optereenju dizajnom koji mu omoguava slanje zadataka koji prekorauju kapacitet na javni cloud. Upravljanje ivotnim ciklusom aplikacije je olakano u okruju u kojem resursi nisu deficitarni i u kojem se resursi mogu bolje uskladiti sa trenutnim potrebama uz manje trokove. 3.3.3 Manji poetni trokovi Postoje brojna svojstva cloud raunarstva koja pomau pri smanjivanju trokova kod ulaska na nova trita: Budui da je infrastruktura iznajmljena, a ne kupljena, trokovi su kontrolirani i poetna investicija moe biti jednaka nuli. Uz manje trokove kupovine vremena za 19

obradu podataka i prostora za pohranu po potrebi, velika veina pruatelja cloud usluga na dodatne naine pomae pri minimiziranju trokova. Aplikacije se razvijaju vie "sastavljanjem" umjesto programiranjem. Ovakav brzi razvoj aplikacija je pravilo koje smanjuje vrijeme koje je potrebno da se aplikacija pusti na trite, te potencijalno prua organizacijama koje distribuiraju aplikacije na cloud poetnu prednost pred konkurencijom. 3.3.4 Poveani tempo inovacija Cloud raunarstvo moe pomoi pri poveanju tempa inovacija. Niski poetni trokovi pri ulasku na nova trita pomau u izjednaavanju mogunosti jer omoguavaju novim tvrtkama distribuiranje novih proizvoda na brz i jeftin nain. Ovo omoguava malim tvrtkama efikasnije natjecanje sa tradicionalnim organizacijama iji proces distribuiranja na poslovne centre podataka moe biti znatno dui i kompliciraniji. Poveano trino natjecanje pomae pri poveanju tempa inovacija sa mnogo inovacija realiziranih pomou koritenja softvera otvorenog koda cijela industrija ima koristi od poveanog tempa inovacija koje promovira cloud raunarstvo.

3.4 Service Level Agreement (SLA)

Service level agreement (esto skraeno kao SLA) je dio ugovora o usluzi u kojem se formalno definira razina usluge. U praksi se pojam SLA ponekad koristi za referiranje ugovorenog vremena isporuke usluge ili performansi. SLA je dogovoreni ugovor izmeu dviju stranaka, gdje je jedna korisnik, a druga pruatelj usluga. SLA moe predstavljati pravno obvezujui formalni ili neformalni ugovor. Ugovori izmeu pruatelja usluga i tree strane se esto pogreno nazivaju SLA budui da je razina usluge postavljena od strane glavnog korisnika ne moe postojati SLA sa treom stranom. SLA sadri uobiajeno razumijevanje o uslugama, prioritetima, obavezama, garancijama i jamstvima. Svako podruje opsega usluge bi trebalo imati definiranu razinu usluge. SLA moe specificirati razine dostupnosti, uporabivosti, performansi ili druge atribute usluge poput naplate. Razina usluge se, takoer, moe definirati kao ciljana i minimalna, to omoguava korisnicama informiranje o oekivanjima (minimum), te pruanje mjerljive 20

(prosjene) ciljne vrijednosti koja pokazuje razinu organizacijskih performansi. U nekim ugovorima se dogovaraju globe u sluajevima krenja ugovora. Vano je napomenuti da se ugovor odnosi na usluge koje korisnik prima, a ne na nain na koji pruatelj dostavlja usluge. SLA ugovori se koriste od kasnih osamdesetih godina prolog stoljea od strane telekom operatora kao dio ugovora sa pravnim osobama. Ova praksa se toliko rairila da je danas uobiajeno da korisnik pruatelju usluga alje SLA sa potrebnim razinama usluga. U nekim velikim tvrtkama se SLA koriste interno izmeu razliitih odjeljenja i timova. Jedna od dobrobiti ovakvog pristupa je poboljavanje kvalitete usluge. SLA ugovori su zasnovani na izlazu subjekt dogovora je rezultat usluge primljen od strane korisnika. Organizacije, takoer, mogu specificirati nain na koji se usluga dostavlja pomou karakteristika (na razini usluge) i koritenjem podlonih ciljeva. Ovakav tip ugovora je poznat kao ulazni SLA. Kasnije navedeni tip zahtjeva zastarijeva kako organizacije postaju zahtjevnije i prebacuju rizik dostavljanja na pruatelja usluge. SLA ugovori se, takoer, definiraju na razliitim nivoima poput: korisniki zasnovani SLA: ugovor sa individualnom grupom korisnika koji pokriva sve usluge koje se koriste SLA zasnovani na uslugama: ugovori za sve korisnike koji koriste usluge dostavljane od strane pruatelja usluga vierazinski SLA: SLA je podijeljen na razliite razine od kojih se svaka odnosi na drugu grupu korisnika iste usluge SLA na korporativnoj razini: pokriva sve openito upravljanje problemima na razini usluge (SLM) za svakog korisnika u organizaciji SLA na korisnikoj razini: pokriva sve SLM probleme relevantne za pojedine grupe korisnika, nevezano za usluge koje se koriste SLA na razini usluge: pokriva sve SLM probleme relevantne za karakteristine usluge

21

3.4.1 Uobiajene metrike SLA ugovori mogu sadrati brojnu metriku performansi usluga sa odgovarajuim ciljevima na razini usluge. Uobiajeni sluaj u IT upravljanju uslugama je pozivni centar. Metrike koje se uobiajeno dogovaraju u ovom sluaju obuhvaaju: ABA (abandonment rate stopa odustajanja): postotak poziva koji odustanu od ekanja na javljanje operatera ASA (average speed to answer prosjeno vrijeme javljanja): prosjeno vrijeme potrebno da se operater javi na poziv TSF (time service factor): postotak poziva odgovorenih unutar odreenog vremenskog roka FCR (first call resolution): postotak dolaznih poziva koji se mogu rijeiti bez povratnog poziva TAT (turn around time): vrijeme potrebno za zavravanje odreenog zadatka.

Ugovori o vremenu neprekidnog rada su jo jedan primjer este metrike, esto koriteni kod podatkovnih usluga poput virtualnih privatnih servera itd. Uobiajeni ugovori, takoer, sadre postotak vremena neprekidnog rada mree, neprekidnog vremena opskrbe elektrinom energijom itd. Ovdje je dan samo kratki pregled uobiajenih SLA metrika. One uvelike ovise o podruju primjene, to e se vidjeti u kasnijem poglavlju o upravljanju znanjem u cloud raunarstvu gdje su navedeni SLA i SLO koriteni pri implementaciji i evaluaciji pojedinih metoda. 3.4.2 SLA u cloud raunarstvu Cloud raunarstvo, takoer, koristi SLA koncept za kontroliranje koritenja i obraunavanja resursa. Svaka strategija upravljanja SLA ugovorima podrazumijeva dvije dobro diferencirane faze: pregovaranje o ugovoru praenje njegova ispunjenja u realnom vremenu 22

Stoga, upravljanje SLA ugovorima obuhvaa definiranje ugovora (osnovna shema sa parametrima kvalitete usluge), SLA pregovaranje, SLA praenje i SLA provoenje prema definiranim pravilima. Glavna toka je izgradnja novog sloja na cloud middleware koji omoguava mehanizam pregovaranja izmeu pruatelja i korisnika usluga. Temeljne beneficije cloud raunarstva su dijeljeni, distribuirani resursi. Stoga, SLA ugovori obuhvaaju cloud, te se nude od pruatelja usluga u obliku ugovora zasnovanih na uslugama. Mjerenje, praenje i izvjetavanje o cloud performansama se zasniva na iskustvima krajnjeg korisnika ili na sposobnosti krajnjeg korisnika da troi resurse. Negativna strana SLA ugovora u cloud raunarstvu su potekoe u odreivanju stvarnog uzroka prekida usluga zbog kompleksne prirode cloud okruja.

23

ZNANJE I UPRAVLJANJE ZNANJEM

Pojam znanja je jedan od filozofskih pojmova koji do dan danas nisu jednoznano definirani. Klasina se definicija znanja pridjeljuje grkom filozofu Platonu koji je rekao da bi se neka izjava mogla smatrati znanjem treba biti ''opravdano istinito vjerovanje''. Uz pojam znanja vezani su i pojmovi podaci, informacije, mudrost i shvaanje (razumijevanje) koji su kratko definirani u nastavku. Podaci su simboli bez ikakvog znaenja osim vlastitog postojanja. Mogu biti u razliitim formama. Informacije su obraeni podaci koji su dobili znaenje relacijskim vezama s drugim podacima. Ovako obraeni podaci mogu biti i korisni, iako to nije uvjet. U raunalnom svijetu informacije sadri relacijska baza na temelju podataka sloenih u relacijske odnose. Ponekad se kae da informacije daju odgovore na pitanja ''tko'', ''to'', ''gdje'' i ''kada''. Iz podataka dolazimo do informacija ukoliko shvatimo odnose ili relacije. Znanje je odgovarajui skup informacija kojima je osnovna namjena da budu korisni. Znanje se stjee kroz proces uenja u kojem se informacije pretvaraju u znanje kako bi nam bilo od nekakve koristi, kako bi nam posluilo za neto. Ponekad se kae da je znanje primjena podataka i informacija sa ciljem davanja odgovora na pitanje ''kako''. Iz informacija do znanja dolazimo ukoliko shvatimo model, obrazac ili predloak. Na temelju njega moemo i predvidjeti to e se u budunosti dogaati, to kod samog poznavanja informacija nije mogue. Slijedei je korak shvaanje temeljnih principa koji nas vodi prema mudrosti. Mudrost ukljuuje shvaanje temeljnih principa ukljuenih u znanje zbog kojih je znanje upravo takvo kakvo jest. Mudrost bi bila najvei stupanj spoznaje, koji bi trebao ukljuivati ne samo shvaanje principa ve i moral, etiku, pa neki autori smatraju da mudrost moe imati samo ovjek.

24

4.1 Prikazivanje znanja

Znanje se moe formalno prikazati na razliite naine koji se mogu grubo svrstati u 4 grupe: Logike sheme za prikaz znanja Mrene sheme za prikaz znanja Proceduralne sheme za prikaz znanja Okvire

U logike sheme spada prikaz znanja temeljen na matematikoj logici, kako standardnoj, tako i nestandardnoj, dok se postupak zakljuivanja temelji na pravilima zakljuivanja. Najvaniji predstavnik logikih shema su produkcijski sustavi koji su danas sigurno najrasprostranjeniji posebno kod realizacije ekspertnih sustava. U mrene sheme spada prikaz znanja temeljen na mrenim prikazima kojima se iskazuje povezanost pojedinih elemenata znanja. Najistaknutiji predstavnik su semantike mree, jedan od najstarijih i najeih postupaka standardnog prikaza deklarativnog znanja. Proceduralne sheme slue i za prikaz znanja, ali daju i procedure za koritenje tog znanja. Proceduralan prikaz znanja je ujedno i stvarni plan kako se znanje koristi, pa postoji velika slinost izmeu postupaka konstruiranja planova i konstruiranja proceduralnog prikaza znanja. Okviri u svemu tome imaju posebno mjesto i, na neki nain, ine fuziju svih metoda. Okviri su strukture preko kojih, na primjer, moemo implementirati semantiku mreu kojoj smo dodali i proceduralni dodatak kako manipulirati pohranjenim znanjem. Vaan pojam u svim sustavima prikaza znanja su injenice, tj. stvari koje predstavljamo. U logikim sustavima injenice su tvrdnje iju istinitost poznajemo. Kako bismo mogli s jedne strane injenice pripremiti za predstavljanje u formalnim prikazima znanja, a s druge strane i koristiti dobivene rezultate, nuno je uspostaviti vezu izmeu formalnog prikazivanja i vanjskog svijeta. 4.1.1 Logiko prikazivanje znanja Logiki formalizam je izuzetno vaan zbog injenice to se novo znanje moe generirati iz starog znanja koristei postupak matematike dedukcije. Logika barata istinitostima pojedinih tvrdnji i daje precizna pravila kako se iz pojedinih tvrdnji poznate istinitosti povezanih logikim operatorima moe proraunati istinitost sloene tvrdnje. Pomou logike je mogue ustanoviti istinitost neke tvrdnje iju istinitost ne poznajemo, ukoliko dokaemo da je ta tvrdnja izvedena iz injenica koje su istinite i poznate. 25

Matematike logike dijelimo na standardne, koje se oslanjaju na klasinu, propozicijsku ili predikatnu logiku i nestandardne matematike logike, od kojih je moda najpoznatija neizrazita (fuzzy) logika koja je u posljednje vrijeme nezaobilazna kod mnogih primjena inteligentnih tehnologija. Osnovna razlika izmeu standardnih i ne-standardnih logika je u stupnjevima istinitosti. Kod standardnih logika imamo samo dva stupnja istinitosti, pa tvrdnja moe biti ili istinita ili lana (neistinita). Standardna logika je dvovaljana. Nestandardne logike su vievaljane, odnosno mogu imati vie stupnjeva istinitosti. Granini sluaj je neizrazita (fuzzy) logika koja je beskonano valjana. U osnovi raunalnog programiranja nalazi se logika. Programski jezici su po mnogim svojim znaajkama samo implementacija specijalnih logikih formi. Na primjer, u jeziku C logika su generalne procedure iskazane IF naredbama, dok su jezici tipa Prolog direktni primjer implementacije predikatne logike. 4.1.1.1 Propozicijska logika Propozicijska se logika bavi odreivanjem istinitosti ili neistinitosti razliitih propozicija, a propozicija je ispravno postavljena tvrdnja koja moe biti istinita ili lana. Propozicije se meusobno povezuju operatorima u dobro formulirane formule . Operatora ima ukupno 16, od kojih je 10 koji povezuju dvije propozicije posebno zanimljivo, a vaan je i jedini operator koji se odnosi na samo jednu varijablu (negacija). Istinitost dvije tvrdnje povezane operatorima rauna se pomou tablica istinitosti. Iako je propozicijska logika osnova digitalne elektronike, sklopovskog ustroja raunala i brojnih raunalnih jezika, ona nije ba najpogodnija za prikazivanje ljudskog znanja zato to nema mogunosti prikazivanja odnosa izmeu objekata, pa se koritenjem propozicijske logike ne moe upotrijebiti nikakva klasifikacija. Ovi nedostaci su ispravljeni u predikatnoj logici koja preuzima sva svojstva propozicijske logike i dodaje joj vrlo vaan pojam predikata. 4.1.1.2 Predikatna logika Propozicijska logika ne dozvoljava formiranje generalne izjava tipa Marko jede sve to mu je drago. U duhu propozicijske logike za sva jela koje Marko voli trebamo napisati posebne propozicije, na primjer Marko voli okoladu, Marko voli keks, Marko voli sir., Marko ne voli prut. itd. Predikatna logika to omoguava. Umjesto da se bavi propozicijama koje se ne mogu ralaniti, predikatna logika uvodi pojam predikat, koji je u biti funkcija koja vraa vrijednost istinitosti (0 ili 1) u ovisnosti o svojim argumentima. 26

Osnovna razlika izmeu predikatne i propozicijske logike je separacija atributa od objekata koji posjeduju te atribute. Drugim rijeima u predikatnoj logici moe se definirati funkcija kojom odreujemo tvrdou bilo kojeg objekta, dok se u propozicijskoj logici za svaki pojedini sluaj mora definirati posebna tvrdnja. Osnovni pojmovi predikatne logike su: domena skup elemenata nad kojima se izvodi zakljuivanje konstante elementi domene varijable simboli koji se obino oznaavaju slovima X, Y, W itd. koji mogu poprimiti bilo koju vrijednost iz domene predikati funkcije koje preslikavaju jedan ili vie elemenata domene u jednu od vrijednosti istinitosti. Predikat govori o nekom svojstvu elemenata domene ili o meusobnim relacijama elemenata domene. 4.1.1.3 Nestandardne logike Ne-standardne logike se dijele u dvije osnovne grupe: logike koje proiruju standardne logike i nisu s njima u kontradikciji. Kod njih vrijede svi aksiomi standardnih logika plus neki dodatni. Tipian primjer su modalne logike. Na primjer osnovna modalna logika koja uvodi nove operatore: L (nuno je) i M (mogue je), zatim temporalne logike kojima se dodaje pojam vremena, neke trovaljane logike itd. logike koje su u suprotnosti sa standardnim logikama, kod kojih se pojedini aksiomi suprotstavljaju aksiomima standardnih logika. Tipian primjer su takoer vie-valjane logike, kao na primjer neizrazita (fuzzy) logika, zatim intuicijske logike itd.

4.2 Upravljanje znanjem

Upravljanje znanjem spaja niz strategija i praksi koje se koriste u organizaciji za identificiranje, stvaranje, prikazivanje, distribuiranje i omoguavanje usvajanja predodbi i iskustava [7]. Predodbe i iskustva obuhvaaju znanje, bilo da je ono utjelovljeno u pojedincima ili sadrano u organizacijskim procesima i praksama. Drugim rijeima, upravljanje znanjem je disciplina koja omoguava pojedincima, timovima i cijelim organizacijama kolektivno i sistematsko stvaranje, dijeljenje i primjenu znanja u svrhu 27

efikasnijeg postizanja ciljeva.Upravljanje znanjem je kao disciplina uspostavljeno od 1991. godine, te se protee kroz nekoliko polja poput poslovne administracije, informacijskih sustava, rukovodstva i informacijskih znanosti. Odnedavno su i druga polja poela pridonositi istraivanjima upravljanjem znanja ukljuujui informacije i medije, raunalnu znanost, javno zdravstvo itd. Dosta velikih i neprofitnih organizacija imaju istraivanja posveena internim pokuajima upravljanja znanjem, esto kao dio poslovne strategije, informacijske tehnolo gije ili upravljanja ljudskim resursima.Nastojanja upravljanja znanjem se najee fokusiraju na organizacijske ciljeve poput poboljanja performansi, prednosti nad konkurencijom, inovacije, integracije i kontinuiranog unaprjeenja organizacije. Ova nastojanja se esto preklapaju sa organizacijskim uenjem, te se od njega razlikuju veim fokusom na rukovoenje znanjem kao strategijskog faktora i fokusom na podupiranju dijeljenja znanja. Nastojanja upravljanja znanjem pomau pojedincima i grupama u dijeljenju vrijednih organizacijskih predodbi, te se na ovakav nain smanjuju redundantni poslovi, vrijeme obuke novih zaposlenika i olakava prilagodba novim okruenjima i tritima. 4.2.1 Povijest Upravljanje znanjem ima dugu povijest koja obuhvaa forume, korporativne knjinice, profesionalnu obuku i programe mentorstva. U zadnje vrijeme sa poveanim koritenjem raunala u drugoj polovici dvadesetog stoljea specifine primjene tehnologija poput baza znanja, ekspertnih sustava, repozitorija znanja i sustava za podrku grupnom donoenju odluka su omoguile bri razvoj u ovom polju. 1999. godine je uveden pojam osobnog upravljanja znanjem koji se odnosi na upravljanje znanjem na osobnoj razini. Sa poslovnog pogleda, rane kolekcije analiza sluajeva su prepoznale vanost znaajki upravljanja znanjem u mjerenjima strategija i procesa. Zakljueno je da programi upravljanja znanjem mogu prinijeti impresivne koristi pojedincima i organizacijama. U novije vrijeme sa pojavom Web-a 2.0, koncept upravljanja znanjem evoluira prema viziji vie zasnovanoj na ljudskom sudjelovanje. Ova je crta evolucije nazvana Enterprise 2.0. Meutim, postoji tekua rasprava o tome da li je Enterprise 2.0 samo hir koji ne donosi nita novo, ni korisno ili je, zaista, budunost upravljanja znanjem.

28

4.2.2 Istraivanja Upravljanje znanjem se pojavilo kao znanstvena disciplina u ranim devedesetim godinama prolog stoljea. U poetku je podravano iskljuivo od strane strunjaka kad je Scania zaposlila Leif Edvinsson-a kao prvog svjetskog glavnog slubenika znanja (Chief Knowledge Officer). Huber Saint-Onge je istraivao raznolike strane upravljanja znanjem, puno ranije od gore navedenog dogaaja. Cilj CKO-a je upravljanje i maksimiziranje nematerijalne imovine organizacije. Postepeno se CKO poinju baviti, ne samo praktinim, ve i teoretskim aspektima upravljanja znanjem, te je tako stvoreno novo podruje istraivanja. Ideje upravljanja znanjem su prihvatili brojni znanstvenici i akademici. Godine 2001. Thomas A. Stewart izdaje reportau sa naslovnice koja je naglaavala vanost intelektualnog vlasnitva organizacija. Od svog nastanka upravljanje znanjem se postepeno kree ka svojoj akademskoj zrelosti. Postoji irok raspon miljenja o disciplini upravljanja znanjem bez jednoglasne odluke; pristupi variraju od autora do autora. Kako disciplina sazrijeva, poveao se broj akademskih debata koje obuhvaaju i teoriju i praksu, te sadre slijedee perspektive: Tehnoloki orijentirana sa fokusom na tehnologiji koja unaprjeuje stvaranje i dijeljenje znanja. Organizacijska sa fokusom na nain dizajniranja organizacije kako bi se najbolje olakali procesi vezani uz znanje. Ekoloka sa fokusom na ljudskoj komunikaciji, identitetu i okolinskim faktorima kao dijelovima kompleksnog, adaptivnog sustava srodnog prirodnom ekosustavu. Neovisno o autoru ili koli temeljne komponente upravljanja znanjem obuhvaaju ljude, procese, kulturu i tehnologiju. Razliite kole upravljanja znanjem imaju specifine poglede i objanjenja upravljanja znanjem. 4.2.3 Znaajke Postoje razliite okosnice za razlikovanje znanja. Jedna predloena okosnica za kategorizaciju znaajki znanja razlikuje preutno i eksplicitno znanje. Preutno znanje predstavlja znanje kojeg pojedinac ne mora biti svjestan, poput naina obavljana pojedinih zadataka. Sa druge strane eksplicitno znanje predstavlja znanje koje pojedinac svjesno dri u mentalnom fokusu u obliku koji je jednostavan za koritenje u komunikaciji sa drugim pojedincima. 29

Rana istraivanja su pokazala da bi uspjeno upravljanje znanjem trebalo pretvarati preutno znanje u eksplicitno kako bi se ono moglo dijeliti, ali bi isto nastojanje, takoer, moralo dozvoljavati pojedincima da internaliziraju i uine osobno znaajnim bilo koje kodirano znanje izvueno iz procesa upravljanja znanjem. Slijedea istraivanja u polju upravljanja znanjem predlau da razlikovanje izmeu preutnog i eksplicitnog znanja predstavlja pretjerano pojednostavljivanje, te da je samo pojam eksplicitnog znanja sam sebi kontradiktoran. Konkretno, da bi se znanje uinilo eksplicitnim, mora se prevesti u informaciju, tj. u simbole izvan naih glava. Kasnije je predloen model koji u obzir uzima spiralni proces interakcije znanja izmeu eksplicitnog i preutnog znanja. U ovom modelu znanje prati ciklus u kojem se implicitno znanje izvlai kako bi postalo eksplicitno, a eksplicitno se ponovno internalizira u implicitno znanje. Druga predloena okosnica za kategorizaciju znaajki znanja razlikuje ugraeno znanje sustava izvan ljudske individue (npr. informacijski sustavi mogu imati znanje ugraeno u svoj dizajn) i utjelovljeno znanje koje predstavlja sposobnost uenja ljudskog ivanog i endokrinog sustava. Trea predloena okosnica za kategorizaciju znaajki znanja razlikuje istraivako stvaranje novog znanja (npr. inovacije) i prijenos ili eksploataciju uspostavljenog znanja unutar grupe, organizacije ili zajednice. Kolaborativna se okruenja poput koritenja alata za drutveno raunarstvo mogu koristiti za stvaranja i prijenos znanja. 4.2.4 Strategije Znanju se moe pristupiti u tri stadija: prije, tijekom ili nakon aktivnosti vezanih za upravljanje znanjem. Razliite organizacije su probale razliite poticaje za skupljanje znanja. Znatne kontroverze postoje o tome da li poticaji djeluju ili ne, te se jo nije dolo do konsenzusa. Jedna strategija upravljanja znanjem ukljuuje aktivno rukovoenje znanjem. U ovom sluaju pojedinci nastoje eksplicitno enkodirati vlastito znanje u repozotorij dijeljenog znanja (poput baze podataka), te, takoer, dohvaaju znanje koje im je potrebno. Ovaj pristup je uobiajeno poznat kao kodifikacijski pristup upravljanju znanja. Ostale strategije upravljanja znanjem za tvrtke ukljuuju: nagrade (sredstvo motivacije za dijeljenje znanja) pripovijedanja (sredstvo prenoenja preutnog znanja)

30

mapiranje znanja direktoriji eksperta prijenos najbolje prakse upravljanje sposobnostima kolaborativne tehnologije repozitoriji znanja mjerenje i izvjetavanja o intelektualnom vlasnitvu drutveni softver (wiki, blogovi itd.)

4.2.5 Tehnologije Rane tehnologije upravljanja znanjem su obuhvaale korporacijske ute stranice kao lokatore strunosti i sustave za upravljanje dokumentima. Kombinirano sa ranim razvojem kolaboracijskih tehnologija (Lotus Notes), tehnologije upravljanja znanjem se ire u srednjim devedesetim godinama prolog stoljea. Slijedei pokuaji su utjecali semantikim tehnologijama za pretraivanje i razvojem e-learning alata. U novije vrijeme razvoj alata za drutveno raunarstvo omoguava manje strukturirane, samoupravne pristupe prijenosu, hvatanju i stvaranju znanja. No, ovakvi alati su veim dijelom i dalje zasnovani na tekstu i kodu, te kao takvi predstavljaju eksplicitni prijenos podataka. Ovi alati su suoeni sa izazovima kod otkrivanja smislenog znanja. Softverski alati u upravljanju znanjem su kolekcije tehnologija, te se ne mogu nuno dobaviti kao pojedini komad softvera. Nadalje, ovi softverski alati imaju prednost koritenja postojee infrastrukture informacijske tehnologije u organizaciji. Organizacije troe znatnu koliinu resursa i znaajno ulau u najnovije tehnologije, sustave i infrastrukturu kako bi podrali upravljanje znanjem. Upravljanje znanjem je, takoer, postalo kamen temeljac u novim poslovnim strategijama poput Service Lifecycle Management-a (SLM), gdje se tvrtke sve vie obraaju proizvoaima softvera kako bi poboljali efikasnost na tritu.

31

4.2.6 Upravljanje znanjem i kolaboracija Razvoj Web 2.0 je dodao nove dimenzije procesu upravljanja znanjem. Kolaboracijski alati temeljeni na Web tehnologijama, poput wiki-ja, su omoguili zaposlenicima da neprekidno pridonose i pristupaju informacijama centralnog repozitorija. Tvrtke koje su implementirale baze znanja temeljene na wiki dizajnu prijavljuju znatne poraste u produktivnosti nakon to se uspostave navike pridonoenja, dijeljenja i pristupanja znanju. Virtualni svjetovi su nadalje poveali kolaboracijske mogunosti u procesu dijeljenja znanja. Za razliku od Web 2.0 aplikacija u virtualnim svjetovima tim moe raditi sinkronizirano. Nove generacije alata virtualnih svjetova omoguuju timovima ne samo verbalni prijenos informacija, ve i dokumentiranje istih. 4.2.7 Metode upravljanja znanjem Metode upravljanja znanjem se mogu grupirati u dvije glavne grupe: metode koje cirkuliraju znanjem unutar organizacije metode koje pomau pri stvaranju znanja

Metode koje pomau pri cirkuliranju znanja obuhvaaju: komunikaciju licem u lice metode komunikacije zasnovane na raunalima (email, Lotus Notes) skladitenje i dohvaanje informacija koritenje raunalnih sustava (intranet) sustavi zasnovani na znanju (ekspertni sustavi)

Metode i tehnike upravljanja znanjem su brojne te uvelike ovise o podruju primjene. U slijedeem poglavlju e biti prikazane metode koje su izabrane kao najbolje za upravljanje znanjem u cloud/SLA sustavima.

32

UPRAVLJANJE CLOUDIMA

ZNANJEM

SAMOPRILAGODLJIVIM

Da bi se postigla eljena razina fleksibilnosti clouda raunalni resursi moraju biti alocirani softveru koji eka na izvravanje. Potrebno je da alokacija bude ne samo dinamika, ve i autonomna. Kao to je reeno u prijanjim poglavljima, resursi se alociraju prema unaprijed definiranim SLA ugovorima koji se sastoje od parametara poput vremena odziva, dostupnosti ili prostora za pohranu podataka. Service Level Objective (SLO) za svaki SLA parametar definira cilj koji je potrebno postii, npr. dostupnost > 98%. U sluaju krenja SLO-a pruatelj cloud usluga plaa kazne korisniku koje su, takoer, definirane unutar SLA ugovora. U mnogo sluajeva jednostavne reakcije poput premjetanja virtualnih maina sa ve alociranih vorova na dodatne dostupne vorove mogu sprijeiti krenja utvrenih SLA ugovora [8]. Meutim, identificiranje ovakvih reakcija je daleko od trivijalnog. Pozitivni efekti raspoznavanja moguih SLA krenja prije nego se pojave su dvostrani. Sa jedne strane pomae pruatelju cloud usluga da izbjegne plaanje kazni, te sa druge minimizira interakciju korisnika sa samim sustavom. Nadalje, efektivno SLA upravljanje, takoer, oslobaa dodatne resurse koji bi se inae koristili za ispunjavanje SLA ugovora. U ovom poglavlju je prikazano koritenje baza znanja za samoupravljanje u cloudu. Opisane su tri metode upravljanja znanjem i mogunosti njihove implementacije unutar cloud sustava: 1. baze pravila (rule based system) 2. uobiajena logika (default logic) 3. situation calculus 4. rasuivanje temeljeno na sluajevima (case based reasoning) Detaljnije e se prikazati metoda rasuivanja temeljenog na sluajevima [8]. Nadalje e se detaljnije prikazati istraivanja vezana uz default logics metodu koja su obavljena kao kljuni dio ovog rada, te tehnologija i pristup koji je odabran za implementaciju i evaluaciju. Razvoj case based reasoning metode za cloud je sastavni dio FoSII (Foundations of Selfgoverning ICT Infrastructures) [9]. Cilj FoSII projekta je razvoj infrastrukture za autonomno SLA upravljanje i provoenje. U nastavku poglavlja je dan osvrt na FoSII infrastrukturu i 33

povezanost sa metodama upravljanja znanjem. Prikazana je i studija sluaja izabrana za evaluaciju case based reasoning pristupa [8].

5.1 Pregled FoSSI infrastrukture

FoSII infrastruktura se koristi za upravljanje cijelim ivotnim ciklusom usluga samo upravljajueg clouda (Slika 5-1). Upravljanje ureuje ciklus nadziranje-analiza-planiranjeizvravanje (MAPE; implementira tri suelja: 1. suelje za pregovaranje nuno za osnivanje SLA ugovora 2. suelje za upravljanje zadacima nuno za pokretanje zadataka, slanje podataka i slino 3. suelje samoupravljanja nuno za proces osmiljavanja akcija potrebnih za prevenciju krenja SLA ugovora. Monitor-Analysis-Plan-Execute). Nadalje, svaka FoSII usluga

Slika 5-1 FoSII infrastruktura [8]

Suelje za samoupravljanje (Slika 5-1) je implementirano od strane svake cloud usluge i specificira djelovanja potrebna za otkrivanje promjena eljenog stanja, te reakcije na te promjene. Senzori na glavnom raunalu neprestano nadgledaju metriku infrastrukturnih resursa i trenutne statuse resursa dostavljaju autonomnom upravitelju. Senzori otkrivaju 34

budua krenja SLA ugovora na temelju iskustava iskoritenosti resursa i unaprijed definiranih granica prijetnje. Granice prijetnje su restriktivnije od SLO vrijednosti [10]. Odreivanje granica prijetnji je daleko od trivijalnog, te bi one trebale biti konstantno aurirane od strane sustava za upravljanje znanjem, a samo na poetku postavljene runo od strane administratora sustava. Potrebno je opisati mapiranje izmeu izmjerenih vrijednosti glavnog raunala i vrijednosti SLA parametara. Kao to je vidljivo na slici 5-1 razlikuje se nadgledanje glavnog raunala i nadgledanje u vremenu izvravanja. Resursi se nadgledaju pomou proizvoljnih alata za nadgledanje na glavnom raunalu. Stoga, metrika resursa obuhvaa vrijeme stajanja, vrijeme neprekidnog rada, dostupnu irinu dolaznog i odlaznog mrenog pojasa. Na temelju unaprijed definiranih pravila mapiranja zapisanih u bazi podataka izmjerena metrika se periodiki mapira u SLA parametre. Primjer SLA parametra je dostupnost usluge Du (Tablica 5-1) koja se izraunava pomou metrika vremena stajanja i vremena neprekidnog rada. Mapiranje za dostupnost usluge se vri pomou slijedee formule: (1) Pravila mapiranja se definiraju od strane pruatelja usluga koritenjem odgovarajueg DSL (Domain Specific Language) jezika. Izraunate SLA vrijednosti se usporeuju sa predefiniranim granicama prijetnje kako bi se reagiralo prije krenja SLA ugovora. Jednom kada se mogua SLA krenja otkriju reaktivne akcije se moraju provesti kako bi se izbjeglo samo krenje. U slijedeem poglavlju je prikazan SLA primjer koriten za modeliranje i evaluaciju metoda upravljanja znanjem [8]. 5.1.1 Primjer koritenja U ovom poglavlju je prikazan primjer koritenja koji je definiran za ispitivanje metoda upravljanja znanjem. Primjer SLA ugovora je prikazan u tablici 5-1.

35

Tablica 5-1 Primjer SLA ugovora [8] SLO naziva irina dolaznog mrenog pojasa (DM) irina odlaznog mrenog pojasa (OM) Prostor za pohranu (PP) Dostupnost (Du) SLO vrijednost > 10 Mbit/s > 12 Mbit/s > 1024 GB 99%

Razmatraju se etiri SLO cilja: irina dolaznog mrenog pojasa irina odlaznog mrenog pojasa prostor za pohranu dostupnost

Odgovarajue SLO vrijednosti su prikazane u desnom dijelu tablice 5-1. Kako bi se evaluirali razliiti pristupi upravljanju znanjem stanje sustava se opisuje u pogledu na aktivne fizike maine (FM) i na aplikaciju koja se izvrava u tri razliita trenutka (t1, t2, t3) u odnosu na gore navedeni SLA ugovor. Pretpostavlja se da se jedna aplikacija izvrava na jednoj virtualnoj maini (VM), ali se jedna virtualna maina moe izvravati na vie fizikih. Tablica 5-2 prikazuje izmjerena stanja sustava [8].

36

Tablica 5-2 Primjer stanja sustava [8] DM t1 t2 t3 12.0 14.0 20.0 OM 20.0 18.5 25.0 PP 1200 1020 1250 Du 99.50 99.47 99.60 Broj FM 20 17 19

Ciljevi za sustav upravljanja znanjem su definirani na slijedei nain [8]: 1. Kontinuirano stvaranje i unaprjeivanje SLA granica prijetnje. Na temelju promatranja prolih stanja sustav upravljanja znanjem treba stvarati granice prijetnje za odreeni SLO. 2. Odreivanje reakcija. U sluaju nepostojanja granica prijetnje sustav upravljanja znanjem treba predloiti reakcije na temelju prijanjih stanja sustava. Na temelju SLA ugovora definiranog u tablici 5-1 i stanja sustava prikazanih u tablici 5-2 predloene su definicije reakcije sustava [8]. Pretpostavka je da sustav upravljanja znanjem djeluje u modu identifikacije reakcija bez konkretnih predefiniranih granica prijetnje za krenje SLA ugovora. Stoga je definirana skupina akcija koju je komponenta za izvravanje MAPE ciklusa sposobna aktivirati [8]: 1. za pojedine aplikacije (aplikacija se izjednaava sa virtualnom mainom jer se pretpostavlja jedan-na-jedan mapiranje izmeu aplikacija i virtualnih maina): a. poveaj irinu dolaznog mrenog pojasa za x% b. smanji irinu dolaznog mrenog pojasa za x% c. poveaj irinu odlaznog mrenog pojasa za x% d. smanji irinu odlaznog mrenog pojasa za x% e. poveaj koliinu memorije za x%

37

f. smanji koliinu memorije za x% g. dodaj alociranog prostora za pohranu za x% h. ukloni alociranog prostora za pohranu za x% i. povisi CPU udio za x% j. smanji CPU udio za x% k. premjesti aplikaciju na drugi cloud l. prihvati aplikaciju sa drugog clouda m. dodaj fiziku mainu n. ukloni fiziku mainu 2. za fizike maine (raunalne vorove): a. dodaj x raunalnih vorova b. ukloni x raunalnih vorova 3. ne radi nita (bez reakcije) U odreenim trenutcima sustav upravljanja znanjem kao ulaz prima mjerenja, te kao izlaz treba dati akciju koju je mogue izvriti kako bi se sprijeilo krenje SLA ugovora.

5.2 Metode upravljanja znanjem za upravljanje SLA ugovorima

U ovom poglavlju su prikazane metode upravljanja znanjem pogodne za upravljanje SLA ugovorima, te je prikazano istraivanje, implementacija i evaluacija za case based reasoning i default logics. 5.2.1 Rule based system (baze pravila) Baze pravila se koriste kao nain pohranjivanja i manipuliranja znanjem u svrhu interpretacije informacija na koristan nain. esto se koriste u aplikacijama i istraivanjima na polju umjetne inteligencije.

38

5.2.1.1 Aplikacije Klasini primjer baza pravila je ekspertni sustav koji koristi pravila za donoenje zakljuaka. Na primjer, ekspertni sustav moe sluiti kao pomo lijeniku pri izboru ispravne dijagnoze na temelju niza simptoma. Baze pravila se mogu koristiti za izvravanje leksike analize pri kompajliranju ili interpretiranju raunalnih programa, te u obradi prirodnog jezika. Programiranje baza pravila nastoji izvesti instrukcije izvravanja iz poetnog niza podataka i pravila. Ovo je indirektnija metoda od one koju koriste imperativni programski jezici. 5.2.1.2 Izvedba Uobiajena se baza pravila sastoji od etiri osnovne komponente [11]: Niz pravila ili baza pravila (specifini tip baze znanja). Baza znanja (zakljuaka) ili baza za semantiko rasuivanje koji izvode zakljuke na temelju interakcija izmeu ulaza i baze pravila. Privremena radna memorija. Korisniko suelje preko kojeg se ulazni i izlazni signali primaju i alju.

5.2.1.3 Baze pravila i SLA Baza pravila poput Drools [12] sadri pravila u IF uvjet THEN radnja formi, npr. : 1. IF DM < GranicaPrijetnje_DM THEN dodaj fiziku mainu 2. IF DM < GranicaPrijetnje_DM THEN poveaj DM udio za 5% za VM 3. IF Du < GranicaPrijetnje_Du THEN dodaj 2 raunalna vora sustavu 4. IF Du < GranicaPrijetnje_Du THEN premjesti aplikaciju na drugi cloud Kao to je u radnji ranije opisano u ovakvom sluaju se koriste granice prijetnje za aktiviranje odreenih radnji prije krenja SLA ugovora. Meutim, ovakav pristup ima dvije mane:

39

Pitanje granica prijetnje. Ove granice se uvelike razlikuju ovisno o SLA parametru, npr. za SLO prostor za pohranu podataka > 1024 GB, granica prijetnje moe biti ve na 1300 GB (127% originalne granice), dok za SLO DM > 10 mbit/s granica prijetnje moe biti na 11 Mbit/s (110% originalne granice), jer je alociranje udjela mrenog pojasa mnogo bre od alociranja prostora za pohranu. Granice prijetnje se, takoer, mogu razlikovati za isti parametar u razliitim domenama, npr. granica prijetnje za dostupnost usluge u medicinskoj domeni gdje su u pitanju ljudski ivoti mora biti mnogo via od granice za uslugu 3D renderiranja. Jedno od moguih rjeenja bi bilo specificiranje granica prijetnje u DSL-u ili njihovo ukljuivanje u SLA dokument. Meutim, ovaj proces bi uvelike ovisio o subjektivnoj procjeni. Ipak bi bilo mogue pronai vrijednosti iz iskustava koji bi odgovarale za veinu uobiajenih parametara. Nadalje je potrebno odrediti da li se granice prijetnje izvode pomou konstantne funkcije vrijednosti parametra (uvijek dodati 5 jedinica na vrijednost SLA parametra), linearne funkcije (uvijek dodati 10% na vrijednost) ili ak eksponencijalne ili bilo koje druge funkcije. Da bi se ovaj problem rijeio na univerzalan nain potrebno je nai odgovarajuu funkciju za svaki SLA parametar u svakoj domeni.

Drugo pitanje je rjeavanje kontradiktornih pravila. Uzmimo u obzir pravila 3) i 4) prikazana na poetku odlomka. Da li baza znanja treba dodati raunalne vorove, premjestiti aplikaciju ili boje u sluaju da dostupnost odreene usluge padne ispod unaprijed definirane granice prijetnje? Koritenje koncepta istaknutosti (prioriteta) za donoenje odluke vodi ka teko upravljivom skupu pravila.

U primjeru koritenja iz tablice 5-2 gore navedena pravila 1-4 sa granicama prijetnje za DM i Du , baza znanja bi izvrila pravila 1 i/ili 2 u trenutku t1, u trenutku t2 pravila 3 i/ili 4, a u trenutku t3 ne bi izvrila nita. 5.2.2 Default logics (uobiajena logika) Uobiajena logika je nemonotona logika za formaliziranje rasuivanja sa uobiajenim pretpostavkama. Uobiajena logika moe izraziti injenice poput uobiajeno, neto je istinito; za razliku od uobiajene, standardna logika jedino moe izraziti istinitost ili la neega. Ovo predstavlja problem jer rasuivanje esto ukljuuje injenice koje su u veini sluajeva istinite, ali ne uvijek. Klasian primjer je ptice, u pravilu, lete. Ovo pravilo se u standardnoj logici moe 40

izraziti ili kao sve ptice lete, to je nedosljedno sa injenicom da pingvini ne lete, ili kao sve ptice koje nisu pingvini i nojevi i lete, to zahtjeva specificiranje svih iznimki od pravila. Uobiajena logika cilja na formaliziranje ovakvih pravila zakljuivanja bez potrebe za eksplicitnim navoenjem svih iznimki. 5.2.2.1 Sintaksa Uobiajena teorija je par <D, W>. W je skup logikih formula koji se naziva pozadinska teorija koja formalizira injenice koje su za sigurno poznate. D je skup uobiajenih pravila (default rules) od kojih je svako slijedee forme: (2) Prema ovoj zadanoj vrijednosti ako se vjeruje da je Preduvjet istinit i svako dosljedno sa trenutnim uvjerenjima, vjeruje se da je Zakljuak istinit. 5.2.2.2 Primjeri Uobiajeno pravilo (default rule) ptice, u pravilu, lete se formalizira pomou slijedee zadane vrijednosti: {
( ) ( ) ( )

(3)

Ovo pravilo znai da ako je X ptica i moe se pretpostaviti da leti, onda se donosi zakljuak da leti. Pozadinska teorija koja sadri neke od injenica o pticama je slijedea: * ( ) ( ) ( ) ( )+

Prema ovom uobiajenom pravilu kondor leti jer je preduvjet Ptica(Kondor) istinit i opravdanje Leti(Kondor) nije nedosljedno sa trenutno poznatim injenicama. Sa druge strane Ptica(Pingvin) ne doputa zakljuak Leti(Pingvin). Iako je preduvjet Ptica(Pingvin) istinit, opravdanje Leti(Pingvin) je nedosljedno sa trenutno poznatim injenicama. Iz ove pozadinske teorije i zadanih vrijednosti, Ptica(Orao) se ne moe zakljuiti jer zadano pravilo samo doputa izvoenje Leti(X) iz Ptica(X), ali ne i obratno.

41

esta uobiajena pretpostavka je da za to se ne zna da je istinito, vjeruje se da je la. Ovo je poznato kao pretpostavka zatvorenog svijeta, te se formalizira u uobiajenoj logici koritenjem zadane vrijednosti poput slijedee sa svaku injenicu F: Na primjer, programski jezik Prolog koristi vrstu zadane pretpostavke kod upravljanja negacijom: ako se negativni atom ne moe dokazati istinitim, onda se pretpostavlja da je laan. Vano je napomenuti da Prolog koristi takozvanu negaciju kao neuspjeh: kada interpreter mora procijeniti atom opravdanje sadri , pokuava dokazati da je F istinito i zakljuiti da je istinito u sluaju neuspjeha. Za razliku od toga u uobiajenoj logici zadana vrijednost koja za se moe primijeniti samo ako je dosljedno sa trenutnim znanjem.

5.2.2.3 Uobiajena logika i SLA Uobiajena logika [13] je verzija baze pravila u kojoj pravila vie nisu jednostavna IF -THEN pravila, ve se mogu opisati kao IF uvjet i ne postoje razlozi protiv THEN djelovanje. Slijedea formula predstavlja primjer na temelju studije sluaja sa SLA ugovorima: (4)

Ovo pravilo znai: Ako je irina dolaznog mrenog pojasa manja od svoje granice prijetnje i ne postoji razlog protiv poveanja udjela irine pojasa, onda poveaj irinu dolaznog mrenog pojasa. Razlog protiv poveanja bi mogao biti da je irina pojasa ve na maksimumu ili da su druge (vanije) usluge ve zatraile poveanje u isto vrijeme. Suprotno od obinih pravila u bazi pravila, uobiajenoj logici je lako ralaniti da se resursi ne mogu poveavati beskonano. Meutim, uobiajena logika ne nudi sredstvo za rjeavanje problema nalaenja pravilnih granica prijetnje i za razrjeavanje kontradiktornih pravila. Nadalje, uobiajena logika se posebno koristi u poljima sa mnogo kontradiktornih pravila. Za Cloud raunarstvo je vanije saznati uzrok trenutnih informacija mjerenja, npr. zato se trenutna irina dolaznog mrenog pojasa smanjila. Uzroci trenutnih informacija mjerenja se trebaju saznati. Na primjer da li je trenutna irina mrenog pojasa uzrokovana internim problemom (postoji previe zahtjeva, a premalo resursa koji se nude) koje cloud sustav ne moe sam rijeiti. Druga mogunost je vanjski faktor, npr. DDoS (Distributed Denial of Service) napad na koji se ne moe direktno utjecati. Stoga, umjesto kontradiktornih, vie 42

dolazi do pojave nepotpunih informacija. Sa uobiajenom logikom je usko povezana paradigma programiranja skupa odgovora (answer set programming) koja je odabrana za implementaciju ove metode. Paradigma i DLV programski jezik su opisani kasnije u poglavlju. 5.2.2.4 Implementacija Prije istraivanja tehnologija i same implementacije metode uobiajene logike potrebno je ustanoviti temeljne pretpostavke o cloud sustavu (FoSII) i njegovom autonomnom upravljanju resursima i SLA ugovorima. Pretpostavke su slijedee: 1. Svaka fizika maina sadri slijedee resurse: a. CPU jezgre b. CPU brzina c. memorija d. prostor za pohranu podataka e. irina dolaznog/odlaznog mrenog pojasa 2. Svaka virtualna maina sadri slijedee resurse: a. CPU jezgre b. iskoritenost CPU-a fizike maine c. memorija d. prostor za pohranu podataka e. irina dolaznog/odlaznog mrenog pojasa 3. Jedna virtualna maina je distribuirana na tono jednu fiziku mainu. Jedna VM ne moe biti distribuirana na vie fizikih maina u isto vrijeme. Jedna fizika maina moe biti domain za vie VM. 4. Fizike maine mogu biti u tri razliita stanja: upaljene, ugaene, u stanju spavanja. 43

5. CPU brzina fizikih maina se moe dinamiki prilagoavati. 6. Virtualne maine mogu biti u tri razliita stanja: upaljene, ugaene, u stanju spavanja. 7. Virtualne maine se mogu stvarati, migrirati i unititi (brisati). 8. Jedna aplikacija je distribuirana na tono jednu VM. Jedna virtualna maina moe sadrati vie aplikacija. 9. Virtualne maine mogu biti u stanju spavanja samo ako se na njima ne izvrava ni jedna aplikacija. 10. Mogue je mjeriti resurse koritene od strane svake fizike i virtualne maine. 11. Za svaku aplikaciju je mogue mjeriti: a. CPU iskoritenost virtualne maine b. memoriju c. prostor za pohranu podataka d. irinu dolaznog/odlaznog mrenog pojasa 12. Mogue je dinamiki podeavati resurse svake virtualne maine. Gore navedene pretpostavke su podlone stalnim izmjenama i modifikacijama. Neke od pretpostavki ne odgovaraju realnom stanju stvari na distribuiranim sustavima, ali su postavljene radi lake poetne implementacije, koja bi se kasnije modificirala u skladu sa kompleksnijim stanjima aplikacija i cloud sustava. Postoje tri sustava koja implementiraju uobiajenu logiku: DeReS Xray GADeL

44

Meutim, sva tri sustava su se pokazala kao dosta neefikasna, te neki od njih ve neko vrijeme nisu pod aktivnim razvojem. Stoga je izbran pristup prevoenja pravila uobiajene logike u probleme deklarativne logike pomou semantike skupa odgovora. Programiranje skupa odgovora (answer set programming [ASP]) je oblik deklarativnog programiranja orijentiranog prema tekim (primarno NP-tekim) problemima pretraivanja. Temelji se na stabilnom modelu (skup odgovora) semantike logikog programiranja. U ASP-u se problemi pretraivanja reduciraju na stabilne raunalne modele. Rjeavai skupa odgovora (programi za generiranje stabilnih modela) se koriste za izvravanje pretraivanja. Raunski proces koriten u dizajnu brojnih rjeavaa skupa odgovora je poboljanje DPLL (DavisPutnam-Logemann-Loveland) algoritma i u principu uvijek zavrava sa izraunom (za razliku od evaluacije upita u Prologu koja moe voditi do beskonane petlje). Ukratko ASP ukljuuje sve aplikacije od skupova odgovora do prikazivanja znanja, te koristi evaluaciju upita u stilu Prologa za rjeavanje problema koji nastaju u ovim aplikacijama. Lparse je naziv programa koji je originalno stvoren kao front-end za rjeava skupa odgovora smodels, te se danas na isti nain koristi u mnogim drugim rjeavaima (assat, clasp, cmodels, gNt, nomore++ i pbmodels). Za implementaciju metode uobiajene logike je izabran DLV u kojem je sintaksa ASP programa razliita od Lparse sintakse. DLV je sustav baze za zakljuivanje temeljen na disjunktivnom logikom programiranju. Na DLV se moe gledati kao na sustav logikog programiranja i kao na sustav baze podataka za zakljuivanje. Zbog toga se ulaz u program dijeli na dva dijela: 1. Extensional database (EDB) koja predstavlja skup injenica 2. Intensional database (IDB) koja se koristi za zakljuivanje. DLV omoguava stvaranje EDB-a specificiranjem injenica u odvojenoj datoteci. Meutim jasno je da je ovakav pristup nepraktian i neefikasan kod programa sa veim brojem injenica. U svrhu implementacije metode uobiajene logike je izabrana PostgreSQL baza podataka otvorenog koda za skladitenje injenica. Naime, DLV omoguava spajanje na bilo koju relacijsku bazu koja podrava ODBC suelje. ODBC (Open Database Connectivity) nudi standardno softversko suelje za pristup sustavima za upravljanje bazama podataka. 45

Pri implementaciji metode je najprije potrebno napuniti EDB svim potrebnim injenicama poput SLA parametara, informacijama sa mjerenja resursa i sl. Ova baza slui samo kao ulaz. Dalje je potrebno definirati znanje (pravila) koje bi koristilo injenice iz EDB baze za donoenje zakljuaka. Znanje moe ovisiti o EDB bazi, moe predstavljati neovisno i neodreeno znanje ili oboje navedeno. Dio koji donosi zakljuke iz injenica se naziva IDB ili najee samo program. Iako DLV, odnosno programska paradigma skupa odgovora, nudi mogunost iskazivanja pravila uobiajene logike, sa sobom nosi i brojne probleme. Potrebno je osmisliti i organizirati sve mogue injenice koje su vezane za cloud sustav i koje utjeu na njegov rad i na samo donoenje zakljuaka pri regulaciji SLA ugovora. Izostavljanje najmanjeg detalja bi moglo dovesti do donoenja krivih odluka ili potpunog izostanka zakljuka u nekim situacijama, to na posljetku dovodi do krenja odreenih SLA ugovora. 5.2.3 Situation calculus Situation calculus opisuje svijet koji se promatra u stanjima (funkcije) i situacijama. Funkcije su logike formule prvog reda koje mogu biti istinite ili lane na temelju situacije u kojoj se promatraju. Same situacije su konani niz djelovanja. Situacija prije i jednog djelovanja poetna toka sustava se naziva poetna situacija. Stanje situacije s je skup svih funkcija koje su valjane za s. Predefinirana djelovanja mogu unaprijediti situacije u nove u svrhu postizanja unaprijed postavljenog cilja pomou manipuliranja funkcija u njihovim domenama. Za svijet od tri cigle koje se mogu sloiti jedna na drugu, leei na stolu, prilino je jednostavno pronai funkcije: cigla moe i ne mora biti na stolu cigla moe i ne mora na sebi imati drugu ciglu cigla x moe i ne mora leati na cigli y.

Mogua su dva djelovanja: stavi ciglu x na ciglu y skini ciglu y, npr. stavi ciglu y na stol.

46

Cilj bi mogao biti postojanje jednog stoga sa sve tri cigle sloene po odreenom redoslijedu sa poetnom situacijom gdje su cigle sloene u obrnutom redoslijedu od ciljanog. U svakom stanju situacije istinite su razliite funkcije, te stavljanje i skidanje cigli generira novu situaciju. 5.2.3.1 Situation calculus i SLA Mapiranje ove analogije na cloud raunarstvo nije jednostavno. to se tie funkcija u cloudu je potrebno uzeti u obzir trenutne vrijednosti svakog parametra, te da li je odgovarajui SLO ispunjen ili ne. Nadalje sva stanja samog cloud sustava se moraju, takoer, modelirati kao funkcije: broj aktivnih virtualnih maina, broj dostupnih fizikih maina itd. Funkcije za odreenu aplikaciju bi mogle biti predikat ima_vrijednost(SLAParametar p, Vrijednost v) gdje je to znai da SLAParametar p ima vrijednost v u trenutnoj situaciji i u odreenoj situaciji. ispunjava(SLO s). To dalje znai da aplikacija ispunjava odreeni SLO s. Predikat ima_vrijednost(SLAparametar1, x) je valjan samo za jedan Mogua djelovanja su prikazana u primjeru koritenja ranije uradu. Budui da se cloud uvijek promatra kao cjelina sa svim stanjima, moe biti jako komplicirano izvesti tono jedno djelovanje koje moe dovesti do napretka pri ostvarenju cilja. Mogue rjeenje je promatranje aplikacija izolirano jedne od druge, te postojanje sveukupnog pogleda koji u obzir uzima neke informacije vie razine poput ispunjavaSLA(Aplikacija app). Ovo pravilo bi znailo da aplikacija ispunjava sve svoje trenutne SLO ciljeve. Izvodljiv nain definiranja ciljeva bi mogao biti definiranje funkcije korisnosti koja prikazuje korisnost usluge koja ispunjava svoj SLA ugovor. Parametri ove funkcije mogu biti vanost korisnika i kazna koju je potrebno platiti pri krenju svakog SLO cilja. Sustav tada pokuava pronai djelovanje koje bi maksimiziralo korisnost. Ako se u obzir uzme cloud sustav koji odrava 100 aplikacija od kojih svaka ima pet SLA parametra. Ovo vodi prema x), ( ) razliitih funkcija itd. za poput svaku

ima_vrijednost(SLAParametar1, pretraivanja moguih djelovanja.

ima_vrijednost(SLAParametar2,y)

aplikaciju. Stoga su glavne prepreke u ovom pristupu velik broj funkcija i neizmjeran prostor

47

5.2.4 Case-based reasoning (rasuivanje temeljeno na sluajevima) Rasuivanje temeljeno na sluajevima je proces rjeavanja problema na temelj u prethodnih iskustava [15]. Detaljnije, ova metoda pokuava rijeiti sluaj (formatirani primjer) pomou pretraivanja slinih sluajeva iz prolosti. Rjeenja pronaenih slinih sluajeva se koriste za rjeavanje trenutnog sluaja. Openito se CBR ciklus sastoji od slijedeih faza (pod pretpostavkom da je primljen novi sluaj): 1. Pronai i uitati sluaj ili sluajeve sline trenutnom. 2. Iskoristiti informacije i znanje iz slinih sluajeva u rjeavanju problema. 3. Preispitati i po potrebi preraditi predloeno rjeenje. 4. Zadrati dijelove novog iskustva koji bi mogli biti korisni za budua rjeavanja problema. U koraku 4 se novi sluaj i pronaeno rjeenje zapisuju u bazu znanja. U slijedeem poglavlju je prikazan nain koritenja ove metode u svrhe upravljanja SLA ugovorima na polju cloud raunarstva. 5.2.4.1 Rasuivanje temeljeno na sluajevima i SLA U ovom poglavlju se prikazuje osnovni CBR model koji se koristi za upravljanje SLA ugovorima i neke njegove varijacije.

Slika 5-2 Proces rasuivanja temeljenog na sluajevima [8] 48

Kao to je vidljivo na dijagramu (Slika 5-2), ideja je skladitenje pravila koja aktiviraju CBR sustav kada se za odreeni SLA parametar dosegne vrijednost granice prijetnje u bazu podataka 1. Mjerenja se u obliku novog sluaja alju CBR sustavu (uokvireni dijelovi na slici 5-2) od strane komponente za mjerenje. Tada CBR pripremljen sa poetnim suvislim sluajevima zapisanim u bazi podataka 2 bira skup sluajeva koji su najsliniji novom, razliitim tehnikama koje su opisane kasnije u radnji. Iz ovih sluajeva se bira onaj sa najveom korisnou. Dalje se izvrava djelovanje koje je bilo izvreno prije za izabrani, najsliniji sluaj. Konano se nekoliko vremenskih intervala kasnije mjere rezultati djelovanja, usporeuju se sa poetnim sluajem, te se zajedno sa izraunatim korisnostima zapisuju kao novi sluaj u CBR. Postoje slijedei osnovni procesi (Slika 5-2): stiu nova mjerenja (Measurements kvadrat), provjera da li je dosegnuta granica prijetnje za neke parametre (Rules to engage CBR kvadrat), ako je izaberi skup najslinijih sluajeva iz CBR sustava, te iz njih izaberi sluaj sa najveom korisnou (Case Based Reasoning kvadrat), izvri djelovanje izabranog sluaja (Trigger 1 action kvadrat), mjerenjem rezultata izraunaj korisnost izvrenog djelovanja (Measure results kvadrat), zapii sluaj u CBR (Feedback kvadrat).

Izvravanjem gore navedenih procesa je mogue konstantno uiti nove sluajeve i evaluirati korisnost izvrenih djelovanja. Mjerenjem korisnosti u vie vremenskih intervala, CBR takoer moe uiti da li je djelovanje izvreno prekasno (kada se korisnosti slijedei vremenske intervale poboljavaju, ali poboljanje doe prekasno da bi se sprijeilo krenje SLA ugovora) ili ak nepotrebno. Stoga se i granice prijetnje koje pokaz uju kada pokrenuti CBR mehanizam mogu konstantno poboljavati.

49

Daljnja razmiljanja na temelju osnovnog koncepta vode ka slijedeim varijacijama [8]: 1. Umjesto koritenja pravila sa granicama prijetnje, CBR konstantno prima nove sluajeve od komponente za mjerenje. Dalje zakljuuje kada izvriti neko djelovanje, a kada ne. Na ovaj nain je mogue izbaciti granice prijetnje, pogotovo u ranim fazama kada sustav jo nema povijesna mjerenja. 2. Kao to je prikazano na slici 5-3, status sustava se dijeli na: a. runu fazu gdje se sluajevi stvaraju i prilagoavaju runo, b. aktivnu CBR fazu, c. pasivnu fazu temeljenu na sluajevima u kojoj se neto radi samo u sluaju kad se dosegne granica prijetnje. U fazi c se kao i u fazi b takoer izraunavaju korisnosti djelovanja. U sluaju da korisnosti padnu prenisko, ovisno o ozbiljnosti se ili ponovno pokrene faza b za uenje novih sluajeva ili se ak ide nazad u runu fazu (faza a). Kada se korisnosti poboljavaju, ide se u pasivnu fazu (faza c). 3. Za jednostavne parametre postoje jednostavne granice prijetnje i djelovanja koja koriste pravila umjesto CBR sustava. Ovo omoguava oslobaanje raunalnih resursa.

Slika 5-3 Aktivne i pasivne faze CBR upravljanja [8]

50

5.2.4.2 Implementacija U ovom poglavlju su opisani detalji implementacije CBR i metoda koritenih za uenje i reagiranje, kao i upotrjebljenih mjerenja korisnost [8]. Implementacija slijedi varijaciju a) iz prethodnog odlomka. Implementacija je izvrena u Java programskom jeziku, te je temeljena na FreeCBR-u [16]. Kao to je vidljivo na slici 5-4 potpuni sluaj se sastoji od: identifikacijskog broja aplikacije (redak 2, Slika 5-4), poetnog sluaja (mjerenja dobivena od komponente za mjerenje) koji se sastoji od SLO vrijednosti aplikacije i openitih cloud informacija poput broja aktivnih virtualnih maina (redci 3-10, Slika 5-4), izvrene akcije (redak 11, Slika 5-4), rezultirajueg sluaja izmjerenog nekoliko trenutaka kasnije (redci 12-19, Slika 5-4), rezultirajue korisnosti (redak 20, Slika 5-4).
1. ( 2. (SLA, 1), 3. ( 4. ((Incoming Bandwidth, 12.0), 5. (Outgoing Bandwidth, 20.0), 6. (Storage, 1200), 7. (Availability, 99.5), 8. (Running on PMs, 1)), 9. (Physical Machines, 20) 10. ), 11. "Increase Incoming Bandwidth share by 5%", 12. ( 13. ((Incoming Bandwidth, 12.6), 14. (Outgoing Bandwidth, 20.1), 15. (Storage, 1198), 16. (Availability, 99.5), 17. (Running on PMs, 1)), 18. (Physical Machines, 20) 19. ), 20. 0.002 21. )

Slika 5-4 Primjer CBR sluaja [8]

51

Da bi se evaluirala stvarna korisnost odreenog djelovanja koje je pomoglo u nekom sluaju, usporeuje se korisnost poetnog sluaja sa korisnosti rezultirajueg sluaja. Neka su stvarne vrijednosti nekog parametra izmjerenog u poetnom i rezultirajuem sluaju i neka je korisnost za parametar granica prijetnje specificiranog SLA prametra. Definira se ralativna . Ako bi trebao biti sluaj u kojem vrijedi definiramo kao (5) definiciju je

potrebno pomnoiti sa -1. Korisnost ( ) za ( )

Poveanje ili gubitak korisnosti od poetnog do rezultirajueg sluaja za parametar se moe opisati na slijedei nain: ( ) (6)

U slijedeem koraku je potrebno definirati korisnost parametara koji nisu navedeni u SLA ugovoru aplikacije, poput izvrava se na fizikim mainama xy ili globalni parametar fizike maine. S obzirom na primjer koritenja koji je prikazan ranije u radu definira se da je bolje ako se aplikacija izvrava na to manje fizikih maina, jer ovo oslobaa resurse za druge aplikacije. Isto vrijedi i za utjecaj na broj aktivnih fizikih maina. Na gaenje svake fizike maine koja nije potrebna za osiguravanje SLA ugovora se gleda kao na pozitivan utjecaj na korisnost. Stoga se, takoer, usporeuje broj aktivnih fizikih maina od rezultirajueg do poetnog sluaja pomou formule ( ) (7)

Isti princip vrijedi i za parametar izvrava se na fizikim mainama xy. Sada se konana korisnost dobiva uzimanjem prosjeka korisnosti ( ) za sve

parametre i prosjek korisnosti aktivnih fizikih maina i globalnih parametara. Openito govorei postoje sofisticiranije metode za definiranje korisnosti od ovakvog linearnog pristupa, ali je ovakav nain odabran zbog jednostavnosti. Za potpuni sluaj prikazan na slici 5-4 i SLA ugovor iz primjera koritenja (Tablica 5-1), korisnost se izraunava na slijedei nain:

52

(8)

Slinost sluajeva se odreuje pomou Euklidove udaljenosti koja za dva sluaja uzima korijen zbroja kvadrata razlika svakog parametra. Nadalje, za pronalaenje slinih sluajeva su implementirane dvije metode. Svaka metoda trai odreene sluajeve iz kojih bira onaj sa najveom korisnosti. Prva metoda koja se zove t-susjedstvo trai sluaj sa najveim postotkom podudaranja i uzima u obzir sve sluajeve koji su udaljeni za t% od sluaja sa najveim postotkom podudaranja. Druga metoda, metoda grupiranja, koristi k-means algoritam grupiranja za grupiranje sluajeva u k grupe iz kojih se dalje izabire ona koja sadri sluaj sa najveim postotkom podudaranja. Isprobava se grupiranje za nekoliko k grupa, te se naposljetku bira k koji ima najniu varijancu od svih grupa. 5.2.4.3 Evaluacija U ovom odlomku e se usporediti ishodi testnog sluaja dobiveni koritenjem CBR sustava sa djelovanjima za koje se pretpostavlja da bi izvrio administrator. Nakon punjenja baze podataka sa devet razliitih sluajeva (Tablica 5-3) testiramo ih u odnosu na SLA ugovore definirane sa prijanjim sluajem koritenja. Dodano je est novih sluajeva (Tablica 5-4), te su evaluirani rezultati. Poetni sluajevi su prikazani u tablici 5-3 u kojoj svaki stupac sadri jedan od devet sluajeva. Gornji dio tablice (vrijednosti parametara sa indeksom b) prikazuju vrijednosti koje su izmjerene prije izvravanja ikakvog djelovanja od strane sustava. Redak Djelovanje prikazuju izvreno djelovanje za odreene sluajeve, iza ega slijede izmjereni parametri nakon naznaenog djelovanja (vrijednosti parametara sa indeksom a). Redak Korisnost prikazuje korisnosti ostvarene izvoenjem navedenih djelovanja.

53

Tablica 5-3 Poetni sluajevi za CBR [8] 1 15.0 20.0 1200 99.5 1 20 Djelovanje / 2 11.0 20.0 1200 99.5 1 20 DM + 5% 15.0 20.0 1200 99.5 1 20 Korisnost 0.0 11.55 20.0 1200 99.5 1 20 0.009 3 10.5 20.0 1200 99.5 1 20 DM + 10% 11.55 20.0 1200 99.5 1 20 0.0175 4 15.0 13.0 1200 99.5 1 20 OM + 5% 15.0 13.65 1200 99.5 1 20 0.009 5 15.0 12.5 1200 99.5 1 20 OM + 10% 15.0 13.75 1200 99.5 1 20 0.017 6 15.0 20.0 1050 99.5 1 20 PP + 5% 15.0 20.0 1103 99.5 1 20 0.009 7 15.0 20.0 1000 99.5 1 20 PP + 10% 15.0 20.0 1100 99.5 1 20 0.016 8 15.0 20.0 1000 99.45 1 20 M+ 5% 15.0 20.0 1200 99.5 1 20 9 15.0 20.0 1200 99.4 1 20 M+ 10% 15.0 20.0 1200 99.5 1 20

est testnih sluajeva koji su zapisani u bazu znanja se prikazani u tablici 5-4. Stupci, ponovno, sadre sluajeve od 1-6, a redci prikazuju parametre na poetku CBR ciklusa.

54

Tablica 5-4 Testni sluajevi za CBR [8] 1 DM OM PP Du RPM FM 15.0 20.0 1200 99.5 1 20 2 11.0 20.0 1200 99.5 1 20 3 10.5 20.0 1200 99.5 1 20 4 15.0 13.0 1200 99.5 1 20 5 20.0 25.0 1250 99.6 1 20 6 10.0 18.0 1450 99.5 1 20

Rezultati, npr. koje djelovanje je izvreno, se mogu vidjeti u tablicama 5-5 i 5-6 za metodu susjedstva i grupiranja. U tablici 5-5 stupac Oekivano djelovanje prikazuje oekivano djelovanje za testni sluaj (isti stupac vrijedi i za tablicu 5-6 i u njoj nije ponovljen). Stupci Preporuena djelovanja u tablicama 5-5 i 5-6 definiraju koje je djelovanje zapravo preporueno od strane CBR mehanizma. Stupac Varijanca u tablici 5-5 prikazuje kako su grupe kompaktne. Niska varijanca oznaava visoku koherentnost (toke jedne grupe imaju male meusobne udaljenosti), dok visoka varijanca oznaava suprotno. U tablici 5-6 gdje se prikazuju rezultati za t=3% i t=5% se dodatno prikazuje broj sluajeva u t-susjedstvu sluaja sa najveim postotkom podudaranja. Ovo prikazuje koliko je velika bila skupina sluajeva za odabir sluaja sa najveom korisnosti. to ima vie sluajeva, vea je ansa izbora sluaja sa veom korisnosti, ali je u isto vrijeme manja slinost sa originalnim sluajem.

55

Tablica 5-5 Rezultati evaluacije pri koritenju algoritma grupiranja [8] Sluaj 1 2 3 4 5 6 Oekivano djelovanjem DM + 5% OM + 5% PP + 5% PP + 10% / DM + 10% Preporueno djelovanje DM + 10% OM + 10% PP + 10% PP + 10% PP + 10% DM + 10% Varijanca 23 18 208 14 96 40

Na temelju evaluacije se dolazi do zakljuka da su djelovanja za oba algoritma gotovo jednaka i slina oekivanim. Jedino je intenzitet djelovanja uvijek vei od oekivanog, jer se tako dobiva vea vrijednost korisnosti. Ovo bi se moglo poboljati modificiranjem funkcije korisnosti na nain da doputa da umjerenija djelovanja imaju vee korisnosti. Bez obzira na to svaki put je problematini SLA parametar ispravno identificiran. Jedino je za sluaj 5 koji ima izvrsne vrijednosti SLA parametara, te ne zahtjeva izvravanje nikakvih djelovanja, svaka metoda osim metode susjedstva za t=3% preporuila izvravanje nekog djelovanja. Razlog ovome je isti kao kod izbora veeg intenziteta; izvravanje djelovanja uvijek postie veu korisnost. Stoga se vrijednost neizvravanja djelovanja, takoer, moe preferirati u definiranju korisnosti.

56

Tablica 5-6 Rezultati evaluacije pri koritenju algoritma susjedstva [8] t = 5% Sluaj Preporueno djelovanje 1 2 3 4 5 6 DM + 10% OD + 10% PP + 10% PP + 10% M + 5% DM + 10% Broj sluajeva u tsusjedstvu 2 4 2 3 2 8 Preporueno djelovanje DM + 10% OM + 10% PP + 10% PP + 10% / DM + 10% t = 3% Broj sluajeva u tsusjedstvu 2 4 2 2 1 5

57

ZAKLJUAK

U ovom radu je dan kratki osvrt na cloud sustav arhitekturno i infrastrukturno. Glavni problemi koji se trenutno pokuavaju rijeiti na ovom podruju su osiguranje kvalitete usluge koju korisnik zahtijeva. Ovo se nastoji rijeiti pomou SLA ugovora, koji se ve due vrijeme koriste na podruju IT-a, ali i ire. Meutim, upravljanje SLA ugovorima u kompleksnom okruenju poput cloud sustava donosi veliki broj novih problema i prepreka. Jedan od veih problema je veliki broj SLA parametara vezanih za raunalne resurse i stanja sustava sa kojima se mora upravljati ne samo dinamiki, ve i autonomno. Za rjeavanje ovakvih problema se koriste brojne discipline poput upravljanja znanjem i slinih grana iz polja umjetne inteligencije. Upravljanje znanjem sa sobom automatski vue i opsene, kompleksne baze podataka (znanja), koje se koriste za zapisivanje i pretraivanje znanja koje slui za donoenje zakljuaka kod upravljanja resursima. U ovom radu je opisano nekoliko metoda upravljanja znanjem za koje se smatra da su pogodne za koritenje u samo-prilagodljivim cloud sustavima. Opisane su metode rule based system (baze pravila), default logics (uobiajena logika), situation calculus i case based reasoning (rasuivanje temeljeno na sluajevima). Za metodu uobiajene logike je prikazano istraivanje mogunosti i tehnologija za implementaciju. Dan je osvrt i opis izabranih tehnologija, te su prikazane dobre i loe strane odabrane tehnologije. Nadalje je prikazana implementacija rasuivanja temeljenog na sluajevima i evaluacija dobivenih rezultata. U implementaciji se metoda koristila za interpretaciju izmjerenih vrijednosti sa ciljem sprjeavanja krenja SLA ugovora. U sklopu ove metode je, takoer, implementirano autonomno rekonfiguriranje granica prijetnji. Osnovni problem pri implementaciji default logics metode je pravilno definiranje svih moguih pravila koja moraju pokrivati sve resurse i stanja cloud sustava. Potrebno je osmisliti i organizirati sve mogue injenice koje su vezane za cloud sustav i koje utjeu na njegov rad i na samo donoenje zakljuaka pri regulaciji SLA ugovora. Izostavljanje najmanjeg detalja bi moglo dovesti do donoenja krivih odluka ili potpunog izostanka zakljuka u nekim situacijama, to naposljetku dovodi do krenja samih SLA ugovora. Bez same evaluacije i rezultata testova je teko donijeti realan zakljuak, ali se da pretpostaviti da je za upravljanje SLA ugovorima u samoprilagodljivim cloud sustavima najbolji izbor metoda rasuivanja temeljena na sluajevima, jer ona omoguava zakljuivanje 58

i donoenje odluka na temelju prijanjih iskustva, dok uobiajena logika nudi, takorei, brute force rjeenje problema.

59

PRILOZI

7.1 Kazalo slika i tablica

7.1.1 Kazalo slika Slika 3-1 Primjer distribuiranja aplikacije na dvoslojni Web server arhitekturni uzorak ........ 10 Slika 3-2 Javni cloud sa udaljenih lokacija prua usluge viestrukim korisnicima ................. 13 Slika 3-3 Primjer privatnog clouda koji se nalazi u podatkovnom centru tvrtke ..................... 14 Slika 3-4 Hibridni cloud kombinira modele javnog i privatnog clouda ................................... 15 Slika 3-5 Cloud raunarstvo predstavlja koritenje IT infrastrukture kao usluge (od hardvera do API-ja) ................................................................................................................................. 16 Slika 5-1 FoSII infrastruktura [8] ............................................................................................. 34 Slika 5-2 Proces rasuivanja temeljenog na sluajevima [8] ................................................... 48 Slika 5-3 Aktivne i pasivne faze CBR upravljanja [8] ............................................................. 50 Slika 5-4 Primjer CBR sluaja [8]............................................................................................ 51

7.1.2 Kazalo tablica Tablica 5-1 Primjer SLA ugovora [8] ...................................................................................... 36 Tablica 5-2 Primjer stanja sustava [8] ...................................................................................... 37 Tablica 5-3 Poetni sluajevi za CBR [8] ................................................................................ 54 Tablica 5-4 Testni sluajevi za CBR [8] .................................................................................. 55 Tablica 5-5 Rezultati evaluacije pri koritenju algoritma grupiranja [8] ................................. 56 Tablica 5-6 Rezultati evaluacije pri koritenju algoritma susjedstva [8] ................................. 57

7.2 Popis oznaka i kratica

DM irina pojasa dolazne mree OM irina pojasa odlazne mree PP prostor za pohranu Du dostupnost usluge 60

FM fizika maina VM virtualna maina IFM broj fizikih maina na kojima se aplikacija izvrava M memorija SLA Service Level Agreement (ugovor na razini usluge) SLO Service Level Objective (cilj na razini usluge) CBR Case Based Reasoning (rasuivanje temeljeno na sluajevima)

61

LITERATURA

[1]

TechRepublic; executives

Understanding decisions

Cloud on

Computing: computing

white s

paper

for

making

resources,

interneta:

http://whitepapers.techrepublic.com.com/abstract.aspx?docid=1188509, zadnji pristup: 2010-06-03 [2] Grossman, R. (2009). The case for Cloud computing. ITPro, March/April 2009, (2327), 1520-9202/09 [3] Sun microsystems; Introduction to Cloud computing architecture; White paper, 1st Edition, s interneta: https://www.sun.com/offers/details/CloudComputing.xml, zadnji pristup: 2010-06-10 [4] Buyya, R.; Shin Yeo, C.; Venugopal, S.; Broberg, J. & Brandic, I. (2009). Cloud computing and emerging IT platforms: Vision, hype and reality for delivering computing as the 5th utility, Proceedings of Future generation computer systems, Volume 25, (2009), (599-616), 0167-739X [5] Motahari-Nezhad, H.; Stephenson, B. & Singhal, S. (2009); Outsourcing business to Cloud computing services: Opportunities and challenges, s interneta:

http://www.hpl.hp.com/techreports/2009/HPL-2009-23.html, zadnji pristup: 2010-07-02 [6] Botteri, P.; Cowan, D.; Deeter, B.; Fisher, A.; Garg, D.; Goodman, B.; Levine, J.; Messiana, G.; Sarin, A. & Tavel, S. (2010). Bessemer's top 10 laws of Cloud computing and SaaS; Bessemer venture partners, s interenta: http://www.bvp.com/cloud, zadnji pristup: 2010-04-10 [7] www.wikipedia.org; Knowledge management, s intereneta:

http://en.wikipedia.org/wiki/Knowledge_management, zadnji pristup: 2010-04-17 [8] Maurer, M.; Brandic, I.; Emeakaroha, V. & Dustdar, S. (2010). Towards Knowledge management in self-adaptable Clouds, Proccedings of 6th World Congress on Services, (527-534), 978-0-7695-4129-7, Miami, Florida, Srpanj 2010.

62

[9]

(FOSII)

Foundations

of

self-governing

ICT

Infractures,

interneta:

http://www.infosys.tuwien.ac.at/linksites/FOSII, zadnji pristup: 2010-07-18 [10] www.it-tude.com; SLA monitoring and evaluation, s interneta: http://www.ittude.com/slamonitoring-evaluation.html, zadnji pristup:2010-08.05 [11] What is a rule-based system?, s interneta: http://www.j-paine.org/students/lectures/lect3/node5.html, zdanji pristup: 2010-08-15 [12] Drools, s interenta: http://jboss.org/drools, zadnji pristup: 2010-08-15 [13] Antoniou, G. (1999). A tutorial on default logics, ACM Computing Surveys, Volume 31, Issue 4, (Prosinac 1999), (337-359), 0360-0300 [14] Levesque, H.; Pirri, F. & Reiter, R. (1998). Foundations for the situation calculus. Electronic Transactions on Artificial Intelligence, Volume 2, Issue 3-4, (159-178), 1401-9841 [15] Aamodt, A. & Plaza, E. (1994). Case-based reasoning: Foundational issues, methodological variations, and system approaches. AI Communications, Volume 7, Issue 1, (Oujak 1994), (39-59), 0921-7126 [16] FreeCBR, s intereneta: http://freecbr.sourceforge.net, zadnji pristup: 2010-26-06 [17] Stipaniev, D. (2009). Umjetna inteligencija, materijali s predavanja, Sveuilite u Splitu, FESB, Split

63