Vai datu bāzes pastāv Kubernetes?

Tā ir izveidojies, ka IT industrija visos jautājumos tiek sadalīta divās nosacītās nometnēs: vieni ir "par", bet citi "pret". Un strīdu priekšmets var būt pilnīgi nejaušs. Kura operētājsistēma ir labāka: Win vai Linux? Uz viedtālruņa Android vai iOS? Visu glabāt mākoņos vai augšupielādēt uz aukstajiem RAID krātuvēm un ielikt cietos diskus seifā? Vai PHP programmētājiem ir tiesības dēvēt sevi par programmētājiem? Šie strīdi reizēm ir tīri eksistenciāla rakstura un nav balstīti uz neko citu kā tikai sportisku interesi.

Tā nu sanācis, ka ar konteineru parādīšanos un visu šo mūsu iecienīto virtuvīti ar Docker un nosacīto Kubernetes sākās arī strīdi "par" un "pret" jauno iespēju izmantošanu dažādās backend jomās. (Iepriekš piebilsim, ka, lai gan šajā apspriešanā kā orķestrators parasti tiek minēts Kubernetes, pats rīka izvēles princips nav būtisks. Tā vietā var ielikt jebkuru citu, kas Jums šķiet vispiemērotākais un pierastākais.)

Un, šķiet, tas būtu vienkāršs strīds starp divām puses vienas monētas. Tāds pats bezjēdzīgs un nežēlīgs kā mūžīgais pretestības modelis Win vs Linux, kur saprātīgi cilvēki eksistē kaut kur pa vidu. Bet konteinerizācijas gadījumā viss nav tik vienkārši. Parasti šādos strīdos nav pareizās puses, taču gadījumā "pielietot" vai "nepielietot" konteinerus datu bāzu glabāšanai viss tiek apgriezts otrādi. Jo noteiktā nozīmē taisnība ir gan atbalstītājiem, gan pretiniekiem šādai pieejai.

Gaišā puse

Īsi aprakstīt Gaišās Puses argumentāciju var ar vienu frāzi: "Hallo, 2k19 ir aiz loga!" Izklausās pēc populisma, protams, taču, ja iedziļinās situācijā detalizēti, tur ir savi plusi. To mēs arī apskatīsim.

Pieņemsim, ka jums ir liels tīmekļa projekts. Tas varēja sākotnēji tikt veidots, balstoties uz mikroservisu pieeju, vai arī kādā brīdī tas ir evolūcijas ceļā pie tās nonācis — tas patiesībā nav svarīgi. Jūs sadalījāt mūsu projektu atsevišķos mikroservisos, iestatījāt orķestrāciju, slodzes balansēšanu, mērogojamību. Un tagad, ar tīru sirdsapziņu izbaudāt mohito šūpuļtīklā laikā, kad notiek habra-efekti, nevis cīnāties par kritušajiem serveriem. Bet visos pasākumos ir jādara secīgi. Ļoti bieži tiek konteinerizēta tikai paša lietojumprogramma — kods. Un kas mums vēl ir, izņemot kodu?

Pareizi, dati. Jebkura projekta sirds ir tās dati: tas var būt gan tipiska DBMS — MySQL, Postgre, MongoDB, gan krātuves, kas tiek izmantotas meklēšanai (ElasticSearch), key-value krātuves kešēšanai — piemēram, redis, utt. Pašlaik mēs nerunāsim par nepareizām bākenda īstenošanas iespējām, kad DB avārijas notiek slikti rakstītu pieprasījumu dēļ, bet gan par to, kā nodrošināt šīs pašas DB noturību zem klientu slodzes. Galu galā, kad mēs konteinerizējam mūsu lietojumprogrammu un ļaujam tai brīvi mērogoties, lai apstrādātu jebkuru ienākošo pieprasījumu skaitu, tas likumsakarīgi palielina slodzi uz datubāzi.

Iespējams, datu bāzes piekļuves kanāls un serveris, uz kura tā darbojas, kļūst par adatas aci mūsu skaistajā konteinerizētajā bākendā. Tajā pašā laikā galvenais konteinerizācijas motīvs ir struktūras mobilitāte un elastība, kas ļauj maksimāli efektīvi organizēt pikālo slodžu sadalījumu pa visu mūsu pieejamo infrastruktūru. Tātad, ja mēs nekonteinerizējam un neizvēršam visus sistēmas esošos elementus pa klasteri — mēs pieļaujam ļoti nopietnu kļūdu.

Ir daudz loģiskāk, ja klasterizē ne tikai pašu lietojumprogrammu, bet arī pakalpojumus, kas atbild par datu glabāšanu. Veicot klasterizāciju un izvēršot neatkarīgas un slodzi sadalošas tīmekļa serverus k8s, mēs jau risinām datu sinhronizācijas problēmu — piemēram, komentārus pie ierakstiem, ja ņem kādu plašsaziņas līdzekli vai emuāru platformu. Mums joprojām ir jāveido iekšējās klastera, pat ja virtuāla, datu bāzes prezentācija kā ExternalService. Problēma ir tāda, ka pati datu bāze pagaidām nav klasterizēta — kubā izvietotie tīmekļa serveri iegūst informāciju par izmaiņām no mūsu statiskās ražošanas datu bāzes, kas darbojas atsevišķi.

Vai jūti apkaunojošu situāciju? Mēs izmantojam k8s vai Swarm, lai sadalītu slodzi un izvairītos no galvenā pakalpojuma sabrukuma, webservera, taču mēs to nedarām datu bāzei. Bet ja datu bāze sabruks, tad visā mūsu klasterizētajā infrastruktūrā nav jēgas — kāds labums no tukšām tīmekļa lapām, kas atgriež kļūdas ziņojumus par piekļuvi datu bāzei?

Tieši tāpēc ir nepieciešams klasterizēt ne tikai tīmekļa serverus, kā parasti tiek darīts, bet arī datu bāzes infrastruktūru. Tikai tādā veidā mēs varam nodrošināt pilnvērtīgi funkcionējošu, bet vienlaikus vienam no otra neatkarīgu struktūru. Pat ja puse no mūsu aizmugures noslodzes dēļ sabruks — pārējā daļa izdzīvos, un datu bāzes sinhronizācijas iespējas vienā klasterī un bezgalīgas paplašināšanas un jaunu klasteru izvēršanas iespējas palīdzēs ātri sasniegt nepieciešamās jaudas — ja vien datu centrā ir skapji.

Turklāt, klasteros sadalīta datu bāzes modelis ļauj pārvietot šo pašu datu bāzi uz vietu, kur tā ir nepieciešama; ja runājam par globālu pakalpojumu, tad diezgan nelogiski būtu izvērst tīmekļa klasteri kaut kur Sanfrancisko un nodot paketes, piekļūstot datu bāzei pie Maskavas, un atpakaļ.

Tāpat datu bāzes konteinerizācija ļauj izveidot visus sistēmas elementus vienā abstrakcijas līmenī. Tas, savukārt, padara iespējamu pārvaldīt šo pašu sistēmu tieši no koda, bez aktīvas administratoru iesaistes. Programmētājiem ienāca prātā, ka jauna projekta dēļ ir nepieciešama atsevišķa DBMS — viegli! viņi uzrakstīja yaml failu, augšupielādēja to klasterī un tas ir gatavs.

Nu un, iekšējā izmantošana kļūst daudz vienkāršāka. Sakiet, cik reizes jūs esat aizvēris acis brīžos, kad jauns komandas dalībnieks mēģināja piekļūt ražošanas datu bāzei? Kura jums, faktiski, ir viena un šobrīd darbojas? Protams, mēs visi esam pieauguši cilvēki, un mums, iespējams, ir svaiga dublējumkopija, un tur tālāk — aiz plaukta ar vecmātes gurķiem un vecām slēpēm — vēl viena dublējumkopija, iespējams, pat aukstajā glabāšanā, jo reiz jau jūsu birojā bija ugunsgrēks. Bet tomēr, katra jauna komandas dalībnieka iekļaušana ar piekļuvi ražošanas infrastruktūrai un, protams, ražošanas datu bāzei — tas ir stress visiem apkārtējiem. Nu, kas viņu, jauno cilvēku, zina, varbūt viņš ir neveikls? Šausmīgi, piekrītat.

Konteinernizācija un, patiesībā, izkliedētā fiziskā datu bāzes topoloģija jūsu projektam palīdz izvairīties no šādām stresa situācijām. Neuzticieties jaunajam? Labi! Izveidosim viņam savu klasteri darbam un atvienosim no pārējiem datu bāzu klasteriem — sinhronizācija tikai ar manuālu datu pārsūtīšanu un sinhronisku divu atslēgu pagriešanu (viena komandas vadītājam, otra administratoram). Un visi ir laimīgi.

Tagad ir pienācis laiks pārgāt uz pretiniekiem datu bāzu klasterizācijai.

Tumšā puse

Apspriežot, kāpēc nevajadzētu konteinernizēt datu bāzi un turpināt to darbināt uz viena centrālā serveri, nekritīsim līdz ortodoksālo rituālu un apgalvojumiem, piemēram, "vecmāmiņas darbināja datu bāzes uz aparatūras, un mēs to darīsim!" Tā vietā mēģināsim izdomāt situāciju, kurā konteinernizācija tiešām sniegtu taustāmu labumu.

Piekrītiet, projektu, kuriem patiešām nepieciešama datu bāze konteinerā, var saskaitīt uz vienas rokas pirkstiem ne vislabākajam frēzētājam. Lielākajā daļā gadījumu pat k8s vai Docker Swarm izmantošana var būt pārāk. Ļoti bieži šiem rīkiem izmanto, balstoties uz vispārējo tehniku un "visaugstākā" spiediena dēļ no vadības virziena iebāzt visu mākoņos un konteineros. Nu, tāpēc, ka tas tagad ir modē un visi to dara.

Vismaz pusē gadījumu Kubernetes vai vienkārši Docker izmantošana projektā ir pārmērīga. Jautājums ir, ka ne visas komandas vai ārpakalpojumu uzņēmumi, kas nodarbināti klienta infrastruktūras apkalpošanai, to apzinās. Sliktāk — kad konteineri tiek uzspiesti, jo tas maksā klientam noteiktu summu naudā.

Vispār ir izplatīts uzskats, ka Docker/Kubernetes mafija vienkārši pakļauj saviem interešu grupām klientus, kas uztic šos infrastruktūras jautājumus ārpakalpojumiem. Jo, lai strādātu ar klasteriem, ir nepieciešami inženieri, kuri spēj to darīt un kopumā saprot ieviestā risinājuma arhitektūru. Mēs reiz jau aprakstījām mūsu gadījumu ar izdevumu Republic — tur mēs apmācījām klienta komandu strādāt Kubernetes apstākļos, un visi palika apmierināti. Un tas bija godīgi. Bieži vien «ieviešanas» speciālisti K8s paņem klienta infrastruktūru par ķīlnieku — jo tagad tikai viņi saprot, kā viss tur darbojas, klienta pusē speciālistu nav.

Un tagad iedomājieties, ka šādā veidā mēs pasakām ne tikai tīkla servera daļu uzticēt ārpakalpojumiem, bet arī datu bāzes apkalpošanu. Mēs runājām, ka datu bāze ir sirds, un sirds zaudēšana ir fatāla jebkuram dzīvam organismam. Īsāk sakot, perspektīvas nav vislabākās. Tāpēc, vietā hype pienākošā Kubernetes, daudziem projektiem būtu vienkārši jāpārstāj žēlot normālu tarifu AWS, kas atrisinās visas slodzes problēmas viņu mājaslapā/projektā. Bet AWS jau nav moderns, un poži ir dārgāki par naudu — diemžēl arī IT vidē.

Labi. Iespējams, ka klasterizācija projektam tiešām ir vajadzīga, bet, ja ar stateless lietotnēm viss ir skaidrs, kā tad organizēt adekvātu tīkla savienojamību klasterizētai datu bāzei?

Ja, runājot par bezšuvju inženiertehnisko risinājumu, ko pārstāv pāreja uz k8s, mūsu galvenā galvassāpes ir datu replikācija klasterizētā DB. Dažas DBMS sākotnēji diezgan lojāli izturas pret datu sadali starp atsevišķiem instantiem. Tomēr daudzas citas nav tik atsaucīgas. Un diezgan bieži galvenais arguments DBMS izvēlē šim projektam nav spēja replikēt ar minimālām resursu un inženierijas izmaksām. Īpaši, ja projekts sākotnēji nav plānots kā mikroserviss, bet vienkārši ir attīstījies šajā virzienā.

Domājam, ka par tīkla diskos strādājošo ātrumu stāstīt nav jēgas — tie ir lēni. Tas nozīmē, ka, ja nu kas, mums nav reālas iespējas pārlaižu DBMS instanci citur, kur ir vairāk, piemēram, procesoru jaudas vai brīvas operatīvās atmiņas. Mēs ļoti ātri sasniegsim virtuālās disku sistēmas veiktspējas ierobežojumus. Tādējādi DBMS jābūt piesaistītai savam personīgajam mašīnu kopumam, kas atrodas tiešā tuvumā. Vai arī jāatrod kāds ātrs risinājums datu sinhronizācijai uz paredzētajiem rezervēm.

Turpinot tēmu par virtuālajām FS: Docker volumes, diemžēl, nav bez problēmām. Kopumā, ilgtspējīgā un uzticamā datu uzglabāšanā vēlētos iztikt ar maksimāli vienkāršām tehniskām shēmām. Jaunā slāņa abstrakcijas pievienošana no konteineru FS uz vecāku saimniekdatnes FS pati par sevi ir risks. Bet, kad arī sistēmā, kas nodrošina konteinerizāciju, rodas grūtības datu pārsūtīšanā starp šiem slāņiem, tad jau pavisam slikti. Šobrīd lielākā daļa zināmajām cilvēcei problēmām acīmredzot ir iznīcinātas. Bet, kā jūs saprotat, jo sarežģītāks mehānisms, jo vieglāk tas saplīst.

Ņemot vērā visus šos «piedzīvojumus», ir daudz izdevīgāk un vienkāršāk turēt datu bāzi vienuviet, un pat ja jums ir nepieciešama lietojumprogrammu konteinerizācija — ļaujiet tai darboties pati par sevi un iegūt vienlaicīgu savienojumu ar datu bāzi caur sadales vārtiem, kas tiks lasīta un rakstīta tikai vienu reizi un vienā vietā. Šāda pieeja samazina kļūdu un nesakritību iespējamību līdz minimālām vērtībām.

Kāpēc mēs to sakām? Tāpēc, ka datu bāzes konteinerizācija ir pamatota tur, kur tā ir patiešām nepieciešama. Jūs nevarat ielikt pilnīgu aplikāciju datu bāzi un griezt to tā, it kā jums būtu divdesmit mikropakalpojumi — tas tā nestrādā. Un to ir skaidri jāsaprot.

Vietā izvades

Ja jūs gaidāt skaidru secinājumu «virtualizēt vai ne datu bāzi», tad mūs žēl: šeit tāda nebūs. Jo, izstrādājot jebkuru infrastruktūras risinājumu, jāvadās nevis pēc modes un progresu, bet vispirms pēc saprāta.

Ir projekti, kuriem principi un rīki, kas nāk no Kubernetes, perfekti iederas, un šādos projektos vismaz backend jomā tiek pienācis miers. Taču ir projekti, kuriem nepieciešama nevis konteinerizācija, bet normāla serveru infrastruktūra, jo tie principiāli nevar pārstrukturēties mikropakalpojumu klastera modelī, jo tie sabruks.

Avots: habr.com