Sistemi i menaxhimit të konfigurimit të rrjetit të filtrimit Qrator

Sistemi i menaxhimit të konfigurimit të rrjetit të filtrimit Qrator

TL;DR: PĂ«rshkrimi i arkitekturĂ«s klient-server tĂ« sistemit tonĂ« tĂ« brendshĂ«m tĂ« menaxhimit tĂ« konfiguracionit tĂ« rrjetit, QControl. NĂ« themel Ă«shtĂ« njĂ« protokoll transporti me dy nivele, i cili punon me mesazhe tĂ« paketuar nĂ« gzip pa dekodim midis pikave fundore. Routerat e shpĂ«rndarĂ« dhe piketat fundore marrin pĂ«rditĂ«sime tĂ« konfigurimeve, ndĂ«rsa protokolli lejon vendosjen e relave intermedia tĂ« lokalizuara. Sistemi Ă«shtĂ« ndĂ«rtuar sipas parimit tĂ« back-up-it diferencial (“recent-stable”, shpjegohet mĂ« poshtĂ«) dhe angazhon gjuhĂ«n e kĂ«rkesave JMESpath sĂ« bashku me motorin e shabllonĂ«ve Jinja pĂ«r renderimin e skedave tĂ« konfiguracionit.

Qrator Labs menaxhon njĂ« rrjet globalisht tĂ« shpĂ«rndarĂ« pĂ«r neutralizimin e sulmeve. Rrjeti ynĂ« punon sipas parimit anycast, ndĂ«rsa subnetet shpallen pĂ«rmes BGP. Duke qenĂ« njĂ« rrjet BGP anycast, i pozicionuar fizikisht nĂ« disa rajone tĂ« TokĂ«s, ne mund tĂ« procesojmĂ« dhe filtrojmĂ« trafik tĂ« paligjshĂ«m mĂ« afĂ«r thellĂ«sisĂ« sĂ« internetit — operatorĂ«ve Tier-1.

Nga ana tjetër, të jesh një rrjet geografiçisht të 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ë qëndrueshëm të të gjitha nyjeve të rrjetit, duke i përditësuar ato në kohë. Prandaj, me qëllim që t'i ofrojmë konsumatorit nivelin maksimum të mundshëm të shërbimit kryesor, na duhej të gjenim një mënyrë për të sinkronizuar besueshëm të dhënat e konfiguracionit midis kontinenteve.

Në fillim ishte Fjalë. Ajo shpejt u bë një protokoll komunikimi që kishte nevojë për përditësim.


Guri themelor tĂ« ekzistencĂ«s sĂ« QControl dhe njĂ«kohĂ«sisht arsyeja kryesore pĂ«r shpenzimin e njĂ« sasi tĂ« konsiderueshme kohĂ« dhe burimesh nĂ« ndĂ«rtimin e njĂ« protokolli tĂ« tillĂ« Ă«shtĂ« nevoja pĂ«r tĂ« marrĂ« njĂ« burim tĂ« vetĂ«m autoritar konfigurimi dhe, nĂ« fund tĂ« fundit, pĂ«r ta sinkronizuar atĂ« me pikat tona tĂ« pranishme. VetĂ« depoja ishte vetĂ«m njĂ« ndĂ«r disa kĂ«rkesa gjatĂ« zhvillimit tĂ« QControl. PĂ«rveç kĂ«saj, ne gjithashtu kishim nevojĂ« pĂ«r integrime me shĂ«rbime ekzistuese dhe tĂ« planifikuara nĂ« pikat e pranishme (TP), mĂ«nyra inteligjente (dhe tĂ« personalizueshme) tĂ« validimit tĂ« tĂ« dhĂ«nave, si dhe ndarjen e aksesit. PĂ«rveç kĂ«saj, ne gjithashtu donim tĂ« menaxhonim njĂ« sistem tĂ« tillĂ« me komandĂ«, dhe jo me modifikime nĂ« skedarĂ«. Para QControl, tĂ« dhĂ«nat u dĂ«rguan nĂ« pikat e pranishme praktikisht manualisht. NĂ«se njĂ«ra nga pikat e pranishme nuk ishte e disponueshme dhe ne e harronim ta pĂ«rditĂ«sonim mĂ« vonĂ«, konfigurimi pĂ«rfundonte i desinkronizuar — duhej tĂ« shpenzohej kohĂ« pĂ«r ta rikthyer atĂ« nĂ« funksion.

Në fund, ne hartuam skemën e mëposhtme:
Sistemi i menaxhimit të konfigurimit të rrjetit të filtrimit Qrator
Serveri i konfigurimit është përgjegjës për validimin e të dhënave dhe depozitimin, rrjeti ka disa pikë fundi që marrin dhe transmetojnë përditësime të konfigurimit nga klientët dhe ekipi i mbështetjes në server, dhe nga serveri në pikat e pranishme.

CilĂ«sia e lidhjes me internetin ende ndryshon ndjeshĂ«m nĂ« vende tĂ« ndryshme - pĂ«r tĂ« ilustruar kĂ«tĂ« tezĂ«, le tĂ« shikojmĂ« njĂ« MTR tĂ« thjeshtĂ« nga Praga, Çekia nĂ« Singapor dhe Hong Kong.

Sistemi i menaxhimit të konfigurimit të rrjetit të filtrimit Qrator
MTR nga Praga në Singapor

Sistemi i menaxhimit të konfigurimit të rrjetit të filtrimit Qrator
E njëjta gjë për në Hong Kong

Vonesa të larta do të thotë shpejtësi më të ulët. Përveç kësaj, ka humbje paketeshe. Gjerësia e kanaleve nuk kompenzon këtë problem, i cili duhet të merret përherë parasysh gjatë ndërtimit të sistemeve dekentrizuese.

Konfigurimi i plotë i pikës së pranishme është një volum i madh të dhënash që duhet të dërgohen te shumë marrës përmes lidhjeve të pasigurta. Fatmirësisht, megjithëse konfigurimi ndryshon vazhdimisht, kjo ndodh në mënyrë të vogël.

Dizajni recent-stable

ËshtĂ« e vlefshme tĂ« thuhet se ndĂ«rtimi i njĂ« rrjeti tĂ« distribuuar mbi parimin e pĂ«rditĂ«simeve inkrementale Ă«shtĂ« njĂ« zgjidhje mjaft e dukshme. Por ka shumĂ« probleme qĂ« lidhen me difĂ«t. Ne duhet tĂ« ruajmĂ« tĂ« gjitha difĂ«t midis pikave mbĂ«shtetĂ«se dhe gjithashtu tĂ« jemi nĂ« gjendje t'i dĂ«rgojmĂ« ato nĂ«se ndokush ka humbur ndonjĂ« pjesĂ« tĂ« tĂ« dhĂ«nave. Çdo pikĂ« destinacioni duhet t'i aplikojĂ« ato nĂ« njĂ« rend tĂ« caktuar. Zakonisht nĂ« rastin e disa pikave destinacioni, njĂ« operacion i tillĂ« mund tĂ« marrĂ« njĂ« kohĂ« tĂ« gjatĂ«. MarrĂ«si gjithashtu duhet tĂ« jetĂ« nĂ« gjendje tĂ« kĂ«rkojĂ« pjesĂ«t e humbura dhe, natyrisht, pjesa qendrore duhet tĂ« pĂ«rgjigjet saktĂ« ndaj kĂ«tij kĂ«rkesi, duke dĂ«rguar vetĂ«m tĂ« dhĂ«nat qĂ« janĂ« humbur.

Si rrjedhojĂ«, arritĂ«m nĂ« njĂ« zgjidhje shumĂ« interesante — kemi vetĂ«m njĂ« nivel mbĂ«shtetjesh, tĂ« palĂ«vizshme, ta quajmĂ« atĂ« stable, dhe vetĂ«m njĂ« diff pĂ«r tĂ« — recent. Çdo recent Ă«shtĂ« i bazuar nĂ« stable-n e fundit tĂ« formuar dhe Ă«shtĂ« i mjaftueshĂ«m pĂ«r riformatimin e tĂ« dhĂ«nave konfiguruese. Sa herĂ« qĂ« njĂ« recent i ri arrin nĂ« destinacion, i vjetri nuk Ă«shtĂ« mĂ« i nevojshĂ«m.

KĂ«shtu qĂ« mbetet tĂ« dĂ«rgojmĂ« herĂ« pas here konfigurimin e ri stable, pĂ«r shembull pĂ«r shkak se recent Ă«shtĂ« bĂ«rĂ« shumĂ« i madh. Gjithashtu Ă«shtĂ« e rĂ«ndĂ«sishme qĂ« ne dĂ«rgojmĂ« tĂ« gjitha kĂ«to pĂ«rditĂ«sime nĂ« mĂ«nyrĂ« broadcast/multicast, pa u shqetĂ«suar pĂ«r marrĂ«sit e veçantĂ« dhe aftĂ«sinĂ« e tyre pĂ«r tĂ« mbledhur copĂ«zat e tĂ« dhĂ«nave sĂ« bashku. Sa herĂ« qĂ« sigurohemi qĂ« çdo kush ka stable-n e duhur — ne dĂ«rgojmĂ« vetĂ«m recent-et e reja. A Ă«shtĂ« e nevojshme tĂ« saktĂ«sojmĂ« se kjo funksionon? Funksionon. Stable ruhet nĂ« serverin e konfigurimit dhe te marrĂ«sit, recent krijohet sipas nevojĂ«s.

Arkitektura e transportit me dy nivele

Pse e ndĂ«rtuam transportin tonĂ« nĂ« dy nivele? PĂ«gjigja Ă«shtĂ« mjaft e thjeshtĂ« — deshĂ«m tĂ« ndarim ĐŒĐ°Ń€ŃˆŃ€ŃƒŃ‚ĐžĐ·Đ°Ń†ĐžŃŽ nga logjika me nivel mĂ« tĂ« lartĂ«, duke u frymĂ«zuar nga modeli OSI me nivelin e tij tĂ« transportit dhe nivelin e aplikacioneve. PĂ«r rolin e protokollit tĂ« transportit, morĂ«m Thrift, dhe pĂ«r formatin me nivel mĂ« tĂ« lartĂ« tĂ« mesazheve tĂ« menaxhimit — formatin e serializimit msgpack. Kjo Ă«shtĂ« arsyeja pse router-i (i cili kryen multicast/broadcast/relay) nuk shikon brenda msgpack, nuk e ripakoton dhe nuk e paketizon pĂ«rmbajtjen pĂ«rsĂ«ri dhe kryen vetĂ«m pĂ«rcjelljen e tĂ« dhĂ«nave.

Thrift (nga anglisht "thrift", shqiptohet si [Ξrift]) Ă«shtĂ« njĂ« gjuhĂ« pĂ«r pĂ«rshkrimin e ndĂ«rfaqeve, e cila pĂ«rdoret pĂ«r tĂ« pĂ«rcaktuar dhe krijuar shĂ«rbime pĂ«r gjuhĂ« tĂ« ndryshme programimi. ËshtĂ« njĂ« framework pĂ«r thirrje proceduriale tĂ« largĂ«ta (RPC). Kombinon njĂ« pipeline programimi me njĂ« motor gjenerimi kodi pĂ«r zhvillimin e shĂ«rbimeve, qĂ« funksionojnĂ« nĂ« mĂ«nyrĂ« efektive dhe lehtĂ«sisht ndĂ«rmjet gjuhĂ«ve.

Ne përdorëm frameworkun Thrift për shkak të RPC dhe mbështetjes për shumë gjuhë. Si zakonisht, pjesët më të lehta ishin klienti dhe serveri. Megjithatë, router-i ishte një kokëfortë, pjesërisht për shkak të mungesës së një zgjidhjeje të gatshme gjatë zhvillimit tonë.

Sistemi i menaxhimit të konfigurimit të rrjetit të filtrimit QratorEkzistojnë edhe opsione të tjera, si protobuf / gRPC, megjithatë, kur filluam projektin tonë, gRPC ishte ende i ri dhe nuk e morëm në konsideratë.

Sigurisht, ne mund të kishim (dhe në të vërtetë, do kishte qenë më e mençur) të krijonim një "bicikletë" të vetën. Do të ishte 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 zbatuar krahas ndërtimit të një router-i mbi Thrift. Megjithatë, për çdo protokoll të vetë-krijuar dhe implementimin e bibliotekave të njohura (jo pa arsye) ekziston një paragjykim tradicional, përveç kësaj, gjithmonë lind pyetja: "Si do e portojmë këtë në gjuhë të tjera?". Prandaj, ne e hodhëm menjëherë idenë për një bicikletë.

Msgpack është një ekuivalent i JSON, por më i shpejtë dhe më i vogël. Ky është një format binar për serializimin e të dhënave, që lejon shkëmbimin e të dhënave midis një numri të madh gjuhësh.

NĂ« nivelin e parĂ« kemi Thrift me informacionin minimal tĂ« nevojshĂ«m pĂ«r router-in pĂ«r tĂ« dĂ«rguar mesazhin. NĂ« nivelin e dytĂ« – strukturat e paketuar msgpack.

Ne zgjodhëm msgpack sepse është më i shpejtë dhe më kompakt në krahasim me JSON. Por ajo që është edhe më e rëndësishme, mbështet tipe të dhënash të personalizuara, duke na lejuar të përdorim veçori të lezetshme si transmetimi i binarëve të papërpunuar ose objekteve të veçanta që përfaqësojnë mungesën e të dhënave, 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 të kërkosh dhe filtrosh nënstruktura në një strukturë sipërfaqësore të çfarëdo forme, si dhe të aplikosh ndryshime në të dhëna në kohën e duhur. Ai gjithashtu lejon shtimin e filtra-special dhe procedura transformimi të të dhënave. Megjithatë, natyrisht, kërkon një përpjekje mendore për ta kuptuar.

Jinja
PĂ«r disa pĂ«rdorues, na nevojitet tĂ« kthejmĂ« konfigurimin nĂ« njĂ« skedar — pĂ«r kĂ«tĂ« ne pĂ«rdorim motorin e shabllonĂ«ve dhe Jinja Ă«shtĂ« zgjedhja e dukshme. Me ndihmĂ«n e saj, ne gjenerojmĂ« skedarin e konfigurimit nga njĂ« shabllon dhe tĂ« dhĂ«nat e marra nĂ« vendin e caktuar.

PĂ«r tĂ« gjeneruar skedarin e konfigurimit na nevojitet njĂ« Đ·Đ°ĐżŃ€ĐŸŃ JMESPath, njĂ« shabllon pĂ«r vendndodhjen e skedarit nĂ« sistemin e skedarĂ«ve, dhe njĂ« shabllon pĂ«r vetĂ« konfigurimin. Gjithashtu, nĂ« kĂ«tĂ« fazĂ« Ă«shtĂ« mirĂ« tĂ« saktĂ«sojmĂ« tĂ« drejtat e qasjes nĂ« skedarin. TĂ« gjitha kĂ«to arritĂ«m t'i kombinojmĂ« me sukses nĂ« njĂ« skedarin — para fillimit tĂ« shabllonit tĂ« konfigurimit vendosim njĂ« titull nĂ« formatin YAML, i cili 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ë krijuar një skedar konfigurimi për shërbimin e ri ne shtojmë vetëm një skedar të ri shablloni. Nuk kërkohen ndryshime në kodin burimor apo në programin në pikat e pranishme.

ÇfarĂ« ka ndryshuar pas hyrjes nĂ« operacionet e QControl? E para dhe mĂ« e rĂ«ndĂ«sishmja — dorĂ«zimi konsistent dhe i besueshĂ«m i pĂ«rditĂ«simeve tĂ« konfigurimit nĂ« tĂ« gjithĂ« nyjet e rrjetit. E dyta — marrja e njĂ« mjeti tĂ« fuqishĂ«m pĂ«r kontrollin e konfigurimit dhe ndryshime tĂ« tij nga ekipi ynĂ« mbĂ«shtetĂ«s, si dhe nga konsumatorĂ«t e shĂ«rbimit.

Të gjitha 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ë konfigurimit. Përdorim një protokoll me dy nivele për të mbështetur një mënyrë ruterimi të dhënash të pa-varur nga përmbajtja. Me integrimin e suksesshëm të motorit të gjenerimit të konfigurimit 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ërndara dhe të larmishme.

Faleminderit për ndihmën në shkrimin e materialit. VolanDamrod, serenheit, NoN.

Versioni anglisht post.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster