-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathfejlesztes.tex
executable file
·53 lines (38 loc) · 6.65 KB
/
fejlesztes.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
\section{Fejlesztési megfontolások}
%(8-10 oldal): python, mongodb, logolás, email küldés, weboldal, hibák függetlenítése, megbízhatóságnövelő megfontolások
\subsection{MongoDB adatbázis használata}
Először SQLite adatbázis volt használva a mérési eredmények tárolására. Az SQL lekérdezési nyelvet széleskörű ismerete miatt lett használva, valamint a Python programozási környezetből való kényelmes használta miatt. Az adatbázis egyszerű fájlként van tárolva, így könnyebben kezelhető. A fejlesztés közben sűrűn változó struktúrájú adatok tárolásár azonban nem volt megfelelő. Egy új mérési attribútum bevezetésekor új adattáblát kellett létrehozni, a régi adatokat pedig megfelelően importálni. A felmerülő adatkonverziók feleslegesen vettek el időt. Ezen felül az adatok feldolgozása is erőforrás igényes volt, mivel a komplexebb adatfeldolgozási lépések Python szkripteken futottak amelyek többször fordultak újra az SQLite adatbázishoz.
Ezen problémák miatt más adatbázis megoldások lettek felmérve, amelyek jobban illeszkedhetnek majd a rendszerek igényeihez. A relációs adatbázisokkal szemben a dokumentum alapú adatbázisok nem rendelkeznek szigorú adatstruktúrákkal. Egy kollekcióban (az adattáblákhoz hasonló elem) többféle felépítésű adatelem is elhelyezkedhet. Egy hibás mérés adateleme például csak kevéssel különbözik a többitől. Ezek könnyen kezelhetően együtt tudnak élni egy ilyen dokumentum alapú adatbázisban, míg komplex relációs táblák kialakítása lett volna szükséges SQL esetében.
Végül a MongoDB lett kiválasztva, a széleskörű adatfeldolgozási támogatása miatt. Egyes komplexebb feldolgozási lépéseket akár azonnal az adatbázisban el lehet végezni, a többfokozatú adataggregálási rendszerének és a JavaScript alapú map-reduce eljárásnak hála. Az adatfeldolgozó képességeinek bemutatására az alábbi kódrészletet mutatom be, amely egy későbbiekben bemutatandó adat kollekcióból kigyűjti a mérések által felderített Internetes kapcsolatok tulajdonságait:
\begin{lstlisting}[language=JavaScript]
db.getCollection('links').aggregate([
{$project:{_id:0, links:1}},
{$unwind:"$links"},
{$project:{
delay: "$links.delay",
jitter: "$links.jitter",
rtt: "$links.rtt"
}},
{$out:"to_export"}
])
\end{lstlisting}
A választás meghozta eredményét, mivel felgyorsult az új adatfeldolgozások fejlesztése, valamint a régebbi struktúrájú mérések az újakkal könnyen együtt kezelhetővé váltak.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Címszavakban a tartalom:
%rugalmas adatstruktúrák
%fejlesztés közbeni átmeneti állapotok jó kezelése
%Aggregálási képességek hangsúlyozása
%(komplex lekérdezése)
\subsection{Megbízhatósági törekvések}
A mérési rendszer úgy lett kialakítva, hogy bizonytalan körülmények között is megfelelően működjön. A PlanetLab hálózatában rendkívül sokféle számítógép található, amelyek karbantartása sok esetben nem megfelelő. Korábban olyanra is akadt példa, hogy egy PlanetLab-os számítógép rendellenes viselkedése leállította az egész mérési folyamatot. Az ehhez hasonló hibák elkerülésére valamint a hibák minél hamarabbi észlelésére nagy figyelem lett fordítva a mérési rendszer fejlesztésekor.
\subsubsection*{Hibalehetőségek függetlenítése}
A mérés egy folyamatos ciklusból áll: A PlanetLab gépeit megpróbálja elérni, azokon a megfelelő méréseket elvégezni, végül eltárolni az eredményeket, majd egy újabb géppel folytatni a mérést.
Korábban egy hiba fenntarthatta az egész mérést. Ennek elkerülése miatt két programszálra lett bontva a folyamat: Egy központi program folyamatosan iterál a PlanetLab gépein és egy újabb független programot indít a mérendő gép címét paraméterként megadva. A hívott program bármilyen hibába ütközik arról értesül a főprogram, de nem tudja leállásra kényszeríteni azt. Az alprogram futásának pedig egy félperces maximálisan megengedett időablaka van, amelyet ha meghalad automatikusan leállításra kerül és egy újabb méréssel folytatódik a ciklus.
\subsubsection*{Maximálisan megengedett időkeret elve}
Az maximálisan megengedett időkeret elvét több másik folyamatra is bevezettem. A mérés során ha bármely lépése a folyamatnak időkorlátba ütközik a hiba oka fel lesz tüntetve a mérésről készült jelentésben. Ilyen módon könnyen kideríthető a hiba oka.
\subsection*{Hibanaplók készítése}
A fejlesztés kezdeti szakaszában ha hiba fordult elő a kódban az viszonylag hamar kiderült és a fejlesztőkörnyezetben kényelmes eszközök álltak rendelkezésre, hogy a kiderüljön a hiba oka. Később amikor a mérés folyamatosan futott nagyban feltartotta a megoldását, hogy a hiba egyetlen jelensége az volt, hogy nem került mentésre egy újabb sikeres (vagy akár sikertelen) mérés sem. Ennek megoldására a mérésnek szinte miden szintjén be lett vezetve a hibanapló írása. Így a mérés állapota és az esetleges hibák forrásai egyből elérhetővé váltak. A felhős platformon pedig a hibanaplók akár a weboldalon egyből megtekinthetővé váltak.
\subsubsection*{Felmerülő hibák kategorizálása, előfordulásuk monitorozása}
Mint korábban említettem a PlanetLab hálózatán sok nem karbantartott gép is jelen van, emiatt a hivatalosan elérhető 1030 gépből átlagosan csak 400 elérhető ping paranccsal, amelyek közül átlagosan csak 200-hoz lehet sikeresen ssh kapcsolatot felépíteni és parancsot futtatni. A géppark állapotáról ezért óránként egy felmérés készül, amely a PlanetLab gépeihez csatlakozni próbál és a problémamentes gépeket nyilvántartja, hogy ne kelljen feleslegesen csatlakozási kísérletet végezni a hibás gépekhez. Ez az eljárás nagyban felgyorsította a sikeres mérések begyűjtését.
A csatlakozási és parancsfuttatási hibák a felmérés során kategorizálásra kerülnek és későbbi statisztikák számára tárolódnak. Így nyomon követhető a PlanetLab hálózatán elérhető gépek tényleges elérhetősége/használhatósága.
A mérési rendszer honlapján ezek a friss statisztikák szintén elérhetően, így könnyen felmérhetjük a tömeges hibák okait. Ilyenre volt példa amikor a BME által üzemeltetett PlanetLab gépek leálltak és a PlanetLab megszüntette a hálózatukban elérhető gépekre való csatlakozási engedélyünket. Egy új hibakategória jelent meg a felmérési statisztikákban amely hirtelen sok gépet tett elérhetetlenné (bár nem mindet).