Kihagyás

Felhő rendszerek

Ez az anyagrész a ZH-n nem kerül számonkérésre.

A témáról bővebben esik szó az őszi félévben induló IoT-Felhő rendszerek szimulációja speckoll keretein belül.

A gyakorlat anyaga

Ebben a gyakorlati anyagrészben megnézzük a párhuzamos programozás és a felhő számítás kapcsolatát, illetve részletesebben megvizsgálunk egy infrastruktúra felhő működését szimuláló szoftvert.

A párhuzamos és az elosztott számítás két olyan megközelítés, amelyek célja, hogy hatékonyabbá tegyék a számítási feladatok végrehajtását. A párhuzamos számítás esetén egy (összetett) feladatot több processzor(mag) között osztanak szét, hogy egyszerre több részfeladatot végezhessenek el, ezáltal növelve a teljesítményt és gyorsítva a számítási folyamatot.

Az elosztott számítás esetében a rendszer komponensei térben elkülönülten helyezkednek el, és a hálózaton keresztül kommunikálnak egymással. Ilyen módon több számítógép vagy számítási egység összekapcsolódik és együtt dolgozik egy feladaton, a tipikus elosztott rendszerek közé tartozik a Grid, a Cloud vagy a P2P hálózatok. Egy felhőalapú párhuzamos számítási környezet lehetővé teszi a nagyobb számítási feladatok hatékonyabb és gyorsabb megoldását, miközben kihasználják az elosztott erőforrásokat.

Cloud Computing

Buyya et al. definíciója szerint "..A cloud is a type of parallel and distributed system consisting of a collection of interconnected and virtualized computers that are dynamically provisioned and presented as one or more unified computing resource..".

Érdemes összehasonlítani az elosztott rendszerek két fő irányát pár szempont szerint, a Grid Computing-ot és Cloud Computing-ot:

Grid Computing Cloud Computing
Erőforrások csoportosítása Több számítógép egy feladatra Virtualizáció segítségével egy számítógép több feladatot is elláthat
Tipikus használat Számításigényes feladatok, limitált idejű végrehajtás Hosszútávon futtatott szolgáltatások
Kapacitás Véges mennyiségű CPU, memória, tárhely "Végtelen" mennyiségű CPU, memória, tárhely
Célközönség Kutatók Üzleti
Hozzáférhetőség Grid köztesréteg Tipikus web protokollok (pl. REST)
Felügyelet Decentralizált Centralizált

A felhő alapú technológiát szolgáltatási szintek alapján három kategóriára oszthatjuk. Az infrastruktúra-szintű szolgáltatás (Infrastructure as a Service - IaaS), ami erőforrást, számítási kapacitást, virtualizáció lehetőségét biztosítja, például a Google Compute Engine. Egy platformszintű szolgáltatás (Platform as a Service - PaaS) az alkalmazás elkészítéséhez és futtatásához nyújt virtualizált környezetet, például a Google App Engine. A szoftverszintű szolgáltatás (Software as a Service - SaaS) magát a szoftvert nyújtja szolgáltatásként, például a Google Docs.

cloudlevel

További felhő tulajdonságok:

  • Globális (minimális válaszidő)

  • Költséghatékony (pay-as-you-go)

  • Rugalmasan skálázható (horizontális, vertikális)

  • Megbízható (replikált tárolás)

  • Biztonságos (fizikai, digitális védelem)

Felhő szolgátatás esetén számos kérdés merülhet fel mind az üzemeltető, mind a felhasználó szemszögéből.

  • Új VM ütemző algoritmust szeretnék bevezetni, hatékonyabb, mint az eddigi megoldások?

  • Bírni fogja az webalkalmazásom a karácsonyi vásárlási rohamot?

  • Mennyibe fog kerülni, mennyi energiát használ az otthoni időjárásmérő alkalmazásom egy tetszőlegesen választott felhőben futtatva?

Infrastruktúra felhők működésének tesztelése vagy viselkedésének tanulmányozása valós környezetben viszont nem minden esetben járható út. Gazdasági szempontból a virtuális szerverparkokban bérelt fizikai gépeken eltérő szenáriók futtatása más-más sávszélességet, processzor és memória erőforrásokat igényelnek, ezért ezek rendkívül költségesek lehetnek. Emiatt egyre inkább elterjedt a különböző felhő szimulátorok használata, amelyekkel lehetővé válik a valós világbeli rendszerek szimulációja realisztikus eredménnyel.

Az évek alatt számos különböző infrastruktúra felhő szimulátor jelent meg (CloudSim, DISSECT-CF) amelyek képesek felhők viselkedését megfelelő pontossággal lemodellezni, ezáltal alkalmassá váltak, hogy ezeket használhassuk a felhőt érintő kutatásokban. Használatukkal új virtuális gép ütemező, vagy energia fogyasztás mérők rendszerszintű beiktatása csupán egy-egy programozási feladat az adott környezetben.

Egy kutatás eredményessége nagyban függ attól, hogy milyen az adott szimulátor pontossága, részletessége. A jelenleg elérhető szimulátorokat két csoportra bonthatjuk:

  • Hálózati szimulációkon alapuló szimulátorok megfelelő használatához nagy részletességű hálózati működés meghatározása szükséges. Ennek szimulálása nagyon időigényes lehet, ezért kellő időráfordítás nélkül az eredmények pontatlanok lehetnek.

  • Az általános célú szimulátorok hátránya pont az elnagyolt hálózati működés, aminek oka a szimulációs idő röviden tartása. Előnye, hogy jobban skálázhatóak.

DISSECT-CF

A DISSECT-CF egy nyílt forráskódú, eseményvezérelt szimulátor, amely Java nyelven íródott és infrastruktúra felhők belső működésének tanulmányozását tűzte ki céljául, továbbá képes modellezni a virtuális infrastruktúra létrehozásakor megváltozó hálózati működést is.

A szimulátor főbb előnyei:

  • Modellezhető a teljes IaaS felhő szolgáltatás. Fizikai gépeken indíthatunk virtuális gépeket, amelyeket virtuális képfájlok alapján hoztunk létre. Lehetőség van virtuális gépek ütemezésére is. Rendelkezik tárhely szimulációval is, illetve a hálózati szimulációhoz szükséges komponensekkel is és a IaaS felhő energiafogyasztását is mérhetjük.

  • A DISSECT-CF sokkal pontosabban modellezi az IaaS felhők hálózati szolgáltatásait, mint a hasonló megoldások.

  • A virtuális infrastruktúra létrehozásakor fellépő hálózati forgalom szimulálását a legtöbb szimulátor nem tartalmazza, csupán a virtuális infrastruktúra használata során fellépő hálózati szolgáltatásaira fókuszál, és nem veszi figyelembe, hogy létrehozáskor fellépő hálózati forgalom kihathat a hálózat teljesítménymutatóira, így pontatlan hálózati szimulációt kapunk. A DISSECT-CF szimulátor egyszerre veszi figyelembe a virtuális infrastruktúra létrehozáskor és a használat során fellépő hálózati forgalmat.

dcfarc

Így tehát egy adott probléma vizsgálata a DISSECT-CF használatával lényegében a megfelelő szimulátor-beli kompononensek felhasználásával leprogramozható. A függőségek kezeléséhez és a kód menedzseléséhez Maven-t használ a szimulátor. A mintaprogramokat a Maven project Eclipse/IntelliJ-be történő importálásával érdemes kipróbálni.

Időzített események

A szimulátorok legtöbbike a DES modellt követi. A modell lényege, hogy a rendszer állapotához csak disztkrét időpillanatokban férünk hozzá, ezekben az időpillanatokban tudjuk a rendszerben szereplő komponenseket módosítani. Fontos, hogy ilyen rendszerek esetében a valós idő és a szimulációs idő kettéválik, ezt a modell egy belső óra segítségével valósítja meg. Azaz lényegében előfordulhatnak olyan esetek, amikor a valós időben csupán néhány perc telik el, addig a szimulációs idő már a rendszer több éves várható működését modellezte le.

Több programozási nyelvhez készült olyan könyvtárcsomag, amellyel tetszőleges nyelven tudunk DES alapú szimulátorokat építeni. Fontos még megjegyezni azt is, hogy az ilyen modellekben nagyon nagy jelentősége van az időegységnek, azaz hogy mi az a legkisebb időfelbontás, amely kettő diszkrét esemény között eltelik. Tipikusan ez miliszekundum, szekundum, esetleg perc.

A DISSECT-CF szimulátor esetén nem meglévő DES könyvtár került alkalmazásra, hanem a saját DES modelljét használja. Ennek a megközelítésnek az egyik nagy előnye, hogy tetszőleges időfelbontást tesz lehetővé, azaz egy időegység (amit DISSECT-CF esetén tick-nek nevezünk) bármilyen értéket reprezentálhat: nanoszekundum, hónap, év, stb. Természetesen bármely DES-re igaz, hogy a szimuláció csak akkor lesz helyes, ha minden idő(től függő) mértékegység azonos nagyságrendben szerepel.

DISSECT-CF esetén 2 fajta időzített eseményt különböztetünk meg, amellyel a szimuláció vezérelhető. Ezek az események akkor kerülnek végrehajtásra, ha feliratkoznak a szimulátor belső órájára.

  • Timed: visszatérő eseményeket tudunk vele létrehozni, azaz például minden 5 percben futtassunk le egy daemon szolgáltatást. Minden eseményhez tartozik egy ún. freq, azaz frekvenciaérték, amely kettő esemény közötti időt mondja meg

  • DeferredEvent: késleltett, egyszeri események létrehozása, tipikusan akkor alkalmazzuk, amikor egy esemény bekövetkezte után egy egyszeri feladatot még végre akarunk hajtani, azaz például ha minden fájl beérkezett a központi tárolóba, akkor töröljük ki az összes lokális másolatot. Az eseményt a delay, azaz a késleltetés mértéke határozza meg

Nézzünk is egy példát. A következő ábrán zöld és piros jelöli a Timed eseményeket, a kék pedig a DeferredEvent eseményeket. Természetesen minden eseményből tetszőlegesen sok létrehozható.

events

Egy egyszerű Timed eseményt megvalósító program:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
package hu.u_szeged.inf.demo;

import hu.mta.sztaki.lpds.cloud.simulator.Timed;

public class TimedTest extends Timed{

    String id;

    TimedTest(String id, long freq){
        this.id=id;
        subscribe(freq);
    }

    @Override
    public void tick(long fires) {

        if(Timed.getFireCount()>=500) {
            unsubscribe();
        }

        System.out.println(this.id+" - time: "+ Timed.getFireCount());
    }

    public static void main(String[] args) {    
        new TimedTest("TimedTest - 1", 100);  
        new TimedTest("TimedTest - 2", 95);

        Timed.simulateUntilLastEvent();
    }
}

Egy egyszerű DeferredEvent eseményt megvalósító program, amely használja az előző osztályt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
package hu.u_szeged.inf.demo;

import hu.mta.sztaki.lpds.cloud.simulator.Timed;
import hu.mta.sztaki.lpds.cloud.simulator.DeferredEvent;

public class DeferredEventTest extends DeferredEvent{

    public DeferredEventTest(long delay) {
        super(delay);
    }

    @Override
    protected void eventAction() {
        new TimedTest("TimedTest -2", 25);
    }

public static void main(String[] args) {
        new TimedTest("TimedTest - 1", 100);
        new DeferredEventTest(300);

        Timed.simulateUntilLastEvent();
    }
}

Azaz ahhoz, hogy időzített eseményeket tudjunk létrehozni, származtatnunk kell a Timed és/vagy a DeferredEvent osztályból a saját eseményünket leíró osztályt.

A következő metódusokra van szükség:

  • Timed.simulateUntilLastEvent(), simulateUntil(long time): Ezzel az utasítással tudjuk elindítani a belső órát, ezt követően az összes feliratkozott esemény végrehajtódik. A második esetben paraméterként meg tudjuk adni az időtartamot, hogy mennyi időt (és a hozzá tartozó eseményeket) szimuláljon a rendszer.

  • Timed.getFireCount(): A belső óra által mért eltelt idő

  • subscribe(long freq), unsubscribe(): Timed osztályból származó osztály fel- és leiratkozásért felelős függvénye. Paraméterben a kettő esemény közötti időt kell megadni

  • tick(long fires): A Timed osztályból származó osztály eseményét leíró metódus, amely újra és újra meghívásra kerül az objektum frekvenciájának megfelelően

  • eventAction(): A DeferredEvent osztályt megvalósító osztály eseményét leíró metódus. A késleltetés mértéke a konstruktorban kerül átadásra

Hálózat és tárhely

A DISSECT-CF szimulátorban a háttértárolót a Repository osztály valósítja meg. Felhős környezetben tipikusan egy ilyen tárolóban találhatóak az ún. virtuális képfájlok (szimulátor-beli megfelelője: VirtualAppliance), amelyből aztán a virtuális gépeket tudunk létrehozni (VirtualMachine). A szimulátorban Repository felel a hálózati kommunikációért. Állhat önmagában, illetve fizikai gépek (PhysicalMachine) háttértárolójaként is funkcionálhat, azaz kettő fizikai gép (vagy a fizikai gépen futó virtuális gép) közötti kommunikáció lényegében a gépek Repository objektumai között fog végbemenni. A Repository a fájlokat reprezentáló StorageObject-eket és VirtualAppliance-eket képes tárolni.

A Repository legfontosabb függvényei:

  • registerObject(StorageObject obj), deRegisterObject(StorageObject obj): A fájlt reprezentáló objektum lementése/kitörlése a tárolóból.

  • requestContentDelivery(String id, Repository target, ConsumptionEvent event): A fájl (id) elküldése egy másik tárolónak (target). Fájlküldés esetén lehetőségünk van annak sikeressége esetén egy ConsumptionEventAdapter esemény végrehajtására. Miután mentésre került a fájl, akkor a conComplete() metódusa kerül végrehajtásra. Azaz például szimulálhatnánk egy ilyen működést: Ha beérkezett a fájl, akkor küldjünk egy válaszüzenetet..

Amit még használunk a A következő példában, ahol három tároló közötti fájlmozgatás történik:

  • A DISSECT-CF szimulátor képes a fizikai/virtuális gépek energiafogyasztását mérni. Mi most ezzel nem foglalkozunk annak komplexitása végett, viszont a Repository konstruktora várja az ehhez kapcsolódó értékeket, így használjuk a PowerTransitionGenerator-t

  • A Repository csak akkor képes kommunikációra, ha állapota RUNNING. Ezt a setState(..) függvény segítségével állítjuk be.

  • Repository(final long capacity, final String id, final long maxInBW, final long maxOutBW, final long diskBW, final Map<String, Integer> latencyMap, Map<String, PowerState> diskPowerTransitions, Map<String, PowerState> networkPowerTransitions):

    • capacity: A tároló mérete, a kutatók tipikusan bájt mértékegységet használnak az egységesség kedvéért

    • id: A tároló azonosítója

    • maxInBW, maxOutBW, diskBW,: A tároló sávszélessége (bejövő, kimenő és "házon belüli" adat esetén). A mértékegységnek megfelelő értéknek itt van a jelentősége, például adott a következő internet sebesség: 70 Mb/s. Gondoljunk bele hogyan változtatna az eredményeken az, hogy a mértékegységek nem egységesen lennének kezelve.

    • latencyMap: A hálózatot leíró másik fogalom a késleltetés. Ahhoz, hogy egy hálózatba kössünk DISSECT-CF-beli objektumokat, létre kell hoznunk egy hálózatot leíró <String, Integer> párokból álló Map-et (az id és a késleltetés mértéke alapján). Itt tipikusan ms-ben dolgozunk

    • diskPowerTransitions, networkPowerTransitions: Az energiamérés paraméterei

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
package hu.u_szeged.inf.demo;

import hu.mta.sztaki.lpds.cloud.simulator.Timed;
import hu.mta.sztaki.lpds.cloud.simulator.energy.powermodelling.PowerState;
import hu.mta.sztaki.lpds.cloud.simulator.iaas.resourcemodel.ConsumptionEventAdapter;
import hu.mta.sztaki.lpds.cloud.simulator.io.NetworkNode;
import hu.mta.sztaki.lpds.cloud.simulator.io.NetworkNode.NetworkException;
import hu.mta.sztaki.lpds.cloud.simulator.io.Repository;
import hu.mta.sztaki.lpds.cloud.simulator.io.StorageObject;
import hu.mta.sztaki.lpds.cloud.simulator.util.PowerTransitionGenerator;
import java.util.EnumMap;
import java.util.HashMap;
import java.util.Map;

public class Transfer extends ConsumptionEventAdapter{

    Repository from;
    Repository to;
    StorageObject so;
    long start;

    static long storageSize = 1073741824;
    static int FileSize = 100;
    static long bandwidth = 1000;

    public Transfer(Repository from, Repository to, StorageObject so) throws NetworkException{
        this.from = from;
        this.to = to;
        this.so = so;
        this.from.registerObject(so);
        this.from.requestContentDelivery(so.id, to, this);
        this.start=Timed.getFireCount();
    }

    @Override
    public void conComplete() {
        this.from.deregisterObject(this.so);
        System.out.println("Start: " + this.start + " from: " +
                    this.from.getName() + " to: " + this.to.getName() + " end: " +Timed.getFireCount());
    }

    public static void main(String[] args) throws NetworkException  {

        final EnumMap<PowerTransitionGenerator.PowerStateKind, Map<String, PowerState>> transitions =
                PowerTransitionGenerator.generateTransitions(0, 0, 0, 0, 0);

        HashMap<String, Integer> latencyMap = new HashMap<String, Integer>();

        Repository r1 = new Repository(storageSize, "r1", bandwidth, bandwidth, bandwidth, latencyMap, 
                transitions.get(PowerTransitionGenerator.PowerStateKind.storage),transitions.get(PowerTransitionGenerator.PowerStateKind.network));

        Repository r2 = new Repository(storageSize, "r2", bandwidth, bandwidth, bandwidth, latencyMap,
                transitions.get(PowerTransitionGenerator.PowerStateKind.storage),transitions.get(PowerTransitionGenerator.PowerStateKind.network));

        Repository r3 = new Repository(storageSize, "r3", bandwidth, bandwidth, bandwidth, latencyMap,
                transitions.get(PowerTransitionGenerator.PowerStateKind.storage),transitions.get(PowerTransitionGenerator.PowerStateKind.network));

        r1.setState(NetworkNode.State.RUNNING);
        r2.setState(NetworkNode.State.RUNNING);
        r3.setState(NetworkNode.State.RUNNING);

        latencyMap.put("r1",5);
        latencyMap.put("r2",6);
        latencyMap.put("r3",7);

        new Transfer(r1,r2,new StorageObject("s12",FileSize,false));
        new Transfer(r1,r3,new StorageObject("s13",FileSize,false));

        new Transfer(r2,r3,new StorageObject("s23",FileSize,false));
        new Transfer(r2,r1,new StorageObject("s21",FileSize,false));

        new Transfer(r3,r2,new StorageObject("s32",FileSize,false));
        new Transfer(r3,r1,new StorageObject("s31",FileSize,false));

        Timed.simulateUntilLastEvent();

        System.out.println("r1: " + r1.contents());
        System.out.println("r2: " + r2.contents());
        System.out.println("r3: " + r3.contents());
    }
}

Virtuális gép és számítási feladat

Végezetül nézzük meg a korábban már említett, de még be nem mutatott VirtualMachine és a virtuális gépek által futtatott számítási feladat (ComputeTask) létrehozását.

A felhő egy olyan párhuzamos és elosztott rendszer, ahol egy hálózatba kapcsolt virtualizált számítógépek biztosítanak egységesített erőforrást. Ilyen erőforrás lehet többek közt például a tárhelyszolgáltatás vagy a számítási kapitás bérbaadása. Utóbbi tipikusan egy virtuális gép létrehozásával történik. Nézzük meg, hogy az AWS mennyiért ad bérbe egy virtuális gépet. A virtuális gép létrehozásának főbb lépései:

  • virtuális képfájl (~OS, szoftverek) feltöltése egy Repository-ba

  • A képfájl átmásolása a PhysicalMachine saját tárolójába

  • A virtuális gép telepítése a megadott tnstance type alapján (AlterableResourceConstraints) azaz hogy mennyi vCPU, vRAM fusson a virtuális gép alatt

  • A felhasználói hozzáférés biztosítása számítási feladatok (ComputeTask) létrehozásához

A következő utasításokat és metódusokat fogjuk használni:

  • PhysicalMachine(double cores, double perCorePocessing, long memory, Repository disk, int onD, int offD, Map<String, PowerState> cpuPowerTransitions)

    • cores: A fizikai gép processzormagjainak a száma

    • perCorePocessing: egy processzormagnak az ereje utasításfeldolgozás szintjén. Hogy megértsük ennek a jelentőségét érdemes megnézni ezt az oldalt: MIPS.

    • memory: A fizikai gép memóriájának mérete

    • disk: A fizikai gép Repository-ja

    • onD, offD: A boot-olás és leállítás szimulálása utasítások formájában

    • cpuPowerTransitions: Az energiamérés paraméterei

  • turnon(): A fizikai gép bekapcsolása. Csak akkor tud számítási feladatot végezni, ha RUNNING állapotba kerül.

  • VirtualAppliance(final String id, final double startupProcess, final long nl, boolean vary, final long reqDisk): A virtuális képfájl konstruktora

    • id: A képfájl azonosítója

    • startupProcess: A képfájlból készült virtuális gép boot-olásának szimulálása utasítások szintjén

    • nl: A hálózati forgalom szimulálása, amennyiben a virtuális képfájl nem az őt futtató fizikai gépen található

    • vary: A képfájl mérete random tényezőket is figyelembe vesz true esetén

    • reqDisk: A képfájl mérete

  • AlterableResourceConstraints(final double cpu, final double processing, final long memory): egy VM példány virtuális erőforrásait leíró konstruktora

    • cpu: A virtuális gép által használt CPU magok száma

    • processing: A virtuális gép által használt CPU magjának az erőssége

    • memory: A virtuális gép memóriájának a mérete

  • requestVM(final VirtualAppliance va, final ResourceConstraints rc, final Repository vaSource, final int count): A virtuális gép létrehozására szolgáló metódus

    • va: A képfájlra mutató referencia

    • rc: VM példány virtuális erőforrására mutató referencia

    • vaSource: A képfájlt tartalmazó Repository

    • count: Az ilyen beállításokkal futó virtuális gépek száma

    • newComputeTask(final double total, final double limit, final ResourceConsumption.ConsumptionEvent e): Egy számítási feladat konstruktura

    • total: Az utasítások száma

    • limit: Korlát, hogy mennyi utasítás lehet feldolgozva egy időegység alatt, itt tipikusan a maximális értéket engedjük meg. Azaz ha egy PM perCorePocessing-je 1, akkor a PM-en futó VM AlterableResourceConstraints-jának processing adattagja nem lehet nagyobb 1-nél. Ez a szám azt mondja meg, hogy 1 időegység alatt mennyi db utasítás kerülhet végrehajtásra 1 processzormagon

    • e: Esemény, amely által a következő forgatókönyv is akár megvalósítható: Miután a VM a feladatot elvégezte, küldjünk egy válaszüzenetet egy másik VM-nek 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
javapackage hu.u_szeged.inf.demo;

import java.util.EnumMap;
import java.util.HashMap;
import java.util.Map;
import hu.mta.sztaki.lpds.cloud.simulator.Timed;
import hu.mta.sztaki.lpds.cloud.simulator.energy.powermodelling.PowerState;
import hu.mta.sztaki.lpds.cloud.simulator.iaas.PhysicalMachine;
import hu.mta.sztaki.lpds.cloud.simulator.iaas.VMManager.VMManagementException;
import hu.mta.sztaki.lpds.cloud.simulator.iaas.VirtualMachine;
import hu.mta.sztaki.lpds.cloud.simulator.iaas.constraints.AlterableResourceConstraints;
import hu.mta.sztaki.lpds.cloud.simulator.iaas.resourcemodel.ConsumptionEventAdapter;
import hu.mta.sztaki.lpds.cloud.simulator.iaas.resourcemodel.ResourceConsumption;
import hu.mta.sztaki.lpds.cloud.simulator.io.NetworkNode;
import hu.mta.sztaki.lpds.cloud.simulator.io.Repository;
import hu.mta.sztaki.lpds.cloud.simulator.io.VirtualAppliance;
import hu.mta.sztaki.lpds.cloud.simulator.io.NetworkNode.NetworkException;
import hu.mta.sztaki.lpds.cloud.simulator.util.PowerTransitionGenerator;


public class VmTask {

    public static void main(String[] args) throws NetworkException, VMManagementException {

        final EnumMap<PowerTransitionGenerator.PowerStateKind, Map<String, PowerState>> transitions =
                PowerTransitionGenerator.generateTransitions(0, 0, 0, 0, 0);

        HashMap<String, Integer> latencyMap = new HashMap<String, Integer>();

        Repository repo = new Repository(17179869184L, "repo", 1000000, 1000000, 1000000, latencyMap, 
                transitions.get(PowerTransitionGenerator.PowerStateKind.storage),transitions.get(PowerTransitionGenerator.PowerStateKind.network));

        repo.setState(NetworkNode.State.RUNNING);

        PhysicalMachine pm = new PhysicalMachine(8, 1, 8589934592L,repo, 10, 10, transitions.get(PowerTransitionGenerator.PowerStateKind.host));

        pm.turnon();

        Timed.simulateUntilLastEvent();

        System.out.println("Time: " + Timed.getFireCount() + " PM state: " + pm.getState());

        VirtualAppliance va = new VirtualAppliance("va", 800, 0, false, 1073741824L);

        repo.registerObject(va);

        AlterableResourceConstraints arc = new AlterableResourceConstraints( 4, 1, 4294967296L);

        VirtualMachine vm = pm.requestVM(va, arc, repo, 1)[0];

        Timed.simulateUntilLastEvent();

        System.out.println("Time: " + Timed.getFireCount() + " PM state: " + pm.getState() + " VM state: " + vm.getState());

        vm.newComputeTask(100000, ResourceConsumption.unlimitedProcessing, new ConsumptionEventAdapter() {

            @Override
            public void conComplete() {
                System.out.println("Time: " + Timed.getFireCount());
            }
        });

        Timed.simulateUntilLastEvent();
    }   
}

Összefoglalás és kitekintés

Láthatjuk, hogy egy szimulációs eszköz segítségével lehetőségünk van valós felhő rendszereket modellezni, és ahogyan a valóságban is, úgy szimulációs körülmények között is rengeteg objektumot és azon paramétereit kell összehangolni egy sikeres és hatékony rendszer kiépítésének érdekében. Az itt látottakon kívül a DISSECT-CF számos olyan funkcióval rendelkezik amit érdemes lenne bemutatni, de egyúttal sajnos túlmútat a tantárgy keretein is.

Az egy hálózatba kapcsolt fizikai gépek IaaSService-t alkotnak. Egy ilyen szolgáltatáson számtalan virtuális gép indítható és azt, hogy melyik virtuális gép az IaaS melyik fizikai gépére kerüljön azt az aktuális scheduling policy dönti el. Ilyen rendszerek energiafogyasztásának mérése is egy fontos feladat.

Továbbá a jelenlegi internet használatot egyre több okoseszköz (például okostelefon, okosóra) megjelenése jellemzi, amely nagy mértékben megnövelheti az adatforgalmazást és tárolást. Egyes becslések szerint 2025-ra már több, mint 200 milliárd okoseszköz fog az internetre csatlakozni. Ez hatalmas gazdasági és informatikai potenciált rejt magában.

A dolgok internetét (Internet of Things - IoT) a jövő internetének meghatározó részeként tekintik, amely egy olyan dinamikus infrastruktúra, amely rendelkezik önkonfigurációs és adaptációs tulajdonságokkal, és a benne részt vevő eszközök emberi beavatkozás nélkül képesek együttműködő módon adatot és információt felfedezni, megosztani és feldolgozni.

Látható, hogy az IoT rendszerek nagyon szerteágazóak és rendkívül sokszínű alkalmazási területtel rendelkeznek, az emberközeli, viselhető eszközöktől a nagy kiterjedésű, elosztott szenzorhálózatokat igénylő rendszerekig. Az IoT jelen van az orvostudomány betegmegfigyelő rendszerében, vagy a városi forgalmat szabályzó rendszerben is, amiknek a működését a szenzorok által generált és a felho által feldolgozott adatok kiértékelése határozza meg. Más megfigyelőorendszerek is használják az IoT technológiát, például parkolóházak szabad helyeiről tájékoztatást nyújtó rendszereknél, ahol a parkolóhelyen beépített súlymérő szenzorok érzékelik, hogy foglalt-e a hely, vagy különböző súlymérő szenzorok használata annak eldöntésére, hogy a kihelyezett szelektív vagy más hulladékgyűjtők mennyire vannak tele. Ezek a rendszerek összességében alkothatják az okosváros paradigmát, mely rengeteg tervezési és kutatási lehetőséget biztosít.

A köd alapú technológia, azaz a Fog Computing fogalma 2015 környékén jelent meg. Ez nem egy független technológia, hanem a felhő alapú rendszerek egy olyan kiterjesztett változata, ahol a központi adatfeldolgozás mellett megjelennek a kliens közeli eszközök is. Ezeket a csomópontokat köd eszközöknek nevezzük, melyek saját számítási kapacitással rendelkeznek, így biztosítva valós idejű adatfeldolgozást. A köd alapú technológia az egyszerű felhő alapú megoldással szemben decentralizált, melyben a köd csomópontok mediátorként működnek a kliens és a felhő között. Ez az infrastruktúra lehetővé teszi a felhő tehermentesítését, azáltal, hogy az adat része vagy egésze lokális feldolgozásra kerül. A köd alapú technológia rengeteg előnnyel jár, továbbá az IoT eszközöket integráló hálózatok rendeltetésszerű működésének alapjait biztosítja. Mivel a köd csomópontok a klienshez fizikálisan közelebb helyezkednek el, ezért az alacsony válaszidővel valós idejű adatfeldolgozás érhető el.

fogtop

IoT Cloud kutatócsoportban több különböző módszerrel, többek között szimulációval is vizsgáljuk az IoT-köd-felhő rendszerek viselkedését.

Köszönetnyílvánítás

EZ A FEJEZET AZ INNOVÁCIÓS ÉS TECHNOLÓGIAI MINISZTÉRIUM ÚNKP-21-3 KÓDSZÁMÚ ÚJ NEMZETI KIVÁLÓSÁG PROGRAMJÁNAK A NEMZETI KUTATÁSI, FEJLESZTÉSI ÉS INNOVÁCIÓS ALAPBÓL FINANSZÍROZOTT SZAKMAI TÁMOGATÁSÁVAL KÉSZÜLT.

unkp

Kapcsolódó linkek

IoT Cloud kutatócsoport

DISSECT-CF szimulátor

Utolsó frissítés: 2025-05-05 09:47:35