Čau Habr!
Atgādinām, ka esam publicējuši vēl vienu ārkārtīgi interesantu un noderīgu rakstu par Kubernetes modeļiem. Viss sākās ar ""Brendans Bērnss, un, starp citu, mums ir darbs šajā segmentā Šodien aicinām izlasīt rakstu no MinIO emuāra, kurā īsi aprakstītas datu glabāšanas modeļu tendences un specifika Kubernetes vidē.
Kubernetes ir fundamentāli mainījis tradicionālos lietojumprogrammu izstrādes un ieviešanas modeļus. Komandas tagad var izstrādāt, testēt un ieviest lietojumprogrammu tikai dažu dienu laikā — vairākās vidēs, visas Kubernetes klasteru ietvaros. Šāda veida darbs ar iepriekšējām tehnoloģiju paaudzēm parasti aizņēma nedēļas, ja ne mēnešus.
Šo paātrinājumu nodrošina Kubernetes nodrošinātā abstrakcija — tas ir, fakts, ka Kubernetes pats apstrādā fizisko vai virtuālo mašīnu zemākā līmeņa informāciju, ļaujot lietotājiem norādīt, cita starpā, vēlamo procesoru, nepieciešamo atmiņu un konteineru instanču skaitu. Ar savu milzīgo kopienu, kas to atbalsta, un tās nepārtraukti augošo pieņemšanu, Kubernetes ir nepārprotams līderis starp konteineru orķestrēšanas platformām.
Pieaugot Kubernetes ieviešanai, pieaug arī neskaidrības par tā glabāšanas modeļiem..
Tā kā visi sacenšas par daļu no Kubernetes pīrāga (tas ir, par datu glabāšanu), tad, runājot par datu glabāšanu, signālu apslāpē daudz trokšņa.
Kubernetes iemieso mūsdienīgu lietojumprogrammu izstrādes, izvietošanas un pārvaldības modeli. Šis modernais modelis atdala krātuvi no skaitļošanas. Lai pilnībā izprastu šo atdalīšanu Kubernetes kontekstā, ir jāsaprot arī stāvokļa un bezstāvokļa lietojumprogrammu jēdzieni un tas, kā krātuve tajos iederas. Šeit S3 REST API pieeja piedāvā skaidras priekšrocības salīdzinājumā ar POSIX/CSI pieeju, kas raksturīga citiem risinājumiem.
Šajā rakstā mēs apspriedīsim datu glabāšanas modeļus Kubernetes vidē un īpaši pievērsīsimies diskusijai starp lietojumprogrammām ar statusu un bez statusa, lai pilnībā izprastu atšķirības un to nozīmi. Pārējā raksta daļā tiks aplūkotas lietojumprogrammas un to glabāšanas modeļi, ņemot vērā konteineru un Kubernetes labāko praksi.
Bezvalstnieku konteineri
Konteineri pēc savas būtības ir viegli un īslaicīgi. Tos var viegli apturēt, dzēst vai izvietot citā mezglā — tas viss dažu sekunžu laikā. Lielā konteineru orķestrācijas sistēmā šādas darbības notiek nepārtraukti, un lietotāji nezina par izmaiņām. Tomēr pārvietošana ir iespējama tikai tad, ja konteineram nav atkarību no mezgla, kurā tas atrodas. Šādi konteineri tiek saukti par darbojošiem. bezvalstnieks.
Stateful konteineri
Ja konteiners glabā datus lokāli pievienotās ierīcēs (vai bloka ierīcē), kļūmes gadījumā datu krātuve, kurā tā atrodas, ir jāpārvieto uz jaunu mezglu kopā ar pašu konteineru. Tas ir svarīgi, jo pretējā gadījumā konteinerā darbojošā lietojumprogramma nevarēs pareizi darboties, jo tai ir jāpiekļūst lokālajā krātuvē glabātajiem datiem. Šādi konteineri tiek saukti par darbojošiem. stāvoklis.
No tīri tehniska viedokļa, stāvokļa konteinerus var pārvietot arī uz dažādiem mezgliem. To parasti panāk, izmantojot izkliedētas failu sistēmas vai tīklam pievienotu bloku krātuvi, kas pievienota visiem mezgliem, kuros darbojas konteineri. Tādā veidā konteineriem ir piekļuve pastāvīgiem krātuves sējumiem, un informācija tiek glabāta diskos, kas atrodas visā tīklā. Es šo metodi saukšu par "stāvokļa konteinera pieeja", un pārējā rakstā es to atsaukšos kā tādu konsekvences labad.
Tipiskā stāvokļa konteinera pieejā visi lietojumprogrammu podi ir pievienoti vienai izkliedētai failu sistēmai, izveidojot sava veida koplietotu krātuvi, kurā atrodas visi lietojumprogrammu dati. Lai gan ir iespējamas dažas variācijas, šī ir augsta līmeņa pieeja.
Tagad aplūkosim, kāpēc stāvokļa konteinera pieeja ir pretējs modelis mākoņdatošanas pasaulē.
Mākonī orientētu lietojumprogrammu dizains
Tradicionāli lietojumprogrammas izmantoja datubāzes strukturētai glabāšanai un lokālos diskus vai izkliedētas failu sistēmas, lai uzglabātu visus nestrukturētos vai pat daļēji strukturētos datus. Pieaugot nestrukturēto datu apjomam, izstrādātāji saprata, ka POSIX ir pārāk detalizēts, rada ievērojamas papildu izmaksas un galu galā kavē lietojumprogrammu veiktspēju patiesi lielā mērogā.
Tas lielā mērā ir veicinājis jauna datu glabāšanas standarta parādīšanos: mākoņdatošanas krātuvi, kas galvenokārt darbojas, izmantojot REST API, un atbrīvo lietojumprogrammas no lokālās datu glabāšanas uzturēšanas pienākuma. Šajā gadījumā lietojumprogramma faktiski pārslēdzas uz bezstāvokļa režīmu (jo stāvoklis tiek glabāts attālināti). Mūsdienu lietojumprogrammas tiek veidotas no nulles, ņemot vērā šo faktoru. Parasti jebkura mūsdienu lietojumprogramma, kas apstrādā jebkāda veida datus (žurnālus, metadatus, blobus utt.), tiek veidota, izmantojot mākoņdatošanas paradigmu, kur stāvoklis tiek migrēts uz īpašu programmatūras sistēmu.
Stateful konteinera pieeja piespiež visu šo paradigmu atgriezties tur, kur tā sākās!
Izmantojot POSIX saskarnes datu glabāšanai, lietojumprogrammas uzvedas tā, it kā tās būtu stāvokļpastāvīgas, un tādējādi atsakās no svarīgākajiem mākoņdatošanas dizaina principiem, piemēram, spējas mainīt lietojumprogrammas darba pavedienu lielumu atkarībā no ienākošās slodzes, pāriet uz jaunu mezglu, tiklīdz pašreizējais mezgls neizdodas, utt.
Aplūkojot šo situāciju rūpīgāk, mēs atklājam, ka, izvēloties datu krātuvi, mēs atkal un atkal saskaramies ar dilemmu "POSIX pret REST API", BET ar papildu POSIX problēmu saasināšanos Kubernetes vides izkliedētā rakstura dēļ. Jo īpaši,
- POSIX ir pļāpīgsPOSIX semantika prasa, lai katra operācija būtu saistīta ar metadatiem un failu deskriptoriem, kas palīdz uzturēt operācijas stāvokli. Tas rada ievērojamas papildu izmaksas, kurām nav reālas vērtības. Objektu glabāšanas API, īpaši S3 API, ir novērsuši šīs prasības, ļaujot lietojumprogrammai izpildīt izsaukumu un pēc tam to "aizmirst". Krātuves sistēmas atbilde norāda, vai darbība bija veiksmīga vai nē. Ja tā neizdodas, lietojumprogramma var mēģināt vēlreiz.
- Tīkla ierobežojumiIzkliedētā sistēmā tas nozīmē, ka var būt vairākas lietojumprogrammas, kas mēģina ierakstīt datus vienā un tajā pašā pievienotajā atmiņas ierīcē. Tāpēc ne tikai lietojumprogrammas konkurēs savā starpā par datu pārsūtīšanas joslas platumu (lai nosūtītu datus uz atmiņas ierīci), bet arī pati atmiņas sistēma konkurēs par šo joslas platumu, sadalot datus pa fiziskajiem diskiem. POSIX daudzpusīgās informācijas dēļ tīkla izsaukumu skaits palielinās vairākkārt. No otras puses, S3 API nodrošina skaidru atšķirību starp tīkla izsaukumiem, kas nāk no klienta uz serveri, un tiem, kas notiek serverī.
- DrošībaPOSIX drošības modelis balstās uz aktīvu cilvēka iejaukšanos: administratori konfigurē konkrētus piekļuves līmeņus katram lietotājam vai grupai. Šo paradigmu ir grūti pielāgot mākoņdatošanas pasaulei. Mūsdienu lietojumprogrammas balstās uz API balstītiem drošības modeļiem, kur piekļuves tiesības ir definētas kā politiku, pakalpojumu kontu, pagaidu akreditācijas datu un tā tālāk kopums.
- VadāmībaStateful konteineriem ir noteiktas pārvaldības izmaksas. Vienlaicīgas datu piekļuves sinhronizēšana un datu konsekvences nodrošināšana prasa rūpīgu datu piekļuves modeļu apsvēršanu. Ir jāinstalē, jāpārvalda un jākonfigurē papildu programmatūra, nemaz nerunājot par papildu izstrādes piepūli.
Datu glabāšanas konteinera saskarne
Lai gan konteineru glabāšanas saskarne (CSI) ir bijusi liels palīgs Kubernetes apjoma slāņa ieviešanā, daļēji uzticot to trešo pušu datu glabāšanas piegādātājiem, tā ir arī netīši veicinājusi uzskatu, ka stāvokļa konteineru pieeja ir ieteicamā datu glabāšanas metode Kubernetes.
CSI tika izstrādāts kā standarts patvaļīgu bloku un failu glabāšanas sistēmu nodrošināšanai mantotajām lietojumprogrammām, kas darbojas Kubernetes platformā. Un, kā parādīts šajā rakstā, vienīgā situācija, kurā ir jēga izmantot stāvokļa konteinera pieeju (un CSI tās pašreizējā formā), ir tad, ja pati lietojumprogramma ir mantota sistēma, kas nevar atbalstīt objektu glabāšanas API.
Ir svarīgi saprast, ka, lietojot CSI tās pašreizējā formā, tas ir, palielinot 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 ir organizēta POSIX stilā.
Kvalitatīvāka pieeja
Šajā gadījumā ir svarīgi saprast, ka lielākā daļa lietojumprogrammu nav paredzētas darbībai ne ar stāvokli, ne bez stāvokļa. Šī 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 lietojumprogrammām ar stāvokli.
Principā visus lietojumprogrammu datus var iedalīt vairākos plašos veidos:
- Žurnāla dati
- Laika zīmoga dati
- Darījumu dati
- Metadati
- Konteinera attēli
- Blobu dati (bināri lieli objekti)
Visus šos datu tipus ļoti labi atbalsta modernas datu glabāšanas platformas, un ir vairākas mākoņdatošanas platformas, kas paredzētas datu piegādei katrā no šiem konkrētajiem formātiem. Piemēram, darījumu dati un metadati var atrasties modernā mākoņdatošanas datubāzē, piemēram, CockroachDB, YugaByte un citās. Konteineru attēlus vai blobu datus var glabāt Docker reģistrā, pamatojoties uz MinIO. Laika zīmoga datus var glabāt laika rindu datubāzē, piemēram, InfluxDB un citās. Šeit mēs neiedziļināsimies katra datu tipa un atbilstošo lietojumprogrammu detaļās, taču vispārējā ideja ir izvairīties no pastāvīgas datu glabāšanas, kuras pamatā ir lokālo disku pievienojumi.
Turklāt bieži vien ir efektīvi nodrošināt pagaidu kešatmiņas slāni, kas kalpo kā sava veida pagaidu failu glabātuve lietojumprogrammām, taču lietojumprogrammām nevajadzētu paļauties uz šo slāni kā uz patiesības avotu.
State-Up lietojumprogrammu krātuve
Lai gan vairumā gadījumu ir izdevīgi palaist lietojumprogrammas bez stāvokļa, lietojumprogrammām, kas paredzētas datu glabāšanai, piemēram, datubāzēm, objektu glabāšanai un atslēgu un vērtību glabātuvēm, jābūt ar stāvokli. Izpētīsim, kāpēc šīs lietojumprogrammas tiek izvietotas Kubernetes. Kā piemēru izmantosim MinIO, taču līdzīgi principi attiecas uz jebkuru citu lielu mākoņdatošanas krātuves sistēmu.
Mākonī bāzētas lietojumprogrammas ir izstrādātas, lai izmantotu konteineru raksturīgo elastību. Tas nozīmē, ka tās neizdara nekādus pieņēmumus par vidi, kurā tās tiks izvietotas. Piemēram, MinIO izmanto iekšēju dzēšanas kodēšanas mehānismu, kas nodrošina sistēmu ar pietiekamu noturību, lai tā varētu darboties pat tad, ja puse no tās diskiem sabojājas. MinIO arī pārvalda datu integritāti un drošību, izmantojot savu servera puses hešēšanu un šifrēšanu.
Šādām mākoņdatošanas lietojumprogrammām ērtākā dublējumu krātuve ir lokālie pastāvīgie sējumi (PV). Lokālais PV nodrošina neapstrādātu datu glabāšanu, savukārt lietojumprogrammas, kas darbojas uz šiem PV, neatkarīgi vāc informāciju, lai mērogotu datus un pārvaldītu pieaugošo datu pieprasījumu.
Šī pieeja ir daudz vienkāršāka un mērogojamāka nekā uz CSI balstīti PV, kas sistēmā ievieš savus datu pārvaldības un redundances slāņus; problēma ir tā, ka šie slāņi parasti konfliktē ar stāvokli balstītām lietojumprogrammām.
Pārliecināts solis ceļā uz datu atdalīšanu no aprēķiniem
Šajā rakstā mēs apspriedām, kā lietojumprogrammas pāriet uz darbību bez statusa jeb, citiem vārdiem sakot, datu glabāšanas atdalīšanu no skaitļošanas. Noslēgumā aplūkosim dažus reālus šīs tendences piemērus.
Spark, atzīta datu analīzes platforma, tradicionāli ir bijusi ar stāvokli balstīta un izvietota HDFS. Tomēr, Spark virzoties uz mākoņpakalpojumu pasauli, tā arvien vairāk tiek izmantota bez stāvokļa, izmantojot s3a. Spark izmanto s3a, lai paziņotu stāvokli citām sistēmām, savukārt paši Spark konteineri ir pilnīgi bez stāvokļa. Citi nozīmīgi uzņēmumu dalībnieki lielo datu analīzes jomā, jo īpaši , , Viņi arī virzās uz darbu pie datu glabāšanas un aprēķinu atdalīšanas.
Līdzīgus modeļus var novērot arī citās nozīmīgās analītikas platformās, tostarp Presto, Tensorflow to R un Jupyter. Pārnesot statusa pārvaldību uz attālām mākoņkrātuves sistēmām, lietojumprogrammas pārvaldība un mērogošana kļūst daudz vienkāršāka. Tas arī atvieglo lietojumprogrammu pārnesamību dažādās vidēs.
Avots: www.habr.com
