🥇Tarantool Kartuşu: Üç sətirdə Lua arxa hissənin parçalanması

Mail.ru Group-da bizdə Tarantool var - bu, Lua-da bir proqram serveridir, bu da birləşmiş verilənlər bazasıdır (və ya əksinə?). Sürətli və sərindir, lakin tək bir serverin imkanları hələ də qeyri-məhdud deyil. Şaquli miqyaslama da panacea deyil, buna görə Tarantool-da üfüqi miqyaslama üçün alətlər var - vshard modulu [1]. Bu, birdən çox server arasında məlumatları parçalamağa imkan verir, lakin onu qurmaq və biznes məntiqini sındırmaq üçün onunla işləmək məcburiyyətindəsiniz.

Yaxşı xəbər: konusları topladıq (məsələn [2], [3]) və bu problemin həllini əhəmiyyətli dərəcədə asanlaşdıracaq başqa bir çərçivə təqdim etdi.

Tarantool kartuşu mürəkkəb paylanmış sistemlərin inkişafı üçün yeni çərçivədir. Bu, infrastruktur problemlərini həll etmək əvəzinə iş məntiqini yazmağa diqqət yetirməyə imkan verir. Kəsmə altında sizə bu çərçivənin necə işlədiyini və paylanmış xidmətlərin necə yazacağını söyləyəcəyəm.

Və problem tam olaraq nədir?

Tarantulamız var, vshardımız var - daha nə istəyə bilərsən?

Birincisi, bu, rahatlıq məsələsidir. Vshard konfiqurasiyası Lua cədvəlləri vasitəsilə konfiqurasiya edilir. Çoxsaylı Tarantool proseslərinin paylanmış sisteminin düzgün işləməsi üçün konfiqurasiya hər yerdə eyni olmalıdır. Heç kim bunu əl ilə etmək istəmir. Buna görə də hər cür skript, Ansible, yerləşdirmə sistemləri istifadə olunur.

Kartric vshard konfiqurasiyasını özü idarə edir, bunu özü əsasında edir öz paylanmış konfiqurasiyası. Əsasən, bir nüsxəsi Tarantool-un hər bir nümunəsində saxlanılan sadə bir YAML faylıdır. Sadələşdirmə ondan ibarətdir ki, çərçivə özü onun konfiqurasiyasına nəzarət edir və onun hər yerdə eyni olmasını təmin edir.

İkincisi, yenə də rahatlıq məsələsidir. Vshard konfiqurasiyasının biznes məntiqinin inkişafı ilə heç bir əlaqəsi yoxdur və yalnız proqramçının diqqətini işdən yayındırır. Layihənin arxitekturasını müzakirə edərkən, ən çox fərdi komponentlər və onların qarşılıqlı əlaqəsi haqqında danışırıq. 3 məlumat mərkəzi üçün klaster yaratmaq barədə düşünmək hələ tezdir.

Biz bu problemləri vaxtaşırı həll etdik və müəyyən bir nöqtədə proqramla işi bütün həyat dövrü ərzində sadələşdirməyə imkan verən bir yanaşma hazırlamağa müvəffəq olduq: yaradılması, inkişafı, sınaqdan keçirilməsi, CI / CD, texniki xidmət.

Kartric hər bir Tarantool prosesi üçün rol anlayışını təqdim edir. Rollar tərtibatçıya kod yazmağa diqqət yetirməyə imkan verən konsepsiyadır. Layihədə mövcud olan bütün rollar bir Tarantool nümunəsində işlədilə bilər və bu, testlər üçün kifayət edəcəkdir.

Tarantool kartricinin əsas xüsusiyyətləri:

avtomatlaşdırılmış klaster orkestrasiyası;
tətbiq funksionallığının yeni rollarla genişləndirilməsi;
inkişaf və yerləşdirmə üçün tətbiq şablonu;
quraşdırılmış avtomatik parçalanma;
Luatest test çərçivəsi ilə inteqrasiya;
WebUI və API istifadə edərək klasterin idarə edilməsi;
qablaşdırma və yerləşdirmə alətləri.

Salam, Dünya!

Çərçivənin özünü göstərmək üçün səbirsizlənirəm, ona görə də arxitektura haqqında hekayəni sonraya buraxıb sadə başlayaq. Tarantool-un özünün artıq quraşdırıldığını fərz etsək, ediləcək tək şey qalır

$ tarantoolctl rocks install cartridge-cli
$ export PATH=$PWD/.rocks/bin/:$PATH

Bu iki əmr əmr satırı yardım proqramlarını quraşdıracaq və şablondan ilk tətbiqinizi yaratmağa imkan verəcək:

$ cartridge create --name myapp

Və əldə etdiyimiz budur:

myapp/
├── .git/
├── .gitignore
├── app/roles/custom.lua
├── deps.sh
├── init.lua
├── myapp-scm-1.rockspec
├── test
│   ├── helper
│   │   ├── integration.lua
│   │   └── unit.lua
│   ├── helper.lua
│   ├── integration/api_test.lua
│   └── unit/sample_test.lua
└── tmp/

Bu, "Salam, Dünya!" ilə git deposudur. tətbiq. Asılılıqları quraşdırdıqdan sonra (çərçivənin özü də daxil olmaqla) dərhal onu işə salmağa çalışaq:

$ tarantoolctl rocks make
$ ./init.lua --http-port 8080

Beləliklə, bizdə gələcək partladılmış tətbiqin bir qovşağı var. Maraqlı bir layman dərhal veb interfeysini aça, siçan ilə bir qovşaqdan klasteri konfiqurasiya edə və nəticədən həzz ala bilər, lakin sevinmək üçün hələ tezdir. Hələ ki, tətbiq faydalı bir şey etməyi bilmir, ona görə də yerləşdirmə haqqında daha sonra danışacağam və indi kod yazmaq vaxtıdır.

Tətbiq İnkişafı

Təsəvvür edin, biz məlumatları qəbul etməli, saxlamalı və gündə bir dəfə hesabat hazırlamalı olan bir layihə hazırlayırıq.

Diaqramı çəkməyə başlayırıq və üzərinə üç komponent yerləşdiririk: şlüz, saxlama və planlaşdırıcı. Memarlıq üzərində işləyirik. Biz vshard-dan yaddaş kimi istifadə etdiyimiz üçün sxemə vshard-router və vshard-storage əlavə edirik. Nə şlüz, nə də planlaşdırıcı anbara birbaşa daxil olmayacaq, bunun üçün bir marşrutlaşdırıcı var, bunun üçün yaradılmışdır.

Bu diaqram hələ də layihədə nə yaradacağımızı tam dəqiq əks etdirmir, çünki komponentlər mücərrəd görünür. Bunun real Tarantool-a necə proqnozlaşdırıldığını hələ də görməliyik - gəlin komponentlərimizi proseslərə görə qruplaşdıraq.

Vshard-router və gateway-i ayrı-ayrı instansiyalarda saxlamağın mənası yoxdur. Əgər bu artıq marşrutlaşdırıcının məsuliyyətidirsə, niyə şəbəkəni bir daha keçməliyik? Onlar eyni proses daxilində işlədilməlidir. Yəni həm gateway, həm də vshard.router.cfg bir prosesdə işə salınır və onların lokal olaraq qarşılıqlı fəaliyyət göstərməsinə icazə verilir.

Dizayn mərhələsində üç komponentlə işləmək rahat idi, lakin bir tərtibatçı olaraq kod yazarkən Tarnatool-un üç nümunəsini işlətmək barədə düşünmək istəmirəm. Testlər keçirməli və şlüzün düzgün yazıldığını yoxlamalıyam. Yaxud həmkarlarıma bir xüsusiyyət nümayiş etdirmək istəyirəm. Mən niyə üç instansiya yerləşdirməklə məşğul olmalıyam? Rol anlayışı belə yarandı. Rol adi luash moduludur, onun həyat dövrü Kartric tərəfindən idarə olunur. Bu nümunədə onlardan dördü var - şlüz, marşrutlaşdırıcı, saxlama, planlaşdırıcı. Başqa bir layihədə daha çox ola bilər. Bütün rollar bir prosesdə işlədilə bilər və bu kifayət edəcəkdir.

Və səhnələşdirmə və ya istehsala yerləşdirməyə gəldikdə, biz hər bir Tarantool prosesinə aparat imkanlarından asılı olaraq öz rollar dəstini təyin edəcəyik:

Topologiyanın idarə edilməsi

Hansı rolların işlədiyi barədə məlumat bir yerdə saxlanmalıdır. Və bu "haradasa" yuxarıda qeyd etdiyim paylanmış konfiqurasiyadır. Onda ən vacib şey klasterin topologiyasıdır. Budur 3 Tarantool prosesinin 5 təkrarlama qrupu:

Biz məlumatları itirmək istəmirik, ona görə də çalışan proseslər haqqında məlumatların qayğısına qalırıq. Kartric iki fazalı öhdəliyi ilə konfiqurasiyanı izləyir. Konfiqurasiyanı yeniləmək istəyən kimi o, ilk növbədə bütün nümunələrin mövcud olduğunu və yeni konfiqurasiyanı qəbul etməyə hazır olduğunu yoxlayır. Bundan sonra ikinci mərhələ konfiqurasiyanı tətbiq edir. Beləliklə, bir nüsxə müvəqqəti olaraq əlçatmaz olsa belə, pis bir şey olmayacaq. Konfiqurasiya sadəcə tətbiq edilməyəcək və əvvəlcədən bir səhv görəcəksiniz.

Topologiya bölməsində hər bir təkrarlama qrupunun lideri kimi mühüm parametr də var. Bu adətən yazılan nümunədir. İstisnalar ola bilər, baxmayaraq ki, qalanları çox vaxt yalnız oxunur. Bəzən cəsarətli tərtibatçılar münaqişələrdən qorxmur və məlumatları paralel olaraq bir neçə replikaya yaza bilərlər, lakin bəzi əməliyyatlar var ki, hər şeyə baxmayaraq, iki dəfə yerinə yetirilməməlidir. Bunun üçün bir lider əlaməti var.

Rolların həyatı

Belə bir arxitekturada mücərrəd bir rolun mövcud olması üçün çərçivə onları bir şəkildə idarə etməlidir. Təbii ki, idarəetmə Tarantool prosesini yenidən başlatmadan baş verir. Rolları idarə etmək üçün 4 geri çağırış var. Kartricin özü paylanmış konfiqurasiyada yazdıqlarından asılı olaraq onları çağıracaq və bununla da konfiqurasiyanı xüsusi rollara tətbiq edəcəkdir.

function init()
function validate_config()
function apply_config()
function stop()

Hər rolun bir funksiyası var init. Bir rol aktiv olduqda və ya Tarantool yenidən işə salındıqda bir dəfə çağırılır. Orada, məsələn, box.space.create-i işə salmaq rahatdır və ya planlaşdırıcı müəyyən fasilələrlə işi yerinə yetirəcək bəzi fon liflərini işə sala bilər.

tək funksiya init yetərli olmaya bilər. Kartric rollara topologiyanı saxlamaq üçün istifadə etdiyi paylanmış konfiqurasiyadan istifadə etməyə imkan verir. Eyni konfiqurasiyada yeni bölmə elan edə və orada biznes konfiqurasiya fraqmentini saxlaya bilərik. Mənim nümunəmdə bu, məlumat sxemi və ya planlaşdırıcı rolu üçün cədvəl parametrləri ola bilər.

Klaster zəngləri validate_config и apply_config hər dəfə paylanmış konfiqurasiya dəyişir. Konfiqurasiya iki fazalı öhdəçilik tərəfindən tətbiq edildikdə, klaster hər bir rolun bu yeni konfiqurasiyanı qəbul etməyə hazır olduğunu yoxlayır və lazım olduqda istifadəçiyə xəta haqqında məlumat verir. Hər kəs konfiqurasiyanın normal olduğuna razılaşdıqda, o zaman apply_config.

Rolların da bir üsulu var stopBu, rolun həyati hissələrini təmizləmək üçün lazımdır. Planlayıcıya artıq bu serverdə ehtiyac olmadığını söyləsək, o, başladığı lifləri dayandıra bilər init.

Rollar bir-biri ilə qarşılıqlı əlaqədə ola bilər. Biz Lua-da funksiya çağırışlarını yazmağa öyrəşmişik, lakin ola bilər ki, bu prosesdə bizə lazım olan heç bir rol yoxdur. Şəbəkə üzərindən zəngləri asanlaşdırmaq üçün biz Tarantool-da quraşdırılmış standart netbox əsasında qurulmuş rpc (uzaqdan prosedur çağırışı) köməkçi modulundan istifadə edirik. Bu, məsələn, şlüzünüz planlaşdırıcıdan işi bir gün gözləməkdənsə, dərhal yerinə yetirməsini xahiş etmək istəsə faydalı ola bilər.

Başqa bir vacib məqam səhvlərə dözümlülüyün təmin edilməsidir. Kartric sağlamlığına nəzarət etmək üçün SWIM protokolundan istifadə edir [4]. Bir sözlə, proseslər UDP üzərindən bir-biri ilə “şayiələr” mübadiləsi aparır – hər bir proses qonşularına ən son xəbərləri deyir və onlar da cavab verirlər. Birdən cavab gəlmədisə, Tarantool nəyinsə səhv olduğundan şübhələnməyə başlayır və bir müddət sonra ölümü söyləyir və bu xəbəri ətrafdakı hər kəsə danışmağa başlayır.

Bu protokola əsasən, Kartric nasazlıqların avtomatik idarə edilməsini təşkil edir. Hər bir proses öz mühitinə nəzarət edir və əgər lider qəflətən cavab verməyi dayandırarsa, replika öz rolunu götürə bilər və Kartric çalışan rolları müvafiq olaraq konfiqurasiya edir.

Burada diqqətli olmalısınız, çünki tez-tez irəli-geri keçid replikasiya zamanı məlumat konfliktlərinə səbəb ola bilər. Təsadüfi olaraq avtomatik uğursuzluğu işə salmaq, əlbəttə ki, buna dəyməz. Nə baş verdiyini aydın şəkildə başa düşməlisiniz və lider bərpa edildikdən və tac ona qaytarıldıqdan sonra təkrarlamanın pozulmayacağına əmin olun.

Yuxarıda göstərilənlərin hamısından, rolların mikroservislər kimi olduğunu hiss edə bilərsiniz. Müəyyən mənada, onlar yalnız Tarantool proseslərində modullardır. Ancaq bir sıra əsaslı fərqlər də var. Birincisi, bütün layihə rolları eyni kod bazasında yaşamalıdır. Və bütün Tarantool prosesləri eyni kod bazasından işləməlidir ki, planlaşdırıcını işə salmağa çalışdığımız zaman sürprizlər olmasın, lakin o, sadəcə mövcud deyil. Həmçinin, kod versiyalarında fərqlərə yol verməməlisiniz, çünki belə bir vəziyyətdə sistemin davranışını proqnozlaşdırmaq və debug etmək çox çətindir.

Docker-dən fərqli olaraq, biz sadəcə bir rolun "şəklini" götürə, onu başqa maşına aparıb orada işlədə bilmərik. Bizim rollarımız Docker konteynerləri qədər təcrid olunmuş deyil. Həmçinin, biz eyni nümunədə iki eyni rolu icra edə bilmərik. Rol ya var, ya da yoxdur, müəyyən mənada təkdir. Üçüncüsü, bütün replikasiya qrupu daxilində rollar eyni olmalıdır, çünki əks halda bu, gülünc olardı - məlumatlar eynidir, lakin konfiqurasiya fərqlidir.

Yerləşdirmə alətləri

Mən Cartridge proqramların yerləşdirilməsinə necə kömək etdiyini göstərməyə söz verdim. Başqalarının həyatını asanlaşdırmaq üçün çərçivə RPM paketlərini paketləyir:

$ cartridge pack rpm myapp -- упакует для нас ./myapp-0.1.0-1.rpm
$ sudo yum install ./myapp-0.1.0-1.rpm

Quraşdırılmış paket demək olar ki, sizə lazım olan hər şeyi ehtiva edir: həm proqram, həm də quraşdırılmış luash asılılıqları. Tarantool da RPM paketindən asılı olaraq serverə gələcək və xidmətimiz işə salınmağa hazırdır. Bu systemd vasitəsilə edilir, lakin əvvəlcə bir az konfiqurasiya yazmalısınız. Ən azı hər bir prosesin URI-ni təyin edin. Bir nümunə üçün üç kifayətdir.

$ sudo tee /etc/tarantool/conf.d/demo.yml <<CONFIG
myapp.router: {"advertise_uri": "localhost:3301", "http_port": 8080}
myapp.storage_A: {"advertise_uri": "localhost:3302", "http_enabled": False}
myapp.storage_B: {"advertise_uri": "localhost:3303", "http_enabled": False}
CONFIG

Burada maraqlı bir nüans var. Yalnız ikili protokol portunu təyin etmək əvəzinə, host adı daxil olmaqla prosesin bütün ictimai ünvanını təyin edirik. Bu, çoxluq qovşaqlarının bir-birinə necə qoşulacağını bilməsi üçün lazımdır. 0.0.0.0-dan advertise_uri kimi istifadə etmək pis fikirdir, o, bağlama yuvası deyil, ictimai IP olmalıdır. Onsuz heç bir şey işləməyəcək, ona görə də Kartric sadəcə olaraq yanlış advertise_uri ilə bir node işə salmağa imkan verməyəcək.

İndi konfiqurasiya hazırdır, proseslərə başlaya bilərsiniz. Adi sistem vahidi birdən çox prosesin başlamasına imkan vermədiyindən, Kartricdəki proqramlar sözdə quraşdırılır. bu kimi işləyən qurulmuş vahidlər:

$ sudo systemctl start myapp@router
$ sudo systemctl start myapp@storage_A
$ sudo systemctl start myapp@storage_B

Konfiqurasiyada biz Kartricin veb interfeysinə xidmət etdiyi HTTP portunu göstərdik - 8080. Gəlin ona keçək və baxaq:

Biz görürük ki, proseslər işləsə də, hələ konfiqurasiya olunmayıb. Patron hələ kimin kiminlə təkrarlamalı olduğunu bilmir və özbaşına qərar qəbul edə bilmir, ona görə də bizim hərəkətlərimizi gözləyir. Və çox seçimimiz yoxdur: yeni bir çoxluğun həyatı ilk qovşağın konfiqurasiyası ilə başlayır. Sonra qalanları klasterə əlavə edirik, onlara rollar təyin edirik və bu nöqtədə yerləşdirmə uğurla başa çatmış hesab edilə bilər.

Sevdiyiniz içkidən bir stəkan tökün və uzun bir iş həftəsindən sonra istirahət edin. Tətbiq işlədilə bilər.