ProHoster > Blog > Administrim > 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ë tjetër artikull tepër interesant dhe të dobishëm libër për modelet Kubernetes. E gjithë kjo filloi me "Modelet" të Brendan Burns, dhe megjithatë, puna në këtë segment është në zhvillim. Sot, ne ju ofrojmë të lexoni një artikull nga blogu MinIO, i cili paraqet shkurtimisht tendencat dhe specifikat e modeleve të ruajtjes së të dhënave në Kubernetes.

Kubernetes ka ndryshuar nĂ« mĂ«nyrĂ« themelore modelet tradicionale tĂ« zhvillimit dhe implementimit tĂ« aplikacioneve. Tani ekipi mund tĂ« shpenzojĂ« vetĂ«m disa ditĂ« pĂ«r tĂ« zhvilluar, testuar dhe implementuar njĂ« aplikacion – nĂ« mjedise tĂ« ndryshme, dhe gjithçka brenda klastereve Kubernetes. Puna me teknologjitĂ« e brezave tĂ« kaluar zakonisht merrte javĂ« tĂ« tĂ«ra, nĂ«se jo muaj.

Ky pĂ«rshpejtim Ă«shtĂ« bĂ«rĂ« i mundur falĂ« abstraksionit qĂ« ofron Kubernetes — dmth, falĂ« faktit se Kubernetes ndĂ«rvepron me detalet e ulĂ«ta tĂ« pajisjeve fizike ose virtuale, duke lejuar pĂ«rdoruesit tĂ« shpallin, pĂ«rveç parametrave tĂ« tjerĂ«, procesorin e nevojshĂ«m, sasinĂ« e kujtesĂ«s, numrin e instancave tĂ« kontejnerĂ«ve. Duke qenĂ« se njĂ« komunitet i madh Ă«shtĂ« i angazhuar nĂ« mbĂ«shtetje tĂ« Kubernetes dhe shkalla e pĂ«rdorimit tĂ« Kubernetes vazhdon tĂ« zgjerohet, ai Ă«shtĂ« nĂ« mĂ«nyrĂ« tĂ« dukshme lider nĂ« mesin e tĂ« gjitha platformave tĂ« orkestrimit tĂ« kontejnerĂ«ve.

Me rritjen e përdorimit të Kubernetes, rritet edhe konfuzioni në lidhje me modelet e ruajtjes së të dhënave të aplikuara atje..

Me gjithë konkurrencën për një copë të tortës Kubernetes (dmth, për ruajtjen e të dhënave), kur bëhet fjalë 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 ndan ruajtjen e të dhënave nga llogaritjet. Për të kuptuar plotësisht këtë ndarje në kontekstin e Kubernetes, është e nevojshme gjithashtu të kuptohet se çfarë përfaqësojnë aplikacionet me ruajtje gjendjeje dhe pa ruajtje gjendjeje, si dhe se si lidhen kjo me ruajtjen e të dhënave. Këtu është vendi ku qasja REST API e aplikuar nga S3 ka avantazhe të qarta krahasuar me qasjen POSIX/CSI, tipike për zgjidhjet e tjera.

Në këtë artikull do të flasim për modelet e ruajtjes së të dhënave në Kubernetes dhe do të trajtojmë veçmas debatin në lidhje me aplikacionet që punojnë me gjendje dhe pa gjendje, për të kuptuar saktësisht se çfarë përbën dallimin mes tyre dhe pse është i rëndësishëm. Më tej, do të shqyrtohen 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ët dhe Kubernetes.

Kontejnerë pa gjendje

Kontejnerët natyrshëm janë të lehtë dhe efemer. Ata mund të ndalen, hiqen ose vendosen pa mundim në një nod tjetër - të gjitha këto kërkojnë vetëm disa sekonda. Në një sistem të madh orkestrimi të kontejnerëve, këto operacione ndodhin vazhdimisht dhe përdoruesit nuk e vërejnë asnjëherë këto ndryshime. Megjithatë, lëvizjet janë të mundshme vetëm nëse kontenieri nuk ka asnjë varësi nga nodi në të cilin ndodhet. Për këta kontejnerë thuhet se ata punojnë pa gjendje.

Kontejnerë me gjendje

Nëse një kontenier ruan të dhëna në pajisje të lidhura lokalisht (ose në një pajisje bllok), atëherë ruajtja e të dhënave, në të cilën ndodhet, do të duhet të lëvizi në një nod të ri së bashku me vetë kontenierin - në rast se ndodh një dështim. Kjo është e rëndësishme, sepse në të kundërt aplikacioni që ekzekutohet në kontenier nuk do të funksionojë siç duhet, pasi i nevojitet të aksesojë të dhënat e ruajtura në médhjet lokale. Për këta kontejnerë thuhet se ata punojnë me gjendje.

Nga një këndvështrim tërësor teknik, kontejnerët me gjendje gjithashtu mund të lëvizin në nod të tjerë. Kjo zakonisht sigurohet përmes sistemeve të shpërndara të skedarëve ose ruajtjeve të dhënash të lidhura me rrjet të bllokut, të cilat janë të lidhura me të gjithë nodet ku punojnë kontejnerët. Kështu, kontejnerët aksesojnë volumin për ruajtjen e qëndrueshme të të dhënave, dhe informacioni ruhet në disqe që ndodhen në të gjithë rrjetin. Ky metodë unë do ta quaj "përqasje konteinerike me gjendje", dhe në pjesën tjetër të artikullit do ta quaj ashtu për shkak të uniformitetit.

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

Me qasja tipike me kontejnerë që ruajnë gjendjen, të gjitha pods e aplikacioneve lidhen me një sistem të shpërndarë skedarësh - duke krijuar një lloj ruajtjeje të përbashkët, ku gjenden të dhënat e të gjitha aplikacioneve. Megjithëse mund të ketë disa variacione, ky është një qasje me nivel të lartë.

Tani le të shqyrtojmë se pse qasja me kontejnerë që ruajnë gjendjen në botën e orientuar drejt cloud-it është një antipattern.

Projektimi i aplikacioneve të orientuara drejt cloud-it

Tradicionalisht, aplikacionet përdornin bazat e të dhënave për ruajtjen e strukturuar të informacionit dhe disqet lokale ose sistemet e shpërndara të skedarëve, ku mblidheshin të gjitha të dhënat e pa-strukturuara ose madje gjysmë-strukturuara. Ndërsa volumi i të dhënave të pa-strukturuara rritej, zhvilluesit kuptuan se POSIX ishte tepër "i zëshëm", përfshirë kosto të konsiderueshme dhe, përfundimisht, pengonte funksionimin e aplikacionit kur kalonte në nivele të vërteta të mëdha.

Kjo kryesisht ndihmoi në shfaqjen e një standardi të ri për ruajtjen e të dhënave, që do të thotë, ruajtje të orientuar drejt cloud-it, që funksionon kryesisht mbi REST API dhe çliron aplikacionin nga mbikqyrja e ngarkuar e ruajtjes lokale të të dhënave. Në këtë rast, aplikacioni në fakt kalon në një mod të punës që nuk ruan gjendjen (pasi gjendja është në ruajtjen e largët). Aplikacionet moderne ndërtohen me këtë faktor në mendje. Si rregull, çdo aplikacion modern që proceson të dhëna të ndonjë lloji (logs, metadata, blobs, etj.) është ndërtuar mbi paradigmen e orientuar drejt cloud-it, ku gjendja transferohet në një sistem softuerik të veçantë për ruajtjen e saj.

Qasja me kontejnerë që ruajnë gjendjen e kthen tërë këtë paradigëm saktësisht atje ku filloi!

Duke përdorimi të ndërfaqeve POSIX për ruajtjen e të dhënave, aplikacionet punojnë ashtu siç do të bëjnë nëse do të ruanin gjendjen, dhe për këtë arsye, ata largohen nga postulatat më të rëndësishme të projektimit të orientuar ndaj cloud, pra, nga mundësia për të variuar përmasat e rrjedhave të punës të aplikacionit në varësi të ngarkesës së hyrjes, të kalojnë në një nyje të re sapo nyja aktuale të dështojë, e kështu me radhë.

Duke e shqyrtuar këtë situatë më afër, zbulojmë se kur zgjedhim ruajtjen e të dhënave, përsëri dhe përsëri hasim në dilemmën "POSIX kundër REST API", POR me një komplikim shtesë të problemeve POSIX të shkaktuara nga natyra e shpërndarë e mjediseve Kubernetes. Në veçanti,

  • POSIX flet shumĂ«: semantika POSIX kĂ«rkon tĂ« asociohet çdo operacion me metadatat dhe deshifruesit e skedarĂ«ve, tĂ« cilat ndihmojnĂ« nĂ« mbĂ«shtetje tĂ« gjendjes sĂ« operacionit. Kjo çon nĂ« shpenzime tĂ« konsiderueshme, pa ndonjĂ« vlerĂ« reale. API pĂ«r ruajtjen e objekteve, nĂ« veçanti, S3 API, e ka hequr kĂ«tĂ« kĂ«rkesĂ«, duke lejuar qĂ« aplikacioni tĂ« punojĂ«, e mĂ« pas "ta harrojĂ«" thirrjen. PĂ«rgjigjja e sistemit tĂ« ruajtjes sĂ« tĂ« dhĂ«nave tregon nĂ«se veprimi Ă«shtĂ« pĂ«rfunduar me sukses apo jo. NĂ« rast dĂ«shtimi, aplikacioni mund tĂ« bĂ«jĂ« njĂ« pĂ«rpjekje tĂ« re.
  • Kufizimet e rrjetit: NĂ« njĂ« sistem tĂ« shpĂ«rndarĂ«, supozohet se mund tĂ« ekzistojnĂ« shumĂ« aplikacione qĂ« pĂ«rpiqen tĂ« shkruajnĂ« tĂ« dhĂ«na nĂ« tĂ« njĂ«jtin mbajtĂ«s tĂ« lidhur. Prandaj, pĂ«rveç se aplikacionet do tĂ« konkurrojnĂ« me njĂ«ra-tjetrĂ«n pĂ«r bandwidth (pĂ«r tĂ« dĂ«rguar tĂ« dhĂ«na nĂ« mbajtĂ«s), sistemi i ruajtjes sĂ« tĂ« dhĂ«nave vetĂ« do tĂ« konkurrojĂ« pĂ«r kĂ«tĂ« bandĂ«, duke shpĂ«rndarĂ« tĂ« dhĂ«na pĂ«rmes disqeve fizike. PĂ«r shkak tĂ« fjalĂ«shkruarjes sĂ« POSIX, numri i thirrjeve rrjetit rritet disa herĂ«. Nga ana tjetĂ«r, S3 API ofron njĂ« ndarje tĂ« qartĂ« tĂ« thirrjeve rrjetore midis atyre qĂ« vijnĂ« nga klienti nĂ« server, dhe atyre qĂ« ndodhin brenda serverit.
  • Siguria: Modeli i sigurisĂ« POSIX parashikon njĂ« angazhim aktiv tĂ« njeriut: administratorĂ«t konfigurojnĂ« nivelet e veçanta tĂ« aksesit pĂ«r çdo pĂ«rdorues ose grup. Kjo paradigĂ«m Ă«shtĂ« e vĂ«shtirĂ« tĂ« pĂ«rshtatet me botĂ«n cloud-oriented. Aplikacionet moderne varen nga modelet e sigurisĂ« tĂ« lidhura me API, ku tĂ« drejtat e aksesit pĂ«rcaktohen si njĂ« grup politikash, llogaritĂ« e shĂ«rbimeve, kredencialet e pĂ«rkohshme etj.
  • MenaxhueshmĂ«ria: KonteinerĂ«t me ruajtje tĂ« qĂ«ndrueshme sjellin kosto tĂ« caktuara tĂ« lidhura me menaxhimin. KĂ«tu flasim pĂ«r sinkronizimin e aksesit tĂ« paralel pĂ«r tĂ« dhĂ«nat, pĂ«r tĂ« siguruar koherencĂ«n e tĂ« dhĂ«nave, gjithçka kjo kĂ«rkon njĂ« vlerĂ«sim tĂ« kujdesshĂ«m tĂ« modeleve tĂ« aksesit tĂ« tĂ« dhĂ«nave qĂ« do tĂ« pĂ«rdoren. NĂ«shtĂ« e nevojshme tĂ« instalojmĂ«, tĂ« kontrollojmĂ« dhe konfigurojmĂ« programe tĂ« tjera, pa pĂ«rmendur pĂ«rpjekjet shtesĂ« tĂ« shpenzuara pĂ«r zhvillim.

Interfaci i ruajtjes së të dhënave të konteinerëve

Ndërsa interfaci i ruajtjes së të dhënave të konteinerëve (CSI) ka ndihmuar shumë në shpërndarjen e nivelit të volumit të Kubernetes, duke e kaluar pjesërisht atë te ofruesit e tjerë të ruajtjes, por gjithashtu me rastin ndihmoi në bindjen 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 njĂ« standard pĂ«r ofrimin e sistemeve tĂ« ruajtjes me bllok dhe skedarĂ« tĂ« rastĂ«sishĂ«m pĂ«r aplikacionet e trashĂ«guara gjatĂ« punĂ«s me Kubernetes. Dhe, siç u tregua nĂ« kĂ«tĂ« artikull, situata e vetme nĂ« tĂ« cilĂ«n qasja e konteinerĂ«ve me ruajtje tĂ« qĂ«ndrueshme (dhe CSI nĂ« formĂ«n e saj aktuale) Ă«shtĂ« e arsyeshme – Ă«shtĂ« kur vetĂ« aplikacioni Ă«shtĂ« njĂ« sistem i trashĂ«guar, nĂ« tĂ« cilin nuk Ă«shtĂ« e mundur tĂ« shtohet mbĂ«shtetje pĂ«r API-nĂ« e ruajtjes sĂ« objektit.

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

Qasje më cilësore

Në këtë rast, është e rëndësishme të kuptojmë se shumica e aplikacioneve, në thelb, nuk janë të dizajnuara për të punuar me ruajtjen e gjendjes ose pa ruajtjen e gjendjes. Ky tipar varet nga arkitektura e përgjithshme e sistemit dhe nga variantet e veçanta të zgjedhura gjatë projektimit. Le të flasim pak rreth aplikacioneve që ruajnë gjendjen.

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

  • TĂ« dhĂ«na log-esh
  • TĂ« dhĂ«na tĂ« etiketave tĂ« kohĂ«s
  • TĂ« dhĂ«na transaksionesh
  • Metadatot
  • Imazhe kontejnerĂ«sh
  • TĂ« dhĂ«na blob-esh (objekte binarĂ« tĂ« mĂ«dhenj)

Të gjitha këto lloje të dhënash mbështeten shumë mirë në platformat moderne të ruajtjes së të dhënave, dhe ekzistojnë disa platforma të orientuara nga reja të përshtatura për të ofruar të dhëna në secilin nga këto formate specifike. Për shembull, të dhënat e transaksioneve dhe metadat e mund të ndodhen në një bazë të dhënash moderne të orientuar nga reja, siç janë CockroachDB, YugaByte, etj. Imazhet e kontejnerëve ose të dhënat e blob-eve mund të ruhen në regjistrin docker, të bazuar në MinIO. Të dhënat e etiketave të kohës mund të ruhen në një bazë të dhënash të serive të kohës, si InfluxDB, etj. Nuk do të futemi këtu në detajet e secilit lloj të dhënash dhe aplikacionet përkatëse, por ideja kryesore është të shmangim ruajtjen përhershme 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ë efektiv të ofrohet një nivel përkohësisht të ruajtjes, që shërben si një magazinë për skedarët përkohësisht, por aplikacionet nuk duhet të varen nga ky nivel si burimi i të vërtetës.

Ruajtja për aplikacione që ruajnë gjendjen

NdĂ«rkohĂ« qĂ« nĂ« shumicĂ«n e rasteve Ă«shtĂ« e dobishme tĂ« kemi aplikacione pa gjendje, ato aplikacione qĂ« janĂ« tĂ« destinuara pĂ«r ruajtjen e tĂ« dhĂ«nave – si bazat e tĂ« dhĂ«nave, magazinat e objekteve, magazinat e çelĂ«save dhe vlerave – duhet tĂ« ruajnĂ« gjendjen. Le tĂ« shqyrtojmĂ« arsyet pse kĂ«to aplikacione janĂ« implementuar nĂ« Kubernetes. Si njĂ« shembull, le tĂ« marrim MinIO, por principe tĂ« ngjashme janĂ« tĂ« aplikueshme edhe pĂ«r çdo sistem tjetĂ«r tĂ« madh tĂ« ruajtjes sĂ« tĂ« dhĂ«nave tĂ« orientuara nga reja.

Aplikacionet e orientuara nga reja projektohen për të shfrytëzuar maksimalisht fleksibilitetin që ofrojnë kontejnerët. Kjo do të thotë se nuk bëhen asnjë supozim në lidhje me mjedisin në të cilin do të shpërndahen. Për shembull, MinIO përdor një mekanizëm të brendshëm të kodimit të tepruar (erasure coding) që siguron një qëndrushmëri të mjaftueshme për sistemin në mënyrë që të mbetet funksional edhe në rast dështimi të gjysmë të hard diskëve. Po ashtu, MinIO menaxhon integritetin dhe sigurinë e të dhënave duke përdorur hashing dhe enkriptim të vetin në anën e serverit.

Për aplikacionet e tilla të orientuara nga reja, volumi i qëndrueshëm lokal (PV) është zgjidhja më e përshtatshme për ruajtjen e rezervave. PV lokal ofron mundësinë për ruajtjen e të dhënave të papërpunuara, ndërsa aplikacionet që punojnë mbi këto PV mbledhin vetë informacionin që lejon që të dhënat të shkallëzohen dhe të menaxhohen kërkesat në rritje për të dhëna.

Ky qasje është shumë më e thjeshtë dhe shkallëzohet ndjeshëm më mirë se PV-të e bazuara në CSI, të cilat sjellin në sistem nivele të veta të menaxhimit të të dhënave dhe tepricave; problemi është se këto nivele zakonisht bien në kontradiktë me aplikacionet e dizajnuara sipas parimit të ruajtjes së gjendjes.

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

Në këtë artikull diskutuam se si aplikacionet po riorientohen për të punuar pa ruajtje të gjendjes, ose, në fjalë të tjera, ruajtja e të dhënave ndahen nga llogaritjet mbi to. Në përfundim, le të shqyrtojmë disa shembuj realë të këtij trendi.

Spark, platforma e njohur për analizën e të dhënave, tradicionalisht është përdorur me ruajtje gjendjeje dhe me shpërndarje në sistemin e skedarëve HDFS. Megjithatë, ndërsa Spark kalon në botën e orientuar nga reja, kjo platformë po përdoret gjithnjë e më shumë pa ruajtje gjendjeje duke përdorur `s3a`. Spark përdor s3a për të transferuar gjendjen në sisteme të tjera, ndërsa vetë kontejnerët e Spark punojnë në mënyrë të plotë pa ruajtje gjendjeje. Aktorë të tjerë të mëdhenj në fushën e analizës së të dhënave të mëdha, përkatësisht, Vertica, Teradata, Greenplum po ashtu po kalojnë në punë me ndarjen e ruajtjes së të dhënave dhe llogaritjeve mbi to.

Modelet e ngjashme gjithashtu vërehen në platforma të tjera të mëdha analitike, përfshirë Presto, Tensorflow për R, Jupyter. Duke eksportuar gjendjen në sisteme të ruajtjes së të dhënave në re, bëhet shumë më e lehtë të menaxhosh aplikacionin tënd dhe ta shkallëzosh atë. Për më tepër, kjo ndihmon në portabilitetin e aplikacionit në mjedise të ndryshme.

Burimi: habr.com

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