2021-12-18 22:01:23 +01:00
parent 762bffe668
commit 4652dc8f49
8 changed files with 110 additions and 21 deletions
							
							
								
							
							
						
@@ -28,7 +28,7 @@ Az \textit{EdgeX Foundry} és \textit{Porject EVE} használatát korán elvetett
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.
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 és azt, hogy saját ütemezőt készítek.
\section{Szolgáltatás létesítés és mozgatás \textit{KubeFed} környezetben}
							
								
							
							
								
							
							
						
@@ -104,6 +104,7 @@ Az áthelyezés így jelentősen leegyszerűsödik, hiszen csak arra van szüks
A vezérlést megvalósító szolgáltatás komponensek indításáért ebben az alkalmazásban külön szolgáltatás felel, ezért ez az a szoftverkomponens, amelynek támogatnia kell a dinamikus ütemezési döntések alkalmazását. 
\section{Ütemező rendszer}
\label{sec:scheduler}
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ó. A szoftver tervezése során figyelembe vettem azokat a közös funkcionalitásokat, amelyeket mindkét alkalmazás egyformán használ. Emellett szétválasztottam azokat a komponenseket, amelyek alkalmazás specifikus funkciót valósítanak meg.
							
								
							
							
								
							
							
						
@@ -215,3 +216,9 @@ Szerettem volna egy olyan megoldást készíteni, amely nem csak az adatközpont
Ezt úgy oldottam meg, hogy felkonfiguráltam egy egyszerű webszerver konténert, amely minden kérésre egyből egy üres válasszal válaszol. Ezt a konténert \textit{KubeFed} segítségével úgy futtattam, mint bármelyik másik szolgáltatást minden adatközpontban. Ezt a szolgáltatást kiajánlottam minden adatközpont publikus címére. A szkriptem pedig a \acrshort{http} kérés körülfordulási idejét méri.
Az így mért értékeket az ütemező fel tudja használni arra, hogy eldöntse, hogy melyik adatközpontra ütemezze be a robotkarok vezérléséhez szükséges szolgáltatást.
\subsection{Robotkarok vezérlésének átalakítása}
A robotkarok vezérlését megvalósító komponens a \textit{Kubernetes} \acrshort{api} interfészét használva indítja el \textit{KubeFed} segítségével az egyes \textit{programok} végrehajtását végző szolgáltatásokat. Ahhoz, hogy ezeket a szolgáltatásokat dinamikusan a legideálisabb környezetben indítsa el, arra van szükség, hogy szolgáltatás indítása előtt lekérje a \textit{Mérés kezelő} szolgáltatásból az egyes adatközpontok felé a cél telephely késleltetését, ezután pedig kiválassza azt, ahol legkisebb a késleltetés. 
A viselkedés implementálása egy \acrshort{http} \acrshort{api} hívást igényelt csak, közvetlenül az ütemezés kezdete előtt. Ezzel lekérte a szolgáltatásból a linkek késleltetésének középértékét az elmúlt két percre vetítve. Ezután egy minimum függvénnyel meghatározható volt, hogy melyik adatközpontban kerüljön ütemezésre a szolgáltatás.