diff --git a/src/bib/mybib.bib b/src/bib/mybib.bib index a24d34a..0459740 100644 --- a/src/bib/mybib.bib +++ b/src/bib/mybib.bib @@ -429,5 +429,37 @@ title = {Lossless Audio Formats vs Lossy Audio Formats - A Complete Guide}, howpublished = {\url{https://www.musicgateway.com/blog/how-to/lossy-or-lossless-audio-formats}}, note = {Megtekintve: 2021-12-16} +} + + +@misc{libvirt_xml, + author = {}, + title = {libvirt: XML format}, + howpublished = {\url{https://libvirt.org/format.html}}, + note = {Megtekintve: 2021-12-17} +} + + +@misc{ansible_docs, + title = {Ansible Documentation}, + howpublished = {\url{https://docs.ansible.com/}}, + note = {Megtekintve: 2021-12-17} +} + +@misc{installing_kubefed, + title = {KubeFed documentation - Installing KubeFed}, + howpublished = {\url{https://github.com/kubernetes-sigs/kubefed/blob/master/docs/installation.md}}, + note = {Megtekintve: 2021-12-17} +} + +@manual{man_tc, + title = "TC(8) System Administration tools and Daemons", + %author = "", + %organization = "", + %address = "", + edition = "5.15.0", + year = "2001", + month = "December", + %note = "", +} -} \ No newline at end of file diff --git a/src/content/birbnetes_impl.tex b/src/content/birbnetes_impl.tex index ad75d69..ef15aac 100644 --- a/src/content/birbnetes_impl.tex +++ b/src/content/birbnetes_impl.tex @@ -62,7 +62,7 @@ Az előszűrés által adott sávszélesség megtakarítást nehéz megbecsülni Eredeti Tanító minta részlet & 190 & 152 & 80.0\% \\ Erdei hangfelvétel madárcsiripeléssel & 1000 & 288 & 28.8\% \\ Erdő, kevés madárcsiripeléssel & 316 & 53 & 16.7\% \\ - Erdőszél, este & 1500 & ? & ?\% \\ + Erdőszél, este & 1500 & ? & ?\% \\ %TODO: Ezt ne felejtsem el kitölteni \hline \end{tabular} \caption{Első fázisú \acrshort{mi} áteresztésének vizsgálata különböző hangmintákra} @@ -77,7 +77,7 @@ Ennek a problémának a megoldására nyújt lehetőséget a peremhálózati ren A tervezés során fontosnak tartottam, hogy a rendszer többi komponensében minimális változtatásokat kelljen tenni. Az eredeti rendszer mikroszolgáltatás architektúrára épült, így az egyes komponensek felelőssége jól elkülönül. A megtervezett architektúrába könnyen beilleszthető extra funkcionalitás. -Mivel \textit{Kubefed} keretrendszert választottam az alkalmazásom futtatására, ezért egyértelmű volt, hogy a már meglévő alkalmazás komponenseken nem kell módosítani. Hiszen a \textit{Kubefed} csak kiegészíti a \textit{Kubernetes} funkcionalitását, amely az eredeti rendszer tervezésénél is meghatározó volt. Az első szintű \acrshort{ml} algoritmust ezekből az okokból egy újabb mikroszolgáltatásként terveztem meg. +Mivel \textit{KubeFed} keretrendszert választottam az alkalmazásom futtatására, ezért egyértelmű volt, hogy a már meglévő alkalmazás komponenseken nem kell módosítani. Hiszen a \textit{KubeFed} csak kiegészíti a \textit{Kubernetes} funkcionalitását, amely az eredeti rendszer tervezésénél is meghatározó volt. Az első szintű \acrshort{ml} algoritmust ezekből az okokból egy újabb mikroszolgáltatásként terveztem meg. Az \acrshort{iot} eszközön futó szoftver \acrshort{http} interfészen keresztül tölti fel a mintákat. Az új mikroszolgáltatást proxyként terveztem meg. Azaz egy ugyanolyan \acrshort{http} interfészt szolgál ki, mint a felhőben a hangfájlok fogadására szolgáló végpont. Ha az \acrshort{ml} algoritmus madárcsiripelést azonosít a mintában, akkor azt módosítás nélkül továbbküldi. Így az eszközök és a felhő számára is teljesen transzparens módon tud működni az új szolgáltatás. A megváltozott architektúráról \aref{fig:birbnetes_super_simple_services}.\ ábra ad vázlatos áttekintést. Ez a szolgáltatás egyformán futhat a felhőben, de a peremen is, nincsenek lokalitási kötöttségei. diff --git a/src/content/glossary.tex b/src/content/glossary.tex index 08e68d6..3b9b1be 100644 --- a/src/content/glossary.tex +++ b/src/content/glossary.tex @@ -68,7 +68,6 @@ description={OpenXML standard kompatibilis XML fájlok halmaza \textit{ZIP} csomagban. A \textit{Microsoft} fejlesztette 2007-ben. Többek között a \textit{Microsoft Excel 2007} és újabb táblázatkezelők használják} } - \newacronym{mdt}{MDT}{Model-Driven Telemetry} \newacronym{ai}{AI}{Artificial Intelligence} \newacronym{ml}{ML}{Machine Learning} @@ -154,4 +153,6 @@ \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} \ No newline at end of file +\newacronym{oci}{OCI}{Open Container Initiative} +\newacronym{raid}{RAID}{Redundant Array of Independent Disks} +\newacronym{ssd}{SSD}{Solid State Drive} \ No newline at end of file diff --git a/src/content/overview.tex b/src/content/overview.tex index 3c7e66a..6743e94 100644 --- a/src/content/overview.tex +++ b/src/content/overview.tex @@ -242,7 +242,7 @@ 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}. +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) klasztert. 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}. @@ -250,7 +250,7 @@ Implementáció szempontjából a federáció vezérlőre telepít és futtat ol 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 földrajzilag 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 megfelel. +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 megfelel. 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ű a \textit{Kubernetes} klaszterek terén jártas üzemeltetők számára. diff --git a/src/content/test_system.tex b/src/content/test_system.tex index 785c9ef..7f51e2a 100644 --- a/src/content/test_system.tex +++ b/src/content/test_system.tex @@ -45,11 +45,11 @@ A teszt infrastruktúrát két szempontból bontottam fel. Az egyik az előbb em \subsubsection{Futtató környezet} -A környezetben szükség van a választott alkalmazás futtató keretrendszer (esetünkben \textit{Kubedfed}) futtatására. A \textit{Kubefed} lényegében több \textit{Kubernetes} klaszter fölé húzott közös vezérlési réteg. Ennek megfelelően virtuális gépek kijelölt csoportjaira önálló csoportjainak egy-egy \textit{Kubernetes} klaszter futtatását jelöltem ki. +A környezetben szükség van a választott alkalmazás futtató keretrendszer (esetünkben \textit{Kubedfed}) futtatására. A \textit{KubeFed} lényegében több \textit{Kubernetes} klaszter fölé húzott közös vezérlési réteg. Ennek megfelelően virtuális gépek kijelölt csoportjaira önálló csoportjainak egy-egy \textit{Kubernetes} klaszter futtatását jelöltem ki. Az egyes \textit{Kubernetes} klaszterek esetünkben az egyes adatközpontokat szimbolizálják. Egy ilyen klaszter jelöli a felhő adatközpontot, a többi klaszter pedig jelölheti a peremhálózati adatközpontokat vagy akár további felhőket is. A méréseink szempontjából nincs számottevő különbség egy felhő vagy egy peremhálózati adatközpontban működésüket tekintve, ezért itt főképp csak az elnevezésükben térnek el. -Az önálló \textit{Kubernetes} klaszterek fölé már lehet \textit{Kubefed} környezetet telepíteni. A telepített \textit{Kubefed} szoftver megfelelően modellezi a valós környezetben használt futtató környezetet, hiszen ugyanaz a szoftver. Telepítése és üzemeltetése között nincs különbség a valós és teszt környezetben. +Az önálló \textit{Kubernetes} klaszterek fölé már lehet \textit{KubeFed} környezetet telepíteni. A telepített \textit{KubeFed} szoftver megfelelően modellezi a valós környezetben használt futtató környezetet, hiszen ugyanaz a szoftver. Telepítése és üzemeltetése között nincs különbség a valós és teszt környezetben. \subsubsection{Kliens} @@ -91,28 +91,97 @@ A munka során a terveim alapján konkrétan megvalósított környezetem három \label{fig:birb_edgemu_architecture} \end{figure} -A \textit{Kubefed} federáció tagjai a \texttt{cloud}, \texttt{edge-1} és \texttt{edge-2} nevű klaszterek. Ezek közül a \texttt{cloud} nevű klaszter a federációt vezérlő klaszter. +A \textit{KubeFed} federáció tagjai a \texttt{cloud}, \texttt{edge-1} és \texttt{edge-2} nevű klaszterek. Ezek közül a \texttt{cloud} nevű klaszter a federációt vezérlő klaszter. + +A klasztereknek és klienseknek természetesen nem csak egymással kell tudniuk kommunikálni. Előfordulhat, hogy szükségük van arra, hogy elérjék a publikus internetet is (például szoftverfrissítés letöltésére). Az ilyen típusú forgalom nem kívánatos a virtuális útválasztón. Mivel a környezetben csak a klaszterek és a kliensek közötti forgalom paramétereit szeretnénk befolyásolni, ezért felesleges a nem arra irányuló forgalom átvezetése. Emellett az extra forgalom bizonyos szélsőséges helyzetekben befolyásolhatja a mérési eredményeket is. Ennek megoldására minden alhálózatban két átjáró van, az egyik a virtuális útválasztó a másik a virtuális környezet által biztosított átjáró amelyen keresztül el lehet érni a publikus internetet. \subsection{Virtuális gépek és hálózat} -% cloudinit + +A környezetet alkotó virtuális gépek futtatása nem függ egy konkrét virtualizációs platform implementációtól. Az egyetlen elvárás azzal szemben, hogy képes legyen virtuális gépeket és virtuális hálózatokat létrehozni és futtatni. + +A virtuális gépek futtatásához \textit{libvirt}\footnote{\url{https://libvirt.org/}} környezetet használtam. + +A \textit{libvirt} számára \acrshort{xml} formátumban lehet definiálni a virtuális gépeket és virtuális hálózatokat \cite{libvirt_xml}. A felépítés ezen lépésének automatizálására írtam egy egyszerű \gls{python} szkriptet, amely ilyen \acrshort{xml} definíciókat generál. Ezek importálásával \textit{libvirt}be, a virtuális gépek és a hálózati infrastruktúra készen állt. + +Négy virtuális hálózatot hoztam létre, ezeket \texttt{cloud}, \texttt{edge-1}, \texttt{edge-2} és \texttt{client}-nek neveztem el attól függően, hogy melyik virtuális gépeket szolgálja ki. Az útválasztó kivételével minden virtuális gépnek egy interfésze van, amely az adott hálózatra van csatlakoztatva. Az útválasztónak mind a négy hálózatba van interfésze. A hoszt által biztosított átjáró minden hálózatban jelen van. Az ide irányuló forgalom hálózati címfordítás segítségével a gazdagép címére fordul, így a virtuális gépek elérik az internetet is. \subsection{Operációs rendszer konfigurációja} -% leírni mindhárom classt: kliens-emu, router, kubememe memeber + +Mivel a környezet 11 virtuális gépből áll, ezért ezeknek egyenként \enquote{kézzel} való telepítése időigényes lenne és könnyen lehetne hibát ejteni benne, amelynek megkeresése és javítása további időt igényelne. + +Ezért a virtuális gépek telepítésére és alapvető konfigurációjának elvégzésére is automatizációs eszközöket használtam. + +Az operációs rendszer telepítése helyett inkább egy előre elkészített képfájlból dolgoztam. Az általam használt képfájl \textit{Ubuntu} \gls{linux} disztribúciót tartalmaz. A képfájlon előre fel van telepítve a \textit{Cloud Init}\footnote{\url{https://cloud-init.io/}} nevű eszköz, amely rendszer indulás közben elvégzi az operációs rendszer alapvető konfigurációját. Ilyen a gép hosztneve, (egyszerűsített) hálózati konfigurációja, és az \acrfull{ssh} kapcsolaton való bejelentkezéshez szükséges publikus kulcsok telepítése. + +A \textit{Cloud Init} az egyedi konfigurációt egy második lemez képfájlról tölti be. A lemez képfájlok elkészítésére írtam egy egyszerű \gls{python} szkriptet. + +Mivel a \textit{Cloud Init} csak az alapvető rendszer konfigurációt hajtja végre, ezért a komplexebb/specifikus konfigurációk elvégzésére egy másik eszközt használtam. A \textit{Cloud Init} egy olyan működő konfiguráció állít be a virtuális gépen, amely lehetővé teszi, hogy be tudjunk arra jelentkezni \acrshort{ssh} kapcsolaton keresztül. Az \acrshort{ssh} kapcsolat tökéletesen megfelel arra, hogy \textit{Ansible}\footnote{\url{https://www.ansible.com/}} konfiguráció menedzsment eszközt használjunk. + +Az \textit{Ansible} egy deklaratív konfiguráció kezelő eszköz \cite{ansible_docs}. Az elvárt állapotot írjuk le, amelyhez az \textit{Ansible} automatikusan igazítani fogja a konfigurációs beállításokat az operációs rendszeren. Futás közben \acrshort{ssh} protokollon keresztül csatlakozik a konfigurálni kívánt hosztokra. Majd ellenőrzi, hogy minden beállítás egyezik-e az általunk elvárt állapottal. Ha valamelyik konfiguráció eltér, akkor azt automatikusan beállítja az elvárt állapotra. + + +\textit{Ansible} segítségével, letöröltem felesleges szoftver komponenseket, feltelepítettem szükségeseket és beállítottam a végleges hálózati konfigurációt. + +Annak érdekében, hogy a virtuális gépek az alhálózatok közti forgalmat a virtuális útválasztón keresztül küldjék, a többi forgalmat pedig a gazdagép átjáróján keresztül, statikus útválasztó tábla bejegyzéseket vettem fel minden gépen. Ahol minden gépen a többi alhálózathoz az átjáró a virtuális útválasztó, az alapértelmezett pedig a gazdagép átjárója. + \subsection{\textit{Kubernetes} telepítése} +A \textit{KubeFed} használatához először szükség van arra, hogy legyenek működő \textit{Kubernetes} klasztereink, amelyeket federálni tudunk \cite{installing_kubefed}. -% Nginx ingress controller -% Longhorn storage class +Egy \textit{Kubernetes} klaszter telepítésére több lehetőségünk is van. Rendelkezésünkre állnak disztribúciók, amelyek minimális konfigurációval egy teljes értékű klasztert képesek telepíteni. A telepítéshez a \textit{Kubespary}\footnote{\url{https://kubespray.io/}} disztribúciót használtam. -\subsection{\textit{Kubefed} telepítése} +A \textit{Kubespray} alapvető konfigurációjában csak keveset módosítottam. Úgy állítottam be, hogy a három virtuális gépből egyet jelöljön ki \texttt{master} szerepre kettőt pedig \texttt{worker} szerepre. A Kubernetes telepítését egyenként végeztem el mindhárom klaszterre. + +Sikeres telepítés után néhány alapvető komponenst szintén kézzel, \textit{Helm}\footnote{\url{https://helm.sh/}} segítségével telepítettem: +\begin{itemize} + \item A perzisztens tárhely kezeléshez \textit{Longhorn}\footnote{\url{https://longhorn.io/}} \textit{Storage Class}-t telepítettem. A \textit{Longhorn} nem igényli külső adat tároló szerverek használatát, a \textit{Kubernetes} klasztert alkotó gépek saját tárhelyét használja. + \item A beérkező \acrshort{http} kérések fogadására, kezelésére és megfelelő mikroszolgáltatásokhoz irányítására \textit{Nginx}\footnote{\url{https://kubernetes.github.io/ingress-nginx/}} \textit{Ingress Controller}-t telepítettem. Ennek segítségével mikroszolgáltatások halmazával megvalósított szolgáltatás egy egységes \acrshort{http} interfészen érhetőek el. +\end{itemize} + + +\subsection{\textit{KubeFed} telepítése} + +A \textit{KubeFed} telepítéséhez követtem annak dokumentációját. A telepítés csak pár lépésből állt. + +Első lépésként a \textit{Helm} segítségével telepítettem a \textit{KubeFed} vezérlését megvalósító komponenseket a \texttt{cloud} nevű klaszterbe. Ezek után a letöltöttem a \texttt{kubefedctl} nevű parancssoros alkalmazást, amely segítségével beléptettem mindhárom klasztert a federációba\footnote{A vezérlő klasztert is be kell léptetni annak érdekében, hogy a \textit{KubeFed} oda is ütemezzen alkalmazás komponenseket}. Ezek után lekérdeztem a klaszterek állapotát reprezentáló \acrshort{api} objektumot a \textit{Kubernetes} \acrshort{api} interfészén, ez megerősítette, hogy a federáció vezérlő mindhárom \textit{Kubernetes} klasztert eléri és tudja kezelni. + +Ezek után lehetőségem volt egyenként ki és be kapcsolni a \textit{KubeFed} által federált objektumok használatát, mint a federált névterek, federált konfigurációk vagy éppen federált \textit{deployment}-ek. + +\section{Erőforrás igények} + +Bár a rendszer erőforrás igénye nagyban függ a telepített alkalmazásoktól. Maga a környezet telepítése és futtatása is igényel valamennyi erőforrást. + +\textit{Kubernetes} futtatásához, minden virtuális gépnek legalább 2 Gigabyte rendszer memória szükséges és két processzor mag \cite{kubernetes_docs}. Tapasztalataim viszont azt mutatják, hogy ez néha túl kevés tud lenni és különböző teljesítménybeli problémákba tudunk ütközni, ezért a \textit{Kubernetes}-t futtató virtuális gépeknek ajánlott legalább 4 Gigabyte memória allokálása. + +Az útválasztó gépnek nincs szüksége sok memóriára a csomagok továbbítására, amíg nem használjuk másra, addig 512 Megabyte memória megfelel neki. + +Elmondható ezek alapján, hogy a tesztkörnyezet futtatásához legalább 36.5 Gigabyte memóriára van szükség, ha a klienseket nem számoljuk. + +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. + +A lemez elérések teljesítménye viszont egy 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 amik 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. \section{Környezet alkalmazása} -% tc tutorial basically +A tesztkörnyezetnek egyik fontos célja, hogy különböző hálózati paramétereket tudjon szimulálni. Ennek megvalósításáért a virtuális útválasztó felel. -%\section{Környezet értékelése} +A szükséges hálózati funkciókat implementálja a \gls{linux} kernel. Ezért a virtuális gépen is ugyanolyan \textit{Ubuntu} operációs rendszer fut, mint a többin a környezetben. A virtuális gépen bekonfigurálásra kerültek a megfelelő útválasztó táblák és engedélyezve lett rajta az útválasztó funkcionalitás. Ennyi elég ahhoz, hogy működő kapcsolatot létesítsen az egyes alhálózatok között. -% fogom a pontokat a célokból és elmondom, hogy mindet tök királyul teljesítettem. \ No newline at end of file +A hálózati kondíciók szimulálásához a kernelbe \textit{Traffic Control} képességek tökéletesen használhatóak. A \textit{Traffic Control} a következő részekből áll \cite{man_tc}: +\begin{itemize} + \item \textbf{Shaping} (formálás): Interfészről kimenő csomagok rátájának szabályozása. Nem csak sávszélesség szabályozásra alkalmas. Használható például az egyenetlen adatforgalom simítására is. + \item \textbf{Scheduling} (ütemezés): A csomagok küldésének idejét ütemezhetjük vele, alkalmas arra, hogy például késleltetést szimuláljunk. Csak kimenő csomagokra alkalmazható. + \item \textbf{Policing} (rendészet): Hasonló a formáláshoz, viszont a kimenő csomagok helyett a beérkezőkre vonatkozik. + \item \textbf{Dropping} (ejtés): Bizonyos szabályok alapján eldobhatunk csomagokat amelyek meghaladnak sávszélességi korlátokat. Ez mind a bejövő mind a kimenő forgalomra alkalmazható. +\end{itemize} + +A kernelben lévő \textit{Traffic Control} konfigurálásához a \texttt{tc} nevű felhasználói módú eszközt tudjuk használni. A használatára egy példát mutat be \aref{ex:tc}.\ kódrészlet. + +\begin{lstlisting}[float=!ht,caption={10ms késleltetés konfigurálása egy interfészre \texttt{tc} használatával},label=ex:tc] + tc qdisc add dev enp1s0f2 root netem delay 10ms +\end{lstlisting} diff --git a/src/content/ursim_impl.tex b/src/content/ursim_impl.tex index 2bbf64c..a60df88 100644 --- a/src/content/ursim_impl.tex +++ b/src/content/ursim_impl.tex @@ -113,7 +113,7 @@ A fenti monolit demó átültetése alapos tervezést igényelt egy felhő és p \subsection{Architektúra} -Mivel a \textit{Kubefed} keretrendszert választottam az alkalmazásom futtatására, így ennek megfelelően kellett megválasztanom annak felépítését. Az alkalmazást mikroszolgáltatás architektúrára terveztem. \textit{Kubefed} használatával lényegében az alkalmazásunk (egy vagy több) \textit{Kubernetes} klaszterben fut. A mikroszolgáltatás architektúra az ilyen környezetben azért jó, mert az alkalmazás komponensek egymás belső működésétől függetlenek. Így amíg az egyes komponensek egymás \acrshort{api} felületét elérik, nem számít, hogy hol és milyen környezetben futnak. Természetesen a felületek elérése is egy összetett probléma önmagában, ennek megoldásáról \aref{chapter:dynamic_scheduling}.\ fejezet értekezik. +Mivel a \textit{KubeFed} keretrendszert választottam az alkalmazásom futtatására, így ennek megfelelően kellett megválasztanom annak felépítését. Az alkalmazást mikroszolgáltatás architektúrára terveztem. \textit{KubeFed} használatával lényegében az alkalmazásunk (egy vagy több) \textit{Kubernetes} klaszterben fut. A mikroszolgáltatás architektúra az ilyen környezetben azért jó, mert az alkalmazás komponensek egymás belső működésétől függetlenek. Így amíg az egyes komponensek egymás \acrshort{api} felületét elérik, nem számít, hogy hol és milyen környezetben futnak. Természetesen a felületek elérése is egy összetett probléma önmagában, ennek megoldásáról \aref{chapter:dynamic_scheduling}.\ fejezet értekezik. Ennek érdekében a tervezés első lépéseként felbontottam funkcionális egységekre a jelenlegi demonstráció vezérlését. A felbontásnál viszont itt nem csak a funkcionális egységek elkülönítését tartottam szem előtt. Mivel egy három rétegű architektúrára tervezek, ezért figyelembe kellett vennem annak elvárásait és adottságait.