TL; DR: Meie sisemise võrgukonfiguratsiooni haldussüsteemi QControl klient-server arhitektuuri kirjeldus. See põhineb kahekihilisel transpordiprotokollil, mis töötab gzip-pakitud sõnumitega ilma lõpp-punktide vahel dekompressioonita. Jaotatud ruuterid ja lõpp-punktid saavad konfiguratsioonivärskendusi ning protokoll ise võimaldab paigaldada lokaliseeritud vahereleed. Süsteem on üles ehitatud põhimõttel (“recent-stable”, selgitatud allpool) ja kasutab konfiguratsioonifailide renderdamiseks JMESpathi päringukeelt koos Jinja mallimootoriga.
Qrator Labs haldab ülemaailmselt hajutatud rünnakute leevendamise võrgustikku. Meie võrk töötab anycast põhimõttel ja alamvõrke reklaamitakse BGP kaudu. Kuna tegemist on BGP anycast-võrguga, mis asub füüsiliselt mitmes Maa piirkonnas, saame töödelda ja filtreerida ebaseaduslikku liiklust lähemale Interneti tuumale – 1. tasandi operaatoritele.
Teisest küljest pole geograafiliselt hajutatud võrguks olemine lihtne. Side võrgu kohalolekupunktide vahel on turvateenuse pakkuja jaoks kriitilise tähtsusega, et kõigi võrgusõlmede konfiguratsioon oleks ühtne, värskendades neid õigeaegselt. Seetõttu pidime tarbijale kõrgeima võimaliku põhiteenuse pakkumiseks leidma võimaluse konfiguratsiooniandmete usaldusväärseks sünkroonimiseks kontinentide lõikes.
Alguses oli Sõna. Sellest sai kiiresti uuendust vajav sideprotokoll.
QControli olemasolu nurgakivi ja samal ajal peamine põhjus, miks seda tüüpi protokolli loomiseks kulutatakse palju aega ja ressursse, on vajadus hankida üks autoriteetne konfiguratsiooniallikas ja lõpuks sünkroonida meie kohalolekupunktid. sellega. Salvestusruum ise oli vaid üks paljudest QControli arendamise nõuetest. Lisaks vajasime ka integreerimist olemasolevate ja kavandatavate teenustega kohalolekupunktides (POP), nutikaid (ja kohandatavaid) andmete valideerimise meetodeid ning juurdepääsu juhtimist. Lisaks soovisime sellist süsteemi juhtida ka käskude abil, mitte failides muudatuste tegemisega. Enne QControli saadeti andmed kohalolekupunktidesse peaaegu käsitsi. Kui üks kohalolekupunktidest pole saadaval ja unustasime selle hiljem värskendada, ei sünkrooni konfiguratsioon ja me peaksime selle taaskäivitamiseks aega raiskama.
Selle tulemusena jõudsime järgmise skeemini:
Konfiguratsiooniserver vastutab andmete valideerimise ja salvestamise eest; ruuteril on mitu lõpp-punkti, mis võtavad vastu ja edastavad konfiguratsioonivärskendusi klientidelt ja tugimeeskondadelt serverisse ning serverist kohalolekupunktidesse.
Interneti-ühenduse kvaliteet on maailmas endiselt väga erinev – selle punkti illustreerimiseks vaatame lihtsat MTR-i Prahast, Tšehhist Singapuri ja Hongkongini.
MTR Prahast Singapuri
Hongkongis sama lugu
Suur latentsusaeg tähendab väiksemat kiirust. Lisaks on paketikadu. Kanali laius ei kompenseeri seda probleemi, millega tuleb alati arvestada detsentraliseeritud süsteemide ehitamisel.
Kohalolekupunkti täielik konfiguratsioon on märkimisväärne hulk andmeid, mis tuleb saata paljudele adressaatidele ebausaldusväärsete ühenduste kaudu. Õnneks, kuigi konfiguratsioon muutub pidevalt, toimub see väikeste sammudena.
Hiljutine stabiilne disain
Võime öelda, et järkjärguliste värskenduste põhimõttel põhineva hajutatud võrgu ehitamine on üsna ilmne lahendus. Diffidega on aga palju probleeme. Peame salvestama kõik võrdluspunktide vahelised erinevused ja suutma need uuesti saata juhuks, kui kellelgi jäi osa andmetest kahe silma vahele. Iga sihtkoht peab neid rakendama rangelt määratud järjekorras. Tavaliselt võib mitme sihtkoha puhul selline toiming võtta kaua aega. Vastuvõtja peab saama ka puuduvaid osi nõuda ja loomulikult peab keskosa sellisele päringule korrektselt vastama, saates ainult puuduvad andmed.
Selle tulemusena jõudsime üsna huvitava lahenduseni - meil on ainult üks võrdluskiht, fikseeritud, nimetagem seda stabiilseks, ja selle jaoks ainult üks erinevus - hiljutine. Iga viimane põhineb viimati loodud tallil ja on piisav konfiguratsiooniandmete taastamiseks. Niipea, kui värske värske sihtkohta jõuab, pole vana enam vaja.
Jääb üle vaid aeg-ajalt värske stabiilne konfiguratsioon saata, näiteks kuna hiljutine on liiga suureks muutunud. Siin on oluline ka see, et saadame kõik need värskendused välja edastus-/multiedastusrežiimis, muretsemata üksikute adressaatide ja nende võime pärast andmeid kokku panna. Kui oleme kindlad, et kõigil on õige tall, saadame ainult uusi viimaseid. Kas tasub selgitada, et see toimib? Töötab. Stable salvestatakse vahemällu konfiguratsiooniserveris ja adressaatides, viimased luuakse vastavalt vajadusele.
Kahetasandilise transpordi arhitektuur
Miks ehitasime oma transpordi kahele tasandile? Vastus on üsna lihtne – soovisime marsruutimise lahti siduda kõrgetasemelisest loogikast, ammutades inspiratsiooni OSI mudelist koos selle transpordi- ja rakenduskihtidega. Transpordiprotokolli rolliks kasutasime Thrifti ja juhtsõnumite kõrgetasemelise vormingu jaoks serialiseerimisvormingut msgpack. See on põhjus, miks ruuter (teostab multisaadet/edastust/edastust) ei vaata msgpacki sisse, ei paki lahti ega paki sisu tagasi ning edastab ainult andmeid.
Thrift (inglise keelest - "thrift", hääldatakse [θrift]) on liidese kirjelduskeel, mida kasutatakse erinevate programmeerimiskeelte teenuste määratlemiseks ja loomiseks. See on kaugprotseduurikõnede (RPC) raamistik. Kombineerib tarkvarakonveieri koodigenereerimismootoriga, et arendada teenuseid, mis töötavad enam-vähem tõhusalt ja hõlpsalt erinevate keelte vahel.
Valisime Thrift raamistiku RPC ja paljude keelte toe tõttu. Nagu tavaliselt, olid lihtsad osad klient ja server. Ruuter osutus aga kõvaks pähkliks, osalt seetõttu, et meie arenduse käigus puudus valmislahendus.
On ka teisi võimalusi, näiteks protobuf / gRPC, kuid kui me oma projekti alustasime, oli gRPC üsna uus ja me ei julgenud seda kaasa võtta.
Muidugi oleksime võinud (ja tegelikult oleksime pidanud) oma ratta ehitada. Lihtsam oleks luua protokolli selle jaoks, mida vajame, kuna klient-serveri arhitektuuri on suhteliselt lihtne rakendada, võrreldes ruuteri ehitamisega Thriftis. Ühel või teisel viisil kaldutakse (põhjusel põhjusel) isekirjutatud protokollide ja populaarsete raamatukogude rakenduste poole; lisaks kerkib arutelude käigus alati küsimus: "Kuidas me seda teistesse keeltesse teisaldame?" Seega viskasime jalgratta idee kohe välja.
Msgpack on sarnane JSON-iga, kuid kiirem ja väiksem. See on kahendandmete serialiseerimisvorming, mis võimaldab vahetada andmeid mitme keele vahel.
Esimesel tasemel on meil Thrift minimaalse teabega, mis on ruuteri jaoks sõnumi edastamiseks vajalik. Teisel tasemel on pakitud msgpack-struktuurid.
Valisime msgpacki, kuna see on JSON-iga võrreldes kiirem ja kompaktsem. Kuid mis veelgi olulisem, see toetab kohandatud andmetüüpe, võimaldades meil kasutada lahedaid funktsioone, nagu töötlemata binaarfailide või spetsiaalsete objektide edastamine, mis näitavad andmete puudumist, mis oli meie hiljutise stabiilse skeemi jaoks oluline.
JMESPath
JMESPath on JSON-i päringukeel.
Täpselt selline näeb välja kirjeldus, mille saame ametlikust JMESPathi dokumentatsioonist, kuid tegelikult teeb see palju enamat. JMESPath võimaldab otsida ja filtreerida alampuid suvalises puustruktuuris ning rakendada andmetes muudatusi käigupealt. Samuti võimaldab see lisada spetsiaalseid filtreid ja andmete teisendusprotseduure. Kuigi selle mõistmine nõuab muidugi ajupingutust.
Jinja
Mõne tarbija jaoks peame muutma konfiguratsiooni failiks – seega kasutame mallimootorit ja Jinja on ilmselge valik. Tema abiga genereerime sihtpunkti saadud mallist ja andmetest konfiguratsioonifaili.
Konfiguratsioonifaili genereerimiseks vajame JMESPathi päringut, faili asukoha malli FS-is ja malli konfiguratsiooni enda jaoks. Samuti on hea mõte selles etapis selgitada faili õigusi. Kõik see ühendati edukalt ühte faili – enne konfiguratsioonimalli algust panime YAML-vormingus päise, mis kirjeldab ülejäänut.
Näiteks:
---
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) }}
Uue teenuse jaoks konfiguratsioonifaili tegemiseks lisame ainult uue mallifaili. Lähtekoodi ega tarkvara kohalolekupunktides muudatusi ei nõuta.
Mis on pärast QControli kasutuselevõttu muutunud? Esimene ja kõige olulisem asi on konfiguratsioonivärskenduste järjepidev ja usaldusväärne edastamine võrgu kõikidesse sõlmedesse. Teiseks saame meie tugimeeskonnalt ja ka teenuse tarbijatelt võimsa tööriista konfiguratsiooni kontrollimiseks ja selles muudatuste tegemiseks.
Seda kõike saime teha hiljutise stabiilse värskendusskeemi abil, et lihtsustada konfiguratsiooniserveri ja konfiguratsiooni saajate vahelist suhtlust. Kahekihilise protokolli kasutamine, et toetada sisust sõltumatut andmete marsruutimise viisi. Jinja-põhise konfiguratsiooni genereerimismootori integreerimine hajutatud filtreerimisvõrku õnnestus. See süsteem toetab laia valikut konfiguratsioonimeetodeid meie hajutatud ja heterogeensete välisseadmete jaoks.
Täname abi eest materjali kirjutamisel. , , .
postitus.
Allikas: www.habr.com