|
|
|
|
@ -45,11 +45,11 @@ A teszt infrastruktúrát két szempontból bontottam fel: az egyik az előbb em
|
|
|
|
|
|
|
|
|
|
\subsubsection{Futtató környezet}
|
|
|
|
|
|
|
|
|
|
A környezetben szükség van a választott alkalmazás futtató keretrendszer (esetünkben \textit{Kubedfed}) futtatására. A \textit{Kubefed} lényegében több \textit{Kubernetes} klaszter fölé húzott közös vezérlési réteg. Ennek megfelelően virtuális gépeket csoportokra bontottam, adott csoportok egy-egy \textit{Kubernetes} klasztert valósítanak meg.
|
|
|
|
|
A környezetben szükség van a választott alkalmazás futtató keretrendszer (esetünkben \textit{KubeFed}) futtatására. A \textit{KubeFed} lényegében több \textit{Kubernetes} klaszter fölé húzott közös vezérlési réteg. Ennek megfelelően virtuális gépeket csoportokra bontottam, adott csoportok egy-egy \textit{Kubernetes} klasztert valósítanak meg.
|
|
|
|
|
|
|
|
|
|
Az egyes \textit{Kubernetes} klaszterek esetünkben az egyes adatközpontokat szimbolizálják. Egy ilyen klaszter jelöli a felhő adatközpontot, a többi klaszter pedig jelölheti a peremhálózati adatközpontokat vagy akár további felhőket is. A tesztelendő alkalmazások szempontjából, nincs számottevő különbség egy felhő vagy egy peremhálózati adatközpont belső működésében, ezért itt főképp csak az elnevezésükben térnek el.
|
|
|
|
|
|
|
|
|
|
Az önálló \textit{Kubernetes} klaszterek fölé már lehet \textit{Kubefed} környezetet telepíteni. A telepített \textit{Kubefed} szoftver megfelelően modellezi a valós környezetben használt futtató környezetet, hiszen ugyanaz a szoftver. Telepítése és üzemeltetése között nincs különbség a valós és teszt környezetben.
|
|
|
|
|
Az önálló \textit{Kubernetes} klaszterek fölé már lehet \textit{KubeFed} környezetet telepíteni. A telepített \textit{KubeFed} szoftver megfelelően modellezi a valós környezetben használt futtató környezetet, hiszen ugyanaz a szoftver. Telepítése és üzemeltetése között nincs különbség a valós és teszt környezetben.
|
|
|
|
|
|
|
|
|
|
\subsubsection{Kliens}
|
|
|
|
|
|
|
|
|
|
@ -91,28 +91,97 @@ A munka során a terveim alapján konkrétan megvalósított környezetem három
|
|
|
|
|
\label{fig:birb_edgemu_architecture}
|
|
|
|
|
\end{figure}
|
|
|
|
|
|
|
|
|
|
A \textit{Kubefed} federáció tagjai a \texttt{cloud}, \texttt{edge-1} és \texttt{edge-2} nevű klaszterek. Ezek közül a \texttt{cloud} nevű klaszter a federációt vezérlő klaszter.
|
|
|
|
|
A \textit{KubeFed} federáció tagjai a \texttt{cloud}, \texttt{edge-1} és \texttt{edge-2} nevű klaszterek. Ezek közül a \texttt{cloud} nevű klaszter a federációt vezérlő klaszter.
|
|
|
|
|
|
|
|
|
|
A klasztereknek és klienseknek természetesen nem csak egymással kell tudniuk kommunikálni. Előfordulhat, hogy szükségük van arra, hogy elérjék a publikus internetet is (például szoftverfrissítés letöltésére). Az ilyen típusú forgalom nem kívánatos a virtuális útválasztón. Mivel a környezetben csak a klaszterek és a kliensek közötti forgalom paramétereit szeretnénk befolyásolni, ezért felesleges a nem arra irányuló forgalom átvezetése. Emellett az extra forgalom bizonyos szélsőséges helyzetekben befolyásolhatja a mérési eredményeket is. Ennek megoldására minden alhálózatban két átjáró van, az egyik a virtuális útválasztó a másik a virtuális környezet által biztosított átjáró amelyen keresztül el lehet érni a publikus internetet.
|
|
|
|
|
|
|
|
|
|
\subsection{Virtuális gépek és hálózat}
|
|
|
|
|
% cloudinit
|
|
|
|
|
|
|
|
|
|
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 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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
\subsection{Operációs rendszer konfigurációja}
|
|
|
|
|
|
|
|
|
|
% leírni mindhárom classt: kliens-emu, router, kubememe memeber
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\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.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{\textit{Kubernetes} telepítése}
|
|
|
|
|
|
|
|
|
|
A \textit{KubeFed} használatához először szükség van arra, hogy legyenek működő \textit{Kubernetes} klasztereink, amelyeket federálni tudunk \cite{installing_kubefed}.
|
|
|
|
|
|
|
|
|
|
% Nginx ingress controller
|
|
|
|
|
% Longhorn storage class
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
\subsection{\textit{Kubefed} telepítése}
|
|
|
|
|
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.
|
|
|
|
|
\end{itemize}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{\textit{KubeFed} telepítése}
|
|
|
|
|
|
|
|
|
|
A \textit{KubeFed} telepítéséhez követtem annak dokumentációját. A telepítés csak pár lépésből állt.
|
|
|
|
|
|
|
|
|
|
Első lépésként a \textit{Helm} segítségével telepítettem a \textit{KubeFed} vezérlését megvalósító komponenseket a \texttt{cloud} nevű klaszterbe. Ezek után a letöltöttem a \texttt{kubefedctl} nevű parancssoros alkalmazást, amely segítségével beléptettem mindhárom klasztert a federációba\footnote{A vezérlő klasztert is be kell léptetni annak érdekében, hogy a \textit{KubeFed} oda is ütemezzen alkalmazás komponenseket}. Ezek után lekérdeztem a klaszterek állapotát reprezentáló \acrshort{api} objektumot a \textit{Kubernetes} \acrshort{api} interfészén, ez megerősítette, hogy a federáció vezérlő mindhárom \textit{Kubernetes} klasztert eléri és tudja kezelni.
|
|
|
|
|
|
|
|
|
|
Ezek után lehetőségem volt egyenként ki és be kapcsolni a \textit{KubeFed} által federált objektumok használatát, mint a federált névterek, federált konfigurációk vagy éppen federált \textit{deployment}-ek.
|
|
|
|
|
|
|
|
|
|
\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.
|
|
|
|
|
|
|
|
|
|
\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.
|
|
|
|
|
|
|
|
|
|
Elmondható ezek alapján, hogy a tesztkörnyezet futtatásához legalább 36.5 Gigabyte memóriára van szükség, ha a klienseket nem számoljuk.
|
|
|
|
|
|
|
|
|
|
A kliensek száma és erőforrás igénye teljesen a használt alkalmazástól függ. Itt ezért kezdetben 2 Gigabyte memóriát allokáltam, majd később kibővítettem, amikor szükség volt rá.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Környezet alkalmazása}
|
|
|
|
|
|
|
|
|
|
% tc tutorial basically
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
%\section{Környezet értékelése}
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
% fogom a pontokat a célokból és elmondom, hogy mindet tök királyul teljesítettem.
|
|
|
|
|
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}:
|
|
|
|
|
\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ó.
|
|
|
|
|
\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.
|
|
|
|
|
|
|
|
|
|
\begin{lstlisting}[float=!ht,caption={10ms késleltetés konfigurálása egy interfészre \texttt{tc} használatával},label=ex:tc]
|
|
|
|
|
tc qdisc add dev enp1s0f2 root netem delay 10ms
|
|
|
|
|
\end{lstlisting}
|
|
|
|
|
|
