ProHoster > Blogs > Administrācija > Vai Kubernetes dzīvo datu bāzes?

Vai Kubernetes dzīvo datu bāzes?

Vai Kubernetes dzīvo datu bāzes?

Kaut kā vēsturiski IT nozare jebkādu iemeslu dēļ ir sadalÄ«ta divās nosacÄ«tās nometnēs: tajos, kas ir ā€œparā€ un tajos, kas ir ā€œpretā€. Turklāt strÄ«du priekÅ”mets var bÅ«t pilnÄ«gi patvaļīgs. Kura OS ir labāka: Win vai Linux? Android vai iOS viedtālrunÄ«? Vai jums vajadzētu visu glabāt mākoņos vai ievietot aukstā RAID krātuvē un ievietot skrÅ«ves seifā? Vai PHP cilvēkiem ir tiesÄ«bas saukties par programmētājiem? Å ie strÄ«di dažkārt ir tikai eksistenciāli, un tiem nav cita pamata kā tikai sporta intereses.

Tā sagadÄ«jās, ka lÄ«dz ar konteineru parādÄ«Å”anos un visu Å”o iemīļoto virtuvi ar dokeru un nosacÄ«tajiem k8s sākās diskusijas ā€œparā€ un ā€œpretā€ jaunu iespēju izmantoÅ”anu dažādās backend jomās. (Jau iepriekÅ” atrunāsim, lai arÄ« Kubernetes Å”ajā diskusijā visbiežāk tiks norādÄ«ts kā orÄ·estrētājs, Ŕī konkrētā rÄ«ka izvēlei nav bÅ«tiskas nozÄ«mes. Tā vietā varat aizstāt jebkuru citu, kas jums Ŕķiet ērtākais un pazÄ«stamākais .)

Un, Ŕķiet, tas bÅ«tu vienkārÅ”s strÄ«ds starp vienas monētas divām pusēm. Tikpat bezjēdzÄ«ga un nežēlÄ«ga kā mūžīgā konfrontācija starp Win vs Linux, kurā adekvāti cilvēki eksistē kaut kur pa vidu. Bet konteinerizācijas gadÄ«jumā ne viss ir tik vienkārÅ”i. Parasti Ŕādos strÄ«dos nav labās puses, bet ā€œizmantotā€ vai ā€œnelietotā€ konteineru gadÄ«jumā datu bāzu glabāŔanai viss apgriežas kājām gaisā. Jo savā ziņā taisnÄ«ba ir gan Ŕīs pieejas atbalstÄ«tājiem, gan pretiniekiem.

GaiŔā puse

Vieglās puses argumentu var Ä«si raksturot vienā frāzē: "Sveiki, 2k19 ir aiz loga!" Tas, protams, izklausās pēc populisma, bet, ja sÄ«kāk iedziļināsies situācijā, tam ir savas priekÅ”rocÄ«bas. Sakārtosim tos tagad.

Pieņemsim, ka jums ir liels tÄ«mekļa projekts. Sākotnēji to varēja uzbÅ«vēt, pamatojoties uz mikropakalpojumu pieeju, vai arÄ« kādā brÄ«dÄ« tas nonāca pa evolÅ«cijas ceļu - patiesÄ«bā tas nav Ä«paÅ”i svarÄ«gi. JÅ«s izkaisÄ«jāt mÅ«su projektu atseviŔķos mikropakalpojumos, iestatÄ«jāt orÄ·estrÄ“Å”anu, slodzes lÄ«dzsvaroÅ”anu un mērogoÅ”anu. Un tagad ar tÄ«ru sirdsapziņu jÅ«s habra efektu laikā iemalkojat mohito ŔūpuļtÄ«klā, nevis ceļat pakrituÅ”os serverus. Bet visās darbÄ«bās jums jābÅ«t konsekventai. Ä»oti bieži konteinerā tiek ievietota tikai pati lietojumprogramma ā€” kods. Kas vēl mums ir bez koda?

TieÅ”i tā, dati. Jebkura projekta bÅ«tÄ«ba ir tā dati: tie var bÅ«t vai nu tipiska DBVS ā€” MySQL, Postgre, MongoDB, vai krātuve, ko izmanto meklÄ“Å”anai (ElasticSearch), atslēgas vērtÄ«bu krātuve keÅ”atmiņai ā€” piemēram, redis utt. mēs runāsim par greizām aizmugursistēmas ievieÅ”anas iespējām, kad datubāze avarē slikti uzrakstÄ«tu vaicājumu dēļ, un tā vietā mēs runāsim par Ŕīs paÅ”as datu bāzes kļūdu tolerances nodroÅ”ināŔanu klienta slodzes laikā. Galu galā, kad mēs konteinerizējam savu lietojumprogrammu un ļaujam tai brÄ«vi mērogot, lai apstrādātu jebkādu ienākoÅ”o pieprasÄ«jumu skaitu, tas dabiski palielina datu bāzes slodzi.

Faktiski kanāls piekļuvei datu bāzei un serverim, kurā tas darbojas, kļūst par adatas aci mÅ«su skaistajā konteinerizētajā aizmugursistēmā. Tajā paŔā laikā galvenais konteineru virtualizācijas motÄ«vs ir struktÅ«ras mobilitāte un elastÄ«ba, kas ļauj maksimāli efektÄ«vi organizēt maksimālās slodzes sadali pa visu mums pieejamo infrastruktÅ«ru. Tas ir, ja mēs nekonteinerējam un neizvērsÄ«sim visus esoÅ”os sistēmas elementus visā klasterÄ«, mēs pieļaujam ļoti nopietnu kļūdu.

Daudz loÄ£iskāk ir grupēt ne tikai paÅ”u lietojumprogrammu, bet arÄ« pakalpojumus, kas ir atbildÄ«gi par datu glabāŔanu. Sagrupējot un izvietojot tÄ«mekļa serverus, kas strādā neatkarÄ«gi un sadala slodzi savā starpā k8s, mēs jau risinām datu sinhronizācijas problēmu - tie paÅ”i komentāri pie ierakstiem, ja ņemam par piemēru kādu mediju vai blogu platformu. Jebkurā gadÄ«jumā mums ir klastera iekŔējais, pat virtuāls, datu bāzes attēlojums kā ārējais pakalpojums. Jautājums ir par to, ka pati datu bāze vēl nav sagrupēta - kubā izvietotie tÄ«mekļa serveri informāciju par izmaiņām ņem no mÅ«su statiskās kaujas datu bāzes, kas rotē atseviŔķi.

Vai jÅ«tat nozveju? Mēs izmantojam k8s vai Swarm, lai sadalÄ«tu slodzi un izvairÄ«tos no galvenā tÄ«mekļa servera avārijām, taču mēs to nedarām datubāzei. Bet, ja datu bāze avarē, tad visai mÅ«su klasterizētajai infrastruktÅ«rai nav jēgas ā€“ ko gan tur tukÅ”as tÄ«mekļa lapas, kas atgriež datu bāzes piekļuves kļūdu?

Tāpēc ir nepiecieÅ”ams klasterēt ne tikai tÄ«mekļa serverus, kā tas parasti tiek darÄ«ts, bet arÄ« datu bāzes infrastruktÅ«ru. Tikai tā mēs varam nodroÅ”ināt struktÅ«ru, kas pilnÄ«bā darbojas vienā komandā, bet tajā paŔā laikā neatkarÄ«gi viens no otra. Turklāt, pat ja puse no mÅ«su aizmugursistēmas ā€œsabrÅ«kā€ slodzes laikā, pārējais izdzÄ«vos, un klastera datu bāzu savstarpējās sinhronizācijas sistēma un iespēja bezgalÄ«gi mērogot un izvietot jaunus klasterus palÄ«dzēs ātri sasniegt nepiecieÅ”amo jaudu. ja vien datu centrā bÅ«tu statÄ«vi .

Turklāt klasteros izplatÄ«tais datu bāzes modelis ļauj tieÅ”i Å”o datu bāzi nogādāt tur, kur tas ir nepiecieÅ”ams; Ja mēs runājam par globālu pakalpojumu, tad ir diezgan neloÄ£iski izveidot tÄ«mekļa klasteru kaut kur Sanfrancisko apgabalā un tajā paŔā laikā sÅ«tÄ«t paketes, piekļūstot datubāzei Maskavas reÄ£ionā un atpakaļ.

Tāpat datu bāzes konteinerizācija ļauj veidot visus sistēmas elementus vienā abstrakcijas lÄ«menÄ«. Tas, savukārt, ļauj pārvaldÄ«t Å”o sistēmu tieÅ”i no koda, izstrādātājiem bez aktÄ«vas administratoru iesaistes. Izstrādātāji uzskatÄ«ja, ka jaunajam apakÅ”projektam ir nepiecieÅ”ama atseviŔķa DBVS ā€“ vienkārÅ”i! uzrakstÄ«ja yaml failu, augÅ”upielādēja to klasterÄ« un esat pabeidzis.

Un, protams, iekŔējā darbÄ«ba ir ievērojami vienkārÅ”ota. Pastāsti man, cik reizes tu esi aizvēris acis, kad jauns komandas dalÄ«bnieks darba dēļ ielika rokas kaujas datubāzē? Kura patiesÄ«bā ir vienÄ«gā, kas jums ir un Å”obrÄ«d griežas? Protams, mēs visi Å”eit esam pieauguÅ”ie, un kaut kur mums ir svaigs dublējums, un vēl tālāk - aiz plaukta ar vecmāmiņas gurÄ·iem un vecām slēpēm - vēl viens rezerves variants, iespējams, pat saldētavā, jo jÅ«su birojs jau reiz dega. Bet tomēr katra jauna komandas biedra ievadÄ«Å”ana ar piekļuvi kaujas infrastruktÅ«rai un, protams, kaujas datu bāzei, ir spainis validola visiem apkārtējiem. Nu, kas viņu pazÄ«st, iesācēju, varbÅ«t viņŔ ir krustu Ŕķērsu? Tas ir biedējoÅ”i, jÅ«s piekrÄ«tat.

JÅ«su projekta datu bāzes konteinerizÄ“Å”ana un faktiski izkliedētā fiziskā topoloÄ£ija palÄ«dz izvairÄ«ties no Ŕādiem apstiprināŔanas brīžiem. Vai neuzticaties iesācējam? LABI! Iedosim viņam savu klasteru darbam un atvienosim datu bāzi no citām kopām ā€” sinhronizāciju tikai manuāli nospiežot un sinhroni pagriežot divus taustiņus (viens komandas vadÄ«tājam, otrs administratoram). Un visi ir laimÄ«gi.

Un tagad ir pienācis laiks kļūt par datu bāzu klasterizācijas pretiniekiem.

TumŔā puse

Argumentējot, kāpēc nav vērts ievietot datu bāzi konteineros un turpināt to darbināt vienā centrālajā serverÄ«, mēs nenolaidÄ«simies uz ortodoksijas retoriku un apgalvojumiem, piemēram, "vectēvi vadÄ«ja datubāzes uz aparatÅ«ras, un mēs arÄ« to darÄ«sim!" Tā vietā mēģināsim izdomāt situāciju, kurā konteinerizācija tieŔām nestu jÅ«tamas dividendes.

PiekrÄ«tu, projektus, kuriem tieŔām nepiecieÅ”ama pamatne konteinerā, var uz vienas rokas pirkstiem saskaitÄ«t ne pats labākais frēzmaŔīnu operators. Lielākoties pat paÅ”as k8s vai Docker Swarm lietoÅ”ana ir lieka - diezgan bieži Å”ie rÄ«ki tiek Ä·erti vispārējās tehnoloÄ£iju ažiotāžas un "visvarenā" attieksmes dēļ dzimumu personā, lai visu virzÄ«tu iekŔā. mākoņi un konteineri. Nu, jo tagad tas ir modē un visi tā dara.

Vismaz pusē gadÄ«jumu Kubernetis vai tikai Docker izmantoÅ”ana projektā ir lieka. Problēma ir tāda, ka ne visas komandas vai ārpakalpojumu uzņēmumi, kas nolÄ«gti klienta infrastruktÅ«ras uzturÄ“Å”anai, to apzinās. Sliktāk ir uzlikt konteinerus, jo tas klientam maksā noteiktu monētu daudzumu.

Vispār valda uzskats, ka dokeru/kubu mafija stulbi grauž klientus, kas Å”os infrastruktÅ«ras jautājumus nodod ārpakalpojumā. Galu galā, lai strādātu ar klasteriem, mums ir nepiecieÅ”ami inženieri, kuri to spēj un kopumā saprot ieviestā risinājuma arhitektÅ«ru. Kādreiz jau aprakstÄ«jām savu gadÄ«jumu ar republikas izdevumu - tur apmācÄ«jām klienta komandu strādāt Kubernetis realitātē, un visi bija apmierināti. Un tas bija pieklājÄ«gi. Bieži vien k8s ā€œieviesējiā€ sagrābj klienta infrastruktÅ«ru par Ä·Ä«lniekiem - jo tagad tikai viņi saprot, kā tur viss darbojas, klienta pusē nav speciālistu.

Tagad iedomājieties, ka Ŕādā veidā mēs ārpakalpojumu sniedzam ne tikai tÄ«mekļa servera daļu, bet arÄ« datu bāzes uzturÄ“Å”anu. Mēs teicām, ka BD ir sirds, un sirds zudums ir nāvējoÅ”s jebkuram dzÄ«vam organismam. ÄŖsāk sakot, izredzes nav tās labākās. Tātad ažiotāžas Kubernetis vietā daudziem projektiem vienkārÅ”i nevajadzētu apnikt parasto AWS tarifu, kas atrisinās visas problēmas ar slodzi viņu vietnē/projektā. Taču AWS vairs nav modē, un izrādÄ«Å”anās ir vairāk vērta nekā nauda ā€“ diemžēl arÄ« IT vidē.

LABI. VarbÅ«t projektam patieŔām ir nepiecieÅ”ama klasterizācija, bet, ja ar bezvalsts lietojumprogrammām viss ir skaidrs, kā mēs varam organizēt pienācÄ«gu tÄ«kla savienojumu klasterizētai datubāzei?

Ja mēs runājam par nevainojamu inženiertehnisko risinājumu, kas ir pāreja uz k8s, tad mÅ«su galvenās galvassāpes ir datu replikācija klasteru datubāzē. Dažas DBVS sākotnēji ir diezgan uzticÄ«gas datu izplatÄ«Å”anai starp saviem individuālajiem gadÄ«jumiem. Daudzi citi nav tik pretimnākoÅ”i. Un diezgan bieži galvenais arguments, izvēloties DBVS mÅ«su projektam, nav spēja replicēt ar minimālām resursu un inženierijas izmaksām. It Ä«paÅ”i, ja projekts sākotnēji nebija plānots kā mikropakalpojums, bet vienkārÅ”i attÄ«stÄ«jās Å”ajā virzienā.

Mēs domājam, ka nav nepiecieÅ”ams runāt par tÄ«kla disku ātrumu - tie ir lēni. Tie. Mums joprojām nav reālas iespējas, ja kaut kas notiek, restartēt DBVS gadÄ«jumu kaut kur, kur ir vairāk, piemēram, procesora jaudas vai brÄ«vas RAM. Mēs ļoti ātri nonāksim pie virtualizētā diska apakÅ”sistēmas veiktspējas. AttiecÄ«gi DBVS ir jāpiesaista tās personÄ«gajam iekārtu komplektam, kas atrodas tieŔā tuvumā. Vai arÄ« ir nepiecieÅ”ams kaut kā atseviŔķi atdzesēt pietiekami ātru datu sinhronizāciju paredzētajām rezervēm.

Turpinot tēmu par virtuālajām failu sistēmām: Docker Volumes diemžēl nav bez problēmām. Kopumā tādā jautājumā kā ilgstoÅ”a uzticama datu glabāŔana es gribētu iztikt ar tehniski vienkārŔākajām shēmām. Un jauna abstrakcijas slāņa pievienoÅ”ana no konteinera FS vecākresursdatora FS ir risks pats par sevi. Bet, ja konteinerizācijas atbalsta sistēmas darbÄ«bai ir arÄ« grÅ«tÄ«bas ar datu pārsÅ«tÄ«Å”anu starp Å”iem slāņiem, tā patieŔām ir katastrofa. Å obrÄ«d Ŕķiet, ka lielākā daļa progresÄ«vajai cilvēcei zināmo problēmu ir izskaustas. Bet jÅ«s saprotat, jo sarežģītāks mehānisms, jo vieglāk tas sabojājas.

Ņemot vērā visus Å”os ā€œpiedzÄ«vojumusā€, ir daudz izdevÄ«gāk un vienkārŔāk glabāt datu bāzi vienuviet, un pat tad, ja nepiecieÅ”ams konteinerizēt lietojumprogrammu, ļaujiet tai darboties paÅ”ai un caur izplatÄ«Å”anas vārteju saņemt vienlaicÄ«gu saziņu ar datu bāze, kas tiks lasÄ«ta un rakstÄ«ta tikai vienu reizi un Vienā vietā. Å Ä« pieeja samazina kļūdu un desinhronizācijas iespējamÄ«bu lÄ«dz minimumam.

Pie kā mēs vedam? Turklāt datu bāzu konteinerizācija ir piemērota tur, kur pēc tās ir reāla vajadzÄ«ba. JÅ«s nevarat aizpildÄ«t pilnas lietotnes datubāzi un griezt to tā, it kā jums bÅ«tu divi desmiti mikropakalpojumu ā€” tas nedarbojas Ŕādā veidā. Un tas ir skaidri jāsaprot.

Izvades vietā

Ja jÅ«s gaidāt skaidru secinājumu "virtualizēt datu bāzi vai nē", mēs jÅ«s pievilsim: tā Å”eit nebÅ«s. Jo, veidojot jebkuru infrastruktÅ«ras risinājumu, ir jāvadās nevis pēc modes un progresa, bet, pirmkārt, pēc veselā saprāta.

Ir projekti, kuriem Kubernetis komplektā esoŔie principi un instrumenti lieliski der, un Ŕādos projektos ir miers vismaz backend jomā. Un ir projekti, kuriem nevajag konteinerizāciju, bet normālu serveru infrastruktūru, jo tie principā nevar pārskanot uz mikropakalpojumu klastera modeli, jo kritīs.

Avots: www.habr.com

Pievieno komentāru