TL; DR: Beskrywing van die kliënt-bediener-argitektuur van ons interne netwerkkonfigurasiebestuurstelsel, QControl. Dit is gebaseer op 'n twee-laag vervoer protokol wat werk met gzip-verpakte boodskappe sonder dekompressie tussen eindpunte. Verspreide routers en eindpunte ontvang konfigurasie-opdaterings, en die protokol self laat die installering van gelokaliseerde intermediêre relais toe. Die stelsel is gebou op die beginsel ("onlangs-stabiel", hieronder verduidelik) en gebruik die JMESpath-navraagtaal saam met die Jinja-sjabloonenjin om konfigurasielêers weer te gee.
Qrator Labs bedryf 'n wêreldwyd verspreide aanvalversagtende netwerk. Ons netwerk werk volgens die anycast-beginsel, en subnette word via BGP geadverteer. Aangesien ons 'n BGP anycast-netwerk is wat fisies in verskeie streke van die aarde geleë is, kan ons onwettige verkeer nader aan die kern van die internet verwerk en filter - Tier-1-operateurs.
Aan die ander kant is dit nie maklik om 'n geografies verspreide netwerk te wees nie. Kommunikasie tussen netwerkpunte van teenwoordigheid is van kritieke belang vir die sekuriteitsdiensverskaffer om 'n konsekwente opstelling van alle netwerknodusse te hê, wat hulle betyds bywerk. Daarom, om die hoogste moontlike vlak van kerndiens aan die verbruiker te verskaf, moes ons 'n manier vind om konfigurasiedata oor kontinente heen betroubaar te sinkroniseer.
In die begin was die Woord. Dit het vinnig 'n kommunikasieprotokol geword wat 'n opdatering benodig.
Die hoeksteen van QControl se bestaan, en terselfdertyd die hoofrede vir die besteding van 'n aansienlike hoeveelheid tyd en hulpbronne aan die bou van hierdie soort protokol, is die behoefte om 'n enkele gesaghebbende bron van konfigurasie te verkry en, uiteindelik, ons punte van teenwoordigheid te sinchroniseer daarmee saam. Die berging self was net een van verskeie vereistes tydens die ontwikkeling van QControl. Daarbenewens het ons ook integrasies met bestaande en beplande dienste by teenwoordigheidspunte (POP), slim (en aanpasbare) metodes vir datavalidering, asook toegangsbeheer nodig gehad. Behalwe dit, wou ons ook so 'n stelsel beheer deur opdragte te gebruik eerder as om wysigings aan lêers te maak. Voor QControl is data amper handmatig na teenwoordigheidspunte gestuur. As een van die teenwoordigheidspunte nie beskikbaar was nie en ons vergeet om dit later op te dateer, sal die konfigurasie nie gesinchroniseer word nie en sal ons tyd moet mors om dit weer aan die gang te kry.
As gevolg hiervan het ons met die volgende skema vorendag gekom:
Die konfigurasiebediener is verantwoordelik vir datavalidering en berging; die router het verskeie eindpunte wat konfigurasieopdaterings van kliënte en ondersteuningspanne na die bediener ontvang en uitsaai, en van die bediener na punte van teenwoordigheid.
Die kwaliteit van internetverbindings verskil steeds baie oor die wêreld – om hierdie punt te illustreer, kom ons kyk na 'n eenvoudige MTR van Praag, Tsjeggiese Republiek tot Singapoer en Hong Kong.
MTR van Praag na Singapoer
Dieselfde ding met Hong Kong
Hoë latensie beteken laer spoed. Daarbenewens is daar pakkieverlies. Kanaalwydte vergoed nie vir hierdie probleem nie, wat altyd in ag geneem moet word wanneer gedesentraliseerde stelsels gebou word.
Die volle konfigurasie van 'n punt van teenwoordigheid is 'n aansienlike hoeveelheid data wat aan baie ontvangers gestuur moet word oor onbetroubare verbindings. Gelukkig, hoewel die konfigurasie voortdurend verander, gebeur dit in klein inkremente.
Onlangse stabiele ontwerp
Ons kan sê dat die bou van 'n verspreide netwerk gebaseer op die beginsel van inkrementele opdaterings 'n redelik voor die hand liggende oplossing is. Maar daar is baie probleme met verskille. Ons moet al die verskille tussen die verwysingspunte stoor, en ook in staat wees om dit weer te stuur ingeval iemand 'n deel van die data gemis het. Elke bestemming moet dit in 'n streng gespesifiseerde volgorde toepas. Tipies, in die geval van verskeie bestemmings, kan so 'n operasie lank neem. Die ontvanger moet ook die ontbrekende dele kan aanvra en natuurlik moet die sentrale deel korrek op so 'n versoek reageer en slegs die ontbrekende data stuur.
As gevolg hiervan het ons by 'n taamlik interessante oplossing gekom - ons het net een verwysingslaag, vas, kom ons noem dit stabiel, en slegs een verskil daarvoor - onlangs. Elke onlangse is gebaseer op die laaste gegenereerde stal en is voldoende om die konfigurasiedata te herbou. Sodra die vars onlangse een sy bestemming bereik, is die ou een nie meer nodig nie.
Al wat oorbly, is om van tyd tot tyd 'n vars stabiele konfigurasie te stuur, byvoorbeeld omdat onlangs te groot geword het. Wat ook hier belangrik is, is dat ons al hierdie opdaterings in 'n uitsaai-/multicastmodus uitstuur, sonder om bekommerd te wees oor individuele ontvangers en hul vermoë om stukke data saam te voeg. Sodra ons seker is dat almal die korrekte stal het, stuur ons net nuwe onlangses. Is dit die moeite werd om te verduidelik dat dit werk? Werke. Stabiel is in die kas op die konfigurasiebediener en ontvangers, onlangse word geskep soos nodig.
Argitektuur van twee-vlak vervoer
Hoekom het ons ons vervoer op twee vlakke gebou? Die antwoord is redelik eenvoudig - ons wou roetering van hoëvlak-logika ontkoppel, met inspirasie uit die OSI-model met sy vervoer- en toepassingslae. Ons het Thrift gebruik vir die rol van die vervoerprotokol, en die msgpack-serialiseringsformaat vir die hoëvlakformaat van beheerboodskappe. Dit is hoekom die roeteerder (wat multicast/uitsaai/aflos uitvoer) nie binne-in msgpack kyk nie, nie die inhoud uitpak of terugpak nie, en net data aanstuur.
Thrift (van Engels - "thrift", uitgespreek [θrift]) is 'n koppelvlakbeskrywingstaal wat gebruik word om dienste vir verskillende programmeertale te definieer en te skep. Dit is 'n raamwerk vir afstandprosedure-oproepe (RPC). Kombineer 'n sagtewarepyplyn met 'n kodegenereringsenjin om dienste te ontwikkel wat min of meer doeltreffend en maklik tussen tale werk.
Ons het die Thrift-raamwerk gekies as gevolg van RPC en ondersteuning vir baie tale. Soos gewoonlik was die maklike dele die kliënt en bediener. Die router het egter geblyk 'n moeilike neut te wees om te kraak, deels weens die gebrek aan 'n klaargemaakte oplossing tydens ons ontwikkeling.
Daar is ander opsies, soos protobuf / gRPC, maar toe ons met ons projek begin het, was gRPC taamlik nuut en ons het nie gewaag om dit aan boord te neem nie.
Natuurlik kon ons (en moes eintlik) ons eie fiets gebou het. Dit sal makliker wees om 'n protokol te skep vir wat ons nodig het, want die kliënt-bediener-argitektuur is relatief eenvoudig om te implementeer in vergelyking met die bou van 'n router op Thrift. Op een of ander manier is daar 'n tradisionele vooroordeel teenoor selfgeskrewe protokolle en implementering van populêre biblioteke (met goeie rede); daarbenewens kom die vraag altyd tydens besprekings op: "Hoe gaan ons dit na ander tale oordra?" Ons het dus dadelik die idee van 'n fiets uitgegooi.
Msgpack is soortgelyk aan JSON, maar vinniger en kleiner. Dit is 'n binêre data-serialiseringsformaat waarmee data tussen verskeie tale uitgeruil kan word.
Op die eerste vlak het ons Thrift met die minimum inligting wat nodig is vir die router om die boodskap aan te stuur. Op die tweede vlak is daar verpakte bsgpack-strukture.
Ons het msgpack gekies omdat dit vinniger en meer kompak is in vergelyking met JSON. Maar nog belangriker, dit ondersteun pasgemaakte datatipes, wat ons in staat stel om koel kenmerke te gebruik soos die deurgee van rou binaries of spesiale voorwerpe wat die afwesigheid van data aandui, wat belangrik was vir ons "onlangse stabiele" skema.
JMESPath
JMESPath is 'n JSON-navraagtaal.
Dit is presies hoe die beskrywing lyk wat ons uit die amptelike JMESPath-dokumentasie kry, maar in werklikheid doen dit baie meer as dit. JMESPath laat jou toe om subbome in 'n arbitrêre boomstruktuur te soek en te filtreer, en veranderinge aan die data toe te pas. Dit laat jou ook toe om spesiale filters en datatransformasieprosedures by te voeg. Alhoewel dit natuurlik breinpoging verg om te verstaan.
Jinja
Vir sommige verbruikers moet ons die konfigurasie in 'n lêer verander - dus gebruik ons 'n sjabloonenjin en Jinja is die voor die hand liggende keuse. Met sy hulp genereer ons 'n konfigurasielêer uit die sjabloon en data wat by die bestemming ontvang is.
Om 'n konfigurasielêer te genereer, benodig ons 'n JMESPath-versoek, 'n sjabloon vir die lêerligging in die FS, en 'n sjabloon vir die konfigurasie self. Dit is ook 'n goeie idee om op hierdie stadium die lêertoestemmings te verduidelik. Dit alles is suksesvol gekombineer in een lêer - voor die aanvang van die konfigurasie sjabloon, het ons 'n kopskrif in YAML-formaat geplaas wat die res beskryf.
Byvoorbeeld:
---
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) }}
Om 'n konfigurasielêer vir 'n nuwe diens te maak, voeg ons slegs 'n nuwe sjabloonlêer by. Geen veranderinge aan die bronkode of sagteware op die punte van teenwoordigheid word vereis nie.
Wat het verander sedert QControl in werking gestel is? Die eerste en belangrikste ding is konsekwente en betroubare aflewering van konfigurasie-opdaterings aan alle nodusse in die netwerk. Die tweede is om 'n kragtige instrument te ontvang om die konfigurasie na te gaan en veranderinge daaraan te maak deur ons ondersteuningspan, sowel as deur verbruikers van die diens.
Ons kon dit alles doen deur die onlangse stabiele opdateringskema te gebruik om kommunikasie tussen die konfigurasiebediener en konfigurasie-ontvangers te vereenvoudig. Die gebruik van 'n twee-laag protokol om 'n inhoud-onafhanklike manier van roetering van data te ondersteun. Suksesvol geïntegreer 'n Jinja-gebaseerde konfigurasie generasie-enjin in 'n verspreide filternetwerk. Hierdie stelsel ondersteun 'n wye reeks konfigurasiemetodes vir ons verspreide en heterogene randapparatuur.
Dankie vir jou hulp met die skryf van die materiaal. , , .
Post.
Bron: will.com