SVEUČILIŠTE U SPLITU

FAKULTET ELEKTROTEHNIKE, STROJARSTVA I BRODOGRADNJE

DIPLOMSKI RAD

UPRAVLJANJE ZNANJEM U SAMOPRILAGODLJIVIM CLOUD

SUSTAVIMA

Mario Volf

Split, rujan 2010.

S V E U Č I L I Š T E U S P L I T U

FAKULTET ELEKTROTEHNIKE, STROJARSTVA I

BRODOGRADNJE

Diplomski studij: Računarstvo

Smjer/Usmjerenje:

Oznaka programa: 250

Akademska godina: 2009/10

Ime i prezime: MARIO VOLF

Broj indeksa: 801-2008

ZADATAK DIPLOMSKOG RADA

Naslov: UPRAVLJANJE ZNANJEM U SAMOPRILAGODLJIVIM CLOUD

SUSTAVIMA

Zadatak: U radnji je potrebno opisati trendove u računarstvu koji omogućuju korisniku

smanjenje administriranja infrastrukture. Analizirati prednosti cloud računarstva.

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 istraţivanja vezane za implementaciju

metode uobičajene logike. Prikazati koncept i implementaciju za realizaciju baze

znanja korištenjem metode rasuĎivanja temeljenog na slučajevima (case based

reasoning).

Prijava rada: 25.03.2010.

Rok za predaju rada: 15.10.2010.

Rad predan:

Predsjednik

Odbora za diplomski rad: Mentor: Komentor:

Dr. sc. Sven Gotovac, red. prof. Dr. sc. Stipo Čelar, doc. 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

1

SADRŢAJ

1 SAŢETAK I KLJUČNE RIJEČI ........................................................................................ 3

2 UVOD ................................................................................................................................. 4

3 CLOUD RAČUNARSTVO I SERVICE LEVEL AGREEMENT (SLA) ......................... 6

3.1 Izgradnja na postojećim trendovima............................................................................ 6 3.1.1 Virtualne mašine kao standardni objekti za distribuiranje ................................... 7 3.1.2 On-demand, self-service, pay-by-use model ........................................................ 7 3.1.3 Dostavljanje usluga preko mreţe ....................................................................... 11

3.1.4 Uloga softvera otvorenog koda .......................................................................... 12 3.2 Infrastrukturni modeli cloud računarstva .................................................................. 12

3.2.1 Javni, privatni i hibridni cloud ........................................................................... 12 3.2.2 Arhitekturni slojevi cloud računarstva ............................................................... 16 3.2.3 Sučelja za programiranje cloud aplikacije ......................................................... 18

3.3 Dobrobiti cloud računarstva ...................................................................................... 18 3.3.1 Smanjenje vremena izvršavanja i odziva ........................................................... 19 3.3.2 Minimiziranje infrastrukturnog rizika ................................................................ 19

3.3.3 Manji početni troškovi ....................................................................................... 19 3.3.4 Povećani tempo inovacija ................................................................................... 20

3.4 Service Level Agreement (SLA) ............................................................................... 20

3.4.1 Uobičajene metrike ............................................................................................ 22 3.4.2 SLA u cloud računarstvu .................................................................................... 22

4 ZNANJE I UPRAVLJANJE ZNANJEM ......................................................................... 24

4.1 Prikazivanje znanja .................................................................................................... 25 4.1.1 Logičko prikazivanje znanja .............................................................................. 25

4.2 Upravljanje znanjem .................................................................................................. 27

4.2.1 Povijest ............................................................................................................... 28

4.2.2 Istraţivanja ......................................................................................................... 29 4.2.3 Značajke ............................................................................................................. 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

5 UPRAVLJANJE ZNANJEM U SAMOPRILAGODLJIVIM CLOUDIMA ................... 33

5.1 Pregled FoSSI infrastrukture ..................................................................................... 34 5.1.1 Primjer korištenja ............................................................................................... 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 (uobičajena logika) ..................................................................... 40

5.2.3 Situation calculus ............................................................................................... 46

5.2.4 Case-based reasoning (rasuĎivanje temeljeno na slučajevima) ......................... 48

6 ZAKLJUČAK ................................................................................................................... 58

7 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

2

8 LITERATURA ................................................................................................................. 62

3

1 SAŢETAK I KLJUČNE RIJEČI

Saţetak

Najnoviji trendovi u računarstvu uključuju 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) računarstvo koje je nastalo na temeljima

Grid-a, ali uključuje nove i ključne tehnologije poput virtualizacije. Najveće 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

samoupravljajuće cloud infrastrukture kako bi se postila potrebna razina flaksibilnosti. Cilja

se na autonomno upravljanje SLA ugovorima koje mora spriječiti sva eventualna kršenja

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), uobičajena logika (default logics), situation calculus i rasuđivanje temeljeno na

slučajevima (case based reasoning). Detaljnije su opisana istraživanja tehnologija i

mogućnosti za implementaciju metode uobičajene logike, te je prikazana implementacija i

evaluacija metode rasuđivanja temeljenog na slučajevima. Na kraju rada su doneseni

zaključci vezani uz gore navedene metode i očekivanja u mogućnostima daljnjeg razvoja.

Ključne riječi

Cloud, Service Level Agreement (SLA), upravljanje znanjem, autonomno računarstvo, baze

pravila (rule based system), uobičajena logika (default logics), situation calculus, rasuđivanje

temeljeno na slučajevima (case based reasoning)

4

2 UVOD

Sa znatnim napretkom u informacijskoj tehnologiji tokom zadnjih godina sve se više razvija

vizija da će računarstvo jednog dana postati peta komunalija (voda, struja, plin, telefon).

Ovakvo računarstvo bi, kao i preostale četiri komunalije, nudilo osnovni nivo usluge koji se

smatra neophodnim za svakodnevne potrebe opće zajednice. U svrhu ostvarivanja ove vizije

je razvijen veći broj računarskih paradigmi, meĎu kojima je posljednja poznata kao cloud

računarstvo koje predstavlja konvergenciju i evoluciju nekoliko koncepta (virtualizacija,

distribuirani dizajn aplikacija, Grid i poduzetno IT upravljanje).

Cloud je novonastala infrastruktura koja predstavlja nadogradnju najnovijih postignuća u

raznolikim područjima istraţivanja poput Grid računarstva, pruţanja 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 izvršavanje moraju

dodjeljivati ne samo dinamički, već i na autonoman način. 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 postići (npr. dostupnost > 98%).

MeĎutim, uslijed raznih kvarova na sustavu i promjena u uvjetima opterećenja utvrĎeni SLA

ugovori mogu biti prekršeni. Da bi se izbjeglo kršenje ugovora potrebne su fleksibilne i

prilagodljive strategije definiranja SLA ugovora. U svrhu ostvarivanja ovih strategija koriste

se mogućnosti autonomnog računarstva, upravljanja znanjem i sličnih tehnologija.

Tema ovog rada su samostalno upravljane cloud infrastrukture koje omogućavaju odreĎen

nivo fleksibilnosti i pridrţavanje korisničkim zahtjevima definiranim pomoću SLA ugovora.

Ovakve infrastrukture bi trebale automatski reagirati na promjenu komponenti, opterećenja i

okolinskih uvjeta. Ovako se minimizira potreba za interakcijama korisnika sa sustavom i

smanjuje mogućnost kršenja uspostavljenih ugovora. Da bi se ovakva infrastruktura ostvarila,

istraţuju se mogućnosti trenutno poznatih metoda za upravljanje znanjem. U ovom radu je

dan pregled cloud računarstva koji će sadrţavati najčešće korištene definicije, podjele i

mogućnosti. Nakon toga slijedi uvod u neke od metoda za upravljanje znanjem. Glavni dio

rada se odnosi na mogućnosti primjene pojedinih metoda na cloudu kako bi se ostvarilo

autonomno praćenje i upravljanje promjenama u svrhu sprječavanja kršenja SLA ugovora, te

eventualne promjene postojećih ugovora u dozvoljenim slučajevima. Bit će dan pregled

tehnologija koje su dostupne i pogodne za implementaciju metoda upravljanja znanjem na

cloud infrastrukturama.

5

Glavni doprinosi rada su: (i) osvrt i rasprava o autonomnom rješavanju problema SLA

ugovora u cloud računarstvu korištenjem 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 istraţivanja vezanih za implementaciju metode

uobičajene logike; (v) koncept i implementacija za realizaciju baze znanja korištenjem metode

rasuĎivanja temeljenog na slučajevima [8].

Rad je organiziran na slijedeći način: poglavlje 3 sadrţi općeniti prikaz i uvod u cloud

računarstvo te SLA ugovore. U poglavlju 4 je dan teorijski osvrt na znanje i upravljanje

znanjem. Poglavlje 5 obuhvaća opis metoda za upravljanje znanjem koje su odabrane za

implementaciju u samoprilagodljivim cloudima. Ovo poglavlje, takoĎer, sadrţi prikaz

istraţivanja vezanog za metodu uobičajene logike i implementaciju metode rasuĎivanja

temeljenog na slučajevima. Posljednje, šesto poglavlje sadrţi zaključke donesene tokom

istraţivanja i pisanja rada.

6

3 CLOUD RAČUNARSTVO I SERVICE LEVEL AGREEMENT (SLA)

Cloud računarstvo još uvijek nema standardnu definiciju, ali bi se moglo reći da cloud ili

klasteri distribuiranih računala nude računalne resurse i usluge na zahtjev preko mreţne

infrastrukture, najčešće Interneta, sa skalabilnosti i pouzdanosti podatkovnog centra. Cloud je

novi trend u računarstvu gdje su dostupni resursi izloţeni kao usluga.

Preciznija definicija bi bila:

cloud je vrsta paralelnog i distribuiranog sustava koji se sastoji od meĎusobno

povezanih i virtualiziranih računala koja se dinamički pruţaju i predstavljaju kao

jedan ili više objedinjenih računalnih resursa zasnovanih na SLA ugovorima koji se

utvrĎuju dogovorima izmeĎu pruţatelja i korisnika usluga. [4]

Površnim promatranjem se čini da je cloud kombinacija klastera i Grid-a. MeĎutim, ovo bi

bila pogrešna pretpostavka. cloud predstavlja novu generaciju podatkovnih centara sa

virtualiziranim čvorovima koji se dinamički pruţaju kao personalizirani skup resursa u svrhu

ispunjavanja specifičnih SLA ugovora. Generalno se moţe reći da je cloud nova generacija

mreţnog računarstva. Ukratko rečeno, ono što razlikuje cloud od prijašnjih modela je

korištenje informacijske tehnologije kao usluge preko mreţe. Usluge koje se pruţaju su

striktno definirane, imaju API te su dostupne preko mreţe. Ovakva definicija obuhvaća

korištenje procesorskih i resursa za pohranu podataka kao usluge.

3.1 Izgradnja na postojećim trendovima

Cloud računarstvo nastavlja razvoj uspostavljenih trendova koji smanjuju troškove

dostavljanja, dok povećavaju brzinu i agilnost dostavljanja usluga. Uvelike smanjuje vrijeme

potrebno od osmišljavanja aplikacijske arhitekture do same instalacije. Cloud obuhvaća

virtualizaciju, dostavljanje usluge na zahtjev, dostavljanje usluga putem Interneta i softver

otvorenog koda. Iz jedne perspektive cloud ne nudi ništa novo jer koristi pristupe, koncepte i

najbolje prakse koje su već odavno uspostavljene. Iz druge perspektive nudi mnogo novog jer

mijenja način na koji se osmišljavaju, razvijaju, dostavljaju, skaliraju, aţuriraju, odrţavaju i

plaćaju aplikacije te infrastruktura na kojoj se izvršavaju.

7

3.1.1 Virtualne mašine kao standardni objekti za distribuiranje

Tokom nekoliko proteklih godina virtualne mašine su postale standardni objekti za

distribuiranje. Virtualizacija povećava fleksibilnost jer apstrahira hardver do točke u kojoj se

aplikacije mogu distribuirati bez vezivanja za specifični fizički server. Virtualizacija

omogućava dinamičke podatkovne centre gdje serveri pruţaju udruţene resurse koji se

iskorištavaju po potrebi, te gdje se veza izmeĎu aplikacija, prostora za pohranu i mreţnih

resursa dinamički mijenja u svrhu ostvarivanja potrebnog radnog opterećenja i poslovnih

potreba. Budući da je distribuiranje aplikacija odvojeno od distribuiranja servera, aplikacije se

mogu rapidno distribuirati i skalirati, bez potreba za prethodnim pribavljanjem fizičkih

servera.

Virtualne mašine su postale prevladavajući oblik apstrakcije (i jedinice za distribuiranje) jer

su najviše odgovarale i pruţateljima i razvijateljima usluga. Korištenje virtualnih mašina kao

objekata za distribuiranje je dostatno u 80% slučajeva, te pomaţe u zadovoljavanju potreba za

rapidnom implementacijom i skaliranjem aplikacija. Virtualni ureĎaji su virtualne mašine

koje sadrţe softver koji je dijelom ili u potpunosti konfiguriran za izvršavanje specifičnog

zadatka. Oni nadalje povećavaju sposobnost sustava za rapidnim stvaranjem i distribuiranjem

aplikacija. Kombinacija virtualnih mašina i ureĎaja kao standardnih objekata za distribuiranje

je jedno od ključnih svojstava cloud računarstva.

Cloud-ovi za procesiranje podataka se najčešće upotpunjuju sa cloudima za pohranu podataka

koji pruţaju virtualizirani prostor za pohranu podataka pomoću API-ja koji olakšava pohranu

slika virtualnih mašina, izvorišnih datoteka, podataka sa aplikacijskim stanjima i općenitih

poslovnih podataka.

3.1.2 On-demand, self-service, pay-by-use model

Cloud takoĎer proširuje postojeće trendove korištenjem on-demand, self-service i pay-by-use

modela. Sa poduzetne perspektive on-demand priroda clouda pomaţe podrţavanju aspekata

performansi i kapaciteta ciljeva na razini usluge. Samoposluţna priroda clouda omogućava

organizacijama stvaranje elastičnih okruţja koja se šire i smanjuju ovisno o radnom

opterećenju. Naposljetku, pay-by-use priroda clouda moţe poprimiti formu iznajmljivanja

opreme koja garantira minimalnu razinu usluge od strane pruţatelja usluga.

8

Virtualizacija je ključno svojstvo ovog modela. IT organizacije su odavno zaključile da

virtualizacija omogućava brzo i jednostavno stvaranje kopija postojećih okruţja (koja

ponekad uključuju višestruke virtualne mašine) u svrhu podrške testiranju, razvijanju i

izvršavanju. Trošak ovakvih okruţja je minimalan jer ona mogu koegzistirati na istim

serverima sa produkcijskim okruţjima.

Na isti način, nove aplikacije mogu biti razvijane i distribuirane na novim virtualnim

mašinama na postojećim serverima, otvorene za korištenje na Internetu i po potrebama

skalirane. Ovaj model "laganog" distribuiranja je već doveo do "Darwinističkog" pristupa

poslovnog razvoja u kojem se objavljuju beta verzije softvera, te trţište odreĎuje koje se

aplikacije trebaju skalirati i dalje razvijati.

Cloud računarstvo nadograĎuje ovaj trend pomoću automatizacije. Umjesto pregovaranja sa

IT organizacijom oko resursa na koje distribuirati aplikacije, cloud za procesiranje podataka

predstavlja samoposluţnu komponentu u kojoj kreditna kartica moţe kupiti cikluse za obradu

podataka. Web sučelje ili API se koristi za stvaranje virtualnih mašina i uspostavljanje

mreţnih odnosa meĎu njima. Umjesto uspostavljanja dugoročnog ugovora za usluge sa IT

organizacijom ili pruţateljem usluga cloudi rade po modelu plati koliko koristiš u kojem

aplikacija moţe biti aktivna za izvršavanje zadatka nekoliko minuta, sati ili dugoročno.

Cloud-ovi za procesiranje podataka su osmišljeni sa pretpostavkom da su aplikacije

privremene, a naplata je zasnovana na potrošnji resursa:

korištenju CPU sati

količini prenesenih podataka

količini pohranjenih podataka...

Mogućnost korištenja i plaćanja samo iskorištenih resursa pomiče rizik odlučivanja o

kupovini potrebne infrastrukture sa organizacije koja razvija aplikaciju na pruţatelja cloud

usluga. TakoĎer pomiče odgovornost za arhitekturne odluke sa arhitekata aplikacija na

razvijatelje.

9

3.1.2.1 Programabilna infrastruktura

Pomak arhitekturne odgovornosti ima bitne posljedice. Prije bi arhitekti aplikacija odreĎivali

kako različite komponente aplikacije raspodijeliti na niz servera, kako ih meĎusobno

povezati, osigurati i skalirati. Sada razvijatelj aplikacije moţe koristiti API pruţatelja cloud

usluga kako bi stvorio ne samo početnu kompoziciju aplikacije na virtualnim mašinama, već i

odredio skaliranje i evoluiranje aplikacije u svrhu zadovoljavanja promjena u radnom

opterećenju.

Mogućnost dinamičkog programiranja aplikacijske arhitekture daje razvijateljima aplikacija

ogromnu moć kojoj je proporcionalna količina odgovornosti. Da bi se cloud iskoristio

najefikasnije razvijatelj aplikacije mora biti i arhitekt koji mora biti u mogućnosti stvoriti

aplikaciju koja se sama kontrolira i po potrebi proširuje. Razvijatelj/arhitekt mora razumjeti

kada je odgovarajuće kreiranje nove niti, a kada nove virtualne mašine zajedno sa

arhitekturnim uzorcima za njihovo meĎusobno 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 postojećih servisa i softvera

otvorenog koda. Aplikacije i arhitekture koje je moguće rastaviti na module kako bi se

ostvarila najveća moguća iskoristivost standardnih komponenti će najbolje moći 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 postojećih alata koji se mogu direktno koristiti

brzo povećavaju.

10

3.1.2.3 Primjer distribuiranja Web aplikacije

Kao primjer kako kombinacija virtualizacije i samoposluţivanja olakšava distribuiranje

aplikacije u obzir će se uzeti distribuiranje dvoslojne Web aplikacije na cloud (Slika 3-1):

1. Razvijatelj moţe izabrati Web server i bazu podataka iz biblioteke unaprijed

konfiguriranih slika virtualnih mašina.

2. Razvijatelj konfigurira svaku komponentu kako bi stvorio vlastite, prilagoĎene slike.

Softver za balansiranje opterećenja bi se podesio, Web server napunio sa statičkim

sadrţajem stavljanjem podataka na cloud za pohranu podataka i baza podataka bi se

napunila dinamičkim sadrţajem za stranicu.

3. Razvijatelj vlastiti kod razlaţe u slojeve za novu arhitekturu, te osigurava da

komponente zadovoljavaju specifične aplikacijske zahtjeve.

4. Razvijatelj bira uzorak koji uzima slike za svaki sloj, te ih distribuira vodeći računa o

mreţi, sigurnosti i skalabilnosti.

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

11

5. Sigurna, visoko dostupna Web aplikacija je distribuirana i aktivna. U slučaju potrebe

za aţuriranjem aplikacije, aţuriraju se virtualne mašine, kopiraju kroz lanac

razvijanje-testiranje-korištenje, te se cijela infrastruktura ponovno distribuira. Cloud

pretpostavlja da je sve privremeno, te je ponovno distribuiranje cijele aplikacije

jednako jednostavno kao i ručno ispravljanje grupe individualnih virtualnih mašina.

U ovom primjeru apstraktna priroda slika virtualnih mašina podrţava pristup razvijanju

zasnovan na "sastavljanju" aplikacija. Podjelom problema moguće je koristiti standardni niz

komponenti kako bi se aplikacija brzo distribuirala. Sa ovakvim modelom zahtjevi u tvrtkama

se mogu brzo riješiti bez potrebe za kupovinom, instalacijom, kabliranjem i konfiguracijom

servera, skladišta podataka i mreţne infrastrukture.

3.1.3 Dostavljanje usluga preko mreţe

Cloud računarstvo proširuje postojeći trend omogućavanja dostupnosti aplikacija preko

mreţe. Gotovo je svaka ozbiljna tvrtka u svijetu prepoznala vaţnost sučelja baziranog na

Web-u za svoje aplikacije. Ovakva sučelja mogu biti javno dostupna svim korisnicima ili

predstavljati interne aplikacije koje su dostupne autoriziranim zaposlenicima, partnerima,

dobavljačima i konzultantima. Najveća vrlina dostavljanja usluga baziranom na Internetu je,

naravno, dostupnost aplikacija u bilo koje vrijeme i sa bilo kojeg mjesta.

Dok su velike tvrtke svjesne mogućnosti sigurne komunikacije korištenjem SSL (Secure

Socket Layer) enkripcije zajedno sa jakom autentikacijom, pokretačko povjerenje u cloud

okruţju zahtjeva paţljivo razmatranje razlika izmeĎu poslovnog računarstva i cloud

računarstva. Kada je propisno arhitekturno osmišljeno, dostavljanje usluga preko Interneta

nudi fleksibilnost i sigurnost dostatnu tvrtkama svih veličina.

12

3.1.4 Uloga softvera otvorenog koda

Softver otvorenog koda igra vaţnu ulogu u cloud računarstvu omogućavajući kreiranje

osnovnih softverskih elemenata (slike virtualnih mašina) iz lako dostupnih komponenti. Jedna

od najvaţnijih značajki softvera otvorenog koda je striktno korištenje sluţbenih, čvrsto

ustanovljenih svjetskih standarda. Ovo ima pojačavajući učinak:

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 omogućavaju

kreiranje, distribuiranje i dinamičko skaliranje cloud aplikacija na zahtjev. Kao

primjer se moţe uzeti Animoto aplikacija (alat za kreiranje videa iz niza slika i

glazbenih datoteka) raĎena 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

većih aplikacija generira još više komponenti otvorenog koda. Zauzvrat, ovo čini

ulogu softvera otvorenog koda još vaţnijom. Na primjer potreba za MapReduce

algoritmom koji se moţe izvršavati u cloud okruţju je bio jedan od faktora koji je

stimulirao njegov razvoj. Sada kada je alat kreiran koristi se kako bi još više podigao

nivo na kojem razvijatelji programiraju cloud aplikacije.

3.2 Infrastrukturni modeli cloud računarstva

Računalni arhitekti moraju uzeti u obzir brojna razmatranja pri premještanju 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 korištenju vlasničkih 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 najčešće "vani" na Internetu, a privatni smješteni na odreĎenoj, poznatoj lokaciji,

to ne mora nuţno biti tako.

13

Tvrtke moraju uzeti u obzir brojna razmatranja povezana sa odabranim cloud modelom za

korištenje, te mogu, takoĎer, koristiti više od jednog modela kako bi riješili odreĎene

probleme. Aplikacija koja je privremeno potrebna je najbolja za distribuiranje na javni cloud

jer pomaţe pri izbjegavanju potrebe za kupovinom dodatne opreme kako bi se riješila

privremena potreba. Sa druge strane, stalna aplikacija ili aplikacija koja ima specifične

zahtjeve na kvalitetu usluge ili lokaciju podataka je najbolji kandidat za privatni ili hibridni

cloud.

3.2.1.1 Javni cloud

Javni cloud se odrţava od strane neovisnih pruţatelja usluga, te se najčešće aplikacije od

različitih korisnika meĎusobno miješaju na cloud serverima, sustavima za pohranu podataka i

mreţi (Slika 3-2).

Slika 3-2 Javni cloud sa udaljenih lokacija pruža usluge višestrukim korisnicima

Javni cloud se najčešće nalazi na lokaciji udaljenoj od prostorija korisnika. Nudi način

reduciranja korisničkih troškova i rizika fleksibilnim i po mogućnosti privremenim

proširenjem korisničke 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 veći od

14

mogućeg privatnog clouda tvrtke. Nude mogućnost skalabilnosti na zahtjev i pomiču rizike

vezane uz infrastrukturu sa tvrtke na pruţatelja cloud usluga.

Dijelovi javnog clouda se mogu odijeliti za isključivo korištenje jednog korisnika stvarajući

virtualni privatni centar podataka. Umjesto da je virtualni privatni centar podataka ograničen

na distribuiranje slika virtualnih mašina na javni cloud, on korisnicima pruţa veći uvid u

svoju infrastrukturu. U ovakvom slučaju korisnici mogu manipulirati ne samo slikama

virtualnih mašina, već i serverima, sustavima za pohranu podataka, mreţnim ureĎajima i

mreţnom topologijom. Stvaranje virtualnog privatnog centra podataka sa svim

komponentama smještenim na istoj lokaciji pomaţe pri smanjivanju problema vezanih uz

lokalitet podataka, jer je mreţna propusnost velika i najčešće besplatna pri spajanju elemenata

unutar iste lokacije.

3.2.1.2 Privatni cloud

Privatni cloud se implementira za isključivo korištenje jednog korisnika nudeći najviši stupanj

kontrole nad podacima, sigurnosti i kvaliteti usluge (Slika 3-3). Tvrtka posjeduje

infrastrukturu i ima kontrolu nad načinom izvoĎenja aplikacija na njoj. Privatni cloud se moţe

implementirati unutar podatkovnog centra tvrtke ili na udaljenoj lokaciji.

Privatni cloud se moţe implementirati i odrţavati od strane vlastitog IT odjela unutar tvrtke ili

od strane pruţatelja cloud usluga. U drugom modelu neka cloud tvrtka moţe instalirati,

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

tvrtke

15

konfigurirati i upravljati infrastrukturom kako bi se uspostavio privatni cloud unutar

podatkovnog centra tvrtke. Ovakav model daje tvrtkama veliku količinu kontrole nad

korištenjem cloud resursa, dok se treća strana brine o stručnosti potrebnoj za uspostavljanje i

upravljanje okruţjem.

3.2.1.3 Hibridni cloud

Hibridni cloud kombinira modele javnog i privatnog clouda (Slika 3-4). Hibridni model

pomaţe pri omogućavanju sustava koji je dostupan na zahtjev i pruţen od treće strane.

Mogućnost obogaćivanja privatnog clouda sa resursima javnog se moţe koristiti kako bi se

odrţavale razine usluga u svrhu dostizanja brzih fluktuacija u radnom opterećenju. Ovakav

model se najčešće viĎa u korištenju clouda za pohranu podataka sa Web 2.0 aplikacijama.

Hibridni cloud se takoĎer moţe koristiti za manipuliranje planiranih šiljaka u radnom

opterećenju. U ovom modelu se javni cloud moţe koristiti za izvršavanje periodičkih zadataka

koji se mogu na njega jednostavno distribuirati.

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

Hibridni cloud uvodi kompleksnost odreĎivanja kako distribuirati aplikacije preko javnog i

privatnog clouda. MeĎu spornim pitanjima na koje treba odgovoriti je odnos izmeĎu resursa

16

za obradu i pohranu podataka. U slučaju kada su podaci mali hibridni cloud moţe biti puno

uspješniji nego u slučaju kada se velike količine podataka moraju slati na javni cloud za malu

količinu obrade.

3.2.2 Arhitekturni slojevi cloud računarstva

Moţe se reći da cloud računarstvo obuhvaća pruţanje usluga koje obuhvaćaju bilo koji od

tradicionalnih slojeva od hardvera do aplikacija (Slika 3-5). U praksi pruţatelji cloud usluga

teţe 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 različite slojeve prikazane na slici 3-5 sa odreĎenim preklapanjem.

Slika 3-5 Cloud računarstvo predstavlja korištenje IT infrastrukture kao usluge (od hardvera

do API-ja)

17

3.2.2.1 Softver kao usluga (SaaS)

Softver kao usluga se sastoji od potpune aplikacije koje se pruţa kao usluga na zahtjev. Jedna

instanca softvera se izvršava na cloudu i pruţa uslugu višestrukim krajnjim korisnicima.

Najpoznatiji primjer softvera kao usluge je salesforce.com, iako su brojni drugi primjeri

prisutni na trţištu, poput Google Apps koji nudi osnovne poslovne usluge.

Iako salesforce.com prethodi definiciji cloud računarstva nekoliko godina sada djeluje

iskorištavanjem svog pratioca force.com koji se moţe definirati platformom kao uslugom.

3.2.2.2 Platforma kao usluga (PaaS)

Platforma kao usluga obuhvaća sloj softvera i nudi ga kao uslugu koja se moţe koristiti za

izradu usluga višeg sloja. Postoje barem dvije perspektive na PaaS ovisno o perspektivi

proizvoĎača ili korisnika usluga:

Razvijatelj PaaS-a moţe razviti platformu integriranjem OS-a, meĎusoftvera,

aplikacijskog softvera te čak i razvojnog okruţja koje se onda pruţa korisniku kao

usluga.

Korisnik PaaS-a moţe vidjeti obuhvaćene usluge koje su prikazane preko API-ja.

Korisnik pristupa platformi preko API-ja, a platforma izvršava potrebne akcije kako bi

se odrţavala i skalirala u svrhu pruţanja odreĎene razine usluge. Virtualni ureĎaji se

mogu klasificirati kao instance PaaS-a.

PaaS moţe nuditi usluge za svaku fazu razvoja i testiranja softvera ili moţe biti specijaliziran

oko odreĎenog područja poput upravljanja sadrţajem. Komercijalni primjeri PaaS-a su

Google Apps Engine koji pruţa aplikacije na Google-ovoj infrastrukturi. Ovakve PaaS usluge

nude moćne temelje za distribuiranje aplikacija, meĎutim mogu biti ograničene

mogućnostima koje nudi pruţatelj cloud usluga.

3.2.2.3 Infrastruktura kao usluga (IaaS)

Infrastruktura kao usluga pruţa osnovne mogućnosti pohrane i obrade podataka u obliku

standardiziranih usluga preko mreţe. Serveri, sustavi pohrane podataka, prospojnici,

usmjernici i ostali sustavi se grupiraju i pruţaju u svrhu rukovanja radnim opterećenjima koja

se kreću od aplikacijskih komponenti do aplikacija visokih performansi. Komercijalni

18

primjeri IaaS-a su Joyent čiji je glavni proizvod linija virtualiziranih servera koji pruţaju

visoko dostupnu infrastrukturu na zahtjev.

3.2.3 Sučelja za programiranje cloud aplikacije

Jedna od ključnih karakteristika koja razlikuje cloud od standardnog poslovnog računarstva je

činjenica da je sama infrastruktura programabilna. Umjesto fizičkog razmještaja servera,

sustava za pohranu podataka i mreţnih resursa razvijatelji specificiraju kako su odgovarajuće

virtualne komponente konfigurirane i meĎusobno povezane. U ovom procesu se i odreĎuje

kako se slike virtualnih mašina i aplikacije pohranjuju i dohvaćaju sa clouda za pohranu

podataka. Specificira se kako i kada se komponente distribuiraju pomoću API-ja kojeg nudi

pruţatelj cloud usluga.

Analogija je način rada FTP-a: FTP serveri odrţavaju kontroliranu povezanost sa klijentom

koji je aktivan za vrijeme trajanja sesije. Kada se podaci trebaju prenijeti, koristi se

kontrolirana veza koja serveru nudi ime odredišne ili izvorišne datoteke te se koristi za

pregovaranje o izvorišnom i odredišnom portu za sami transfer. Moţe se reći da je cloud API

poput FTP kontroliranog kanala: aktivan je za vrijeme korištenja cloud sustava, te kontrolira

kako se cloud iskorištava kako bi osigurao krajnje usluge koje je razvijatelj imao u vidu.

Postoji zamka kod korištenja API-ja za definiranje kako se infrastruktura clouda iskorištava:

za razliku od FTP protokola, cloud API-jevi još nisu standardizirani te svaki pruţatelj cloud

usluga ima vlastiti API za upravljanje uslugama. Ovo stanje je svojstveno za mlade industrije

i tehnologije, kada svaki isporučitelj ima svoju vlasničku tehnologiju kojoj je jedna od svrha

zadrţavanje korisnika, jer vlasnički API-ji oteţavaju promjenu pruţatelja usluga.

3.3 Dobrobiti cloud računarstva

Da bi se cloud računarstvo najviše iskoristilo, razvijatelji moraju biti u mogućnosti razloţiti

aplikacije kako bi one mogle maksimalno iskoristiti arhitekturne i distribucijske paradigme

koje cloud podrţava. Dobrobiti distribuiranja aplikacija korištenjem clouda obuhvaćaju

smanjenje vremena izvršavanja i odziva, minimiziranje rizika pri distribuiranju fizičke

infrastrukture, smanjivanje početnih troškova i povećavanje tempa inovacija.

19

3.3.1 Smanjenje vremena izvršavanja i odziva

Za aplikacije koje koriste cloud najviše za izvršavanje serijske obrade velike količine

podataka cloud omogućava jednostavno korištenje npr. 1000 servera za završavanje zadatka u

1000 puta kraćem vremenu nego da se zadatak izvršava na jednom serveru. Za aplikacije koje

moraju imati dobro vrijeme odziva prema korisnicima vrši se podjela na module tako da se

svaki CPU intenzivan zadatak šalje "radničkim" virtualnim mašinama. Ovo pomaţe u

optimizaciji vremena odziva, te omogućava 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 fizičkih

servera. Hoće li nova aplikacija biti uspješna? Ako hoće, koliko je servera potrebno i mogu li

se distribuirati jednakom brzinom kojom će rasti radno opterećenje? Ako neće, hoće li velika

investicija na servere propasti? Ako je uspjeh aplikacije kratkotrajan hoće li IT organizacija

uloţiti u veliku količinu infrastrukture koja će većinu vremena biti neiskorištena?

Pri distribuiranju aplikacije na cloud skalabilnost i rizik kupovine previše ili premalo

infrastrukture postaje problem pruţatelja cloud usluge. U velikom broju slučajeva pruţatelj

cloud usluge posjeduje ogromnu količinu infrastrukture koja moţe podrţati rast i šiljke u

radnom opterećenju pojedinih korisnika. Drugi način na koji cloud minimizira infrastrukturne

rizike je omogućavanje surge računarstva u kojem poslovni centar podataka (moţda neki na

kojem je implementiran privatni cloud) pospješuje svoju mogućnost podrţavanja šiljaka u

opterećenju dizajnom koji mu omogućava slanje zadataka koji prekoračuju kapacitet na javni

cloud. Upravljanje ţivotnim ciklusom aplikacije je olakšano u okruţju u kojem resursi nisu

deficitarni i u kojem se resursi mogu bolje uskladiti sa trenutnim potrebama uz manje

troškove.

3.3.3 Manji početni troškovi

Postoje brojna svojstva cloud računarstva koja pomaţu pri smanjivanju troškova kod ulaska

na nova trţišta:

Budući da je infrastruktura iznajmljena, a ne kupljena, troškovi su kontrolirani i

početna investicija moţe biti jednaka nuli. Uz manje troškove kupovine vremena za

20

obradu podataka i prostora za pohranu po potrebi, velika većina pruţatelja cloud

usluga na dodatne načine pomaţe pri minimiziranju troškova.

Aplikacije se razvijaju više "sastavljanjem" umjesto programiranjem. Ovakav brzi

razvoj aplikacija je pravilo koje smanjuje vrijeme koje je potrebno da se aplikacija

pusti na trţište, te potencijalno pruţa organizacijama koje distribuiraju aplikacije na

cloud početnu prednost pred konkurencijom.

3.3.4 Povećani tempo inovacija

Cloud računarstvo moţe pomoći pri povećanju tempa inovacija. Niski početni troškovi pri

ulasku na nova trţišta pomaţu u izjednačavanju mogućnosti jer omogućavaju novim tvrtkama

distribuiranje novih proizvoda na brz i jeftin način. Ovo omogućava malim tvrtkama

efikasnije natjecanje sa tradicionalnim organizacijama čiji proces distribuiranja na poslovne

centre podataka moţe biti znatno duţi i kompliciraniji. Povećano trţišno natjecanje pomaţe

pri povećanju tempa inovacija – sa mnogo inovacija realiziranih pomoću korištenja softvera

otvorenog koda cijela industrija ima koristi od povećanog tempa inovacija koje promovira

cloud računarstvo.

3.4 Service Level Agreement (SLA)

Service level agreement (često skraćeno 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 izmeĎu

dviju stranaka, gdje je jedna korisnik, a druga pruţatelj usluga. SLA moţe predstavljati

pravno obvezujući formalni ili neformalni „ugovor“. Ugovori izmeĎu pruţatelja usluga i treće

strane se često pogrešno nazivaju SLA – budući da je razina usluge postavljena od strane

glavnog korisnika ne moţe postojati SLA sa trećom stranom.

SLA sadrţi uobičajeno razumijevanje o uslugama, prioritetima, obavezama, garancijama i

jamstvima. Svako područje opsega usluge bi trebalo imati definiranu razinu usluge. SLA

moţe specificirati razine dostupnosti, uporabivosti, performansi ili druge atribute usluge

poput naplate. Razina usluge se, takoĎer, moţe definirati kao ciljana i minimalna, što

omogućava korisnicama informiranje o očekivanjima (minimum), te pruţanje mjerljive

21

(prosječne) ciljne vrijednosti koja pokazuje razinu organizacijskih performansi. U nekim

ugovorima se dogovaraju „globe“ u slučajevima kršenja ugovora. Vaţno je napomenuti da se

ugovor odnosi na usluge koje korisnik prima, a ne na način na koji pruţatelj dostavlja usluge.

SLA ugovori se koriste od kasnih osamdesetih godina prošlog stoljeća od strane telekom

operatora kao dio ugovora sa pravnim osobama. Ova praksa se toliko raširila da je danas

uobičajeno da korisnik pruţatelju usluga šalje SLA sa potrebnim razinama usluga. U nekim

velikim tvrtkama se SLA koriste interno izmeĎu različitih odjeljenja i timova. Jedna od

dobrobiti ovakvog pristupa je poboljšavanje kvalitete usluge. SLA ugovori su zasnovani na

„izlazu“ – subjekt dogovora je rezultat usluge primljen od strane korisnika. Organizacije,

takoĎer, mogu specificirati način na koji se usluga dostavlja pomoću karakteristika (na razini

usluge) i korištenjem podloţnih „ciljeva“. Ovakav tip ugovora je poznat kao „ulazni“ SLA.

Kasnije navedeni tip zahtjeva zastarijeva kako organizacije postaju zahtjevnije i prebacuju

rizik dostavljanja na pruţatelja usluge.

SLA ugovori se, takoĎer, definiraju na različitim nivoima poput:

korisnički 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 pruţatelja usluga

višerazinski SLA: SLA je podijeljen na različite razine od kojih se svaka odnosi na

drugu grupu korisnika iste usluge

SLA na korporativnoj razini: pokriva sve općenito upravljanje problemima na razini

usluge (SLM) za svakog korisnika u organizaciji

SLA na korisničkoj 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 karakteristične usluge

22

3.4.1 Uobičajene metrike

SLA ugovori mogu sadrţati brojnu metriku performansi usluga sa odgovarajućim ciljevima

na razini usluge. Uobičajeni slučaj u IT upravljanju uslugama je pozivni centar. Metrike koje

se uobičajeno dogovaraju u ovom slučaju obuhvaćaju:

ABA (abandonment rate – stopa odustajanja): postotak poziva koji odustanu od

čekanja na javljanje operatera

ASA (average speed to answer – prosječno vrijeme javljanja): prosječno vrijeme

potrebno da se operater javi na poziv

TSF (time service factor): postotak poziva odgovorenih unutar odreĎenog vremenskog

roka

FCR (first call resolution): postotak dolaznih poziva koji se mogu riješiti bez

povratnog poziva

TAT (turn around time): vrijeme potrebno za završavanje odreĎenog zadatka.

Ugovori o vremenu neprekidnog rada su još jedan primjer česte metrike, često korišteni kod

podatkovnih usluga poput virtualnih privatnih servera itd. Uobičajeni ugovori, takoĎer, sadrţe

postotak vremena neprekidnog rada mreţe, neprekidnog vremena opskrbe električnom

energijom itd.

Ovdje je dan samo kratki pregled uobičajenih SLA metrika. One uvelike ovise o području

primjene, što će se vidjeti u kasnijem poglavlju o upravljanju znanjem u cloud računarstvu

gdje su navedeni SLA i SLO korišteni pri implementaciji i evaluaciji pojedinih metoda.

3.4.2 SLA u cloud računarstvu

Cloud računarstvo, takoĎer, koristi SLA koncept za kontroliranje korištenja i obračunavanja

resursa.

Svaka strategija upravljanja SLA ugovorima podrazumijeva dvije dobro diferencirane faze:

pregovaranje o ugovoru

praćenje njegova ispunjenja u realnom vremenu

23

Stoga, upravljanje SLA ugovorima obuhvaća definiranje ugovora (osnovna shema sa

parametrima kvalitete usluge), SLA pregovaranje, SLA praćenje i SLA provoĎenje prema

definiranim pravilima. Glavna točka je izgradnja novog sloja na cloud middleware koji

omogućava mehanizam pregovaranja izmeĎu pruţatelja i korisnika usluga. Temeljne

beneficije cloud računarstva su dijeljeni, distribuirani resursi. Stoga, SLA ugovori obuhvaćaju

cloud, te se nude od pruţatelja usluga u obliku ugovora zasnovanih na uslugama. Mjerenje,

praćenje i izvještavanje o cloud performansama se zasniva na iskustvima krajnjeg korisnika ili

na sposobnosti krajnjeg korisnika da troši resurse. Negativna strana SLA ugovora u cloud

računarstvu su poteškoće u odreĎivanju stvarnog uzroka prekida usluga zbog kompleksne

prirode cloud okruţja.

24

4 ZNANJE I UPRAVLJANJE ZNANJEM

Pojam znanja je jedan od filozofskih pojmova koji do dan danas nisu jednoznačno definirani.

Klasična se definicija znanja pridjeljuje grčkom 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 shvaćanje

(razumijevanje) koji su kratko definirani u nastavku.

Podaci su simboli bez ikakvog značenja osim vlastitog postojanja. Mogu biti u različitim

formama.

Informacije su obraĎeni podaci koji su dobili značenje relacijskim vezama s drugim

podacima. Ovako obraĎeni podaci mogu biti i korisni, iako to nije uvjet. U računalnom svijetu

informacije sadrţi relacijska baza na temelju podataka sloţenih u relacijske odnose. Ponekad

se kaţe da informacije daju odgovore na pitanja ''tko'', ''što'', ''gdje'' i ''kada''. Iz podataka

dolazimo do informacija ukoliko shvatimo odnose ili relacije.

Znanje je odgovarajući skup informacija kojima je osnovna namjena da budu korisni. Znanje

se stječe kroz proces učenja u kojem se informacije pretvaraju u znanje kako bi nam bilo od

nekakve koristi, kako bi nam posluţilo za nešto. Ponekad se kaţe da je znanje primjena

podataka i informacija sa ciljem davanja odgovora na pitanje ''kako''. Iz informacija do znanja

dolazimo ukoliko shvatimo model, obrazac ili predloţak. Na temelju njega moţemo i

predvidjeti što će se u budućnosti dogaĎati, što kod samog poznavanja informacija nije

moguće.

Slijedeći je korak shvaćanje temeljnih principa koji nas vodi prema mudrosti.

Mudrost uključuje shvaćanje temeljnih principa uključenih u znanje zbog kojih je znanje

upravo takvo kakvo jest. Mudrost bi bila najveći stupanj spoznaje, koji bi trebao uključivati

ne samo shvaćanje principa već i moral, etiku, pa neki autori smatraju da mudrost moţe imati

samo čovjek.

25

4.1 Prikazivanje znanja

Znanje se moţe formalno prikazati na različite načine koji se mogu grubo svrstati u 4 grupe:

Logičke sheme za prikaz znanja

Mreţne sheme za prikaz znanja

Proceduralne sheme za prikaz znanja

Okvire

U logičke sheme spada prikaz znanja temeljen na matematičkoj logici, kako standardnoj,

tako i nestandardnoj, dok se postupak zaključivanja temelji na pravilima zaključivanja.

Najvaţniji predstavnik logičkih shema su produkcijski sustavi koji su danas sigurno

najrasprostranjeniji posebno kod realizacije ekspertnih sustava.

U mreţne sheme spada prikaz znanja temeljen na mreţnim prikazima kojima se iskazuje

povezanost pojedinih elemenata znanja. Najistaknutiji predstavnik su semantičke mreţe,

jedan od najstarijih i najčešćih postupaka standardnog prikaza deklarativnog znanja.

Proceduralne sheme sluţe i za prikaz znanja, ali daju i procedure za korištenje tog znanja.

Proceduralan prikaz znanja je ujedno i stvarni plan kako se znanje koristi, pa postoji velika

sličnost izmeĎu postupaka konstruiranja planova i konstruiranja proceduralnog prikaza

znanja.

Okviri u svemu tome imaju posebno mjesto i, na neki način, čine fuziju svih metoda. Okviri

su strukture preko kojih, na primjer, moţemo implementirati semantičku mreţu kojoj smo

dodali i proceduralni dodatak kako manipulirati pohranjenim znanjem.

Vaţan pojam u svim sustavima prikaza znanja su činjenice, tj. stvari koje predstavljamo. U

logičkim 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, nuţno je uspostaviti vezu izmeĎu formalnog prikazivanja i

vanjskog svijeta.

4.1.1 Logičko prikazivanje znanja

Logički formalizam je izuzetno vaţan zbog činjenice što se novo znanje moţe generirati iz

starog znanja koristeći postupak matematičke dedukcije. Logika barata istinitostima pojedinih

tvrdnji i daje precizna pravila kako se iz pojedinih tvrdnji poznate istinitosti povezanih

logičkim operatorima moţe proračunati istinitost sloţene tvrdnje. Pomoću logike je moguće

ustanoviti istinitost neke tvrdnje čiju istinitost ne poznajemo, ukoliko dokaţemo da je ta

tvrdnja izvedena iz činjenica koje su istinite i poznate.

26

Matematičke logike dijelimo na standardne, koje se oslanjaju na klasičnu, propozicijsku ili

predikatnu logiku i nestandardne matematičke logike, od kojih je moţda najpoznatija

neizrazita (fuzzy) logika koja je u posljednje vrijeme nezaobilazna kod mnogih primjena

inteligentnih tehnologija. Osnovna razlika izmeĎu standardnih i ne-standardnih logika je u

stupnjevima istinitosti. Kod standardnih logika imamo samo dva stupnja istinitosti, pa tvrdnja

moţe biti ili istinita ili laţna (neistinita). Standardna logika je dvovaljana. Nestandardne

logike su viševaljane, odnosno mogu imati više stupnjeva istinitosti. Granični slučaj je

neizrazita (fuzzy) logika koja je beskonačno valjana.

U osnovi računalnog programiranja nalazi se logika. Programski jezici su po mnogim svojim

značajkama samo implementacija specijalnih logičkih 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 odreĎivanjem istinitosti ili neistinitosti različitih propozicija, a

propozicija je ispravno postavljena tvrdnja koja moţe biti istinita ili laţna. Propozicije se

meĎusobno povezuju operatorima u dobro formulirane formule . Operatora ima ukupno 16,

od kojih je 10 koji povezuju dvije propozicije posebno zanimljivo, a vaţan je i jedini operator

koji se odnosi na samo jednu varijablu (negacija). Istinitost dvije tvrdnje povezane

operatorima računa se pomoću tablica istinitosti.

Iako je propozicijska logika osnova digitalne elektronike, sklopovskog ustroja računala i

brojnih računalnih jezika, ona nije baš najpogodnija za prikazivanje ljudskog znanja zato što

nema mogućnosti prikazivanja odnosa izmeĎu objekata, pa se korištenjem propozicijske

logike ne moţe upotrijebiti nikakva klasifikacija. Ovi nedostaci su ispravljeni u predikatnoj

logici koja preuzima sva svojstva propozicijske logike i dodaje joj vrlo vaţan 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 pršut.“ itd. Predikatna logika to omogućava. Umjesto da se bavi

propozicijama koje se ne mogu raščlaniti, predikatna logika uvodi pojam predikat, koji je u

biti funkcija koja vraća vrijednost istinitosti (0 ili 1) u ovisnosti o svojim argumentima.

27

Osnovna razlika izmeĎu predikatne i propozicijske logike je separacija atributa od objekata

koji posjeduju te atribute. Drugim riječima u predikatnoj logici moţe se definirati funkcija

kojom odreĎujemo tvrdoću bilo kojeg objekta, dok se u propozicijskoj logici za svaki pojedini

slučaj mora definirati posebna tvrdnja.

Osnovni pojmovi predikatne logike su:

domena – skup elemenata nad kojima se izvodi zaključivanje

konstante – elementi domene

varijable – simboli koji se obično označavaju slovima X, Y, W itd. koji mogu poprimiti

bilo koju vrijednost iz domene

predikati – funkcije koje preslikavaju jedan ili više elemenata domene u jednu od

vrijednosti istinitosti. Predikat govori o nekom svojstvu elemenata domene ili o

meĎusobnim relacijama elemenata domene.

4.1.1.3 Nestandardne logike

Ne-standardne logike se dijele u dvije osnovne grupe:

logike koje proširuju standardne logike i nisu s njima u kontradikciji. Kod njih vrijede

svi aksiomi standardnih logika plus neki dodatni. Tipičan primjer su modalne logike.

Na primjer osnovna modalna logika koja uvodi nove operatore: L (nuţno je) i M

(moguće je), zatim temporalne logike kojima se dodaje pojam vremena, neke tro-

valjane logike itd.

logike koje su u suprotnosti sa standardnim logikama, kod kojih se pojedini aksiomi

suprotstavljaju aksiomima standardnih logika. Tipičan primjer su takoĎer više-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 omogućavanje usvajanja predodţbi i

iskustava [7]. Predodţbe i iskustva obuhvaćaju znanje, bilo da je ono utjelovljeno u

pojedincima ili sadrţano u organizacijskim procesima i praksama. Drugim riječima,

upravljanje znanjem je disciplina koja omogućava pojedincima, timovima i cijelim

organizacijama kolektivno i sistematsko stvaranje, dijeljenje i primjenu znanja u svrhu

28

efikasnijeg postizanja ciljeva.Upravljanje znanjem je kao disciplina uspostavljeno od 1991.

godine, te se proteţe kroz nekoliko polja poput poslovne administracije, informacijskih

sustava, rukovodstva i informacijskih znanosti. Odnedavno su i druga polja počela pridonositi

istraţivanjima upravljanjem znanja uključujući informacije i medije, računalnu znanost, javno

zdravstvo itd.

Dosta velikih i neprofitnih organizacija imaju istraţivanja posvećena internim pokušajima

upravljanja znanjem, često kao dio poslovne strategije, informacijske tehnologije ili

upravljanja ljudskim resursima.Nastojanja upravljanja znanjem se najčešće fokusiraju na

organizacijske ciljeve poput poboljšanja performansi, prednosti nad konkurencijom,

inovacije, integracije i kontinuiranog unaprjeĎenja organizacije. Ova nastojanja se često

preklapaju sa organizacijskim učenjem, te se od njega razlikuju većim fokusom na

rukovoĎenje znanjem kao strategijskog faktora i fokusom na podupiranju dijeljenja znanja.

Nastojanja upravljanja znanjem pomaţu pojedincima i grupama u dijeljenju vrijednih

organizacijskih predodţbi, te se na ovakav način smanjuju redundantni poslovi, vrijeme

obuke novih zaposlenika i olakšava prilagodba novim okruţenjima i trţištima.

4.2.1 Povijest

Upravljanje znanjem ima dugu povijest koja obuhvaća forume, korporativne knjiţnice,

profesionalnu obuku i programe mentorstva. U zadnje vrijeme sa povećanim korištenjem

računala u drugoj polovici dvadesetog stoljeća specifične primjene tehnologija poput baza

znanja, ekspertnih sustava, repozitorija znanja i sustava za podršku grupnom donošenju

odluka su omogućile brţi 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 slučajeva su prepoznale vaţnost značajki

upravljanja znanjem u mjerenjima strategija i procesa. Zaključeno 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 više zasnovanoj na

ljudskom sudjelovanje. Ova je crta evolucije nazvana Enterprise 2.0. MeĎutim, postoji tekuća

rasprava o tome da li je Enterprise 2.0 samo hir koji ne donosi ništa novo, ni korisno ili je,

zaista, budućnost upravljanja znanjem.

29

4.2.2 Istraţivanja

Upravljanje znanjem se pojavilo kao znanstvena disciplina u ranim devedesetim godinama

prošlog stoljeća. U početku je podrţavano isključivo od strane stručnjaka kad je Scania

zaposlila Leif Edvinsson-a kao prvog svjetskog glavnog sluţbenika znanja (Chief Knowledge

Officer). Huber Saint-Onge je istraţivao raznolike strane upravljanja znanjem, puno ranije od

gore navedenog dogaĎaja. Cilj CKO-a je upravljanje i maksimiziranje nematerijalne imovine

organizacije. Postepeno se CKO počinju baviti, ne samo praktičnim, već i teoretskim

aspektima upravljanja znanjem, te je tako stvoreno novo područje istraţivanja. Ideje

upravljanja znanjem su prihvatili brojni znanstvenici i akademici. Godine 2001. Thomas A.

Stewart izdaje reportaţu sa naslovnice koja je naglašavala vaţnost intelektualnog vlasništva

organizacija. Od svog nastanka upravljanje znanjem se postepeno kreće ka svojoj akademskoj

zrelosti. Postoji širok raspon mišljenja o disciplini upravljanja znanjem bez jednoglasne

odluke; pristupi variraju od autora do autora. Kako disciplina sazrijeva, povećao se broj

akademskih debata koje obuhvaćaju i teoriju i praksu, te sadrţe slijedeće perspektive:

Tehnološki orijentirana sa fokusom na tehnologiji koja unaprjeĎuje stvaranje i

dijeljenje znanja.

Organizacijska sa fokusom na način dizajniranja organizacije kako bi se najbolje

olakšali procesi vezani uz znanje.

Ekološka 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 obuhvaćaju ljude,

procese, kulturu i tehnologiju. Različite škole upravljanja znanjem imaju specifične poglede i

objašnjenja upravljanja znanjem.

4.2.3 Značajke

Postoje različite okosnice za razlikovanje znanja. Jedna predloţena okosnica za kategorizaciju

značajki znanja razlikuje prešutno i eksplicitno znanje. Prešutno znanje predstavlja znanje

kojeg pojedinac ne mora biti svjestan, poput načina obavljana pojedinih zadataka. Sa druge

strane eksplicitno znanje predstavlja znanje koje pojedinac svjesno drţi u mentalnom fokusu u

obliku koji je jednostavan za korištenje u komunikaciji sa drugim pojedincima.

30

Rana istraţivanja su pokazala da bi uspješno upravljanje znanjem trebalo pretvarati prešutno

znanje u eksplicitno kako bi se ono moglo dijeliti, ali bi isto nastojanje, takoĎer, moralo

dozvoljavati pojedincima da internaliziraju i učine osobno značajnim bilo koje „kodirano“

znanje izvučeno iz procesa upravljanja znanjem. Slijedeća istraţivanja u polju upravljanja

znanjem predlaţu da razlikovanje izmeĎu prešutnog i eksplicitnog znanja predstavlja

pretjerano pojednostavljivanje, te da je samo pojam eksplicitnog znanja sam sebi

kontradiktoran. Konkretno, da bi se znanje učinilo eksplicitnim, mora se prevesti u

informaciju, tj. u simbole izvan naših glava. Kasnije je predloţen model koji u obzir uzima

spiralni proces interakcije znanja izmeĎu eksplicitnog i prešutnog znanja. U ovom modelu

znanje prati ciklus u kojem se implicitno znanje „izvlači“ kako bi postalo eksplicitno, a

eksplicitno se „ponovno internalizira“ u implicitno znanje. Druga predloţena okosnica za

kategorizaciju značajki znanja razlikuje ugraĎeno znanje sustava izvan ljudske individue (npr.

informacijski sustavi mogu imati znanje ugraĎeno u svoj dizajn) i utjelovljeno znanje koje

predstavlja sposobnost učenja ljudskog ţivčanog i endokrinog sustava.

Treća predloţena okosnica za kategorizaciju značajki znanja razlikuje istraţivačko stvaranje

„novog znanja“ (npr. inovacije) i prijenos ili eksploataciju „uspostavljenog znanja“ unutar

grupe, organizacije ili zajednice. Kolaborativna se okruţenja poput korištenja alata za

društveno računarstvo mogu koristiti za stvaranja i prijenos znanja.

4.2.4 Strategije

Znanju se moţe pristupiti u tri stadija: prije, tijekom ili nakon aktivnosti vezanih za

upravljanje znanjem. Različite organizacije su probale različite poticaje za skupljanje znanja.

Znatne kontroverze postoje o tome da li poticaji djeluju ili ne, te se još nije došlo do

konsenzusa. Jedna strategija upravljanja znanjem uključuje aktivno rukovoĎenje znanjem. U

ovom slučaju pojedinci nastoje eksplicitno enkodirati vlastito znanje u repozotorij dijeljenog

znanja (poput baze podataka), te, takoĎer, dohvaćaju znanje koje im je potrebno. Ovaj pristup

je uobičajeno poznat kao kodifikacijski pristup upravljanju znanja.

Ostale strategije upravljanja znanjem za tvrtke uključuju:

nagrade (sredstvo motivacije za dijeljenje znanja)

pripovijedanja (sredstvo prenošenja prešutnog znanja)

31

mapiranje znanja

direktoriji eksperta

prijenos najbolje prakse

upravljanje sposobnostima

kolaborativne tehnologije

repozitoriji znanja

mjerenje i izvještavanja o intelektualnom vlasništvu

društveni softver (wiki, blogovi itd.)

4.2.5 Tehnologije

Rane tehnologije upravljanja znanjem su obuhvaćale korporacijske ţute stranice kao lokatore

stručnosti i sustave za upravljanje dokumentima. Kombinirano sa ranim razvojem

kolaboracijskih tehnologija (Lotus Notes), tehnologije upravljanja znanjem se šire u srednjim

devedesetim godinama prošlog stoljeća. Slijedeći pokušaji su utjecali semantičkim

tehnologijama za pretraţivanje i razvojem e-learning alata. U novije vrijeme razvoj alata za

društveno računarstvo omogućava manje strukturirane, samoupravne pristupe prijenosu,

hvatanju i stvaranju znanja. No, ovakvi alati su većim dijelom i dalje zasnovani na tekstu i

kodu, te kao takvi predstavljaju eksplicitni prijenos podataka. Ovi alati su suočeni sa

izazovima kod otkrivanja smislenog znanja. Softverski alati u upravljanju znanjem su

kolekcije tehnologija, te se ne mogu nuţno dobaviti kao pojedini komad softvera. Nadalje, ovi

softverski alati imaju prednost korištenja postojeće infrastrukture informacijske tehnologije u

organizaciji. Organizacije troše znatnu količinu resursa i značajno ulaţu u najnovije

tehnologije, sustave i infrastrukturu kako bi podrţali upravljanje znanjem. Upravljanje

znanjem je, takoĎer, postalo kamen temeljac u novim poslovnim strategijama poput Service

Lifecycle Management-a (SLM), gdje se tvrtke sve više obraćaju proizvoĎačima softvera

kako bi poboljšali efikasnost na trţištu.

32

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 omogućili 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 pridonošenja, dijeljenja i pristupanja znanju. Virtualni svjetovi su nadalje

povećali kolaboracijske mogućnosti u procesu dijeljenja znanja. Za razliku od Web 2.0

aplikacija u virtualnim svjetovima tim moţe raditi sinkronizirano. Nove generacije alata

virtualnih svjetova omogućuju 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 pomaţu pri stvaranju znanja

Metode koje pomaţu pri cirkuliranju znanja obuhvaćaju:

komunikaciju licem u lice

metode komunikacije zasnovane na računalima (email, Lotus Notes)

skladištenje i dohvaćanje informacija korištenje računalnih sustava (intranet)

sustavi zasnovani na znanju (ekspertni sustavi)

Metode i tehnike upravljanja znanjem su brojne te uvelike ovise o području primjene. U

slijedećem poglavlju će biti prikazane metode koje su izabrane kao najbolje za upravljanje

znanjem u cloud/SLA sustavima.

33

5 UPRAVLJANJE ZNANJEM U SAMOPRILAGODLJIVIM

CLOUDIMA

Da bi se postigla ţeljena razina fleksibilnosti clouda računalni resursi moraju biti alocirani

softveru koji čeka na izvršavanje. Potrebno je da alokacija bude ne samo dinamička, već i

autonomna. Kao što je rečeno u prijašnjim 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 postići, npr. dostupnost > 98%. U slučaju kršenja SLO-a

pruţatelj cloud usluga plaća kazne korisniku koje su, takoĎer, definirane unutar SLA ugovora.

U mnogo slučajeva jednostavne reakcije poput premještanja virtualnih mašina sa već

alociranih čvorova na dodatne dostupne čvorove mogu spriječiti kršenja utvrĎenih SLA

ugovora [8]. MeĎutim, identificiranje ovakvih reakcija je daleko od trivijalnog.

Pozitivni efekti raspoznavanja mogućih SLA kršenja prije nego se pojave su dvostrani. Sa

jedne strane pomaţe pruţatelju cloud usluga da izbjegne plaćanje kazni, te sa druge

minimizira interakciju korisnika sa samim sustavom. Nadalje, efektivno SLA upravljanje,

takoĎer, oslobaĎa dodatne resurse koji bi se inače koristili za ispunjavanje SLA ugovora.

U ovom poglavlju je prikazano korištenje baza znanja za samoupravljanje u cloudu. Opisane

su tri metode upravljanja znanjem i mogućnosti njihove implementacije unutar cloud sustava:

1. baze pravila (rule based system)

2. uobičajena logika (default logic)

3. situation calculus

4. rasuĎivanje temeljeno na slučajevima (case based reasoning)

Detaljnije će se prikazati metoda rasuĎivanja temeljenog na slučajevima [8]. Nadalje će se

detaljnije prikazati istraţivanja vezana uz default logics metodu koja su obavljena kao ključni

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 Self-

governing ICT Infrastructures) [9]. Cilj FoSII projekta je razvoj infrastrukture za autonomno

SLA upravljanje i provoĎenje. U nastavku poglavlja je dan osvrt na FoSII infrastrukturu i

34

povezanost sa metodama upravljanja znanjem. Prikazana je i studija slučaja izabrana za

evaluaciju case based reasoning pristupa [8].

5.1 Pregled FoSSI infrastrukture

FoSII infrastruktura se koristi za upravljanje cijelim ţivotnim ciklusom usluga samo-

upravljajućeg clouda (Slika 5-1). Upravljanje ureĎuje ciklus nadziranje-analiza-planiranje-

izvršavanje (MAPE; Monitor-Analysis-Plan-Execute). Nadalje, svaka FoSII usluga

implementira tri sučelja:

1. sučelje za pregovaranje nuţno za osnivanje SLA ugovora

2. sučelje za upravljanje zadacima nuţno za pokretanje zadataka, slanje podataka i slično

3. sučelje samoupravljanja nuţno za proces „osmišljavanja“ akcija potrebnih za

prevenciju kršenja SLA ugovora.

Slika 5-1 FoSII infrastruktura [8]

Sučelje 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 računalu neprestano nadgledaju metriku infrastrukturnih

resursa i trenutne statuse resursa dostavljaju autonomnom upravitelju. Senzori otkrivaju

35

buduća kršenja SLA ugovora na temelju iskustava iskorištenosti resursa i unaprijed

definiranih granica prijetnje.

Granice prijetnje su restriktivnije od SLO vrijednosti [10]. OdreĎivanje granica prijetnji je

daleko od trivijalnog, te bi one trebale biti konstantno aţurirane od strane sustava za

upravljanje znanjem, a samo na početku postavljene ručno od strane administratora sustava.

Potrebno je opisati mapiranje izmeĎu izmjerenih vrijednosti glavnog računala i vrijednosti

SLA parametara. Kao što je vidljivo na slici 5-1 razlikuje se nadgledanje glavnog računala i

nadgledanje u vremenu izvršavanja. Resursi se nadgledaju pomoću proizvoljnih alata za

nadgledanje na glavnom računalu. Stoga, metrika resursa obuhvaća vrijeme stajanja, vrijeme

neprekidnog rada, dostupnu širinu dolaznog i odlaznog mreţnog pojasa. Na temelju unaprijed

definiranih pravila mapiranja zapisanih u bazi podataka izmjerena metrika se periodički

mapira u SLA parametre. Primjer SLA parametra je dostupnost usluge Du (Tablica 5-1) koja

se izračunava pomoću metrika vremena stajanja i vremena neprekidnog rada. Mapiranje za

dostupnost usluge se vrši pomoću slijedeće formule:

(1)

Pravila mapiranja se definiraju od strane pruţatelja usluga korištenjem odgovarajućeg DSL

(Domain Specific Language) jezika. Izračunate SLA vrijednosti se usporeĎuju sa

predefiniranim granicama prijetnje kako bi se reagiralo prije kršenja SLA ugovora.

Jednom kada se moguća SLA kršenja otkriju reaktivne akcije se moraju provesti kako bi se

izbjeglo samo kršenje. U slijedećem poglavlju je prikazan SLA primjer korišten za

modeliranje i evaluaciju metoda upravljanja znanjem [8].

5.1.1 Primjer korištenja

U ovom poglavlju je prikazan primjer korištenja koji je definiran za ispitivanje metoda

upravljanja znanjem. Primjer SLA ugovora je prikazan u tablici 5-1.

36

Tablica 5-1 Primjer SLA ugovora [8]

SLO naziva SLO vrijednost

Širina dolaznog mreţnog pojasa (DM) > 10 Mbit/s

Širina odlaznog mreţnog pojasa (OM) > 12 Mbit/s

Prostor za pohranu (PP) > 1024 GB

Dostupnost (Du) ≥ 99%

Razmatraju se četiri SLO cilja:

širina dolaznog mreţnog pojasa

širina odlaznog mreţnog pojasa

prostor za pohranu

dostupnost

Odgovarajuće SLO vrijednosti su prikazane u desnom dijelu tablice 5-1. Kako bi se evaluirali

različiti pristupi upravljanju znanjem stanje sustava se opisuje u pogledu na aktivne fizičke

mašine (FM) i na aplikaciju koja se izvršava u tri različita trenutka (t1, t2, t3) u odnosu na

gore navedeni SLA ugovor. Pretpostavlja se da se jedna aplikacija izvršava na jednoj

virtualnoj mašini (VM), ali se jedna virtualna mašina moţe izvršavati na više fizičkih. Tablica

5-2 prikazuje izmjerena stanja sustava [8].

37

Tablica 5-2 Primjer stanja sustava [8]

DM OM PP Du Broj FM

t1 12.0 20.0 1200 99.50 20

t2 14.0 18.5 1020 99.47 17

t3 20.0 25.0 1250 99.60 19

Ciljevi za sustav upravljanja znanjem su definirani na slijedeći način [8]:

1. Kontinuirano stvaranje i unaprjeĎivanje SLA granica prijetnje. Na temelju

promatranja prošlih stanja sustav upravljanja znanjem treba stvarati granice prijetnje

za odreĎeni SLO.

2. OdreĎivanje reakcija. U slučaju nepostojanja granica prijetnje sustav upravljanja

znanjem treba predloţiti reakcije na temelju prijašnjih stanja sustava.

Na temelju SLA ugovora definiranog u tablici 5-1 i stanja sustava prikazanih u tablici 5-2

predloţene su definicije reakcije sustava [8]. Pretpostavka je da sustav upravljanja znanjem

djeluje u modu identifikacije reakcija bez konkretnih predefiniranih granica prijetnje za

kršenje SLA ugovora. Stoga je definirana skupina akcija koju je komponenta za izvršavanje

MAPE ciklusa sposobna aktivirati [8]:

1. za pojedine aplikacije (aplikacija se izjednačava sa virtualnom mašinom jer se

pretpostavlja jedan-na-jedan mapiranje izmeĎu aplikacija i virtualnih mašina):

a. povećaj širinu dolaznog mreţnog pojasa za x%

b. smanji širinu dolaznog mreţnog pojasa za x%

c. povećaj širinu odlaznog mreţnog pojasa za x%

d. smanji širinu odlaznog mreţnog pojasa za x%

e. povećaj količinu memorije za x%

38

f. smanji količinu 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 fizičku mašinu

n. ukloni fizičku mašinu

2. za fizičke mašine (računalne čvorove):

a. dodaj x računalnih čvorova

b. ukloni x računalnih čvorova

3. ne radi ništa (bez reakcije)

U odreĎenim trenutcima sustav upravljanja znanjem kao ulaz prima mjerenja, te kao izlaz

treba dati akciju koju je moguće izvršiti kako bi se spriječilo kršenje 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 istraţivanje, implementacija i evaluacija za case based reasoning i

default logics.

5.2.1 Rule based system (baze pravila)

Baze pravila se koriste kao način pohranjivanja i manipuliranja znanjem u svrhu interpretacije

informacija na koristan način. Često se koriste u aplikacijama i istraţivanjima na polju

umjetne inteligencije.

39

5.2.1.1 Aplikacije

Klasični primjer baza pravila je ekspertni sustav koji koristi pravila za donošenje zaključaka.

Na primjer, ekspertni sustav moţe sluţiti kao pomoć liječniku pri izboru ispravne dijagnoze

na temelju niza simptoma.

Baze pravila se mogu koristiti za izvršavanje leksičke analize pri kompajliranju ili

interpretiranju računalnih programa, te u obradi prirodnog jezika.

Programiranje baza pravila nastoji izvesti instrukcije izvršavanja iz početnog niza podataka i

pravila. Ovo je indirektnija metoda od one koju koriste imperativni programski jezici.

5.2.1.2 Izvedba

Uobičajena se baza pravila sastoji od četiri osnovne komponente [11]:

Niz pravila ili baza pravila (specifični tip baze znanja).

Baza znanja (zaključaka) ili baza za semantičko rasuĎivanje koji izvode zaključke na

temelju interakcija izmeĎu ulaza i baze pravila.

Privremena radna memorija.

Korisničko sučelje preko kojeg se ulazni i izlazni signali primaju i šalju.

5.2.1.3 Baze pravila i SLA

Baza pravila poput Drools [12] sadrţi pravila u „IF uvjet THEN radnja“ formi, npr. :

1. IF DM < GranicaPrijetnje_DM THEN dodaj fizičku mašinu

2. IF DM < GranicaPrijetnje_DM THEN povećaj DM udio za 5% za VM

3. IF Du < GranicaPrijetnje_Du THEN dodaj 2 računalna čvora sustavu

4. IF Du < GranicaPrijetnje_Du THEN premjesti aplikaciju na drugi cloud

Kao što je u radnji ranije opisano u ovakvom slučaju se koriste granice prijetnje za aktiviranje

odreĎenih radnji prije kršenja SLA ugovora. MeĎutim, ovakav pristup ima dvije mane:

40

Pitanje granica prijetnje. Ove granice se uvelike razlikuju ovisno o SLA parametru,

npr. za SLO prostor za pohranu podataka > 1024 GB, granica prijetnje moţe biti već

na 1300 GB (127% originalne granice), dok za SLO DM > 10 mbit/s granica prijetnje

moţe biti na 11 Mbit/s (110% originalne granice), jer je alociranje udjela mreţnog

pojasa mnogo brţe od alociranja prostora za pohranu. Granice prijetnje se, takoĎer,

mogu razlikovati za isti parametar u različitim domenama, npr. granica prijetnje za

dostupnost usluge u medicinskoj domeni gdje su u pitanju ljudski ţivoti mora biti

mnogo viša od granice za uslugu 3D renderiranja. Jedno od mogućih rješenja bi bilo

specificiranje granica prijetnje u DSL-u ili njihovo uključivanje u SLA dokument.

MeĎutim, ovaj proces bi uvelike ovisio o subjektivnoj procjeni. Ipak bi bilo moguće

pronaći vrijednosti iz iskustava koji bi odgovarale za većinu uobičajenih parametara.

Nadalje je potrebno odrediti da li se granice prijetnje izvode pomoću 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 riješio na univerzalan način potrebno je naći

odgovarajuću funkciju za svaki SLA parametar u svakoj domeni.

Drugo pitanje je rješavanje kontradiktornih pravila. Uzmimo u obzir pravila 3) i 4)

prikazana na početku odlomka. Da li baza znanja treba dodati računalne čvorove,

premjestiti aplikaciju ili boje u slučaju da dostupnost odreĎene usluge padne ispod

unaprijed definirane granice prijetnje? Korištenje koncepta istaknutosti (prioriteta) za

donošenje odluke vodi ka teško upravljivom skupu pravila.

U primjeru korištenja iz tablice 5-2 gore navedena pravila 1-4 sa granicama prijetnje za DM i

Du , baza znanja bi izvršila pravila 1 i/ili 2 u trenutku t1, u

trenutku t2 pravila 3 i/ili 4, a u trenutku t3 ne bi izvršila ništa.

5.2.2 Default logics (uobičajena logika)

Uobičajena logika je nemonotona logika za formaliziranje rasuĎivanja sa uobičajenim

pretpostavkama.

Uobičajena logika moţe izraziti činjenice poput „uobičajeno, nešto je istinito“; za razliku od

uobičajene, standardna logika jedino moţe izraziti istinitost ili laţ nečega. Ovo predstavlja

problem jer rasuĎivanje često uključuje činjenice koje su u većini slučajeva istinite, ali ne

uvijek. Klasičan primjer je „ptice, u pravilu, lete“. Ovo pravilo se u standardnoj logici moţe

41

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. Uobičajena logika cilja na formaliziranje ovakvih pravila zaključivanja bez potrebe za

eksplicitnim navoĎenjem svih iznimki.

5.2.2.1 Sintaksa

Uobičajena teorija je par <D, W>. W je skup logičkih formula koji se naziva pozadinska

teorija koja formalizira činjenice koje su za sigurno poznate. D je skup uobičajenih pravila

(default rules) od kojih je svako slijedeće forme:

(2)

Prema ovoj zadanoj vrijednosti ako se vjeruje da je Preduvjet istinit i svako

dosljedno sa trenutnim uvjerenjima, vjeruje se da je Zaključak istinit.

5.2.2.2 Primjeri

Uobičajeno pravilo (default rule) „ptice, u pravilu, lete“ se formalizira pomoću slijedeće

zadane vrijednosti:

{ ( ) ( )

( )} (3)

Ovo pravilo znači da ako je X ptica i moţe se pretpostaviti da leti, onda se donosi zaključak

da leti. Pozadinska teorija koja sadrţi neke od činjenica o pticama je slijedeća:

* ( ) ( ) ( ) ( )+

Prema ovom uobičajenom 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 dopušta zaključak 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 moţe zaključiti jer zadano pravilo samo

dopušta izvoĎenje Leti(X) iz Ptica(X), ali ne i obratno.

42

Česta uobičajena 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 uobičajenoj logici

korištenjem zadane vrijednosti poput slijedeće sa svaku činjenicu F:

Na primjer, programski jezik Prolog koristi vrstu zadane pretpostavke kod upravljanja

negacijom: ako se negativni atom ne moţe dokazati istinitim, onda se pretpostavlja da je

laţan. Vaţno je napomenuti da Prolog koristi takozvanu negaciju kao neuspjeh: kada

interpreter mora procijeniti atom , pokušava dokazati da je F istinito i zaključiti da je

istinito u slučaju neuspjeha. Za razliku od toga u uobičajenoj logici zadana vrijednost koja za

opravdanje sadrţi se moţe primijeniti samo ako je dosljedno sa trenutnim znanjem.

5.2.2.3 Uobičajena logika i SLA

Uobičajena logika [13] je verzija baze pravila u kojoj pravila više nisu jednostavna IF-THEN

pravila, već se mogu opisati kao IF uvjet – i ne postoje razlozi protiv – THEN djelovanje.

Slijedeća formula predstavlja primjer na temelju studije slučaja sa SLA ugovorima:

(4)

Ovo pravilo znači: Ako je širina dolaznog mrežnog pojasa manja od svoje granice prijetnje i

ne postoji razlog protiv povećanja udjela širine pojasa, onda povećaj širinu dolaznog

mrežnog pojasa. Razlog protiv povećanja bi mogao biti da je širina pojasa već na maksimumu

ili da su druge (vaţnije) usluge već zatraţile povećanje u isto vrijeme. Suprotno od običnih

pravila u bazi pravila, uobičajenoj logici je lako raščlaniti da se resursi ne mogu povećavati

beskonačno. MeĎutim, uobičajena logika ne nudi sredstvo za rješavanje problema nalaţenja

pravilnih granica prijetnje i za razrješavanje kontradiktornih pravila.

Nadalje, uobičajena logika se posebno koristi u poljima sa mnogo kontradiktornih pravila. Za

Cloud računarstvo je vaţnije saznati uzrok trenutnih informacija mjerenja, npr. zašto se

trenutna širina dolaznog mreţnog pojasa smanjila. Uzroci trenutnih informacija mjerenja se

trebaju saznati. Na primjer da li je trenutna širina mreţnog pojasa uzrokovana internim

problemom (postoji previše zahtjeva, a premalo resursa koji se nude) koje cloud sustav ne

moţe sam riješiti. Druga mogućnost je vanjski faktor, npr. DDoS (Distributed Denial of

Service) napad na koji se ne moţe direktno utjecati. Stoga, umjesto kontradiktornih, više

43

dolazi do pojave nepotpunih informacija. Sa uobičajenom 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 istraţivanja tehnologija i same implementacije metode uobičajene logike potrebno je

ustanoviti temeljne pretpostavke o cloud sustavu (FoSII) i njegovom autonomnom upravljanju

resursima i SLA ugovorima. Pretpostavke su slijedeće:

1. Svaka fizička mašina sadrţi slijedeće resurse:

a. CPU jezgre

b. CPU brzina

c. memorija

d. prostor za pohranu podataka

e. širina dolaznog/odlaznog mreţnog pojasa

2. Svaka virtualna mašina sadrţi slijedeće resurse:

a. CPU jezgre

b. iskorištenost CPU-a fizičke mašine

c. memorija

d. prostor za pohranu podataka

e. širina dolaznog/odlaznog mreţnog pojasa

3. Jedna virtualna mašina je distribuirana na točno jednu fizičku mašinu. Jedna VM ne

moţe biti distribuirana na više fizičkih mašina u isto vrijeme. Jedna fizička mašina

moţe biti domaćin za više VM.

4. Fizičke mašine mogu biti u tri različita stanja: upaljene, ugašene, u stanju spavanja.

44

5. CPU brzina fizičkih mašina se moţe dinamički prilagoĎavati.

6. Virtualne mašine mogu biti u tri različita stanja: upaljene, ugašene, u stanju spavanja.

7. Virtualne mašine se mogu stvarati, migrirati i uništiti (brisati).

8. Jedna aplikacija je distribuirana na točno jednu VM. Jedna virtualna mašina moţe

sadrţati više aplikacija.

9. Virtualne mašine mogu biti u stanju spavanja samo ako se na njima ne izvršava ni

jedna aplikacija.

10. Moguće je mjeriti resurse korištene od strane svake fizičke i virtualne mašine.

11. Za svaku aplikaciju je moguće mjeriti:

a. CPU iskorištenost virtualne mašine

b. memoriju

c. prostor za pohranu podataka

d. širinu dolaznog/odlaznog mreţnog pojasa

12. Moguće je dinamički podešavati resurse svake virtualne mašine.

Gore navedene pretpostavke su podloţne stalnim izmjenama i modifikacijama. Neke od

pretpostavki ne odgovaraju realnom stanju stvari na distribuiranim sustavima, ali su

postavljene radi lakše početne implementacije, koja bi se kasnije modificirala u skladu sa

kompleksnijim stanjima aplikacija i cloud sustava.

Postoje tri sustava koja implementiraju uobičajenu logiku:

DeReS

Xray

GADeL

45

MeĎutim, sva tri sustava su se pokazala kao dosta neefikasna, te neki od njih već neko

vrijeme nisu pod aktivnim razvojem. Stoga je izbran pristup prevoĎenja pravila uobičajene

logike u probleme deklarativne logike pomoću semantike skupa odgovora.

Programiranje skupa odgovora (answer set programming [ASP]) je oblik deklarativnog

programiranja orijentiranog prema teškim (primarno NP-teškim) problemima pretraţivanja.

Temelji se na stabilnom modelu (skup odgovora) semantike logičkog programiranja. U ASP-u

se problemi pretraţivanja reduciraju na stabilne računalne modele. Rješavači skupa odgovora

(programi za generiranje stabilnih modela) se koriste za izvršavanje pretraţivanja. Računski

proces korišten u dizajnu brojnih rješavača skupa odgovora je poboljšanje DPLL (Davis-

Putnam-Logemann-Loveland) algoritma i u principu uvijek završava sa izračunom (za razliku

od evaluacije upita u Prologu koja moţe voditi do beskonačne petlje).

Ukratko ASP uključuje sve aplikacije od skupova odgovora do prikazivanja znanja, te koristi

evaluaciju upita u stilu Prologa za rješavanje problema koji nastaju u ovim aplikacijama.

Lparse je naziv programa koji je originalno stvoren kao front-end za rješavač skupa odgovora

smodels, te se danas na isti način koristi u mnogim drugim rješavačima (assat, clasp, cmodels,

gNt, nomore++ i pbmodels).

Za implementaciju metode uobičajene logike je izabran DLV u kojem je sintaksa ASP

programa različita od Lparse sintakse. DLV je sustav baze za zaključivanje temeljen na

disjunktivnom logičkom programiranju.

Na DLV se moţe gledati kao na sustav logičkog programiranja i kao na sustav baze podataka

za zaključivanje. 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 zaključivanje.

DLV omogućava stvaranje EDB-a specificiranjem činjenica u odvojenoj datoteci. MeĎutim

jasno je da je ovakav pristup nepraktičan i neefikasan kod programa sa većim brojem

činjenica. U svrhu implementacije metode uobičajene logike je izabrana PostgreSQL baza

podataka otvorenog koda za skladištenje činjenica. Naime, DLV omogućava spajanje na bilo

koju relacijsku bazu koja podrţava ODBC sučelje. ODBC (Open Database Connectivity) nudi

standardno softversko sučelje za pristup sustavima za upravljanje bazama podataka.

46

Pri implementaciji metode je najprije potrebno napuniti EDB svim potrebnim činjenicama

poput SLA parametara, informacijama sa mjerenja resursa i sl. Ova baza sluţi samo kao ulaz.

Dalje je potrebno definirati znanje (pravila) koje bi koristilo činjenice iz EDB baze za

donošenje zaključaka. Znanje moţe ovisiti o EDB bazi, moţe predstavljati neovisno i

neodreĎeno znanje ili oboje navedeno. Dio koji donosi zaključke iz činjenica se naziva IDB

ili najčešće samo program.

Iako DLV, odnosno programska paradigma skupa odgovora, nudi mogućnost iskazivanja

pravila uobičajene logike, sa sobom nosi i brojne probleme. Potrebno je osmisliti i

organizirati sve moguće činjenice koje su vezane za cloud sustav i koje utječu na njegov rad i

na samo donošenje zaključaka pri regulaciji SLA ugovora. Izostavljanje najmanjeg detalja bi

moglo dovesti do donošenja krivih odluka ili potpunog izostanka zaključka u nekim

situacijama, što na posljetku dovodi do kršenja odreĎenih SLA ugovora.

5.2.3 Situation calculus

Situation calculus opisuje svijet koji se promatra u stanjima (funkcije) i situacijama. Funkcije

su logičke formule prvog reda koje mogu biti istinite ili laţne na temelju situacije u kojoj se

promatraju. Same situacije su konačni niz djelovanja. Situacija prije i jednog djelovanja –

početna točka sustava – se naziva početna 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 pomoću manipuliranja funkcija u njihovim domenama.

Za svijet od tri cigle koje se mogu sloţiti jedna na drugu, leţeći na stolu, prilično je

jednostavno pronaći funkcije:

cigla moţe i ne mora biti na stolu

cigla moţe i ne mora na sebi imati drugu ciglu

cigla x moţe i ne mora leţati na cigli y.

Moguća su dva djelovanja:

stavi ciglu x na ciglu y

skini ciglu y, npr. stavi ciglu y na stol.

47

Cilj bi mogao biti postojanje jednog stoga sa sve tri cigle sloţene po odreĎenom redoslijedu

sa početnom situacijom gdje su cigle sloţene u obrnutom redoslijedu od ciljanog. U svakom

stanju situacije istinite su različite funkcije, te stavljanje i skidanje cigli generira novu

situaciju.

5.2.3.1 Situation calculus i SLA

Mapiranje ove analogije na cloud računarstvo nije jednostavno. Što se tiče funkcija u cloudu

je potrebno uzeti u obzir trenutne vrijednosti svakog parametra, te da li je odgovarajući SLO

ispunjen ili ne. Nadalje sva stanja samog cloud sustava se moraju, takoĎer, modelirati kao

funkcije: broj aktivnih virtualnih mašina, broj dostupnih fizičkih mašina itd. Funkcije za

odreĎenu aplikaciju bi mogle biti predikat ima_vrijednost(SLAParametar p, Vrijednost v)

gdje je što znači da SLAParametar p ima vrijednost v u trenutnoj situaciji i

ispunjava(SLO s). To dalje znači da aplikacija ispunjava odreĎeni SLO s. Predikat

ima_vrijednost(SLAparametar1, x) je valjan samo za jedan u odreĎenoj situaciji.

Moguća djelovanja su prikazana u primjeru korištenja ranije uradu.

Budući da se cloud uvijek promatra kao cjelina sa svim stanjima, moţe biti jako komplicirano

izvesti točno jedno djelovanje koje moţe dovesti do napretka pri ostvarenju cilja. Moguće

rješenje je promatranje aplikacija izolirano jedne od druge, te postojanje sveukupnog pogleda

koji u obzir uzima neke informacije više razine poput ispunjavaSLA(Aplikacija app). Ovo

pravilo bi značilo da aplikacija ispunjava sve svoje trenutne SLO ciljeve. Izvodljiv način

definiranja ciljeva bi mogao biti definiranje funkcije korisnosti koja prikazuje korisnost

usluge koja ispunjava svoj SLA ugovor. Parametri ove funkcije mogu biti vaţnost korisnika i

kazna koju je potrebno platiti pri kršenju svakog SLO cilja. Sustav tada pokušava pronaći

djelovanje koje bi maksimiziralo korisnost.

Ako se u obzir uzme cloud sustav koji odrţava 100 aplikacija od kojih svaka ima pet SLA

parametra. Ovo vodi prema ( ) različitih funkcija poput

ima_vrijednost(SLAParametar1, x), ima_vrijednost(SLAParametar2,y) itd. za svaku

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

pretraţivanja mogućih djelovanja.

48

5.2.4 Case-based reasoning (rasuĎivanje temeljeno na slučajevima)

RasuĎivanje temeljeno na slučajevima je proces rješavanja problema na temelju prethodnih

iskustava [15]. Detaljnije, ova metoda pokušava riješiti slučaj (formatirani primjer) pomoću

pretraţivanja sličnih slučajeva iz prošlosti. Rješenja pronaĎenih sličnih slučajeva se koriste za

rješavanje trenutnog slučaja. Općenito se CBR ciklus sastoji od slijedećih faza (pod

pretpostavkom da je primljen novi slučaj):

1. Pronaći i učitati slučaj ili slučajeve slične trenutnom.

2. Iskoristiti informacije i znanje iz sličnih slučajeva u rješavanju problema.

3. Preispitati i po potrebi preraditi predloţeno rješenje.

4. Zadrţati dijelove novog iskustva koji bi mogli biti korisni za buduća rješavanja

problema.

U koraku 4 se novi slučaj i pronaĎeno rješenje zapisuju u bazu znanja. U slijedećem poglavlju

je prikazan način korištenja ove metode u svrhe upravljanja SLA ugovorima na polju cloud

računarstva.

5.2.4.1 Rasuđivanje temeljeno na slučajevima 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 rasuđivanja temeljenog na slučajevima [8]

49

Kao što je vidljivo na dijagramu (Slika 5-2), ideja je skladištenje pravila koja aktiviraju CBR

sustav kada se za odreĎeni SLA parametar dosegne vrijednost granice prijetnje u bazu

podataka 1. Mjerenja se u obliku novog slučaja šalju CBR sustavu (uokvireni dijelovi na slici

5-2) od strane komponente za mjerenje. Tada CBR pripremljen sa početnim suvislim

slučajevima zapisanim u bazi podataka 2 bira skup slučajeva koji su najsličniji novom,

različitim tehnikama koje su opisane kasnije u radnji. Iz ovih slučajeva se bira onaj sa

najvećom korisnošću. Dalje se izvršava djelovanje koje je bilo izvršeno prije za izabrani,

najsličniji slučaj. Konačno se nekoliko vremenskih intervala kasnije mjere rezultati

djelovanja, usporeĎuju se sa početnim slučajem, te se zajedno sa izračunatim korisnostima

zapisuju kao novi slučaj u CBR.

Postoje slijedeći osnovni procesi (Slika 5-2):

stiţu nova mjerenja („Measurements“ kvadrat),

provjera da li je dosegnuta granica prijetnje za neke parametre („Rules to engage CBR

„kvadrat),

ako je izaberi skup najsličnijih slučajeva iz CBR sustava, te iz njih izaberi slučaj sa

najvećom korisnošću („Case Based Reasoning“ kvadrat),

izvrši djelovanje izabranog slučaja („Trigger 1 action“ kvadrat),

mjerenjem rezultata izračunaj korisnost izvršenog djelovanja („Measure results“

kvadrat),

zapiši slučaj u CBR („Feedback“ kvadrat).

Izvršavanjem gore navedenih procesa je moguće konstantno učiti nove slučajeve i evaluirati

korisnost izvršenih djelovanja. Mjerenjem korisnosti u više vremenskih intervala, CBR

takoĎer moţe učiti da li je djelovanje izvršeno prekasno (kada se korisnosti slijedeći

vremenske intervale poboljšavaju, ali poboljšanje doĎe prekasno da bi se spriječilo kršenje

SLA ugovora) ili čak nepotrebno. Stoga se i granice prijetnje koje pokazuju kada pokrenuti

CBR mehanizam mogu konstantno poboljšavati.

50

Daljnja razmišljanja na temelju osnovnog koncepta vode ka slijedećim varijacijama [8]:

1. Umjesto korištenja pravila sa granicama prijetnje, CBR konstantno prima nove

slučajeve od komponente za mjerenje. Dalje zaključuje kada izvršiti neko djelovanje, a

kada ne. Na ovaj način je moguće 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. ručnu fazu gdje se slučajevi stvaraju i prilagoĎavaju ručno,

b. aktivnu CBR fazu,

c. pasivnu fazu temeljenu na slučajevima u kojoj se nešto radi samo u slučaju kad

se dosegne granica prijetnje.

U fazi c se kao i u fazi b takoĎer izračunavaju korisnosti djelovanja. U slučaju da

korisnosti padnu prenisko, ovisno o ozbiljnosti se ili ponovno pokrene faza b za učenje

novih slučajeva ili se čak ide nazad u ručnu fazu (faza a). Kada se korisnosti

poboljšavaju, ide se u pasivnu fazu (faza c).

3. Za jednostavne parametre postoje jednostavne granice prijetnje i djelovanja koja

koriste pravila umjesto CBR sustava. Ovo omogućava oslobaĎanje računalnih resursa.

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

51

5.2.4.2 Implementacija

U ovom poglavlju su opisani detalji implementacije CBR i metoda korištenih za učenje i

reagiranje, kao i upotrjebljenih mjerenja korisnost [8]. Implementacija slijedi varijaciju a) iz

prethodnog odlomka.

Implementacija je izvršena u Java programskom jeziku, te je temeljena na FreeCBR-u [16].

Kao što je vidljivo na slici 5-4 potpuni slučaj se sastoji od:

identifikacijskog broja aplikacije (redak 2, Slika 5-4),

početnog slučaja (mjerenja dobivena od komponente za mjerenje) koji se sastoji od

SLO vrijednosti aplikacije i općenitih cloud informacija poput broja aktivnih

virtualnih mašina (redci 3-10, Slika 5-4),

izvršene akcije (redak 11, Slika 5-4),

rezultirajućeg slučaja izmjerenog nekoliko trenutaka kasnije (redci 12-19, Slika 5-4),

rezultirajuće 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 slučaja [8]

52

Da bi se evaluirala stvarna korisnost odreĎenog djelovanja koje je pomoglo u nekom slučaju,

usporeĎuje se korisnost početnog slučaja sa korisnosti rezultirajućeg slučaja. Neka su

stvarne vrijednosti nekog parametra α izmjerenog u početnom i rezultirajućem

slučaju i neka je granica prijetnje specificiranog SLA prametra. Definira se ralativna

korisnost za parametar . Ako bi trebao biti slučaj u kojem vrijedi definiciju je

potrebno pomnoţiti sa -1. Korisnost ( ) za definiramo kao

( )

(5)

Povećanje ili gubitak korisnosti od početnog do rezultirajućeg slučaja za parametar α se moţe

opisati na slijedeći način:

( )

(6)

U slijedećem koraku je potrebno definirati korisnost parametara koji nisu navedeni u SLA

ugovoru aplikacije, poput „izvršava se na fizičkim mašinama xy“ ili globalni parametar

„fizičke mašine“. S obzirom na primjer korištenja koji je prikazan ranije u radu definira se da

je bolje ako se aplikacija izvršava na što manje fizičkih mašina, jer ovo oslobaĎa resurse za

druge aplikacije. Isto vrijedi i za utjecaj na broj aktivnih fizičkih mašina. Na gašenje svake

fizičke mašine koja nije potrebna za osiguravanje SLA ugovora se gleda kao na pozitivan

utjecaj na korisnost. Stoga se, takoĎer, usporeĎuje broj aktivnih fizičkih mašina od

rezultirajućeg do početnog slučaja pomoću formule

( )

(7)

Isti princip vrijedi i za parametar „izvršava se na fizičkim mašinama xy“.

Sada se konačna korisnost dobiva uzimanjem prosjeka korisnosti ( ) za sve

parametre α i prosjek korisnosti aktivnih fizičkih mašina i globalnih parametara.

Općenito govoreći postoje sofisticiranije metode za definiranje korisnosti od ovakvog

linearnog pristupa, ali je ovakav način odabran zbog jednostavnosti.

Za potpuni slučaj prikazan na slici 5-4 i SLA ugovor iz primjera korištenja (Tablica 5-1),

korisnost se izračunava na slijedeći način:

53

( ) (

)

(8)

Sličnost slučajeva se odreĎuje pomoću Euklidove udaljenosti koja za dva slučaja uzima

korijen zbroja kvadrata razlika svakog parametra.

Nadalje, za pronalaţenje sličnih slučajeva su implementirane dvije metode. Svaka metoda

traţi odreĎene slučajeve iz kojih bira onaj sa najvećom korisnosti. Prva metoda koja se zove

t-susjedstvo traţi slučaj sa najvećim postotkom podudaranja i uzima u obzir sve slučajeve koji

su udaljeni za t% od slučaja sa najvećim postotkom podudaranja. Druga metoda, metoda

grupiranja, koristi k-means algoritam grupiranja za grupiranje slučajeva u k grupe iz kojih se

dalje izabire ona koja sadrţi slučaj sa najvećim postotkom podudaranja. Isprobava se

grupiranje za nekoliko k grupa, te se naposljetku bira k koji ima najniţu varijancu od svih

grupa.

5.2.4.3 Evaluacija

U ovom odlomku će se usporediti ishodi testnog slučaja dobiveni korištenjem CBR sustava sa

djelovanjima za koje se pretpostavlja da bi izvršio administrator.

Nakon punjenja baze podataka sa devet različitih slučajeva (Tablica 5-3) testiramo ih u

odnosu na SLA ugovore definirane sa prijašnjim slučajem korištenja. Dodano je šest novih

slučajeva (Tablica 5-4), te su evaluirani rezultati.

Početni slučajevi su prikazani u tablici 5-3 u kojoj svaki stupac sadrţi jedan od devet

slučajeva. Gornji dio tablice (vrijednosti parametara sa indeksom b) prikazuju vrijednosti koje

su izmjerene prije izvršavanja ikakvog djelovanja od strane sustava. Redak Djelovanje

prikazuju izvršeno djelovanje za odreĎene slučajeve, iza čega slijede izmjereni parametri

nakon naznačenog djelovanja (vrijednosti parametara sa indeksom a). Redak Korisnost

prikazuje korisnosti ostvarene izvoĎenjem navedenih djelovanja.

54

Tablica 5-3 Početni slučajevi za CBR [8]

1 2 3 4 5 6 7 8 9

15.0

20.0

1200

99.5

1

20

11.0

20.0

1200

99.5

1

20

10.5

20.0

1200

99.5

1

20

15.0

13.0

1200

99.5

1

20

15.0

12.5

1200

99.5

1

20

15.0

20.0

1050

99.5

1

20

15.0

20.0

1000

99.5

1

20

15.0

20.0

1000

99.45

1

20

15.0

20.0

1200

99.4

1

20

Djelovanje / DM +

5%

DM +

10%

OM +

5%

OM +

10%

PP +

5%

PP +

10%

M +

5%

M +

10%

15.0

20.0

1200

99.5

1

20

11.55

20.0

1200

99.5

1

20

11.55

20.0

1200

99.5

1

20

15.0

13.65

1200

99.5

1

20

15.0

13.75

1200

99.5

1

20

15.0

20.0

1103

99.5

1

20

15.0

20.0

1100

99.5

1

20

15.0

20.0

1200

99.5

1

20

15.0

20.0

1200

99.5

1

20

Korisnost 0.0 0.009 0.0175 0.009 0.017 0.009 0.016

Šest testnih slučajeva koji su zapisani u bazu znanja se prikazani u tablici 5-4. Stupci,

ponovno, sadrţe slučajeve od 1-6, a redci prikazuju parametre na početku CBR ciklusa.

55

Tablica 5-4 Testni slučajevi za CBR [8]

1 2 3 4 5 6

DM

OM

PP

Du

RPM

FM

15.0

20.0

1200

99.5

1

20

11.0

20.0

1200

99.5

1

20

10.5

20.0

1200

99.5

1

20

15.0

13.0

1200

99.5

1

20

20.0

25.0

1250

99.6

1

20

10.0

18.0

1450

99.5

1

20

Rezultati, npr. koje djelovanje je izvršeno, se mogu vidjeti u tablicama 5-5 i 5-6 za metodu

susjedstva i grupiranja. U tablici 5-5 stupac Očekivano djelovanje prikazuje očekivano

djelovanje za testni slučaj (isti stupac vrijedi i za tablicu 5-6 i u njoj nije ponovljen). Stupci

Preporučena djelovanja u tablicama 5-5 i 5-6 definiraju koje je djelovanje zapravo

preporučeno od strane CBR mehanizma. Stupac Varijanca u tablici 5-5 prikazuje kako su

grupe kompaktne. Niska varijanca označava visoku koherentnost (točke jedne grupe imaju

male meĎusobne udaljenosti), dok visoka varijanca označava suprotno. U tablici 5-6 gdje se

prikazuju rezultati za t=3% i t=5% se dodatno prikazuje broj slučajeva u t-susjedstvu slučaja

sa najvećim postotkom podudaranja. Ovo prikazuje koliko je velika bila skupina slučajeva za

odabir slučaja sa najvećom korisnosti. Što ima više slučajeva, veća je šansa izbora slučaja sa

većom korisnosti, ali je u isto vrijeme manja sličnost sa originalnim slučajem.

56

Tablica 5-5 Rezultati evaluacije pri korištenju algoritma grupiranja [8]

Slučaj Očekivano djelovanjem Preporučeno djelovanje Varijanca

1

2

3

4

5

6

DM + 5%

OM + 5%

PP + 5%

PP + 10%

/

DM + 10%

DM + 10%

OM + 10%

PP + 10%

PP + 10%

PP + 10%

DM + 10%

23

18

208

14

96

40

Na temelju evaluacije se dolazi do zaključka da su djelovanja za oba algoritma gotovo

jednaka i slična očekivanim. Jedino je intenzitet djelovanja uvijek veći od očekivanog, jer se

tako dobiva veća vrijednost korisnosti. Ovo bi se moglo poboljšati modificiranjem funkcije

korisnosti na način da dopušta da umjerenija djelovanja imaju veće korisnosti. Bez obzira na

to svaki put je problematični SLA parametar ispravno identificiran. Jedino je za slučaj 5 koji

ima izvrsne vrijednosti SLA parametara, te ne zahtjeva izvršavanje nikakvih djelovanja, svaka

metoda osim metode susjedstva za t=3% preporučila izvršavanje nekog djelovanja. Razlog

ovome je isti kao kod izbora većeg intenziteta; izvršavanje djelovanja uvijek postiţe veću

korisnost. Stoga se vrijednost neizvršavanja djelovanja, takoĎer, moţe preferirati u definiranju

korisnosti.

57

Tablica 5-6 Rezultati evaluacije pri korištenju algoritma susjedstva [8]

t = 5% t = 3%

Slučaj Preporučeno

djelovanje

Broj slučajeva u t-

susjedstvu

Preporučeno

djelovanje

Broj slučajeva u t-

susjedstvu

1

2

3

4

5

6

DM + 10%

OD + 10%

PP + 10%

PP + 10%

M + 5%

DM + 10%

2

4

2

3

2

8

DM + 10%

OM + 10%

PP + 10%

PP + 10%

/

DM + 10%

2

4

2

2

1

5

58

6 ZAKLJUČAK

U ovom radu je dan kratki osvrt na cloud sustav arhitekturno i infrastrukturno. Glavni

problemi koji se trenutno pokušavaju riješiti na ovom području su osiguranje kvalitete usluge

koju korisnik zahtijeva. Ovo se nastoji riješiti pomoću SLA ugovora, koji se već duţe vrijeme

koriste na području IT-a, ali i šire. MeĎutim, upravljanje SLA ugovorima u kompleksnom

okruţenju poput cloud sustava donosi veliki broj novih problema i prepreka. Jedan od većih

problema je veliki broj SLA parametara vezanih za računalne resurse i stanja sustava sa

kojima se mora upravljati ne samo dinamički, već i autonomno. Za rješavanje ovakvih

problema se koriste brojne discipline poput upravljanja znanjem i sličnih grana iz polja

umjetne inteligencije. Upravljanje znanjem sa sobom automatski vuče i opseţne, kompleksne

baze podataka (znanja), koje se koriste za zapisivanje i pretraţivanje znanja koje sluţi za

donošenje zaključaka kod upravljanja resursima.

U ovom radu je opisano nekoliko metoda upravljanja znanjem za koje se smatra da su

pogodne za korištenje u samo-prilagodljivim cloud sustavima. Opisane su metode rule based

system (baze pravila), default logics (uobičajena logika), situation calculus i case based

reasoning (rasuĎivanje temeljeno na slučajevima). Za metodu uobičajene logike je prikazano

istraţivanje mogućnosti i tehnologija za implementaciju. Dan je osvrt i opis izabranih

tehnologija, te su prikazane dobre i loše strane odabrane tehnologije. Nadalje je prikazana

implementacija rasuĎivanja temeljenog na slučajevima i evaluacija dobivenih rezultata. U

implementaciji se metoda koristila za interpretaciju izmjerenih vrijednosti sa ciljem

sprječavanja kršenja SLA ugovora. U sklopu ove metode je, takoĎer, implementirano

autonomno rekonfiguriranje granica prijetnji.

Osnovni problem pri implementaciji default logics metode je pravilno definiranje svih

mogućih pravila koja moraju pokrivati sve resurse i stanja cloud sustava. Potrebno je osmisliti

i organizirati sve moguće činjenice koje su vezane za cloud sustav i koje utječu na njegov rad

i na samo donošenje zaključaka pri regulaciji SLA ugovora. Izostavljanje najmanjeg detalja bi

moglo dovesti do donošenja krivih odluka ili potpunog izostanka zaključka u nekim

situacijama, što naposljetku dovodi do kršenja samih SLA ugovora.

Bez same evaluacije i rezultata testova je teško donijeti realan zaključak, ali se da

pretpostaviti da je za upravljanje SLA ugovorima u samoprilagodljivim cloud sustavima

najbolji izbor metoda rasuĎivanja temeljena na slučajevima, jer ona omogućava zaključivanje

59

i donošenje odluka na temelju prijašnjih iskustva, dok uobičajena logika nudi, takoreći, brute

force rješenje problema.

60

7 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 pruţa usluge višestrukim 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 računarstvo predstavlja korištenje IT infrastrukture kao usluge (od hardvera

do API-ja) ................................................................................................................................. 16

Slika 5-1 FoSII infrastruktura [8] ............................................................................................. 34

Slika 5-2 Proces rasuĎivanja temeljenog na slučajevima [8] ................................................... 48

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

Slika 5-4 Primjer CBR slučaja [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 Početni slučajevi za CBR [8] ................................................................................ 54

Tablica 5-4 Testni slučajevi za CBR [8] .................................................................................. 55

Tablica 5-5 Rezultati evaluacije pri korištenju algoritma grupiranja [8] ................................. 56

Tablica 5-6 Rezultati evaluacije pri korištenju algoritma susjedstva [8] ................................. 57

7.2 Popis oznaka i kratica

DM – širina pojasa dolazne mreţe

OM – širina pojasa odlazne mreţe

PP – prostor za pohranu

Du – dostupnost usluge

61

FM – fizička mašina

VM – virtualna mašina

IFM – broj fizičkih mašina na kojima se aplikacija izvršava

M – memorija

SLA – Service Level Agreement (ugovor na razini usluge)

SLO – Service Level Objective (cilj na razini usluge)

CBR – Case Based Reasoning (rasuĎivanje temeljeno na slučajevima)

62

8 LITERATURA

[1] TechRepublic; Understanding Cloud Computing: A white paper for

executives making decisions on computing resources, s 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, (23-

27), 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.

63

[9] (FOSII) – Foundations of self-governing ICT Infractures, s 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.it-

tude.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, (Oţujak 1994), (39-59), 0921-7126

[16] FreeCBR, s intereneta: http://freecbr.sourceforge.net, zadnji pristup: 2010-26-06

[17] Stipaničev, D. (2009). Umjetna inteligencija, materijali s predavanja, Sveučilište u

Splitu, FESB, Split