TL; DR: Gure barne sarearen konfigurazioa kudeatzeko sistemaren bezero-zerbitzariaren arkitekturaren deskribapena, QControl. Bi geruzako garraio-protokolo batean oinarritzen da, gzip-n paketaturiko mezuekin funtzionatzen duena, amaierako puntuen artean deskonprimitu gabe. Banatutako bideratzaileek eta amaiera-puntuek konfigurazio-eguneratzeak jasotzen dituzte, eta protokoloak berak tarteko errele lokalizatuak instalatzea ahalbidetzen du. Sistema printzipioaren arabera eraikitzen da ("azken-egonkorra", behean azaltzen dena) eta JMESpath kontsulta-lengoaia erabiltzen du Jinja txantiloi-motorrekin batera konfigurazio fitxategiak errendatzeko.
Qrator Labs-ek mundu osoan banatutako erasoak arintzeko sare bat funtzionatzen du. Gure sareak anycast printzipioaren arabera funtzionatzen du eta azpisareak BGP bidez iragartzen dira. Lurreko hainbat eskualdetan fisikoki kokatuta dagoen BGP anycast sarea izanik, trafiko ilegala prozesatu eta iragazi dezakegu Interneten muinetik hurbilago - Tier-1 operadoreak.
Bestalde, geografikoki banatutako sare bat izatea ez da erraza. Sareko presentzia-puntuen arteko komunikazioa funtsezkoa da segurtasun-zerbitzu-hornitzaileak sare-nodo guztien konfigurazio koherentea izan dezan, garaiz eguneratuz. Hori dela eta, kontsumitzaileari oinarrizko zerbitzu-maila handiena eskaintzeko, kontinenteetan zehar konfigurazio-datuak modu fidagarrian sinkronizatzeko modu bat aurkitu behar genuen.
Hasieran Hitza zen. Azkar eguneratu behar zuen komunikazio protokolo bihurtu zen.
QControl-en existentziaren oinarria, eta, aldi berean, protokolo mota hau eraikitzeko denbora eta baliabide handia gastatzearen arrazoi nagusia, konfigurazio iturri autoritario bakarra lortu beharra da eta, azken finean, gure presentzia puntuak sinkronizatzea. horrekin. Biltegiratzea bera QControl-en garapenean hainbat eskakizunetako bat besterik ez zen. Horrez gain, presentzia puntuetan (POP) dauden eta aurreikusitako zerbitzuekin integrazioak ere behar genituen, datuak balioztatzeko metodo adimentsuak (eta pertsonalizagarriak), baita sarbideen kontrola ere. Honetaz gain, horrelako sistema bat ere kontrolatu nahi izan dugu komandoak erabiliz fitxategietan aldaketak egin beharrean. QControl aurretik, datuak presentzia puntuetara ia eskuz bidaltzen ziren. Presentzia punturen bat erabilgarri ez balego eta beranduago eguneratzea ahaztuko bagenu, konfigurazioa sinkronizatuta geratuko litzateke eta denbora galdu beharko genuke berriro martxan jartzen.
Ondorioz, eskema hau atera genuen:
Konfigurazio-zerbitzaria datuak baliozkotzeaz eta biltegiratzeaz arduratzen da; bideratzaileak bezeroen eta laguntza-taldeen konfigurazio-eguneratzeak jaso eta igortzen dituzten hainbat puntu ditu zerbitzarira, eta zerbitzaritik presentzia puntuetara.
Internet konexioaren kalitatea oraindik asko aldatzen da munduan zehar; puntu hau argitzeko, ikus dezagun Pragatik, Txekiar Errepublikatik Singapurretik eta Hong Kongera arteko MTR soil bat.
MTR Pragatik Singapurrera
Gauza bera Hong Kong-en
Latentzia handiak abiadura txikiagoa esan nahi du. Horrez gain, paketeen galera dago. Kanalaren zabalerak ez du arazo hori konpentsatzen, sistema deszentralizatuak eraikitzerakoan beti kontuan hartu behar dena.
Presentzia-puntu baten konfigurazio osoa datu-kopuru esanguratsua da, fidagarritasunik gabeko konexioen bidez hartzaile askori bidali behar zaiena. Zorionez, konfigurazioa etengabe aldatzen den arren, zati txikitan gertatzen da.
Azkenaldiko diseinu egonkorra
Eguneratze inkrementalen printzipioan oinarritutako sare banatu bat eraikitzea nahiko argia dela esan dezakegu. Baina arazo asko daude desberdinekin. Erreferentzia puntuen arteko desberdintasun guztiak gorde behar ditugu, eta, gainera, berriro bidaltzeko gai izan norbaitek datuen zati bat galdu badu. Destino bakoitzak zorrozki zehaztutako sekuentzian aplikatu behar ditu. Normalean, hainbat helmugaren kasuan, eragiketa horrek denbora luzea izan dezake. Hartzaileak ere falta diren zatiak eskatzeko gai izan behar du eta, noski, zati zentralak behar bezala erantzun behar dio eskaera horri, falta diren datuak soilik bidaliz.
Ondorioz, konponbide nahiko interesgarri batera iritsi ginen: erreferentzia-geruza bakarra dugu, finkoa, egonkorra dei dezagun, eta desberdin bakarra - azkena. Azken bakoitza sortutako azken egonkorrean oinarritzen da eta nahikoa da konfigurazio-datuak berreraikitzeko. Berri berria helmugara iritsi bezain laster, zaharra ez da beharrezkoa.
Noizean behin konfigurazio egonkor berri bat bidaltzea besterik ez da geratzen, adibidez, azkena handiegia bihurtu delako. Hemen ere garrantzitsua dena da eguneratze horiek guztiak igorpen/multicast moduan bidaltzen ditugula, hartzaile indibidualez eta datu-zatiak elkartzeko duten gaitasunez kezkatu gabe. Denek egonkor egokia dutela ziur gaudenean, azken berriak bakarrik bidaltzen ditugu. Merezi al du horrek funtzionatzen duela argitzea? Obrak. Egonkorra konfigurazio-zerbitzarian eta hartzaileek cachean gordetzen da, azkena behar bezala sortzen da.
Bi mailatako garraioaren arkitektura
Zergatik eraiki genuen gure garraioa bi mailatan? Erantzuna nahiko erraza da: bideraketa goi-mailako logikatik desakoplatu nahi genuen, OSI ereduan inspiratuta bere garraio eta aplikazio geruzekin. Garraio-protokoloaren funtziorako Thrift erabili dugu, eta msgpack serializazio formatua kontrol-mezuen goi-mailako formatuan. Horregatik bideratzaileak (multidifusioa/difusioa/erreleboa egiten du) ez du msgpack-en barruan begiratzen, ez du edukia deskonprimitzen edo itzultzen, eta datuak soilik birbidaltzen ditu.
Thrift (ingelesetik - "thrift", [ΞΈrift] ahoskatua) programazio hizkuntza ezberdinetarako zerbitzuak definitzeko eta sortzeko erabiltzen den interfazearen deskribapen-lengoaia da. Urruneko prozedura deien (RPC) esparru bat da. Software kanalizazio bat konbinatzen du kodea sortzeko motor batekin, hizkuntzen artean eraginkortasun gehiago edo gutxiago funtzionatzen duten zerbitzuak garatzeko.
Thrift esparrua aukeratu dugu RPCgatik eta hizkuntza askotarako laguntzagatik. Ohi bezala, zati errazak bezeroa eta zerbitzaria ziren. Hala ere, bideratzailea apurtzeko intxaur gogorra izan zen, neurri batean gure garapenean prest egindako irtenbiderik ez zegoelako.
Beste aukera batzuk ere badaude, hala nola protobuf / gRPC, hala ere, gure proiektua hasi genuenean, gRPC nahiko berria zen eta ez ginen ausartu hura hartzen.
Noski, geure bizikleta eraiki genezake (eta, hain zuzen ere, beharko genuke). Errazagoa izango litzateke behar dugunerako protokolo bat sortzea bezero-zerbitzariaren arkitektura nahiko erraza baita inplementatzeko Thrift-en bideratzaile bat eraikitzearekin alderatuta. Modu batean edo bestean, herri-liburutegien norberak idatzitako protokoloen eta inplementazioen aldeko joera tradizionala dago (arrazoi onarengatik); gainera, eztabaidetan beti sortzen da galdera: βNola eramango dugu hau beste hizkuntzetara?β. Beraz, berehala bota genuen bizikleta baten ideia.
Msgpack JSONen antzekoa da, baina azkarragoa eta txikiagoa. Datuak serializatzeko formatu bitar bat da, datuak hizkuntza anitzen artean trukatzeko aukera ematen duena.
Lehen mailan Thrift dugu bideratzaileak mezua birbidaltzeko beharrezkoa den gutxieneko informazioarekin. Bigarren mailan msgpack egiturak daude paketatuta.
msgpack aukeratu dugu JSONekin alderatuta azkarragoa eta trinkoagoa delako. Baina are garrantzitsuagoa dena, datu-mota pertsonalizatuak onartzen ditu, bitar gordinak edo daturik eza adierazten duten objektu bereziak pasatzea bezalako ezaugarri bikainak erabiltzeko aukera emanez, hori garrantzitsua zen gure "azkenaldiko" eskemarako.
JMESPath
JMESPath JSON kontsulta-lengoaia da.
Hau da, hain zuzen, JMESPath dokumentazio ofizialetik lortzen dugun deskribapena nolakoa den, baina, egia esan, hori baino askoz gehiago egiten du. JMESPath-ek zuhaitz-egitura arbitrario batean azpizuhaitzak bilatu eta iragazteko aukera ematen dizu, eta datuei aldaketak berehala aplikatzeko. Gainera, iragazki bereziak eta datuak eraldatzeko prozedurak gehitzeko aukera ematen du. Nahiz eta, noski, ulertzeko garunaren ahalegina eskatzen duen.
Jinja
Kontsumitzaile batzuentzat, konfigurazioa fitxategi batean bihurtu behar dugu; beraz, txantiloi-motorra erabiltzen dugu eta Jinja da aukera agerikoa. Bere laguntzarekin, helmugan jasotako txantiloitik eta datuetatik konfigurazio fitxategi bat sortzen dugu.
Konfigurazio-fitxategi bat sortzeko, JMESPath eskaera bat, FSko fitxategiaren kokapenaren txantiloia eta konfigurazio beraren txantiloia behar ditugu. Etapa honetan ere ideia ona da fitxategien baimenak argitzea. Hau guztia fitxategi batean ongi konbinatu zen - konfigurazio txantiloia hasi aurretik, gainontzekoak deskribatzen dituen YAML formatuan goiburu bat jarri genuen.
Adibidez:
---
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) }}
Zerbitzu berri baterako konfigurazio-fitxategi bat egiteko, txantiloi-fitxategi berria bakarrik gehitzen dugu. Ez da iturburu kodean edo softwarean aldaketarik behar presentzia puntuetan.
Zer aldatu da QControl zuzenean jarri zenetik? Lehenengo eta garrantzitsuena sareko nodo guztiei konfigurazio-eguneratzeak bidaltzea koherentea eta fidagarria da. Bigarrena, konfigurazioa egiaztatzeko eta aldaketak egiteko tresna indartsu bat jasotzea da gure laguntza-taldeak, baita zerbitzuaren kontsumitzaileek ere.
Hau guztia egin ahal izan dugu azken eguneratze-eskema egonkorra erabiliz konfigurazio-zerbitzariaren eta konfigurazio-hartzaileen arteko komunikazioa errazteko. Bi geruzako protokoloa erabiltzea datuak bideratzeko edukiaren arabera independentea den modu bat onartzeko. Arrakastaz integratu Jinja-n oinarritutako konfigurazioa sortzeko motorra banatutako iragazketa-sare batean. Sistema honek konfigurazio-metodo ugari onartzen ditu gure periferiko banatu eta heterogeneoetarako.
Eskerrik asko materiala idazteko laguntzagatik. , , .
mezua.
Iturria: www.habr.com