TL; DR: Beskriuwing fan de client-tsjinner arsjitektuer fan ús ynterne netwurk konfiguraasje behear systeem, QControl. It is basearre op in twa-laach ferfier protokol dat wurket mei gzip-ynpakt berjochten sûnder dekompresje tusken einpunten. Ferspraat routers en einpunten ûntfange konfiguraasje updates, en it protokol sels lit de ynstallaasje fan pleatslike tuskenlizzende relays. It systeem is boud op it prinsipe ("resint-stabyl", hjirûnder útlein) en brûkt de JMESpath-fraachtaal tegearre mei de Jinja-sjabloanmotor om konfiguraasjebestannen wer te jaan.
Qrator Labs betsjinnet in wrâldwiid ferspraat netwurk foar oanfalsmitigaasje. Us netwurk wurket op it anycast-prinsipe, en subnets wurde advertearre fia BGP. As in BGP anycast-netwurk dat fysyk yn ferskate regio's fan 'e ierde leit, kinne wy illegitime ferkear ferwurkje en filterje tichter by de kearn fan it ynternet - Tier-1-operators.
Oan 'e oare kant is it net maklik om in geografysk ferspraat netwurk te wêzen. Kommunikaasje tusken netwurkpunten fan oanwêzigens is kritysk foar de befeiligingstsjinstferliener om in konsekwinte konfiguraasje te hawwen fan alle netwurkknooppunten, dy't se op 'e tiid bywurkje. Dêrom, om it heechst mooglike nivo fan kearntsjinst oan 'e konsumint te leverjen, moasten wy in manier fine om konfiguraasjegegevens betrouber te syngronisearjen oer kontininten.
Yn it begjin wie it Wurd. It waard rap in kommunikaasjeprotokol dat in update nedich wie.
De hoekstien fan it bestean fan QControl, en tagelyk de wichtichste reden foar it besteegjen fan in wichtige hoemannichte tiid en middels oan it bouwen fan dit soarte protokol, is de needsaak om ien autoritative boarne fan konfiguraasje te krijen en, úteinlik, ús punten fan oanwêzigens te syngronisearjen mei. De opslach sels wie mar ien fan ferskate easken tidens de ûntwikkeling fan QControl. Dêrnjonken hawwe wy ek yntegraasjes nedich mei besteande en plande tsjinsten op punten fan oanwêzigens (POP), tûke (en oanpasbere) metoaden foar gegevensvalidaasje, lykas tagongskontrôle. Njonken dit woenen wy ek sa'n systeem kontrolearje mei kommando's ynstee fan wizigingen oan bestannen. Foar QControl waarden gegevens stjoerd nei punten fan oanwêzigens hast mei de hân. As ien fan 'e punten fan oanwêzichheid net beskikber wie en wy fergeaten it letter te aktualisearjen, soe de konfiguraasje út syngronisaasje einigje en soene wy tiid moatte fergrieme om it wer op en te rinnen.
As gefolch hawwe wy it folgjende skema betocht:
De konfiguraasjetsjinner is ferantwurdlik foar gegevensvalidaasje en opslach; de router hat ferskate einpunten dy't konfiguraasje-updates ûntfange en útstjoere fan kliïnten en stipeteams nei de tsjinner, en fan 'e tsjinner nei punten fan oanwêzigens.
Ynternetferbiningskwaliteit ferskilt noch hieltyd rûn de wrâld - om dit punt te yllustrearjen, litte wy sjen nei in ienfâldige MTR fan Praach, Tsjechje nei Singapore en Hong Kong.
MTR fan Praach nei Singapore
Itselde ding foar Hong Kong
Hege latency betsjut legere snelheid. Dêrneist is der pakketferlies. Kanaal breedte net kompensearje foar dit probleem, dat moat altyd wurde rekken holden by it bouwen fan desintralisearre systemen.
De folsleine konfiguraasje fan in oanwêzichheid is in wichtige hoemannichte gegevens dy't moatte wurde stjoerd nei in protte ûntfangers oer ûnbetroubere ferbiningen. Gelokkich, hoewol de konfiguraasje konstant feroaret, bart it yn lytse stappen.
Resint-stabyl ûntwerp
Wy kinne sizze dat it bouwen fan in ferspraat netwurk basearre op it prinsipe fan inkrementele updates is in frij foar de hân lizzende oplossing. Mar d'r binne in protte problemen mei ferskillen. Wy moatte alle ferskillen tusken de referinsjepunten bewarje, en se kinne ek opnij ferstjoere foar it gefal dat immen in diel fan 'e gegevens miste. Elke bestimming moat se tapasse yn in strikt oantsjutte folchoarder. Typysk, yn it gefal fan ferskate bestimmingen, kin sa'n operaasje lang duorje. De ûntfanger moat ek de ûntbrekkende dielen opfreegje kinne en fansels moat it sintrale diel goed op sa'n fersyk reagearje, allinich de ûntbrekkende gegevens ferstjoere.
As gefolch, wy kamen ta in nochal nijsgjirrige oplossing - wy hawwe mar ien referinsje laach, fêst, lit ús neame it stabyl, en mar ien ferskil foar it - resint. Elke resinte is basearre op de lêste generearre stâl en is genôch om de konfiguraasjegegevens opnij op te bouwen. Sadree't de frisse resinte syn bestimming berikt, is de âlde net mear nedich.
Alles wat oerbliuwt is om sa no en dan in frisse stabile konfiguraasje te stjoeren, bygelyks om't resint te grut wurden is. Wat hjir ek wichtich is, is dat wy al dizze updates stjoere yn in útstjoer-/multicast-modus, sûnder ús soargen te meitsjen oer yndividuele ûntfangers en har fermogen om stikken gegevens byinoar te meitsjen. Sadree't wy wis binne dat elkenien de juste stâl hat, stjoere wy allinich nije resinte. Is it de muoite wurdich om te ferdúdlikjen dat dit wurket? Wurket. Stabyl is yn it cache op 'e konfiguraasjetsjinner en ûntfangers, resint wurdt makke as nedich.
Arsjitektuer fan twa-nivo ferfier
Wêrom hawwe wy ús ferfier op twa nivo's boud? It antwurd is frij simpel - wy woenen routing loskoppele fan logika op heech nivo, ynspiraasje nimme fan it OSI-model mei syn ferfier- en applikaasjelagen. Wy brûkten Thrift foar de rol fan it ferfierprotokol, en it msgpack-serialisaasjeformaat foar it opmaak op hege nivo fan kontrôleberjochten. Dit is de reden wêrom't de router (multycast / útstjoering / estafette útfiert) net yn msgpack sjocht, de ynhâld net útpakke of werompakke, en allinich gegevens trochstjoert.
Thrift (fan it Ingelsk - "thrift", útsprutsen [θrift]) is in ynterfacebeskriuwingstaal dy't brûkt wurdt om tsjinsten foar ferskate programmeartalen te definiearjen en te meitsjen. It is in ramt foar proseduereoproppen op ôfstân (RPC). Kombinearret in softwarepipeline mei in koadegeneraasjemotor om tsjinsten te ûntwikkeljen dy't mear of minder effisjint en maklik wurkje tusken talen.
Wy hawwe it Thrift-kader keazen fanwegen RPC en stipe foar in protte talen. Lykas gewoanlik wiene de maklike dielen de kliïnt en tsjinner. De router blykte lykwols in hurde nut te wêzen om te kraken, foar in part troch it ûntbrekken fan in klearebare oplossing tidens ús ûntwikkeling.
D'r binne oare opsjes, lykas protobuf / gRPC, lykwols, doe't wy ús projekt begûnen, wie gRPC frij nij en wy doarsten it net oan board te nimmen.
Fansels koenen (en hiene we eins) ús eigen fyts bouwe. It soe makliker wêze om in protokol te meitsjen foar wat wy nedich binne, om't de client-server-arsjitektuer relatyf ienfâldich is om te ymplementearjen yn ferliking mei it bouwen fan in router op Thrift. Op ien of oare manier is d'r in tradysjonele bias nei selsskreaune protokollen en ymplemintaasje fan populêre bibleteken (foar goede reden); boppedat komt by diskusjes altyd de fraach op: "Hoe sille wy dit oerdrage nei oare talen?" Dat wy smieten daliks it idee fan in fyts út.
Msgpack is gelyk oan JSON, mar rapper en lytser. It is in serialisaasjeformaat foar binêre gegevens wêrtroch gegevens útwiksele wurde kinne tusken meardere talen.
Op it earste nivo hawwe wy Thrift mei de minimale ynformaasje dy't nedich is foar de router om it berjocht troch te stjoeren. Op it twadde nivo binne d'r ferpakte msgpack-struktueren.
Wy hawwe foar msgpack keazen om't it rapper en kompakter is yn ferliking mei JSON. Mar noch wichtiger, it stipet oanpaste gegevenstypen, wêrtroch't wy koele funksjes kinne brûke lykas it trochjaan fan rau binaries of spesjale objekten dy't de ôfwêzigens fan gegevens oanjaan, wat wichtich wie foar ús "resint-stabile" skema.
JMESPath
JMESPath is in JSON-fraachtaal.
Dit is krekt wat de beskriuwing dy't wy krije fan 'e offisjele JMESPath-dokumintaasje derút sjocht, mar yn feite docht it folle mear dan dat. JMESPath kinne jo sykje en filterje subtrees yn in willekeurige beamstruktuer, en tapasse feroarings oan gegevens op 'e fly. It lit jo ek spesjale filters en gegevenstransformaasjeprosedueres tafoegje. Hoewol't it, fansels, fereasket harsens ynspanning om te begripen.
Jinja
Foar guon konsuminten moatte wy de konfiguraasje omsette yn in bestân - dus wy brûke in sjabloanmotor en Jinja is de foar de hân lizzende kar. Mei har help generearje wy in konfiguraasjetriem fan it sjabloan en gegevens ûntfongen op 'e bestimming.
Foar in generearje in konfiguraasje triem, wy moatte in JMESPath fersyk, in sjabloan foar de triem lokaasje yn de FS, en in sjabloan foar de konfiguraasje sels. It is op dit stadium ek in goed idee om de triemrjochten te ferdúdlikjen. Dit alles waard mei súkses kombinearre yn ien bestân - foar it begjin fan 'e konfiguraasjesjabloan sette wy in koptekst yn YAML-formaat dy't de rest beskriuwt.
Bygelyks:
---
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) }}
Om in konfiguraasjetriem foar in nije tsjinst te meitsjen, foegje wy allinich in nij sjabloanbestân ta. Gjin feroarings oan de boarnekoade of software op de punten fan oanwêzigens binne nedich.
Wat is feroare sûnt QControl gie live? De earste en meast wichtige ding is konsekwint en betroubere levering fan konfiguraasje updates oan alle knopen yn it netwurk. De twadde is om in krêftich ark te ûntfangen foar it kontrolearjen fan de konfiguraasje en it meitsjen fan feroaringen troch ús stipeteam, lykas ek troch konsuminten fan 'e tsjinst.
Wy koene dit alles dwaan mei it resinte-stabile updateskema om de kommunikaasje tusken de konfiguraasjetsjinner en konfiguraasjeûntfangers te ferienfâldigjen. Mei help fan in twa-laach protokol te stypjen in ynhâld-ûnôfhinklike manier fan routing gegevens. Mei súkses yntegrearre in Jinja-basearre konfiguraasje-generaasjemotor yn in ferspraat filternetwurk. Dit systeem stipet in breed oanbod fan konfiguraasjemetoaden foar ús ferspraat en heterogene perifeare apparaten.
Tank foar jo help by it skriuwen fan it materiaal. , , .
peal.
Boarne: www.habr.com