iaas felhő kialakításának újabb lehetőségei - tdk · tartalomjegyzék 1. bevezetés 3 2....

IAAS felhő kialakításának újabb lehetőségei

Készítette:

Rostás László

Témavezetõ:

Dr. Kecskeméti Gábor

Miskolci Egyetem, 2012.

Tartalomjegyzék

1. Bevezetés 3

2. Nyilvános Kulcsú Infrastruktúra Szolgáltatás 6

3. Virtualizáció 8

4. Felhőszolgáltatás 12

5. Jelenlegi rendszer analízise, átalakítása 16

5.1. Jelenlegi rendszer ismertetése . . . . . . . . . . . . . . . . . . . . . . . 16

5.2. VirtualBox-os kiegészítés . . . . . . . . . . . . . . . . . . . . . . . . . . 17

5.3. Lemezkezelő . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

6. Mérések 20

6.1. Mérési területek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.2. Tömörítési algoritmusok mérése . . . . . . . . . . . . . . . . . . . . . . 22

6.3. Állapotszinkronizációs mérés . . . . . . . . . . . . . . . . . . . . . . . . 25

6.4. Mérések összegzése . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7. Konklúzió 30

8. Mellékletek 32

8.1. Repository mérés grafikonja . . . . . . . . . . . . . . . . . . . . . . . . 32

8.2. Tömörítési algoritmusok mérésének grafikonjai . . . . . . . . . . . . . . 32

8.3. Szinkronizációs megoldások mérésének grafikonjai . . . . . . . . . . . . 36

2

1. Bevezetés

Exponenciálisan nő azoknak az eszközöknek a száma, amelyek kommunikációra képe-

sek más eszközökkel. Centralizált rendszerek esetén egy szerver kezeli az információkat.

Ebben az esetben a szerver erőforrásait a szolgáltatás típusától és a felhasználók szá-

mától függően kell méretezni. Használat során könnyen változhatnak az igények (több

felhasználó, bővülő szolgáltatás). A virtualizációs megoldások terjedésével, fejlődésé-

vel könnyebbé vált, hogy egymástól független rendszereket futtassanak párhuzamosan

egy adott környezetben. Ezeknek a rendszereknek sokkal könnyebben lehet az erő-

forrásaikat módosítani, illetve áthelyezni őket más környezetbe. Azon rendszereket,

amelyekben a felhasználó egy szolgáltatás által jut valamilyen számítási erőforrások-

hoz számítási felhőknek nevezzük.

A felhőrendszerek napjainkban már nem számítanak újdonságnak. Számos típusa

létezik, többek között az infrastruktúra, a platform és a szoftver szolgáltatás (IaaS,

PaaS, SaaS). A Dolgozatom során az IaaS rendszerekkel foglalkozom. A felhasználó

infrastruktúra erőforrást igényel a szolgáltatástól. A kapott gépet megadott határokon

belül bármilyen célra felhasználhatja.

Több helyen is igénybe vehetünk ilyen jellegű szolgáltatást (pl.: Amazon), de szá-

mos nyílt forráskódú rendszer is elérhető, mely céltól függően alkalmazható, és segít-

ségével létrehozhatunk, privát, publikus illetve hibrid szolgáltatásokat. Hibrid felhők

létrehozásának lehetősége fontossá teszi, hogy legyen egy közel azonos hozzáférési fe-

lület, amely általában az Amazon szolgáltatás API-ja. Egyedi, az igényekhez jobban

illeszkedő felület kialakítása egy fejlesztési terület a témában. Egy szolgáltatás egy-

másra épülő rétegekből épül fel, ami egy komplexebb rendszer esetén megfelelő ismeret

hiányába nehezen módosítható, átalakítható. Rétegződések segítségével több különálló

területre bontható a rendszer (pl.: ütemezés optimalizálás, hálózati rendszer kialakítás,

virtualizációs technológiák).

Szükségesek olyan kutatói rendszereknek a létrehozása, melynek fő feladata nem a

szolgáltatásnyújtás, hanem egyes területeken való fejlesztés megkönnyítése. Ezeknek a

rendszereknek a forrását könnyen át kell tudni látni, illetve lényeges, hogy át lehessen

3

alakítani, bővíteni a rendszerigényeknek megfelelően. Ezen rendszer megkönnyítheti a

kutatásokat, amely segítségével hatékonyabb, biztonságosabb rendszereket lehet létre-

hozni.

Dolgozatom célja egy olyan IaaS szolgáltatás létrehozása, amely lehetővé teszi az

üzemeltető számára a virtualizációs alkalmazás opcionális megválasztását. Projektem

alapját egy korábban készült disszertáció[12] kutatása adta, amely az aktuális IaaS-ek

problémáival foglalkozik. A disszertációhoz készült alkalmazás elsősorban mérési cé-

lokra készült, melyeknek eredményeit a téma kutatása során hasznosított. Munkám

célkitűzése, hogy ezt a rendszert kiegészítsem olyan elemekkel, amelyek kibővíthetik

a későbbi kutatási, felhasználási területeket. Jelenleg a rendszer XEN, illetve Ama-

zon gépeket kezel. Virtualizációs technológiák népszerűsége miatt, azonban egyre több

alkalmazás nyújt lehetőséget számunkra, melyek különböző eredménnyel teljesítenek.

Ezen oknál fogva a rendszert úgy egészítem ki, hogy az a VirtualBox alapú gépe-

ket is tudja kezelni. Mivel ezeket a rendszereket általában más rendszerekkel együtt

használjuk, ezért szükséges egy olyan programfelület (továbbiakban API), amelynek

segítségével bármely program képes felhasználni a szolgáltatását. Dolgozatom keretén

belül részletesen kitérek ezen kiegészítések megvalósításának menetére.

Projektem során már meglévő alkalmazást alakítottam át, egészítettem ki. A ki-

alakítandó környezet elsősorban nyílforrású rendszereket támogatok (IP-cím beállítás

miatt adott típusú Linux disztribúciók). XEN-es lemezképek esetén módosított kernel

szükséges a futtatandó rendszerek esetében is. ShellScript-el történik a host iniciali-

zálása, illetve a hoston történő virtuális gépek kezelése is, ezért a host gépeken Unix

alapú rendszernek kell futni, amelyekre telepítve vannak a szükséges programok (pl.:

PigZ, QEMU). A rendszernek néhány folyamatán mérésekkel igazoltam a módosítás

szükségességét, illetve ezáltal újabb lehetséges fejlesztési területeket határoztam meg.

A dolgozatban előszőr a hálózati kommunikáció biztonságát szolgáló PKI, illetve fel-

hőszolgáltatás alapját szolgáló virtualizációs technológiák elméleti hátterét mutatom

be. Jelenleg elérhető felhőszolgáltatási rendszereknek az összehasonlítása szerkezeti

felépítés, illetve hozzáférési felület tekintetébe. Elméleti hátterek után egy kutatási

4

rendszernek[12] a pontos forráskód felépítésének ismertetése, melyben a javítási, kez-

detleges célkitűzéseket ismertetem. Külön fejezetben a rendszer folyamatokon végzett

méréseket tárgyalom, melyben ismertetem a méréseket, illetve azoknak az eredményeit

mutatom be.

5

2. Nyilvános Kulcsú Infrastruktúra Szolgáltatás

Informatikai kommunikáció során az egyik legalapvetőbb, és fontosabb kérdés a bizalmi

kommunikáció, hogy biztosak lehessünk abba, hogy nem egy idegen harmadik fél próbál

tőlünk információt megszerezni. Bizalom megtartáshoz megfelelő titkosítás szükséges.

Két alapvető módszert ismerünk, a szimmetrikus és az asszimetrikus. Szimmetrikus

titkosítás során ismernie kell mind a két félnek a dekódoló algoritmust, illetve a meg-

felelő kulcsokat, és maga a titkosítási kulcs elküldését is meg kell oldani. Másik eljárás

az asszimetrikus titkosítás, melyet Diffie–Hellman [1] nevéhez fűződik, mikor az 1970-

es években egy olyan cryptográfia függvényt mutattak be, melyben egyik (nyilvános)

kulccsal lehet kódolni a tartalmat, de visszafejteni már nem, míg egy másik (titkos)

kulccsal pedig visszafejthető a tartalom. Egyik legelterjedtebb ilyen algoritmus az RSA

eljárás.

Az RSA kulcs biztonsági alapját a nagy számok prímtényezős felbontásának nehéz-

sége adja, mivel nem ismert jelenleg olyan gyors algoritmus, mely ezt meg tudná tenni.

A privát és a publikus kulcs alapját egy-egy nagy prímszám adja, amelynek egymástól

különböznie kell, ebből a két prímszámból meghatározhatjuk a két kulcsot illetve az N

számot. A privát kód feltöréshez N számot kell faktorizálni, mely a nagy prímértékek

miatt igen erőforrás igényes, ezáltal hosszú ideig tart.

Azonosítás egy rendszerben igen gyakran, és gyorsan kell történnie, így egy külön

rendszer összeállítás is készült. A Nyilvános kulcsú infrastruktúra (PKI) [13] hardverek,

szoftverek és üzemeltetőkből áll. Fő célja, hogy nyílt, nem biztonságos hálózatokon

biztonságos kommunikációt biztosítson.

A rendszer fő első elemeként a certificate authority (CA) (Tanúsítvány kiadó), mely-

nek feladata a tanúsítvány kiállítása, nyilvántartása (állapot frissítéssel), visszavonási

listák elkészítése. Elemei maga az eszköz azt működtető szoftver és személyzetből te-

vődik össze. A kiadót a neve és nyilvános kulcsa alapján lehet azonosítani. Az általa

kiadott tanúsítványok kezelése, aktuális, illetve lejárt tanúsítványokat is kezel. A nagy

információ kezelés miatt, egyes tevékenységeket külön szervezetek veszik át, a megfelelő

terhelés elosztás, elszigetelés miatt.

6

Egyik ilyen a Registration Authority (RA) (Regisztrációs szervezet), melynek fel-

adata a tanúsítvány tartalmának ellenőrzése, információk feldolgozása, majd a szük-

séges információk továbbítása a CA felé. Minden tanúsítvány kiadóaknak van egy

listája amely az általa megbízhatónak talált regisztrációs szervezeteket tartalmazza, és

az alapján fogadja el, vagy utasítja el a szervezettől érkezett kéréseket. Itt is név és

nyilvános kulcs azonosítja.

A tanúsítványok tárolás két részre oszlik, egyik az aktív, másik meg az archív

elemek tárolására. Ezeket valamilyen X.500-as protokollú szabvány implementációjával

biztosítják a tárolás és szétküldés lehetőségét. X.500 protokoll készlet meghatározza

az alapvető műveleteket, ilyen például a láncolás, követés, irányítás, és hozzáférési

protokoll.

A rendszer azon elemei, melyek során a rendszernek csak azon részébe érintettek,

hogy egy tanúsítványt megszerezzenek és aláírjanak dokumentumokat, és más forrásból

származó tanúsítványokat is ellenőrizzenek, ezeket hívjuk a rendszer PKI végfelhaszná-

lóinak. Rendszer egyes elemei nincsenek feltétlenül teljesen elkülönülve, mivel egy-egy

felhasználó lehet szolgáltató és kiszolgált szerepbe is.

A készülő rendszerben a PKI nyilvános - titkos kulcsú rendszer az ssh bejelentkezés

miatt kiemelten fontos, mivel automatizált bejelentkezés történik így egy olyan meg-

oldásra van szükség, amely nem használja a standard input mezőt (így nem is kérhet

be jelszót), de mégis a teljes biztonságot megtartja. Az általános bejelentkezés so-

rán a publikus kulcs egy szimmetrikus titkosítással titkosítva van, melyet a stdin-ről

megadott jelszóval fejtenek vissza, így adva át publikus kulcsot. Ebbe az esetben is

a későbbi kommunikáció a publikus - titkos kulcspárral lesz titkosítva. Lehetőség van

arra is, hogy egy kulcspárt generáltatunk, amelynek a publikus kulcsát vagy elhelye-

zünk, vagy ssh bejelentkezés során küldünk el, és a titkos kulcs párját pedig ahonnan

bejelentkezünk oda helyezzük el. Publikus kulcs gyűjtemény a /.ssh/authorized_keys

fájlba, a saját privát kulcsunk pedig az id_rsa fájlba lesz. Algoritmusát tekint RSA

algoritmusossal dolgozik.

7

3. Virtualizáció

A virtualizáció létrehozásának egyik fő előnye, hogy egy hardveren több különböző

feladatot, egymástól elszigetelten lehet végezni. Akár más operációs rendszer virtuális

futtatásával vagy alkalmazások virtualizációs rétegen történő futtatásával. A virtua-

lizáció már a 70-es évek közepétől a nagy gépek (mainframe) használatánál is jelen

volt. Mára a felhasználási területek igen széles körben, a számítógép-használat számos

területén megjelenik[14]. A gyors szoftver- és hardverfejlődési ütemnek köszönhetően,

számos olyan szoftver van használatban, amely nem tud megfelelően együttműködni

az adott hardverrel vagy más szoftverrel, operációs rendszerrel. Fejlesztők számára az

egyik legjobb legkényelmesebb tesztelési megoldás lehet a virtualizációs módon több

különböző operációs rendszer feltelepítése, majd azokon való tesztelés. Felhasználóknak

pedig lehetőséget ad arra, hogy régebbi programokat, rendszereket tudjanak futtatni

mai hardvereken. Ezenkívül egyre nagyobb teret hódítanak az operációs rendszerbe

épített virtualizációs megoldások is, hogy minél kényelmesebbé tegyék a program hasz-

nálatát, és elrejtsék a hardver, szoftver kompatibilitási problémákat. Ilyen például a

könyvtárvirtualizáció vagy az alkalmazásszintű virtualizáció. Könyvtárvirtualizációra

legismertebb példa Linuxos rendszerkörnyezetben a Wine, illetve OS X-es rendszereken

a Cider. Könyvtárvirtualizáció esetében pedig a legismertebbek: Java vagy C#.

Azonban, ha teljes értékű operációs rendszereket szeretnénk virtualizálni, akkor

négy fő módszerrel tehetjük meg. Az egyes módszerek közötti különbség az elszigetelt-

ség és hatékonyság-kényelmesség arányának változásában jelenik meg. Egyik legjobban

elszigetelt virtualizációs megoldás az utánzás módszer, ami teljesen önálló architektú-

rát teremt a virtualizált rendszer számára, amely változtatás nélkül is telepíthető rá.

Egy hiperfelügyelőn keresztül történik minden rendszerhívás, ezért is az egyik leglas-

sabb emulációk közé tartozik. Széleskörű alkalmazási területe van, fejlesztés során,

még el nem érhető hardver történő fejlesztéshez, vagy más architektúrájú rendsze-

rek futtatása, talán egyik legjobban ismert példa a Microsoft Virtual PC Mac OS-re

szánt verziója, amikor PPC-s architektúrára Intel alapú rendszerek telepítését tette

lehetővé. Ezenkívül ide tartoznak a “muzeális” rendszerek használatának lehetősége,

8

ami akár a legelső operációs rendszerek futtatását, használatát is lehetővé teszi. Régi

Apple gépeken ROM-mal futtathatunk régi Mac OS rendszereket például a Basilisk

II, sheep shaver segítségével. Ismertebb ma is használatos emulátorok: Qemu, illetve

PPC architektura futtatáshoz használatos Pear PC. Teljes Virtualizáció esetében is a

teljes értékű rendszer képét látjuk. Legnagyobb különbség az utánzás, és ezen módszer

között, hogy itt csak a saját architektúrájának megfelelő rendszer futtatására képes,

mivel itt a rendszernek lehetősége nyílik közvetlenül a hardvernek adni az utasítást,

és a hiperfelügyelő pedig szabályozza a hardver hozzáférésének jogait. Ennél a mód-

szernél is a módosítatlan operációs rendszer kerül telepítésre a virtuális gép esetén.

Paravirtualizációt a teljes virtualizáció egy módosításaként is lehet nevezni, mivel itt

az operációs rendszerbe történnek olyan változtatások, amely a hagyományos hardver

elérés helyett egy hiperfelügyelőn történő hívásra cserélődik (application binary inter-

face, ABI) ezzel hatékonyan gyorsítható a vendégrendszer futtathatósága. Problémát

jelenthetnek a fel nem készített zárt forráskódú rendszerek használatának ellehetetle-

nedése. Operációsrendszer-szintű virtualizáció esetén már nem a hagyományosan teljes

rendszerként ismert egymástól független gépeket kapunk, hanem egymástól elszigetelt

kiszolgáló egységeket. Ez esetben az operációs rendszerből csak egy van, amely módo-

sításon keresztül teszi lehetővé az ilyen jellegű virtualizációt. Egyik legnagyobb előnye,

hogy hatékonysága ennek a legjobb, megközelíti a nem virtualizált rendszerek telje-

sítményét, azonban nagy megkötésnek számít, hogy a számítási háttereknek meg kell

egyeznie, tehát ugyanazon rendszer, ugyanazon frissítéseit használja, így oldható meg

a közös rendszermag.

Virtualizációknak nem csak azon része fejlődik, válik hatékonyabbá, melyben tel-

jes operációs rendszer képét adjuk a felhasználó számára, hanem más jellegű, egyre

jobban terjedő, az egyre jobban integrálódó virtualizáció, ami a natív program lát-

szatát próbálja megteremteni. Fejlesztői szemszögből lehetőséget ad, hogy minél több

rendszerre minél kevesebb nyelven kell megírni, portolni az adott alkalmazást. Ennek

két fő irányzata létezik. Ebből az egyik a könyvtárvirtualizáció. Leggyakrabban ezt

a módszert játékok esetében, ún. transgameingeknél használják. Ebben az esetben

9

a már Windows rendszerre megírt játékokat a lehető legkisebb többlettelköltséggel és

lehető legkönnyebben telepíthető verzióban teszik elérhetővé a felhasználók számára.

Linux alatt legismertebb a Wine, OS X esetén pedig a Cider. A másik egyre jobban

terjedő vonulat a felügyelt kódú programok írása. Ez esetben a korábban tárgyalt hi-

perfelügyelők szerepét egy futtató környezet veszi át. Ez a Java nyelv az utánzáshoz

hasonlítható, amikor a teljes kód a futtató környezet segítségével, közvetlen hardver

elérés nincs. C# illetve Mono esetébe pedig közvetlen utasítások is vannak és a futtató

környezet a teljes virtualizációhoz hasonlóan a hozzáférési jogokat moderálja.

Elszigeteltséghez segítséget nyújt a processzor architektúrájának kiépítése, például

az x86 esetében a védelmi gyűrűkkel. A hagyományos x86-os architektúra 4 védelmi

gyűrűvel rendelkezik. A legnagyobb jogosultsággal, a legkisebbel pedig a 3. szint. Ha-

gyományos nem virtualizált esetben a 0. szinten helyezkedik el az operációs rendszer

és 3. szinten meg a felhasználói alkalmazások. Virtualizáció esetében kernel módosí-

tásokkal elérhető, hogy a nulladik szinten a hiperfelügyelő kapjon helyet, amely teljes

uralmat kap a hardver felett, a vendég rendszerek pedig az első szinten, és a legala-

csonyabb szinten pedig a felhasználói programok. A mai processzorkornál egyre több

támogatást kapnak a virtualizációt elősegítő lehetőségek. Egyik lehetőség a nulladik

réteg alatti szint, amelynek nagyobb joga van a nulladik szintél.

A dolgozat során kialakítandó hálózat nem feltétlenül egy homogén, azonos tulaj-

donságokkal bíró rendszer, ezért is szükséges egy másik, gyorsan fejlődő virtualizációs

program beillesztése az alkalmazásba. A virtualizációs program kiválasztása során

figyelembe kell venni több olyan tényezőt, mely hosszútávon hatással lehet az üzemel-

tetésre, megbízhatóságra. Vizsgálat során a legpopulárisabb emulátor programokat

nézzük (WMware, Parallels, VirtualBox, Microsoft Virtual PC, Qeumu). A listába

nem vettem bele a XEN emulátort, mivel azt a rendszer már jelenleg is tudja. Az

alábbi táblázat során három operációs rendszeren vizsgálom: Microsoft Windows, Li-

nux, Mac OS X. Vizsgálat során a jelenlegi Windows alapú VirtualPC-t tekintjük, mely

más mint a régen PowerPC-s processzorra, OSX-re megjelent x86-os architektúrát vir-

tualizáló emulátor.

10

Felvetés VirtualBox WMware Parallels Qemu VirtualPC

Ár Ingyenes Fizetős Fizetős Ingyenes Ingyenes

Forrás nyílt zárt zárt nyílt zárt

1. táblázat.

Fontos szempont, hogy minél több operációs rendszeren fusson az adott emulátor,

ezért a VirtualPC nem jöhet számításba.

A táblázat alapján, a VirtualBox és a Qemu emulátorok maradtak lehetőségként,

mivel a többi zárt forráskódú, általában fizetős rendszer. Virtualizációs lehetőségeket

tudását figyelembe véve a rendszer számára nincs olyan jelentős eltérés. A Qemu és

VirtualBox közötti döntést még külön-külön vizsgálva a lehetőségeket, a VirtualBox

javára szól, hogy a virtuális gép leírója, egy xml alapú dokumentáció, így későbbiekbe

jól lehet szükség szerint manipulálni. Támogatottság kérdését is érdemes vizsgálni,

mivel a VirtualBox rendszerét az Oracle fejleszti, ezáltal az esetlegesen fellépő hibák

javítása várható. Ezek alapján lett az Oracle-s program választva.

11

4. Felhőszolgáltatás

Ma még számítási igények növekedését a processzorok sebessége nem tudja kellő módon

követni, így hatékonyság érdekében más eljárásokat alkalmaznak a megfelelő számítá-

sok időben történő elvégzéséhez. Egy osztott rendszer segítségével a felmerülő számítási

igény szétosztható egyrészt párhuzamos programozás révén, másrészt a teljes rendszer

szolgáltatásainak több erőforrásra való áthelyezésével. Ezzel a válaszidő jelentős mér-

tékben lecsökkenthető. Ezenkívül figyelembe véve azt, hogy a kisebb teljesítményű

gépeket olcsóbban lehet beszerezni és az áramfogyasztás is kisebb, kedvezőbb üzemel-

tetési költség érhető el. Több operációs rendszer esetén több gépre van szükség, amely

akár lehet virtuális gép is. Virtualizációs technológiák segítségével akár egy gép erő-

forrását is fel tudjuk osztani kisebb erőforrású gépekre, ezáltal igény szerint osztható

fel a rendszert. Az optimális felosztáshoz jobban közelíthetünk, ha ezt egy olyan szoft-

verre bízzuk, ami kezeli a rendszerben lévő gépek erőforrását. Ezt az infrastruktúrát

és a hozzátartozó szoftver együttesét nevezzük Számítási Felhőnek. A szolgáltatás fel-

használójának nem kell törődnie a mögötte álló rendszer felépítésével, ad egy kérést az

interfészen keresztül, majd megkapja a kért erőforrás elérhetőségét.

A szolgáltatást szabványos internet protokollon keresztül lehet elérni. Legelterjed-

tebb ezek közül a HTTP protokollon használt SOAP rendszer. A SOAP protokollt a W3C

definiálja, így szabványosítottnak kezelhetjük. A SOAP-ról röviden annyi kiemelendő,

hogy a hagyományos GETkérésekkel szemben itt mindig POST üzenetbe küld XML for-

mátumú kérést. Ezáltal viszonylag nagy üzeneteket hoz létre. Ehhez kapcsolódik

egy WSDL[8] amely egy webszolgáltatást ír le, ezáltal egy pontosan, jól használható

kérés-válasz protokollt kapunk. XML nagy terjedelme miatt egyre több helyen kezdték

használni a JSONalapú kommunikációt. Előnye ennek, hogy sokkal kevesebb redundáns

részt tartalmaz az üzenet, így kisebb a hálózat plusz terhelése.

A NationalInstitute of Standards and Technology (NIST) definíciójában két fő

modellbe csoportosították a felhőket (2011):[15]

12

Telepítési modell

Privát felhő Kizárólagosan egyetlen szervezet tulajdonában, használatá-

ban van. Felhasználói több szervezeti egysége is lehet az adott körbe.

Közösségi felhő Ebben az esetben egy közösség (több szervezet), valami-

lyen közös érdek miatt közös tulajdonban, közös irányításba van.

Nyílt felhő Nagy közönség számára nyújt szolgáltatást valamilyen szerve-

zet.

Hibrid felhő Ebben az esetben a teljes felhő privát és nyílt felhő alrend-

szerből is felépül.

Szolgáltatási modell

Software as a Service (SaaS) Legmagasabb absztrakciós szint, itt ma-

gát a megírt alkalmazás futtatását adja, hálózat, tárolás, Operációs

rendszer a szolgáltatás részét képzi.

Platform as a Service (PaaS) Platform felhő szolgáltatás esetén magát

operációs rendszert kapjuk kézhez, ezzel elrejtve az összes fizikai réteget.

Infrastructure as a Service (IaaS) Legalacsonyabb szintje, ennél a ma-

gát a gépet kapjuk kézhez, ennél nekünk kell gondoskodni a megfelelő

rendszerről.

Egyik legismertebb és legelterjedtebb szolgáltatást az Amazon nyújtja. Az Amazon

felhőrendszerei mára a legtöbb – NIST által definiált – modellt lefedik. Ezek közül ki

kell emelni az egyes IaaS típusú szolgáltatási interfészeket. Elsőként az Amazon Elastic

Compute Cloudot (EC2) említhetjük, ami a virtuális gépeket kezeli (létrehozza, elin-

dítja, újraindítja, leállítja). Ezt követi az Amazon Simple Storage Service (S3), egy

az adattároláshoz szükséges szolgáltatás. Az Amazon által implementált rendszerek

zárt forráskódúak, ezért nem ismertek a belső működési felépítése. Amazon interfészé-

vel azonos nyílt forráskódú rendszerek is megjelentek. Ezért lehetőség van ezeknek a

rendszereket hibrid módon használni. Néhány rendszer mely összehasonlításra kerül:

13

OpenStack, Eucalyptus, OpenNebula, és a létrehozandó rendszer. Ezek a rendszerek

IaaS szolgáltatást implementálnak, melyek strukturális felépítésben megegyeznek. Elő-

ször az Eucalyptus [16] implentálta az EC2 és S3 interfaceket. Öt fő komponensből

épül fel[7] . AWS EC2-es számítási szolgáltatásnak a Colud Controller (CLC) fele-

lős, ez adja az egyik külső interfészt. Másik publikus interfésze a Walrus, mely az

adattárolás AWS S3-as szolgáltatást nyúlt. Minden fizikai gép a hálózatba egy-egy

Clustert képvisel, mely további két fő komponenst tartalmaz. Egyik a Cluster vezérlő

(Cluster Controller - CC) mely a hálózatépítéssel, felhasználó és virtuális gép, illetve

virtuális gépek közötti kapcsolatépítéssel foglalkozik, illetve magával a Virtuális gépek

kezelésével az adott csomóponton belül. Ez hozza létre az ez alatt elhelyezkedő csomó-

pontvezérlőket (Node Controller - NC). Csomópontvezérlő hipervisor feladatkört lát

el. A tárolórendszer irányítását a Storage Controller(SC) végzi. Blokkszintű hálózati

tároló, amit dinamikus lehet csatolni a rendszerhez. Ezt a teljes rendszert általában a

központi gépre telepítik.

Az OpenNebula is egy nyílt forráskódra épülő rendszer, melynek fő célkitűzése,

hogy lehetőleg minden gépet támogasson akár a szolgáltatások mennyiségének, és ru-

galmasság rovására is. A felhő jelenleg három virtualizációs technikát támogat (XEN,

KVM,Vmware). Rendszer hozzáférési pontok (APIs) [4] esetén a rendszer komponen-

seinek rétegződése és azoknak egymással történő kommunikációja is ezeken keresztül

történik. OpenNebula rendszerből kiindulva a fizikai host-ok felé van egy driver API

csoport, ami az azonosításért, monitorlizálásért, virtualizációs műveletek, illetve ma-

gáért a tárolásért felelős. A felhasználó felé megjelenő hozzáférési pontok alapját az

XML-RPC protokoll adja. Ez a protokoll HTTP hívásokon XML kódolású kérések

mennek. Hozzáférési lehetőséget ad az OCA(OpenNebula Cloud API)-n keresztüli ké-

rés, amely a JAVA-t és Ruby-t támogat. Ezen protokollok felé épül még pl.: az EC2-es

tool vagy a web-es GUI-s konfigurációs, monitorozó felület a SunStone. A CLI (Com-

mand Line Interface)-en keresztül is elérhető a teljes rendszer.

A kiépülő rendszer felépítését tekintve három részre bontható. Front-End az a

része, ahová fizikailag felkerül az openNebula alkalmazás. Ez foglalkozik az összes

14

management funkcióval (kiépíti a kapcsolatot, fogadja a kéréseket, monitoroz). A

virtualizált gépek a Hostokon futnak. A host felé sok követelmény nincs, egyedül, hogy

a megfelelő hypervisor, illetve ssh szerver fusson. A lemezképekért felelős rész az Image

Reposytory és Storage.

Az OpenStack 2010-ben jelent meg először Austin verzióval a Nasa és a Rackspace

együttműködésével. A rendszer hat komponens [9] alkotja. Ami magát a felhő szol-

gáltatást képviseli az a Nova. Ez két fő Hypervisor-t támogat. A Xen-t és a KVM-et.

Ezenkívül, még részlegesen az LXC-t, ESX-t és ESXi-t. A tárolási szolgáltatást a Swift

látja el. A lemezképeket virtuális gépekhez pedig a Glance. Az azonosítási eljárást a

Keystone látja el, ami támogatja az oAuth, SAML és openID autentikációkat. A rend-

szer hálózati kapcsolódási pontjait a Quantum komponens definiálja. Támogatja az

XML és a JSON formájú kéréseket is, azonban az API jelenleg nem tartalmazza EC2

SOAP API kérést, csak a Query API érhető el hozzá [6]. A vizuális felületet biztosít,

amely igényekhez testre szabható, tartalmazza az összes alap funkciót.

Felhők felhasználási területe nő és, hogy minden igény megfelelően ki lehessen elé-

gíteni, egyre több felhőszolgáltatás jelenik meg. Az említett nyílt forráskódú IaaS

rendszerek belső felépítésében sok közös pont található meg. Külső elérésnél pedig

cél, hogy minél jobban együtt tudjanak működni, hiszen így a hibrid felhők előnyét is

élvezhetjük. Ennek leírására egy metamodell [11] szolgál. Három modell szint van (Fi-

zikai, Belső logikai, Felhasználói felület), illetve vízszintes tagolásokba pedig a rendszer

komponensei (Virtuális gép management, Tároló, Lemezképsablon).

15

5. Jelenlegi rendszer analízise, átalakítása

Egy olyan IaaS szolgáltatás megírása a cél, mely a többi eddig említett rendszerhez

hasonló szerkezeti felépítéssel rendelkezik. Jelenleg a rendszer a XEN virtuális szerver

driverrel üzemel. Cél, hogy VirtualBoxal[5] (későbbiekben akár más jellegű rendsze-

rek is) rendelkező gépeket is csatlakoztatni lehessen a mostani rendszerbe. Jelenlegi és

kiépítendő rendszernek elsősorban az erőforrás menedzsment a feladata, ami a lemez-

képek, hostok, virtuális gépek nyilvántartása, kezelése.

5.1. Jelenlegi rendszer ismertetése

A rendszernek több üzemeltetést segítő osztálya van, mely kezeli a kapcsolatokat, össze-

gyűjti a különböző erőforrásokat, elérhető címeket. Ezek az osztályok a Util alrend-

szerben találhatóak. Egyik ilyen osztály az AddressPool, melyből egy példány fut a

rendszer teljes életciklusa alatt, nyilvántartja, lefoglalja, felszabadítja a rendelkezésre

álló IP-címeket. Kiegészítés után nem csak a XEN gépeket kezeli, hanem az alkalmazás

összes ip-címmel történő feladatot is ez látja el. Az osztálynak van egy hibaosztálya

is, mely a menedzselés során előkerülő hibák osztálya. Erőforrásokat a későbbiekben

kialakított HostPool fogja végezni. A kapcsolathoz segítséget nyújt az SSHConnector.

Ennek a feladata, hogy ssh kapcsolatot nyisson a host géppekkel, szükség esetén tunel-

t is összeállítson. Felügyeletét maga is végzi, tárolja az összes ssh kapcsolatot, amelyet

megszüntethetünk, lekérdezhetjük, és nyithatunk is újakat. A kapcsolat további osztá-

lyokba is finomítva lett, az util csomagba. Logolási rendszer rész is az util csomagban

kap helyet.

Következő alrendszere az iaas.xentarget, XEN rendszer specifikus elemeket is tar-

talmaz. A XenHost a rendszer azon része, mely egy adott virtuális szervert képvisel.

Ez az osztály osztja ki a virtuális gépnek a megadott erőforrást, és szolgáltat számára

IP-címet is. A XenHostPool osztály hasonlóan az AddressPool-hoz itt is csak egy pél-

dányba fut, ez managel-i az összes Host gépet. Ide érkezik be egy virtuális gép indítási

kérése, mely bekerül egy várólistába. Egy külön szálon megadott (10 ms) időközönként

16

ellenőrzi, hogy van-e a várakozó virtuális gép. XenHostPool átalakítás után nem egy

XEN specifikus, hanem egy sokkal általánosabb szerepet lát el, az összes elérhető host-

ot ez látja el. XenVirtualMachine magát a futtatandó rendszernek az irányítására

szolgál. Ez az osztály a hoston futtatható virtuális gép reprezentációja. Példányosítás

során el is indítja a kapott erőforrásoson, megadott paraméterek segítségével a startvm

scriptet, ami a hoston létrehozza a gépet.

5.2. VirtualBox-os kiegészítés

Dolgozatom céljában is szereplő VirtualBox-os kiegészítés és a rendszer funkcióinak

kibővítése miatt a jelenlegi forráskódnak átszervezése, kiegészítése vált szükségessé. A

kiegészítés esetén a virtuális gépek irányítására két fő irány is rendelkezésre áll. Ren-

delkezik saját Java-s API-val és konzolos applikációval (VBoxManage).Választásom a

konzolos applikációra esik, mivel a korábban elkészült XEN-es rendszer esetében is ha-

sonló megoldás van, így viszonylag kis módosítás szükséges ennek a beüzelemelésére.

Néhány probléma is felmerül a rendszer felépítés során. Egyik ilyen a lemezkép kér-

dése, mivel mind két virtualizációs szoftvernek más-más a saját lemezkép típusa. A

VBoxManage-nek van egy convertfromraw kapcsoló, parancsa, amivel az img lemezké-

pet (XEN által támogatott lemezkép) át lehet konvertálni a VirtualBox által használt

lemezképpé. Nagy időt venne igénybe az elindulás során, mivel így előszr az image

fájlt kell átmásolni, kicsomagolni, beállítani az IP címet, majd a kész lemezképet át-

konvertálni a szükséges formává. Azonban egy nyílt forráskódú projektnél (QEUMU[3])

megoldották a VirtualBox által használt lemezképek felcsatolását (vdi). A qemu-nbd

segítségével elvégezhetjük a mountolást a rendszer számára, ezután a XEN-el megegyező

módon beállítható az ip-cím. Ezen kívül már csak kisebb eltérések vannak, melyek

shell scriptbe áthidalhatóak. XEN rendszer esetén a virtuális gép létrehozása egy

config fájlból történt, addig VirtualBox-os környezetben pedig vagy generálunk egy

vbox kiterjesztésű fájlt (ami egy xml fájl), vagy konzolos környezetben létrehozzuk,

majd a szükséges beállításokat egyesével beállítjuk. Mivel a VirtualBox különálló meg-

valósítás nagy kódegyezőséget okozna, ezért több közös ősosztályba emeltem ki a közös

17

kódrészeket (virtuális gép, host). Átszervezésnél nem megengedhető, hogy az egyes

virtualizációs megoldásoknak egymástól független segédosztályai legyenek (címkezelés,

hostpool), mert akkor az egységességét, illetve a külvilág felé történő homogén felületét

elvesztené.

A következő probléma abból adódott, hogy a virtualizációhoz, valamint a lemezké-

pek felcsatolásához rendszergazdai jogosultság szükséges. A Linux-os rendszerüzemel-

tetési javaslat szerint az alkalmazásokat lehetőség szerint nem root-ként kell futtatni,

ezért vannak olyan disztribúciók, ahol a root-ként való bejelentkezés tiltott (pl Ubuntu).

Ezeknél a rendszereknél a sudu segítségével ajánlott a rendszergazdai feladatok elvég-

zése. Ez elősegíti, hogy csak a szükséges programok kapjanak rendszergazdai jogo-

sultságot. Ebben az esetben megerősítés (jelszómegadás) kérésével biztosított, hogy a

felhasználó szeretné elvégezni a műveletet, így a probléma megoldása során ez a mód-

szer nem alkalmazható. Ennek megoldásához engedélyezni kellett az adott gépekre

történő root-ként való bejelentkezést.

5.3. Lemezkezelő

Az alapkialakításban pontos címen megadott lemezkép alapján volt létrehozható egy

virtuális gép. Célom szerint egy azonosítónak elegendőnek kell lennie ahhoz, hogy a vir-

tuális gép elindulhasson a felhőben. Fontos cél volt az is, hogy a rendszer maga döntse

el, hogy melyik virtualizációs megoldást használja. A korábbi rendszerkialakításban a

java-s kód először létrehozott egy adott virtuális gép osztálynak egy példányát, az előre

ismert virtualizációs technológia alapján, majd ahhoz kapcsolta a megfelelő erőforrást.

Ez a megoldás megfelelő azon kialakítások számára, ami csak egy virtualizációs tech-

nológiát tartalmaz, vagy ha ismerjük előre, hogy milyen gépet szeretnénk létrehozni.

Lemezkezelő kialakításánál figyelni kellet, hogy nem csak a hostkezelő résznél kellet

kiegészíteni a kódot, hanem át is kellet alakítani az indítási folyamatot.

Az elérhető lemezképek feltérképezését az inicializáló host végezi el. A host gépen

tárolandó lemezképeknek meghatározott struktúrával kell rendelkeznie: Repositoryban

lévő jegyzékek neve lesz a lemezkép azonosító. A jegyzékekben található jegyzékek,

18

melynek nevei (xen vagy vbox, virtualizációtól függően), illetve tartalma a lemezkép.

Inicializálás során nem csak az elérhető összes processzormag számát adja vissza, hanem

a feltárt lemezképeket is. Ezeket az információkat a hostkezelő kezeli.

ScriptHost

IaaS HostPool

elérhető

hostokon,

amíg

sikertelen

AdressPool

ScriptVirtualMachine

ForeachacquireCPU

<< VM >>

allocateAddress

createVM

<< IP >>

createVM

<< Host >>

registerHost(Host)

<< VM >>

1. ábra: Host inicializálás, illetve virtuális gép indítása az átalakított rendszerben.

Az azonosító alapján működő gépindításhoz, a korábbi folyamatot átalakítva, a rend-

szer először igényel a hostpool-ból egy erőforrást. A rendelkezésre álló erőforrás alap-

ján már ismert a host-on futtatható virtualizációs technológia, így létre lehet hozni a

megfelelő virtuális gép osztálynak a példányát. A lemezkép címének meghatározása

során előfordulhat, hogy a szükséges lemezkép több helyen is megtalálható. Jelenleg

megvalósítás során végig nézi az elérhető képfájlokat, és ahol először megtalálja, onnan

tölti át. Későbbiekben ezen algoritmus fejleszthető, hogy kisebb erőforrást igényeljen,

illetve gyorsabb legyen a rendszerindulás.

19

6. Mérések

Jelen dolgozatban szereplő mérés célja, hogy a rendszerben végzett folyamatok álla-

potáról, mennyiségéről összehasonlítható, értékelhető információt szerezzünk. Mérés

megvalósításánál használom a Méréstechnika[10] által elfogadott irányelveket. Az el-

készített, működő rendszerben keresek olyan kódrészleteket, területeket, melyek újra-

gondolásával, bővítésével gyorsíthatom a rendszert. Először meg kell keresni a rendszer

azon részeit, aminek az átlagos futási sebességhez képest lassabb a végrehajtási ideje.

Ilyen probléma keletkezhet egy nem megfelelően választott algoritmus, vagy akár a ren-

delkezésre álló erőforrások korlátaiból adódó várakozás esetén (pl.: hálózathasználat,

háttértárra történő nagy mennyiségű adat kiírásánál). Már a tervezés, implementáció

során is felmerülhetnek olyan problémák, melyek esetében további kutatómunka szük-

séges a mérés folytatásához. Ilyen lehet például egy többféleképpen leírható kódrészlet.

6.1. Mérési területek

A rendszer alapvetően hálózati kommunikációra épül, ezért ahol lehetséges csökkenteni

kell az adatforgalmat. Az egyik nagy hálózati adatforgalomra épülő rendszerfolyamat

a virtuális gép létrehozása. A folyamat során át kell másolni hálózaton keresztül egy

képfájlt, majd a képfájl alapján létrehozni egy futtatható virtuális gépet.

A rendszernek egy másik folyamatrésze, ami a virtuális gépek szinkronizációjáért

felelős, az nem a nagy hálózati forgalma miatt került vizsgálatra, hanem a gyakori host

gépen történő futtatása miatt. A script segítségével szinkronba tarthatjuk a virtuális

gépek állapotát, ami kétféleképpen valósítható meg. Egyik, mikor a java alkalmazás

egyesével kérdezi le a virtuális gépek állapotát a hostról, míg a másik esetben az adott

host összes virtuális gép állapotát egyszerre kerül lekérdezésre, majd a java-s oldalon

feldolgozásra.

Mérésekkel összehasonlítható az idő alapján a két virtualizációs alkalmazás funkciói

(például, virtuális gép létrehozása, elindítása, leállítása, törlése), azonban ezek a mé-

rések csak tájékoztató jellegűek, mivel dolgozatom során ezeket az implementációkat

20

csak felhasználom, ezért a futási idejükre nincs közvetlen ráhatásom.

Az inicializálás során elkészült a lemezkép repository feltérképezése. Mérésekkel a

repository feltérképezésének módszereit lehet összehasonlítani. A megvalósításra került

kód szerint, a script a jegyzékeket listázza ki, majd a kívánt formába adja vissza. Másik

megoldás pedig, hogy egy fájlban már előre ki vannak gyűjtve valamilyen strukturált

adatszerkezetben az elérhető gépek.

A felvetett rendszer folyamatok összehasonlítása közül az első kettő mérést végeztem

el. A Legfontosabb terület az első, mivel cél, hogy csökkentve legyen az adatforgalom

és a virtuális gép indulási ideje is. A virtualizációs technikák összehasonlítása csak

tájékoztató jellegű információt ad, mivel annak sebességén módosítani a rendszerben

lévő kódok átírásával nem lehet. A repository listázás esetén pedig a jelenlegi kód

megfelelő sebességű (várhatóan 26-27ms körüli érték 24 lemezkép esetén 5.ábra). Az

inicializálás a virtuális gépek futtatása előtt csak egyszer fut le, így használat során

nem okoz terhelést.

Méréseimet három gépből álló zárt hálózaton végezem. Az első, ami kapcsolatban

áll az internettel, egy 4 magos, 4 giga RAM és VirtualBox virtualizációval telepített

számítógép. A második és harmadik gép is 2-2 magos, a második gép 2 giga RAM-mal

és VirtualBox virtualizációval rendelkezik, addig a harmadik gép 6 giga RAM-mal és

XEN-es virtualizációt használ. A gépek közötti belső hálózat pedig 10mbit/s sebességű.

Switch (10mbit/s)

Internet

1-es gép

4*2,66GHZ4 GB RAMVirtualBox

2-es gép

2*2,66GHZ2 GB RAMVirtualBox

3-as gép

2*2,66GHZ6 GB RAM

XEN

2. ábra: Mérésben résztvevő gépek.

21

6.2. Tömörítési algoritmusok mérése

A legfontosabb területen történő mérések esetén probléma, hogy a számítógépen belüli

másolási sebességhez képest, viszonylagosan kis áteresztő képességgel rendelkezik a

hálózati másolás, ezért a képfájlok méretét csökkenteni érdemes. Ennek legegyszerűbb

módja a tömörítés. Tömörített fájlok esetén kisebb lemezképet kapunk, így gyorsabban

lehet áttölteni a képfájlokat. A tömörítéseknek veszteségmentesnek kell lennie, mivel

kicsomagolás után az eredeti fájllal megegyezőnek lemezképet szeretnénk használni.

Többféle tömörítési eljárást is ismerünk.

Vizsgálataim során két fő algoritmus alapján implementált programokat vizsgálok.

Egyik ilyen a DEFLATE algoritmus, ami LZ77 és Huffman kódolás kombinációján alap-

szik (gzip, pigz). A gzip és pigz egymással kompatibilis fájlokat hoz létre, csak a pigz

több szálon fut, ezáltal jobban ki tudja használni a rendelkezésre álló erőforrásokat,

ezért gyorsabb, mint a gzip. A másik az LMZA (Lempel-Ziv-Markov chain-Algorithm)

algoritmuson alapuló 7zip implementációja a p7zip. A DEFLATE és az LMZA algorit-

mus is szótáralapú tömörítés. Az LMZA jobb tömörítési aránnyal rendelkezik cserébe

nagyobb memória és processzor-erőforrás igénye van. Ahhoz, hogy el tudjam dönteni,

melyik a számomra megfelelőbb módszer, össze kell hasonlítanom őket valamilyen mó-

don. Elsősorban a kérés kiadásától a használatba vétel között eltelt időt szeretném

gyorsítani. A virtuális gép elindításának legidőigényesebb része a korábban említett

áttöltés, illetve a kicsomagolás, ezért mérések során ennek a két folyamat elvégzésének

ideje alapján össze tudom hasonlítani a tömörítési eljárásokat.

A rendszerben használt script alapján, az erre vonatkozó részek átültetésével, (kép-

fájl átmásolása, illetve a tömörítések esetén a kicsomagolás) létrehoztam az eljárások

számára egy-egy új scripteket, amely az eredetivel megegyező módon, idő alatt mű-

ködik. A méréseket az IaaS rendszertől függetlenül végzem. Az automatikus mérések

miatt szükséges van egy olyan script, ami meghívja az elkészített scripteket. Ennek a

feladata, hogy a standard kimenetre a megfelelő formába alakítsa a várt információt. A

futási időket a time parancs segítségével határozom meg. Ügyelni kell a time parancs

kimenetével is, mivel a várt információnk nem a stantard, hanem az error outputra

22

kerül. Minden futtatás után visszaállítom alaphelyzetbe a rendszert (törlöm a fájlo-

kat, illetve memória puffert is ürítem), hogy a mérések egymást ne befolyásolhassák.

Ahhoz, hogy elérjem a szükséges mérésszámot, és mentésre kerüljön a várt információ,

egy újabb scriptet hoztam létre, melynek feladata az előbb említett Script futtatása

megadott mennyiségbe, illetve fájlba törtnő mentése a feladata.

Mérő script alapállapotba helyezés

tömörítésmentes 7zip pigz gzip

3. ábra: Mérés szekvencia diagramja.

A méréseket a korábban említett első, illetve második gépen végeztem (8.2-es mel-

léklet). Mindkét esetben a belső hálózatot használva történt a másolás. Mérésekhez

három az eljáráshoz szükséges forrásfájlokat hoztam létre. A tömörítésmenteshez a

disk.vdi-t (919 MB), a gzip, illetve pigz-hez a appliance.tgz-t (375.1 MB), illetve az

appliance.7z-t (269.9 MB) ami a 7zip algoritmushoz szükséges. Mindkét esetben 78

mérést végeztem, amelynek átlagidejét a 2. táblázat tartalmaz gépekre, illetve eljárá-

sokra bontva.

23

átlagidő Tömörítésmentes 7zip gzip pigz

1-es gép 1m 28,49s 1m 06,81s 45,09s 42,83s

2-es gép 1m 28,49s 1m 02,82s 51,58s 51,04s

2. táblázat. Mérések átlagideje.

A tömörítésmentesnél csak hálózati áttöltés történik és nem szükséges utána egyéb

művelet a lemezkép eléréséhez. A két gépnél az átlagérték megegyezik és mindkét

esetben azonos méretű lemezképeket töltünk át, így ebből következtethető, hogy a há-

lózatot mindkét esetben azonos sebességgel használta. A vizsgált 4 módszer közül ez

a leglassabb eljárás. 7zip esetében a legkisebb a fájl mérete, így azt tölti át a legha-

marabb a hálózaton. Az eredményekből látható, hogy a kicsomagolás sokkal nagyobb

erőforrást igényel a többinél, ezáltal tovább veszi el a rendszeren futtatható virtuális

gépektől az erőforrást. A két leggyorsabb módszer mindkét esetben a gzip, illetve a

pigz adta. Mivel mindkét esetben ugyanazokkal a fájlokkal dolgoztunk, ugyanolyan

hálózati sávszélességen töltötte át és egy-egy processzormagnak a tulajdonságai is azo-

nosak, csak a processzormagok számában térnek el, ezért megállapítható, hogy mindkét

eljárás több szálon fut, ezzel jobban kihasználva a hardver lehetőségeit. A második gép

esetén átlagban a két idő között 50 nanosec van, addig az első gép esetében a két futási

idő között már 3 másodperc körüli idő mérhető. Pigz párhuzamosított programnak

készült, ezért is tapasztalható a jobb idő arány, a gzippel szembe. Átlagidő alapján a

pigz tömörítési program használata javasolt.

szórás Tömörítésmentes 7zip gzip pigz

1-es gép 00,03s 00,09s 00,05s 00,11s

2-es gép 00,52s 00,18s 00,93s 00,55s

3. táblázat. Mérések szórása.

A szórás megmutatja, hogy egy-egy algoritmus mennyire stabil, tehát az átlag futási

időtől átlagosan mennyire tér el. Észrevehető, hogy az első gép esetében minden érték

kisebb mint a második gépnél, azonban mindkét mérésnél más-más sorrendet mutat

24

a stabilitás. A méréseket igyekeztem a lehető legkisebb módon befolyásolni, ezzel

elkerüljem a durva hibát.Mérések alatt a szükséges kommunikáción kívül más hálózati

aktivitás, illetve általam indított alkalmazás, szolgáltatás nem volt használatban. Az

átlagidőhöz képest kicsi az algoritmusok szórása, mind egy másodpercen belüli. Minden

mérés tartalmaz kisebb-nagyobb hibát, ezért pontos értéket nem tudunk meghatározni,

ezért is végzünk el, minden mérés többször. A mért adatoknál is megtalálható a hiba,

amelynek mértékét nem tudjuk előre meghatározni. Ezt nevezzük a méréstechnikában

véletlen hibának.

Az eljárás idejét tekintve a legjobb eredményt a pigz érte el, addig a legkisebb

lemezképfájlt a 7zip érte el. Szórásokat figyelembe véve a pigz és a 7zip is megfe-

lelő eredményekkel rendelkezik. A 7zip esetén a pigz-hez képest túl sokáig dolgozik,

és célkitűzésbe szerepel a gyors rendszerindítás, ezért a pigz implementáció kerül a

bevezetésre.

6.3. Állapotszinkronizációs mérés

Ennél az összehasonlító mérésnél az alapelgondolás szerint a java-s alkalmazásban min-

den virtuális gép maga kérdezi le az állapotát, így ahány gép van, annyi script futtatás

történik. Ezzel a megoldással, ha egy hoston nem csak egy gép fut, akkor többször

lefut ez a script. A másik megoldás szerint nem virtuális gépekként frissítünk, ha-

nem hosttonként. Ennek a megoldásnak az előnye, hogy kevesebbszer fordulunk a

hosthoz. Az implementáció a különböző virtualizációs technológiák esetén változhat.

Xen-es rendszer esetén a virtualizációs alkalmazás egyszeri meghívásával megkapjuk

a kívánt információkat, míg a VirtualBox-os rendszer esetében a kívánt információk

eléréséhez összességében többször kell a menedzser alkalmazástól(VBoxManage) infor-

mációt elkérni. Probléma, hogy segédalkalmazások futtatása az általános kiíratások,

listázásokkal szemben, egy lassabb művelet.

25

Loop

reset vms startvmmérés script vmlistening

resetvms

<<return>>

startvm

<<return>>

vmlistening

<<return>>

Loopamíg elkészül a

megadott

gépszám

amíg nem

használható

a gép

4. ábra: Host alapú szinkronizációs script szekvencia diagramja.

Mérésem célja, hogy idő alapján összehasonlítsam az említett két szinkronizációs meg-

közelítést. A méréseket VirtualBox-os és XEN-es virtualizációs környezetben is el kell

végezni. A virtuális gép alapú mérések során elegendő a script futási idejének a mé-

rése, mivel a java-s alkalmazás egy kész állapot kap meg értékül, aminél nincs szükség

további feldolgozásra. A hostalapú mérések során a hosttól kapott válaszban több vir-

tuális gép állapotinformációi is megtalálhatóak. A kapott információt először fel kell

dolgozni (parsolni), hogy az állapotokat az adott virtuális géphez tudjuk rendelni.

Ennek a folyamatnak az idejét a java-s alkalmazásban időbélyegek segítségével lehet

lemérni. Ezért szükségesek olyan mérések, amelyek a java-s rendszerből történnek,

azonban a virtuális gép indítása, lassú folyamat, ezért készül egy olyan script is, ami

a java-s alkalmazás helyett elindítja majd leállítja a virtuális gépeket, és közben az

állapotlekérdezéseket méri. A virtuális gépek indítása akkor kezdődik meg, ha az előző

indított rendszer teljesen betöltött és használatra kész.

26

Java-s alkalamzáson belüli méréseket a 2-es gépen végeztem el (8.3-as melléklet),

míg a script alapúakat, amelyek a java-s rendszertől függetlenek, mind a három gépen

(8.3-as melléklet). Minden esetben négy virtuális gépet hozok létre. A java-s rendszer-

ből történő méréseket lassabban lehet elvégezni, mivel minden esetben újra átmásolja

a lemezképet, majd beállítja és utána indítja csak el. Ennek gyorsítására készült el a

segédscript, ami pontosabb eredményt is nyújt. Java-s rendszerben azért pontatlanabb

a mérés, mivel ott a teljes időt mérem, amibe beletartozik a várakozási idő is. time

parancs esetén pedig a valós futási időt kapunk meg. A korábban már említett java-

s feldolgozási időt viszont mindenképpen le kell mérni a rendszerben. Ezért egy 500

mérésből álló méréssorozatot csináltam a 2-es gépen, amelyben mérem a feldolgozási,

illetve a script futtatási idejét is (mindkettőt időbélyegekkel). A mért eredmények átla-

gai, illetve szórása a 4. táblázatban megtalálható. A táblázatban a script futási idejét

Java-s feldolgozás Script futási idő

Átlag 0,4093493 ps 0,191925293 s

Szórás 1,3041838 ps 0,1358972308 s

4. táblázat. 2-es gépen Java-s rendszerben mért eredmények.

összehasonlítottam a későbbiekben azonos gépen mért script által vezérelt mérésekkel,

és közel azonos eredményeket adott. A Feldolgozási algoritmusnak az átlagideje töre-

déke a Script futási idejének, kevesebb, mint az eredmények szórása. A kis érték miatt

ez az idő elhanyagolható.

Későbbi mérések során a segédscript segítségével kapott eredményeket elemzem.

Az 1-es és a 2-es gépen VirtualBox virtualizációt, a harmadikon XEN-es technológiát

használok. VM alapú szinkronizációs táblázatnál az értékek azt jelzik, hogy mennyi idő

alatt kérdezi le az összes futó virtuális gépet. A két VirtualBox-os gép esetén közel azo-

nos idő alatt érhető el a kívánt információ mindkét módszer alatt, mivel a megvalósítás

is azonos módon történt. A fix különbség abból adódik, hogy a host alapú megoldásnál

még le kell kérnem a virtuális gépeket is, ami plusz időt jelent. A VirtualBox-os meg-

oldásoknál így a futási idő mindenképp függ a hoston futó virtuális gépek számától.

27

VM alapú 1.gép 2.gép 3.gép 4.gép

1-es gép 64,670ms 131,349ms 200,140ms 269,561ms

2-es gép 66,013ms 131,498ms 197,372ms 265,409ms

3-as gép 1607,743ms 1113,262ms 1406,754ms 1685,664ms

Host alapú 1.gép 2.gép 3.gép 4.gép

1-es gép 89,783ms 153,110ms 218,412ms 285,900ms

2-es gép 093,603ms 154,668ms 214,664ms 280,677ms

3-as gép 360,857ms 359,156ms 380,083ms 379,458ms

5. táblázat. Szinkroizációs mérések átlagideje.

Négy gép esetén kisebb a lekérdezési idő, mint a XEN-es rendszernél. XEN-es meg-

oldásoknál már nagyobb különbségek fedezhetőek fel. A leglassabb minden esetben

az eredeti elképzelés szerinti megoldás. A másik megoldás során 360ms körüli értéket

kapunk. Ennél is felfedezhető időnövekedés a gépek számától függően (például: két

gép esetén 20ms). A tömörítési méréseknél hasonlóan itt is törekedtem a durva hiba

VM alapú 1.gép 2.gép 3.gép 4.gép

1-es gép 4,192ms 7,624ms 11,556ms 11,800ms

2-es gép 11,253ms 23,538ms 30,729ms 37,099ms

3-as gép 332,452ms 377,861ms 275,904ms 232,503ms

Host alapú 1.gép 2.gép 3.gép 4.gép

1-es gép 4,504ms 7,316ms 10,388ms 12,331ms

2-es gép 21,867ms 27,176ms 33,147ms 45,388ms

3-as gép 148,296ms 120,964ms 134,658ms 120,262ms

6. táblázat. Szinkroizációs mérések szórása.

elkerülésére. Az algoritmusok stabilitását a mérések szórása jól ábrázolja. Legkisebb

szórással a VirtualBox rendelkezik (4,5-45,3 ms). Xen esetében itt is eltérő a két eset.

28

Első esetben 232 és 377 ms között volt a szórás, addig a host alapú méréseknél 120-148

ms között. A második eset egy gyorsabb és stabilabb algoritmusnak mondható.

Futási időben a XEN-es virtualizációnál tapasztalható jelentős változás, ahol egy

gép esetén 50%-os az időmegtakarítás, további futó gépek esetében pedig többszöröse.

VirtualBox használatánál a jelenlegi kialakítás mellett minimálisan 20ms-mal lassabb,

ami a virtuális gépek listázásából ered. A java-s feldolgozási idő elhanyagolható a script

futási idejével szemben. A Host alapú megoldást a nagyarányú XEN-es időmegtakarítás

miatt, és jelentősen nem változtat a VirtualBox megvalósítás esetén, tehát előnyösebb

használni.

6.4. Mérések összegzése

Az első mérés eredménye egyértelműen a pigz tömörítő eljárást hozta a legjobb ered-

ményként. A tömörített lemezkép egy debian rendszernek a lemezképe, amely tömö-

rítve a 919MB-nek csak a 40%-a. A többi vizsgált eljárás hosszabb időt vett igénybe.

A 7zip megoldásnak sikerült a leghatékonyabban összetömöríteni az eredeti képfájlt

(eredeti fájl 29,37%-a), de a tömörítési eljárás költséges, így több időt vesz igénybe a

többihez képest. Későbbiekben a pigz tömörítési eljárás kerül bevezetésre.

A szinkronizációs mérések esetén a VirtualBox alapú rendszerek használatában nem

okoz jelentős változást a kódváltozás (minimálisan nő a futtatási idő 20ms). A XEN-

es rendszereknél azonban legalább, 50% -os az időmegtakarítás. A vizsgált host alapú

mérésnél a 4. virtuális gép futtatásnál a VB 290ms, a XEN 380ms. A host alapú

algoritmus a XEN-es eredményekre alapozva hatékonyabb működéshez vezet, ezért ez

a módszer lesz használatos.

29

7. Konklúzió

Munkám során alapul vett alkalmazás sikeresen ki lett egészítve, illetve át lett alakítva

úgy, hogy VirtualBox-os környezetben futó gépeket is üzemeltethessen. Ezáltal a ki-

alakult rendszer már három virtualizációt támogat (XEN, VirtualBox, Amazon). Ki

alakításra került egy lemezkép nyilvántartó rész is, amely már elkészült virtualizációs

megoldáshoz szükséges lemezkép típusokat támogatja. Munkám során megtartottam

az eredeti célkitűzést úgy, hogy a projekt átlátható, egyszerű, kutatási célokat szolgáló

alkalmazás maradjon, mellyel méréseket lehet végezni.

Rendszer kialakításánál számos problémát kellet számbavenni. A VirtualBox imp-

lementálása hasonló módon történt, mint a XEN-es virtualizáció. A probléma a le-

mezképkezelés során merült fel. A VirtualBox többféle lemezképet is támogat, ezek

közül a vdi lett kiválasztva, mivel ennél a lemez mérete dinamikusan növekszik. A

XEN-el nincs közösen támogatott lemezkép típusa. A probléma, hogy nem garantált

a DHCP-s IP kiosztás, így manuális be kell tudni állítani a címet. Manuális beállítás

miatt fel kell tudni csatolni a lemezképet, amit a QEMU segédprogram segítségével

lett megvalósítva.

Szükségessé vált egy lemezképkezelő rendszernek is a kialakítása, aminek segítségé-

vel a gép létrehozásakor már csak egy azonosító szükséges ahhoz, hogy meghatározzuk

a kívánt lemezképet. A rendelkezésre álló lemezképeknél a fájlrendszer jegyzéknevei

alapján térképezi fel a host inicializálásakor.

Mivel már több vitualizációs technológiát is támogat a rendszer, és ahhoz, hogy

egységesen lehessen kezelni virtualizációtól függetlenül a gépek kiosztás, ezért a rend-

szernek kell eldöntenie, hogy melyik hostra, milyen virtualizációval hozza létre a kívánt

gépet. Ennek megvalósításához módosítani kellet a rendszerfelépítését a virtuális gép

létrehozásánál.

Fejlesztés során kialakításra került egy privát felhő, amely három gépből épül fel.

Mindhárom gépen Debian rendszer került installálásra. A kialakított rendszernek root

jogra van szüksége, így ha olyan rendszerre történik a telepítés, ahol ez tiltott, ott

engedélyezni kell. A kialakított tesztrendszeren méréseket is végeztem, amelynek ered-

30

ményeivel két fő területen sikerült célnak megfelelően jobb megoldást találni. Egyik

ilyen a lemezkép áttöltése. Ennél a vizsgált négy megoldás közül a pigz eredményei

voltak a legjobbak, ezért ennek a használata került bevezetésre. A másik vizsgálat

terület az állapotszinkronizációnál történt. Alapmegoldás szerint virtuálisgép alapon

történt, tehát a java-s alkalmazásban levő virtuálisgép reprezentációja intézte a szink-

ronizációt. A probléma olyan esetek során került elő, amikor egy hoston több virtuális

gép is futott, és mint a mérési eredmények is mutatják, XEN-es környezetben nagy

erőforrást foglal le az állapotlekérdezés. Ezért a másik megoldás, ami host alapon

történő szinkronizációt támogatja (egy hosttól egyszerre kéri el az összes rajta futó

virtuális gép állapotát) került bevezetésre, mivel XEN-es rendszerek esetén legalább

50%-os időmegtakarítás érhető el, míg VirtualBox alatt közel azonosak az eredmények.

Számos fejlesztési területen nyújt lehetőséget a rendszer. Ilyen például a lemezkép

forrásának a meghatározása a rendelkezésre álló hostok esetén. A VirtualBox szink-

ronizációs mérései során megfigyelhető, hogy ha egy hoston minél több gép fut annál

lassabb a script. Emiatt, illetve például még a hálózati terheltség miatt is fontos terü-

let, hogy a virtuális gépek indítása melyik hostra történjen.

Másik fejlesztési irány a szolgáltatási rétegnek kialakítása, amelyet az OCCI[2]

szabvány ad. Egy WEB-en keresztül elérhető HTTP szolgáltatási felület, aminek se-

gítségével lehet létrehozni, leállítani, újraindítani a virtuáls gépeket, illetve kezelni a

lemezképeket.

31

8. Mellékletek

8.1. Repository mérés grafikonja

5. ábra: 2-es gépen mért repository mérés grafikonja.

8.2. Tömörítési algoritmusok mérésének grafikonjai

6. ábra: 1-es gépen mért gzip eredmények.

32

7. ábra: 1-es gépen mért pigz eredmények.

8. ábra: 1-es gépen mért tömörítésmentes eredmények.

33

9. ábra: 1-es gépen mért 7zip eredmények.

10. ábra: 2-es gépen mért gzip eredmények.

34

11. ábra: 2-es gépen mért pigz eredmények.

12. ábra: 2-es gépen mért tömörítésmentes eredmények.

35

13. ábra: 2-es gépen mért 7zip eredmények.

8.3. Szinkronizációs megoldások mérésének grafikonjai

14. ábra: VM alapú 1-es gép: 1 virtuális gép futás esetén.

36



37



38



39


22. ábra: VM alapú 3-as gép: 1 virtuális gép futás esetén.

40



41


26. ábra: Host alapú 1-es gép: 1 virtuális gép futás esetén.

42



43



44



45


34. ábra: Host alapú 3-as gép: 1 virtuális gép futás esetén.

46



47


38. ábra: Host alapú 2-es gépen Java-s mérés (script futási idő). Mind a 4 virtuális

gép futása esetén.

48

39. ábra: Host alapú 2-es gépen Java-s mérés (java futási idő). Mind a 4 virtuális gép

futása esetén.

49

Hivatkozások

[1] http://en.wikipedia.org/wiki/diffie

[2] http://occi-wg.org/.

[3] http://qemu.org.

[4] https://support.opennebula.pro/entries/354633-opennebula-2-0-apis.

[5] https://www.virtualbox.org/.

[6] http://wiki.openstack.org/nova/apifeaturecomparison.

[7] http://www.eucalyptus.com/.

[8] http://www.w3.org/tr/wsdl.

[9] CSS Corp. OpenStack Compute Starter Guide, 2011.

[10] Váradiné dr. Szarka Angéla; Dr. Hegedűs János; Bátorfi Richárd; Unhauzer Attila.

Méréstechnika. HEFOP támogatásával, 2007.

[11] Budai Péter István and Dr. Goldschmidt Balázs. Egységes metamodell kialakí-

tása privát iaas cloud rendszerekhez. Budapesti Műszaki és Gazdaságtudományi

Egyetem Irányítástechnika és Informatika Tanszék, page 7, március 2012.

[12] Gabor Kecskemeti. Foundations of efficient virtual appliance based service dep-

loyments Foundations of efficient virtual appliance based service deployments Fo-

undations of efficient virtual appliance based service deployments Foundations of

efficient virtual appliance based service deployments. PhD thesis, University of

westminister, December 2011.

[13] D. Richard Kuhn, Vincent C. Hu, W. Timothy Polk, and Shu-Jen Chang. Beve-

zetés a publikus (nyilvános) kulcsú technológiába és a u.s. szövetségi kormányzati

pki infrastruktúrába. Országos Szabványügyi és Technológia Intézet, 2001.

50

[14] Jeanna N. Matthews. Xen a gyakorlatban – Útmutató a virtualizáció művészetéhez.

Prentice Hall, Bp., 2010.

[15] Peter Mell and Timothy Grance. The nist definition of cloud computing. National

Institute of Standards and Technology, 53(6):50, 2009.

[16] Daniel Nurmi, Rich Wolski, Chries Grzegorczyk, Graziano Obertelli, Sunil So-

man, Lamia Youseff, and Dmitrii Zagorodnov. The eucalyptus open-source cloud-

computing system. In Cluster Computing and the Grid, 2009. CCGRID’09. 9th

IEEE/ACM International Symposium on, pages 124–131. IEEE, 2009.

51

iaas felhő kialakításának újabb lehetőségei - tdk · tartalomjegyzék 1. bevezetés 3 2....

Documents