Pozdravljeni, Habr!
Spominjamo vas, da smo objavili še en izjemno zanimiv in uporaben članek o vzorcih Kubernetes. Vse se je začelo z ""Brendan Burns, in mimogrede, v tem segmentu imamo delo." Danes vas vabimo, da preberete članek z bloga MinIO, ki na kratko opisuje trende in posebnosti vzorcev shranjevanja podatkov v Kubernetes.
Kubernetes je temeljito spremenil tradicionalne vzorce razvoja in uvajanja aplikacij. Ekipe lahko zdaj razvijejo, preizkusijo in uvedejo aplikacijo v samo nekaj dneh – v več okoljih, vse znotraj gruč Kubernetes. Ta vrsta dela je s prejšnjimi generacijami tehnologij običajno trajala tedne, če ne mesece.
To pospešitev omogoča abstrakcija, ki jo zagotavlja Kubernetes – torej dejstvo, da Kubernetes sam obravnava podrobnosti na nizki ravni fizičnih ali virtualnih strojev, kar uporabnikom omogoča, da med drugim določijo želeni procesor, potreben pomnilnik in število primerkov vsebnikov. Z ogromno skupnostjo, ki ga podpira, in nenehno naraščajočo uporabo je Kubernetes daleč vodilni med platformami za orkestracijo vsebnikov.
Z naraščajočo uporabo Kubernetes narašča tudi zmeda glede njegovih vzorcev shranjevanja..
Ker se vsi potegujejo za kos Kubernetesove pogače (torej za shranjevanje podatkov), pri shranjevanju podatkov signal preglasi veliko šuma.
Kubernetes uteleša sodoben model za razvoj, uvajanje in upravljanje aplikacij. Ta sodoben model ločuje shranjevanje od računalništva. Da bi v celoti razumeli to ločevanje v kontekstu Kubernetesa, moramo razumeti tudi koncepta aplikacij s stanjem in aplikacij brez stanja ter kako se shranjevanje vanje vklaplja. Tukaj pristop REST API podjetja S3 ponuja jasne prednosti pred pristopom POSIX/CSI, značilnim za druge rešitve.
V tem članku bomo razpravljali o vzorcih shranjevanja podatkov v Kubernetes in se posebej posvetili razpravi med aplikacijami s poudarkom na stanju in aplikacijami brez poudarka na stanju, da bi v celoti razumeli razlike in zakaj so pomembne. Preostanek članka bo preučil aplikacije in njihove vzorce shranjevanja glede na najboljše prakse vsebnikov in Kubernetes.
Zabojniki brez stanja
Kontejnerji so sami po sebi lahki in kratkotrajni. Z lahkoto jih je mogoče ustaviti, izbrisati ali namestiti na drugo vozlišče – vse v nekaj sekundah. V velikem sistemu orkestracije kontejnerjev se takšne operacije izvajajo neprekinjeno in uporabniki se sprememb ne zavedajo. Vendar pa je premestitev mogoča le, če kontejner nima odvisnosti od vozlišča, na katerem se nahaja. Za takšne kontejnerje pravimo, da se izvajajo. brez državljanstva.
Vsebniki z možnostjo ohranjanja stanja
Če vsebnik shranjuje podatke na lokalno priključenih napravah (ali na blokovni napravi), je treba v primeru okvare shrambo podatkov, na kateri se nahaja, skupaj s samim vsebnikom premakniti na novo vozlišče. To je pomembno, ker sicer aplikacija, ki se izvaja v vsebniku, ne bo mogla pravilno delovati, saj mora dostopati do podatkov, shranjenih v lokalnem pomnilniku. Za take vsebnike pravimo, da se izvajajo. stanje.
S čisto tehničnega vidika je mogoče vsebnike s stanjem premikati tudi na različna vozlišča. To se običajno doseže z uporabo porazdeljenih datotečnih sistemov ali omrežno povezanega blokovnega shranjevanja, ki je povezano z vsemi vozlišči, na katerih se izvajajo vsebniki. Na ta način imajo vsebniki dostop do trajnih shranjevalnih nosilcev, informacije pa so shranjene na diskih, ki se nahajajo v omrežju. To metodo bom poimenoval "pristop k zabojniku s stalnim delovanjem«, in v preostalem delu članka ga bom zaradi doslednosti tako tudi navajal.
Pri tipičnem pristopu s stočnimi vsebniki so vsi aplikacijski podomrežji priključeni na en sam porazdeljen datotečni sistem, kar ustvarja nekakšno skupno shrambo, kjer se nahajajo vsi podatki aplikacije. Čeprav so možne nekatere različice, gre za pristop na visoki ravni.
Zdaj pa si poglejmo, zakaj je pristop z uporabo vsebnikov s spremljanjem stanja anti-vzorec v svetu, ki je izvorno v oblaku.
Zasnova aplikacij, osredotočenih na oblak
Tradicionalno so aplikacije uporabljale podatkovne baze za strukturirano shranjevanje in lokalne diske ali porazdeljene datotečne sisteme za shranjevanje vseh nestrukturiranih ali celo delno strukturiranih podatkov. Ko se je količina nestrukturiranih podatkov povečevala, so razvijalci spoznali, da je POSIX preveč obsežen, da povzroča znatne režijske stroške in na koncu ovira delovanje aplikacij v resnično velikem obsegu.
Prav to je v veliki meri prispevalo k nastanku novega standarda shranjevanja podatkov: shranjevanja v oblaku, ki deluje predvsem na REST API-ju in aplikacijam odvzame breme vzdrževanja lokalnega shranjevanja podatkov. V tem primeru aplikacija dejansko preklopi v način brez stanja (saj se stanje shranjuje na daljavo). Sodobne aplikacije so zgrajene od začetka do konca s tem dejavnikom v mislih. Praviloma je vsaka sodobna aplikacija, ki obdeluje kakršne koli podatke (dnevnike, metapodatke, blobove itd.), zgrajena z uporabo paradigme shranjevanja v oblaku, kjer se stanje prenese v namensko programsko opremo.
Pristop s prepoznavanjem stanja v vsebniku sili celotno paradigmo nazaj na začetek!
Z uporabo vmesnikov POSIX za shranjevanje podatkov se aplikacije obnašajo, kot da bi bile stateful, in s tem opuščajo najpomembnejša načela zasnove v oblaku, kot je možnost spreminjanja velikosti delovnih niti aplikacije glede na dohodno obremenitev, premik na novo vozlišče takoj, ko trenutno vozlišče odpove, in tako naprej.
Če to situacijo pogledamo natančneje, ugotovimo, da se pri izbiri shrambe podatkov vedno znova soočamo z dilemo "POSIX proti REST API", VENDAR z dodatnim poslabšanjem težav POSIX zaradi porazdeljene narave okolij Kubernetes. Zlasti,
- POSIX je klepetavSemantika POSIX zahteva, da je vsaka operacija povezana z metapodatki in deskriptorji datotek, ki pomagajo vzdrževati stanje operacije. To uvaja znatne dodatne stroške, ki nimajo dejanske vrednosti. API-ji za shranjevanje objektov, zlasti API S3, so te zahteve odpravili in aplikaciji omogočili, da se izvede in nato "pozabi" na klic. Odgovor sistema za shranjevanje nakazuje, ali je bilo dejanje uspešno ali ne. Če ni uspešno, lahko aplikacija poskusi znova.
- Omejitve omrežjaV porazdeljenem sistemu se implicira, da lahko več aplikacij poskuša zapisovati podatke na isto priključeno pomnilniško napravo. Zato se aplikacije ne bodo med seboj potegovale le za pasovno širino prenosa podatkov (za pošiljanje podatkov na pomnilniško napravo), temveč se bo za to pasovno širino potegoval tudi sam sistem za shranjevanje z distribucijo podatkov po fizičnih diskih. Zaradi podrobnosti POSIX-a se število omrežnih klicev večkrat poveča. Po drugi strani pa S3 API zagotavlja jasno razlikovanje med omrežnimi klici, ki prihajajo od odjemalca do strežnika, in tistimi, ki se izvajajo znotraj strežnika.
- varnostVarnostni model POSIX se zanaša na aktivno človeško posredovanje: skrbniki konfigurirajo določene ravni dostopa za vsakega uporabnika ali skupino. To paradigmo je težko prilagoditi svetu, ki temelji na oblaku. Sodobne aplikacije se zanašajo na varnostne modele, ki temeljijo na API-jih, kjer so pravice dostopa opredeljene kot niz pravilnikov, računov storitev, začasnih poverilnic itd.
- UpravljivostVsebniki z upoštevanjem stanja imajo določene stroške upravljanja. Sinhronizacija sočasnega dostopa do podatkov in zagotavljanje doslednosti podatkov zahtevata skrbno preučitev vzorcev dostopa do podatkov. Namestiti, upravljati in konfigurirati je treba dodatno programsko opremo, da ne omenjamo dodatnega razvojnega napora.
Vmesnik zabojnika za shranjevanje podatkov
Čeprav je bil vmesnik za shranjevanje kontejnerjev (CSI) v veliko pomoč pri uvajanju plasti volumna Kubernetes, deloma z zunanjim izvajanjem pri zunanjih ponudnikih shranjevanja podatkov, je nenamerno prispeval tudi k prepričanju, da je pristop shranjevanja podatkov s stanjem priporočena metoda shranjevanja podatkov v Kubernetes.
CSI je bil razvit kot standard za zagotavljanje poljubnih sistemov za shranjevanje blokov in datotek za starejše aplikacije, ki se izvajajo v okolju Kubernetes. In kot je prikazano v tem članku, je edina situacija, v kateri je pristop s stočnim vsebnikom (in CSI v svoji trenutni obliki) smiseln, ko je aplikacija sama starejši sistem, ki ne more podpirati API-jev za shranjevanje objektov.
Pomembno je razumeti, da bomo pri uporabi CSI v njegovi trenutni obliki, torej pri nameščanju nosilcev podatkov pri delu s sodobnimi aplikacijami, naleteli na približno enake težave, kot so se pojavile v sistemih, kjer je shranjevanje podatkov organizirano v slogu POSIX.
Bolj kvalitativni pristop
V tem primeru je pomembno razumeti, da večina aplikacij ni zasnovanih za delovanje s spremljanjem ali brez spremljanja stanja. To vedenje je odvisno od celotne arhitekture sistema in specifičnih oblikovalskih odločitev. Pogovorimo se malo o aplikacijah s spremljanjem stanja.
Načeloma lahko vse podatke o aplikacijah razdelimo na več širših tipov:
- Podatki dnevnika
- Podatki časovnega žiga
- Podatki o transakcijah
- Metapodatki
- Slike kontejnerjev
- Blob podatki (veliki binarni objekti)
Vse te vrste podatkov zelo dobro podpirajo sodobne platforme za shranjevanje podatkov, obstaja pa več platform, ki so zasnovane za zagotavljanje podatkov v vsaki od teh specifičnih oblik. Podatki o transakcijah in metapodatki se lahko na primer nahajajo v sodobni podatkovni zbirki, ki je izvorna v oblaku, kot so CockroachDB, YugaByte in druge. Slike vsebnikov ali podatki blobov se lahko shranijo v register Docker, ki temelji na MinIO. Podatki časovnih žigov se lahko shranijo v podatkovno zbirko časovnih vrst, kot je InfluxDB in druge. Tukaj se ne bomo spuščali v podrobnosti posameznih vrst podatkov in ustreznih aplikacij, vendar je splošna ideja, da se izognemo trajnemu shranjevanju podatkov na podlagi lokalnih priklopov diskov.
Poleg tega je pogosto učinkovito zagotoviti začasno plast predpomnjenja, ki služi kot nekakšno začasno shranjevanje datotek za aplikacije, vendar aplikacije ne bi smele biti odvisne od te plasti kot vira resnice.
Shranjevanje za aplikacije s spremljanjem stanja
Čeprav je v večini primerov koristno izvajati aplikacije brez ohranjanja stanja, bi morale biti aplikacije, namenjene shranjevanju podatkov – kot so baze podatkov, shranjevanje objektov in shrambe ključ-vrednost – podvržene ohranjanju stanja. Poglejmo, zakaj so te aplikacije nameščene v Kubernetes. Kot primer bomo uporabili MinIO, vendar podobna načela veljajo za kateri koli drug velik sistem za shranjevanje v oblaku.
Aplikacije, ki so zasnovane v oblaku, so zasnovane tako, da izkoriščajo inherentno fleksibilnost vsebnikov. To pomeni, da ne predvidevajo okolja, v katerem bodo nameščene. MinIO na primer uporablja notranji mehanizem kodiranja za brisanje, ki sistemu zagotavlja zadostno odpornost, da ostane delujoč, tudi če polovica diskov odpove. MinIO upravlja tudi integriteto in varnost podatkov z lastnim zgoščevanjem in šifriranjem na strani strežnika.
Za takšne aplikacije, ki so izvorno v oblaku, so lokalni trajni nosilci podatkov (PV) najprimernejše shranjevanje varnostnih kopij. Lokalni PV zagotavlja shranjevanje surovih podatkov, medtem ko aplikacije, ki se izvajajo na teh PV-jih, neodvisno zbirajo informacije za skaliranje podatkov in upravljanje naraščajočih potreb po podatkih.
Ta pristop je veliko enostavnejši in se bistveno bolje skalira kot fotovoltaični sistemi, ki temeljijo na CSI in v sistem uvajajo lastne plasti upravljanja podatkov in redundance; težava je v tem, da te plasti običajno nasprotujejo aplikacijam, ki ohranjajo stanje.
Samozavesten korak k ločevanju podatkov od računanja
V tem članku smo razpravljali o tem, kako se aplikacije preusmerjajo k delovanju brez ohranjanja stanja oziroma, z drugimi besedami, k ločevanju shranjevanja podatkov od računanja. Za zaključek si bomo ogledali nekaj primerov tega trenda iz resničnega sveta.
Spark, priznana platforma za analizo podatkov, je tradicionalno uporabljala sisteme za analizo podatkov z ohranjanjem stanja in bila nameščena na sistemih HDFS. Vendar pa se s prehodom na oblačno tehnologijo vse pogosteje uporablja brez ohranjanja stanja z uporabo protokola s3a. Spark uporablja protokol s3a za sporočanje stanja drugim sistemom, medtem ko so sami vsebniki Spark popolnoma brez ohranjanja stanja. Drugi večji akterji v podjetjih na področju analitike velikih podatkov, zlasti , , Prav tako se premikajo k delu z ločitvijo shranjevanja podatkov in izračunov.
Podobne vzorce lahko opazimo tudi pri drugih večjih analitičnih platformah, vključno s Presto, Tensorflow to R in Jupyter. Z razbremenitvijo stanja na oddaljene sisteme za shranjevanje v oblaku postane upravljanje in skaliranje aplikacije veliko lažje. To olajša tudi prenosljivost aplikacij v različnih okoljih.
Vir: www.habr.com
