TL;DR: Meie sisemise võrgu konfiguratsioonihalduse süsteemi, QControl, kliendiserveri arhitektuuri kirjeldus. Selle aluseks on kahe tasandi transpordiprotoos, mis töötab gzip'i pakitud sõnumitega, ilma entrepoint'ide vahel dekompressioonita. Jaotatud ruuterid ja lõpp-punktid saavad konfiguratsiooni värskendusi, ning protokoll võimaldab lokaliseeritud vahepealsete releede seadmise. Süsteem on üles ehitatud (“recent-stable”, seletatakse allpool) ja kasutab JMESpathi päringukeelt koos Jinja templating süsteemiga konfiguratsioonifailide renderdamiseks.
Qrator Labs haldab globaalset jaotatud ründekaitsevõrku. Meie võrk töötab anycast'i põhimõttel ning alamvõrgud kuulutatakse välja BGP kaudu. Kuna oleme BGP anycast-võrk, mis on füüsiliselt paigutatud mitmesse maailma piirkonda, saame hallata ja filtreerida ebaseaduslikku liiklust lähemal interneti keskusele — Tier-1 operaatoritele.
Teisest küljest ei ole geograafiliselt jaotunud võrguna eksisteerimine lihtne. Suhtlus erinevate kohaloleku punktide vahel on kriitilise tähtsusega küberturvateenuste pakkujale, et tagada kõikide võrgu sõlmede kooskõlastatud konfiguratsioon ja nende õigeaegne uuendamine. Seetõttu, et pakkuda tarbijale maksimaalset võimalikku taset põhiteenusest, pidime leidma viisi, kuidas usaldusväärselt sünkroniseerida konfiguratsiooniteavet kontinenti vahel.
Alguses oli Sõna. See muutus kiiresti suhtlusprotokolliks, mis vajas uuendamist.
QControli eksistentsi nurgakivi ja samas põhjus, miks me kulutasime suure hulga aega ja ressursse sel delikaatse protokolli ülesehitamiseks, on vajadus saada ühtne usaldusväärne konfigureerimise allikas ja lõpuks sünkroonida meie kohaloleku punktid sellega. Isegi andmehoidla oli vaid üks mitmest nõudest QControli arendamise käigus. Lisaks sellele vajasime ka integratsiooni olemasolevate ja plaanitud teenustega kohaloleku punktides (KP), nutikaid (ja kohandatavaid) andmete valideerimise meetodeid ning juurdepääsu piiranguid. Samuti soovisime, et sellist süsteemi juhitaks käskude kaudu, mitte failide muutmisega. Enne QControlit saadeti andmed kohaloleku punktidesse peaaegu käsitsi. Kui üks kohaloleku punktidest oli ligipääsetav, ja me unustasime hiljem selle uuendada, jäi konfigureerimine sünkroonimata — pidime kulutama aega selle taastamiseks.
Lõpuks töötasime välja järgmise skeemi:
Konfiguratsiooniserver vastutab andmete valideerimise ja salvestamise eest, ruuteril on mitu lõpp-punkti, mis saavad ja edastavad konfiguratsiooniuuendusi klientidelt ja tugimeeskonnalt serverile ning serverist kohalolekupunktidele.
Interneti-ühenduse kvaliteet varieerub endiselt oluliselt üle maailma — et illustreerida seda väidet, vaatame lihtsat MTR-ed Pragsist, Tšehhi Vabariigist Singapuri ja Hongkongi.
MTR Pragsist Singapuri
Sama Hongkongi
Suured viivitused tähendavad väiksemat kiirus. Lisaks on ka pakettide kaotus. Kanalite laius ei kompenseeri seda probleemi, mis tuleb alati arvesse võtta detsentraliseeritud süsteemide loomisel.
Kohalolekupunkti täielik konfiguratsioon on märkimisväärne andmemaht, mida tuleb edastada paljudele saajatele ebastabiilsete ühenduste kaudu. Õnneks, ehkki konfiguratsioon muutub pidevalt, toimub see väikeste osadena.
recent-stable disain
Võib öelda, et jaotatud võrgu ehitamine inkrementaalsete uuenduste põhimõttel on üsna ilmne lahendus. Kuid diffidega on seotud palju probleeme. Me peame säilitama kõik diffid tugipunktide vahel ning suutma saata neid uuesti, kui keegi on osa andmetest maha jätnud. Igal sihtpunktil peab neid rakendama rangelt määratud järjestuses. T tavaliselt võib selline operatsioon mitme sihtpunkti puhul võtta pika aega. Saaja peab samuti suutma nõuda puuduvaid osi ja muidugi peab keskmine osa sellisele nõudmisele korrektselt vastama, saates ainult kadunud andmed.
Lõpuks jõudsime üsna huvitava lahenduseni — meil on ainult üks tugikiht, fikseeritud, nimetame seda stabiilseks, ja ainult üks diff selle jaoks — hiljuti. Iga hiljutine põhineb viimati loodud stabiilsel ja on piisav konfiguratsiooniliste andmete taastamiseks. Niipea kui värske hiljutine jõuab sihtkohta, ei ole vana enam vajalik.
Ainult aeg-ajalt tuleb saata värske stable konfiguratsioon, näiteks kuna recent on muutunud liiga suureks. Samuti on oluline, et me edastame kõik need uuendused broadcast/multicast režiimis, muretsemata üksikute vastuvõtjate ja nende võime kohta andmeid kokku panna. Niikaua kui oleme veendunud, et kõigil on korrektne stable, saadame ainult uusi recent. Kas tasub täpsustada, et see töötab? Töötab. Stable salvestatakse konfiguratsiooniserveris ja vastuvõtjates, recent luuakse vajadusel.
Kaks tasandit transporti arhitektuur
Miks me ehitasime meie transpordi kahel tasemel? Vastus on piisavalt lihtne — soovisime eraldada marsruutimise kõrgtasemest loogikast, tuginedes OSI mudeli transporditasemele ja rakendustasandile. Transpordiprotokollina kasutasime Thrift'i ning kõrgetasemelise juhtmessengeri formaadina msgpack'i serialiseerimisformaat. Just seetõttu ei vaata ruuter (mis teostab multicast/broadcast/relay) msgpack'i sisse, ei paketita ja ei lahti pakenda sisu ning teostab vaid andmete edastamise.
Thrift (ingl. k. 'ökonoomia', hääldus: [θrift]) on liideste kirjeldamise keel, mida kasutatakse teenuste määratlemiseks ja loomiseks erinevate programmeerimiskeelte jaoks. See on distantseeritud protseduurikutsumise (RPC) raamistik. See ühendab tarkvaratoru koodigeneratsiooni mootori teenuste arendamiseks, mis töötavad tõhusalt ja lihtsalt erinevate keelte vahel.
Valisime Thrift raamistiku RPC ja mitme keele toe tõttu. Nagu tavaliselt, olid kliendi ja serveri osad lihtsad. Kuid marsruuter osutus tõeliseks pähkliks, osalt seetõttu, et meie arenduse ajal ei olnud valmis lahendust.
On ka teisi võimalusi, nagu protobuf / gRPC, kuid kui me oma projekti alustasime, oli gRPC piisavalt noor ja me ei julgenud seda kasutada.
Loomulikult oleksime saanud (ja tegelikult oleks pidanud) oma ratast uuesti leiutama. Oleks olnud lihtsam luua protokoll, mis sobib meie vajadustega, kuna kliendi-serveri arhitektuur on rakendamiseks suhteliselt sirgjooneline võrreldes Thriftil põhineva marsruuteri loomisega. Ükskõik kuidas, on kohandatud protokollide ja populaarses teegis rakenduste arendamise puhul (mitte ilmaasjata) traditsiooniline eelarvamus, lisaks tõuseb arutelus alati küsimus: „Kuidas me selle teistesse keeltesse edastame?”. Seega eemaldusime kohe ratta leiutamise ideedest.
Msgpack on JSONi analoog, kuid kiirem ja väiksem. See on binaarne andmeserialiseerimise formaat, mis võimaldab andmeid vahetada paljude keelte vahel.
Esimese taseme kõige olulisem teave sõnumi edastamiseks on Thrift, sealhulgas minimaalne vajalik teave ruuteri kohta. Teisel tasemel on pakendatud struktuurid msgpack formaadis.
Valisime msgpack'i, kuna see on kiirem ja kompaktsem kui JSON. Kuid veelgi olulisem on, et see toetab kohandatud andmetüüpe, võimaldades meil kasutada edasiviajaid funktsioone, näiteks toorete binaaride edastamist või erilise objektide määratlemist, mis tähistavad andmete puudumist, mis oli meie "recent-stable" skeemi jaoks tähtis.
JMESPath
JMESPath on JSON-i päringukeel.
Nii näeb välja kirjeldus, mille saame JMESPath ametlikest dokumentidest, kuid tegelikult pakub see palju enamat. JMESPath võimaldab otsida ja filtreerida alampuud suvalises puustruktuuris ning rakendada andmetele muudatusi reaalajas. Samuti võimaldab see lisada erifiltreid ja andmete töötlemise protseduure. Kuigi see nõuab muidugi mõtte pingutust, et mõista.
Jinja
Mõnede tarbijate jaoks peame konfigureerimise faili vormindama — seetõttu kasutame šablooni mootori ja Jinja on ilmne valik. Selle abil genereerime konfigureerimisfaili šabloonist ja andmetest, mis saadakse sihtkohas.
Konfigureerimisfaili genereerimiseks vajame JMESPath'i päringut, šablooni faili asukoha määramiseks failisüsteemis ning šablooni konfiguraatsiooni enda jaoks. Samuti on sel etapil hea täpsustada faili juurdepääsuõigusi. Kõike seda õnnestub edukalt ühte faili kombineerida — konfigureerimisšablooni alguses paneme YAMLi formaadis pealkirja, mis kirjeldab ülejäänud.
Näiteks:
---
selector: "[@][?@.fft._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) }}
Uue teenuse konfigureerimisfaili valmistamiseks lisame ainult uue šabloonifaili. Ei ole vajalikud muudatused lähtekoodis või tarkvaras kohaloleku punktides.
Mis on muutunud pärast QControl'i sissetoomist operatiivsetesse tegevustesse? Esimene ja kõige olulisem on järjekindel ja usaldusväärne konfigureerimisuuenduste kohaletoimetamine kõikidesse võrgusõlmedesse. Teiseks on meie tugimeeskonna ja teenuse kasutajate jaoks saadud võimekas tööriist konfiguraatsiooni kontrollimiseks ja muutmiseks.
Me suutsime selle saavutada, rakendades recent-stable värskenduste skeemi, et lihtsustada suhtlemist konfiguratsiooniserveri ja konfiguratsioonisaajate vahel. Kasutades kaheastmelist protokolli, et toetada sisust sõltumatut andmete marsruutimise meetodit. Eduka Jinja-põhise konfiguratsioonigeneratsiooni mootori integreerimisega jaotatud filtrivõrku. See süsteem toetab laia valikut konfigureerimise viise meie jaotatud ja mitmekesise äärepoolse seadme jaoks.
Aitäh materjali kirjutamise eest , , .
post.
Allikas: habr.com
