TL; DR: Dahili ağ konfigürasyon yönetim sistemimiz QControl'ün istemci-sunucu mimarisinin açıklaması. Uç noktalar arasında sıkıştırmayı açmadan gzip paketli mesajlarla çalışan iki katmanlı bir aktarım protokolüne dayanmaktadır. Dağıtılmış yönlendiriciler ve uç noktalar yapılandırma güncellemelerini alır ve protokolün kendisi de yerelleştirilmiş ara rölelerin kurulumuna izin verir. Sistem şu prensip üzerine inşa edilmiştir: (“son kararlı”, aşağıda açıklanmıştır) ve yapılandırma dosyalarını oluşturmak için JMESpath sorgu dilini Jinja şablon oluşturma motoruyla birlikte kullanır.
Qrator Labs, küresel olarak dağıtılmış bir saldırı azaltma ağını işletmektedir. Ağımız her noktaya yayın ilkesiyle çalışır ve alt ağların reklamı BGP aracılığıyla yapılır. Dünyanın çeşitli bölgelerinde fiziksel olarak bulunan bir BGP her noktaya yayın ağı olarak, İnternet'in çekirdeğine (Kademe-1 operatörleri) daha yakın olan yasa dışı trafiği işleyebilir ve filtreleyebiliriz.
Öte yandan coğrafi olarak dağıtık bir ağ olmak da kolay değil. Ağın varlık noktaları arasındaki iletişim, güvenlik hizmeti sağlayıcısının tüm ağ düğümlerinin tutarlı bir yapılandırmasına sahip olması ve bunları zamanında güncellemesi açısından kritik öneme sahiptir. Bu nedenle, tüketiciye mümkün olan en yüksek düzeyde temel hizmet sağlamak amacıyla, yapılandırma verilerini kıtalar arasında güvenilir bir şekilde senkronize etmenin bir yolunu bulmamız gerekiyordu.
Başlangıçta Söz vardı. Hızla güncellenmesi gereken bir iletişim protokolü haline geldi.
QControl'ün varlığının temel taşı ve aynı zamanda bu tür bir protokol oluşturmak için önemli miktarda zaman ve kaynak harcamanın ana nedeni, tek bir yetkili konfigürasyon kaynağı elde etme ve sonuçta varlık noktalarımızı senkronize etme ihtiyacıdır. Bununla birlikte. Depolamanın kendisi, QControl'ün geliştirilmesi sırasındaki çeşitli gereksinimlerden yalnızca biriydi. Ayrıca erişim noktalarında mevcut ve planlanan hizmetlerle (POP), veri doğrulama için akıllı (ve özelleştirilebilir) yöntemlerin yanı sıra erişim kontrolüyle entegrasyonlara da ihtiyacımız vardı. Bunun yanı sıra böyle bir sistemi dosyalarda değişiklik yapmak yerine komutlarla da kontrol etmek istedik. QControl'den önce veriler, varlık noktalarına neredeyse manuel olarak gönderiliyordu. Varlık noktalarından biri kullanılamıyorsa ve onu daha sonra güncellemeyi unutursak, konfigürasyonun senkronizasyonu bozulur ve onu tekrar çalışır duruma getirmek için zaman harcamak zorunda kalırız.
Sonuç olarak aşağıdaki şemayı oluşturduk:
Yapılandırma sunucusu, veri doğrulama ve depolamadan sorumludur; yönlendiricinin, yapılandırma güncellemelerini istemcilerden ve destek ekiplerinden sunucuya ve sunucudan varlık noktalarına alıp yayınlayan çeşitli uç noktaları vardır.
İnternet bağlantı kalitesi hala dünya çapında büyük farklılıklar göstermektedir; bu noktayı açıklamak için Prag, Çek Cumhuriyeti'nden Singapur ve Hong Kong'a kadar basit bir MTR'ye bakalım.
Prag'dan Singapur'a MTR
Hong Kong'a da aynı şey
Yüksek gecikme, daha düşük hız anlamına gelir. Ayrıca paket kaybı da var. Kanal genişliği, merkezi olmayan sistemler kurarken her zaman dikkate alınması gereken bu sorunu telafi etmez.
Bir varlık noktasının tam yapılandırması, güvenilmez bağlantılar üzerinden birçok alıcıya gönderilmesi gereken önemli miktarda veridir. Neyse ki, konfigürasyon sürekli değişse de bu küçük artışlarla gerçekleşir.
Son zamanlardaki kararlı tasarım
Artımlı güncelleme ilkesine dayalı dağıtılmış bir ağ oluşturmanın oldukça açık bir çözüm olduğunu söyleyebiliriz. Ancak farklarla ilgili birçok sorun var. Referans noktaları arasındaki tüm farkları kaydetmemiz ve ayrıca birisinin verinin bir kısmını kaçırması durumunda bunları yeniden gönderebilmemiz gerekiyor. Her hedefin bunları kesin olarak belirlenmiş bir sırayla uygulaması gerekir. Genellikle birden fazla varış noktası olması durumunda bu tür bir işlem uzun zaman alabilir. Alıcının aynı zamanda eksik parçaları da talep edebilmesi ve tabii ki merkezi parçanın böyle bir talebe yalnızca eksik verileri göndererek doğru yanıt vermesi gerekir.
Sonuç olarak, oldukça ilginç bir çözüme ulaştık - yalnızca bir referans katmanımız var, sabit, buna kararlı diyelim ve bunun için yalnızca bir fark var - güncel. Her yeni, son oluşturulan kararlı olanı temel alır ve yapılandırma verilerini yeniden oluşturmak için yeterlidir. Yeni olan hedefine ulaştığında artık eskisine ihtiyaç kalmaz.
Geriye kalan tek şey zaman zaman yeni ve kararlı bir yapılandırma göndermektir; örneğin son sürüm çok büyük hale geldiğinden. Burada önemli olan, tüm bu güncellemeleri yayın/çoklu yayın modunda, bireysel alıcılar ve onların veri parçalarını bir araya getirme yetenekleri konusunda endişelenmeden göndermemizdir. Herkesin doğru ahıra sahip olduğundan emin olduktan sonra yalnızca yeni ve güncel ahırları göndeririz. Bunun işe yaradığını açıklamaya değer mi? İşler. Kararlı, yapılandırma sunucusunda ve alıcılarda önbelleğe alınır, gerektiğinde en yenisi oluşturulur.
İki seviyeli ulaşımın mimarisi
Taşımamızı neden iki seviyede inşa ettik? Cevap oldukça basit; taşıma ve uygulama katmanlarıyla OSI modelinden ilham alarak yönlendirmeyi üst düzey mantıktan ayırmak istedik. Aktarım protokolünün rolü için Thrift'i ve kontrol mesajlarının yüksek düzey formatı için msgpack serileştirme formatını kullandık. Bu nedenle yönlendirici (çok noktaya yayın/yayın/aktarma gerçekleştiren) msgpack'in içine bakmaz, içeriği paketinden çıkarmaz veya geri paketlemez ve yalnızca verileri iletir.
Tutumluluk (İngilizce'den - “tasarruf”, telaffuz edilir [θrift]), farklı programlama dilleri için hizmetleri tanımlamak ve oluşturmak için kullanılan bir arayüz tanımlama dilidir. Uzaktan prosedür çağrıları (RPC) için bir çerçevedir. Diller arasında az çok verimli ve kolay çalışan hizmetler geliştirmek için bir yazılım hattını kod oluşturma motoruyla birleştirir.
RPC ve birçok dili desteklemesi nedeniyle Thrift çerçevesini seçtik. Her zamanki gibi kolay kısımlar istemci ve sunucuydu. Bununla birlikte, kısmen geliştirmemiz sırasında hazır bir çözümün bulunmamasından dolayı yönlendiricinin kırılması zor bir somun olduğu ortaya çıktı.
Protobuf / gRPC gibi başka seçenekler de var ancak projemize başladığımızda gRPC oldukça yeniydi ve onu almaya cesaret edemedik.
Elbette kendi bisikletimizi yapabilirdik (ve aslında yapmalıydık). İhtiyacımız olan şey için bir protokol oluşturmak daha kolay olurdu çünkü istemci-sunucu mimarisinin uygulanması, Thrift'te bir yönlendirici oluşturmaya kıyasla nispeten basittir. Öyle ya da böyle, popüler kütüphanelerin kendi kendine yazılan protokolleri ve uygulamalarına yönelik geleneksel bir önyargı vardır (bunun iyi bir nedeni vardır); ayrıca tartışmalar sırasında şu soru her zaman ortaya çıkar: "Bunu diğer dillere nasıl aktaracağız?" Biz de bisiklet fikrinden hemen vazgeçtik.
Msgpack JSON'a benzer ancak daha hızlı ve daha küçüktür. Birden fazla dil arasında veri alışverişine olanak tanıyan ikili veri serileştirme formatıdır.
İlk seviyede, yönlendiricinin mesajı iletmesi için gereken minimum bilgiyi içeren Thrift'e sahibiz. İkinci seviyede paketlenmiş msgpack yapıları bulunmaktadır.
JSON'a göre daha hızlı ve daha kompakt olduğu için msgpack'i seçtik. Ancak daha da önemlisi, özel veri türlerini destekleyerek ham ikili dosyaların veya veri yokluğunu gösteren özel nesnelerin iletilmesi gibi harika özellikleri kullanmamıza olanak tanır; bu, "son kararlı" planımız için önemliydi.
JMESYol
JMESPath bir JSON sorgu dilidir.
Resmi JMESPath belgelerinden aldığımız açıklama tam olarak buna benziyor ancak aslında bundan çok daha fazlasını yapıyor. JMESPath, rastgele bir ağaç yapısındaki alt ağaçları aramanıza ve filtrelemenize ve verilere anında değişiklik uygulamanıza olanak tanır. Ayrıca özel filtreler ve veri dönüştürme prosedürleri eklemenize de olanak tanır. Her ne kadar elbette anlamak için beyin çabası gerektirse de.
Jinja
Bazı tüketiciler için konfigürasyonu bir dosyaya dönüştürmemiz gerekiyor; bu nedenle bir şablon motoru kullanıyoruz ve Jinja bariz seçimdir. Onun yardımıyla şablondan ve hedefte alınan verilerden bir yapılandırma dosyası oluşturuyoruz.
Bir konfigürasyon dosyası oluşturmak için bir JMESPath isteğine, FS'deki dosya konumu için bir şablona ve konfigürasyonun kendisi için bir şablona ihtiyacımız var. Bu aşamada dosya izinlerini netleştirmek de iyi bir fikirdir. Tüm bunlar başarıyla tek bir dosyada birleştirildi - yapılandırma şablonunun başlangıcından önce, gerisini açıklayan YAML biçiminde bir başlık koyduk.
Örneğin:
---
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) }}
Yeni bir hizmete ait yapılandırma dosyası oluşturmak için yalnızca yeni bir şablon dosyası ekliyoruz. Kaynak kodunda veya yazılımda mevcudiyet noktalarında herhangi bir değişiklik yapılmasına gerek yoktur.
QControl yayına girdiğinden beri neler değişti? İlk ve en önemli şey, yapılandırma güncellemelerinin ağdaki tüm düğümlere tutarlı ve güvenilir bir şekilde iletilmesidir. İkincisi, destek ekibimizin yanı sıra hizmetin tüketicileri tarafından yapılandırmayı kontrol etmek ve değişiklik yapmak için güçlü bir araç edinmektir.
Tüm bunları, yapılandırma sunucusu ile yapılandırma alıcıları arasındaki iletişimi basitleştirmek için en son kararlı güncelleme şemasını kullanarak yapabildik. Verileri yönlendirmenin içerikten bağımsız bir yolunu desteklemek için iki katmanlı bir protokol kullanma. Jinja tabanlı bir konfigürasyon oluşturma motoru, dağıtılmış bir filtreleme ağına başarıyla entegre edildi. Bu sistem, dağıtılmış ve heterojen çevre birimlerimiz için çok çeşitli yapılandırma yöntemlerini destekler.
Materyali yazma konusundaki yardımınız için teşekkür ederiz. , , .
postalamak.
Kaynak: habr.com