2021-12-19 01:06:13 +01:00
parent a30824b7e3
commit 6ceed8ed9a
8 changed files with 43 additions and 34 deletions
							
							
								
							
							
						
@@ -3,20 +3,27 @@
\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.
A munkám első részében a felhő és peremhálózati számítástechnika alkalmazási területeit, jellemző felhasználási módjait tekintettem át. Megvizsgáltam több keretrendszert is, az ezek mögött rejlő ötleteket és megoldásokat és kiválasztottam az ideális környezetet a feladatom megvalósításához..
Az irodalomkutatás során szerzett ismeretek alapján olyan alkalmazásokat kerestem, amelyek működéséhez előnyösen járul hozzá a peremhálózati rendszerek alkalmazása. Kutatásaim során kettő alkalmazást is találtam, amelyek egyenként különböző előnyeit képesek kihasználni a felhő és peremhálózati rendszerek együttes alkalmazásának. Az alkalmazásokat részletesen tanulmányoztam és bemutattam.
% TODO
% átalakítottam, hogy jó legyen edge-be
% kimértem, hogy jó lett
Ezek után megvizsgáltam a dinamikus átütemezés előnyeit és megvalósítási lehetőségeit a választott alkalmazásaim kontextusában.
Megterveztem és felállítottam egy tesztkörnyezetet az átalakított alkalmazások tesztelésére. Ez a tesztkörnyezet megfelelő modelljét adta egy éles peremhálózati és felhő rendszernek. 
Ezek után az elkészített tesztkörnyezetben demonstráltam a dinamikus komponens mozgatást működését és hatásait felhő és peremhálózati infrastruktúrák közt.
\section{Jövőbeni tervek}
% TODO: Big todo
Az elkészült ütemező rendszert tekintve érdekes fejlesztési irány lenne megvizsgálni annak a lehetősségét, hogy miként lehetne általánossá tenni a működését annak érdekében, hogy könnyen lehessen újabb illeszteni hozzá. Jelenleg a rendszer elkészítése során csak az általam vizsgált alkalmazások igényeit és működését vettem figyelembe. Úgy vélem egy általános megoldás mindenképpen hiánypótló lenne jelenleg az iparban.
Mint ahogy \aref{sec:birbnetes-evaluation}.\ alfejezetben is említettem, a peremhálózaton futó hangminta előszűrés áteresztő képessége szinte csalódáskeltően alacsony. Mindenképpen meg kell vizsgálni annak a lehetőségét, hogy miként lehet a dinamikus ütemezés kontextusában a skálázást is megvalósítani.
A robotkarok vezérlését megvalósító alkalmazás dinamikus ütemezésénél egy erős megkötés volt, hogy a közvetlen vezérlést megvalósító szolgáltatások belső állapottal rendelkeznek, így preemptív átütemezésük szinte megoldhatatlan. Úgy vélem, hogy megoldható lenne a vezérlési komponenseket állapotmentessé tenni illetve megoldani a biztonságos átütemezését az egyes komponenseknek miközben egy \textit{program} épp fut. Ezzel tovább lehet növelni az alkalmazás flexibilitását és ellenállását a bekövetkező hálózati változásoknak, ezzel is javítva a teljesítőképességét és megbízhatóságát a felhő alapú robotvezérlésnek.
Implementációs szempontból úgy vélem hasznos ötlet lenne a várakozási sorok kiszervezése az egyes előszűrő szolgáltatásokból és egy közös várakozási sort fenntartani minden adatközpontban ahol a feldolgozó egység fut. Ennek az apró változtatásnak hála a skálázás megvalósításával sokkal hatékonyabb lenne az alkalmazás működése, hiszen az újonnan induló komponensek a korábban felgyűlt mintákon is tudnának dolgozni. Emellett egy-egy feldolgozó szolgáltatás kiesése nem járna adatvesztéssel.
% közös queue/site