ProHoster > Blog > Administrimi > Modelet e ruajtjes së të dhënave në Kubernetes

Modelet e ruajtjes së të dhënave në Kubernetes

Modelet e ruajtjes së të dhënave në Kubernetes
Përshëndetje, Habr!

Ju kujtojmë se kemi publikuar një libër tjetër jashtëzakonisht interesant dhe të dobishëm libri për modelet Kubernetes. E gjitha filloi nga "Modele" Brendan Burns, dhe, megjithatë, puna në këtë segment për ne e ngjeshur. Sot, ne ju ofrojmë të lexoni një artikull nga blogu MinIO, që përmbledh tendencat dhe specifikat e modeleve të ruajtjes së të dhënave në Kubernetes.

Kubernetes ka ndryshuar thelbĂ«sisht modelet tradicionale tĂ« zhvillimit dhe implementimit tĂ« aplikacioneve. Tani ekipi mund tĂ« marrĂ« vetĂ«m disa ditĂ« pĂ«r zhvillimin, testimin dhe implementimin e aplikacionit – nĂ« ambientet e ndryshme, dhe tĂ« gjitha kĂ«to brenda klasterĂ«ve Kubernetes. NjĂ« punĂ« me teknologjitĂ« e brezit tĂ« kaluar zakonisht merrte javĂ« tĂ« tĂ«ra, po jo muaj.

Ky përshpejtim është bërë i mundur falë abstraksionit që ofron Kubernetes - domethënë, falë faktit se Kubernetes vetë merr përsipër ndërveprimin me detajet e ulëta të makinave fizike ose virtuale, duke lejuar përdoruesit të shpallin ndër të tjera procesorin e duhur, sasinë e nevojshme të memories, dhe numrin e ekzemplarëve të kontejnerëve. Siç mbështetet Kubernetes nga një komunitet i madh, dhe si përdorimi i Kubernetes vazhdon të zgjerrohet, ai është me një diferencë të madhe lider mes të gjitha platformave të orkestrimit të kontejnerëve.

Me zgjerimin e përdorimit të Kubernetes, rritet gjithashtu konfuzioni rreth modeleve të ruajtjes së të dhënave që përdoren në të..

Me gjithë konkurrencën për një copë nga torta Kubernetes (atë që përfshin ruajtjen e të dhënave), kur diskutohet për ruajtjen e të dhënave, sinjali këtu humbet në një zhurmë të madhe.
Kubernetes përmbush modelin modern të zhvillimit dhe implementimit të aplikacioneve, si dhe menaxhimin e tyre. Ky model modern tërheq ruajtjen e të dhënave nga llogaritjet. Për të kuptuar plotësisht këtë shkëputje në kontekstin e Kubernetes, është gjithashtu e nevojshme të kuptohet se çfarë janë aplikacionet që punojnë me ruajtje të gjendjes dhe ato që punojnë pa ruajtje të gjendjes, si dhe si përshtatet ruajtja e të dhënave me këtë. Këtu, qasja e REST API, e përdorur nga S3, ka avantazhe të dukshme krahasuar me qasjen POSIX/CSI, karakteristike për zgjidhje të tjera.

Në këtë artikull, ne do të flasim për modelet e ruajtjes së të dhënave në Kubernetes dhe do të shqyrtojmë ndarë debatin rreth aplikacioneve që punojnë me gjendje dhe pa gjendje, për të kuptuar mirë se çfarë e ndan ato dhe pse kjo është e rëndësishme. Në vazhdim do të shqyrtojmë aplikacionet dhe modelet e ruajtjes së të dhënave që përdoren në to në dritën e praktikave më të mira të punës me kontejnerë dhe Kubernetes.

Kontejnerët pa gjendje

Kontejnerët për natyrën e tyre janë të lehtë dhe efemerë. Ata mund të ndalen, fshihen ose implementohen lehtësisht në një nod tjetër - për të gjitha këto nevojiten vetëm disa sekonda. Në një sistem të madh të orkestrimit të kontejnerëve, këto operacione ndodhin vazhdimisht, dhe përdoruesit madje nuk e ndiejnë këtë ndryshim. Megjithatë, lëvizjet janë të mundshme vetëm nëse konteineri nuk ka asnjë varësi nga nodeli ku ndodhet. Për këta kontejnerë, thuhet se ata punojnë pa gjendje.

Kontejnerët me gjendje

Nëse konteineri ruan të dhëna në pajisje të lidhura lokalisht (ose në një pajisje bllokuese), atëherë ruajtja e të dhënave ku ndodhet duhen lëvizur në një nod të ri së bashku me vetë konteinerin - në rast se ka një dështim. Kjo është e rëndësishme, pasi në të kundërt, aplikacioni që funksionon në konteiner nuk do të mund të funksionojë siç duhet, pasi i duhet të aksesojë të dhënat e ruajtura në pajisjet lokale. Për këta kontejnerë, thuhet se ata punojnë me gjendje.

Nga një pikëpamje të pastër teknike, kontejnerët me gjendje gjithashtu mund të lëvizin në nod të tjera. Zakonisht, kjo sigurohet përmes sistemeve të skedave të shpërndara ose ruajtesve të rrjetit të bllokut që janë të lidhura me të gjitha nodet ku funksionojnë kontejnerë. Kështu, kontejnerët kanë akses në volumin për ruajtjen e të dhënave të qëndrueshme, dhe informacioni ruhet në disqe që ndodhen në të gjithë rrjetin. Ky metod do ta quaj "afro-kontejner me gjendje", dhe në pjesën tjetër të artikullit do ta emërtoj kështu për qëllime të njëllojtësisë.

Modelet e ruajtjes së të dhënave në Kubernetes

Në qasjen tipike të konteinerëve me gjendje, të gjitha podet e aplikacioneve lidhen me një sistem skedash të shpërndarë - kështu krijohet një lloj ruajtjeje të ndarë, ku ndodhen të gjithë të dhënat e aplikacioneve. Edhe pse janë të mundshme disa variacione, kjo është një qasje me nivel të lartë.

Së tanishme, le të kuptojmë pse qasja e kontejnerëve me ruajtje të qëndrueshme në botën e orientuar nga re është një antipatrone.

Projektimi i aplikacioneve të orientuara nga re

Tradicionalisht, aplikacionet kanë përdorur baza të dhënash për ruajtjen e strukturuar të informacionit dhe diske lokale ose sisteme të shpërndara të skedarëve ku derdhen të gjitha të dhënat e pa strukturuara ose madje edhe gjysmë të strukturuara. Ndërsa volumet e të dhënave të pa strukturuara rriteshin, zhvilluesit kuptuan se POSIX ishte tepër "flasës", përcaktonte kosto të konsiderueshme dhe, përfundimisht, pengonte funksionimin e aplikacionit kur kalonte në shkallë të vërtetë të madhe.

Kjo kryesisht çoi në shfaqjen e një standardi të ri për ruajtjen e të dhënave, pra, depozita të orientuara nga re që funksionojnë kryesisht në bazë të REST API dhe çlirojnë aplikacionin nga ngarkesa e mirëmbajtjes së ruajtjes lokale të të dhënave. Në këtë rast, aplikacioni në fakt kalon në një gjendje pune pa ruajtje të qëndrueshme (pasi gjendja ndodhet në një depo të largët). Aplikacionet moderne ndërtohen nga e para duke marrë parasysh këtë faktor. Si rregull, çdo aplikacion modern që përpunon të dhëna të çfarëdo lloji (log, metadata, blob dhe të tjera) është ndërtuar sipas paradigmës së orientuar nga re, ku gjendja është transferuar në një sistem të softuerit të dedikuar për ruajtjen e saj.

Qasja e kontejnerëve me ruajtje të qëndrueshme e shtyn të gjithë këtë paradigmë të rikthehet pikërisht aty ku nisi!

Kur përdoren ndërfaqet POSIX për ruajtjen e të dhënave, aplikacionet funksionojnë ashtu siç do të bënin nëse do të ruanin gjendjen, dhe për këtë arsye ato largohen nga parimet më të rëndësishme të projektimit të orientuar nga re, pra, nga mundësia për të ndryshuar dimensionet e flukseve të punës të aplikacionit në varësi të ngarkesës hyrëse, për të kaluar në një nyje të re, sapo nyja aktuale dështojë, dhe kështu me radhë.

Duke e shqyrtuar këtë situatë më me kujdes, zbuloni se kur zgjidhni një depo të dhënash, përsëri dhe përsëri ndodhemi përballë dilemës "POSIX kundër REST API", POR me një përkeqësim të shtuar të problemeve POSIX, të shkaktuara nga natyra e shpërndarë e ambienteve Kubernetes. Në veçanti,

  • POSIX Ă«shtĂ« flasĂ«s: semantika e POSIX kĂ«rkon tĂ« asociojĂ« çdo operacion me metadatat dhe deskriptorĂ«t e skedarĂ«ve, tĂ« cilĂ«t ndihmojnĂ« nĂ« ruajtjen e gjendjes sĂ« operacionit. Kjo çon nĂ« kosto tĂ« konsiderueshme, qĂ« nuk kanĂ« asnjĂ« vlerĂ« reale. API pĂ«r ruajtjen e objekteve, nĂ« veçanti, S3 API, e ka eliminuar kĂ«tĂ« kĂ«rkesĂ«, duke lejuar qĂ« aplikacioni tĂ« punojĂ« dhe pastaj "tĂ« harrojĂ«" thirrjen. Reagimi i sistemit tĂ« ruajtjes tregon nĂ«se kjo veprim Ă«shtĂ« kryer me sukses apo jo. NĂ« rast dĂ«shtimi, aplikacioni mund tĂ« provojĂ« pĂ«rsĂ«ri.
  • Kufizimet e rrjetit: NĂ« njĂ« sistem tĂ« shpĂ«rndarĂ« supozohet se mund tĂ« ketĂ« shumĂ« aplikacione qĂ« pĂ«rpiqen tĂ« shkruajnĂ« tĂ« dhĂ«na nĂ« njĂ« mbajtĂ«s tĂ« ngjitur. Pra, pĂ«rveç faktit se aplikacionet do tĂ« konkurrojnĂ« me njĂ«ra-tjetrĂ«n pĂ«r bandĂ« (pĂ«r tĂ« dĂ«rguar tĂ« dhĂ«na nĂ« mbajtĂ«s), vetĂ« sistemi i ruajtjes do tĂ« jetĂ« nĂ« garĂ« pĂ«r kĂ«tĂ« bandĂ«, duke shpĂ«rndarĂ« tĂ« dhĂ«na nĂ« diskĂ«t fizikĂ«. PĂ«r shkak tĂ« flasĂ«sisĂ« sĂ« POSIX, numri i thirrjeve nĂ« rrjet rritet disa herĂ«. Nga ana tjetĂ«r, S3 API ofron njĂ« ndarje tĂ« qartĂ« tĂ« thirrjeve tĂ« rrjetit mes atyre qĂ« vijnĂ« nga klienti nĂ« server, dhe atyre qĂ« ndodhin brenda serverit.
  • Siguria: Modeli i sigurisĂ« sĂ« POSIX Ă«shtĂ« i dizajnuar pĂ«r pĂ«rfshirjen aktive tĂ« njeriut: administratorĂ«t konfigurojnĂ« nivelet specifike tĂ« aksesit pĂ«r çdo pĂ«rdorues apo grup. Kjo paradigmĂ« Ă«shtĂ« e vĂ«shtirĂ« pĂ«r t'u adaptuar nĂ« botĂ«n e orientuar nga re. Aplikacionet moderne varen nga modelet e sigurisĂ« qĂ« lidhen me API-tĂ«, ku tĂ« drejtat e aksesit pĂ«rcaktohen si njĂ« grup politikash, krijohen llogari shĂ«rbimi, kredenciale tĂ« pĂ«rkohshme etj.
  • Menaxhimi: KontejnerĂ«t me ruajtje tĂ« qĂ«ndrueshme sjellin disa kosto tĂ« lidhura me menaxhimin. KĂ«tu flasim pĂ«r sinkronizimin e aksesit paralel nĂ« tĂ« dhĂ«na, pĂ«r sigurimin e konsistencĂ«s sĂ« tĂ« dhĂ«nave, gjithçka kĂ«rkon tĂ« peshojmĂ« me kujdes se cilat modele tĂ« aksesit tĂ« dhĂ«nash do tĂ« pĂ«rdoren. Duhet tĂ« instalohen, kontrollohen dhe konfigurohen programe tĂ« tjera, pa pĂ«rmendur pĂ«rpjekjet e shtura qĂ« shpenzohen pĂ«r zhvillim.

Ndërfaqja e kontejnerit për ruajtjen e të dhënave

Ndërsa ndërfaqja e ruajtjes së të dhënave të konteinerëve (CSI) ndihmoi shumë me shpërndarjen e nivelit të volumeve Kubernetes, duke e kaluar pjesërisht tek furnizuesit e jashtëm të ruajtjes së të dhënave, ajo gjithashtu për fat të keq ka ndihmuar në krijimin e bindjes se qasja e konteinerëve me ruajtje të qëndrueshme është metoda e rekomanduar për ruajtjen e të dhënave në Kubernetes.

CSI është zhvilluar si standard për ofrimin e sistemeve të ruajtjes së dhënave të bllokut dhe skedarit për aplikacionet e trashëguara gjatë punës me Kubernetes. Dhe, siç u tregua në këtë artikull, situata e vetme kur qasja e konteinerëve me ruajtje të qëndrueshme (dhe CSI në formën e saj aktuale) ka kuptim është kur aplikacioni vetë është një sistem trashëguar, në të cilin është e pamundur të shtohet mbështetje për API-në e ruajtjes objektore.

ËshtĂ« e rĂ«ndĂ«sishme tĂ« kuptohet se duke pĂ«rdorur CSI nĂ« formĂ«n e saj aktuale, dmth, duke montuar volumin gjatĂ« punĂ«s me aplikacione moderne, do tĂ« pĂ«rballemi me probleme tĂ« ngjashme si ato qĂ« ndodhnin nĂ« sistemet ku ruajtja e tĂ« dhĂ«nave ishte organizuar nĂ« stilin POSIX.

Qasje më cilësore

Në këtë rast, është e rëndësishme të kuptohet se shumica e aplikacioneve në thelb nuk janë të dizajnuara posaçërisht për të punuar me ruajtje të qëndrueshme ose pa ruajtje të qëndrueshme. Kjo sjellje varet nga arkitektura e përgjithshme e sistemit dhe nga variantet specifike të zgjedhura gjatë dizajnimit. Le të flasim pak për aplikacionet që ruajnë gjendjen.

Në parim, të dhënat e aplikacioneve mund të ndahen në disa tipe të gjera:

  • TĂ« dhĂ«nat e regjistrave
  • TĂ« dhĂ«nat e etiketave tĂ« kohĂ«s
  • TĂ« dhĂ«nat e transaksioneve
  • Metadatat
  • Imazhet e konteinerĂ«ve
  • TĂ« dhĂ«nat e blobĂ«ve (objekteve binarĂ« tĂ« mĂ«dhenj)

Të gjitha këto tipe të dhënash mbështeten shumë mirë në platformat moderne të ruajtjes së të dhënave, dhe ekzistojnë disa platforma të fokusuar në re, të përshtatura për ofrimin e të dhënave në secilin nga këto formate specifike. Për shembull, të dhënat e transaksioneve dhe metadata mund të gjenden në një databazë moderne të orientuar nga reja, si CockroachDB, YugaByte, etj. Imazhet e konteinerëve ose të dhënat e blobëve mund të ruhen në një regjistër docker, të bazuar në MinIO. Të dhënat e etiketave të kohës mund të ruhen në një databazë të serive të kohës, për shembull, InfluxDB, etj. Nuk do të hyjmë këtu në detajet e çdo tipi të dhënash dhe aplikacioneve përkatëse, por ideja e përgjithshme është të shmangen ruajtja e qëndrueshme të të dhënave që bazohet në montimin lokal të disqeve.

Modelet e ruajtjes së të dhënave në Kubernetes

Për më tepër, shpesh është efikase të ofrohet një nivel përkohësisht të ruajtjes, i cili shërben si një ruajtës për aplikacionet për skedarët e përkohshëm, por aplikacionet nuk duhet të varen nga ky nivel si burim i vërtetë.

Ruajtja për aplikacionet me gjendje

NdĂ«rsa nĂ« shumicĂ«n e rasteve Ă«shtĂ« e dobishme tĂ« mbahen aplikacionet pa gjendje, ato aplikacione qĂ« janĂ« tĂ« destinuara pĂ«r ruajtjen e tĂ« dhĂ«nave – si databazat, ruajtĂ«sit e objekteve, ruajtĂ«sit e çelĂ«save dhe vlerave – duhet tĂ« mbajnĂ« gjendjen. Le tĂ« shqyrtojmĂ« pse kĂ«to aplikacione implementohen nĂ« Kubernetes. Si njĂ« shembull, do tĂ« marrim MinIO, por parime tĂ« ngjashme janĂ« tĂ« aplikueshme nĂ« çdo sistem tĂ« madh tĂ« ruajtjes sĂ« tĂ« dhĂ«nave orientuar nga re.

Aplikacionet e orientuara nga re janë të dizajnuara për të shfrytëzuar në maksimum fleksibilitetin që ofrojnë konteinerët. Kjo do të thotë se ato nuk bëjnë asnjë supozim rreth mjedisit në të cilin do të implementohen. Për shembull, në MinIO përdoret një mekanizëm i brendshëm i kodimit të tepruar (erasure coding), i cili siguron që sistemi të mbetet funksional edhe në rastin e dështimit të gjysmë të disqeve. Gjithashtu, MinIO menaxhon integritetin dhe sigurinë e të dhënave duke përdorur hashing dhe enkriptim të vetin në anën e serverit.

Për këto aplikacione të orientuara nga re, ruajtësit lokalë të përhershëm (PV) janë më të përshtatshëm për ruajtje rezervë. PV të lokalizuar ofrojnë mundësinë e ruajtjes së të dhënave të papërpunuara, ndërsa aplikacionet që punojnë mbi këto PV mbledhin informacionin që u mundëson atyre të shkallëzojnë të dhënat dhe të menaxhojnë kërkesat në rritje për të dhëna.

Kjo qasje është shumë më e thjeshtë dhe shkallëzohet dukshëm më mirë në krahasim me PV të bazuar në CSI, të cilat sjellin nivele të tyre të menaxhimit të të dhënave dhe tepër, sepse këto nivele zakonisht konflitikojnë me aplikacionet e dizajnuara për ruajtjen e gjendjes.

Një lëvizje e sigurt drejt shkëputjes së të dhënave nga llogaritjet

Në këtë artikull, ne diskutuam se si aplikacionet riorganizohen për të punuar pa ruajtjen e gjendjes, ose, me fjalë të tjera, ruajtja e të dhënave ndarja nga llogaritë mbi to. Në përfundim, do të shqyrtojmë disa shembuj realë të këtij trendi.

Spark, platforma e njohur për analizën e të dhënave, traditaërisht është përdorur me ruajtjen e gjendjes dhe me shpërndarjen në sistemin e skedarëve HDFS. Megjithatë, ndërsa Spark kalon në një botë të orientuar nga re, kjo platformë po përdoret gjithnjë e më shumë pa ruajtjen e gjendjes me përdorimin e `s3a`. Spark përdor s3a për të transferuar gjendjen në sisteme të tjera, ndërsa kontenierët e vetë Spark punojnë plotësisht pa ruajtjen e gjendjes. Aktorët e tjerë të mëdhenj të ndërmarrjeve në fushën e analizës së të dhënave të mëdha, veçanërisht, Vertica, Teradata, Greenplum në po ashtu kalojnë në punën me ndarjen e ruajtjes së të dhënave dhe llogaritjeve mbi to.

Modele të tilla gjithashtu vërehen në platforma të tjera të mëdha analitike, përfshirë Presto, Tensorflow to R, Jupyter. Duke eksportuar gjendjen në sisteme të largëta të ruajtjes së të dhënave në re, bëhet shumë më e lehtë të menaxhoni aplikacionin tuaj dhe ta shkallëzoni atë. Për më tepër, kjo ndihmon në portabilitetin e aplikacionit në mjedise të ndryshme.

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster