TL;DR: PĂ«rshkrimi i arhitekturĂ«s klient-server tĂ« sistemit tonĂ« tĂ« brendshĂ«m tĂ« menaxhimit tĂ« konfiguracionit tĂ« rrjetit, QControl. Baza e tij Ă«shtĂ« njĂ« protokoll transporti me dy nivele, i cili punon me mesazhe tĂ« kompresuara nĂ« gzip pa dekompresim midis pikave tĂ« fundit. Ruterat e shpĂ«rndarĂ« dhe piketat e fundit marrin pĂ«rditĂ«sime tĂ« konfiguracionit, ndĂ«rsa protokolli lejon vendosjen e relĂ«ve tĂ« ndĂ«rmjetme lokalizuara. Sistemi Ă«shtĂ« ndĂ«rtuar nĂ« parimin e (ârecent-stableâ, shpjegohet mĂ« poshtĂ«) dhe angazhon gjuhĂ«n e pyetjeve JMESpath sĂ« bashku me motorin e shablloneve Jinja pĂ«r renderimin e skedave tĂ« konfiguracionit.
Qrator Labs menaxhon njĂ« rrjet globalisht tĂ« shpĂ«rndarĂ« pĂ«r neutralizimin e sulmeve. Rrjeti ynĂ« funksionon sipas parimit anycast, dhe subnetet shpallin pĂ«rmes BGP. Si njĂ« rrjet BGP anycast, i pozicionuar fizikisht nĂ« disa rajone tĂ« TokĂ«s, ne mund tĂ« pĂ«rpunojmĂ« dhe filtroni trafikun e paligjshĂ«m mĂ« afĂ«r thelbit tĂ« internetit â operatorĂ«ve Tier-1.
Nga ana tjetër, të qenurit një rrjet gjeografikisht i shpërndarë nuk është e lehtë. Komunikimi midis pikave të pranishme të rrjetit është kritik për ofruesin e shërbimeve të sigurisë për të pasur një konfigurim të besueshëm të të gjithë nyjeve të rrjetit, duke i përditësuar ato në mënyrë të duhur. Prandaj, për të siguruar nivelin më të lartë të mundshëm të shërbimit për konsumatorin, na duhej të gjenim një mënyrë për të sinkronizuar me besueshmëri të dhënat konfiguruese ndërmjet kontinenteve.
Në fillim ishte Fjala. Ajo u bë shpejt një protokoll komunikimi që kishte nevojë për përditësim.
The cornerstone of QControl's existence and the main reason for spending significant time and resources on building this type of protocol is the need to obtain a single authoritative source of configuration and ultimately synchronize our points of presence with it. The storage itself was just one of several requirements during the development of QControl. In addition, we also needed integrations with existing and planned services at the points of presence (PP), smart (and customizable) data validation methods, as well as access control. Furthermore, we wanted to manage such a system through commands, rather than modifying files. Before QControl, data was sent to the points of presence almost manually. If one of the points of presence became unavailable and we forgot to update it later, the configuration would become unsynchronized, requiring time to restore it.
As a result, we came up with the following scheme:
Serveri i konfigurimit është përgjegjës për validimin e të dhënave dhe ruajtjen e tyre, routeri ka disa endpoint-e që marrin dhe transmetojnë azhurnimet e konfigurimit nga klientët dhe ekipi mbështetës në server, dhe nga serveri në pikëprerjet.
CilĂ«sia e lidhjes me internetin akoma ndryshon ndjeshĂ«m nĂ« pjesĂ« tĂ« ndryshme tĂ« botĂ«s â pĂ«r tĂ« ilustruar kĂ«tĂ« tezĂ«, le tĂ« shikojmĂ« njĂ« MTR tĂ« thjeshtĂ« nga Praga, Republika Ăeke nĂ« Singapor dhe Hong Kong.
MTR nga Praga në Singapor
E njëjta gjë në Hong Kong
Vonesa të larta nënkuptojnë shpejtësi më të ulët. Përveç kësaj, ka humbje paketa. Gjerësia e kanaleve nuk e kompenzon këtë problem, i cili duhet gjithmonë të merret parasysh kur ndërtohen sisteme të decentralizuara.
Konfigurimi i plotë i pikës së pranishme është një volum i konsiderueshëm të dhënash që duhet të dërgohet shumë marrësve përmes lidhjeve të papërcaktuara. Për fat të mirë, megjithëse konfigurimi ndryshon vazhdimisht, kjo ndodh në pjesë të vogla.
Dizajni recent-stable
Mund tĂ« thuhet se ndĂ«rtimi i njĂ« rrjeti tĂ« shpĂ«rndarĂ« sipas parimit tĂ« pĂ«rditĂ«simeve inkrementale Ă«shtĂ« njĂ« zgjidhje mjaft e qartĂ«. Por, ka njĂ« numĂ«r tĂ« madh problemesh qĂ« lidhen me diffs. Na nevojitet tĂ« ruajmĂ« tĂ« gjitha diffs midis pikave referuese, si dhe tĂ« jemi nĂ« gjendje t'i dĂ«rgojmĂ« ato nĂ« rast se dikush ka humbur pjesĂ«n e tĂ« dhĂ«nave. Ădo destinacion duhet t'i aplikojĂ« ato nĂ« njĂ« rend tĂ« caktuar. Zakoniisht, nĂ« rastin e disa destinacioneve, njĂ« operacion i tillĂ« mund tĂ« marrĂ« njĂ« kohĂ« tĂ« gjatĂ«. MerrĂ«si gjithashtu duhet tĂ« jetĂ« nĂ« gjendje tĂ« kĂ«rkojĂ« pjesĂ«t e humbura dhe, sigurisht, pjesa qendrore duhet tĂ« pĂ«rgjigjet saktĂ« nĂ« njĂ« kĂ«rkesĂ« tĂ« tillĂ«, duke dĂ«rguar vetĂ«m tĂ« dhĂ«nat e humbura.
NĂ« fund, ne arritĂ«m nĂ« njĂ« zgjidhje mjaft interesante â kemi vetĂ«m njĂ« shtresĂ« referuese, tĂ« fiksuar, ta quajmĂ« atĂ« stable, dhe vetĂ«m njĂ« diff pĂ«r tĂ« â recent. Ădo recent mbĂ«shtetet nĂ« stable-n mĂ« tĂ« fundit tĂ« formuar dhe Ă«shtĂ« i mjaftueshĂ«m pĂ«r ri-gjenerimin e tĂ« dhĂ«nave konfiguruese. Sa herĂ« qĂ« njĂ« recent i ri arrin nĂ« destinacion, ai i vjetĂ«r tashmĂ« nuk Ă«shtĂ« i nevojshĂ«m.
Mbete vetĂ«m tĂ« dĂ«rgoni herĂ« pas here njĂ« konfigurim stabil, pĂ«r shembull pĂ«r shkak se e fundit Ă«shtĂ« bĂ«rĂ« shumĂ« e madhe. Po ashtu e rĂ«ndĂ«sishme kĂ«tu Ă«shtĂ« se ne dĂ«rgojmĂ« tĂ« gjithĂ« kĂ«to pĂ«rditĂ«sime nĂ« mĂ«nyrĂ« tĂ« transmetimit/multicast, pa u shqetĂ«suar pĂ«r marrĂ«sit e veçantĂ« dhe aftĂ«sinĂ« e tyre pĂ«r tĂ« mbledhur copĂ«za tĂ« dhĂ«nash sĂ« bashku. Sapo tĂ« sigurohemi qĂ« tĂ« gjithĂ« kanĂ« njĂ« stabil tĂ« saktĂ« â ne dĂ«rgojmĂ« vetĂ«m tĂ« rejat e fundit. A duhet tĂ« theksohet se kjo funksionon? Funksionon. Stabil kesh-adohet nĂ« serverin e konfigurimit dhe tek marrĂ«sit, e fundit krijohet sipas nevojĂ«s.
Arkitektura e transportit me dy nivele
Pse e kemi ndërtuar transportin tonë në dy nivele? Pjesa e thjeshtë është se dëshironim të ndanim ruterimin nga logjika e nivelit të lartë, duke tërhequr frymëzim nga modeli OSI me nivelin e tij të transportit dhe nivelin e aplikacionit. Si protokoll transporti zgjodhëm Thrift, ndërsa për formatin e lartë të mesazheve menaxhuese, përdorëm formatin e serializimit msgpack. Kjo është arsyeja pse routeri (i cili realizon multicast/broadcast/relay) nuk shikon brenda msgpack, nuk e shpaketon dhe as e paketojnë përmbajtjen përsëri dhe thjesht kryen përcjelljen e të dhënave.
Thrift (nga anglishtja - "kursim", shqiptohet si [Ξrift]) është një gjuhë për përshkrimin e ndërfaqeve që përdoret për të përcaktuar dhe krijuar shërbime për gjuhë të ndryshme programimi. Ajo është një kornizë për thirrjen e procedurave të largëta (RPC). Kombinon një tubacion programor me një motor gjenerimi kodi për zhvillimin e shërbimeve, në një shkallë të caktuar duke funksionuar në mënyrë efektive dhe lehtë mes gjuhëve.
Ne morëm framework-un Thrift për shkak të RPC-së dhe mbështetjes për shumë gjuhë. Si zakonisht, pjesët e lehta ishin klienti dhe serveri. Megjithatë, router-i doli të ishte një gështenjë e fortë, pjesërisht për shkak të mungesës së një zgjidhjeje gati gjatë zhvillimit tonë.
Ka dhe mundësi të tjera, si protobuf / gRPC, megjithatë, kur ne filluam projektin tonë, gRPC ishte akoma mjaft i ri dhe nuk guxuam ta merrnim në bord.
Sigurisht, mund ta bënim (dhe në fakt, do ta kishte pasur kuptim) të krijonim një biçikletë të re. Do të kishte qenë më e lehtë të krijonim një protokoll për atë që na nevojitej, sepse arkitektura klient-server është relativisht e thjeshtë për t'u implementuar në krahasim me ndërtimin e një router-i mbi Thrift. Sidoqoftë, ekziston një paragjykim tradicional ndaj protokolleve dhe implementimeve të shkruara vetë (nuk është pa arsye), përveç kësaj, kur diskutohet gjithmonë ngrihet pyetja: "Si do ta portojmë këtë në gjuhë të tjera?". Prandaj, ne menjëherë hodhëm poshtë idetë për biçikleta.
Msgpack është një alternativë për JSON, por më e shpejtë dhe më e vogël. Ky është një format binar i serializimit të të dhënave, i cili lejon shkëmbeimin e të dhënave midis shumë gjuhëve.
NĂ« nivelin e parĂ« kemi Thrift me informacionin minimal tĂ« nevojshĂ«m pĂ«r ruterin pĂ«r dĂ«rgimin e mesazhit. NĂ« nivelin e dytĂ« â struktura tĂ« paketuara msgpack.
ZgjodhĂ«m msgpack sepse Ă«shtĂ« mĂ« i shpejtĂ« dhe mĂ« kompakt se JSON. Por çka Ă«shtĂ« mĂ« e rĂ«ndĂ«sishme, mb suporton lloje tĂ« dhĂ«nash tĂ« personalizuara, duke na lejuar tĂ« pĂ«rdorim karakteristika interesante si dĂ«rgimi i binarĂ«ve tĂ« papĂ«rpunuar ose objekteve speciale qĂ« shĂ«nojnĂ« mungesĂ«n e tĂ« dhĂ«nave, gjĂ« qĂ« ishte e rĂ«ndĂ«sishme pĂ«r skemĂ«n tonĂ« ârecent-stableâ.
JMESPath
JMESPath është një gjuhë pyetjesh për JSON.
Kështu duket përshkrimi që marrim nga dokumentacioni zyrtar i JMESPath, por në të vërtetë, ai ofron shumë më tepër. JMESPath lejon kërkimin dhe filtrimin e nënpemeve në një strukturë të çfarëdo ndjese, si dhe aplikimin e ndryshimeve në të dhëna në kohë reale. Ai gjithashtu lejon shtimin e filtreve speciale dhe procedurave të transformimit të të dhënave. Megjithatë, kërkon sigurisht një përpjekje mendore për t'u kuptuar.
Jinja
PĂ«r disa konsumatorĂ«, na nevojitet tĂ« kthejmĂ« konfigurimin nĂ« njĂ« skedar â prandaj ne pĂ«rdorim njĂ« motor shabllonĂ«sh dhe Jinja Ă«shtĂ« zgjedhja e qartĂ«. Me ndihmĂ«n e saj, ne gjenerojmĂ« skedarin e konfigurimit nga shablli dhe tĂ« dhĂ«nat e marra nĂ« pikĂ«n e destinacionit.
PĂ«r tĂ« gjeneruar skedarin e konfigurimit, na nevojitet njĂ« kĂ«rkesĂ« JMESPath, njĂ« shabllon pĂ«r vendndodhjen e skedarit nĂ« FS, njĂ« shabllon pĂ«r vetĂ« konfigurimin. Po ashtu, nĂ« kĂ«tĂ« fazĂ« Ă«shtĂ« mirĂ« tĂ« sqarojmĂ« tĂ« drejtat e aksesit nĂ« skedar. TĂ« gjitha kĂ«to ia dolĂ«m t'i kombinojmĂ« me sukses nĂ« njĂ« skedar â para fillimit tĂ« shabllonit tĂ« konfigurimit vendosim njĂ« titull nĂ« formatin YAML, qĂ« pĂ«rshkruan tĂ« tjerat.
PĂ«r shembull:
---
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) }}
Për të bërë një skedar konfigurimi për shërbimin e ri, ne shtojmë vetëm një skedar të ri shablloni. Nuk kërkohen asnjë ndryshim në kodin burimor ose softuerin në pikat e pranishme.
ĂfarĂ« ka ndryshuar pas integrimit tĂ« QControl nĂ« veprimtarinĂ« operative? E para dhe mĂ« e rĂ«ndĂ«sishmja â njĂ« dorĂ«zim i qĂ«ndrueshĂ«m dhe tĂ« besueshĂ«m tĂ« pĂ«rditĂ«simeve tĂ« konfigurimit nĂ« tĂ« gjitha nyjat e rrjetit. E dyta â marrja e njĂ« ĐžĐœŃŃŃŃĐŒĐ”ĐœŃĐž tĂ« fuqishĂ«m pĂ«r kontrollin e konfigurimit dhe pĂ«r tĂ« bĂ«rĂ« ndryshime nga ekipi ynĂ« mbĂ«shtetje dhe pĂ«rdoruesit e shĂ«rbimit.
Këto arritëm t'i bëjmë duke përdorur skemën e përditësimeve recent-stable për të thjeshtuar komunikimin midis serverit të konfigurimit dhe marrësve të konfiguracionit. Përdorim një protokoll me dy nivele për të mbështetur një mënyrë të pavarur nga përmbajtja për ruterimin e të dhënave. Kemi integuar me sukses një motor gjenerimi konfiguracionesh të bazuar në Jinja në një rrjet të shpërndarë filtrimi. Ky sistem mbështet një gamë të gjerë mënyrash konfigurimi për periferi tonë të shpërndarë dhe të larmishme.
Faleminderit për ndihmën në shkrimin e materialit , , .
postës.
Burimi: habr.com
