Merge branch 'markosz-5' into 'master'
Added Markosz revision See merge request marcsello/dipterv!4
This commit is contained in:
commit
d5c64abbac
|
|
@ -10,21 +10,21 @@
|
|||
\chapter*{Kivonat}\addcontentsline{toc}{chapter}{Kivonat}
|
||||
|
||||
|
||||
Napjainkban szinte alapvetőnek tekinthető a felhőben üzemeltetett alkalmazások. Évről évre egyre nagyobb adoptációt érnek el de mégis vannak még olyan területek, ahol még várat magára, hogy szélesebb körben is alkalmazzák. Ilyen területnek számítanak azok az alkalmazások ahol a hálózati késleltetés egy kritikus tényező, vagy éppen a megfelelő sávszélesség nem áll rendelkezésre vagy túl költséges lenne a felhasználás helye és a felhő között.
|
||||
Napjainkban szinte alapvetőnek tekinthetők a felhőben üzemeltetett alkalmazások. Évről évre egyre nagyobb adoptációt érnek el, de mégis vannak még olyan területek, ahol még várat magára, hogy szélesebb körben is alkalmazzák. Ilyen területnek számítanak azok az alkalmazások, ahol a hálózati késleltetés egy kritikus tényező, vagy éppen a megfelelő sávszélesség nem áll rendelkezésre vagy túl költséges lenne a felhasználás helye és a felhő között.
|
||||
|
||||
Ilyen és ehhez hasonló problémákra adhat megoldást a peremhálózati infrastruktúra használata. A megfelelő alkalmazások a peremhálózati infrastruktúra lehetőségeivel kiegészítve képesek lehetnek egyes komponensekkel csökkentett késleltetéssel és kedvezőbb sávszélességi feltételekkel kommunikálni.
|
||||
Ilyen és ehhez hasonló problémákra adhat megoldást a peremhálózati infrastruktúra használata. A megfelelő alkalmazások a peremhálózati infrastruktúra lehetőségeivel kiegészítve képesek lehetnek egyes komponensekkel csökkentett késleltetéssel és kedvezőbb sávszélesség feltételekkel kommunikálni.
|
||||
|
||||
Peremhálózati rendszerek alkalmazásának rengeteg előnye ellenére még kevés olyan alkalmazás van, amely teljesen ki tudja használni azokat. Ennek oka az, hogy lévén viszonylag új keletű technológia még számos kérdés megoldatlan vele kapcsolatban.
|
||||
Peremhálózati rendszerek alkalmazásának rengeteg előnye ellenére még kevés olyan alkalmazás van, amely teljesen ki tudja használni azokat. Ennek oka az, hogy lévén viszonylag újkeletű technológia, még számos kérdés megoldatlan vele kapcsolatban.
|
||||
|
||||
A dolgozat célja, hogy konkrét alkalmazásokon keresztül mutassa be a azt, miképp lehet ezeknek a kérdéseknek egy részét megválaszolni és így sikeresen kihasználni a a peremhálózati infrastruktúra adta lehetőségeket, ezzel segítve ezen rendszere rendszerek adoptációjának további fejlődését.
|
||||
A dolgozat célja, hogy konkrét alkalmazásokon keresztül mutassa be a azt, miképp lehet ezeknek a kérdéseknek egy részét megválaszolni és így sikeresen kihasználni a a peremhálózati infrastruktúra adta lehetőségeket, ezzel segítve ezen rendszerek adoptációjának további fejlődését.
|
||||
|
||||
A dolgozat első részében rövid áttekintést nyújt a felhő és a peremhálózati infrastruktúrák felépítésébe és működésébe. Bemutat néhány lehetséges keretrendszert, amelyek segítségével megoldható a peremhálózati infrastruktúra bevonása az alkalmazásunkba. Ezekből egyet kiválasztva mutatja be a peremhálózati szolgáltatás létesítését két konkrét alkalmazáson keresztül.
|
||||
|
||||
Emellett részletesebben ismertetésre kerül a felhő és a peremhálózati rendszerek közötti dinamikus szolgáltatás elhelyezés problémája is. Itt konkrét alkalmazások kontextusán keresztül tárja fel a problémákat és tervez rájuk megoldást.
|
||||
Emellett részletesebben ismertetésre kerül a felhő és a peremhálózati rendszerek közötti dinamikus szolgáltatás elhelyezés problémája is. Itt konkrét alkalmazások kontextusán keresztül tárja fel a problémákat és ad rá megoldást.
|
||||
|
||||
Bemutatásra kerül egy egyedi tesztkörnyezet tervezése és telepítése, amelyben a korábban ismertetett alkalmazások tesztelésre kerülnek.
|
||||
|
||||
Végül összefoglalja az elért eredményeket és kitekintést ad a jövőbeli további fejlesztési lehetőségekre.
|
||||
A dolgozat végül összefoglalja az elért eredményeket és kitekintést ad a jövőbeli további fejlesztési lehetőségekre.
|
||||
|
||||
|
||||
\vfill
|
||||
|
|
@ -36,21 +36,21 @@ Végül összefoglalja az elért eredményeket és kitekintést ad a jövőbeli
|
|||
%----------------------------------------------------------------------------
|
||||
\chapter*{Abstract}\addcontentsline{toc}{chapter}{Abstract}
|
||||
|
||||
These days, applications hosted in the cloud are considered almost basic. They are gaining adoption year on year, but there are still areas where they have yet to be more widely adopted. Such areas include applications where network latency is a critical factor, or where the bandwidth is not available or would be too costly to transfer from the point of use to the cloud.
|
||||
These days, applications hosted in the cloud are considered almost fundamental. They are gaining in adoption year by year, but there are still areas where they have yet to be more widely adopted. Such areas include applications where network latency is a critical factor, or where high bandwidth is not available or would be too costly to transfer from the endpoint to the cloud.
|
||||
|
||||
Such and similar problems are attempted to be solved by using edge network infrastructure. The right applications may be able to use the capabilities of the edge infrastructure to communicate with certain components with reduced latency and better bandwidth conditions.
|
||||
Such and similar problems are attempted to be solved by using edge computing infrastructure. Applications may be able to use the capabilities of the edge infrastructure to communicate with certain components with reduced latency and better bandwidth conditions.
|
||||
|
||||
Despite the many advantages of using edge network systems, there are still few applications that can fully utilize them. The reason behind this is mostly because, being a technology relatively new, many issues remain to be resolved.
|
||||
Despite the many advantages of using edge computing systems, there are still few applications that can fully utilize them. This is mostly because, being a technology relatively new, many issues remain to be resolved.
|
||||
|
||||
The aim of this thesis is to show, through the example of specific applications, how some of these questions can be answered and thus successfully exploit the potential of edge network infrastructure, thus helping to develop the adoption of these systems further.
|
||||
The aim of this thesis is to show, through examples of specific applications, how some of these questions can be answered and thus successfully exploit the potential of edge computing infrastructure, thus helping to develop the adoption of these systems further.
|
||||
|
||||
In the first part of the thesis, a brief overview of the architecture and operation of cloud and edge network infrastructures is presented. It will outline some possible frameworks aim to help adopting cloud and edge network infrastructure into an application. One of these is chosen to demonstrate how to set up an edge network service using two specific applications.
|
||||
In the first part of the thesis, a brief overview of the architecture and operation of cloud and edge computing infrastructures is presented. It will outline possible frameworks aiming to help adopting cloud and edge computing infrastructures with applications. One of these frameworks is chosen to demonstrate how to set up an edge service using two specific applications.
|
||||
|
||||
In addition, the problem of dynamic service placement between the cloud and edge network systems will be described in more detail. Here, the problems are explored and solutions designed through the context of specific applications.
|
||||
In addition, the problem of dynamic service placement between the cloud and edge computing domains will be described in more detail. Here, the problems are explored, and solutions are designed through the context of specific applications.
|
||||
|
||||
The design and deployment of a custom test environment in which the previously described applications are tested is also discussed.
|
||||
The design and deployment of a custom test environment, in which the previously described applications are tested, is also discussed.
|
||||
|
||||
Finally, it summarises the results achieved and provides insights for future further development.
|
||||
Finally, the thesis summarises the results achieved and provides insights for future further development options.
|
||||
|
||||
\vfill
|
||||
\selectthesislanguage
|
||||
|
|
|
|||
|
|
@ -10,4 +10,4 @@ Külön szeretném megköszönni a Schönherz kollégiumban működő Kollégium
|
|||
|
||||
Kiemelném Rafael~László és Majthényi-Wass~Józsué nevét: nélkülük minden bizonnyal mérésre alkalmas hardver erőforrás hiányában maradtam volna a dolgozatom egyik legfontosabb pontján.
|
||||
|
||||
Emellett szeretném megköszönni barátnőmnek Alexának, családomnak és barátaimnak a végtelen támogatást amit tőlük kaptam.
|
||||
Emellett szeretném megköszönni barátnőmnek Alexának, családomnak és barátaimnak a végtelen támogatást, amit tőlük kaptam.
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
|
||||
\section{Összefoglalás}
|
||||
|
||||
A munkám első részében a felhő és peremhálózati számítástechnika alkalmazási területeit, jellemző felhasználási módjait tekintettem át. Megvizsgáltam több keretrendszert is, az ezek mögött rejlő ötleteket és megoldásokat és kiválasztottam az ideális környezetet a feladatom megvalósításához..
|
||||
A munkám első részében a felhő és peremhálózati számítástechnika alkalmazási területeit, jellemző felhasználási módjait tekintettem át. Megvizsgáltam több keretrendszert is, az ezek mögött rejlő ötleteket és megoldásokat és kiválasztottam az ideális környezetet a feladatom megvalósításához.
|
||||
|
||||
Az irodalomkutatás során szerzett ismeretek alapján olyan alkalmazásokat kerestem, amelyek működéséhez előnyösen járul hozzá a peremhálózati rendszerek alkalmazása. Kutatásaim során kettő alkalmazást is találtam, amelyek egyenként különböző előnyeit képesek kihasználni a felhő és peremhálózati rendszerek együttes alkalmazásának. Az alkalmazásokat részletesen tanulmányoztam és bemutattam.
|
||||
|
||||
|
|
@ -18,12 +18,12 @@ Ezek után az elkészített tesztkörnyezetben demonstráltam a dinamikus kompon
|
|||
|
||||
\section{Jövőbeni tervek}
|
||||
|
||||
Az elkészült ütemező rendszert tekintve érdekes fejlesztési irány lenne megvizsgálni annak a lehetősségét, hogy miként lehetne általánossá tenni a működését annak érdekében, hogy könnyen lehessen újabb illeszteni hozzá. Jelenleg a rendszer elkészítése során csak az általam vizsgált alkalmazások igényeit és működését vettem figyelembe. Úgy vélem egy általános megoldás mindenképpen hiánypótló lenne jelenleg az iparban.
|
||||
Az elkészült ütemező rendszert tekintve érdekes fejlesztési irány lenne megvizsgálni annak a lehetőségét, hogy miként lehetne általánossá tenni a működését annak érdekében, hogy könnyen lehessen újabb illeszteni hozzá. Jelenleg a rendszer elkészítése során csak az általam vizsgált alkalmazások igényeit és működését vettem figyelembe. Úgy vélem egy általános megoldás mindenképpen hiánypótló lenne jelenleg az iparban.
|
||||
|
||||
Mint ahogy \aref{sec:birbnetes-evaluation}.\ alfejezetben is említettem, a peremhálózaton futó hangminta előszűrés áteresztő képessége szinte csalódáskeltően alacsony. Mindenképpen meg kell vizsgálni annak a lehetőségét, hogy miként lehet a dinamikus ütemezés kontextusában a skálázást is megvalósítani.
|
||||
|
||||
A robotkarok vezérlését megvalósító alkalmazás dinamikus ütemezésénél egy erős megkötés volt, hogy a közvetlen vezérlést megvalósító szolgáltatások belső állapottal rendelkeznek, így preemptív átütemezésük szinte megoldhatatlan. Úgy vélem, hogy megoldható lenne a vezérlési komponenseket állapotmentessé tenni illetve megoldani a biztonságos átütemezését az egyes komponenseknek miközben egy \textit{program} épp fut. Ezzel tovább lehet növelni az alkalmazás flexibilitását és ellenállását a bekövetkező hálózati változásoknak, ezzel is javítva a teljesítőképességét és megbízhatóságát a felhő alapú robotvezérlésnek.
|
||||
A robotkarok vezérlését megvalósító alkalmazás dinamikus ütemezésénél erős megkötés volt, hogy a közvetlen vezérlést megvalósító szolgáltatások belső állapottal rendelkeznek, így preemptív átütemezésük szinte megoldhatatlan. Úgy vélem, hogy megoldható lenne a vezérlési komponenseket állapotmentessé tenni, illetve megoldani a biztonságos átütemezését az egyes komponenseknek, miközben egy \textit{program} épp fut. Ezzel tovább lehet növelni az alkalmazás flexibilitását és ellenállását a bekövetkező hálózati változásokkal szemben, ezzel is javítva a teljesítőképességét és megbízhatóságát a felhő alapú robotvezérlésnek.
|
||||
|
||||
Implementációs szempontból úgy vélem hasznos ötlet lenne a várakozási sorok kiszervezése az egyes előszűrő szolgáltatásokból és egy közös várakozási sort fenntartani minden adatközpontban ahol a feldolgozó egység fut. Ennek az apró változtatásnak hála a skálázás megvalósításával sokkal hatékonyabb lenne az alkalmazás működése, hiszen az újonnan induló komponensek a korábban felgyűlt mintákon is tudnának dolgozni. Emellett egy-egy feldolgozó szolgáltatás kiesése nem járna adatvesztéssel.
|
||||
Implementációs szempontból úgy vélem hasznos ötlet lenne a várakozási sorok kiszervezése az egyes előszűrő szolgáltatásokból és egy közös várakozási sort fenntartani minden adatközpontban, ahol a feldolgozó egység fut. Ennek az apró változtatásnak hála a skálázás megvalósításával sokkal hatékonyabb lenne az alkalmazás működése, hiszen az újonnan induló komponensek a korábban felgyűlt mintákon is tudnának dolgozni, emellett egy-egy feldolgozó szolgáltatás kiesése nem járna adatvesztéssel.
|
||||
|
||||
% közös queue/site
|
||||
|
|
@ -19,7 +19,7 @@ Az első fejezet bemutatja a feladatot és a kutatás hátterét.
|
|||
|
||||
A második fejezetben részletesen bemutatom a felhő és a peremhálózati számítástechnikát és az azt megvalósító keretrendszereket.
|
||||
|
||||
A harmadik fejezet egy felhő és \acrshort{iot} alapú projektet mutat be, amely a szőlővidékek kártevővédelmére lett kifejlesztve. Emellett megvizsgálja a peremhálózati rendszerek alkalmazásának lehetőségét. És bemutatja annak tervezését és implementációját.
|
||||
A harmadik fejezet egy felhő és \acrshort{iot} alapú projektet mutat be, amely a szőlővidékek kártevővédelmére lett kifejlesztve. Emellett megvizsgálja a peremhálózati rendszerek alkalmazásának lehetőségét, és bemutatja annak tervezését és implementációját.
|
||||
|
||||
A negyedik fejezet egy gyártósori szcenáriót mutat be, ahol szintén körbejárja a peremhálózati rendszerek alkalmazásának lehetőségét, majd bemutatja az átalakítás tervezési és implementálási folyamatát.
|
||||
|
||||
|
|
@ -27,4 +27,4 @@ Az ötödik fejezet a végeszközöket kiszolgáló komponensek dinamikus mozgat
|
|||
|
||||
A hatodik fejezet egy teszt környezet tervezésével és kialakításával foglalkozik, majd a hetedik fejezet a korábban ismertetett két alkalmazás tesztelését mutatja be ebben a környezetben.
|
||||
|
||||
Ezután munkám eredményét a nyolcadik fejezetben foglalom össze.
|
||||
Ezután munkám eredményeit a nyolcadik fejezetben foglalom össze.
|
||||
|
|
@ -3,7 +3,7 @@
|
|||
\chapter{Alkalmazások tesztelése}
|
||||
%----------------------------------------------------------------------------
|
||||
|
||||
A peremhálózati adatközpontok lehetőségeinek dinamikus kihasználásra felkészített alkalmazásokat \aref{ch:test_system}.\ fejezetben ismertetett és felépített teszt környezetben egymástól függetlenül teszteltem. A környezet és a benne futó alkalmazások jól megfigyelhetőek voltak, így sikerült mindkét alkalmazás esetében egyértelmű következtetéseket levonnom. Az egyes alkalmazások mérésének körülményeit, kivitelezését és a mért értékeket a következőkben ismertetem.
|
||||
A peremhálózati adatközpontok lehetőségeinek dinamikus kihasználására felkészített alkalmazásokat \aref{ch:test_system}.\ fejezetben ismertetett és felépített teszt környezetben egymástól függetlenül teszteltem. A környezet és a benne futó alkalmazások jól megfigyelhetőek voltak, így sikerült mindkét alkalmazás esetében egyértelmű következtetéseket levonnom. Az egyes alkalmazások mérésének körülményeit, kivitelezését és a mért értékeket a következőkben ismertetem.
|
||||
|
||||
|
||||
% mit, miért, hogyan, mivel, eredmények, konklúzió
|
||||
|
|
@ -23,7 +23,7 @@ Az alkalmazás működésének teszteléséhez egy olyan forgatókönyvet állí
|
|||
|
||||
A mérés elvégezéséhez szükségem volt arra, hogy a klienseket emuláló virtuális gép képes legyen több \acrshort{iot} eszköz emulálására. \Aref{sec:birbnetes_short_desc}.\ alfejezetben ismertetett kétrétegű szoftver architektúra miatt ez könnyen kivitelezhető volt. Egy új platform illesztő szoftver komponenst implementáltam, amely az \acrshort{iot} eszközön lévő hardverelemeket emulálja. A mikrofon emulációja egy fixen felvett hangfájl tartalmát szolgálja ki a logikai résznek, a többi hardver elem működése pedig csak naplózásra kerül.
|
||||
|
||||
Miután ez megvolt egy egyszerű szkriptet készítettem, amely konfigurálható számú \acrshort{iot} hardver emulációját indítja el és felel az életciklusuk kezeléséért. Ennek segítségével a mérések során tetszőleges számú eszközt tudtam emulálni.
|
||||
Miután ez elkészült, egy szkriptet készítettem, amely konfigurálható számú \acrshort{iot} hardver emulációját indítja el és felel az életciklusuk kezeléséért. Ennek segítségével a mérések során tetszőleges számú eszközt tudtam emulálni.
|
||||
|
||||
\subsection{Mérés}
|
||||
|
||||
|
|
@ -48,17 +48,17 @@ Egy eszköz átütemezése nem orvosolta még a problémát, ezért átütemezet
|
|||
|
||||
A tesztek eredménye jól demonstrálja, az ütemező algoritmus és az átalakított alkalmazások helyes működését.
|
||||
|
||||
Elsőre kevésnek tűnhet a másodpercenkénti két minta feldolgozása a peremhálózati rendszeren. Ennek több oka is volt. A feldolgozás sebessége erősen függ az alkalmazást futtató számítógép számítási teljesítményétől. A teszt során a környezet Intel\textregistered \ Xeon\texttrademark \ X5675 processzor alapú szervergép futtatta. Ez a processzor 2011-ben jött ki \cite{intel_ark}. Azóta léteznek sokkal jobb számítási kapacitással rendelkező processzorok és szervergépek.
|
||||
Elsőre kevésnek tűnhet a másodpercenkénti két minta feldolgozása a peremhálózati rendszeren, ennek több oka is volt. Egyrészt a feldolgozás sebessége erősen függ az alkalmazást futtató számítógép számítási teljesítményétől. A teszt során a környezet Intel\textregistered \ Xeon\texttrademark \ X5675 processzor alapú szervergépen futott. Ez a processzor 2011-ben jelent meg \cite{intel_ark}, azóta léteznek sokkal jobb számítási kapacitással rendelkező processzorok és szervergépek.
|
||||
|
||||
A másik fő indok az alacsony feldolgozási kapacitás mellett a horizontális skálázás teljes hiánya. Az ütemező nem képes az elindított szolgáltatások skálázására. Így minden adatközpontban csak egy példányban futott az alkalmazás. Emiatt egyszerre csak egy minta kiértékelése történik, a többi minta addig vár a sorban. Horizontális skálázással a rendszer képes lenne kihasználni az adatközpontban elérhető teljes számítási kapacitást ami jóval nagyobb áteresztő képességet biztosítana.
|
||||
A másik fő indok az alacsony feldolgozási kapacitás mellett a horizontális skálázás teljes hiánya. Az ütemező nem képes az elindított szolgáltatások skálázására. Így minden adatközpontban csak egy példányban futott az alkalmazás. Emiatt egyszerre csak egy minta kiértékelése történik, a többi minta addig vár a sorban. Horizontális skálázással a rendszer képes lenne kihasználni az adatközpontban elérhető teljes számítási kapacitást, ami jóval nagyobb áteresztő képességet biztosítana.
|
||||
|
||||
Emellett feltűnő volt, hogy a rendszer nagyon lassan reagál a terhelésre és sokáig \enquote{tart neki} átütemezni a terhelést. Ez javítható lehet a paraméterek további optimalizálásával, hiszen jelentősen nagyobb terhelés esetén szükséges lehet a gyorsabb átütemezés.
|
||||
Emellett feltűnő volt, hogy a rendszer nagyon lassan reagál a terhelésre és sokáig tart átütemezni a terhelést. Ez javítható lehet a paraméterek további optimalizálásával, hiszen jelentősen nagyobb terhelés esetén szükséges lehet a gyorsabb átütemezés.
|
||||
|
||||
\section{Robotkar vezérlés dinamikus ütemezése}
|
||||
|
||||
\subsection{Környezet}
|
||||
|
||||
Az alkalmazás teszteléséhez feltelepítettem az alkalmazást a felhő adatközpontot szimbolizáló klaszterbe. Ugyanebbe a klaszterbe telepítettem \aref{sec:scheduler}.\ alfejezetben ismertetett ütemező szoftvert metrika gyűjtő komponenseit is, mivel itt nem volt szükség az ott ismertetett ütemező futtatására.
|
||||
Az alkalmazás teszteléséhez feltelepítettem az alkalmazást a felhő adatközpontot szimbolizáló klaszterbe. Ugyanebbe a klaszterbe telepítettem \aref{sec:scheduler}.\ alfejezetben ismertetett ütemező szoftver metrika gyűjtő komponenseit is, mivel itt nem volt szükség az ott ismertetett ütemező futtatására.
|
||||
|
||||
A robotkarok szimulálására \aref{sec:ursim_simulator}.\ alfejezetben ismertetett \textit{DockURSim} szoftvert futtattam két példányban. Mivel a vezérlő szolgáltatások \acrshort{ip} cím alapján kapcsolódnak az egyes robotkarokhoz, így a klienseket emuláló virtuális gépnek felvettem két \acrshort{ip} címet, az egyik szimulátor portjait az egyik címhez a másikat a másikhoz rendeltem. Így képes voltam két robotkar szimulálására.
|
||||
|
||||
|
|
@ -80,7 +80,7 @@ A mérés során a kliensek és az adatközpontok közötti késleltetést megfe
|
|||
\label{fig:latency}
|
||||
\end{figure}
|
||||
|
||||
Ezek után kezdeményeztem egy új \textit{program} futtatását a felhőben futó szolgáltatástól. A rendszer helyesen az \texttt{edge-1} adatközpontra ütemezte be a \textit{program} futtatását. Onnan sikeresen csatlakozott az emulált robotkarokhoz és hajtotta végre a \textit{program} futását.
|
||||
Ezek után kezdeményeztem egy új \textit{program} futtatását a felhőben futó szolgáltatástól. A rendszer helyesen az \texttt{edge-1} adatközpontra ütemezte be a \textit{program} futtatását. Onnan sikeresen csatlakozott az emulált robotkarokhoz és hajtotta végre a \textit{program} futtatását.
|
||||
|
||||
Lefutás után megváltoztattam a késleltetési értékeket úgy, hogy az eddig kedvező \texttt{edge-1} késleltetése nagyobb legyen, mint az \texttt{edge-2} adatközponté, ehhez utóbbi késleltetését csökkentettem.
|
||||
|
||||
|
|
|
|||
|
|
@ -97,7 +97,7 @@ Ha ezt ismerjük, akkor egy egyszerű minimum függvényt használva, ki tudjuk
|
|||
|
||||
A vezérlést megvalósító komponens belső állapottal rendelkezik, futás közbeni átütemezése ezért nem megvalósítható. A robotkarok mozgatása nem engedhet meg kiesést, hiszen a vezérlés elvesztése akár katasztrofális következményekkel is járhat. A belső állapottal rendelkező komponensek áthelyezése kiesés nélkül viszont komplex feladat.
|
||||
|
||||
Mivel \aref{sec:edge_layer_plans}.\ alfejezetben kikötöttük, hogy minden programnak biztonságos állapotba kell helyeznie a robotkarokat lefutása végén, illetve ebből az ismert állapotból legyen képes megkezdeni a vezérlést, ezért lehetőségünk van arra, hogy két lefutás között helyezzük át a programot.
|
||||
Mivel \aref{sec:edge_layer_plans}.\ alfejezetben kikötöttük, hogy minden programnak biztonságos állapotba kell helyeznie a robotkarokat lefutása végén, illetve ebből az ismert állapotból kezdje meg a vezérlést, ezért lehetőségünk van arra, hogy két lefutás között helyezzük át a programot.
|
||||
|
||||
Az áthelyezés így jelentősen leegyszerűsödik, hiszen csak arra van szükség, hogy a vezérlő komponenseket a megfelelő adatközpontban indítsuk el.
|
||||
|
||||
|
|
@ -110,36 +110,36 @@ Bár a két alkalmazás működése és igényei jelentősen eltérnek, szerette
|
|||
|
||||
\subsection{Metrikák gyűjtése és kiértékelése}
|
||||
|
||||
Mindkét alkalmazásban közös, hogy az ütemezési döntéseket az alakhamzásból gyűjtött metrikákra. Ezek a metrikák bár eltérő tulajdonságokat írnak le, gyűjtésük és kiértékelésük szempontjából nem különböznek egymástól.
|
||||
Mindkét alkalmazásban közös, hogy az ütemezési döntéseket az alakhamzásból gyűjtött metrikákra alapozza. Ezek a metrikák, bár eltérő tulajdonságokat írnak le, gyűjtésük és kiértékelésük szempontjából nem különböznek egymástól.
|
||||
|
||||
A gyűjtött metrikák minden esetben idősoros adatként kezelhetőek. Az idősoros adatok olyan mérések, amelyek meghatározott időközönként rögzítésre kerülnek. Egy rögzített adatpont mindig időhöz kötötten reprezentálja a megfigyelt pillanatnyi állapotot \cite{timeseries_basics}. Az alkalmazásaink állapotát idősoros adatként gyűjtve képesek vagyunk a döntési logika felépítésénél többfajta statisztikai kiértékelést is a döntések alapjául venni.
|
||||
|
||||
A metrikák gyűjtésére és kiértékelésére így egy központi megoldást terveztem. Gyűjtés során az egyes alkalmazás komponensek vagy mérő szoftverek elküldik a központi rendszerbe, amely idősorosan tárolja az adatokat. Ha egy ütemezési döntést végző szolgáltatásnak szüksége van arra, hogy a rögzített adatokon készített kiértékelést használja (például átlagolt értéket egy meghatározott idősávra), akkor innen le tudja kérni.
|
||||
A metrikák gyűjtésére és kiértékelésére így egy központi megoldást terveztem. Gyűjtés során az egyes alkalmazás komponensek vagy mérő szoftverek elküldik a központi rendszerbe, amely idősorosan tárolja az adatokat. Ha egy ütemezési döntést végző szolgáltatásnak szüksége van arra, hogy a rögzített adatokon készített kiértékelést használja (például átlagolt értéket egy meghatározott időtartamra), akkor innen le tudja kérni.
|
||||
|
||||
Ezt a szolgáltatás mindkét alkalmazás egyformán tudja használni.
|
||||
Ezt a szolgáltatást mindkét alkalmazás egyformán tudja használni.
|
||||
|
||||
\subsection{Ütemezési algoritmus}
|
||||
\label{sec:scheduling-algo}
|
||||
|
||||
Bár a robotkarokat vezérlő alkalmazásnál az ütemezést megvalósító algoritmus meghatározott fix időpontokban egy egyszerű minimum keresés a madárhang felismerő rendszer esetén ennél összetettebb megoldásra van szükség.
|
||||
Bár a robotkarokat vezérlő alkalmazásnál az ütemezést megvalósító algoritmus meghatározott fix időpontokban egy egyszerű minimum keresés a madárhang felismerő rendszer esetén, ennél összetettebb megoldásra van szükség.
|
||||
|
||||
Ebben az esetben nem csak a konténerek ütemezésére van szükség az egyes adatközpontok között, hanem arra is, hogy az \acrshort{iot} eszközök konfigurációját is frissítsük. Emellett az ütemezési események generálása sem előre meghatározott. Az algoritmusnak folyamatosan figyelnie kell a rendszer állapotát és szükség esetén be kell tudnia avatkozni.
|
||||
Ebben az esetben nem csak a konténerek ütemezésére van szükség az egyes adatközpontok között, hanem arra is, hogy az \acrshort{iot} eszközök konfigurációját is frissítsem. Emellett az ütemezési események generálása sem előre meghatározott. Az algoritmusnak folyamatosan figyelnie kell a rendszer állapotát és szükség esetén be kell tudnia avatkozni.
|
||||
|
||||
Egy ilyen viselkedést megvalósító naiv algoritmust terveztem, amely a próbálgatás módszerével keres egy megfelelő eloszlást a szolgáltatásoknak a peremhálózati adatközpontok és a felhő között és az ezekhez kapcsolódó \acrshort{iot} eszközök között.
|
||||
Egy ilyen viselkedést megvalósító naiv algoritmust terveztem, amely a próbálgatás módszerével keresi a szolgáltatások megfelelő elosztását a peremhálózati adatközpontok és a felhő között, és az ezekhez kapcsolódó \acrshort{iot} eszközök között.
|
||||
|
||||
Ahhoz, hogy a folyamatos felügyelet megvalósuljon, egy periodikusan futó algoritmust terveztem, amely rögzített időközönként felméri a rendszer állapotát és szükség esetén képes szolgáltatásokat mozgatni és konfigurációt frissíteni az eszközökön.
|
||||
|
||||
Az algoritmus periodikus futása során fel kell tudnia mérni, ha kedvezőtlen rendszer állapot áll fenn és döntést kell hoznia annak megoldása érdekében. A madárhang elemző rendszer esetében ilyen kedvezőtlen állapot ha a komponensek belső sorhossza monoton növekedésnek indul. Ilyen helyzetben a rendszer működése instabil. Stabilnak azt az állapotot tekinthetjük ha a sorhossz csökken, vagy konstans értékhez közelít.
|
||||
Az algoritmus periodikus futása során fel kell tudnia mérni, ha kedvezőtlen rendszer állapot áll fenn és döntést kell hoznia annak megoldása érdekében. A madárhang elemző rendszer esetében ilyen kedvezőtlen állapot, ha a komponensek belső sorhossza monoton növekedésnek indul. Ilyen helyzetben a rendszer működése instabil. Stabilnak azt az állapotot tekinthetjük, amikor a sorhossz csökken, vagy konstans értékhez közelít.
|
||||
|
||||
A sorhossz növekedésének detektálásához kihasználtam az idősoros adatokon végezhető kiértékelési lehetőségeket. Az algoritmus periodikus futása során az elmúlt időszak (konfigurálható időre visszamenően) deriváltját kérdezi le. Ebből adódóan, ha a derivált értéke nagyobb mint 0 akkor feltételezhető az instabil állapot, 0 és annál kisebb értékek esetén a rendszer stabilnak mondható.
|
||||
A sorhossz növekedésének detektálásához kihasználtam az idősoros adatokon végezhető kiértékelési lehetőségeket. Az algoritmus periodikus futása során az elmúlt időszak (konfigurálható időre visszamenően) deriváltját kérdezi le. Ebből adódóan, ha a derivált értéke nagyobb mint 0, akkor feltételezhető az instabil állapot, 0 és annál kisebb értékek esetén a rendszer stabilnak mondható.
|
||||
|
||||
Ha az algoritmus többszöri futás esetén is nullánál nagyobb értéket kap a sorhossz deriváltjára, akkor megkezdi a javító folyamatot. Ez a folyamat egy eszköz által küldött adatokat irányítja át másik felhőbe. Mielőtt frissíti az eszköz konfigurációját ellenőrzi hogy az új cél-adatközpontban fut-e a szolgáltatás egy példánya. Ha nem akkor előbb elindítja azt és miután az készen áll az adatok fogadására csak akkor ütemezi át a a küldést.
|
||||
Ha az algoritmus többszöri futás esetén is nullánál nagyobb értéket kap a sorhossz deriváltjára, akkor megkezdi a javító folyamatot. Ez a folyamat egy kiválasztott eszköz által küldött adatokat irányítja át másik felhőbe. Mielőtt frissíti az eszköz konfigurációját, ellenőrzi hogy az új cél-adatközpontban fut-e a szolgáltatás egy példánya. Ha nem, akkor előbb elindítja azt, és miután az készen áll az adatok fogadására, csak akkor ütemezi át a a küldést.
|
||||
|
||||
Ez a viselkedés hasonlít a korában ismertetett átterheléses mozgatásra. Azaz ha mozgatni kell, akkor csak azután teszi meg, hogy az \enquote{új} szolgáltatás készen áll, ez idő alatt a \enquote{régi} szolgáltatás dolgozza fel a kéréseket, így kiesés nélkül vihető véghez a szolgáltatások mozgatása.
|
||||
Ez a viselkedés hasonlít a korában ismertetett átterheléses mozgatásra. Azaz, ha mozgatni kell, akkor csak azután teszi meg, hogy az \enquote{új} szolgáltatás készen áll, ez idő alatt a \enquote{régi} szolgáltatás dolgozza fel a kéréseket, így kiesés nélkül vihető véghez a szolgáltatások mozgatása.
|
||||
|
||||
Annak eldöntése, hogy melyik adatközpontba kezdje el átütemezni a terhelést az algoritmus jelenlegi megoldásomban egy fix rangsort használ. Ahol egy előre rögzített listán minden egyes lehetőséget megvizsgál stabilitás szerint és ez alapján választja ki az ideális jelöltet.
|
||||
A jelenlegi megoldásomban egy fix rangsort használ annak eldöntése, hogy melyik adatközpontba kezdje el átütemezni a terhelést az algoritmus. A működése során egy előre rögzített listán minden egyes lehetőséget megvizsgál stabilitás szerint és ez alapján választja ki az ideális jelöltet.
|
||||
|
||||
Ilyen szintű naiv megoldás szuboptimális eredményt hozhat. Hiszen könnyen belátható, hogy hajlamos a vibrációra, azaz amikor egy terhelést folyamatosan oda-vissza ütemez két adatközpont között. Ez akkor fordulhat elő ha egy adatközpont működése stabil, de egy egységnyi terhelés (esetünkben egy \acrshort{iot} eszköz által küldött hangminták) már instabillá teszik.
|
||||
Ilyen szintű naiv megoldás szuboptimális eredményt hozhat, hiszen könnyen belátható, hogy hajlamos a vibrációra, azaz amikor egy terhelést folyamatosan oda-vissza ütemez két adatközpont között. Ez akkor fordulhat elő, ha egy adatközpont működése stabil, de plusz egy egységnyi terhelés (esetünkben egy \acrshort{iot} eszköz által küldött hangminták) már instabillá teszi.
|
||||
|
||||
Ennek a jelenségnek az elkerülésére az algoritmus megjelöli, ha egy adatközpontban instabil működés miatt el kellett mozgatnia onnan terhelést. Ez a jelölés egy idő után lejár, ideális esetben azután, hogy a rendszer ismét elérte a stabil állapotot. Mivel a stabil állapot nem vezet átütemezéshez, ezért itt már nincs jelentősége a jelölésnek.
|
||||
|
||||
|
|
@ -153,13 +153,13 @@ Azt, hogy ennek a táblázatnak a tartalmát hogyan szinkronizáljam az eszköz
|
|||
|
||||
Míg a \textit{push} alapú megoldás megoldás esetén a rendszer azonnal képes lehet értesíteni az eszközöket, sokkal komplexebb megoldást igényel, hiszen kezelni kell azokat a hiba lehetőségeket, amelyek felmerülhetnek a kommunikáció során és biztosítani, hogy ezeknek ellenáll az információ továbbítás.
|
||||
|
||||
Ezzel szemben \textit{pull} alapú megoldás esetén az eszközök ezt az információt működésük során periodikusan lekérhetik, és ennek megfelelően állíthatják át küldésük célját. Ebben az esetben a két lekérdezés között eltelt idő miatt nagyobb késleltetéssel értesülnek a változásról az eszközök, hiszen a táblában változott bejegyzésről csak a következő lekérésben tudnak értesülni. Emellett a folyamatos periodikus lekérdezés felesleges terhelést is jelent az ütemező rendszer számára, hiszen akkor is teljesítenie kell a kéréseket, ha nem változott semmi a konfigurációban. Cserében ebben az esetben nem okoz nagy problémát ha egy frissítés nem jut el az eszközhöz, vagy a frissítés pillanatában éppen nem elérhető az eszköz. A folyamatos lekérdezés miatt idővel konvergálni fog a helyes konfigurációhoz.
|
||||
Ezzel szemben \textit{pull} alapú megoldás esetén az eszközök ezt az információt működésük során periodikusan lekérhetik, és ennek megfelelően állíthatják át küldésük célcímét. Ebben az esetben a két lekérdezés között eltelt idő miatt nagyobb késleltetéssel értesülnek a változásról az eszközök, hiszen a táblában változott bejegyzésről csak a következő lekérésben tudnak értesülni. Emellett a folyamatos periodikus lekérdezés felesleges terhelést is jelent az ütemező rendszer számára, hiszen akkor is teljesítenie kell a kéréseket, ha nem változott semmi a konfigurációban. Cserébe ebben az esetben nem okoz nagy problémát, ha egy frissítés nem jut el az eszközhöz, vagy a frissítés pillanatában éppen nem elérhető az eszköz. A folyamatos lekérdezés miatt idővel konvergálni fog a helyes konfigurációhoz.
|
||||
|
||||
A konfiguráció leküldéséhez a periodikus lekérdezést választottam. Ennek oka az, hogy implementációja jelentősen könnyebb, mint az értesítési mechanizmus esetén. Emellett a konfiguráció változtatás nem időérzékeny: az átterheléses mozgatás miatt bizonyos mértékű késleltetés nem okoz problémát.
|
||||
|
||||
\subsection{Rendszer implementáció}
|
||||
|
||||
Az ütemező rendszerem megvalósítását \textit{Kubernetes} környezetben futtatható mikroszolgáltatás architektúrára terveztem. A rendszer vázlatos felépítése \aref{fig:turbomemer}.\ ábrán látható. Az egyes szolgáltatások és egyéb szoftver komponensek implementációját a következő szekciókban részletezem.
|
||||
Az ütemező rendszerem megvalósítását \textit{Kubernetes} környezetben futtatható mikroszolgáltatás architektúrára terveztem. A rendszer vázlatos felépítése \aref{fig:turbomemer}.\ ábrán látható. Az egyes szolgáltatások és egyéb szoftver komponensek implementációját a következő alfejezetekben részletezem.
|
||||
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
|
|
@ -168,40 +168,40 @@ Az ütemező rendszerem megvalósítását \textit{Kubernetes} környezetben fut
|
|||
\label{fig:turbomemer}
|
||||
\end{figure}
|
||||
|
||||
\subsubsection{Mérés kezelő}
|
||||
\subsubsection{Mérési adat kezelő komponens}
|
||||
\label{sec:birb-latency-collector}
|
||||
|
||||
Ez a szolgáltatás egy kívülről is elérhető interfészt valósít meg. Feladata a rendszer állapotát leíró mért adatok gyűjtése és azokról kiértékelések szolgáltatása. Ennek megvalósítására egy idősoros adatbázist használ. Az általam választott idősoros adatbázis az \textit{InfluxDB}.
|
||||
|
||||
Azért választottam az \textit{InfluxDB}-t, mert egy hatékonyan működő adatbázis sok hasznos funkcióval. Ilyen például a 2-es verzió óta beépített adatvizualizáció, így közvetlenül lehet a szoftvert arra használni, hogy a rögzített méréseket megtekintsük. Saját lekérdező nyelvén pedig sokféle adat aggregáció, transzformáció és kiértékelő funkcionalitás érhető el.
|
||||
|
||||
Új mérések érkezésekor a szolgáltatás eltárolja az információkat az adatbázisban. Ha szükség van kiértékelésre, akkor az \textit{InfluxDB} saját lekérdezőnyelvére fordítja a kérést és az adatbázis szoftverben futtatja azt le, így hatékonyan és egyszerűen tudja megkapni a kiértékelt adatokat, amelyeket válaszul ad a kérésre.
|
||||
Új mérések érkezésekor a szolgáltatás eltárolja az információkat az adatbázisban. Ha szükség van kiértékelésre, akkor az \textit{InfluxDB} saját lekérdezőnyelvére fordítja a kérést, és az adatbázis szoftverben futtatja azt le, így hatékonyan és egyszerűen tudja megkapni a kiértékelt adatokat, amelyeket válaszul ad a kérésre.
|
||||
|
||||
Ezt a szolgáltatást a robotkarok vezérlését megvalósító alkalmazás közvetlenül tudja használni az ütemezési döntés meghozatalára.
|
||||
|
||||
\subsubsection{Ütemezés nyilvántartó}
|
||||
\subsubsection{Ütemezés nyilvántartó komponens}
|
||||
\label{sec:birb-scheduler-teller}
|
||||
|
||||
Ezt a szolgáltatás kizárólag az intelligens madárhang elemző alkalmazás használja.
|
||||
|
||||
Ennek a szolgáltatásnak a feladata, hogy számontartsa az egyes eszközök jelenlétét illetve kiszolgálja számukra, hogy pillanatnyilag melyik adatközponthoz vannak rendelve. Az eszközök futásuk során ettől a szolgáltatástól tudják lekérni az ütemezési információikat.
|
||||
|
||||
Ha a szolgáltatásból egy eddig ismeretlen eszköz kéri le az ütemezését, akkor azt egy dinamikusan megválasztott \enquote{alapértelmezett} adatközponthoz rendeli. Ezután ezt az ütemezési döntést elmenti és innentől kezdve ugyanúgy van kezelve az új eszköz is, mint az összes többi.
|
||||
Ha a szolgáltatástól egy eddig ismeretlen eszköz kéri le az ütemezését, akkor azt egy dinamikusan megválasztott \enquote{alapértelmezett} adatközponthoz rendeli. Ezután ezt az ütemezési döntést elmenti, és innentől kezdve ugyanúgy van kezelve az új eszköz is, mint az összes többi.
|
||||
|
||||
A kiszolgált adatokat egy kulcs-érték adatbázisban tárolja. Ehhez \textit{Redis} adatbázist használtam, ennek oka az, hogy a \textit{Redis} támogatja az értékekhez lejárati idő rendelését. A lejárai idő leteltével az értékeket automatikusan törli. Ennek a segítségével számos funkcionalitást könnyebb volt implementálni. A \textit{Redis} támogatja továbbá az osztott memóriaként való funkcionalitást, amelyet kihasználva \aref{sec:birb-scheduler}.\ alfejezetben ismertetett szolgáltatással való kommunikációt megoldottam.
|
||||
|
||||
\subsubsection{Dinamikus újra-ütemező}
|
||||
\subsubsection{Dinamikus újra-ütemező komponens}
|
||||
\label{sec:birb-scheduler}
|
||||
|
||||
\Aref{sec:birb-scheduler-teller}.\ alfejezetben ismertetett szolgáltatás csak egy statikus hozzárendelést valósít meg az új eszközök és az adatközpontok között. Viszont ezek után nem változtatja meg a döntését. Ezeknek a döntéseknek a felülvizsgálatára és az \enquote{alapértelmezett} adatközpont dinamikus megváltoztatására szolgál ez a szolgáltatás.
|
||||
|
||||
Ez a szolgáltatás valósítja meg \aref{sec:scheduling-algo}.\ alfejezetben vázolt periodikusan futó ütemező algoritmust.
|
||||
|
||||
Futása során a kiértékelt metrikákat lekérdezi a \textit{Mérés kezelő} szolgáltatásból. Majd ezek alapján és az osztott \textit{Redis} adatbázisban tárolt információk alapján meghozza az ütemezési döntést. Szükség esetén \textit{Kubernetes} \acrshort{api} hívásokkal elindítja a \textit{KubeFed} által kezelt szolgáltatást a megfelelő adatközpontban majd ezek után az ütemezési döntést rögzíti a az adatbázisban. így legközelebb amikor az eszköz frissíti a konfigurációját már az újonnan indított szolgáltatáshoz küldi az információkat, ezzel megvalósítva a dinamikus átütemezést.
|
||||
Futása során a kiértékelt metrikákat lekérdezi a \textit{Mérési adat kezelő} szolgáltatásból. Majd ezek alapján és az osztott \textit{Redis} adatbázisban tárolt információk alapján meghozza az ütemezési döntést. Szükség esetén \textit{Kubernetes} \acrshort{api} hívásokkal elindítja a \textit{KubeFed} által kezelt szolgáltatást a megfelelő adatközpontban majd ezek után az ütemezési döntést rögzíti a az adatbázisban. Így legközelebb, amikor az eszköz frissíti a konfigurációját, már az újonnan indított szolgáltatáshoz küldi az információkat, ezzel megvalósítva a dinamikus átütemezést.
|
||||
|
||||
A szolgáltatás azt is ellenőrzi, hogy a kijelölt \enquote{alapértelmezett} adatközpont stabilnak számít-e. Ha nem, akkor ezt a beállítást is frissíti, így az új eszközök már másik adatközpontba kezdik el küldeni az adatokat.
|
||||
|
||||
Értelem szerűen ezt a szolgáltatást is csak az intelligens madárhang elemző alkalmazás használja.
|
||||
Értelemszerűen ezt a szolgáltatást is csak az intelligens madárhang elemző alkalmazás használja.
|
||||
|
||||
\subsection{Link késleltetés mérése}
|
||||
|
||||
|
|
@ -209,16 +209,16 @@ A robotkarokat vezérlő alkalmazás számára szükség van arra az informáci
|
|||
|
||||
Ennek a megvalósítására egy egyszerű szkriptet készítettem, amely leméri az összes adatközponttal szembeni késleltetést, majd ezeket elküldi \aref{sec:birb-latency-collector}.\ alfejezetben ismertetett szolgáltatás számára, amely így képes arról kiértékelést készíteni.
|
||||
|
||||
A késleltetés mérésére kézenfekvő megoldás lehet a hagyományos \acrfull{icmp} által biztosított \textit{Ping} kérésekkel mérni a körülfordulási időt. De ez csak egy nagyon limitált eredményt ad egy konkrét végponthoz.
|
||||
A késleltetés mérésére kézenfekvő megoldás lehet a hagyományos \acrfull{icmp} által biztosított \textit{Ping} kérésekkel mérni a körülfordulási időt. De ez nagyon limitált eredményt ad egy konkrét végponthoz.
|
||||
|
||||
Szerettem volna egy olyan megoldást készíteni, amely nem csak az adatközpont határán lévő, publikus címmel rendelkező végponthoz tudja mérni a késleltetést, hanem közvetlenül az ott futó szolgáltatások és a végpont közti kapcsolatot tudja mérni. Ennek hála a késleltetés nem csak a publikus hálózat állapotát, de az egyes adatközpontok belső hálózatáról is képet tud adni. Ezzel átfogóbb és pontosabb információt kapunk arról, hogy melyik adatközpontot érdemes használnunk.
|
||||
Szerettem volna egy olyan megoldást készíteni, amely nem csak az adatközpont határán lévő, publikus címmel rendelkező végponthoz tudja mérni a késleltetést, hanem közvetlenül az ott futó szolgáltatások és a végpont közti kapcsolatot tudja mérni. Ennek köszönhetően a mért késleltetés nem csak a publikus hálózat állapotáról, hanem az egyes adatközpontok belső hálózatáról is képet tud adni. Ezzel átfogóbb és pontosabb információt kapunk arról, hogy melyik adatközpontot érdemes használnunk.
|
||||
|
||||
Ezt úgy oldottam meg, hogy felkonfiguráltam egy egyszerű webszerver konténert, amely minden kérésre egyből egy üres válasszal válaszol. Ezt a konténert \textit{KubeFed} segítségével úgy futtattam, mint bármelyik másik szolgáltatást minden adatközpontban. Ezt a szolgáltatást kiajánlottam minden adatközpont publikus címére. A szkriptem pedig a \acrshort{http} kérés körülfordulási idejét méri.
|
||||
Ezt úgy oldottam meg, hogy felkonfiguráltam egy egyszerű webszerver konténert, amely minden kérésre egy üres válasszal válaszol. Ezt a konténert \textit{KubeFed} segítségével úgy futtattam, mint bármelyik másik szolgáltatást minden adatközpontban. Ezt a szolgáltatást kiajánlottam minden adatközpont publikus címére. A szkriptem pedig a \acrshort{http} kérés körülfordulási idejét méri.
|
||||
|
||||
Az így mért értékeket az ütemező fel tudja használni arra, hogy eldöntse, hogy melyik adatközpontra ütemezze be a robotkarok vezérléséhez szükséges szolgáltatást.
|
||||
|
||||
\subsection{Robotkarok vezérlésének átalakítása}
|
||||
|
||||
A robotkarok vezérlését megvalósító komponens a \textit{Kubernetes} \acrshort{api} interfészét használva indítja el \textit{KubeFed} segítségével az egyes \textit{programok} végrehajtását végző szolgáltatásokat. Ahhoz, hogy ezeket a szolgáltatásokat dinamikusan a legideálisabb környezetben indítsa el, arra van szükség, hogy szolgáltatás indítása előtt lekérje a \textit{Mérés kezelő} szolgáltatásból az egyes adatközpontok felé a cél telephely késleltetését, ezután pedig kiválassza azt, ahol legkisebb a késleltetés.
|
||||
A robotkarok vezérlését megvalósító komponens a \textit{Kubernetes} \acrshort{api} interfészét használva indítja el \textit{KubeFed} segítségével az egyes \textit{programok} végrehajtását végző szolgáltatásokat. Ahhoz, hogy ezeket a szolgáltatásokat dinamikusan a legideálisabb környezetben indítsa el, arra van szükség, hogy szolgáltatás indítása előtt lekérje a \textit{Mérési adat kezelő} szolgáltatásból az egyes adatközpontok felé a cél telephely késleltetését, ezután pedig kiválassza azt, ahol legkisebb a késleltetés.
|
||||
|
||||
A viselkedés implementálása egy \acrshort{http} \acrshort{api} hívást igényelt csak, közvetlenül az ütemezés kezdete előtt. Ezzel lekérte a szolgáltatásból a linkek késleltetésének középértékét az elmúlt két percre vetítve. Ezután egy minimum függvénnyel meghatározható volt, hogy melyik adatközpontban kerüljön ütemezésre a szolgáltatás.
|
||||
A viselkedés implementálása egy \acrshort{http} \acrshort{api} hívást igényelt csak, közvetlenül az ütemezés kezdete előtt. Ezzel lekérte a szolgáltatásból a linkek késleltetésének középértékét az elmúlt két percre vetítve. Ezután minimum függvénnyel meghatározható volt, hogy melyik adatközpontban kerüljön ütemezésre a szolgáltatás.
|
||||
Loading…
Reference in New Issue