Checkpoint

I just got struck by the tought of loosing my work again.

drawio/workload_move

@@ -0,0 +1 @@
+<mxfile host="Electron" modified="2021-12-17T23:37:06.115Z" agent="5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/15.4.0 Chrome/91.0.4472.164 Electron/13.5.0 Safari/537.36" etag="GZSC3sqwAeZHdOnhQ7tZ" version="15.4.0" type="device"><diagram id="NCvFC_-pmfNS0SrqqLgx" name="Page-1">5VhNc6M4EP01HJMCYTAc/ZXJVmVqpiqH3TnKIEATGXmFiO38+pVAfAjBjp3YO5XaHBKpkVrQ7/Xrjix3tTt+YXCffaUxIhaw46Plri0A5r4tfkvDqTZ4HqgNKcNxbXI6wzN+Q8qo9qUljlGhLeSUEo73ujGieY4irtkgY/SgL0so0U/dwxQZhucIEtP6J455pqyObXcPHhFOM3V04KkHO9gsVoYigzE99EzuxnJXjFJej3bHFSIydk1c6n0PE0/bF2Mo5+dsePz2lQZR/gUuyx+AFD8f4tdvd45y8wpJqb7YWrnWwuEcsUxAKSdhgWU0twS+qE/hpyY+jJZ5jOQRtuUuDxnm6HkPI/n0IAghbBnfETFzxLDgjL6gFSWUCUtOc7FsmWBCGpMF3CRJQBRJO8254oPjibl6UcQ4Ok6GwGkDKwiJ6A5xdhJL1AYwV1goMoJAzQ89aBtb1kO1YTFUbEpb113AxUDF/IL4z42AoljwT00p4xlNaQ7JprMu9ZB3a54o3atA/0Scn1TwYMmpDkN9pjzo0jgyRCDHr/q+saCord8pFh7b+PszPf4zexBXDlmKuNrV5/LAUfALPwUtWYQMPxVE7ee8H7XASBqxfOVZoTMK5xPcikzSIIAEp7kYRyLiSDB/KXmNhews1IMdjuMabVTgN5F7SOG9lx9Vfaa3tLz1IFECMSfyuCWMXtKKKYN0m0wjpaDqqE63+rSY5vBkzt3Z98D1Qw2vO3XkB+nkAk9z64S6B5okBboJARxgyuYQ+ahkr1WWSrxRHi9kNZKQE1gUONL5oOd0H1Ff7v6lJgiE2Okvtb2a/OhP1kdtdlKziinfaYE5ppJ0rFa8loxPg+dcCkzLXYISPsLcLeWc7kxhjz0UxDOjCognAdi6vv8hYeoJuDei343tw4Qb1A/3PN0xHIlCdG/3fua62/l5sigYBU+9ZUoaJl/fKH+u1jGIQe3xuqnijqSKTyRzij3MtZzx/y5lN7TURqn8+0ceV63ImtftSdH4EO9Uu6nXGVkoVI6PS+8EfS8QXllZC5Wm53Q3jWmQ3XLeywbfDrzZalrHY5TAknQf+6GOyGA0MDsifyShwK0aIsf7T5V1KvYXKK7TV9x2MqG4w2Y3iFDV7BqauBUv4tmfQBO9AYPc4J2aOJuF92HvJ9DderfRxJk3/vq31cTQJPkGWOLocLNoRsJqP9LijV+gaddoJweqNuwuryA6wzLke4bmhCOEHRbbq2kOGPknuIFj+b+Do+2qfxscZnP9hOqyT8iwC/j05X6xnj1UJecKSBpaPDer+dj1xs2qORhr/gaQ9e+HmisyCUAMi6yt2+dnlPCxl553x1ReSN7Xl4Cg/ivdNqW4uqJ05CinPMqs3r9E/9Z0nQvnCBOugLChnSMIu2PV/nYQn9Gw/VaI+wg7nwBixx8ksWtCPCrI74BYTLsL6Lq76W7x3c0/</diagram></mxfile>

src/content/scheduling.tex

@@ -4,24 +4,103 @@
 \label{chapter:dynamic_scheduling}
 %----------------------------------------------------------------------------
 
+Az előző fejezetekben ismertetett, átalakított alkalmazások jól ki tudják használni a peremhálózati informatikai infrastruktúra adta lehetőségeket. Mint azt a \aref{sec:peremhalozati_rendszerek}.\ szekcióban is ismertettem a peremhálózati rendszerek a hagyományos adatközpontokkal szemben számos különbséget képviselnek. Egyik ilyen különbség a telepítésük sűrűsége. Ez a tulajdonsága lehetővé teszi, hogy a megvalósított alkalmazás szempontjából bizonyos szolgáltatásokat a felhasználókhoz \enquote{közel} futtasson. Ennek a \enquote{közelségnek} önmagában számos előnye tud lenni, mint például a csökkentett hálózati késleltetés és terhelés. Tipikusan a peremhálózati infrastruktúrákra jellemző, hogy a felhő végtelennek tűnő számítási kapacitásához képest erősen limitált erőforrások állnak rendelkezésre.
 
+Könnyen beláthatjuk ezekből adódóan, hogy fontos szerepe van annak a kérdésnek, hogy egyes szolgáltatásokat mikor és melyik peremhálózati rendszeren futtatunk, vagy hogy megéri-e kihelyezni őket a felhő által nyújtott futtatókörnyezetből. Egy rosszul megválasztott szolgáltatás elhelyezés könnyen lehet, hogy az előnyök teljes ellentétét idézi elő megnövekedett költségek mellett. Mivel a peremhálózati rendszerek sokkal nagyobb számban állnak rendelkezésre és a helyes elhelyezés is kockázatos feladat, ezért az elhelyezési feladatokat minden esetben \enquote{kézzel} megoldani jelentős kihívást tud jelenteni.
 
-\section{Felhős keretrendszer kiválasztása}
+Megoldást jelenthet a problémára ha az egyes szolgáltatás komponenseket automatikusan tudjuk peremhálózati infrastruktúrába kihelyezni. Egy olyan ütemező algoritmusra van szükség, amely képes kiválasztani az ideális futtatási helyet a megfelelő komponenseknek és automatikusan áthelyezni (azaz ütemezni) oda. Így nincs szükség emberi beavatkozásra a megfelelő peremhálózati adatközpont kiválasztásához.
+
+A dinamikus ütemezés több kérdést és problémát is felvet, hiszen nem egyértelmű, hogy melyik alkalmazás szempontjából mi számít ideális környezetnek. Illetve ha tudjuk, hogy mi számít ideális környezetnek, hogy tudjuk felmérni, hogy melyik környezet lehet ideális jelölt az alkalmazás futtatására.
+
+Ebben a fejezetben megvizsgálom a dinamikus áthelyezés megvalósításának lehetőségét a korábban ismertetett alkalmazásokon, illetve egy egyszerű megoldást is tervezek, amely a probléma megoldását mutatja be.
+
+\section{Alkalmas felhős keretrendszer kiválasztása}
 \label{sec:cloud_framework}
 
-% 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{KubeFed}-et választottam.
 
+A kiválasztásnál elsősorban azt vettem figyelembe, hogy milyen lehetőségeket adnak az egyes keretrendszerek a szolgáltatások dinamikus átütemezésére felhő és perem, illetve perem és perem adatközpontok között.
 
-% Itt leírom, hogy az összes egy nagy kula, és a kubefedet is csak azért választom, hogy legyen egységes controlplane
+A \textit{KubeFed} mellett a \textit{Kubeedge} volt a másik keretrendszer, amely ideálisnak tűnt, ám mélyebb vizsgálatot követően elvetettem. Ennek oka a korábban is ismertetett hiányosságai kezdetleges állapota volt. 
 
-% támogatja az ütemezést
-% saját ütemezője nincs
-% 
+Az \textit{EdgeX Foundry} és \textit{Porject EVE} használatát korán elvetettem. Tipikusan erős különbségeket feltételeznek a perem és a felhő adatközpontokkal szemben támasztott elvárásoktól. Emiatt olyan megoldásokat kínálnak, amelyek teljesen más igényeket próbálnak kielégíteni, mint amiket az én eredeti problémafelvetésem támaszt. Emiatt ezeknek a megoldásoknak a használata csak felesleges nehézségeket jelentene.
 
-\section{Komponensek dinamikus ütemezése}
+A megvizsgált \acrshort{paas} rendszereket azért nem szerettem volna használni, mert célom volt egy teljesen nyílt megoldás készítése, ami nyílt szoftverekre épül és nem függ egy konkrét megoldástól. Továbbá így előfizetésre se volt szükségem.
+
+A \textit{KubeFed} saját ütemezőt nem implementál (mint ahogy egyik másik vizsgált megoldás sem). Viszont az általa megvalósított egységes vezérlő felületnek köszönhetően nagyon könnyen képesek vagyunk az egyes komponenseket adatközpontokra mozgatni, így könnyen tudunk olyan saját ütemezőt készíteni, ami megvalósítja a feladatot. Emiatt választottam ezt a keretrendszert.
+
+\section{Szolgáltatás létesítés és mozgatás \textit{KubeFed} környezetben}
+
+Konténerizált alkalmazás környezetben egy futó konténer mozgatása csak korlátozott értelemben lehetséges. Mivel az alkalmazás nem egy virtualizált hardveren, hanem magán a hoszt operációs rendszeren fut egy konténerizált környezetben, így nincs egyszerű arra, hogy egy alkalmazást a memória tartalmával együtt mozgassunk, úgy, hogy az egy másik hoszton ugyan úgy tudja folytatni a működését. 
+
+Ezért az áthelyezés az adott konténer leállítását és egy másik hoszton (másik klaszterben) való elindítását jelenti. Ez állapotmentes szolgáltatásoknál nem jelent nagyobb problémát, hiszen nincs belső állapot amit meg kell őrizni a mozgatás során. Belső állapottal rendelkező alkalmazások esetén viszont ez komplex problémát is jelenthet akár. 
+
+Állapotmentes szoftverek esetén lehetőségünk van arra, hogy a konténerek \enquote{mozgatása} alatti kieséseket minimalizálhatjuk azzal, hogy az új konténereket előbb indítjuk el, mint hogy a régit leállítanánk. Ez idő alatt lehetőség van a még futó kéréseket befejeznie a leállítandó alkalmazásnak, miközben az új kérések már az újonnan indított alkalmazáshoz érkeznek. Egy ilyen átterheléses áthelyezés időbeni lefutását mutatja be \aref{fig:workload_move}.\ ábra. Ideális esetben egy ilyen mozgatás teljes mértékben szolgáltatás kiesés nélkül megoldható.
+
+\begin{figure}[h!]
+	\centering
+	\includegraphics[width=0.7\textwidth]{figures/workload_move}
+	\caption{Állapotmentes alkalmazás mozgatása \enquote{A} hosztról \enquote{B} hosztra.}
+	\label{fig:workload_move}
+\end{figure}
+
+Az átterheléses mozgatás belső állapottal rendelkező alkalmazások esetén nem könnyen oldható meg, hiszen a belső állapot szinkronizálása komoly feladat és többnyire nem is oldható meg az alkalmazás közreműködése nélkül.
+
+
+Az alkalmazások leállítását és másik klaszterben való elindítását a \textit{KubeFed} teljes mértékben támogatja. Az összes federált \acrshort{api} objektum esetén lehetőséget ad arra, hogy kiválasszuk, hogy melyik klaszterben hozza létre. De még arra is lehetőséget nyújt, hogy bizonyos tulajdonságait az objektumoknak klaszterre szabva változtassuk meg. 
+
+Ezeknek a konstrukcióknak a segítségével az ütemező szoftvernek csak egy \acrshort{api} hívást kell intéznie a \textit{Kubernetes} \acrshort{api}-hoz és ezzel meg tudja változtatni az ütemezést. A fentebb vázolt átterheléses mozgatást magától nem tudja megvalósítani a \textit{KubeFed}, de megfelelő \acrshort{api} hívásokkal ez is megoldható.
+
+\section{Alkalmazás komponensek dinamikus ütemezésének vizsgálata}
+
+Egy alkalmazás komponens dinamikus ütemezésének megvalósítása nagyon sok esetben támogatást igényel az alkalmazástól. Annak eldöntése, hogy mikor ütemezzük a komponenseket, hova és mit nyerünk az ütemezéssel mind-mind az alkalmazás saját tulajdonságaitól és belső működésétől függ. 
+
+Emellett a konkrét ütemezés megvalósítása is erősen függ az alkalmazás tulajdonságaitól működésétől.
+
+A következőkben a korábban bemutatott alkalmazásokat fogom megvizsgálni abból a szempontból, hogy ezeket a problémákat, hogy lehet megoldani. Illetve milyen támogatásra van szükség az alkalmazástól.
+
+\subsection{Intelligens madárhang felismerés}
+
+Ebben az alkalmazásban a peremhálózati adatközpontba egy előszűrést megvalósító komponens kerül. Ennek a komponensnek a feladata, hogy a sok \acrshort{iot} eszköz által feltöltött hangminták által generált hálózati terhelést csökkentse azzal, hogy intelligens felismerést futtatva csak a releváns hangmintákat küldi tovább.
+
+Ez a komponens állapotmentes és 
+
+\subsubsection{Ütemezési döntés meghozása}
+
+\subsubsection{Ütemezés megvalósítása}
+
+\subsection{Robot vezérlés}
+
+A felhő alapú robotkarok alkalmazásánál a peremhálózati adatközpontba egy vagy több alacsony szintű mozgást vezérlő komponens kerülhet. Ezek egymással egy osztott memóriát megvalósító \textit{Redis} adatbázison keresztül kommunikálnak. Ezek a komponensek belső állapottal rendelkeznek. Létrehozásukkor megkezdik a hozzájuk rendelt \textit{program} letöltését és futtatását. Ha a \textit{program} véget ért, akkor a komponensek kilépnek.
+
+\subsubsection{Ütemezési döntés meghozása}
+
+Ebben az alkalmazásban annak a megállapítása, hogy milyen logika alapján lehet eldönteni, hogy hol futtassuk az alkalmazásunkat jelentősen egyszerűbb: A valósidejű vezérléshez az elérhető legkisebb késleltetést kell elérnünk. Ahhoz, hogy meg tudjuk állapítani, hogy melyik az a peremhálózati adatközpont, amely ilyen tulajdonságokkal rendelkezik, ismernünk kell a robotkarokat tartalmazó telephely és az összes számításba jövő peremhálózati adatközpont közötti késleltetést.
+
+Ha ezt ismerjük, akkor egy egyszerű minimum függvényt használva, ki tudjuk választani az ideális futtatás helyét.
+
+\subsubsection{Ütemezés megvalósítása}
+
+A vezérlést megvalósító komponens belső állapottal rendelkezik. Futás közbeni átütemezése ezért nem megvalósítható. A robotkarok mozgatása nem engedhet meg kiesést, hiszen a vezérlés elvesztése akár katasztrofális következményekkel is járhat. A belső állapottal rendelkező komponensek áthelyezése kiesés nélkül viszont komplex feladat.
+
+Mivel \aref{sec:edge_layer_plans}.\ szekcióban kikötöttük, hogy minden programnak biztonságos állapotba kell helyeznie a robotkarokat lefutása végén. Illetve ebből az ismert állapotból legyen képes megkezdeni a vezérlést, ezért lehetőségünk van arra, hogy két lefutás között helyezzük át a programot. 
+
+Az áthelyezés így jelentősen leegyszerűsödik, hiszen csak arra van szükség, hogy a vezérlő komponenseket a megfelelő adatközpontban indítsuk el.
+
+A vezérlést megvalósító szolgáltatás komponensek indításáért ebben az alkalmazásban külön szolgáltatás felel, ezért ez az a szoftverkomponens, amelynek támogatnia kell a dinamikus ütemezési döntések alkalmazását. 
+
+
+\section{Ütemező rendszer}
+
+
+\subsection{Algoritmus}
+
+Egy ilyen algoritmusnak fel kell tudnia mérni, hogy melyik a legideálisabb környezet futtatni a szolgáltatást. Sajnos az, hogy mi számít ideális környezetnek, az erősen alkalmazás függő. Vannak alkalmazások, amelyeknél a késleltetés minimalizálása a kliensek felé a cél, de olyan is van, ahol pont a hálózati forgalom aggregálása a cél. Ezért a megfelelő algoritmus megalkotásához szükség van támogatásra a konkrét alkalmazástól.
+
+%Egy ilyen algoritmusnak fel kell tudnia mérni azokat 
+
+\subsection{Megvalósítás}
 
 
 \begin{figure}[h!]
@@ -29,4 +108,5 @@
 	\includegraphics[width=0.5\textwidth]{figures/turbomemer-legit}
 	\caption{asd}
 	\label{fig:turbomemer}
-\end{figure}
+\end{figure}
+