aaaaa
This commit is contained in:
parent
1edaaa9590
commit
e51c50f060
@ -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},
|
||||
|
@ -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
|
@ -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}
|
@ -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}
|
||||
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user