Added Markosz revision

src/content/scheduling.tex

@@ -97,7 +97,7 @@ Ha ezt ismerjük, akkor egy egyszerű minimum függvényt használva, ki tudjuk
 
 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}.\ 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. 
+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 kezdje meg 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.
 
@@ -110,36 +110,36 @@ Bár a két alkalmazás működése és igényei jelentősen eltérnek, szerette
 
 \subsection{Metrikák gyűjtése és kiértékelése}
 
-Mindkét alkalmazásban közös, hogy az ütemezési döntéseket az alakhamzásból gyűjtött metrikákra. Ezek a metrikák bár eltérő tulajdonságokat írnak le, gyűjtésük és kiértékelésük szempontjából nem különböznek egymástól.
+Mindkét alkalmazásban közös, hogy az ütemezési döntéseket az alakhamzásból gyűjtött metrikákra alapozza. Ezek a metrikák, bár eltérő tulajdonságokat írnak le, gyűjtésük és kiértékelésük szempontjából nem különböznek egymástól.
 
 A gyűjtött metrikák minden esetben idősoros adatként kezelhetőek. Az idősoros adatok olyan mérések, amelyek meghatározott időközönként rögzítésre kerülnek. Egy rögzített adatpont mindig időhöz kötötten reprezentálja a megfigyelt pillanatnyi állapotot \cite{timeseries_basics}. Az alkalmazásaink állapotát idősoros adatként gyűjtve képesek vagyunk a döntési logika felépítésénél többfajta statisztikai kiértékelést is a döntések alapjául venni.
 
-A metrikák gyűjtésére és kiértékelésére így egy központi megoldást terveztem. Gyűjtés során az egyes alkalmazás komponensek vagy mérő szoftverek elküldik a központi rendszerbe, amely idősorosan tárolja az adatokat. Ha egy ütemezési döntést végző szolgáltatásnak szüksége van arra, hogy a rögzített adatokon készített kiértékelést használja (például átlagolt értéket egy meghatározott idősávra), akkor innen le tudja kérni.
+A metrikák gyűjtésére és kiértékelésére így egy központi megoldást terveztem. Gyűjtés során az egyes alkalmazás komponensek vagy mérő szoftverek elküldik a központi rendszerbe, amely idősorosan tárolja az adatokat. Ha egy ütemezési döntést végző szolgáltatásnak szüksége van arra, hogy a rögzített adatokon készített kiértékelést használja (például átlagolt értéket egy meghatározott időtartamra), akkor innen le tudja kérni.
 
-Ezt a szolgáltatás mindkét alkalmazás egyformán tudja használni.
+Ezt a szolgáltatást mindkét alkalmazás egyformán tudja használni.
 
 \subsection{Ütemezési algoritmus}
 \label{sec:scheduling-algo}
 
-Bár a robotkarokat vezérlő alkalmazásnál az ütemezést megvalósító algoritmus meghatározott fix időpontokban egy egyszerű minimum keresés a madárhang felismerő rendszer esetén ennél összetettebb megoldásra van szükség. 
+Bár a robotkarokat vezérlő alkalmazásnál az ütemezést megvalósító algoritmus meghatározott fix időpontokban egy egyszerű minimum keresés a madárhang felismerő rendszer esetén, ennél összetettebb megoldásra van szükség. 
 
-Ebben az esetben nem csak a konténerek ütemezésére van szükség az egyes adatközpontok között, hanem arra is, hogy az \acrshort{iot} eszközök konfigurációját is frissítsük. Emellett az ütemezési események generálása sem előre meghatározott. Az algoritmusnak folyamatosan figyelnie kell a rendszer állapotát és szükség esetén be kell tudnia avatkozni.
+Ebben az esetben nem csak a konténerek ütemezésére van szükség az egyes adatközpontok között, hanem arra is, hogy az \acrshort{iot} eszközök konfigurációját is frissítsem. Emellett az ütemezési események generálása sem előre meghatározott. Az algoritmusnak folyamatosan figyelnie kell a rendszer állapotát és szükség esetén be kell tudnia avatkozni.
 
-Egy ilyen viselkedést megvalósító naiv algoritmust terveztem, amely a próbálgatás módszerével keres egy megfelelő eloszlást a szolgáltatásoknak a peremhálózati adatközpontok és a felhő között és az ezekhez kapcsolódó \acrshort{iot} eszközök között.
+Egy ilyen viselkedést megvalósító naiv algoritmust terveztem, amely a próbálgatás módszerével keresi a szolgáltatások megfelelő elosztását a peremhálózati adatközpontok és a felhő között, és az ezekhez kapcsolódó \acrshort{iot} eszközök között.
 
 Ahhoz, hogy a folyamatos felügyelet megvalósuljon, egy periodikusan futó algoritmust terveztem, amely rögzített időközönként felméri a rendszer állapotát és szükség esetén képes szolgáltatásokat mozgatni és konfigurációt frissíteni az eszközökön. 
 
-Az algoritmus periodikus futása során fel kell tudnia mérni, ha kedvezőtlen rendszer állapot áll fenn és döntést kell hoznia annak megoldása érdekében. A madárhang elemző rendszer esetében ilyen kedvezőtlen állapot ha a komponensek belső sorhossza monoton növekedésnek indul. Ilyen helyzetben a rendszer működése instabil. Stabilnak azt az állapotot tekinthetjük ha a sorhossz csökken, vagy konstans értékhez közelít.
+Az algoritmus periodikus futása során fel kell tudnia mérni, ha kedvezőtlen rendszer állapot áll fenn és döntést kell hoznia annak megoldása érdekében. A madárhang elemző rendszer esetében ilyen kedvezőtlen állapot, ha a komponensek belső sorhossza monoton növekedésnek indul. Ilyen helyzetben a rendszer működése instabil. Stabilnak azt az állapotot tekinthetjük, amikor a sorhossz csökken, vagy konstans értékhez közelít.
 
-A sorhossz növekedésének detektálásához kihasználtam az idősoros adatokon végezhető kiértékelési lehetőségeket. Az algoritmus periodikus futása során az elmúlt időszak (konfigurálható időre visszamenően) deriváltját kérdezi le. Ebből adódóan, ha a derivált értéke nagyobb mint 0 akkor feltételezhető az instabil állapot, 0 és annál kisebb értékek esetén a rendszer stabilnak mondható.
+A sorhossz növekedésének detektálásához kihasználtam az idősoros adatokon végezhető kiértékelési lehetőségeket. Az algoritmus periodikus futása során az elmúlt időszak (konfigurálható időre visszamenően) deriváltját kérdezi le. Ebből adódóan, ha a derivált értéke nagyobb mint 0, akkor feltételezhető az instabil állapot, 0 és annál kisebb értékek esetén a rendszer stabilnak mondható.
 
-Ha az algoritmus többszöri futás esetén is nullánál nagyobb értéket kap a sorhossz deriváltjára, akkor megkezdi a javító folyamatot. Ez a folyamat egy eszköz által küldött adatokat irányítja át másik felhőbe. Mielőtt frissíti az eszköz konfigurációját ellenőrzi hogy az új cél-adatközpontban fut-e a szolgáltatás egy példánya. Ha nem akkor előbb elindítja azt és miután az készen áll az adatok fogadására csak akkor ütemezi át a a küldést.
+Ha az algoritmus többszöri futás esetén is nullánál nagyobb értéket kap a sorhossz deriváltjára, akkor megkezdi a javító folyamatot. Ez a folyamat egy kiválasztott eszköz által küldött adatokat irányítja át másik felhőbe. Mielőtt frissíti az eszköz konfigurációját, ellenőrzi hogy az új cél-adatközpontban fut-e a szolgáltatás egy példánya. Ha nem, akkor előbb elindítja azt, és miután az készen áll az adatok fogadására, csak akkor ütemezi át a a küldést.
 
-Ez a viselkedés hasonlít a korában ismertetett átterheléses mozgatásra. Azaz ha mozgatni kell, akkor csak azután teszi meg, hogy az \enquote{új} szolgáltatás készen áll, ez idő alatt a \enquote{régi} szolgáltatás dolgozza fel a kéréseket, így kiesés nélkül vihető véghez a szolgáltatások mozgatása.
+Ez a viselkedés hasonlít a korában ismertetett átterheléses mozgatásra. Azaz, ha mozgatni kell, akkor csak azután teszi meg, hogy az \enquote{új} szolgáltatás készen áll, ez idő alatt a \enquote{régi} szolgáltatás dolgozza fel a kéréseket, így kiesés nélkül vihető véghez a szolgáltatások mozgatása.
 
-Annak eldöntése, hogy melyik adatközpontba kezdje el átütemezni a terhelést az algoritmus jelenlegi megoldásomban egy fix rangsort használ. Ahol egy előre rögzített listán minden egyes lehetőséget megvizsgál stabilitás szerint és ez alapján választja ki az ideális jelöltet. 
+A jelenlegi megoldásomban egy fix rangsort használ annak eldöntése, hogy melyik adatközpontba kezdje el átütemezni a terhelést az algoritmus. A működése során egy előre rögzített listán minden egyes lehetőséget megvizsgál stabilitás szerint és ez alapján választja ki az ideális jelöltet. 
 
-Ilyen szintű naiv megoldás szuboptimális eredményt hozhat. Hiszen könnyen belátható, hogy hajlamos a vibrációra, azaz amikor egy terhelést folyamatosan oda-vissza ütemez két adatközpont között. Ez akkor fordulhat elő ha egy adatközpont működése stabil, de egy egységnyi terhelés (esetünkben egy \acrshort{iot} eszköz által küldött hangminták) már instabillá teszik.
+Ilyen szintű naiv megoldás szuboptimális eredményt hozhat, hiszen könnyen belátható, hogy hajlamos a vibrációra, azaz amikor egy terhelést folyamatosan oda-vissza ütemez két adatközpont között. Ez akkor fordulhat elő, ha egy adatközpont működése stabil, de plusz egy egységnyi terhelés (esetünkben egy \acrshort{iot} eszköz által küldött hangminták) már instabillá teszi.
 
 Ennek a jelenségnek az elkerülésére az algoritmus megjelöli, ha egy adatközpontban instabil működés miatt el kellett mozgatnia onnan terhelést. Ez a jelölés egy idő után lejár, ideális esetben azután, hogy a rendszer ismét elérte a stabil állapotot. Mivel a stabil állapot nem vezet átütemezéshez, ezért itt már nincs jelentősége a jelölésnek.
 
@@ -153,13 +153,13 @@ Azt, hogy ennek a táblázatnak a tartalmát hogyan szinkronizáljam az eszköz
 
 Míg a \textit{push} alapú megoldás megoldás esetén a rendszer azonnal képes lehet értesíteni az eszközöket, sokkal komplexebb megoldást igényel, hiszen kezelni kell azokat a hiba lehetőségeket, amelyek felmerülhetnek a kommunikáció során és biztosítani, hogy ezeknek ellenáll az információ továbbítás.
 
-Ezzel szemben \textit{pull} alapú megoldás esetén az eszközök ezt az információt működésük során periodikusan lekérhetik, és ennek megfelelően állíthatják át küldésük célját. Ebben az esetben a két lekérdezés között eltelt idő miatt nagyobb késleltetéssel értesülnek a változásról az eszközök, hiszen a táblában változott bejegyzésről csak a következő lekérésben tudnak értesülni. Emellett a folyamatos periodikus lekérdezés felesleges terhelést is jelent az ütemező rendszer számára, hiszen akkor is teljesítenie kell a kéréseket, ha nem változott semmi a konfigurációban. Cserében ebben az esetben nem okoz nagy problémát ha egy frissítés nem jut el az eszközhöz, vagy a frissítés pillanatában éppen nem elérhető az eszköz. A folyamatos lekérdezés miatt idővel konvergálni fog a helyes konfigurációhoz. 
+Ezzel szemben \textit{pull} alapú megoldás esetén az eszközök ezt az információt működésük során periodikusan lekérhetik, és ennek megfelelően állíthatják át küldésük célcímét. Ebben az esetben a két lekérdezés között eltelt idő miatt nagyobb késleltetéssel értesülnek a változásról az eszközök, hiszen a táblában változott bejegyzésről csak a következő lekérésben tudnak értesülni. Emellett a folyamatos periodikus lekérdezés felesleges terhelést is jelent az ütemező rendszer számára, hiszen akkor is teljesítenie kell a kéréseket, ha nem változott semmi a konfigurációban. Cserébe ebben az esetben nem okoz nagy problémát, ha egy frissítés nem jut el az eszközhöz, vagy a frissítés pillanatában éppen nem elérhető az eszköz. A folyamatos lekérdezés miatt idővel konvergálni fog a helyes konfigurációhoz. 
 
 A konfiguráció leküldéséhez a periodikus lekérdezést választottam. Ennek oka az, hogy implementációja jelentősen könnyebb, mint az értesítési mechanizmus esetén. Emellett a konfiguráció változtatás nem időérzékeny: az átterheléses mozgatás miatt bizonyos mértékű késleltetés nem okoz problémát. 
 
 \subsection{Rendszer implementáció}
 
-Az ütemező rendszerem megvalósítását \textit{Kubernetes} környezetben futtatható mikroszolgáltatás architektúrára terveztem. A rendszer vázlatos felépítése \aref{fig:turbomemer}.\ ábrán látható. Az egyes szolgáltatások és egyéb szoftver komponensek implementációját a következő szekciókban részletezem.
+Az ütemező rendszerem megvalósítását \textit{Kubernetes} környezetben futtatható mikroszolgáltatás architektúrára terveztem. A rendszer vázlatos felépítése \aref{fig:turbomemer}.\ ábrán látható. Az egyes szolgáltatások és egyéb szoftver komponensek implementációját a következő alfejezetekben részletezem.
 
 \begin{figure}[h!]
 	\centering
@@ -168,40 +168,40 @@ Az ütemező rendszerem megvalósítását \textit{Kubernetes} környezetben fut
 	\label{fig:turbomemer}
 \end{figure}
 
-\subsubsection{Mérés kezelő}
+\subsubsection{Mérési adat kezelő komponens}
 \label{sec:birb-latency-collector}
 
 Ez a szolgáltatás egy kívülről is elérhető interfészt valósít meg. Feladata a rendszer állapotát leíró mért adatok gyűjtése és azokról kiértékelések szolgáltatása. Ennek megvalósítására egy idősoros adatbázist használ. Az általam választott idősoros adatbázis az \textit{InfluxDB}.
 
 Azért választottam az \textit{InfluxDB}-t, mert egy hatékonyan működő adatbázis sok hasznos funkcióval. Ilyen például a 2-es verzió óta beépített adatvizualizáció, így közvetlenül lehet a szoftvert arra használni, hogy a rögzített méréseket megtekintsük. Saját lekérdező nyelvén pedig sokféle adat aggregáció, transzformáció és kiértékelő funkcionalitás érhető el.
 
-Új mérések érkezésekor a szolgáltatás eltárolja az információkat az adatbázisban. Ha szükség van kiértékelésre, akkor az \textit{InfluxDB} saját lekérdezőnyelvére fordítja a kérést és az adatbázis szoftverben futtatja azt le, így hatékonyan és egyszerűen tudja megkapni a kiértékelt adatokat, amelyeket válaszul ad a kérésre.
+Új mérések érkezésekor a szolgáltatás eltárolja az információkat az adatbázisban. Ha szükség van kiértékelésre, akkor az \textit{InfluxDB} saját lekérdezőnyelvére fordítja a kérést, és az adatbázis szoftverben futtatja azt le, így hatékonyan és egyszerűen tudja megkapni a kiértékelt adatokat, amelyeket válaszul ad a kérésre.
 
 Ezt a szolgáltatást a robotkarok vezérlését megvalósító alkalmazás közvetlenül tudja használni az ütemezési döntés meghozatalára.
 
-\subsubsection{Ütemezés nyilvántartó}
+\subsubsection{Ütemezés nyilvántartó komponens}
 \label{sec:birb-scheduler-teller}
 
 Ezt a szolgáltatás kizárólag az intelligens madárhang elemző alkalmazás használja. 
 
 Ennek a szolgáltatásnak a feladata, hogy számontartsa az egyes eszközök jelenlétét illetve kiszolgálja számukra, hogy pillanatnyilag melyik adatközponthoz vannak rendelve. Az eszközök futásuk során ettől a szolgáltatástól tudják lekérni az ütemezési információikat. 
 
-Ha a szolgáltatásból egy eddig ismeretlen eszköz kéri le az ütemezését, akkor azt egy dinamikusan megválasztott \enquote{alapértelmezett} adatközponthoz rendeli. Ezután ezt az ütemezési döntést elmenti és innentől kezdve ugyanúgy van kezelve az új eszköz is, mint az összes többi.
+Ha a szolgáltatástól egy eddig ismeretlen eszköz kéri le az ütemezését, akkor azt egy dinamikusan megválasztott \enquote{alapértelmezett} adatközponthoz rendeli. Ezután ezt az ütemezési döntést elmenti, és innentől kezdve ugyanúgy van kezelve az új eszköz is, mint az összes többi.
 
 A kiszolgált adatokat egy kulcs-érték adatbázisban tárolja. Ehhez \textit{Redis} adatbázist használtam, ennek oka az, hogy a \textit{Redis} támogatja az értékekhez lejárati idő rendelését. A lejárai idő leteltével az értékeket automatikusan törli. Ennek a segítségével számos funkcionalitást könnyebb volt implementálni. A \textit{Redis} támogatja továbbá az osztott memóriaként való funkcionalitást, amelyet kihasználva \aref{sec:birb-scheduler}.\ alfejezetben ismertetett szolgáltatással való kommunikációt megoldottam.
 
-\subsubsection{Dinamikus újra-ütemező}
+\subsubsection{Dinamikus újra-ütemező komponens}
 \label{sec:birb-scheduler}
 
 \Aref{sec:birb-scheduler-teller}.\ alfejezetben ismertetett szolgáltatás csak egy statikus hozzárendelést valósít meg az új eszközök és az adatközpontok között. Viszont ezek után nem változtatja meg a döntését. Ezeknek a döntéseknek a felülvizsgálatára és az \enquote{alapértelmezett} adatközpont dinamikus megváltoztatására szolgál ez a szolgáltatás.
 
 Ez a szolgáltatás valósítja meg \aref{sec:scheduling-algo}.\ alfejezetben vázolt periodikusan futó ütemező algoritmust. 
 
-Futása során a kiértékelt metrikákat lekérdezi a \textit{Mérés kezelő} szolgáltatásból. Majd ezek alapján és az osztott \textit{Redis} adatbázisban tárolt információk alapján meghozza az ütemezési döntést. Szükség esetén \textit{Kubernetes} \acrshort{api} hívásokkal elindítja a \textit{KubeFed} által kezelt szolgáltatást a megfelelő adatközpontban majd ezek után az ütemezési döntést rögzíti a az adatbázisban. így legközelebb amikor az eszköz frissíti a konfigurációját már az újonnan indított szolgáltatáshoz küldi az információkat, ezzel megvalósítva a dinamikus átütemezést.
+Futása során a kiértékelt metrikákat lekérdezi a \textit{Mérési adat kezelő} szolgáltatásból. Majd ezek alapján és az osztott \textit{Redis} adatbázisban tárolt információk alapján meghozza az ütemezési döntést. Szükség esetén \textit{Kubernetes} \acrshort{api} hívásokkal elindítja a \textit{KubeFed} által kezelt szolgáltatást a megfelelő adatközpontban majd ezek után az ütemezési döntést rögzíti a az adatbázisban. Így legközelebb, amikor az eszköz frissíti a konfigurációját, már az újonnan indított szolgáltatáshoz küldi az információkat, ezzel megvalósítva a dinamikus átütemezést.
 
 A szolgáltatás azt is ellenőrzi, hogy a kijelölt \enquote{alapértelmezett} adatközpont stabilnak számít-e. Ha nem, akkor ezt a beállítást is frissíti, így az új eszközök már másik adatközpontba kezdik el küldeni az adatokat.
 
-Értelem szerűen ezt a szolgáltatást is csak az intelligens madárhang elemző alkalmazás használja.
+Értelemszerűen ezt a szolgáltatást is csak az intelligens madárhang elemző alkalmazás használja.
 
 \subsection{Link késleltetés mérése}
 
@@ -209,16 +209,16 @@ A robotkarokat vezérlő alkalmazás számára szükség van arra az informáci
 
 Ennek a megvalósítására egy egyszerű szkriptet készítettem, amely leméri az összes adatközponttal szembeni késleltetést, majd ezeket elküldi \aref{sec:birb-latency-collector}.\ alfejezetben ismertetett szolgáltatás számára, amely így képes arról kiértékelést készíteni.
 
-A késleltetés mérésére kézenfekvő megoldás lehet a hagyományos \acrfull{icmp} által biztosított \textit{Ping} kérésekkel mérni a körülfordulási időt. De ez csak egy nagyon limitált eredményt ad egy konkrét végponthoz. 
+A késleltetés mérésére kézenfekvő megoldás lehet a hagyományos \acrfull{icmp} által biztosított \textit{Ping} kérésekkel mérni a körülfordulási időt. De ez nagyon limitált eredményt ad egy konkrét végponthoz. 
 
-Szerettem volna egy olyan megoldást készíteni, amely nem csak az adatközpont határán lévő, publikus címmel rendelkező végponthoz tudja mérni a késleltetést, hanem közvetlenül az ott futó szolgáltatások és a végpont közti kapcsolatot tudja mérni. Ennek hála a késleltetés nem csak a publikus hálózat állapotát, de az egyes adatközpontok belső hálózatáról is képet tud adni. Ezzel átfogóbb és pontosabb információt kapunk arról, hogy melyik adatközpontot érdemes használnunk.
+Szerettem volna egy olyan megoldást készíteni, amely nem csak az adatközpont határán lévő, publikus címmel rendelkező végponthoz tudja mérni a késleltetést, hanem közvetlenül az ott futó szolgáltatások és a végpont közti kapcsolatot tudja mérni. Ennek köszönhetően a mért késleltetés nem csak a publikus hálózat állapotáról, hanem az egyes adatközpontok belső hálózatáról is képet tud adni. Ezzel átfogóbb és pontosabb információt kapunk arról, hogy melyik adatközpontot érdemes használnunk.
 
-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.
+Ezt úgy oldottam meg, hogy felkonfiguráltam egy egyszerű webszerver konténert, amely minden kérésre  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 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ési adat 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.
+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 minimum függvénnyel meghatározható volt, hogy melyik adatközpontban kerüljön ütemezésre a szolgáltatás.