• Rezultati Niso Bili Najdeni

Arhitektura avtomatskega zagona eksperimentov

6https://github.com/

7https://github.com/logatec3/logatec-experiment

4 Razˇ siritev funkcionalnosti testnega omreˇ zja LOG-a-TEC

Testno omreˇzje omogoˇca samodejni zagon eksperimentov in z abstrakcijo meha-nizma se uporabniku ni potrebno vmeˇsavati v potek izvedbe [20]. Na ta naˇcin lahko uporabnik zaˇzene eksperiment in preprosto poˇcaka na konec, dobi opra-vljene meritve in jih analizira. Kaj se dogaja v testnem omreˇzju med potekom eksperimenta, pa uporabnik ne ve, kar se je v praksi izkazalo za pomanjkljivo funkcionalnost. Ali je naprava dobila repozitorij s tesno aplikacijo, ali so vse ˇ

zelene naprave vkljuˇcene v eksperiment, ali je infrastrukturna naprava uspeˇsno zgradila izvrˇsilno kodo za eksperimentalno napravo, ali se aplikacija izvaja in kako se izvaja? To so samo primeri nekaterih informacij, ki so kljuˇcne pri izvajanju tudi najpreprostejˇsih eksperimentov. Uporabnik poˇzene eksperiment in ˇcaka na rezultate, nevedoˇc kaj se dejansko dogaja v testnem omreˇzju. Tako je lahko v primeru napake zaman ˇcakal veˇc ur, samo da je ugotovil, da eksperiment sploh ni deloval pravilno.

Eksperimenti izvedeni s testnim omreˇzjem morajo biti ponovljivi, zato da lahko raziskovalci veˇckrat preizkusijo isti problem v podobnem okolju. Poslediˇcno mora testno omreˇzje zagotavljati tehnike ponovljivosti oz. moˇznost izvedbe ek-sperimentov v podobnih pogojih. Realizacija takˇsnega okolja je zahtevna, saj je delovanje naprav v testnem omreˇzju odvisno od veliko spremenljivk (kakovost omreˇzne povezave, delovna temperatura, motnje v okolju itd.). Poslediˇcno je za izvedbo takˇsnega okolja potreben nadzor nad ˇcim veˇcimi spremenljivkami in potekom dogodkov v testnem omreˇzju [10]. Osnoven primer je sinhron zagon eksperimentalne aplikacije na vseh vozliˇsˇcih v testnem omreˇzju. Trenutni sis-tem omogoˇca samodejni zagon eksperimentov, vendar se zaradi razliˇcne dolˇzine

27

ˇ

casa, ki ga potrebuje posamezna infrastrukturna naprava za pripravo okolja, ek-sperimenti na napravah ne zaˇcnejo soˇcasno. Moˇznosti zaustavitve ali ponovitve eksperimenta brez ponovnega zagona testno omreˇzje tudi ne ponuja. Nekatere zagate je moˇc reˇsiti preko povezave SSH in roˇcne prekinitve poteka eksperimenta, kar je pa v primeru omreˇzja z veliko vozliˇsˇci ˇcasovno potratno opravilo, saj se mora uporabnik loˇceno povezati na vsako vozliˇsˇce.

V primeru kompleksnejˇsih eksperimentov, na primer pri testiranju komunika-cijskih protokolov, je realno ˇcasovna interaktivnost s testnim omreˇzjem kljuˇcnega pomena. Poglavitna informacija za uporabnika je na primer stanje eksperimen-talnega omreˇzja, kot so informacije o naˇcinu oblikovanja omreˇzja, vrstni red in ˇcasovni potek pridruˇzevanja naprav omreˇzju ipd. Testno aplikacijo za pre-izkuˇsanje komunikacijskih protokolov je smiselno pognati v primeru, ko so vse zah-tevane naprave del eksperimentalnega omreˇzja. Pridruˇzevanje naprav k omreˇzju je zaradi nedeterministiˇcnosti teˇzko napovedati brez realno ˇcasovne informacije o stanju vozliˇsˇcnih naprav.

Nekateri eksperimenti temeljijo na opazovanju iskane meritve med samim iz-vajanjem testa. Uporabnik je do sedaj lahko le ˇcakal na prejete rezultate in naknadno opazoval in analiziral spremembe, namesto da bi jih lahko spremljal ˇze v realnem ˇcasu.

Zgoraj naˇsteti primeri so kljuˇcni razlogi, ki so nas privedli do odloˇcitve za nadgradnjo testnega omreˇzja LOG-a-TEC. Razˇsiritev smo poimenovali: sistem za spremljanje in nadzor eksperimentov (ang. experiment controll and monitoring system, ECMS). Podrobneje je opisana v naslednjih podpoglavjih, vkljuˇcno z opisom integracije v ˇze razvit sistem IMBA.

4.1 Analiza zahtev

Za pridobivanje podatkov iz poljubnega raˇcunalniˇskega sistema poznamo me-todi [4, stran 319 - 322]: monitor strojne opreme in monitor programske opreme.

Slednja, za nas pomembna metoda, je v raˇcunalniˇski sistem lahko vgrajena kot del operacijskega sistema ali pa kot aplikacija v njem. Podatke lahko pridobimo s postopki periodiˇcnega izvajanja meritev ali z izvajanjem meritev pogojenih z

4.2 Zasnova in uporabljene tehnologije 29

dogodki v operacijskem sistemu [4, stran 319 - 322]. V obeh primerih mora biti programska oprema monitorja ˇcim krajˇsa, da ne posega v delovanje operacijskega sistema in s tem ne vpliva na eksperiment. Hkrati morajo biti meritve opravljene preudarno, ker lahko preveliko ˇstevilo meritev predstavlja preobremenitev za vire raˇcunalniˇskega sistema. Poslediˇcno se mora nadzorni del za zajem podatkov na testnem vozliˇsˇcu izvajati soˇcasno s testno aplikacijo, prednost pa mora imeti sle-dnja.

Testno omreˇzje LOG-a-TEC se uporablja v raznovrstnih eksperimentih, tako z eksperimentalnimi napravami kot z infrastrukturnimi. Nadgradnja mora biti temu primerno univerzalna in prilagodljiva. Uporabniˇski vmesnik mora biti intu-itiven in preprost za uporabo ter integriran v ˇze razvito platformo SMS. Nazorno mora prikazovati stanja naprav med izvajanjem eksperimenta (npr. naprava je aktivna oz. izkljuˇcena iz eksperimenta, izvaja aplikacijo ali pa je z izvajanjem ˇ

ze zakljuˇcila ipd.). Jasno naj bo razviden prehod med stanji z moˇznostjo pri-kaza dodatnih informacij vozliˇsˇca. Sinhron zaˇcetek delovanja eksperimentalne aplikacije na veˇc napravah lahko doseˇzemo z uvedbo ukaza za zaˇcetek izvajanja meritev. Podobno naj bodo omogoˇceni tudi ukazi za zaustavitev in ponovitve eksperimenta. Uporabniku naj bo ponujen vmesnik za interakcijo z vozliˇsˇci, s katerim lahko poˇslje ukaze eni napravi, ali veˇc napravam hkrati.

Kot vsak nadzorni sistem naj tudi ta stremi k ˇcim veˇcji odzivnosti in posoda-bljanju stanj in informacij v realnem ˇcasu. V brezˇziˇcnem omreˇzju s senzorskimi napravami je doseganje realno ˇcasovnih odzivov naprav v pravem pomenu besede praktiˇcno nemogoˇce. Brezˇziˇcen prenos sporoˇcila iz ene naprave na drugo vnaˇsa zamudo, ravno tako obdelava sporoˇcila, zato v tem primeru sistem v realnem ˇcasu razumemo bolj kot sistem, ki se odzove “brez obˇcutne zakasnitve”[36, stran 214].

4.2 Zasnova in uporabljene tehnologije

Predhodno opisane zahteve smo naslovili z naˇcrtovanjem spletnega vmesnika za prikaz stanj in mehanizmom izmenjevanja sporoˇcil med vozliˇsˇci. Spletni vmesnik uporabniku prikazuje realno ˇcasoven pregled nad stanjem vozliˇsˇc v eks-perimentu in omogoˇca poˇsiljanje ukazov ter prejemanje odgovorov ciljnih naprav.

Mehanizem izmenjevanja sporoˇcil je namenjen posredovanju informacij med upo-rabnikom in napravami. Realizirali smo ga z uporabo centraliziranega pristopa, kjer ena naprava deluje kot centralni upravitelj vseh naprav v testnem omreˇzju.

Vsebuje bazo podatkov vseh vozliˇsˇc in njihovo realno ˇcasovno stanje. Uporabni-kov ukaz se na centralni napravi obdela in prenese do izbranega vozliˇsˇca, hkrati pa naprave same posodabljajo svoje stanje s poˇsiljanjem sporoˇcil na centralno napravo, le ta pa jih posreduje uporabniku. Diagram idejne zasnove prikazuje