marcsello/marci-dipterv-latex
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

some changes

Browse Source
This commit is contained in:
Pünkösd Marcell 2021-11-27 23:09:27 +01:00
parent e51c50f060
commit 2f7cc2eb47
14 changed files with 147 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
src/bib/mybib.bib
View File

@ -256,6 +256,49 @@
note = {Megtekintve: 2020-05-09}
}
@misc{oci_format_docs,
author = {},
title = {Open Container Initiative - Image Format Specification},
howpublished = {\url{https://github.com/opencontainers/image-spec/blob/main/spec.md}},
note = {Megtekintve: 2021-11-27}
}
@misc{podman_docs,
author = {},
title = {Podman documentation},
howpublished = {\url{https://docs.podman.io/en/latest/}},
note = {Megtekintve: 2021-11-27}
}
@misc{kubefed_readme,
author = {},
title = {Kubefed - README},
howpublished = {\url{https://github.com/kubernetes-sigs/kubefed/blob/master/README.md}},
note = {Megtekintve: 2021-11-27}
}
@misc{kubefed_old,
author = {Lukasz Guminski and Allan Naim},
title = {Cluster Federation in Kubernetes 1.5},
howpublished = {\url{https://kubernetes.io/blog/2016/12/cluster-federation-in-kubernetes-1-5/}},
note = {Megtekintve: 2021-11-27}
}
@misc{kubefed_userguide,
author = {},
title = {Kubefed - User guide},
howpublished = {\url{https://github.com/kubernetes-sigs/kubefed/blob/master/docs/userguide.md}},
note = {Megtekintve: 2021-11-27}
}
@misc{kubernetes_why_federation,
author = {{devopspoints.com}},
title = {Kubernetes – Why federation?},
howpublished = {\url{https://devopspoints.com/kubernetes-why-federation.html}},
note = {Megtekintve: 2021-11-27}
}
@misc{microservices,
author = {Tom Huston},
title = {What is Microservices?},

63
src/content/birbnetes_impl.tex
View File

@ -4,7 +4,7 @@
\label{chapter:birbnetes}
%----------------------------------------------------------------------------
É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 a kártékony madaraktól \cite{nk}.
É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 é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.
@ -24,7 +24,7 @@ A hangminták felismerése egy két szintű \acrfull{mi} rendszerben történik.
A második szinten egy sokkal bonyolultabb \acrfull{cnn} alapú algoritmus áll. A \acrshort{cnn} által használt modell úgy lett tanítva, hogy a rögzített -- feltehetően -- madárhangokat tudja osztályokba sorolni. Így képes specifikusan a seregély hangját felismerni és elkülöníteni a többi madárhangtól.
A korábban említett \acrshort{svm} alapú komponens alacsony erőforrás igénye miatt miatt az \acrshort{iot} eszközökön futott, míg a komolyabb számítási igényű \acrshort{cnn} alapú megoldás, már igényeli a felhő által nyújtott komolyabb számítási teljesítményt.
A korábban említett \acrshort{svm} alapú komponens alacsony erőforrás igénye miatt az \acrshort{iot} eszközökön futott, míg a komolyabb számítási igényű \acrshort{cnn} alapú megoldás, már igényeli a felhő által nyújtott komolyabb számítási teljesítményt.
Az algoritmusok elméleti működéséről a következő fejezetek adnak áttekintést.
@ -56,7 +56,17 @@ Munkánk során egy ilyen eszköz prototípusát is elkészítettük mind hardve
\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. 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öznénk. Azt szerettük volna, ha kész a rendszer akkor konkrét mérésekre és számításokra tudjuk alapozni a hardverválasztást, de addig ne legyen ebből 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 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ó.
\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}
\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öznénk. Azt szerettük volna, ha kész a rendszer akkor konkrét mérésekre és számításokra tudjuk alapozni a hardverválasztást, de addig ne legyen ebből 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.
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.
@ -77,20 +87,33 @@ A prototípus egy műanyag házba van beszerelve. Az összeszerelt prototípus \
\label{fig:doboz}
\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 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.
% TODO: akkumlátoros működés
\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}
\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 nekünk kívül estek a munkánk témájából. 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.
\subsubsection{Szoftver}
A szoftverkörnyezet alapjául szolgáló operációs rendszer egy \textit{Debian}\footnote{\url{https://www.debian.org/}} alapú rendszer (\textit{Raspbian}) fut. Ez egy népszerű és jól dokumentált operációs rendszer.
Az erre telepített szoftver komponens két részre bontható. Platform függő \textbf{platform-illesztőre} és platform független \textbf{üzleti logikára}.
Az erre telepített szoftver komponens három rétegre bontható. Operációs rendszerre, platform függő \textbf{platform-illesztőre} és platform független \textbf{üzleti logikára}. Az egyes rétegeket \aref{fig:birbox_software_blockdiagram}.\ ábra vázolja.
\begin{figure}[h!]
\centering
\includegraphics[width=0.80\textwidth]{figures/birbox_software_blockdiagram}
\caption{Az \acrshort{iot} hardveren futó szoftver rétegei az információs összefüggésekkel ábrázolva.}
\label{fig:birbox_software_blockdiagram}
\end{figure}
A \textbf{platform-illesztő} feladata az, hogy absztrakciós rétegként szolgáljon a platform specifikus hardver vezérlési és illesztési logika fölé, ezzel egy egységes programozói interfészt biztosítva az üzleti logika számára. Ennek az az előnye, hogy a fejlesztésnél használt konkrét hardver könnyen cserélhető, sőt akár az üzleti logika módosítás nélkül áthelyezhető egy kész termékbe is. Minden alkalommal ha változik a hardver csak a platformillesztő komponenst kell módosítani. Ebből a komponensből akár többet is fenntarthatunk, így egyszerre több különböző platformot tesztelhetjük az üzleti logikát annak bármilyen módosítása nélkül.
Az \textbf{üzleti logika} lényegében minden egyéb, ami nem platform specifikus. Felépítése egy három fázisú csővezeték. Az első fázisban a platform illesztőn keresztül megkap egy szenzor adatot. Ez lehet egy hangfájl a mikrofonról de bármilyen más szenzortól származó mérési érték is. Ezután egy előfeldolgozó lépés következik, amely képes döntést hozni arról, hogy az adott mérést továbbítsa-e a következő fázisra, amely egy ideális protokollon elküldi a hangmintát a felhőbe. A folyamat egy időzítő által meghatározott intervallumokban fut le.
Jelenleg az üzleti logikában lévő csővezeték második fázisaként van implementálva az \acrshort{svm} alapú algoritmus. Így csak akkor továbbítja a hangmintát a felhő felé, ha madárhangot észlelt.
@ -101,7 +124,7 @@ A szoftver \gls{python} nyelven került implementálásra. A telepítése közve
\subsection{Felhő rendszer}
A felhőrendszer mikroszolgáltatás architektúrát használva került megvalósításra. 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 egyszer, amikor lecserélésre került a használt \acrshort{mi} algoritmus.
A felhőrendszer 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.
@ -112,13 +135,6 @@ Az egyes szolgáltatások között mindig csak a legkisebb hasznos adat kerül t
A rendszerbe érkező összes hangminta a beérkezés pontján címkézésre kerül. Később a feldolgozó szalag egyes fázisain ezzel lehet hivatkozni egy konkrét hangmintára. Ezek a címkék biztosítottan egyediek a rendszeren belül.
\begin{figure}[h!]
\centering
\includegraphics[width=1.05\textwidth]{figures/architecture-redesigned}
\caption{A felhő szoftver architekturális felépítése}
\label{fig:architecture-redesigned}
\end{figure}
A rendszert alkotó mikroszolgáltatások négy fő csoportra oszthatóak. Ezt a felosztást mutatja be \aref{fig:architecture-redesigned}.\ ábra. Röviden ezek a csoportok a következőek:
\begin{itemize}
\item \textbf{West-End Subsystem} Az itt található szolgáltatások felelnek a beérkező hangfájlok és egyéb mérések adminisztrációjáért.
@ -127,15 +143,20 @@ A rendszert alkotó mikroszolgáltatások négy fő csoportra oszthatóak. Ezt a
\item \textbf{Device Subsystem} Azok a szolgáltatások, amelyek közvetlenül az eszközök vezérlésért, azok adminisztrációjáért felelnek.
\end{itemize}
\begin{figure}[h!]
\centering
\includegraphics[width=1.05\textwidth]{figures/architecture-redesigned}
\caption{A felhő szoftver architekturális felépítése}
\label{fig:architecture-redesigned}
\end{figure}
A rendszerhez készült egy webes kezelőfelület is, amelyet hallgatótársunk Kunkli Richárd fejlesztett.
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éséről és felelősségeiről egy rövid leírás olvasható az alábbiakban.
Az általunk tervezett és implementált mikroszolgáltatások működéséről é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.
@ -180,14 +201,12 @@ Az \acrshort{iot} eszközök a felhővel való kommunikáció során hibrid mód
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.
%\section{Tervezés}
\section{Felkészítés peremhálózati alkalmazásra}
%\subsection{Keretrendszer}
%\label{sec:birbframework}
% Itt leírom az átalakítást a három rétegű pörgő lófaszra
% Még jó, hogy mikro meme, meg k8s, így tök véletlenül pont a kubeedge a legjobb framework hozzá
% Itt még nem írok szerintem a kubefedről
% a szükséges átalakításokat összeszedem

2
src/content/conclusion.tex
View File

@ -3,6 +3,8 @@
\chapter{Konklúzió}
%----------------------------------------------------------------------------
% TODO: Ez az egész fos mert a dipterv1 végére íródott
\section{Összefoglalás}
A féléves 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.

1
src/content/glossary.tex
View File

@ -154,3 +154,4 @@
\newacronym{rtde}{RTDE}{Real-time Data Exchange}
\newacronym{rdp}{RDP}{Remote Desktop Protocol}
\newacronym{cpu}{CPU}{Central Processing Unit}
\newacronym{oci}{OCI}{Open Container Initiative}

4
src/content/introduction.tex
View File

@ -22,3 +22,7 @@ A második fejezetben részletesen bemutatom a felhő és peremhálózati szám
A harmadik fejezetben egy korábbi 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.
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.
Az ötödik fejezet a végeszközöket kiszolgáló komponensek dinamikus mozgatásával foglalkozik a felhő adatközpont és a peremhálózati rendszerek között.
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.

2
src/content/measurements.tex
View File

@ -1,6 +1,6 @@
% !TeX root = ../thesis.tex
%----------------------------------------------------------------------------
\chapter{Mérések}
\chapter{Alkalmazások tesztelése}
%----------------------------------------------------------------------------
% Ez érdekes lesz

42
src/content/overview.tex
View File

@ -38,7 +38,9 @@ Egy alkalmazás konténer általánosságban egy önálló csomag, amely tartalm
Az alkalmazás konténerek koncepciójának megvalósítására egy népszerű implementáció a \textit{Docker}, amely a \gls{linux} kernelben található izolációs szolgáltatásokra épít. Ezzel valósítja meg, hogy a konténerek egymástól független környezetben tudjanak futni. Egyetlen szoftver erőforrás, amin közösen osztoznak az a kernel maga.
% TODO: Átírni OCI-re
Dockerben az alkalmazást és környezetét úgynevezett képfájlokban (image) tároljuk. Ezek a képfájlok általában csak a legszükségesebb komponenseket tartalmazzák, ezért a virtuális számítógépekhez képfájlaihoz képest kisebb méretűek. Ezeket a képfájlokat az alkalmazás fejlesztése után készítjük és az alkalmazás konténer indításához használjuk \cite{docker_docs}.
\textit{Docker} használatakor, az alkalmazást és környezetét úgynevezett képfájlokban (image) tároljuk. Kezdetben ez a képfájl formátum \textit{Docker} projekt által tervezett saját formátum volt. Később erre alapozva jött létre az \acrfull{oci} által készített \textit{Image Format Specification} (képfájl formátum specifikáció) amely a manapság használt szinte minden kontér futtató környezet támogat \cite{oci_format_docs}. Ennek köszönhetően a \textit{Docker} környezetben épített képfájlok használhatóak más alternatíváknál is, mint a \textit{Podman} \cite{podman_docs}.
Ezek a képfájlok általában csak a legszükségesebb komponenseket tartalmazzák, ezért a virtuális számítógépekhez képfájlaihoz képest kisebb méretűek. Építése során a kívánt szoftver komponenseket (lefordított bináris, scriptek program fájlok, könyvtárak stb.) egy kiinduló képfájlba másoljuk bele. Ez a kiinduló képfájl lehet egy üres környezet, de lehet valamilyen operációs rendszer disztribúció felhasználói módú program környezete. Olyan képfájlok is léteznek, amelyekbe egy adott futtatókörnyezet már előre van telepítve, így csak a kész programunkat kell a megfelelő helyre tenni. Futtatáskor a konténer futtató környezet ezeket a képfájlokat használja fel a konténer fájlrendszerének felépítéséhez, a benne található alkalmazás futtatásához \cite{docker_docs}.
\subsubsection{Kubernetes}
@ -50,15 +52,19 @@ Kubernetes klaszternek nevezzük azt a multihoszt környezetet, ahol több -- eg
A klaszteren belül két jól elkülöníthető szerepkört definiálunk, ezek a master (mester) és a worker (munkás) szereprek. A master felel az erőforrások elosztásáért, a konténerek workerhez rendeléséért és összességében a klaszter irányításáért. A workerek felelnek a konkrét alkalmazásunkhoz tartozó konténerek futtatásáért.
Egy \textit{Kubernetes} környezetben különböző objektumokat definiálunk, amelyekkel leírhatjuk a klaszterünkben futó alkalmazások elvárt állapotát. Ezek az objektumok közül a legkisebb kezelhető egység a \textit{Pod}. A \textit{Pod} egy vagy több futó konténert reprezentáló logikai egység. Az egy \textit{Pod}on belül futó konténerek osztoznak bizonyos névtereken, ilyen a hálózati vagy a folyamatok névtere.
A klaszterünk felügyelete és kezelése az általa kiszolgált Alkalmazás programozói interfész (\acrlong{api}; \acrshort{api}) használatával történik. Ezt az interfészt elérhetik a klaszterben futó szoftverek, de akár a klaszteren kívüli alkalmazások és azokon keresztül pedig az klaszter adminisztrátorai.
% Ide még bőven lehet írni
Egy \textit{Kubernetes} környezetben, az \acrshort{api}-n keresztül különböző objektumokat definiálunk, amelyekkel leírhatjuk a klaszterünkben futó alkalmazások elvárt állapotát. Ezeket az objektumokat a \textit{Kubernetes} dekleratív módon kezeli. Azaz az objektumok segítségével egy állapotot írhatunk le, amely a klaszter elvárt állapotát jelképezi. A \textit{Kubernetes} feladata ezt az állapotot elérni és fenntartani.
Eggyel \enquote{nagyobb} objektum ezeknél a \textit{Deployment}, a \textit{Deployment} egy alkalmazás futtatásához szükséges állapotot írja le. A \textit{Kubernetes} klaszter törekszik a \textit{Deployment}ben megfogalmazott állapot elérésére és fenntartására.
Ezek az objektumok közül a legegyszerűbb példa a \textit{Pod}. A \textit{Pod} egy vagy több futó konténert reprezentáló logikai egység. Az egy \textit{Pod}on belül futó konténerek osztoznak bizonyos erőforrás névtereken, ilyen a hálózati vagy a folyamatok névtere. Azaz az egy \textit{Pod}-on belül futó két konténer a megfelelő rendszerhívásokkal tájékozódhat a másik konténerben futó folyamatok létezéséről. Illetve a hálózati kommunikációs erőforrásokat közösen használják.
A \textit{Podok} életciklusának (létrehozás, törlés) kezelésére a \textit{Deployment} objektum nyújt megoldást. A \textit{Deployment} egy alkalmazás futtatásához szükséges állapotot írja le. Milyen \textit{Podból} és mennyi példánynak kell futnia.
Ezek mellett még rengeteg alkalmazás specifikus objektumot ad rendelkezésünkre a \textit{Kubernetes}. Sőt, mindemellett lehetőség van arra, hogy egyedi erőforrás objektumokat is definiáljunk. Amelyekkel könnyedén bővíthetjük a klaszterünk funkcionalitását.
\subsubsection{Mikroszolgáltatások}
A mikroszolgáltatás modell egy újkeletű architekturális megközelítés a szoftver fejlesztésben. Ebben a megközelítésben egyfunkciós modulokat tervezünk és fejlesztünk, amelyek jól definiált Alkalmazás programozói interfész (\acrlong{api}; \acrshort{api}) használatával kommunikálnak egymással \cite{microservices}. Ennek hála, amíg egy komponens teljesíti az elvárt \acrshort{api} definíciót, addig szabadon kicserélhető
A mikroszolgáltatás modell egy újkeletű architekturális megközelítés a szoftver fejlesztésben. Ebben a megközelítésben egyfunkciós modulokat tervezünk és fejlesztünk, amelyek jól definiált \acrshort{api} használatával kommunikálnak egymással \cite{microservices}. Ennek hála, amíg egy komponens teljesíti az elvárt \acrshort{api} definíciót, addig szabadon kicserélhető
Az egységek a fejlesztése, és tesztelése sokkal gyorsabb ütemben tud haladni a kisebb kódbázis miatt. A rajtuk eszközölt fejlesztések sokkal hamarabb kerülhetnek ki az éles rendszerbe, hiszen a változtatásuk nem érinti a teljes rendszert, ezért könnyebb őket frissíteni, vagy valamilyen szélsőséges esemény hatására visszaállni egy korábbi változatra.
@ -109,7 +115,7 @@ A szójegyzék jelenlegi (2.0-ás verzió) kiadása alapján néhány fontosabb
Az előbbiek alapján ez a dolgozat peremhálózati \gls{adatkozpont}oknak azokat tekinti, amelyek logikailag -- és valamilyen szinten fizikailag is -- a felhő és a \gls{vegeszkoz}ök között helyezkednek el. Ezen a tartományon értelmezve \enquote{közel} áll a \gls{vegeszkoz}höz.
Ezt a fajta logikai \enquote{közelség} úgy valósul meg, hogy az úton, amelyet egy hálózati üzenetnek be kell járnia a \gls{vegeszkoz}től a felhőig, a peremhálózati \gls{adatkozpont}ot a lehető legközelebb igyekszünk helyezni a \gls{vegeszkoz}höz. Következésképp egy hálózati csomagnak jelentősen rövidebb utat kell bejárnia a peremhálózati \gls{adatkozpont}ig, mint a központi megfelelőjéig. Egy ilyen architektúra vázlatát mutatja be \aref{fig:overview_with_edge}.\ ábra. Az \gls{adatkozpont} \enquote{közelebb} helyezése a végeszközökhöz számos előnnyel jár.
Ez a fajta logikai \enquote{közelség} úgy valósul meg, hogy az úton, amelyet egy hálózati üzenetnek be kell járnia a \gls{vegeszkoz}től a felhőig, a peremhálózati \gls{adatkozpont}ot a lehető legközelebb igyekszünk helyezni a \gls{vegeszkoz}höz. Következésképp egy hálózati csomagnak jelentősen rövidebb utat kell bejárnia a peremhálózati \gls{adatkozpont}ig, mint a központi megfelelőjéig. Egy ilyen architektúra vázlatát mutatja be \aref{fig:overview_with_edge}.\ ábra. Az \gls{adatkozpont} \enquote{közelebb} helyezése a végeszközökhöz számos előnnyel jár.
\begin{figure}[h!]
\centering
@ -128,7 +134,7 @@ Az adatforgalomért sok esetben az interneten szolgáltatók között is fizetni
% Privacy/Security
\section{felhő és perem rendszerek együttes alkalmazásának előnyei} % A perem és a felhő hálózatok mire jók
\section{Felhő és perem rendszerek együttes alkalmazásának előnyei} % A perem és a felhő hálózatok mire jók
Ugyan a peremhálózati adatközpontok alkalmazása önmagában sok előnnyel kecsegtet, fontos megjegyezni, hogy a peremhálózati rendszerek nem fogják és nem is tervezik kiváltani a tradicionális megközelítést. Sokkal inkább azt kiegészítve szimbiózisban tudnak igazán érvényesülni.
@ -143,18 +149,20 @@ Számos olyan alkalmazás van, amelynél a peremhálózati és felhő rendszerek
Jelenleg is már több alkalmazásnál is használják, vagy tervezik használni. Ilyenek például az önvezető járművek \cite{liu2019edge}, ipari rendszerek távfelügyelete \cite{hao2020cloud}, betegfelügyelet \cite{wang2020secure}, felhő alapú játék szolgáltatások \cite{edge_gaming}, okos otthonok és városok \cite{shi2016edge} és még sok minden más területen \cite{edge_companies}.
A dolgozatom részeként két konkrét alkalmazáson mutatom be a felhő és a peremhálózati rendszerek használatát. Ezek az alkalmazások korábban elkészült munkákon alapulnak, amelyeken jól demózhatóak az előnyök. Ezeknek a megvalósítását a \aref{chapter:birbnetes}.\ és \aref{chapter:ursim}.\ fejezetek részletezik.
A dolgozatom részeként két konkrét alkalmazáson mutatom be a felhő és a peremhálózati rendszerek használatát. Ezek az alkalmazások korábban elkészült munkákon alapulnak, amelyeken jól demózhatóak az előnyök. Ezeknek a megvalósítását a \aref{chapter:birbnetes}.\ és \aref{chapter:ursim}.\ fejezetek részletezik.
\section{Alkalmazás futtatási és fejlesztési keretrendszerek}
\label{sec:frameworks}
% itt le lehet írni, hogy igazából mit is kell egy keretrendszernek tudnia
Ahhoz, hogy az alkalmazásunkat könnyen tudjuk egy felhő és peremhálózati környezetben futtatni érdemes egy már létező keretrendszert használni. Az ilyen keretrendszerek nagyban megkönnyítik a fejlesztést, hiszen az adott alkalmazási terület általánosan felmerülő problémáit és kérdéseit megoldja. Így az alkalmazás fejlesztőinek nem szükséges azzal foglalkozni, hogy pontosan hogy indul el az alkalmazásuk egyik vagy másik helyen, mert ezt elfedi előlük a keretrendszer.
A feladatom megvalósításához több keretrendszert is megvizsgáltam, ezeket az alábbiakban általánosságban részletezem. A feladat specifikus elvárásokat pedig \aref{chapter:running_on_the_edge}.\ fejezetben fejtem ki.
Egy ilyen keretrendszernél szükség van arra, hogy lehetőséget biztosítson egyes alkalmazás komponenseket a peremhálózati adatközpontban futtatni, másokat pedig a központi felhőben. Biztosítson valamilyen beavatkozható logikát arra, hogy egy alkalmazás mely adatközpontban kerül futtatásra. Elfedje az egyes futtató adatközpontok sajátosságait.
A feladatom megvalósításához több ilyen keretrendszert is megvizsgáltam, ezeket az alábbiakban általánosságban részletezem. A feladat specifikus elvárásokat pedig \aref{chapter:dynamic_scheduling}.\ fejezetben fejtem ki.
\subsection{EdgeX Foundry}
Az \textit{EdgeX Foundry} egy mikroszolgáltatásokból felépülő környezet, amelynek a célja az, hogy a perem alkalmazások fejlesztésénél gyakran felmerülő feladatokat ellátó komponensek egységesek legyenek \cite{edgexfoundry_docs}.
Az \textit{EdgeX Foundry} egy mikroszolgáltatásokból felépülő környezet, amelynek a célja az, hogy a perem alkalmazások fejlesztésénél gyakran felmerülő feladatokat ellátó komponensek egységesek legyenek \cite{edgexfoundry_docs}.
A keretrendszer komponensei lazán csatoltak. Ez lehetővé teszi, hogy akár az előbb bemutatott három szintű peremhálózati architektúránál akár több réteget is bevezessünk. A komponensek mind platform függetlenek és a megfelelő környezetben egymástól függetlenül bárhol futtathatóak.
@ -205,7 +213,7 @@ A peremhálózaton megtalálható a kommunikációs interfész párja \textit{Ed
Az alkalmazás komponensek ugyanúgy képesek kommunikálni egymással, mint egy \textit{Kubernetes} környezetben a perem és a központi felhő komponensek között. Ugyanazok a monitorozó, felügyeleti és ütemezős eszközök működnek mindkét oldalán a rendszernek. Ezáltal a \textit{KubeEdge} lehetővé teszi, hogy a hagyományos formában felépített mikroszolgáltatás alapú alkalmazások komponenseit kiszervezze a peremhálózatra. Viszont bizonyos helyzetekben az alkalmazásnak a felelőssége megoldani, hogy áthidalja az olyan helyzeteket, amikor nem áll rendelkezésre kapcsolat a központi felhővel. Ahhoz, hogy ezt megoldja, a \textit{Kubernetes} klaszteren belül használt hálózati plugin segítségével kiterjeszti és összekapcsolja a \textit{Pod} hálózatot.
Mindennek köszönhetően a \textit{KubeEdge} platformon futtatható alkalmazások fejlesztése nagyon könnyű, hiszen az szinte teljesen megegyezik a mikroszolgáltatás alapú alkalmazások fejlesztésével. Cserében a \textit{KubeEdge} nem implementál dinamikus ütemezési megoldásokat. Az egyes alkalmazásokat kézzel kell a kívánt peremhálózati szerverek valamelyikéhez rendelni. Ez jelentősen megnehezíti a skálázását az alkalmazásoknak, hiszen nem tudják a peremhálózatokra telepített több számítógép által nyújtott terhelés eloszlási lehetőségeket kihasználni\cite{kubeedge_crds}.
Mindennek köszönhetően a \textit{KubeEdge} platformon futtatható alkalmazások fejlesztése nagyon könnyű, hiszen az szinte teljesen megegyezik a mikroszolgáltatás alapú alkalmazások fejlesztésével. Cserében a \textit{KubeEdge} nem implementál dinamikus ütemezési megoldásokat. Az egyes alkalmazásokat kézzel kell a kívánt peremhálózati szerverek valamelyikéhez rendelni. Ez jelentősen megnehezíti a skálázását az alkalmazásoknak, hiszen nem tudják a peremhálózatokra telepített több számítógép által nyújtott terhelés eloszlási lehetőségeket kihasználni \cite{kubeedge_crds}.
\subsection{\acrshort{aws} \acrshort{iot} Greengrass}
@ -233,3 +241,13 @@ Az \textit{Azure \acrshort{iot} Edge} előnye, hogy egy kiforrott ipari megoldá
\subsection{Kubernetes Federation}
% Nem erre való, de jó erre
A \textit{Kubernetes Federation} (Röviden \textit{Kubefed}) eredetileg a \textit{Kubernetes} projekt részeként született \cite{kubefed_old}. Később külön projektként folytatódott a fejlesztése. A projekt célja az, hogy több teljesen önálló \textit{Kubernetes} klaszter \enquote{fölé} egy egységes vezérlő réteget húzzon. Ezzel megvalósítva a több klaszter egységes kezelését és felügyeletét \cite{kubefed_readme}.
Az üzemeltetés szempontjából, ezt úgy valósul meg, hogy kijelöl egy federáció vezérlő (federation controller) klaszter. Ez lesz az irányító klaszter (nagyjából olyan szerepe van mint a mester node-nak a klaszteren belül). Ehhez csatlakozik be a többi klaszter. Az egyes federált funkcionalitások megvalósítására egyedi \acrshort{api} objektumokat hoz létre. Ilyen objektumokkal tudjuk kezelni egységesen a multiklaszter erőforrásokat \cite{kubefed_userguide}.
Egy federált \textit{Kubernetes} környezetnek több felhasználása is lehet. De a felhasználási mintákban szinte alapvető, hogy az önálló klaszterek geológiailag elhatárolva üzemelnek \cite{kubernetes_why_federation}. Ez megfeleltethető annak, ahogy a peremhálózati rendszerek és a felhő rendszerek is különállóan üzemelnek.
Bár egyértelműen látszik, hogy a \textit{Kubefed} elsősorban nem a peremhálózati rendszerek által nyújtott elvárások kielégítésre lett kifejlesztve. Általános klaszter federációs megoldásként viszont képes arra, hogy az ezen a téren támasztott elvárásoknak is többszörösen megfeleljen.
Népszerűségének köszönhetően sok dokumentáció, leírás és egyéb segítség létezik hozzá. Emellett erősen épít a \textit{Kubernetes} szolgáltatásaira és tervezési mintáira. Ezeknek köszönhetően az üzemeltetése viszonylag egyszerű az olyan illetők számára aki már jártas a \textit{Kubernetes} klaszterek terén.

4
src/content/scheduling.tex
View File

@ -1,7 +1,7 @@
% !TeX root = ../thesis.tex
%----------------------------------------------------------------------------
\chapter{Futtatás a peremhálózaton}
\label{chapter:running_on_the_edge}
\chapter{Alkalmazás komponensek dinamikus ütemezése}
\label{chapter:dynamic_scheduling}
%----------------------------------------------------------------------------

4
src/content/test_system.tex Normal file
View File

@ -0,0 +1,4 @@
% !TeX root = ../thesis.tex
%----------------------------------------------------------------------------
\chapter{Teszt környezet kialakítása}
%----------------------------------------------------------------------------

27
src/content/ursim_impl.tex
View File

@ -4,7 +4,7 @@
\label{chapter:ursim}
%----------------------------------------------------------------------------
A negyedik ipari forradalom az \enquote{okos} gyártásról szól. A korábban helyileg telepített számítási erőforrásokat felhasználó előre meghatározott, kötött gyártás irányítást leváltja a felhő alapú folyamat irányítás és optimalizálás. Itt már nem csak a gyártás a lényeg, a folyamatok elemzésével és mély megértésével a hangsúly a precíz optimalizációra és produktivitás növelésre hegyeződik ki. Ehhez felhasználják az ipar legújabb vívmányait: Egyre nagyobb teret hódít az Ipari \acrshort{iot} (\acrshort{iiot}), a mesterséges intelligencia és gépi tanulás, a gép-gép kommunikáció, valósidejű adatgyűjtés, \textit{Big Data} és még sok minden más \cite{whatisindustry4}.
A negyedik ipari forradalom az \enquote{okos} gyártásról szól. A korábban helyileg telepített számítási erőforrásokat felhasználó előre meghatározott, kötött gyártás irányítást leváltja a felhő alapú folyamat irányítás és optimalizálás. Itt már nem csak a gyártás a lényeg, a folyamatok elemzésével és mély megértésével a hangsúly a precíz optimalizációra és produktivitás növelésre hegyeződik ki. Ehhez felhasználják az ipar legújabb vívmányait: Egyre nagyobb teret hódít a gyártástechnikában az Ipari \acrshort{iot} (\acrshort{iiot}), a mesterséges intelligencia és gépi tanulás, a gép-gép kommunikáció, valósidejű adatgyűjtés, \textit{Big Data} és még sok minden más \cite{whatisindustry4}.
A robotvezérlés precíz időzítést igényel, hiszen itt pár-tíz milliszekundumos eltérések akár katasztrofális következményekkel járhatnak. Éppen ezért sokáig a robotok közvetlen vezérlésének kiszervezése a felhőbe nem volt megoldható. A peremhálózati rendszerekkel viszont ez megváltozhat.
@ -38,9 +38,9 @@ A két robotkar végére két különböző gripper van telepítve, mindkettő \
Az demó által használt \textit{Universal Robots} robotkarok többféle kommunikációs interfésszel rendelkeznek, amelyeket a \textit{Control Box} valósít meg \cite{robot_client_interfaces}:
\begin{itemize}
\item \textbf{Primary/Secondary Interfaces}: A robotok vezérlő szoftvere két interfészt tart fenn a robotkar státuszának módosítására és megfigyelésére. Az elsődleges (primary) interfészen olvasni és írni is lehet a robot állapotát a másodikon csak olvasni. Elsősorban ez az interfész a grafikus kezelőfelülettel történő kommunikációra lett kifejlesztve. URScript parancsokat képes küldeni és fogadni 10Hz-es rátával (Azaz 100ms gyakorisággal).
\item \textbf{Primary/Secondary Interfaces}: A robotok vezérlő szoftvere két interfészt tart fenn a robotkar státuszának módosítására és megfigyelésére. Az elsődleges (primary) interfészen olvasni és írni is lehet a robot állapotát a másodikon csak olvasni. Elsősorban ez az interfész a grafikus kezelőfelülettel történő kommunikációra lett kifejlesztve. URScript parancsokat képes küldeni és fogadni 10Hz-es rátával (Azaz 100ms gyakorisággal küldhetünk vagy fogadhatunk valamilyen információt).
\item \textbf{Real-time Interfaces}: A valós idejű interfész működése hasonló az előbb említett elsődleges másodlagos intefész működéséhez. Úgyanúgy státuszt tudunk vele megkapni és URScript parancsokat fogad. A fő különbség a működési ráta. Itt akár 500Hz-es rátát is elérhetünk (azaz 2ms gyakorisággal küldhetünk vagy fogadhatunk valamilyen információt) \cite{robot_controll_tcpip}.
\item \textbf{Real-time Interfaces}: A valós idejű interfész működése hasonló az előbb említett elsődleges másodlagos intefész működéséhez. Úgyanúgy státuszt tudunk vele megkapni és URScript parancsokat fogad. A fő különbség a működési ráta. Itt akár 500Hz-es rátát is elérhetünk (azaz 2ms gyakorisággal) \cite{robot_controll_tcpip}.
\item \textbf{Dashboard Server}: A robot grafikus kezelőfelületét is képesek vagyunk közvetlenül, programozottan vezérelni \acrshort{tcp} kapcsolaton keresztül. Ez olyan alapvető funkciókat enged végrehajtani, mint az eltárolt programok betöltése, futtatása, felhasználók hozzáférési szintjének szabályozása, és alapvető robot státusz információk lekérdezése.
@ -108,19 +108,21 @@ A program a konfigurációs beállításait egy \gls{ini} fájlban tárolja. Eze
Az \gls{ini} fájl mellett a program a konkrét lépésekhez tartozó koordinátákat egy \textit{Microsoft Excel} \gls{xlsx} fájlból olvassa ki. Ebben a fájlban mindkét robotkarhoz tartozóan fel vannak sorolva az egyes pózok leírásai sorrendben. % koordináták mind tool- és joint térben. %TODO verify naming
\section{Tervezés} % Itt foglalom össze, hogy hogy terveztem meg ezt a fost
\section{Felkészítés a peremhálózati alkalmazásra} % Itt foglalom össze, hogy hogy terveztem meg ezt a fost
Alapos tervezést igényelt a fenti monolit demó átültetése egy felhő és perem számítástechnikai rendszerbe oly módon, hogy annak előnyeit megfelelően ki tudja használni.
\subsection{Keretrendszer}
% TODO: Itt nagyon sok mindent át kell írni
\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.
%\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.
\subsection{Architektúra}
@ -251,6 +253,7 @@ Ennek a komponensnek a működése nagyban függ a konkrét keretrendszertől é
\subsubsection{\textit{Metrics Service}}
% TODO: Ez mekkora kamu
% A metrika gyűjtés tervezése és implementációja még hátra van.

BIN
src/figures/birbox_hardware_blockschema.pdf Normal file
View File

Binary file not shown.

BIN
src/figures/birbox_software_blockdiagram.pdf Normal file
View File

Binary file not shown.

BIN
src/figures/doboz_new.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 1.5 MiB

3
src/thesis.tex
View File

@ -1,4 +1,4 @@
% !TeX spellcheck = en_US
% !TeX spellcheck = hu_HU
% !TeX encoding = UTF-8
% !TeX program = xelatex
@ -75,6 +75,7 @@
\include{content/birbnetes_impl}
\include{content/ursim_impl}
\include{content/scheduling}
\include{content/test_system}
\include{content/measurements}
\include{content/conclusion}