TL; DR: Daxili şəbəkə konfiqurasiya idarəetmə sistemimizin müştəri-server arxitekturasının təsviri, QControl. O, son nöqtələr arasında dekompressiya olmadan gzip paketli mesajlarla işləyən iki qatlı nəqliyyat protokoluna əsaslanır. Paylanmış marşrutlaşdırıcılar və son nöqtələr konfiqurasiya yeniləmələrini alır və protokolun özü lokallaşdırılmış aralıq relelərin quraşdırılmasına imkan verir. Sistem prinsip əsasında qurulub ("son-sabit", aşağıda izah edilmişdir) və konfiqurasiya fayllarını göstərmək üçün Jinja şablon mühərriki ilə birlikdə JMESpath sorğu dilini istifadə edir.
Qrator Labs qlobal miqyasda yayılmış hücumların azaldılması şəbəkəsini idarə edir. Şəbəkəmiz anycast prinsipi ilə işləyir və alt şəbəkələr BGP vasitəsilə reklam olunur. Fiziki olaraq Yer kürəsinin bir neçə bölgəsində yerləşən BGP anycast şəbəkəsi olaraq, biz İnternetin nüvəsinə - Tier-1 operatorlarına daha yaxın olan qeyri-qanuni trafiki emal edə və filtrləyə bilərik.
Digər tərəfdən, coğrafi olaraq paylanmış şəbəkə olmaq asan deyil. Şəbəkə mövcudluq nöqtələri arasında əlaqə təhlükəsizlik xidməti provayderinin bütün şəbəkə qovşaqlarının ardıcıl konfiqurasiyasına malik olması və onları vaxtında yeniləməsi üçün çox vacibdir. Buna görə də, istehlakçıya mümkün olan ən yüksək səviyyəli əsas xidmət göstərmək üçün konfiqurasiya məlumatlarını qitələr arasında etibarlı şəkildə sinxronlaşdırmaq üçün bir yol tapmalı olduq.
Başlanğıcda Söz idi. Tez bir zamanda yeniləməyə ehtiyacı olan bir rabitə protokoluna çevrildi.
QControl-un mövcudluğunun təməl daşı və eyni zamanda bu cür protokolun qurulmasına xeyli vaxt və resurs sərf etməyin əsas səbəbi vahid səlahiyyətli konfiqurasiya mənbəyi əldə etmək və nəhayət, mövcud nöqtələrimizi sinxronlaşdırmaq ehtiyacıdır. Bununla. Saxlamanın özü QControl-un inkişafı zamanı bir neçə tələbdən yalnız biri idi. Bundan əlavə, bizə mövcud və planlaşdırılan xidmətlərlə mövcud nöqtələrdə (POP), məlumatların yoxlanılması üçün ağıllı (və fərdiləşdirilə bilən) üsullarla inteqrasiyaya, həmçinin girişə nəzarətə ehtiyacımız var. Bundan əlavə, biz də fayllara dəyişiklik etməkdənsə, əmrlərdən istifadə edərək belə bir sistemi idarə etmək istədik. QControl-dan əvvəl məlumatlar mövcud nöqtələrə demək olar ki, əl ilə göndərilirdi. Əgər mövcudluq nöqtələrindən biri əlçatmaz olsaydı və biz onu sonradan yeniləməyi unutsaq, konfiqurasiya sinxronizasiyadan çıxacaq və onu yenidən işə salmaq üçün vaxt itirməli olacaqdıq.
Nəticədə aşağıdakı sxemə gəldik:
Konfiqurasiya serveri məlumatların yoxlanılması və saxlanmasına cavabdehdir; marşrutlaşdırıcının müştərilərdən və dəstək qruplarından serverə və serverdən mövcudluq nöqtələrinə konfiqurasiya yeniləmələrini qəbul edən və yayımlayan bir neçə son nöqtəsi var.
İnternetə qoşulma keyfiyyəti hələ də bütün dünyada geniş şəkildə dəyişir - bu məqamı göstərmək üçün Praqadan, Çexiyadan Sinqapur və Honq Konqa qədər sadə MTR-ə nəzər salaq.
Praqadan Sinqapura MTR
Honq-Konqa da eyni şey
Yüksək gecikmə aşağı sürət deməkdir. Bundan əlavə, paket itkisi var. Kanalın eni bu problemi kompensasiya etmir, mərkəzləşdirilməmiş sistemlər qurarkən həmişə nəzərə alınmalıdır.
Mövcudluq nöqtəsinin tam konfiqurasiyası etibarsız bağlantılar üzərindən bir çox alıcıya göndərilməli olan əhəmiyyətli miqdarda məlumatdır. Xoşbəxtlikdən, konfiqurasiya daim dəyişsə də, kiçik artımlarla baş verir.
Son stabil dizayn
Deyə bilərik ki, artımlı yeniləmələr prinsipi əsasında paylanmış şəbəkə qurmaq kifayət qədər açıq bir həlldir. Ancaq fərqlərlə bağlı çoxlu problemlər var. İstinad nöqtələri arasındakı bütün fərqləri yadda saxlamalıyıq və həmçinin məlumatların bir hissəsini kimsə qaçırdığı halda onları yenidən göndərə bilməliyik. Hər bir təyinat məntəqəsi onları ciddi şəkildə müəyyən edilmiş ardıcıllıqla tətbiq etməlidir. Tipik olaraq, bir neçə istiqamətə gəldikdə, belə bir əməliyyat uzun müddət çəkə bilər. Qəbul edən həm də çatışmayan hissələri tələb edə bilməlidir və təbii ki, mərkəzi hissə belə sorğuya düzgün cavab verərək yalnız çatışmayan məlumatları göndərməlidir.
Nəticədə, biz kifayət qədər maraqlı bir həllə gəldik - sabitlənmiş yalnız bir istinad təbəqəmiz var, onu sabit adlandıraq və bunun üçün yalnız bir fərq var - son. Hər bir yeni son yaradılan stabilə əsaslanır və konfiqurasiya məlumatlarını yenidən qurmaq üçün kifayətdir. Təzə yenisi təyinat yerinə çatan kimi köhnəsinə ehtiyac qalmır.
Qalır ki, vaxtaşırı təzə stabil konfiqurasiya göndərməkdir, məsələn, son vaxtlar çox böyük olduğundan. Burada vacib olan odur ki, biz bütün bu yeniləmələri ayrı-ayrı alıcılar və onların məlumat hissələrini birləşdirmək qabiliyyətindən narahat olmadan yayım/çox yayım rejimində göndəririk. Hər kəsin düzgün tövləyə malik olduğuna əmin olduqdan sonra biz yalnız yenilərini göndəririk. Bunun işlədiyini aydınlaşdırmağa dəyərmi? işləyir. Stabil konfiqurasiya serverində və alıcılarda yaddaşda saxlanılır, lazım olduqda ən son yaradılır.
İki səviyyəli nəqliyyatın memarlığı
Nə üçün nəqliyyatımızı iki səviyyədə qurduq? Cavab olduqca sadədir - biz nəqliyyat və tətbiq səviyyələri ilə OSI modelindən ilham alaraq marşrutlaşdırmanı yüksək səviyyəli məntiqdən ayırmaq istədik. Nəqliyyat protokolunun rolu üçün Thrift-dən və nəzarət mesajlarının yüksək səviyyəli formatı üçün msgpack serializasiya formatından istifadə etdik. Buna görə marşrutlaşdırıcı (çox yayım/yayım/relay yerinə yetirir) msgpack-in içərisinə baxmır, məzmunu paketdən çıxarmır və ya qablaşdırmır və yalnız məlumatları ötürür.
Qənaət (ingilis dilindən - "qənaət", tələffüz [θrift]) müxtəlif proqramlaşdırma dilləri üçün xidmətləri müəyyən etmək və yaratmaq üçün istifadə olunan interfeys təsviri dilidir. O, uzaqdan prosedur çağırışları (RPC) üçün çərçivədir. Dillər arasında az və ya çox səmərəli və asanlıqla işləyən xidmətləri inkişaf etdirmək üçün proqram təminatı boru kəmərini kod yaratmaq mühərriki ilə birləşdirir.
RPC və bir çox dilləri dəstəklədiyimiz üçün Thrift çərçivəsini seçdik. Həmişə olduğu kimi, asan hissələr müştəri və server idi. Bununla belə, marşrutlaşdırıcı, qismən inkişafımız zamanı hazır həllin olmaması səbəbindən çatlamaq üçün çətin bir qoz oldu.
Protobuf / gRPC kimi başqa variantlar da var, lakin biz layihəmizə başlayanda gRPC olduqca yeni idi və biz onu işə götürməyə cəsarət etmədik.
Əlbəttə ki, biz öz velosipedimizi hazırlaya bilərdik (və əslində olmalı idik). Ehtiyacımız olan şeylər üçün protokol yaratmaq daha asan olardı, çünki Thrift-də marşrutlaşdırıcı qurmaqla müqayisədə müştəri-server arxitekturasının həyata keçirilməsi nisbətən sadədir. Bu və ya digər şəkildə, öz-özünə yazılmış protokollara və populyar kitabxanaların tətbiqinə ənənəvi qərəzli münasibət var (üzrlü səbəbə görə); üstəlik, müzakirələr zamanı həmişə sual yaranır: "Bunu başqa dillərə necə köçürəcəyik?" Beləliklə, biz dərhal velosiped ideyasını atdıq.
Msgpack JSON-a bənzəyir, lakin daha sürətli və daha kiçikdir. Bu, çoxlu dillər arasında məlumat mübadiləsinə imkan verən ikili verilənlərin serializasiya formatıdır.
Birinci səviyyədə, marşrutlaşdırıcının mesajı ötürməsi üçün lazım olan minimum məlumatı olan Qənaətimiz var. İkinci səviyyədə paketlənmiş msgpack strukturları var.
Biz msgpack-i seçdik, çünki o, JSON ilə müqayisədə daha sürətli və yığcamdır. Ancaq daha da əhəmiyyətlisi, o, xüsusi məlumat növlərini dəstəkləyir və bizə “son sabit” sxemimiz üçün vacib olan məlumatların olmamasını göstərən xam ikili faylları və ya xüsusi obyektləri ötürmək kimi gözəl xüsusiyyətlərdən istifadə etməyə imkan verir.
JMESPath
JMESPath JSON sorğu dilidir.
Rəsmi JMESPath sənədlərindən əldə etdiyimiz təsvir tam olaraq belə görünür, lakin əslində, bundan daha çox şey edir. JMESPath ixtiyari ağac strukturunda alt ağacları axtarmağa və süzgəcdən keçirməyə və məlumatlara dəyişiklikləri tez bir zamanda tətbiq etməyə imkan verir. O, həmçinin xüsusi filtrlər və məlumatların çevrilməsi prosedurlarını əlavə etməyə imkan verir. Baxmayaraq ki, bunu başa düşmək üçün əlbəttə ki, beyin səyi lazımdır.
Jinja
Bəzi istehlakçılar üçün konfiqurasiyanı fayla çevirməliyik - buna görə də şablon mühərrikindən istifadə edirik və Jinja açıq seçimdir. Onun köməyi ilə biz təyinat yerində alınan şablon və məlumatlardan konfiqurasiya faylı yaradırıq.
Konfiqurasiya faylı yaratmaq üçün bizə JMESPath sorğusu, FS-də fayl yeri üçün şablon və konfiqurasiyanın özü üçün şablon lazımdır. Bu mərhələdə fayl icazələrini aydınlaşdırmaq da yaxşı bir fikirdir. Bütün bunlar uğurla bir faylda birləşdirildi - konfiqurasiya şablonuna başlamazdan əvvəl, qalanını təsvir edən YAML formatında bir başlıq qoyduq.
Misal üçün:
---
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 xidmət üçün konfiqurasiya faylı yaratmaq üçün biz yalnız yeni şablon faylı əlavə edirik. Varlıq nöqtələrində mənbə koduna və ya proqram təminatına heç bir dəyişiklik tələb olunmur.
QControl yayımlanandan sonra nə dəyişdi? Birinci və ən vacib şey, konfiqurasiya yeniləmələrinin şəbəkədəki bütün qovşaqlara ardıcıl və etibarlı çatdırılmasıdır. İkincisi, dəstək komandamız, eləcə də xidmət istehlakçıları tərəfindən konfiqurasiyanı yoxlamaq və ona dəyişikliklər etmək üçün güclü alət əldə etməkdir.
Biz bütün bunları konfiqurasiya serveri ilə konfiqurasiya alıcıları arasında əlaqəni sadələşdirmək üçün son sabit yeniləmə sxemindən istifadə edərək edə bildik. Məlumatların yönləndirilməsinin məzmundan asılı olmayan üsulunu dəstəkləmək üçün iki qatlı protokoldan istifadə. Jinja əsaslı konfiqurasiya yaratma mühərriki paylanmış filtrləmə şəbəkəsinə uğurla inteqrasiya edildi. Bu sistem paylanmış və heterojen periferiyalarımız üçün geniş spektrli konfiqurasiya üsullarını dəstəkləyir.
Materialın yazılmasında köməyinizə görə təşəkkür edirik. , , .
post.
Mənbə: www.habr.com