Kuidagi ajalooliselt jaguneb IT-tööstus mis tahes põhjusel kahte tingimuslikku leeri: need, kes on poolt ja need, kes on vastu. Pealegi võib vaidluste teema olla täiesti meelevaldne. Milline OS on parem: Win või Linux? Androidi või iOS-i nutitelefonis? Kas hoida kõike pilvedes või panna külmale RAID-mällu ja kruvid seifi panna? Kas PHP inimestel on õigus olla programmeerijateks? Need vaidlused on kohati eranditult eksistentsiaalsed ja neil pole muud alust kui sportlikud huvid.
Juhtus nii, et konteinerite ja kogu selle armastatud köögi tulekuga dockeri ja tingimuslike k8-dega algasid vaidlused uute võimaluste kasutamise poolt ja vastu erinevatel taustaprogrammi valdkondades. (Tehkeme juba ette reservatsiooni, et kuigi Kubernetes on selles arutelus kõige sagedamini märgitud orkestreerijaks, ei ole selle konkreetse tööriista valik põhimõttelise tähtsusega. Selle asemel võite asendada mõne muu, mis teile kõige mugavam ja tuttavam tundub .)
Ja tundub, et see oleks lihtne vaidlus sama mündi kahe poole vahel. Sama mõttetu ja halastamatu nagu igavene vastasseis Win vs Linuxi vahel, kus adekvaatsed inimesed eksisteerivad kuskil keskel. Kuid konteineriseerimise puhul pole kõik nii lihtne. Tavaliselt pole sellistes vaidlustes õiget poolt, kuid andmebaaside hoidmiseks mõeldud konteinerite “kasuta” või “mitte kasuta” puhul pöördub kõik pea peale. Sest teatud mõttes on õigus nii selle lähenemise pooldajatel kui ka vastastel.
Hele pool
Light Side'i argumenti saab lühidalt kirjeldada ühe lausega: "Tere, 2k19 on akna taga!" See kõlab muidugi populismina, aga kui olukorda täpsemalt süveneda, on sellel omad plussid. Sorteerime need nüüd ära.
Oletame, et teil on suur veebiprojekt. See võis olla algselt üles ehitatud mikroteenuste lähenemise alusel või mingil hetkel jõudis see selleni evolutsiooni tee kaudu – see pole tegelikult väga oluline. Jagasite meie projekti eraldi mikroteenusteks, seadistasite orkestreerimise, koormuse tasakaalustamise ja skaleerimise. Ja nüüd rüüpad puhta südametunnistusega habraefektide ajal võrkkiiges mojitot, selle asemel, et allakukkunud servereid tõsta. Kuid kõigis tegevustes peate olema järjekindel. Väga sageli on konteinerisse paigutatud ainult rakendus ise – kood. Mis meil peale koodi veel on?
See on õige, andmed. Iga projekti keskmes on selle andmed: see võib olla kas tüüpiline DBMS – MySQL, Postgre, MongoDB või otsinguks kasutatav salvestusruum (ElasticSearch), võtmeväärtuste salvestusruum vahemällu salvestamiseks – näiteks redis jne. Praegu me seda ei tee. räägime kõveratest taustaprogrammi juurutamise võimalustest, kui andmebaas halvasti kirjutatud päringute tõttu kokku jookseb, ja selle asemel räägime just selle andmebaasi veataluvuse tagamisest kliendi koormuse all. Lõppude lõpuks, kui me oma rakenduse konteinerisse paigutame ja lubame sellel vabalt skaleerida, et töödelda mis tahes arvu sissetulevaid taotlusi, suurendab see loomulikult andmebaasi koormust.
Tegelikult muutub andmebaasile juurdepääsu kanal ja server, millel see töötab, meie kauni konteineri taustaprogrammi nõelasilmaks. Samas on konteinerite virtualiseerimise peamiseks motiiviks struktuuri mobiilsus ja paindlikkus, mis võimaldab võimalikult efektiivselt korraldada tippkoormuste jaotust kogu meie käsutuses oleva taristu ulatuses. See tähendab, et kui me kõiki olemasolevaid süsteemi elemente üle klastri ei koonda ega juuruta, teeme väga tõsise vea.
Palju loogilisem on rühmitada mitte ainult rakendus ise, vaid ka andmete salvestamise eest vastutavad teenused. Klasterdades ja juurutades iseseisvalt töötavaid ja k8s-des koormuse jaotavaid veebiservereid, lahendame juba andmete sünkroniseerimise probleemi - samad kommentaarid postitustele, kui võtta näiteks mõni meedia- või blogiplatvorm. Igal juhul on meil klastrisisese, isegi virtuaalse andmebaasi esitus välisteenusena. Küsimus on selles, et andmebaas ise pole veel rühmitatud – kuubis juurutatud veebiserverid võtavad info muudatuste kohta meie staatilisest lahinguandmebaasist, mis pöörleb eraldi.
Kas tunnete saaki? Koormuse jaotamiseks ja peamise veebiserveri krahhi vältimiseks kasutame k8s või Swarm, kuid andmebaasi jaoks me seda ei tee. Kui aga andmebaas jookseb kokku, siis pole kogu meie klastritaristul mõtet – mis kasu on tühjadest veebilehtedest, mis tagastavad andmebaasi juurdepääsu vea?
Seetõttu on vaja klastrida mitte ainult veebiservereid, nagu tavaliselt tehakse, vaid ka andmebaasi infrastruktuuri. Ainult nii saame tagada struktuuri, mis töötab täielikult ühes meeskonnas, kuid samas üksteisest sõltumatu. Veelgi enam, isegi kui pool meie taustaprogrammist koormuse all “kokku variseb”, jääb ülejäänud ellu ning klastri sees olevate andmebaaside üksteisega sünkroonimise süsteem ning võimalus uusi klastreid lõputult skaleerida ja juurutada aitavad kiiresti vajaliku võimsuse saavutada – kui vaid andmekeskuses oleks nagid .
Lisaks võimaldab klastritena jaotatud andmebaasimudel viia just selle andmebaasi sinna, kuhu vaja; Kui me räägime globaalsest teenusest, siis on üsna ebaloogiline kerrata veebiklastrit kuskil San Francisco piirkonnas ja samal ajal saata pakette Moskva piirkonna andmebaasi sisenedes ja tagasi.
Samuti võimaldab andmebaasi konteineriseerimine luua kõik süsteemi elemendid samal abstraktsioonitasemel. Mis omakorda võimaldab hallata just seda süsteemi otse koodist, arendajate poolt, ilma administraatorite aktiivse kaasamiseta. Arendajad arvasid, et uue alamprojekti jaoks on vaja eraldi DBMS-i – lihtne! kirjutas yaml-faili, laadis selle klastrisse üles ja ongi valmis.
Ja loomulikult on sisemine toimimine oluliselt lihtsustatud. Rääkige, mitu korda olete silmad sulgenud, kui uus meeskonnaliige pani oma käed tööks lahinguandmebaasi? Mis on tegelikult ainus, mis teil on ja mis praegu keerleb? Muidugi oleme siin kõik täiskasvanud ja kuskil on meil värske tagavara ja veelgi kaugemal - vanaema kurkide ja vanade suuskadega riiuli taga - veel üks tagavara, võib-olla isegi külmhoones, sest teie kontor põles juba kord. Kuid sellegipoolest on iga uue meeskonnaliikme tutvustus, kellel on juurdepääs lahinguinfrastruktuurile ja loomulikult lahinguandmebaasile, ämber validooli kõigile ümberkaudsetele inimestele. Noh, kes teda tunneb, uustulnukat, võib-olla on ta risti-rästi? See on hirmutav, nõustute.
Konteinerimine ja tegelikult teie projekti andmebaasi hajutatud füüsiline topoloogia aitab selliseid valideerimismomente vältida. Kas te ei usalda algajat? OKEI! Anname talle oma klastri töötamiseks ja ühendame andmebaasi teistest klastritest lahti – sünkroonimine toimub ainult käsitsi vajutamise ja kahe klahvi sünkroonse pööramise teel (üks meeskonna juhile, teine administraatorile). Ja kõik on õnnelikud.
Ja nüüd on aeg muutuda andmebaaside rühmitamise vastasteks.
Tume pool
Vaieldes selle üle, miks ei tasu andmebaasi konteinerisse paigutada ja seda ühes keskserveris edasi käitada, ei lange me õigeusklike retoorika ja väidete juurde nagu "vanaisad juhtisid andmebaase riistvara peal ja nii teeme ka meie!" Selle asemel proovime välja mõelda olukorra, kus konteineriseerimine tooks tegelikult käegakatsutavaid dividende.
Nõus, need projektid, mis tõesti konteineris alust vajavad, võib ühe käe sõrmedel üles lugeda mitte just parim freespinki operaator. Enamasti on isegi k8-de või Docker Swarmi enda kasutamine üleliigne - üsna sageli kasutatakse neid tööriistu tehnoloogia üldise hüppe ja sugupoolte isikus "kõikvõimsate" hoiakute tõttu, et kõik sisse suruda. pilved ja konteinerid. Noh, sest nüüd on see moes ja kõik teevad seda.
Vähemalt pooltel juhtudel on Kubernetise või lihtsalt Dockeri kasutamine projektis üleliigne. Probleem on selles, et mitte kõik kliendi infrastruktuuri hooldamiseks palgatud meeskonnad või allhankeettevõtted ei ole sellest teadlikud. Hullem on, kui konteinereid peale surutakse, sest see maksab kliendile teatud hulga münte.
Üldiselt ollakse arvamusel, et dokkide/kuubiku maffia purustab rumalalt kliente, kes neid taristuprobleeme allhanke korras teevad. Vajame ju klastritega töötamiseks insenere, kes on selleks võimelised ja mõistavad üldiselt rakendatava lahenduse arhitektuuri. Kunagi kirjeldasime juba oma juhtumit Vabariigi väljaandega - seal koolitasime kliendi meeskonda Kubernetise reaalsuses töötama ja kõik jäid rahule. Ja see oli korralik. Tihti võtavad k8s “rakendajad” kliendi taristu pantvangi – sest nüüd saavad ainult nemad aru, kuidas seal kõik toimib, kliendi poolel pole spetsialiste.
Kujutage nüüd ette, et sellisel viisil me allhankega mitte ainult veebiserveri osa, vaid ka andmebaasi hoolduse. Me ütlesime, et BD on süda ja südame kaotus on saatuslik igale elusorganismile. Ühesõnaga, väljavaated pole just kõige paremad. Seega ei peaks paljud projektid Kubernetise hype asemel lihtsalt vaeva nägema AWS-i tavatariifiga, mis lahendab kõik nende saidi/projekti koormusega seotud probleemid. Kuid AWS pole enam moes ja eputamine on rahast rohkem väärt – kahjuks ka IT-keskkonnas.
OKEI. Võib-olla vajab projekt tõesti rühmitamist, kuid kui olekuta rakendustega on kõik selge, siis kuidas korraldada klastri andmebaasi jaoks korralik võrguühendus?
Kui me räägime sujuvast insenertehnilisest lahendusest, milleks on üleminek k8s-ile, siis meie peamine peavalu on andmete replikatsioon rühmitatud andmebaasis. Mõned DBMS-id on algselt üsna lojaalsed andmete jaotamisel oma üksikute eksemplaride vahel. Paljud teised ei ole nii vastutulelikud. Ja üsna sageli ei ole meie projekti jaoks DBMS-i valimisel peamine argument võimalus replitseerida minimaalsete ressursi- ja insenerikuludega. Eriti kui projekt ei olnud algselt planeeritud mikroteenusena, vaid lihtsalt selles suunas arenes.
Arvame, et võrguketaste kiirusest pole vaja rääkida – need on aeglased. Need. Meil pole ikka veel reaalset võimalust, kui midagi juhtub, taaskäivitada DBMS-i eksemplari kuskil, kus on rohkem, näiteks protsessori võimsust või vaba RAM-i. Saame väga kiiresti kokku virtualiseeritud ketta alamsüsteemi jõudlusega. Sellest lähtuvalt peab DBMS olema naelutatud oma isikliku masinate komplekti, mis asuvad vahetus läheduses. Või on vaja kuidagi eraldi jahutada piisavalt kiire andmete sünkroniseerimine oletatavate reservide jaoks.
Virtuaalsete failisüsteemide teemat jätkates: Dockeri köited pole kahjuks probleemivabad. Üldiselt tahaksin sellises asjas nagu pikaajaline usaldusväärne andmete säilitamine leppida tehniliselt kõige lihtsamate skeemidega. Ja uue abstraktsioonikihi lisamine konteineri FS-ist vanemhosti FS-i on risk omaette. Kuid kui konteinerite tugisüsteemi töös tekib raskusi andmete edastamisel nende kihtide vahel, on see tõesti katastroof. Praegu tundub, et suurem osa progressiivsele inimkonnale teadaolevatest probleemidest on likvideeritud. Kuid saate aru, mida keerulisem on mehhanism, seda kergemini see puruneb.
Kõiki neid "seiklusi" silmas pidades on palju tulusam ja lihtsam hoida andmebaasi ühes kohas ning isegi kui teil on vaja rakendust konteinerisse paigutada, laske sellel iseseisvalt töötada ja levitamise lüüsi kaudu samaaegselt suhelda andmebaasi, mida loetakse ja kirjutatakse ainult üks kord ja ühes kohas. Selline lähenemine vähendab vigade ja desünkroniseerimise tõenäosust miinimumini.
Milleni me juhime? Lisaks on andmebaasi konteinerisse paigutamine asjakohane, kui selle järele on tõeline vajadus. Te ei saa täisrakenduste andmebaasi toppida ja seda keerutada, nagu oleks teil kaks tosinat mikroteenust – see ei tööta nii. Ja seda tuleb selgelt mõista.
Väljundi asemel
Kui ootate selget järeldust "kas virtualiseerida andmebaas või mitte", valmistame teile pettumuse: seda siin pole. Sest mis tahes taristulahenduse loomisel tuleb juhinduda mitte moest ja progressist, vaid eelkõige tervest mõistusest.
On projekte, mille jaoks Kubernetisega kaasas olevad põhimõtted ja tööriistad sobivad ideaalselt ning sellistes projektides valitseb rahu vähemalt backend piirkonnas. Ja on projekte, mis ei vaja konteineriseerimist, vaid tavalist serveri infrastruktuuri, sest nad ei saa põhimõtteliselt ümber skaleerida mikroteenuste klastri mudeliks, sest need kukuvad.
Allikas: www.habr.com