marcsello/marci-dipterv-latex
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

aaaaa

Browse Source
This commit is contained in:
Pünkösd Marcell 2021-11-26 22:09:32 +01:00
parent 1edaaa9590
commit e51c50f060
4 changed files with 53 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
src/bib/mybib.bib
View File

@ -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},

23
src/content/overview.tex
View File

@ -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.
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

33
src/content/scheduling.tex
View File

@ -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}

4
src/thesis.tex
View File

@ -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}