TL; DR: Përshkrimi i arkitekturës klient-server të sistemit tonë të brendshëm të menaxhimit të konfigurimit të rrjetit, QControl. Ai bazohet në një protokoll transporti me dy shtresa që funksionon me mesazhe të mbushura me gzip pa dekompresim midis pikave fundore. Ruterat dhe pikat fundore të shpërndarë marrin përditësime të konfigurimit dhe vetë protokolli lejon instalimin e releve të ndërmjetme të lokalizuara. Sistemi është ndërtuar mbi parimin (“recent-stable”, shpjeguar më poshtë) dhe përdor gjuhën e pyetjeve JMESpath së bashku me motorin e modelimit Jinja për të dhënë skedarët e konfigurimit.
Qrator Labs operon një rrjet të shpërndarë globalisht për zbutjen e sulmeve. Rrjeti ynë funksionon në parimin anycast, dhe nënrrjetet reklamohen nëpërmjet BGP. Duke qenë një rrjet BGP anycast i vendosur fizikisht në disa rajone të Tokës, ne mund të përpunojmë dhe filtrojmë trafikun e paligjshëm më afër bërthamës së Internetit - operatorët Tier-1.
Nga ana tjetër, të jesh një rrjet i shpërndarë gjeografikisht nuk është e lehtë. Komunikimi ndërmjet pikave të pranisë së rrjetit është kritik që ofruesi i shërbimit të sigurisë të ketë një konfigurim të qëndrueshëm të të gjitha nyjeve të rrjetit, duke i përditësuar ato në kohën e duhur. Prandaj, për t'i ofruar konsumatorit nivelin më të lartë të mundshëm të shërbimit bazë, na duhej të gjenim një mënyrë për të sinkronizuar në mënyrë të besueshme të dhënat e konfigurimit nëpër kontinente.
Në fillim ishte Fjala. Ai u bë shpejt një protokoll komunikimi që kishte nevojë për një përditësim.
Guri themeltar i ekzistencës së QControl, dhe në të njëjtën kohë arsyeja kryesore për shpenzimin e një sasie të konsiderueshme kohe dhe burimesh për ndërtimin e këtij lloj protokolli, është nevoja për të marrë një burim të vetëm autoritar të konfigurimit dhe, në fund të fundit, të sinkronizojmë pikat tona të pranisë. me të. Vetë ruajtja ishte vetëm një nga disa kërkesa gjatë zhvillimit të QControl. Përveç kësaj, ne kishim nevojë gjithashtu për integrime me shërbimet ekzistuese dhe të planifikuara në pikat e pranisë (POP), metoda të zgjuara (dhe të personalizueshme) të vërtetimit të të dhënave, si dhe kontrollin e aksesit. Përveç kësaj, ne gjithashtu donim të kontrollonim një sistem të tillë duke përdorur komanda në vend që të bënim modifikime në skedarë. Përpara QControl, të dhënat dërgoheshin në pikat e pranisë pothuajse manualisht. Nëse një nga pikat e pranisë nuk ishte e disponueshme dhe ne harronim ta përditësojmë më vonë, konfigurimi do të përfundonte jashtë sinkronizimit dhe do të duhej të humbnim kohë për ta rikthyer dhe funksionuar.
Si rezultat, ne dolëm me skemën e mëposhtme:
Serveri i konfigurimit është përgjegjës për vërtetimin dhe ruajtjen e të dhënave; ruteri ka disa pika fundore që marrin dhe transmetojnë përditësime të konfigurimit nga klientët dhe ekipet mbështetëse te serveri, dhe nga serveri në pikat e pranisë.
Cilësia e lidhjes së internetit ende ndryshon shumë në mbarë botën - për të ilustruar këtë pikë, le të shohim një MTR të thjeshtë nga Praga, Republika Çeke në Singapor dhe Hong Kong.
MTR nga Praga në Singapor
E njëjta gjë me Hong Kongun
Vonesa e lartë do të thotë shpejtësi më e ulët. Përveç kësaj, ka humbje të paketave. Gjerësia e kanalit nuk e kompenson këtë problem, i cili gjithmonë duhet të merret parasysh gjatë ndërtimit të sistemeve të decentralizuara.
Konfigurimi i plotë i një pike prezence është një sasi e konsiderueshme të dhënash që duhet t'u dërgohen shumë marrësve përmes lidhjeve jo të besueshme. Për fat të mirë, megjithëse konfigurimi ndryshon vazhdimisht, kjo ndodh në rritje të vogla.
Dizajn i qëndrueshëm i kohëve të fundit
Mund të themi se ndërtimi i një rrjeti të shpërndarë bazuar në parimin e përditësimeve në rritje është një zgjidhje mjaft e qartë. Por ka shumë probleme me dallimet. Ne duhet të ruajmë të gjitha ndryshimet midis pikave të referencës, dhe gjithashtu të jemi në gjendje t'i ridërgojmë ato në rast se dikush humbi një pjesë të të dhënave. Çdo destinacion duhet t'i zbatojë ato në një sekuencë të specifikuar rreptësisht. Në mënyrë tipike, në rastin e disa destinacioneve, një operacion i tillë mund të zgjasë shumë. Marrësi duhet gjithashtu të jetë në gjendje të kërkojë pjesët që mungojnë dhe, natyrisht, pjesa qendrore duhet t'i përgjigjet saktë një kërkese të tillë, duke dërguar vetëm të dhënat që mungojnë.
Si rezultat, arritëm në një zgjidhje mjaft interesante - kemi vetëm një shtresë referimi, të fiksuar, le ta quajmë të qëndrueshme, dhe vetëm një ndryshim për të - të fundit. Çdo i fundit bazohet në stabilin e fundit të gjeneruar dhe është i mjaftueshëm për të rindërtuar të dhënat e konfigurimit. Sapo e reja e freskët arrin destinacionin e saj, e vjetra nuk është më e nevojshme.
Gjithçka që mbetet është të dërgoni një konfigurim të ri të qëndrueshëm herë pas here, për shembull sepse kohët e fundit është bërë shumë i madh. Ajo që është gjithashtu e rëndësishme këtu është që ne t'i dërgojmë të gjitha këto përditësime në një modalitet transmetimi/multitransmetimi, pa u shqetësuar për marrësit individualë dhe aftësinë e tyre për të bashkuar pjesë të të dhënave. Pasi të jemi të sigurt se të gjithë kanë stallën e duhur, ne dërgojmë vetëm të reja të fundit. A ia vlen të sqarohet se kjo funksionon? Punimet. Stable ruhet në serverin e konfigurimit dhe marrësit, e fundit krijohet sipas nevojës.
Arkitektura e transportit me dy nivele
Pse e ndërtuam transportin tonë në dy nivele? Përgjigja është mjaft e thjeshtë - ne donim të shkëputnim rrugëzimin nga logjika e nivelit të lartë, duke marrë frymëzim nga modeli OSI me shtresat e tij të transportit dhe aplikimit. Ne përdorëm Thrift për rolin e protokollit të transportit dhe formatin e serializimit të msgpack për formatin e nivelit të lartë të mesazheve të kontrollit. Kjo është arsyeja pse ruteri (duke kryer multicast/transmetim/rele) nuk shikon brenda msgpack, nuk e shpaketon ose paketon përmbajtjen prapa dhe vetëm përcjell të dhëna.
Thrift (nga anglishtja - "thrift", shqiptuar [θrift]) është një gjuhë përshkrimi e ndërfaqes që përdoret për të përcaktuar dhe krijuar shërbime për gjuhë të ndryshme programimi. Është një kornizë për thirrjet e procedurave në distancë (RPC). Kombinon një tubacion softuerësh me një motor të gjenerimit të kodit për të zhvilluar shërbime që funksionojnë pak a shumë me efikasitet dhe lehtësi midis gjuhëve.
Ne zgjodhëm kornizën Thrift për shkak të RPC dhe mbështetjes për shumë gjuhë. Si zakonisht, pjesët e thjeshta ishin klienti dhe serveri. Sidoqoftë, ruteri doli të ishte një arrë e fortë për t'u çarë, pjesërisht për shkak të mungesës së një zgjidhjeje të gatshme gjatë zhvillimit tonë.
Ka opsione të tjera, si protobuf / gRPC, megjithatë, kur filluam projektin tonë, gRPC ishte mjaft i ri dhe ne nuk guxuam ta merrnim atë në bord.
Sigurisht, ne mund (dhe në fakt duhet të kishim) të ndërtonim biçikletën tonë. Do të ishte më e lehtë të krijonim një protokoll për atë që na nevojitet, sepse arkitektura klient-server është relativisht e thjeshtë për t'u zbatuar në krahasim me ndërtimin e një ruteri në Thrift. Në një mënyrë apo tjetër, ekziston një paragjykim tradicional ndaj protokolleve të vetë-shkruara dhe zbatimeve të bibliotekave të njohura (për arsye të mirë); përveç kësaj, gjatë diskutimeve gjithmonë lind pyetja: "Si do ta transferojmë këtë në gjuhë të tjera?" Kështu që menjëherë hodhëm idenë e një biçiklete.
Msgpack është i ngjashëm me JSON, por më i shpejtë dhe më i vogël. Është një format binar i serializimit të të dhënave që lejon shkëmbimin e të dhënave midis shumë gjuhëve.
Në nivelin e parë kemi Thrift me informacionin minimal të nevojshëm që ruteri të përcjellë mesazhin. Në nivelin e dytë ka struktura të paketuara msgpack.
Ne zgjodhëm msgpack sepse është më i shpejtë dhe më kompakt në krahasim me JSON. Por më e rëndësishmja, ai mbështet lloje të personalizuara të të dhënave, duke na lejuar të përdorim veçori të lezetshme si kalimi i binarëve të papërpunuar ose objekteve të veçanta që tregojnë mungesën e të dhënave, gjë që ishte e rëndësishme për skemën tonë "të qëndrueshme të kohëve të fundit".
JMESPath
JMESPath është një gjuhë pyetjesh JSON.
Pikërisht kështu duket përshkrimi që marrim nga dokumentacioni zyrtar JMESPath, por në fakt, ai bën shumë më tepër se kaq. JMESPath ju lejon të kërkoni dhe filtroni nënpemë në një strukturë arbitrare të pemës dhe të aplikoni ndryshime në të dhënat menjëherë. Gjithashtu ju lejon të shtoni filtra të veçantë dhe procedura të transformimit të të dhënave. Edhe pse, natyrisht, kërkon përpjekje të trurit për ta kuptuar.
Jinja
Për disa konsumatorë, ne duhet ta kthejmë konfigurimin në një skedar - kështu që ne përdorim një motor shabllon dhe Jinja është zgjedhja e dukshme. Me ndihmën e tij, ne gjenerojmë një skedar konfigurimi nga shablloni dhe të dhënat e marra në destinacion.
Për të gjeneruar një skedar konfigurimi, na duhet një kërkesë JMESPath, një shabllon për vendndodhjen e skedarit në FS dhe një shabllon për vetë konfigurimin. Është gjithashtu një ide e mirë që në këtë fazë të sqarohen lejet e skedarit. E gjithë kjo u kombinua me sukses në një skedar - para fillimit të shabllonit të konfigurimit, ne vendosëm një kokë në formatin YAML që përshkruan pjesën tjetër.
Për shembull:
---
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) }}
Për të krijuar një skedar konfigurimi për një shërbim të ri, ne shtojmë vetëm një skedar të ri shabllon. Nuk kërkohen ndryshime në kodin burimor ose në softuerin në pikat e pranisë.
Çfarë ka ndryshuar që kur QControl doli drejtpërdrejt? Gjëja e parë dhe më e rëndësishme është shpërndarja e qëndrueshme dhe e besueshme e përditësimeve të konfigurimit në të gjitha nyjet në rrjet. E dyta është të merrni një mjet të fuqishëm për të kontrolluar konfigurimin dhe për të bërë ndryshime në të nga ekipi ynë mbështetës, si dhe nga konsumatorët e shërbimit.
Ne ishim në gjendje t'i bënim të gjitha këto duke përdorur skemën e përditësimit të qëndrueshëm të fundit për të thjeshtuar komunikimin midis serverit të konfigurimit dhe marrësve të konfigurimit. Përdorimi i një protokolli me dy shtresa për të mbështetur një mënyrë të pavarur nga përmbajtja e kursimit të të dhënave. U integrua me sukses një motor gjenerimi i konfigurimit të bazuar në Jinja në një rrjet filtrimi të shpërndarë. Ky sistem mbështet një gamë të gjerë metodash konfigurimi për pajisjet tona periferike të shpërndara dhe heterogjene.
Faleminderit për ndihmën tuaj në shkrimin e materialit. , , .
postim.
Burimi: www.habr.com