TL; DR: Beschreiwung vun der Client-Server Architektur vun eisem intern Reseau Configuratioun Gestioun System, QControl. Et baséiert op engem Zwee-Schicht Transportprotokoll dee mat gzip-gepackte Messagen ouni Dekompressioun tëscht Endpunkte funktionnéiert. Verdeelt Router an Endpunkte kréien Konfiguratiounsupdates, an de Protokoll selwer erlaabt d'Installatioun vu lokaliséierten Zwësche Relais. De System ass op de Prinzip gebaut ("rezent-stabil", hei ënnen erkläert) a benotzt d'JMESpath Ufro Sprooch zesumme mam Jinja Templatemotor fir Konfiguratiounsdateien ze maachen.
Qrator Labs bedreift e weltwäit verdeelt Attackemitigatiounsnetz. Eist Netzwierk funktionnéiert nom Anycast-Prinzip, an Subnets ginn iwwer BGP ugekënnegt. Als BGP Anycast Netz ze sinn, déi kierperlech a verschiddene Regioune vun der Äerd läit, kënne mir den illegitime Verkéier méi no beim Kär vum Internet veraarbechten an filteren - Tier-1 Betreiber.
Op der anerer Säit, e geographesch verdeelt Netzwierk ze sinn ass net einfach. Kommunikatioun tëscht Netzwierkpunkte vun der Präsenz ass kritesch fir de Sécherheetsserviceprovider fir eng konsequent Konfiguratioun vun all Netzwierkknäppchen ze hunn, se fristgerecht ze aktualiséieren. Dofir, fir den héchste méiglechen Niveau vum Kärservice dem Konsument ze bidden, musse mir e Wee fannen fir d'Konfiguratiounsdaten iwwer Kontinenter zouverlässeg ze synchroniséieren.
Am Ufank war d'Wuert. Et gouf séier e Kommunikatiounsprotokoll deen en Update brauch.
De Grondsteen vun der Existenz vun QControl, a gläichzäiteg den Haaptgrond fir eng bedeitend Quantitéit un Zäit a Ressourcen ze verbréngen fir dës Aart vu Protokoll ze bauen, ass de Besoin fir eng eenzeg autoritär Konfiguratiounsquell ze kréien an, schlussendlech, eis Punkte vun der Präsenz ze synchroniséieren domat. De Stockage selwer war just ee vun e puer Ufuerderunge während der Entwécklung vun QControl. Zousätzlech brauche mir och Integratioune mat existéierenden a geplangte Servicer op Punkten vun der Präsenz (POP), Smart (an personaliséierbar) Methoden fir Datenvalidatioun, souwéi Zougangskontrolle. Ausserdeem wollte mir och esou e System mat Kommandoen kontrolléieren anstatt Ännerunge fir Dateien ze maachen. Virun QControl goufen Donnéeën op Punkte vun Präsenz bal manuell geschéckt. Wann ee vun de Punkte vun der Präsenz net verfügbar war a mir vergiess hunn et spéider ze aktualiséieren, géif d'Konfiguratioun aus der Synchroniséierung ophalen a mir mussen Zäit verschwenden fir se erëm opzemaachen a lafen.
Als Resultat hu mir de folgende Schema erausfonnt:
De Konfiguratiounsserver ass verantwortlech fir d'Datevalidatioun a Lagerung; de Router huet e puer Endpunkte déi Konfiguratiounsupdate vu Clienten an Supportteams op de Server kréien an iwwerdroen, a vum Server op Punkte vu Präsenz.
D'Qualitéit vun der Internetverbindung variéiert nach ëmmer vill ronderëm d'Welt - fir dëse Punkt ze illustréieren, kucke mer en einfachen MTR vu Prag, Tschechesch Republik op Singapur an Hong Kong.
MTR vu Prag op Singapur
Selwecht Saach zu Hong Kong
Héich latency bedeit manner Geschwindegkeet. Zousätzlech gëtt et Paketverloscht. Kanal Breet kompenséiert net fir dëse Problem, deen ëmmer muss berücksichtegt ginn wann Dir dezentraliséierte Systemer bauen.
Déi voll Konfiguratioun vun engem Punkt vun der Präsenz ass eng bedeitend Quantitéit un Daten, déi un vill Empfänger iwwer onzouverlässeg Verbindunge geschéckt musse ginn. Glécklecherweis, obwuel d'Konfiguratioun dauernd ännert, geschitt et a klenge Schrëtt.
Rezent-stabil Design
Mir kënne soen datt e verdeelt Netzwierk bauen baséiert op dem Prinzip vun inkrementellen Updates eng zimlech offensichtlech Léisung ass. Awer et gi vill Probleemer mat Differenzen. Mir mussen all d'Differenzen tëscht de Referenzpunkte späicheren, an och fäeg sinn se nei ze schécken, wann een en Deel vun den Donnéeën verpasst huet. All Destinatioun muss se an enger strikt spezifizéierter Sequenz uwenden. Typesch, am Fall vu verschiddenen Destinatiounen, kann esou eng Operatioun laang daueren. Den Empfänger muss och fäeg sinn déi fehlend Deeler ze froen an natierlech muss den zentrale Deel richteg op esou eng Ufro reagéieren, nëmmen déi fehlend Donnéeën schécken.
Als Resultat si mir op eng zimlech interessant Léisung komm - mir hunn nëmmen eng Referenzschicht, fixéiert, loosst eis et stabil nennen, an nëmmen een Ënnerscheed dofir - rezent. All rezent baséiert op de leschten generéierte Stall an ass genuch fir d'Konfiguratiounsdaten opzebauen. Soubal dee frësche rezente seng Destinatioun erreecht, brauch deen alen net méi.
Alles wat bleift ass eng frësch stabil Konfiguratioun vun Zäit zu Zäit ze schécken, zum Beispill well rezent ze grouss ginn ass. Wat och hei wichteg ass, ass datt mir all dës Updates an engem Broadcast-/Multicast-Modus schécken, ouni Iech Suergen iwwer eenzel Empfänger an hir Fäegkeet fir Stécker vun Daten zesummenzebréngen. Wa mir sécher sinn datt jiddereen dee richtege Stall huet, schécken mir nëmmen nei rezent. Ass et derwäert ze klären datt dëst funktionnéiert? Wierker. Stable gëtt um Konfiguratiounsserver an Empfänger cache, rezent gëtt erstallt wéi néideg.
Architektur vun zwee-Niveau Transport
Firwat hu mir eisen Transport op zwee Niveauen opgebaut? D'Äntwert ass zimmlech einfach - mir wollten d'Routing vun der héijer Logik ofkoppelen, Inspiratioun vum OSI Modell mat sengen Transport- an Uwendungsschichten. Mir hunn Thrift fir d'Roll vum Transportprotokoll benotzt, an de msgpack Serialiséierungsformat fir den héije Format vu Kontrollmeldungen. Dofir kuckt de Router (Multicast / Broadcast / Relais aus) net an de msgpack, packt net den Inhalt zréck oder packt den Inhalt net zréck, a schéckt nëmmen Daten weider.
Thrift (aus Englesch - "Thrift", ausgeschwat [θrift]) ass eng Interface Beschreiwungssprooch déi benotzt gëtt fir Servicer fir verschidde Programméierungssproochen ze definéieren an ze kreéieren. Et ass e Kader fir Remote Prozedur Uriff (RPC). Kombinéiert eng Software Pipeline mat engem Code Generatioun Motor fir Servicer z'entwéckelen déi méi oder manner effizient an einfach tëscht Sproochen funktionnéieren.
Mir hunn den Thrift Kader gewielt wéinst RPC an Ënnerstëtzung fir vill Sproochen. Wéi gewinnt waren déi einfach Deeler de Client an de Server. Wéi och ëmmer, de Router huet sech als haart Nëss erausgestallt fir ze knacken, deelweis wéinst dem Mangel un enger fäerdeger Léisung während eiser Entwécklung.
Et ginn aner Optiounen, wéi Protobuf / gRPC, awer, wéi mir eise Projet ugefaang hunn, war gRPC zimlech nei a mir hunn eis net getraut et matzehuelen.
Natierlech kéinten (an eigentlech hätten) mir eisen eegene Vëlo bauen. Et wier méi einfach e Protokoll ze kreéieren fir dat wat mir brauchen well d'Client-Server Architektur relativ einfach ass ze implementéieren am Verglach mam Bau vun engem Router op Thrift. Op eng oder aner Manéier gëtt et eng traditionell Bias vis-à-vis vu selbstgeschriwwene Protokoller an Implementatioune vu populäre Bibliothéiken (aus gudde Grond); Zousätzlech, während Diskussiounen stellt sech ëmmer d'Fro: "Wéi wäerte mir dat an aner Sproochen portéieren?" Also hu mir direkt d'Iddi vun engem Vëlo erausgehäit.
Msgpack ass ähnlech wéi JSON, awer méi séier a méi kleng. Et ass e binäre Dateserialiséierungsformat dat et erlaabt Daten tëscht verschidde Sproochen austauscht ze ginn.
Um éischte Niveau hu mir Thrift mat der Minimum Informatioun déi néideg ass fir de Router fir de Message weiderzebréngen. Um zweeten Niveau ginn et verpackte msgpack Strukturen.
Mir hunn msgpack gewielt well et méi séier a méi kompakt ass am Verglach zum JSON. Awer méi wichteg, et ënnerstëtzt personaliséiert Datentypen, wat et eis erlaabt cool Features ze benotzen wéi rau Binären oder speziellen Objeten déi d'Feele vun Daten uginn, wat wichteg war fir eis "rezent-stabil" Schema.
JMESPath
JMESPath ass eng JSON Ufro Sprooch.
Dëst ass genau wéi d'Beschreiwung déi mir aus der offizieller JMESPath Dokumentatioun kréien, ausgesäit, awer tatsächlech mécht et vill méi wéi dat. JMESPath erlaabt Iech Subtrees an enger arbiträrer Bamstruktur ze sichen an ze filteren, an Ännerungen op Donnéeën ze gëllen. Et erlaabt Iech och speziell Filteren an Datentransformatiounsprozeduren ze addéieren. Obwuel et, natierlech, Gehir Effort verlaangt ze verstoen.
Jinja
Fir e puer Konsumenten musse mir d'Konfiguratioun an eng Datei ëmsetzen - also benotze mir e Schablounmotor an Jinja ass déi offensichtlech Wiel. Mat senger Hëllef generéiere mir eng Konfiguratiounsdatei aus der Schabloun an Donnéeën, déi op der Destinatioun kritt ginn.
Fir eng Konfiguratiounsdatei ze generéieren, brauche mir eng JMESPath Ufro, eng Schabloun fir d'Dateiplaz an der FS, an eng Schabloun fir d'Konfiguratioun selwer. Et ass och eng gutt Iddi op dëser Etapp d'Datei Permissiounen ze klären. All dëst gouf erfollegräich an enger Datei kombinéiert - virum Start vun der Konfiguratiounsschabloun setzen mir en Header am YAML-Format deen de Rescht beschreift.
Zum Beispill:
---
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) }}
Fir eng Konfiguratiounsdatei fir en neie Service ze maachen, addéiere mer nëmmen eng nei Schabloundatei. Keng Ännerunge vum Quellcode oder Software op de Punkte vun der Präsenz sinn erfuerderlech.
Wat huet geännert zënter QControl liewen gaangen? Déi éischt a wichtegst Saach ass konsequent an zouverlässeg Liwwerung vun Konfiguratioun Aktualiséierungen op all Wirbelen am Netz. Déi zweet ass e mächtegt Tool ze kréien fir d'Konfiguratioun z'iwwerpréiwen an Ännerungen ze maachen vun eisem Supportteam, souwéi vun de Konsumenten vum Service.
Mir konnten dëst alles maachen mat dem rezent-stabile Updateschema fir d'Kommunikatioun tëscht dem Konfiguratiounsserver an dem Configuratiounsempfänger ze vereinfachen. Mat engem zwee-Schichte Protokoll fir eng Inhalt-onofhängeg Manéier z'ënnerstëtzen fir Daten ze routing. Erfollegräich integréiert e Jinja-baséiert Konfiguratiounsgeneratiounsmotor an e verdeelt Filternetz. Dëse System ënnerstëtzt eng breet Palette vun Konfiguratiounsmethoden fir eis verdeelt an heterogen Peripheriegeräter.
Merci fir Är Hëllef beim Schreiwen vum Material. , , .
posten.
Source: will.com