TL; DR: Opis klijentsko-poslužiteljske arhitekture našeg internog sustava za upravljanje konfiguracijom mreže, QControl. Temelji se na dvoslojnom transportnom protokolu koji radi s porukama pakiranim u gzip bez dekompresije između krajnjih točaka. Distribuirani usmjerivači i krajnje točke primaju ažuriranja konfiguracije, a sam protokol dopušta instalaciju lokaliziranih međureleja. Sustav je izgrađen na principu ("recent-stable", objašnjeno u nastavku) i koristi jezik upita JMESpath zajedno s Jinja motorom za izradu predložaka za renderiranje konfiguracijskih datoteka.
Qrator Labs upravlja globalno distribuiranom mrežom za ublažavanje napada. Naša mreža radi na anycast principu, a podmreže se reklamiraju putem BGP-a. Budući da smo BGP anycast mreža fizički smještena u nekoliko regija na Zemlji, možemo obraditi i filtrirati nelegitimni promet bliže jezgri interneta - Tier-1 operaterima.
S druge strane, biti geografski distribuirana mreža nije lako. Komunikacija između mrežnih točaka prisutnosti ključna je za pružatelja sigurnosnih usluga kako bi imao dosljednu konfiguraciju svih mrežnih čvorova, ažurirajući ih na vrijeme. Stoga, kako bismo potrošaču pružili najvišu moguću razinu osnovne usluge, morali smo pronaći način za pouzdanu sinkronizaciju konfiguracijskih podataka na svim kontinentima.
U početku bijaše Riječ. Brzo je postao komunikacijski protokol kojemu je potrebno ažuriranje.
Kamen temeljac postojanja QControl-a, a ujedno i glavni razlog za trošenje značajne količine vremena i resursa na izgradnju ove vrste protokola, je potreba za dobivanjem jednog autoritativnog izvora konfiguracije i, u konačnici, sinkronizacijom naših točaka prisutnosti s tim. Sama pohrana bila je samo jedan od nekoliko zahtjeva tijekom razvoja QControla. Osim toga, trebale su nam i integracije s postojećim i planiranim uslugama na točkama prisutnosti (POP), pametne (i prilagodljive) metode provjere valjanosti podataka, kao i kontrola pristupa. Osim toga, željeli smo kontrolirati takav sustav pomoću naredbi, a ne mijenjati datoteke. Prije QControla, podaci su se gotovo ručno slali na točke prisutnosti. Ako je jedna od točaka prisutnosti bila nedostupna i zaboravili smo je ažurirati kasnije, konfiguracija bi završila izvan sinkronizacije i morali bismo gubiti vrijeme da je ponovno pokrenemo i pokrenemo.
Kao rezultat toga, došli smo do sljedeće sheme:
Konfiguracijski poslužitelj odgovoran je za provjeru valjanosti i pohranu podataka; usmjerivač ima nekoliko krajnjih točaka koje primaju i emitiraju ažuriranja konfiguracije od klijenata i timova za podršku poslužitelju, te od poslužitelja do točaka prisutnosti.
Kvaliteta internetske veze i dalje uvelike varira diljem svijeta - da bismo ilustrirali ovu tvrdnju, pogledajmo jednostavan MTR od Praga, Češke do Singapura i Hong Konga.
MTR od Praga do Singapura
Ista stvar za Hong Kong
Visoka latencija znači manju brzinu. Osim toga, postoji gubitak paketa. Širina kanala ne kompenzira ovaj problem, što se uvijek mora uzeti u obzir pri izgradnji decentraliziranih sustava.
Potpuna konfiguracija točke prisutnosti značajna je količina podataka koja se mora poslati velikom broju primatelja preko nepouzdanih veza. Srećom, iako se konfiguracija stalno mijenja, to se događa u malim koracima.
Nedavno stabilan dizajn
Možemo reći da je izgradnja distribuirane mreže na principu inkrementalnih ažuriranja prilično očito rješenje. Ali ima puno problema s razlikama. Moramo spremiti sve razlike između referentnih točaka, a također ih moći ponovno poslati u slučaju da je netko propustio dio podataka. Svako ih odredište mora primijeniti u strogo određenom slijedu. Tipično, u slučaju nekoliko odredišta, takva operacija može trajati dugo. Primatelj također mora biti u mogućnosti zatražiti dijelove koji nedostaju i, naravno, središnji dio mora ispravno odgovoriti na takav zahtjev, šaljući samo podatke koji nedostaju.
Kao rezultat toga, došli smo do prilično zanimljivog rješenja - imamo samo jedan referentni sloj, fiksni, nazovimo ga stabilni, i samo jedan diff za njega - recentni. Svaki nedavni temelji se na zadnjoj generiranoj stabilnoj i dovoljan je za ponovnu izgradnju konfiguracijskih podataka. Čim novi novi stigne na odredište, stari više nije potreban.
Sve što preostaje je s vremena na vrijeme poslati svježu stabilnu konfiguraciju, na primjer zato što je recent postao prevelik. Ono što je također važno ovdje je da šaljemo sva ova ažuriranja u načinu emitiranja/višestrukog slanja, bez brige o pojedinačnim primateljima i njihovoj sposobnosti da sastave dijelove podataka. Nakon što smo sigurni da svi imaju ispravnu stabilnu, šaljemo samo nove najnovije. Vrijedi li pojasniti da ovo radi? Djela. Stable je predmemorirana na konfiguracijskom poslužitelju i primateljima, recent se kreira po potrebi.
Arhitektura transporta na dvije razine
Zašto smo izgradili naš prijevoz na dvije razine? Odgovor je prilično jednostavan - htjeli smo odvojiti usmjeravanje od logike visoke razine, crpeći inspiraciju iz OSI modela s njegovim transportnim i aplikacijskim slojevima. Koristili smo Thrift za ulogu transportnog protokola, a msgpack format za serijalizaciju za format visoke razine kontrolnih poruka. Zbog toga usmjerivač (koji izvodi multicast/broadcast/relay) ne gleda u msgpack, ne raspakira niti pakira sadržaj natrag, već samo prosljeđuje podatke.
Thrift (od engleskog - “thrift”, izgovara se [θrift]) je jezik za opis sučelja koji se koristi za definiranje i kreiranje usluga za različite programske jezike. To je okvir za pozive udaljenih procedura (RPC). Kombinira softverski cjevovod s motorom za generiranje koda za razvoj usluga koje rade više ili manje učinkovito i jednostavno između jezika.
Odabrali smo okvir Thrift zbog RPC-a i podrške za mnoge jezike. Kao i obično, lakši dijelovi bili su klijent i poslužitelj. Međutim, ruter se pokazao tvrd orah, dijelom i zbog nedostatka gotovog rješenja tijekom našeg razvoja.
Postoje i druge opcije, kao što je protobuf / gRPC, međutim, kada smo započeli naš projekt, gRPC je bio prilično nov i nismo ga se usudili prihvatiti.
Naravno, mogli smo (i zapravo smo trebali) napraviti vlastiti bicikl. Bilo bi lakše stvoriti protokol za ono što nam je potrebno jer je klijent-poslužiteljska arhitektura relativno jednostavna za implementaciju u usporedbi s izgradnjom usmjerivača na Thriftu. Na ovaj ili onaj način, postoji tradicionalna pristranost prema samonapisanim protokolima i implementacijama popularnih biblioteka (s dobrim razlogom); osim toga, tijekom rasprava uvijek se postavlja pitanje: "Kako ćemo ovo prenijeti na druge jezike?" Stoga smo odmah odbacili ideju o biciklu.
Msgpack je sličan JSON-u, ali brži i manji. To je binarni format serijalizacije podataka koji omogućuje razmjenu podataka između više jezika.
Na prvoj razini imamo Thrift s minimumom informacija potrebnih da ruter proslijedi poruku. Na drugoj razini nalaze se pakirane strukture msgpacka.
Odabrali smo msgpack jer je brži i kompaktniji u usporedbi s JSON-om. Ali što je još važnije, podržava prilagođene tipove podataka, omogućujući nam korištenje zgodnih značajki poput prosljeđivanja neobrađenih binarnih datoteka ili posebnih objekata koji pokazuju odsutnost podataka, što je bilo važno za našu shemu "nedavno stabilna".
JMESPath
JMESPath je JSON upitni jezik.
Upravo ovako izgleda opis koji smo dobili iz službene JMESPath dokumentacije, ali zapravo, radi mnogo više od toga. JMESPath vam omogućuje pretraživanje i filtriranje podstabala u proizvoljnoj strukturi stabla i primjenu promjena podataka u hodu. Također vam omogućuje dodavanje posebnih filtara i postupaka transformacije podataka. Iako, naravno, za razumijevanje je potreban napor mozga.
Jinja
Za neke korisnike konfiguraciju trebamo pretvoriti u datoteku - stoga koristimo predložak i Jinja je očiti izbor. Uz njegovu pomoć generiramo konfiguracijsku datoteku iz predloška i podataka primljenih na odredištu.
Za generiranje konfiguracijske datoteke potreban nam je JMESPath zahtjev, predložak za lokaciju datoteke u FS-u i predložak za samu konfiguraciju. Također je dobra ideja u ovoj fazi razjasniti dopuštenja za datoteke. Sve je to uspješno spojeno u jednu datoteku – prije početka konfiguracijskog predloška stavili smo zaglavlje u YAML formatu koje opisuje ostalo.
Na primjer:
---
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) }}
Kako bismo napravili konfiguracijsku datoteku za novu uslugu, dodajemo samo novu datoteku predloška. Nisu potrebne promjene izvornog koda ili softvera na točkama prisutnosti.
Što se promijenilo otkad je QControl pušten u rad? Prva i najvažnija stvar je dosljedna i pouzdana isporuka ažuriranja konfiguracije svim čvorovima u mreži. Drugi je dobivanje moćnog alata za provjeru konfiguracije i izmjene u njoj od strane našeg tima za podršku, kao i od strane korisnika usluge.
Uspjeli smo sve to učiniti pomoću sheme nedavnog stabilnog ažuriranja kako bismo pojednostavili komunikaciju između konfiguracijskog poslužitelja i primatelja konfiguracije. Korištenje dvoslojnog protokola za podršku načinu usmjeravanja podataka neovisan o sadržaju. Uspješno integriran motor za generiranje konfiguracije temeljen na Jinji u distribuiranu mrežu filtriranja. Ovaj sustav podržava širok raspon konfiguracijskih metoda za naše distribuirane i heterogene periferije.
Hvala na pomoći u pisanju materijala. , , .
objaviti.
Izvor: www.habr.com