Tl; DR: Paglalarawan ng arkitektura ng client-server ng aming internal na network configuration management system, QControl. Ito ay batay sa isang two-layer transport protocol na gumagana sa mga mensaheng puno ng gzip nang walang decompression sa pagitan ng mga endpoint. Ang mga distributed na router at endpoint ay tumatanggap ng mga update sa configuration, at ang protocol mismo ay nagbibigay-daan sa pag-install ng mga localized na intermediate relay. Ang sistema ay binuo sa prinsipyo (βrecent-stableβ, ipinaliwanag sa ibaba) at ginagamit ang JMESpath query language kasama ang Jinja templating engine upang mag-render ng mga configuration file.
Ang Qrator Labs ay nagpapatakbo ng isang globally distributed attack mitigation network. Gumagana ang aming network sa prinsipyo ng anycast, at ang mga subnet ay ina-advertise sa pamamagitan ng BGP. Bilang isang BGP anycast network na pisikal na matatagpuan sa ilang mga rehiyon ng Earth, maaari naming iproseso at i-filter ang hindi lehitimong trapiko na mas malapit sa core ng Internet - Tier-1 na mga operator.
Sa kabilang banda, hindi madali ang pagiging isang network na ipinamamahagi sa heograpiya. Ang komunikasyon sa pagitan ng mga network point of presence ay kritikal para sa security service provider na magkaroon ng pare-parehong configuration ng lahat ng network node, na ina-update ang mga ito sa isang napapanahong paraan. Samakatuwid, para maibigay ang pinakamataas na posibleng antas ng pangunahing serbisyo sa consumer, kailangan naming humanap ng paraan para mapagkakatiwalaang i-sync ang data ng configuration sa mga kontinente.
Sa pasimula ay ang Salita. Mabilis itong naging protocol ng komunikasyon na nangangailangan ng update.
Ang pundasyon ng pagkakaroon ng QControl, at sa parehong oras ang pangunahing dahilan sa paggastos ng malaking halaga ng oras at mga mapagkukunan sa pagbuo ng ganitong uri ng protocol, ay ang pangangailangan na makakuha ng isang awtoritatibong mapagkukunan ng pagsasaayos at, sa huli, i-synchronize ang aming mga punto ng presensya kasama. Ang imbakan mismo ay isa lamang sa ilang mga kinakailangan sa panahon ng pagbuo ng QControl. Bilang karagdagan, kailangan din namin ng mga pagsasama sa mga umiiral at nakaplanong serbisyo sa mga punto ng presensya (POP), matalino (at nako-customize) na mga pamamaraan para sa pagpapatunay ng data, pati na rin ang kontrol sa pag-access. Bukod dito, gusto rin naming kontrolin ang naturang sistema gamit ang mga command sa halip na gumawa ng mga pagbabago sa mga file. Bago ang QControl, ang data ay ipinadala sa mga punto ng presensya halos manu-mano. Kung hindi available ang isa sa mga punto ng presensya at nakalimutan namin itong i-update sa ibang pagkakataon, mawawalan ng sync ang configuration at kailangan naming mag-aksaya ng oras sa pag-back up at pagpapatakbo nito.
Bilang resulta, nakabuo kami ng sumusunod na scheme:
Ang configuration server ay may pananagutan para sa data validation at storage; ang router ay may ilang mga endpoint na tumatanggap at nagbo-broadcast ng mga update sa configuration mula sa mga kliyente at support team sa server, at mula sa server hanggang sa mga punto ng presensya.
Malaki pa rin ang pagkakaiba-iba ng kalidad ng koneksyon sa internet sa buong mundo - para ilarawan ang puntong ito, tingnan natin ang isang simpleng MTR mula Prague, Czech Republic hanggang Singapore at Hong Kong.
MTR mula Prague hanggang Singapore
Parehong bagay sa Hong Kong
Ang mataas na latency ay nangangahulugan ng mas mababang bilis. Bilang karagdagan, mayroong pagkawala ng packet. Ang lapad ng channel ay hindi nagbabayad para sa problemang ito, na dapat palaging isaalang-alang kapag nagtatayo ng mga desentralisadong sistema.
Ang buong configuration ng isang point of presence ay isang malaking halaga ng data na dapat ipadala sa maraming tatanggap sa mga hindi mapagkakatiwalaang koneksyon. Sa kabutihang palad, kahit na ang pagsasaayos ay patuloy na nagbabago, nangyayari ito sa maliliit na pagtaas.
Kamakailang matatag na disenyo
Masasabi nating ang pagbuo ng isang distributed network batay sa prinsipyo ng incremental updates ay isang medyo halatang solusyon. Ngunit mayroong maraming mga problema sa mga pagkakaiba. Kailangan nating i-save ang lahat ng pagkakaiba sa pagitan ng mga reference point, at maipadala rin muli ang mga ito kung sakaling may napalampas na bahagi ng data. Dapat ilapat ng bawat destinasyon ang mga ito sa isang mahigpit na tinukoy na pagkakasunud-sunod. Karaniwan, sa kaso ng ilang mga destinasyon, ang naturang operasyon ay maaaring tumagal ng mahabang panahon. Ang receiver ay dapat ding humiling ng mga nawawalang bahagi at, siyempre, ang gitnang bahagi ay dapat tumugon sa naturang kahilingan nang tama, na nagpapadala lamang ng nawawalang data.
Bilang isang resulta, nakarating kami sa isang medyo kawili-wiling solusyon - mayroon lamang kaming isang reference na layer, naayos, tawagan natin itong matatag, at isang pagkakaiba lamang para dito - kamakailan. Ang bawat kamakailan ay batay sa huling nabuong stable at sapat na upang muling buuin ang data ng configuration. Sa sandaling maabot ng bagong bago ang patutunguhan nito, hindi na kailangan ang luma.
Ang natitira na lang ay magpadala ng isang sariwang stable na configuration paminsan-minsan, halimbawa dahil ang kamakailang ay naging masyadong malaki. Ang mahalaga din dito ay ipinapadala namin ang lahat ng mga update na ito sa isang broadcast/multicast mode, nang hindi nababahala tungkol sa mga indibidwal na tatanggap at ang kanilang kakayahang pagsama-samahin ang mga piraso ng data. Kapag natitiyak namin na ang lahat ay may tamang kuwadra, nagpapadala lamang kami ng mga bago. Ito ba ay nagkakahalaga ng paglilinaw na ito ay gumagana? Gumagana. Ang Stable ay naka-cache sa configuration server at mga tatanggap, kamakailan ay nilikha kung kinakailangan.
Arkitektura ng dalawang antas na transportasyon
Bakit namin ginawa ang aming transportasyon sa dalawang antas? Ang sagot ay medyo simple - gusto naming ihiwalay ang pagruruta mula sa mataas na antas na lohika, kumukuha ng inspirasyon mula sa modelo ng OSI kasama ang mga layer ng transportasyon at aplikasyon nito. Ginamit namin ang Thrift para sa papel ng transport protocol, at ang msgpack serialization format para sa mataas na antas na format ng mga control message. Ito ang dahilan kung bakit ang router (gumaganap ng multicast/broadcast/relay) ay hindi tumitingin sa loob ng msgpack, hindi nag-unpack o nag-pack ng mga nilalaman pabalik, at nagpapasa lamang ng data.
Ang Thrift (mula sa English - "thrift", binibigkas na [ΞΈrift]) ay isang interface ng paglalarawan ng wika na ginagamit upang tukuyin at lumikha ng mga serbisyo para sa iba't ibang programming language. Ito ay isang balangkas para sa mga remote procedure call (RPC). Pinagsasama ang isang software pipeline sa isang code generation engine upang bumuo ng mga serbisyo na gumagana nang higit pa o hindi gaanong mahusay at madali sa pagitan ng mga wika.
Pinili namin ang Thrift framework dahil sa RPC at suporta para sa maraming wika. Gaya ng dati, ang mga madaling bahagi ay ang kliyente at server. Gayunpaman, ang router ay naging isang matigas na mani na i-crack, bahagyang dahil sa kakulangan ng isang handa na solusyon sa panahon ng aming pag-unlad.
Mayroong iba pang mga pagpipilian, tulad ng protobuf / gRPC, gayunpaman, noong sinimulan namin ang aming proyekto, ang gRPC ay medyo bago at hindi kami nangahas na dalhin ito sa board.
Siyempre, maaari kaming (at sa katunayan ay dapat) gumawa ng aming sariling bike. Mas madaling gumawa ng protocol para sa kung ano ang kailangan natin dahil ang arkitektura ng client-server ay medyo diretsong ipatupad kumpara sa pagbuo ng router sa Thrift. Sa isang paraan o iba pa, mayroong isang tradisyunal na pagkiling sa mga self-written na protocol at pagpapatupad ng mga sikat na aklatan (para sa magandang dahilan); bilang karagdagan, sa panahon ng mga talakayan ang tanong ay palaging lumalabas: "Paano natin ito ipo-port sa ibang mga wika?" Kaya agad naming itinapon ang ideya ng isang bisikleta.
Ang Msgpack ay katulad ng JSON, ngunit mas mabilis at mas maliit. Ito ay isang binary data serialization format na nagpapahintulot sa data na makipagpalitan sa pagitan ng maraming wika.
Sa unang antas mayroon kaming Thrift na may pinakamababang impormasyong kinakailangan para sa router na maipasa ang mensahe. Sa pangalawang antas mayroong mga naka-package na istruktura ng msgpack.
Pinili namin ang msgpack dahil mas mabilis at mas compact ito kumpara sa JSON. Ngunit higit sa lahat, sinusuportahan nito ang mga custom na uri ng data, na nagbibigay-daan sa amin na gumamit ng mga cool na feature tulad ng pagpasa ng mga raw binary o mga espesyal na bagay na nagsasaad ng kawalan ng data, na mahalaga para sa aming "recent-stable" na scheme.
JMESPath
Ang JMESPath ay isang JSON query language.
Ito mismo ang hitsura ng paglalarawan na nakukuha namin mula sa opisyal na dokumentasyon ng JMESPath, ngunit sa katunayan, higit pa rito ang nagagawa nito. Binibigyang-daan ka ng JMESPath na maghanap at mag-filter ng mga subtree sa isang arbitrary na istraktura ng puno, at ilapat ang mga pagbabago sa data sa mabilisang. Nagbibigay-daan din ito sa iyo na magdagdag ng mga espesyal na filter at mga pamamaraan sa pagbabago ng data. Bagaman ito, siyempre, ay nangangailangan ng pagsisikap ng utak upang maunawaan.
Jinja
Para sa ilang mga mamimili, kailangan naming gawing file ang configuration - kaya gumagamit kami ng template engine at Jinja ang malinaw na pagpipilian. Sa tulong nito, bumubuo kami ng configuration file mula sa template at data na natanggap sa destinasyon.
Para makabuo ng configuration file, kailangan namin ng JMESPath request, template para sa lokasyon ng file sa FS, at template para sa config mismo. Magandang ideya din sa yugtong ito na linawin ang mga pahintulot ng file. Ang lahat ng ito ay matagumpay na pinagsama sa isang file - bago magsimula ang template ng pagsasaayos, naglalagay kami ng isang header sa format na YAML na naglalarawan sa iba.
Halimbawa:
---
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) }}
Upang makagawa ng configuration file para sa isang bagong serbisyo, nagdagdag lang kami ng bagong template file. Walang mga pagbabago sa source code o software sa mga punto ng presensya ay kinakailangan.
Ano ang nagbago mula nang maging live ang QControl? Ang una at pinakamahalagang bagay ay pare-pareho at maaasahang paghahatid ng mga update sa pagsasaayos sa lahat ng mga node sa network. Ang pangalawa ay ang makatanggap ng isang mahusay na tool para sa pagsuri sa configuration at paggawa ng mga pagbabago dito ng aming team ng suporta, gayundin ng mga consumer ng serbisyo.
Nagawa namin ang lahat ng ito gamit ang recent-stable na update scheme para pasimplehin ang komunikasyon sa pagitan ng configuration server at configuration recipients. Paggamit ng dalawang-layer na protocol upang suportahan ang isang content-independent na paraan ng pagruruta ng data. Matagumpay na naisama ang isang Jinja-based configuration generation engine sa isang distributed filtering network. Sinusuportahan ng system na ito ang malawak na hanay ng mga paraan ng pagsasaayos para sa aming mga distributed at heterogenous na peripheral.
Salamat sa iyong tulong sa pagsulat ng materyal. , , .
post.
Pinagmulan: www.habr.com