Merge branch 'master' into markosz-4

src/bib/mybib.bib

@@ -463,3 +463,17 @@
 	%note      = "",
 }
 
+@misc{timeseries_basics,
+	author = {Eric Clower},
+	year = {2019},
+	title = {Introduction to the Fundamentals of Time Series Data and Analysis},
+	howpublished = {\url{https://www.aptech.com/blog/introduction-to-the-fundamentals-of-time-series-data-and-analysis/}},
+	note = {Megtekintve: 2021-12-18}
+}
+
+
+@misc{intel_ark,
+	title = {{Intel ARK - Intel\textregistered \ Xeon\texttrademark \ Processor X5675 Specifications}},
+	howpublished = {\url{https://ark.intel.com/content/www/us/en/ark/products/52577/intel-xeon-processor-x5675-12m-cache-3-06-ghz-6-40-gts-intel-qpi.html}},
+	note = {Megtekintve: 2021-12-18}
+}

src/content/acknowledgement.tex

@@ -10,3 +10,4 @@ Emellett szeretném megköszönni családomnak és barátaimnak a végtelen tám
 
 
 % lackó, Josh, kszk
+% kszk

src/content/birbnetes_impl.tex

@@ -14,6 +14,7 @@ Ez az alkalmazás a peremhálózati rendszerek adat aggregációs lehetőségeit
 
 
 \section{Felépítés}
+\label{sec:birbnetes_short_desc}
 
 A rendszer felépítése két rétegű. Az egyik réteg a felhőben futó szoftver a másik magukon az \acrshort{iot} eszközökön fut. A két rendszer magas szintű működésének funkcionális vázlatát \aref{fig:nagyon_simple_birbnetes}.\ ábra szemlélteti. 
 

src/content/glossary.tex

@@ -156,3 +156,4 @@
 \newacronym{oci}{OCI}{Open Container Initiative}
 \newacronym{raid}{RAID}{Redundant Array of Independent Disks}
 \newacronym{ssd}{SSD}{Solid State Drive}
+\newacronym{icmp}{ICMP}{Internet Control Message Protocol}

src/content/measurements.tex

@@ -3,20 +3,94 @@
 \chapter{Alkalmazások tesztelése}
 %----------------------------------------------------------------------------
 
-% Ez érdekes lesz
+A peremhálózati adatközpontok lehetőségeinek dinamikus kihasználásra felkészített alkalmazásokat \aref{ch:test_system}.\ fejezetben ismertetett és felépített teszt környezetben egymástól függetlenül teszteltem. A környezet és a benne futó alkalmazások jól megfigyelhetőek voltak, így sikerült mindkét alkalmazás esetében egyértelmű következtetéseket levonnom. Az egyes alkalmazások mérésének körülményeit, kivitelezését és a mért értékeket a következőkben ismertetem.
 
 
+% mit, miért, hogyan, mivel, eredmények, konklúzió
+\section{Madárhang elemző alkalmazás terhelésének dinamikus ütemezése}
+
+
+\subsection{Környezet}
+
+Az alkalmazás teszteléséhez feltelepítettem az alkalmazást a felhő adatközpontot szimbolizáló klaszterbe. Ugyanebbe a klaszterbe telepítettem \aref{sec:scheduler}.\ szekcióban ismertetett ütemező szoftvert is.
+
+Az alkalmazás működésének teszteléséhez egy olyan forgatókönyvet állítottam össze, amelyben az ütemező számára mind a három adatközpont potenciális jelölt lehet az előszűrő szolgáltatás beütemezésére. Ehhez az alábbi prioritási sorrendet állítottam fel:
+\begin{enumerate}
+	\item \texttt{edge-1}
+	\item \texttt{edge-2}
+	\item \texttt{cloud}
+\end{enumerate}
+
+A mérés elvégezéséhez szükségem volt arra, hogy a klienseket emuláló virtuális gép képes legyen több \acrshort{iot} eszköz emulálására. \Aref{sec:birbnetes_short_desc}.\ szekcióban ismertetett kétrétegű szoftver architektúra miatt ez könnyen kivitelezhető volt. Egy új platform illesztő szoftver komponenst implementáltam, amely az \acrshort{iot} eszközön lévő hardverelemeket emulálja. A mikrofon emulációja egy fixen felvett hangfájl tartalmát szolgálja ki a logikai résznek, a többi hardver elem működése pedig csak naplózásra kerül.
+
+Miután ez megvolt egy egyszerű szkriptet készítettem, amely konfigurálható számú \acrshort{iot} hardver emulációját indítja el és felel az életciklusuk kezeléséért. Ennek segítségével a mérések során tetszőleges számú eszközt tudtam emulálni.
+
+\subsection{Mérés}
+
+A mérések során az alkalmazás helyesen működött. Indulásuk után az emulált eszközök lekérdezték a feltöltés célját, majd megkezdték a hangminták feltöltését. Átütemezési eseményekre sikeresen átkonfigurálták a küldés helyét, ezzel az új adatközpontot terhelve. Szolgáltatás kiesés a teljes mérés alatt nem volt tapasztalható, egy hangminta sem veszett el.
+
+Több mérést is futtattam más-más paraméterekkel. \Aref{fig:enhanced}.\ ábra összefoglalja az egyes adatközpontokon futó szolgáltatások által fenntartatott sorok hosszát az idő függvényében 5 darab eszköz emulálása során. Emellett ezen az ábrán jelölve vannak az ütemező algoritmus által hozott ütemezési döntések.
+
 \begin{figure}[h!]
 	\centering
 	\includegraphics[width=0.8\textwidth]{figures/enhanced}
-	\caption{asd}
+	\caption{Szolgáltatás terheltsége adatközpontonként és átütemezési események. (5 eszköz) \\ \textbf{zöld}: Mérés kezdete \\ \textbf{kék}: Ütemezés \texttt{edge-1}-ből \texttt{edge-2}-be \\ \textbf{narancssárga}: Ütemezés \texttt{edge-2}-ből \texttt{cloud}-ba. }
 	\label{fig:enhanced}
 \end{figure}
 
+Jól látszik a grafikonokon, hogy kezdetben az összes eszköz a prioritásban első helyen álló adatközpontra ütemeződött. Ez túl nagy terhelés volt a szolgáltatás számára, ezért percekkel később az ütemező algoritmus átütemezett egy eszközt. Mivel az átütemezés pillanatában ebben az adatközpontban még nem futott szolgáltatás, így előbb elindította azt (ez az oka annak, hogy korábbról nem látszik mérési eredmény). 
+
+Egy eszköz átütemezése nem orvosolta még a problémát, ezért átütemezett még további kettőt. Ekkor már három eszköz volt az \texttt{edge-2} adatközpontra ütemezve. A harmadik eszköz átütemezése után az \texttt{edge-2} adatközpont is instabillá vált, ezért az algoritmus átütemezett egy eszközt a felhőbe. Ezek után stabilizálódott a rendszer állapota. További ütemezések nem történtek.
+
+
+\subsection{Értékelés}
+
+A tesztek eredménye jól demonstrálja, az ütemező algoritmus és az átalakított alkalmazások helyes működését. 
+
+Elsőre kevésnek tűnhet a másodpercenkénti két minta feldolgozása a peremhálózati rendszeren. Ennek több oka is volt. A feldolgozás sebessége erősen függ az alkalmazást futtató számítógép számítási teljesítményétől. A teszt során a környezet Intel\textregistered \ Xeon\texttrademark \ X5675 processzor alapú szervergép futtatta. Ez a processzor 2011-ben jött ki \cite{intel_ark}. Azóta léteznek sokkal jobb számítási kapacitással rendelkező processzorok és szervergépek.
+
+A másik fő indok az alacsony feldolgozási kapacitás mellett a horizontális skálázás teljes hiánya. Az ütemező nem képes az elindított szolgáltatások skálázására. Így minden adatközpontban csak egy példányban futott az alkalmazás. Emiatt egyszerre csak egy minta kiértékelése történik, a többi minta addig vár a sorban. Horizontális skálázással a rendszer képes lenne kihasználni az adatközpontban elérhető teljes számítási kapacitást ami jóval nagyobb áteresztő képességet biztosítana.
+
+Emellett feltűnő volt, hogy a rendszer nagyon lassan reagál a terhelésre és sokáig \enquote{tart neki} átütemezni a terhelést. Ez javítható lehet a paraméterek további optimalizálásával, hiszen jelentősen nagyobb terhelés esetén szükséges lehet a gyorsabb átütemezés.
+
+\section{Robotkar vezérlés dinamikus ütemezése}
+
+\subsection{Környezet}
+
+Az alkalmazás teszteléséhez feltelepítettem az alkalmazást a felhő adatközpontot szimbolizáló klaszterbe. Ugyanebbe a klaszterbe telepítettem \aref{sec:scheduler}.\ szekcióban ismertetett ütemező szoftvert metrika gyűjtő komponenseit is, mivel itt nem volt szükség az ott ismertetett ütemező futtatására.
+
+A robotkarok szimulálására \aref{sec:ursim_simulator}.\ szekcióban ismertetett \textit{DockURSim} szoftvert futtattam két példányban. Mivel a vezérlő szolgáltatások \acrshort{ip} cím alapján kapcsolódnak az egyes robotkarokhoz, így a klienseket emuláló virtuális gépnek felvettem két \acrshort{ip} címet, az egyik szimulátor portjait az egyik címhez a másikat a másikhoz rendeltem. Így képes voltam két robotkar szimulálására. 
+
+A méréshez növeltem a kliens és az egyes adatközpontok közötti linkek késleltetését úgy, hogy a következő értékeket érjék el:
+\begin{itemize}
+	\item \texttt{cloud}: 40ms
+	\item \texttt{edge-1}: 10ms
+	\item \texttt{edge-2}: 20ms
+\end{itemize}
+
+\subsection{Mérés}
+
+A mérés során a kliensek és az adatközpontok közötti késleltetést megfelelően mérte a rendszer. A késleltetési mérések kimenetét \aref{fig:latency}.\ ábra mutatja be. Tisztán látszik, hogy a legalacsonyabb késleltetés az \texttt{edge-1} nevű adatközpontban érhető el.
 
 \begin{figure}[h!]
 	\centering
 	\includegraphics[width=1\textwidth]{figures/latency_feliratos_jo}
-	\caption{asd}
+	\caption{Detektált késleltetés az egyes adatközpontok és a kliens között az idő függvényében}
 	\label{fig:latency}
 \end{figure}
+
+Ezek után kezdeményeztem egy új \textit{program} futtatását a felhőben futó szolgáltatástól. A rendszer helyesen az \texttt{edge-1} adatközpontra ütemezte be a \textit{program} futtatását. Onnan sikeresen csatlakozott az emulált robotkarokhoz és hajtotta végre a \textit{program} futását.
+
+Lefutás után megváltoztattam a késleltetési értékeket úgy, hogy az eddig kedvező \texttt{edge-1} késleltetése nagyobb legyen, mint az \texttt{edge-2} adatközponté, ehhez utóbbi késleltetését csökkentettem. 
+
+Ezek után a következő futásnál az ütemező sikeresen kiválasztotta ismét a megfelelő adatközpontot az alkalmazás futtatására. 
+
+\subsection{Értékelés}
+
+Az ütemezés sikeresen választotta ki a legalacsonyabb késleltetéssel rendelkező adatközpontot. Így akár egy dinamikusan változó környezetben is képes mindig a legalacsonyabb késleltetéssel futtatni \textit{programok} sorozatát.
+
+\section{Ütemező rendszer értékelése}
+
+Az elkészített ütemező rendszer mindkét alkalmazás esetében sikeresen teljesítette a felé támasztott elvárásokat. 
+
+Ennek köszönhetően ezeknél az alkalmazásoknál képes a komponenseket emberi beavatkozás nélkül hatékonyan ütemezni.

src/content/scheduling.tex

@@ -29,7 +29,7 @@ Az \textit{EdgeX Foundry} és \textit{Porject EVE} használatát korán elvetett
 
 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.
+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 és azt, hogy saját ütemezőt készítek.
 
 \section{Szolgáltatás létesítés és mozgatás \textit{KubeFed} környezetben}
 
@@ -104,28 +104,122 @@ Az áthelyezés így jelentősen leegyszerűsödik, hiszen csak arra van szüks
 
 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}
+\label{sec:scheduler}
 
-Bár a két alkalmazás működése és igényei jelentősen eltérnek, szerettem volna egy olyan rendszert megalkotni, amelynek segítségével mindkét alkalmazás ütemezése megoldható.
+Bár a két alkalmazás működése és igényei jelentősen eltérnek, szerettem volna egy olyan rendszert megalkotni, amelynek segítségével mindkét alkalmazás ütemezése megoldható. A szoftver tervezése során figyelembe vettem azokat a közös funkcionalitásokat, amelyeket mindkét alkalmazás egyformán használ. Emellett szétválasztottam azokat a komponenseket, amelyek alkalmazás specifikus funkciót valósítanak meg.
 
-\subsection{Metrikák gyűjtése és felhasználása}
+\subsection{Metrikák gyűjtése és kiértékelése}
 
-% bele van tolva influx db-be
-% Az infulxdbj nagyon jó mert tud egy csomó midnent például deriválni
+Mindkét alkalmazásban közös, hogy az ütemezési döntéseket az alakhamzásból gyűjtött metrikákra. Ezek a metrikák bár eltérő tulajdonságokat írnak le, gyűjtésük és kiértékelésük szempontjából nem különböznek egymástól.
 
-\subsection{Algoritmus}
+A gyűjtött metrikák minden esetben idősoros adatként kezelhetőek. Az idősoros adatok olyan mérések, amelyek meghatározott időközönként rögzítésre kerülnek. Egy rögzített adatpont mindig időhöz kötötten reprezentálja a megfigyelt pillanatnyi állapotot \cite{timeseries_basics}. Az alkalmazásaink állapotát idősoros adatként gyűjtve képesek vagyunk a döntési logika felépítésénél többfajta statisztikai kiértékelést is a döntések alapjául venni.
 
+A metrikák gyűjtésére és kiértékelésére így egy központi megoldást terveztem. Gyűjtés során az egyes alkalmazás komponensek vagy mérő szoftverek elküldik a központi rendszerbe, amely idősorosan tárolja az adatokat. Ha egy ütemezési döntést végző szolgáltatásnak szüksége van arra, hogy a rögzített adatokon készített kiértékelést használja (például átlagolt értéket egy meghatározott idősávra), akkor innen le tudja kérni.
 
-%Egy ilyen algoritmusnak fel kell tudnia mérni azokat 
+Ezt a szolgáltatás mindkét alkalmazás egyformán tudja használni.
 
-\subsection{Megvalósítás}
+\subsection{Ütemezési algoritmus}
+\label{sec:scheduling-algo}
 
+Bár a robotkarokat vezérlő alkalmazásnál az ütemezést megvalósító algoritmus meghatározott fix időpontokban egy egyszerű minimum keresés a madárhang felismerő rendszer esetén ennél összetettebb megoldásra van szükség. 
+
+Ebben az esetben nem csak a konténerek ütemezésére van szükség az egyes adatközpontok között, hanem arra is, hogy az \acrshort{iot} eszközök konfigurációját is frissítsük. Emellett az ütemezési események generálása sem előre meghatározott. Az algoritmusnak folyamatosan figyelnie kell a rendszer állapotát és szükség esetén be kell tudnia avatkozni.
+
+Egy ilyen viselkedést megvalósító naiv algoritmust terveztem, amely a próbálgatás módszerével keres egy megfelelő eloszlást a szolgáltatásoknak a peremhálózati adatközpontok és a felhő között és az ezekhez kapcsolódó \acrshort{iot} eszközök között.
+
+Ahhoz, hogy a folyamatos felügyelet megvalósuljon, egy periodikusan futó algoritmust terveztem, amely rögzített időközönként felméri a rendszer állapotát és szükség esetén képes szolgáltatásokat mozgatni és konfigurációt frissíteni az eszközökön. 
+
+Az algoritmus periodikus futása során fel kell tudnia mérni, ha kedvezőtlen rendszer állapot áll fenn és döntést kell hoznia annak megoldása érdekében. A madárhang elemző rendszer esetében ilyen kedvezőtlen állapot ha a komponensek belső sorhossza monoton növekedésnek indul. Ilyen helyzetben a rendszer működése instabil. Stabilnak azt az állapotot tekinthetjük ha a sorhossz csökken, vagy konstans értékhez közelít.
+
+A sorhossz növekedésének detektálásához kihasználtam az idősoros adatokon végezhető kiértékelési lehetőségeket. Az algoritmus periodikus futása során az elmúlt időszak (konfigurálható időre visszamenően) deriváltját kérdezi le. Ebből adódóan, ha a derivált értéke nagyobb mint 0 akkor feltételezhető az instabil állapot, 0 és annál kisebb értékek esetén a rendszer stabilnak mondható.
+
+Ha az algoritmus többszöri futás esetén is nullánál nagyobb értéket kap a sorhossz deriváltjára, akkor megkezdi a javító folyamatot. Ez a folyamat egy eszköz által küldött adatokat irányítja át másik felhőbe. Mielőtt frissíti az eszköz konfigurációját ellenőrzi hogy az új cél-adatközpontban fut-e a szolgáltatás egy példánya. Ha nem akkor előbb elindítja azt és miután az készen áll az adatok fogadására csak akkor ütemezi át a a küldést.
+
+Ez a viselkedés hasonlít a korában ismertetett átterheléses mozgatásra. Azaz ha mozgatni kell, akkor csak azután teszi meg, hogy az \enquote{új} szolgáltatás készen áll, ez idő alatt a \enquote{régi} szolgáltatás dolgozza fel a kéréseket, így kiesés nélkül vihető véghez a szolgáltatások mozgatása.
+
+Annak eldöntése, hogy melyik adatközpontba kezdje el átütemezni a terhelést az algoritmus jelenlegi megoldásomban egy fix rangsort használ. Ahol egy előre rögzített listán minden egyes lehetőséget megvizsgál stabilitás szerint és ez alapján választja ki az ideális jelöltet. 
+
+Ilyen szintű naiv megoldás szuboptimális eredményt hozhat. Hiszen könnyen belátható, hogy hajlamos a vibrációra, azaz amikor egy terhelést folyamatosan oda-vissza ütemez két adatközpont között. Ez akkor fordulhat elő ha egy adatközpont működése stabil, de egy egységnyi terhelés (esetünkben egy \acrshort{iot} eszköz által küldött hangminták) már instabillá teszik.
+
+Ennek a jelenségnek az elkerülésére az algoritmus megjelöli, ha egy adatközpontban instabil működés miatt el kellett mozgatnia onnan terhelést. Ez a jelölés egy idő után lejár, ideális esetben azután, hogy a rendszer ismét elérte a stabil állapotot. Mivel a stabil állapot nem vezet átütemezéshez, ezért itt már nincs jelentősége a jelölésnek.
+
+Átütemezés után az újonnan indított szolgáltatás is automatikusan elkezdi küldeni a belső állapot információit, az ütemező algoritmus pedig automatikusan elkezdi figyelemmel kísérni a változásokat. Ezek után kezdődik elölről az algoritmus futása.
+
+\subsection{Kommunikációs interfész}
+
+Úgy terveztem, hogy az ütemező rendszerrel kívülről \acrshort{http} \acrshort{api} segítségével lehessen kommunikálni. A rendszer megvalósít interfészeket a metrikák beküldésére és kiértékelésére. Emellett az \acrshort{iot} eszközök esetében egy táblázatot tart fenn arról, hogy melyik eszközt melyik adatközponthoz rendeli. 
+
+Azt, hogy ennek a táblázatnak a tartalmát hogyan szinkronizáljam az eszközök beállításaival, két megoldást vizsgáltam meg. Ez a két megoldás a \textit{push} (amikor az algoritmus direktben értesíti az eszközöket) és a \textit{pull} (amikor az eszközök periodikusan kérdeznek le információt). 
+
+Míg a \textit{push} alapú megoldás megoldás esetén a rendszer azonnal képes lehet értesíteni az eszközöket, sokkal komplexebb megoldást igényel, hiszen kezelni kell azokat a hiba lehetőségeket, amelyek felmerülhetnek a kommunikáció során és biztosítani, hogy ezeknek ellenáll az információ továbbítás.
+
+Ezzel szemben \textit{pull} alapú megoldás esetén az eszközök ezt az információt működésük során periodikusan lekérhetik, és ennek megfelelően állíthatják át küldésük célját. Ebben az esetben a két lekérdezés között eltelt idő miatt nagyobb késleltetéssel értesülnek a változásról az eszközök, hiszen a táblában változott bejegyzésről csak a következő lekérésben tudnak értesülni. Emellett a folyamatos periodikus lekérdezés felesleges terhelést is jelent az ütemező rendszer számára, hiszen akkor is teljesítenie kell a kéréseket, ha nem változott semmi a konfigurációban. Cserében ebben az esetben nem okoz nagy problémát ha egy frissítés nem jut el az eszközhöz, vagy a frissítés pillanatában éppen nem elérhető az eszköz. A folyamatos lekérdezés miatt idővel konvergálni fog a helyes konfigurációhoz. 
+
+A konfiguráció leküldéséhez a periodikus lekérdezést választottam. Ennek oka az, hogy implementációja jelentősen könnyebb, mint az értesítési mechanizmus esetén. Emellett a konfiguráció változtatás nem időérzékeny: az átterheléses mozgatás miatt bizonyos mértékű késleltetés nem okoz problémát. 
+
+\subsection{Rendszer implementáció}
+
+Az ütemező rendszerem megvalósítását \textit{Kubernetes} környezetben futtatható mikroszolgáltatás architektúrára terveztem. A rendszer vázlatos felépítése \aref{fig:turbomemer}.\ ábrán látható. Az egyes szolgáltatások és egyéb szoftver komponensek implementációját a következő szekciókban részletezem.
 
 \begin{figure}[h!]
 	\centering
 	\includegraphics[width=0.5\textwidth]{figures/turbomemer-legit}
-	\caption{asd}
+	\caption{Ütemező rendszer szolgáltatásainak áttekintése}
 	\label{fig:turbomemer}
 \end{figure}
 
+\subsubsection{Mérés kezelő}
+\label{sec:birb-latency-collector}
+
+Ez a szolgáltatás egy kívülről is elérhető interfészt valósít meg. Feladata a rendszer állapotát leíró mért adatok gyűjtése és azokról kiértékelések szolgáltatása. Ennek megvalósítására egy idősoros adatbázist használ. Az általam választott idősoros adatbázis az \textit{InfluxDB}.
+
+Azért választottam az \textit{InfluxDB}-t, mert egy hatékonyan működő adatbázis sok hasznos funkcióval. Ilyen például a 2-es verzió óta beépített adatvizualizáció, így közvetlenül lehet a szoftvert arra használni, hogy a rögzített méréseket megtekintsük. Saját lekérdező nyelvén pedig sokféle adat aggregáció, transzformáció és kiértékelő funkcionalitás érhető el.
+
+Új mérések érkezésekor a szolgáltatás eltárolja az információkat az adatbázisban. Ha szükség van kiértékelésre, akkor az \textit{InfluxDB} saját lekérdezőnyelvére fordítja a kérést és az adatbázis szoftverben futtatja azt le, így hatékonyan és egyszerűen tudja megkapni a kiértékelt adatokat, amelyeket válaszul ad a kérésre.
+
+Ezt a szolgáltatást a robotkarok vezérlését megvalósító alkalmazás közvetlenül tudja használni az ütemezési döntés meghozatalára.
+
+\subsubsection{Ütemezés nyilvántartó}
+\label{sec:birb-scheduler-teller}
+
+Ezt a szolgáltatás kizárólag az intelligens madárhang elemző alkalmazás használja. 
+
+Ennek a szolgáltatásnak a feladata, hogy számontartsa az egyes eszközök jelenlétét illetve kiszolgálja számukra, hogy pillanatnyilag melyik adatközponthoz vannak rendelve. Az eszközök futásuk során ettől a szolgáltatástól tudják lekérni az ütemezési információikat. 
+
+Ha a szolgáltatásból egy eddig ismeretlen eszköz kéri le az ütemezését, akkor azt egy dinamikusan megválasztott \enquote{alapértelmezett} adatközponthoz rendeli. Ezután ezt az ütemezési döntést elmenti és innentől kezdve ugyanúgy van kezelve az új eszköz is, mint az összes többi.
+
+A kiszolgált adatokat egy kulcs-érték adatbázisban tárolja. Ehhez \textit{Redis} adatbázist használtam, ennek oka az, hogy a \textit{Redis} támogatja az értékekhez lejárati idő rendelését. A lejárai idő leteltével az értékeket automatikusan törli. Ennek a segítségével számos funkcionalitást könnyebb volt implementálni. A \textit{Redis} támogatja továbbá az osztott memóriaként való funkcionalitást, amelyet kihasználva \aref{sec:birb-scheduler}.\ szekcióban ismertetett szolgáltatással való kommunikációt megoldottam.
+
+\subsubsection{Dinamikus újra-ütemező}
+\label{sec:birb-scheduler}
+
+\Aref{sec:birb-scheduler-teller}.\ szekcióban ismertetett szolgáltatás csak egy statikus hozzárendelést valósít meg az új eszközök és az adatközpontok között. Viszont ezek után nem változtatja meg a döntését. Ezeknek a döntéseknek a felülvizsgálatára és az \enquote{alapértelmezett} adatközpont dinamikus megváltoztatására szolgál ez a szolgáltatás.
+
+Ez a szolgáltatás valósítja meg \aref{sec:scheduling-algo}.\ szekcióban vázolt periodikusan futó ütemező algoritmust. 
+
+Futása során a kiértékelt metrikákat lekérdezi a \textit{Mérés kezelő} szolgáltatásból. Majd ezek alapján és az osztott \textit{Redis} adatbázisban tárolt információk alapján meghozza az ütemezési döntést. Szükség esetén \textit{Kubernetes} \acrshort{api} hívásokkal elindítja a \textit{KubeFed} által kezelt szolgáltatást a megfelelő adatközpontban majd ezek után az ütemezési döntést rögzíti a az adatbázisban. így legközelebb amikor az eszköz frissíti a konfigurációját már az újonnan indított szolgáltatáshoz küldi az információkat, ezzel megvalósítva a dinamikus átütemezést.
+
+A szolgáltatás azt is ellenőrzi, hogy a kijelölt \enquote{alapértelmezett} adatközpont stabilnak számít-e. Ha nem, akkor ezt a beállítást is frissíti, így az új eszközök már másik adatközpontba kezdik el küldeni az adatokat.
+
+Értelem szerűen ezt a szolgáltatást is csak az intelligens madárhang elemző alkalmazás használja.
+
+\subsection{Link késleltetés mérése}
+
+A robotkarokat vezérlő alkalmazás számára szükség van arra az információra, hogy az egyes adatközpontokkal milyen minőségű a link összeköttetése. 
+
+Ennek a megvalósítására egy egyszerű szkriptet készítettem, amely leméri az összes adatközponttal szembeni késleltetést, majd ezeket elküldi \aref{sec:birb-latency-collector}.\ szekcióban ismertetett szolgáltatás számára, amely így képes arról kiértékelést készíteni.
+
+A késleltetés mérésére kézenfekvő megoldás lehet a hagyományos \acrfull{icmp} által biztosított \textit{Ping} kérésekkel mérni a körülfordulási időt. De ez csak egy nagyon limitált eredményt ad egy konkrét végponthoz. 
+
+Szerettem volna egy olyan megoldást készíteni, amely nem csak az adatközpont határán lévő, publikus címmel rendelkező végponthoz tudja mérni a késleltetést, hanem közvetlenül az ott futó szolgáltatások és a végpont közti kapcsolatot tudja mérni. Ennek hála a késleltetés nem csak a publikus hálózat állapotát, de az egyes adatközpontok belső hálózatáról is képet tud adni. Ezzel átfogóbb és pontosabb információt kapunk arról, hogy melyik adatközpontot érdemes használnunk.
+
+Ezt úgy oldottam meg, hogy felkonfiguráltam egy egyszerű webszerver konténert, amely minden kérésre egyből egy üres válasszal válaszol. Ezt a konténert \textit{KubeFed} segítségével úgy futtattam, mint bármelyik másik szolgáltatást minden adatközpontban. Ezt a szolgáltatást kiajánlottam minden adatközpont publikus címére. A szkriptem pedig a \acrshort{http} kérés körülfordulási idejét méri.
+
+Az így mért értékeket az ütemező fel tudja használni arra, hogy eldöntse, hogy melyik adatközpontra ütemezze be a robotkarok vezérléséhez szükséges szolgáltatást.
+
+\subsection{Robotkarok vezérlésének átalakítása}
+
+A robotkarok vezérlését megvalósító komponens a \textit{Kubernetes} \acrshort{api} interfészét használva indítja el \textit{KubeFed} segítségével az egyes \textit{programok} végrehajtását végző szolgáltatásokat. Ahhoz, hogy ezeket a szolgáltatásokat dinamikusan a legideálisabb környezetben indítsa el, arra van szükség, hogy szolgáltatás indítása előtt lekérje a \textit{Mérés kezelő} szolgáltatásból az egyes adatközpontok felé a cél telephely késleltetését, ezután pedig kiválassza azt, ahol legkisebb a késleltetés. 
+
+A viselkedés implementálása egy \acrshort{http} \acrshort{api} hívást igényelt csak, közvetlenül az ütemezés kezdete előtt. Ezzel lekérte a szolgáltatásból a linkek késleltetésének középértékét az elmúlt két percre vetítve. Ezután egy minimum függvénnyel meghatározható volt, hogy melyik adatközpontban kerüljön ütemezésre a szolgáltatás.

src/content/test_system.tex

@@ -1,6 +1,7 @@
 % !TeX root = ../thesis.tex
 %----------------------------------------------------------------------------
 \chapter{Teszt környezet kialakítása}
+\label{ch:test_system}
 %----------------------------------------------------------------------------
 
 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.
@@ -161,7 +162,7 @@ Elmondható ezek alapján, hogy a tesztkörnyezet futtatásához legalább 36.5
 
 A kliensek száma és erőforrás igénye teljesen a használt alkalmazástól függ. Itt ezért kezdetben 2 Gigabyte memóriát allokáltam, majd később kibővítettem, amikor szükség volt rá.
 
-Processzor tekintetében nem fedeztem fel különösen nagy elvárásokat. Tapasztalataim szerint a rendszer stabilan működött egy 2011-ben gyártott négymagos \textit{Intel}\textregistered \textit{Core}\texttrademark i7-3770 processzoron. 
+Processzor tekintetében nem fedeztem fel különösen nagy elvárásokat. Tapasztalataim szerint a rendszer stabilan működött egy 2011-ben gyártott négymagos \textit{Intel}\textregistered \ \textit{Core}\texttrademark \ i7-3770 processzoron. 
 
 A lemez elérések teljesítménye viszont jelentős tényező volt a rendszer teljesítménye szempontjából. A környezet önmagában stabilan üzemelt egy \acrshort{raid}5 tömbre telepítve, amelyet 8 darab 15.000 percenkénti fordulatú hagyományos mechanikus diszk alkotott. Viszont amint feltelepítettem a tesztelésre szánt alkalmazásokat, a tárhely elérési késleltetés jelentősen megnőtt olyan mértékekig, ami az alkalmazás instabil működését és átmeneti összeomlását okozták. Ezért mindenképpen ajánlott ilyen rendszert \acrshort{ssd} lemezekből álló tárhely tömbre telepíteni.
 

src/content/ursim_impl.tex

@@ -65,6 +65,7 @@ A robotokat 125Hz-es rátával kell vezérelni (azaz 8ms-ként kell utasítást
 
 
 \subsubsection{Szimulátor}
+\label{sec:ursim_simulator}
 
 A tanszéken található kettő robotkar természetesen nem áll mindig rendelkezésre. Más csapatok más-más projektekben is használják. A fejlesztés és a tesztelés megkönnyítésére több szimulátor is megvizsgálásra került a projekten korábban dolgozó csapat által. Végül a leghatékonyabban használhatónak a \textit{DockURSim}\footnote{\url{https://github.com/ahobsonsayers/DockURSim}} bizonyult. 
 

src/thesis.tex

@@ -62,7 +62,7 @@
 % Declaration and Abstract
 %~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 \include{include/declaration}
-%\include{content/abstract}
+\include{content/abstract}
 
 
 % The main part of the thesis
@@ -103,7 +103,7 @@
 
 % Appendix
 %~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-%\include{content/appendices}
+\include{content/appendices}
 
 %\label{page:last}
 \end{document}