Nekako zgodovinsko gledano je IT industrija iz kakršnega koli razloga razdeljena na dva pogojna tabora: tiste, ki so »za«, in tiste, ki so »proti«. Poleg tega je lahko predmet sporov povsem poljuben. Kateri OS je boljši: Win ali Linux? Na pametnem telefonu Android ali iOS? Bi morali vse shraniti v oblake ali dati v hladno shrambo RAID in vijake pospraviti na varno? Ali imajo PHP ljudje pravico, da se imenujejo programerji? Ti spori so včasih izključno eksistencialne narave in nimajo nobene druge podlage kot športni interes.
Tako se je zgodilo, da so se s prihodom vsebnikov in vse te ljubljene kuhinje z dockerji in pogojnimi k8 začele razprave "za" in "proti" uporabi novih zmogljivosti na različnih področjih ozadja. (Naredimo rezervacijo vnaprej, čeprav bo Kubernetes v tej razpravi najpogosteje označen kot orkestrator, izbira tega orodja ni bistvenega pomena. Namesto tega lahko zamenjate katero koli drugo, ki se vam zdi najbolj priročno in znano .)
In zdi se, da bi bil to preprost spor med dvema stranema istega kovanca. Tako nesmiselno in neusmiljeno, kot je večni spopad med Winom in Linuxom, v katerem so nekje na sredini ustrezni ljudje. Toda v primeru kontejnerizacije ni vse tako preprosto. Običajno v takšnih sporih ni prave strani, v primeru "uporabe" ali "neuporabe" vsebnikov za shranjevanje baz podatkov pa se vse obrne na glavo. Ker imajo v določenem smislu tako zagovorniki kot nasprotniki tega pristopa prav.
Svetla stran
Argument Svetle strani je mogoče na kratko opisati z enim stavkom: "Pozdravljeni, 2k19 je zunaj okna!" Sliši se seveda kot populizem, a če se podrobno poglobiš v situacijo, ima svoje prednosti. Zdaj jih razvrstimo.
Recimo, da imate velik spletni projekt. Lahko bi bil sprva zgrajen na podlagi mikrostoritvenega pristopa ali pa je na neki točki do njega prišel po evolucijski poti – to pravzaprav ni zelo pomembno. Naš projekt ste razpršili v ločene mikrostoritve, nastavili orkestracijo, uravnoteženje obremenitve in skaliranje. In zdaj mirne vesti med habra efekti srkaš mojito v viseči mreži namesto da bi dvigoval padle serverje. Toda v vseh dejanjih morate biti dosledni. Zelo pogosto je samo aplikacija sama – koda – zaprta. Kaj še imamo poleg kode?
Tako je, podatki. Srce vsakega projekta so njegovi podatki: to je lahko tipičen DBMS - MySQL, Postgre, MongoDB ali shramba, ki se uporablja za iskanje (ElasticSearch), shramba ključ-vrednost za predpomnjenje - na primer redis itd. Trenutno nismo govorili bomo o pokvarjenih možnostih izvedbe zaledja, ko se baza podatkov zruši zaradi slabo napisanih poizvedb, namesto tega pa bomo govorili o zagotavljanju tolerance napak prav te baze podatkov pod obremenitvijo odjemalca. Konec koncev, ko svojo aplikacijo pretvorimo v vsebnike in ji dovolimo, da se prosto prilagaja za obdelavo poljubnega števila dohodnih zahtev, to seveda poveča obremenitev baze podatkov.
Pravzaprav kanal za dostop do podatkovne baze in strežnik, na katerem teče, postaneta uho igle v našem čudovitem kontejnerskem zaledju. Hkrati je glavni motiv virtualizacije zabojnikov mobilnost in fleksibilnost strukture, ki nam omogoča čim bolj učinkovito organizacijo porazdelitve koničnih obremenitev po celotni infrastrukturi, ki nam je na voljo. To pomeni, da če vseh obstoječih elementov sistema ne pospravimo v kontejnerje in jih ne razgrnemo po gruči, delamo zelo resno napako.
Veliko bolj logično je združiti ne samo aplikacijo, ampak tudi storitve, odgovorne za shranjevanje podatkov. Z združevanjem in razmestitvijo spletnih strežnikov, ki delujejo neodvisno in si v k8s porazdelijo obremenitev, že rešujemo problem sinhronizacije podatkov – enakih komentarjev na objave, če vzamemo za primer kakšno medijsko ali blog platformo. V vsakem primeru imamo znotraj gruče, celo virtualno, predstavitev baze podatkov kot ExternalService. Vprašanje je, da sama zbirka podatkov še ni združena v gruče – spletni strežniki, ki so nameščeni v kocki, informacije o spremembah prejemajo iz naše statične bojne baze podatkov, ki se rotira ločeno.
Ali čutite ulov? Uporabljamo k8s ali Swarm za porazdelitev obremenitve in preprečevanje zrušitve glavnega spletnega strežnika, vendar tega ne počnemo za bazo podatkov. Toda če se zbirka podatkov zruši, potem naša celotna gručasta infrastruktura nima smisla - kaj nam pomagajo prazne spletne strani, ki vrnejo napako pri dostopu do baze podatkov?
Zato je treba združiti v gruče ne le spletne strežnike, kot se to običajno počne, ampak tudi infrastrukturo baze podatkov. Le tako lahko zagotovimo strukturo, ki deluje polno v enem timu, a hkrati neodvisno drug od drugega. Še več, tudi če se polovica našega ozadja pod obremenitvijo »zruši«, bo preostanek preživel, sistem medsebojne sinhronizacije baz podatkov znotraj gruče in zmožnost neskončnega prilagajanja in uvajanja novih gruč pa bosta pomagala hitro doseči zahtevano zmogljivost - če bi le obstajala stojala v podatkovnem centru.
Poleg tega vam model baze podatkov, porazdeljen v grozde, omogoča, da to bazo podatkov ponesete tja, kjer je potrebna; Če govorimo o globalni storitvi, potem je precej nelogično vrteti spletni grozd nekje na območju San Francisca in hkrati pošiljati pakete pri dostopu do baze podatkov v moskovski regiji in nazaj.
Tudi kontejnerizacija baze podatkov omogoča gradnjo vseh elementov sistema na isti ravni abstrakcije. Kar pa omogoča upravljanje prav tega sistema neposredno iz kode, s strani razvijalcev, brez aktivnega vpletanja skrbnikov. Razvijalci so menili, da je za nov podprojekt potreben ločen DBMS - preprosto! napisal datoteko yaml, jo naložil v gručo in končali ste.
In seveda, notranje delovanje je močno poenostavljeno. Povejte mi, kolikokrat ste zatisnili oči, ko je novi član ekipe za delo vtaknil roke v bojno bazo? Katera je pravzaprav edina, ki jo imate in se trenutno vrti? Seveda smo tu vsi odrasli in nekje imamo svežo rezervo, še dlje stran - za polico z babičinimi kumarami in starimi smučmi - pa še eno rezervo, morda celo v hladilnici, saj je vaša pisarna enkrat že gorela. A kljub temu je vsaka uvedba novega člana ekipe z dostopom do bojne infrastrukture in seveda do bojne baze vedro validola za vse okoli. No, kdo ga pozna, novinec, morda je križem rok? Strašljivo je, se strinjate.
Kontejnerizacija in pravzaprav porazdeljena fizična topologija baze podatkov vašega projekta pomagata preprečiti takšne trenutke preverjanja. Ne zaupate novincu? V REDU! Dajmo mu lastno gručo za delo in izključimo bazo podatkov iz drugih gruč - sinhronizacija samo z ročnim pritiskom in sinhronim vrtenjem dveh tipk (enega za vodjo ekipe, drugega za skrbnika). In vsi so srečni.
In zdaj je čas, da postanemo nasprotniki združevanja podatkovnih baz v gruče.
Temna stran
Če razpravljamo o tem, zakaj se baze podatkov ne splača kontejnerizirati in jo še naprej izvajati na enem osrednjem strežniku, se ne bomo spustili v retoriko ortodoksij in izjav, kot je "dedje so baze podatkov vodili na strojni opremi, mi jih bomo tudi!" Namesto tega poskusimo najti situacijo, v kateri bi kontejnerizacija dejansko izplačala oprijemljive dividende.
Strinjam se, projekte, ki resnično potrebujejo podlago v posodi, lahko na prste ene roke prešteje ne najboljši operater rezkalnika. Večinoma je tudi sama uporaba k8s ali Docker Swarm odveč - pogosto se k tem orodjem zatečejo zaradi splošnega pompa tehnologij in stališč "vsemogočnega" v osebi spolov, da vse potisnejo v oblaki in posode. No, saj je zdaj to moderno in vsi to počnejo.
V vsaj polovici primerov je uporaba Kubernetisa ali samo Dockerja na projektu odveč. Težava je v tem, da se vse ekipe ali zunanje izvajalske družbe, najete za vzdrževanje naročnikove infrastrukture, tega ne zavedajo. Huje je, ko so posode vsiljene, saj to stranko stane določeno količino kovancev.
Na splošno obstaja mnenje, da docker/cube mafija neumno drobi stranke, ki te infrastrukturne zadeve oddajo zunanjim izvajalcem. Konec koncev, za delo z grozdi potrebujemo inženirje, ki so tega sposobni in na splošno razumejo arhitekturo implementirane rešitve. Naš primer smo nekoč že opisali pri publikaciji Republic - tam smo ekipo naročnika usposobili za delo v realnostih Kubernetisa in vsi so bili zadovoljni. In bilo je spodobno. Pogosto "izvajalci" k8s vzamejo strankino infrastrukturo za talca - ker zdaj samo oni razumejo, kako tam vse deluje; na strani stranke ni strokovnjakov.
Zdaj pa si predstavljajte, da na ta način oddamo zunanjemu izvajalcu ne samo del spletnega strežnika, ampak tudi vzdrževanje baze podatkov. Rekli smo, da je BD srce in izguba srca je usodna za vsak živ organizem. Skratka, obeti niso najboljši. Torej, namesto hype Kubernetisa, se mnogi projekti preprosto ne bi smeli ukvarjati z običajno tarifo za AWS, ki bo rešila vse težave z obremenitvijo njihove strani/projekta. A AWS ni več moderen, bahanje pa je vredno več kot denar – žal tudi v IT okolju.
V REDU. Morda projekt res potrebuje združevanje v gruče, a če je z aplikacijami brez stanja vse jasno, kako potem lahko organiziramo dostojno omrežno povezljivost za bazo podatkov v gručah?
Če govorimo o brezhibni inženirski rešitvi, kar je prehod na k8s, potem je naš glavni glavobol replikacija podatkov v gručasti bazi podatkov. Nekateri DBMS so na začetku precej zvesti distribuciji podatkov med svojimi posameznimi primerki. Mnogi drugi niso tako dobrodošli. In pogosto glavni argument pri izbiri DBMS za naš projekt ni zmožnost replikacije z minimalnimi stroški virov in inženiringa. Še posebej, če projekt sprva ni bil načrtovan kot mikrostoritev, ampak se je preprosto razvijal v tej smeri.
Menimo, da o hitrosti omrežnih pogonov ni treba govoriti - počasni so. Tisti. Še vedno nimamo prave priložnosti, da bi, če se kaj zgodi, znova zagnali instanco DBMS nekje, kjer je več, na primer procesorske moči ali prostega RAM-a. Zelo hitro bomo naleteli na zmogljivost virtualiziranega diskovnega podsistema. V skladu s tem mora biti DBMS prikovan na svoj osebni niz strojev, ki se nahajajo v neposredni bližini. Ali pa je treba nekako posebej ohladiti dovolj hitro sinhronizacijo podatkov za domnevne rezerve.
Nadaljevanje teme o virtualnih datotečnih sistemih: Docker Volumes na žalost niso brez težav. Na splošno bi se v zadevi, kot je dolgoročno zanesljivo shranjevanje podatkov, rad zadovoljil s tehnično najbolj preprostimi shemami. In dodajanje nove abstraktne plasti iz FS vsebnika v FS nadrejenega gostitelja je samo po sebi tveganje. Ko pa se pri delovanju sistema za podporo kontejnerizacije pojavijo težave tudi pri prenosu podatkov med temi plastmi, potem je to res katastrofa. Trenutno se zdi, da je večina problemov, ki jih pozna napredno človeštvo, izkoreninjenih. Ampak razumete, bolj ko je mehanizem zapleten, lažje se zlomi.
Glede na vse te »pustolovščine« je veliko bolj donosno in lažje hraniti bazo podatkov na enem mestu, in tudi če morate aplikacijo pospraviti v kontejner, jo pustite, da teče sama in prek distribucijskega prehoda prejme hkratno komunikacijo z baza podatkov, ki bo prebrana in zapisana samo enkrat in na enem mestu. Ta pristop zmanjša verjetnost napak in desinhronizacije na minimum.
K čemu vodimo? Poleg tega je kontejnerizacija baze podatkov primerna tam, kjer obstaja resnična potreba po njej. Ne morete napolniti zbirke podatkov s celotno aplikacijo in jo zavrteti, kot da bi imeli dva ducata mikrostoritev – to ne deluje tako. In to je treba jasno razumeti.
Namesto izida
Če čakate na jasen zaključek "virtualizirati bazo podatkov ali ne", vas bomo razočarali: tukaj ga ne bo. Kajti pri ustvarjanju kakršne koli infrastrukturne rešitve se ne smemo ravnati po modi in napredku, ampak predvsem po zdravi pameti.
Obstajajo projekti, za katere načela in orodja, ki jih prinaša Kubernetis, popolnoma ustrezajo, in v takih projektih je mir vsaj v zaledju. In obstajajo projekti, ki ne potrebujejo kontejnerizacije, ampak običajno strežniško infrastrukturo, ker v osnovi ne morejo spremeniti velikosti v model gruče mikrostoritev, ker bodo padli.
Vir: www.habr.com