Kažkaip istoriškai IT pramonė dėl bet kokios priežasties yra padalinta į dvi sąlygines stovyklas: tuos, kurie yra „už“ ir tuos, kurie „prieš“. Be to, ginčų objektas gali būti visiškai savavališkas. Kuri OS geresnė: Win ar Linux? „Android“ ar „iOS“ išmaniajame telefone? Ar turėtumėte viską laikyti debesyse ar įdėti į šaltą RAID saugyklą ir įdėti varžtus į seifą? Ar PHP žmonės turi teisę būti vadinami programuotojais? Šie ginčai kartais yra išimtinai egzistencinio pobūdžio ir neturi jokio kito pagrindo, išskyrus sportinius interesus.
Taip jau atsitiko, kad atsiradus konteineriams ir visai šiai pamėgtai virtuvei su dokeriu ir sąlyginiais k8s, prasidėjo diskusijos „už“ ir „prieš“ naujų galimybių panaudojimą įvairiose backend srityse. (Iš anksto padarykime išlygą, kad nors Kubernetes šioje diskusijoje dažniausiai bus nurodytas kaip orkestrantas, šio konkretaus įrankio pasirinkimas nėra esminis. Vietoj to, galite pakeisti bet kurį kitą, kuris jums atrodo patogiausias ir pažįstamas .)
Ir, atrodytų, tai būtų paprastas ginčas tarp dviejų tos pačios monetos pusių. Toks pat beprasmis ir negailestingas, kaip amžina „Win“ ir „Linux“ konfrontacija, kurioje tinkami žmonės egzistuoja kažkur per vidurį. Tačiau konteinerizavimo atveju ne viskas taip paprasta. Dažniausiai tokiuose ginčuose nėra dešinės pusės, tačiau „naudoti“ ar „nenaudoti“ konteinerių duomenų bazėms saugoti atveju viskas apsiverčia aukštyn kojomis. Nes tam tikra prasme ir šio požiūrio šalininkai, ir priešininkai yra teisūs.
Šviesioji pusė
Šviesios pusės argumentą galima trumpai apibūdinti viena fraze: „Sveiki, 2k19 yra už lango! Žinoma, tai skamba kaip populizmas, bet jei įsigilini į situaciją detaliau, tai turi savų privalumų. Sutvarkykime juos dabar.
Tarkime, kad turite didelį žiniatinklio projektą. Iš pradžių jis galėjo būti sukurtas mikroserviso metodo pagrindu arba tam tikru momentu jis atėjo evoliucijos keliu – iš tikrųjų tai nėra labai svarbu. Išsklaidėte mūsų projektą į atskiras mikropaslaugas, nustatėte orkestravimą, apkrovos balansavimą ir mastelio keitimą. O dabar ramia sąžine per habros efektus gurkšnojate mojito hamake, o ne keldami nukritusius serverius. Tačiau visuose veiksmuose turite būti nuoseklūs. Labai dažnai tik pati programa – kodas – talpinama. Ką dar turime be kodo?
Teisingai, duomenys. Bet kurio projekto esmė yra jo duomenys: tai gali būti tipinė DBVS – MySQL, Postgre, MongoDB arba saugykla, naudojama paieškai (ElasticSearch), raktų vertės saugykla talpykloje kaupti, pvz., redis ir kt. Šiuo metu mes nesame kalbėsime apie kreivas backend diegimo parinktis, kai duomenų bazė sugenda dėl prastai parašytų užklausų, o vietoj to kalbėsime apie šios duomenų bazės atsparumo gedimams užtikrinimą, kai klientas apkraunamas. Galų gale, kai sutalpiname savo programą ir leidžiame jai laisvai keisti mastelį, kad būtų galima apdoroti bet kokį gaunamų užklausų skaičių, tai natūraliai padidina duomenų bazės apkrovą.
Tiesą sakant, prieigos prie duomenų bazės ir serverio, kuriame jis veikia, kanalas mūsų nuostabioje talpykloje yra tarsi adatos akis. Kartu pagrindinis konteinerių virtualizacijos motyvas yra konstrukcijos mobilumas ir lankstumas, leidžiantis kuo efektyviau organizuoti piko apkrovų paskirstymą visoje mums prieinamoje infrastruktūroje. Tai yra, jei nekonteineruojame ir neišskleidžiame visų esamų sistemos elementų visame klasteryje, darome labai rimtą klaidą.
Daug logiškiau sugrupuoti ne tik pačią programą, bet ir paslaugas, atsakingas už duomenų saugojimą. Klasterizuodami ir diegdami žiniatinklio serverius, kurie dirba savarankiškai ir paskirsto apkrovą tarpusavyje k8s, jau sprendžiame duomenų sinchronizavimo problemą – tie patys komentarai prie įrašų, jei pavyzdžiu paimtume kokią nors mediją ar tinklaraščio platformą. Bet kuriuo atveju mes turime klasterį, net virtualų, duomenų bazės atvaizdavimą kaip išorinę paslaugą. Kyla klausimas, kad pati duomenų bazė dar nėra sugrupuota – kube dislokuoti žiniatinklio serveriai informaciją apie pakeitimus ima iš mūsų statinės kovos duomenų bazės, kuri sukasi atskirai.
Ar jaučiate laimikį? Naudojame k8s arba Swarm, kad paskirstytume apkrovą ir išvengtume pagrindinio žiniatinklio serverio strigimo, tačiau duomenų bazėje to nedarome. Bet jei duomenų bazė sugenda, tada visa mūsų sugrupuota infrastruktūra neturi prasmės – kam iš tušti tinklalapiai, kurie grąžina duomenų bazės prieigos klaidą?
Štai kodėl reikia klasterizuoti ne tik žiniatinklio serverius, kaip paprastai daroma, bet ir duomenų bazių infrastruktūrą. Tik tokiu būdu galime užtikrinti struktūrą, kuri visiškai veikia vienoje komandoje, bet kartu ir nepriklausoma viena nuo kitos. Be to, net jei pusė mūsų užpakalinės programos „sugrius“ veikiant apkrovai, likusi dalis išliks, o duomenų bazių sinchronizavimo sistema klasteryje ir galimybė be galo didinti ir diegti naujas grupes padės greitai pasiekti reikiamą pajėgumą. jei tik duomenų centre būtų stovai .
Be to, klasteriuose paskirstytas duomenų bazės modelis leidžia perkelti būtent šią duomenų bazę ten, kur jos reikia; Jei mes kalbame apie pasaulinę paslaugą, tai yra gana nelogiška sukurti žiniatinklio klasterį kur nors San Francisko srityje ir tuo pačiu metu siųsti paketus, kai pasiekiate duomenų bazę Maskvos regione ir atgal.
Taip pat duomenų bazės konteinerizavimas leidžia sukurti visus sistemos elementus tame pačiame abstrakcijos lygyje. Tai, savo ruožtu, leidžia valdyti šią sistemą tiesiogiai iš kodo, kūrėjams, be aktyvaus administratorių įsitraukimo. Kūrėjai manė, kad naujam subprojektui reikia atskiros DBVS – paprasta! parašė yaml failą, įkėlė jį į klasterį ir viskas.
Ir, žinoma, vidinis veikimas yra labai supaprastintas. Sakykite, kiek kartų užsimerkėte, kai naujas komandos narys darbui įdėjo rankas į kovinę duomenų bazę? Kuris iš tikrųjų yra vienintelis, kurį turite ir šiuo metu sukasi? Žinoma, mes čia visi suaugę, ir kažkur turime šviežią atsarginę kopiją, o dar toliau - už lentynos su močiutės agurkais ir senomis slidėmis - dar vieną atsarginę kopiją, galbūt net šaldytuve, nes kažkada jūsų biuras jau degė. Bet vis tiek kiekvienas naujo komandos nario, turinčio prieigą prie kovos infrastruktūros ir, žinoma, kovos duomenų bazės, pristatymas yra kibiras validolio visiems aplinkiniams. Na, kas jį pažįsta, naujoką, gal jis sukryžiavo? Baisu, sutikite.
Jūsų projekto duomenų bazės talpinimas ir, tiesą sakant, paskirstyta fizinė topologija padeda išvengti tokių patvirtinimo momentų. Nepasitiki naujoku? GERAI! Duokime jam dirbti su savo klasteriu ir atjunkite duomenų bazę nuo kitų grupių - sinchronizavimas tik rankiniu būdu ir sinchroniniu dviejų klavišų pasukimu (vienas skirtas komandos vadovui, kitas administratoriui). Ir visi laimingi.
O dabar laikas tapti duomenų bazių grupavimo priešininkais.
Tamsioji pusė
Argumentuodami, kodėl neverta talpinti duomenų bazės ir toliau ją paleisti viename centriniame serveryje, nepasileisime prie ortodoksų retorikos ir teiginių, kaip „seneliai tvarkė duomenų bazes aparatinėje įrangoje, o mes taip pat! Vietoj to, pabandykime sugalvoti situaciją, kurioje konteinerizavimas iš tikrųjų duotų apčiuopiamų dividendų.
Sutikite, projektus, kuriems tikrai reikia pagrindo konteineryje, ne pats geriausias frezavimo staklių operatorius gali suskaičiuoti ant vienos rankos pirštų. Daugeliu atvejų net pats k8s ar Docker Swarm naudojimas yra perteklinis - gana dažnai šių įrankių imamasi dėl bendro technologijų ažiotažo ir „visagalio“ požiūrio į lyčių asmenį, norint viską sustumti į debesys ir konteineriai. Na, nes dabar tai madinga ir visi taip daro.
Mažiausiai puse atvejų projekte naudoti „Kubernetis“ ar tiesiog „Docker“ yra perteklinė. Problema ta, kad ne visos komandos ar užsakomųjų paslaugų įmonės, pasamdytos prižiūrėti kliento infrastruktūrą, tai žino. Blogiau, kai dedami konteineriai, nes tai klientui kainuoja tam tikrą monetų kiekį.
Apskritai yra nuomonė, kad dokerių/kubų mafija kvailai triuškina klientus, kurie šias infrastruktūros problemas perduoda iš išorės. Juk norint dirbti su klasteriais reikia tai gebančių inžinierių, kurie apskritai supranta įgyvendinamo sprendimo architektūrą. Kažkada jau aprašėme savo atvejį su leidiniu „Respublika“ – ten mokėme kliento komandą dirbti „Kubernečio“ realijomis ir visi liko patenkinti. Ir buvo padoru. Dažnai k8s „diegėjai“ paima kliento infrastruktūrą įkaitais – nes dabar tik jie supranta, kaip ten viskas veikia, kliento pusėje nėra specialistų.
Dabar įsivaizduokite, kad tokiu būdu perkame ne tik žiniatinklio serverio dalį, bet ir duomenų bazės priežiūrą. Mes sakėme, kad BD yra širdis, o širdies praradimas yra mirtinas bet kuriam gyvam organizmui. Trumpai tariant, perspektyvos nėra pačios geriausios. Taigi, vietoj ažiotažo Kubernetis, daugelis projektų turėtų tiesiog nesivarginti su įprastu AWS tarifu, kuris išspręs visas problemas dėl jų svetainės/projekto apkrovos. Tačiau AWS nebėra madinga, o pasirodymai verti daugiau nei pinigai – deja, ir IT aplinkoje.
GERAI. Galbūt projektui tikrai reikia klasterizuoti, bet jei viskas aišku su programomis be būsenos, kaip galime organizuoti tinkamą tinklo ryšį sugrupuotai duomenų bazei?
Jei kalbame apie vientisą inžinerinį sprendimą, kuris yra perėjimas prie k8s, tada pagrindinis mūsų galvos skausmas yra duomenų replikacija sugrupuotoje duomenų bazėje. Kai kurios DBVS iš pradžių yra gana ištikimos duomenų paskirstymui tarp atskirų egzempliorių. Daugelis kitų nėra tokie svetingi. Ir gana dažnai pagrindinis argumentas renkantis DBVS mūsų projektui yra ne galimybė atkartoti su minimaliomis resursų ir inžinerinėmis sąnaudomis. Ypač jei projektas iš pradžių nebuvo planuotas kaip mikropaslaugos, o tiesiog vystėsi šia kryptimi.
Manome, kad nereikia kalbėti apie tinklo diskų greitį – jie lėti. Tie. Vis dar neturime realios galimybės, jei kas atsitiks, iš naujo paleisti DBVS egzempliorių kur nors, kur yra daugiau, pavyzdžiui, procesoriaus galios ar laisvos RAM. Labai greitai susidursime su virtualizuoto disko posistemio veikimu. Atitinkamai, DBVS turi būti prikaltas prie jos asmeninio mašinų rinkinio, esančio arti. Arba reikia kažkaip atskirai atvėsinti pakankamai greitą duomenų sinchronizaciją tariamiems rezervams.
Tęsiant temą apie virtualias failų sistemas: Docker Volumes, deja, nėra be problemų. Apskritai tokiu klausimu kaip ilgalaikis patikimas duomenų saugojimas, norėčiau apsieiti su pačiomis techniškai paprasčiausiomis schemomis. Naujo abstrakcijos sluoksnio įtraukimas iš konteinerio FS į pagrindinio pagrindinio kompiuterio FS yra savaime rizika. Tačiau kai konteinerizacijos palaikymo sistema taip pat susiduria su sunkumais perduodant duomenis tarp šių sluoksnių, tai tikrai yra nelaimė. Šiuo metu atrodo, kad dauguma progresyviai žmonijai žinomų problemų jau išnaikintos. Bet jūs suprantate, kuo sudėtingesnis mechanizmas, tuo lengviau jis sugenda.
Atsižvelgiant į visus šiuos „nuotykius“, daug pelningiau ir lengviau laikyti duomenų bazę vienoje vietoje ir net jei reikia sudėti programą, leisti jai veikti pačiai ir per platinimo šliuzą gauti tuo pačiu metu ryšį su duomenų bazė, kuri bus skaitoma ir rašoma tik vieną kartą ir vienoje vietoje. Šis metodas sumažina klaidų ir desinchronizacijos tikimybę iki minimumo.
Prie ko mes vedame? Be to, duomenų bazių talpinimas yra tinkamas ten, kur tikrai to reikia. Negalite užpildyti visos programos duomenų bazės ir sukti jos taip, lyg turėtumėte dvi dešimtis mikro paslaugų – tai neveikia. Ir tai turi būti aiškiai suprantama.
Vietoj produkcijos
Jei laukiate aiškios išvados „virtualizuoti duomenų bazę ar ne“, mes jus nuvilsime: jos čia nebus. Nes kuriant bet kokį infrastruktūros sprendimą reikia vadovautis ne mada ir pažanga, o, visų pirma, sveiku protu.
Yra projektų, kuriems su Kubernetis ateinantys principai ir įrankiai puikiai tinka, o tokiuose projektuose ramybė bent jau backend srityje. Ir yra projektų, kuriems reikia ne konteinerizavimo, o normalios serverių infrastruktūros, nes jie iš esmės negali persiskambinti į mikroservisų klasterio modelį, nes nukris.
Šaltinis: www.habr.com