TL; DR: Sisäisen verkkokokoonpanon hallintajärjestelmämme QControl asiakas-palvelin-arkkitehtuurin kuvaus. Se perustuu kaksikerroksiseen siirtoprotokollaan, joka toimii gzip-pakattujen viestien kanssa ilman päätepisteiden välistä purkamista. Hajautetut reitittimet ja päätepisteet saavat kokoonpanopäivitykset, ja itse protokolla mahdollistaa paikallisten välireleiden asennuksen. Järjestelmä on rakennettu periaatteelle ("recent-stable", selitetty alla) ja käyttää JMESpath-kyselykieltä yhdessä Jinja-mallinnusmoottorin kanssa konfigurointitiedostojen hahmontamiseen.
Qrator Labs ylläpitää maailmanlaajuisesti hajautettua hyökkäystentorjuntaverkostoa. Verkkomme toimii anycast-periaatteella ja aliverkkoja mainostetaan BGP:n kautta. Koska BGP-anycast-verkko sijaitsee fyysisesti useilla maan alueilla, voimme käsitellä ja suodattaa laitonta liikennettä lähemmäs Internetin ydintä - Tier-1-operaattoreita.
Toisaalta maantieteellisesti hajautettu verkko ei ole helppoa. Viestintä verkon läsnäolopisteiden välillä on kriittinen tietoturvapalvelun tarjoajalle, jotta kaikki verkkosolmut voivat konfiguroida yhdenmukaisesti ja päivittää ne ajoissa. Siksi, jotta voimme tarjota kuluttajalle korkeimman mahdollisen peruspalvelun, meidän oli löydettävä tapa synkronoida määritystiedot luotettavasti eri mantereilla.
Alussa oli Sana. Siitä tuli nopeasti päivityksen tarpeessa oleva viestintäprotokolla.
QControlin olemassaolon kulmakivi ja samalla tärkein syy kuluttaa huomattava määrä aikaa ja resursseja tämänkaltaisen protokollan rakentamiseen on tarve saada yksi virallinen konfigurointilähde ja lopulta synkronoida läsnäolopisteemme. sen kanssa. Itse tallennustila oli vain yksi useista vaatimuksista QControlin kehittämisen aikana. Lisäksi tarvitsimme integraatioita olemassa oleviin ja suunniteltuihin läsnäolopisteiden (POP) palveluihin, älykkäitä (ja mukautettavia) menetelmiä tietojen validointiin sekä kulunvalvontaa. Tämän lisäksi halusimme myös ohjata tällaista järjestelmää komentojen avulla sen sijaan, että tekisimme muutoksia tiedostoihin. Ennen QControlia tiedot lähetettiin läsnäolopisteisiin lähes manuaalisesti. Jos jokin läsnäolopisteistä ei ollut käytettävissä ja unohdamme päivittää sen myöhemmin, kokoonpano ei ole synkronoitu ja joutuisimme tuhlaamaan aikaa sen saamiseen uudelleen käyttöön.
Tuloksena päädyimme seuraavaan kaavioon:
Konfigurointipalvelin vastaa tietojen validoinnista ja tallentamisesta; reitittimessä on useita päätepisteitä, jotka vastaanottavat ja lähettävät konfigurointipäivityksiä asiakkailta ja tukiryhmiltä palvelimelle ja palvelimelta läsnäolopisteisiin.
Internet-yhteyden laatu vaihtelee edelleen suuresti eri puolilla maailmaa – tämän asian havainnollistamiseksi katsotaanpa yksinkertaista MTR:ää Prahasta, Tšekin tasavallasta Singaporeen ja Hongkongiin.
MTR Prahasta Singaporeen
Sama asia Hongkongiin
Suuri latenssi tarkoittaa pienempää nopeutta. Lisäksi on pakettihäviöitä. Kanavan leveys ei kompensoi tätä ongelmaa, joka on aina otettava huomioon hajautettujen järjestelmien rakentamisessa.
Läsnäolopisteen täydellinen konfiguraatio on huomattava määrä tietoa, joka on lähetettävä monille vastaanottajille epäluotettavien yhteyksien kautta. Onneksi, vaikka kokoonpano muuttuu jatkuvasti, se tapahtuu pienin askelin.
Viimeaikainen vakaa muotoilu
Voidaan sanoa, että hajautetun verkon rakentaminen inkrementaalisten päivitysten periaatteella on melko ilmeinen ratkaisu. Mutta erojen kanssa on paljon ongelmia. Meidän on tallennettava kaikki vertailupisteiden väliset erot ja myös voitava lähettää ne uudelleen, jos joltakin puuttuu osa tiedoista. Jokaisen kohteen on käytettävä niitä tiukasti määritellyssä järjestyksessä. Usean määränpään tapauksessa tällainen toimenpide voi tyypillisesti kestää kauan. Vastaanottajan on myös voitava pyytää puuttuvat osat ja tietysti keskusosan on vastattava pyyntöön oikein lähettäen vain puuttuvat tiedot.
Tuloksena päädyimme melko mielenkiintoiseen ratkaisuun - meillä on vain yksi viitekerros, kiinteä, kutsukaamme sitä vakaaksi, ja sille vain yksi ero - uusi. Jokainen uusi perustuu viimeksi luotuun vakaaseen ja riittää konfigurointitietojen uudelleen rakentamiseen. Heti kun uusi tuore saavuttaa määränpäänsä, vanhaa ei enää tarvita.
Jäljelle jää vain lähettää uusi vakaa konfiguraatio ajoittain esimerkiksi siksi, että viimeaikaisesta on tullut liian suuri. Tärkeää tässä on myös se, että lähetämme kaikki nämä päivitykset lähetys-/multicast-tilassa murehtimatta yksittäisistä vastaanottajista ja heidän kyvystään koota dataa. Kun olemme varmoja, että kaikilla on oikea talli, lähetämme vain uudet viimeisimmät. Kannattaako selventää, että tämä toimii? Toimii. Stable tallennetaan välimuistiin määrityspalvelimelle ja vastaanottajille, viimeisimmät luodaan tarvittaessa.
Kaksitasoisen liikenteen arkkitehtuuri
Miksi rakensimme kuljetuksemme kahdelle tasolle? Vastaus on melko yksinkertainen - halusimme irrottaa reitityksen korkean tason logiikasta ottamalla inspiraatiota OSI-mallista sen kuljetus- ja sovelluskerroksineen. Käytimme Thriftiä siirtoprotokollan rooliin ja msgpack-serialisointimuotoa ohjausviestien korkean tason muotoon. Tästä syystä reititin (joka suorittaa monilähetyksen/lähetyksen/välityksen) ei katso msgpack-paketin sisään, ei pura tai pakkaa sisältöä takaisin, vaan lähettää vain dataa eteenpäin.
Thrift (englanniksi "thrift", lausutaan [θrift]) on käyttöliittymän kuvauskieli, jota käytetään palveluiden määrittämiseen ja luomiseen eri ohjelmointikielille. Se on kehys etäproseduurikutsuille (RPC). Yhdistää ohjelmistoputken koodintuotantomoottoriin kehittääkseen palveluita, jotka toimivat enemmän tai vähemmän tehokkaasti ja helposti eri kielten välillä.
Valitsimme Thrift-kehyksen RPC:n ja monien kielten tuen vuoksi. Kuten tavallista, helpot osat olivat asiakas ja palvelin. Reititin osoittautui kuitenkin kovaksi pähkinäksi, mikä johtui osittain valmiin ratkaisun puutteesta kehitystyömme aikana.
On muitakin vaihtoehtoja, kuten protobuf / gRPC, mutta kun aloitimme projektimme, gRPC oli melko uusi, emmekä uskaltaneet ottaa sitä mukaan.
Tietenkin olisimme voineet (ja itse asiassa olisi pitänyt) rakentaa oman pyörämme. Olisi helpompi luoda protokolla tarvitsemamme tarpeeseen, koska asiakas-palvelin-arkkitehtuuri on suhteellisen yksinkertaista toteuttaa verrattuna reitittimen rakentamiseen Thriftille. Tavalla tai toisella on olemassa perinteinen ennakkoluulo itsekirjoitettuja protokollia ja suosittujen kirjastojen toteutuksia kohtaan (hyvästä syystä); lisäksi keskusteluissa herää aina kysymys: "Kuinka aiomme siirtää tämän muille kielille?" Joten heitimme heti pois ajatuksen polkupyörästä.
Msgpack on samanlainen kuin JSON, mutta nopeampi ja pienempi. Se on binääritietojen serialisointimuoto, joka mahdollistaa tietojen vaihdon useiden kielten välillä.
Ensimmäisellä tasolla meillä on Thrift, joka sisältää vähimmäistiedot, joita reititin tarvitsee viestin välittämiseen. Toisella tasolla on pakatut msgpack-rakenteet.
Valitsimme msgpackin, koska se on nopeampi ja kompaktimpi verrattuna JSONiin. Mutta mikä vielä tärkeämpää, se tukee mukautettuja tietotyyppejä, jolloin voimme käyttää hienoja ominaisuuksia, kuten raakabinaarien tai erikoisobjektien välittämistä, jotka osoittavat tietojen puuttumisen, mikä oli tärkeää "äskettäin vakaalle" -järjestelmällemme.
JMESPath
JMESPath on JSON-kyselykieli.
JMESPathin virallisesta dokumentaatiosta saamamme kuvaus näyttää täsmälleen tältä, mutta itse asiassa se tekee paljon enemmän. JMESPathin avulla voit etsiä ja suodattaa alipuita mielivaltaisessa puurakenteessa ja tehdä muutoksia tietoihin lennossa. Sen avulla voit myös lisätä erityisiä suodattimia ja tietojen muunnosmenettelyjä. Vaikka sen ymmärtäminen vaatii tietysti aivoponnistusta.
Jinja
Joillekin kuluttajille meidän on muutettava kokoonpano tiedostoksi - joten käytämme mallimoottoria ja Jinja on ilmeinen valinta. Sen avulla luomme mallista ja määränpäähän vastaanotetuista tiedoista määritystiedoston.
Määritystiedoston luomiseksi tarvitsemme JMESPath-pyynnön, mallin tiedoston sijainnille FS:ssä ja mallin itse konfiguraatiolle. Tässä vaiheessa on myös hyvä selvittää tiedostojen käyttöoikeudet. Kaikki tämä yhdistettiin onnistuneesti yhdeksi tiedostoksi - ennen määritysmallin alkua laitoimme YAML-muodossa otsikon, joka kuvaa loput.
Esimerkiksi:
---
selector: "[@][[email protected]._meta.version == `42`] | items([0].fft_config || `{}`)"
destination_filename: "fft/{{ match[0] }}.json"
file_mode: 0644
reload_daemons: [fft]
...
{{ dict(match[1]) | json(indent=2, sort_keys=True) }}
Jotta uudelle palvelulle voidaan tehdä asetustiedosto, lisäämme vain uuden mallitiedoston. Lähdekoodiin tai ohjelmistoon ei vaadita muutoksia läsnäolopisteissä.
Mikä on muuttunut QControlin käyttöönoton jälkeen? Ensimmäinen ja tärkein asia on johdonmukainen ja luotettava konfiguraatiopäivitysten toimitus verkon kaikkiin solmuihin. Toinen on saada tukitiimimme sekä palvelun kuluttajien toimesta tehokas työkalu kokoonpanon tarkistamiseen ja siihen muutosten tekemiseen.
Pystyimme tekemään kaiken tämän käyttämällä viimeaikaista vakaata päivitysmallia yksinkertaistaaksemme konfigurointipalvelimen ja määritysten vastaanottajien välistä viestintää. Kaksikerroksisen protokollan käyttäminen tukemaan sisällöstä riippumatonta tapaa reitittää tietoja. Integroitu Jinja-pohjainen kokoonpanon luontimoottori onnistuneesti hajautettuun suodatusverkkoon. Tämä järjestelmä tukee laajaa valikoimaa konfigurointimenetelmiä hajautetuille ja heterogeenisille oheislaitteillemme.
Kiitos avustasi materiaalin kirjoittamisessa. , , .
lähettää.
Lähde: will.com