Added Markosz revision 4th edition
This commit is contained in:
parent
f859303a65
commit
b4dfc35c25
|
|
@ -4,35 +4,36 @@
|
|||
\label{chapter:dynamic_scheduling}
|
||||
%----------------------------------------------------------------------------
|
||||
|
||||
Az előző fejezetekben ismertetett, átalakított alkalmazások jól ki tudják használni a peremhálózati informatikai infrastruktúra adta lehetőségeket. Mint azt a \aref{sec:peremhalozati_rendszerek}.\ szekcióban is ismertettem a peremhálózati rendszerek a hagyományos adatközpontokkal szemben számos különbséget képviselnek. Egyik ilyen különbség a telepítésük sűrűsége. Ez a tulajdonsága lehetővé teszi, hogy a megvalósított alkalmazás szempontjából bizonyos szolgáltatásokat a felhasználókhoz \enquote{közel} futtasson. Ennek a \enquote{közelségnek} önmagában számos előnye tud lenni, mint például a csökkentett hálózati késleltetés és terhelés. Tipikusan a peremhálózati infrastruktúrákra jellemző, hogy a felhő végtelennek tűnő számítási kapacitásához képest erősen limitált erőforrások állnak rendelkezésre.
|
||||
Az előző fejezetekben ismertetett, átalakított alkalmazások jól ki tudják használni a peremhálózati informatikai infrastruktúra adta lehetőségeket. Mint azt a \aref{sec:peremhalozati_rendszerek}.\ %szekcióban
|
||||
alfejezetben is ismertettem, a peremhálózati rendszerek és a hagyományos adatközpontok több dologban különböznek. Egyik ilyen különbség a telepítésük sűrűsége. Ez a tulajdonság lehetővé teszi, hogy a megvalósított alkalmazás szempontjából bizonyos szolgáltatásokat a felhasználókhoz \enquote{közel} futtasson. Ennek a \enquote{közelségnek} önmagában számos előnye tud lenni, mint például a csökkentett hálózati késleltetés és terhelés. Tipikusan a peremhálózati infrastruktúrákra jellemző, hogy a felhő végtelennek tűnő számítási kapacitásához képest erősen limitált erőforrások állnak rendelkezésre.
|
||||
|
||||
Könnyen beláthatjuk ezekből adódóan, hogy fontos szerepe van annak a kérdésnek, hogy egyes szolgáltatásokat mikor és melyik peremhálózati rendszeren futtatunk, vagy hogy megéri-e kihelyezni őket a felhő által nyújtott futtatókörnyezetből. Egy rosszul megválasztott szolgáltatás elhelyezés könnyen lehet, hogy az előnyök teljes ellentétét idézi elő megnövekedett költségek mellett. Mivel a peremhálózati rendszerek sokkal nagyobb számban állnak rendelkezésre és a helyes elhelyezés is kockázatos feladat, ezért az elhelyezési feladatokat minden esetben \enquote{kézzel} megoldani jelentős kihívást tud jelenteni.
|
||||
|
||||
Megoldást jelenthet a problémára ha az egyes szolgáltatás komponenseket automatikusan tudjuk peremhálózati infrastruktúrába kihelyezni. Egy olyan ütemező algoritmusra van szükség, amely képes kiválasztani az ideális futtatási helyet a megfelelő komponenseknek és automatikusan áthelyezni (azaz ütemezni) oda. Így nincs szükség emberi beavatkozásra a megfelelő peremhálózati adatközpont kiválasztásához.
|
||||
|
||||
A dinamikus ütemezés több kérdést és problémát is felvet, hiszen nem egyértelmű, hogy melyik alkalmazás szempontjából mi számít ideális környezetnek. Illetve ha tudjuk, hogy mi számít ideális környezetnek, hogy tudjuk felmérni, hogy melyik környezet lehet ideális jelölt az alkalmazás futtatására.
|
||||
A dinamikus ütemezés több kérdést és problémát is felvet, hiszen nem egyértelmű, hogy melyik alkalmazás szempontjából mi számít ideális környezetnek. Illetve, ha tudjuk, hogy mi számít ideális környezetnek, hogy tudjuk felmérni, hogy melyik környezet lehet ideális jelölt az alkalmazás futtatására.
|
||||
|
||||
Ebben a fejezetben megvizsgálom a dinamikus áthelyezés megvalósításának lehetőségét a korábban ismertetett alkalmazásokon, illetve egy egyszerű megoldást is tervezek, amely a probléma megoldását mutatja be.
|
||||
|
||||
\section{Alkalmas felhős keretrendszer kiválasztása}
|
||||
\section{Alkalmas felhő keretrendszer kiválasztása}
|
||||
\label{sec:cloud_framework}
|
||||
|
||||
|
||||
\Aref{sec:frameworks}.\ szekcióban több keretrendszert is megvizsgáltam. Ezek közül a \textit{KubeFed}-et választottam.
|
||||
\Aref{sec:frameworks}.\ alfejezeteben több keretrendszert is megvizsgáltam. Ezek közül a \textit{KubeFed}-et választottam.
|
||||
|
||||
A kiválasztásnál elsősorban azt vettem figyelembe, hogy milyen lehetőségeket adnak az egyes keretrendszerek a szolgáltatások dinamikus átütemezésére felhő és perem, illetve perem és perem adatközpontok között.
|
||||
|
||||
A \textit{KubeFed} mellett a \textit{Kubeedge} volt a másik keretrendszer, amely ideálisnak tűnt, ám mélyebb vizsgálatot követően elvetettem. Ennek oka a korábban is ismertetett hiányosságai kezdetleges állapota volt.
|
||||
A \textit{KubeFed} mellett a \textit{Kubeedge} volt a másik keretrendszer, amely ideálisnak tűnt, ám mélyebb vizsgálatot követően elvetettem. Ennek oka a korábban is ismertetett hiányosságai és kezdetleges állapota volt.
|
||||
|
||||
Az \textit{EdgeX Foundry} és \textit{Porject EVE} használatát korán elvetettem. Tipikusan erős különbségeket feltételeznek a perem és a felhő adatközpontokkal szemben támasztott elvárásoktól. Emiatt olyan megoldásokat kínálnak, amelyek teljesen más igényeket próbálnak kielégíteni, mint amiket az én eredeti problémafelvetésem támaszt. Emiatt ezeknek a megoldásoknak a használata csak felesleges nehézségeket jelentene.
|
||||
|
||||
A megvizsgált \acrshort{paas} rendszereket azért nem szerettem volna használni, mert célom volt egy teljesen nyílt megoldás készítése, ami nyílt szoftverekre épül és nem függ egy konkrét megoldástól. Továbbá így előfizetésre se volt szükségem.
|
||||
A megvizsgált \acrshort{paas} rendszereket azért nem szerettem volna használni, mert célom volt egy teljesen nyílt megoldás készítése, ami nyílt szoftverekre épül és nem függ egy konkrét megoldástól, továbbá így előfizetésre se volt szükségem.
|
||||
|
||||
A \textit{KubeFed} saját ütemezőt nem implementál (mint ahogy egyik másik vizsgált megoldás sem). Viszont az általa megvalósított egységes vezérlő felületnek köszönhetően nagyon könnyen képesek vagyunk az egyes komponenseket adatközpontokra mozgatni, így könnyen tudunk olyan saját ütemezőt készíteni, ami megvalósítja a feladatot. Emiatt választottam ezt a keretrendszert.
|
||||
|
||||
\section{Szolgáltatás létesítés és mozgatás \textit{KubeFed} környezetben}
|
||||
|
||||
Konténerizált alkalmazás környezetben egy futó konténer mozgatása csak korlátozott értelemben lehetséges. Mivel az alkalmazás nem egy virtualizált hardveren, hanem magán a hoszt operációs rendszeren fut egy konténerizált környezetben, így nincs egyszerű arra, hogy egy alkalmazást a memória tartalmával együtt mozgassunk, úgy, hogy az egy másik hoszton ugyan úgy tudja folytatni a működését.
|
||||
Konténerizált alkalmazás környezetben egy futó konténer mozgatása csak korlátozott értelemben lehetséges. Mivel az alkalmazás nem egy virtualizált hardveren, hanem magán a hoszt operációs rendszeren fut egy konténerizált környezetben, így nincs egyszerű mód arra, hogy egy alkalmazást a memória tartalmával együtt mozgassunk, úgy, hogy az egy másik hoszton ugyanúgy tudja folytatni a működését.
|
||||
|
||||
Ezért az áthelyezés az adott konténer leállítását és egy másik hoszton (másik klaszterben) való elindítását jelenti. Ez állapotmentes szolgáltatásoknál nem jelent nagyobb problémát, hiszen nincs belső állapot amit meg kell őrizni a mozgatás során. Belső állapottal rendelkező alkalmazások esetén viszont ez komplex problémát is jelenthet akár.
|
||||
|
||||
|
|
@ -50,15 +51,15 @@ Az átterheléses mozgatás belső állapottal rendelkező alkalmazások esetén
|
|||
|
||||
Az alkalmazások leállítását és másik klaszterben való elindítását a \textit{KubeFed} teljes mértékben támogatja. Az összes federált \acrshort{api} objektum esetén lehetőséget ad arra, hogy kiválasszuk, hogy melyik klaszterben hozza létre. De még arra is lehetőséget nyújt, hogy bizonyos tulajdonságait az objektumoknak klaszterre szabva változtassuk meg.
|
||||
|
||||
Ezeknek a konstrukcióknak a segítségével az ütemező szoftvernek csak egy \acrshort{api} hívást kell intéznie a \textit{Kubernetes} \acrshort{api}-hoz és ezzel meg tudja változtatni az ütemezést. A fentebb vázolt átterheléses mozgatást magától nem tudja megvalósítani a \textit{KubeFed}, de megfelelő \acrshort{api} hívásokkal ez is megoldható.
|
||||
Ezeknek a konstrukcióknak a segítségével az ütemező szoftvernek csak egy \acrshort{api} hívást kell intéznie a \textit{Kubernetes} \acrshort{api}-hoz, és ezzel meg tudja változtatni az ütemezést. A fentebb vázolt átterheléses mozgatást magától nem tudja megvalósítani a \textit{KubeFed}, de megfelelő \acrshort{api} hívásokkal ez is megoldható.
|
||||
|
||||
\section{Alkalmazás komponensek dinamikus ütemezésének vizsgálata}
|
||||
|
||||
Egy alkalmazás komponens dinamikus ütemezésének megvalósítása nagyon sok esetben támogatást igényel az alkalmazástól. Annak eldöntése, hogy mikor ütemezzük a komponenseket, hova és mit nyerünk az ütemezéssel mind-mind az alkalmazás saját tulajdonságaitól és belső működésétől függ.
|
||||
Egy alkalmazás komponens dinamikus ütemezésének megvalósítása nagyon sok esetben támogatást igényel az alkalmazástól. Annak eldöntése, hogy mikor ütemezzük a komponenseket, hova, és mit nyerünk az ütemezéssel, mind-mind az alkalmazás saját tulajdonságaitól és belső működésétől függ.
|
||||
|
||||
Emellett a konkrét ütemezés megvalósítása is erősen függ az alkalmazás tulajdonságaitól működésétől.
|
||||
Emellett a konkrét ütemezés megvalósítása is erősen függ az alkalmazás tulajdonságaitól, működésétől.
|
||||
|
||||
A következőkben a korábban bemutatott alkalmazásokat fogom megvizsgálni abból a szempontból, hogy ezeket a problémákat, hogy lehet megoldani. Illetve milyen támogatásra van szükség az alkalmazástól.
|
||||
A következőkben a korábban bemutatott alkalmazásokat fogom megvizsgálni abból a szempontból, hogy ezeket a problémákat hogyan lehet megoldani, illetve milyen támogatásra van szükség az alkalmazástól.
|
||||
|
||||
\subsection{Intelligens madárhang felismerés}
|
||||
|
||||
|
|
@ -66,21 +67,21 @@ Ebben az alkalmazásban a peremhálózati adatközpontba egy előszűrést megva
|
|||
|
||||
Ez a komponens állapotmentes, két kérés teljesítésének eredménye egymástól teljesen független. Ennek köszönhetően könnyen skálázható több példányra, hogy képes legyen nagy mennyiségű klienst kiszolgálni. Mivel a peremhálózati adatközpontokban -- a felhőhöz képest -- általában korlátozottan állnak csak rendelkezésünkre erőforrások, ezért nem tudjuk tetszőlegesen skálázni a feldolgozó szolgáltatásunkat.
|
||||
|
||||
Előfordulhat olyan helyzet, amikor a peremhálózat kifogy a számítási kapacitásból. Ilyen esetben is szeretnénk legalább annyi terhelést megtartani a használt peremhálózati adatközpontban, amennyit az teljesíteni képes a fennmaradó terhelést pedig szeretnénk átütemezni egy másik peremhálózati adatközpontba vagy végszükségben a felhőbe. Ezzel annyi sávszélesség kihasználtságot spórolni, amennyire csak képesek vagyunk.
|
||||
Előfordulhat olyan helyzet, amikor a peremhálózat kifogy a számítási kapacitásból. Ilyen esetben is szeretnénk legalább annyi terhelést megtartani a használt peremhálózati adatközpontban, amennyit az teljesíteni képes, a fennmaradó terhelést pedig szeretnénk átütemezni egy másik peremhálózati adatközpontba vagy végszükségben a felhőbe. Ezzel annyi sávszélesség kihasználtságot lehet megtakarítani, amennyire csak képesek vagyunk.
|
||||
|
||||
\subsubsection{Ütemezési döntés meghozása}
|
||||
|
||||
Ebben az alkalmazásban azt szeretnénk megvalósítani, hogy ha egy adatközpontban fogytán van a számítási kapacitás, akkor más adatközpontokhoz tudjunk fordulni a feladataink végrehajtásával. Ebből következik, hogy szükségünk van arra, hogy mérjük egy adatközpont terheltségét.
|
||||
|
||||
A futó előszűrő szoftver komponens teljesítőképességéről egy jó jellemző a várakozási sorának hossza. \Aref{sec:prefilter_service_implementation}.\ szekcióban ismertetettek szerint a szolgáltatás fenntart egy várakozási sort, ahol a feldolgozásra váró adatokat állítja sorba. Ideális esetben, ha miden beérkező kérést időben el tud látni, akkor ennek a sornak a hossza stabil 1 körüli érték. Ha a szolgáltatás teljesítőképessége végéhez közeledik, akkor elkezdenek felgyűlni a feladatai, ezáltal a sorhossz monoton növekedésnek indul.
|
||||
A futó előszűrő szoftver komponens teljesítőképességéről egy jó jellemző a várakozási sorának hossza. \Aref{sec:prefilter_service_implementation}.\ alfejezetben ismertetettek szerint a szolgáltatás fenntart egy várakozási sort, ahol a feldolgozásra váró adatokat állítja sorba. Ideális esetben, ha miden beérkező kérést időben el tud látni, akkor ennek a sornak a hossza stabil 1 körüli érték. Ha a szolgáltatás teljesítőképessége végéhez közeledik, akkor elkezdenek felgyűlni a feladatai, ezáltal a sorhossz monoton növekedésnek indul.
|
||||
|
||||
Szükség van támogatásra az előszűrő szolgáltatástól, hogy gyűjteni tudjuk a futó szolgáltatások belső sorhosszát.
|
||||
Ahhoz, hogy gyűjteni tudjuk a futó szolgáltatások belső sorhosszát, támogatásra van szükség az előszűrő szolgáltatástól.
|
||||
|
||||
\subsubsection{Ütemezés megvalósítása}
|
||||
|
||||
Mivel az előszűrő szolgáltatás állapotmentes működést valósít meg, ezért könnyedén lehet mozgatni az egyes adatközpontok között, illetve több példányban is futtatni egyszerre.
|
||||
|
||||
Az \acrshort{iot} eszközök egy előre beállított címre küldik a hangmintákat. Ez a cím az egyes adatközpontoknál más és más lehet. Mivel a szolgáltatásokat adatközpontok között mozgatjuk, ezért szükség van támogatásra a az eszközök részéről is, hogy dinamikusan meg tudjuk változtatni a küldés célját.
|
||||
Az \acrshort{iot} eszközök egy előre beállított címre küldik a hangmintákat. Ez a cím az egyes adatközpontoknál más és más lehet. Mivel a szolgáltatásokat adatközpontok között mozgatjuk, ezért támogatásra van szükség az eszközök részéről is, hogy dinamikusan meg tudjuk változtatni a küldés célját.
|
||||
|
||||
|
||||
\subsection{Robot vezérlés}
|
||||
|
|
@ -95,9 +96,9 @@ Ha ezt ismerjük, akkor egy egyszerű minimum függvényt használva, ki tudjuk
|
|||
|
||||
\subsubsection{Ütemezés megvalósítása}
|
||||
|
||||
A vezérlést megvalósító komponens belső állapottal rendelkezik. Futás közbeni átütemezése ezért nem megvalósítható. A robotkarok mozgatása nem engedhet meg kiesést, hiszen a vezérlés elvesztése akár katasztrofális következményekkel is járhat. A belső állapottal rendelkező komponensek áthelyezése kiesés nélkül viszont komplex feladat.
|
||||
A vezérlést megvalósító komponens belső állapottal rendelkezik, futás közbeni átütemezése ezért nem megvalósítható. A robotkarok mozgatása nem engedhet meg kiesést, hiszen a vezérlés elvesztése akár katasztrofális következményekkel is járhat. A belső állapottal rendelkező komponensek áthelyezése kiesés nélkül viszont komplex feladat.
|
||||
|
||||
Mivel \aref{sec:edge_layer_plans}.\ szekcióban kikötöttük, hogy minden programnak biztonságos állapotba kell helyeznie a robotkarokat lefutása végén. Illetve ebből az ismert állapotból legyen képes megkezdeni a vezérlést, ezért lehetőségünk van arra, hogy két lefutás között helyezzük át a programot.
|
||||
Mivel \aref{sec:edge_layer_plans}.\ alfejezetben kikötöttük, hogy minden programnak biztonságos állapotba kell helyeznie a robotkarokat lefutása végén, illetve ebből az ismert állapotból legyen képes megkezdeni a vezérlést, ezért lehetőségünk van arra, hogy két lefutás között helyezzük át a programot.
|
||||
|
||||
Az áthelyezés így jelentősen leegyszerűsödik, hiszen csak arra van szükség, hogy a vezérlő komponenseket a megfelelő adatközpontban indítsuk el.
|
||||
|
||||
|
|
@ -106,7 +107,7 @@ A vezérlést megvalósító szolgáltatás komponensek indításáért ebben az
|
|||
|
||||
\section{Ütemező rendszer}
|
||||
|
||||
Bár a két alkalmazás működése és igényei jelentősen eltérnek, szerettem volna egy olyan rendszert megalkotni, aminek segítségével mindkét alkalmazás ütemezése megoldható.
|
||||
Bár a két alkalmazás működése és igényei jelentősen eltérnek, szerettem volna egy olyan rendszert megalkotni, amelynek segítségével mindkét alkalmazás ütemezése megoldható.
|
||||
|
||||
\subsection{Metrikák gyűjtése és felhasználása}
|
||||
|
||||
|
|
|
|||
|
|
@ -97,33 +97,33 @@ A klasztereknek és klienseknek természetesen nem csak egymással kell tudniuk
|
|||
|
||||
\subsection{Virtuális gépek és hálózat}
|
||||
|
||||
A környezetet alkotó virtuális gépek futtatása nem függ egy konkrét virtualizációs platform implementációtól. Az egyetlen elvárás azzal szemben, hogy képes legyen virtuális gépeket és virtuális hálózatokat létrehozni és futtatni.
|
||||
A környezetet alkotó virtuális gépek futtatása nem függ egy konkrét virtualizációs platform implementációtól. Az egyetlen elvárás, hogy képes legyen virtuális gépeket és virtuális hálózatokat létrehozni és futtatni.
|
||||
|
||||
A virtuális gépek futtatásához \textit{libvirt}\footnote{\url{https://libvirt.org/}} környezetet használtam.
|
||||
|
||||
A \textit{libvirt} számára \acrshort{xml} formátumban lehet definiálni a virtuális gépeket és virtuális hálózatokat \cite{libvirt_xml}. A felépítés ezen lépésének automatizálására írtam egy egyszerű \gls{python} szkriptet, amely ilyen \acrshort{xml} definíciókat generál. Ezek importálásával \textit{libvirt}be, a virtuális gépek és a hálózati infrastruktúra készen állt.
|
||||
A \textit{libvirt} számára \acrshort{xml} formátumban lehet definiálni a virtuális gépeket és virtuális hálózatokat \cite{libvirt_xml}. A felépítés ezen lépésének automatizálására írtam egy egyszerű \gls{python} szkriptet, ami ilyen \acrshort{xml} definíciókat generál. Ezek \textit{libvirt}be importálásával a virtuális gépek és a hálózati infrastruktúra készen állt.
|
||||
|
||||
Négy virtuális hálózatot hoztam létre, ezeket \texttt{cloud}, \texttt{edge-1}, \texttt{edge-2} és \texttt{client}-nek neveztem el attól függően, hogy melyik virtuális gépeket szolgálja ki. Az útválasztó kivételével minden virtuális gépnek egy interfésze van, amely az adott hálózatra van csatlakoztatva. Az útválasztónak mind a négy hálózatba van interfésze. A hoszt által biztosított átjáró minden hálózatban jelen van. Az ide irányuló forgalom hálózati címfordítás segítségével a gazdagép címére fordul, így a virtuális gépek elérik az internetet is.
|
||||
Négy virtuális hálózatot hoztam létre, ezeket \texttt{cloud}, \texttt{edge-1}, \texttt{edge-2} és \texttt{client}-nek neveztem el, attól függően, hogy melyik virtuális gépeket szolgálják ki. Az útválasztó kivételével minden virtuális gépnek egy interfésze van, amely az adott hálózatra van csatlakoztatva. Az útválasztónak mind a négy hálózatban van interfésze. A hoszt által biztosított átjáró minden hálózatban jelen van. Az ide irányuló forgalom hálózati címfordítás segítségével a gazdagép címére fordul, így a virtuális gépek elérik az internetet is.
|
||||
|
||||
\subsection{Operációs rendszer konfigurációja}
|
||||
|
||||
|
||||
Mivel a környezet 11 virtuális gépből áll, ezért ezeknek egyenként \enquote{kézzel} való telepítése időigényes lenne és könnyen lehetne hibát ejteni benne, amelynek megkeresése és javítása további időt igényelne.
|
||||
Mivel a környezet 11 virtuális gépből áll, ezért ezeknek egyenként \enquote{kézzel} való telepítése időigényes lenne és könnyen lehetne hibát ejteni benne, aminek a megkeresése és javítása további időt igényelne.
|
||||
|
||||
Ezért a virtuális gépek telepítésére és alapvető konfigurációjának elvégzésére is automatizációs eszközöket használtam.
|
||||
|
||||
Az operációs rendszer telepítése helyett inkább egy előre elkészített képfájlból dolgoztam. Az általam használt képfájl \textit{Ubuntu} \gls{linux} disztribúciót tartalmaz. A képfájlon előre fel van telepítve a \textit{Cloud Init}\footnote{\url{https://cloud-init.io/}} nevű eszköz, amely rendszer indulás közben elvégzi az operációs rendszer alapvető konfigurációját. Ilyen a gép hosztneve, (egyszerűsített) hálózati konfigurációja, és az \acrfull{ssh} kapcsolaton való bejelentkezéshez szükséges publikus kulcsok telepítése.
|
||||
Az operációs rendszer telepítése helyett inkább egy előre elkészített képfájlból dolgoztam. Az általam használt képfájl \textit{Ubuntu} \gls{linux} disztribúciót tartalmaz. A képfájlon előre fel van telepítve a \textit{Cloud Init}\footnote{\url{https://cloud-init.io/}} nevű eszköz, ami rendszer indulás közben elvégzi az operációs rendszer alapvető konfigurációját. Ilyen a gép hosztneve, (egyszerűsített) hálózati konfigurációja, és az \acrfull{ssh} kapcsolaton való bejelentkezéshez szükséges publikus kulcsok telepítése.
|
||||
|
||||
A \textit{Cloud Init} az egyedi konfigurációt egy második lemez képfájlról tölti be. A lemez képfájlok elkészítésére írtam egy egyszerű \gls{python} szkriptet.
|
||||
|
||||
Mivel a \textit{Cloud Init} csak az alapvető rendszer konfigurációt hajtja végre, ezért a komplexebb/specifikus konfigurációk elvégzésére egy másik eszközt használtam. A \textit{Cloud Init} egy olyan működő konfiguráció állít be a virtuális gépen, amely lehetővé teszi, hogy be tudjunk arra jelentkezni \acrshort{ssh} kapcsolaton keresztül. Az \acrshort{ssh} kapcsolat tökéletesen megfelel arra, hogy \textit{Ansible}\footnote{\url{https://www.ansible.com/}} konfiguráció menedzsment eszközt használjunk.
|
||||
Mivel a \textit{Cloud Init} csak az alapvető rendszer konfigurációt hajtja végre, ezért a komplexebb/specifikus konfigurációk elvégzésére egy másik eszközt használtam. A \textit{Cloud Init} egy olyan működő konfiguráció állít be a virtuális gépen, amely lehetővé teszi, hogy be tudjunk arra jelentkezni \acrshort{ssh} kapcsolaton keresztül. Az \acrshort{ssh} kapcsolat alkalmas arra, hogy \textit{Ansible}\footnote{\url{https://www.ansible.com/}} konfiguráció menedzsment eszközt használjunk.
|
||||
|
||||
Az \textit{Ansible} egy deklaratív konfiguráció kezelő eszköz \cite{ansible_docs}. Az elvárt állapotot írjuk le, amelyhez az \textit{Ansible} automatikusan igazítani fogja a konfigurációs beállításokat az operációs rendszeren. Futás közben \acrshort{ssh} protokollon keresztül csatlakozik a konfigurálni kívánt hosztokra. Majd ellenőrzi, hogy minden beállítás egyezik-e az általunk elvárt állapottal. Ha valamelyik konfiguráció eltér, akkor azt automatikusan beállítja az elvárt állapotra.
|
||||
Az \textit{Ansible} egy deklaratív konfiguráció kezelő eszköz \cite{ansible_docs}, vagyis az elvárt állapotot írjuk le, amelyhez az \textit{Ansible} automatikusan igazítani fogja a konfigurációs beállításokat az operációs rendszeren. Futás közben \acrshort{ssh} protokollon keresztül csatlakozik a konfigurálni kívánt hosztokra, majd ellenőrzi, hogy minden beállítás egyezik-e az általunk elvárt állapottal. Ha valamelyik konfiguráció eltér, akkor azt automatikusan beállítja az elvárt állapotra.
|
||||
|
||||
|
||||
\textit{Ansible} segítségével, letöröltem felesleges szoftver komponenseket, feltelepítettem szükségeseket és beállítottam a végleges hálózati konfigurációt.
|
||||
\textit{Ansible} segítségével letöröltem a felesleges szoftver komponenseket, feltelepítettem a szükségeseket és beállítottam a végleges hálózati konfigurációt.
|
||||
|
||||
Annak érdekében, hogy a virtuális gépek az alhálózatok közti forgalmat a virtuális útválasztón keresztül küldjék, a többi forgalmat pedig a gazdagép átjáróján keresztül, statikus útválasztó tábla bejegyzéseket vettem fel minden gépen. Ahol minden gépen a többi alhálózathoz az átjáró a virtuális útválasztó, az alapértelmezett pedig a gazdagép átjárója.
|
||||
Annak érdekében, hogy a virtuális gépek az alhálózatok közti forgalmat a virtuális útválasztón keresztül küldjék, a többi forgalmat pedig a gazdagép átjáróján keresztül, statikus útválasztó tábla bejegyzéseket vettem fel minden gépen. A bejegyzések alapján minden gépen a többi alhálózathoz az átjáró a virtuális útválasztó, az alapértelmezett pedig a gazdagép átjárója.
|
||||
|
||||
|
||||
\subsection{\textit{Kubernetes} telepítése}
|
||||
|
|
@ -132,12 +132,12 @@ A \textit{KubeFed} használatához először szükség van arra, hogy legyenek m
|
|||
|
||||
Egy \textit{Kubernetes} klaszter telepítésére több lehetőségünk is van. Rendelkezésünkre állnak disztribúciók, amelyek minimális konfigurációval egy teljes értékű klasztert képesek telepíteni. A telepítéshez a \textit{Kubespary}\footnote{\url{https://kubespray.io/}} disztribúciót használtam.
|
||||
|
||||
A \textit{Kubespray} alapvető konfigurációjában csak keveset módosítottam. Úgy állítottam be, hogy a három virtuális gépből egyet jelöljön ki \texttt{master} szerepre kettőt pedig \texttt{worker} szerepre. A Kubernetes telepítését egyenként végeztem el mindhárom klaszterre.
|
||||
A \textit{Kubespray} alapvető konfigurációjában csak keveset módosítottam. Úgy állítottam be, hogy a három virtuális gépből egyet jelöljön ki \texttt{master} szerepre, kettőt pedig \texttt{worker} szerepre. A Kubernetes telepítését egyenként végeztem el mindhárom klaszterre.
|
||||
|
||||
Sikeres telepítés után néhány alapvető komponenst szintén kézzel, \textit{Helm}\footnote{\url{https://helm.sh/}} segítségével telepítettem:
|
||||
\begin{itemize}
|
||||
\item A perzisztens tárhely kezeléshez \textit{Longhorn}\footnote{\url{https://longhorn.io/}} \textit{Storage Class}-t telepítettem. A \textit{Longhorn} nem igényli külső adat tároló szerverek használatát, a \textit{Kubernetes} klasztert alkotó gépek saját tárhelyét használja.
|
||||
\item A beérkező \acrshort{http} kérések fogadására, kezelésére és megfelelő mikroszolgáltatásokhoz irányítására \textit{Nginx}\footnote{\url{https://kubernetes.github.io/ingress-nginx/}} \textit{Ingress Controller}-t telepítettem. Ennek segítségével mikroszolgáltatások halmazával megvalósított szolgáltatás egy egységes \acrshort{http} interfészen érhetőek el.
|
||||
\item A beérkező \acrshort{http} kérések fogadására, kezelésére és megfelelő mikroszolgáltatásokhoz irányítására \textit{Nginx}\footnote{\url{https://kubernetes.github.io/ingress-nginx/}} \textit{Ingress Controller}-t telepítettem. Ennek segítségével mikroszolgáltatások halmazával megvalósított szolgáltatás egy egységes \acrshort{http} interfészen érhető el.
|
||||
\end{itemize}
|
||||
|
||||
|
||||
|
|
@ -151,9 +151,9 @@ Ezek után lehetőségem volt egyenként ki és be kapcsolni a \textit{KubeFed}
|
|||
|
||||
\section{Erőforrás igények}
|
||||
|
||||
Bár a rendszer erőforrás igénye nagyban függ a telepített alkalmazásoktól. Maga a környezet telepítése és futtatása is igényel valamennyi erőforrást.
|
||||
Bár a rendszer erőforrás igénye nagyban függ a telepített alkalmazásoktól, maga a környezet telepítése és futtatása is igényel valamennyi erőforrást.
|
||||
|
||||
\textit{Kubernetes} futtatásához, minden virtuális gépnek legalább 2 Gigabyte rendszer memória szükséges és két processzor mag \cite{kubernetes_docs}. Tapasztalataim viszont azt mutatják, hogy ez néha túl kevés tud lenni és különböző teljesítménybeli problémákba tudunk ütközni, ezért a \textit{Kubernetes}-t futtató virtuális gépeknek ajánlott legalább 4 Gigabyte memória allokálása.
|
||||
\textit{Kubernetes} futtatásához minden virtuális gépnek legalább 2 Gigabyte rendszer memória szükséges és két processzor mag \cite{kubernetes_docs}. Tapasztalataim viszont azt mutatják, hogy ez néha túl kevés tud lenni és különböző teljesítménybeli problémákba tudunk ütközni, ezért a \textit{Kubernetes}-t futtató virtuális gépeknek ajánlott legalább 4 Gigabyte memória allokálása.
|
||||
|
||||
Az útválasztó gépnek nincs szüksége sok memóriára a csomagok továbbítására, amíg nem használjuk másra, addig 512 Megabyte memória megfelel neki.
|
||||
|
||||
|
|
@ -163,21 +163,21 @@ A kliensek száma és erőforrás igénye teljesen a használt alkalmazástól f
|
|||
|
||||
Processzor tekintetében nem fedeztem fel különösen nagy elvárásokat. Tapasztalataim szerint a rendszer stabilan működött egy 2011-ben gyártott négymagos \textit{Intel}\textregistered \textit{Core}\texttrademark i7-3770 processzoron.
|
||||
|
||||
A lemez elérések teljesítménye viszont egy jelentős tényező volt a rendszer teljesítménye szempontjából. A környezet önmagában stabilan üzemelt egy \acrshort{raid}5 tömbre telepítve, amelyet 8 darab 15.000 percenkénti fordulatú hagyományos mechanikus diszk alkotott. Viszont amint feltelepítettem a tesztelésre szánt alkalmazásokat a tárhely elérési késleltetés jelentősen megnőtt olyan mértékekig amik az alkalmazás instabil működését és átmeneti összeomlását okozták. Ezért mindenképpen ajánlott ilyen rendszert \acrshort{ssd} lemezekből álló tárhely tömbre telepíteni.
|
||||
A lemez elérések teljesítménye viszont jelentős tényező volt a rendszer teljesítménye szempontjából. A környezet önmagában stabilan üzemelt egy \acrshort{raid}5 tömbre telepítve, amelyet 8 darab 15.000 percenkénti fordulatú hagyományos mechanikus diszk alkotott. Viszont amint feltelepítettem a tesztelésre szánt alkalmazásokat, a tárhely elérési késleltetés jelentősen megnőtt olyan mértékekig, ami az alkalmazás instabil működését és átmeneti összeomlását okozták. Ezért mindenképpen ajánlott ilyen rendszert \acrshort{ssd} lemezekből álló tárhely tömbre telepíteni.
|
||||
|
||||
|
||||
\section{Környezet alkalmazása}
|
||||
|
||||
A tesztkörnyezetnek egyik fontos célja, hogy különböző hálózati paramétereket tudjon szimulálni. Ennek megvalósításáért a virtuális útválasztó felel.
|
||||
|
||||
A szükséges hálózati funkciókat implementálja a \gls{linux} kernel. Ezért a virtuális gépen is ugyanolyan \textit{Ubuntu} operációs rendszer fut, mint a többin a környezetben. A virtuális gépen bekonfigurálásra kerültek a megfelelő útválasztó táblák és engedélyezve lett rajta az útválasztó funkcionalitás. Ennyi elég ahhoz, hogy működő kapcsolatot létesítsen az egyes alhálózatok között.
|
||||
A szükséges hálózati funkciókat implementálja a \gls{linux} kernel, ezért a virtuális gépen is ugyanolyan \textit{Ubuntu} operációs rendszer fut, mint a többin a környezetben. A virtuális gépen bekonfigurálásra kerültek a megfelelő útválasztó táblák és engedélyezve lett rajta az útválasztó funkcionalitás. Ennyi elég ahhoz, hogy működő kapcsolatot létesítsen az egyes alhálózatok között.
|
||||
|
||||
A hálózati kondíciók szimulálásához a kernelbe \textit{Traffic Control} képességek tökéletesen használhatóak. A \textit{Traffic Control} a következő részekből áll \cite{man_tc}:
|
||||
A hálózati kondíciók szimulálásához a kernel \textit{Traffic Control} képessége tökéletesen használható. A \textit{Traffic Control} a következő részekből áll \cite{man_tc}:
|
||||
\begin{itemize}
|
||||
\item \textbf{Shaping} (formálás): Interfészről kimenő csomagok rátájának szabályozása. Nem csak sávszélesség szabályozásra alkalmas. Használható például az egyenetlen adatforgalom simítására is.
|
||||
\item \textbf{Scheduling} (ütemezés): A csomagok küldésének idejét ütemezhetjük vele, alkalmas arra, hogy például késleltetést szimuláljunk. Csak kimenő csomagokra alkalmazható.
|
||||
\item \textbf{Policing} (rendészet): Hasonló a formáláshoz, viszont a kimenő csomagok helyett a beérkezőkre vonatkozik.
|
||||
\item \textbf{Dropping} (ejtés): Bizonyos szabályok alapján eldobhatunk csomagokat amelyek meghaladnak sávszélességi korlátokat. Ez mind a bejövő mind a kimenő forgalomra alkalmazható.
|
||||
\item \textbf{Policing} (szabályozás): Hasonló a formáláshoz, viszont a kimenő csomagok helyett a beérkezőkre vonatkozik.
|
||||
\item \textbf{Dropping} (eldobás): Bizonyos szabályok alapján eldobhatunk csomagokat amelyek meghaladnak sávszélességi korlátokat. Ez mind a bejövő mind a kimenő forgalomra alkalmazható.
|
||||
\end{itemize}
|
||||
|
||||
A kernelben lévő \textit{Traffic Control} konfigurálásához a \texttt{tc} nevű felhasználói módú eszközt tudjuk használni. A használatára egy példát mutat be \aref{ex:tc}.\ kódrészlet.
|
||||
|
|
|
|||
Loading…
Reference in New Issue