Še en nadzorni sistem

16 modemov, 4 mobilni operaterji = Odhodna hitrost 933.45 Mbit/s

Predstavitev

Zdravo! Ta članek govori o tem, kako smo sami napisali nov nadzorni sistem. Od obstoječih se razlikuje po zmožnosti pridobivanja visokofrekvenčnih sinhronih meritev in zelo nizki porabi virov. Hitrost anketiranja lahko doseže 0.1 milisekunde s sinhronizacijsko natančnostjo med meritvami 10 nanosekund. Vse binarne datoteke zasedajo 6 megabajtov.

O

Imamo precej specifičen izdelek. Izdelujemo celovito rešitev za povzemanje prepustnosti in tolerance napak kanalov za prenos podatkov. To je, ko je več kanalov, recimo Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Nekaj ​​drugega (5 Mbit/s), rezultat je en stabilen in hiter kanal, katerega hitrost bo približno to: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.

Takšne rešitve so v povpraševanju, kjer je zmogljivost katerega koli kanala nezadostna. Na primer promet, videonadzorni sistemi in pretakanje videa v realnem času, oddajanje televizijskih in radijskih oddaj v živo, morebitni primestni objekti, kjer so med telekomunikacijskimi operaterji samo predstavniki velike četverice in hitrost na enem modemu/kanalu ni dovolj. .
Za vsako od teh področij izdelujemo svojo linijo naprav, vendar je njihov programski del skoraj enak in je kakovosten nadzorni sistem eden njegovih glavnih modulov, brez pravilne implementacije katerega produkt ne bi bil mogoč.

V nekaj letih nam je uspelo ustvariti večnivojski, hiter, večplatformski in lahek nadzorni sistem. To želimo deliti z našo spoštovano skupnostjo.

Izjava o težavah

Sistem spremljanja zagotavlja metrike dveh bistveno različnih razredov: metrike v realnem času in vse druge. Sistem spremljanja je imel samo naslednje zahteve:

1. Visokofrekvenčni sinhroni zajem metrik v realnem času in njihov prenos v sistem upravljanja komunikacij brez zakasnitve.
   Visoka frekvenca in sinhronizacija različnih metrik ni le pomembna, ampak je ključnega pomena za analizo entropije kanalov prenosa podatkov. Če je v enem kanalu za prenos podatkov povprečna zakasnitev 30 milisekund, bo napaka v sinhronizaciji med preostalimi metrikami le ene milisekunde povzročila poslabšanje hitrosti nastalega kanala za približno 5 %. Če napačno določimo čas za 1 milisekundo na 4 kanalih, lahko poslabšanje hitrosti zlahka pade na 30 %. Poleg tega se entropija v kanalih spreminja zelo hitro, tako da če jo merimo manj kot enkrat na 0.5 milisekunde, bomo na hitrih kanalih z majhno zakasnitvijo dobili degradacijo visoke hitrosti. Seveda pa taka natančnost ni potrebna za vse metrike in ne v vseh pogojih. Ko je zakasnitev v kanalu 500 milisekund in s tem delamo, potem napaka 1 milisekunde skoraj ne bo opazna. Tudi za metrike sistema za vzdrževanje življenja imamo dovolj hitrosti anketiranja in sinhronizacije 2 sekund, vendar mora biti sam nadzorni sistem sposoben delati z ultra visokimi stopnjami anketiranja in ultra natančno sinhronizacijo meritev.
2. Minimalna poraba virov in en sklad.
   Končna naprava je lahko zmogljiv vgrajeni kompleks, ki lahko analizira situacijo na cesti ali vodi biometrično snemanje ljudi, ali računalnik z eno ploščo velikosti dlani, ki ga vojak specialnih sil nosi pod neprebojnim jopičem za prenos videa v realnem času v slabih komunikacijskih pogojih. Kljub tako raznolikim arhitekturam in računalniški moči bi radi imeli enak programski sklad.
3. Krovna arhitektura
   Meritve je treba zbrati in združiti na končni napravi, lokalno shraniti ter vizualizirati v realnem času in za nazaj. Če obstaja povezava, prenesite podatke v centralni nadzorni sistem. Ko ni povezave, se mora čakalna vrsta za pošiljanje kopičiti in ne porabiti RAM-a.
4. API za integracijo v nadzorni sistem stranke, saj nihče ne potrebuje veliko nadzornih sistemov. Stranka mora zbirati podatke iz poljubnih naprav in omrežij v enoten nadzor.

Kaj se je zgodilo

Da ne bi obremenjeval že tako impresivnega branja, ne bom navajal primerov in meritev vseh nadzornih sistemov. To bo vodilo do drugega članka. Povedal bom le, da nismo mogli najti sistema za spremljanje, ki bi bil sposoben zajemati dve metriki hkrati z napako, manjšo od 1 milisekunde, in ki bi deloval enako učinkovito tako na arhitekturi ARM s 64 MB RAM-a kot na arhitekturi x86_64 z 32 GB RAM-a. Zato smo se odločili napisati svojega, ki zmore vse to. Evo, kaj imamo:

Povzemanje prepustnosti treh kanalov za različne topologije omrežja

Vizualizacija nekaterih ključnih meritev

arhitektura

Golang uporabljamo kot glavni programski jezik, tako na napravi kot v podatkovnem centru. Močno je poenostavil življenje s svojo implementacijo večopravilnosti in možnostjo pridobitve ene statično povezane izvršljive binarne datoteke za vsako storitev. Posledično znatno prihranimo pri virih, metodah in prometu za uvedbo storitve na končne naprave, čas razvoja in odpravljanje napak kode.

Sistem je izveden po klasičnem modularnem principu in vsebuje več podsistemov:

1. Registracija metrike.
   Vsako meritev streže lastna nit in je sinhronizirana med kanali. Dosegli smo natančnost sinhronizacije do 10 nanosekund.
2. Shranjevanje metrik
   Izbirali smo med pisanjem lastnega pomnilnika za časovne vrste ali uporabo nečesa, kar je že bilo na voljo. Podatkovna baza je potrebna za retrospektivne podatke, ki so predmet naknadne vizualizacije, torej ne vsebuje podatkov o zamikih v kanalu vsakih 0.5 milisekunde ali odčitkih napak v transportnem omrežju, ampak je hitrost na vsakem vmesniku vsakih 500 milisekund. Poleg visokih zahtev po večplatformnosti in nizke porabe virov je za nas izjemno pomembno, da lahko procesiramo. podatki so tam, kjer so shranjeni. To prihrani ogromno računalniških virov. Tarantool DBMS v tem projektu uporabljamo od leta 2016 in zaenkrat na obzorju ne vidimo njegove zamenjave. Prilagodljivo, z optimalno porabo virov, več kot ustrezno tehnično podporo. Tarantool implementira tudi GIS modul. Seveda ni tako zmogljiv kot PostGIS, vendar je dovolj za naše naloge shranjevanja nekaterih metrik, povezanih z lokacijo (pomembno za transport).
3. Vizualizacija metrik
   Tukaj je vse razmeroma preprosto. Podatke zajemamo iz skladišča in jih prikazujemo v realnem času ali za nazaj.
4. Sinhronizacija podatkov s centralnim nadzornim sistemom.
   Centralni nadzorni sistem sprejema podatke iz vseh naprav, jih shrani z določeno zgodovino in jih prek API-ja pošlje v nadzorni sistem stranke. Za razliko od klasičnih nadzornih sistemov, pri katerih »glava« hodi naokoli in zbira podatke, imamo obratno shemo. Naprave same pošiljajo podatke, ko obstaja povezava. To je zelo pomembna točka, saj vam omogoča prejemanje podatkov iz naprave za tista časovna obdobja, v katerih niso bili na voljo, in ne nalaganje kanalov in virov, medtem ko naprava ni na voljo. Kot centralni nadzorni sistem uporabljamo nadzorni strežnik Influx. Za razliko od analogov lahko uvozi retrospektivne podatke (torej z drugačnim časovnim žigom od trenutka prejema metrike).Zbrane metrike vizualizira Grafana, spremenjeno z datoteko. Ta standardni sklad je bil izbran tudi zato, ker ima že pripravljene integracije API s skoraj vsemi sistemi za spremljanje strank.
5. Sinhronizacija podatkov s centralnim sistemom za upravljanje naprav.
   Sistem za upravljanje naprav izvaja Zero Touch Provisioning (posodabljanje vdelane programske opreme, konfiguracije itd.) in v nasprotju s sistemom za spremljanje prejema samo težave na napravo. To so sprožilci za delovanje vgrajenih storitev nadzornika strojne opreme in vseh meritev sistemov za vzdrževanje življenja: temperatura CPE in SSD, obremenitev CPE, prosti prostor in SMART zdravje na diskih. Podsistem za shranjevanje je prav tako zgrajen na Tarantool. To nam omogoča znatno hitrost pri združevanju časovnih vrst na tisoče naprav, prav tako pa popolnoma reši vprašanje sinhronizacije podatkov s temi napravami. Tarantool ima odličen sistem čakalne vrste in zajamčene dostave. To pomembno funkcijo smo dobili takoj, super!

Sistem za upravljanje omrežja

Kaj je naslednje?

Zaenkrat je naš najšibkejši člen centralni nadzorni sistem. Implementiran je 99.9 % na standardnem skladu in ima številne pomanjkljivosti:

1. InfluxDB izgubi podatke ob izpadu napajanja. Stranka praviloma sproti zbira vse, kar prihaja iz naprav, sama baza podatkov pa ne vsebuje podatkov, starejših od 5 minut, vendar bo to v prihodnosti lahko postalo težava.
2. Grafana ima kar nekaj težav z združevanjem podatkov in sinhronizacijo prikaza. Najpogostejša težava je, ko baza vsebuje časovno vrsto z intervalom 2 sekund, ki se začne od recimo 00:00:00, Grafana pa začne prikazovati podatke v agregaciji od +1 sekunde. Posledično uporabnik vidi plešoči graf.
3. Prevelika količina kode za integracijo API-ja s sistemi za spremljanje tretjih oseb. Lahko ga naredimo veliko bolj kompaktnega in ga seveda prepišemo v Go)

Mislim, da ste vsi dobro videli, kako Grafana izgleda in poznate njene težave tudi brez mene, zato objave ne bom preobremenila s slikami.

Zaključek

Namenoma nisem opisal tehničnih podrobnosti, ampak sem opisal le osnovno zasnovo tega sistema. Prvič, za tehnično popoln opis sistema bo potreben še en članek. Drugič, to ne bo zanimalo vseh. V komentarje napišite, katere tehnične podrobnosti bi radi vedeli.

Če ima kdo vprašanja, ki presegajo obseg tega članka, mi lahko pišete na a.rodin @ qedr.com

Vir: www.habr.com