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