diff --git a/src/bib/mybib.bib b/src/bib/mybib.bib index 9c53819..73d213b 100644 --- a/src/bib/mybib.bib +++ b/src/bib/mybib.bib @@ -243,6 +243,12 @@ note = {Megtekintve: 2021-05-19} } +@misc{kubeedge_crds, + title = {Device Management using CRDs}, + howpublished = {\url{https://github.com/kubeedge/kubeedge/blob/release-1.8/docs/proposals/device-crd.md}}, + note = {Megtekintve: 2021-11-25} +} + @misc{edgexfoundry_docs, author = {}, title = {EdgeX Foundry DocumentationIntroduction}, diff --git a/src/content/overview.tex b/src/content/overview.tex index ea9e15d..71e1716 100644 --- a/src/content/overview.tex +++ b/src/content/overview.tex @@ -150,7 +150,7 @@ A dolgozatom részeként két konkrét alkalmazáson mutatom be a felhő és a p % itt le lehet írni, hogy igazából mit is kell egy keretrendszernek tudnia -A feladatom megvalósításához több keretrendszert is megvizsgáltam, ezeket az alábbiakban részletezem. +A feladatom megvalósításához több keretrendszert is megvizsgáltam, ezeket az alábbiakban általánosságban részletezem. A feladat specifikus elvárásokat pedig \aref{chapter:running_on_the_edge}.\ fejezetben fejtem ki. \subsection{EdgeX Foundry} @@ -171,9 +171,11 @@ A keretrendszert felépítő mikroszolgáltatások négy rétegbe sorolhatóak: Mindezek mellett két további két rendszerszolgáltatást is tartalmaz, ezek a biztonságért és a rendszerfelügyeletért felelnek. +% TODO: Savazni + \subsection{Project EVE} -A Project EVE célje egy különálló, direkt peremhálózati rendszerek megvalósítására tervezett operációs rendszer fejlesztése. \Gls{linux} alapokra épített operációs rendszerük neve az \textit{EVE-OS}. A rendszer célja a fejlesztés, orchestráció egyszerűsítése és egy nyílt platform létrehozása. Az \textit{EVE}-OS jelenleg támogat \textit{Docker} konténereket, virtuális gépeket és \textit{Kubernetes} klasztereket, viszont utóbbi támogatása kezdetleges. +A \textit{Project EVE} célja egy különálló, direkt peremhálózati rendszerek megvalósítására tervezett operációs rendszer fejlesztése. \Gls{linux} alapokra épített operációs rendszerük neve az \textit{EVE-OS}. A rendszer célja a fejlesztés, orchestráció egyszerűsítése és egy nyílt platform létrehozása. Az \textit{EVE}-OS jelenleg támogat \textit{Docker} konténereket, virtuális gépeket és \textit{Kubernetes} klasztereket, viszont utóbbi támogatása erősen kezdetleges. A projekt tervezése során kiemelt figyelmet fordítottak a a teljesítmény optimalizálásra. Lehetőség van az operációs rendszerben hogy a processzor és GPU erőforrásokat az egyes alkalmazások számára dedikáltan rendelje hozzá, valamint lehetséges távolról befolyásolni a processzor, memória, hálózat és egyéb erőforrások ütemezését. Mindezek mellett hangsúlyosak a biztonsági szempontok is mind hardveresen és szoftveresen is: A nem használt \acrshort{io} portokat ki lehet kapcsolni. A használt szoftverek távoli és automatizált frissítése is lehetséges. Az EVE-OS a rajta futó alkalmazásoknak további védelmet nyújt a policy alapú, elosztott tűzfal alkalmazásával. A fejlesztők igyekeznek az rendszert úgy konfigurálni, hogy az biztonságos alapbeállításokkal rendelkezzen. @@ -181,6 +183,7 @@ Az EVE-OS a különböző futtatókörnyezeteket backendként definiálja. A ren A különböző backendek támogatása azzal jár, hogy ezeket egységes absztrakt interfészen keresztül kell tudnia kezelnie. Ennek az lehet a hátránya, hogy az elérhető funkcionalitások között a legkisebb közös halmazt szolgálja ki a felhasználó számára. A konkrét platformok egyéni előnyeinek kiaknázásra nem sok lehetőséget ad. +% TODO Savazni \subsection{Akarino Edge Stack} @@ -188,11 +191,9 @@ A többi bemutatott megoldással szemben az \textit{Akarino Edge Stack} egy spec Ezek a specifikációk lefednek számos, a peremhálózati számítástechnika esetében releváns felhasználási területet, például a valós idejű játékokat, videófeldolgozást és elosztott gépi tanulást. A specifikációk megalkotása során cél a komplexitás minimalizálása véges számú lehetséges konfiguráció alkalmazásával. A specifikációk biztonsági szempontokból validálásra kerülnek. -% TODO befejezni +Lévén ezek csak specifikációk és tervrajzok. Az egyes kiadások nem szoftver termékek, hanem dokumentumok. Az egyes kiadásokban böngészhetünk az alkalmazási területünknek legmegfelelőbb tervrajzok közül és ezeket ingyenesen elérthetjük. -%\subsection{StarlingX} - -% TODO erről is írni valamit +% TODO Majd megemlíteni, hogy ezt is megnéztem esküTM \subsection{KubeEdge} @@ -202,9 +203,9 @@ A központi felhőben található fő komponensek a \textit{CloudHub} és az \te A peremhálózaton megtalálható a kommunikációs interfész párja \textit{Edged} néven. Emellett itt fut a \textit{KubeEdge} saját \textit{Pod} életciklus kezelője és meta adat tárolója. Emellett tartalmaz még egy \textit{EventBus} nevű komponenst is, amely a peremhálózaton belüli kommunikációért felel. -Az alkalmazás komponensek ugyanúgy képesek kommunikálni egymással, mint egy \textit{Kubernetes} környezetben a perem és a központi felhő komponensek között. Ugyanazok a monitorozó, felügyeleti és ütemezős eszközök működnek mindkét oldalán a rendszernek. Ezáltal a \textit{KubeEdge} lehetővé teszi, hogy a hagyományos formában felépített mikroszolgáltatás alapú alkalmazások komponenseit kiszervezze a peremhálózatra. Viszont bizonyos helyzetekben az alkalmazásnak a felelőssége megoldani, hogy áthidalja az olyan helyzeteket, amikor nem áll rendelkezésre kapcsolat a központi felhővel. +Az alkalmazás komponensek ugyanúgy képesek kommunikálni egymással, mint egy \textit{Kubernetes} környezetben a perem és a központi felhő komponensek között. Ugyanazok a monitorozó, felügyeleti és ütemezős eszközök működnek mindkét oldalán a rendszernek. Ezáltal a \textit{KubeEdge} lehetővé teszi, hogy a hagyományos formában felépített mikroszolgáltatás alapú alkalmazások komponenseit kiszervezze a peremhálózatra. Viszont bizonyos helyzetekben az alkalmazásnak a felelőssége megoldani, hogy áthidalja az olyan helyzeteket, amikor nem áll rendelkezésre kapcsolat a központi felhővel. Ahhoz, hogy ezt megoldja, a \textit{Kubernetes} klaszteren belül használt hálózati plugin segítségével kiterjeszti és összekapcsolja a \textit{Pod} hálózatot. -Mindennek köszönhetően a \textit{KubeEdge} platformon futtatható alkalmazások fejlesztése nagyon könnyű, hiszen az szinte teljesen megegyezik a mikroszolgáltatás alapú alkalmazások fejlesztésével. +Mindennek köszönhetően a \textit{KubeEdge} platformon futtatható alkalmazások fejlesztése nagyon könnyű, hiszen az szinte teljesen megegyezik a mikroszolgáltatás alapú alkalmazások fejlesztésével. Cserében a \textit{KubeEdge} nem implementál dinamikus ütemezési megoldásokat. Az egyes alkalmazásokat kézzel kell a kívánt peremhálózati szerverek valamelyikéhez rendelni. Ez jelentősen megnehezíti a skálázását az alkalmazásoknak, hiszen nem tudják a peremhálózatokra telepített több számítógép által nyújtott terhelés eloszlási lehetőségeket kihasználni\cite{kubeedge_crds}. \subsection{\acrshort{aws} \acrshort{iot} Greengrass} @@ -227,4 +228,8 @@ A rendszer felépítése három fő komponensből áll. Az első az \textit{\acr A rendszer üzembe helyezéséhez az \acrshort{iot} eszközökön kizárólag az \textit{Azure \acrshort{iot} Edge} csomag telepítése szükséges. Az eszköz regisztrálása után központilag van lehetőség alkalmazásmodulok telepítésére. -Az \textit{Azure \acrshort{iot} Edge} előnye, hogy egy kiforrott ipari megoldásról van szó, viszont a belső működése a szolgáltatásnak zárt. Az árazás szintekbe van sorolva, az ingyenes szinten naponta csupán nyolcezer üzenetet lehet átvinni a felhőben futó rendszer és a peremen\footnote{A dolgozat értelmezésében a végeszközök.} található eszközök között. \ No newline at end of file +Az \textit{Azure \acrshort{iot} Edge} előnye, hogy egy kiforrott ipari megoldásról van szó, viszont a belső működése a szolgáltatásnak zárt. Az árazás szintekbe van sorolva, az ingyenes szinten naponta csupán nyolcezer üzenetet lehet átvinni a felhőben futó rendszer és a peremen\footnote{A dolgozat értelmezésében a végeszközök.} található eszközök között. + + +\subsection{Kubernetes Federation} +% Nem erre való, de jó erre \ No newline at end of file diff --git a/src/content/scheduling.tex b/src/content/scheduling.tex index 0fd370f..d7388fe 100644 --- a/src/content/scheduling.tex +++ b/src/content/scheduling.tex @@ -1,11 +1,40 @@ % !TeX root = ../thesis.tex %---------------------------------------------------------------------------- -\chapter{Futtató környezet} +\chapter{Futtatás a peremhálózaton} +\label{chapter:running_on_the_edge} %---------------------------------------------------------------------------- +% Futtató környezet tervezése +% Vázolni a futtató környezetet amit elkészítettem +% írni arról, hogy készítettem, ansible, kubespray + +% Ütemezés megoldása +% Nincsenek jó ütemező algoritmusok +% Kell csinálni sajátot +% Ütemezési algoritmus tervezése +% Ütemezési algoritmus implementálása +% Bemeneti adatok +% Kimeneti adatok egy ábrán +% adat -> doboz -> ütemezési döntés +% Ütemezési döntések hogy materializálódnak a clusterek közt +% Az ütemező algoritmus bemente nagyon alakalmazás függő, attól függ mit akarunk elérni +% Ezért robotkaroknál latency, birbnetesnél sávszél +% Hogyan lettek mérve és gyűjtve +% Hogyan lettek kiértékelve + % Erről egyelőre még csak annyi a biztos, hogy kubernetes lesz -\section{Szolgáltatás telepítés} + +% Ütemező algoritmus +% Big brain matekoshoz ismerni kéne sokmindent +% Próbálgatós naiv algoritmust csinálok +% robotkar: mindig a legkisebb latency-hez igazítsa, ha oda nem sikerül, akkor fail (esetleg küszöbértéket meghatározni) +% Birbnetes: sávszél és queue hosszal lehet variálni. Sávszél alapján lehet osztályozni a queue hossz pedig a trigger, +% Itt nézni lehetne, hogy hol járt már, az oda-vissza rakosgatás elkerülése érdekében. + +\section{Felhős Keretrendszer} + +% Itt leírom, hogy az összes egy nagy kula, és a kubefedet is csak azért választom, hogy legyen egységes controlplane \section{Komponensek dinamikus ütemezése} \ No newline at end of file diff --git a/src/thesis.tex b/src/thesis.tex index 1ad2b70..49ffcb3 100644 --- a/src/thesis.tex +++ b/src/thesis.tex @@ -74,8 +74,8 @@ \include{content/overview} \include{content/birbnetes_impl} \include{content/ursim_impl} -%\include{content/scheduling} -%\include{content/measurements} +\include{content/scheduling} +\include{content/measurements} \include{content/conclusion}