TL; DR: Katrangan arsitektur klien-server sistem manajemen konfigurasi jaringan internal kita, QControl. Iku adhedhasar protokol transportasi rong lapisan sing bisa digunakake karo pesen gzip-dikempalken tanpa dekompresi antarane endpoints. Router lan endpoint sing disebarake nampa nganyari konfigurasi, lan protokol kasebut ngidini instalasi relay penengah lokal. Sistem dibangun ing prinsip ("anyar-stabil", diterangno ing ngisor iki) lan nggunakake basa query JMESpath bebarengan karo mesin template Jinja kanggo nerjemahake file konfigurasi.
Qrator Labs ngoperasikake jaringan mitigasi serangan sing disebarake sacara global. Jaringan kita ngoperasikake prinsip anycast, lan subnet diiklanake liwat BGP. Dadi jaringan BGP anycast sing dumunung sacara fisik ing sawetara wilayah ing Bumi, kita bisa ngolah lan nyaring lalu lintas sing ora sah nyedhaki inti saka Internet - operator Tier-1.
Ing sisih liya, dadi jaringan sing disebarake sacara geografis ora gampang. Komunikasi antarane titik ngarsane jaringan iku kritis kanggo panyedhiya layanan keamanan duwe konfigurasi konsisten kabeh simpul jaringan, nganyari ing proses pas wektune. Mula, kanggo nyedhiyakake layanan inti sing paling dhuwur kanggo konsumen, kita kudu golek cara kanggo nyelarasake data konfigurasi kanthi andal ing saindenging bawana.
Ing wiwitan ana Sabda. Cepet dadi protokol komunikasi sing mbutuhake nganyari.
Landasan saka eksistensi QControl, lan ing wektu sing padha alesan utama kanggo nglampahi jumlah pinunjul saka wektu lan sumber daya kanggo mbangun iki jenis protokol, iku perlu kanggo njupuk sumber kuoso siji saka konfigurasi lan, wekasanipun, nyinkronake kita titik ngarsane. karo. Panyimpenan kasebut mung minangka salah sawijining syarat sajrone pangembangan QControl. Kajaba iku, kita uga mbutuhake integrasi karo layanan sing wis ana lan direncanakake ing titik ngarsane (POP), metode cerdas (lan bisa disesuaikan) kanggo validasi data, uga kontrol akses. Kajaba iku, kita uga pengin ngontrol sistem kasebut nggunakake perintah tinimbang nggawe modifikasi file. Sadurunge QControl, data dikirim menyang titik ngarsane meh manual. Yen salah siji saka titik ngarsane ora kasedhiya lan kita kelalen nganyari mengko, konfigurasi bakal rampung metu saka sinkronisasi lan kita kudu mbuang wektu kanggo njaluk maneh munggah lan mlaku.
AkibatΓ©, kita teka karo skema ing ngisor iki:
Server konfigurasi tanggung jawab kanggo validasi lan panyimpenan data; router duwe sawetara titik pungkasan sing nampa lan nyebarake nganyari konfigurasi saka klien lan tim dhukungan menyang server, lan saka server menyang titik ngarsane.
Kualitas sambungan internet isih beda-beda ing saindenging jagad - kanggo nggambarake babagan iki, ayo deleng MTR sing prasaja saka Praha, Republik Ceko nganti Singapura lan Hong Kong.
MTR saka Praha nganti Singapura
Bab sing padha karo Hong Kong
Latensi dhuwur tegese kacepetan sing luwih murah. Kajaba iku, ana mundhut paket. Jembar saluran ora ngimbangi masalah iki, sing kudu dianggep nalika mbangun sistem desentralisasi.
Konfigurasi lengkap saka titik ngarsane minangka jumlah data sing penting sing kudu dikirim menyang akeh panampa liwat sambungan sing ora bisa dipercaya. Begjanipun, sanajan konfigurasi diganti terus-terusan, kedadeyan kasebut kanthi bertahap.
Desain anyar-stabil
Kita bisa ngomong yen mbangun jaringan sing disebarake adhedhasar prinsip nganyari tambahan minangka solusi sing cukup jelas. Nanging ana akeh masalah karo diffs. Kita kudu nyimpen kabeh beda ing antarane titik referensi, lan uga bisa ngirim maneh yen ana wong sing ora kejawab bagean data kasebut. Saben tujuan kudu ditrapake ing urutan sing ditemtokake kanthi ketat. Biasane, ing sawetara tujuan, operasi kasebut bisa njupuk wektu suwe. Panrima uga kudu bisa njaluk bagean sing ilang lan, mesthi, bagean tengah kudu nanggapi panjaluk kasebut kanthi bener, mung ngirim data sing ilang.
AkibatΓ©, kita teka menyang solusi sing rada menarik - mung siji lapisan referensi, tetep, ayo diarani stabil, lan mung siji bedane - anyar. Saben anyar adhedhasar stabil pungkasan kui lan cukup kanggo mbangun maneh data konfigurasi. Sanalika sing anyar seger tekan tujuane, sing lawas ora perlu maneh.
Kabeh sing isih ana yaiku ngirim konfigurasi stabil sing seger saka wektu kanggo wektu, contone amarga anyar wis dadi gedhe banget. Sing penting uga ing kene yaiku ngirim kabeh update kasebut ing mode siaran / multicast, tanpa kuwatir babagan panampa individu lan kemampuan kanggo nggabungake potongan data. Sawise kita yakin manawa kabeh wong duwe stabil sing bener, kita mung ngirim sing anyar. Apa worth njlentrehake yen iki bisa digunakake? Nyambut gawe. Stabil di-cache ing server konfigurasi lan panampa, paling anyar digawe yen perlu.
Arsitektur transportasi rong tingkat
Napa kita mbangun transportasi ing rong tingkat? Jawaban iki cukup prasaja - kita pengin ngilangi rute saka logika tingkat dhuwur, njupuk inspirasi saka model OSI kanthi lapisan transportasi lan aplikasi. Kita nggunakake Thrift kanggo peran protokol transportasi, lan format serialisasi msgpack kanggo format pesen kontrol tingkat dhuwur. Mulane router (performing multicast / broadcast / relay) ora katon ing msgpack, ora mbongkar utawa ngemas isi maneh, lan mung nerusake data.
Thrift (saka basa Inggris - "thrift", diucapake [ΞΈrift]) minangka basa deskripsi antarmuka sing digunakake kanggo nemtokake lan nggawe layanan kanggo macem-macem basa pamrograman. Iku framework kanggo telpon prosedur remot (RPC). Nggabungake pipa piranti lunak karo mesin generasi kode kanggo ngembangake layanan sing bisa dianggo luwih utawa kurang efisien lan gampang antarane basa.
Kita milih kerangka Thrift amarga RPC lan dhukungan kanggo akeh basa. Kaya biasane, bagean sing gampang yaiku klien lan server. Nanging, router kasebut dadi angel kanggo retak, sebagian amarga ora ana solusi sing wis siap sajrone pembangunan.
Ana pilihan liyane, kayata protobuf / gRPC, nanging nalika miwiti proyek, gRPC cukup anyar lan ora wani njupuk.
Mesthi, kita bisa (lan nyatane kudu) nggawe sepeda kita dhewe. Bakal luwih gampang nggawe protokol kanggo apa sing kita butuhake amarga arsitektur klien-server relatif gampang diimplementasikake dibandhingake karo mbangun router ing Thrift. Salah siji cara utawa liyane, ana bias tradisional kanggo protokol sing ditulis dhewe lan implementasi perpustakaan populer (kanggo alesan sing apik); Kajaba iku, sajrone diskusi, pitakonan tansah muncul: "Kepiye carane ngirim iki menyang basa liya?" Dadi kita langsung mbuwang ide sepeda.
Msgpack mirip karo JSON, nanging luwih cepet lan luwih cilik. Iki minangka format serialisasi data binar sing ngidini data bisa diijolke ing antarane pirang-pirang basa.
Ing tingkat pisanan, kita duwe Thrift kanthi informasi minimal sing dibutuhake kanggo router kanggo nerusake pesen kasebut. Ing tingkat kapindho ana rangkep struktur msgpack.
Kita milih msgpack amarga luwih cepet lan luwih kompak dibandhingake karo JSON. Nanging sing luwih penting, ndhukung jinis data khusus, ngidini kita nggunakake fitur sing keren kaya ngliwati binari mentah utawa obyek khusus sing nuduhake ora ana data, sing penting kanggo skema "anyar-stabil".
JMESPath
JMESPath minangka basa pitakon JSON.
Iki persis kaya deskripsi sing ditampa saka dokumentasi resmi JMESPath, nanging nyatane, luwih akeh tinimbang iku. JMESPath ngijini sampeyan kanggo nelusuri lan nyaring subtrees ing struktur wit kasepakatan, lan aplikasi owah-owahan kanggo data ing fly. Uga ngidini sampeyan nambah saringan khusus lan tata cara transformasi data. Senajan iku, mesthi, mbutuhake gaweyan otak kanggo mangerteni.
Jinja
Kanggo sawetara konsumen, kita kudu ngowahi konfigurasi dadi file - supaya kita nggunakake mesin template lan Jinja minangka pilihan sing jelas. Kanthi bantuan, kita ngasilake file konfigurasi saka cithakan lan data sing ditampa ing panggonan sing dituju.
Kanggo generate file konfigurasi, kita kudu request JMESPath, Cithakan kanggo lokasi file ing FS, lan cithakan kanggo config dhewe. Iku uga apike ing tahap iki kanggo njlentrehake ijin file. Kabeh iki kasil digabungake ing siji file - sadurunge wiwitan cithakan konfigurasi, kita sijine header ing format YAML sing nggambarake liyane.
Contone:
---
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) }}
Kanggo nggawe file konfigurasi kanggo layanan anyar, kita mung nambah file cithakan anyar. Ora ana owah-owahan ing kode sumber utawa piranti lunak ing titik ngarsane sing dibutuhake.
Apa wis diganti wiwit QControl urip? Wangsulan: Bab ingkang pisanan lan paling penting yaiku pangiriman konsisten lan dipercaya nganyari konfigurasi kanggo kabeh simpul ing jaringan. Kapindho yaiku nampa alat sing kuat kanggo mriksa konfigurasi lan nggawe owah-owahan dening tim dhukungan kita, uga dening konsumen layanan kasebut.
Kita bisa nindakake kabeh iki nggunakake skema nganyari stabil anyar kanggo nyederhanakake komunikasi antarane server konfigurasi lan panampa konfigurasi. Nggunakake protokol loro-lapisan kanggo ndhukung cara data nuntun isi-independen. Kasil nggabungake mesin generasi konfigurasi basis Jinja menyang jaringan nyaring sing disebarake. Sistem iki ndhukung macem-macem cara konfigurasi kanggo periferal sing disebar lan heterogen.
Matur nuwun kanggo bantuan sampeyan nulis materi. , , .
kirim.
Source: www.habr.com