This commit is contained in:
Pünkösd Marcell 2021-12-18 04:56:44 +01:00
parent cd997b8ef6
commit f859303a65
2 changed files with 21 additions and 2 deletions

View File

@ -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.

View File

@ -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