Merge branch 'markosz-3' into 'master'

Markosz 3

See merge request marcsello/dipterv!2
This commit is contained in:
Pünkösd Marcell 2021-12-17 21:37:05 +00:00
commit c10479c8e2
6 changed files with 88 additions and 101 deletions

View File

@ -1,12 +1,12 @@
% !TeX root = ../thesis.tex
%----------------------------------------------------------------------------
\chapter*{\koszonetnyilvanitas}\addcontentsline{toc}{chapter}{\koszonetnyilvanitas}
%----------------------------------------------------------------------------
Szeretném köszönetemet kifejezni konzulensemnek, Dr.~Maliosz~Markosznak, amiért lehetővé tette, hogy egy ilyen remek témán dolgozzak és emellett a rengeteg segítséget, amit Dr.~Simon~Csabával közösen adtak munkám során.
Emellett köszönettel tartozom a Távközlési és Médiainformatikai Tanszék Nagysebességű Hálózatok Laboratóriumának (HSN LAB) és a Schönherz Kollégiumban található Schönherz Elektronikai Műhelynek (SEM), hogy biztosították számomra az eszközöket, szerszámokat és helyszínt a munkámhoz.
Emellett szeretném megköszönni családomnak és barátaimnak a végtelen támogatást amit kaptam.
% !TeX root = ../thesis.tex
%----------------------------------------------------------------------------
\chapter*{\koszonetnyilvanitas}\addcontentsline{toc}{chapter}{\koszonetnyilvanitas}
%----------------------------------------------------------------------------
Szeretném köszönetemet kifejezni konzulensemnek, Dr.~Maliosz~Markosznak, amiért lehetővé tette, hogy egy ilyen remek témán dolgozzak és emellett a rengeteg segítséget, amit Dr.~Simon~Csabával közösen adtak munkám során.
Emellett köszönettel tartozom a Távközlési és Médiainformatikai Tanszék Nagysebességű Hálózatok Laboratóriumának (HSN LAB) és a Schönherz Kollégiumban található Schönherz Elektronikai Műhelynek (SEM), hogy biztosították számomra az eszközöket, szerszámokat és helyszínt a munkámhoz.
Emellett szeretném megköszönni családomnak és barátaimnak a végtelen támogatást amit kaptam.
% lackó, Josh, kszk

View File

@ -27,11 +27,13 @@
Éves szinten komoly károkat tudnak okozni a szőlőtermő vidékeken a termést előszeretettel fogyasztó seregély madarak \cite{seregelykar}. Jelenleg kevés hatékony megoldás van arra, hogy a szőlősgazdák meg tudják védeni a termést ezen kártevőktől \cite{nk}.
A kártevő madarak hangalapú azonosítására dolgozott ki egy mesterséges intelligenciát alkalmazó megoldást diplomamunkája során Nagy Kristóf. Az ő munkájára alapoztunk ezt követően egy egy éves projekt munkát Torma Kristóffal jelen diplomamunkát megelőző évben, így itt csak rövid áttekintést szeretnék adni róla.
A kártevő madarak hangalapú azonosítására dolgozott ki egy mesterséges intelligenciát alkalmazó megoldást diplomamunkája során Nagy Kristóf. Az ő munkájára alapoztunk ezt követően egy egy éves projekt munkát Torma Kristóffal jelen diplomamunkát megelőző évben, aminek eredményeképpen elkészült a felhő környezetben futó madárhang felismerő rendszer.
%így itt csak rövid áttekintést szeretnék adni róla.
A Nagy Kristóf által megalkotott detekciós algoritmus felhasználást olyan megoldásban láttuk, ahol termőföldekre kihelyezett, nagy mennyiségben telepített \acrfull{iot} eszközök gyűjtik a hangmintákat és továbbítják a központi feldolgozó egység felé, amely a hangminták intelligens felismerését végzi. A kártékony madarak hangjának azonosítása után pedig valamilyen beavatkozást tudnak tenni a madarak elriasztásának érdekében (Például: a természetes ellenségeinek hangját lejátszani).
%A Nagy Kristóf által megalkotott detekciós algoritmus felhasználását olyan megoldásban láttuk, ahol
A rendszerben a termőföldekre kihelyezett, nagy mennyiségben telepített \acrfull{iot} eszközök gyűjtik a hangmintákat és továbbítják a központi feldolgozó egység felé, amely a hangminták intelligens felismerését végzi. A kártékony madarak hangjának azonosítása után pedig valamilyen beavatkozást tudnak tenni a madarak elriasztásának érdekében (például: a természetes ellenségeinek hangját lejátszani).
A fejlesztett rendszert hagyományos felhő architektúrára terveztük. Az \acrshort{iot} eszközök közvetlenül a felhőben futó szolgáltatásokkal kommunikálnak.
Az elkészült rendszer hagyományos felhő architektúrára épül. Az \acrshort{iot} eszközök közvetlenül a felhőben futó szolgáltatásokkal kommunikálnak.
\subsection{Intelligens felismerés}
@ -57,11 +59,11 @@ Működésének alapját az adja, hogy úgy próbálja az adathalmazt felosztani
\subsubsection{Konvolúciós Neurális Hálók}
A neurális hálók működésükben és felépítésükben a leginkább hasonlítanak az emberi agy működésére. Minden egyes neuronnak van egy bemenete és egy kimenete. A neuronok belsejében pedig egy aktivációs függvény van, amely alapján a kimenetet számolja. Ezeket a neuronokat rétegekbe szervezik, és oly módon kötik össze őket, hogy az egyes rétegekben lévő neuronok, az előttük lévő réteg kimenetét kapják meg bemenet gyanánt. Egy ilyen konstrukciót nevezünk neurális hálónak \cite{medium_nn}. A háló minden éle rendelkezik úgynevezett súlyozással, itt mi ezeknek a súlyozásoknak az összességét és magának a hálónak a felépítését egy csomagban modellnek nevezk.
A neurális hálók működésükben és felépítésükben a leginkább hasonlítanak az emberi agy működésére. Minden egyes neuronnak van egy bemenete és egy kimenete. A neuronok belsejében pedig egy aktivációs függvény van, amely alapján a kimenetet számolja. Ezeket a neuronokat rétegekbe szervezik, és oly módon kötik össze őket, hogy az egyes rétegekben lévő neuronok, az előttük lévő réteg kimenetét kapják meg bemenet gyanánt. Egy ilyen konstrukciót nevezünk neurális hálónak \cite{medium_nn}. A háló minden éle rendelkezik úgynevezett súlyozással, itt mi ezeknek a súlyozásoknak az összességét és magának a hálónak a felépítését egy csomagban modellnek nevezik.
A konvolúciós neurális hálóknak (\acrlong{cnn}; \acrshort{cnn}) nagyon széles felhasználási köre van, a mozgókép felismeréstől az ajánló rendszereken át a természetes nyelvfeldolgozásig. A konvolúciós neurális hálók a neurális hálók egy speciális fajtája, ahol az egyes rétegek konvolúciót valósítanak meg \cite{medium_cnn}.
Az alkalmazott megoldás a beérkező hangokból spektrogramot generál, majd ezeket képként értelmezve végez rajtuk felismerést. Mivel a konvolúciós neurális hálókat eredményesen használják képfelismerésre, ezért ez egy kézenfekvő megoldás itt is.
Az alkalmazott megoldás a beérkező hangokból spektrogramot generál, majd ezeket képként értelmezve végez rajtuk felismerést. Mivel a konvolúciós neurális hálókat eredményesen használják képfelismerésre, ezért ez kézenfekvő megoldás itt is.
\subsection{Telepített eszköz}
@ -69,21 +71,27 @@ A termőföldre telepített eszközök alacsony áramfogyasztású és következ
A telepítés helyének adottságaiból fakadóan, fontos, hogy képesek legyenek valamilyen rádiós interfészen kommunikálni, mivel a szőlő termő vidékeken ritkán áll rendelkezésre megfelelő vezetékesen kiépített informatikai infrastruktúra, illetve a termőföldek sokasága és mérete miatt sem könnyen kivitelezhető ez.
Munkánk során egy ilyen eszköz prototípusát is elkészítettük, mind hardver, mind szoftver tekintetében. Fontosnak tartottuk a platform bővíthetőségét, így ezt figyelembe véve terveztük meg azt.
%Munkánk során egy ilyen eszköz prototípusát is elkészítettük, mind hardver, mind szoftver tekintetében.
A prototípusként elkészült eszköznél fontos szempont volt a platform bővíthetősége, így ez figyelembe lett véve a tervezésnél.
\subsubsection{Hardver}
A hardver lényegében egy számítógép a szükséges perifériákkal együtt egy dobozba szerelve. Az eszköz egy későbbi változatának felépítés-blokkváza \aref{fig:birbox_hardware_blockschema}.\ ábrán látható.
A hardver lényegében egy számítógép a szükséges perifériákkal együtt egy dobozba szerelve. Az eszköz felépítés-blokkváza \aref{fig:birbox_hardware_blockschema}.\ ábrán látható.
\begin{figure}[h!]
\centering
\includegraphics[width=0.95\textwidth]{figures/birbox_hardware_blockschema}
\caption{A második reviziós \acrshort{iot} eszköz belső hardveres felépítésének blokkváza}
\caption{Az \acrshort{iot} eszköz belső hardveres felépítésének blokkváza}
\label{fig:birbox_hardware_blockschema}
\end{figure}
A rendszer lelkét adó számítógép egy \acrfull{rpi} mikroszámítógép 4-es modellje. Ez a modell 4 magos ARM processzorral és 8 Gigabyte memóriával rendelkezik. Ennek az az oka, hogy nem szerettük volna, ha már a fejlesztés szakaszában hardveres limitációkba ütköztünk volna. Terveink szerint, a kész rendszer esetén konkrét mérésekre és számításokra alapozzuk a hardverválasztást, de a fejlesztés során ne legyen teljesítméynbeli probléma. Népszerűségének köszönhetően a \acrlong{rpi} kellően jó közösségi támogatással rendelkezik, mind hardveres, mind pedig szoftveres szempontból.
A rendszer lelkét adó számítógép egy \acrfull{rpi} mikroszámítógép 4-es modellje. Ez a modell 4 magos ARM processzorral és 8 Gigabyte memóriával rendelkezik.
%Ennek az az oka, hogy nem szerettük volna, ha már a fejlesztés szakaszában hardveres limitációkba ütköztünk volna. Terveink szerint, a kész rendszer esetén konkrét mérésekre és számításokra alapozzuk a hardverválasztást, de
%hogy a fejlesztés során ne ütközzünk
%ne legyen
%teljesítméynbeli problémába.
Népszerűségének köszönhetően a \acrlong{rpi} kellően jó közösségi támogatással rendelkezik, mind hardveres, mind pedig szoftveres szempontból.
Az eszköz bemenetéül egy USB mikrofon szolgál. Ez egy egyszerű széles hatókörű konferencia mikrofon, amely eredeti funkcióját tekintve arra szolgál, hogy az asztal közepén az asztal körül ülők hangját képes legyen venni, így a tesztkörnyezetünkhöz is megfelelő lefedettséggel rendelkezik.
@ -95,28 +103,29 @@ Emellett a prototípus tartalmaz egy hangszórót és egy D osztályú erősít
A vezeték nélküli kommunikációs interfésze az eszköznek nincs fixen rögzítve. Az adott környezetnek és tesztesetnek megfelelő kiegészítővel látjuk el, ha szükség van rá. Ez lehet \acrshort{wifi} de \gls{4g} vagy akár \gls{5g} is.
A prototípus egy műanyag házba van beszerelve. Az összeszerelt prototípus \aref{fig:doboz}.\ ábrán látható. A fejlesztés és tesztelés megkönnyítésére egy RJ45-ös csatlakozó is beépítésre került, amelynek segítségével csatlakozhatunk az eszközre \acrshort{ip} protokoll felett. Az összeszerelés -- annak egyszerűségéből adódóan -- kézzel történt.
A prototípus egy műanyag házba van beszerelve. A fejlesztés és tesztelés megkönnyítésére egy RJ45-ös csatlakozó is beépítésre került, amelynek segítségével csatlakozhatunk az eszközre \acrshort{ip} protokoll felett. Emellett soros csatlakozó és egy USB port is kivezetésre került a különböző rádiós interfészek csatlakoztatásának megkönnyítésére. A doboz külső megjelenését \aref{fig:doboz}.\ és \aref{fig:doboz-ng}.\ ábra mutatja be. Összesen három ilyen eszköz készült. Az összeszerelés -- annak egyszerűségéből adódóan -- kézzel történt.
\begin{figure}[h!]
\centering
\includegraphics[width=0.8\textwidth]{figures/doboz}
\includegraphics[width=0.4\textwidth]{figures/doboz}
\caption{Összeszerelt prototípusa a telepített \acrshort{iot} eszköznek}
\label{fig:doboz}
\end{figure}
Az eszköz eredeti változatából később készült egy revízió, aminek kapcsán kapott egy soros csatlakozót és egy USB port is kivezetésre került a különböző rádiós interfészek csatlakoztatásának megkönnyítésére. Az új tervek alapján pedig további két modell épült. Az eszközök megjelenésbeli különbségét \aref{fig:doboz-ng}.\ ábra mutatja be.
\begin{figure}[h!]
\centering
\includegraphics[width=0.8\textwidth]{figures/doboz_new}
\caption{A második reviziós \acrshort{iot} eszközök csatlakozókkal és hangerő vezérlővel ellátott hátlapja}
\caption{\acrshort{iot} eszközök csatlakozókkal és hangerő vezérlővel ellátott hátlapja}
\label{fig:doboz-ng}
\end{figure}
Az eszköz tápellátása 5V-on történik, a használt tápegység 3A áram leadására képes, tapasztalatink szerint ez elegendő az eszköz stabil működtetésére. Az eszköz áramellátása természetesen nem csak hálózati táplálásról oldható meg. A tervek közt szerepelt napelemes és akkumulátoros megoldás is, de ezek
Az eszköz tápellátása 5V-on történik, a használt tápegység 3A áram leadására képes,
%tapasztalatink szerint ez
ami elegendő az eszköz stabil működtetésére. Az eszköz áramellátása természetesen nem csak hálózati táplálásról oldható meg.
%A tervek közt szerepelt napelemes és akkumulátoros megoldás is, de ezek
%nekünk kívül estek a munkánk témájából.
túlmutattak a kitűzött célokon.
Az ajánlásunk az, hogy bármilyen más áramellátást kívülről a telepített tápcsatlakozón keresztül kerüljön csatlakoztatásra.
%túlmutattak a kitűzött célokon.
%Az ajánlásunk az, hogy bármilyen más áramellátást kívülről a telepített tápcsatlakozón keresztül kerüljön csatlakoztatásra.
@ -145,7 +154,8 @@ A szoftver \gls{python} nyelven került implementálásra. A telepítése közve
\subsection{Felhő rendszer}
A felhő rendszerben futó szoftver architektúráját tekintve mikroszolgáltatásokból épül fel. Ez azért indokolt, mert így az egyes komponenseket könnyen lehet skálázni, ami egy ilyen sok végeszközt kiszolgáló rendszernél előny. Emellett bizonyos komponensei könnyen kicserélhetőek. Erre szükség is volt a fejlesztés során, amikor lecserélésre került a használt \acrshort{mi} algoritmus.
A felhő rendszerben futó szoftver architektúráját tekintve mikroszolgáltatásokból épül fel. Ez azért indokolt, mert így az egyes komponenseket könnyen lehet skálázni, ami egy ilyen sok végeszközt kiszolgáló rendszernél előny. Emellett bizonyos komponensei könnyen kicserélhetőek.
%Erre szükség is volt a fejlesztés során, amikor lecserélésre került a használt \acrshort{mi} algoritmus.
A rendszer fő része lényegében itt is egy csővezetéket (más néven feldolgozó szalagot) valósít meg, amelynek belépési pontja az \textit{Input Service} és kimenetei a hangmintákon végzett predikciók vagy esetlegesen automatizált riasztások az \acrshort{iot} eszközök felé. A feldolgozó szalag fázisai az egyes mikroszolgáltatások, amelyek önállóan tolják tovább az adatot mindig a következő szolgáltatásnak.
@ -171,12 +181,17 @@ A rendszert alkotó mikroszolgáltatások négy fő csoportra oszthatóak. Ezt a
\end{figure}
A rendszerhez készült két webes kezelőfelület is, ebből egyiket hallgatótársunk Kunkli Richárd fejlesztette. Az egyik felület -- amelyet mi készítettünk -- a rendszer belső működésébe enged betekintést és néhány paraméter egyszerű beállítására ad lehetőséget. A második, pedig inkább a rendszert használó felhasználók számára készült, itt többek közt a folyamatokat a szőlővidék térképén vizualizálva figyelhetjük meg.
A rendszerhez készült két webes kezelőfelület is.
%, ebből egyiket hallgatótársunk Kunkli Richárd fejlesztette.
Az egyik felület
%-- amelyet mi készítettünk --
a rendszer belső működésébe enged betekintést és néhány paraméter egyszerű beállítására ad lehetőséget. A második, pedig inkább a rendszert használó felhasználók számára készült, itt többek közt a folyamatokat a szőlővidék térképén vizualizálva figyelhetjük meg.
\subsubsection{Implementált mikroszolgáltatások}
Az általunk tervezett és implementált mikroszolgáltatások működése és felelősségei a következőek:
%Az általunk tervezett és implementált
A mikroszolgáltatások működése és felelősségei a következőek:
\begin{itemize}
\item \textbf{Input Service} Ez az a szolgáltatás, amely a felhőbe érkező hangfájlokat fogadja. Ennek a szolgáltatásnak a felelőssége ellátni az egyes hangmintákat címkével. Ezeket a címkéket lokálisan egy relációs adatbázisban is letárolja a hangfájlhoz tartozó egyéb információkkal együtt. A fogadott hangfájlt továbbküldi a \textit{Storage Service} számára. Miután az sikeresen eltárolta, ez a szolgáltatás az üzenetsorba publikál egy üzenetet, hogy értesítse a feliratkozókat az új hangminta érkezéséről.
@ -199,14 +214,16 @@ Az általunk tervezett és implementált mikroszolgáltatások működése és f
\subsubsection{Használt külső fejlesztésű szoftverek}
Az alkalmazás több \enquote{off-the-self} komponenst is használ ahhoz, hogy megvalósítsa a tervezett működést. Ezeket mi választottunk ki a tervezés során. A következőkben csak röviden bemutatom ezeket a komponenseket és a kiválasztásának okát.
Az alkalmazás több \enquote{off-the-self} komponenst is használ ahhoz, hogy megvalósítsa a tervezett működést.
%Ezeket mi választottunk ki a tervezés során.
A következőkben csak röviden bemutatom ezeket a komponenseket és a kiválasztásuk okát.
\begin{itemize}
\item \textbf{PostgreSQL} (Relációs Adatbázis): Második legnépszerűbb nyílt forráskódú relációs adatbázis kezelő rendszer, kifejezetten alacsony erőforrás igényekkel, valamint igen fejlett képességekkel rendelkezik. Rendkívül jó a közösségi támogatása. A fejlesztés előtt volt már vele korábbi tapasztalatunk.
\item \textbf{PostgreSQL} (Relációs Adatbázis): Második legnépszerűbb nyílt forráskódú relációs adatbázis kezelő rendszer, kifejezetten alacsony erőforrás igényekkel, valamint igen fejlett képességekkel rendelkezik. Rendkívül jó a közösségi támogatása. %A fejlesztés előtt volt már vele korábbi tapasztalatunk.
\item \textbf{MinIO} (Objektum tár): Nagy teljesítményű Objektum tár, amely az Amazon S3 \acrshort{api}-ját implementálja. Egyenesen \textit{Kubernetes} környezetbe tervezve. Egyszerűen használható és telepíthető. Emellett rendelkezik a fejlesztőktől származó \gls{python} implementációval, melyhez könnyen kezelhető \textit{Flask} plugin is tartozik.
\item \textbf{InfluxDB} (Idősoros adatbázis): Az \textit{Influx Data} által fejlesztett idősoros adatbázis. Rendkívül hatékonyan tud az adatokon műveleteket végezni, az \acrshort{api} kezelése egyszerű és intuitív. A fejlesztés előtt volt már vele korábbi tapasztalatunk.
\item \textbf{InfluxDB} (Idősoros adatbázis): Az \textit{Influx Data} által fejlesztett idősoros adatbázis. Rendkívül hatékonyan tud az adatokon műveleteket végezni, az \acrshort{api} kezelése egyszerű és intuitív. %A fejlesztés előtt volt már vele korábbi tapasztalatunk.
\item \textbf{RabbitMQ} (Üzenetsor): \textit{Erlangban} írt, népszerű, nyílt forráskódú üzenetsort megvalósító rendszer. Kezelése kifejezetten egyszerű és rendelkezik \gls{python} \acrshort{api}-val, valamint rendkívül jó minőségű dokumentáció érhető el hozzá.
@ -219,4 +236,6 @@ A mikroszolgáltatás architektúrának és a megfelelő tervezésnek köszönhe
Az \acrshort{iot} eszközök a felhővel való kommunikáció során hibrid módon használnak \acrfull{http} vagy \acrfull{mqtt} protokollt. Ezt a hibrid megoldást indokolja, hogy előfordul, hogy az eszközöknek nagy méretű fájlokat kell feltöltenie (Hangmintákat) illetve időnként szintén nagy méretű fájlokat kell letöltenie (\acrshort{mi} modellek). Viszont mindkét esetben a kezdeményező fél maga az \acrshort{iot} eszköz. Ilyenkor az eszköz a felhőhöz csatlakozik, amihez könnyű egy jól ismert címet társítani.
Emellett időnként szükség van \enquote{kis} adatok átvitelére mindkét irányba. Ilyenkor a felhő is küldhet az eszközöknek parancsot. A kapcsolat kezdeményezése a felhőből nem egyszerű, hiszen a fogyó \acrshort{ipv4} címek és az \acrshort{ipv6} hálózatok csekély adoptációja és az eszközök nagy száma miatt könnyen előfordulhat, hogy azok \acrfull{nat} mögül kapcsolódnak. Erre az esetre ezért egy olyan protokollt szerettünk volna használni, amelynél a kapcsolatot a végeszköz kezdeményezi a felhő felé, de az üzenetküldés mindkét irányban lehetséges. Erre a feladatra az \acrshort{mqtt} használtuk, amely egyszerű, megbízható és kifejezetten \acrshort{iot} környezetbe lett tervezve. Az \acrshort{mqtt} egy perzisztens \acrshort{tcp} kapcsolatot épít fel egy bróker felé, majd a bróker gondoskodik róla, hogy bármelyik fél képes legyen üzenetet küldeni és azt a címzett biztosan megkapja.
Emellett időnként szükség van \enquote{kis} adatok átvitelére mindkét irányba. Ilyenkor a felhő is küldhet az eszközöknek parancsot. A kapcsolat kezdeményezése a felhőből nem egyszerű, hiszen a fogyó \acrshort{ipv4} címek és az \acrshort{ipv6} hálózatok csekély adoptációja és az eszközök nagy száma miatt könnyen előfordulhat, hogy azok \acrfull{nat} mögül kapcsolódnak.
%Erre az esetre ezért egy olyan protokollt szerettünk volna használni, amelynél a kapcsolatot a végeszköz kezdeményezi a felhő felé, de az üzenetküldés mindkét irányban lehetséges.
Erre a feladatra az \acrshort{mqtt} alkalmas, amely egyszerű, megbízható és kifejezetten \acrshort{iot} környezetbe lett tervezve. Az \acrshort{mqtt} egy perzisztens \acrshort{tcp} kapcsolatot épít fel egy bróker felé, majd a bróker gondoskodik róla, hogy bármelyik fél képes legyen üzenetet küldeni és azt a címzett biztosan megkapja.

View File

@ -38,19 +38,18 @@ Működés közben az \acrshort{iot} eszközök folyamatosan rögzítik a hangmi
\subsection{Motiváció}
Az eredeti szoftver architektúrában az \acrshort{iot} eszközök közvetlenül kommunikálnak a felhővel. Az eszközökön futó \acrshort{mi} komponens jelentősen csökkenti a hálózati terhelést, de cserébe az \acrshort{iot} eszköznek képesnek kell lennie futtatni a komponenst, amelynek ugyan a felhőben futó kiértékelő szoftvernél kevesebb a számítási igénye, továbbra is számottevő tud lenni, különösen az eszközök tömegtermelésénél, ahol eszközönként pár cent különbség is sokat jelenthet. Ha meg tudjuk spórolni ezt a funkcionalitást, akkor azzal jelentős költség megtakarítást tudunk elérni, kisebb teljesítményű, energiatakarékos hardverek alkalmazása révén.
Az eredeti szoftver architektúrában az \acrshort{iot} eszközök közvetlenül kommunikálnak a felhővel. Az eszközökön futó \acrshort{mi} komponens jelentősen csökkenti a hálózati terhelést, de cserébe az \acrshort{iot} eszköznek képesnek kell lennie futtatni a komponenst, amelynek ugyan a felhőben futó kiértékelő szoftvernél kevesebb a számítási igénye, de továbbra is számottevő tud lenni. Különösen fontos ez az eszközök tömegtermelésénél, ahol eszközönként pár cent különbség is sokat jelenthet. Ha meg tudjuk spórolni ezt a funkcionalitást, akkor azzal jelentős költség megtakarítást tudunk elérni, kisebb teljesítményű, energiatakarékos hardverek alkalmazása révén.
Az első szintű \acrshort{mi} alapú szűrés teljes eltávolítása viszont nem minden esetben járható út. Megtehetjük, hogy ezt a fázist a felhőbe \enquote{költöztetjük}. Ám ebben az esetben az összes rögzített hangmintát minden eszköznek fel kell küldenie a felhőbe. Az alábbi számításból kiderül, hogy -- a jelenlegi hangminőségi beállítások szerint -- mindössze alig több mint 1400 darab eszköznek együttesen már gigabites sávszélességi igénye van.
Az első szintű \acrshort{mi} alapú szűrés teljes eltávolítása viszont nem minden esetben járható út. Megtehetjük, hogy ezt a fázist a felhőbe \enquote{költöztetjük}. Ám ebben az esetben az összes rögzített hangmintát minden eszköznek fel kell küldenie a felhőbe. Az alábbi számításból kiderül, hogy -- a jelenlegi hangminőségi beállítások szerint -- mindössze alig több mint 1400 darab eszköznek együttesen már átlagosan gigabites sávszélesség igénye van, ha folyamatosan és egyszerre küldenek hangmintákat.
$$ 44100\textrm{Hz} \cdot 16\textrm{bit} = 88.2\textrm{kbyte/s} = 705.6\textrm{kbit/s} = 0.7056\textrm{Mbit/s}$$
%$$ 1\textrm{Gbit/s} = 1000\textrm{Mbit/s} $$
$$ \dfrac{1000\textrm{Mbit/s}}{0.7056\textrm{Mbit/s}} = 1417.2334$$
A hangminták tömörítése természetükből adódóan nem lehetséges veszteségmentesen számottevő módon tömöríteni \cite{audio_quality}. Veszteséges tömörítéssel jelentős megtakarítást lehetne elérni, ám ekkor félő, hogy elvesznek olyan vonások % <- feature magyarul
is, amelyek hiánya negatívan befolyásolja a felismerés hatékonyságát. Ezért mindenképpen az eredeti minőségében kell a felvételeket továbbítani.
A hangmintákat természetükből adódóan nem lehetséges számottevő módon tömöríteni, úgy hogy teljesen veszteségmentes legyen \cite{audio_quality}. Veszteséges tömörítéssel jelentős megtakarítást lehetne elérni, ám ekkor félő, hogy elvesznek olyan jellemzők is, amelyek hiánya negatívan befolyásolja a felismerés hatékonyságát. Ezért mindenképpen az eredeti minőségében kell a felvételeket továbbítani.
Az előszűrés által adott sávszélesség megtakarítást nehéz megbecsülni, hiszen nagyban függ az évszaktól, napszaktól, a tájegységtől, időjárástól a környező élővilágtól és egyéb hatásoktól, körülményektől. A hatékonyság megbecsléséhez -- kizárólag szemléltető célzattal -- összegyűjtöttem néhány -- a célterülethez hasonló -- hangfelvételt az internetről. Ezeket felbontottam egy másodperces szegmensre és lefuttattam rájuk a felismerő algoritmust. Az eredményeket \aref{tab:proof_maker}.\ táblázat foglalja össze.
Az előszűrés által adott sávszélesség megtakarítást nehéz megbecsülni, hiszen nagyban függ az évszaktól, napszaktól, a tájegységtől, időjárástól a környező élővilágtól és egyéb hatásoktól, körülményektől. A hatékonyság megbecsléséhez -- kizárólag szemléltető célzattal -- összegyűjtöttem néhány -- a célterülethez hasonló -- hangfelvételt az internetről. Ezeket felbontottam egy másodperces szegmensekre és lefuttattam rájuk a felismerő algoritmust. Az eredményeket \aref{tab:proof_maker}.\ táblázat foglalja össze.
\begin{table}[h!]
\centering
@ -71,15 +70,15 @@ Az előszűrés által adott sávszélesség megtakarítást nehéz megbecsülni
Beláthatjuk, hogy az intelligens felismeréssel jelentős sávszélességet tudunk megtakarítani. A felhőbe felküldött, de nem madárcsiripelést tartalmazó minták felesleges hálózati terhelést jelentenek, hiszen ellenőrzés után eldobásra kerülnek.
Ennek a problémának a megoldására nyújt lehetőséget a peremhálózati rendszer bevonása. Mivel a peremhálózati rendszer sokkal elosztottabb és logikailag közelebb van az adatok forrásához. Ezért képesek vagyunk vele egyszerre kevesebb eszközt kiszolgálni sokkal alacsonyabb adatforgalmi költségek mellett, hiszen nem kell az összes, csak a gyanús mintákat elküldeni elemzésre a felhőbe. Emellett a peremhálózati rendszereken sokkal jobban skálázódhat az alkalmazás. Emellett a megosztott erőforrásoknak is hasznát vehetjük, ha egyes \acrshort{iot} eszközöket leállítunk (például télen, amikor nem fenyeget madár veszély) akkor nem fog kihasználatlanul állni az eszközökben az extra számítási kapacitás, hiszen a peremhálózati felhőrendszerbe könnyen be tudunk ütemezni más feladatokat.
Ennek a problémának a megoldására nyújt lehetőséget a peremhálózati rendszer bevonása. Mivel a peremhálózati rendszer sokkal elosztottabb és logikailag közelebb van az adatok forrásához, ezért képesek vagyunk vele egyszerre kevesebb eszközt kiszolgálni sokkal alacsonyabb adatforgalmi költségek mellett, hiszen nem az összes, hanem csak a gyanús mintákat kell elküldeni elemzésre a felhőbe. Emellett a peremhálózati rendszereken sokkal jobban skálázódhat az alkalmazás. Ezeken felül a megosztott erőforrásoknak is hasznát vehetjük, ha egyes \acrshort{iot} eszközöket leállítunk (például télen, amikor nem fenyeget madár veszély) akkor nem fog kihasználatlanul állni az eszközökben az extra számítási kapacitás, hiszen a peremhálózati felhőrendszerbe könnyen be tudunk ütemezni más feladatokat.
\subsection{Tervezés}
A tervezés során fontosnak tartottam, hogy a rendszer többi komponensében minimális változtatásokat kelljen tenni. Az eredeti rendszer mikroszolgáltatás architektúrára épült, így az egyes komponensek felelőssége jól elkülönül. A megtervezett architektúrába könnyen beilleszthető extra funkcionalitás.
Mivel \textit{KubeFed} keretrendszert választottam az alkalmazásom futtatására, ezért egyértelmű volt, hogy a már meglévő alkalmazás komponenseken nem kell módosítani. Hiszen a \textit{KubeFed} csak kiegészíti a \textit{Kubernetes} funkcionalitását, amely az eredeti rendszer tervezésénél is meghatározó volt. Az első szintű \acrshort{ml} algoritmust ezekből az okokból egy újabb mikroszolgáltatásként terveztem meg.
Mivel \textit{KubeFed} keretrendszert választottam az alkalmazásom futtatására, ezért egyértelmű volt, hogy a már meglévő alkalmazás komponenseken nem kell módosítani. Hiszen a \textit{KubeFed} csak kiegészíti a \textit{Kubernetes} funkcionalitását, amely az eredeti rendszer tervezésénél is meghatározó volt. Az első szintű \acrshort{mi} algoritmust ezekből az okokból egy újabb mikroszolgáltatásként terveztem meg.
Az \acrshort{iot} eszközön futó szoftver \acrshort{http} interfészen keresztül tölti fel a mintákat. Az új mikroszolgáltatást proxyként terveztem meg. Azaz egy ugyanolyan \acrshort{http} interfészt szolgál ki, mint a felhőben a hangfájlok fogadására szolgáló végpont. Ha az \acrshort{ml} algoritmus madárcsiripelést azonosít a mintában, akkor azt módosítás nélkül továbbküldi. Így az eszközök és a felhő számára is teljesen transzparens módon tud működni az új szolgáltatás. A megváltozott architektúráról \aref{fig:birbnetes_super_simple_services}.\ ábra ad vázlatos áttekintést. Ez a szolgáltatás egyformán futhat a felhőben, de a peremen is, nincsenek lokalitási kötöttségei.
Az \acrshort{iot} eszközön futó szoftver \acrshort{http} interfészen keresztül tölti fel a mintákat. Az új mikroszolgáltatást proxy-ként terveztem meg, azaz egy ugyanolyan \acrshort{http} interfészt szolgál ki, mint a felhőben a hangfájlok fogadására szolgáló végpont. Ha az \acrshort{ml} algoritmus madárcsiripelést azonosít a mintában, akkor azt módosítás nélkül továbbküldi, így az eszközök és a felhő számára is teljesen transzparens módon tud működni az új szolgáltatás. A megváltozott architektúráról \aref{fig:birbnetes_super_simple_services}.\ ábra ad vázlatos áttekintést. Ez a szolgáltatás egyformán futhat a felhőben, de a peremen is, nincsenek lokalitási kötöttségei.
\begin{figure}[h!]
\centering
@ -98,20 +97,20 @@ A mikroszolgáltatás fejlesztését \gls{python} nyelven végeztem. Azért ezt
A szoftverkomponens funkcionalitását tekintve három fő funkcionalitást kell megvalósítania. Ezek a \acrshort{http} kérések fogadása, intelligens felismerés futtatása, majd eredménytől függően újabb \acrshort{http} kérés indítása.
A \acrshort{http} interfész megvalósítására a \textit{Flask}\footnote{\url{https://flask.palletsprojects.com/}} mikrokeretrendszert használtam. Ez a keretrendszer könnyen bővíthető további letölthető beépülők segítségével a projekt többi területén is használom ezért választottam itt is ezt.
A \acrshort{http} interfész megvalósítására a \textit{Flask}\footnote{\url{https://flask.palletsprojects.com/}} mikrokeretrendszert használtam. Ez a keretrendszer könnyen bővíthető további letölthető beépülő modulok segítségével, a projekt többi területén is használom, ezért választottam itt is ezt.
A felhős szoftver egy hangminta fogadása után egyből visszatér a válasszal. Ezt a viselkedést az új komponensestől is elvárhatjuk, hogy megtartsa. Ezért az nem egy jó megközelítés, hogy a kérés hatására a kérés kezelésének részeként hajtjuk végre az intelligens felismerést, hiszen ez olykor több ideig is eltarthat, előfordulhat, hogy egy komponenshez egyszerre több kérés is beérkezik, ez csak tovább rontaná a válaszidőt.
A felhőben futó szoftver egy hangminta fogadása után egyből visszatér a válasszal. Ezt a viselkedést az új komponensestől is elvárhatjuk, ezért az nem egy jó megközelítés, hogy a kérés hatására a kérés kezelésének részeként hajtjuk végre az intelligens felismerést, hiszen ez olykor sokáig is eltarthat, valamint előfordulhat, hogy egy komponenshez egyszerre több kérés is beérkezik, ami csak tovább rontaná a válaszidőt.
Ennek a problémának a megoldására az \textit{uWSGI}\footnote{\url{https://github.com/unbit/uwsgi}} futtató környezetet használtam. Ez a futtatókörnyezet lehetőséget ad arra, hogy párhuzamosan futó programkódot futtassunk a webes alkalmazásuk mellett, amellyel a webes része az alkalmazásunknak egy sor segítségével tud kommunikálni. Új hangminta érkezésekor az bekerül ebbe a várakozási sorba. Ebből a sorból egy párhuzamosan futó programrész veszi ki, futtatja le az intelligens felismerést és szükség esetén indítja a további \acrshort{http} kérést, amely tartalmilag megegyezik a hozzá beérkezett eredeti kéréssel.
Ennek a problémának a megoldására az \textit{uWSGI}\footnote{\url{https://github.com/unbit/uwsgi}} futtató környezetet használtam. Ez a futtatókörnyezet lehetőséget ad arra, hogy párhuzamosan futó programkódot futtassunk a webes alkalmazásuk mellett, amellyel a webes része az alkalmazásunknak egy sor segítségével tud kommunikálni. Új hangminta érkezésekor az bekerül ebbe a várakozási sorba. Ebből a sorból egy párhuzamosan futó programrész veszi ki, futtatja le az intelligens felismerést, és szükség esetén indítja a további \acrshort{http} kérést, amely tartalmilag megegyezik a hozzá beérkezett eredeti kéréssel.
A felismerő algoritmusnak szüksége van egy modell fájlra a működéséhez. Ez a modellfájlt tartalmazza a mesterséges intelligencia paramétereit. Ezeket a felhőből lehet letölteni, az \acrshort{iot} eszköz is innen tölti le, ha szüksége van rá. Ugyanezt a viselkedést implementáltam a mikroszolgáltatásba is. Futtatás előtt ellenőrzi, hogy rendelkezésére áll-e a modell. Ha nem, akkor \acrshort{http} kérés segítségével letölti azt a felhőből és betölti. Későbbi használatra betöltve tartja.
A felismerő algoritmusnak szüksége van egy modell fájlra a működéséhez. Ez a modellfájlt tartalmazza a mesterséges intelligencia paramétereit. Ezeket a felhőből lehet letölteni, az \acrshort{iot} eszköz is innen tölti le, ha szüksége van rá. Ugyanezt a viselkedést implementáltam a mikroszolgáltatásba is. Futtatás előtt ellenőrzi, hogy rendelkezésére áll-e a modell. Ha nem, akkor \acrshort{http} kérés segítségével letölti azt a felhőből és betölti, valamint későbbi használatra betöltve tartja.
\subsubsection{\acrshort{iot} szoftver módosítása}
Az \acrshort{iot} eszköz szoftverén ahhoz hogy megvalósítsam a tervekben foglaltat, felvettem egy új konfigurációs változót. Ennek segítségével ki lehet kapcsolni a beépített intelligens szűrés futtatását.
Az \acrshort{iot} eszköz szoftverén ahhoz, hogy megvalósítsam a tervekben foglaltat, felvettem egy új konfigurációs változót. Ennek segítségével ki lehet kapcsolni a beépített intelligens szűrés futtatását.
A szoftveren belül az intelligens felismerést egy osztály valósítja meg. Megoldásomban létrehoztam egy osztályt, amelynek ugyanaz az interfésze, mint az intelligens felismerő osztálynak, de felismerés helyett mindig felküldésre ítéli a hangmintákat.
A konfigurációs beállítás a példányosításnál játszik szerepet. Azt befolyásolja hogy az eredeti osztály, vagy a fent vázolt osztályból jöjjön létre példány.
A konfigurációs beállítás a példányosításnál játszik szerepet, azt befolyásolja hogy az eredeti osztály, vagy a fent vázolt osztályból jöjjön létre példány.

View File

@ -4,54 +4,23 @@
\label{chapter:dynamic_scheduling}
%----------------------------------------------------------------------------
% A robotkaroknál menet közbeni átütemezés nem jó ötlet, ezért csak a biztonságos állásban ütemezi át
% Futtató környezet tervezése
% Vázolni a futtató környezetet amit elkészítettem
% írni arról, hogy készítettem, ansible, kubespray
% Ütemezés megoldása
% Nincsenek jó ütemező algoritmusok
% Kell csinálni sajátot
% Ütemezési algoritmus tervezése
% Ütemezési algoritmus implementálása
% Bemeneti adatok
% Kimeneti adatok egy ábrán
% adat -> doboz -> ütemezési döntés
% Ütemezési döntések hogy materializálódnak a clusterek közt
% Az ütemező algoritmus bemente nagyon alakalmazás függő, attól függ mit akarunk elérni
% Ezért robotkaroknál latency, birbnetesnél sávszél
% Hogyan lettek mérve és gyűjtve
% Hogyan lettek kiértékelve
% Erről egyelőre még csak annyi a biztos, hogy kubernetes lesz
% Ütemező algoritmus
% Big brain matekoshoz ismerni kéne sokmindent
% Próbálgatós naiv algoritmust csinálok
% robotkar: mindig a legkisebb latency-hez igazítsa, ha oda nem sikerül, akkor fail (esetleg küszöbértéket meghatározni)
% Birbnetes: sávszél és queue hosszal lehet variálni. Sávszél alapján lehet osztályozni a queue hossz pedig a trigger,
% Itt nézni lehetne, hogy hol járt már, az oda-vissza rakosgatás elkerülése érdekében.
\section{Felhős Keretrendszer}
\section{Felhős keretrendszer kiválasztása}
\label{sec:cloud_framework}
% TODO: Itt nagyon sok mindent át kell írni
%\subsection{Keretrendszer}
%
%\Aref{sec:frameworks}.\ szekcióban több keretrendszert is megvizsgáltam. Ezek közül a \textit{KubeEdge}-et választottam.
%
%A kiválasztásának fő oka az volt, hogy támogatja a mikroszolgáltatás architektúrát, emellett -- a leírása alapján -- könnyen lehet alkalmazni, hiszen ha az alkalmazásunk konténerből futtatható, alig kell rajta módosítani, hiszen a \textit{KubeEdge} képes ezeket a konténereket beütemezni, hogy a peremhálózaton futhassanak. Így a korábban szerzett mikroszolgáltatás alapú alkalmazásfejlesztési tapasztalataimat itt könnyen tudtam hasznosítani.
%
%Mindemellett \aref{sec:birbframework}.\ szekcióban kifejtettek alapján a másik alkalmazásomat is \textit{KubeEdge} alapokra építettem fel. Ennek köszönhetően a későbbi méréseimet is egyforma környezetben tudom végezni, ezzel egyszerűsítve azok implementációját amellett, hogy a két alkalmazáshoz nem kell két külön keretrendszert megismernem és fejleszteni rá.
%
%A \textit{KubeEdge} használatának további előnye, hogy az általam már jól ismert \textit{Kubernetes} konténer orkesztációs platformra épül így a telepítése és megismerése számomra egyszerűbb.
\Aref{sec:frameworks}.\ szekcióban több keretrendszert is megvizsgáltam. Ezek közül a \textit{KubeFed}-et választottam.
% Itt leírom, hogy az összes egy nagy kula, és a kubefedet is csak azért választom, hogy legyen egységes controlplane
% támogatja az ütemezést
% saját ütemezője nincs
%
\section{Komponensek dinamikus ütemezése}

View File

@ -3,7 +3,7 @@
\chapter{Teszt környezet kialakítása}
%----------------------------------------------------------------------------
A munkám során elkészített és módosított szoftverek helyes működésének demonstrálása egy teljes peremhálózati is felhő számítástechnikai rendszer kiépítését igénylik. Mivel az ilyen környezetek sokszor nem állnak rendelkezésünkre ezért szükség van egy olyan megoldásra, amely jól modellezi az ilyen rendszerek működését, így képesek vagyunk az alkalmazásainkat telepíteni benne.
A munkám során elkészített és módosított szoftverek helyes működésének demonstrálása egy teljes peremhálózati és felhő számítástechnikai rendszer kiépítését igénylik. Mivel az ilyen környezetek sokszor nem állnak rendelkezésünkre, ezért szükség van egy olyan megoldásra, amely jól modellezi az ilyen rendszerek működését, így képesek vagyunk az alkalmazásainkat telepíteni benne.
Vannak szituációk amikor egy teljesen kontrollált tesztkörnyezet alkalmazását kívánja meg a teszt szcenárió. Egy ilyen környezetben a rendszerben elvárás, hogy minden lényeges paramétere szabadon módosítható és precízen megfigyelhető legyen.
@ -11,9 +11,9 @@ Ebben a fejezetben egy ilyen tesztkörnyezet fejlesztését és kialakítását
\section{Célkitűzések}
A tesztkörnyezet egy modellje a valódi környezetnek, amelyben a tesztelni kívánt alkalmazások futnak. A modell lényege, hogy a valóságnak egy egyszerűsített mását adja. A mérések szempontjából fontos tulajdonságokat megtartsa, jól mimikázza, ideális esetben konfigurálhatóvá tegye. A mérés szempontjából nem lényeges vagy nem befolyásoló tényezőket elhagyhatjuk a modellből, ezzel egyszerűsítve annak működését, hogy a funkcionalitásra tudjunk koncentrálni.
A tesztkörnyezet egy modellje a valódi környezetnek, amelyben a tesztelni kívánt alkalmazások futnak. A modell lényege, hogy a valóságnak egy egyszerűsített mását adja. A mérések szempontjából fontos tulajdonságokat megtartsa, ideális esetben konfigurálhatóvá tegye. A mérés szempontjából nem lényeges vagy nem befolyásoló tényezőket elhagyhatjuk a modellből, ezzel egyszerűsítve annak működését, hogy a funkcionalitásra tudjunk koncentrálni.
A tesztkörnyezet megtervezése előtt összefoglaltam, hogy mik azok a tulajdonságok, amiket át kell emelni a modellbe és mik azok, amelyekkel nem kell foglalkozni. Ezek megfogalmazásánál figyelembe vettem azt, hogy az előző fejezetekben ismeretet munkám eredményei jól demonstrálhatóak legyenek. Azok a tulajdonságok, amelyeket a modellnek meg kell valósítania a következők:
A tesztkörnyezet megtervezése előtt összefoglaltam, hogy mik azok a tulajdonságok, amiket át kell emelni a modellbe és mik azok, amelyekkel nem kell foglalkozni. Ezek megfogalmazásánál figyelembe vettem azt, hogy az előző fejezetekben ismeretet munkám eredményei jól demonstrálhatóak legyenek. Azok a tulajdonságok, amelyeket a modellnek meg kell valósítania, a következők:
\begin{itemize}
\item A választott futtatási környezet minden tulajdonságát egy-az-egyben meg kell valósítania.
\item Legalább egy perem és egy felhő infrastruktúra környezet legyen modellezve.
@ -22,15 +22,15 @@ A tesztkörnyezet megtervezése előtt összefoglaltam, hogy mik azok a tulajdon
További követelmény a tesztkörnyezet felé, hogy telepítése egyszerű legyen és hordozható. Igény esetén akár egy fejlesztő vagy tesztelő képes legyen a saját számítógépén is elindítani és használni. A benne futtatott teszteknek reprodukálhatónak kell lennie, azaz két teszt között a tesztet befolyásoló tényezők ne változzanak.
Azok mellett a követelmények mellett, amelyeket a modellnek teljesítenie kell, érdemes megemlíteni néhány tulajdonságát a rendszernek, amelyet az egyszerűsítés kedvéért érdemes elhanyagolni. Ilyenek a kliens eszközök konkrét fizikai környezete. Mivel a munkám első sorban a felhős alkalmazások átalakítására, implementálására és a köztük lévő hálózati kapcsolat vizsgálatára irányult, ezért a konkrét kliensek fizikai környezete és megvalósítása nem játszik szerepet.
Azok mellett a követelmények mellett, amelyeket a modellnek teljesítenie kell, érdemes megemlíteni néhány tulajdonságát a rendszernek, amelyet az egyszerűsítés kedvéért érdemes elhanyagolni. Ilyenek a kliens eszközök konkrét fizikai környezete. Mivel a munkám elsősorban a felhő alkalmazások átalakítására, implementálására és a köztük lévő hálózati kapcsolat vizsgálatára irányult, ezért a konkrét kliensek fizikai környezete és megvalósítása nem játszik szerepet.
Mivel mindkét szoftver amellyel a korábbi fejezetekben foglalkoztam tartalmaz olyan komponenst, amely a környezetéről gyűjt információt (Hangrögzítés), vagy éppen abba avatkozik bele (Robotkarok tárgyakat mozgatnak) ezeket a funkcionalitásokat érdemes emulálni. De szükség esetén érdemes fenntartani a lehetőséget, hogy valódi eszközöket csatlakoztassunk a tesztkörnyezethez.
Mivel mindkét szoftver, amellyel a korábbi fejezetekben foglalkoztam tartalmaz olyan komponenst, amely a környezetéről gyűjt információt (Hangrögzítés), vagy éppen abba avatkozik bele (Robotkarok tárgyakat mozgatnak), ezeket a funkcionalitásokat érdemes emulálni. Szükség esetén érdemes fenntartani a lehetőséget, hogy valódi eszközöket csatlakoztassunk a tesztkörnyezethez.
\section{Magas szintű tervezés}
A kijelölt célok megvalósítására egy teljesen virtuális környezetet terveztem meg. Az egyes szerepeket virtuális gépek, vagy azok egy csoportja látja el.
A teszt infrastruktúrát két szempontból bontottam fel. Az egyik az előbb említett szerepek és azok kapcsolata. A másik pedig a szoftverek telepítésének rétegei szerint. Mivel ezek a rétegek egymásra épülnek. Minden komponens konfigurációja egységes, egyedi konfigurációk változtatása a telepítés során adja ki a végleges infrastruktúrát. A két felbontást két dimenzión ábrázolva \aref{fig:birbemu_layers}.\ ábra részletezi. A függőleges felbontás az egyes szerepeket, míg a vízszintes felbontás a telepítés rétegeit ábrázolja.
A teszt infrastruktúrát két szempontból bontottam fel: az egyik az előbb említett szerepek és azok kapcsolata, a másik pedig a szoftverek telepítésének rétegei, mivel ezek a rétegek egymásra épülnek. Minden komponens konfigurációja egységes, egyedi konfigurációk változtatása a telepítés során adja ki a végleges infrastruktúrát. A két felbontást két dimenzión ábrázolva \aref{fig:birbemu_layers}.\ ábra részletezi. A függőleges felbontás az egyes szerepeket, míg a vízszintes felbontás a telepítés rétegeit ábrázolja.
\begin{figure}[h!]
@ -45,29 +45,29 @@ A teszt infrastruktúrát két szempontból bontottam fel. Az egyik az előbb em
\subsubsection{Futtató környezet}
A környezetben szükség van a választott alkalmazás futtató keretrendszer (esetünkben \textit{Kubedfed}) futtatására. A \textit{KubeFed} lényegében több \textit{Kubernetes} klaszter fölé húzott közös vezérlési réteg. Ennek megfelelően virtuális gépek kijelölt csoportjaira önálló csoportjainak egy-egy \textit{Kubernetes} klaszter futtatását jelöltem ki.
A környezetben szükség van a választott alkalmazás futtató keretrendszer (esetünkben \textit{KubeFed}) futtatására. A \textit{KubeFed} lényegében több \textit{Kubernetes} klaszter fölé húzott közös vezérlési réteg. Ennek megfelelően virtuális gépeket csoportokra bontottam, adott csoportok egy-egy \textit{Kubernetes} klasztert valósítanak meg.
Az egyes \textit{Kubernetes} klaszterek esetünkben az egyes adatközpontokat szimbolizálják. Egy ilyen klaszter jelöli a felhő adatközpontot, a többi klaszter pedig jelölheti a peremhálózati adatközpontokat vagy akár további felhőket is. A méréseink szempontjából nincs számottevő különbség egy felhő vagy egy peremhálózati adatközpontban működésüket tekintve, ezért itt főképp csak az elnevezésükben térnek el.
Az egyes \textit{Kubernetes} klaszterek esetünkben az egyes adatközpontokat szimbolizálják. Egy ilyen klaszter jelöli a felhő adatközpontot, a többi klaszter pedig jelölheti a peremhálózati adatközpontokat vagy akár további felhőket is. A tesztelendő alkalmazások szempontjából, nincs számottevő különbség egy felhő vagy egy peremhálózati adatközpont belső működésében, ezért itt főképp csak az elnevezésükben térnek el.
Az önálló \textit{Kubernetes} klaszterek fölé már lehet \textit{KubeFed} környezetet telepíteni. A telepített \textit{KubeFed} szoftver megfelelően modellezi a valós környezetben használt futtató környezetet, hiszen ugyanaz a szoftver. Telepítése és üzemeltetése között nincs különbség a valós és teszt környezetben.
\subsubsection{Kliens}
A peremhálózati rendszerek három rétegű architektúrájában legalul foglal helyet maga a kliens eszköz. A klienseket ebben a környezetben egy vagy több önálló virtuális gép valósítja meg. Egy virtuális gép egy vagy több klienst is megvalósíthat függően a kliensek erőforrás és hálózati konfiguráció igényeitől.
A peremhálózati rendszerek három rétegű architektúrájában legalul foglal helyet maga a kliens eszköz. A klienseket ebben a környezetben egy vagy több önálló virtuális gép valósítja meg. Egy virtuális gép egy vagy több klienst is megvalósíthat, függően a kliensek erőforrás és hálózati konfiguráció igényeitől.
\subsubsection{Hálózat}
A célok között fontos szerepet képviselt az egyes \enquote{adatközpontokat} illetve adatközpontokat kliensekkel összekötő hálózat és azok sajátosságainak megfelelő modellezése. Ez magában foglalja a különböző hálózati anomáliák és kedvezőtlen paraméterek szimulálását is.
A célok között fontos szerepet képviselt az egyes \enquote{adatközpontokat} illetve adatközpontokat kliensekkel összekötő hálózat, és azok sajátosságainak megfelelő modellezése. Ez magában foglalja a különböző hálózati anomáliák és kedvezőtlen paraméterek szimulálását is.
Ehhez az egy \enquote{adatközponthoz} tartozó virtuális gépeket közös adatkapcsolati rétegbe szerveztem. Hálózat fizikai és adatkapcsolati rétegeit a virtualizációs környezet biztosítja. Az egyes elszeparált alhálózati rétegek mindegyikét saját alhálózatukba rendeztem. A kliens eszközök önmaguk is egy vagy több elszeparált alhálózatba kerülhetnek.
Ehhez az egy \enquote{adatközponthoz} tartozó virtuális gépeket közös adatkapcsolati rétegbe szerveztem. A hálózat fizikai és adatkapcsolati rétegeit a virtualizációs környezet biztosítja. Az egyes elszeparált alhálózati rétegek mindegyikét saját alhálózatukba rendeztem. A kliens eszközök önmaguk is egy vagy több elszeparált alhálózatba kerülhetnek.
Az alhálózatok között az útválasztást egy külön virtuális gép végzi, amely olyan szoftvert futtat ami képes különböző egyedileg konfigurálható hálózati paramétereket szimulálni. Ezek a paraméterek elsősorban késleltetés, sávszélesség, csomagvesztés stb.
Az alhálózatok között az útválasztást egy külön virtuális gép végzi, amely olyan szoftvert futtat ami képes különböző egyedileg konfigurálható hálózati paramétereket emulálni. Ezek a paraméterek elsősorban késleltetés, sávszélesség, csomagvesztés stb.
\subsection{Telepítés rétegei szerinti felbontás}
A környezet felépítését rétegekre osztottam. Ennek az a célja, hogy az egyes rétegek telepítése önállóan jól definiálható és tervezhető legyen. További előnye ennek a felosztásnak, hogy az egyes rétegek szükség esetén cserélhetőek más megoldásokra, ezzel elérve, hogy a tesztkörnyezet könnyen testre-szabható legyen.
A környezet felépítését rétegekre osztottam. Ennek az a célja, hogy az egyes rétegek telepítése önállóan jól definiálható és tervezhető legyen. További előnye ennek a felosztásnak, hogy az egyes rétegek szükség esetén cserélhetőek más megoldásokra, ezzel elérve, hogy a tesztkörnyezet könnyen testreszabható legyen.
Az egyes rétegek egymásra épülésének sorrendje a következő:
\begin{enumerate}
@ -78,7 +78,7 @@ Az egyes rétegek egymásra épülésének sorrendje a következő:
\item \textbf{Alkalmazás:} A futtatókörnyezetbe telepített egyéni alkalmazások, amelyek tesztelését végezzük.
\end{enumerate}
A telepítés egyes rétegeinek telepítésére önálló automatizációs megoldásokat terveztem használni. A rétegek megfelelő szeparálása ezeknek az eszközöknek a kiválasztását, beállítását és alkalmazását is megkönnyíti. Lehetőségünk van olyan eszközöket használni, amik az egyes rétegeken belüli feladatcsoportok végrehajtására specializáltak.
Az egyes rétegeinek telepítésére önálló automatizációs megoldásokat terveztem használni. A rétegek megfelelő szeparálása ezeknek az eszközöknek a kiválasztását, beállítását és alkalmazását is megkönnyíti. Lehetőségünk van olyan eszközöket használni, amelyek az egyes rétegeken belüli feladatcsoportok végrehajtására specializáltak.
\section{Megvalósítás}

Binary file not shown.

Before

Width:  |  Height:  |  Size: 3.3 MiB

After

Width:  |  Height:  |  Size: 1.6 MiB