diff --git a/src/bib/mybib.bib b/src/bib/mybib.bib index fa21d5f..41c3a83 100644 --- a/src/bib/mybib.bib +++ b/src/bib/mybib.bib @@ -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} +} \ No newline at end of file diff --git a/src/content/glossary.tex b/src/content/glossary.tex index b728859..339d41a 100644 --- a/src/content/glossary.tex +++ b/src/content/glossary.tex @@ -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} \ No newline at end of file +\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} diff --git a/src/content/overview.tex b/src/content/overview.tex index 38ffc15..0d3fbad 100644 --- a/src/content/overview.tex +++ b/src/content/overview.tex @@ -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. \ No newline at end of file +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} \ No newline at end of file diff --git a/src/content/ursim_impl.tex b/src/content/ursim_impl.tex index 85e164b..9a5ead0 100644 --- a/src/content/ursim_impl.tex +++ b/src/content/ursim_impl.tex @@ -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 diff --git a/src/include/packages.tex b/src/include/packages.tex index 0e628ea..1faf035 100644 --- a/src/include/packages.tex +++ b/src/include/packages.tex @@ -69,4 +69,5 @@ \usepackage{soul} \usepackage{tabularx} \usepackage{rotating} -\usepackage{mdframed} \ No newline at end of file +\usepackage{mdframed} +\usepackage[autostyle]{csquotes} \ No newline at end of file