isleep
This commit is contained in:
parent
cd997b8ef6
commit
f859303a65
@ -92,6 +92,7 @@ Emellett természetesen a jelenlegi \acrshort{iot} szoftverben is módosítást
|
||||
\subsection{Implementáció}
|
||||
|
||||
\subsubsection{Előszűrő szolgáltatás}
|
||||
\label{sec:prefilter_service_implementation}
|
||||
|
||||
A mikroszolgáltatás fejlesztését \gls{python} nyelven végeztem. Azért ezt választottam, mert az \acrshort{iot} eszközön futó szoftver korábban abban íródott, ezért a releváns komponenseket könnyen át tudtam emelni.
|
||||
|
||||
|
@ -64,12 +64,25 @@ A következőkben a korábban bemutatott alkalmazásokat fogom megvizsgálni abb
|
||||
|
||||
Ebben az alkalmazásban a peremhálózati adatközpontba egy előszűrést megvalósító komponens kerül. Ennek a komponensnek a feladata, hogy a sok \acrshort{iot} eszköz által feltöltött hangminták által generált hálózati terhelést csökkentse azzal, hogy intelligens felismerést futtatva csak a releváns hangmintákat küldi tovább.
|
||||
|
||||
Ez a komponens állapotmentes és
|
||||
Ez a komponens állapotmentes, két kérés teljesítésének eredménye egymástól teljesen független. Ennek köszönhetően könnyen skálázható több példányra, hogy képes legyen nagy mennyiségű klienst kiszolgálni. Mivel a peremhálózati adatközpontokban -- a felhőhöz képest -- általában korlátozottan állnak csak rendelkezésünkre erőforrások, ezért nem tudjuk tetszőlegesen skálázni a feldolgozó szolgáltatásunkat.
|
||||
|
||||
Előfordulhat olyan helyzet, amikor a peremhálózat kifogy a számítási kapacitásból. Ilyen esetben is szeretnénk legalább annyi terhelést megtartani a használt peremhálózati adatközpontban, amennyit az teljesíteni képes a fennmaradó terhelést pedig szeretnénk átütemezni egy másik peremhálózati adatközpontba vagy végszükségben a felhőbe. Ezzel annyi sávszélesség kihasználtságot spórolni, amennyire csak képesek vagyunk.
|
||||
|
||||
\subsubsection{Ütemezési döntés meghozása}
|
||||
|
||||
Ebben az alkalmazásban azt szeretnénk megvalósítani, hogy ha egy adatközpontban fogytán van a számítási kapacitás, akkor más adatközpontokhoz tudjunk fordulni a feladataink végrehajtásával. Ebből következik, hogy szükségünk van arra, hogy mérjük egy adatközpont terheltségét.
|
||||
|
||||
A futó előszűrő szoftver komponens teljesítőképességéről egy jó jellemző a várakozási sorának hossza. \Aref{sec:prefilter_service_implementation}.\ szekcióban ismertetettek szerint a szolgáltatás fenntart egy várakozási sort, ahol a feldolgozásra váró adatokat állítja sorba. Ideális esetben, ha miden beérkező kérést időben el tud látni, akkor ennek a sornak a hossza stabil 1 körüli érték. Ha a szolgáltatás teljesítőképessége végéhez közeledik, akkor elkezdenek felgyűlni a feladatai, ezáltal a sorhossz monoton növekedésnek indul.
|
||||
|
||||
Szükség van támogatásra az előszűrő szolgáltatástól, hogy gyűjteni tudjuk a futó szolgáltatások belső sorhosszát.
|
||||
|
||||
\subsubsection{Ütemezés megvalósítása}
|
||||
|
||||
Mivel az előszűrő szolgáltatás állapotmentes működést valósít meg, ezért könnyedén lehet mozgatni az egyes adatközpontok között, illetve több példányban is futtatni egyszerre.
|
||||
|
||||
Az \acrshort{iot} eszközök egy előre beállított címre küldik a hangmintákat. Ez a cím az egyes adatközpontoknál más és más lehet. Mivel a szolgáltatásokat adatközpontok között mozgatjuk, ezért szükség van támogatásra a az eszközök részéről is, hogy dinamikusan meg tudjuk változtatni a küldés célját.
|
||||
|
||||
|
||||
\subsection{Robot vezérlés}
|
||||
|
||||
A felhő alapú robotkarok alkalmazásánál a peremhálózati adatközpontba egy vagy több alacsony szintű mozgást vezérlő komponens kerülhet. Ezek egymással egy osztott memóriát megvalósító \textit{Redis} adatbázison keresztül kommunikálnak. Ezek a komponensek belső állapottal rendelkeznek. Létrehozásukkor megkezdik a hozzájuk rendelt \textit{program} letöltését és futtatását. Ha a \textit{program} véget ért, akkor a komponensek kilépnek.
|
||||
@ -93,10 +106,15 @@ A vezérlést megvalósító szolgáltatás komponensek indításáért ebben az
|
||||
|
||||
\section{Ütemező rendszer}
|
||||
|
||||
Bár a két alkalmazás működése és igényei jelentősen eltérnek, szerettem volna egy olyan rendszert megalkotni, aminek segítségével mindkét alkalmazás ütemezése megoldható.
|
||||
|
||||
\subsection{Metrikák gyűjtése és felhasználása}
|
||||
|
||||
% bele van tolva influx db-be
|
||||
% Az infulxdbj nagyon jó mert tud egy csomó midnent például deriválni
|
||||
|
||||
\subsection{Algoritmus}
|
||||
|
||||
Egy ilyen algoritmusnak fel kell tudnia mérni, hogy melyik a legideálisabb környezet futtatni a szolgáltatást. Sajnos az, hogy mi számít ideális környezetnek, az erősen alkalmazás függő. Vannak alkalmazások, amelyeknél a késleltetés minimalizálása a kliensek felé a cél, de olyan is van, ahol pont a hálózati forgalom aggregálása a cél. Ezért a megfelelő algoritmus megalkotásához szükség van támogatásra a konkrét alkalmazástól.
|
||||
|
||||
%Egy ilyen algoritmusnak fel kell tudnia mérni azokat
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user