16 modems, 4 sellulêre operateurs = Uitgaande spoed 933.45 Mbit/s
Inleiding
Hallo! Hierdie artikel handel oor hoe ons 'n nuwe moniteringstelsel vir onsself geskryf het. Dit verskil van bestaandes in sy vermoë om hoëfrekwensie-sinchroniese maatstawwe en baie lae hulpbronverbruik te verkry. Die stemtempo kan 0.1 millisekondes bereik met 'n sinchronisasie-akkuraatheid tussen metrieke van 10 nanosekondes. Alle binêre lêers beslaan 6 megagrepe.
Oor die projek
Ons het 'n taamlik spesifieke produk. Ons produseer 'n omvattende oplossing vir die opsomming van die deurset en fouttoleransie van data-oordragkanale. Dit is wanneer daar verskeie kanale is, kom ons sê Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ Iets anders (5 Mbit/s), die resultaat is een stabiele en vinnige kanaal, waarvan die spoed iets soos hierdie: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.
Sulke oplossings is in aanvraag waar die kapasiteit van enige een kanaal onvoldoende is. Byvoorbeeld, vervoer, videobewakingstelsels en intydse videostroming, uitsaai van regstreekse televisie- en radio-uitsendings, enige voorstedelike fasiliteite waar daar onder die telekommunikasie-operateurs net verteenwoordigers van die Groot Vier is en die spoed op een modem/kanaal nie genoeg is nie .
Vir elk van hierdie gebiede produseer ons 'n aparte reeks toestelle, maar hul sagteware-deel is amper dieselfde en 'n hoë-gehalte moniteringstelsel is een van sy hoofmodules, sonder die korrekte implementering waarvan die produk nie moontlik sou wees nie.
In die loop van 'n paar jaar het ons daarin geslaag om 'n multi-vlak, vinnige, kruis-platform en liggewig moniteringstelsel te skep. Dit is wat ons met ons gerespekteerde gemeenskap wil deel.
Probleemstelling
Die moniteringstelsel verskaf statistieke van twee fundamenteel verskillende klasse: intydse statistieke en alle ander. Die moniteringstelsel het slegs die volgende vereistes gehad:
- Hoëfrekwensie sinchroniese verkryging van intydse statistieke en hul oordrag na die kommunikasiebestuurstelsel sonder versuim.
Hoë frekwensie en sinchronisasie van verskillende metrieke is nie net belangrik nie, dit is noodsaaklik vir die ontleding van die entropie van data-oordragkanale. As in een data-oordragkanaal die gemiddelde vertraging 30 millisekondes is, dan sal 'n fout in sinchronisasie tussen die oorblywende maatstawwe van net een millisekonde lei tot verswakking van die spoed van die resulterende kanaal met ongeveer 5%. As ons die tydsberekening met 1 millisekonde oor 4 kanale mistyd, kan die spoeddegradasie maklik tot 30% daal. Boonop verander entropie in kanale baie vinnig, so as ons dit minder as een keer elke 0.5 millisekondes meet, sal ons op vinnige kanale met 'n klein vertraging 'n hoë spoeddegradasie kry. Natuurlik is sulke akkuraatheid nie nodig vir alle metrieke nie en nie in alle toestande nie. Wanneer die vertraging in die kanaal 500 millisekondes is, en ons werk daarmee, dan sal 'n fout van 1 millisekonde amper nie opmerklik wees nie. Ook, vir lewensondersteuningstelsel-metrieke, het ons genoeg stem- en sinchronisasietempo's van 2 sekondes, maar die moniteringstelsel self moet met ultrahoë meningspeilingskoerse en ultra-presiese sinchronisasie van metrieke kan werk. - Minimale hulpbronverbruik en 'n enkele stapel.
Die eindtoestel kan óf 'n kragtige aan boord kompleks wees wat die situasie op die pad kan ontleed of biometriese opname van mense kan doen, óf 'n palmgrootte enkelbord rekenaar wat 'n spesiale magte soldaat onder sy lyfwapens dra om video in te stuur. reële tyd in swak kommunikasietoestande. Ten spyte van so 'n verskeidenheid argitekture en rekenaarkrag, wil ons graag dieselfde sagtewarestapel hê. - Sambreel argitektuur
Metrieke moet op die eindtoestel versamel en saamgevoeg word, plaaslik gestoor en intyds en terugwerkend gevisualiseer word. As daar 'n verbinding is, dra data oor na die sentrale moniteringstelsel. Wanneer daar geen verbinding is nie, moet die versendingtou ophoop en nie RAM verbruik nie. - API vir integrasie in die kliënt se moniteringstelsel, want niemand het baie moniteringstelsels nodig nie. Die kliënt moet data van enige toestelle en netwerke in 'n enkele monitering insamel.
Wat het gebeur
Om nie die reeds indrukwekkende langlees te belas nie, sal ek nie voorbeelde en metings van alle moniteringstelsels gee nie. Dit sal lei tot 'n ander artikel. Ek sal net sê dat ons nie 'n moniteringstelsel kon vind wat in staat is om twee metrieke gelyktydig te neem met 'n fout van minder as 1 millisekonde nie en wat ewe effektief werk op beide ARM-argitektuur met 64 MB RAM en op x86_64-argitektuur met 32 GB RAM. Daarom het ons besluit om ons eie te skryf, wat dit alles kan doen. Hier is wat ons gekry het:
Opsomming van die deurset van drie kanale vir verskillende netwerktopologieë
Visualisering van sommige sleutelmaatstawwe
Argitektuur
Ons gebruik Golang as die hoofprogrammeertaal, beide op die toestel en in die datasentrum. Dit het die lewe aansienlik vereenvoudig met die implementering van multitasking en die vermoë om een staties gekoppelde uitvoerbare binêre lêer vir elke diens te kry. As gevolg hiervan bespaar ons aansienlik in hulpbronne, metodes en verkeer vir die ontplooiing van die diens om toestelle te beëindig, ontwikkelingstyd en kodeontfouting.
Die stelsel word volgens die klassieke modulêre beginsel geïmplementeer en bevat verskeie substelsels:
- Metrieke registrasie.
Elke maatstaf word deur sy eie draad bedien en oor kanale gesinchroniseer. Ons kon sinchronisasie-akkuraatheid van tot 10 nanosekondes bereik. - Metrieke berging
Ons het gekies tussen die skryf van ons eie berging vir tydreekse of om iets te gebruik wat reeds beskikbaar was. Die databasis is nodig vir terugwerkende data wat onderhewig is aan daaropvolgende visualisering Dit wil sê, dit bevat nie data oor vertragings in die kanaal elke 0.5 millisekondes of foutlesings in die vervoernetwerk nie, maar daar is spoed op elke koppelvlak elke 500 millisekondes. Benewens die hoë vereistes vir kruisplatform en lae hulpbronverbruik, is dit vir ons uiters belangrik om te kan verwerk. data is waar dit gestoor word. Dit bespaar enorme rekenaarhulpbronne. Ons gebruik die Tarantool DBMS sedert 2016 in hierdie projek en tot dusver sien ons nie 'n plaasvervanger daarvoor op die horison nie. Buigsaam, met optimale hulpbronverbruik, meer as voldoende tegniese ondersteuning. Tarantool implementeer ook 'n GIS-module. Natuurlik is dit nie so kragtig soos PostGIS nie, maar dit is genoeg vir ons take om sommige liggingverwante statistieke (relevant vir vervoer) te stoor. - Visualisering van metrieke
Alles is relatief eenvoudig hier. Ons neem data uit die pakhuis en vertoon dit óf intyds óf retrospektief. - Sinchronisasie van data met die sentrale moniteringstelsel.
Die sentrale moniteringstelsel ontvang data van alle toestelle, stoor dit met 'n gespesifiseerde geskiedenis en stuur dit na die kliënt se moniteringstelsel via API. Anders as klassieke moniteringstelsels, waarin die “kop” rondloop en data insamel, het ons die teenoorgestelde skema. Die toestelle stuur self data wanneer daar 'n verbinding is. Dit is 'n baie belangrike punt, aangesien dit jou toelaat om data vanaf die toestel te ontvang vir daardie tydperke waartydens dit nie beskikbaar was nie en nie kanale en hulpbronne te laai terwyl die toestel nie beskikbaar is nie. Ons gebruik instromingsmoniteringbediener as 'n sentrale moniteringstelsel. Anders as sy analoë, kan dit terugwerkende data invoer (dit wil sê met 'n tydstempel wat verskil van die oomblik wat die metrieke ontvang is).Die versamelde metrieke word deur Grafana gevisualiseer, met 'n lêer gewysig. Hierdie standaardstapel is ook gekies omdat dit klaargemaakte API-integrasies met byna enige kliëntmoniteringstelsel het. - Datasinchronisasie met 'n sentrale toestelbestuurstelsel.
Die toestelbestuurstelsel implementeer Zero Touch Provisioning (opdatering van firmware, konfigurasie, ens.) en, anders as die moniteringstelsel, ontvang slegs probleme per toestel. Dit is snellers vir die werking van hardeware-waghonddienste aan boord en al die maatstawwe van lewensondersteuningstelsels: SVE- en SSD-temperatuur, SVE-lading, vrye spasie en SMART-gesondheid op skywe. Die substelselberging is ook gebou op Tarantool. Dit gee ons aansienlike spoed in die samevoeging van tydreekse oor duisende toestelle, en los ook die kwessie van sinchronisering van data met hierdie toestelle heeltemal op. Tarantool het 'n uitstekende toustaan- en gewaarborgde afleweringstelsel. Ons het hierdie belangrike kenmerk uit die boks gekry, wonderlik!
Netwerkbestuurstelsel
Wat is volgende?
Tot dusver is ons swakste skakel die sentrale moniteringstelsel. Dit word 99.9% op 'n standaardstapel geïmplementeer en het 'n aantal nadele:
- InfluxDB verloor data wanneer krag verloor word. As 'n reël versamel die kliënt dadelik alles wat van die toestelle af kom en die databasis self bevat nie data ouer as 5 minute nie, maar in die toekoms kan dit 'n pyn word.
- Grafana het 'n aantal probleme met data-aggregasie en sinchronisasie van die vertoon daarvan. Die mees algemene probleem is wanneer die databasis 'n tydreeks bevat met 'n interval van 2 sekondes vanaf, sê, 00:00:00, en Grafana begin data in samevoeging wys vanaf +1 sekonde. As gevolg hiervan, sien die gebruiker 'n dansende grafiek.
- Oormatige hoeveelheid kode vir API-integrasie met derdeparty-moniteringstelsels. Dit kan baie meer kompak gemaak word en natuurlik in Go herskryf word)
Ek dink julle het almal perfek gesien hoe Grafana lyk en ken sy probleme sonder my, so ek sal nie die post oorlaai met prentjies nie.
Gevolgtrekking
Ek het doelbewus nie die tegniese besonderhede beskryf nie, maar slegs die basiese ontwerp van hierdie stelsel beskryf. Eerstens, om die stelsel tegnies volledig te beskryf, sal nog 'n artikel vereis word. Tweedens sal nie almal hierin belangstel nie. Skryf in die kommentaar watter tegniese besonderhede jy graag wil weet.
As iemand vrae het buite die bestek van hierdie artikel, kan jy aan my skryf by a.rodin @ qedr.com
Bron: will.com