🥇Tarantool kasetė: „Lua“ užpakalinės dalies suskaidymas į tris eilutes

„Mail.ru Group“ turime „Tarantool“ - tai „Lua“ programų serveris, kuris taip pat veikia kaip duomenų bazė (ar atvirkščiai?). Tai greita ir šaunu, tačiau vieno serverio galimybės vis tiek nėra neribotos. Vertikalus mastelio keitimas taip pat nėra panacėja, todėl Tarantool turi įrankius horizontaliam mastelio keitimui – modulį vshard [1]. Tai leidžia suskaidyti duomenis keliuose serveriuose, tačiau turite su jais susitvarkyti, kad nustatytumėte ir pridėtumėte verslo logiką.

Geros naujienos: surinkome keletą didelių kadrų (pvz [2], [3]) ir sukūrė kitą sistemą, kuri žymiai supaprastins šios problemos sprendimą.

Tarantool kasetė yra nauja sudėtingų paskirstytų sistemų kūrimo sistema. Tai leidžia sutelkti dėmesį į verslo logikos rašymą, o ne infrastruktūros problemų sprendimą. Po pjūviu papasakosiu, kaip ši sistema veikia ir kaip naudojant ją rašyti paskirstytas paslaugas.

Kas tiksliai yra problema?

Mes turime tarantulą, turime vshardą - ko daugiau norėti?

Pirma, tai patogumo reikalas. Vshard konfigūracija sukonfigūruojama naudojant Lua lenteles. Kad paskirstyta kelių Tarantool procesų sistema veiktų tinkamai, konfigūracija visur turi būti vienoda. Niekas nenori to daryti rankiniu būdu. Todėl naudojami visokie scenarijai, Ansible ir diegimo sistemos.

Kasetė pati valdo vshard konfigūraciją, tai daro remdamasi ja paskirstyta konfigūracija. Iš esmės tai paprastas YAML failas, kurio kopija saugoma kiekviename Tarantool egzemplioriuje. Supaprastinimas yra tas, kad pati sistema stebi savo konfigūraciją ir užtikrina, kad ji visur būtų vienoda.

Antra, tai vėlgi patogumo reikalas. Vshard konfigūracija neturi nieko bendra su verslo logikos plėtra ir tik atitraukia programuotoją nuo jo darbo. Kai aptariame projekto architektūrą, dažniausiai kalbame apie atskirus komponentus ir jų sąveiką. Dar per anksti galvoti apie klasterio išleidimą į 3 duomenų centrus.

Mes vėl ir vėl sprendėme šias problemas ir tam tikru momentu mums pavyko sukurti metodą, kuris supaprastino darbą su programa per visą jos gyvavimo ciklą: kūrimą, kūrimą, testavimą, CI / CD, priežiūrą.

Kasetė pristato vaidmens koncepciją kiekvienam Tarantool procesui. Vaidmenys yra koncepcija, leidžianti kūrėjui sutelkti dėmesį į kodo rašymą. Visi projekte galimi vaidmenys gali būti vykdomi viename Tarantool egzemplioriuje, ir to pakaks testams.

Pagrindinės Tarantool kasetės savybės:

automatizuotas klasterių orkestravimas;
išplėsti programos funkcionalumą naudojant naujus vaidmenis;
kūrimo ir diegimo programos šablonas;
įmontuotas automatinis skilimas;
integracija su Luatest testavimo sistema;
klasterių valdymas naudojant WebUI ir API;
pakavimo ir išdėstymo įrankiai.

Labas pasauli!

Nekantrauju parodyti patį karkasą, todėl pasakojimą apie architektūrą paliksime vėlesniam laikui ir pradėsime nuo kažko paprasto. Jei darysime prielaidą, kad pati Tarantool jau įdiegta, belieka tik padaryti

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

Šios dvi komandos įdiegs komandų eilutės programas ir leis jums sukurti pirmąją programą iš šablono:

$ cartridge create --name myapp

Ir štai ką mes gauname:

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/

Tai „git“ saugykla su paruoštu „Sveikas, pasauli! taikymas. Pabandykime jį paleisti iš karto, prieš tai įdiegę priklausomybes (įskaitant pačią sistemą):

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

Taigi, turime vieną mazgą, skirtą būsimai susmulkintai programai. Smalsus pasaulietis gali iš karto atidaryti žiniatinklio sąsają, pele sukonfigūruoti vieno mazgo sankaupą ir mėgautis rezultatu, tačiau dar anksti džiaugtis. Kol kas programa negali padaryti nieko naudingo, todėl apie diegimą papasakosiu vėliau, bet dabar laikas parašyti kodą.

Programų kūrimas

Įsivaizduokite, mes kuriame projektą, kuris turi gauti duomenis, juos išsaugoti ir sukurti ataskaitą kartą per dieną.

Pradedame braižyti diagramą ir ant jos dedame tris komponentus: šliuzą, saugyklą ir planuoklį. Mes toliau dirbame su architektūra. Kadangi naudojame vshard kaip saugyklą, prie schemos pridedame vshard-router ir vshard-storage. Nei šliuzas, nei planuoklis tiesiogiai nepasieks saugyklos, tam skirtas maršrutizatorius, tam jis buvo sukurtas.

Ši diagrama vis dar tiksliai neatspindi to, ką mes statysime projekte, nes komponentai atrodo abstrakčiai. Vis dar turime pamatyti, kaip tai bus pritaikyta tikrajam Tarantool – sugrupuokime komponentus pagal procesą.

Nėra prasmės laikyti vshard-router ir gateway atskirais atvejais. Kodėl mums reikia dar kartą naršyti tinkle, jei tai jau yra maršrutizatoriaus atsakomybė? Jie turi būti vykdomi per tą patį procesą. Tai reiškia, kad vartai ir vshard.router.cfg inicijuojami viename procese ir leidžia jiems sąveikauti vietoje.

Projektavimo etape buvo patogu dirbti su trimis komponentais, tačiau aš, kaip kūrėjas, rašydamas kodą nenoriu galvoti apie trijų Tarnatool egzempliorių paleidimą. Turiu atlikti testus ir patikrinti, ar teisingai parašiau šliuzą. O gal noriu pademonstruoti savo kolegoms bruožą. Kodėl turėčiau išgyventi vargą diegdamas tris kopijas? Taip gimė vaidmenų samprata. Vaidmuo yra įprastas „luash“ modulis, kurio gyvavimo ciklą valdo „Cartridge“. Šiame pavyzdyje jų yra keturi – šliuzas, maršrutizatorius, saugykla, planuoklis. Kitame projekte gali būti daugiau. Visus vaidmenis galima atlikti vienu procesu, ir to pakaks.

O kai kalbama apie diegimą sustojimo ar gamybos metu, kiekvienam Tarantool procesui priskirsime savo vaidmenų rinkinį, atsižvelgdami į aparatinės įrangos galimybes:

Topologijos valdymas

Informacija apie tai, kur kurie vaidmenys veikia, turi būti kažkur saugoma. Ir tai „kažkur“ yra paskirstyta konfigūracija, kurią jau minėjau aukščiau. Svarbiausias dalykas yra klasterio topologija. Čia yra 3 replikacijos grupės iš 5 Tarantool procesų:

Nenorime prarasti duomenų, todėl su informacija apie vykdomus procesus elgiamės atsargiai. Kasetė seka konfigūraciją naudodama dviejų fazių patvirtinimą. Kai norime atnaujinti konfigūraciją, pirmiausia patikrinama, ar visi egzemplioriai yra prieinami ir pasirengę priimti naują konfigūraciją. Po to antrasis etapas pritaiko konfigūraciją. Taigi, net jei viena kopija pasirodys laikinai nepasiekiama, nieko blogo nenutiks. Konfigūracija tiesiog nebus pritaikyta ir iš anksto pamatysite klaidą.

Taip pat topologijos skyriuje nurodomas toks svarbus parametras kaip kiekvienos replikacijos grupės lyderis. Paprastai tai yra įrašoma kopija. Likusieji dažniausiai yra tik skaitomi, nors gali būti išimčių. Kartais drąsūs kūrėjai nebijo konfliktų ir gali lygiagrečiai įrašyti duomenis į kelias kopijas, tačiau yra keletas operacijų, kurių, kad ir kaip būtų, nederėtų atlikti du kartus. Už tai yra lyderio ženklas.

Vaidmenų gyvenimas

Kad tokioje architektūroje egzistuotų abstraktus vaidmuo, sistema turi kažkaip juos valdyti. Natūralu, kad valdymas vyksta neperkraunant Tarantool proceso. Yra 4 atgaliniai skambučiai vaidmenims valdyti. Pati kasetė juos iškvies priklausomai nuo to, kas parašyta jos paskirstytoje konfigūracijoje, taip pritaikydama konfigūraciją konkretiems vaidmenims.

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

Kiekvienas vaidmuo turi savo funkciją init. Jis iškviečiamas vieną kartą, kai vaidmuo įgalinamas arba Tarantool paleidžiamas iš naujo. Ten patogu, pavyzdžiui, inicijuoti box.space.create arba planuoklis gali paleisti kokį nors foninį pluoštą, kuris atliks darbą tam tikrais laiko intervalais.

Viena funkcija init gali nepakakti. Kasetė leidžia vaidmenims pasinaudoti paskirstytos konfigūracijos, kurią ji naudoja topologijai saugoti, pranašumais. Galime paskelbti naują skyrių toje pačioje konfigūracijoje ir joje saugoti verslo konfigūracijos fragmentą. Mano pavyzdyje tai gali būti duomenų schema arba planuotojo vaidmens tvarkaraščio nustatymai.

Klasterio skambučiai validate_config и apply_config kiekvieną kartą, kai pasikeičia paskirstyta konfigūracija. Kai konfigūracija taikoma dviejų fazių įteikimu, klasteris patikrina, ar kiekvienas vaidmuo yra pasirengęs priimti šią naują konfigūraciją, ir, jei reikia, praneša vartotojui apie klaidą. Kai visi sutinka, kad konfigūracija yra normali, tada apply_config.

Taip pat vaidmenys turi metodą stop, kurios reikia norint išvalyti vaidmens rezultatus. Jei sakysime, kad planuoklis šiame serveryje nebereikalingas, jis gali sustabdyti tuos pluoštus, su kuriais pradėjo veikti init.

Vaidmenys gali sąveikauti vienas su kitu. Esame įpratę rašyti funkcijų iškvietimus Lua programoje, tačiau gali atsitikti taip, kad tam tikras procesas neatlieka mums reikalingo vaidmens. Norėdami palengvinti skambučius tinkle, naudojame RPC (nuotolinio procedūrų skambučio) pagalbinį modulį, kuris yra sukurtas naudojant standartinį Tarantool įmontuotą tinklo dėžutę. Tai gali būti naudinga, jei, pavyzdžiui, jūsų šliuzas nori tiesiogiai paprašyti planuotojo atlikti darbą dabar, o ne laukti dieną.

Kitas svarbus dalykas yra gedimų tolerancijos užtikrinimas. Kasetė naudoja SWIM protokolą sveikatai stebėti [4]. Trumpai tariant, procesai keičiasi „gandais“ tarpusavyje dėl UDP – kiekvienas procesas praneša savo kaimynams paskutines naujienas, o jie atsako. Jei staiga atsakymas negaunamas, Tarantool pradeda įtarti, kad kažkas negerai, o po kurio laiko deklamuoja mirtį ir pradeda pasakoti visiems aplinkiniams šią naujieną.

Remdamasi šiuo protokolu, kasetė organizuoja automatinį gedimų apdorojimą. Kiekvienas procesas stebi savo aplinką ir, jei vadovas staiga nustoja reaguoti, replika gali perimti savo vaidmenį, o kasetė atitinkamai sukonfigūruoja veikiančius vaidmenis.

Čia reikia būti atsargiems, nes dažnas perjungimas pirmyn ir atgal gali sukelti duomenų konfliktus replikacijos metu. Žinoma, neturėtumėte įjungti automatinio perjungimo atsitiktinai. Turime aiškiai suprasti, kas vyksta, ir būti tikri, kad replikacija nenutrūks atkūrus lyderį ir jam grąžinus karūną.

Iš viso to gali susidaryti jausmas, kad vaidmenys yra panašūs į mikropaslaugas. Tam tikra prasme jie yra tik tokie, tik kaip Tarantool procesų moduliai. Tačiau yra ir nemažai esminių skirtumų. Pirma, visi projekto vaidmenys turi gyventi toje pačioje kodų bazėje. Ir visi Tarantool procesai turėtų būti paleisti iš tos pačios kodų bazės, kad nebūtų netikėtumų, pavyzdžiui, kai bandome inicijuoti planuoklį, bet jo tiesiog nėra. Taip pat neturėtumėte leisti kodo versijų skirtumų, nes sistemos elgseną tokioje situacijoje labai sunku numatyti ir derinti.

Kitaip nei Docker, mes negalime tiesiog paimti vaidmens „vaizdo“, perkelti jį į kitą mašiną ir ten paleisti. Mūsų vaidmenys nėra tokie izoliuoti kaip Docker konteineriai. Be to, viename egzemplioriuje negalime atlikti dviejų identiškų vaidmenų. Vaidmuo arba egzistuoja, arba ne, tam tikra prasme jis yra vienas. Ir trečia, vaidmenys turi būti vienodi visoje replikacijos grupėje, nes kitaip būtų absurdiška – duomenys tie patys, bet konfigūracija kitokia.

Diegimo įrankiai

Pažadėjau parodyti, kaip kasetė padeda diegti programas. Kad būtų lengviau gyventi kitiems, sistemoje yra RPM paketai:

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

Įdiegtame pakete yra beveik viskas, ko jums reikia: ir programa, ir įdiegtos priklausomybės. Tarantool taip pat pateks į serverį kaip RPM paketo priklausomybė, o mūsų paslauga yra paruošta paleisti. Tai daroma per systemd, bet pirmiausia turite parašyti šiek tiek konfigūracijos. Nurodykite bent kiekvieno proceso URI. Pavyzdžiui, pakanka trijų.

$ 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

Čia yra įdomus niuansas. Užuot nurodyę tik dvejetainio protokolo prievadą, nurodome visą viešąjį proceso adresą, įskaitant pagrindinio kompiuterio pavadinimą. Tai būtina, kad klasterio mazgai žinotų, kaip prisijungti vienas prie kito. Netinkama naudoti 0.0.0.0 kaip ads_uri adresą, tai turėtų būti išorinis IP adresas, o ne lizdas. Be jo niekas neveiks, todėl kasetė paprasčiausiai neleis paleisti mazgo su netinkamu ads_uri.

Dabar, kai konfigūracija paruošta, galite pradėti procesus. Kadangi įprastas sistemos blokas neleidžia pradėti daugiau nei vieno proceso, kasetėje esančios programos įdiegiamos vadinamuoju. momentiniai vienetai, kurie veikia taip:

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

Konfigūracijoje nurodėme HTTP prievadą, kuriame kasetė aptarnauja žiniatinklio sąsają – 8080. Eikime prie jo ir pažiūrėkime:

Matome, kad nors procesai veikia, jie dar nesukonfigūruoti. Užtaisas dar nežino, kas su kuo turėtų replikuotis ir negali pats priimti sprendimo, todėl laukia mūsų veiksmų. Tačiau mes neturime daug pasirinkimo: naujojo klasterio gyvavimas prasideda nuo pirmojo mazgo konfigūravimo. Tada pridėsime kitus prie klasterio, priskirsime jiems vaidmenis ir šiuo metu diegimas gali būti laikomas sėkmingai baigtu.

Išsipilkime taure mėgstamo gėrimo ir atsipalaiduosime po ilgos darbo savaitės. Programa gali būti naudojama.