SVEUILITE U SPLITU

FAKULTET ELEKTROTEHNIKE, STROJARSTVA I BRODOGRADNJE

Dr. sc. EUGEN MUDNI

GRID RAUNALNI SUSTAVI

SKRIPTA (predavanja i vjebe)

Mostar, 2015

SADRAJ:
1. DEFINICIJA I PREGLED GRID RAUNALNIH SUSTAVA .................................................. 5
1.1

Uvod ......................................................................................................................... 5

1.2

Tehnoloki poticaj razvoju Grid raunalnih sustava ................................................ 5

1.3

Definicija Grid raunalnih sustava ........................................................................... 9

1.4

Definicija Grid pojmova ......................................................................................... 11

1.5

Grid sustavi usporeeni s ostalim distribuiranim sustavima ................................. 11

1.6

Arhitektura i funkcionalnost Grid sustava ............................................................. 11

1.7

Motivacija i koristi od koritenja Grid sustava i nedostaci .................................... 13

1.8

Klasifikacija Grid sustava ........................................................................................ 14

1.9

Osnovni elementi Grid midllewarea ...................................................................... 19

1.10

Osnovni Grid standardi ........................................................................................ 21

1.11

Evolucija Grida prema Cloud raunalstvu ............................................................ 23

1.12

Kratak pregled Grid projekata.............................................................................. 23

2. UPRAVLJANJE PODACIMA ....................................................................................... 26

2.1

Uvod ....................................................................................................................... 26

2.2

Zahtjevi upravljanja podacima ............................................................................... 27

2.3

Funkcije upravljanja podacima u Grid sustavima .................................................. 28

2.4

Servisi za meta-podatke u Grid sustavima............................................................. 31

2.5

Replikacija .............................................................................................................. 33

2.6

Efikasan prijenos podataka .................................................................................... 33

3. GRID RASPOREIVANJE (SCHEDULING) I INFORMACIJSKI SERVISI ........................... 35

3.1

Mapiranje poslova strategije rasporeda poslova ............................................... 35

3.2

Mapiranje poslova na paralelnim strojevima ........................................................ 36

3.3

Mapiranje ili strategije rasporeivanja poslova na meta-raunalima ................... 38

3.4

Algoritmi rasporeda meta-rasporeivaa.............................................................. 42

3.5

Otkrivanje i nadgledanje servisa (Service monitoring and discovery)................... 43

3.6

Grid workflow ........................................................................................................ 44

3.7

Tolerancija greaka u Grid sustavima .................................................................... 45

4. SIGURNOST U GRID SUSTAVIMA ............................................................................. 46

4.1

Uvod ...................................................................................................................... 46

4.2

Povjerenje i sigurnost u Grid sustavima ................................................................ 47

5. RAUNARSTVO U OBLAKU..................................................................................... 51
5.1

Poetci raunarstva u oblaku ................................................................................ 51

5.2

Od velikih centralnih raunala do raunarstva u oblaku ....................................... 52

5.3

Slojevi i tipovi oblaka ............................................................................................. 53

5.4

Infrastruktura kao usluga (IaaS) ............................................................................ 55

5.5

Javni, privatni i hibridni oblak ............................................................................... 57

V1. VIRTUALIZACIJA UVOD ..................................................................................... 60

1.1

Virtualizacija hardvera ........................................................................................... 60

1.2

Virtualizacija softvera ............................................................................................ 63

1.3

Virtualizacija memorije.......................................................................................... 65

1.4

Virtualizacija pohrane podataka ........................................................................... 66

1.5

Virtualizacija podataka .......................................................................................... 69

1.6

Virtualizacija mree ............................................................................................... 70

V2. KREIRANJE VIRTUALNOG STROJA NA ESXI OKOLINI ............................................. 71

V3. HTCONDOR - UPRAVLJANJE POSLOVIMA............................................................. 81
3.1

Uvod ...................................................................................................................... 81

3.2

Instalacija HTCondor vora .................................................................................... 82

3.3

Hardverski i ostali zahtjevi..................................................................................... 82

3.1

Postupak instalacije na Ubuntu 14.04 LTS sustavu ............................................... 83

3.2

Podnoenje zahtjeva za HTCondor poslom ........................................................... 84

V4. HTCONDOR - UPRAVLJANJE POSLOVIMA............................................................. 86

4.1

Uparivanje (matchmaking) s ClassAds .................................................................. 86

4.2

Kreiranje i slanje poslova....................................................................................... 88

4.3

HTCondor universe izbor .................................................................................... 89

4.4

Primjeri................................................................................................................... 92

4.5

HTCondor - lista naredbi ........................................................................................ 95

4.6

Primjeri naredbi ..................................................................................................... 96

1. DEFINICIJA I PREGLED GRID RAUNALNIH SUSTAVA

1.1 Uvod
Pojam Grid ili Grid raunalni sustavi oznaava ovisno o primjeni koristi se za niz razliitih
raunalnih tehnologija, trita i rjeenja. Znaenje je asocirano s pojmovima raunalstva u
grozdu (cluster computing), raunalstva visokih performansi (HTC - high throughput
computing), usluno raunalstvo (utility computing), peer-to-peer raunalstvo, raunalstva u
Oblaku (Cloud computing). U cilju definiranja pojma u ovom poglavlju dan je pregled
slijedeih aspekata :

Tehnoloki poticaji razvoju Grid raunalnih sustava

Definicija Grid raunalnih sustava

Pregled osnovnih arhitektura Grid raunalnih sustava

Pregled osnovnih komponenti i funkcionalnosti Grid raunalnih sustava

Pregled prednosti i nedostataka Grid raunalnih sustava

Klasifikacija Grid raunalnih sustava

Pregled trendova u razvoju razliitih Grid raunalnih sustava

Slika 1.1. Grid raunalni sustav

1.2 Tehnoloki poticaj razvoju Grid raunalnih sustava

U razvoju raunalne tehnologije se periodiki dogaa konvergencija niza tehnologija u jednu
zajedniku cjelinu. Jedan od primjera jest razvoj mrenih tehnologija, resursa i aplikacija u
neto to danas zovemo Internet.
Foster i Kesselman su 2004 napisali slijedeu definiciju:

Grid je nadolazea infrastruktura koja e na fundamentalan nain izmijeniti nain na koji

razmiljamo o i koristimo raunalne resurse. Rije Grid koristi se kao analogija elektrinoj
mrei (power Grid), koja omoguava sveprisutnu dostupnost elektrinoj energiji, koja je kao
raunala i mali broj drugih izuma imala dramatian utjecaj na ljudske sposobnosti i drutvo
openito. Mnogi vjeruju da e omoguavanjem da se komponente nae informatike
infrastrukture raunalni resursi, baze podataka, senzori i ljudi dijele fleksibilno kao prava
sredstva za suradnju, Grid imati slian efekt transformacije, omoguavajui pojavu nove
klase aplikacija.
Gledano sa strane korisnika Grid raunalni sustav omoguava da se raunalni resursi mogu
dobiti poput struje u elektrinoj mrei. Kad korisnik ukljui troilo u mrei ne vodi brigu o
tome iz koje elektrane dolazi struja. Isto tako korisnik raunalnog Grida ne vodi rauna o
tome gdje se skladite i obrauju podaci koje treba.
Gledano s tehnike strane za takvu uslugu potrebno je postii slino onome to je ve davno
krajem 19. stoljea napravljeno u koritenju elektrine struje. Tada se od izoliranih
pogona/elektrana i gradova/elektrana, koritenjem efikasnog standardiziranog izmjeninog
sustava prijenosa energije, prelo na posve novu paradigmu opskrbe elektrinom energijom
elektrinu mreu (electrical Grid).
U sustavima s veim brojem korisnika koji dijele istovjetne resurse esto je mogue postii
bolju iskoritenost sustava uz istodobno vei vrni kapacitet zbog vremenskog
nepodudaranja optereenja. Dijeljenje resursa podrazumijeva i njihovu koncentraciju to
opet dovodi do niih trokova. Stoga se javlja opravdan interes za udruivanje i dijeljenje
resursa.
Slijedee slike pokazuju primjere koritenje resursa od pojedinanog korisnika. Primjetno je
da vrno optereenje je znatno vee od prosjenog.

Slika 1.2. Koritenje CPU / Koritenje elektrine energije u stanu

Slijedea slika pokazuje kako zajedniko dijeljenje resursa moe pridonijeti efikasnijem
koritenju.

Slika 1.3. Zajedniko dijeljenje resursa

Kako je i povezivanje elemenata elektrine mree sadravalo niz izazova koji su vremenom
rijeeni (velika uloga Nikole Tesle!) tako i povezivanje raunalnih resursa imaju analogne
izazove:

prevladavanje heterogenosti raunalnih resursa

prevladavanje barijera vlasnitva i lokacije resursa

regulirano koritenje resursa

1.2.1 E-znanost
Evolucija Grid sustava poinje sredinom 90-tih. Kao i niz drugih tehnologija (npr. Internet)
poetno se javlja u znanosti gdje stalno postoji potreba za obradom i pohranom velike
koliine podataka. To je naroito izraeno u podrujima geofizike, fizike, astronomije, kemije
i drugima, a to je zajedniki oznaeno kao eZnanost (eScience). Da bi se potaknuo razvoj
eZnanosti potaknute su mnoge internacionalne i nacionalne inicijative iji cilj je bio da se
potakne ulaganje u zajednike raunalne resurse i specijaliziranu opremu, te utvrde naini
efikasnog zajednikog koritenja.
Jedna od prvih inicijativa bila je unutar CERN organizacije koja je potekla od potreba obrade i
pohrane podataka generiranih od strane LHC eksperimenta. etiri detektora generiraju
podatke reda veliine PB/god i ukljuuju preko 2000 korisnika i 150 institucija u obradi istih.
Obrada takve koliine podataka bila je iznad mogunosti jedne organizacije i kao takva
zahtijevala je udruivanje resursa ukljuenih istraivakih organizacije. tovie CERN nije bio
samo inicijativa ve u okviru CERN-a djeluje vie raunalnih timova koji su dali te i dalje daju
znaajan doprinos razvoju komponenti Grid-a.

Slika 1.4 Hijerarhija CERN-LHC obrade podataka

U okviru CERN-a zaeta je i ira inicijativa EGEE (Enabling Grid for E-SciencE) za podruje EU i
koja obuhvaa 50-ak zemalja. Inicijative ovakvog opsega imaju zadatak odabira i
standardizacije tehnologija koje e se koristiti.
1.2.2 Poslovna primjena
U poslovnoj primjeni raunalni sustav treba omoguiti korisniku da za uloena sredstva
dobije vrijednost koja e mu omoguiti da se konkurentno natjee na tritu. Dananja
globalna ekonomija zahtijeva od poduzea neke nove karakteristike poput visoke agilnosti,
globalizacije aktivnosti i poveane mobilnosti. Posebno je bitna agilnost tj. da se u svakom pa
i informatikom pogledu odgovori na brze eksterne i interne promjene.
Veina postojee IT infrastrukture u poduzeima nije dovoljno fleksibilna tj. ne moe se
dovoljno brzo ni predvidljivo adaptirati promjenama u poslovanju. Na tom podruju
virtualizacija resursa , njihova integracija te uvezivanje moe podii agilnost.
Globalizacija poslovanja namee izgradnju globalne-distribuirane informatike infrastrukture
poduzea kako bi se efikasno podralo lokalno poslovanje.
U isto vrijeme i korisnici unutar poduzea postaju sve vie mobilni i ele sa bilo koje pozicije
koristiti sustav na isti nain. Osim toga sve je vea koliina senzora koji prate procese u
poduzeu i koji distribuirano generiraju podatke koje je potrebno obraditi u sustavu.
Postavlja se pitanje koji su to elementi Grid sustava koji se poklapaju s ovim zahtjevima.
Pokazalo se da je trend u distribuciji i decentralizaciji IT resursa u suprotnosti s efikasnom
upotrebom koja zahtijeva konsolidaciju.
Za distribuirane raunalne centre karakteristini su slijedei vezani problemi:

Stalna potranja za procesnim i resursima pohrane kako bi se pokrila lokalna vrna

optereenja

To rezultira u veem broju slabo iskoritenih podatkovnih centara

Mnogo vei trokovi (raunala, napajanje, hlaenje) nego za konsolidiranu obradu

CO2, CO2, .... sve skuplja energija

Grid raunalne tehnologije su meu prvima koje su pokuale reducirati broj raunalnih
vorova u distribuiranim raunalnim centrima kako bi se postigla vea iskoritenost
distribuiranih i heterogenih resursa unutar poduzea.
Napredak u tehnologiji virtualizacije omoguio je znaajan stupanj razdvajanja fizikih
raunalnih resursa i aplikacija, to je dovelo do vee prihvaenosti Grid koncepata te kao
nadgradnje razvoja Cloud koncepta kao slijedeeg stupnja konsolidacije tj. outsourcinga
raunalnih resursa vanjskim opskrbljivaima.
ire prihvaanje Grid sustava u poslovnom okruju jo nije predvidljivo zbog niza razloga:

Grid tehnologija je kompleksna i jo nije jasno koji su najbolji naini primjene

Poduzea u odnosu na eZnanost imaju niz posebnih zahtjeva, posebno vezano za

sigurnost i pouzdanost

Mnogi poslovni procesi ne mogu se efikasno preslikati na Grid infrastrukturu tj.

efikasnije se izvode na sustavima posebne namjene

1.3 Definicija Grid raunalnih sustava

Pojam Grid poetno se javio u znanstvenim krugovima (eScience) kao sinonim za uvezivanje
skupa tehnologija iz podruja distribuiranog raunalstva, raunalstva u grozdu i HPC. See u
90-te godine kada se javlja umreavanje snanih raunala u grozdove pomou
visokopropusnih mrenih veza s ciljem da se omogue zahtjevni znanstveni prorauni ili
obrade podataka. Kako bi se naglasilo da se za raunalnu obradu ne koristi jedno raunalo
ve odabrani resursi skupine raunala koristili su se pojmovi hyper-computing i metacomputing. Osim toga razvoj Interneta donosi i povezivanje samih grozdova te mogunost
udaljenog koritenja od strane korisnika.
Daljnji razvoj takvih sustava pokazuje vrlo veliku slinost s elektrinom mreom (electrical
Grid) bilo u strukturi sustava bilo u nainu koritenja. Stoga se pojam Grid poinje koristiti i u
raunarstvu.
Jedan od kljunih elemenata evolucije Grid sustava je beavna integracija geografski
distribuiranih i heterogenih sustava tako da se korisniku omogui transparentno koritenje
servisa sustava. Korisnici se ne bi trebali brinuti o lokaciji i vlasnitvu resursa. Sa strane
korisnika treba postojati samo jedna toka ulaza u sustav. Oni alju svoj zahtjeve na taj ulaz,
a dalje je na Grid sustavu da locira dostupne i upotrebljive resurse. Korisnik ima utisak da
koristi jedinstven virtualni raunalnih sustav vrlo visokih performansi.
Iz toga doba see i jedna od najcitiranijih definicija Grid raunalstva (Foster and Kesselman 1998) :

A computational Grid is a hardware and software infrastructure that provides dependable,

consistent, pervasive, and inexpensive access to high-end computational capabilities.
U prijevodu : hardversko/softverska infrastruktura pouzdanih, konzistentnih, sveprisutnih i
cjenovno dostupnih raunalni resursa visokih performansi.
Ve na primjerima hyper(meta)-computinga u okviru raunalnih grozdova postalo je
evidentno da dijeljenje resursa nije samo bitno za znanstveno, ve i za niz drugih podruja.
tovie postaje jasno da se dijeljenje resursa moe izvesti i generiki tj. bez obzira na
primjenu. To je postavilo niz izazova za razvoj hardversko/softverskih rjeenja koje e
omoguiti generiko dijeljenje razliiti oblika raunalnih resursa. Ti izazovi su oslikani
slijedeim citatom:
The real and specific problem that underlies the Grid concept is coordinated resource sharing
and problem solving in dynamic, multi-institutional virtual organizations. The sharing that we
are concerned with is not primarily file exchange but rather direct access to computers,
software, data, and other resources, as is required by a range of collaborative problemsolving and resource brokering strategies emerging in industry, science, and
engineering. (Foster et al. 2001)
Kako je ve navedeno, od pojave do danas pojam Grid koristio se za niz raunalnih
tehnologija, trita i rjeenja. Postoje raunalni sustavi koji imaju navedene karakteristike, ali
da bi to bio Grid sustav treba zadovoljiti dodatne karakteristike. Ian Foster (2002) daje tri
testna pitanja za odreivanje da li je raunalni sustav Grid sustav:

Da li je koordinacija resursa bez sredinje kontrole ?

Da li je zasnovan na otvorenim standardima ?

Da li je prihvatljiva kvaliteta servisa ?

Odgovor bi trebao biti pozitivan na sva pitanja. Navedena pitanja opet naglaavaju analogiju
s elektrinom mreom. Elektrina mrea je uvezana na svjetskom nivou, nema sredinju
kontrolu, koristi usuglaene i otvorene standarde i moe na gotovo svakoj prikljunoj toki
dati korisniku prihvatljivu kvalitetu servisa.
Ipak resursi koje isporuuje Grid raunalni sustav su raznovrsniji od struje/napona u
elektrinoj mrei. Resursi koji se dijele u Grid sustavu se mogu podijeliti u:

Raunalna/procesna snaga

Pohrana podataka

Mrena propusnost

Aplikacije

Znanstveni instrumenti senzori

Od navedenih resursa danas samo mrena propusnost koja se veim dijelom realizira kroz
Internet daje pozitivan odgovor na Fosterova testna pitanja. Svi ostali elementi su jo u
razvoju i trebat e neko vrijeme da se Grid s potpunim pravom moe pisati velikim poetnim
slovom. Zasad imamo niz razliitih raunalnih sustava koji u svojoj podlozi vie ili manje
implementiraju razliite Grid tehnologije.

1.4 Definicija Grid pojmova

Kako je pojam Grid dosta openit koristit emo u daljnjem tekstu slijedee preciznije
definicije:

Grid midlleware : softver koji omoguava dijeljenje heterogenih resursa i uspostavu

virtualnih organizacija. To je virtualizacijski meusloj koji se postavlja izmeu resursa
(heterogeni) i korisnikih aplikacija.

Grid computing Grid raunalstvo :

o dinamika kolekcija heterogenih raunalni resursa (mrea, procesne jedinice,
pohrana podataka,...) koji su koritenjem Grid midllewarea korisniku
predoeni jedinstven virtualni raunalni sustav Grid infrastruktura
o ili programska paradigma aplikacija prilagoenih izvoenju na Grid sustavima

Utiliy computing usluno raunalstvo omoguavanje da se Grid infrastruktura i

aplikacije koriste kao usluga tj. bez posjedovanja, a na modelu plati koliko koristi.

1.5 Grid sustavi usporeeni s ostalim distribuiranim sustavima

Ostali distribuirani sustavi najee daju servise vezane za jedno organizaciju te imaju
centralizirano upravljanje. Grid sustavi nemaju centralizirano upravljanje i sustav korist veliki
broj organizacija. Ostali distribuirani sustavi najee imaju heterogene resurse, ali
heterogenost je limitirana politikom jedne organizacije. Heterogenost Grid sustava je
naglaena neovisnou viestrukih organizacija. Ostali distribuirani sustavi najee koriste
klijent-server model u kojem se dijeli neki informacijski resurs. Grid sustavi ne dijele samo
informacije , ve i hardver i aplikacije. Za razliku od ostalih distribuiranih sustava , Grid
sustavi podravaju otkrivanje resursa i nadgledanje istih na globalnoj skali. Distribuirani peerto-peer sustavi omoguavaju globalne servise, ali vrlo specijalizirane i bez puno brige o
kvaliteti servisa te sigurnosnim aspektima.

1.6 Arhitektura i funkcionalnost Grid sustava

Grid arhitektura daje pregled osnovnih komponenti Grid sustava, njihovu svrhu i
funkcionalnost i nain na koji su povezane. Glavni fokus je na interoperabilnosti i
protokolima koji omoguavaju dijeljeno koritenje resursa od strane korisnika/aplikacija. Po
Fosteru i Kesselmanu (2004) protokoli su organizirani u slojeve poput prikaza na slijedeoj
slici: Fabric layer, Connectivity layer, resource layer, Collective layer, Application layer

Slika 1.5. Opa arhitektura Grid sustava (Foster et.all. 2001)

Fabric layer (fabriki sloj): to su fiziki resursi koji se dijele unutar Grid sustava. To bi bili
raunala, sustavi pohrane, mrena oprema, senzori zajedno s njihovim unutarnjim softverom
(firmware) koji im daje osnovnu funkcionalnost.
Connectivity layer : sadrava osnovne (standardizirane) komunikacijske i protokole
autentikacije koji su potrebni za ostvarivanje Grid funkcionalnosti. Omoguavaju izmjenu
podataka resursa fabrikog sloja. Najznaajnije su funkcije ovog sloja su transport,
usmjeravanje, imenovanje kao i podrka za sigurnu komunikaciju. Pri tome sigurna
komunikacija treba imati svojstvo da korisnik jednom prijavom/autentikacijom dobiva
mogunost da koristi sustav i da dobivena prava moe delegirati aplikaciji koju pokree u
sustavu.
Resource layer: koristi komunikacijske i sigurnosne protokole prethodnog sloja za upravljanje
sigurnim pregovaranjem, inicijalizacijom, nadgledanjem, raunovodstvom i naplatom
resursa.
Collective layer: odgovaran je za upravljanje resursima na globalnoj razini te interakciju
kolekcije resursa. Kolektivni sloj primjenjuje niz servisa dijeljenja resursa. Najbitnije
funkcionalnosti ovog sloja su: imenici, koalokacija, servisi rasporeda i brokeringa,
dijagnostiki i monitoring servisi te servisi replikacije podataka. Na ovom sloju se realizira i
autorizacija na nivou organizacija i lanova organizacija, kao i regulacija koritenja servisa.
Application layer: ukljuuje aplikacije koje se isporuuju na Grid sustav. Bitno je naglasiti da
se ne moe svaka aplikacija isporuiti na Grid. Samo aplikacija (Grid enabled) koja je
dizajnirana ili modificirana da moe se paralelno izvravati na Grid infrastrukturi moe imati
dobiti od izvravanja na istoj.

1.7 Motivacija i koristi od koritenja Grid sustava i nedostaci

Koritenje Grid sustava posjeduje niz prednosti i potencijalnih dobitaka za razliite
organizacije i to na dva nivoa: na nivou upravljanja IT resursima omoguava sniavanje
ukupnih trokova, a na korisnikom nivou podie se agilnost, fleksibilnost i efikasnost
koritenja resursa.
Kljuna rije koja se danas vee za IT usluge je agilnost. Bilo da ste poduzee ili neka druga
ustanova koja treba obradu ili pohranu podataka koliina resursa (CPU,pohrana,mrea,..)
koju trebate nije stalna veliina. Ona najee prati poslovnu aktivnost, a koja varira bilo
dnevno, tjedno, sezonski ili varira zbog porasta/pada poslovanja. ak i znanstvene
organizacije poput CERN-a ponekad trebaju velike resurse samo par mjeseci u tijeku obrade
podataka. Dakle korisnik eli imati resursa taman onoliko mu treba u nekom trenutku, s tim
da ima mogunost brze rezervacije ili otputanja resursa.
Grid sustavi omoguavaju suradnju izmeu viestrukih organizacija u dijeljenju resursa.
Organizacije mogu biti lanovi vie VO. Svaka od tih VO moe imati razliite politike
administrativne kontrole. Pripadnou nekoj od VO korisnici lanovi neke organizacije
osiguravaju prava na koritenje resursa pod kontrolom te VO.
Sumarno koristi su slijedee:

Grid saima heterogeni sustav u jedno veliko raunalo i stoga potencijalno moe
raunalnom zadatku dodijeliti ogromnu raunalnu snagu.
o Neki zadaci (job/task) se mogu razbiti u vie pod-zadataka, od kojih svaki
moe biti pokrenut na razliitom stroju. Npr. matematiko modeliranje,
simulacija subatomskih estica, renderiranje slika, 3D animacija. Takve
aplikacije se mogu napisati da se pokreu kao neovisni zadaci i rezultati podzadataka se kombiniraju kako bi se dobio eljeni izlaz.
o Meutim, ne mogu se svi zadaci razbiti na takav nain. Moe postojati i
ogranienje na koliko se pod-zadataka moe razbiti neki zadatak, to limitira
maksimalno poveanje performansi bez obzira na raspoloive resurse. Stoga
postoji ogranienje na vrste zadataka koje se mogu uspjeno izvravati u Grid
sustavu.

Dijeljenje resursa omoguava znatno vee iskoritenje nego kad korisnici koriste
zasebne resurse (zbog neistovremenosti zahtjeva za resursima).

Balansiranje omoguava ravnomjeran raspored zadataka na dostupne resurse.

Pretpostavimo da je neki dio Grida preoptereen. Grid algoritmi rasporeivanja moe
premjestiti neke od poslova na dijelove sustava koji su manje optereeni. Sve je to
opet transparentno za korisnika.

Ukupni trokovi posjedovanja raunalnih resursa (TCO) su obino nii za

konsolidirane resurse

Skalabilnost infrastrukture sustava je znatno vea jer su uklonjene umjetne IT granice

(prvenstveno heterogenost i mrena propusnost) izmeu grupa ili odjeljenja pa se
novi resursi lake dodaju.

Podie se robusnost i pouzdanost sustava zbog lake zamjenjivosti dijelova sustava, tj.
mogunosti da sustav nastavlja raditi nakon ispada pojedinih komponenti (uvijek
lake realizirati u veim sustavima)
o Pretpostavimo da je korisnikov posao poslan na izvravanje. Posao alocira
odgovarajue resurse (vor na Gridu) ovisno o dostupnosti i politici rasporeda
(schedulling policy) Grid sustava. Pretpostavimo pad vora dok izvrava posao.
Grid osigurava da se posao automatski ponovo poalje nekom drugom
dostupnom voru.
o Data Grid definiran je kao Grid za upravljanje i dijeljenje velike koliine
podataka. Moe se koristiti u razne svrhe. Jedna od njih je da se povea brzina
dohvata datoteka. Vie kopija podataka moe biti distribuirano na razliitim
geografskim pozicijama. Ako korisnik treba podatke oni mogu biti dohvaeni s
najblieg stroja koji dri podatke. Dalje, ako su neki od strojeva u data Gridu
iskljueni, drugi strojevi pruaju rezervu. Ako se zna (monitoring) da odreeni
stroj ee dohvaa odreene podatke, oni mogu biti smjeteni na neki bliski
stroj.
o Dakle, korisnik se ne brine ni o mjestu obrade niti o mjestu pohrane podataka.

Zbog intenzivnog koritenja virtualizacije mogue je uniformnije upravljanje

heterogenim distribuiranim resursima. Virtualizacija isto tako omoguava lake
uparivanje resursa sa zadacima.

Mogunost da se trokovi IT infrastrukture ne raunaju kao kapitalni nego operacijski.

Takav model omoguava da se lake financira IT infrastruktura , odnosno da dinamika
trokova lake prati dinamiku poslovanja.

Naravno postoje i izazovi koje ne treba zanemariti:

Grid raunalstvo je nova paradigma koja zahtijeva znaajne promjene u razmiljanju o

procesima obrade podataka. esto pojedini korisnici ili odjeljenja ele ba svoje
lokalne resurse jer nisu svjesni prednosti dijeljenja resursa te ujedno preuveliavaju
opasnosti dijeljenja resursa.

Nije dovoljno da se postojea razasuta IT infrastruktura transformira u Grid. Potrebna

su i znaajna ulaganja u prilagodbu aplikacija kako bi se ostvarile prednosti.

Nedostatak opeprihvaenih standarda za realizaciju Grid infrastrukture poveava

rizik ulaganja u istu

Prelazak na novu paradigmu je dugoroan projekt koji treba biti paljivo planiran
kako ne bi poremetio poslovanje sustava

U svakom pojedinanom sluaju svaka organizacija treba odvagati prednosti naprama

nedostacima te odluiti se i isplanirati tranziciju.

1.8 Klasifikacija Grid sustava

Grid raunalstvo se moe klasificirati s obzirom na slijedee kriterije:

S obzirom na resurse u fokusu koritenja

Opseg dijeljenja resursa

1.8.1 Klasifikacija s obzirom na resurse u fokusu koritenja

Iako je krajnji cilj Grid raunalstva omoguavanje dijeljenja svih vrsta raunalnih resursa.
Razliite inaice Grid midllewarea su se razvijale s fokusom na odreenu vrstu resursa. Stoga
se i danas pojedini Grid midlleware moe svrstati u slijedee kategorije:

Raunalni Grid, fokusiran na dijeljenje procesnih resursa (CPU)

Podatkovni Grid, fokusiran na upravljanje pohrane podataka u velikim heterogenim i

distribuiranim sustavima

Aplikacijski Grid, fokusiran na omoguavanje pristupa udaljenom softveru i

bibliotekama

Servisni (usluni) Grid, fokusiran na pojedine usluge (npr. mail usluge, sigurnosne
usluge,)

1.8.2 Klasifikacija s obzirom na opseg dijeljenja resursa

Ovisno o opsegu resursa koji se dijele mogu se razlikovati slijedei pristupi:

Cluster Grid (Grid grozd)

Enterprise Grid (Grid na nivou poduzea)

Utility Grid Service (Grid na nivou pruatelja usluga)

Partner/Community Grid (Partnerski/Zajedniki Grid)

1.8.2.1 Cluster Grid (Grid grozdova)

Grid grozd samo grozd je kolekcija skupno lociranih raunala povezanih visokopropusnom
lokalnom mreom i dizajniranih da se koriste kao jedinstveni procesni resurs.

Korisnici koji pokreu aplikacije na grozdu

Slika 1.6. Primjer organizacije grozda

Grozd je uobiajeno homogena cjelina. Njegove komponente se razlikuju primarno u

konfiguraciji (brzina CPU, memorija, prostor za pohranu) ali je osnovna arhitektura ista.
Vremenom postaju neto heterogeniji zbog dodavanja novog hardvera, ali se nastoji da svaki
vor ima bar isti OS. Grozd je lokalni resurs koji funkcionira unutar domene zatiene
vatrozidom, a upravlja se od strane jedinstvenog administrativnog entiteta koji ima
kompletnu kontrolu nad svakom komponentom.
Stoga Grozd u uem smislu i nije Grid jer inicijalno ne omoguava udruivanje i dijeljenje
resursa van domene. Ipak grozdovi su najee osnovni graevni elementi Grid sustava te
prvi korak prema Grid sustavu. CERN eksperimenti su se u poetku oslanjali na veliki, ali ipak
lokalni grozd. Danas se u okviru CERN-a govori o Worldwide LHC computing Gridu (WLCG).
1.8.2.2 Enterprise Grid (Grid na nivou poduzea)

Slika 1.7. Primjer Grid-a poduzea

Pojam Eneterprise Grid koristi se kada se Grid raunalstvo koristi u okviru jednog poduzea.
Sve komponente sustava i dalje funkcioniraju unutar vatrozida jednog poduzea, ali mogu
biti heterogene i fiziki distribuirane na razliite lokacije, a time i pripadati razliitim
administrativnim domenama. Koritenjem Enterprise Grid midllewarea svi raspoloivi resursi
mogu se prvo virtualizirati i zatim upravljati na unificiran i centraliziran nain. To omoguava
da se resursi alociraju procesima prema potrebi. U dijeljenje se mogu ukljuiti i
nespecijalizirani resursi poput desktop raunala. Takvi sustavi sadre bar osnovne sustave
nadgledanje, analizu i upravljanje pogrekama u sustavu. Najvei problem irenju ovakvih
sustava je nedostatak standardizacije pa su ovakvi sustavi najee nadgradnja postojeih
sustava (Oracle Enterprise Grid, Sun Grid Engine, HP Adaptive Enterprise, Aneka).
Jedan od primjera Grida na nivou poduzea jeste Enterprise Grid farmaceutskog poduzea
Novartis. 2003 su posjedovali oko 65000 desktop PC raunala s procjenom da je oko 90%
CPU vremena neiskoriteno. Istovremeno poduzee ima velike zahtjeve za proraunima
vezanim za nove lijekove (struktura bjelanevina). Isto tako sa strane sigurnosti poeljno je
da se prorauni odvijaju unutar poduzea. Uvezivanjem svih resursa postigli su da proraune
kojima treba 6 godina na jednom raunalu izvedu na Enterprise Gridu za 12 sati. Troak
implementacije Grid sustava bio je oko 350 000, a sustav je zamijenio najmanje 2 miliona
vrijednu opremu.
1.8.2.3 Usluni Grid sustav
Grid sustav koji je u posjedu tree strane i koji nudi/prodaje usluge procesiranja i pohrane
podataka najee po sustavi plati koliko koristi, nazivamo uslunim Grid sustavom. Takav
sustav djeluje izvan vatrozida korisnika. Jedan od najvei ponuaa takvih usluga je tvrtka
Amazon kroz svoj proizvod AWS (Amazon Web Services http://aws.amazon.com/). Korisnik
niti posjeduje Grid niti ima kontrolu nad njegovim djelovanjem. Korisnik alje/pohranjuje
podatke na usluni Grid, obrauje ih, vraa rezultate nazad. Tu se postavljaju pitanja
sigurnosti i privatnosti podataka. Korisnik mora procijeniti rizike za podatke koje alje vani
svog vatrozida. Meutim ovakav nain koritenja omoguava najveu fleksibilnost
(elastinost resursa) za korisnika.

Slika 1.8. Primjer povezivanja na usluni Grid

1.8.2.4 Partner Grid , Community Grid (Partnersk Grid , Grid zajednice)

Partnerski Grid sustav
Ideja partnerskih Grid sustava proistjee iz eScience podruja. Mnogi znanstveni istraivaki
projekti, posebno u prirodnim znanostima (npr. Opet CERN) zahtijevaju zajedniki rad
istraivaa irom svijeta. Time se otvara mogunost zajednikog koritenja (dijeljenja)
raspoloive IT infrastrukture od strane ukljuenih institucija. Takva kooperacija obino
rezultira u stvaranju jedne ili vie virtualnih organizacija (VO) unutar koji se realizira dijeljenje
resursa. Ovakva pojava nije ograniena samo na znanstveni svijet jer i velika poduzea mogu
na ovaj nain udruivati i dijeliti svoju infrastrukturu. U takvoj VO svaki partner daje na
raspolaganje dio svoje infrastrukture. Pri tom definira pravila koritenja ili prihvaa zajedniki
usvojena pravila koritenja.

Slika 1.9. Primjer VO na nivou eksperimenta

Arhitektura partnerskog Grid sustava moe se promatrati kao kolekcija neovisnih reursa
(grozdovi, sustavi pohrane i sl.) povezani preko Globalnog Grid midllewarea. Dostupni su
preko suelja/portala.
Hardver i operacijske platforme koje se koriste mogu biti heterogene. Dok jedan grozd moe
biti Linux/Intel drugi moe biti Solaris/Sparc. Tu heterogenost treba savladati Grid
midlleware. Zajednika infrastruktura podie pitanja sigurnosti i privatnosti na viu razinu.
Posebno osjetljivo pitanje u VO jeste tko koordinira upotrebu resursa. Najee to ini lan s
najveim resursima ili trea strana (npr. Grid appliance).
Grid zajednice
Grid zajednice se zasnivaju najee na donaciji slobodnih resursa privatnih korisnika.
Najpoznatiji primjer Grid zajednice je SETI@HOME ili Folding@home.

1.9 Osnovni elementi Grid midllewarea

Kako smo vidjeli Grid arhitektura je slojevita arhitektura. Prikaz na slijedeoj slici pokazuje
nam poloaj midllewarea u odnosu na ostale komponente sustava. Grid midlleware se nalazi
izmeu Fabric sloja (Mrea/resursi) i Application sloja (aplikacija/aplikacijski servisi) .

Slika 1.10. Slojevita Grid arhitektura

Middleware ukljuuje softver ili pakete koje koristimo za implementaciju Grida, poput
Globus Toolkita ili gLite. Grid midlleware se da grupirati po funkcionalnosti.
1.9.1 Sigurnost
Poeljno je da Grid sustav moe osigurati tri sigurnosna elementa.
To su:

pojedinana prijava (single sign-on)

autentikacija

autorizacija.

Pojedinana prijava znai da se korisnik moe jednom logirati u sustav i nakon toga moe
pristupati resursima sustava u odreenom vremenu. Autentikacija se odnosi na osiguranje
dokaza identiteta korisnika. Npr. kad se logirate na email raun , vi se autenticirate serveru
davanjem korisnikog imena i zaporke. Autorizacija je proces kojim se utvruju privilegije
pojedinog korisnika. Autorizacija se obavlja nakon autentikacije. Grid sustavi moraju
osigurati sustav za upravljanje vjerodajnicama (credential management) i delegaciju
privilegija.
1.9.2 Upravljanje resursima (resource management)
Grid mora obavljati optimizaciju upotrebe resursa kako bi se osigurala maksimalna
propusnost. Kad korisnik poalje posao na obradu, Grid sustav koristi servise otkrivanja
raspoloivih i odgovarajuih resursa. Komponenta Grid sustava koju nazivamo Grid
rasporeiva (Grid scheduller) ima zadatak da odlui na koji resurs i u koje vrijeme e poslati
odreeni zadatak. Odluka o rasporedu donosi se na osnovu niza faktora. Npr. ako su neki
poslovi oznaeni da ovise o izvrenju drugih poslova, rasporeiva to mora uzeti u obzir te
poslove izvravati sekvencijalno. Odluka o rasporedu takoer moe ovisiti o prioritetu posla
vezano za SLA.
1.9.3 Upravljanje podacima (data management)
Upravljanje podacima u Grid sustavima vezano je za razliite aspekte upravljanja velikom
koliinom podataka. To ukljuuje siguran pristup podacima, replikaciju i migraciju podataka,
upravljanje metapodacima, indeksiranje, raspored poslova koji vodi obzira o lokaciji
podataka (data aware schedulling). Data aware schedulling treba posjedovati algoritme
kojima e odrediti na kojemu je mjestu najpovoljnije izvriti neku obradu podataka s obzirom
na njihov smjetaj. Ponekad e to biti blizu lokacije podataka, a ponekad e zbog
preoptereenja procesnih resursa na lokaciji biti potrebno transferirati podatke na neko
drugo mjesto. Moduli za upravljanje podacima trebaju osigurati brz, siguran i pouzdan
mehanizam prijenosa podataka unutar Grid sustava.

1.9.4 Otkrivanje informacija i nadgledanje (Information discovery and monitoring)

Grid rasporeiva treba imati informacije o slobodnim resursima da bi odredio koje resurse
dodijeliti odreenom poslu. Ove informacije pribavlja servis za otkrivanje informacija. Unutar
ovog servisa odrava se lista raspoloivih resursa i njihov trenutni status. Kada Grid
rasporeiva postavlja upit servisu za otkrivanje informacija on obino postavlja ogranienja
na nain da trai resurse koji su relevantni (na kojima se posao moe izvriti) i najprikladniji
za izvrenje posla. Npr. moe traiti resurse ija procesna snaga omoguava izvrenje posla u
odreenom vremenu.
Servis za otkrivanje informacija mogu biti organizirani i hijerarhijski gdje servisi nieg nivoa
prikupljaju i konsolidiraju informacije te alju servisima vieg nivoa. Takav pristup je
uobiajen za Grid sustave.

1.9.5 Regulacija koritenja resursa

Grid se moe koristiti na nain da korisnik poalje zadatke na izvravanje i dobije izlazne
rezultate, a onda se korisniku naplauje koritenje resursa na osnovu neke metrike, poput
procesorskog vremena potrebnog za izvrenje zadatka. U takvim sluajevima gdje se vodi
neka vrsta raunovodstva za usluge pruene korisniku, korisnik oekuje i odreenu kvalitetu
servisa. To se specificira u service level agreement (SLA). SLA specificira minimalnu kvalitetu
servisa, dostupnosti, itd. , te cijene koritenja usluga. Moe se za odreenu cijenu korisniku
ponuditi i prioritet u izvravanju zadataka tj vii nivo QoS. Isto tako mogue je izvriti
rezervaciju resursa za velike poslove. rezervacijom se moe postii da Grid u trenutku pojave
vaeg velikog posla, (preemptivno) prekine niz poslova u izvravanju te na osloboene
resurse rasporedi vae poslove. ini vam se da se ponavlja pria koja vai i za druge
distribuirane sustave. Ono to je novo u Grid sustavima je da sve ovo treba funkcionirati za
korisnike ukljuene u viestruke organizacije te sa minimumom centralne kontrole.

1.10 Osnovni Grid standardi

Ovdje je dan pregled nekih otvorenih standarda koritenih u implementaciji Grid sustava.
Iako je razvoj Grid midllewarea poeo i prije pojave standarda vezanih za Web servise tek je
nakon toga dolo do breg razvoja Grid midllewarea. Primjer je npr. CERN-ov Grid
midlleware AliEn(Alice environment) koji ini podlogu gLite midllewrea. Napisan je u Perl
jeziku, a glavna motivacija koritenja Perl jezika je pojava SOAP::Lite modula za Perl koji je
koritenje Web servisa pojednostavnio do krajnjih granica.
1.10.1 Grid servisi kao ekstenzija Web servisa
OGSA (Open Grid service architecture) definira Grid servise kao ekstenziju web servisa.
Relevantni standardi na kojima se zasnivaju Web servisi su:
etiri glavne specifikacije vezane za web servise su:
1. eXtensible Markup Language(XML) - je jezik zasnovan na oznakama iji je cilj
koritenje zajednikog formata za izmjenu podataka kroz razliita suelja. Sve poruke
koje se izmjenjuju kroz web servise koriste XML format.
2. Simple Object Access Protocol(SOAP ) - je komunikacijski protokol zasnovan na
porukama kojeg mogu koristit dvije strane u komunikaciji preko Interneta. SOAP
poruke se zasnivaju na XML protokolu i stoga su neovisne o platformi i jeziku. SOAP
poruke se obino transmitiraju preko HTTP protokola pa tako za razliku od RPC ili
CORBA poruka lako izlaze na kraj s vatrozidima.
3. Web Service Denition Language(WSDL)- je XML dokument koji se koristi za opis
suelja web servisa.
4. Universal Description, Discovery and Integration (UDDI) - je na XML zasnovan
registrator (registry) koji slui za pronalazak web servisa na Internetu. To je
specifikacija koja omoguava da pojedini pruatelj web servisa prui informacije o

sebi i o ponuenim web servisima. Tu se nalazi informacija kako pronai i kako se

vezati na odreene web servise.
Apliciranjem standarda Web servisa Grid protokoli i servisi mogu biti enkapsulirani i
opisani u standardiziranom obliku (vidi slijedeu sliku). Koritenje Web servisa kao suelja
omoguilo je ne samo dijeljenje resursa, ve dijeljenje i interoperabilnost modula iz
razliitih Grid razvojnih inicijativa.

Slika 1.11. Mjesto Web servisa u Grid arhitekturi

1.10.2 Open Grid service architecture (OGSA), Open Grid services infrastructure (OGSI)
Godine 2002, Globus project i IBM inicirali su razvojni projekt kojim se postiglo usklaenje
Grid raunalstva s Web servisima. To je rezultiralo s OGSA arhitekturom. OGSA definira
funkcionalnost niza web servisa potrebnih za implementaciju Grida te ih naziva Grid
servisima. Ovim standardom se nastoji da pojedini servisi poput otkrivanja resursa,
upravljanja resursima, sigurnosti , itd. poprime standardiziranu formu. Definira i niz ne
nunih, ali korisnih servisa za Grid sustave.
OGSA je slojevita arhitektura s jasnom separacijom funkcionalnosti svakog sloja koja je
prezentirana na slijedeoj slici.

Slika 1.12. Pregled OGSA arhitekture

1.11 Evolucija Grida prema Cloud raunalstvu

Kako vrijeme ide sve sastavne tehnologije Grid sustava sazrijevaju: Postaje mogua
integracija heterogenih fizikih resursa u jednu virtualiziranu cjelinu dostupnu s jednog
mjesta. Grid tehnologija omoguila je novi poslovni model koritenja uslunog raunalstva,
odnosno opskrbu raunalnim resursima prema potrebi na bazi plati koliko potroi.
Dok veliki proizvoai hardvera (npr. IBM, HP) guraju Grid tehnologije, dotle isporuioci
softvera (npr. Microsoft, SAP, Oracle) guraju SaaS tehnologije. I jedno i drugo predstavlja
eksternalizaciju bilo hardvera ili softvera.
Slijedea slika prikazuje trendove u razvoju.

Slika 1.13. Trend razvoja Grid->Cloud

Usluno raunalstvo i SaaS su dva komplementarna trenda: usluno raunalstvo moe postati
trino uspjeno samo ako postoji kritina masa aplikacija koje e se pogoniti na njemu. SaaS
treba za izvoenje odgovarajuu infrastrukturu. Prema tome slijedei prirodni korak bio bi
ujedinjenje dvaju trendova uz sljedee smjernice:

Skalabilna, fleksibilna, robusna i pouzdana fizika infrastruktura

Platformski servisi koji omoguavaju iskoritenje fizike infrastrukture kroz apstraktna

suelja

SaaS razvijen, isporuen i pokretan na fleksibilnoj i skalabilnoj infrastrukturi

Sve ovo dobivamo s novom online platformom koja se naziva raunalstvo u oblaku (Cloud
computing). Dakle raunalsvo u oblaku je konvergencija Grid raunalstva, uslunog
raunalstva i SaaS. Predstavlja najnoviji korak u stalnom trendu eksternalizacije IT resursa,
poput raunalnog procesiranja, pohrane, poslovnih aplikacija tj. nabavom istih kao servisa.

1.12 Kratak pregled Grid projekata

Razvoj Grid projekata potaknut je s ciljem rjeavanja raznih znanstvenih problema koji
zahtijevaju velike raunalnih resursa kao i to generiraju velike koliine podataka. Npr. CERN
je pustio u pogon jedan od najveih znanstvenih instrumenata Large Hadron Collider (LHC).
Ovaj ureaj u svakodnevnom radu generira ogromne koliine podataka koje treba pohraniti,
obraditi i opet pohraniti rezultate obrade. Radi se o koliini obrade i podataka koju ni jedan

super-raunalo ne moe obraditi. Zato je odabrana Grid arhitektura (kao virtualno superraunalo!). LHC je potaknuo niz istraivakih projekata diljem Europe. U Americi je vie
panje posveeno Gridu kao openitoj strukturi za raunalne probleme. Globus projekt je
producirao Globus toolkit koji se iroko koristi za konstrukciju Grid sustava. rasporeiva
poslova razvijen u okviru Condor projekta dao je znaajan doprinos HPC-u. I u drugim
dijelovima svijeta radi se na znaajnim Grid projektima.
1.12.1 Ameriki projekti
Globus projekt uglavnom se bavi tehnologijama vezanim za Grid infrastrukturu te izdaje i
odraava skup softverskih alata Globus toolkit (GT). GT sadrava slojevit niz Grid alata
potrebnih za realizaciju osnovnih servisa vezanih za sigurnost, otkrivanje resursa, upravljanje
resursima, komunikaciju, itd. U posljednjim verzijama zasnovan je na web servisima.
Open Science Grid(OSG) je Amerika Grid infrastruktura za znanstveno istraivanje. U okviru
OSG organizirana je ogromna koliina raunalnih i sustava pohrane podataka. Trenutno
obuhvaa 50-ak lokacija irom SAD, Azije i June Amerike. Sastoji se od dva Grid sustava.
Integracijskog Grida i Produkcijkog Grida. Integracijski Grid namijenjen je znanstvenoj
zajednici te razvoju aplikacija i servisa. Produkcijski Grid namijenjen je industriji i osigurava
stabilno procesno i okruenje za pohranu podataka. Produkcijski servisi su Computing
Element (CE), Storage Element (SE), Virtual organization (VO), Membership service i Service
Catalouge.
TeraGrid je Grid sustav koji se sastoji od high-end raunalnih i resursa pohrane podataka
distribuiranih na 7 lokacija. Za taj sustav razvijen je poseban softver nazvan Common
TeraGrid Software Stack (CTSS). CTSS je instaliran na svim raunalima to osigurava
homogenost servisa potrebnu za odreene Grid aplikacije.

1.12.2 Europski projekti

EGEE (Enabling Grids for E-sciencE) je projekt koji nastoji osigurati raunalne resurse kako za
akademsko istraivanje tako i za industriju. EGEE Grid je tzv. worldwide Grid te korisnici nisu
limitirani geografskom lokacijom. Trenutno EGEE osigurava stabilnu i robusnu Grid
infrastrukturu (>30000CPU, >5PB za pohranu podataka), te obuku korisnika. Ovaj Grid se
koristi za razliite namjene. Trenutno aplikacije se mogu podijeliti na dva podruja. fizika
visokih energija (HEP) i biomedicina.
D-Grid inicijativa je Njemaka Grid platforma. Orijentirana je prvenstveno na znanstvenu
zajednicu tj. procesiranje i pohranu znanstvenih podataka.
CERN Zbog potrebe za pohranom i statistikom analizom velike koliine podataka CERN je
posluio kao inkubator za razvoj velikog broja tehnologija dananjih Grid sustava. Skup Grid
middleware rjeenja razvijen u okviru Alice eksperimenta AliEn (Alice Environment) je
osnova gLite midllewarea. AliEn je bio prvi Grid middleware zasnovan na web servisima.
I dalje svaki od trenutno 4 eksperimenta sudjeluje u razvoju specifinih Grid rjeenja. U
okviru CERN-a djeluje WLCG (Worldwide LHC Computing Grid) koji okuplja 170 raunalnih
centara u 34 zemlje.

GEANT je projekt nastao suradnjom 30 Europskih zemalja. Sastoji se od vie od 20

nacionalnih istraivakih mrea (NREN) . Njegov cilj je bio razvoj gigabitne mrene okosnice
(backbone) na Europskom nivou. Jedan od ciljeva je i osiguranje QoS unutar mree. Projekt
Geant je u stalnom irenju kapaciteta.
Cro-Grid je hrvatska inicijativa iji je cilj povezati grozdove u mreu koristei CARNet i to na
nain da su na raspolaganju znanstvenoj i akademskoj zajednici te da ih se moe ponuditi
gospodarstvu.

2. UPRAVLJANJE PODACIMA
2.1 Uvod
Kako Grid sustave moemo podijeliti u raunalne Gridove i podatkovne Gridove, upravljanje
s podacima u Grid sustavima moemo promatrati u okviru raunalnih Gridova ili kao zasebnu
kategoriju. Zasebno gledano to znai sustav za distribuiranu pohranu podataka koji podrava
pristup, sinkronizaciju i koordinaciju distribuiranih podataka pohranjenih na meusobno
udaljenim mjestima.
U prvoj definiciji smatramo da ne postoji znaajan prijenos podataka tj. da je problem
raunanja izraeniji nego problem prijenosa podataka. Tada se obino podaci mogu prenijeti
zajedno s izvrnom datotekom na mjesto raunanja.
Druga definicija fokusira se na procesiranje velike koliine distribuiranih podataka. To su
podaci koji zbog svog opsega i intenzivnog pristupa istima ne mogu se pohraniti na jednom
mjestu (serveru) bilo zbog procesnih kapaciteta servera ili mrene propusnosti.
Jedno od rjeenja je primjena data Grida kojim se podaci distribuiraju po razliitim
lokacijama (lokalno ili udaljeno) te se nastoji iskoristiti procesna snaga i kapacitet
pojedinanih resursa kako bi se postigla ujednaenje optereenja.

Slika 2.1. Globalni datoteni sustav

DDBMS (distributed database management system) i data Grid se koriste sline okoline
(fiziki distribuirana mrea), ali postoje razlike. Data Grid je u potpunosti heterogen to se
nastoji izbjei kod DDBMS-a. Heterogenost se oituje u razliitoj reprezentaciji podataka i
razliitim sustavima za pohranu podataka. DDBMS uobiajeno koristi homogene izvore
podataka. Drugo, DDBMS moe u potpunosti kontrolirati podatke tj. operacije kao to su
insert, delete, update su atomine operacije koje osiguravaju konzistenciju svih podataka.
Data Gridovi obino nemaju potpunu kontrolu izvora podataka. To znai da mogu dopustit

istovremene operacije pisanja i itanja (posljedice?). Kao posljednje, data Gridovi operiraju s
mnogo veim koliinama podataka te sustav mora biti izrazito skalabilan.

2.2 Zahtjevi upravljanja podacima

U okruju Grid sustava podaci su geografski disperzirani i heterogeni. Tradicionalni naini
upravljanja podacima poput insert,delete i update operacije koje se koriste u relacijskim
bazama podataka nisu prikladni za data Grid. Sagledavajui karakteristike podataka u data
Gridovima moemo doi do zahtjeva za upravljanje.
2.2.1 Statiki podaci i dinamiki podaci
Podatke u data Gridovima moemo podijeliti na statike i dinamike. Statiki podaci su oni
koji nakon to su generirani samo se itaju i analiziraju, ali se nikada modificiraju ili auriraju.
Primjer takvih podataka je npr. DNA podaci. Nakon to su oitani i pohranjeni na jedno ili
vie mjesta pohrane, DNA podaci se u analizama samo usporeuju. Dinamiki podaci, poput
podataka u poslovnim aplikacijama predmet su uestale promjene poput auriranja,
transakcijskih operacija, praenja stanja eksternih sustava.

Slika 2.2. Statiki(DNK,medicinske snimke) i dinamiki podaci (stanje burze)

U sluaju statikih podataka skup operacija je relativno jednostavan. Operacije obuhvaaju

pristup podacima i pomicanje podataka na vor obrade te vraanje rezultata korisniku
obrade. Takav nain obrade pogodan je samo za neke tipove Grid aplikacija jer Grid aplikacije
osim to itaju podatke mogu i generirati podatke. Osim toga mogu premjetati podatke
izmeu razliitih lokacija pohrane. Podaci mogu biti replicirani na nizu lokacija to u sluaju
da se radi o dinamikim podacima uvodi problem sinkronizacije. Pohrana na heterogenim
sustavima dovodi do potrebe realizacije unificiranog naina pristupa. Ako neki proraun
treba podatke koji su disperzirani na vie sustava pohrane treba postojati mehanizam
njihove integracije.
Prema svemu navedenome osnovni problemi koje treba efikasno rijeiti upravljanje
podacima u Grid sustavu su:

unificiran pristup podacima

replikacija podataka

sinkronizacija podataka

integracija podataka

prijenos podataka

2.3 Funkcije upravljanja podacima u Grid sustavima

2.3.1 Upravljanje replikama podataka
Replikacija podataka uvedena je u Grid sustavima kao metoda potreban za optimizaciju
pristupa podacima. Identine kopije (replike) podataka se kreiraju i distribuiraju na razliite
lokacije pohrane podataka. Korisnici, odnosno njihove aplikacije mogu pristupiti najbliim
replikama umjesto da uvijek pristupaju originalnim podacima te time reducirati latenciju u
pristupu podacima. Servis za upravljanje replikama (data replication management service
RMS) odgovoran je za slijedee:

kreiranje replike skupa ili dijela skupa podataka,

operacije dodavanja, brisanja i modificiranja replika,

registracija novih replika u RMS,

katalogiziranje registriranih replika na nain da korisnici mogu dobiti informacije o

pristupu replikama,

selektiranje replika prema kriterijima koji najbolje odgovaraju zahtjevima korisnika

odnosno aplikacija,

odravanje konzistencije izmeu replika na nain da se automatski auriraju replike

nakon to je originalni podatak izmijenjen.

2.3.2 Upravljanje meta-podacima

Meta-podatak je opisna informacija o podacima. Pojam je stariji od Grid sustava. Npr. metapodaci se mogu koristiti za upravljanje bibliotekom knjiga. U tom primjeru meta-podaci su
relevantne informacije o knjigama koje su zapisane na kartice. Korisnik moe preko kartica
dobiti informacije o eljenoj knjizi. To su uobiajene informacije poput: naslov knjige, kljune
rijei, naziv autora, ... Dakle pomou meta podataka opisujemo iri izvor informacija te
omoguavamo njegovo lake pronalaenje i kombiniranje s drugim izvorima podataka. Metapodaci omoguavaju da korisnik preko informacija o pojedinim skupovima podataka obavlja
zahtjeve, lociranje, pristupanje i upravlja podacima.

2.3.3 Objava i otkrivanje (publication and discovery)

Funkcije objave i otkrivanja zasnivaju se na servisima meta-podataka. Objava podataka znai
vezivanje atributa za skup podataka te omoguavanje da korisnici imaju pristup istima ime

se omoguava efikasnije istraivanje podataka. Ponekad proces objave u generiranju atributa

pojedinog skupa podataka koristi ve postojee meta-podatke u sustavu.
Otkrivanje podataka je proces odreivanja skupa podataka i njihovih lokacija bez navoenja
identifikatora podataka, a na osnovu upita koji sadrava:

vrijednosti pojedinih atributa iz skupa meta-podataka

specifikacije interne strukture podataka: veliina , nain pristupa, vlasnitvo.

Nakon otkrivanja skupa podataka korisnik dobiva informaciju o zahvaenom skupu podataka
te nakon toga moe dalje pristupati istima.
2.3.4 Transport podataka
Zbog distribuiranosti podataka u Grid sustavima operacije u Grid sustavima ukljuuju veliki
broj prijenosa podataka. Stoga upravljanje podacima zahtijeva brz i pouzdan mehanizam za
prijenos podataka. File transfer protocol (FTP) je jedno od rjeenja. FTP realizira efikasnu
transmisiju podataka kroz mreu, bilo LAN ili WAN. Za potrebe Grid sustava razvijen je i
usvojen GridFTP protokol koji zajedno s Grid Security Interface (GSI) omoguava brz,
pouzdan i siguran prijenos podataka. GridFTP u svojim funkcijama prua sve aspekte koje bi
trebao imati uspjean prototip prijenosa podataka u Grid sustavima:

Velika brzina prijenosa podrka za razliite transportne protokole preko mree. Za

potrebu breg prijenosa podaci se mogu slati paralelno.

Stripped data transfer velike datoteke se mogu particionirati u manje blokove i

svaki se blok neovisno alje. Podaci se agregiraju na odreditu.

Partial file transfer mogunost slanja dijela datoteke umjesto cijele.

Third-party control of transfer korisnik ili aplikacija moe upravljati prijenosom

podataka izmeu dva vora s treeg vora. Moe pokrenuti, nadgledati i upravljati
prijenosom.

Restartable transfer ako doe do prekida transfera isti se moe nakon oporavka
nastaviti od mjesta pogreke.

Automatska TCP optimizacija

2.3.5 Translacija i transformacija podataka

Translacija podataka podrazumijeva promjenu formata podataka uz to manju promjenu
sadraja podataka. Transformacija podataka znai derivaciju informacije u neku drugu formu
(npr. fourierova transformacija). Translaciju i transformaciju podataka moe obaviti i sama
aplikacija, ali ako se potreba za odreenom translacijom/transformacijom javlja esto i za
druge aplikacije, potrebno je razmisliti o njenom ugraivanju u servise prijenosa podataka.

2.3.6 Sinkronizacija podataka

U statikim okolinama sve replike su read-only (samo za itanje), te uz operacije kopiranja na
druga mjesta ne postoje problemi sinkronizacije. Meutim u veini Grid sustava podaci se
osim transferiranja i mijenjaju od strane korisnika ili aplikacija. U idealnom sluaju svaka
distribuirana replika (lokalna ili udaljena), ukljuujui i originalne podatke dri se u potpunoj
konzistenciji. Meutim to je vrlo nepraktino za Grid sustave. U stvari esto korisnici ne
trebaju potpunu konzistenciju. Moemo smanjiti stupanj konzistencije na nain da dozvolimo
da neki dio podataka bude nekonzistentan u odreenim vremenskim trenucima. Slijedi pet
stupnjeva konzistencije poevi od najlabavijeg do najstroeg (sve operacije se obavljaju
sekvencijalno) :

Mogua nekonzistentna kopija (Consistency Level -1) . Dozvoljeno je kreiranje replike

uz viestruke operacije pisanja u datoteku. Rezultirajua datoteka ne odgovara stanju
originalne datoteke u bilo kojem vremenskom trenutku.

Konzistentno kopiranje datoteka (Consistency Level 0). Na ovom stupnju sadraj

replike moe odgovarati sadraju koji je original imao u nekom vremenskom
trenutku. Postie se na nain da se datoteka kljua na nain da se dozvoljavaju
viestruke operacije itanja, ali samo jedna operacija pisanja tijekom kreiranja replike
(read shared lock).

Konzistentna transakcijska kopija (Consistency Level 1). Tijekom kreiranja replike ne

dozvoljava se pisanje u originalnu datoteku. Garantira se da ne postoji
nekonzistentnost unutar jedne datoteke, ali ne i izmeu svih replika jer izmeu
kreiranja pojedinih replika mogue je mijenjanje originala.

Konzistentan skup transakcijskih kopija (Consistency Level 2). Ako sve replike za neko
mjesto pohrane (site) kreiramo u jednom transakcijskom postupku onda moemo
garantirati konzistentnost novo-kreiranih replika. Meutim i dalje nismo sigurni da e
te replike biti stalno konzistentne s replikama koje nisu pod naom kontrolom (druga
lokacija - site). Dakle, ovaj stupanj konzistencije ne osigurava konzistenciju izmeu
lokacija (site).

Konzistentan skup aurnih transakcijskih kopija (Consistency Level 3). Svaka replika u
Grid sustavu identina je s drugim replikama. Operacije kljuanja itaj/pii se
obavljaju na nivou svih mjesta u okviru odreene Grid okoline. Vrlo teko se postie.
Zahtijeva da se sve zahtjevi operacija nad podacima alju kroz jedinstvenu toku
pristupa te da nije dozvoljen pristup van Grid-a.

2.3.7 Autentikacija, kontrola pristupa, raunovodstvo

U odreenim Grid zajednicama potrebno je osigurati zatitu podataka na nain da smo
odreeni korisnici mogu pristupati odreenim podacima. Koriste se rjeenja zasnovana na
Grid Security Infrastructure (GSI) . GSI dodjeljuje korisnika prava korisniku ili aplikaciji te
osigurava njihovu delegaciju za potrebe pristupa pojedinim resursima. U Grid sustavima
pojedine operacije zahtijevaju prava pristupa unutar jedne lokacije, a druge operacije se
obavljaju na viestrukim lokacijama. Odluke prava pristupa koje se obavljaju na viestrukim

lokacijama zahtijevaju uzimanje u obzir globalnih i lokalnih pravila i prava pristupa. Osim
administratora Grid sustava i osiguravatelj resursa moe odluivati koja prava koji korisnik
ima.
Grid sustavi koriste i raunovodstveni sustav kojim se biljei povijest koritenja resursa. Ta
informacija se moe iskoristiti za predvianje budueg optereenja resursa. Na osnovu
povijesti koritenja sustava moe se odluiti gdje postaviti replike podataka.

2.3.8 Pristup podacima i upravljanje pohranom podataka (Data Access and Storage
management)
Metode pristupa podacima su vrlo razliite. Distribuirani datoteni sustav (DFS) organizira
distribuirane datoteke u formi stabla. Datoteni sustav moe biti pohranjen u bazu podataka
(SQL). Korisnici trebaju uniforman nain (suelje) za dohvat podataka. Korisnik postavlja upit
te na osnovu njega dobiva eljene podatke. Upravljanje pohranom podataka treba na nekom
sustavu pohrane osigurati kreiranje prostora za pohranu, datoteni sustav (moe biti
realiziran i s bazom podataka), te osnove operacije pohrane.

2.3.9 Integracija podataka

Integracija podataka ima za cilj da podatke pohranjene na razliitim sustavima za pohranu
podataka predstavi kao jedinstven skup podataka. Moe se promatrati i van teme
upravljanja podacima u Grid sustavu. Integracija podataka sastoji se od slijedeih faza:

otkrivanje podataka: upit na servis meta-podataka za pronalaenjem relevantnih

podataka

pristup podacima: verificiranje da li su podaci dostupni te korisni za rjeavani

problem

transport podataka na mjesto obrade

analiza podataka: obrada podataka (ukljuivi i lokalne podatke)

sinteza podataka: kreiranje novog pogleda na podatke (vizualno, statistiki, datoteke)

2.4 Servisi za meta-podatke u Grid sustavima

Zato su nam potrebni meta-podaci u okviru Grid sustava ? Glavni razlog je velika koliina
podataka. Tradicionalne tehnike poput koritenja SQL upita ili traenja po nazivu datoteka ne
mogu se primijeniti za velike koliine podataka. Drugo je da zbog heterogenosti sustava nije
lako koristiti direktne tehnike pristupa (razliiti datoteni sustavi, baze). Tree je da podaci iz
razliitih znanstvenih izvora imaju eto pridruene biljeke. Te biljeke potrebno je
organizirati na prikladan nain te ih vezati uz originalne podatke.

2.4.1 Tipovi metapodataka

Zbog velikog opsega moguih metapodataka potrebno ih je organizirati u niz kategorija:
Data Metadata (meta-podaci o podacima). Informacija o podacima je najbitnija kategorija
metapodataka. Dijelimo je na tri tipa:

Fiziki metapodaci : ukljuuju karakteristike fizikog sustava pohrane to

obuhvaa veliinu datoteke ili objekta, lokaciju, vrijeme kreacije, naziv kreatora i
format datoteke (.doc, .jpg, ...)

Meta-podaci o replikama: veza izmeu logikog naziva datoteke i njene jedne ili
vie replika koje mogu biti pohranjene na razliitim datotenim sustavima ili
bazama podataka

Meta-podaci o pripadnoj domeni: najee se podaci klasificiraju prema

problemskoj domeni koja ih generira (ili koristi). najee je u pitanju hijearhijska
organizacija. Npr. (LHC Experiment > Alice,CMS,Atlas,LHCb)

Korisniki metapodaci. Korisniki podaci sadre informaciju o korisniku koji kreira, koristi ili
modificira podatke. Dakle, ime i prezime, adresa , email, telefon. Korsni ima i atribut o
domeni kojoj pripada te moe imati niz atributa pripadnosti pojedinim grupama.
Metapodaci o aplikacijama. Podatke generiraju aplikacije (mogu biti dio strojeva).
Metapodaci o aplikacijama mogu sadravati podatke opisa sadraja podataka, uvjete pod
kojima su podaci proizvedeni ili neke druge podatke koji mogu posluiti kao uputa za daljnje
procesiranje.
Metapodaci o resursima. Tu pripadaju karakteristike resursa pohrane podataka poput
adrese pristupa, fizike lokacije, tipa resursa, liste dozvole pristupa.

2.4.2 Servisi za meta-podatke

Pohrana.Vie je naina za pohranu meta podataka. Npr. koritenje relacijske baze podataka,
pohrana u XML datoteku, koritenje LDAP-a. Relacijska baza podataka je pogodna zbog
mogunosti postavljanja SQL-upita. U Grid sustavima se nalaze sve vee koliine
metapodataka pa se esto posee da distribuiranim bazama podataka. S druge strane XML se
zbog standardiziranosti namee kao pogodan format pohrane metapodataka. Metapodaci
Grid sustava mogu biti i kombinirani u vie razliitih formata.
Objava i pronalaenje podataka. Metadata servisi moraju osigurati korisniku da na
jednostavan i kontroliran nain dodijeli metapodatke podacima (najee datotekama). U

fazi pronalaenja servisi omoguavaju da korisnik formira upit nad metapodacima te mu se

na osnovu upita vrate eljene datoteke ili skupovi podataka.

2.5 Replikacija
Nova replika podataka se kreira zato to nova lokacija pohrane omoguava bolje
performanse neke aplikacije. replika se moe izbrisati zbog nedostatka prostora, isteklog
ivotnog vijeka ili drugih razloga. U Grid okolinama s aplikacijama koje obrauju podatke
pristup podacima prethodi veini operacija. Prvo se preko servisa metapodataka slanjem
upita s atributima podataka obavlja traenje podataka. Servis metapodataka vraa logike
nazive datoteka korisniku ili aplikaciji. Logiki naziv datoteke alje se servisu za upravljanje
replikama koji vraa listu lokacija s jednom ili vie replika. Servis za odabir replike pronalazi
najpogodniju repliku. Pri tome se koristi drugim servisima kojima se prati rad sustava
pohrane i prijenosa podataka.
Metapodaci o replikama sadravaju podatke o mapiranju instanci neke datoteke na
odreene lokacije pohrane. Npr. jedna od implementacija je da metapodaci sadre
mapiranje izmeu logikog naziva datoteke i GUID (globally unique identifier). GUID je 128bitni broj koji garantira da odreeni podatak ima jedinstveni identifikator unutar Grid
okoline. Lokalni sustav pohrane koristi i dodatne lokalne identifikatore.
Katalog replika. To je servis za registraciju replika te postavljanje upita. Kad se replika kreira
ona se upisuje u katalog tj. upisuje se njena fizika lokacija te vee s logikim nazivom
(GUID). Brisanjem replike brie se i njena oznaka u katalogu.
Upravljanje replikama osigurava mehanizme za kreiranje i brisanje replika na mjestima
pohrane.
Odabir replike je postupak traenja optimalne replike iz niza raspoloivih replika. Cilj je
postii veu propusnost sustava. Servis odabira replike moe i naloiti kreiranje novih replika.

2.6 Efikasan prijenos podataka

Podaci su najee pohranjeni na vie distribuiranih lokacija pohrane. U nekim proraunima
mogue je da se koriste podaci koji su geografski distribuirani. Tada nam ograniavajui
faktor moe biti mrena propusnost. Openito imamo tri tipa ogranienja mrene
propusnosti:

propusnost veze servera s mrenom okosnicom (Internet)

propusnost veze klijent-server

propusnost klijenta prema mrenoj okosnici (Internet)

Kako bi se iskoristili limitirani mreni resursi postoje razliite tehnike transfera podataka kod
kojih se koriste u paraleli viestruki vorovi pohrane podataka.
Prijenos podataka s ko-alokacijom. Kako se replikacija ve uestalo primjenjuje svaki skup
podataka (dataset) posjeduje viestruke kopije na razliitim lokacijama. Umjesto

transferiranja skupa podataka s jedne lokacije, moe se transfer podijeliti u niz manjih
transfera dijelova skupa podataka s razliitih lokacija. Finalno se dijelovi sastavljaju na
odreditu. Ovaj postupak nazivamo transfer s ko-alokacijom.
Ko-alokacijski transfer posjeduje nekoliko mehanizama alokacije. Dva su osnovna tipa :
statefull i stateless.
Kod stateless alokacije klijent koji eli transfer vee se na niz servera na kojima su replike
locirane. Cijeli dataset se dijeli na niz jednakih dijelova i svaki dio se vue s posebne lokacije.
Kod ovog mehanizma nije potrebno odravati podatke o opsegu pojedinog dijela te ga je vrlo
lako realizirati. Meutim, kao ne koristi podatke o trenutnim performansama prijenosa od
pojedinih lokacija, tako je mogue da optereenje nije pravilno rasporeeno i da nam
pojedini dijelovi podataka kasne.
Statefull alokacijski mehanizam uzima u obzir stanje na lokaciji replike, mrenu
propusnost,.itd. te na osnovu toga odrediti koliki dio podataka e povui s odreene lokacije.
Postoje dva osnovna pristupa u donoenju odluka:

alokacijski mehanizam zasnovan na povijesti predvianje trajanja prijenosa zasniva

se na povijesti prethodnih prijenosa. Na osnovu toga se proraunava veliina skupa
podataka koja se eli prenijeti s neke lokacije. Cilj je da svi dijelovi stignu otprilike u
isto vrijeme. Ako se stanje resursa (pohrana, mrea) znaajno promijeni u tijeku
prijenosa poremetit e istovremeno primanje.

dinamika alokacija skup podataka se particionira u niz manjih blokova jednake

veliine. Svaki server s replikom transferira prvo po jedan blok i nakon toga mu se
dodjeljuje slijedei blok. Bri server e prvi prenijeti podatke i prvi e dobiti slijedei
blok za prijenos. Kao rezultat bri serveri transferiraju vie podataka od sporijih. U
ovom mehanizmu vaan je pojam round-trip vremena. To je vrijeme od kad jedan
transfer zavri do vremena kad je poslan zahtjev serveru za slijedei blok. To se moe
zaobii tako da server posjeduje cjevovod u koji se alju viestruki zahtjevi za transfer
(vie blokova).

3. GRID RASPOREIVANJE (SCHEDULING) I INFORMACIJSKI SERVISI

Rasporeivanje i informacijski servisi su dvije komponente Grid sustava koje imaju kljunu
ulogu u postizanju performansi aplikacija koje se izvravaju na Grid sustavu. Informacijski
sustavi upotpunjuju sustav Grid rasporeivanja. Osnovi problem je kako mapirati resurse
(procesori, memorije, mrena propusnost,...) na zadatke koje treba obaviti.
Raspored posla na neki vor zahtijeva dva razmatranja:

da li resurs ispunjava minimalne (ako i postoje) zahtjeve QoS za izvravanje posla

kad je resurs slobodan za obavljanje posla

I jedno i drugo se doznaje preko informacijskih servisa. Meutim raspored poslova nije tako
jednostavan kako na prvi pogled izgleda. Postoje sluajevi koji kompliciraju odluku o
rasporedu:

zadatak moe biti razdijeljen na vie pod zadataka koji se obavljaju na razliitim
vorovima sustava

zadaci mogu imati meuovisnosti, pa se moraju izvravati u definiranom redoslijedu

zadatak zahtijeva veliku koliinu ulaznih podataka ; nije ga mogue poslati na prvi
slobodni vor

pad nekog pod-zadatka zahtijeva njegovo ponovno rasporeivanje i to bre

izvravanje

Podatke Grid informacijskog sustava zbog velike geografskih udaljenosti resursa i koliine
podataka nije zgodno drati na jednom mjestu jer to mjesto tada predstavlja jedinstvenu
toku pogreke sustava (single point of failure) i nije dovoljno skalabilno. najee se koristi
hijerarhijska struktura.

3.1 Mapiranje poslova strategije rasporeda poslova

Osnovna karakteristika Grid sustava je njihova heterogenost. Takav sustav moemo nazvati i
hetreogeni raunalni (HC- heterogeneous computing) sustav. Sposobnost HC sustava da
rijee neki raunalni problem uvelike ovisi o njihovoj sposobnosti da upare raunalne resurse
s raunalnim potrebama. Ono to je bitno u tim sustavima je : nije svaki stroj pogodan za
svaki zadatak. Npr. neki zadaci zahtijevaju specifian instrukcijski set i pogodniji su za
izvravanje na nekim strojevima nego na drugima. Drugi zadaci zahtijevaju koliinu memorije
koju nemaju svi strojevi u sustavu.
Jedan od naina iskoritavanja potencijala HC sustava je dijeljenje zadataka u pod-zadatke.
Svaki od pod-zadataka se moe upariti (matching) s moguim mjestima izvravanja.
Zatim se odreuje potreban redoslijed izvravanja zadataka. Tijekom toga se moraju
razmotriti specifini zahtjevi pod-zadataka poput meuovisnosti zadataka ili interprocesne
komunikacija izmeu zadataka. Odreivanje rasporeda izvravanja pod zadataka nazivamo
rasporeivanje (schedulling). Kompletan postupak uparivanja i rasporeda nazivamo

mapiranje ili strategija rasporeivanja poslova. Cilj je maksimizirati funkciju cilja koja se
zasniva na QoS atributima poput vremena izvravanja, vremena odziva ili drugih koje
zahtijevaju korisnici HC sustava.

3.2 Mapiranje poslova na paralelnim strojevima

3.2.1 Heuristike metode
Heuristika je tehnika kojom se trae dobra rjeenja uz razumne raunalne trokove, a koja ne
garantira niti pronalaenje niti optimalnost pa ak u mnogim sluajevima ni procjenu koliko
je neko rjeenje blisko optimalnome.
Heuristike metode mapiranja moemo podijeliti na statike i dinamike. U statikim
metodama odluke o uparivanju i rasporedu donose se prije izvravanja aplikacije. Statiko
mapiranje uzima pretpostavku da je vrijeme izvravanja i transfera podataka unaprijed
poznato. Efikasnost statikog mapiranja ovisi o tonosti procjene vremena izvravanja.
Dinamike metode izvode uparivanje i raspored i tijekom izvoenja aplikacije.
Druga podjela se odnosi na to kad je zadatak mapiran na odreeni stroj. Ako se zadatak
uparuje im stigne to je on-line mod. Ako se stavlja na stog i mapiranje se odvija u
predodreenim vremenskim intervalima to je batch mod.
Maper je komponenta u Grid rasporeivau koja izvodi algoritme mapiranja. Maper obino
odrava matrice koja se nazivaju ETC matrica (expected time to compute). Ona sadri
oekivana vremena izvravanja razliitih zadatka (dijelovi meta-zadatka) na odreenim
strojevima.
m1

m2

m3

z1

10

20

14

z2

20

40

24

z3

10

20

18

Slika 3.1. Primjer ETC matrice

Varijanca vremena izvravanja zadataka unutar meta-zadatka odreuje heterogenost

zadatka. Hetrogenost strojeva daje varijancu vremena izvravanja pojedinog zadatka po
razliitim strojevima.
ETC matrice mogu se podijeliti na konzistentni i nekonzistentni tip. Za konzistentnu ETC
matricu ako stroj mi ima manje vrijeme izvravanja od stroja mj za zadatak za, tada to vrijedi
za bilo koji drugi zadatak. Za nekonzistentnu ETC matricu to ne vrijedi. Meutim podskup
matrice ETC moe biti konzistentan pa takve matrice nazivamo polukonzistentne
(semiconsistent). Heuristike mapiranja se ponaaju razliito ovisno o uvjetima
konzistentnosti.
Slijede neki pojmovi koji se koriste u diskusiji heuristika mapiranja.

Oekivano vrijeme izvravanja (expected execution time): To je vrijeme izvravanja

zadatka na stroju kad isti nije pod nekim drugim optereenjem. Oznaava se kao eij ,
to znai oekivano vrijeme izvravanja zadatka ti na stroju mj.

Oekivano vrijeme izvrenja (expected completion time) : To je vrijeme koje pokazuje

sat u trenutku kad je stroj mj izvrio zadatak ti. Oznaava se s cij.

Vrijeme dostupnosti stroja (Machine availability time): Najranije vrijeme kad stroj
postaje slobodan. To znai da je izvrio sve prethodno dodijeljene zadatke. Oznaava
se s mat(j). Iz prethodnog cij= mat(j)+ eij.

Jo moemo definirati makespan kao vrijeme potrebno da se izvre svi zadaci nekog metazadatka. To je mjera propusnosti nekog sustava.
3.2.1.1 Oportunistiko balansiranje optereenja (oportunistic load balancing)
Kod oportunistikog balansiranja zadatak se dodjeljuje prvom slobodnom stroju. Ako je vie
strojeva dostupno bira se proizvoljno. Ne uzima se u obzir vrijeme izvravanja na tom stroju.
Ovaj algoritam oekivano ima loe performanse za sve vrste ETC matrica.
3.2.1.2 Lakomo ili minimalno vrijeme kompletiranja (Fast Greedy or Minimum Completion
Time (MCT) )
Kod ovog algoritma se proizvoljno odabran zadatak dodjeljuje stroju koji ima minimalno
vrijeme izvrenja za taj tip zadatka (min(mat(j)+ eij)) . Kod ove heuristike neki zadaci nee biti
dodijeljeni na stroj koji ih najefikasnije izvrava. Ova heuristika ima dobre performanse za
polu ili nekonzistentne ETC matrice, ali loe za konzistentne ETC matrice.
3.2.1.3 Minimalno vrijeme izvravanja (Minimum Execution Time (MET))
U ovoj heuristici proizvoljno odabran zadatak se dodjeljuje stroju koji ima najkrae vrijeme
izvravanja za taj tip zadatka. Kako ova heuristika ne uzima u obzir vrijeme dostupnosti
stroja, moe uzrokovati ozbiljnu nebalansiranost optereenja sustava za konzistentne ETC
matrice. Prednost je jednostavnost implementacije.
3.2.1.4 Preklopni algoritam (Switching Algorithm - SA)
Ovaj algoritam koristi naizmjenino MCT i MET heuristiku kao bi se ouvalo ravnomjerno
optereenje strojeva u sustavu. SA algoritam zasnovan je na slijedeoj ideji: MET algoritam
moe kreirati disbalans optereenja, dok MCT heuristika popravlja balans dodjeljujui
zadatke stroju s najranijim vremenom izvrenja. Stalno se prati mjera balansiranosti sustava
te prema potrebi prebacuje s jednog na drugi algoritam (MCT,MET).

3.2.1.5 Min-Min
Min-min mapiranje je zasnovano na ideji da e raspored zadatka na nain da se minimizira
ponovno vrijeme dostupnosti nekog stroja vjerojatno proizvesti manji makespan za metazadatak.
Algoritam:

zapoinje raunanjem oekivanog vremena izvrenja za sve zadatke na svim

strojevima

zatim se rauna najranije vrijeme izvrenja za svaki zadatak unutar meta-zadatka

zadatak s minimalnim najranijim vremenom izvrenja alje se na izvravanje

vrijeme dostupnosti stroja se aurira s dodavanjem oekivanog vremena izvravanja

na tom stroju

procedura se ponavlja sve dok ima zadataka u listi

3.2.1.6 Max-Min
Ovo je slina heuristika kao min-min mapiranje.
Algoritam:

zapoinje raunanjem oekivanog vremena izvrenja za sve zadatke na svim

strojevima

zatim se rauna najranije vrijeme izvrenja za svaki zadatak unutar meta-zadatka

zadatak s maksimalnim najranijim vremenom izvrenja alje se na izvravanje

vrijeme dostupnosti stroja se aurira s dodavanjem oekivanog vremena izvravanja

na tom stroju

procedura se ponavlja sve dok ima zadataka u listi

Max-min heuristika e openito nadmaiti min-min heuristiku kada je broj manjih zadataka
vei od broja velikih zadataka. Ona e prvo poslati due zadatke na izvravanje, a zatim e se
manji zadaci moi paralelno izvravati s velikima. To bi u pravilu trebalo smanjiti makespan.

3.3 Mapiranje ili strategije rasporeivanja poslova na meta-raunalima

Raspored poslova za jedno paralelno raunalo znaajno se razlikuje od rasporeivanja za
meta-raunalo. Rasporeiva paralelnog stroja vri raspored poslova kako bi na stroju
postigao visoku iskoritenost resursa. Pri tome ima visoki stupanj kontrole nad resursima.
Rasporeivanje za meta-raunalo komplicira prvenstveno to ga sainjava niz paralelnih
strojeva (grozdovi), svaki sa svojom lokalnom politikom rasporeda. Dakle meta-rasporeiva
formira novi stupanj rasporeivanja povrh lokalnih rasporeivaa. Raspored zadataka

ugroava i volatilnost resursa, tj. to resursi mogu se pridruiti ili izai iz Grida u bilo koje
vrijeme. Dakle takvi sustavi zahtijevaju specijalne arhitekture i strategije rasporeda poslova.
Sustav za raspored zadataka u Grid sustavu moe se podijeliti na tri dijela: politika rasporeda,
funkcija cilja i algoritam rasporeda. Politika rasporeda sastoji se od niza pravila kojima se
definira alokacija resursa za posao. Npr. u Grid organizaciji poslovi koje alje odjel A mogu
imati vei prioritet od poslova grupe B. To znai da ako su u stigli na raspored u isto vrijeme
onda poslovi od A e biti rasporeeni prije poslova od B. Funkcija cilja dodjeljuje svakom
moguem rasporedu neku usporedivu vrijednost(i) koja nam omoguava da se odabere
odreeni raspored. Algoritam rasporeda treba proizvesti raspored blizak optimalnome uz
prihvatljivo vrijeme izvravanja i koritene resurse.
Postoje dvije osnovne arhitekture rasporeivaa za Grid raunala: centralizirana i
decentralizirana. Algoritmi koji se primjenjuju u rasporedu se kreu od prilagoenih
algoritama koji se koriste i na obinim paralelnim strojevima do posebno razvijenih
algoritama.
3.3.1 Centralizirano rasporeivanje poslova
U centraliziranoj okolini svi zadaci se rasporeuju na paralelne strojeve (grozdove) iz jednog
sredita. Zbog toga je na to centralno mjesto potrebno prikupiti i sve informacije o stanju
sustava. Ovakav koncept nije skalabilan s porastom veliine Grid sustava. Osim toga prekid
mrenih veza rasporeivaa utjee na sve vezane resurse. Meutim ovakav rasporeiva ima
mogunost da izvodi vrlo efikasan raspored poslova.
Ova paradigma rasporeivanja poslova korisna je za jedan raunalni centar, gdje se svi
raunalni resursi koriste za jedan cilj. U tom sluaju i prekid komunikacije je malo vjerovatan.
O ovom scenariju poslovi se alju centralnom rasporeivau. Svi poslovi koji se ne mogu
odmah pokrenuti stavljaju se u centralni red ekanja.

Slika 3.2. Centralizirano rasporeivanje

Dalje moemo razluiti rasporeivae prema tome kako se resursi kombiniraju za izvravanje
poslova. Ovo razluivanje moe se primijeniti i na decentralizirane rasporeivae.
Rasporeivanje na jednu lokaciju (single site)
Posao se obavlja na jednom paralelnom stroju. Mogu se upotrijebiti dobro poznati algoritmi
za balansiranje optereenjem (FCFS, Backfill). Latencije za potencijalno komunikaciju izmeu
poslova se ne razmatraju velike brzine komunikacije unutar paralelnog stroja.
Rasporeivanje na vie lokacija (multi site scheduling)
Dijelovi posla koji se obavljaju na razliitim strojevima imaju loije uvjete komunikacije.
Sustav za raspored ima otean zadatak ako je potrebno sve poslove pokrenuti u isto vrijeme.
3.3.2 Hijerarhijska struktura rasporeivanja poslova
Mogua konfiguracija u raunalnim Gridovima je koritenje centralnog rasporeivaa koji
prima poslove, a svaka paralelni stroj posjeduje vlastiti rasporeiva. Ova struktura
posjeduje svojstva i centraliziranog i decentraliziranog rasporeivanja, ali zbog jednog mjesta
prijema poslova moemo je okarakterizirati kao preteno centraliziranu. Prednost
hijerarhijske strukture je to se mogu koristit razliite politike rasporeda u centralnom i
lokalnim rasporeivaima. Centralni rasporeiva je neka vrsta meta-rasporeivaa koji vri
redirekciju poslova na redove ekanja u lokalnim rasporeivaima prema nekoj politici
rasporeda.

Slika 3.3. Hijerarhijsko rasporeivanje

3.3.3 Decentralizirano rasporeivanje

U decentraliziranome rasporeivanju rasporeivai komuniciraju jedan s drugim i nakon
toga rasporeuju poslove na udaljene sustave. Ne postoji centralna instanca odgovorna za
raspored poslova. Zbog toga nije potrebno ni informaciju o stanju sustava prikupljati na

samo jedno mjesto. Sustav je i skalabilniji. Pad jednog rasporeivaa nee utjecati na cijeli
sustav. Nedostatak u odnosu na centralni rasporeiva koji ima potpunu informaciju o stanju
cjelokupnog sustava je sub-optimalni rasporeda poslova. Osim toga s ovakvom vrstom
rasporeivanja poslova jo tee je ostvariti podrku za aplikacije koje se izvravaju na vie
lokacija.
Slijedi prikaz dva sluaja decentraliziranih arhitektura. Svi poslovi su poslani lokalno.
Direktna komunikacija

Slika 3.4. Decentralizirana arhitektura rasporeivaa - direktna komunikacija

Lokani rasporeivai mogu direktno primati/slati poslove od drugih rasporeivaa. Svaki

rasporeiva posjeduje listu rasporeivaa koje moe kontaktirati ili se koristi neki
informacijski sustav. Ako posao nije mogue odmah pokrenuti na lokalnom stroju, lokalni
rasporeiva trai alternativno mjesto izvravanja. Ako se pronae takav stroj posao se
njemu prosljeuje. Mogu se naznaiti poslovi koji su kandidati za prosljeivanje.
Komunikacija preko centralne priuve poslova (central job pool)
Poslovi koji se ne mogu izvriti odmah alju se na centralnu priuvu umjesto na udaljeni stroj.
Za razliku od centralnog rasporeivanja ovdje lokalni rasporeivai mogu pokupiti prikladne
poslove za svoj lokalni raspored. U ovom scenariju poslovi su vueni iz priuve (pull). Resursi
vuku poslove ovisno o svom optereenju. Stoga sustav posjeduje ravnomjeran raspored
poslova. Potrebno je uspostaviti politiku priuve u kojoj unato zahtjevima lokalnih
rasporeivaa svi poslovi e doi na red u izvravanju ( izbjei starvation, izgladnjivanje).
Ova metoda se moe dalje modificirati tako da se svi poslovi nakon slanja guraju direktno u
priuvu.

Slika 3.3. Decentralizirana arhitektura rasporeivaa centralna priuva poslova

3.4 Algoritmi rasporeda meta-rasporeivaa

Promatramo poslove iji dijelovi zahtijevaju istovremeno pokretanje na svim vorovima
sustava. U tom sluaju bitni faktori koji odreuju raspored izvravanje nekog posla su duljina
posla i broj vorova koji posao zahtjeva (irina).

3.4.1.1 First-Come-First-Served
U First-Come-First-Served (FCFS) shemi rasporeda poslovi su poredani na osnovu njihova
vremena prijave (submission). Nakon pojave resursa za njegovo izvravanje posao koji je prvi
pristigao alje se na izvravanje. Prednosti FCFS su:

to je fair (pravedan) algoritam jer vrijeme izvravanja posla je neovisno o bilo kojem
poslu koji je poslan poslije njega

ne zahtjeva poznavanje vremena izvravanja posla na resursu

vrlo lak za implementaciju

Nedostaci:

Moe proizvesti rasporede u kojima neki vorovi e biti bez posla due vremena (idle)

Posebna degradacija ako se alju poslovi s velikim vremenom izvravanja po voru

3.4.1.2 Backfilling algoritam

Backfilling algoritam zahtjeva procjenu vremena izvravanja posla na stroju. Ako se posao
koji je na elu liste ne moe izvriti uslijed nepodudaranja/nedostatka resursa onda
backfilling trai prvi slijedei posao koji se da izvriti na resursu, ali koji nee odgoditi
izvravanje posla na elu liste. Koriste se dvije varijante backfillinga:

Konzervativni backfilling: U ovoj varijanti se resursi rezerviraju za svaki posao kad isti
pristigne na red ekanja. Poslovi se mogu micati naprijed u redu sve dok to ne
ugroava odreeno vrijeme izvravanja posla drugih poslova (ne samo onoga na
elu). Tako e se dugi poslovi teko probiti u redu izvravanja. Meutim to titi iroke
poslove koji ulaskom u red izvravanja dobivaju garantirani poetak izvravanja .

Agresivni ili EASY backfilling: U ovoj vrsti backfillinga samo posao na elu liste ima
rezervaciju izvravanja. Dui poslovi imaju veu ansu da se probiju jer ih ograniava
samo jedna rezervacija izvravanja posla na elu. Meutim iroki poslovi mogu biti
potisnuti jer ne dobivaju prednost u izvravanju sve dok se ne probiju na elo.

Ovisno o sastavu poslova, vezano za irinu i duinu svaka shema ima svoje prednosti i
nedostatke. Ponekad se upotrebljavaju dva reda ekanja, jedan s konzervativnim,a drugi s
agresivnim backfillingom.

3.5 Otkrivanje i nadgledanje servisa (Service monitoring and discovery)

Kada se posao poalje na Grid u izvravanje, rasporeiva mapira posao na prikladne resurse
koristei heuristiku mapiranja. Mapiranje se oslanja na informacije o resursima, odnosno o
njihovoj dostupnosti. Resursi koji su u Gridu su raznovrsni, poevi od raunala, mrea,
sustava pohrane do protokola i algoritama koje se koriste u aplikacijama. Nadgledanje je
proces u kojem se prikupljaju informacije vezane za resurse i servise kako bi se saznali uzorci
koritenja (usage patterns) ili uoile pogreke. Otkrivanje je proces kojim se nalaze prikladni
resursi za obavljanje poslova. U dinamikom sustavu poput Grid sustava, gdje resursi mogu
ulaziti ili izlaziti iz sustava bez ikakve prijave, otkrivanje dostupnih resursa je od iznimne
vanosti. Otkrivanje servisa je komplicirano zbog:

heterogenosti sustava (oteava prikupljanje istoznanih informacija dostupnosti)

dinamike prirode resursa (informacija dostupnosti brzo zastarijeva)

geografske distribucije resursa (promjenjivi uvjeti dostupnosti npr. mrena

propusnost)

velike koliine resursa (velika koliina informacija, veliki broj korisnika : potrebna
decentralizacija, hijerarhijska struktura)

Bitno je da se od informacijskog sustava ne zahtijeva konzistentna niti potpuna informacija o

stanju sustava. Konzistentnost informacije za sve korisnike znai da u nekom vremenskom
trenutku svaki korisnik ima istu informaciju o dostupnosti nekog resursa. Omoguavanje da
svaki korisnik ima konzistentnu informaciju o stanju cijelog sustava za sustav veliine Grida je
prevelik zahtjev.

U distribuiranoj okolini i resursi i sustavi za informacije o resursima su podloni grekama.

Grid sustav treba biti otporan na takve pogreke.
Primjer:
Pretpostavimo da dio VO postane nedostupan uslijed mrene pogreke. To ne smije
onemoguiti korisnike da dobiju informaciju o ostalim dijelovima sustava. Dalje, informacijski
sustav treba na vrijeme pruiti informaciju o padu dijela sustava. To se postie najee kroz
soft-state model.To znai da se informacija o stanju sustava odbacuje ako nije nakon nekog
prethodno definiranog vremena osvjeena. U sluaju da dio sustava ostane bez mrene veze
to znai da nee Grid informacijski sustav nee dobiti informaciju o stanju tog dijela sustava.
Nakon nekog predefiniranog vremena informacijski sustav e pretpostaviti da su resursi tog
dijela sustava nedostupni.
Grid informacijski sustav moe dobavljati informacije i o resursima unutar drugih VO. U tom
sluaju bit e potrebne dodatne provjere vezano za identifikaciju traitelja informacije i o
tome da li isti ima dovoljne privilegije za dobivanje istih.

3.6 Grid workflow

Opa definicija za workflow bi bila npr. automatizacija procesa koji se sastoji od vie manjih
sub-procesa, gdje postoji mogunost razmjene informacija ili podataka izmeu istih, a koja
se obavlja na temelju predefiniranih pravila.
Zadatak u Grid sustavu moe biti sastavljen od niza pod-zadataka, koji najee posjeduju
meuovisnost, npr..

podzadatak B zahtjeva rezultate od podzadatka B, stoga zadatak A je potrebno

rasporediti da se izvrava prije zadatka A.

zadatak A i zadatak B komuniciraju tijekom izvravanja koristei RPC (remote

procedure call), tj. potrebno je istovremeno izvravanje.

Gledano na nivou web servisa novi web servis se moe kreirati koritenjem postojeih web
servisa te je u tom sluaju definiran redoslijed pozivanja i izvravanja sastavnih web servisa.
Razne aplikacije s podruja bio-informatike, astronomije, fizike visokih energija, itd.
zahtijevaju orkestraciju razliitih resursa i izvravanje kompleksnih workflow-a.
Grid workflow se moe podijeliti linearni, Acikliki i ciklini.

U linearnom workflowu zadaci se obavljaju u specificiranom linearnom slijedu i

obino koriste neki skriptni jezik za svoj opis

Acikliki workflow moe biti opisan aciklikim grafom gdje su vorovi zadaci, a grane
su meuovisnosti zadataka. Tee se opsuju skriptnim jezicima, zahtijevaju poseban
workflow jezik.

Ciklini workflow se opisuje ciklinim grafovima. Tu se komunikacija odvija u nizu

izmjena poruka. Grane predstavljaju komunikaciju izmeu servisa.

3.7 Tolerancija greaka u Grid sustavima

Stroj u Grid sustavu moe pasti uslijed razliitih razloga ili moe biti odsjeen od sustava zbog
pada mree. Grid sustav treba rukovati s ovakvim pogrekama na korisniku transparentan
nain. Razlog tome je da korisnik sagledava Grid kao jedan virtualni stroj. Korisnik
jednostavno alje na izvravanje aplikaciju i oekuje rezultat. Korisnika ne zanima koji dio
sustava ne funkcionira i neovisno o tome eli rezultat aplikacije. Stoga, upravljanje
pogrekama u sustavu mora biti neovisno o korisniku.
Na pogreke u Gridu moemo gledati iz dvije perspektive.
Stroj koji je trebao izvriti zadatak uslijed pogreke prekida s radom. U tom sluaju posao se
treba dodijeliti nekom drugom stroju koji zadovoljava uvjete koji postavlja posao.
U drugom scenariju posao koji je pokrenut moe zahtijevati podatke koji su na udaljenoj
lokaciji. Zbog nekog razloga veza s tom lokacijom nije dostupna. U tom sluaju zadatak Grid
sustava je lociranje alternativne lokacije koritenjem Grid informacijskog sustava. Tek u
sluaju da se ne moe locirati alternativna lokacija, korisnik prima prikladnu poruku.
U prvom sluaju radi se o strategiji koja se naziva preraspored. Za drugi scenarij koristi se
replikacija podataka.

4. SIGURNOST U GRID SUSTAVIMA

4.1 Uvod
Sigurnost u Grid sustavima ima svoje specifinosti nastale iz potrebe da se izgrade skalabilne
VO. VO je grupa geografski distribuiranih individua ili organizacija koji imaju privremen ili
stalan pristup resursima ili servisima. Dinamika priroda i preklapanje VO predstavljaju izazov
u implementaciji sigurnosnih mehanizama.
Osnovni problem je da nema centralne toke kontrole u Grid sustavu. To znai da svaki
pruatelj resursa u Grid sustavu treba napraviti procjenu rizika kad obavlja interakciju s
nekim drugim korisnikom ili pruateljem resursa te nakon toga uspostavi povjerenje. U ovaj
proces ukljueni su tradicionalni sigurnosni mehanizmi: autentikacija, autorizacija i
povjerljivost.

4.1.1 Autentikacija
Autentikacija potvruje identitet entiteta u mrenom okruju. Taj entitet moe biti korisnik,
proces ili resurs.
Pretpostavimo da elite komunicirati s raunalom na mrei koje tvrdi da ima odreeni
identitet. Proces autentikacije omoguava vam provjeru deklariranog identiteta.
Najjednostavniji proces autentikacije je upotreba korisnikog imena i passworda. Drugi nain
je Kerberos, koji koristi simetrinu kriptografiju kljua za autentikaciju vezano za
klijent/server aplikacije. Tehnologija koja je kljuna za Grid sustave je Public Key
Infrastructure (PKI). PKI opisuje sigurnosni sustav koji za koristi za identifikaciju X.509
certifikate. Takvi certifikati se izdaju od strane visoko povjerljivih organizacija poznatih kao
CA (certifitying authorities). Npr. korisnik moe biti igrati razliite uloge u sustavu i biti lan
razliitih VO u isto vrijeme. Razliite VO se mogu sloiti da koriste iste ili razliite CA. Stoga
korisnici mogu koristiti razliite dokumente certifikacije (credential) isto vrijeme.
4.1.2 Autorizacija
Autorizacija je drugi korak u uspostavljanju povjerenja izmeu dva entiteta u Grid sustavu.
Predstavlja verifikaciju privilegija koje su dodijeljene entitetu koje moe koristiti u pristupu
resursu ili servisu unutar Grid sustava. Autorizacija slijedi nakon uspjeno obavljene
autentikacije. U Grid sustavima vlasnici resursa posjeduju mogunost davanja ili odbijanja
pristupa resursima.
Najranije autorizacijske tehnike poput Globus Toolkit Gridmap su bile datoteke koje su imale
mapirane globalne nazive Grid korisnika i lokalne nazive rauna. Grid korisnik je time
dobivao prava koje mu je lokalni administrator dodijelio i u skladu s lokalnom politikom
sigurnosti. Ovaj pristup zahtijeva da svaki administrator dri aurnim sadraj datoteke za
mapiranje, to je u Grid sustavima zbog velikog broja korisnika zahtijevan zadatak.

Community Authorization Service (CAS) je slijedei korak u upravljanju autorizacijom u Grid

okolini. U CAS sustavu vlasnik resursa moe dodijeliti kontroliran pristup ne samo jednom
korisniku ve nekoj drugoj VO. Zatim ta VO odreuje tko ima pravo pristupa resursima. Svaka
VO odrava CAS server koja predstavlja posrednika izmeu dozvoljenih resursa i korisnika
VO.
Virtual Organization Membership Service (VOMS- razvijeno za EU DataGrid) koristi se za VO
koje se mogu protezati na vie organizacija. To je baza podataka zajedno s nizom alata. Kada
korisnik treba neki resurs onda se pomou alata kreira njegov certifikacijski dokument
zajedno s informacijom o ulozi korisnika i njegovim pravima. Te informacije dalje koristi
njegova aplikacija u pristupu resursima sustava.

4.1.3 Povjerljivost (Confidentiality)

Povjerljivost podrazumijeva skrivanje osjetljivih informacija od onih koji nemaju pravo
pristupa istima. Grid aplikacije se esto procesiranjem osjetljivih informacija poput
industrijskih informacija, financijskih informacija, medicinskih podataka, itd. Potreba za
zatitom takvih podataka proizlazi iz spreavanja povrede intelektualnog vlasnitva ili
spreavanja povrede privatnih podataka. Stoga se esto primjenjuju tehnike enkripcije
podataka.
Kod obrade povjerljivih podataka u Grid sustavu, rasporeiva zadataka treba potovati
sigurnosne zahtjeve vlasnika podataka te zadatke rasporediti samo na one strojeve
(grozdove) koji osiguravaju nivo zatite zahtjevan od korisnika.

4.2 Povjerenje i sigurnost u Grid sustavima

Inicijalna upotreba Grid sustava je bila u znanstvenim kolaboracijama u kojoj su korisnici
poznavali jedni druge. Takve kolaboracije imaju implicitno povjerenje korisnika i
podrazumijeva se da nijedan od korisnika nee zlonamjerno koristiti sustav. irenjem Grid
sustav, posebno u poslovna okruja, postavlja problem da korisnik koji dijeli resurse s
drugim korisnikom ne moe biti siguran u njegove namjere.
Stoga se dijeljenje resursa u Grid sustavima dozvoljava samo kad uesnici u dijeljenju
posjeduju nain da jedan drugome potvrde svoj identitet, tj. posjeduju neku ispravu
(dokument) izdan od strane povjerljivog autoriteta (poput putovnice).
4.2.1 Postojee tehnologije sigurnosti
Grid sustavi u realizaciji sigurnosnih mehanizama oslanjaju se na niz postojeih tehnologija.
naglasak je na otvorenim standardima. najee koritene tehnologije su Public Key
Infrastructure (PKI) i X.509 kao sastavni dio PKI. Za uzajamnu autentikaciju klijent-server
koristi se Kerberos protokol.

4.2.1.1 PKI infrastruktura

PKI infrastruktura omoguava korisnicima mogunost sigurne komunikacije u nesigurnim
javnim mreama koritenjem para kljueva - javni/privatni. PKI ukljuuje treu povjerljivu
stranu, koju nazivamo certifikacijskim autoritetom (CA). CA izdaje certifikate korisnicima, koji
mogu biti pojedinci ili organizacije. Digitalni certifikat jedinstveno identificira korisnika.
Digitalni certifikat prati strukturu kako je to definirano X.509 sustavom. U tom sustavu
jedinstveno ime korisnika vezano je s njegovim javnim kljuem. Privatni klju uva korisnik,
vlasnik certifikata, a javni klju je dostupan za javnu upotrebu. Podaci enkriptirani javnim
privatnim kljuem mogu se dekriptirati samo privatnim kljuem i obrnuto.
PKI slijedi hijerarhijsku strukturu u uspostavljanju povjerenja. Na najniem nivou su krajnji
korisnici. Slijedei nivo su CA na podrunom stupnju. Ne postoji fiksno odreenje veliine
podruja. To moe biti neka mala organizacija ili pak velika drava. Svaka od podrunih
organizacija takoer posjeduje svoj digitalni certifikat. Taj certifikat potpisuje CA vieg nivoa.
Na vrhu hijerarhije nije jedna CA, ve ih moe biti vie. To su CA kojima je osnovni posao
izdavanje digitalnih certifikata i koje su izborile povjerenje od svih na tritu izdavanja
certifikata.
Ako korisniku neka individua predoi svoj digitalni certifikat oznaen od nekog CA, onda
moe imati povjerenje u taj CA, ili moe za taj CA traiti certifikat izdan od CA vieg nivoa.
Korisnik dakle moe u lancu CA pronai onaj CA u koji ima povjerenje.
Npr. logiranjem na CERN Grid sustav korisnik moe se predoiti certifikat koje izdaje SRCEZagreb. CERN Grid sustav sigurnosti ne mora na popisu CA kojima vjeruje imati SRCE-Zagreb i
tada e provjeriti tko je dao certifikat za SRCE-Zagreb,...
X.509 standard opisuje sadraj certifikata, odnosno polja:

Verzija certifikata

Serijski broj jedinstveni serijski broj

Identifikator algoritma npr. md5withRSAEncryption (RSA za generaciju kljueva, md5

za hashing algoritam

Izdava

Vrijednost (vrijedni ne prije, vrijedi ne poslije)

Subjekt naziv organizacije

Informacija o javnom kljuu

...

Hash kod sadraja certifikata enkriptiran javnim kljuem izdavatelja certifikata (ne
ukljuuje polje hash koda)

Hash polje titi polja certifikata od izmjena koje mogu nastati u slanju nesigurnim mrenim
kanalima.

CA u PKI sustavu dune su i objavljivati Certification Revocation List (CRL). To su certifikati

koji su iz bilo kojih razloga povueni tj. vie se na smatraju ispravnima.

4.2.2 Grid Security Infrastructure

Grid Security Infrastructure (GSI) je dio Globus Toolkita. Na njenom primjeru obradit emo
osnovne elemente vezane za sigurnost u Grid sustavima.
GSI je razvijena da bi se osigurali specifini sigurnosni elementi za Grid sustave:
1. Jednostruka prijava (single sign-on) korisnik se samo jednom autenticira u Grid
sustav, a zatim dalje koristi resurse bez dodatnih autentikacija. Kada se korisnik prvi
put autenticira kreira se proxy certifikat s ogranienim vremenom trajanja (npr. 12h).
Kod daljnjih pristupa resursima za autentikaciju se automatski koristi proxy certifikat.
2. Delegacija privilegija:
a. Zamislimo situaciju gdje imamo tri entiteta: X,Y i Z. Y vjeruje X i Z vjeruje X.
Pretpostavimo da X eli da Y obavi zadatak koji ukljuuje pristup resursima
koji pripadaju Z. Kako Z ne vjeruje Y, ne moe dozvoliti Y pristup svojim
resursima. Da bi se rijeio taj problem, X moe delegirati dio svojih privilegija
Y izdavanjem proxy certifikata entitetu Y. Proxy certifikat zajedno s njegovim
javnim kljuem nazivamo proxy dokument (credential). Dakle, X delegira samo
one privilegije Y koje su potrebne za obavljanje zadatka.
b. U drugom scenariju korisnik alje posao Grid resursu. Korisnik tada moe
delegirati poslu podskup svojih privilegija kojima isti pristupa resursima u ime
korisnika.
3. Podrka za sigurnost u razliitim domenama Grid moe sadravati entitete koji se
proteu na viestruke organizacije. Svaka od njih moe imati unutar sebe razliite
sigurnosne politike. Sigurnosni mehanizmi moraju sadravati rjeenje za interakciju
entiteta u razliitim domenama. Stoga mora postojati neki proxy ili agent koji je
pokrenut unutar domene i koji osigurava pristup resursima udaljenom korisniku.
4. Sigurna komunikacija : GSI osigurava sigurnu izmjenu poruka koritenjem TLS
(transport layer security)
5. Autentikacija i autorizacija
6. Uniformni certifikacijski dokumenti: kako se zahtjeva interakcija meu razliitim
domenama dogovoreno je koritenje uniformnog certifikacijskog dokumenta : X.509
X.509 Korisniki Certifikati (End User Certificates)
X.509 Korisniki certifikati koriste se za identificiranje entiteta u gris sustavu. Svaki korisnik u
Gridu se identificira jedinstvenim X.509 certifikatom a i procesi koji su pokrenuti u ime tog
korisnika koriste isti certifikat.

X.509 Proxy Certifikati

Pojedini entitet moe izdati proxy certifikat kojim podskup svojih privilegija dodjeljuje
drugom entitetu. Proxy certifikat je vremenski ogranien te je to ogranienje zapisano u
samom certifikatu. Kako je proxy certifikat punovrijedan samo ogranieno vrijeme (npr. 12h),
privatni klju certifikata se moe drati ne-enkriptiran u datotenom sustavu. Pristup kljuu
titi se funkcijama zatite pristupa ugraenim u operacijski sustav. Proxy sadri novi par
javni/privatni klju. Taj novi certifikat sadri identitet vlasnika i potpisan je od strane
vlasnika, a ne CA.
Kada se koristi proxy certifikat, strana koja vri autentikaciju prima proxy certifikat i vlasnikov
X.509 certifikat. Korisnikov javni klju koristi se da se utvrdi da li je proxy certifikat valjan,
odnosno da li ga je potpisao korisnik. Slino se moe provjeriti da li je korisnikov X.509
certifikat ispravan koristei CA potpis. Na taj nain uspostavljen je lanac povjerenja od CA
preko korisnika do proxy certifikata.

5. RAUNARSTVO U OBLAKU
Raunarstvo samo po sebi da bi bilo potpuno virtualizirano mora omoguiti da se raunala
potpuno izgrade iz distribuiranih komponenti kao to su obrada, pohrana, podaci, softverski
resursi.
Tehnologije kao to su cluster, Grid, i sada raunarstvo u oblaku, sve imaju za cilj pruanje
pristupa velikim koliinama raunalne energije u potpuno virtualiziranom nainu, udruujui
resurse i pruajui jedan pogled na sustav. Znaajan cilj ovih tehnologija je isporuka obrade
podataka kao usluge. Usluna obrada oznaava poslovni model za na-zahtjev isporuku
raunalne energije, a potroai plaaju pruatelju usluge temeljeno na koritenju (platikoliko-potroi), slino nainu na koji trenutno primamo usluge iz ustaljenih javnih usluga
kao to su voda, struja, plin i telefonija. Raunarstvo u oblaku je zajedniki naziv da se opie
kategorija sofisticiranih na-zahtjev raunalnih servisa poetno ponuenih od komercijalnih
pruatelja usluga, kao to su Amazon, Google, i Microsoft. Ono obiljeava model pod kojim
se raunalna infrastruktura gleda kao oblak, iz kojeg poslovni i individualni subjekti
pristupaju na-zahtjev aplikacijama koje se nalaze bilo gdje u svijetu. Glavni princip iza modela
je pruanje obrade, pohrane i softvera kao usluge.

5.1 Poetci raunarstva u oblaku

Moemo popratiti poetke raunarstva u oblaku promatrajui napredak nekolicine
tehnologija, posebno na podruju hardvera (virtualizacija, viejezgreni ipovi), internet
tehnologije (Web servisi, servisno-orijentirane arhitekture, Web 2.0), distribuirano
raunarstvo (cluster raunala, Grid sustavi), upravljanje sustavima (autonomno raunarstvo,
automatizacija podatkovnog centra). Na slijedeoj slici prikazano je spajanje polja
tehnologija koje su znaajno uznapredovale i najavile pojavu raunarstva u oblaku.
Neke od ovih tehnologija su oznaene kao nedozrele u ranijim stadijima razvoja, ali ipak
kasnije su primile znaajnu panju sa akademskih krugova i podrane od strane velikih
industrijskih igraa. Postupno, uslijedio je proces specifikacije i standardizacije dovodei do
sazrijevanja i ireg usvajanja. Pojava raunarstva u oblaku sama po sebi je usko vezana za
sazrijevanje takvih tehnologija. Pruit emo bolji pogled na tehnologije koje formiraju
osnovu raunarstva u oblaku, sa ciljem pruanja jasnije slike o Cloud ekosustavu kao cjelini.

Slika 5.1. Spajanje razliitih napredaka dovodi do pojave raunarstva u oblaku.

5.2 Od velikih centralnih raunala do raunarstva u oblaku

Trenutno svjedoimo promjeni u IT (eng. information technology) svijetu, od interno
generirane raunalne energije do servisa dostupnih preko raunalnih resursa omoguenih
putem Interneta kao Web servisi. Ovaj trend je slian onome to se dogodilo otprilike prije
jedno stoljee sa tvornicama, koje su generirale vlastitu elektrinu energiju, dolazei do
zakljuka da je jeftinije ukljuivanje njihovih strojeva u formiranu gradsku elektrinu mreu.
Raunalstvo dostavljeno kao usluga se moe definirati kao na-zahtjev dostava
infrastrukture, aplikacija, poslovnih procesa u visoko osiguranom, raspodijeljenom,
skalabilnom i utemeljenom raunalnom okruenju preko Interneta za odreenu cijenu.
Ovaj model donosi beneficije i potroaima i pruateljima IT usluga. Potroai mogu zadrati
redukciju na IT trokovima tako da odaberu jeftinije usluge od eksternih pruatelja usluge
suprotno velikim investicijama u IT infrastrukturu i zapoljavanje osoblja. Komponenta nazahtjev ovog modela doputa potroaima da prilagode njihovo IT koritenje nasuprot
rapidnom porastu nepredvienih raunalnih trokova.
Pruatelji IT usluga postiu bolje cijene, hardverske i softverske infrastrukture su izgraene
da prue viestruke solucije i poslue mnoge korisnike, tako poveavajui efikasnost i
konano dovodei do breg povratka investicije kao i manjih ukupnih trokova oko
vlasnitva.

Nekoliko tehnologija je imalo za cilj pokretanje koncepta uslunog raunalstva u stvarnost. U

1970-ima, tvrtke koje su nudile usluge obrade uobiajenih podataka, kao to su
automatizacija platne liste, su rukovale vremenski podijeljenim koritenjem centralnih
glavnih raunala koja su mogla posluiti desetke aplikacija i koja su esto radila sa 100%
kapaciteta. Zapravo, centralna glavna raunala su morala raditi sa visokom mjerom usluge
jer su bila skupa i trokove je trebalo opravdati efikasnim koritenjem.
Era centralnih glavnih raunala je doivjela kolaps pojavom brzih i jeftinih mikroprocesora.
Osim oitih prednosti, novi model je neupitno doveo do izolacije radnog optereenja (eng.
workload) na namjenskim serverima, uglavnom zbog nekompatibilnosti softverskih stogova i
operativnih sustava. Nadalje, nedostupnost efikasnih raunalnih mrea je znailo da IT
infrastruktura treba da bude locirana na udaljenosti na kojoj e se i koristiti. Sve u svemu,
ove injenice su spreavale da usluno raunarstvo postane stvarnost na modernim
raunalnim sustavima.
Slino kao kod starih elektro-stanica, koje su snabdijevale svaka svoju tvornicu, raunalni
serveri i desktop raunala u modernoj organizaciji su esto ispod granica uslunih
mogunosti, poto je IT infrastruktura konfigurirana tako da odgovori na teoretsku koliinu
zahtjeva. Nadalje, u ranoj fazi generiranje elektrine energije, elektrina struja nije mogla
prei velike udaljenosti bez znaajnijeg gubitka u voltai. Ipak, nove paradigme su se pojavile
kulminirajui sa sustavom prijenosa sposobnim da uini elektrinu energiju dostupnu
stotinama kilometara od mjesta gdje je generirana. Isto tako, pojava brzih mrea s optikim
vlaknima je ponovno upalila vatru i pojavile su se nove tehnologije koje omoguuju
raspodjeljivanje raunalne energije preko velikih udaljenosti.
Ove injenice otkrivaju potencijal isporuivanja raunalnih usluga sa brzinom i pouzdanou
koju poslovni subjekti imaju na lokalnim ureajima. Beneficije skalirane ekonomije i visoke
uslunosti doputaju pruateljima usluge da ponude raunalne usluge za samo dio onog
koliko to kota tipinu tvrtku da generira sama svoju raunalnu energiju.

5.3 Slojevi i tipovi oblaka

Usluge raunarstva u oblaku su podijeljene u tri klase, u skladu s razinom apstrakcije pruene
sposobnosti i uslunog modela pruatelja usluge :
(1) Infrastruktura kao usluga (eng. Infrastructure as a Service - IaaS)
(2) Platforma kao usluga (eng. Platform as a Service - PaaS)
(3) Softver kao usluga (eng. Software as a Service - Saas)

Slijedea slika prikazuje slojnu organizaciju oblaka od fizike infrastrukture do aplikacija.

Slika 5.2. Slojna organizacija raunarstva u oblaku

Ove razine apstrakcije se mogu razmatrati kao slojna arhitektura gdje se slojevi vie razine
mogu sastojati od usluga nieg sloja. Meuprogram upravlja fizikim resursima i prividnim
strojevima (eng. virtual machine) postavljenim iznad njih, nadalje, prua traene
karakteristike (preraunavanje i naplaivanje) da bi ponudio plati-koliko-potroi usluge
viestrukim zakupcima. Razvojna okruenja raunarstva u oblaku izgraena su na
infrastrukturnim uslugama da bi imali mogunost razvoja aplikacija i sposobnost
implementacije na ovoj razini. Sastoje se od razni programskih modela, biblioteka, API-ja
(eng. application programming interface) i ureivaa koji omoguuju kreiranje raznovrsnih
poslova, Web, i znanstvenih aplikacija. Jednom postavljene u oblak, ove aplikacije mogu
koristiti krajnji korisnici.
Iako je raunarstvo u oblaku proizalo iz javnih raunalnih usluga, drugi modeli
implementacije, s varijacijama s obzirom na fiziku lokaciju i distribuciju su takoer usvojeni.
U tom smislu, bez obzira na tip klase, oblak se moe klasificirati kao javni, privatni,
organizacijski, ili hibridni bazirano na modelu implementacije.
Javni oblak se moe shvatiti kao oblak koji je dostupan javnim korisnicima putem platikoliko-potroi naina, a privatni oblak kao interni centar podataka poslovne ili druge
organizacije, koji nije dostupan javnim korisnicima.
U veini sluajeva, postavljanje privatnog oblaka znai restrukturiranje postojee
infrastrukture dodajui virtualizaciju i pripadno suelje oblaka. Ovo omoguuje korisnicima
interakciju s lokalnim podatkovnim centrom dok istovremeno koriste iste prednosti koje
imaju javni oblaci.

Organizacijski oblak je raspodijeljen preko vie organizacija i podrava specifinu

organizaciju koja ima dijeljene interese (cilj, smjer, sigurnosni zahtjevi, meusobno suglasje).
Hibridni oblak poprima oblik kada je privatni oblak nadodan sa raunalnim kapacitetom od
javnog oblaka. Pristup kojim se trenutno iznajmljuje kapacitet da bi se pobrinuli za poraste u
optereenju je znan kao cloud-bursting.

5.4 Infrastruktura kao usluga (IaaS)

U proteklih nekoliko godina, bilo je golemih napredaka u domeni infrastrukture kao usluge
diljem svijeta. Jedna stvar postaje sigurna, a to je da sjedite tvrtke nije nuno mjesto gdje se
odvijaju sve najznaajnije aktivnosti. Danas stvarna slika pokazuje da se dvije treine
populacije nekog posla radi s lokacija koje su smjetene daleko od sjedita. Nadalje, rauna
se da se koliina mobilne radne snage poveava iz dana u dan. Stoga ete lako pronai
vlasnike jednako kao i zaposlenike da izvravaju poslovne zadae sa udaljenih lokacija. Moe
se zakljuiti, da pojava i isticanje Infrastrukture kao usluge je dovelo do toga da vlasnici sa
svih strana proiruju svoja poduzea zapoljavajui mobilnu radnu snagu.
Utjecajne IT organizacije danas predstavljaju inovativna Infrastruktura kao usluga rjeenja
i aplikacije. Pristup koji ove tvrtke imaju prema svojim klijentima se moe najbolje opisati
kroz termin partnerstvo, umjesto samo pruatelj usluge. Tvrtke asistiraju pri pruanju
vanih i poslovno kritinih aplikacija. Nadalje pruaju pomo organizaciji pri implementaciji
kritine IT infrastrukture.
Dosada su kljuni aspekti IT infrastrukture, hardver, tehnoloka sredstva i administracija bili
tradicionalna domena IT odjela u svakoj tvrtki. Kvalificirano osoblje instaliralo je i
konfiguriralo servere, usmjerivae, vatrozide i ostale ureaje. Ova oprema zahtjeva
odgovarajue skladitenje ali takoer i pripadnu kontrolu okoline. Konano, svaka tvrtka
dodjeljuje dodatni prostor gdje IT osoblje radi kao podrka smjetene infrastrukture. Svaki
aspekt IT infrastrukture je dosad evoluirao sam za sebe, ali donedavno nije se ilo na
integraciju u jednu cjelinu.
Na primjer, tvrtka kupi softver koji joj je potreban te onda kupi i server da pokree taj
softver. Ako je nuna pohrana podataka za podatke i baze podataka, sustavi diskova i tvrdi
diskovi su dodavani u kombinaciju za potrebe tvrtke. Lokalna mrea se odrava da bi
omoguila zaposlenicima pristup IT resursima, i Internet konekcija velike brzine je takoer
neophodna. Praktiki govorei svaki IT sustav ima svoj upravljaki sustav, sa nekim
sustavima koji zahtijevaju i posebno specijalizirano osoblje[3].
Infrastruktura kao usluga uzima ove tradicionalne komponente IT infrastrukture i nudi ih sa
udaljene lokacije u ujedinjenom, skalabilnom paketu tvrtkama koje upravljaju tim
komponentama kroz jedno upravljano suelje.

Prednosti koje pripadaju tvrtki koja koristi IaaS su:

bolje predvianje IT trokova, smanjenje trokova izmeu 20-30% na IT operacijama,

razdvajanje IT trokova od korisnika (tvrtke) i prebacivanje trokova u kategoriju
infrastrukture.

Smanjuje trokove vlasnitva Nema potrebe kupovati sredstva da bi koristili ta

sredstva i smanjuje trokove odravanja i tehnike podrke.

Infrastruktura dostupna kao usluga (spremna na koritenje) omoguava tvrtci da

fokusira svoje vrijeme i resurse na postizanje inovacija u aplikacijama i rjeenjima.

Sve je usluga - Svaka komponenta infrastrukture je dostupna kao usluga. Hardver

kao usluga, server kao usluga, raunalstvo kao usluga, pohrana kao usluga.

Dinamiko skaliranje - Skaliranje usluga infrastrukture bazirano na koritenju

aplikacije, dobro za aplikacije gdje imamo znaajnih poveanja optereenja sustava.
Omoguava skalabilnosti i elasticiteta u poslovanju.

Znaajno ogranienje poetne investicije Posebno pogodno za tvrtke sa

ogranienim kapitalom za
investiranje u hardver i infrastrukturu.

Mjerljiva usluga IaaS usluga je izmjerena i naplaena na bazi jedinica (instanci) koje
su potroene. Plaanje za ono to koristimo i kada koristimo.

Fleksibilna uslunost Pristup infrastrukturi sa bilo kojih udaljenosti, lokacije i

ureaja.

Omoguuje Zelenu tehnologiju Smanjuje utjecaj na okoli sa optimalnim

koritenjem IT resursa i sustava.

5.4.1 IaaS cijena i naplaivanje

IaaS moe biti dostupan na bazi plati-koliko-potroi ili na fiksnoj (eng. flat-rate) bazi

Plati-koliko-potroi model izmjerena usluga. Plaanje za usluge infrastrukture koje

se koriste. Obino se naplata vri po ostvarenom prometu, ali neki prodavai
naplauju i vrijeme zauzetosti servera.

Fiksni model fiksni model na mjesenoj bazi. Na tromjeseju ili na godinjoj bazi za
pretplaenu konfiguraciju.

Stoga, primjeujemo u dananjem natjecateljskom dobu da IaaS aplikacije pruaju tvrtkama

znaajne pogodnosti IT infrastrukture uz takoer ostvarenu konkurentnost na tritu.

5.4.2 Tehnika podloga za IaaS

Da bi omoguili ovaj oblik raunarstva u oblaku, preduvjet je priprema (eng. provisioning)
infrastrukture oblaka u podatkovnim centrima. Meutim, priprema za sustave i aplikacije na
velikom broju fizikih ureaja je proces koji uzima dosta vremena. Nadalje emo se fokusirati
na uslugu pripremanja virtualnog stroja (eng. virtual machine provisioning). Da bi prikazali
to jasnije ovaj koncept pripreme virtualnog stroja predoimo slijedeu analogiju. Kada je
potrebno instalirati novi server za odreenu zadau da bi pruili odreenu uslugu klijentu IT
administrator mora uloiti dosta napora i mnogo vremena se potroi na instaliranje i
pripremanje servera, stoga to administrator mora slijediti specifinu listu zadaa i
procedura da bi obavio svoju zadau. (Provjeriti inventar za novo raunalo, nabaviti ga,
formatirati, instalirati zahtijevani OS (eng. operating system), i instalirati usluge (servise) ).
Sada s pojavom virtualizacijske tehnologije i modela IaaS raunarstva u oblaku,isti rezultat
mogue je postii za par minuta. Sve to trebamo jest pripremiti virtualni server kroz suelje
samo-usluivanja (eng. self-service) u nekoliko koraka da bi dobili to elimo sa zahtijevanom
specifikacijom. Sve bez obzira da li vrimo pripremanje stroja u javnom oblaku kao to je
Amazon Compute Cloud (EC2) ili koristimo softver paket za upravljanje virtualizacijom ili za
privatni oblak upravljako rjeenje instalirano u podatkovnom centru.
Moemo povui istu analogiju za usluge migracije. Prije, kad god bi se pojavila potreba za
nadograivanjem servera ili pri odravanju servera, uloilo bi se dosta truda i napora, jer je
dosta opsean posao nadograivati glavni server koji ima dosta aplikacija i korisnika. Sada, s
napretkom virtualizacijske tehnologije i usluga migracije skupa s mogunostima hypervisora,
ove zadae (odravanje, nadograivanje, zakrpe, itd.) su veoma lagane i u kratko vrijeme
obavljene.
Za pripremanje novog virtualnog stroja nam treba nekoliko minuta, to nam uteuje dosta
vremena i napora. Migracija virtualnog stroja je stvar sekunda.

5.5 Javni, privatni i hibridni oblak

Javni oblak i infrastrukturne usluge
Javni ili eksterni oblak opisuje raunarstvo u oblaku na tradicionalan nain, gdje su resursi
dinamiki pripremljeni preko javno dostupnih Web aplikacija/Web usluga (SOAP ili REST
suelja) sa udaljenog pruatelja usluge, koji dijeli resurse i naplauje dok korisnik plaa samo
za kapacitet pripremljenih (omoguenih) resursa kroz odreeno vrijeme. O primjerima
stvarnih pruatelja infrastrukture kao usluge e biti rijei kasnije.
Privatni oblak i infrastrukturne usluge

Privatni oblak cilja na pruanje funkcionalnosti javnog oblaka, ali sa privatnim resursima, dok
odrava kontrolu na podacima organizacije i resursima da bi sve bilo u suglasnosti s mjerama
sigurnosti i zahtjevima upravljanja u organizaciji. Privatni oblak izlae visoko virtualizirani
podatkovni centar u oblaku smjeten unutar vatrozida organizacije. Moe se takoer raditi o
privatnom prostoru namijenjenom za vau tvrtku unutar podatkovnog centra u oblaku
prodavaa kreiranim da upravlja radnim optereenjima organizacije.
Hibridni oblak
Vano je navesti i trei tip instalacije oblaka nazvan hibridni oblak, u kojem kombinacija
privatnih/internih i eksternih resursa oblaka egzistira zajedno omoguavanjem
eksternaliziranja (eng. outsourcing) nekritinih usluga i funkcija u javnom oblaku, a kritine
ostaju zadrane interno. Glavna funkcija hibridnog oblaka je oslobaanje resursa iz javnog
oblaka i rukovanje iznenadnim zahtjevima za koritenje, to je nazvano cloud bursting.

V1. VIRTUALIZACIJA UVOD

U ovom poglavlju pokuat emo dati uvod u virtualizaciju tj. odgovoriti na pitanja :

to je to virtualizacija i koji su razliiti oblici virtualizacije

Koje su dobiti virtualizacije

Virtualizacija se moe podijeliti na slijedea podruja:

Virtualizacija hardvera

Virtualizacija softvera

Virtualizacija memorije

Virtualizacija sustava pohrane

Virtualizacija podataka

Virtualizacija mree

Potrebno je naglasiti da virtualizacija nije pogodna samo za velike raunalne centre i velike
poslovne ili znanstvene organizacije. IT profesionalci i krajnji korisnici mogu i imat e velike
koristi od virtualizacije.

1.1 Virtualizacija hardvera

Povijesno dugo vremena je odravana 1 na 1 veza izmeu fizikog servera i operacijskog
sustava. Relativno niski zahtjev za CPU, memorijom i mreom dobro su se podudarali s
raspoloivim hardverom. Meutim razvojem aplikacija i poveanim zahtjevima procesiranja,
pohrane i transfera podataka poeli su se isticati trokovi energije, fizikog prostora i samog
sklopovlja.
Osnovni koncept virtualizacije je apstrakcija. Hardverska virtualizacija postie se apstrakcijom
fizikog sloja hardvera upotrebom hypervisora. Hypervisor upravlja dijeljenjem fizikih
resursa hardvera izmeu operacijskih sustava koji su pokrenuti na domainu (host). Fiziki
resursi postaju apstraktni u standardiziranom formatu bez obzira na hardver u podlozi.
Operacijski sustav moe ih zahvaati na isti nain kao to zahvaa fizike resurse. Postoje
razliiti stupnjevi hardverske virtualizacije:
Puna Gostujui operacijski sustav je potpuno nesvjestan virtualizacije. Hypervisor obrauje
sve OS-hardver zahtjeve i moe keirati rezultate za buduu upotrebu. U ovoj instanci
virtualizirani OS je u potpunosti izoliran od hardverske podloge. Ovo omoguava najvei
mogui nivo sigurnosti i fleksibilnosti a time i iri opseg operacijskih sustava koji se mogu
virtualizirati.

Paravirtualizacija Gostujui operacijski sustav je dizajniran na nain da je svjestan

virtualizacije. Jezgra operacijskog sustava je podeena da zamijeni neke instrukcije s
metodama koje direktno meudjeluju s hypervisorom. Vrijednost paravirtualiziranih sustava
je u manjim dodatnim kanjenjima a time mogunosti optimalnijeg izvoenja operacija.
Paravirtualizaciju obino susreemo u Linux okolini u vidu Xen kernela.
Potpomognuta hardverom Isporuioci hardvera uvidjeli su prednosti virtualizacije i uveli su
u svoj hardver podrku za podizanje performansi i funkcionalnosti. To je najizraenije kod
procesora kroz AMD-V i Intel VT poboljanja procesora. Ona omoguuju da se pojedini CPU
pozivi/naredbe ne prolaze kroz hypervisor ve direktno izvode na CPU-u. To smanjuje
optereenje hypervisora i time podie performanse sustava.

1.1.1 to je to hypervisor
Softver za virtualizaciju kojeg nazivamo hypervisor emulira raunalni hardver dozvoljavajui
da se na jednom raunalu pokree vie operacijskih sustava. Svaki gostujui OS ima utisak da
posjeduje vlastiti procesor, memoriju i ostale resurse.

Zapravo hypervisor upravlja procesorom, memorijom i ostalim resursima domaina te

alocira potrebne resurse gostujuim operacijskim sustavima, brinui se pri tome da ne dolazi
do neeljene meusobne interakcija operacijskih sustava.

Hypervisor

Postoje dva osnovna tipa hypervisora.

Tip 2 Tip 2 hypervisori instalirani su povrh operacijskog sustava (hosted). Kanjenja u

izvoenju pojedinih operacija su vea jer idu preko operacijskog sustava koji u stvari upravlja
raspodjelom resursa. Primjeri su VMware Workstation (Player), Microsoft Virtual PC, Fusion i
Oracle VirtualBox. Oni se instaliraju kao aplikacija unutar OS. Tip 2 hypervisori imaju
prednost da preko pogonitelja operacijskog sustava mogu imati podrano vie I/O tipova
ureaja nego je to sluaj s Tip 1 hypervisorima. Zbog izvoenja operacija na hardveru kroz
OS performanse su 70-90% u odnosu na direktno izvoenje.

Tip 1 Tip 1 hypervisori su instalirani direktno na hardver (bare-metal), slino kao to se OS

instaliraju na pojedinani server. Zbog direktne komunikacije hypervisor-hardver , kanjenja
su mala i samim time bolje performanse. Primjeri Tip-1 hypervisora su: VMware ESXi,
Microsoft Hyper-V i Citrix XenServer. Hypervisor treba biti usklaen s hardverom pa je
mogue da ga nije uvijek mogue instalirati na svaki stroj. Podrava vei broj VM po fizikom
CPU nego to je to sluaj kod Tip 2 hypervisora. Performanse variraju od 85-98% u odnosu na
direktno izvoenje.

1-1 Tip1 i Tip2 hypervisori

1.1.2 Dobiti hardverske virtualizacije

Glavne dobiti virtualizacije ukljuuju efikasnije koritenje resursa, manje ukupne trokove
(ROI), bre vraanje investicije, poveano vrijeme dostupnosti sustava (uptime) i veu
fleksibilnost sustava. Detaljnije:

Efikasnije koritenje resursa: Fiziki resursi se mogu dijeliti izmeu virtualnih

strojeva. Nekoriteni resursi, iako alocirani za pojedini virtualni stroj u sluaju potrebe
mogu se prealocirati drugim virtualnim strojevima.

Manji trokovima uslijed konsolidacije servera / bri povrat investicije: Sada kad je
mogue da se viestruki operacijski sustavi izvravaju na jednom stroju/platformi
mogue je znaajno reducirati broj servera, ormara te posebno reducirati sustav
napajanja i hlaenja.

Poveana dostupnost sustava zbog virtualizacije : Moderni hypervisori posjeduju

mogunost orkestracije operacija nad instancama virtualnih strojeva koje finalno
podiu dostupnost sustava, npr.:

Sposobnost migriranja strojeva s jednog na drugi host bez gaenja

Odravanje pokrenutih kopija strojeva kao rezerve

Poveana fleksibilnost IT sustava: Hardverska virtualizacija omoguava brzo

uspostavljanje servera na upravljiv i konzistentan nain. Na taj nain mogue je da IT
brzo reagira na potrebe poslovnih procesa.

1.2 Virtualizacija softvera

Upravljanje tj. distribucija aplikacija postaje veoma teak zadatak za IT odjele, posebno u
okruenjima s velikim brojem korisnika. Instalacijski mehanizmi se razlikuju od aplikacije do

aplikacije. Neki programi zahtijevaju odreene pomone aplikacije ili okoline, a aplikacije i
okoline mogu biti u konfliktu s postojeim aplikacijama ili novim aplikacijama.
Virtualizacija softvera omoguava da se izvri apstrakcija instalacije softvera i da se kreira
virtualna instalacija softvera. Virtualizirani softver je aplikacija koja je instalirana u zatvorenu
samostalnu jedinicu.
U Windows okolini ta jedinica sadrava virtualni registry , %TEMP% direktorij i mjesto za
pohranu podataka. Takva aplikacija postaje jedna cjelina koja se isporuuje na nain kao da
se kopira datoteka na neku lokaciju. Aplikaciji se moe dozvoliti interakcija s okolinom ili da
ostane zatvorena u okviru sebe. Instalacijski postupak aplikacije u ovakvom sluaju postaje
postupak poput diff operacije. Nakon konfiguracije istog operacijskog sustava uzima se
snimka okoline (snapshot). Nakon toga instalira se aplikacija te ponovo radi snapshot cijele
okoline. Razlika izmeu snimaka je zapravo virtualizirana aplikacija.

Prednosti softverske virtualizacije:

Ova metodologija donosi znaajne prednosti odravateljima aplikacija:

Laka isporuka klijenata: postupak instalacije svodi se na kopiranje na radnu stanicu

klijenta ili samo na povezivanje (linking) na aplikaciju na djeljivom prostoru mrene
pohrane (network share). Takva instalacija se moe vrlo lako automatizirati.

Dodana sigurnost: softverska virtualizacija omoguava i uvezivanje s LDAP/Active

directory mehanizmima koji daju dozvole pokretanja softvera. Time se vrlo lako moe
odrediti i strojevi i korisnici koji imaju pravo pokretanja aplikacije pa ak i vremena
kad mogu pokretati aplikacije.

Lakoa odravanja: Upravljanje nadogradnjama postaje daleko jednostavniji zadatak.

Nova verzija se kopira na mjesto za distribuciju. Zatim se izvrava isporuka (kopiranje)
nove verzije na mjesto stare. Ako nova aplikacije ne profunkcionira moe se vrlo lako
vratiti na staru verziju (kopiranje stare verzije na mjesto nove). Odravatelj aplikacija
ima mehanizam za jednostavno upravljanje verzijama.

Migracija softvera: Premjetanje korisnika s jedne platforme na drugu zna biti vrlo
zahtjevan zadatak. Ako su aplikacije izolirane od operacijskog sustava onda migracija
aplikacija se svodi na kopiranje.

Rjeavanje konflikata razliitih softvera: Zbog injenice da je softver zatvoren u

virtualni kontejner, aplikacije koje su prije moda imale meusobne konflikte sada
mogu funkcionirati.

1.3 Virtualizacija memorije

U najjednostavnijoj formi virtualizacija memorije odnosi se na virtualnu memoriju (swap) na
serverima ili radnim stanicama. Konceptualno swap postoji da bi se na sustavu s
napunjenom memorijom nastavilo izvravanje bez potrebe za zaustavljanjem ili ubijanjem
procesa. Procesi na raunalu vide swap memoriju kao dodatno adresabilnu memoriju i ne
razlikuju je od glavne RAM memorije. Operacijski sustav brine se da se prvenstveno koristi
puno bra RAM memorija. Intenzivno koritenje swap memorije predstavlja znaajnu
degradaciju sustava. Pisanje na disk, ak i SSD disk, daleko je sporije od radne memorije.
Velika propusna mo i niske latencije specijaliziranih mrea omoguavaju koritenje
virtualizacije memorije. To su tehnologije poput InfiniBand ili veza u klasterima. Remote
Direct Memory Access (RDMA) koristi se za daljinski pristup memoriji raunala bez neeljenih
interferencija. RDMA postaje jo jedna sekcija adresabilne memorije za raunalo. Brzina je
daleko vea od swap datoteke. Kako se budu sve vie koristile 10Gb veze tako e RDMA
postajati sve znaajnija opcija. Za RDMA se razvijaju i Ethernet standardi.

Isporuioci serverskih virtualizacija sve vie koriste mogunost apstrakcije memorijskih

resursa te su realizirane neke vrlo interesantne funkcionalnosti:

Sposobnost dijeljenja zajednikih memorijskih stranica izmeu razliitih strojeva. To

je vrlo zgodno ako domain pokree viestruke kopije istog operacijskog sustava.
Tada nema potrebe da postoje viestruke kopije istih stranica OS, te se time oslobaa
znaajna koliina memorije.

Sposobnost snimanja (snapshot) memorije i vraanje na prethodno stanje ako novo

nije optimalno ili prihvatljivo

Mogunost transmisije stanja memorije kroz mreu na drugi host za potrebe

migracije virtualnog stroja s jednog hosta na drugi

Kompresija memorijskog prostora

Otputanje alocirane, ali nekoritene memorije kako bi se preusmjerila na druge

strojeve.

Prednosti virtualizacije memorije

Prednosti virtualizacije memorije ukljuuju:

Efikasnije koritenje memorije dijeljenjem ukupne memorije i s time mogunost

pokretanja veeg broja virtualnih strojeva na raunalu domainu.

Ciljano upravljanje raspodjelom zajednike memorije

Pristup memoriji i vie nego to je u raunalu domainu mogue smjestiti

Napredne funkcije virtualizacije poput migracije.

1.4 Virtualizacija pohrane podataka

Povijesno postoji jaka veza izmeu fizikog raunala domaina i lokalno instaliranih sustava
pohrane. Ova paradigma se u zadnje vrijeme drastino mijenja u toj mjeri da dolazimo do
toke da lokalni sustav pohrane nije potreban.
Virtualizacija sustava pohrane postaje najbolja praksa za servere u formi upravljaa sustavom
diskova koji mogu biti organizirani u RAID ili jo naprednije sustave (Grid). Operacijski sustavi
i aplikacije i dalje piu po disku. U pozadini upravljaki sustavi konfiguriraju diskove u RAID
ili sl. Grupe te prezentiraju to operacijskom sustavu kao jednu ili vie jedinica pohrane
(Logical Volumes). Operacijski sustav alje naredbe jedinici pohrane (Volumes) i ima utisak
da radi s diskom. Meutim sustav pohrane je apstrahiran jer upravlja odreuje kako e i na
koje mjesto zapisivati ili itati podatke.
Virtualizacija porane podataka javlja se danas u razliitim oblicima:

Datoteni server (File server): Operacijski sustav pie na udaljenu lokaciju bez
potrebe da razumije kako se pie na fiziki mediji.

pNFS: komponenta NFS 4.1 sustava, pNFS /parallel NFS), moe zahtijevati podatke s
udaljenog NFS dijeljenog prostora. Meutim podaci mogu biti pohranjeni na

razliitim lokacijama i medijima. Traitelj podataka nije svjestan toga gdje su podaci
jer dohvat i isporuku podataka obavlja NFS server.

NAS i SAN: sustav pohrane se operacijskom sustavu predstavlja preko ethernet

mree. NAS sustav omoguava pristup preko datotenih operacija (NFS, CIFS). SAN
tehnologija omoguava pristup na nivou blokova (poput iSCSI ili Fibre chanell), dakle
poput lokalnog sustava pohrane.

Storage Pools: Na nivou velikih korisnika poeljno je koncentrirati veu koliinu

diskova i dobiveni prostor prezentirati u apstraktnom obliku. Administrator odreuje
podjelu ukupnih resursa na nain da kreira virtualizirane jedinice s odreenom
veliinom, propusnom moi i prioritetom. Vea koliina diskova u sustavu omoguava
vee performanse i veu pouzdanost. Performanse se postiu paralelizacijom, a
pouzdanost time da otkaz jednog diska predstavlja otkaz vrlo malog dijela ukupnog

sustava. Velika koliina diskova esto koristi i napredne sustave razmjetaja

podataka, tj. umjesto uobiajenih RAID shema koriste se sheme jo vieg stupnja.

Storage Tiering (pohrana u slojevima): Zasnovano na storage pools sustavu, sustav s

pohranom u slojevima stalno analizira transfere podataka i podatke koji se najee
koriste sprema u pool s najveim performansama. Primjeri su sustavi pohrane koji su
kombinacija SSD i standardne tehnologije diskova ili razliitih tipova diskova.

Prednosti virtualizacije pohrane

Prednosti su:

Podaci su pohranjeni na pouzdanu lokaciju dalje od raunala domaina. U sluaju

otkaza raunala domaina podaci nisu nuno kompromitirani.

Napredni sustavi pohrane mogu osiguravati funkcije poput: deduplikacija, replikacija,

thin provisioning, oporavak od veih greaka.

Apstrakcijom sustava pohrane, IT operacije dijeljenja, dostupnosti i zatite postaju

fleksibilnije.

1.5 Virtualizacija podataka

Podaci u okolini poprimaju razliite oblike. Mogu biti dinamini , ali i statini. Nekada su
pohranjeni u bazu podataka, a mogu biti pohranjeni u obinu datoteku. Nekada su smjeteni
u raunovodstveni sustav, a ponekad u sustav ljudskih resursa. Lokacija podataka moe biti
Europa, ali i neki drugi kontinent. U nekim sluajevima podaci su zasnovani na cijelim
brojevima, a u drugom koriste brojeve u pokretnom zarezu.
Upravljanje lokacijom podataka i njihova dostupnost mogu biti veliki problem u sluajevima
kad je radi analize podatke potrebno povui iz razliitih izvora. Virtualizacija podataka bavi se
apstrakcijom lokacije, metoda pristupa i tipova podataka, omoguavajui korisniku da se
koncentrira na sadraj podataka. To je tipian primjer u aplikacijama poslovnik okruenja,
kao to su IT Dashboards, BI alati i CRM alati.

Dashboard i BI/CRM alati omoguavaju upravljanje apstrakcijom lokacije podataka. Takvi

alati posjeduju mogunost pristupa razliitim izvorima podataka te iste agregiraju u
jedinstven skup pogodan za analizu. Izvori podataka ukljuuju konektore baza, API-je,
podatke na webu, podatke senzora, spremita datoteka, aplikacije, itd. Analitiar nema
potrebu poznavanja izvora i formata podataka, ve samo da li isti postoje i da li su ispravni.
Koristi virtualizacije podataka

Manje brige za krajnjeg korisnika koji ne mora posjedovati tehnika znanja o tome
gdje i kako su podaci pohranjeni niti o sigurnosnim mehanizmima pristupa.

Posljedino prvome mogue je bolje fokusiranje na samu analizu podataka.

1.6 Virtualizacija mree

Virtualizacija hardvera se moe promatrati kao apstrakcija i kreiranje viestrukih logikih
sustava na jednoj fizikoj platformi. Za virtualizaciju mree to ostaje istinito, ali ne i tako
jasno kao za virtualizaciju servera.
Svaki virtualni stroj moe biti konfiguriran s jednom ili vie virtualnih ethernet kartica. Te
kartice gostujui OS vidi kao uobiajene mrene kartice i koristi svoje standardne
pogonitelje. Postoji manji broj tipova virtualnih mrenih adaptera (npr. E1000, Realtek), a
pojedini isporuioci virtualizacijskih rjeenja napisali su optimizirane pogonitelje za razliite
OS.
Virtualne mrene kartice prikljuene su na virtualne preklopnike, a virtualni preklopnici na
fiziku karticu/kartice.
Virtualni preklopnici omoguavaju komunikaciju virtualnih strojeva na istom hostu
koritenjem istih protokola koji se koriste na fizikim preklopnicima. Virtualni preklopnik
emulira standardni fiziki Ethernet preklopnik na nivou prosljeivanja okvira (podatkovni
sloj). Na virtualni preklopnik moe se prikljuiti i jedna ili vie fizikih ethernet kartica.
Raunalo domain moe posjedovati vie virtualnih preklopnika s praktiki neogranienim
brojem virtualnih portova.

Prednosti virtualizacije mree

Lako upravljanje promjenama: rekonfiguracija mrene povezivosti unutar virtualnog

stroja obavlja se bez fizikog prespajanja

Utede: Virtualizacijom sloja preklopnika mogue je efikasnije dijeljenje tako

kreiranog mrenog resursa. Mogunost dinamike dodjele resursa omoguavala bolje
balansiranje optereenjem tako realiziranim mrenim podsustavom.

Sigurnost: Zbog ujednaene arhitekture i logike separacije slojeva mnoge sigurnosne

rizike je mogue lake kontrolirati

V2. KREIRANJE VIRTUALNOG STROJA NA ESXI OKOLINI

Nakon instalacije hypervisora (ESXi) i klijenta (vSphere) mogue je pristupiti kreiranju
virtualnog stroja. Nakon pokretanja vSphere klijenta potrebno je logirati se na server sa
korisnikim imenom i lozinkom (user10/** ).

Slika 1: Unos adrese server, korisnikog imena i lozinke

Vjerojatno ete nakon ovog koraka dobiti upozorenje kao na slijedeoj slici. Ono u osnovi
znai da SSL certifikat koji se koristi na ESXi stroju nema vae povjerenje. Ako ste sigurni da
dolazi s vaeg servera moete ga ignorirati ili izabrati instaliranje certifikata u vau lokalnu
pohranu certifikata kako se isto upozorenje ne bi vie javljalo.

Slika 2: Moete ignorirati ovo upozorenje.

Nakon logiranja u vSphere klijent kliknite na adresu vaeg server i izaberite New Virtual
Machine

Slika 3: Kreiranje novog virtualnog stroja

Prva opcija je jednostavna, a pita vas se da li odabirete tipine vrijednosti zasnovane na OS

kojeg ete koristiti ili posebno podeavanje (custom). Za potrebe ove vjebe odabiremo
Custom.

Slika 4: Podeavanje virtualnog stroja

Slijedei korak je upis jedinstvenog imena stroja.

Slika 5: Imenovanje VM

Za sluaj vjebi koristimo sustav lokalne pohrane na samom ESXi hostu. Dakle pohrana nije
na SAN ureaju kako je to uobiajeno. Stoga e virtualni stroj biti sadran na lokalnom
sustavu pohrane, kako to pokazuje slijedea slika.

Slika 6: Odabir sustava pohrane

VMware povremeno uvodi nove verzije formata virtualnog stroja. Verzija 8 donosi nova
unapreenja poput sposobnost 3D grafike ili koritenja USB 3.0 ureaja. Po ovome se vidi da
se cilja na virtualizaciju desktopa. Tablica ispod daje neke najbitnije razlike izmeu dviju
verzije 8 i 7. Iako je verzija 8 skalabilnija, treba pripaziti s njenim koritenjem jer je mogue
da nije podrana sa svim alatima potrebnim za integraciju s razliitim OS.
Neke mogunosti VM su vezane i za verziju ESXi servera. Npr. Broj procesora ili maksimalna
koliina RAM memorije

Tablica : Bitne razlike VMware virtualnog stroja 7 i 8

Version 7

Version 8

SMP

8-way

32-way

RAM

256 GB

1 TB

3D support

No

Yes

BIOS

Yes

Yes

EFI

No

Yes

CPU hot add

Yes

Yes

RAM hot add

Yes

Yes

Slika 7: Biranje verzije VM

Slijedei korak je odreivanje operacijskog sustava koji e se izvravati na VM. Selekcijom

OS-a se aktiviraju preporuene specifikacije za koje bi taj OS trebao dobro funkcionirati.

Slika 8: Izbor OS

Slijedei korak je odabir broja virtualnih utora i jezgri. ESXi 5 sustav donosi ovu podjelu
prvenstveno za potrebe zadovoljavanja licencnih uvjeta pojedinih OS. Ukupan broj jezgri je
umnoak broja utora i broja jezgri po utoru.

Slika 9: Specifikacija CPU opcija

Slijedi dodjela RAM memorije virtualnom stroju. arobnjak za kreiranje daje niz preporuka za
veliinu RAM memorije poevi od najmanje preporuene veliine za zdani OS, preko
preporuene do maksimalno preporuene koliine.

Slika 10: RAM preporuka

Svaki virtualni stroj treba jedan ili vie mrenih adaptera. Zbog toga je potrebno odabrati
broj NIC-ova i njihov tip te svakog spojiti na neku od virtualnih mrea.
E1000. E1000 je emulirana verzija od irom koritenog Intel 82545EM Gigabit Ethernet
adaptera. Ne moraju svi gostujui OS podravati navedeni adapter. Ako je pokrenut sustav
Linux kernelom 2.4.19 ili kasnije, Windows XP Professional x64 Edition i poslije i Windows
Server 2003 (32-bit) i kasnije, osigurana je podrka za E1000 adapter.
VMXNET 2 (Enhanced). Za razliku od E1000 ovi virtualni adapteri nemaju svoje fizike
parnjake i dizajnirani su posebno za upotrebu u virtualnim strojevima. Kada na gostujui OS
instalirate VMware Tools, osigurani su pogonitelji za ovaj adapter. VMXNET 2 je zasnovan na
prethodnom virtualnom adapteru VMXNET uz novo dodane osobine poput podrke za
jumbo okvire.
VMXNET 2 podrka osigurana je u slijedeim OS : Windows Server 2003, Windows Small
Business Server 2003, Windows XP Pro 32-bit, Red Hat Enterprise Linux 5.0, SUSE Linux
Enterprise 10, Red Hat Enterprise Linux 4.0 64-bit, Ubuntu Linux 64-bit
VMXNET 3 nije samo slijedea verzija VMXNET 2. Ima potpuno novi dizajn s podrkom za
napredne mrene osobine. Podrka je ve ukljuena u : Microsoft Windows XP,7, 2003, 2003
R2, 2008 i 2008 R2, Red Hat Enterprise Linux 5.0, SUSE Linux Enterprise Server 10, Debian
4, Ubuntu 7.04 , Sun Solaris 10

Slika 11: Izbor mrenog adaptera

Izbor SCSI upravljaa vezan je za OS koji elimo instalirati i ima vei utjecaj na performanse
nego izbor mrenog adaptera. Pojedini OS bolje performanse postiu s odreenim
upravljaima. Stoga je dobro drati se preporuke koju nam daje VMware arobnjak (ako smo
odabrali konkretan tip OS u prethodnim koracima).
BusLogic Parallel : pretpostavljeno za starije OS.
LSI Logic Parallel : kompatibilan s veinom OS, ali ne i optimalan izbor za sve OS.
LSI Logic SAS : za sustave zasnovane na Windows OS.
VMware Paravirtual: najbolje performanse, ali i ograniena podrka za OS.

Slika 12: Izbor SCSI upravljaa

Slijedei korak je odabir virtualnog diska. Moete kreirati novi, koristiti stari, mapirati na
RAW ureaj ili uope ne koristiti disk.

Slika 13: Odabir diska

Kako emo kreirati novi disk potrebno je odrediti njegove parametre.

Osim veliine diska potrebno je odabrati dodatne parametre. Prvi je provisioning
(omoguavanje). Postoje u osnovi dvije varijante Thin/Tick. Thick varijanta u potpunosti
alocira prostor za disk na sustavu pohrane, a thin varijanta alocira prostor na sustavu
pohrane prema potrebi, odnosno kako se disk puni. Thin provisioning osigurava ekonomino
upravljanje prostorom, ali je potrebno paziti da se ne premai ukupno raspoloiv prostor
diska prilikom ekspanzije pojedinih diskova. Lazy zeroed / eager zeroed opcije odnose se na
brisanje prethodnog sadraja diska. Osim brisanja eager zeroed opcija obrisani prostor
popunjava nulama to u nekim primjenama moe imati prednosti.

Slika 14: Odabir lokacije virtualnog diska

Ako je potrebno mogue je na zakljunim stranicama arobnjak podesiti dodatne opcije.

Slika 15: Odabir SCSI vora

Slijedei korak je instalacija OS. Instalaciju je mogue zapoeti s razliitih izvora (PXE boot s
mree, DVD/CD,...). Poto na virtualnom stroju nemamo pristup fizikom CD/DVD ureaju,
instalaciju moemo pokrenuti s ISO slike. ISO slike mogu biti pohranjene na bilo kojem
sustavu pohrane dostupan virtualnom stroju. U naem sluaju to je jedan od direktorija na
sustavu pohrane koji koristimo i za sam smjetaj slika virtualnih strojeva.

Slika 16: Odabir ISO slike instalacijskog CD/DVD

Odabirom odgovarajue slike i odabirom opcije da je virtualni CD/DVD ureaj ukljuen

prilikom dizanja sustava nakon paljenja virtualnog stroja, pokree se instalacija sustava.

Slika 17: Prvi ekran prilikom podizanja sustava

V3. HTCONDOR - UPRAVLJANJE POSLOVIMA

U ovom dijelu vidjet emo kako na jednostavan nain uspostaviti Grid sustav zasnovan na
HTCondor distribuiranom softverskom sustavu.

3.1 Uvod
HTCondor je distribuirani softverski sustav koji omoguava izvoenje HTC (High Throughput
Computing) zadataka na distribuiranim resursima koji mogu imati i distribuirano vlasnitvo.
HTCondor je proizvod dugogodinjeg istraivanja od strane Centra za HPC raunarstvo na
odsjeku za raunalne znanosti na Sveuilitu Wisconsin-Madison (UW-Madison). Po prvi put
je instaliran kao radni sustav prije vie od 15 godina. Stotine organizacija u industriji, vladi i
akademske zajednica koriste HTCondor zasnovana raunalna postrojenja u rasponu veliina
od nekoliko do vie tisua radnih jedinica.
HTCondor realizira red prijema-ekanja-izvravanja (job queue) za poslove, raspored
poslova, shemu prioriteta, praenje resursa i upravljanje resursima. Kad korisnici poalju
svoje serijske ili paralelne poslovi na HTCondor, HTCondor ih stavlja u red, odluuje kada i
gdje izvoditi poslove na temelju zadane politike, prati njihov napredak te u konanici
obavjetava korisnika nakon zavretka poslova.
HTCondor moe se koristiti za upravljanje poevi od grozda, preko grida do distribuiranih
sustava koji koriste neiskoritenu procesorsku snagu stolnih raunala.
Na primjer, HTCondor moe biti konfiguriran da koristiti stolna raunala samo kada su
tipkovnica i mi u stanju pripravnosti. Ukoliko HTCondor detektira da stroj vie nije dostupan
(aktivnost korisnika), u mnogim sluajevima je u stanju transparentno proizvesti kontrolnu
toku i prebaciti posao na neki drugi stroj koji bi inae bio u stanju mirovanja. HTCondor ne
zahtijeva zajedniki sustav datoteka. Ako se ne dijeli sustav datoteka, HTCondor moe
prenijeti podatke u ime korisnika ili moe transparentno preusmjeriti sve ulazno/izlazne
zahtjeve posla na stroj koji je naloio zadatak. Kao rezultat toga, HTCondor moe se koristiti
da neprimjetno kombinira sve raunalne resurse u jedan izvor.
HTCondor ClassAd mehanizam prua iznimno fleksibilan i izraajan okvir za podudaranje
zahtijevanih resursa poslova sa resursima strojeva. Posao moe navesti zahtjeve, a isto tako i
preference. Isto tako, strojevi mogu odrediti uvjete i vrste poslova koji su spremni pokrenuti.
Ti zahtjevi i preference mogu se opisati posebno razraenim izrazima, to rezultira da se
HTCondor moe adaptirati na gotovo bilo koji eljenu politiku rasporeda.
HTCondor moe se koristiti za izgradnju Grid-style raunalnih okruenja koja prelaze
administrativne granice. HTCondor "flocking" tehnologija omoguuje da vie HTCondor
sustava rade zajedno. HTCondor sadri mnoge suvremene Grid i Cloud zasnovane raunalne

metode i protokole. Na primjer, HTCondor-G je potpuno interoperabilan s resursima kojima

upravlja Globus sustav.

3.2 Instalacija HTCondor vora

HTCondor vor moe se instalirati na razliite OS (Linux, Unix, Mac OS X, FreeBSD). Za
potrebe vjebi instalirat emo ga na virtualnom stroju Linux Ubuntu 14.04 LTS.
Bar jedan tip vora mora biti instaliran i konfiguriran na raunalima koji sudjeluju u obradi
podataka:

glavni vor (head, master - HTCondor sredinji upravitelj)

izvrne vorove (worker nodes)

jedan ili vie vorova za podnoenje zadataka (submit vorovi)

Mogue je na jedno raunalo instalirati jedan, dva ili sva tri tipa vora.
Neki koraci instalacije i konfiguracije trebaju biti izvedeni na svakom voru, ali specifina
konfiguracija za svaki vor razlikuje po vrsti tog vora.
Na primjer, glavni vor i submit vorovi mogu svaki ima posebne konfiguracije, ali svi worker
vorovi mogu imati istu konfiguraciju tj. mogu biti klonirani.
Najvaniji direktoriji bitni za postupak instalacije su:

/var/lib/Condor - sadri HTCondor spool (privremeni radni direktorij)

/etc/condor katalog sadri konfiguracijske datoteke

/var/log/condor sadri log datoteke HTCondor sustava

3.3 Hardverski i ostali zahtjevi

Navedeni su minimalni hardverski zahtjevi za vor. Ako zadaci koji se planiraju izvoditi na
ovom ureaju zahtijevaju vee resurse trebamo ih osigurati podeavanjem virtualnog stroja.

Standardni Intel / AMD x86-kompatibilan PC ,

1 GHz ili bri procesor,

512 MB RAM-a,

2G slobodnog prostora na disku,

Mreni pristup.

Dalje je za instalaciju HTCondor sustava potrebno:

Jedno raunalo za HTCondor glavni vor (Collector and Negotiator),

Jedno ili vie raunala za HTCondor submit node (Schedd),

Raunala za HTCondor izvrne vorove (Startds),

podrani operacijski sustav npr. Ubuntu 14.04 LTS,

root prava pristupa.

3.1 Postupak instalacije na Ubuntu 14.04 LTS sustavu

Za instalaciju je potrebno imati pripremljen stroj s podranim operacijskim sustavom, a u
naem sluaju je to Ubuntu 14.04 LTS. Preporuljivo je za ove vjebe da je su worker i submit
strojevi namjeteni na DHCP mrene postavke iako mogu imati i statike adrese.
Prilikom instalacije potrebno je izvriti niz dalje opisanih koraka:
ZAJEDNIKI POSTUPAK
sudo apt-get update (update instalacijskog repozitorija)
sudo apt-get install mc (koristan program za navigaciju i editiranje)
wget http://zeta.fesb.hr:1111/public/HTCondor/condor-8.2.7-300022-ubuntu_14.04_amd64.deb
sudo dpkg -i condor-8.2.7-300022-ubuntu_14.04_amd64.deb
sudo apt-get -f install (prisilno instalira nedostajue softverske pakete)

GLAVNI VOR (Podeavanje)

sudo mcedit /etc/condor/condor_config
ALLOW_WRITE

$(FULL_HOSTNAME)

$(IP_ADDRESS)

CONDOR_HOST

$(CONDOR_HOST)

*.fesb.hr
127.0.0.1

DAEMON_LIST = COLLECTOR, MASTER, NEGOTIATOR, SCHEDD, STARTD

sudo service condor restart
WORKER-SUBMIT NODE
sudo mcedit /etc/condor/condor_config
ALLOW_WRITE = $(FULL_HOSTNAME) $(IP_ADDRESS) localhost $(CONDOR_HOST)
CONDOR_HOST
DAEMON_LIST = MASTER, SCHEDD, STARTD
sudo service condor restart

mega.fesb.hr

3.2 Podnoenje zahtjeva za HTCondor poslom

Veina korisnika e prvenstveno koristiti HTCondor kroz suelje za podnoenje poslova.
Glavne naredbe koje korisnik trebaju su "condor_submit", "condor_q" i "condor_status".
Kako bismo objasnili djelovanje ovih naredbi, koristit emo jedan od ponuenih primjera. To
je primjer koji koristi Monte Carlo metodu za procjenu vrijednosti broja PI. Ovaj primjer
ilustrira uobiajenu uporabu grid raunalstva. Program ima samo jedan argument, a to je
koliko toaka generira. Na temelju tog parametra, on generira sluajne toke u jedininom
kvadratu i izraunava omjer toaka koje ulaze unutar jedinine krunice kako bi procijenio
vrijednost broja PI. Naravno, procjena e biti tim bolja to imamo vie generiranih toaka, ali
sve pod uvjetom da je generator sluajnih brojeva kvalitetan. Kako to radi moe se vidjeti
unutar datoteke izvornog koda - montepi.c.
Upiite sljedee naredbe u ljusci kolodvora:
montepi example
sudo apt-get install gcc
wget http://zeta.fesb.hr:1111/public/HTCondor/condor_examples.tgz
tar xvzf condor_examples.tgz
cd condor/examples/montepi
cat readme.txt
gcc montepi.c -o montepi lm
condor_submit submit_montepi_vanilla
condor_q
condor_status
U poetnom koraku instalira se GNU C prevodilac. Za izvrenje instalacije bit e potrebno
unijeti password korisnika s root pristupom. Nakon toga pritisnite tipku Y i nastavite. Zatim
povlaimo (wget) i raspakiramo datoteku s primjerima. Zatim se pozicioniramo u direktorij s
primjerom. Naredba gcc prevodi i povezuje montepi.c u izvrnu datoteku. Posao aljemo na
izvravanje s "condor_submit" koji uzima kao ulaz konfiguracijsku datoteku
submit_montepi_vanilla. Koristite "more submit_montepi_vanilla" naredbu da biste
pregledali tu datoteku. Condor konfiguracijske datoteke slanja poslova mogu biti puno
sloenije nego prethodno koritena, ali ovaj primjer pokazuje konfiguraciju koja je korisna za
mnoge jednostavne aplikacije.
condor_q provjerava napredak naih poslova - svakom poslu je dodijeljen identifikator.
Status "I" znai da je posao miruje, a "R" oznaava posao radi. condor_status

provjerava status cijelog HTCondor bazena i drugih poslova koji su pokrenuti u sustavu.
Dok su poslovi pokrenuti, pogledajte sadraj Condor submit konfiguracijske datoteke:
more submit_montepi_vanilla

Primijetit ete da se specificira koriteni Condor "Universe" (vanilla podrava nemodificirane

izvrne datoteke), naziv izvrne datoteke (montepi) i argumente aplikacije. U ovom primjeru,
50 poslova je poslano na izvravanje s argumentom 10000, a zatim jo 50 poslova s
argumentom 20000.
Nakon to 100 poslova zavri, rezultati e biti smjeteni u datoteke s nastavcima "*.out".
Upiite sljedeu naredbu da biste vidjeli svih 100 PI procjena koje su bile izraunane:
grep pi *.out
Datoteke s nastavkom "*.log" pokazuju mjesto izvravanja svakog HTCondor posla. Upiite
sljedeu naredbu da biste vidjeli virtualnu IP adresu svakog ureaja koji izvrava posao:
grep executing *.log

V4. HTCONDOR - UPRAVLJANJE POSLOVIMA

U svojoj jezgri HTCondor je specijalizirani batch sustav za upravljanje raunalno zahtjevnim
poslovima. Kao mnogi drugi batch sustavi, HTCondor sadrava mehanizam za redove
ekanja, politiku rasporeda, sheme prioriteta i klasifikaciju resursa. Korisnik alje svoje
poslove HTCondoru, HTCondor stavlja poslove u red ekanja, po1kree ih i korisnika
obavjetava o rezultatu.
Batch sustavi obino rade samo s dediciranim strojevima, tj . raunalima koja su namijenjena
iskljuivo izvravanju raunalnih poslova. Meutim, HTCondor je dizajniran da moe
efektivno upotrebljavati i strojeve koji nisu prvenstveno namijenjeni izvravanju poslova, ve
koji se koriste i za druge namjene. U tom sluaju HTCondor se moe podesiti da takve
strojeve koristi samo u sluaju kad ne izvravaju svoje primarne poslove na nain da prati
aktivnost tipkovnice ili prosjeno optereenje stroja. To je bitno jer uobiajena je situacija da
ukupna raspoloiva raunalna snaga desktop raunala esto premauje snagu dediciranih
resursa u okviru jedne organizacije.

4.1 Uparivanje (matchmaking) s ClassAds

Kako bismo efikasno koristili algoritam rasporeivaa HTCondora potrebno je znati kako
HTCondor uparuje poslove s raspoloivim resursima (strojevima).
HTCondor pojednostavljuje slanje poslova na nain da djeluje kao upariva za ClassAds.
ClassAds su neto kao oglasi u novinama. Prodava specificira to prodaje nadajui se da e
privui kupce. Kupci mogu oglaavati specifine karakteristike proizvoda koji kupuju. Trebaju
se podudariti i zahtjevi kupca i prodavaa kako bi se obavila prodaja/kupnja. Npr. Kupac ima
maksimalni iznos koji planira potroiti, a prodava ima minimalnu cijenu po kojoj prodaje. Za
sluaj HTCondor sustava , kupci bi bili oni koji alju poslove, a prodavatelji su vlasnici resursa.
Svi strojevi u HTCondor bazenu oglaavaju svoje atribute poput raspoloive memorije, tipa i
brzine CPU-a, veliine virtualne memorije, trenutnog optereenja i niza drugih dinamikih i
statikih osobina. ClassAdd stroja takoer oglaava uvjete pod kojima je spreman izvriti
posao i koje tipove poslova preferira. Npr. vlasnik strojeva moe preferirati poslove
odreene grupe korisnika ili npr. da preferira samo izvravanje ako na stroju nema neke
druge aktivnosti.
Slino kada se alje posao, specificira se ClassAd s zahtjevima i preferencijama. ClassAd moe
sadravati informaciju o eljenom tipu CPU-a. Npr. elite li strojeve koji najbre izvravaju
operacije s brojevima u pokretnom zarezu. Moete traiti strojeve koji imaju npr. najmanje
512MB RAM memorije na raspolaganju. Moete i traiti bilo koji stroj koji je dostupan.
HTCondor igra ulogu uparivaa na nain da kontinuirano ita sve ClassAd-ove poslova i
uparuje ih (i rangira) s ClassAd-ovima strojeva na nain da svi uvjeti budu ispunjeni.

4.1.1 Pregled ClassAd-ova s condor_status

Nakon to je HTCondor instaliran i pokrenut moemo dobiti osjeaj to se ini s ClassAdovima pokretanjem condor_status naredbe. Ta naredba daje nam sumarni pregled
dostupnih resursa oglaenih preko ClassAd-ova. Nakon tipkanja condor_status dobit emo
neto poput slijedeega:
Name

OpSys

Arch

State

Activity LoadAv Mem

amul.cs.wisc.edu
slot1@amundsen.cs.
slot2@amundsen.cs.
angus.cs.wisc.edu
anhai.cs.wisc.edu
apollo.cs.wisc.edu
arragon.cs.wisc.ed
bamba.cs.wisc.edu

LINUX
LINUX
LINUX
LINUX
LINUX
LINUX
LINUX
LINUX

INTEL
INTEL
INTEL
INTEL
INTEL
INTEL
INTEL
INTEL

Claimed
Owner
Owner
Claimed
Claimed
Unclaimed
Claimed
Owner

Busy
Idle
Idle
Busy
Busy
Idle
Busy
Idle

0.990
0.000
0.110
0.940
1.400
1.000
0.980
0.040

ActvtyTime

1896 0+00:07:04
1456 0+00:21:58
1456 0+00:21:59
873 0+00:02:54
1896 0+00:03:03
3032 0+00:00:04
873 0+00:04:29
3032 15+20:10:19

Naredba condor_status ima niz varijanti koji sumariziraju ClassAdove na razliite naine.
condor_status available : pokazuje strojeve koji mogu izvravati poslove odmah
condor_status run : pokazuje strojeve koji upravo izvravaju poslove
condor_status long : prikazuje ClassAd-ova za sve strojeve u bazenu.
Slijedei ispis pokazuje dio ClassAd-a za jedan stroj. HTCondor moe koristi bilo koji atribut
naveden u ClassAd-u stroja kao kriterij za raspored posla. Dodatni atributi se vrlo lako
dodaju.
Machine = "turunmaa.cs.wisc.edu"
FileSystemDomain = "cs.wisc.edu"
Name = "turunmaa.cs.wisc.edu"
CondorPlatform = "$CondorPlatform: x86_rhap_5 $"
Cpus = 1
IsValidCheckpointPlatform = ( ( ( TARGET.JobUniverse == 1 ) == false ) ||
( ( MY.CheckpointPlatform =!= undefined ) &&
( ( TARGET.LastCheckpointPlatform =?= MY.CheckpointPlatform ) ||
( TARGET.NumCkpts == 0 ) ) ) )
CondorVersion = "$CondorVersion: 7.6.3 Aug 18 2011 BuildID: 361356 $"
Requirements = ( START ) && ( IsValidCheckpointPlatform )
EnteredCurrentActivity = 1316094896
MyAddress = "<128.105.175.125:58026>"
EnteredCurrentState = 1316094896
Memory = 1897
CkptServer = "pitcher.cs.wisc.edu"
OpSys = "LINUX"
State = "Owner"
START = true
Arch = "INTEL"
Mips = 2634
Activity = "Idle"
StartdIpAddr = "<128.105.175.125:58026>"
TargetType = "Job"
LoadAvg = 0.210000
CheckpointPlatform = "LINUX INTEL 2.6.x normal 0x40000000"
Disk = 92309744
VirtualMemory = 2069476
TotalSlots = 1
UidDomain = "cs.wisc.edu"

MyType = "Machine"

4.2 Kreiranje i slanje poslova

Priprema koda
Posao koji se pokree preko HTCondora mora biti mogue pokrenuti kao pozadinski posao.
Programi koji se odvijaju u pozadini ne mogu vriti interaktivni ulaz ili izlaz. HTCondor moe
izvriti redirekciju izlaza konzole (stdout i stderr) i tipkovnice (stdin) u ili iz datoteka.
HTCondor universe
HTCondor posjeduje nekoliko radnih okolina (nazvanih universe) koje moemo izabrati
prilikom pokretanja poslova. Dva od ponuenih, a to su standard i vanilla su najei izbor
prilikom uenja kako se poslovi pokreu na HTCondor okolini. Standard universe dozvoljava
poslu pokrenutom preko HTCondora da upravlja sistemskim pozivima na nain da ih
prosljeuje stroju s kojeg je posao poslan. Standard universe posjeduje i mehanizme koji
omoguavaju da se postavljaju kontrolne toke te da se djelomino obavljeni poslovi mogu
migrirati na druge strojeve ako stroj na kojem se posao izvravao postane nedostupan. Da bi
se koristio standard universe potrebno je program relinkati s HTCondor condor_compile
naredbom.
Vanilla universe omoguava pokretanje poslova koje ne moemo ili ne elimo relinkati
(povezivati) s HTCondor bibliotekama. Nema naina da se postavljaju kontrolne toke niti da
se migriraju poslovi koji su u okviru vanilla universe okoline. Da bi se manipuliralo ulaznim i
izlaznim datotekama potrebno je koristiti bilo dijeljeni datoteni sustav ili HTCondor
mehanizam za transfer datoteka.
Submit description datoteka
U submit description datoteci upravlja se detaljima vezanim za detalje slanja poslova.
Datoteka sadrava informacije o poslu poput odreenja izvrne datoteke koju treba
pokrenuti, ulazno izlaznih datoteka za preusmjeravanje standardnih ulaza/izlaza, potrebne
platforme, adrese e-maila na koju treba poslati obavijest o izvrenju programa. Moe se i
naloiti da viestruko pokrene program te definirati potrebni skupovi ulaznih podataka.
Slanje posla
Posao se alje naredbom condor_submit submit_desription_file
Nakon slanja, HTCondor se brine o svim fazama izvravanja posla. Moe se pratiti stanje
izvravanja naredbama condor_q i condor_status. Moe se modificirati prioritet vlastitih

poslova naredbom condor_prio. Ako je potrebno HTConor moe i biljeiti u log file niz
podataka, poput podataka o eventualnim migracijama poslova.

4.3 HTCondor universe izbor

Universe definira izvrnu okolinu. HTCondor verzija 7.8.7 ima podrku za nekoliko razliitih
universe okolina.

Standard
Vanilla
Grid
Java
Scheduler
Local
Parallel
VM

4.3.1 Standard universe

Standard universe omoguava kontrolne toke (checkpoints) i udaljene sistemske pozive
(remote system calls). Te osobine podiu pouzdanost izvravanja poslova. Kako bi se
program pripremio za standard universe potrebno ga je relinkati s condor_compile. Veina
programa se mogu pripremiti na ovaj nain, ali postoji i nekoliko ogranienja.
HTCondor provjerava program u regularnim intervalima. Slika kontrolne toke (checkpoint
image) je snimka trenutnog stanja posla. Ako je posao potrebno migrirati s jednog stroja na
drugi, HTCondor e napraviti snimku kontrolne toke i pokrenuti program s mjesta gdje je
stao. Ako stroj na kojem se izvrava posao blokira tijekom izvravanja posla, HTCondor moe
pokrenuti posao na novom stroju koristei zadnju snimku. Na ovaj nain poslovi mogu biti
pokrenuti u duim vremenskim intervalima bez obzira na padove i povremenu nedostupnost
strojeva.
Udaljeni sistemski pozivi omoguavaju da posao u izvravanju percipira da se izvrava na
lokalnom stroju, a u stvarnosti se moe izvravati na vie udaljenih poslova. Kada se posao
pokree na udaljenim strojevima, poseban proces nazvan condor_shadow izvrava se na
stroju odakle je posao poslan. Kada posao pokua sistemski poziv, condor_shadow preuzima
isti, izvrava ga na lokalnom stroju i rezultat vraa udaljenom stroju. Npr. ako posao pokua

otvaranje datoteke, condor_shadow e to uiniti na lokalnom stroju i traene podatke poslati

udaljenom poslu.

Razlika izmeu udaljenih i lokalnih poziva

Da bi se program konvertirao u standard universe posao, potrebno je koristiti

condor_compile na nain da se stavlja ispred standardne link naredbe. Nije potreban pristup
izvornom kodu, ali je potrebno imati pristup nelinkanim object datotekama. Dakle nije
mogue da se izvrna datoteka direktno pretvori u standard universe posao.
Dakle umjesto standardnog linkanja npr:
% cc main.o tools.o -o program

Potrebno je :
% condor_compile cc main.o tools.o -o program

Postoji nekoliko ogranienja na standard universe poslove:

1. Poslovi s viestrukim procesima nisu dozvoljeni. To znai da nije dozvoljeno kreirati
dodatne procese poput koritenja fork(), exec() i system() naredbi.
2. Nije dozvoljena interprocesna komunikacija (pipes, semaphores, shared memory).
3. Mrena komunikacija treba biti kratka. Posao moe koristiti mrene pozive
koritenjem npr. socket() naredbi, ali mrena konekcija ne bi trebala biti otvorena
due vrijeme jer onemoguava kontrolne toke i migraciju.
4. Nije dozvoljeno slanje signala SIGUSR2 i SIGTSTP jer ih HTCondor interno koristi.
5. Timeri, alarmi i beskonani sleep nisu dozvoljeni.

6. Viestruke niti na nivou kernela nisu dozvoljene, ali jesu na nivou korisnika (user
threads).
7. Nisu dozvoljene memorijski mapirane datoteke.
8. Kljuanje datoteka je dozvoljeno, ali ne zadrava se nakon kontrolnih toaka.
9. Sve datoteke se trebaju otvoriti kao read-only ili write-only. Datoteke otvorene i za
itanje i pisanje mogu praviti probleme u sluaju vraanja na prethodnu kontrolnu
snimku.
10. Na stroju koji alje poslove mora biti dovoljno velik slobodan prostor na disku za
pohranu kontrolnih slika. Slika je otprilike veliine virtualne memorije koju koristi
pokrenuti posao. U sluaju da se radi o veim koliinama mogue je uspostaviti
poseban server za pohranu.
11. Linux izvrna datoteka mora biti statiki povezana.
12. Rad s datotekama veim od 2GB mogue je samo ako su stroj slanja i izvrni stroj 64bitni
4.3.2 Vanilla universe
Vanilla universe je okolina koja je namijenjena programima koji se ne mogu relinkati. Jedan
od primjera su i shell skripte. Kao to smo ve prije naveli nema mogunost kontrolnih
snimaka i migracije niti udaljenih sistemskih poziva.
U sluaju da udaljeni stroj prestane izvravati poslove HTCondor nema drugog izbora doli
suspendirati posao na neko vrijeme ili pokrenuti ga ispoetka na nekom drugom stroju.
Poto nema sistemskih poziva kojima bi mogli transferirati podatke izmeu udaljenog stroja i
lokalnog hosta potrebno je koristiti alternativne metode. Jedan od naina je koritenje
dijeljenih datotenih sustava poput AFS i NFS sustava. Alternativno, HTCondor posjeduje
mehanizme za prijenos datoteka na raun korisnika. HTCondor e prenijeti datoteke na
mjesto izvravanja, pokrenuti posao i transferirati izlazne datoteke nazad na stroj koji je
poslao poslove.
4.3.3 Grid universe
Grid universe namijenjen je slanju poslova u posebnoj konfiguraciji HTCondor sustava,
HTCondor-C. Ovako konfiguriran HTCondor omoguava da se koriste viestruki redovi
ekanja na udaljenim serverima i da se poslovi transferiraju s jednog na drugi red ekanja
prema predefiniranoj politici. HTCondor-C je stoga izuzetno otporan na ispade strojeva.
Sustav je tako kreiran da korisnik koji pokree poslove moe poslove dati na izvravanje,

iskljuiti se (npr. laptop) i onda nakon nekog vremena se prikljuiti i ako su poslovi izvreni,
transferirati rezultate.
4.3.4 Java universe
Program koji poaljemo u Java universe trebao bi se pokrenuti na bilo kojem stroju s JVM bez
obzira na lokaciju, vlasnika ili JVM verziju. HTCondor bi trebao preuzeti brigu oko detalja
izvravanja poput pronalaenja JVM izvrnih datoteka i podeavanja classpath varijable.
4.3.5 Scheduler universe / Local universe
Omoguava slanje laganih poslova na izvravanje na lokalnom stroju bez da poslovi idu u red
na serveru.

4.4 Primjeri
Primjer 1
Primjer 1. je najjednostavnija mogua submit decription datoteka. Ona alje u Condor red
ekanja jednu kopiju izvrne datoteke foo. HTCondoru se nalae koristi vanilla universe i da
prilikom izvravanja koristi datoteku foo.log za snimanje detalja izvravanja. Naredba queue
na kraju alje posao u red ekanja uzimajui u obzir sve prethodno navedene parametre.
Linije koje poinju s # se ignoriraju (komentari).
# Example 1 : Simple submit file
universe = vanilla
executable = foo
log = foo.log
queue

Primjer 2
Primjer 2. je neto malo detaljniji. Na izvravanje se alje perl skripta env-test.pl .
#!/usr/bin/env perl
foreach $key (sort keys(%ENV))
{
print "$key = $ENV{$key}\n"
}
exit 0;

Ako datoteka nije oznaena kao izvrna potrebno je to uiniti s : chmod 755 env-test.pl U
SDL datoteci naloeno je postavljanje dodatnih varijabli okoline koje e biti izlistane zajedno
s varijablama okoline izvrnog hosta te vraene sortirane u izlaznoj datoteci.
executable = env-test.pl
universe = vanilla
environment = foo = bar; zot = qux
output = env-test.out.$(cluster)
log = env-test.log.$(cluster)
should_transfer_files = YES
when_to_transfer_output = ON_EXIT
queue

Primjer 3
U ovom primjeru zadatak se izvrava u standard universe okolini. U direktorij programa
ulazimo s cd~/examples/compiling_for_condor.
Izlistajte ga s more simple.c .
main(int argc, char **argv)
{
int sleep_time;
int input;
int failure;
if (argc != 3) {
printf("Usage: simple <sleep-time> <integer>\n");
failure = 1;
} else {
sleep_time = atoi(argv[1]);
input

= atoi(argv[2]);

printf("Thinking really hard for %d seconds...\n",

sleep(sleep_time);
printf("We calculated: %d\n", input * 2);
failure = 0;
}
return failure;
}

sleep_time);

Program ne radi nita do spava specificirano vrijeme u sekundama i napravi malu kalkulaciju
iji rezultat spremi u izlaznu datoteku. Prevoenje ide na slijedei nain:
condor_compile gcc -o simple.std simple.c

U postupku se mogu generirati upozorenja, ali mogu se zasada zanemariti. Nakon uspjenog
izvoenja generira se HTCondor binarna datoteka simple. U direktoriju se nalazi i datoteka
za slanje posla submit.std. Pogledajte sadraj datoteke (more submit.std). Kao i prije
datoteka specificira universe tip, naziv izvrne datoteke, nazive ulazno/izlaznih/log datoteka.
Za razliku od prijanjih primjera gdje se slao samo jedan posao, ovdje se alje vie poslova (3)
s razliitim parametrima.
Posao poaljemo s: condor_sumbit submit.std
Izvravanje posla pratimo s : condor_q
Log informacija se moe pratiti s : more simple.log
Kad su poslovi izvreni izlazne datoteke se mogu pregledati s: more *.out
Primjer 4
Primjer 4. Pokazuje upotrebu direktorija za organizaciju podataka. Pokrenut emo
modificirani primjer za raunanje broja PI, ali umjesto upotrebe argumenata ulazne podatke
organizirat emo po direktorijima ( zasad samo dva run_1 i run_2).
Universe = vanilla
Executable = montepi2
output = pi.out
error = pi.error
log = pi.log
input = input.dat
initialdir = run_1
queue
initialdir = run_2
queue

Primjer 5

Modificirajmo primjer tako da koristi $(Process)makro te dodajmo uvjete da se izvrava

samo na strojevima koji imaju vie od 640MB memorije.
Universe = vanilla
Executable = montepi2
requirements = Memory > 128 && Arch == "INTEL" && OpSys == "Linux"
rank = KFlops
image_size = 180
output = pi.out
error = pi.error
log = pi.log
input = input.dat
initialdir = run_$(Process)
queue 2

4.5 HTCondor - lista naredbi

Command
condor_analyze
condor_checkpoint

Description
analiza poslova koji nisu upareni
provjera checkpoint poslova koji su pokrenuti na odreenim
hostovima

condor_hold
condor_prio
condor_qedit
condor_q
condor_release
condor_reschedule
condor_rm

kreiraj posebno povezanu izvrnu datoteku za slanje na

Standard Universe
dodaj Globus resurs u HTCondor
pregled poslova obavljenih od strane HTCondor sustava do
odreenog vremena
Stavi poslove u redu u stanje hold
Promijeni priritet poslova u redu
Modificiraj atribute ve poslanog posla
Prikai informaciju o poslovima u redu
Otpusti zadrane (hold) posove u redu
Auriraj informaciju o rasporedu
Ukoni poslove iz reda

condor_run

Poalji shell command-line kao HTCondor posao

condor_status

Prikai status HTCondor resursa

condor_submit_dag

Upravljaj i stavi u red poslove DAG ssutava

condor_compile
condor_glidein
condor_history

condor_submit

Poalji poslove u red ekanja za izvravanje

condor_userlog

Prikai i sumariziraj statistiki izvravanja poslova iz log datoteka

condor_version

Prikai verziju instaliranog softvera

4.6 Primjeri naredbi

Korisno je prije slanja posla pogledati stanje sustava:
% condor_status -submitters

Ova naredba vratit e nam listu svih korisnika s popisom poslova koje su poslali na
izvravanje.
Stanje svih poslova u redu ekanja dobit emo s:
% condor_q
ID

OWNER

SUBMITTED

55574.0

jane

6/23 11:33

RUN_TIME ST PRI SIZE

4+03:35:28 R

CMD

25.7 seycplex seymour.d

...
ST (R-run, I- idle, H- hold)
RUN_TIME vrijeme za koje je posao alociran na izvrnom stroju
(DAYS+HOURS:MINS:SECS)

Izvravanje posla moe se pratiti i preko log datoteke.

Lociranje strojeva koji izvravaju posao odreenog korisnika moe se izvriti i s npr.:
% condor_status -constraint 'RemoteUser == "breach@cs.wisc.edu"'

Informacija o svim strojevima koji izvravaju neki posao:

% condor_status -run

Poslovi se mogu ukloniti tako da se prvo identificira ID (cluster.proces) i onda uklone s

condor_rm cluster.proces (npr. condor_rm 123.0)
4.6.1.1 Promjena prioriteta poslova
Pored prioriteta koji se dodjeljuju svakom korisniku HTCondor omoguava da korisnici
dodjeljuju prioritete pojedinim poslovima. Ti su prioriteti lokalni za svaki red ekanja i u

opsegu -20 do +20. Vii broj znai vii prioritet, a pretpostavljeni broj je 0. Npr. za promjenu
prioriteta posla na -15, unesemo:
%

condor_q raman

-- Submitter: froth.cs.wisc.edu : <128.105.73.44:33847> : froth.cs.wisc.edu

ID

OWNER

SUBMITTED

126.0

raman

4/11 15:06

RUN_TIME

ST PRI SIZE CMD

0+00:00:00 I

0.3

hello

1 jobs; 1 idle, 0 running, 0 held

% condor_prio -p -15 126.0
% condor_q raman
-- Submitter: froth.cs.wisc.edu : <128.105.73.44:33847> : froth.cs.wisc.edu
ID

OWNER

SUBMITTED

126.0

raman

4/11 15:06

RUN_TIME

ST PRI SIZE CMD

0+00:00:00 I

-15 0.3

hello

1 jobs; 1 idle, 0 running, 0 held

Naglaavamo da su ovi prioriteti sasvim neovisni o prioritetima korisnika koje dodjeljuje

HTCondor. Prioriteti po poslovima samo odreuju redoslijed izvravanja vaih poslova, a ne
u odnosu na poslove drugih korisnika.
4.6.1.2 Utvrivanje razloga zato se poslovi ne izvravaju
Odreeni posao moe se ne izvravati iz niza razloga. Razlozi ukljuuju posao koji je
neispravan, ogranienja strojeva za izvravanje, neispunjive preference, nedovoljan prioritet
i drugi. Veliki broj uzroka moe biti ustanovljen koritenjem analyze opcije condor_q
naredbe.
Npr. poslovi korisnika jbasney nisu se pokrenuli ni nakon nekoliko dana.
% condor_q
-- Submitter: froth.cs.wisc.edu : <128.105.73.44:33847> : froth.cs.wisc.edu
ID

OWNER

125.0

jbasney

SUBMITTED
4/10 15:35

RUN_TIME

ST PRI SIZE CMD

0+00:00:00 I

-10 1.2

1 jobs; 1 idle, 0 running, 0 held

Pokretanjem condor_q'sanalizatora dobivena je slijedea informacija:

% condor_q 125.0 -analyze

hello.remote

-- Submitter: froth.cs.wisc.edu : <128.105.73.44:33847> : froth.cs.wisc.edu

--125.000:

Run analysis summary.

Of 323 resource offers,

323 do not satisfy the request's constraints

0 resource offer constraints are not satisfied by this request
0 are serving equal or higher priority customers
0 are serving more preferred customers
0 cannot preempt because preemption has been held
0 are available to service your request
WARNING:

Be advised:

No resources matched request's constraints

Check the Requirements expression below:
Requirements = Arch == "INTEL" && OpSys == "IRIX6" &&
Disk >= ExecutableSize && VirtualMemory >= ImageSize

Zahtjevi ovog posla specificiraju nepostojeu platformu pa je rezultat izraza uvijek false.
Dok analizator moe dijagnosticirati mnoge probleme, postoje situacije kada detekcija nije
pouzdana zbog promjenjivosti informacija na koje se oslanja u detekciji. Npr. analizator moe
dojaviti da resursi za izvravanje posla postoje, ali posao se ne izvrava. U velikom broju
situacija radi se o tome da se radi samo o kanjenju u izvravanju.
U sluaju kompleksnijih greaka, poput toga da posao se pone izvravati i odmah pree u
idle stanje, potrebno je pogledati error and log datoteke posla (specificirane u submit
datoteci) i HTCondor SHADOW_LOG datoteci.
4.6.1.3 Zavretak posla
Kada HTCondor posao zavri bilo normalno ili abnormalno, HTCondor e ga ukoniti iz reda poslova (stoga
se vie ne pojavljuje u izlazu naredbe condor_q) i umetnuti u history datoteku. Povijest poslova se moe
pregledati s naredbom condor_history. Ako je u submit datoteci specificirana log datoteka onda e i u
povijesti poslova biti zabiljeen. Unaprijed je postavljeno da HTCondor zavretkom posla alje e-mail
poruku.

4.6.1.4 Politika rasporeda poslova ( job Policy)

HTCondor daje na raspolaganje nekoliko izraza kojima se moe kontrolirati posao dok je jo u
redu ekanja. HTCondor e periodiki izraunavati te izraze i prema rezultatima izvravati
akcije u ime korisnika. HTCondor daje na raspolaganje pet izraza:
periodic_hold, periodic_release, periodic_remove, on_exit_hold, on_exit_remove.
Izrazi se evaluiraju svakih 20 sekundi, osim on_exit izraza koji se evaluira kada se posao
zavri, ali prije nogo to je posao uklonjen iz reda. Periodiki izrazi imaju prednost nad

on_exit izrazima, a hold izrazi imaju prednost nad remove izrazima. Periodiki izrazi su tipa
ClassAs poput requirements izraza.
Ovi se izrazi mogu koristiti za automatizaciju mnogih uobiajenih akcija. Npr. ako elite da se
posao nikad ne izvrava due od jednog sata, tj. ako se izvrava due od jednog sata onda
neto nije u redu s izvravanjem pa treba ispitati razloge. U tom sluaju umjesto da posao
ostane u nepotrebnom izvravanju i zauzima resurse, mogue je posao staviti u hold stanje
ako se doda u submit datoteku slijedee:
periodic_hold = (ServerStartTime - JobStartDate) > 3600