16 modeemia, 4 matkapuhelinoperaattoria = lähtönopeus 933.45 Mbit/s
Esittely
Hei! Tämä artikkeli kertoo, kuinka teimme uuden seurantajärjestelmän itsellemme. Se eroaa olemassa olevista kyvystään saada korkeataajuisia synkronisia mittareita ja erittäin alhaisella resurssien kulutuksella. Pollausnopeus voi olla 0.1 millisekuntia synkronointitarkkuuden ollessa 10 nanosekuntia. Kaikki binaaritiedostot vievät 6 megatavua.
О проекте
Meillä on melko erityinen tuote. Tuotamme kokonaisvaltaisen ratkaisun tiedonsiirtokanavien suorituskyvyn ja vikasietoisuuden yhteenvetoon. Tämä on kun kanavia on useita, oletetaan Operaattori1 (40Mbit/s) + Operaattori2 (30Mbit/s)+ Jotain muuta (5 Mbit/s), tuloksena on yksi vakaa ja nopea kanava, jonka nopeus tulee olemaan jotain tämä: (40+ 30+5)x0.92=75×0.92=69 Mbit/s.
Tällaisia ratkaisuja tarvitaan silloin, kun yhden kanavan kapasiteetti ei ole riittävä. Esimerkiksi liikenne, videovalvontajärjestelmät ja reaaliaikainen videon suoratoisto, suorien televisio- ja radiolähetysten lähetys, kaikki esikaupunkien tilat, joissa teleoperaattoreiden joukossa on vain suuren nelosen edustajia ja yhden modeemin/kanavan nopeus ei riitä .
Valmistamme kullekin alueelle erillisen laitesarjan, mutta niiden ohjelmisto-osa on lähes sama ja laadukas valvontajärjestelmä on yksi sen päämoduuleista, ilman jonka oikeaa toteutusta tuote ei olisi mahdollinen.
Useiden vuosien aikana onnistuimme luomaan monitasoisen, nopean, monialustaisen ja kevyen seurantajärjestelmän. Tämän haluamme jakaa arvostetun yhteisömme kanssa.
Ongelma
Valvontajärjestelmä tarjoaa kahden olennaisesti erilaisen luokan mittareita: reaaliaikaiset ja kaikki muut. Valvontajärjestelmällä oli vain seuraavat vaatimukset:
- Reaaliaikaisten mittareiden korkeataajuinen synkroninen hankinta ja niiden siirto viestintähallintajärjestelmästä ilman viiveitä.
Korkea taajuus ja eri mittareiden synkronointi ei ole vain tärkeää, se on elintärkeää tiedonsiirtokanavien entropian analysoinnissa. Jos yhdessä tiedonsiirtokanavassa keskimääräinen viive on 30 millisekuntia, niin vain yhden millisekunnin synkronointivirhe jäljellä olevien mittareiden välillä johtaa tuloksena olevan kanavan nopeuden heikkenemiseen noin 5 %. Jos ajoitamme ajoituksen väärin 1 millisekunnin 4 kanavalla, nopeuden heikkeneminen voi helposti pudota 30 prosenttiin. Lisäksi entropia kanavissa muuttuu hyvin nopeasti, joten jos mittaamme sen harvemmin kuin kerran 0.5 millisekunnissa, nopeilla kanavilla pienellä viiveellä saamme nopean huononemisen. Tällaista tarkkuutta ei tietenkään tarvita kaikille mittareille eikä kaikissa olosuhteissa. Kun kanavan viive on 500 millisekuntia ja työskentelemme sen kanssa, 1 millisekunnin virhe on melkein huomaamaton. Myös elämän tukijärjestelmän mittareille meillä on tarpeeksi 2 sekunnin kysely- ja synkronointinopeudet, mutta itse valvontajärjestelmän on kyettävä toimimaan erittäin korkeilla kyselynopeuksilla ja erittäin tarkalla mittareiden synkronoinnilla. - Minimaalinen resurssien kulutus ja yksi pino.
Päätelaite voi olla joko tehokas aluksella oleva kompleksi, joka pystyy analysoimaan tien tilannetta tai suorittamaan ihmisten biometrisen tallentamisen, tai kämmenen kokoinen yhden kortin tietokone, jota erikoisjoukkojen sotilas käyttää panssariensa alla lähettääkseen videokuvaa. reaaliajassa huonoissa viestintäolosuhteissa. Arkkitehtuurien ja laskentatehon moninaisuudesta huolimatta haluaisimme saman ohjelmistopinon. - Sateenvarjo-arkkitehtuuri
Mittarit on kerättävä ja koottava päätelaitteessa, tallennettava paikallisesti ja visualisoitava reaaliajassa ja takautuvasti. Jos yhteys on, siirrä tiedot keskusvalvontajärjestelmään. Kun yhteyttä ei ole, lähetysjonon tulisi kerääntyä eikä kuluttaa RAM-muistia. - API integroitavaksi asiakkaan valvontajärjestelmään, koska kukaan ei tarvitse monia valvontajärjestelmiä. Asiakkaan tulee kerätä tiedot kaikista laitteista ja verkoista yhteen valvontaan.
Mitä tapahtui
Jotta en rasita jo ennestään vaikuttavaa pitkää lukua, en anna esimerkkejä ja mittauksia kaikista valvontajärjestelmistä. Tämä johtaa toiseen artikkeliin. Sanon vain, että emme löytäneet valvontajärjestelmää, joka pystyisi ottamaan kaksi mittaa samanaikaisesti alle 1 millisekunnin virheellä ja joka toimii yhtä tehokkaasti sekä ARM-arkkitehtuurissa 64 Mt RAM-muistilla että x86_64-arkkitehtuurissa 32:lla. GB RAM-muistia. Siksi päätimme kirjoittaa oman, joka voi tehdä kaiken tämän. Tässä on mitä saimme:
Yhteenveto kolmen kanavan suorituskyvystä eri verkkotopologioilla
Joidenkin keskeisten mittareiden visualisointi
Arkkitehtuuri
Käytämme Golangia pääohjelmointikielenä sekä laitteessa että datakeskuksessa. Se yksinkertaisti elämää huomattavasti käyttämällä moniajoa ja kykyä saada yksi staattisesti linkitetty suoritettava binaaritiedosto jokaista palvelua kohden. Tämän seurauksena säästämme merkittävästi resursseja, menetelmiä ja liikennettä palvelun käyttöönotossa loppulaitteisiin, kehitysaikaa ja koodin virheenkorjausta.
Järjestelmä on toteutettu klassisen modulaarisen periaatteen mukaisesti ja sisältää useita alajärjestelmiä:
- Mittareiden rekisteröinti.
Jokaista mittaria palvelee oma säikeensä ja se synkronoidaan kanavien välillä. Pystyimme saavuttamaan jopa 10 nanosekunnin synkronointitarkkuuden. - Mittareiden tallennus
Valitsimme, kirjoitimmeko aikasarjoille oman tallennustilan tai käytämme jotain, joka oli jo saatavilla. Tietokantaa tarvitaan jälkikäteen visualisoitaville tiedoille, eli se ei sisällä tietoja kanavan viiveistä 0.5 millisekunnin välein tai virhelukemista siirtoverkossa, vaan jokaisella rajapinnalla on nopeutta 500 millisekunnin välein. Korkeiden cross-platform-vaatimusten ja alhaisen resurssien kulutuksen lisäksi meille on erittäin tärkeää pystyä käsittelemään. tiedot ovat siellä, missä ne tallennetaan. Tämä säästää valtavia laskentaresursseja. Olemme käyttäneet Tarantool DBMS:ää tässä projektissa vuodesta 2016, emmekä toistaiseksi näe sille korvaavaa näkökulmaa. Joustava, optimaalinen resurssien kulutus, enemmän kuin riittävä tekninen tuki. Tarantool toteuttaa myös GIS-moduulin. Se ei tietenkään ole yhtä tehokas kuin PostGIS, mutta se riittää meidän tehtäviimme tallentaa joitain sijaintiin liittyviä mittareita (kuljetuksiin liittyviä). - Mittareiden visualisointi
Täällä kaikki on suhteellisen yksinkertaista. Otamme tiedot varastosta ja näytämme sen joko reaaliajassa tai jälkikäteen. - Tietojen synkronointi keskusvalvontajärjestelmän kanssa.
Keskusvalvontajärjestelmä vastaanottaa tiedot kaikilta laitteilta, tallentaa ne määritetyllä historialla ja lähettää sen asiakkaan valvontajärjestelmään API:n kautta. Toisin kuin klassisissa valvontajärjestelmissä, joissa "pää" kävelee ympäriinsä ja kerää tietoja, meillä on päinvastainen kaava. Laitteet itse lähettävät dataa, kun yhteys on olemassa. Tämä on erittäin tärkeä seikka, koska sen avulla voit vastaanottaa tietoja laitteesta niiltä ajanjaksoilta, joina se ei ollut käytettävissä, etkä lataa kanavia ja resursseja, kun laite ei ole käytettävissä. Käytämme Influx-seurantapalvelinta keskusvalvontajärjestelmänä. Toisin kuin sen analogit, se voi tuoda takautuvaa dataa (eli aikaleimalla, joka eroaa mittarin vastaanottamishetkestä) Kerätyt mittarit visualisoi Grafana, muokataan tiedostolla. Tämä standardipino valittiin myös siksi, että siinä on valmiit API-integraatiot lähes mihin tahansa asiakasvalvontajärjestelmään. - Tietojen synkronointi keskitetyn laitehallintajärjestelmän kanssa.
Laitehallintajärjestelmä toteuttaa Zero Touch Provisioningin (päivittää laiteohjelmiston, kokoonpanon jne.) ja vastaanottaa valvontajärjestelmästä poiketen vain ongelmat laitetta kohti. Nämä laukaisevat sisäisten laitteistojen vahtikoirapalveluiden toiminnan ja kaikkien elämää ylläpitävien järjestelmien mittareiden: CPU:n ja SSD:n lämpötilan, suorittimen kuormituksen, vapaan tilan ja SMART-kunnon levyillä. Myös osajärjestelmän tallennus on rakennettu Tarantoolille. Tämä antaa meille huomattavan nopeuden aikasarjojen kokoamisessa tuhansien laitteiden välillä ja ratkaisee myös täysin ongelman tietojen synkronoinnista näiden laitteiden kanssa. Tarantoolilla on erinomainen jonotus- ja toimitustakuujärjestelmä. Saimme tämän tärkeän ominaisuuden pakkauksesta, hienoa!
Verkonhallintajärjestelmä
Mitä seuraavaksi
Toistaiseksi heikoin lenkkimme on keskusvalvontajärjestelmä. Se on toteutettu 99.9 % vakiopinossa, ja sillä on useita haittoja:
- InfluxDB menettää tietoja, kun virta katkeaa. Asiakas kerää pääsääntöisesti ripeästi kaiken laitteilta tulevan eikä tietokanta itsessään sisällä yli 5 minuuttia vanhoja tietoja, mutta jatkossa tästä voi tulla tuskaa.
- Grafanalla on useita ongelmia tietojen yhdistämisessä ja näytön synkronoinnissa. Yleisin ongelma on, kun tietokanta sisältää aikasarjan 2 sekunnin välein alkaen esimerkiksi 00:00:00 ja Grafana alkaa näyttää dataa koottuna +1 sekunnista. Tämän seurauksena käyttäjä näkee tanssivan kaavion.
- Liian paljon koodia API-integraatioon kolmannen osapuolen valvontajärjestelmiin. Se voidaan tehdä paljon kompaktimmaksi ja tietysti kirjoittaa uudelleen Go:lla)
Luulen, että olette kaikki nähneet täydellisesti miltä Grafana näyttää ja tiedätte sen ongelmat ilman minua, joten en ylikuormita postausta kuvilla.
Johtopäätös
En tarkoituksella kuvaillut teknisiä yksityiskohtia, vaan kuvailin vain tämän järjestelmän perusrakennetta. Ensinnäkin järjestelmän teknisen täydellisen kuvaamiseksi tarvitaan toinen artikkeli. Toiseksi, kaikki eivät ole kiinnostuneita tästä. Kirjoita kommentteihin mitä teknisiä yksityiskohtia haluaisit tietää.
Jos jollain on kysymyksiä tämän artikkelin ulkopuolella, voit kirjoittaa minulle osoitteeseen a.rodin @ qedr.com
Lähde: will.com