% !TeX root = ../thesis.tex
%----------------------------------------------------------------------------
\chapter{Alkalmazások tesztelése}
%----------------------------------------------------------------------------

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}.\ alfejezetben 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}.\ alfejezetben 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{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}
\label{sec:birbnetes-evaluation}

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}.\ alfejezetben 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}.\ alfejezetben 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{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.