Datu uzglabāŔanas modeļi Kubernetes

Datu uzglabāŔanas modeļi Kubernetes
Čau Habr!

Atgādinām, ka esam laiduÅ”i klajā vēl vienu ārkārtÄ«gi interesantu un noderÄ«gu grāmata par Kubernetes modeļiem. Viss sākās ar "Raksti"Brendans Bērnss, un, starp citu, mums ir darbs Å”ajā segmentā vārās. Å odien aicinām izlasÄ«t rakstu no MinIO emuāra, kurā Ä«si izklāstÄ«tas Kubernetes datu uzglabāŔanas modeļu tendences un specifika.

Kubernetes ir bÅ«tiski mainÄ«jis tradicionālos lietojumprogrammu izstrādes un izvietoÅ”anas modeļus. Tagad komanda var izstrādāt, pārbaudÄ«t un izvietot lietojumprogrammu dažu dienu laikā ā€” vairākās vidēs, un tas viss notiek Kubernetes klasteros. Šāds darbs ar iepriekŔējo paaudžu tehnoloÄ£ijām parasti ilga nedēļas, ja ne mēneÅ”us.

Å o paātrinājumu padara iespējamu Kubernetes nodroÅ”inātā abstrakcija, proti, Kubernetes pati mijiedarbojas ar fizisko vai virtuālo maŔīnu zema lÄ«meņa detaļām, ļaujot lietotājiem deklarēt vēlamo procesoru, vēlamo atmiņas apjomu un konteinera skaitu. gadÄ«jumos, starp citiem parametriem. Ar milzÄ«gu kopienu, kas atbalsta Kubernetes, un tās ievieÅ”ana nepārtraukti paplaÅ”inās, Kubernetes ir lÄ«deris starp visām konteineru orÄ·estrÄ“Å”anas platformām ar lielu pārsvaru.

Pieaugot Kubernetes izmantoŔanai, pieaug arī neskaidrības par tā uzglabāŔanas modeļiem..

Ikvienam sacenÅ”oties par daļu no Kubernetes pÄ«rāga (t.i., datu glabāŔanas), runājot par datu glabāŔanu, signāls tiek noslÄ«cināts lielā trokŔņā.
Kubernetes iemieso modernu lietojumprogrammu izstrādes, izvietoŔanas un pārvaldības modeli. Šis modernais modelis atdala datu krātuvi no skaitļoŔanas. Lai pilnībā izprastu atdalīŔanu Kubernetes kontekstā, jums ir arī jāsaprot, kas ir statusa un bezvalsts lietojumprogrammas un kā datu glabāŔana tajā iekļaujas. Šeit S3 izmantotajai REST API pieejai ir skaidras priekŔrocības salīdzinājumā ar citu risinājumu POSIX/CSI pieeju.

Å ajā rakstā mēs runāsim par datu glabāŔanas modeļiem Kubernetes un Ä«paÅ”i pieskarsimies debatēm starp statusu un bezvalsts lietojumprogrammām, lai labāk saprastu, kāda ir atŔķirÄ«ba starp tām un kāpēc tā ir svarÄ«ga. Pārējā teksta daļā tiks aplÅ«kotas lietojumprogrammas un to datu glabāŔanas modeļi, ņemot vērā paraugpraksi darbam ar konteineriem un Kubernetes.

Konteineri bez pilsonības

Konteineri pēc bÅ«tÄ«bas ir viegli un Ä«slaicÄ«gi. Tos var viegli apturēt, noņemt vai izvietot citā mezglā ā€” tas viss dažu sekunžu laikā. Lielajā konteineru orÄ·estrÄ“Å”anas sistēmā Ŕādas darbÄ«bas notiek visu laiku, un lietotāji Ŕādas izmaiņas pat nepamana. Tomēr pārvietoÅ”ana ir iespējama tikai tad, ja konteineram nav atkarÄ«bu no mezgla, kurā tas atrodas. Tiek uzskatÄ«ts, ka Ŕādi konteineri darbojas bezvalstnieks.

Status saturoŔi konteineri

Ja konteiners glabā datus lokāli pievienotās ierÄ«cēs (vai blokierÄ«cē), datu krātuve, kurā tas atrodas, kļūmes gadÄ«jumā kopā ar paÅ”u konteineru bÅ«s jāpārvieto uz jaunu mezglu. Tas ir svarÄ«gi, jo pretējā gadÄ«jumā lietojumprogramma, kas darbojas konteinerā, nevarēs pareizi darboties, jo tai ir jāpiekļūst datiem, kas glabājas vietējā datu nesējā. Tiek uzskatÄ«ts, ka Ŕādi konteineri darbojas Å”tata.

No tÄ«ri tehniskā viedokļa statusa saturoÅ”us konteinerus var pārvietot arÄ« uz citiem mezgliem. Parasti to panāk, izmantojot sadalÄ«tas failu sistēmas vai bloķējot tÄ«kla krātuvi, kas pievienota visiem mezgliem, kuros darbojas konteineri. Tādā veidā konteineri piekļūst sējumiem pastāvÄ«gai datu glabāŔanai, un informācija tiek glabāta diskos, kas atrodas visā tÄ«klā. Es nosaukÅ”u Å”o metodi "statusa konteinera pieeja", un pārējā rakstā es to vienveidÄ«bas labad nosaukÅ”u tā.

Datu uzglabāŔanas modeļi Kubernetes

Tipiskā statusa konteinera pieejā visi lietojumprogrammu bloki ir pievienoti vienai sadalÄ«tai failu sistēmai ā€” sava veida koplietojamai krātuvei, kurā atrodas visi lietojumprogrammu dati. Lai gan ir iespējamas dažas variācijas, Ŕī ir augsta lÄ«meņa pieeja.

Tagad apskatīsim, kāpēc statusful konteinera pieeja ir pretmodelis uz mākoņiem orientētā pasaulē.

Mākoņa lietojumprogrammu dizains

Tradicionāli lietojumprogrammas izmantoja datu bāzes strukturētai informācijas glabāŔanai un lokālos diskus vai izplatÄ«tās failu sistēmas, kurās tika izmesti visi nestrukturētie vai pat daļēji strukturētie dati. Pieaugot nestrukturēto datu apjomam, izstrādātāji saprata, ka POSIX ir pārāk pļāpÄ«gs, tam ir ievērojamas papildu izmaksas, un galu galā tas kavē lietojumprogrammu veiktspēju, pārejot uz patiesi lieliem mērogiem.

Tas galvenokārt veicināja jauna datu glabāŔanas standarta raÅ”anos, tas ir, mākoņdatoÅ”anas krātuvi, kas galvenokārt darbojas, pamatojoties uz REST API un atbrÄ«vo lietojumprogrammu no apgrÅ«tinoŔās lokālās datu krātuves uzturÄ“Å”anas. Å ajā gadÄ«jumā lietojumprogramma faktiski pāriet bezvalsts režīmā (jo stāvoklis atrodas attālajā krātuvē). MÅ«sdienu lietojumprogrammas tiek veidotas no nulles, paturot prātā Å”o faktoru. Parasti jebkura moderna lietojumprogramma, kas apstrādā viena vai cita veida datus (žurnālus, metadatus, blobus utt.), tiek veidota pēc mākoņdatoÅ”anas paradigmas, kur stāvoklis tiek pārsÅ«tÄ«ts uz programmatÅ«ras sistēmu, kas Ä«paÅ”i paredzēta tā glabāŔanai.

Stāvokļa konteinera pieeja liek Ŕai paradigmai atgriezties tieŔi tur, kur tā sākās!

Izmantojot POSIX saskarnes datu glabāŔanai, lietojumprogrammas darbojas tā, it kā tām bÅ«tu statuss, un Ŕī iemesla dēļ tās atŔķiras no svarÄ«gākajiem uz mākoņiem orientēta dizaina principiem, tas ir, no iespējas mainÄ«t lietojumprogrammu darbinieku pavedienu lielumu atkarÄ«bā no ienākoŔā ievades ielāde, pārejiet uz jaunu mezglu, tiklÄ«dz paÅ”reizējais mezgls neizdodas, un tā tālāk.

AplÅ«kojot Å”o situāciju tuvāk, mēs atklājam, ka, izvēloties datu krātuvi, mēs atkal un atkal saskaramies ar POSIX vs. REST API dilemmu, BET ar papildu POSIX problēmu saasināŔanos Kubernetes vidi izkliedētā rakstura dēļ. It Ä«paÅ”i,

  • POSIX ir pļāpÄ«gs: POSIX semantika pieprasa, lai katra darbÄ«ba bÅ«tu saistÄ«ta ar metadatiem un failu deskriptoriem, kas palÄ«dz uzturēt operācijas stāvokli. Tas rada ievērojamas izmaksas, kurām nav reālas vērtÄ«bas. Objektu krātuves API, Ä«paÅ”i S3 API, atbrÄ«vojas no Ŕīm prasÄ«bām, ļaujot lietojumprogrammai aktivizēties un pēc tam ā€œaizmirstā€ par zvanu. UzglabāŔanas sistēmas atbilde norāda, vai darbÄ«ba bija veiksmÄ«ga vai nē. Ja tas neizdodas, lietojumprogramma var mēģināt vēlreiz.
  • TÄ«kla ierobežojumi: Izkliedētā sistēmā tiek domāts, ka var bÅ«t daudzas lietojumprogrammas, kas mēģina rakstÄ«t datus tajā paŔā pievienotajā datu nesējā. Tāpēc lietojumprogrammas ne tikai sacentÄ«sies savā starpā par datu pārraides joslas platumu (lai nosÅ«tÄ«tu datus uz datu nesēju), bet arÄ« pati uzglabāŔanas sistēma konkurēs par Å”o joslas platumu, nosÅ«tot datus pa fiziskajiem diskiem. POSIX skaļuma dēļ tÄ«kla zvanu skaits palielinās vairākas reizes. No otras puses, S3 API nodroÅ”ina skaidru atŔķirÄ«bu starp tÄ«kla izsaukumiem, kas tiek veikti no klienta uz serveri, un tiem, kas notiek serverÄ«.
  • DroŔība: POSIX droŔības modelis ir paredzēts aktÄ«vai cilvēku lÄ«dzdalÄ«bai: administratori konfigurē Ä«paÅ”us piekļuves lÄ«meņus katram lietotājam vai grupai. Å o paradigmu ir grÅ«ti pielāgot uz mākoņiem orientētai pasaulei. MÅ«sdienu lietojumprogrammas ir atkarÄ«gas no droŔības modeļiem, kuru pamatā ir API, kur piekļuves tiesÄ«bas tiek definētas kā politiku kopums, tiek pieŔķirti pakalpojumu konti, pagaidu akreditācijas dati utt.
  • VadāmÄ«ba: statusu saturoÅ”iem konteineriem ir noteiktas pārvaldÄ«bas izmaksas. Mēs runājam par paralēlās piekļuves datiem sinhronizāciju, datu konsekvences nodroÅ”ināŔanu, tas viss prasa rÅ«pÄ«gi apsvērt, kādus datu piekļuves modeļus izmantot. Papildu programmatÅ«ra ir jāinstalē, jāuzrauga un jākonfigurē, nemaz nerunājot par papildu izstrādes pasākumiem.

Konteinera datu glabāŔanas interfeiss

Lai gan konteineru krātuves interfeiss (CSI) ir ļoti palÄ«dzējis Kubernetes apjoma slāņa izplatÄ«Å”anā, daļēji nododot to treÅ”o puÅ”u krātuves piegādātājiem, tas arÄ« netīŔām ir veicinājis pārliecÄ«bu, ka statusful konteinera pieeja ir ieteicamā metode datu glabāŔana Kubernetes.

CSI tika izstrādāts kā standarts patvaļīgu bloku un failu uzglabāŔanas sistēmu nodroÅ”ināŔanai mantotajām lietojumprogrammām, kad tās darbojas Kubernetes. Un, kā parādÄ«ts Å”ajā rakstā, vienÄ«gā situācija, kurā ir jēga statusful konteinera pieejai (un CSI tās paÅ”reizējā formā), ir tad, ja pati lietojumprogramma ir mantota sistēma, kurā nav iespējams pievienot atbalstu objektu krātuves API. .

Ir svarÄ«gi saprast, ka, izmantojot CSI tā paÅ”reizējā formā, tas ir, montējot apjomus, strādājot ar modernām lietojumprogrammām, mēs saskarsimies ar aptuveni tādām paŔām problēmām, kas radās sistēmās, kurās datu glabāŔana tiek organizēta POSIX stilā.

Labāka pieeja

Å ajā gadÄ«jumā ir svarÄ«gi saprast, ka lielākā daļa lietojumprogrammu pēc bÅ«tÄ«bas nav Ä«paÅ”i izstrādātas darbam ar statusu vai bezvalstniekiem. Å Ä« darbÄ«ba ir atkarÄ«ga no vispārējās sistēmas arhitektÅ«ras un konkrētajām dizaina izvēlēm. Parunāsim nedaudz par statusa pieteikumiem.

Principā visus lietojumprogrammu datus var iedalīt vairākos plaŔos veidos:

  • Žurnāla dati
  • Laika zÄ«moga dati
  • DarÄ«juma dati
  • Metadati
  • Konteineru attēli
  • Blob (bināro lielu objektu) dati

Visi Å”ie datu veidi tiek ļoti labi atbalstÄ«ti mÅ«sdienu krātuves platformās, un ir vairākas mākoņdatoÅ”anas platformas, kas pielāgotas datu piegādei katrā no Å”iem konkrētajiem formātiem. Piemēram, darÄ«jumu dati un metadati var atrasties mÅ«sdienÄ«gā mākoņdatnē, piemēram, CockroachDB, YugaByte utt. Konteinera attēlus vai lāses datus var saglabāt docker reÄ£istrā, kura pamatā ir MinIO. Laika zÄ«mogu datus var saglabāt laikrindu datubāzē, piemēram, InfluxDB utt. Å eit mēs neiedziļināsimies sÄ«kāk par katru datu tipu un tā lietojumprogrammām, taču vispārÄ«gā ideja ir izvairÄ«ties no pastāvÄ«gas datu glabāŔanas, kas ir atkarÄ«ga no lokāla diska montāžas.

Datu uzglabāŔanas modeļi Kubernetes

Turklāt bieži vien ir efektÄ«vi nodroÅ”ināt pagaidu keÅ”atmiņas slāni, kas kalpo kā pagaidu failu krātuve lietojumprogrammām, taču lietojumprogrammas nedrÄ«kst bÅ«t atkarÄ«gas no Ŕī slāņa kā patiesÄ«bas avota.

Stateful lietojumprogrammu krātuve

Lai gan vairumā gadÄ«jumu ir lietderÄ«gi saglabāt lietojumprogrammas bez statusa, tām lietojumprogrammām, kas paredzētas datu glabāŔanai, piemēram, datu bāzēm, objektu krātuvēm, atslēgu vērtÄ«bu krātuvēm, ir jābÅ«t statusam. ApskatÄ«sim, kāpēc Ŕīs lietojumprogrammas tiek izvietotas Kubernetes. Ņemsim par piemēru MinIO, taču lÄ«dzÄ«gi principi attiecas uz jebkuru citu lielu mākoņdatoÅ”anas sistēmu.

Mākoņprogrammas ir izstrādātas, lai pilnÄ«bā izmantotu konteineriem raksturÄ«gās elastÄ«bas priekÅ”rocÄ«bas. Tas nozÄ«mē, ka viņi neizdara nekādus pieņēmumus par vidi, kurā tie tiks izvietoti. Piemēram, MinIO izmanto iekŔēju dzÄ“Å”anas kodÄ“Å”anas mehānismu, lai nodroÅ”inātu sistēmu ar pietiekamu noturÄ«bu, lai tā varētu darboties pat tad, ja puse disku neizdodas. MinIO arÄ« pārvalda datu integritāti un droŔību, izmantojot patentētu servera puses jaukÅ”anu un Å”ifrÄ“Å”anu.

Šādām uz mākoņiem orientētām lietojumprogrammām vietējie pastāvÄ«gie sējumi (PV) ir visērtākie kā rezerves krātuve. Vietējais PV nodroÅ”ina iespēju saglabāt neapstrādātus datus, savukārt lietojumprogrammas, kas darbojas virs Å”iem PV, neatkarÄ«gi apkopo informāciju, lai mērogotu datus un pārvaldÄ«tu pieaugoŔās datu prasÄ«bas.

Å Ä« pieeja ir daudz vienkārŔāka un ievērojami mērogojamāka nekā uz CSI balstÄ«ti PV, kas sistēmā ievieÅ” savus datu pārvaldÄ«bas un dublÄ“Å”anas slāņus; Lieta ir tāda, ka Å”ie slāņi parasti ir pretrunā ar lietojumprogrammām, kas paredzētas statusa noteikÅ”anai.

Spēcīga virzība uz datu atsaisti no aprēķiniem

Å ajā rakstā mēs runājām par to, kā lietojumprogrammas tiek pārorientētas uz darbu bez stāvokļa saglabāŔanas vai, citiem vārdiem sakot, datu glabāŔana tiek atdalÄ«ta no skaitļoÅ”anas tajā. Noslēgumā aplÅ«kosim dažus reālus Ŕīs tendences piemērus.

Dzirkstele, ievērojama datu analÄ«zes platforma, tradicionāli ir bijusi statusa un izvietota HDFS. Tomēr, Spark pārejot uz mākoņiem orientētu pasauli, platforma arvien vairāk tiek izmantota bezvalsts, izmantojot ā€œs3aā€. Spark izmanto s3a, lai pārsÅ«tÄ«tu stāvokli uz citām sistēmām, savukārt paÅ”i Spark konteineri darbojas pilnÄ«gi bez valsts. Citi lielākie uzņēmumu dalÄ«bnieki lielo datu analÄ«tikas jomā, jo Ä«paÅ”i, Vertica, Teradata, Greenplum Viņi arÄ« pāriet uz darbu ar datu uzglabāŔanas un aprēķinu atdalÄ«Å”anu.

Līdzīgus modeļus var redzēt arī citās lielās analītiskajās platformās, tostarp Presto, Tensorflow to R, Jupyter. Pārlādējot stāvokli uz attālām mākoņu krātuves sistēmām, kļūst daudz vieglāk pārvaldīt un mērogot jūsu lietojumprogrammu. Turklāt tas atvieglo lietojumprogrammas pārnesamību uz dažādām vidēm.

Avots: www.habr.com

Pievieno komentāru