VYTAUTO DIDŢIOJO UNIVERSITETAS

VYTAUTO DIDŢIOJO UNIVERSITETAS

INFORMATIKOS FAKULTETAS

TAIKOMOSIOS INFORMATIKOS KATEDRA

Dainius Petravičius

„DEBESŲ KOMPIUTERIJOS“ PANAUDOJIMO ĮMONĖS IT

INFRASTRUKTŪROJE GALIMYBIŲ ANALIZĖ

Magistro baigiamasis darbas

Verslo informatikos studijų programa, valstybinis kodas 62609P102

Informatikos studijų kryptis

Vadovas (-ė) doc.dr. Kęstutis Šidlauskas _________ __________ (Moksl. laipsnis, vardas, pavardė) (Parašas) (Data)

Apginta doc.dr. Kęstutis Šidlauskas __________ __________ (Fakulteto dekanas) (Parašas) (Data)

Kaunas, 2010

2

TURINYS

SANTRUMPŲ IR TERMINŲ ŢODYNAS ........................................................................................ 6

ĮVADAS .............................................................................................................................................. 7

1. TEORINĖ „DEBESŲ KOMPIUTERIJOS“ GALIMYBIŲ ANALIZĖ ...................................... 8

1.1. „Debesų kompiuterijos“ samprata ........................................................................................ 8

1.2. Paslaugų modeliai ................................................................................................................. 9

1.3. Diegimo modeliai ............................................................................................................... 11

1.4. Klasifikacija ........................................................................................................................ 11

1.5. „Debesų kompiuterijos“ panaudojimo galimybės .............................................................. 13

1.5.1. Vartotojas – Debesis .................................................................................................... 14

1.5.2. Įmonė – Debesis – Vartotojas ...................................................................................... 15

1.5.3. Įmonė – Debesis .......................................................................................................... 17

1.5.4. Įmonė – Debesis – Įmonė ............................................................................................ 18

1.5.5. Privatus debesis ........................................................................................................... 20

1.5.6. Mišrus debesis ............................................................................................................. 21

1.6. Panaudojimo scenarijų apibendrinimas .............................................................................. 22

1.7. Virtualių mašinų platformos ............................................................................................... 23

1.8. „Debesų kompiuterijos“ platformos ................................................................................... 25

1.8.1. „AbiCloud“ .................................................................................................................. 26

1.8.2. „Eucalyptus“ ................................................................................................................ 28

1.8.3. „OpenNebula“ ............................................................................................................. 31

1.8.4. „OpenQRM“ ................................................................................................................ 33

1.8.5. „VMware vSphere“ ..................................................................................................... 35

1.9. Platformų apibendrinimas ................................................................................................... 38

1.10. VGĮ poreikių analizė ....................................................................................................... 39

2. PRAKTINIS TYRIMAS ............................................................................................................ 42

2.1. „Debesies“ modelių panaudojimas ..................................................................................... 42

3

2.2. Tyrimui pasirinktas metodas ............................................................................................... 43

2.2.1. „AbiCloud“ .................................................................................................................. 44

2.2.2. „Eucalyptus“ ................................................................................................................ 45

2.2.3. „OpenNebula“ ............................................................................................................. 46

2.2.4. „OpenQRM“ ................................................................................................................ 48

2.2.5. „VMware vSphere“ ..................................................................................................... 50

2.3. Platformų lyginamoji analizė .............................................................................................. 51

3. PROTOTIPO PROJEKTAS ....................................................................................................... 55

3.1. Diegimas ............................................................................................................................. 55

3.1.1. Problemos ir apribojimai ............................................................................................. 58

3.2. Tolimesni tyrimai ................................................................................................................ 60

IŠVADOS .......................................................................................................................................... 61

LITERATŪROS SĄRAŠAS ............................................................................................................. 62

PRIEDAI ........................................................................................................................................... 65

4

Santrauka

Magistro darbo autorius: Dainius Petravičius

Magistro darbo pavadinimas: „Debesų kompiuterijos“ panaudojimo įmonės IT infrastruktūroje

galimybių analizė

Vadovas: doc. dr. Kęstutis Šidlauskas

Darbas pristatytas: Vytauto Didţiojo Universitetas, Informatikos fakultetas,

Kaunas, 2010

Puslapių skaičius: 64

Lentelių skaičius: 4

Paveikslų skaičius: 18

Priedų skaičius: 3

Šiame darbe analizuojamos viešosios gydymo įstaigos (VGĮ) IT infrastruktūros plėtros

galimybės, pasitelkiant „debesų kompiuteriją“. Teorinėje dalyje pristatoma „debesų kompiuterijos“

samprata, jos sudėtis, modeliai bei platformos. Išanalizavus „debesų kompiuterijos“ panaudojimo

galimybes, nustatyta su kokiais reikalavimais susiduria įmonė konkrečiu atveju. Darbo eigoje atlikta

VGĮ poreikių analizė parodė, kad „debesų kompiuterijos“ sprendimai yra tinkama kryptis VGĮ

poreikiams tenkinti. Tyrimo eigoje pritaikytas lyginamosios analizės metodas, kurio metu buvo

išsikelti kriterijai „debesų“ platformoms palyginti. Paskutinėje darbo dalyje atlikta lyginamoji

analizė leido nustatyti, kuri „debesies“ platforma labiausiai atitinka VGĮ poreikius. Pritaikius šią

platformą, sudarytas VGĮ „debesies“ modelis, leidţiantis turėti lanksčią bei efektyvesnę IT

infrastruktūrą.

5

Abstract

Author of Master Thesis: Dainius Petravicius

Full title of Master Thesis: Feasibility analysis of Cloud Computing in the corporate IT

infrastructure

Supervisor: doc. dr. Kestutis Sidlauskas

Presented at: Vytautas Magnus University, Faculty of Informatics, Kaunas,

May 2010

Number of pages: 64

Number of tables: 4

Number of pictures: 18

Number of appendices: 3

This work analyses IT infrastructure development possibilities for a public medical

institution (PMI) by applying “cloud computing” technologies. The theoretical part presents the

concept of “cloud computing”, architecture, models and platforms. After analyzing the possibilities

of applying “cloud computing”, the ICT infrastructure requirements of the company are analysed.

The PMI needs analysis showed that the application of “cloud computing” technologies is the right

direction to take. The method of comparative analysis was applied in the research, and

corresponding criteria were formulated for the platform comparison. In the last part, the results of

the comparative analysis were used to estimate which “cloud” platforms are most suitable for

meeting the PMI needs. A “cloud” model was built for PMI, offering a flexible and effective IT

infrastructure for the institution.

6

SANTRUMPŲ IR TERMINŲ ŢODYNAS

API (Application Programming Interface) – susitarimų ir procedūrų rinkinys ryšiams tarp atskirų

programų ir operacinės sistemos realizuoti.

DHCP (Dynamic Host Configuration Protocol) – tai kompiuterinių tinklų protokolas,

naudojamas klientų IP adresų priskyrimui ir sukonfigūravimui.

EC2 (Amazon elastic compute cloud) – tai centrinė „Amazon“ „debesies“ platformos dalis.

Front-end – „debesų kompiuterijoje“ taip vadinamas „debesies“ valdiklis.

Guest OS – operacinė sistema, veikianti virtualioje mašinoje.

Haizea – tai atviro kodo virtualių mašinų nuomos valdymo architektūra.

Host – kompiuteris, kuris naudoja virtualizacijos programą, kad paleisti virtualias mašinas.

Host OS – operacinė sistema, veikianti pagrindiniame įrenginyje (pvz. serveryje).

HTTP (HyperText Transfer Protocol) - hipertekstų persiuntimo protokolas, skirtas ţiniatinklio

duomenims (ištekliams) persiųsti.

Klasteris (angl. cluster) – tai grupė sujungtų serverių, veikiančių kartu kaip vienas serveris

virtualioje aplinkoje. Klasteriai suteikia nepertraukiamo prieinamumo (angl. high availability)

galimybes.

Mazgas (angl. node) – tai gali būti kompiuteris, mobilus įrenginys ar serveris.

Momentinė kopija (angl. snapshot) – virtualių mašinų kopija, kurią galima padaryti, kai ji yra

įjungta, išjungta arba sulaikyta.

Papildinys (angl. plug-in) - Papildomas komponentas, įtaisytas į programą, kompiuterį arba jo

įtaisą ir išplečiantis jo galimybes.

Shared FS (shared file system) – tai bendra failų sistema, kuri reiškia, kad skirtingi vartotojai su

skirtingom OS gali naudotis tais pačiais duomenimis.

SSL (Secure Sockets Layer) – tai kriptografinis protokolas, skirtas internete sklindančiai

informacijai šifruoti.

UEC (Ubuntu Enterprise Cloud) – tai įmonėms skirta „Eucalyptus“ „debesies“ platforma.

VGĮ – viešoji gydymo įstaiga.

7

ĮVADAS

„Debesų kompiuterija“ palaipsniui tampa vis svarbesne sąvoka IT pasaulyje, kadangi ši

technologija suteikia galimybę turėti lanksčią IT infrastruktūrą ir efektyviau panaudoti

kompiuterinius resursus. Daugelis uţsienio sveikatos prieţiūros centrų jau svarsto apie šios

technologijos pritaikymą savo srityje. Tuo tarpu Lietuvoje buvo paskelbtas projektas „E. sveikatos

paslaugos“, kurio pagrindinis tikslas – sukurti sveikatos prieţiūros įrašų sistemą. Iš to galima daryti

prielaidą, kad viešosios gydymo įstaigos (VGĮ) privalės praplėsti savo IT infrastruktūrą, norint

įsidiegti šią paslaugą. Pasitelkus „debesų kompiuteriją”, atsiranda galimybė nesudėtingai praplėsti

įmonės IT infrastruktūrą, todėl VGĮ norėtų gauti patarimus dėl galimų sprendimo variantų.

Taigi šio darbo tikslas – pasiūlyti sprendimo būdą(-us) VGĮ IT infrastruktūros plėtrai ir

efektyviam išnaudojimui, pasitelkiant „debesų kompiuteriją“.

Siekiant šio darbo tikslo, iškelti tokie uţdaviniai:

Pateikti „debesų kompiuterijos“ sampratą.

Atlikti „debesų kompiuterijos“ panaudojimo galimybių analizę.

Atlikti VGĮ poreikių analizę.

Išsikelti kriterijus pagal kuriuos toliau būtų galima tyrinėti pasirinktas „debesų“

platformas.

Atlikti „debesų“ platformų lyginamąją analizę.

Suformuluoti pasiūlymus ir rekomendacijas.

Darbas suskirstytas į tris dalis. Pirmoje dalyje trumpai pristatoma „debesų kompiuterijos“

samprata, jos sudėtis bei panaudojimo galimybės. Čia pateikiama informacija apie galimus

„debesų“ išsidėstymo tipus, klasifikaciją bei panaudojimo scenarijus. Taip pat šioje dalyje

apţvelgiamos „debesų“ platformos bei atliekama VGĮ poreikių analizė.

Antroje dalyje projektuojami „debesies“ sprendimai, atsiţvelgiant į VGĮ poreikius. Vėliau

iškeliami kriterijai, pagal kuriuos tiriamos pasirinktos platformos. Tyrimui atlikti panaudotas

lyginamosios analizės metodas. Remiantis juo, nagrinėjamos penkios „debesų kompiuterijos“

platformos, kurios labiausiai atitiko VGĮ keliamus reikalavimus.

Trečioje dalyje pristatomas „debesies“ prototipo projektas, kurio metu išdėstomi

pasiūlymai ir rekomendacijos apie VGĮ galimybes praplėsti savo IT infrastruktūrą, pritaikant

labiausiai jai atitinkantį „debesų kompiuterijos“ modelį bei platformą.

8

1. TEORINĖ „DEBESŲ KOMPIUTERIJOS“ GALIMYBIŲ

ANALIZĖ

Šioje darbo dalyje pateikiama „debesų kompiuterijos“ samprata, jos paslaugų bei diegimo

modeliai, klasifikacija. Toliau atliekama „debesų kompiuterijos“ panaudojimo galimybių analizė

bei pristatomos galimos „debesų“ platformos. Taip pat šiame skyriuje analizuojami VGĮ poreikiai.

1.1. „Debesų kompiuterijos“ samprata

Terminas „debesų kompiuterija“ (angl. cloud computing) yra sukurtas, remiantis teiginiu,

kad didţioji tinklo dalis yra pateikiama debesies forma. Pavyzdţiui, internetas daţniausiai

vaizduojamas kaip debesis. Taip yra todėl, kad daugelis neţino, kas jame yra, ir negali jo

kontroliuoti. Bet įvedus šiek tiek duomenų, galima gauti kai kuriuos kitus duomenis. Tokia pati

situacija yra ir „debesies“ atveju, nes nėra ţinoma, kur yra serveriai (su kuriais uţmezgamas ryšys),

tačiau pateikus uţklausą, gaunamas tam tikras atsakymas.

NIST (Jungtinių Valstijų nacionalinių standartų ir technologijų institutas) pateikė tokį

„debesų kompiuterijos“ apibrėţimą: „ „debesų kompiuterija“ yra modelis, uţtikrinantis patogią

prieigą prie bendros konfigūruojamų kompiuterio resursų (pvz.: tinklų, serverių, saugyklų,

taikomųjų programų ir paslaugų) terpės, kurį labai lengva priţiūrėti, nes reikalinga tik nedidelė

prieţiūra ar minimali paslaugų teikėjo sąveika. Šis „debesies“ modelis yra lengviau prieinamas ir

sudarytas iš penkių pagrindinių savybių, trijų paslaugų ir keturių diegimo modelių“ [1]. Penkios

pagrindinės savybės: prisijungimą pagal poreikius (angl. on-demand self-service), plačią prieigą

prie tinklo (angl. broad network access), resursų kaupimą (angl. resource pooling), greitai kintantį

elastingumą (angl. rapid elasticity) ir apskaičiuotas paslaugas (angl. measured service).

Uţ „debesų kompiuterijos“ slypintis modelis yra pagrįstas daugeliu senų ir keletu naujų

sričių idėjų, tokių kaip paskirstyti skaičiavimo tinklai, paskirstytos sistemos bei virtualizacija.

„Debesų kompiuterija“ sulaukė didelio susidomėjimo per pastaruosius kelerius metus, nes šis

modelis suteikė galimybę lengvai keisti savo resursų dydį. Ši technologija leidţia padidinti arba

sumaţinti savo resursus ir mokėti tik uţ tuos, kuriais naudojamasi. Taigi „debesų kompiuterija“

sudaro naują, komunalinių kompiuterinių paslaugų fazę, o tai reiškia kompiuterio resursų

apibendrinimą, pavyzdţiui, skaičiavimą ir saugojimą, kaip fiksuotas paslaugas, panašias į tradicines

komunalines paslaugas (t.y. mokesčius uţ elektrą, vandenį, gamtines dujas arba telefono ryšį).

„Debesį“ įmanoma sukurti su jau turima technine įranga duomenų centre. Dauguma

„debesies“ sprendimų grindţiami virtualizacijos modeliais. „Virtualizacijos principas yra gana

paprastas - slėpti tikrąją kompiuterio ir jo dalių architektūrą nuo operacinės sistemos. Operacinė

9

sistema mato tik tai, ką virtualizacijos įrankis jai leidţia matyti. Tarkime, turėdami keletą nedidelės

talpos standţiųjų diskų, tam tikro virtualizacijos įrankio pagalba, mes galime juos sujungti į vieną

didelės talpos diską. Operacinė sistema neatpaţins, kad iš tiesų tai yra ne vienas diskas, o keli.

Tokiu pačiu būdu gali būti apgaudinėjama ir programinė kompiuterio įranga, tik šiuo atveju

virtualizaciją atlieka jau operacinė sistema“ [35].

Taigi pasitelkus šiuos modelius, klientai gali labai lengvai pasiekti resursus. O kartu

panaudojant tarpinę programinę įranga, visi duomenų centro (arba kelių duomenų centrų) serveriai

gali būti sujungti, paverčiant juos viena bendra resursų terpe ir perduodant juos klientams. Šie

metodai „debesų kompiuteriją“ paverčia įgyvendinama ir itin sėkminga technologija.

Kitame skyriuje apibūdinamos įvairios „debesų kompiuterijos“ paslaugos ir galimybės.

1.2. Paslaugų modeliai

„Debesų kompiuterija“ pasiţymi keliais darbui skirtais sluoksniais. Pagrindiniai (ir

daţniausiai naudojami) lygiai: programinė įranga, platforma ir infrastruktūra. Toliau išsamiau

paaiškinami šie trys sluoksniai, kurie galėtų veikti tuo pačiu metu, jei programinė įranga (PĮ) yra

aukščiausias, o infrastruktūra – ţemiausias lygis (ţr. 1 pav.), Siekiant paskutinio šio sluoksnio

efektyvumo, galėtų būti naudojami virtualizacijos modeliai.

1 pav. „Debesies“ trikampis

Šaltinis: http://blog.gogrid.com/2009/03/26/navigating-the-layers-of-the-cloud-computing-pyramid/

Išskiriami trys pagrindiniai „debesų kompiuterijos“ paslaugų modeliai [1]:

Programinė įranga kaip paslauga (angl. SaaS – Software as a Service)

Platforma kaip paslauga (angl. Paas – Platform as a Service)

Infrastruktūra kaip paslauga (angl. IaaS – Infrastructure as a Service)

SaaS. Norėdama naudotis SaaS, įmonė privalo sudaryti sutartį su šios paslaugos teikėju.

Programas priţiūri ir tvarko „debesies“ teikėjas. Įmonė gali išsinuomoti šias programas savo

10

reikmėms. Akivaizdu, kad tokio panaudojimo atveju, mokama tik uţ tai, kiek naudojama. Kadangi

ši paslauga sukuriama „debesyje“, resursus galima lengviau pritaikyti pagal klientų poreikius.

SaaS suteikia galimybę skaičiavimų krūvį perkelti iš vartotojų terminalo į duomenų centrus

su įdiegtomis „debesų“ programomis. Tai, savo ruoţtu, maţina techninei įrangai keliamus

reikalavimus, kas yra be galo svarbu galutiniams vartotojams: jiems patiems nebūtina turėti didelę

skaičiavimo galią, nes viskas atliekama (nuotoliniuose) duomenų centruose. Visa tai reiškia, kad

nėra išankstinių investicijų į serverius ar licencijas.

Kai kurie programinės įrangos kaip paslaugos pavyzdţiai yra: Klientų pirkimo galios

valdymo (angl. CRM – Salesforce Customer Relationships Management) sistema ir „Google Apps“.

PaaS. Ši „debesų kompiuterijos“ forma kūrimo aplinkas pateikia kaip paslaugą.

Suteikiama galimybė susikurti savo programas, kurios vėliau veiktų paslaugų teikėjo

infrastruktūroje, o vartotojai galėtų jomis naudotis internetu per paslaugų teikėjo serverius.

Vartotojai nevaldo pagrindinės „debesies“ infrastruktūros, įskaitant tinklus, serverius,

operacines sistemas arba duomenų bazes, tačiau kontroliuoja diegimo ir kartais – uţ aplinkos

konfigūracijas atsakingas programas.

Kai kurie platformos kaip paslaugos pavyzdţiai yra: „Salesforce Apex“ ir „Google Apps

Engine“.

IaaS. Šis sluoksnis daţniausiai pasitelkiamas kartu su techninės įrangos vitualizacija. Jis

pasitelkiamas pagal klientų poreikius, suteikiant jiems virtualias mašinas, kuriomis naudodamiesi

jie galėtų teikti savo paslaugas. Klientai gali susikurti savo nuosavą infrastruktūrą (apimančią

apdorojimą, duomenų centrus, tinklus ir kitus pagrindinius skaičiavimų resursus) šiame „debesies“

lygyje.

Keletas IaaS teikėjų suteikia galimybę jų „debesyje“ susikurti visą kompiuterinę

infrastruktūrą; tokias paslaugas teikia „Amazon Web Services“1. Vartotojai gali valdyti jiems

priklausančią infrastruktūrą per paslaugų teikėjo suteikiamą API (Application Programming

Interface) programų sąsają. Vartotojai nevaldo pagrindinės „debesies“ infrastruktūros, bet

kontroliuoja operacinę sistemą, duomenų bazes, įdiegtas programas, o kartais iš dalies valdo tinklo

sudedamąsias dalis (pvz.: ugniasienes).

Kai kurie infrastruktūros kaip paslaugos pavyzdţiai yra: „Amazon Web Services“ ir

„GoGrid“.

1 Amazon Web Services (AWS) – tai nuotolinės „debesų kompiuterijos“ paslaugos, kurias siūlo „Amazon“.

11

Be trijų aukščiau paminėtų sluoksnių, egzistuoja ir kitų rūšių „debesies“ paslaugos,

pavyzdţiui, duomenų bazė kaip paslauga (DaaS – Data-Storage as a Service) ir pranešimai kaip

paslauga (CaaS – Communication as a Service).

1.3. Diegimo modeliai

„Debesų kompiuterija“ pasiţymi tokiais diegimo modeliais [1]:

Privatus „debesis“ (angl. Private cloud) „debesies“ infrastruktūra yra skirta išskirtinai

vienai organizacijai. Infrastruktūrą gali valdyti ši organizacija arba trečioji šalis; ji gali egzistuoti

organizacijos patalpose arba uţ jų ribų.

Bendrijos „debesis“ (angl. Community cloud) Keletas organizacijų dalijasi „debesies“

infrastruktūra, kuri apima tam tikrą bendriją, pasiţyminčią bendrais interesais (pvz.: ta pačia

paskirtimi, saugumo reikalavimais, strategija ir principų laikymusi). Ją valdyti gali šios

organizacijos arba trečioji šalis; ji gali egzistuoti organizacijų patalpose arba uţ jų ribų.

Viešasis „debesis“ (angl. Public cloud) „debesies“ paslaugas parduodančiai organizacijai

priklausanti „debesies“ infrastruktūra yra prieinama plačiajai visuomenei arba įmonėms.

Mišrusis „debesis“ (angl. Hybrid cloud) „debesies“ infrastruktūra apima du ar daugiau

(privačių, bendrijos ar viešųjų) „debesis“, kurie išlieka unikaliais subjektais, nors tuo pačiu metu yra

sujungiami standartinių arba patentuotų technologijų, leidţiančių perkelti duomenis ir programas.

1.4. Klasifikacija

Ţemiau pateiktoje diagramoje (ţr. 2 pav.), paslaugos vartotojai naudojasi paslaugomis,

teikiamomis per „debesį“. Paslaugų teikėjai valdo „debesies“ infrastruktūrą, o paslaugų vystytojai

(programuotojai) sukuria šias paslaugas savarankiškai. (Paţymėtina, kad atviri standartai yra būtini

tam, kad šie vaidmenys sąveikautų tarpusavyje).

12

2 pav. „Debesų kompiuterijos“ klasifikacija

Šaltinis: http://www.flickr.com/photos/skemsley/3746242768/

Toliau pateikiami detalizuoti vaidmenų aprašymai:

Paslaugos vartotojas. Paslaugos vartotoju gali būti įmonė arba galutinis vartotojas, kuris

naudojasi programa, platforma ar infrastruktūra kaip paslauga. Toks vartotojas dirba su skirtingomis

vartotojui ar programuotojui skirtomis sąsajomis, priklausomai nuo paslaugos tipo.

Kai kurios vartotojo sąsajos veikia kaip įprastos, todėl naudojantis programomis

vartotojams nereikalinga ţinoti apie „debesų kompiuterijos“ funkcionavimą. Tačiau yra sąsajų,

leidţiančių vartotojams administruoti bei valdyti dalį „debesų kompiuterijos“ (pvz.: pačiam paleisti

ar sustabdyti virtualius įrenginius (angl. VM – virtual machines2).

Vartotojai taip pat susiduria su SLA3 ir kontraktais. Sutartys sudaromos abipusių šalių

susitarimu. Vartotojo ir tiekėjo tarpusavio pasitikėjimas vis dar išlieka kaip lemiamas vaidmuo.

Paslaugos teikėjas. Paslaugos teikėjas teikia paslaugas vartotojui. Teikėjui keliami

reikalavimai priklauso nuo paslaugos tipo:

SaaS atveju, teikėjas diegia, valdo ir administruoja programinę įrangą, kuri gali būti

patalpina to paties arba kito teikėjo serveriuose. Vartotojas turi prieigą tiktai prie programinės

įrangos (prie infrastruktūros neprieina).

2 VM – tai yra virtualūs įrengimai (kompiuteriai), kurie veikia taip pat kaip fiziniai įrengimai.

3 SLA – tai yra susitarimas tarp paslaugos teikėjo ir vartotojo, kuris apibrėţia vartotojo teises ir teikėjo įsipareigojimus,

tokius kaip: privatumas ir saugumas.

13

PaaS atveju, teikėjas valdo „debesų“ infrastruktūros platformą, kuri paprastai būna kaip

struktūra konkrečiam programos tipui. Vartotojo programa neturi prieigos prie platformos

infrastruktūros.

IaaS atveju, teikėjas administruoja vietą serveriuose, duomenų bazę, virtualių įrengimų

aplinką. Vartotojai naudojasi tokiomis paslaugomis, tačiau prieigos prie šių paslaugų infrastruktūros

neturi, nes ją administruoja paslaugos teikėjas.

Paslaugos teikėjo diagramoje techninė įranga uţima ţemiausią lygmenį.

Virš įrangos toliau seka Kernel programa, operacinė sistema ar VM. Kartu jie sudaro

„debesų“ infrastruktūrą. Virtualius atvaizdus (įskaitant ir jų savybes) valdo VM tvarkyklė.

Labai svarbią vietą paslaugos teikėjo operacijose uţima valdymo sluoksnis. Ţemesnio

lygio valdymas reikalingas skaičiavimams atlikti, apie tai kas ir kokiu mastu naudoja paslaugas.

Taip pat naudojamas tam, kad nustatyti resursų būseną, sekti ir kontroliuoti resursų paskirstymą

vartotojams. Aukštesnio lygio valdymas apima atsiskaitymus uţ paslaugas, vietos planavimą

serveriuose pagal vartotojų pareikalavimą, SLA (vartotojų pasitikėjimas) ir pranešimus sistemos

administratoriams.

Saugumas reikalingas visuose teikėjo operacijos lygmenyse (yra daug saugumo lygių,

tačiau šiame darbe apie juos nebus diskutuojama).

Paslaugos kūrėjas. Paslaugos kūrėjas programuoja, publikuoja ir kontroliuoja „debesies“

paslaugą. Aplinka, skirta kurti paslaugas, gali keistis. Jeigu kūrėjai kuria Saas aplikaciją, tai aplinka

bus „debesies“ teikėjo. Taigi šiuo atveju norint leisti paslaugą į apyvartą reikia pasinaudoti

„debesų“ teikėjo infrastruktūra.

Paslaugos kūrimo stadijoje analitikai ją pratestuoja ir tik davę patvirtinimą leidţia į

apyvartą. Išplatinus šią paslaugą, analitikai toliau duoda leidimą programuotojams stebėti ir

kontroliuoti savo sukurtas paslaugas bei esant poreikiui tobulinti, darant pakeitimus.

1.5. „Debesų kompiuterijos“ panaudojimo galimybės

Šios darbo dalies tikslas – pabrėţti galimybes ir reikalavimus, kurie turi būti standartizuoti

įmonės „debesies“ aplinkoje, kad garantuotų funkcinį suderinamumą, integracijos ir mobilumo

lengvumą. Panaudojimo galimybės būtent, visa tai aiškiai ir apibūdina, suformuodamos bendrą

uţduotį ir atvaizduodamos sunkumus jo atlikime.

Taigi išskiriami (bendru atveju) tokie panaudojimo scenarijai:

Vartotojas – Debesis

Įmonė – Debesis – Vartotojas

Įmonė – Debesis

14

Įmonė – Debesis – Įmonė

Privatus debesis

Mišrus debesis

Šiems panaudojimo scenarijams suprojektuoti buvo pasitelkta „Microsoft Visio 2007“

programinė įranga.

1.5.1. Vartotojas – Debesis

Šiame scenarijuje (ţr. 3 pav.) galutinis vartotojas turi priėjimą prie savo duomenų ar

aplikacijų, esančių „debesyse“. Tokio tipo aplikacijos yra: elektroninis paštas bei socialiniai

tinklalapiai. Pavyzdţiui, „Gmail“ arba „Facebook“ vartotojai naudoja savo duomenis ir aplikacijas,

nepriklausomai nuo naršyklės ar įrenginio tipo.

Vartotojų duomenys saugomi ir valdomi „debesyse“, todėl juos net nedomina kaip visa tai

veikia. Vartotojui svarbu gauti prieigą prie interneto, tuomet jis jau gali naudotis savo duomenimis.

3 pav. Vartotojas – Debesis

Šaltinis: sudaryta autoriaus

Reikalavimai:

Identifikavimas: „Debesų“ paslaugos privalo autentifikuoti galutinį vartotoją.

Atviras klientas: Prieiga prie „debesies“ paslaugos neturėtų reikalauti (iš vartotojo pusės)

skirtingų platformų ar technologijų.

Saugumas: Saugumas (apimant ir privatumą) bendrai reikalaujamas visuose panaudojimo

scenarijuose, tik kai kada jo detalumas gali ir skirtis.

SLAs: Kad ir koks bebūtų paslaugos sudėtingumo lygis (įmonių-sudėtingas; vartotojų-

paprastas), „debesų“ tiekėjai privalo aiškiai suformuluoti ir pateikti išsamią informaciją apie

teikiamos paslaugos garantijas ir sąlygas.

15

1.5.2. Įmonė – Debesis – Vartotojas

Šiame scenarijuje (ţr. 4 pav.) įmonė naudoja „debesis“ tam, kad pateikti duomenis ir

paslaugas galutiniams vartotojams. Sąveikaujant vartotojui su įmone, pastaroji siųsdama rezultatus

vartotojui, panaudoja „debesis“ duomenų išrinkimui ir manipuliavimui su jais. Galutiniu vartotoju

gali būti kaţkas iš įmonės arba pavienis išorinis klientas.

4 pav. Įmonė – Debesis – Vartotojas


Reikalavimai:

Identifikavimas: „Debesų“ paslaugos privalo autentifikuoti galutinį vartotoją.

Atviras klientas: Prieiga prie „debesies“ paslaugos neturėtų reikalauti (iš vartotojo pusės)

skirtingų platformų ar technologijų.

Federacinis identifikavimas (angl. Federated Identity): Įmonės darbuotojų ir išorės

klientų identifikavimas turėtų būti atskiras. Taip būtų daug patogiau įmonėms, kadangi jų

vartotojų vardai nesidubliuotų su išorės klientų vartotojų vardais.

Vietovės nustatymas (angl. Location Awareness): Kadangi įmonė nenurodo fizinės

serverio, kuriame yra laikomi duomenys vietos, susiduriama su vartotojo teisių apribojimų

paţeidimu, kadangi kai kurie duomenų tipai reikalauja to. Nors ir kaip svarbu „debesų

kompiuterijai“, kad galutinis vartotojas neturi ţinoti detalios informacijos apie

infrastruktūrą, tačiau šis reikalavimas išlieka esminis. Daugelis aplikacijų negali būti

perkeltos į „debesį“ tol, kol „debesies“ teikėjai neaprūpins programavimo sąsaja (angl. API

16

– Application Programming Interface4), nustatančia fizinės aparatinės įrangos vietą, kuri

tiekia „debesies“ paslaugas.

Vertinimas ir kontroliavimas (angl. Metering and Monitoring): „Debesų“ paslaugų

įvertinimas reikalingas kainų kontrolei bei mokesčių deklaravimui.

Valdymas ir valdţia (angl. Management and Governance): Viešo tipo „debesų“ teikėjai

daro kuo paprastesnes sąlygas sąskaitų atidarymui ir „debesų“ paslaugų naudojimuisi. Taigi

naudojimo paprastumas (angl. ease of use) sukuria riziką, kad įmonėje dirbantys asmenys

„debesų“ paslaugas gali lengvai panaudoti savo asmeniniams tikslams. Todėl valdant VM,

būtina nuolatos stebėti resursų panaudojimą t.y. atlikti monitoringą. Taigi pagrindinė

valdţios funkcija - uţtikrinti, kad naudojant „debesų kompiuteriją“, laikomasi nustatytų

valdymo taisyklių ir normų.

Saugumas: Visuose panaudojimo scenarijuose, kuriuose dalyvauja įmonė, saugumui

keliami reikalavimai yra daug sudėtingesni negu kai ji nedalyvauja (single end user atveju).

Taigi kuo sudėtingesnis įmonės panaudojimo scenarijus, tuo aukštesni saugumo

reikalavimai.

Bendras VM failų formatas (angl. A Common File Format for VMs): Virtuali mašina,

sukurta vienai „debesies“ pardavėjo platformai, turi būti pritaikoma kito pardavėjo

platformoje, todėl VM failų formatas privalo būti bendras.

Bendras API (angl. Common APIs for Cloud Storage and Middleware): Įmonių

panaudojimo scenarijai reikalauja bendros API programų sąsajos, kuriant prieigą prie

duomenų saugojimo paslaugų, duomenų bazių ir kt.. Programuojant individualius

uţsakymus, pritaikančius tik konkrečiai pardavėjo paslaugai, įmonė „uţsidaro“ pati savo

sistemos viduje, eliminuodama „debesų kompiuterijos“ teikiamą finansinę naudą ir

lankstumą.

Duomenų ir aplikacijų suderinamumas (angl. Data and Application Federation):

Įmonių duomenys ir aplikacijos, gauti ir naudojami skirtinguose „debesų“ šaltiniuose turi

būti suderinti.

SLA ir našumo testai (angl. benchmarks): Įmonėms pasirašius kontraktus su „debesų“

teikėjais, papildomai reikėtų standartinės kompiuterių našumą tikrinančios programos.

Tuomet turi būti atliekami sistemos našumo testai, palyginantys „debesų“ teikėjo

įsipareigotą ir realų veikimą.

4 API – tai yra susitarimas, kurio laikosi programų kūrėjai. Jis nusako kaip reikia programuoti aplikacijas ir kokią

sintaksę reikia naudoti skirtingose sistemose.

17

Gyvavimo ciklo valdymas (angl. Lifecycle Management): Įmonėms turi būti suteikta

galimybė valdyti savo dokumentų ir aplikacijų gyvavimo ciklą. Šis reikalavimas apima

aplikacijų atnaujinimą, suteikiant joms naujas versijas bei dokumentų saugojimą bei

šalinimą.

1.5.3. Įmonė – Debesis

Šio scenarijaus atveju (ţr. 5 pav.) įmonė naudoja „debesies“ paslaugas savo vidaus

procesams pagerinti. Tai galėtų būti labiausiai paplitęs panaudojimo scenarijus ankstyvose „debesų

kompiuterijos“ vystymosi stadijose, kadangi įmonei duodama dauguma kontrolės.

5 pav. Įmonė – Debesis


Šiame scenarijuje įmonė, norėdama uţpildyti savo silpnąsias vietas papildomais resursais,

naudoja tokias „debesų“ paslaugas:

„Debesyse“ gali būti saugojamos atsarginės duomenų kopijos arba retai naudojami

duomenys, todėl įmonei nereiktų apkrauti savų serverių.

Esant labai didelei procesorių apkrovai, naudojami papildomi VM procesoriai, patalpinti

„debesyse“. Kai apkrova nėra didelė, tada papildomi procesoriai nėra naudojami.

„Debesyse“ gali būti naudojamos aplikacijos (SaaS) įprastoms įmonės funkcijoms atlikti

(elektroninis paštas, kalendorius, CRM ir t.t.).

Įmonė naudoja „debesų“ duomenų bazę kaip dalį aplikacijos veikimo, skirtą duomenų

pasidalinimui su partneriais, vyriausybinėmis agentūromis ir t.t.

Reikalavimai:

18

Pagrindiniai Įmonė – Debesis panaudojimo scenarijų reikalavimai yra labai panašūs į

scenarijų Įmonė – Debesis – Vartotojas:

Atviras klientas, Federacinis identifikavimas, Vietovės nustatymas, Vertinimas ir kontroliavimas,

Valdymas ir valdţia, Saugumas, Bendras VM failų formatas, Bendras API, Duomenų ir aplikacijų

suderinamumas, SLA ir kompiuteriniai testai, Gyvavimo ciklo valdymas – viskas įeina į šį

panaudojimo scenarijų.

Kiti reikalavimai šiam panaudojimo scenarijui:

Išsidėstymas (angl. Deployment): Turi būti nesudėtinga sukurti VM atvaizdą (angl. image)

ir paskleisti jį „debesyse“. Sukurtą VM atvaizdą galima perkelti iš vieno „debesies“ teikėjo į

kitą. Tą patį būtų galima padaryti ir su aplikacijomis, sukuriant joms atskirus atvaizdus.

Specifiniai pramonėje naudojami standartai ir protokolai (angl. Industry-specific

standarts and protocols): Daugelis įmonių, turinčių „debesų kompiuteriją“, naudosis

egzistuojančiais standartais RosettaNet arba OASIS5. Dėl galiojančių standartų keisis

pramonėje naudojamos aplikacijos.

1.5.4. Įmonė – Debesis – Įmonė

Šis panaudojimo scenarijus (ţr. 6 pav.) apima dvi, tą patį „debesį“ naudojančias įmones.

Pagrindinis dėmesys skiriamas įmonių tarpusavio sąveikai. Tiekimo grandinės logistika galėtų būti

geriausias pavyzdys šiam atvejui.

5 OASIS (Organization for the Advancement of Structured Information Standards) valdo atvirųjų pasaulinės

informacinės visuomenės standartų kūrimą, konvergavimą ir adaptavimą.

19

6 pav. Įmonė – Debesis – Įmonė


Reikalavimai:

Pagrindiniai Įmonė – Debesis – Įmonė panaudojimo scenarijų reikalavimai yra labai

panašūs į Įmonė – Debesis:

Identifikavimas, Atviras klientas, Federacinis identifikavimas, Vietovės nustatymas, Vertinimas ir

kontroliavimas, Valdymas ir valdţia, Saugumas, Specifiniai pramonėje naudojami standartai ir

protokolai, Bendras API, Duomenų ir aplikacijų suderinamumas, SLA ir kompiuteriniai testai,

Gyvavimo ciklo valdymas – viskas įeina į šį panaudojimo scenarijų.

Kiti reikalavimai šiam panaudojimo scenarijui:

Tarpusavio susitarimai ir suderinimai (angl. Transactions and concurrency): Skirtingų

įmonių susitarimai ir suderinimai yra „gyvybiškai“ svarbūs tada, kai jos dalinasi bendrais

duomenimis bei bendromis programomis. Jeigu keletas įmonių naudoja tą pačią programą,

VM ar duomenų saugojimo vietą, tai darant kokius nors pakeitimus prieš tai turi būti

suderinta tarpusavyje.

Tarpusavio sąveika (angl. Interoperability): Tarpusavio sąveika yra būtina, kadangi

dalyvauja daugiau kaip viena įmonė.

20

1.5.5. Privatus debesis

Privataus „debesies“ panaudojimas yra visai kitoks negu prieš tai nagrinėti atvejai, kadangi

„debesis“ dalyvauja įmonės viduje (ţr. 7 pav.). Tai naudinga didesnėms įmonėms. Pavyzdţiui, algų

mokėjimo skyrius turi didţiausią darbo krūvį 15-tą ir 30-tą kiekvieno mėnesio dieną. Taigi tik tuo

metu jiems reikia daugiausiai skaičiavimo resursų, nes kitomis darbo dienomis algų mokėtojams

pakanka ir minimalių skaičiavimo resursų. Naudojant privatų „debesį“, skaičiavimo resursai

paskirstomi tiktai įmonės viduje. Algų mokėjimo skyrius gauna papildomus resursus tik tada, kai jų

labiausiai reikia. Kiti padaliniai taip pat gali būti aprūpinti papildomais resursais. Taigi toks

cikliškas resursų pasidalinimas visos įmonės mastu gali ţenkliai padidinti santaupas.

7 pav. Privatus debesis


Reikalavimai:

Pagrindiniai privataus „debesies“ panaudojimo scenarijų reikalavimai yra tokie:

Atviras klientas, Vertinimas ir kontroliavimas, Valdymas ir valdţia, Saugumas,

Išsidėstymas, Tarpusavio sąveika, Bendras VM failų formatas, SLA.

Reikėtų atkreipti dėmesį, kad privatus „debesis“ daugeliu atvejų nereikalauja:

Identifikavimas, Federacinis identifikavimas, Vietovės nustatymas, Tarpusavio susitarimai,

Pramonės standartai, Bendras API, Gyvavimo ciklo valdymas.

Kadangi vartotojai naudojasi privačiu „debesiu“, todėl nereikalingas identifikavimas prie

„debesies“ bei nereikalinga nustatinėti buvimo vietos. Kai „debesis“ yra įmonės viduje, sumaţėja

reikalavimai identifikavimo priemonių valdymui, standartams bei API.

21

1.5.6. Mišrus debesis

Šis panaudojimo scenarijus apima daugialypius (viešus ir privačius) „debesis“, veikiančius

išvien (ţr. 8 pav.). Mišrius „debesis“ platinanti teikėjų federacija, apjungia savo ir kitų teikėjų

resursus. Brokeris taip pat gali platinti mišrius „debesis“, tačiau jis jau neapjungia savo resursų,

kadangi jų neturi. Mišrių „debesų“ teikėjas turi suvaldyti ir paskirstyti „debesų“ resursus, pagal

vartotojų nustatytas sąlygas.

8 pav. Mišrus debesis


Svarbu paţymėti, kad mišraus „debesies“ vartotojams, šis panaudojimas niekuo nesiskiria

nuo prieš tai nagrinėto Vartotojas – Debesis. Vartotojas neturi jokių ţinių apie tai, ką mišraus

„debesies“ teikėjas daro iš tikrųjų.

Reikalavimai:

Šiam panaudojimui įeina visi ankstesni panaudojimo scenarijų reikalavimai (išskyrus

Tarpusavio susitarimus ir suderinimus), o ypatingai Saugumas, Duomenų ir aplikacijų

suderinamumas ir Tarpusavio sąveika.

SLA: reikalingas standartinis, SLA apibūdinantis, formatas, kurį suprastų kompiuteriai. Tai

leistų mišraus „debesies“ teikėjui paskirstyti savo vartotojams resursus (pagal SLA aprašytas

vartotojo sąlygas) be ţmogiško įsikišimo.

22

1.6. Panaudojimo scenarijų apibendrinimas

Ţemiau pateikiamoje lentelėje atsispindi panašumai ir skirtumai tarp galimų panaudojimo

scenarijų (ţr. 1 lentelę).

1 lentelė

Reikalavimai Vartotojas –

Debesis

Įmonė –

Debesis –

Vartotojas

Įmonė –

Debesis

Įmonė –

Debesis –

Įmonė

Privatus

debesis Mišrus

debesis

Identifikavimas + + + +

Atviras klientas + + + + + +

Federacinis

identifikavimas + + + +

Vietovės

nustatymas + + + +

Vertinimas ir

kontroliavimas + + + + +

Valdymas ir

valdţia + + + + +

Saugumas + + + + + +

Išsidėstymas + +

Tarpusavio

susitarimai ir

suderinimai

+

Tarpusavio

sąveika + +

Specifiniai

pramonės

standartai

+ + +

VM atvaizdo

formatas + + + + +

API + + + +

Duomenų ir

aplikacijų

suderinamumas

+ + + +

SLAs + + + + + +

Gyvavimo ciklo

valdymas + + + +

Apibendrinta panaudojimo galimybių lentelė pateikia panašumus ir skirtumus tarp galimų

scenarijų. Tai parodo su kokiais reikalavimais susiduriama konkrečiu atveju. Privataus „debesies“

atveju keliama maţiausiai reikalavimų, kadangi jis yra įmonės viduje. Tuo tarpu mišraus tipo

„debesis“ apima visus reikalavimus, kadangi jis sudarytas iš privataus ir viešo tipo „debesų“

kombinacijos.

Kiekvienas scenarijus turi vieną ar kelis tik sau išskirtinius reikalavimus. Kiti reikalavimai

tokie kaip saugumas priskiriami kaip bendrieji, kadangi jie keliami visiems panaudojimo

23

scenarijams. Lentelėje (ţr. 1 lentelę) pastebima, kad kuo sudėtingesnis įmonės panaudojimo

scenarijus, tuo aukštesnis saugumo reikalavimo lygis.

Viešo tipo „debesies“ panaudojimas galimas visais atvejais, išskyrus privatų „debesies“

panaudojimą. Reikalavimų sudėtingumas, priklauso nuo to, kas dalyvauja konkrečiam scenarijuje.

Jei tai yra tik pavienis galutinis vartotojas, tai ir reikalavimai yra minimalūs, tačiau jeigu papildomai

šalia atsiranda ir įmonė, tai jau ir reikalavimai tampa sudėtingesni.

Privataus „debesies“ panaudojimas labiau naudingas didesnėms įmonėms, kadangi

„debesis“ dalyvauja įmonės viduje. Taigi visi procesai ir jiems reikalinga perduoti informacija

skleidţiama įmonės viduje t.y. per intranetą, todėl saugumo reikalavimai yra maţesni, nei kitiems

panaudojimo scenarijams.

Į mišraus tipo „debesies“ panaudojimą įeina visi prieš tai buvusių scenarijų iškelti

reikalavimai, o ypatingai Saugumas, Duomenų ir aplikacijų suderinamumas ir Tarpusavio sąveika.

Taigi, norint įmonei garantuoti funkcinį suderinamumą, integraciją ir mobilumą,

rekomenduojama standartizuoti reikalavimus. Tam, kad šie reikalavimai būtų standartizuoti, būtina

pasitelkti atvirus standartus.

1.7. Virtualių mašinų platformos

Prieš pradedant tirti „debesų kompiuterijos“ platformas, siūloma susipaţinti su galimomis

virtualių mašinų platformomis, kadangi kaip ir anksčiau buvo minėta – „debesyse“ yra naudojama

daug virtualizacijos modelių. Taigi šiame skyriuje trumpai apţvelgtos virtualių mašinų platformos,

kurios yra naudojamos skirtingose „debesų“ platformose. Skyriaus pabaigoje sudaryta VM

platformas apibendrinanti lentelė.

XEN pasiţymi tuo, kad jau yra integruota į „Linux“ diegimo paketą, kaip pvz.:

„openSuSE“ ar kitose „Linux“ versijose. Programos kodas yra tiesiai integruotas į „Linux“

branduolį (angl. Kernel XEN) ir tik įdiegus „Linux“ operacinę sistemą, jau galima kurti virtualias

mašinas. XEN vis dar yra kūrimo stadijoje ir visiems norintiems ją patobulinti yra prieinamas

programos kodas [36].

KVM (angl. Kernel-based Virtual Machine) yra tam tikras programai ištrinti skirtas

„Linux“ branduolio kodas, reikalingas, kai branduolys palaiko virtualią infrastruktūrą [37].

ESX ir ESXi yra „bare-metal“ tipo. Tai reiškia, kad jos yra tiesiogiai įdiegtos fizinėje

techninėje įrangoje, kur ir skirsto pagrindinio serverio resursus. „VMware“ siūlomi ESX/ESXi

sprendimai pasiţymi tokiomis funkcijomis, kaip „vMotion“, pastovus prieinamumas (angl. High

Availability) ir kt. Šios funkcijos taip pat palaikomos ir tada, kai ši platforma naudojama atviro

kodo „debesies“ sprendimui. Nors „VMware“ platforma ir palaiko konfigūraciją bei valdymą, jos

24

neįmanoma susieti su atviro kodo „debesies“ sprendimu. Tai reiškia, kad šios funkcijos turi būti

naudojamos atskirai nuo „debesies“ sprendimo [38].

VirtualBox palaiko beveik visas operacines sistemas. Puikus suderinamumas įdiegus

„Windows“ ar „Linux“ operacinėje sistemoje. Patogi vartotojo sąsaja leidţia be vargo ir greitai

valdyti įdiegtas virtualias mašinas [39].

Linux Vserver leidţia kurti virtualius privačius serverius, kurie veikia kaip įprasti fiziniai

„Linux“ serveriai, tačiau jų gali būti daugiau. Visi virtualūs serveriai veikia vienoje sistemoje,

tačiau galima įjungti arba išjungti atskiras paslaugas (ssh, mail, web, duomenų bazes) kiekvienam

virtualiam serveriui taip pat, kaip ir administruojant realius serverius. Kiekvienas virtualus serveris

turi savo atskirus vartotojų duomenų bazę ir administratorių. Tarpusavyje jie yra nepriklausomi ir

negali turėti įtakos kitų virtualių serverių veikimui [40].

Ţemiau sudarytoje lentelėje (ţr. 2 lentelę) pateiktas VM platformų apibendrinimas.

Daugelį įmonių dominančios operacinės sistemos (OS) yra „Windows“ ir „Linux“, todėl kitos OS

nebuvo įtrauktos.

2 lentelė

VM platforma Gamintojas Veikiančios OS

platformose (host OS)

Palaikomos OS

(guest OS)

Licenzija

ESX VMware nereikalinga Linux, Windows Nuosavybės

ESXi VMware nereikalinga Linux, Windows Nuosavybės

KVM Qumranet Linux Linux, Windows GPL6

Xen Citrix Systems Linux Linux GPL

VirtualBox Sun Microsystems Linux, Windows Linux, Windows GPL; pilnai versijai

taikoma nuosavybės

licenzija

Linux VServer Community

Project

Linux Linux GPL

Apţvelgus virtualių mašinų platformas, pastebėta, kad „VMware“ gamintojo ESX ir ESXi

platformos išsiskiria tuo, kad joms nereikalinga OS. Iš kitų likusių VM platformų išsiskiria

VirtualBox, kuri palaiko populiarias OS t.y. Windows ir Linux. Taigi toliau bus atsiţvelgiama ar

tiriama „debesų kompiuterijos“ platforma palaiko šias dvi VM platformas.

6 (GPL – General Public Licence). Tai reiškia, jog ši programinė įranga yra nemokama, tačiau neturėdami leidimo

vartotojai neturi teisės ja naudotis ir jos platinti.

25

1.8. „Debesų kompiuterijos“ platformos

„Debesų kompiuterijos“ svarba nuolatos auga, todėl vis daugiau bendrovių bando iš šio

reiškinio išgauti naudą. Tokios stambios bendrovės, kaip „Microsoft“, „Google“ ir „Amazon“ jau

teikia „debesų kompiuterijos“ paslaugas. Tuo tarpu maţesnės (maţiau ţinomos) įmonės taip pat

siekia iškilti su savo viešųjų ir privačių „debesų“ sprendimais. Taigi sudarytas toks galimų „debesų

kompiuterijos“ platformų sąrašas:

3Tera (AppLogic)

AbiCloud

Amazon EC2

Aserver/DAAS

Deltacloud

Enomaly's Elastic Computing Platform (ECP)

Eucalyptus

Flexiscale

Gandi

GoGrid

IBM cloudburst

Nimbus

OpenNebula

Openqrm

Rackspace (Mosso)

Ubuntu Enterprise Cloud (UEC)

VMware vSphere

Iš visų galimų aukščiau išvardintų „debesų“ platformų, apţvelgiamos penkios tyrimui

pasirinktos platformos:

„AbiCloud“

„Eucalyptus“

„OpenNebula“

„OpenQrm“

„VMware vSphere“

26

Šios platformos pasirinktos todėl, kad jos yra daugumą reikalavimų atitinkantys

sprendimai; t.y. palaiko dauguma operacinių sistemų, gali jungtis su kitomis „debesų“ ar

virtualizacijos platformomis bei turi didţiausią potencialą.

1.8.1. „AbiCloud“

„AbiCloud“ yra privataus tipo „debesies“ kūrimui skirta platforma, sukurta „Abiquo“, kuri

metams bėgant sukaupė tam tikrą patirtį dirbant su paskirstytų skaičiavimų tinklais (angl. grid

computing) [5]. „AbiCloud“ suteikia galimybę valdyti savo (virtualius) duomenų centrus, pasitelkus

aiškiai suprantamą grafinę vartotojo sąsają.

„AbiCloud“ pasiţymi tiek fizinių, tiek ir virtualių mašinų monitoringo bei valdymo

galimybe. Vartotojai gali kurti programas „debesies“ viduje, kad jas galėtų pasitelkti kaip

programinės įrangos kaip paslaugos produktą. Ši platforma taip pat itin lanksti ir lengvai

praplečiama: „Tai yra atviro tipo platforma, kuri leidţia lengvai integruoti trečiųjų šalių programas

(skirtas monitoringui, saugumui, apskaitai ir t.t.), siekiant palengvinti specifinių privačių „debesų“

kūrimą“ [6].

Galima įsigyti tiek visuomenei, tiek įmonėms skirtas „AbiCloud“ versijas. Pagrindinis

skirtumas tarp šių dviejų variantų yra tai, kad su įmonėms skirta versija galima valdyti daugiau

duomenų centrų. Taip pat išleista speciali, paslaugų teikėjams skirta versija, vadinama „xSP“. Ši

versija pasiţymi tuo, kad turi papildomus įrankius, skirtus viešojo „debesies“ diegimui.

„AbiCloud“ naudoja CPAL (nemokamų programų) 1.0 licenciją, skirtą vartotojo sąsajai

kurti.

Šiam tyrimui naudojama „AbiCloud“ 1.0.0RC3 versija, nes tai buvo naujausia versija,

kurią buvo galima įsigyti.

Architektūra

„AbiCloud“ architektūrą sudaro šie komponentai (ţr. 9 pav.) [6]:

Serveris (abiCloud_Server): skirtas sąveikauti su duomenų baze, valdyti klientus, fizinę

serverio infrastruktūrą, įrankių saugyklą ir virtualius prietaisus.

Web paslaugos (abiCloud_WS): skirtos virtualių įrankių valdymui.

Virtualaus monitoringo sistema (abiCloud_VMS): skirta virtualios infrastruktūros

monitoringui.

Prietaisų valdiklis (AbiCloud Appliance Manager): skirtas prietaisų dydţio keitimui

(angl. scalability), valdymui bei paskirstymui. Tačiau jis vis dar yra kūrimo ir testavimo

būsenoje.

27

Duomenų saugojimo valdiklis (AbiCloud Storage management): skirtas integruoti bet

kokią duomenų saugojimo sistemą į „debesies“ platformą. Šis valdiklis vis dar kuriamas.

Klientas (abiCloud_client): tai lanksti web aplikacija, kuri suteikia vartotojams galimybę

valdyti jų privačius „debesis“ iš bet kur ir bet kokiomis aplinkybėmis.

Atvira API programų sąsaja (Open API‘s): tai svarbus platformos komponentas,

leidţiantis sukurti išorinę terpę, prie kurios galėtų jungtis trečios šalies „debesys“.

9 pav. „AbiCloud“ platformos architektūra

Šaltinis: http://abicloud.s3.amazonaws.com/latest/AbiCloud.Technical.Overview-1.0.pdf

Priimančioji operacinė sistema (angl. Host operating system). „AbiCloud“

suprogramuota „Java“ kalba, o tai reiškia, kad ši platforma yra nepriklausoma. „Abiquo“

palaikomos operacinės sistemos yra: „Linux Ubuntu“, „Linux Centos“, „Microsoft Windows XP“ ir

„Mac OS X“. Mazgų valdikliai (jie paleidţia virtualizacijos įtaisus) palaiko tik „Ubuntu“ ir

„CentOS“.

Svečių operacinė sistema (angl. Guest operating system). „AbiCloud“ palaiko tokias

populiarias operacines sistemas, kaip „OpenSUSE“, „Ubuntu“, „Fedora“ ir „CentOS“.

Virtualių mašinų platformos. Palaikomi virtualizacijos modeliai: „VirtualBox“ 2.2,

„VMware“, XEN ir KVM.

Atviras virtualizacijos formatas7 (angl. OVF – Open Virtualization Format).

„AbiCloud“ yra platforma, skirta darbui su OVF standartu (šiuo metu atitinka OVF 1.0

specifikacijas). Naudojant OVF standartą, skirtingos virtualių mašinų platformos gali naudotis tais

pačiais virtualiais prietaisais, o tai reiškia, kad duomenų centrai gali dalintis virtualiais atvaizdais.

7 Atviros virtualizacijos formatas (angl. Open Virtualization Format) – tai yra atviras standartas, skirtas virtualių įrankių

(virtualių mašinų valdomos programinės įrangos) kūrimui ir platinimui. Įvertinama, ar šis standartas yra taikomas

tiriamoje platformoje.

28

Uţimama rinkos dalis

„AbiCloud“ platforma aktyviausiai naudojasi Ispanijoje (kai kurios iš šios programos

instrukcijų ir dokumentų yra pateikiami ispanų kalba, o tik tada išversti į anglų). „AbiCloud“

gamintojai didţiausią dėmesį skiria „hosting„o“ paslaugų teikėjams bei įmonėms, norinčioms

įgyvendinti „debesies“ sprendimus. Galima manyti, kad „AbiCloud“ gamintojai nėra labai aktyvūs

uţ Ispanijos ribų, nes jų tinklalapyje pavyko uţfiksuoti tik du ne ispanų kilmės klientus. Kadangi

nebuvo rasta daugiau informacijos apie „AbiCloud“ rinką, todėl nuspręsta, kad šios platformos

vaidmuo „debesų kompiuterijos“ rinkoje yra nedidelis, tačiau teikiantis įdomių galimybių.

Tolimesnė raida

„AbiCloud“ vis dar yra kūrimo ir testavimo būsenoje. Remiantis gamintojų interneto

svetainės teikiama informacija, nustatytos funkcijos, kurias jie nori įdiegti ateityje [6]:

Statistika ir monitoringas: siekiama sukurti sąsają, per kurią būtų galima pasinaudoti bet

kokiu (kad ir savo susikurtu) kitu monitoringui skirtu stebėti bet kokią „debesyje“

vykstančią funkciją įrankiu.

Automatinis resursų dydţio keitimas: siekiama sukurti nepriklausomą nuo trečiųjų šalių

įrankį, kuris automatiškai keistų infrastruktūros dydį.

Tinklas: siekiama patobulinti tinklo funkcionalumą, kad pagerinti virtualaus duomenų centro

valdymo kokybę.

Saugumas: siekiama patobulinti saugumo funkcijas bei įdiegti papildomus modulius.

Informacija apie vartotojus: siekiama sukurti sąsaja, kuri leistų atkurti visą informaciją apie

vartotojų aktyvumą „debesyje“.

Pranešimų sistema: siekiama sukurti perspėjimus, skirtus sistemos vartotojams.

1.8.2. „Eucalyptus“

„Eucalyptus“ yra atviro kodo programinės įrangos infrastruktūra, skirta „debesų

kompiuterijos“ diegimui. Jos istorija prasidėjo nuo tada, kai buvo pradėtas informatikos katedros

tyrimų projektas Kalifornijos universitete, Santa Barbaroje [11]. „Eucalyptus“ yra trumpinys, kuris

išsišifruoja taip: Elastic Utility Computing Architecture for Linking Your Programs To Useful

Systems („Lanksti architektūra, sujungianti jūsų programas su naudingomis sistemomis).

„EUCALYPTUS sistema yra sukurta taip, kad administratoriai bei tyrėjai turėtų galimybę įsidiegti

infrastruktūrą, kuri leistų vartotojams valdyti virtualias mašinas ir kartu kontroliuoti svarbiausius

turimus resursus. Jos hierarchinis modelis yra susijęs su daţniausiai akademinėje aplinkoje ir

laboratorijose aptinkamais resursais, įskaitant, bet neapsiribojant, maţo ir vidutinio dydţio „Linux“

blokiniais (angl. cluster), sudėtingų kompiuterių terpėmis ir serveriais“ [12]. „Eucalyptus“ siekia

29

pasiūlyti tas pačias funkcijas kaip ir „Amazon EC2“ (tačiau tik privačiame „debesyje“) ir naudoja

tos pačios rūšies (komandinės eilutės) įrankius.

„Eucalyptus“ suteikia galimybę sukurti privatų „debesį“ uţ savo įmonės ugniasienės ribų.

Vienas iš svarbiausių „Eucalyptus“ privalumų yra toks, kad ji turi daug modulių, o jos naudojama

API programų sąsaja yra suderinta su „Amazon AWS“ [13]. Šis suderinamumas (su vienu iš

didţiausių viešųjų „debesų“ teikėjų) suteikia „Eucalyptus“ didelį lankstumą, taigi, klientai neprivalo

apsiriboti tik savo privačiu „debesiu“, o atsiradus poreikiui, gali lengvai pereiti prie kito „debesies“.

Egzistuoja dvi „Eucalyptus“ versijos: atviro kodo variantas ir įmonėms skirta versija.

Esminis skirtumas tarp šių dviejų variantų yra toks, kad įmonėms skirta versija palaiko „VMware

vSphere“ [13]. Šiuo metu atviro kodo „Eucalyptus“ variantas palaiko tik KVM ir XEN

virtualizacijos modelius. Tikimasi patobulinti „Eucalyptus“ taip, kad ši sistema palaikytų dar

daugiau virtualizacijos platformų [12].

Atviro kodo variantą įsigyti galima pagal „Free BSD“ licenciją, o įmonėms skirta versija

yra komercinis produktas.

Tyrimui naudojama „Eucalyptus“ 1.6.1 versija, nes tai buvo naujausias šios platformos

variantas.

Architektūra

„Eucalyptus“ susideda iš penkių komponentų (ţr. 10 pav.) [11]:

„Debesies“ valdiklis (angl. CLC – Cloud Controller). Tai įeities taškas (angl. entry-point)

į „debesį“, pasiekiamas per web sąsają, skirtą tiek administratoriams tiek ir galutiniams

vartotojams. CLC yra atsakingas uţ vartotojų siunčiamas uţklausas mazgų tvarkyklėms

(angl. node managers) ir pagrindinių resursų (serverių, duomenų saugyklų ir tinklo)

virtualizaciją.

Klasterio valdiklis (angl. CC – Cluster Controller). Tai tarpinis operatorius tarp

„debesies“ valdiklio ir mazgų valdiklio. CC rezervuoja uţduotis, gautas iš CLC ir gavęs

nurodymus, nustato kuris mazgų valdiklis perims tą uţduotį. Šis valdiklis suformuoja

kiekvieno klasterio pradinį proceso etapą (angl. Front-End).

Mazgų valdiklis (angl. NC – Node Controller). Tai įrenginiai, paleidţiantys virtualias

mašinas. NC kontroliuoja VM darbą (įjungimą ir išjungimą) pagrindiniame kompiuteryje

(angl. host), kuriame jis paleidţia, nuskaito ir trina vietines (branduolio, pagrindinių failų

sistemos ir virtualiojo disko) atvaizdų (angl. images) kopijas. Mazgų valdikliai vykdo

uţklausas, gautas iš klasterio valdiklio. Taip pat sąveikauja su OS (pagr. kompiuterio) ir VM

platformomis taip kaip nurodo CC.

30

Saugojimo valdiklis (angl. SC – Storage Controller). Jis uţtikrina objektų saugojimą

(pvz.: „Amazon Elastic Block Storage“ (EBS)), ir gali sąveikauti su įvairiomis saugojimo

sistemomis, tokiomis kaip NFS, iSCSI ir t.t.

„Walrus“ suteikia galimybę vartotojams išsaugoti savo duomenis kaip įprastame kietajame

diske. Jis apima visą „debesį“, o jo atliekamos funkcijos yra panašios į „Amazon S3“. Taigi

„Walrus“ yra suderinta su „Amazon S3“, todėl palaiko „Amazon Machine Image“ (AMI)

valdymo sąsają. AMI leidţia išsaugoti vartotojų duomenis bei virtualios mašinos atvaizdus

ir taip pat valdo prieigą prie jų.

10 pav. „Eucalyptus“ architektūra

Šaltinis: http://open.eucalyptus.com/chrome/site/diagrams/architecture-1.6.png

Priimančioji operacinė sistema. „Eucalyptus“ veikia daugelyje populiarių „Linux“

platinamų OS, įskaitant „Ubuntu“, „Red Hat Enterprise Linux“, „Centos“, „SUSE Linux Enterprise

Server“, „openSUSE“ ir „Debian“. Naudojantis serveriui skirta „Ubuntu“ 9.10 operacine sistema, ji

įdiegiama kaip numatytoji „debesies“ platforma.

Svečių operacinė sistema. Populiariausios „Linux“ platinamos OS palaikomos kaip svečių

operacinės sistemos. „Windows“ taip pat įmanoma paleisti kaip svečių operacinę sistemą.

Virtualių mašinų platformos. Palaikomi virtualizacijos modeliai: XEN ir KVM.

Įmonėms skirta versija (UEC – Ubuntu Enterprise Cloud) taip pat palaiko ir „vSphere“. Diegiant

UEC, naudojama numatytoji KVM platforma.

Atviras virtualizacijos formatas (OVF). Ši platforma vis dar nepalaiko OVF, nes apie tai

nerašoma jų pačių platinamoje dokumentacijoje.


Tokios didelės organizacijos, kaip „NASA“ ir „Lilly“ (didţiulė farmacijos bendrovė) jau

sėkmingai įdiegė privatų „debesį“ [32]. „Eucalyptus“ itin domimasi, kadangi tai yra vienas iš

31

pirmųjų atviro kodo privačių „debesų“ produktų. Šiuo metu įmonės pasitelkia demonstracinę

aplinką, norėdamos išbandyti „Eucalyptus“ teikiamas galimybes. Taip pat sulaukiama didelė

parama iš atviro kodo bendruomenės, taigi, produkto vystymasis yra itin greitas.

Tolimesnė raida

Tikimasi, kad „Eucalyptus“ tobulinimas ir toliau vyks kartu su „Ubuntu“. Kadangi

nepavyko rasti jokios konkrečios informacijos apie būsimus pokyčius, galima tikėtis, kad greitai

trūkstamos savybės greitai bus įdiegtos, o augant susidomėjimui, didės ir bendruomenės narių

skaičius.

1.8.3. „OpenNebula“

„OpenNebula“ yra standartais pagrįstas įrankių rinkinys, skirtas savo „debesies“ kūrimui.

Visų pirma „OpenNebula“ gali būti naudojama kaip priemonė duomenų centro (paprastai vadinamo

privačiu „debesiu“) virtualiai infrastruktūrai valdyti. Jis palaiko mišriuosius „debesis“ ir kartu

sujungia vietinę infrastruktūrą su viešaisiais „debesimis“, o tai suteikia galimybę sukurti keičiamo

dydţio aplinkas. Privatus „debesis“ gali uţmegzti ryšį tiek su partnerio, tiek ir su komerciniais

„debesimis“ [16]. Mišriuose „debesyse“ „OpenNebula“ palaiko „Amazon EC2“ ir „ElasticHosts“

„debesų“ jungtis. Šios „OpenNebula“ savybės suteikia galimybę sukurti keičiamo dydţio aplinką.

Mišriųjų „debesų“ diegimas infrastruktūros vartotojams išlieka suprantamas, kadangi jie

gali ir toliau naudoti tą pačią „debesies“ sąsają. Jungimasis į federaciją atliekamas tik

infrastruktūros (IaaS) lygyje. „ „OpenNebula“ galima naudoti pagal „Apache“ licencijos 2.0

versijos sąlygas.“ [16]

Tyrimui naudojama „OpenNebula“ 1.4 versija, nes tai buvo naujausia versija, kurią buvo

galima įsigyti.

Architektūra

„OpenNebula“ architektūra sudaryta iš trijų sluoksnių (ţr. 11 pav.) [18]:

Branduolio (angl. Core). Tai yra centralizuota sudedamoji dalis, kuri valdo virtualių

mašinų (VM) gyvavimo ciklą, atlikdama pagrindines VM operacijas (t.y. įdiegimą, valdymą,

perkėlimą ar išjungimą). Branduolio atliekamos funkcijos apima:

- Vartotojų siunčiamų uţklausų apdorojimą.

- Virtualių mašinų valdymą ir jų monitoringą.

- Virtualių mašinų atvaizdų (angl. images) valdymą.

- Virtualių tinklų valdymą.

- Fizinių resursų valdymą ir jų monitoringą.

- Duomenų bazių valdymą.

32

Įrankiai (angl. Tools). Šis sluoksnis apima „OpenNebula“ sukurtus valdymo įrankius,

tokius kaip: CLI (angl. Command Line Interface), planuoklė (angl. scheduler), „libvirt“

(sąsaja, skirta sąveikauti su virtualiomis mašinomis). Šiame sluoksnyje gali būti patalpintas

trečios šalies įrankis, sukurtas per „XML-RPC“ arba „OpenNebula Cloud API“ sąsają.

Tvarkyklės (angl. Drivers). Šios tvarkyklės sukurtos tam, kad branduolys galėtų palaikyti

skirtingas virtualizacijos, saugojimo bei monitoringo technologijas.

11 pav. „OpenNebula“ architektūros sluoksniai

Šaltinis: http://www.opennebula.org/documentation:rel1.4:architecture

Priimanti operacinė sistema. „OpenNebula“ palaiko populiariausias „Linux“ platinamas

OS („Ubuntu“, „Red Hat Enterprise Linux“, „Fedora“, „SuSE Linux Enterprise Server“). Įmanoma

įsigyti dvejetainius šių programų paketus (angl. binary packages). „OpenNebula“ naudojamos C++

ir „Ruby“ programavimo kalbos. Daugelis komponentų palaiko tik C++ arba tik „Ruby“

programavimo kalbą, taigi, daţniausiai klientams tereikia mokėti tik vieną iš jų.

Svečių operacinė sistema. Įdiegus ir sukonfigūravus „OpenNebula“, nėra numatyta jokių

šabloniškų (virtualių) atvaizdų (angl. images), kuriuos būtų galima naudoti. Šiuos atvaizdus reikia

sukurti vėliau. Taigi, nėra jokios OS, kuri yra atpaţįstama kaip numatytoji.

Virtualių mašinų platformos. Palaikomi šie virtualizacijos modeliai: XEN, KVM ir

„VMware“.

Atviras virtualizacijos formatas (OVF). „OpenNebula“ gamintojai rekomenduoja

naudoti šį standartą, nes jis supaprastina palaikymą su įvairiomis virtualizacijos platformomis.


33

„OpenNebula“ bendruomenė didėja. Ji taip pat turi daug jos projektų („The Reservoir

Project“ ir „The NUBA Project“) palaikančių globėjų. Kadangi „OpenNebula“ internete yra itin

stipriai domimasi, tikėtina, kad šios platformos vystymasis turėtų būti spartus. Tai yra dar naujas

produktas, todėl daţniausiai juo naudojamasi demonstracinėje aplinkoje. Galima numatyti, kad dėl

puikių savybių ir nuolatinio tobulėjimo ši programa išsivystys iki įdomaus ir perspektyvaus

„debesies“ sprendimo.

Tolimesnė raida

Šiuo metu „OpenNebula“ tobulinama, siekiant, kad ši programa palaikytų „VirtualBox“

VM platformą. Planuojama šią funkciją įdiegti 1.4.2 versijoje.

Kiti numatomi pokyčiai: „SUN Cloud API“, „vCloud API“, „Grid service manager“, LVM

(Logical Volume Manager) ir SAN (Storage Area Network) palaikymas. Taip pat siekiama įdiegti

saugumo sistemą ir sukurti SLA (Service Level Agreement).

Taip pat planuojama „OpenNebula“ įdiegti daugiau atvirų standartų tokių, kaip CSA8,

DMTF, OMG9 ir OASIS.

1.8.4. „OpenQRM“

„OpenQRM“ yra itin visapusiškas ir lankstus atviro kodo infrastruktūros valdymo

panaudojimo atvejis (angl. Open Source Infrastracture Management Solution). Ši platforma

pasiţymi lanksčia architektūra, į kurią galima diegti įvairias programas. Tokio tipo architektūra

pasiţymi sparčiu, automatizuotu prietaisų diegimu, monitoringu, prieinamumo zonomis, ir ypač

gerai prisitaiko prie daugelio virtualizacijos modelių.

Taigi pats „OpenQRM“ savyje nepasiţymi jokiomis aukščiau išvardintomis funkcijomis.

Visos šios platformos atliekamos funkcijos naudoja papildinius (angl. plug-in), kurie „OpenQRM“

paverčia galingu infrastruktūros valdymo įrankiu. Papildiniai uţtikrina prieigą prie įvairių

virtualizacijos platformų, duomenų saugyklų, monitoringo bei kontrolės įrankių, naudojamų

diegiant „debesų kompiuteriją“. Pilnas „OpenQRM v4.x“ naudojamas papildinių sąrašas

pateikiamas jų interneto svetainėje [25].

Galima įsigyti dvi „OpenQRM“ versijas: įmonėms skirtą ir atviro kodo. „Įmonėms skirta

„OpenQRM“ (angl. OpenQRM Enterprise) versija pasitelkia pagrindinių narių ir „OpenQRM“

projekto kūrėjų kompetenciją; kiekviena šio atviro kodo sprendimo detalė yra sukurta, remiantis

8 CSA (Cloud Security Alliance) – tai ne pelno siekianti organizacija, kurios tikslas – skatinti visuomenę dalintis

ţiniomis ir patirtimi, susijusiomis su saugumu „debesų kompiuterijoje“. 9 OMG (Object Management Group) susitelkia ties modeliavimu; pastebimos dar tik pirmosios konkrečios pastangos

apibrėţti su „debesimi“ susijusias specifikacijas, sutelkiant dėmesį į programų ir paslaugų diegimo modeliavimą

„debesyje“.

34

ekspertų ţiniomis, o duomenų centro nustatymai priimti, remiantis geriausia patirtimi. Naudojantis

patvirtinta atviro kodo sistema (angl. Open Source framework), siekiama sumaţinti bendras IT

skyriaus išlaidas (angl. Total Cost of Ownership)“ [26].

„OpenQRM“ yra platinama pagal bendrą viešąją licenziją (angl. GPL – General Public

Licence). Tai reiškia, jog ši programinė įranga yra nemokama, tačiau neturėdami leidimo vartotojai

neturi teisės ja naudotis ir jos platinti.

Tyrimui naudojama „OpenQRM“ 4.6 versija, nes tai buvo naujausia versija, kurią buvo

galima įsigyti.

Architektūra

„OpenQRM“ 4.6 versijos atveju reikalingi tokie prietaisai (ţr. 12 pav.) [25]:

„OpenQRM“ serveris padalintas į dvi dalis t.y. bazė ir papildiniai. Bazė iš dalies valdo

papildinius, ir suteikdama jiems galimybę naudotis įvairiais ruošiniais, kurie padeda

sąveikauti su objektais (duomenų saugojimo, atvaizdų ir t.t.). Tuo tarpu papildiniai vykdo

pagrindines „debesies“ funkcijas.

Pastoviai prieinamo nuotolinio duomenų bazių serverio (pvz.: „MySQL“ arba „Oracle“).

Bent vieno pastoviai prieinamo (angl. high-available) duomenų saugojimo serverio.

Fizinių prietaisų paleidimo bei jų valdymo „OpenQRM“ sistema.

12 pav. „OpenQRM“ architektūros topologija

Šaltinis: http://www.openqrm.com/?q=node/42

35

Priimanti operacinė sistema. „OpenQRM“ palaiko daugelį priimančių operacinių

sistemų, sukurtų tokiomis programavimo kalbomis kaip: C, „Java“, „JavaScript“, PHP, „Perl“,

„Unix Shell“. „OpenQRM 4.x“ palaiko įvairias „Linux“ platinamas OS, tokias kaip „Debian“,

„Ubuntu“, „CentOS“ ir „openSUSE“. Vienas „OpenQRM“ serveris gali nesunkiai aprūpinti šiuos

skirtingus „Linux“ platinamų OS serverius.

Svečių operacinė sistema. Norint greitai ir paprastai paleisti įrenginius „OpenQRM“

naudoja „ready-made“ ir „known-to-work“ atvaizdus tokiose OS kaip „Debian“, „Ubuntu“,

„CentOS“ ir „openSUSE“. Papildomai pridedant pakopomis išdėstomų atvaizdų (angl. image-shelf)

papildinius, atsiranda galimybė prisijungti prie serverių per web sąsają. Gali būti naudojami įprasti

arba specialiai sukurti pakopomis išdėstomų vaizdų serveriai, o tai reiškia, kad serverio vaizdus

galima atsisiųsti iš viešojo pakopomis išdėstomų vaizdų serverio arba pateikti savo specialiai

sukurtų pakopomis išdėstomų vaizdų serverį. „OpenQRM“ taip pat palaiko „Windows“

virtualizaciją.

Virtualių mašinų platformos. Palaikomi virtualizacijos modeliai: „VMware“, XEN,

KVM ir „Linux Vserver“. Per „OpenQRM“ platformą juos nesudėtinga valdyti. „OpenQRM“ taip

pat palaiko ir pagrindinius fizinius įrenginius, kurie neveikia kaip virtualizacija; tačiau ši palaikoma

funkcija yra itin naudinga, kai reikia pereiti nuo fizinio į virtualų duomenų centrą.

Atviros virtualizacijos formatas (OVF) „OpenQRM“ nepalaiko OVF. Jo virtualūs

atvaizdai pasiţymi savo formatu.


„OpenQRM“ yra labiau orientuota į duomenų centrų valdymą, tačiau visai neseniai buvo

įdiegta ir „debesies“ funkcija. Ši platforma jau turi daugybę rėmėjų, kurie suteikia palankesnes

sąlygas produkto vystymui. „OpenQRM“ bendruomenė vis dar auga, diegiami vis nauji šios

platformos patobulinimai, o ypatingai orientuojamasi į klasterių valdymą.

Būsima plėtra

„OpenQRM“ ir toliau tobulinama, todėl „Source-Forge“ puslapyje galima pasiteirauti dėl

naujų „OpenQRM“ galimybių. Taigi numatomas „VirtualBox“ palaikymas, paprastesnis

„Windows“ OS palaikymas ir prietaisų tinklo konfigūravimas (angl. Network Configuration for

Appliances).

1.8.5. „VMware vSphere“

Skirtingai nuo prieš tai ištirtų platformų, „VMware vSphere“ yra įdiegta tiesiogiai į

techninę įrangą ir gali funkcionuoti be pagrindinės operacinės sistemos. Ši galimybė leidţia

pasinaudoti daugeliu „VMware“ virtualizacijos modelių, skirtų privačiam „debesiui“ įmonės viduje

36

sukurti. „vSphere“ sudaro keletas modulių, tokių kaip: ESX/ESXi virtualių mašinų platforma,

paskirstytų resursų planuoklis (angl. DRS – Distributed Resource Scheduler), „Vmotion“,

„VMware“ gyvavimo ciklo valdiklis (angl. VMware LifeCycle Manager). Tai yra plačiai

naudojamos priemonės, leidţiančios pritaikyti virtualizaciją įmonių duomenų centrams. Daugelis

bendrovių jau yra įsidiegę šiuos populiarius „VMware“ modelius [27].

„VMware“ gamintojai jau daugiau kaip dešimt metų dirba su virtualizacijos modeliais. Jie

turi sukaupę didelę virtualizacijos patirtį ir ţino efektyvius sprendimus. Kadangi virtualizacijos

naudojimas sudaro pagrindinę „debesų kompiuterijos“ esmę, tai egzistuoja didelė tikimybė, kad

„vSphere“ gali būti geriausias įmanomas panaudojimo atvejis. „vSphere“ duomenų centrams siūlo

tokias reikalingiausias funkcijas kaip: pastovus prieinamumas, virtualių mašinų perkėlimas realiu

laiku, atsparumas gedimams, atsarginių kopijų variantai ir paprastas naudojimas. Tarp jų siūlomas ir

„vCloud“ – „debesies“ infrastruktūrai skirtas produktas, pasiţymintis galimybe kelis „debesis“

sujungti į federaciją, o taip pat įmanoma perkelti uţduotis į viešuosius „debesis“. Vienintelis

trūkumas yra toks, kad šią programą palaiko tik keli viešųjų „debesų“ teikėjai [27].

Egzistuoja keturios skirtingos „VMware vSphere“ versijos t.y. standartinė, paţangi,

įmonėms skirta ir įmonėms skirta paţangi. Šiame darbe labiausiai orientuotasi į įmonėms skirtą

„vSphere“ versiją, kuri pasiţymi visomis VGĮ svarbiomis savybėmis [28].

Tyrime naudojama „vSphere“ 4-tos versijos 1-as pakeitimas, nes tai buvo naujausia

versija, kurią buvo galima įsigyti.

Architektūra

„VMware vSphere“ sudaro šie komponentai/funkcijos (ţr. 13 pav.) [27]:

„vCenter“ serveris (vCenter server) – tai centrinis taškas, kuris valdo virtualią

infrastruktūrą.

vSphere klientas (vSphere Client) – tai sąsaja, leidţianti vartotojams nuotoliniu būdų

prisijungti prie vCenter serverio arba ESX/ESXi virtualių mašinų su bet kokia „Windows“

operacine sistema.

vSphere web prieiga (vSphere Web Access) – tai web sąsaja, leidţianti valdyti virtualias

mašinas bei administruoti prisijungimą prie jų.

Virtualių mašinų failų sistema (VMFS) – tai itin aukšto lygio klasterių failų sistema,

skirta ESX/ESXi virtualioms mašinoms.

Virtualus SMP (Virtual SMP) – tai funkcija, leidţianti vienai virtualiai mašinai naudoti

kelis fizinius procesorius vienu metu.

VMotion ir Storage VMotion – „VMotion“ įgalina realiu metu perkelti veikiančias

virtualias mašinas (VM) iš vieno fizinio serverio į kitą. Tuo tarpu „Storage VMotion“

37

suteikia galimybę perkelti VM failus iš vienos duomenų saugyklos į kitą be jokio sistemos

sustabdymo.

Nepertraukiamas prieinamumas (angl. High Availability) – tai funkcija, uţtikrinanti

pastovų ir nepertraukiamą sistemos darbą. Jeigu sugenda serveris, tai jame esančios VM

perkeliamos į kitą serverį, kuriame yra papildomos vietos.

Paskirstytų resursų planuoklė (angl. Distributed Resource Scheduler) – tai įrankis,

kuris rezervuoja ir balansuoja kompiuterinius resursus.

vSphere SDK – tai standartinė „VMware“ ir trečių šalių sąsaja.

Atsparumas gedimams (angl. Fault Tolerance) – tai funkcija, sukurianti VM kopijas,

kurias vėliau panaudoja, sugedus originalioms VM.

vNetwork paskirstytas perjungiklis (vNetwork Distributed Switch) – tai funkcija

apjungianti daugumą ESX/ESXi, kad padidinti tinklo aprėptį.

13 pav. „VMware vSphere“ architektūra

Šaltinis: http://www.vmware.com/pdf/vsphere4/r40/vsp_40_intro_vs.pdf

Priimančioji operacinė sistema. „VMware vSphere“ pasiţymi savo ESX ir ESXi

virtualių mašinų platformomis, kurios nereikalauja jokios OS.

38

Svečių operacinė sistema. Palaikoma dauguma naujų ir populiariausių OS [29].

Atviros virtualizacijos formatas (OVF) „VMware“ palaiko šį atvirą standartą, kuris yra

įdiegtas jos „vSphere“ modulyje.


„VMware“ yra vienas iš didţiausių virtualizacijos paslaugas teikiančių įmonių. Didelis

privalumas yra tai, kad visi jų siūlomi produktai yra gerai ištestuoti ir pasiţymintys išsamia

dokumentacija. Galima tikėtis, kad „vSphere“ greitai turėtų tapti vienu iš pasaulinio lygio „debesų

kompiuterijos“ sprendimų lyderių, nes ši platforma jau ir dabar pasiţymi daugeliui pageidaujamų

savybių.

Tolesnė raida

„vSphere“ nuolatos tobulinama, ir šiuo metu įdiegiami daugelio svečių operacinių sistemų

ir techninės įrangos palaikymo papildymai. Kadangi „vSphere“ tampa vis populiaresnė, ji įgyja vis

daugiau viešųjų „debesų“ teikėjų palaikymų. Taigi galima tikėtis, kad „vCloud“ galimybės vis

plėsis, todėl šią platformą palaikys vis daugiau viešųjų „debesų“ tiekėjų.

1.9. Platformų apibendrinimas

Ţemiau sudaryta lentelė (ţr. 3 lentelę) atspindi „debesies“ platformų naudojamus

standartus bei supaţindina su būsimomis produkto galimybėmis, kurios apibrėţiamos pagal rastą

informaciją. Produkto galimybės vertinamos tokiomis reikšmėmis:

- - (labai blogai), - (patenkinamai), 0, + (gerai), + + (labai gerai).

3 lentelė

abiCloud

1.0.0-RC3

Eucalyptus 1.6.1 OpenNebula 1.4 openQRM 4.6 VMware

vSphere 4

Virtualių mašinų

platformos

VirtualBox,

ESXi, Xen,

KVM

Xen, KVM,

VMware

Xen, KVM,

VMware

Xen, KVM,

VMware, Linux

VServer

ESX, ESXi

Licenzijos ir standartai

Atviro kodo Taip Taip Taip Taip Ne

Įmonėms Taip Taip Ne Taip Tik įmonėms

Atviros virtualizacijos

formatas (OVF) Taip Ne Taip Ne Taip

Produkto potencialas

Uţimama rinkos dalis - + + 0 ++

Būsima plėtra + ++ ++ + ++

Daugiausiai virtualių mašinų platformų palaiko „AbiCloud“ bei „OpenQRM“. Tačiau

populiariausias ir labiausiai naudojamas VM platformas palaiko ir likusios „debesų“ platformos.

„vSphere“ naudoja savo gamintojo t.y. „VMware“ sukurtas ESX/ESXi VM platformas.

39

Nors ir „vSphere“ naudoja atviros virtualizacijos formatą, tačiau ši platforma iš visų

nagrinėtų yra vienintelė ne atviro kodo. Prisiminus anksčiau nagrinėtus „debesų kompiuterijos“

reikalavimus, buvo pabrėţta, kad diegiant mišrų „debesį“, reikalinga panaudoti kuo daugiau atvirų

standartų. Tačiau „vSphere“ pagrinde naudoja savo suprogramuotus įrankius, todėl gali kilti

problemų integruojant šią platformą su atviro kodo platformomis. Tuo tarpu „OpenNebula“ ir

„AbiCloud“ yra atviro kodo ir tuo pačiu naudoja atviros virtualizacijos formatą.

Lyginant platformų uţimamas rinkos dalis, pastebėta, kad „AbiCloud“ naudojasi tik

Ispanijoje. Tuo tarpu „Eucalyptus“ ir „OpenNebula“ uţima gana didelę rinkos dalį. „OpenQRM“

rinką buvo sunku nustatyti, kadangi ji labiau orientuojasi į klasterių valdymą, o ne į patį „debesį“.

Analizuojant būsimas plėtros galimybes, nustatyta, kad visos platformos numačiusios daug

svarbių atnaujinimų bei patobulinimų, apie kuriuos plačiau galima pasiskaityti jų gamintojų

svetainėse.

1.10. VGĮ poreikių analizė

Ne per seniausiai buvo paskelbtas projektas „E. sveikatos paslaugos“, „kurio tikslas yra

pradėti įgyvendinti vieningą, visą Lietuvą apimančią ir tarptautiniais standartais paremtą

elektroninės sveikatos bei sveikatos prieţiūros įrašų sistemą, įgalinančią efektyvų sveikatos

prieţiūros įstaigų (SPĮ) informacijos apie paciento gydymo eigą bei rezultatus įvedimą, naudojimą,

perdavimą ir administravimą, garantuojantį savalaikį pasikeitimą duomenimis apie pacientams

suteiktas paslaugas ir atliktus tyrimus kitose SPĮ“ [7]. Iš to galima daryti prielaidą, kad viešosios

gydymo įstaigos (VGĮ) privalės praplėsti savo IT infrastruktūrą, norint įsidiegti šią paslaugą.

Remiantis šia prielaida, toliau bus analizuojami VGĮ poreikiai.

Pacientų sveikatos prieţiūros įrašų sistema reikalauja papildomų kompiuterinių resursų

(serverių, duomenų saugyklų) ir tuo pačiu reikalingas nepertraukiamas duomenų centro veikimas.

Be to, gydymo įstaigose nuolat atliekami įvairūs tyrimai, kuriems taip pat reikalingi kompiuteriniai

ištekliai. Todėl VGĮ iškilo poreikis praplėsti savo IT infrastruktūrą, kad galėtų suvaldyti

padidėjusius informacijos srautus. Tačiau viešosios gydymo įstaigos neturi pakankamai lėšų įsigyti

po atskirą papildomą duomenų centrą kiekvienam padaliniui.

Šiuo metu kiekviena VGĮ turi po atskirą statinį duomenų centrą (ţr. 14 pav.).

40

14 pav.


Toks atskiras statinių duomenų centrų pasiskirstymas lemia neefektyvų kompiuterinių

resursų panaudojimą (ţr. 15 pav.).

15 pav. Statinio duomenų centro resursų panaudojimas


Paprastai statiniame duomenų centre lieka daug nepanaudotų resursų laiko atţvilgiu,

kadangi galia išlieka pastovi nepriklausomai nuo poreikio dydţio. Kitaip tariant, kintant poreikiui,

galia nesikeičia. Todėl kompiuteriniai resursai nėra pilnai išnaudojami.

Taigi atsiranda tokie VGĮ poreikiai:

Efektyvesnis resursų panaudojimas.

Duomenų perkėlimas į virtualią erdvę.

Pastovus prieinamumas.

Išlaidų maţinimas.

Šiame darbe bus ieškoma būdų, kaip būtų galima pasidalinti kompiuteriniais resursais

(tokiais kaip skaičiavimo, operatyviosios atminties, duomenų saugojimo), tiek tarp vienos įstaigos

41

nutolusių padalinių, tiek ir tarp visų kitų gydymo įstaigų. Tokiu atveju, padaliniams nereikėtų kurti

papildomų duomenų centrų, siekiant suvaldyti didelius skaičiavimo uţklausų kiekius. Dalijantis

skaičiavimo resursais, juos būtų įmanoma „skolintis“ iš kitų padalinių, kad iškilus poreikiui, būtų

galima suvaldyti didelį apkrautumą. „Debesų kompiuterija“ suteikia galimybę tai įgyvendinti, todėl

VGĮ norėtų gauti patarimus dėl galimų sprendimo variantų.

Reikalavimai sistemai:

Sistema kliento darbo vietoje turi būti nepriklausoma operacinės sistemos atţvilgiu.

OS suderinamumas su visais aparatiniais įtaisais.

Lanksti OS, leidţianti veikti bet kokiai pasirinktai virtualizavimo programai.

Lankstus įdiegimas.

Virtualių mašinų perkėlimas.

Tvarkyklių suderinamumas ir atnaujinimo galimybės.

Atsarginių kopijų darymo galimybės.

Resursų dalijimosi galimybės.

Sistemos kliento grafinė sąsaja turi būti realizuota interneto naršyklės pagrindu.

Taigi, sekančiame skyriuje bus projektuojami sprendimai apie tai, kaip tenkinti VGĮ

poreikius, pritaikius „debesų kompiuteriją“.

42

2. PRAKTINIS TYRIMAS

Šiame skyriuje nagrinėjami „debesų kompiuterijos“ modeliai, kad nustatyti kuris iš jų yra

tinkamiausias ir labiausiai VGĮ poreikius atitinkantis „debesies“ modelis. Toliau išsikeliami

kriterijai, reikalingi „debesų“ platformoms palyginti. Remiantis išsikeltais kriterijais, nagrinėjamos

penkios pasirinktos platformos. Rezultatai pateikiami lentelės forma (ţr. 1 lentelę), kuri parodo

skirtingų platformų galimybes. Remiantis šiais rezultatais, toliau siekiama išskirti platformą, kuri

geriausiai atitiktų VGĮ reikalavimus.

2.1. „Debesies“ modelių panaudojimas

Šiame darbe tiriamos „debesų kompiuterijos“ panaudojimo galimybės, siekiant įdiegti

bendrus skaičiavimo resursus. Jeigu pasiūlytas „debesies“ sprendimas pasirodys itin sėkmingas,

VGĮ rekomenduos šią technologiją ir kitoms viešojo gydymo įstaigoms. Tada jos visos galės

sudaryti bendrą resursų terpę, kurioje galės naudoti daugiau resursų viena iš kitos, nepirkdamos

papildomos įrangos, saugojimo vietos, energijos ir pan., o iš naujo panaudodamos duomenų

centruose esantį perteklių. Tačiau papildomai reikėtų įsivertinti ir tokį atvejį, kad ne visada gali būti

pakankamas vidinis kompiuterinių resursų kiekis (čia yra atvejis, kai visi įstaigų duomenų centrai

bus pilnai išnaudojami, pvz.: epidemijos laikotarpiu, ar atliekant sudėtingus tyrimus). Todėl ieškant

tinkamo „debesies“ sprendimo, būtina atsiţvelgti ir į tai.

Remiantis pirmo skyriaus teorine analize apie „debesų kompiuterijos“ paslaugų modelius,

galima teigti, kad SaaS modelis yra labiau tinkamas tiems, kurie ieško tik programinės įrangos kaip

paslaugos. Kitaip tariant, tai yra paslaugos tipas, kada programinės įrangos teikėjas suteikia

licenziją ar visą programą vartotojui jos pareikalavus. Vartotojas naudojasi programine įranga, bet

nevaldo operacinės sistemos, aparatinės įrangos ar tinklo infrastruktūros, kurioje visa tai

funkcionuoja. VGĮ atveju netinkamas šis modelis, nes jo atveju nėra galimybės praplėsti savo

infrastruktūros.

PaaS modelis skirtas platformų ir aplikacijų kūrimui. Todėl šis modelis nėra tinkamas,

kadangi VGĮ nepageidauja savarankiškai kurti aplikacijų ar platformų.

Išanalizavus „debesų kompiuterijos“ paslaugų modelius, nustatyta, kad VGĮ tinkamiausias

iš jų yra IaaS modelis, kadangi įstaiga pageidauja tik IT infrastruktūros plėtros. Tai reiškia, kad VGĮ

reikalinga patobulinti tik IT infrastruktūros sritį (serverius, duomenų saugyklas, tinklus). Todėl šiuo

atveju SaaS ir PaaS modeliai yra netinkami, nes jų atveju nėra galimybės valdyti savo

infrastruktūros.

43

Apţvelgus „debesų kompiuterijos“ diegimo modelius, nustatyta, kad VGĮ tinkamiausias iš

jų yra mišraus tipo „debesis“, kadangi įsidiegus tik privatų „debesį“, gali pritrūkti vien tik savo

vidinių išteklių, gaunamų iš kitų padalinių. Todėl prireikus daugiau papildomų resursų, juos būtų

galima „skolintis“ iš kitų gydymo įstaigų, turinčių privačius debesis. Tačiau, esant masiniam

pacientų antplūdţiui (pvz. gripo epidemijos laikotarpiu), gali prireikti papildomų resursų iš šalies,

nes tuo metu vidiniai gydymo įstaigų „debesys“ bus pilnai išnaudojami. Tokiu atveju, dalį

apkrautumo būtų galima perduoti į viešuosius debesis, kurie galėtų suteikti neribotus resursus.

Taigi, remiantis nustatytais „debesų“ modeliais ir VGĮ iškeltais poreikiais, toliau bus

tiriamos „debesų kompiuterijos“ platformos. Suradus tinkamą „debesies“ platformą, gydymo įstaiga

turėtų galimybę susikurti vidinį privatų „debesį“. Jei toks sprendimas sėkmingai pasiteisintų, su šia

įstaiga susijusios organizacijos taip pat galėtų jį įgyvendinti, ir tokiu būdu atsirastų galimybė

suformuoti mišrųjį „debesį“, sujungus įmonių privačius „debesis“.

2.2. Tyrimui pasirinktas metodas

Tyrimui atlikti, pasitelktas lyginamosios analizės metodas, kurio metu buvo išsikelti

kriterijai, atsiţvelgiant į VGĮ poreikius. Remiantis šiais kriterijais, toliau lyginamos pasirinktos

„debesų kompiuterijos“ platformos.

Taigi, ţemiau surašyti išsikelti kriterijai10

:

Daugialypiai „debesys“. Ar egzistuoja daugialypių „debesų“ palaikymas. Kitaip tariant, ar

įmanoma perkelti procesus į kitus privačius „debesis“ arba į viešąjį „debesį“. Šis kriterijus yra itin

svarbus VGĮ, todėl bus analizuojamas kiekvienos platformos tyrimo pradţioje.

API programų sąsaja. Įvertinama, ar tiriama platforma palaiko sudėtinį ar atvirą API

standartą.

Prieinamumo zonos. Tiriama, ar kilus poreikiui įmanoma bus izoliuoti dalį „debesies“.

Atsparumas gedimams. Ar egzistuoja techninės įrangos gedimų sprendimo būdas? Jeigu,

veikiant dvejoms tos pačios virtualios mašinos (VM) uţduotims (angl. instances) skirtinguose

fiziniuose serveriuose, vienas fizinis serveris sugenda, tai kito serverio VM turi perimti atliekamą

uţduotį, tam kad ji nenutrūktų.

Virtualių mašinų perkėlimas realiu laiku (angl. live migration). Tai yra VM

perkėlimas, kai jos vis dar veikia. Paprastai VM perkėlimas yra visada įmanomas, kai jos yra

10

Atsparumas gedimams ir Virtualių mašinų perkėlimas realiu laiku palaikymas priklauso nuo „debesų kompiuterijos“

platformos naudojamos virtualios mašinos platformos.

44

išjungtos, tačiau tiriama ar būtų galima jas perkelti į kitą fizinį įrenginį, joms vis dar veikiant. Tai

būtų itin aukšto lygio lankstumas.

Monitoringas. Ar egzistuoja galimybė, pasitelkus integruotą arba išorinę programą, atlikti

monitoringą t.y. stebėti sistemos virtualių mašinų būseną.

Resursų dydţio keitimas. Ar „debesies“ infrastruktūra galėtų prisitaikyti prie resursų

kiekio kitimo. Ar įmanoma (esant poreikiui) automatiškai padidinti arba sumaţinti resursus; ar tai

galima lengvai padaryti rankiniu būdu (kai to reikia, automatiškai išjungti arba įjungti virtualias ar

fizines mašinas).

Vartotojų administravimas. Ar įmanoma valdyti vartotojus ir jiems suteikinėti teises. Ar

tiriama platforma pasiţymi grafine vartotojo sąsaja, skirta sąveikauti su „debesiu“.

2.2.1. „AbiCloud“

„AbiCloud“ įdiegta „Sun Open Cloud“ API programų sąsaja, leidţianti susikurti

savarankišką, „debesies“ resursų valdymui skirtą programą. Naudojantis įmonėms skirta versija,

galima sujungti kelis „debesis“. Ši platforma suteikia galimybę palengvinti „debesies“ integraciją

(jungimąsi į federaciją). Tačiau „AbiCloud“ nepalaiko uţduočių perkėlimo į kitų platformų

privačius bei viešuosius „debesis“.

API „AbiCloud“ pasiţymi atviro tipo API programų sąsaja, kuri leidţia integruoti kitų

trečiųjų šalių programas. Ji naudojasi „Sun Open Cloud“ API.

Prieinamumo zonos. „AbiCloud“ suteikia vartotojams galimybę susikurti savo virtualų

duomenų centrą, esantį fiziniame duomenų centre.

Monitoringas. „AbiCloud“ turi keletą funkcijų, skirtų virtualių ir fizinių serverių

monitoringui atlikti. Be to, dėl „AbiCloud“ lankstumo, galima naudoti ir kitas monitoringo

priemones.

Resursų dydţio keitimas. Vartotojai gali keisti serverių, atminties, tinklų, virtualaus

tinklo įrenginių bei kitos įrangos dydį, ją valdyti bei automatiškai ir kada panorėję prie jos

prisijungti. „AbiCloud“ leidţia automatiškai pakeisti numatytas ribas (angl. softlimits), suteikdama

galimybę keisti infrastruktūros dydį. Gaila, kad ši platforma nepalaiko fiziniams serveriams

tiekiamos energijos valdymo.

Vartotojų administravimas. „AbiCloud“ pasiţymi itin patogia grafine vartotojo sąsaja,

sukurta, panaudojant „Adobe Flex“ programų kūrimo įrankį. Pasitelkus šią sąsają, įmanoma valdyti

visą „debesį“. „AbiCloud“ valdyti galima ir su trečiosios šalies programomis. Taip pat egzistuoja

vartotojų administravimas, kur galima jiems nustatyti teises prie galimų „debesies“ funkcijų.

Trūkumai

45

„AbiCloud“ pasiţymi tokiais trūkumais:

Ribotas duomenų centrų skaičius. Naudojantis plačiajai visuomenei skirta platformos

versija galima dirbti tik su vienu duomenų centru.

Informacija. Informaciją apie „AbiCloud“ galima rasti tik gamintojų svetainėje, todėl

buvo sunku priimti objektyvius sprendimus. Nors tai yra atviro kodo projektas, tačiau jo

bendruomenė yra labai maţa. Pastebima tik labai nedidelė dokumentais patvirtinta darbo su šiuo

produktu patirtis, kuria remiantis yra sunku nustatyti, kokia yra tikroji „AbiCloud“ vertė. Kai kurie

dokumentai ir dalis rastos informacijos yra ispanų kalba („Abiquo“ yra Ispanijos bendrovė).

Virtualių mašinų perkėlimas realiu laiku Nepalaikomas virtualių mašinų perkėlimas

realiu laiku.

Atsparumas gedimams/sistemos susikeitimas „AbiCloud“ nepalaiko šios funkcijos,

kadangi nebuvo rasta jokių apie tai patvirtinančių faktų.

Apibendrinimas

Ištyrus „AbiCloud“ platformą, pastebėta, kad ji vis dar yra kūrimo ir testavimo būsenoje,

todėl norint VGĮ pasinaudoti šia platforma, reiktų laukti jos naujesnių versijų. „AbiCloud“

platforma išsiskiria tuo, kad ji yra nepriklausoma, kadangi yra suprogramuota „Java“ programavimo

kalba.

2.2.2. „Eucalyptus“

„Eucalyptus“ yra „debesies“ architektūra, kuri palaiko tas pačias API programų sąsajas

kaip ir tokie viešieji „debesys“, kaip „Amazon“. „Eucalyptus“ yra visiškai suderinta su „Amazon

Web Service“ „debesies“ infrastruktūra. Tai pat įmanoma perkelti uţduotis į tokį viešąjį „debesį“,

kaip „Amazon EC2“ ar kitas „debesų“ infrastruktūras. Pasitelkus tokius įrankius, kaip „RightScale“,

atsiranda galimybė per web sąsają iš vienos vietos valdyti kelis skirtingus „debesis“. „Eucalyptus“

pasiţymi saugiu vidiniu ryšiu, pasiekiamu, pasitelkus SOAP (Simple Object Access Protocol)

protokolą su „WS-security“ (web paslaugų saugumu). Tačiau „Eucalyptus“ nepalaiko galimybės

uţduotis perkelti į kitus privačius (tiek tos pačios, tiek ir kitų gamintojų platformų) „debesis“.

API „Eucalyptus“ galima valdyti, pasitelkus „Amazon EC2“ API programų sąsają.

Kadangi ši platforma siūlo tas pačias funkcijas kaip ir „Amazon“, „Eucalyptus“ taip pat galima

valdyti tais pačiais įrankiais kaip ir „Amazon“.

Prieinamumo zonos. Egzistuoja galimybė susikurti „debesį“, sudarytą iš daugelio

klasterių valdiklių (CC). „Amazon“ turi galimybę kurti prieinamumo zonas, leisdama vartotojams

nustatyti, kur patalpinti turimą informaciją, o tai reiškia, kad vieni klientai negali pasiekti kitiems

klientams priklausančių „debesų“. „Eucalyptus“ bando pasiūlyti panašų modelį, bet kitomis

46

priemonėmis. Šios platformos gamintojai atskiria zonas pagal klasterius, taigi, kiekvienas klasteris

yra zona, kuri atstoja „duomenų centrą“; tuo tarpu „Amazon“ zonos yra daug platesnės.

Monitoringas. Naujausia „Eucalyptus“ versija suteikia galimybę naudotis visa, su

monitoringu susijusia informacija, tokiuose atviro kodo monitoringo įrankiuose kaip „Nagios“ ir

„Ganglia“.

Vartotojų administravimas. Naudojamas „Cloud Administrator“ įrankis, skirtas sistemos

valdymui ir vartotojų administravimui. Egzistuoja tokie virtualių mašinų valdymo įrankiai, kaip

„Elasticfox“ ir „Hybridfox“.

Trūkumai

„Eucalyptus“ būdingi šie trūkumai:

Ribotas valdiklių skaičius. Šiuo metu „Eucalyptus“ palaiko tik po vieną „debesies“ ir

„walrus“ valdiklį. Taigi, nėra galimybės turėti atsarginių „debesies“ ir „walrus“ bei klasterio

valdiklio kopijų.

„Eucalyptus“ taip pat nepasiţymi tokiomis savybėmis kaip virtualių mašinų perkėlimas

realiu laiku (angl. live migration), atsparumas gedimams ir automatinis resursų dydţio keitimas

(angl. auto scaling).

Apibendrinimas

Ištyrus „Eucalyptus“ platformą, pastebėta kad ji yra visiškai suderinta su „Amazon Web

Service“ „debesies“ infrastruktūra, todėl norint VGĮ perkelti uţduotis į viešą „debesį“, nekiltų jokių

problemų tai padaryti. Tačiau šiuo metu „Eucalyptus“ palaiko tik po vieną „debesies“ ir „walrus“

valdiklį. Taigi, nėra galimybės turėti atsarginių šių bei klasterio valdiklio kopijų. Taip pat ši

platforma nepasiţymi ypač reikalingomis VGĮ savybėmis: virtualių mašinų perkėlimas realiu laiku,

atsparumas gedimams ir automatinis resursų dydţio keitimas.

2.2.3. „OpenNebula“

„OpenNebula“ pasiţymi itin lanksčia architektūra ir sąsaja, kas suteikia galimybę

sąveikauti su kitais produktais (tokiais, kaip „Eucalyptus“, „Amazon“, „ElasticHosts“ ir „Nimbus“)

bei juos integruoti. Ji palaiko OGF11

„Open Cloud Compute Interface“ specifikaciją.

„OpenNebula“ uţduotis galima perduoti į viešuosius „debesis“, tokius kaip „Amazon

EC2“ arba „ElacticHosts“, prie kurių jie gali prisijungti. Norint pasinaudoti šia galimybe reikalinga,

kad būtų įdiegta EC2 programa „debesies“ valdiklyje (angl. Front-End). Norint perkelti uţduotis į

11

Open Grid Forum (OGF) – tai yra visuomenė, kurią sudaro vartotojai, programuotojai ir prekiautojai. Jų pagrindinis

tikslas – globalus paskirstytų skaičiavimo sistemų (angl. grid computing) standartizavimas.

47

EC2, prieš tai reikia įkelti atvaizdus (angl. images) į S3. Uţduotis taip pat įmanoma perduoti

partneriams, kurie naudojasi savo privačiu „debesiu“, kurio platforma yra „OpenNebula“.

Perkeliant uţduotis iš „OpenNebula“ į EC2 „debesis“, egzistuoja keleta apribojimų:

Kadangi vis dar nėra tiesioginio priėjimo prie „Amazon“ sistemos, todėl neįmanoma

atlikti VM monitoringą, nes nėra ţinoma, kurioje EC2 „debesies“ dalyje veikia VM.

Galima įkelti iki 20 uţduočių (angl. instances), kadangi „OpenNebula“ naudojama

EC2 API yra negalutinėje beta versijoje.

Neprieinamos momentinės kopijos (angl. snapshotting), atkūrimo (angl. restoring) ir

VM perkėlimo galimybės.

„EC2 Query“ API palaikymo galimybė leidţia valdyti „debesį“, naudojant bet kurį „EC2

Query“ įrankį, skirtą privačiam „debesiui“ pasiekti.

„OpenNebula“ palaiko „cloudbursting“, kas reiškia, kad atsiranda galimybė sukombinuoti

jau egzistuojančią infrastruktūrą su „debesies“ infrastruktūra.

API „OpenNebula“ yra suderinta su „Amazon EC2“ sąsaja. Ši platforma taip pat palaiko ir

sąsajas iš kliento pusės. Joje įdiegta „EC2 Query“ API ir OGC OCCI API, skirta „debesies“

vartotojo sąsajai. „OpenNebula“ yra lanksti tuo, kad ji leidţia įdiegti kitas „debesies“ sąsajas arba

suteikia galimybę susikurti savo sąsają.

Prieinamumo zonos. Su „OpenNebula“ galima valdyti „Amazon EC2“ prieinamumo

zonas. „OpenNebula“ 1.4 versijoje egzistuoja galimybė izoliuoti vietas EC2, per kurias

„OpenNebula“ gali kontroliuoti EC2 prieinamumo zonas arba naudoti kitus privačius per EC2

sąsają teikiamus „debesis“.

Atsparumas gedimams. Atsparumą gedimams valdo galinio proceso etapo (angl. back-

end) duomenų bazė, kurioje saugomi pagrindiniai kompiuteriai ir jų virtualių mašinų (VM)

informacija. Visi VM atvaizdai (angl. images) yra saugomi „OpenNebula“ pradinio proceso etape

(angl. Front-End) t.y. branduolyje. Startavus fiziniam įrenginiui, sukuriamas jo VM atvaizdas, kurio

atsarginė kopija perkeliama į klasterio mazgą (angl. cluster node). Sutrikus įrenginio darbui,

klasterio mazgas paleidţia atsarginę VM. Kai atvaizdas tampa nenaudojamu, jis perkeliamas atgal į

VM saugyklą.

Virtualių mašinų perkėlimas. „OpenNebula“ palaiko virtualių mašinų perkėlimą realiu

laiku, jei joje įdiegta „Shared“ tipo failų sistema (FS). Veikdama kartu su „Shared FS“,

„OpenNebula“ platforma suteikia galimybę pasinaudoti visais VM platformų privalumais (pvz.

perkeliant atvaizdą, nebūtina išjungti VM). „OpenNebula“ gali veikti ir be „Shared FS“. Bet tada

reikės pastoviai kurti atsargines vaizdų kopijas, kurias bus galima perkelti tik išjungus VM.

48

Monitoringas. Centralizuotas branduolys gali atlikti monitoringą bei valdyti virtualias

mašinas ir fizinius serverius.

Resursų dydţio keitimas. Egzistuoja dinaminis fizinės infrastruktūros dydţio keitimas.

Resursų dydţio keitimas nėra visiškai automatizuotas, tačiau yra galimybė lengvai išplėsti ar

sumaţinti „debesį“.

Vartotojų administravimas. „OpenNebula“ platforma nėra platinama kartu su grafine

vartotojo sąsaja. Ši platforma platinama su komandinių eilučių sąsaja. Ji palaiko prisijungimo prie

virtualių mašinų ir virtualių tinklų teisių administravimą.

Trūkumai

„OpenNebula“ pasiţymi tokiais trūkumais:

Grafinė vartotojo sąsaja. „OpenNebula“ neplatinama kartu su grafine vartotojo sąsają,

nors ir palaiko „EC2 Query API“.

Ribotas „debesies“ valdiklių skaičius. Neįmanoma padaryti atsarginės „debesies“

valdiklio (angl. front-end) kopijos. Taigi, jeigu serveris su „debesies“ valdikliu atsijungtų, visi

mazgai (angl. node) veiktų ir toliau, tačiau jų nebūtų galima valdyti tol, kol neveiktų „debesies“

valdiklis. Vis dėl to „OpenNebula“ pasiţymi itin gera atkūrimo (angl. recovery) procedūra, taigi,

pradėjus veikti „front-end“ viskas atsistato į pradinę (normalaus veikimo) būseną.

Ribotas EC2 uţduočių skaičius „OpenNebula“ savo uţduotis gali perkelti į viešuosius

EC2 „debesis“. Kadangi EC2 1.4 versija vis dar yra beta, tai vienu metu daugiausiai įmanoma

įjungti tik dvidešimt uţduočių (angl. instances). Be to, perkėlus uţduotis į EC2, prarandamos tokios

funkcijos kaip: momentinės kopijos, atkūrimas ar VM perkėlimas.

Apibendrinimas

Ištyrus „OpenNebula“ platformą, nustatyta, kad norint gydymo įstaigoms perkelti uţduotis

į kitą „debesį“, geriausia rinktis „OpenNebula“ 1.4, nes ši platforma puikiai palaiko perkėlimo į kitą

„debesį“ galimybę. „OpenNebula“ pasiţymi itin lanksčia architektūra ir sąsaja, kas suteikia VGĮ

galimybę sąveikauti su kitais produktais (tokiais, kaip „Eucalyptus“, „Amazon“, „ElasticHosts“ ir

„Nimbus“) bei juos integruoti. Mišriuose „debesyse“ „OpenNebula“ palaiko „Amazon EC2“ ir

„ElasticHosts“ jungtis. Šios savybės suteikia galimybę sukurti keičiamo dydţio aplinką

(infrastruktūrą). Tačiau ši platforma nepasiţymi atsarginiu „debesies“ valdikliu (angl. Front-End),

todėl ji neatitinka nepertraukiamo prieinamumo „debesies“ platformą.

2.2.4. „OpenQRM“

„OpenQRM“ palaiko „Amazon EC2 API“ suderintuvą, kuris leidţia sukurti mišrųjį

„debesį“, kad perkelti uţduotis į „Amazon EC2“.

49

API Kaip minėta anksčiau, „OpenQRM“ palaiko „Amazon EC2 API programų sąsają“.

Atsparumas gedimams. „OpenQRM“ palaiko „N to 1“ sistemos susikeitimą (angl. fail-

over). Tai reiškia, kad N pastoviai veikiantiems serveriams yra reikalingas tik vienas atsarginis

serveris. Dėl to reikia N – 1 serverių maţiau. Taigi, norint turėti pastovią ir nenutrūkstančią

„debesies“ aplinką, reikalingas tik vienas (arba keli) papildomi serveriai vietoj kiekvienam pastoviai

veikiančiam serveriui po atskirą atsarginį.

Egzistuoja galimybė išsaugoti visus atsarginius serverius ir paversti virtualią mašiną kaip

atsargine. Iškilus problemai, pastoviai veikiantys prietaisai persijungs iš fizinių į virtualius.

Sistemoje taip pat galima sukeisti virtualizacijos technologiją A su technologija B (pvz.: KVM su

„VMware“ VM).

Virtualių mašinų perkėlimas. „OpenQRM“ palaiko įvairius mašinų perkėlimo realiu

laiku variantus. Taip pat įmanoma perkelti serverio įrangą iš vieno virtualizacijos modelio į kitą.

Tokia galimybė perkėlimą paverčia labai lanksčia šios platformos funkcija:

Fizinių įrenginių perkėlimas į virtualias mašinas.

Virtualių mašinų perkėlimas į fizinius įrenginius.

Virtualių mašinų perkėlimas į virtualias mašinas.

Monitoringas. Pilnai automatizuota „Nagios“ konfigūracija (įjungiama vienu

paspaudimu), skirta sistemos ir paslaugų monitoringui atlikti.

Resursų dydţio keitimas. „OpenQRM“ palaiko automatinį resursų dydţio keitimą,

pasitelkiant fizinių serverių energijos valdymo papildinį.

Vartotojų administravimas. „OpenQRM“ pasiţymi vartotojams itin patogia web sąsaja.

Ji vadinama „Duomenų centro valdymo skydu“ (angl. „Datacenter Dashboard“).

Trūkumai

„OpenQRM“ pasiţymi tokiais trūkumais:

Prieinamumo zonos. Dokumentai nepateikia jokios informacijos apie prieinamumo zonas;

taigi, galima teigti, kad ši platforma jų nepalaiko.

Ribota dokumentacija. Galima perţiūrėti tik ribotą svarbių dokumentų kiekį.

„OpenQRM“ gamintojai daugiausia dėmesio skiria savo bendro pobūdţio produktams, taigi,

prisijungti prie „debesų“ įmanoma, tik pasitelkus specialius papildinius. Tačiau apie tai randama tik

nedaug tą patvirtinančių dokumentų.

Apibendrinimas

Ištyrus „OpenQRM“ platformą, nustatyta, kad norint VGĮ turėti lanksčią atviro kodo

infrastruktūrą, patartina įsidiegti būtent šią platformą. Tačiau prieš tai reikėtų įsivertinti kokie

papildiniai yra palaikomi ir ar jie visi atitiks įmonės iškeltus reikalavimus. Šios platformos

50

architektūra pasiţymi sparčiu, automatizuotu prietaisų diegimu, monitoringu, prieinamumo

zonomis, ir ypač gerai prisitaiko prie daugelio virtualizacijos modelių. Tačiau pati platforma neturi

savo sukurtų įrankių, kuriais galėtų pasinaudoti galutiniai vartotojai (ji naudoja tik tarpinę

programinę įrangą). „Debesies“ diegimui naudojami įrankiai pasitelkiami kaip papildiniai, kurie ir

atlieka pagrindines funkcijas. „OpenQRM“ labiau orientuojasi į duomenų centrų valdymą (ypač

klasterių valdymą), o ne į patį „debesų kompiuterijos“ funkcionalumą.

2.2.5. „VMware vSphere“

Pasitelkus „vCloud“ įrankį, „vSphere“ gali palaikyti ryšį su keliais „debesimis“, tačiau

reikia uţtikrinti, kad „vCloud“ veiktų kiekviename „debesies“ duomenų centre. Uţduočių

perkėlimas į viešuosius „debesis“ yra labai ribotas: tik keli „debesies“ teikėjai suteikia galimybę

uţduotis perkelti iš „VMware vSphere“.

Pagrindinės „vSphere“ funkcijos ir savybės pateikiamos platformos architekūros dalyje,

todėl toliau bus išvardintos tik tos kurios nebuvo paminėtos.

API „vSphere“ pasiţymi daug funkcijų turinčia valdymo „konsole“. Taip pat turi galimybę

prasiplėsti su trečios šalies API programų sąsajomis.

Prieinamumo zonos. Tiek įmonėms, tiek ir įmonėms paţangi skirtos versijos suteikia

galimybę sukurti izoliuotas resursų terpes (angl. isolated resource pool).

Atsparumas gedimams. „vCenter“ serveris kontroliuoja šią „debesies“ funkciją.

Virtualių mašinų perkėlimas. „vMotion“ leidţia virtualias mašinas perkelti iš vieno

fizinio įrenginio į kitą, net ir tuo atveju, jei virtuali mašina vis dar veikia.

Monitoringas Šios platformos suteikiamos kontrolės galimybės leidţia perţvelgti fizinio

arba virtualaus serverio skaičiavimų apkrovą.

Resursų dydţio keitimas Paskirstytų išteklių planuoklis (DRS) suteikia galimybę serverio

apkrovą automatiškai paskirstyti per visus resursus.

Vartotojų administravimas „vSphere“ pasiţymi „vSphere“ programine įranga, skirta

serverių darbui reguliuoti ir gali būti įdiegta skirtinguose kliento įrenginiuose. Viena kliento įranga

gali būti sujungta su keliais duomenų centrais, skirtais visiems virtualiems serveriams valdyti.

Trūkumai

„VMware vSphere“ pasiţymi tokiais trūkumais:

Ribotas serverių skaičius viename klasteryje Nepaisant visų naudingų funkcijų ir

savybių, „vSphere“ pasiţymi ir keletu trūkumų. Nepertraukiamo prieinamumo klasterį gali sudaryti

daugiausiai 32 pagrindiniai serveriai (angl. hosts). Dideliuose duomenų centruose tai gali būti

problema, kurią reikėtų įsivertinti.

51

Sudėtiniai „debesys“ Tik labai nedidelė paslaugų teikėjų dalis suteikia galimybę naudotis

„vCloud“ ir tokiu būdu perkelti uţduotis į viešuosius „debesis“. Taigi, ši galimybė yra labai ribota.

Perkėlus uţduotis į viešą „debesį“, prarandama nepertraukiamo prieinamumo funkcija.

Apibendrinimas

Ištyrus „vSphere“ platformą, pastebėta, kad ji reikalinga VGĮ norint sukurti privatų,

vidiniam naudojimui skirtą „debesį“. „vSphere“ pasiţymi daugiau funkcijų nei kitos platformos,

įskaitant nepertraukiamą prieinamumą, virtualių mašinų perkėlimą realiu laiku bei kitas VGĮ itin

naudingas savybes. Tačiau reikėtų atkreipti dėmesį, kad susikūrus šios platformos vidinį „debesį“,

praktiškai neįmanoma (arba yra labai ribotos galimybės) perkelti uţduotis į viešuosius „debesis“.

2.3. Platformų lyginamoji analizė

Ţemiau pateiktoje lentelėje (ţr. 4 lentelę) apibendrinamos visos tirtų „debesies“ platformų

savybės. Lentelė sudaryta iš keturių dalių. Pirmoje lentelės dalyje nurodyti diegimo modeliai – tai

yra pagrindiniai VGĮ ir šio tyrimo keliami reikalavimai. Toliau seka platformos prieinamumo12

galimybės – tai yra itin svarbi savybė, siekiant atsirinkti tinkamiausią platformą. Sekanti lentelės

dalis susitelkia ties platformų siūlomomis funkcijomis, kurios atliekamos pasitelkiant jų valdymo

įrankius.

12

Prieinamumas (angl. availability) orientuojasi į platformos stabilumą ir nenutrūkstamą veikimą.

52

4 lentelė

abiCloud

1.0.0-RC3

Eucalyptus 1.6.1 OpenNebula 1.4 openQRM 4.6 VMware

vSphere 4

Išsidėstymas

Privatus „debesis“ Taip Taip Taip Taip Taip

Uţduočių perkėlimas į

kitą privatų „debesį“

(tos pačios platformos)

Taip Ne Taip Taip Taip


kitą privatų „debesį“

(kitos platformos)

Ne Ne Eucalyptus &

UEC

Eucalyptus &

UEC Ne


viešą „debesį“ Ne Taip Taip Taip Ribotas

Prieinamumas

Atsarginis „debesies“

valdiklis (front-end) Taip Ne Ne Taip Taip

Atsparumas gedimams Ne Ne Taip Taip Taip

Funkcijos

Prieinamumo zonos Taip Taip Taip Ne Taip

Resursų dydţio

keitimas Rankinis Rankinis Dinaminis Taip Automatinis

Virtualių mašinų

perkėlimas realiu laiku Ne Ne

Tik su „Shared

FS“ (SAN/-NAS) Ne

Tik su „Shared

FS“ (SAN/-NAS)

Valdymas

API programų sąsaja Sun Open

Cloud EC2

EC2 & OGC

OCCI EC2 vCloud

Vartotojų

administravimas Web sąsaja Web sąsaja 3-ios šalies sąsaja Web sąsaja Taip

Monitoringas

Integruotas Palaikoma 3-ių

šalių

Palaikoma 3-ių

šalių

Integruotas

„Nagios“

Integruotas (taip

pat palaikoma 3-

ių šalių)

Kaip matome iš pateiktos lentelės (ţr. 4 lentelę), privataus tipo „debesies“ kūrimą palaiko

visos nagrinėtos platformos, tačiau labiausiai iš jų pritaikytos yra „AbiCloud“ ir „VMware

vSphere“, o pastaroji uţima lyderio poziciją, kadangi „WMware“ yra viena iš pirmaujančių

virtualizacijos produktų gamintojų. Tuo tarpu uţduočių perkėlimą į kitą (tiek tos pačios, tiek ir kitos

platformos) privatų „debesį“ „Eucalyptus“ platforma nepalaiko. Ši platforma uţduotis perkelti gali

tik į viešuosius „debesis“. Į kitos platformos („Eucalyptus“ ir „UEC“) privatų „debesį“ perkelti

uţduotis gali tik „OpenNebula“ bei „OpenQRM“, tačiau pastaroji vis dar yra kūrimo būsenoje.

Lyginant uţduočių perkėlimą į viešuosius „debesis“, pastebima, kad šios funkcijos visai nepalaiko

tik „AbiCloud“. Tuo tarpu „vSphere“ platformos galimybė perkelti uţduotis į viešuosius „debesis“

yra labai ribota.

Kitas labai svarbus kriterijus yra prieinamumas prie „debesies“. Šiuo funkcionalumu

nepasiţymi „Eucalyptus“ platforma, kadangi ji turi tik vieną „debesies“ valdiklį ir nesuteikia

galimybės pasidaryti atsarginės valdiklio kopijos bei nėra atspari gedimams. „AbiCloud“ taip pat

53

nėra atspari gedimams, nors ir turi atsargines „debesies“ kopijas. „OpenNebula“ atspari gedimams,

tačiau nepasiţymi atsarginiu „debesies“ valdikliu. Tuo tarpu „OpenQRM“ ir „vSphere“ palaiko

pastovų prieinamumą prie „debesies“. Pagrindinis skirtumas tarp šių dviejų platformų yra toks, kad

„vSphere“ turi savo įrankius pastoviam prieinamumui palaikyti, o „OpenQRM“ reikalauja

papildinių.

Prieinamumo zonas palaiko visos platformos, išskyrus „OpenQRM“. Resursų dydţio

keitimo funkciją palaiko visos platformos, tačiau vienos automatiniu, kitos rankiniu būdu.

„AbiCloud“ ir „Eucalyptus“ resursų dydį reguliuoja rankiniu būdu. Tuo tarpu „OpenNebula“

pasiţymi galimybe naudotis tiek savo, tiek ir trečios šalies programomis, skirtomis reguliuoti

resursus. Automatiniu būdu resursus valdo tik „vSphere“ platformos įrankiai.

Virtualių mašinų perkėlimą realiu laiku palaiko tik „OpenNebula“ ir „vSphere“ platformos.

EC2 API programų sąsają palaiko „Eucalyptus“, „OpenNebula“ bei „OpenQRM“

platformos. Tuo tarpu „AbiCloud“ naudoja Sun Open Cloud sąsają, o „vSphere“ vCloud API.

„OpenNebula“ iš visų platformų išsiskiria tuo, kad papildomai palaiko OGC OCCI API ir

sekančioje versijoje ţada palaikyti vCloud API.

„AbiCloud“, „Eucalyptus“ bei „OpenQRM“ vartotojų prieigai prie „debesies“ naudoja web

sąsają. „OpenNebula“ reikalauja trečios šalies grafinės vartotojo sąsajos, nes pati palaiko tik

komandinių eilučių sąsają. Tuo tarpu „vSphere“ turi savo grafinę vartotojo sąsają.

Monitoringo funkcija integruota „AbiCloud“, „OpenQRM“ bei „vSphere“ platformose, o

pastaroji papildomai palaiko galimybę įsidiegti ir trečios šalies monitoringo programą.

„Eucalyptus“ ir „OpenNebula“ neturi savyje monitoringo funkcijos, todėl reikalauja trečios šalies

programų.

Taigi, pagrindinė šios palyginamosios analizės išvada yra tokia, kad nėra nė vienos

platformos, kuri galėtų perkelti uţduotis tiek į privatų, tiek ir į viešąjį „debesis“ bei kartu

pasiţymėtų nepertraukiamo prieinamumo (atsarginiu „debesies“ valdikliu (angl. Front-End))

funkcija. Tačiau labiausiai atitinkanti išsikeltus kriterijus yra „OpenNebula“ platforma, kuri

pasiţymi tiek privačiojo, tiek ir mišriojo „debesio“ įdiegimo galimybe, o taip pat ji yra atviro kodo.

„OpenNebula“ leidţia paskirstyti resursus tarp skirtingų „debesų“ ir pasiţymi kitomis naudingomis

savybėmis, kurios suteikia galimybę šią platformą įvardyti kaip geriausią. Naudojantis

„OpenNebula“, įmanoma sukurti privatų „debesį“; be to, ši platforma gali uţmegzti ryšį su kitomis

(privačių) „debesų“ platformomis ir taip suteikia galimybę duomenis paskirstyti tarp „debesų“.

Sujungus „OpenNebula“ su „Amazon EC2“ API, atsiranda galimybė kompiuterinį krūvį perkelti į

viešąjį „debesį“. Tuo tarpu kitos platformos (tokios kaip „OpenQRM“ ir „vSphere“) taip pat palaiko

šias savybes, bet gana ribotai, palyginus su „OpenNebula“, kuri papildomai pasiţymi ir tokiomis

54

svarbiomis savybėmis, kaip virtualių mašinų perkėlimas realiu laiku bei atsparumas gedimams,

kurios nebuvo būdingos kitoms platformoms. „OpenNebula“ yra suderinta su „Eucalyptus“

platforma, todėl nebūtina visom įstaigom įsidiegti tik „OpenNebula“. Taip pat kuriamas ir šios

platformos „vCloud“ API palaikymas, todėl artimiausioje ateityje „OpenNebula“ bus galima derinti

ir su „vSphere“.

Šios savybės yra būtinos VGĮ, kad galėtų stabiliai funkcionuoti jos mišrusis „debesis“.

Tačiau tai nereiškia, kad „OpenNebula“ yra geriausia visais atvejais, nes kitos platformos pasiţymi

savybėmis, kurios kitomis aplinkybėmis galėtų būti ypatingai svarbios. Šiuo metu „debesų

kompiuterija“ yra palyginti naujas ir vis dar besivystantis reiškinys, todėl visos platformos vis dar

pasiţymi daugybe trūkumų. Taigi, toliau bus siekiama suformuluoti pasiūlymus ir rekomendacijas

kaip būtų galima sukurti VGĮ mišrųjį „debesį“, pasitelkus „OpenNebula“ platformą bei ją

patobulinus.

55

3. PROTOTIPO PROJEKTAS

Šiame skyriuje pateikiamas prototipo projektas, kurio metu suformuojamas konkretus

siūlymas nagrinėjamai įmonei. Čia sudaromas VGĮ „debesies“ modelis, pritaikant jam atitinkamą

platformą ir įrankius. Toliau pateikiama modelio procesų diagrama bei pasiūloma keletas galimų

patobulinimų.

3.1. Diegimas

Ištyrus ir palyginus pasirinktas „debesų kompiuterijos“ platformas, toliau formuluojami

pasiūlymai ir rekomendacijos VGĮ iškeltiems reikalavimams realizuoti. Kadangi tarp ištirtų

platformų neatsirado tokios, kuri atitiktų visus VGĮ poreikius, rekomenduojama taikyti atskirus

panaudojimo scenarijus.

Visų pirma, VGĮ reikėtų susikurti privatų „debesį“, pasitelkiant „OpenNebula“ platformos

architektūrą bei jos įrankius. Tuo tarpu duomenų centrų virtualizavimui, rekomenduojama naudoti

„VMware“ ESX/ESXi virtualių mašinų platformą, kadangi ji labiausiai išsiskyrė iš kitų platformų

savo funkcionalumu, kuriant privatų debesį.

Antra, įkurti bendrijos „debesį“, kurį sudarytų kiti viešojo gydymo įstaigų privatūs

„debesys“, naudojantys tą pačią „OpenNebula“ arba „Eucalyptus“ platformą, nes šios dvi

platformos yra atviro kodo bei pasiţymi tarpusavio sąveika. Čia svarbu, kad kiekviena „debesies“

sistemos įmonė paskirtų šiek tiek fizinės techninės įrangos, kad kartu naudojantis visais resursais,

jos galėtų sukurti bendrą aplinką. Ši resursų terpė gali būti naudojama labai skirtingais tikslais.

Visos susijusios šalys savo įrangoje turėtų įdiegti „OpenNebula“ mazgų valdiklius (angl.

OpenNebula Node Controllers), o viena iš šalių privalėtų valdyti „OpenNebula“ „debesies“ valdiklį

(angl. Front-End). Taigi, viena iš šalių turėtų būti atsakinga uţ bendrijos „debesį“, nes galimas tik

vienas „debesies“ valdiklis (angl. Front-End). Šalys taip pat turėtų susiderinti prieigą prie šio

„debesies“ valdiklio.

Trečia, sukurti mišrųjį „debesį“, pasitelkiant „OpenNebula“ platformą. Tada VGĮ turėtų ne

tik privatų „debesį“, bet ir galėtų perduoti uţduotis į viešuosius „debesis“, pasitelkiant „Amazon“

įrankius, kuriuos palaiko „OpenNebula“. Tokiu atveju VGĮ turėtų lanksčią infrastruktūrą, kurią

galėtų praplėsti ar sumaţinti bet kuriuo metu, neįdedant į tai per daug pastangų (ţr. 16 pav.).

56

16 pav. VGĮ „debesies“ modelis


Taigi, toks VGĮ „debesies“ modelis uţtikrina neribotus resursus, kadangi įstaiga

neapsiriboja tik savo privačiu „debesiu“. Ji gali jungtis su kitų įstaigų privačiais „debesimis“ bei

prireikus dar daugiau papildomų resursų, turi galimybę kreiptis į viešuosius „debesis“, kurie gali

suteikti neribotus resursus.

Ţemiau pateikiama VGĮ „debesies“ modelio procesų diagrama (ţr. 17 pav.).

57

17 pav. VGĮ „debesies“ modelio procesų diagrama. Šaltinis: sudaryta autoriaus

Procesas prasideda nuo to, kai VGĮ „debesies“ vartotojas pareikalauja kompiuterinių

resursų, siųsdamas uţklausą į privatų „debesį“. Tada sistema ieško laisvų resursų padalinyje A ir jei

58

suranda, tuomet juos parezervuoja ir toliau tikrina ar pakanka tų parezervuotų resursų. Jei

nepakanka, tada toliau sistema kreipiasi į padalinį B, ieškodama ten papildomų resursų ir t.t. vyksta

procesas iki N padalinių. Jeigu sistema nesuranda pakankamai resursų vidiniame VGĮ „debesyje“,

tuomet papildomų laisvų resursų ieško kitame viešojo sektoriaus privačiame „debesyje“. Paieškos

procesas vyksta analogiškai kaip ir VGĮ privačiame debesyje. Jei sistema nesuranda laisvų resursų

ir kituose privačiuose „debesyse“, tuomet išeinama į viešuosius „debesis“, kur yra neriboti resursai,

uţ kuriuos moki tik tiek, kiek jų naudoji.

Taigi, pritaikius VGĮ „debesies“ modelį, turėtų sumaţėti nepanaudotų resursų kiekis,

lemiantis efektyvesnį jų išnaudojimą (ţr. 18 pav.).

18 pav. Resursų panaudojimas statinio duomenų centro (kairėje) ir duomenų centro esančio

„debesyje“ (dešinėje) palyginimas


VGĮ „debesyje“ sukurta resursų terpė juos panaudoja tik esant poreikiui. Taigi, galima

teigti, kad perkėlus VGĮ duomenų centrus į „debesį“ turėtų sumaţėti nepanaudotų resursų kiekis,

lyginant su statiniu duomenų centru, kadangi galia kinta kartu su poreikiu.

3.1.1. Problemos ir apribojimai

Norint VGĮ kartu su kitomis gydymo įstaigomis paleisti savo mišrųjį „debesį“, iškyla

problemos dėl tam tikrų valdymo aspektų:

Uţduočių perkėlimo valdymas. Reikia atkreipti dėmesį, kad perkeliant uţduotis į kitus

„debesis“, informacija „nuteka“ uţ organizacijos duomenų centro ribų. Taigi, norint apsaugoti

konfidencialią informaciją, ją reikėtų saugoti savo duomenų centro viduje. Siekiant šio tikslo, reikia

nurodyti, kurios virtualios mašinos yra prioritetinės, o kurios ne, kad sistema ţinotų, kurias uţduotis

galima perkelti.

59

Saugumo strategija. VGĮ turi nuosavą saugumo politiką. Tačiau siekiant išvengti

suderinamumo problemų, VGĮ ir kitos šalys privalo pasirūpinti reikiamu mišriojo „debesies“

saugumo lygiu.

„Debesies“ valdymas. Tokios priemonės, kaip „Haizea“ gali padėti rezervuoti ir tam

tikram momentui atidėti turimus resursus. Svarbu, kad visi vidaus naudojimui skirti resursai būtų

atidedami laiku ir jokios kitos šalys negalėtų jais pasinaudoti. Tokiu būdu, šalys netrukdytų viena

kitai.

Pasiūlymai kaip patobulinti „OpenNebula“

Šiame skyriuje siūlomos papildomos galimybės, kurios galėtų būti naudingos VGĮ, norint

patobulinti „OpenNebula“ platformą.

Tinklas. Siekiant išvengti galimų tinklo kompromisų tarp virtualių mašinų,

rekomenduojama pasitelkti IEEE 802.1Q protokolą, skirtą naudotis virtualiais vietiniais tinklais

(angl. VLAN – Virtual Local Area Networks). „OpenNebula“ platforma suteikia infrastruktūrą,

skirtą virtualių mašinų LAN kūrimui. Taigi pasinaudojus virtualaus tinklo izoliavimu, įmanoma

patalpinti bet kokią tinklo paslaugą, pvz.: DHCP serverį, kiekvienam virtualiam tinklui leidţiantį

suteikti originalų IP adresų intervalą.

Vartotojo sąsaja. „OpenNebula“ „Cloud API“ sąsaja sąveikauja kartu su „Amazon EC2

Query“ web paslauga (Amazon EC2 Query web service). Ši paslauga įdiegiama pradiniame kliento

įrenginyje (angl. Front-End). Taigi per šią bendrą sąsają galima naudotis bet kuriuo „EC2 Query“

įrankiu ar paslauga, skirta prisijungti prie privataus „debesio“. Pagal nutylėjimą „EC2 Query“

paslauga veikia, esant įprastam HTTP ryšiui. Taigi norint įdiegti papildomą saugumą,

rekomenduojama pasitelkti SSL protokolą. Tam įgyvendinti, reikalingi tokie nustatymai:

SSL sertifikatas.

SSL skirtas įgaliotasis HTTP serveris.

Sukonfigūruoti „EC2 Query“ paslaugas taip, kad priimtų įgaliotojo serverio

siunčiamas uţklausas.

Taigi, pasitelkus SSL sertifikatą, galima uţtikrinti saugų ryšį su savo „OpenNebula“

„debesiu“.

Procesų planavimas (angl. scheduling). Norint pagerinti „OpenNebula“ procesų

planavimą, rekomenduojama papildomai įsidiegti „Haizea“ platformą. „Haizea“ gali praplėsti

„OpenNebula“ procesų planavimo galimybes, nes ši architektūra palaiko išplėstinį (angl. advanced)

resursų rezervavimą ir eilių sudarymą (angl. queuing). Taigi išjungus „OpenNebula“ resursų

planuoklį galima nesudėtingai jį pakeisti į „Haizea“. Šios platformos papildo viena kitą, kadangi

„OpenNebula“ suteikia reikiamą valdymo įrangą (pasitelkus „VMware“, „OpenNebula“ gali valdyti

60

XEN ir KVM virtualias mašinas viename klasteryje), o „Haizea“ uţtikrina tinkamą procesų

veikimą.

Daugelio EC2 vietų palaikymas. Siekiant perkelti uţduotis į kitus „debesis“,

rekomenduojama „debesies“ valdiklyje (angl. Front-End) paleisti EC2 suderintuvą (angl. adapter).

Jeigu uţduotis reikia perkelti tik į „OpenNebula“ mazgus (angl. node), reikalinga papildomai įdiegti

OCCI suderintuvą. Svarbu įsitikinti, kad EC2 suderintuvas būtų įdiegtas tik „debesies“ valdiklyje

(angl. Front-End).

Norint įdiegti uţduočių perkėlimo į viešuosius „debesis“ galimybę, reikia turėti veikiančią

AWS (Amazon Web Service) paskyrą bei būti uţsiregistravus EC2 ir S3 paslaugoms gauti.

3.2. Tolimesni tyrimai

Ieškant medţiagos apie „debesų kompiuterijos“ platformas, labiausiai trūko informacijos

apie skirtingų platformų tarpusavio sąveikos, stabilumo ir saugumo bandymus, kadangi gamintojai

tikisi „parduoti“ produktus, taigi, neigiami aspektai nebuvo akcentuojami. Reikia tikėtis, kad

netrukus kiti šaltiniai (trečiosios šalys/nešališkos institucijos) pateiks daugiau informacijos,

bandymų rezultatų ir atsiliepimų apie šias platformas. Todėl tolimesniuose tyrimuose

rekomenduojama susikurti testavimo aplinką, kad būtų galima atlikti eksperimentinius tyrimus t.y.

įsidiegti platformą, paskui sukonfigūruoti ją, ir galiausiai pratestuoti.

Taigi, norėdama įgyvendinti pasiūlytus sprendimus, VGĮ pirmiausia turėtų susikurti

demonstracinę aplinką, kurioje būtų galima nuodugniau ištirti visas platformos funkcijas.

61

IŠVADOS

Apţvelgus „debesų kompiuterijos“ paslaugų modelius, nustatyta, kad VGĮ tinkamiausias iš

jų yra IaaS modelis, kadangi jis pasiţymi IT infrastruktūros kūrimo galimybe „debesyse“.

Apţvelgus „debesų kompiuterijos“ diegimo modelius, nustatyta, kad VGĮ tinkamiausias iš

jų yra mišraus tipo „debesis“ modelis, kadangi jis suteikia galimybę turėti lanksčią infrastruktūrą

bei neribotus resursus.

Atlikta „debesų kompiuterijos“ panaudojimo galimybių analizė parodo su kokiais

reikalavimais susiduria VGĮ konkrečiu atveju; privataus „debesies“ atveju keliama maţiausiai

reikalavimų, kadangi jis yra įmonės viduje. Tuo tarpu mišraus tipo „debesis“ apima visus

reikalavimus, kadangi jis sudarytas iš privataus ir viešo tipo „debesų“ kombinacijos. Taip pat šios

analizės metu nustatyta, kad norint garantuoti funkcinį suderinamumą, integraciją ir mobilumą, VGĮ

reikalinga standartizuoti reikalavimus, keliamus mišraus tipo „debesiui“. Tam, kad šie reikalavimai

būtų standartizuoti, būtina pasitelkti atvirus standartus.

„Debesų“ platformų tyrimui pritaikytas lyginamosios analizės metodas parodė kuri

platforma geriausiai atitinka VGĮ iškeltus reikalavimus. Taikant šį metodą, išsikelti kriterijai pagal

kuriuos buvo lyginamos pasirinktos platformos.

Ištyrus ir palyginus pasirinktas „debesų kompiuterijos“ platformas, nustatyta, kad nėra nė

vienos platformos, kuri galėtų perkelti uţduotis tiek į privatų, tiek ir į viešąjį „debesis“ bei kartu

pasiţymėtų nepertraukiamo prieinamumo (atsarginiu „debesies“ valdikliu (angl. Front-End))

funkcija. Tačiau pagal išsikeltus kriterijus, labiausiai atitiko „OpenNebula“ platforma, pasiţyminti

tiek privataus, tiek ir mišraus „debesies“ įdiegimo galimybe bei kitomis VGĮ naudingomis

savybėmis.

Sudarytas ir pasiūlytas „debesies“ modelio prototipo projektas, skirtas VGĮ IT

infrastruktūros plėtrai bei efektyviam išnaudojimui. Taip pat numatyta tolimesnė tyrimo eiga.

62

LITERATŪROS SĄRAŠAS

1. P. Mell and T. Grance. The NIST Definition of Cloud Computing. URL

http://csrc.nist.gov/groups/SNS/cloud-computing/cloud-def-v15.doc

2. The art of Service. Cloud Computing – The Complete Cornerstone Guide to Cloud

Computing Best Practices. 2009.

3. G. Reese. Cloud Application Architectures. Leidykla – „O„Reilly“. 2008.

4. B. Haley. Cloud Computing Best Practices : for Managing and Measuring Processes for On-

demand Computing, Applications and Data Centers in the Cloud With SLAs. 2008.

5. http://www.abicloud.org/display/abiCloud/Home. AbiCloud home page. Last visited: March

12, 2010.

6. http://abicloud.s3.amazonaws.com/latest/AbiCloud.Technical.Overview-1.0.pdf. Abiquo -

Community Abicloud. Last visited: March 11, 2010.

7. http://esp.sam.lt/Informacija/&Language=lt_LT. Informacija apie projektą „E.sveikatos

paslaugos“. Last visited: May 13, 2010.

8. http://www.vmware.com/appliances/getting-started/learn/ovf.html. Open Virtualization

Format. Last visited: April 6, 2010.

9. http://blog.abiquo.com/category/uncategorized/. Abiquo – OVF. Last visited: March 13,

2010.

10. http://www.abicloud.org/display/abiCloud/Abicloud+Server+Live+Installers. AbiCloud test

servers. Last visited: March 13, 2010.

11. http://open.eucalyptus.com. Eucalyptus Open source. Last visited: April 20, 2010.

12. D. Nurmi, R. Wolski, C. Grzegorczyk, G. Obertelli, S. Soman, L. Youse, D. Zagorodnov.

The Eucalyptus Open-source Cloud-computing System. URL

http://open.eucalyptus.com/documents/ccgrid2009.pdf

13. http://eucalyptus.com/. Eucalyptus Open-Source Cloud Computing Infrastructure – An

Overview. Last visited: April 21, 2010.

14. http://www.ubuntu.com/partners/Eucalyptus. Ubuntu & Eucalyptus. Last visited: April 15,

2010.

15. http://www.ibm.com/developerworks/opensource/library/os-cloud-virtual1/index.html. IBM

- Cloud virtual infrastructure. Last visited: May 11, 2010.

16. http://www.opennebula.org/doku.php?id=about. OpenNebula. Last visited: April 23, 2010.

17. http://www.opennebula.org/doku.php?id=documentation:rel1.4:plan. OpenNebula -

planning installation. Last visited: April 26, 2010.

http://csrc.nist.gov/groups/SNS/cloud-computing/cloud-def-v15.doc

http://www.abicloud.org/display/abiCloud/Home

http://abicloud.s3.amazonaws.com/latest/AbiCloud.Technical.Overview-1.0.pdf

http://esp.sam.lt/Informacija/&Language=lt_LT

http://esp.sam.lt/Informacija/

http://esp.sam.lt/Informacija/

http://www.vmware.com/appliances/getting-started/learn/ovf.html

http://blog.abiquo.com/category/uncategorized/

http://www.abicloud.org/display/abiCloud/Abicloud+Server+Live+Installers

http://open.eucalyptus.com/

http://open.eucalyptus.com/documents/ccgrid2009.pdf

http://eucalyptus.com/

http://www.ubuntu.com/partners/Eucalyptus

http://www.ibm.com/developerworks/opensource/library/os-cloud-virtual1/index.html

http://www.opennebula.org/doku.php?id=about

http://www.opennebula.org/doku.php?id=documentation:rel1.4:plan

63

18. http://www.opennebula.org/documentation:rel1.4:architecture. OpenNebula – Architecture.

Last visited: April 28, 2010.

19. B. Sotomayor, R. S. Montero, I. M. Llorente, I. Foster. Capacity Leasing in Cloud Systems

using the OpenNebula Engine. URL http://haizea.cs.uchicago.edu/pubs/Haizea_CCA08.pdf.

20. https://help.ubuntu.com/community/OpenNebula. Ubuntu - OpenNebula. Last visited: April

14, 2010.

21. http://www.opennebula.org/lib/exe/fetch.php?id=outreach&cache=cache&media=the_openn

ebula_standard-based_open-source_toolkit_to_build_cloud_infrastructures.pdf.

Presentation: OpenNebula - build cloud infrastructures. Last visited: May 13, 2010.

22. http://opennebula.org/doku.php?id=documentation:rel1.4:template. OpenNebula –

templates. Last visited: April 16, 2010.

23. http://haizea.cs.uchicago.edu/index.html. Haizea. Last visited: May 11, 2010.

24. http://haizea.cs.uchicago.edu/doc_multiple.html. Haizea - manual. Last visited: May 11,

2010.

25. https://www.openqrm.com. openQRM. Last visited: April 29, 2010.

26. http://www.openqrm-enterprise.com/company.html. openQRM - enterprise. Last visited:

April 17, 2010.

27. http://www.vmware.com/pdf/vsphere4/r40/vsp_40_intro_vs.pdf. VMware - vSphere. Last

visited: May 3, 2010.

28. http://www.vmware.com/files/pdf/key_features_vsphere.pdf. vSphere features. Last visited:

May 5, 2010.

29. http://www.vmware.com/resources/compatibility/search.php?deviceCategory=software.

vSphere - supported software. Last visited: May 3, 2010.

30. http://www.vmware.com/pdf/vsphere4/r40/vsp_40_config_max.pdf. vSphere - limitations.

Last visited: May 4, 2010.

31. http://cloud-standards.org/wiki/index.php?title=Main_Page. Cloud standards. Last visited:

March 25, 2010.

32. http://www.informationweek.com/cloud-computing/blog/archives/2009/06/eli_lilly_nasa.

NASA and Lilly. Last visited: May 3, 2010.

33. http://blog.gogrid.com/2009/03/26/navigating-the-layers-of-the-cloud-computing-pyramid/.

Cloud layers. Last visited: March 12, 2010.

34. http://www.infoworld.com/d/cloud-computing/what-cloud-computing-really-means-031.

What cloud computing really means. Last visited: March 13, 2010.

http://www.opennebula.org/documentation:rel1.4:architecture

http://haizea.cs.uchicago.edu/pubs/Haizea_CCA08.pdf

https://help.ubuntu.com/community/OpenNebula

http://www.opennebula.org/lib/exe/fetch.php?id=outreach&cache=cache&media=the_opennebula_standard-based_open-source_toolkit_to_build_cloud_infrastructures.pdf

http://www.opennebula.org/lib/exe/fetch.php?id=outreach&cache=cache&media=the_opennebula_standard-based_open-source_toolkit_to_build_cloud_infrastructures.pdf

http://opennebula.org/doku.php?id=documentation:rel1.4:template

http://haizea.cs.uchicago.edu/index.html

http://haizea.cs.uchicago.edu/doc_multiple.html

https://www.openqrm.com/

http://www.openqrm-enterprise.com/company.html

http://www.vmware.com/pdf/vsphere4/r40/vsp_40_intro_vs.pdf

http://www.vmware.com/files/pdf/key_features_vsphere.pdf

http://www.vmware.com/resources/compatibility/search.php?deviceCategory=software

http://www.vmware.com/pdf/vsphere4/r40/vsp_40_config_max.pdf

http://cloud-standards.org/wiki/index.php?title=Main_Page

http://www.informationweek.com/cloud-computing/blog/archives/2009/06/eli_lilly_nasa

http://blog.gogrid.com/2009/03/26/navigating-the-layers-of-the-cloud-computing-pyramid/

http://www.infoworld.com/d/cloud-computing/what-cloud-computing-really-means-031

64

35. Ţ. Ţąsytis. Virtualizavimo infrastruktūros parinkimas ir taikymas maţose ir vidutinio dydţio

įmonėse. Magistro darbas, KTU, 2009.

36. http://www.xen.org/. XEN hypervisor. Last visited: May 11, 2010.

37. http://www.linux-kvm.org/page/Main_Page. Kernel-based virtual machine. Last visited:

May 11, 2010.

38. http://www.vmware.com/products/esx/. „WMware“ ESX/ESXi hypervisors. Last visited:

May 12, 2010.

39. http://www.virtualbox.org/. VirtualBox hypervisor. Last visited: May 10, 2010.

40. http://linux-vserver.org/Welcome_to_Linux-VServer.org. LinuxVserver hypervisor. Last

visited: May 13, 2010.

http://www.xen.org/

http://www.linux-kvm.org/page/Main_Page

http://www.vmware.com/products/esx/

http://www.virtualbox.org/

http://linux-vserver.org/Welcome_to_Linux-VServer.org

65

PRIEDAI

66

1 PRIEDAS

Pirmo tiriamojo darbo santrauka

Tiriamojo darbo autorius: Dainius Petravičius

Tiriamojo darbo pavadinimas: Balso pašto paslauga

Vadovas: dr. V. Liesionis


Kaunas, 2008





Mobilusis telefonas tapo neatsiejama šiuolaikinio ţmogaus gyvenimo dalimi ir yra

naudojamas kaip daugiafunkcinis prietaisas: mobiliuoju telefonu galima suţinoti naujausius įvykius

iš viso pasaulio, atlikti finansines operacijas, naršyti internete, ţiūrėti televizijos programas, gauti

informaciją apie savo sveikatos būklę, pasinaudoti balso pašto paslauga. Darbo eigoje įvardinti

SMART tikslai: konkretūs tikslai – ar aišku ko norima pasiekti, išmatuojami tikslai – kiekybinė

tikslų išraiška, pasiekiami tikslai – ar įmanoma šiuos tikslus pasiekti, realūs tikslai – ar turima

pakankamai įvairių išteklių tikslams pasiekti, numatytas laikas – konkretus tikslų pasiekimo laikas.

Remiantis BCG matrica nuspręsta, kad tikslinis segmentas yra „Klaustukai“, todėl reikės daug

investicijų pereinant į sekančią stadiją. Remiantis lūţio taško metodu, atlikta kainodaros analizė,

kurios metu buvo nustatyta minimali balso pašto paslaugos kaina 5,3Lt, tačiau buvo nuspręsta

paslaugos mėnesinį abonementą pardavinėti uţ 5,7Lt. Sudarytas marketingo veiksmų planas,

kuriame trumpai apţvelgta paslaugos kaina, vieta, aprašyta paslauga bei aptartos galimos reklamos

ir skatinimo priemonės, padėsiančios pritraukti potencialius klientus.

67

2 PRIEDAS

Antro tiriamojo darbo santrauka


Tiriamojo darbo pavadinimas: RFID technologijų panaudojimo galimybės paslaugų

logistikoje

Vadovas: doc. dr. Daiva Vitkutė Adţgauskienė


Kaunas, 2009





Duomenų kaupimo technologijos, tokios kaip RFID (Radio Frequency Identification –

radijo daţnio identifikavimas), galėtų vesti tikro interaktyvumo ir į klientą orientuotų visuotinių

paslaugų tiekimo grandinių link, arba uţtvindyti bendroves jau sukauptais, tačiau iki galo

neišnaudojamais svarbiais duomenimis. Šis darbas pateikia centralizuotą duomenų paieškos

projektą, skirtą daugybei iš RFID lustų arba iš bet kokios kitos duomenų kaupimo technologijos

gaunamų duomenų terabaitams apdoroti. Šiuo metu RFID yra skirtas vietiniam ir daţnai

dvejetainiam naudojimui tam tikromis aplinkybėmis, kuriant duomenis, tačiau, nustačius naudingą

informaciją ir siekiant tvarkyti šiuos duomenis bei perteikti poreikius, reikalingos paţangios

informacijos valdymo technologijos. Įmonės vargsta, apdorodamos šiuos duomenis, todėl galima

teigti, kad, vertinant tokio lygio duomenų rinkimą, svarbu suformuoti naują perspektyvą. Aukščiau

nurodyta perspektyva pasitelkiama ne produkto tiekimo, tačiau paslaugų tiekimo grandinėje.

68

3 PRIEDAS

Trečio tiriamojo darbo santrauka


Tiriamojo darbo pavadinimas: „Cloud Computing“ panaudojimo galimybės

Vadovas: doc. dr. Kęstutis Šidlauskas


Kaunas, 2009





„Cloud Computing“ (liet. debesų kompiuterija) - tai yra modelis, įgalinantis visur esantį

priėjimą prie paskirstytų, lengvai konfigūruojamų kompiuterinių išteklių (tokių kaip: tinklai,

serveriai, atmintinė, programos, ir paslaugos), kuriuos pagal pareikalavimą tiekia ir aprūpina

paslaugos teikėjas, įdėdamas minimalius kaštus. Kitaip tariant, tai yra paslaugos, kurioms pateikti

reikalingas tik interneto ryšys. Numatytas perėjimas į „Cloud Computing“ būtų esminė vystymosi

prieţastis tam tikroje IT srityje. Todėl šiame darbe analizuojami galimi šio modelio panaudojimo

atvejai, kuriems taip pat nustatomi reikalavimai.

Documents

VYTAUTO DIDŢIOJO UNIVERSITETAS