TL; DR : Arsitektur klien-server dari alat manajemen konfigurasi internal kami, QControl.
Di ruang bawah tanahnya, ada protokol transportasi dua lapis yang bekerja dengan pesan yang dikompresi gzip tanpa dekompresi di antara titik akhir. Router dan titik akhir yang didistribusikan menerima pembaruan konfigurasi, dan protokol itu sendiri memungkinkan untuk memasang relay lokal terlokalisasi. Ini didasarkan pada
cadangan diferensial ("baru-stabil," dijelaskan lebih lanjut) desain dan mempekerjakan bahasa permintaan JMESpath dan Jinja templating untuk rendering konfigurasi.
Qrator Labs beroperasi pada dan memelihara jaringan mitigasi yang didistribusikan secara global. Jaringan kami disiarkan, berdasarkan pengumuman subnet kami melalui BGP. Menjadi jaringan BGP anycast yang secara fisik terletak di beberapa wilayah di Bumi memungkinkan kita untuk memproses dan menyaring lalu lintas ilegal lebih dekat ke tulang punggung Internet - operator Tier-1.
Di sisi lain, menjadi jaringan yang terdistribusi secara geografis menghadapi kesulitannya. Komunikasi antara titik-titik kehadiran jaringan (PoP) sangat penting bagi penyedia keamanan untuk memiliki konfigurasi yang koheren untuk semua node jaringan dan memperbaruinya secara tepat waktu dan kohesif. Jadi untuk memberikan layanan terbaik bagi pelanggan, kami harus menemukan cara untuk menyinkronkan data konfigurasi antara berbagai benua secara andal.
Pada awalnya, ada Word ... yang dengan cepat menjadi protokol komunikasi yang membutuhkan peningkatan.
Titik sudut keberadaan QControl dan alasan utama untuk menghabiskan banyak waktu dan upaya dalam membangun protokol kita adalah kebutuhan untuk mendapatkan satu sumber konfigurasi yang otoritatif dan akhirnya menyinkronkan PoP kita dengan itu. Penyimpanan hanyalah salah satu dari beberapa fitur yang diperlukan dalam pengembangan QControl. Selain itu, kami juga membutuhkan integrasi dengan periferal data yang ada dan pinggiran, cerdas (dan dapat disesuaikan), serta diferensiasi akses. Lebih jauh, kami ingin sistem ini mengelola berbagai hal melalui perintah, bukan melalui modifikasi file manual. Sebelum QControl, data dikirim ke titik kehadiran kurang lebih secara manual. Jika beberapa PoP tidak tersedia saat ini, dan kami lupa untuk memperbaruinya nanti, konfigurasi menjadi tidak sinkron, dan pemecahan masalah yang memakan waktu diperlukan untuk mengembalikannya dalam sinkronisasi.
Inilah sistem yang kami buat:
Server konfigurasi bertanggung jawab atas validasi dan penyimpanan data; router memiliki titik akhir yang berbeda untuk menerima dan menyampaikan pembaruan konfigurasi dari klien dan tim dukungan ke server dan dari server ke PoP.
Kualitas koneksi internet masih cukup beragam di seluruh dunia - untuk mengilustrasikannya, mari kita bayangkan traceroute sederhana dari Praha, Republik Ceko ke Singapura, dan Hong Kong.
MTR dari Praha ke Singapura
Tangkapan layar kedua yang sama dengan traceroute ke Hong Kong
Angka latensi tinggi berarti kecepatan yang buruk. Juga, ada paket loss yang tinggi. Angka bandwidth tidak mengkompensasi masalah ini, yang harus selalu dipertimbangkan ketika membangun jaringan yang terdesentralisasi.
Konfigurasi PoP penuh adalah data yang agak signifikan dan perlu ditransfer ke banyak penerima yang berbeda melalui koneksi yang tidak dapat diandalkan. Untungnya, meskipun konfigurasi sering berubah, itu berubah sedikit demi sedikit.
Desain terkini-stabil
Ini adalah keputusan yang cukup mudah untuk membangun jaringan terdistribusi berdasarkan pembaruan bertahap. Meskipun ada beberapa masalah dengan diff, mereka sulit untuk dibangun dengan benar: kita harus menyimpan semua diff antara titik referensi di suatu tempat, untuk dapat mengirim ulang mereka jika seseorang kehilangan sesuatu. Setiap tujuan harus menerapkannya secara koheren. Jika ada beberapa tujuan, ini bisa memakan banyak waktu di semua jaringan. Penerima juga harus dapat meminta bagian yang hilang, dan tentu saja, bagian tengah harus menjawab permintaan tersebut secara akurat, hanya mengirimkan data yang hilang.
Apa yang telah kami bangun pada akhirnya adalah hal yang cukup - kami hanya memiliki satu lapisan referensi, yang "stabil", dan hanya satu perbedaan, "baru" untuk itu. Setiap terbaru didasarkan pada stabil terbaru dan cukup untuk membangun kembali data konfigurasi. Ketika baru baru mencapai tujuan, yang lama sekali pakai.
Itu membuat kita perlu mengirim konfigurasi stabil baru karena yang belakangan ini tumbuh terlalu besar. Juga, catatan penting di sini adalah bahwa kita dapat melakukan semua ini dengan menyiarkan / memperbarui multicasting, tidak khawatir tentang kemampuan menerima tujuan untuk mengumpulkan potongan-potongan. Setelah kami memeriksa bahwa setiap orang memiliki kandang yang tepat, mereka semua diberi makan dengan yang baru. Haruskah kita mengatakan bahwa itu berhasil? Itu benar. Stabil di-cache di server konfigurasi dan penerima, dengan yang baru diciptakan saat diperlukan.
Arsitektur transportasi dua lapis
Mengapa sebenarnya kami membangun transportasi kami dari dua lapisan? Jawabannya cukup sederhana: kami ingin memisahkan rute dari aplikasi, mengambil inspirasi dalam model OSI dengan lapisan transport dan aplikasi. Jadi kami telah memisahkan protokol transport (Hemat) dari format serialisasi perintah tingkat tinggi (msgpack). Itulah sebabnya router (yang melakukan multicast / broadcast / relay) tidak melihat isi msgpack, juga tidak mengekstraksi atau memampatkan payload dan hanya melakukan transmisi.
Wiki hemat:
Apache Thrift memungkinkan Anda untuk menentukan tipe data dan antarmuka layanan dalam file definisi sederhana. Mengambil file itu sebagai input, kompiler menghasilkan kode yang akan digunakan untuk dengan mudah membangun klien RPC dan server yang berkomunikasi secara lancar di seluruh bahasa pemrograman. Alih-alih menulis kode boilerplate untuk membuat cerita bersambung dan mengangkut objek Anda dan memanggil metode jarak jauh.Kami mengambil kerangka kerja Hemat karena RPC dan dukungan berbagai bahasa sekaligus. Seperti biasa, bagian yang mudah mudah dibangun: klien dan server. Namun, router itu cukup sulit untuk retak, sebagian karena tidak adanya solusi yang siap digunakan pada saat itu.
Ada beberapa opsi lain, seperti protobuf / gRPC, meskipun ketika kami mulai dengan proyek kami, gRPC belum matang dan kami ragu untuk menggunakannya.
Tentu saja, kita bisa (dan seharusnya!) Membuat roda kita sendiri. Akan lebih mudah untuk membuat protokol khusus untuk apa yang kita butuhkan, bersama dengan router karena client-server lebih mudah diprogram daripada membuat router yang berfungsi dengan Thrift. Namun, ada negatif tradisional terhadap protokol khusus dan implementasi perpustakaan populer, dan selalu ada "bagaimana cara kami porting sesudahnya ke bahasa lain." Jadi kami memutuskan untuk membatalkan semua ide.
Deskripsi msgpack:
MessagePack adalah format serialisasi biner yang efisien. Ini memungkinkan Anda bertukar data di antara banyak bahasa seperti JSON. Tetapi lebih cepat dan lebih kecil. Bilangan bulat kecil dikodekan ke dalam satu byte, dan string pendek khas hanya membutuhkan satu byte tambahan sebagai tambahan dari string itu sendiri.Pada lapisan pertama, kita memiliki penghematan dengan informasi minimum yang diperlukan oleh router untuk mengirim pesan. Pada lapisan kedua, kami memiliki struktur msgpack terkompresi.
Kami memilih untuk msgpack karena lebih cepat dan lebih kompak dibandingkan dengan JSON. Namun, yang lebih penting, adalah mendukung tipe data khusus, memungkinkan untuk beberapa fitur menarik seperti "white-out" dan transfer data biner mentah.
JmespathJMESPath adalah bahasa permintaan untuk JSON.Itulah satu-satunya deskripsi yang kami dapatkan dari dokumentasi resmi JMESPath, tetapi sebenarnya, ini jauh lebih dari itu. JMESPath memungkinkan untuk mencari dan memfilter struktur seperti pohon yang sewenang-wenang dan bahkan menerapkan transformasi data dengan cepat. Kami menggunakan bahasa permintaan ini untuk mendapatkan informasi yang relevan dari gumpalan konfigurasi besar.
Sementara seluruh konfigurasi memiliki struktur mirip pohon, kami mengekstrak sub-pohon yang relevan untuk target konfigurasi yang berbeda.
Ini juga cukup fleksibel untuk mengubah sub-pohon, terlepas dari templat konfigurasi atau plugin konfigurasi lainnya. Untuk membuatnya lebih baik, JMES Path mudah diperluas dan memungkinkan untuk menulis filter kustom dan rutinitas transformasi data. Perlu beberapa kekuatan otak untuk memahaminya.
JinjaUntuk beberapa target, kita perlu merender konfigurasi menjadi file, jadi kita membutuhkan mesin template, di mana Jinja adalah pilihan yang jelas. Jinja menghasilkan file konfigurasi dari template dan data yang diterima di titik tujuan.
Untuk merender file konfigurasi, kita memerlukan permintaan jmespath, templat untuk path dan file tujuan, templat untuk konfigurasi itu sendiri. Juga, pada titik ini, ada baiknya untuk menentukan hak akses file. Semua ini untungnya digabungkan dalam satu file - sebelum templat konfigurasi, kami meletakkan header YAML, menjelaskan sisanya. Sebagai contoh:
---
selector: "[@][?@.fft._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) }}
Untuk membuat konfigurasi untuk perangkat baru, kami menambahkan file template baru, tidak diperlukan perubahan kode sumber dan pembaruan perangkat lunak PoP.
Apa yang telah berubah setelah menerapkan alat manajemen konfigurasi QControl?
Pertama dan terpenting, kami mendapatkan pembaruan konfigurasi yang koheren dan dapat diandalkan melalui semua jaringan kami.
Kedua, kami menempatkan alat yang ampuh untuk validasi konfigurasi dan berubah ke tangan tim dukungan kami dan klien kami.
Kami telah menyelesaikan ini dengan menggunakan desain terkini yang stabil untuk menyederhanakan komunikasi antara server konfigurasi dan penerima konfigurasi, dengan menggunakan protokol komunikasi dua lapis untuk mendukung router agnostik payload dan dengan menerapkan mesin rendering konfigurasi berbasis-Jinja untuk mendukung berbagai variasi file konfigurasi untuk perangkat kami yang beragam.