GSoC 2012: Modularni nodewatcher EN

V okviru Google Summer of Code 2012 je potekal tudi razvoj jedrnih komponent naslednje verzije platforme nodewatcher, verzije 3.0. Medtem ko je verzija 2.0 služila le potrebam wlan slovenija omrežja, je cilj razvoja verzije 3.0 vzpostaviti prilagodljivo platformo za razvoj rešitev za postavitev, nadzor in upravljanje odprtih a različnih brezžičnih omrežij. Glavna ideja je modularnost platforme na vseh nivojih, tako da lahko posamezno omrežje končno rešitev popolnoma prilagodi svojim primerom uporabe, ciljem in vrednotam, saj se je skozi prakso pokazalo, da se te razlikujejo od omrežja do omrežja, od skupnosti do skupnosti, in da je nemogoče razviti eno rešitev, ki bi zadovoljevala sama po sebi vse. Tako bo nodewatcher 3.0 ne le ena rešitev, ampak prilagodljiva platforma z ekosistemom modulov in skupnosti okoli nje.

Nadaljevanje prispevka predstavlja opis arhitekture vseh komponent iz katerih je nova platforma sestavljena.

Konfiguracija točk in modularnost podatkovnih modelov

Koncept modularnosti v platformo nodewatcher pripelje nove izzive, na prvem mestu se pojavi vprašanje, kako omogočiti modulom, da dodajo svoje nastavitvene možnosti registriranim točkam. Platforma mora na tem mestu zagotoviti vmesnike za več stvari:

  • Trajno shranjevanje konfiguracijskih podatkov, kjer shemo določi razvijalec modula.
  • Možnost, da uporabnik skozi spletni vmesnik (ki je po možnosti samodejno generiran iz sheme, tako da razvijalcu ni potrebno le-te opisati dvakrat) vnese vrednosti konfiguracije.
  • Preverjanje pravilnosti vseh podatkov ob vnosu v širšem kontekstu konfiguracije točke: ena konfiguracijska vrednost ima namreč lahko odvisnosti v drugih modulih, ki zahtevajo ustrezno validacijo ob njeni spremembi. Prav tako smo želeli zaradi potreb generatorja firmwarea zagotoviti, da uporabnik takoj dobi sporočila o napakah v kolikor določena konfiguracija na določeni strojni opremi ni mogoča, tako da lahko konfiguracijo takoj popravi.
  • Specifikacija kontekstno-odvisnih privzetih konfiguracijskih vrednosti. Primer: točka v projektu X ima v primeru, da strojna oprema podpira več SSID, na vmesniku tipa ad-hoc privzeto SSID "mesh.wlan-si.net", v primeru, da strojna oprema podpira zgolj en SSID pa naj bo le-ta privzeto "open.wlan-si.net". Zaradi zahteve po takšnih kompleksnih pravilih smo razvili tudi preprost jezik za specifikacijo takšnih pravil.

Da bi pokrili vse zgornje zahteve, smo razvili komponento imenovano registry. Gre za tanko plast nad obstoječim Django ORMjem, ki omogoča opis shem (primer sheme za konfiguracijo točk se nahaja tukaj), samodejno generiranje ustreznih konfiguracijskih form, nastavitev privzete konfiguracije in validacije za dane sheme. Podprte so tudi hierarhične relacije med posameznimi elementi (npr. en radio ima lahko več omrežnih vmesnikov, ki imajo lahko več naslovov), kar je izziv predvsem za generiranje ustreznega uporabniškega vmesnika ter za izvajanje pravil.

Na več mestih je omogočeno dodajanje funkcionalnosti, tako da lahko npr. razvijalec prilagodi obnašanje form (ki se lahko dinamično spreminjajo glede na vrednosti drugih polj), možno je ob uspešni validaciji konfiguracije izvesti določene postopke (npr. samodejna alokacija IP naslovov glede na izbrane zahteve ali pa validacija konfiguracije za konkretno strojno opremo v primeru generiranja firmwarea).

To komponento nodewatcher 3.0 izkorišča za vodenje evidence o točkah in za črpanje konfiguracije za potrebe vseh ostalih modulov (generatorja firmwarea, spremljanje delovanja omrežja, ipd.)

Spremljanje delovanja omrežja

Nova verzija platforme ponuja tudi komponento za spremljanje delovanja omrežja, ki prav tako omogoča modularno dodajanje funkcionalnosti. Vsak modul lahko doda svoje "procesorje", ki se izvedejo ali nad celotnim omrežjem (vse točke), ali pa za vsako opazovano točko posebej, kar omogoča samodejno paralelizacijo delov spremljanja, ki se nanaša na več točk. Možno je definirati popolnoma poljuben potek izvajanja teh procesorjev. Modularni pristop omogoča tudi podporo različnim virom podatkov in različnim načinom obravnave podatkov (npr. generiranje obvestil ob zaznanih odstopanjih od konfiguracije).

Gre torej za ogrodje, ki omogoča gradnjo rešitev za nadzor omrežja, trenutno implementirana pa je podpora za pridobivanje podatkov iz usmerjevalnega protokola OLSR ter iz obstoječega nodewatcher formata verzije 2.0, v katerem poročajo točke z našim firmwareom.

Razvit je bil tudi modul imenovan datastream, ki zna vse zajete podatke shraniti kot časovno vrsto za nadaljnjo obdelavo oziroma za generiranje grafičnih prikazov spreminjanja podatkov skozi čas.

Generator firmware slik

Še tretja ključna komponenta je generator firmware slik imenovan Configuration Generating Modules (CGMs). Ponovno gre za module, ki znajo iz prej omenjene konfiguracije v registryju zgenerirati konfiguracijo za posamezen operacijski sistem, ki teče na usmerjevalniku (trenutno je podprt zgolj OpenWrt v obliki konfiguracije UCI). To omogoča, da lahko sistem pripravi firmware za točno določeno napravo iz obstoječe konfiguracije. Trenutno ta komponenta še ni popolnoma dokončana, potrebno je dodati še nekatere stvari za upravljanje s paketi in pa pripravo končnega paketa s firmwareom.

Načrti za naprej

Potrebno je predvsem dokončati generator firmware slik in začeti pripravo osnovnih gradnikov grafičnega vmesnika, nato pa dokončati vse module, da bo funkcionalnost na približno enakem nivoju kot trenutna, 2.0, verzija.

Ves razvoj poteka v branchu development, ki je dostopen na GitHub-u.