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

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épesek 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ásokhoz 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ítsé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 felü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 egymá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étrehozni. 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 Amazon 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épeket 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 kialakí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 inicializá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 felhő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, kezdetleges 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 megfelelő 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 1970es é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ézsé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ó), melynek 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 tevő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 feladata a tanúsítvány tartalmának ellenőrzése, információk feldolgozása, majd a szüksé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 megoldá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 sorá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 elhelyezü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 virtualizá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 haszná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 elszigeteltsé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 leglassabb 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ú rendszerek 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ódszerné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 interface, 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 ellehetetlenedé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ódosí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 teljesí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 teljes 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átszatá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 hiperfelü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. Hagyomá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 legalacsonyabb 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 tulajdonsá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 üzemelteté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, Linux, 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 virtualizáló emulátor.

10

Felvetés Ár Forrás

VirtualBox Ingyenes nyílt

WMware

Parallels

Qemu

VirtualPC

Fizetős

Fizetős

Ingyenes

Ingyenes

zárt

nyílt

zárt

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érté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 üzemelteté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 szoftverre 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 felhaszná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. Legelterjedtebb 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 formá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), valamilyen 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 szervezet. Hibrid felhő Ebben az esetben a teljes felhő privát és nyílt felhő alrendszerből is felépül. Szolgáltatási modell Software as a Service (SaaS) Legmagasabb absztrakciós szint, itt magá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 magá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, elindí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) felelő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 rugalmassá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 komponenseinek 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 magáé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 (Command 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ő szolgá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 rendszer 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 (Fizikai, 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ű rendszerek 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 lemezké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, összegyűjti a különböző erőforrásokat, elérhető címeket. Ezek az osztályok a Util alrendszerben 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 tunelt 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 tartalmaz. 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éldá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ő hostot 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. Rendelkezik 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 hasonló 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érdé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 átkonvertá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ó megvaló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üzemelteté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égzése. Ez elősegíti, hogy csak a szükséges programok kapjanak rendszergazdai jogosultsá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ódszer 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 virtuá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 technoló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. IaaS

HostPool

AdressPool ScriptHost

<< Host >> registerHost(Host)

createVM

Foreach elérhető hostokon, amíg sikertelen

acquireCPU

allocateAddress

<< IP >> createVM

ScriptVirtualMachine << VM >>

<< 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 rendszer először igényel a hostpool-ból egy erőforrást. A rendelkezésre álló erőforrás alapjá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 állapotá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 elkészített, működő rendszerben keresek olyan kódrészleteket, területeket, melyek újragondolá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 rendelkezé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üksé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ű.

Internet

1-es gép 4*2,66GHZ 4 GB RAM VirtualBox

2-es gép 2*2,66GHZ 2 GB RAM VirtualBox

Switch (10mbit/s)

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

21

3-as gép 2*2,66GHZ 6 GB RAM XEN

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 alapszik (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 algoritmus 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épfá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ájlokat, 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 mellé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 leghamarabb 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 azonosak, 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 megfelelő 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 minden 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, hanem 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) informá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

mérés script

reset vms

startvm

vmlistening

resetvms <> Loop

startvm

amíg elkészül a megadott gépszám

<> Loop

vmlistening

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 megkö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 virtuá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 rendszerbő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 javas 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 átlagai, 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öredé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 azonos 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 megoldá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

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

Host alapú

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 megoldá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 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

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

VM alapú

Host alapú

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 eredmé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 XENes 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 kialakult 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 implementálása hasonló módon történt, mint a XEN-es virtualizáció. A probléma a lemezké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 rendszernek 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 ered30

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 szinkronizá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 szinkronizá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 segítségével lehet létrehozni, leállítani, újraindítani a virtuáls gépeket, illetve kezelni a lemezképeket.

31

8. 8.1.

Mellékletek 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 deployments Foundations of efficient virtual appliance based service deployments Foundations 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. Bevezeté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 Soman, Lamia Youseff, and Dmitrii Zagorodnov. The eucalyptus open-source cloudcomputing 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

Recommend Documents