Einhvern veginn, sögulega séð, er upplýsingatækniiðnaðinum skipt í tvær skilyrtar fylkingar af hvaða ástæðu sem er: þá sem eru „með“ og þeir sem eru „á móti“. Þar að auki getur efni deilna verið algjörlega handahófskennt. Hvaða stýrikerfi er betra: Win eða Linux? Á Android eða iOS snjallsíma? Ættirðu að geyma allt í skýjunum eða setja það á kalt RAID geymslu og setja skrúfurnar í öryggisskáp? Eiga PHP fólk rétt á að vera kallaðir forritarar? Þessar deilur eru stundum eingöngu tilvistarlegs eðlis og eiga sér enga stoð nema íþróttaáhuga.
Það gerðist bara þannig að með tilkomu gáma og allrar þessarar ástsælu matargerðar með docker og skilyrtum k8s hófust umræðurnar „með“ og „á móti“ notkun nýrra getu á ýmsum sviðum bakendans. (Við skulum gera fyrirvara fyrirfram um að þó að Kubernetes verði oftast tilgreindur sem hljómsveitarstjóri í þessari umræðu, þá skiptir valið á þessu tiltekna verkfæri ekki höfuðmáli. Þess í stað geturðu komið í staðinn fyrir hvert annað sem þér finnst þægilegast og kunnuglegast. .)
Og svo virðist sem þetta væri einfaldur ágreiningur milli tveggja hliða á sama peningi. Eins vitlaus og miskunnarlaus og hin eilífa átök á milli Win vs Linux, þar sem fullnægjandi fólk er til einhvers staðar í miðjunni. En þegar um gámavæðingu er að ræða er ekki allt svo einfalt. Venjulega er engin hægri hlið í slíkum deilum, en þegar um er að ræða „nota“ eða „not use“ gáma til að geyma gagnagrunna snýst allt á hvolf. Vegna þess að í vissum skilningi hafa bæði stuðningsmenn og andstæðingar þessarar aðferðar rétt fyrir sér.
Bjarta hliðin
Rök Light Side má lýsa stuttlega í einni setningu: „Halló, 2k19 er fyrir utan gluggann! Þetta hljómar auðvitað eins og popúlismi, en ef farið er ítarlega ofan í stöðuna hefur það sína kosti. Við skulum redda þeim núna.
Segjum að þú sért með stórt vefverkefni. Það hefði upphaflega getað verið byggt á grundvelli örþjónustunálgunar, eða á einhverjum tímapunkti komið að því í gegnum þróunarleið - þetta er í rauninni ekki mjög mikilvægt. Þú dreifðir verkefninu okkar í aðskildar örþjónustur, settir upp hljómsveitarsetningu, álagsjafnvægi og mælikvarða. Og núna, með góðri samvisku, soparðu mojito í hengirúmi á meðan á habra effects stendur í stað þess að hækka fallna netþjóna. En í öllum aðgerðum verður þú að vera samkvæmur. Mjög oft er aðeins forritið sjálft - kóðinn - í gáma. Hvað annað höfum við fyrir utan kóða?
Það er rétt, gögn. Kjarni hvers verkefnis er gögn þess: þetta getur verið annað hvort dæmigerð DBMS - MySQL, Postgre, MongoDB, eða geymsla sem notuð er til að leita (ElasticSearch), lykilgilda geymsla fyrir skyndiminni - til dæmis, redis, osfrv. Eins og er. við munum tala um skakka bakenda útfærslumöguleika þegar gagnagrunnurinn hrynur vegna illa skrifaðra fyrirspurna, og í staðinn munum við tala um að tryggja bilanaþol einmitt þessa gagnagrunns undir álagi viðskiptavina. Þegar öllu er á botninn hvolft, þegar við geymum forritið okkar og leyfum því að stækka að vild til að vinna úr hvaða fjölda komandi beiðna, eykur þetta náttúrulega álagið á gagnagrunninn.
Reyndar verður rásin til að fá aðgang að gagnagrunninum og netþjóninum sem hann keyrir á nálarauga í fallega gámasvæðinu okkar. Á sama tíma er aðalhvatinn fyrir sýndarvæðingu gáma hreyfanleiki og sveigjanleiki mannvirkisins, sem gerir okkur kleift að skipuleggja dreifingu hámarksálags yfir alla innviði sem okkur standa til boða á eins skilvirkan hátt og mögulegt er. Það er, ef við tökum ekki ílát og rúllum út öllum núverandi þáttum kerfisins yfir klasann, erum við að gera mjög alvarleg mistök.
Það er miklu rökréttara að flokka ekki aðeins forritið sjálft, heldur einnig þá þjónustu sem ber ábyrgð á að geyma gögn. Með því að flokka og setja upp vefþjóna sem vinna sjálfstætt og dreifa álaginu á milli sín í k8s erum við nú þegar að leysa vandamálið við samstillingu gagna - sömu athugasemdir við færslur, ef við tökum einhvern miðil eða bloggvettvang sem dæmi. Í öllum tilvikum höfum við innan-þyrping, jafnvel sýndar, framsetningu á gagnagrunninum sem ytri þjónustu. Spurningin er sú að gagnagrunnurinn sjálfur er ekki enn í þyrpingu - vefþjónarnir sem eru notaðir í teningnum taka upplýsingar um breytingar úr kyrrstöðu bardagagagnagrunninum okkar, sem snýst sérstaklega.
Finnurðu grípa? Við notum k8s eða Swarm til að dreifa álaginu og forðast að hrynja aðal vefþjóninn, en við gerum þetta ekki fyrir gagnagrunninn. En ef gagnagrunnurinn hrynur, þá meikar allur klasainnviði okkar engan sens - hvaða gagn eru tómar vefsíður sem skila aðgangsvillu í gagnagrunni?
Þess vegna er nauðsynlegt að klasa ekki aðeins vefþjóna, eins og venjulega er gert, heldur einnig gagnagrunninn. Aðeins þannig getum við tryggt uppbyggingu sem virkar að fullu í einu teymi en á sama tíma óháð hvert öðru. Þar að auki, jafnvel þótt helmingur bakenda okkar „hrynji“ undir álagi, mun restin lifa af, og kerfið til að samstilla gagnagrunna innbyrðis innan klasans og hæfileikinn til að stækka endalaust og dreifa nýjum klasa mun hjálpa til við að ná fljótt nauðsynlegri getu - ef aðeins væru rekki í gagnaverinu.
Að auki gerir gagnagrunnslíkanið sem er dreift í klasa þér kleift að fara með einmitt þennan gagnagrunn þangað sem þess er þörf; Ef við erum að tala um alheimsþjónustu, þá er frekar órökrétt að spinna upp vefklasa einhvers staðar á San Francisco svæðinu og senda um leið pakka þegar farið er í gagnagrunn á Moskvu svæðinu og til baka.
Einnig gerir gámavæðing gagnagrunnsins þér kleift að byggja alla þætti kerfisins á sama útdráttarstigi. Sem aftur gerir það mögulegt að stjórna þessu kerfi beint úr kóða, af forriturum, án virkrar þátttöku stjórnenda. Hönnuðir töldu að sérstakt DBMS væri þörf fyrir nýja undirverkefnið - auðvelt! skrifaði yaml skrá, hlóð henni upp í þyrpinguna og þú ert búinn.
Og auðvitað er innri reksturinn mjög einfaldaður. Segðu mér, hversu oft hefurðu lokað augunum þegar nýr liðsmaður lagði hendur sínar í bardagagagnagrunninn vegna vinnu? Hver er í raun sá eini sem þú átt og er að snúast núna? Auðvitað erum við öll fullorðin hérna, og einhvers staðar eigum við nýjan varabúnað, og jafnvel lengra í burtu - bak við hilluna með gúrkunum hennar ömmu og gömul skíði - annað varabúnaður, kannski jafnvel í frystigeymslu, því skrifstofan þín var þegar alelda einu sinni. En þrátt fyrir það, hver kynning á nýjum liðsmanni með aðgang að bardagainnviðum og að sjálfsögðu að bardagagagnagrunninum er fötu af validol fyrir alla í kring. Jæja, hver þekkir hann, nýbyrjuð, kannski er hann misvísandi? Það er skelfilegt, þú munt sammála.
Gámavæðing og í raun dreifð efnisfræðileg svæðisfræði gagnagrunns verkefnisins þíns hjálpar til við að forðast slík sannprófunarstund. Treystir þú ekki nýliði? Allt í lagi! Við skulum gefa honum sinn eigin klasa til að vinna með og aftengja gagnagrunninn frá hinum þyrpingunum - samstilling aðeins með handvirkum ýtingum og samstilltum snúningi tveggja lykla (annar fyrir liðsstjórann, hinn fyrir stjórnandann). Og allir eru ánægðir.
Og nú er kominn tími til að breytast í andstæðinga gagnagrunnsþyrpingar.
Dökk hlið
Með því að rökstyðja hvers vegna það er ekki þess virði að geyma gagnagrunninn og halda áfram að keyra hann á einum miðlægum netþjóni, munum við ekki lúta í lægra haldi fyrir orðræðu um rétttrúnað og staðhæfingar eins og „afar ráku gagnagrunna á vélbúnaði, og það gerum við líka!“ Þess í stað skulum við reyna að koma upp þeirri stöðu að gámavæðing myndi í raun skila áþreifanlegum arði.
Sammála, verkefnin sem raunverulega þarfnast grunns í gámi er ekki hægt að telja á fingrum annarrar handar af ekki besti fræsaraðili. Að mestu leyti er jafnvel notkun k8s eða Docker Swarm sjálfs óþörf - oft er gripið til þessara tækja vegna almennrar tæknivæðingar og viðhorfa „almáttugs“ í persónu kynjanna til að ýta öllu inn í ský og ílát. Jæja, því núna er þetta í tísku og allir gera það.
Í að minnsta kosti helmingi tilvika er óþarfi að nota Kubernetis eða bara Docker í verkefni. Málið er að ekki eru öll teymi eða útvistun fyrirtæki ráðin til að viðhalda innviðum viðskiptavinarins meðvituð um þetta. Það er verra þegar gámum er sett á, því það kostar ákveðið magn af mynt fyrir viðskiptavininn.
Almennt séð er sú skoðun að hafnarverkamaður/kubba mafían sé heimskulega að kremja viðskiptavini sem útvista þessum innviðamálum. Þegar öllu er á botninn hvolft, til þess að vinna með klasa, þurfum við verkfræðinga sem eru færir um þetta og skilja almennt arkitektúrinn á innleiddu lausninni. Við lýstum einu sinni máli okkar með lýðveldisútgáfunni - þar þjálfuðum við teymi viðskiptavinarins til að vinna í raunveruleika Kubernetis og allir voru ánægðir. Og það var þokkalegt. Oft taka „framleiðendur“ k8s innviði viðskiptavinarins í gíslingu - því nú skilja þeir aðeins hvernig allt virkar þar; það eru engir sérfræðingar á hlið viðskiptavinarins.
Ímyndaðu þér nú að á þennan hátt útvistum við ekki aðeins vefþjónshlutanum, heldur einnig viðhaldi gagnagrunnsins. Við sögðum að BD væri hjartað og að missa hjartað væri banvænt fyrir hvaða lífveru sem er. Í stuttu máli eru horfurnar ekki þær bestu. Svo, í stað þess að efla Kubernetis, ættu mörg verkefni einfaldlega ekki að trufla venjulega gjaldskrá fyrir AWS, sem mun leysa öll vandamál með álag á síðuna / verkefnið þeirra. En AWS er ekki lengur í tísku og sýningar eru meira virði en peninga - því miður líka í upplýsingatækniumhverfinu.
Allt í lagi. Kannski þarf verkefnið virkilega að klasa, en ef allt er á hreinu með ríkisfangslausum forritum, hvernig getum við þá skipulagt viðeigandi nettengingu fyrir klasaðan gagnagrunn?
Ef við erum að tala um óaðfinnanlega verkfræðilega lausn, sem er það sem umskiptin yfir í k8s eru, þá er helsti höfuðverkurinn okkar gagnaafritun í þyrpuðum gagnagrunni. Sum DBMS eru í upphafi nokkuð trygg við dreifingu gagna milli einstakra tilvika. Margir aðrir eru ekki svo velkomnir. Og oft er aðalröksemdin við að velja DBMS fyrir verkefnið okkar ekki hæfileikinn til að endurtaka með lágmarks auðlinda- og verkfræðikostnaði. Sérstaklega ef verkefnið var upphaflega ekki skipulagt sem örþjónusta, heldur einfaldlega þróast í þessa átt.
Við teljum að það sé engin þörf á að tala um hraða netdrifa - þeir eru hægir. Þeir. Við höfum samt ekki raunverulegt tækifæri, ef eitthvað gerist, til að endurræsa DBMS tilvik einhvers staðar þar sem það er meira, til dæmis, örgjörvaafl eða laust vinnsluminni. Við munum mjög fljótt lenda í afköstum sýndarvæddu diska undirkerfisins. Í samræmi við það verður að negla DBMS við sitt eigið persónulega sett af vélum sem staðsettar eru í nálægð. Eða það er nauðsynlegt að einhvern veginn sérstaklega kæla niður nægilega hraðvirka gagnasamstillingu fyrir ætlaðan varasjóð.
Áframhaldandi efni sýndarskráarkerfa: Docker bindi, því miður, er ekki vandamálalaust. Almennt séð, í slíku máli eins og langtíma áreiðanlegri gagnageymslu, vil ég láta mér nægja tæknilega einföldustu kerfin. Og það er áhætta í sjálfu sér að bæta nýju abstraktlagi úr FS ílátsins við FS móðurhýsilsins. En þegar rekstur gámaflutningskerfisins lendir einnig í erfiðleikum með að senda gögn á milli þessara laga, þá er það í raun hörmung. Í augnablikinu virðast flest vandamál sem framsækið mannkyn þekkir hafa verið útrýmt. En þú skilur, því flóknari sem vélbúnaðurinn er, því auðveldari brotnar hann.
Í ljósi allra þessara „ævintýra“ er mun arðbærara og auðveldara að halda gagnagrunninum á einum stað, og jafnvel þótt þú þurfir að geyma forritið, láttu það keyra á eigin spýtur og fáðu samtímis samskipti við dreifingargáttina. gagnagrunnur, sem verður aðeins lesinn og skrifaður einu sinni og á einum stað. Þessi nálgun dregur úr líkum á villum og afsamstillingu í lágmarki.
Til hvers erum við að leiða? Þar að auki er gámavæðing gagnagrunns viðeigandi þar sem raunveruleg þörf er fyrir það. Þú getur ekki fyllt upp gagnagrunn með fullri app og snúið honum eins og þú værir með tvo tugi örþjónustu - það virkar ekki þannig. Og þetta verður að vera skýrt skilið.
Í stað þess að framleiða
Ef þú ert að bíða eftir skýrri niðurstöðu „að sýndarvera gagnagrunninn eða ekki,“ þá munum við valda þér vonbrigðum: hann mun ekki vera hér. Vegna þess að þegar búið er að búa til hvaða innviðalausn sem er, verður maður ekki að hafa tísku og framfarir að leiðarljósi, heldur fyrst og fremst skynsemi.
Það eru verkefni þar sem meginreglur og verkfæri sem fylgja Kubernetis passa fullkomlega og í slíkum verkefnum er friður að minnsta kosti á bakendasvæðinu. Og það eru verkefni sem þurfa ekki gámavæðingu, heldur venjulegan netþjónainnviði, vegna þess að þau geta í grundvallaratriðum ekki endurskalað í smáþjónustuklasalíkanið, vegna þess að þau munu falla.
Heimild: www.habr.com