Added more stuff
This commit is contained in:
parent
b4750c10d2
commit
0327c695b3
|
|
@ -148,3 +148,135 @@
|
|||
howpublished={\url{https://dataplace.com/en/connectivity/edge-computing}}
|
||||
note = {Hozzáférve: 2021-05-14}
|
||||
}
|
||||
|
||||
@misc{cloudflare_price_of_bandwidth,
|
||||
title={The Relative Cost of Bandwidth Around the World},
|
||||
author={Matthew Prince},
|
||||
howpublished={\url{https://blog.cloudflare.com/the-relative-cost-of-bandwidth-around-the-world/}}
|
||||
note = {Hozzáférve: 2021-05-16}
|
||||
}
|
||||
|
||||
@misc{server_location_matters,
|
||||
title={How server location affects latency?},
|
||||
author={Zain Imran},
|
||||
howpublished={\url{https://www.cloudways.com/blog/how-server-location-affects-latency/}}
|
||||
note = {Hozzáférve: 2021-05-16}
|
||||
}
|
||||
|
||||
|
||||
@article{liu2019edge,
|
||||
title={Edge computing for autonomous driving: Opportunities and challenges},
|
||||
author={Liu, Shaoshan and Liu, Liangkai and Tang, Jie and Yu, Bo and Wang, Yifan and Shi, Weisong},
|
||||
journal={Proceedings of the IEEE},
|
||||
volume={107},
|
||||
number={8},
|
||||
pages={1697--1716},
|
||||
year={2019},
|
||||
publisher={IEEE}
|
||||
}
|
||||
|
||||
@article{hao2020cloud,
|
||||
title={Cloud platforms for remote monitoring system: a comparative case study},
|
||||
author={Hao, Yuqiuge and Helo, Petri and Gunasekaran, Angappa},
|
||||
journal={Production Planning \& Control},
|
||||
volume={31},
|
||||
number={2-3},
|
||||
pages={186--202},
|
||||
year={2020},
|
||||
publisher={Taylor \& Francis}
|
||||
}
|
||||
|
||||
@article{wang2020secure,
|
||||
title={Secure healthcare monitoring framework integrating NDN-based IoT with edge cloud},
|
||||
author={Wang, Xiaonan and Cai, Shaohao},
|
||||
journal={Future Generation Computer Systems},
|
||||
volume={112},
|
||||
pages={320--329},
|
||||
year={2020},
|
||||
publisher={Elsevier}
|
||||
}
|
||||
|
||||
@article{edge_companies,
|
||||
title={60 Edge computing companies to watch in 2021},
|
||||
author={Dalia Adib},
|
||||
howpublished={\url{https://stlpartners.com/edge-computing/edge-computing-companies-to-watch-2021/}}
|
||||
note = {Hozzáférve: 2021-05-18}
|
||||
}
|
||||
|
||||
@article{edge_gaming,
|
||||
title={The future of cloud gaming is on the Edge},
|
||||
author={Greg Elliott},
|
||||
howpublished={\url{https://www.datacenterdynamics.com/en/opinions/future-cloud-gaming-edge/}}
|
||||
note = {Hozzáférve: 2021-05-18}
|
||||
}
|
||||
|
||||
@article{shi2016edge,
|
||||
title={Edge computing: Vision and challenges},
|
||||
author={Shi, Weisong and Cao, Jie and Zhang, Quan and Li, Youhuizi and Xu, Lanyu},
|
||||
journal={IEEE internet of things journal},
|
||||
volume={3},
|
||||
number={5},
|
||||
pages={637--646},
|
||||
year={2016},
|
||||
publisher={IEEE}
|
||||
}
|
||||
|
||||
|
||||
@misc{kubernetes_docs,
|
||||
author = {Google},
|
||||
title = {Kubernetes Documentation},
|
||||
howpublished = {\url{https://kubernetes.io/docs/home/}},
|
||||
note = {Accessed: 2020-05-09}
|
||||
}
|
||||
|
||||
@misc{docker_docs,
|
||||
author = {},
|
||||
title = {Docker Documentation},
|
||||
howpublished = {\url{https://docs.docker.com/}},
|
||||
note = {Accessed: 2020-05-09}
|
||||
}
|
||||
|
||||
@misc{kubeedge_docs,
|
||||
author = {},
|
||||
title = {KubeEdge Documentation},
|
||||
howpublished = {\url{https://kubeedge.io/en/docs/}},
|
||||
note = {Accessed: 2021-05-19}
|
||||
}
|
||||
|
||||
@misc{edgexfoundry_docs,
|
||||
author = {},
|
||||
title = {EdgeX Foundry DocumentationIntroduction},
|
||||
howpublished = {\url{https://docs.edgexfoundry.org/}},
|
||||
note = {Accessed: 2020-05-09}
|
||||
}
|
||||
|
||||
@misc{microservices,
|
||||
author = {Tom Huston},
|
||||
title = {What is Microservices?},
|
||||
howpublished = {\url{https://smartbear.com/solutions/microservices/}},
|
||||
note = {Accessed: 2020-05-09}
|
||||
}
|
||||
|
||||
|
||||
@misc{application_containers,
|
||||
author = {Suzanne Ferry},
|
||||
title = {Overview of Application Containers},
|
||||
howpublished = {\url{https://mapr.com/blog/overview-of-application-containers-part-1-of-4/}},
|
||||
note = {Accessed: 2020-05-09}
|
||||
}
|
||||
|
||||
|
||||
@misc{aas,
|
||||
author = {Stephen Watts and Muhammad Raza},
|
||||
title = {SaaS vs PaaS vs IaaS: What’s The Difference and How To Choose},
|
||||
howpublished = {\url{https://www.bmc.com/blogs/saas-vs-paas-vs-iaas-whats-the-difference-and-how-to-choose/}},
|
||||
note = {Accessed: 2020-05-09}
|
||||
}
|
||||
|
||||
|
||||
@techreport{containermarketshare,
|
||||
title = {Application Container Market by Service (Container Monitoring, Security, Data Management, Networking, Orchestration), Platform (Docker, Kubernetes), Application Area, Deployment Mode, Organization Size, Vertical, and Region - Global Forecast to 2023},
|
||||
url = {https://www.marketsandmarkets.com/Market-Reports/application-container-market-182079587.html},
|
||||
institution = {Markets and Markets},
|
||||
year = {2018}
|
||||
}
|
||||
|
|
@ -88,16 +88,39 @@
|
|||
\newglossaryentry{elasztikus}
|
||||
{
|
||||
name={elasztikus},
|
||||
description={}
|
||||
description={TODO}
|
||||
}
|
||||
|
||||
|
||||
\newglossaryentry{lastmile}
|
||||
{
|
||||
name={utolsó mérföld},
|
||||
description={}
|
||||
description={TODO}
|
||||
}
|
||||
|
||||
\newglossaryentry{felho}
|
||||
{
|
||||
name={felhő},
|
||||
description={TODO}
|
||||
}
|
||||
|
||||
\newglossaryentry{linux}
|
||||
{
|
||||
name={Linux},
|
||||
description={A Linux egy nylílt forráskdú kernel implementáció. A projekt Linus Benedict Torvalds (akkor) finn egyetemi hallgató hobbi projektjeként indult. Mára a vlág legnépszerűbb nyíltforráskódú projektje}
|
||||
}
|
||||
|
||||
\newglossaryentry{python}
|
||||
{
|
||||
name={Python},
|
||||
description={A Python egy általános célú, magas szintű interpretált programozási nyelv. Fejlesztését 1989-ben kezdte Guido van Rossum}
|
||||
}
|
||||
|
||||
\newglossaryentry{devops}
|
||||
{
|
||||
name={DevOps},
|
||||
description={Developement and Operations (Fejlesztés és Operálás) egy vállalati szoftverfejlesztési kifejezés, amely az egyfajta agilis összeköttetést jelent a fejlesztés és üzemeltetés között. A DevOps célja az, hogy közelebb hozza ezt a két vállalati egységet.}
|
||||
}
|
||||
|
||||
|
||||
\newacronym{mdt}{MDT}{Model-Driven Telemetry}
|
||||
|
|
@ -156,4 +179,17 @@
|
|||
\newacronym{ciscoie}{Cisco-IE}{Cisco Innovation Edge}
|
||||
\newacronym{oid}{OID}{Object Identifier}
|
||||
\newacronym{ann}{ANN}{Artificial Neural Network}
|
||||
\newacronym{nms}{NMS}{Network Management Station}
|
||||
\newacronym{nms}{NMS}{Network Management Station}
|
||||
\newacronym{saas}{SaaS}{Software as a Service}
|
||||
\newacronym{paas}{PaaS}{Platform as a Service}
|
||||
\newacronym{iaas}{IaaS}{Infrastructure as a Service}
|
||||
\newacronym{faas}{FaaS}{Function as a Service}
|
||||
\newacronym{svm}{SVM}{Support Vector Machines}
|
||||
\newacronym{knn}{kNN}{k Nearest Neighbor}
|
||||
\newacronym{rest}{REST}{Representational State Transfer}
|
||||
\newacronym{vm}{VM}{Virtual Machine}
|
||||
\newacronym{nat}{NAT}{Network Address Translation}
|
||||
\newacronym{pv}{PV}{Persistent Volume}
|
||||
\newacronym{nfs}{NFS}{Network File System}
|
||||
\newacronym{yaml}{YAML}{YAML Ain't Markup Language}
|
||||
\newacronym{wsgi}{WSGI}{Web Server Gateway Interface}
|
||||
|
|
|
|||
|
|
@ -1,30 +1,72 @@
|
|||
% !TeX root = ../thesis.tex
|
||||
%----------------------------------------------------------------------------
|
||||
\chapter{Áttekintés a perem és felhő rendszerekről}
|
||||
\chapter{Áttekintés a perem és \gls{felho} rendszerekről}
|
||||
%----------------------------------------------------------------------------
|
||||
|
||||
\section{Tradicionális megközelítés} % Egy kis áttekintés a "tradícionális felhőről"
|
||||
|
||||
% TODO: bevezetés
|
||||
|
||||
\section{Klasszikus \gls{felho}s megközelítés} % Egy kis áttekintés a "tradícionális felhőről"
|
||||
\label{sec:tradicionalis_megkozelites}
|
||||
|
||||
Általánosságban véve az informatikában akkor beszélhetünk felhőről, amikor egy adott alkalmazást általunk üzemeltetett infrastruktúra helyett egy távoli szolgáltató által fenntartott környezetben futtatunk\cite{what_is_cloud}. A tradicionális megközelítés szerint ezek a környezetek az üzemeltetéséhez szükséges infrastruktúra egy vagy több -- a szolgáltató által üzemeltetett -- \gls{adatkozpont}ban foglal helyet.
|
||||
\subsection{Általánosságban a \gls{felho}ről}
|
||||
|
||||
A felhőszolgáltatások alkalmazásának több előnye is van, ezekből talán a legfontosabbak az
|
||||
Általánosságban véve az informatikában akkor beszélhetünk \gls{felho}ről, amikor egy adott alkalmazást általunk üzemeltetett infrastruktúra helyett egy távoli szolgáltató által fenntartott környezetben futtatunk\cite{what_is_cloud}. A tradicionális megközelítés szerint ezek a környezetek az üzemeltetéséhez szükséges infrastruktúra egy vagy több -- a szolgáltató által üzemeltetett -- \gls{adatkozpont}ban foglal helyet.
|
||||
|
||||
A \gls{felho}szolgáltatások alkalmazásának több előnye is van, ezekből talán a legfontosabbak az
|
||||
általános hardverelemek használatára visszavezethető alacsonyabb beruházási költség és az automatizált
|
||||
folyamatok biztosította alacsonyabb üzemeltetési költség\cite{costofcloud}. Ezzel leveszi az üzemeltetés terhét és költségét az alkalmazás fejlesztőinek válláról.
|
||||
|
||||
Gyakran a felhőszolgáltató egynél több \gls{adatkozpont}ot tart fenn, amelyeket a világ több pontján helyeznek el. Ezzel biztosítva redundanciát, magasabb rendelkezésre állást és hatékonyabb elérést\cite{geodist}.
|
||||
Gyakran a \gls{felho}szolgáltató egynél több \gls{adatkozpont}ot tart fenn, amelyeket a világ több pontján helyeznek el. Ezzel biztosítva redundanciát, magasabb rendelkezésre állást és hatékonyabb elérést\cite{geodist}.
|
||||
|
||||
Előnyei miatt, manapság a nagyvállalatok csaknem 94\%-a már használja a felhő szolgáltatások nyújtotta előnyöket és alkalmazásaiknak már 83\%-a valamilyen felhő környezetben futnak\cite{cloudadpotation}.
|
||||
A felhő architektúráknak több modelljét is megkülönböztetjük. Ezeket pedig aszerint osztályozhatjuk, hogy mekkora kontrollt adnak a felhasználónak a futó alkalmazás felett. Ennek a kontrollnak a legalacsonyabb szintjén van az úgy nevezett \acrfull{saas} (Szoftver mint szolgáltatás) amely egy előre telepített szoftver eszközt biztosít a szolgáltató \gls{felho} környezetében amelyet általában a felhasználó az interneten keresztül ér el. Legmagasabb szintjén pedig a \acrfull{iaas} foglal helyet, ahol az alapvető infrastruktúrát készen kapjuk, de minden mást a szolgáltatás felhasználójának kell megterveznie, feltelepíteni, konfigurálni és üzemeltetni \cite{aas}.
|
||||
|
||||
Amellett, hogy az felhőszolgáltatások adaptációja növekvő tendenciát mutat. Az internetre kapcsolt eszközök száma is szépen gyarapodik\cite{annualinternetreport}. Ehhez a felhasználói készülékek mellett jelentősen hozzájárul az utóbbi időben jelentős fejlődésnek örvendő \acrfull{iot} rendszerek egyre nagyobb mértékű alkalmazása\cite{iotadpotation}.
|
||||
Előnyei miatt, manapság a nagyvállalatok csaknem 94\%-a már használja a \gls{felho} szolgáltatások nyújtotta előnyöket és alkalmazásaiknak már 83\%-a valamilyen \gls{felho} környezetben futnak\cite{cloudadpotation}.
|
||||
|
||||
Ezek alapján a felhő szolgáltatásokat nyújtó \gls{adatkozpont}ok kapacitásukat mind számítási teljesítményben, mind rendelkezésre álló sávszélességre való tekintettel egyre növekvő elvárással szembesülnek. Mindazonáltal a \gls{vegeszkoz}öket összekötő hálózatok is jelentősen növekvő igényeknek néznek elébe. Mindeközben pedig egyre nagyobb igény mutatkozik arra, hogy az alkalmazásaink jó válaszidővel, alacsony késleltetéssel működjenek\cite{stateofart}.
|
||||
Amellett, hogy az \gls{felho}szolgáltatások adaptációja növekvő tendenciát mutat. Az internetre kapcsolt eszközök száma is szépen gyarapodik\cite{annualinternetreport}. Ehhez a felhasználói készülékek mellett jelentősen hozzájárul az utóbbi időben jelentős fejlődésnek örvendő \acrfull{iot} rendszerek egyre nagyobb volumenű alkalmazása\cite{iotadpotation}.
|
||||
|
||||
Ezek alapján a \gls{felho} szolgáltatásokat nyújtó \gls{adatkozpont}ok kapacitásukat mind számítási teljesítményben, mind rendelkezésre álló sávszélességre való tekintettel egyre növekvő elvárással szembesülnek. Mindazonáltal a \gls{vegeszkoz}öket összekötő hálózatok is jelentősen növekvő igényeknek néznek elébe. Mindeközben pedig egyre nagyobb igény mutatkozik arra, hogy az alkalmazásaink jó válaszidővel, alacsony késleltetéssel működjenek\cite{stateofart}.
|
||||
|
||||
|
||||
\subsection{Felhős alkalmazásüzemeltetési eszközök}
|
||||
|
||||
\subsubsection{Alkalmazás Konténer}
|
||||
|
||||
Egy alkalmazás konténer általánosságban egy önálló csomag, amely tartalmazza a futtatni kívánt alkalmazást és a futtatásához szükséges szoftver környezetet. A konténerek használata jelentősen megkönnyíti és meggyorsítja az alkalmazás fejlesztési és telepítési ciklust. Mivel magába foglalja a teljes környezetet, amely szükséges a futtatáshoz, így a szoftver ugyanúgy fut a fejlesztők számítógépein, a tesztkörnyezetben és az éles környezetben is \cite{application_containers}.
|
||||
|
||||
Az alkalmazás konténerek koncepciójának megvalósítására egy népszerű implementáció a \textit{Docker}, amely a \gls{linux} kernelben található izolációs szolgáltatásokra épít. Ezzel valósítja meg, hogy a konténerek egymástól független környezetben tudjanak futni. Egyetlen szoftver erőforrás, amin közösen osztoznak az a kernel maga.
|
||||
|
||||
Dockerben az alkalmazást és környezetét úgynevezett képfájlokban (image) tároljuk. Ezek a képfájlok általában csak a legszükségesebb komponenseket tartalmazzák, ezért a virtuális számítógépekhez képfájlaihoz képest kisebb méretűek. Ezeket a képfájlokat az alkalmazás fejlesztése után készítjük és az alkalmazás konténer indításához használjuk \cite{docker_docs}.
|
||||
|
||||
\subsubsection{Kubernetes}
|
||||
|
||||
Manapság egyre jobban terjed a konténer alapú szoftver fejlesztés és a felhő alapú megoldások\cite{containermarketshare}. Az egyik legnépszerűbb ilyen felhő implementáció a \textit{Kubernetes}. A \textit{Kubernetes} egy konténer orkesztrációs platform, amely felügyeli és kezeli az egyes alkalmazásokat vagy szolgáltatásokat megvalósító konténerek életciklusát egy multihoszt környezetben.
|
||||
|
||||
Az életciklus kezelés mellett több hasznos szolgáltatást is nyújt. Ilyenek az automatikus szolgáltatás felderítés és terhelés elosztás, tárhely orkesztráció, konfiguráció kezelés. Bizonyos, megfelelően felkonfigurált helyzetekben a \textit{Kubernetes} képes alapszintű hibajavításra is, bizonyos szolgáltatások programozott újraindításával.\cite{kubernetes_docs}
|
||||
|
||||
Kubernetes klaszternek nevezzük azt a multihoszt környezetet, ahol több -- egymással hálózatba kötött -- számítógép (fizikai vagy virtuális) valósítja meg a \textit{Kubernetes} környezetet.
|
||||
|
||||
A klaszteren belül két jól elkülöníthető szerepkört definiálunk, ezek a master (mester) és a worker (munkás) szereprek. A master felel az erőforrások elosztásáért, a konténerek workerhez rendeléséért és összességében a klaszter irányításáért. A workerek felelnek a konkrét alkalmazásunkhoz tartozó konténerek futtatásáért.
|
||||
|
||||
Egy \textit{Kubernetes} környezetben különböző objektumokat definiálunk, amelyekkel le írhatjuk a klaszterünkben futó alkalmazások elvárt állapotát. Ezek az objektumok közül a legkisebb kezelhető egység a \textit{Pod}. A \textit{Pod} egy vagy több futó konténert reprezentáló logikai egység. Az egy \textit{Pod}on belül futó konténerek osztoznak bizonyos névtereken, ilyen a hálózati vagy a folyamatok névtere.
|
||||
|
||||
Eggyel \enquote{nagyobb} objektum ezeknél a \textit{Deployment}, a \textit{Deployment} egy alkalmazás futtatásához szükséges állapotot írja le. A \textit{Kubernetes} klaszter törekszik a \textit{Deployment}ben megfogalmazott állapot elérésére és fenntartására.
|
||||
|
||||
\subsubsection{Mikroszolgáltatások}
|
||||
|
||||
A mikroszolgáltatás modell egy újkeletű architekturális megközelítés a szoftver fejlesztésben. Ebben a megközelítésben egyfunkciós modulokat tervezünk és fejlesztünk, amelyek jól definiált Alkalmazás programozói interfész (\acrlong{api}; \acrshort{api}) használatával kommunikálnak egymással\cite{microservices}. Ennek hála, amíg egy komponens teljesíti az elvárt \acrshort{api} definíciót, addig szabadon kicserélhető
|
||||
|
||||
Az egységek a fejlesztése, és tesztelése sokkal gyorsabb ütemben tud haladni a kisebb kódbázis miatt. A rajtuk eszközölt fejlesztések sokkal hamarabb kerülhetnek ki az éles rendszerbe, hiszen a változtatásuk nem érinti a teljes rendszert, ezért könnyebb őket frissíteni, vagy valamilyen szélsőséges esemény hatására visszaállni egy korábbi változatra.
|
||||
|
||||
Mikroszolgáltatásokkal az alkalmazások skálázása is jelentősen leegyszerűsödik. Míg egy monolit rendszerben a teljes alkalmazást skálázni kellett, ha nagyobb teljesítményre volt szükség, itt -- feltéve, hogy tisztában vagyunk vele, hogy mely komponensek jelentik a szűk keresztmetszetet -- elég csak a megfelelő szolgáltatásokat.
|
||||
|
||||
A mikroszolgáltatásoknak további előnyös jellemzője, hogy az egyes komponensek teljesen egyedül kezelik a saját belső adatstruktúrájukat. Az egyetlen kompatibilitási réteg, amelyet biztosítaniuk kell az az \acrfull{api} interfész. A mikroszolgáltatások teljesen szabadon változtathatják a belső struktúrájukat akár verziók között is. De nem csak az adatstruktúrával szemben van ekkora szabadságunk, hanem akár a különböző programnyelvekkel is.
|
||||
|
||||
|
||||
\section{Peremhálózati rendszerek} % Szóval itt felvezetem hogy van ez a perem meme
|
||||
\label{sec:peremhalozati_rendszerek}
|
||||
|
||||
|
||||
Az előző szekcióban ismertetésre került néhány probléma a felhő-számítástechnika tradicionális alkalmazásával. Mint ahogy azt \aref{fig:overview_no_edge}.\ ábra is szemlélteti, ha az egyes \gls{vegeszkoz}ök közvetlenül kommunikálnak a felhőszolgáltatást nyújtó \gls{adatkozpont}tal, az lineárisan növekvő terhelést jelent, mind a köztes hálózatnak, mint az \gls{adatkozpont}nak. Emellett a megtett távolság miatt a késleltetés is növekszik.
|
||||
A \gls{felho}-számítástechnika tradicionális megközelítésben való alkalmazásában jelentős hatékonysági kérdések merülnek fel. Mint ahogy azt \aref{fig:overview_no_edge}.\ ábra is szemlélteti, ha az egyes \gls{vegeszkoz}ök közvetlenül kommunikálnak a \gls{felho}szolgáltatást nyújtó \gls{adatkozpont}tal, az lineárisan növekvő terhelést jelent, mind a köztes hálózatnak, mint az \gls{adatkozpont}nak. Emellett a megtett távolság miatt a késleltetés is növekszik.
|
||||
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
|
|
@ -39,92 +81,94 @@ A fent vázolt problémákra megoldást ígér a peremhálózati rendszerek alka
|
|||
|
||||
\subsection{Használt fogalmak}
|
||||
|
||||
A peremhálózat pontos definiálása egyelőre nem teljesen tisztázott mivel nem is egy egyszerű kérdés\cite{cureforedge, cloudflare_whatisedge}. Egyes források szerint a peremhálózatit számítástechnika az magukon a \gls{vegeszkoz}ökön futtatott alkalmazások\cite{verge_whatisedge}, míg más források a felhő és a \gls{vegeszkoz}ök között elhelyezkedő számítási környezetre hivatkoznak így\cite{ibm_whatisedge}, illetve vannak források amelyek a határokat teljesen elmosva mindkettőt értelmezik\cite{cb_whatisedge, dataplace_whatisedge}
|
||||
A peremhálózat pontos definiálása egyelőre nem teljesen tisztázott mivel nem is egy egyszerű kérdés\cite{cureforedge, cloudflare_whatisedge}. Egyes források szerint a peremhálózati számítástechnika az magukon a \gls{vegeszkoz}ökön futtatott alkalmazások\cite{verge_whatisedge}, míg más források a \gls{felho} és a \gls{vegeszkoz}ök között elhelyezkedő számítási környezetre hivatkoznak így\cite{ibm_whatisedge}, illetve vannak források amelyek a határokat teljesen elmosva mindkettőt értelmezik\cite{cb_whatisedge, dataplace_whatisedge}
|
||||
|
||||
A fogalom -- és a kapcsolódó fogalmak -- tisztázására és egységesítésére a \textit{Linux Foundation} egy nyitott szójegyzéket hozott létre "\textit{Open Glossary of Edge Computing}" néven. Ezt a szabadon elérhető szójegyzéket egyre több gyártó ismeri el és használja\cite{openglossary}.
|
||||
A fogalom -- és a kapcsolódó fogalmak -- tisztázására és egységesítésére a \textit{Linux Foundation} egy nyitott szójegyzéket hozott létre "\textit{Open Glossary of Edge Computing}" néven\footnote{\url{https://www.lfedge.org/openglossary/}}. Ezt a szabadon elérhető szójegyzéket egyre több gyártó ismeri el és használja\cite{openglossary}.
|
||||
|
||||
A szójegyzék jelenlegi (2.0-ás verzió) kiadása alapján néhány fontosabb fogalmat az alábbiak szerint definiálhatunk:
|
||||
\begin{itemize}
|
||||
\item \textbf{Cloud Computing} (Felhő számítástechnika): Egy olyan rendszer, amely igény-vezérelt hozzáférést biztosít megosztott erőforrásokhoz, beleértve a hálózatot tárolást és számítási kapacitást. Tipikusan kevés számú de nagy méretű regionális \gls{adatkozpont}okat használva.
|
||||
\item \textbf{Cloud Computing} (\Gls{felho} számítástechnika): Egy olyan rendszer, amely igény-vezérelt hozzáférést biztosít megosztott erőforrásokhoz, beleértve a hálózatot tárolást és számítási kapacitást. Tipikusan kevés számú de nagy méretű regionális \gls{adatkozpont}okat használva.
|
||||
|
||||
\item \textbf{Edge Computing} (Perem számítástechnika): A számítási kapacitás eljuttatása hálózat logikai végleteibe, annak érdekében hogy ezzel növeljék a teljesítményt, csökkentsék a működtetési költségeket illetve növeljék a rendelkezésre állását a biztosított alkalmazásoknak és szolgáltatásoknak. [\dots]
|
||||
|
||||
\item \textbf{Edge Cloud} (Perem felhő): Felhő-szerű képességek az infrastruktúra peremén amely -- a felhasználó perspektívájából -- hozzáférést enged \gls{elasztikus}an allokált számítási, adat tárolási és hálózati erőforrásokhoz. Többnyire észrevétlenül szolgál a centralizált privát- vagy publikus felhő kiterjesztéseként. A hálózat peremén telepített mikro-\gls{adatkozpont}okból épül fel. Időnként elosztott perem-felhőként hivatkoznak rá.
|
||||
\item \textbf{Edge Cloud} (Perem \gls{felho}): \Gls{felho}-szerű képességek az infrastruktúra peremén amely -- a felhasználó perspektívájából -- hozzáférést enged \gls{elasztikus}an allokált számítási, adat tárolási és hálózati erőforrásokhoz. Többnyire észrevétlenül szolgál a centralizált privát- vagy publikus \gls{felho} kiterjesztéseként. A hálózat peremén telepített mikro-\gls{adatkozpont}okból épül fel. Időnként elosztott perem-\gls{felho}ként hivatkoznak rá.
|
||||
|
||||
\item \textbf{Edge Data Center} (Perem-\gls{adatkozpont}): Olyan \gls{adatkozpont} amelyet a mennyire csak lehet a hálózat pereméhez lehet telepíteni szemben a hagyományos \gls{adatkozpont}okkal. Képes arra, hogy ugyanazokat a szolgáltatásokat nyújtsa, de önmagában egy sokkal kisebb skálán. [\dots] A \textit{perem} itt a telepítés helyére hivatott utalni. [\dots] Több perem-\gls{adatkozpont} egymással közvetlen kapcsolatban állhat, hogy ezzel biztosítsanak nagyobb kapacitást, migrációt meghibásodás elkerülés vagy terhelés elosztás céljából egy nagy virtuális \gls{adatkozpont}ként funkcionálva.
|
||||
|
||||
\item \textbf{Infrastructure Edge} (Infrastruktúra pereme): Számítási kapacitás a peremen tipikusan egy vagy több perem-\gls{adatkozpont} formájában megvalósítva, amelyet a szolgáltatói \gls{lastmile}ön telepítenek. Számítási, adattárolási és hálózati előforrások, amelyeket az infrastruktúra peremére telepítenek lehetővé teszi a felhőszerű szolgáltatások nyújtását, hasonlóképp mint a centralizált központi \gls{adatkozpont}okban. Ilyenek például az erőforrások \gls{elasztikus} allokációja. De mindezt alacsonyabb késleltetéssel és csökkentett adat továbbítási költségekkel, a magas fokú lokalizációnak köszönhetően szemben a centralizált vagy regionális \gls{adatkozpont}okkal.
|
||||
\item \textbf{Infrastructure Edge} (Infrastruktúra pereme): Számítási kapacitás a peremen tipikusan egy vagy több perem-\gls{adatkozpont} formájában megvalósítva, amelyet a szolgáltatói \gls{lastmile}ön telepítenek. Számítási, adattárolási és hálózati előforrások, amelyeket az infrastruktúra peremére telepítenek lehetővé teszi a \gls{felho}szerű szolgáltatások nyújtását, hasonlóképp mint a centralizált központi \gls{adatkozpont}okban. Ilyenek például az erőforrások \gls{elasztikus} allokációja. De mindezt alacsonyabb késleltetéssel és csökkentett adat továbbítási költségekkel, a magas fokú lokalizációnak köszönhetően szemben a centralizált vagy regionális \gls{adatkozpont}okkal.
|
||||
|
||||
\end{itemize}
|
||||
|
||||
\textbf{A dolgozat további részeiben ezek a fogalmak a mérvadóak} (kivéve ahol ez külön jelölve van).
|
||||
|
||||
\subsection{Architektúra}
|
||||
\subsection{Architekturális előnyök} % TODO: cite
|
||||
|
||||
% Ez a fenn említett fogalmak alapján egy konkrét képet alkot az emeberek fejében.
|
||||
Az előbbiek alapján ez a dolgozat peremhálózati \gls{adatkozpont}oknak azokat tekinti, amelyek logikailag -- és valamilyen szinten fizikailag is -- a \gls{felho} és a \gls{vegeszkoz}ök között helyezkednek el. Ezen a tartományon értelmezve "közel" áll a \gls{vegeszkoz}höz.
|
||||
|
||||
% egy ilyen architektúrát mutat be az ábra
|
||||
Ezt a fajta logikai "közelség" úgy valósul meg, hogy az úton, amelyet egy hálózati üzenetnek be kell járnia a \gls{vegeszkoz}től a \gls{felho}ig, a peremhálózati \gls{adatkozpont}ot a lehető legközelebb igyekszünk helyezni a \gls{vegeszkoz}höz. Következésképp egy hálózati csomagnak jelentősen rövidebb utat kell bejárnia a peremhálózati \gls{adatkozpont}ig, mint a központi megfelelőjéig. Egy ilyen architektúra vázlatát mutatja be \aref{fig:overview_with_edge}.\ ábra. Az \gls{adatkozpont} "közelebb" helyezése a végeszközökhöz számos előnnyel jár.
|
||||
|
||||
\begin{figure}[h!]
|
||||
\centering
|
||||
\includegraphics[width=0.7\textwidth]{figures/overview_with_edge.pdf}
|
||||
\caption{A peremhálózati adatközpontok alkalmazásával egy kisebb skálájú, de teljes funkcionalitású \gls{adatkozpont}ot ékelődik a végfelhasználók és a központi felhő közé.}
|
||||
\caption{A peremhálózati adatközpontok alkalmazásával egy kisebb skálájú, de teljes funkcionalitású \gls{adatkozpont}ot ékelődik a \gls{vegeszkoz} és a központi \gls{felho} közé.}
|
||||
\label{fig:overview_with_edge}
|
||||
\end{figure}
|
||||
|
||||
Az egyik ilyen jelentős előny a késeltetés javítása. A hálózati adattovábbításhoz szükséges időt jelentősen befolyásolja mind az, hogy fizikailag milyen távolságba kell eljuttatni az információt (a jelenlegi legerősebb limitáló faktor maga a fényebesség az optikai összeköttetések esetén) de sokkal inkább az, hogy hány csomóponton kell áthaladnia útközben a csomagnak\cite{server_location_matters}. Azzal, hogy a távolságot és a köztes csomópontok számát csökkentjük jelentős javulást tudunk elérni a késleltetésben.
|
||||
|
||||
% ez jolesz ahol írom hogy mi az az edge es miert old meg gondokat
|
||||
\cite{7807196}
|
||||
|
||||
% Le kell írni az elméleti példát, és hogy hoygan oldja meg a problémákat amit fenn felvetettem
|
||||
% Egy gyakorlati példát is szeretnék adni, ami a mobil hálózatokra igaz, hogy BS-en van a cucc meg az datacenter meg minden
|
||||
|
||||
|
||||
Végül fontos megjegyezni, hogy a peremhálózatok nem fogják és nem is tervezik kiváltani a tradicionális megközelítést, sokkal inkább azt kiegészítve szimbiózisban van értelme üzemeltetni.
|
||||
|
||||
\section{Felhő és perem rendszerek együttes alkalmazásának előnyei} % A perem és a felhő hálózatok mire jók
|
||||
|
||||
% alapvetően bármit ki lehet szervezni ebbe a rendszerbe, de nem mindennek van értelme
|
||||
% ahhoz, hogy megállapítsuk, minek van értelme, egyeztessük a szempontokaz az előnyökkel
|
||||
|
||||
% Itt leírom, hogy aggregáció és késleltetés az két nagyon fontos szempont amin javítani tud a perem és felhő
|
||||
|
||||
|
||||
\subsection{Nagy mennyiségű adatok aggregálása}
|
||||
|
||||
\subsection{Késleltetés érzékeny alkalmazások}
|
||||
|
||||
\subsection{Egyéb szempontok}
|
||||
|
||||
% Kevesebb áram? Nagyobb redundancia?
|
||||
% Valamelyik doksiban írtak egy csomó mindent
|
||||
|
||||
\section{Keretrendszerek}
|
||||
|
||||
% itt le lehet írni, hogy igazából mit is kell egy keretrendszernek tudnia
|
||||
% Keresni pár példát
|
||||
|
||||
\subsection{Alkalmazás fejlesztési keretrendszerek}
|
||||
|
||||
\subsection{Alkalmazás futtatási keretrendszerek}
|
||||
|
||||
|
||||
% El lehet mondani, hogy ezt a kubermeme tudja és az jó nekünk
|
||||
|
||||
|
||||
% Ez a másik chapterből lett iderakva:
|
||||
|
||||
|
||||
% Ez egy bevezetés lényegében
|
||||
|
||||
Az adatforgalomért sok esetben az interneten szolgáltatók között is fizetniük kell az egyes feleknek\cite{cloudflare_price_of_bandwidth}. Azzal, hogy az információnak kevesebb köztes csomóponton kell áthaladnia jelentős adatforgalmi költségeket lehet megtakarítani a köztes szolgáltatóknak. Különös tekintettel arra az esetre, ha az adatforgalom nem hagyja el a szolgáltatói hálózatot.
|
||||
|
||||
% TODO: privacy
|
||||
|
||||
% Villany használat
|
||||
% Privacy/Security
|
||||
|
||||
\section{Megvalósított alkalmazások}
|
||||
|
||||
% Itt leírom hogy a Birbnetes és az ursim miért jók és miért demózzák jól a két fenti megállapítást
|
||||
% A birbnetesnél a minta felismerés át fog mászni az edge-cloudba
|
||||
\section{\Gls{felho} és perem rendszerek együttes alkalmazásának előnyei} % A perem és a felhő hálózatok mire jók
|
||||
|
||||
A választott alkalmazások megvalósítását \aref{chapter:birbnetes}.\ és \aref{chapter:ursim}.\ fejezetek részletezik.
|
||||
Ugyan a peremhálózati adatközpontok alkalmazása önmagában sok előnnyel kecsegtet, fontos megjegyezni, hogy a peremhálózati rendszerek nem fogják és nem is tervezik kiváltani a tradicionális megközelítést. Sokkal inkább azt kiegészítve szimbiózisban tudnak igazán érvényesülni.
|
||||
|
||||
% Itt le kell írni hogy van ez a két dolog
|
||||
Egy ilyen "szimbiózisban" a peremhálózati rendszerekre mint a felhős szolgáltatások kiterjesztéseként tekinthetünk\cite{7807196}. A peremhálózati rendszerek korábban említett két előnye, amelyek az alacsony késleltetés és csökkentett hálózati költségek kiegészítik a \gls{felho}s alkalmazásokat. A késleltetés érzékeny, vagy nagy adatot fogadó komponenseket kiszervezhetjük a peremre, ott akár még előfeldolgozást is végezhetünk az adatokon, így csökkentett mennyiségű és kevésbé késleltetés érzékeny adatokat kell csak eljuttatnunk a felhőbe, ezzel akár még a felhasználói élményt is javítva.
|
||||
|
||||
A gyakorlatban a technológia adott arra, hogy szinte bármit a kiszervezzünk a központi \gls{felho}ből a peremhálózati rendszerekre. Viszont a fent említett előnyök általában véve csak az alkalmazás valamely részegységében ad értelmezhető hasznot. Fontos ezért a megfelelő architekturális tervezése az alkalmazásnak, illetve az alapos felmérése az igényeknek és a hasznoknak.
|
||||
|
||||
|
||||
\section{Gyakorlati alkalmazás}
|
||||
Számos olyan alkalmazás van, amelynél a peremhálózati és felhő rendszerek alkalmazásával jelentős javítást lehet elérni a fenti szempontokban.
|
||||
|
||||
Jelenleg is már több alkalmazásnál is használják, vagy tervezik használni. Ilyenek például az önvezető járművek\cite{liu2019edge}, ipari rendszerek távfelügyelete\cite{hao2020cloud}, betegfelügyelet\cite{wang2020secure}, felhő alapú játék szolgáltatások\cite{edge_gaming}, okos otthonok és városok\cite{shi2016edge} és még sok minden más területen\cite{edge_companies}.
|
||||
|
||||
A dolgozatom részeként a \gls{felho} és a peremhálózati rendszerek előnyeinek bemutatására két konkrét alkalmazást készítettem, amelyen jól demózhatóak az előnyök. Ezeknek a megvalósítását a \aref{chapter:birbnetes}.\ és \aref{chapter:ursim}.\ fejezetek részletezik.
|
||||
|
||||
\section{Alkalmazás futtatási és fejlesztési keretrendszerek}
|
||||
|
||||
% 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
|
||||
|
||||
\subsection{EdgeX Foundry}
|
||||
|
||||
Az \textit{EdgeX Foundry} egy mikroszolgáltatásokból felépülő környezet, amelynek a célja az, hogy a perem alkalmazások fejlesztésénél gyakran felmerülő feladatokat ellátó komponensek egységesek legyenek\cite{edgexfoundry_docs}.
|
||||
|
||||
|
||||
|
||||
|
||||
\subsection{Project EVE}
|
||||
|
||||
\subsection{Akarino Edge Stack}
|
||||
|
||||
\subsection{StarlingX}
|
||||
|
||||
\subsection{KubeEdge}
|
||||
|
||||
A \textit{KubeEdge} egy \textit{Kubernetes}re épülő rendszer, amely kiterjeszti annak képességeit, hogy konténerizált alkalmazásokat peremhálózati rendszerek kezelésével\cite{kubeedge_docs}.
|
||||
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
\subsection{AWS IoT Greengrass}
|
||||
|
||||
\subsection{Azure IoT Edge}
|
||||
|
|
@ -11,13 +11,25 @@
|
|||
% Mivel ezt a dipterv alatt csináltam, ezért részletesebben fogok írni róla
|
||||
|
||||
|
||||
\section{... ismertetése} % Általánosan a robotkar cumók ismertetése
|
||||
\section{Környezet ismertetése} % Általánosan a robotkar cumók ismertetése
|
||||
|
||||
\subsection{TODO} % Általános leírás a robotkarokról
|
||||
\subsection{Universal Robots}
|
||||
% Általános leírás a robotkarokról
|
||||
|
||||
\subsection{RTDE interfész}
|
||||
|
||||
\subsection{TODO} % Itt foglalom össze, hogy hogy terveztem meg ezt a fost
|
||||
\subsubsection{Fizikai jellemzők}
|
||||
% Ide majd keresek valamit, lehet átnevezem valami okosra a címét
|
||||
|
||||
\subsubsection{Kommunikációs interfész}
|
||||
% URTD Interface
|
||||
|
||||
\subsubsection{Szimulátor}
|
||||
% Dockursim
|
||||
|
||||
\subsection{Demo vezérlés}
|
||||
|
||||
|
||||
\section{Tervezés} % Itt foglalom össze, hogy hogy terveztem meg ezt a fost
|
||||
|
||||
% tervezés és a nehézségek nem tételesen de hasonlóan struktúrálva
|
||||
% Illetve a komoly megoldásaim
|
||||
|
|
|
|||
|
|
@ -69,4 +69,5 @@
|
|||
\usepackage{soul}
|
||||
\usepackage{tabularx}
|
||||
\usepackage{rotating}
|
||||
\usepackage{mdframed}
|
||||
\usepackage{mdframed}
|
||||
\usepackage[autostyle]{csquotes}
|
||||
Loading…
Reference in New Issue