16 modemov, 4 mobilna operaterja = Izhodna hitrost 933,45 Mbit/s
Uvod
Pozdravljeni! Ta članek govori o tem, kako smo zase razvili nov sistem za spremljanje. Od obstoječih se razlikuje po možnosti visoko frekvenčnega sinhroniziranega pridobivanja metrik in zelo majhni porabi virov. Frekvenca anketiranja lahko doseže 0,1 milisekunde z natančnostjo sinhronizacije med metrikami 10 nanosekund. Vse binarne datoteke zasedajo 6 megabajtov.
O projektu
Imamo precej specifičen izdelek. Proizvajamo celovito rešitev za seštevanje pasovne širine in odpornosti podatkovnih prenosnih kanalov. To je, ko obstaja več kanalov, recimo Operater1 (40 Mbit/s) + Operater2 (30 Mbit/s) + Kaj drugega (5 Mbit/s), kar v rezultatih prinaša en stalen in hiter kanal, katerega hitrost bo približno takšna: (40+30+5) x 0,92 = 75 x 0,92 = 69 Mbit/s.
Tovrstne rešitve so iskane tam, kjer zmogljivost katerega koli enega kanala ni zadostna. Na primer, v transportu, video nadzornih sistemih in prenosu video vsebin v realnem času, prenosu neposrednih televizijskih in radijskih oddaj, in v vseh podeželskih objektih, kjer so na voljo le predstavniki velike četvorke in hitrosti na enem modemu/kanalu niso dovolj.
Za vsako od teh usmeritev izdamo posebno linijo naprav, vendar je programski del skoraj enak in kakovosten sistem spremljanja - eden od glavnih modulov, brez pravilne implementacije katerega izdelek ne bi bil mogoč.
V zadnjih nekaj letih nam je uspelo ustvariti večstopenjski hiter, večplatformski in lahek sistem spremljanja. Temu želimo deliti z občinstvom.
Definisanje zadatka
Sistem spremljanja zagotavlja pridobivanje metrik dveh temeljno različnih razredov: metrike v realnem času in vse ostale. Za sistem spremljanja so bili le naslednji zahteve:
- Visoko frekvenčno sinhronizirano pridobivanje metrik v realnem času in njihovo posredovanje v sistem za obvladovanje komunikacij brez zamud.
Visoka frekvenca in sinhronizacija različnih metrik ni le pomembna, temveč je življenjsko pomembna za analizo entropije prenosnih kanalov. Če je povprečna zakasnitev v enem prenosnem kanalu 30 milisekund, napaka v sinhronizaciji z ostalimi metriki zgolj eno milisekundo privede do degradacije hitrosti končnega kanala približno za 5%. Če naredimo napako v sinhronizaciji za 1 milisekundo v 4 kanalah, lahko degradacija hitrosti enostavno pade do 30%. Poleg tega se entropija v kanalih zelo hitro spreminja, zato če jo merimo redkeje kot enkrat na 0.5 milisekunde, bomo na hitrih kanalih z majhno zakasnitvijo prejeli visoko degradacijo hitrosti. Seveda točno takšna natančnost ni potrebna za vse metrike in ne v vseh pogojih. Ko bo zakasnitev v kanalu 500 milisekund, in delamo tudi s takšnimi, bo napaka 1 milisekundo skoraj neopazna. Prav tako za metrike sistemov za zagotavljanje življenjskih funkcij zadostuje frekvenca anketiranja in sinhronizacije 2 sekundi, vendar mora sama sistemska nadzorna orodja obvladovati izjemno visoke frekvence anketiranja in izjemno natančno sinhronizacijo metrik. - Minimorna poraba virov in enoten kup.
Končno napravo lahko predstavlja tako močan vgrajen kompleks, ki lahko analizira situacijo na cesti ali izvaja biometrično registracijo ljudi, kot tudi enotna plošča velikosti dlani, ki jo nosi vojak posebnih enot pod jopičem, da bi v realnem času prenašal video v pogojih slabe povezave. Kljub takšni raznolikosti arhitektur in računalniške moči bi želeli imeti enak programerski kup. - Dežnik arhitektura
Metrične podatke je treba zbirati in agregirati na končni napravi, imeti lokalni sistem shranjevanja in vizualizacijo v realnem času ter retrospektivno. V primeru povezave je treba prenesti podatke v centralni sistem nadzora. Ko povezave ni, mora biti vrsta za prenos naložena in ne sme porabljati delovne spomina. - API za integracijo v sistem nadzora naročnika, ker nihče ne potrebuje mnogih sistemov nadzora. Naročnik mora zbirati podatke iz vseh naprav in omrežij v enoten nadzor.
Šta je postignuto
Da ne bi opterećivali već obimnu analizu, neću navoditi primere i mere svih sistema za nadzor. To bi zahtevalo još jedan članak. Samo ću reći da nismo uspeli da pronađemo sistem za nadzor koji može da prati dve metrike istovremeno uz grešku manju od 1 milisekunde i koji jednako efikasno funkcioniše na ARM arhitekturi sa 64MB RAM-a i na x86_64 arhitekturi sa 32GB RAM-a. Stoga smo odlučili da napišemo sopstveni, koji može sve to. Evo šta smo postigli:
Sabrati propusnost tri kanala za različite topologije mreže
Vizualizacija nekih ključnih metrika
Arhitektura
Kao glavni programski jezik, kako na uređaju, tako i u podatkovnom centru, koristimo Golang. On značajno olakšava život svojom implementacijom višezadatnosti i mogućnošću da se dobije jedan statički povezani izvršni binarni fajl za svaku uslugu. Kao rezultat, značajno štedimo u resursima, metodama i saobraćaju pri implementaciji usluge na krajnje uređaje, kao i vreme razvoja i otklanjanja grešaka u kodu.
Sistem je realizovan po klasičnom modularnom principu i sadrži nekoliko podsistema:
- Registracija metrika.
Svaka metrika se poslužuje vlastitom niti i sinhronizuje putem kanala. Uspeli smo da postignemo tačnost sinhronizacije do 10 nanosekundi. - Skladištenje metrika
Izbrali smo med tem, da bi razvili svoje shranjevanje za časovne vrste in uporabo že obstoječega. Podatkovna baza je potrebna za retrospektivne podatke, ki jih bomo kasneje vizualizirali. To pomeni, da nima podatkov o zakasnitvah v kanalu vsakih 0,5 milisekunde ali o napakah v transportnem omrežju, temveč beleži hitrost na vsakem vmesniku vsakih 500 milisekund. Poleg visokih zahtev za medplatformno združljivost in nizko porabo virov je zame izjemno pomembno, da lahko obdelamo podatke tam, kjer so shranjeni. To izjemno prihrani računalniške vire. Od leta 2016 uporabljamo DBMS Tarantool v tem projektu in zaenkrat ne vidimo nobene zamenjave. Fleksibilen, z optimalno porabo virov in z več kot zadovoljivo tehnično podporo. V Tarantoolu je tudi GIS modul. Seveda ni tako zmogljiv kot PostGIS, vendar zadostuje za naše potrebe shranjevanja nekaterih metrike povezanih z lokacijo (kar je aktualno za transport). - Vizualizacija metrik
Tukaj je vse relativno preprosto. Vzamemo podatke iz shranjevanja in jih prikažemo bodisi v realnem času bodisi retrospektivno. - Sinhronizacija podatkov s centralnim sistemom za nadzor.
Centralni sistem za nadzor sprejema podatke iz vseh naprav, jih shranjuje z določenim retrospektivnim obdobjem in jih preko API-ja posreduje v nadzorni sistem naročnika. Za razliko od klasičnih sistemov za nadzor, kjer »glava« zbira podatke, imamo obratno shemo. Naprave same pošiljajo podatke, ko so na voljo. To je zelo pomembna točka, saj omogoča pridobitev podatkov z naprave za tiste časovne intervale, ko ni bila dostopna, ter ne preobremenjuje kanalov in virov, ko naprava ni dostopna. Kot centralni sistem za nadzor uporabljamo Influx monitoring server. Za razliko od analogov lahko uvozi retrospektivne podatke (tj. z časovno oznako, ki se razlikuje od trenutka pridobitve metrike). Zbrane metrike vizualizira izboljšana verzija Grafane. Ta standardni sklop je bil izbran tudi zato, ker ima pripravljene API integracije praktično s katerimkoli nadzornim sistemom naročnika. - Sinhronizacija podatkov s centralnim sistemom za upravljanje naprav.
Upravljalski sistem naprav izvaja Zero Touch Provisioning (posodobitev programske opreme, konfiguracije itd.) in se za razliko od sistema spremljanja osredotoča le na težave naprav. To so sprožilci delovanja vgrajenih strojnih servisov in vse metrike sistemov, ki zagotavljajo življenje: temperatura CPU in SSD, obremenitev CPU, prosti prostor in S.M.A.R.T zdravje diskov. Shranjevanje podnabora je prav tako zgrajeno na Tarantoolu. To nam zagotavlja znatno hitrost pri agregaciji časovnih vrst po tisočih naprav, prav tako pa v celoti rešuje vprašanje sinhronizacije podatkov s temi napravami. Tarantool ima vgrajen odličen sistem čakalnih vrst in zagotovljene dostave. To pomembno funkcijo smo dobili kar iz škatle, odlično!
Sistem upravljanja omrežja
Kaj naprej
Trenutno je naša najs šibkejša povezava osrednji sistem spremljanja. Uresničena je 99,9 % na standardni tehnologiji in ima vrsto pomanjkljivosti:
- InfluxDB izgublja podatke ob izpadu napajanja. Na splošno naročnik hitro sprejme vse, kar pride z naprav, in v sami bazi ni podatkov starejših od 5 minut, vendar bi to v prihodnosti lahko predstavljalo težavo.
- Grafana ima vrsto težav z agregacijo podatkov in sinhronizacijo njihovega prikaza. Najpogostejša težava je, ko v bazi obstaja časovna vrsta z intervalom 2 sekundi, ki se začne recimo ob 00:00:00, Grafana pa začne prikazovati podatke v agregaciji s +1 sekundo. Posledično uporabnik vidi pritiskajoči graf.
- Prekomerna količina kode za API integracijo s tretjimi sistemi spremljanja. Lahko bi bilo veliko bolj kompaktno in seveda prepisano v Go.
Menim, da ste vsi videli, kako izgleda Grafana, in brez mene poznate njene težave, zato ne bom preobremenjeval objave s slikami.
Zaključek
Zavedno nisem podrobno opisoval tehničnih podrobnosti, temveč sem le opisal osnovno zasnovo tega sistema. Prvič, za tehnično popoln opis sistema bi potrebovali še en članek. Drugič, daleč ne bo vsem to zanimivo. V komentarjih mi sporočite, katere tehnične podrobnosti vas zanimajo.
Če imate kakršna koli vprašanja izven tega članka, me lahko kontaktirate na naslov a.rodin @ qedr.com
Izvor: habr.com
