Andmete salvestamise mustrid Kuberneteses

Tere, Habr!

Tuletame meelde, et oleme välja andnud uue, äärmiselt huvitava ja kasuliku raamat Kubernetes'e mustrite kohta. Kõik algas "Mustritest" Brendan Burnsilt, ja muide, meie töö sellel alal keeb. Täna pakume teile lugeda MinIO blogi artiklit, mis lühidalt käsitleb andmemustrite hoidmise suundi ja spetsiifikat Kuberneteses.

Kubernetes on põhimõtteliselt muutnud traditsioonilisi rakenduste arendamise ja juurutamise mustreid. Nüüd võivad meeskondadel minna päevad rakenduse arendamiseks, testimiseks ja juurutamiseks – erinevates keskkondades, ja seda kõike Kubernetes klastrite piirides. Selline töö eelneva põlvkonna tehnoloogiatega võttis tavaliselt tervete nädalate, kui mitte kuude, jagu aega.

Selline kiirus on võimalik tänu Kubernetes'e pakkumisele, võrreldes eelnevate põlvkondade tehnoloogiatega – see tähendab, et Kubernetes ise tegeleb füüsiliste või virtuaalsete masinate madalama tasandi detailidega, võimaldades kasutajatel märgata teiste parameetrite seas vajalikku protsessorit, vajaliku mälumahtu ja konteinerite koopiate arvu. Kuna Kubernetes'e toetab tohutu kogukond ja selle rakendamine laieneb pidevalt, on see kaugel ees kõigist konteinerite orkestreerimise platvormidest.

Kubernetes'e kasutamise kasvu korral suureneb ka segadus andmete hoidmise mustrite osas.

Kuna kõik konkureerivad Kubernetes'e kukeldamise nimel (st andmete hoidmine), kadub andmete hoidmise arutelu siia segasesse mürasse.
Kubernetes kehastab kaasaegset rakenduste arendamise ja juurutamise mudelit, samuti nende haldamist. See kaasaegne mudel eraldab andmete hoidmise arvutustest. Et täielikult mõista sellist eraldamist Kubernetes'e kontekstis, peab mõistma ka, mis on olekuga ja staatilise säilitamisega rakendused ning kuidas andmete hoidmine sellega seondub. Just siin on S3 kasutatav REST API lähenemisviisil selged eelised võrreldes teiste lahenduste iseloomuliku POSIX/CSI lähenemisega.

Selles artiklis räägime andmete salvestamise mustritest Kuberneteses ning käsitleme eraldi arutelu rakendustest, mis töötavad ilma ja koos oleku salvestamisega, et mõista, mis nende vahel vahe on ja miks see on oluline. Edasi teksis vaatleme rakendusi ja kasutatavaid andmete salvestamise mustreid konteinerite ja Kubernetesega töötamise parimate praktikate valguses.

Oleku salvestamata konteinerid

Konteinerid on oma olemuselt kerged ja ajutised. Neid saab kergesti peatada, kustutada või teisele sõlmele rakendada – sellele kulub vaid mõned sekundid. Suures konteinerite orkestreerimise süsteemis toimuvad sellised toimingud pidevalt ning kasutajad ei märkagi selliseid muutusi. Siiski on liikuvus võimalik ainult juhul, kui konteineril ei ole mingeid sõltuvusi sõlmest, kus see asub. Selliste konteinerite kohta öeldakse, et need töötavad ilma oleku salvestamiseta.

Oleku salvestavad konteinerid

Kui konteiner salvestab andmeid kohalikult ühendatud seadmetes (või plokkseadmestikes), peab andmete salvestus, kus ta asub, koos konteineriga uuele sõlmele liikuma – juhul kui tekib tõrge. See on oluline, kuna muidu ei saa konteineris käivituv rakendus korralikult toimida, sest tal on vaja juurdepääsu andmetele, mis on salvestatud kohalikesse mäluseadmetesse. Selliste konteinerite kohta öeldakse, et need töötavad oleku salvestamisega.

Puht tehnilisest vaatenurgast on oleku salvestavaid konteinerid võimalik samuti teisele sõlmele liigutada. Tüüpiliselt saavutatakse see kaudu jaotatud failisüsteemide või plokkide võrgu andmesalvestuse kasutamisega, mis on seotud kõikide sõlmedega, kus konteinerid töötavad. Sel moel saavad konteinerid juurdepääsu püsivale andmesalvestusele ja teave salvestatakse kettale, mis asuvad kogu võrgus. Seda meetodit nimetaksin ma "oleku salvestava konteineri lähenemiseks", ja artikli ülejäänud osas nimetan seda niimoodi ühtsuse nimel.

Tüüpilise konteineripõhise lähenemise korral, kus säilitatakse riik, kinnitatakse kõik rakenduste podid ühte hajutatud failisüsteemi – saadakse omamoodi jagatud salvestus, kus on kõik rakenduste andmed. Kuigi võivad esineda mõned variatsioonid, on see kõrgetasemeline lähenemine.

Nüüd uurigem, miks konteineripõhine lähenemine riigi säilitamisega pilvekeskses maailmas on antipattern.

Pilvekesksed rakenduste projekteerimise põhimõtted

Traditsiooniliselt kasutasid rakendused andmebaase struktureeritud teabe salvestamiseks ja kohalikke kettaid või hajutatud failisüsteeme, kuhu salvestati kõik struktureerimata või isegi osaliselt struktureeritud andmed. Aja jooksul, kui struktureerimata andmete maht kasvas, mõistsid arendajad, et POSIX on liiga "rääkiv", seondub märkimisväärsete kuludega ja lõpuks häirib rakenduse tööd, kui minnakse tõeliselt suurte mastaapide juurde.

See aitas oluliselt kaasa uue andmete salvestamise standardi tekkimisele, st pilvekesksed salvestussüsteemid, mis töötavad peamiselt REST API alusel ja vabastavad rakenduse koormavast kohaliku andmesalvestuse haldamisest. Sellisel juhul töötab rakendus sisuliselt seisundita režiimis (kuna olek asub kaugandmesalves). Kaasaegsed rakendused ehitatakse juba algusest peale arvesse võttes seda tegurit. Üldiselt on iga kaasaegne rakendus, mis töötleb mingi teabe tüüpi (logid, metaandmed, blobid jne), üles ehitatud pilvekesksesse paradigmasse, kus olek viiakse spetsiaalselt selle jaoks nähtud tarkvarasüsteemi.

Konteineripõhine lähenemine riigi säilitamisega sunnib kogu selle paradigma tagasi minema aufs kanti, kust see alguse sai!

Kasutades POSIX-liideseid rakenduste andmete salvestamiseks töötavad rakendused nagu nad salvestaksid olekut, mis toob kaasa kõrvalekaldeid kõige olulisematest pilvepõhisest disaini postulaatidest, nagu võimalus varieerida rakenduse töövoogude suurusi vastavalt sisenevale koormusele, liikuda uuele sõlmele kohe, kui aktiivne sõlm ebaõnnestub, jne.

Sellele olukorrale lähemalt vaatates leiame, et andmesalvestuse valimisel puutume taas kokku dilemma «POSIX vs REST API», kuid lisaks POSIX-i probleemide süvenemisele, mis on tingitud Kubernetes'e jaotatud keskkonnadest. Eeskätt,

• POSIX on jutukas: POSIX-i semantika nõuab, et iga toiminguga seostataks metainformatsioon ja failidesse viitavad descriptor'id, mis aitavad operatsiooni olekut säilitada. See toob kaasa oluliselt suurenenud kulud, millel pole reaalselt mingit väärtust. Objektide salvestus-API, sealhulgas S3 API, on need nõudmised eemaldanud, võimaldades rakendusel toimida ja seejärel
• Võrgupiirangud: Jaotatud süsteemis eeldatakse, et võib eksisteerida mitmeid rakendusi, mis püüavad kirjutada andmeid samale kinnitatud kandjale. Seetõttu mitte ainult, et rakendused konkureerivad omavahel ribalaiuse pärast (et saata andmeid kandjale), vaid ka andmesalvestussüsteem ise konkureerib selle ribalaiuse nimel, jaotades andmeid füüsilistele ketastele. POSIX-i jutukuse tõttu kasvab võrgu väljakutsete arv mitu korda. Teisalt, S3 API tagab selge eristuse võrgu väljakutsete vahel, mis tulevad kliendilt serverisse, ja nende, mis toimuvad serveri sees.
• Turvalisus: POSIX turvamudeli eesmärk on aktiivne inimosalus: administraatorid konfigureerivad iga kasutaja või grupi jaoks konkreetsed juurdepääsutasemed. Selline paradigma on keeruline kohandada pilvepõhisesse maailma. Kaasaegsed rakendused sõltuvad turvamudelitest, mis põhinevad API-l, kus juurdepääsuõigused määratletakse poliitikate kogumina, teenusekontod eraldatakse, ajutised kasutustunnused jne.
• Haldatavus: Olemasolevate konteinerite haldamine toob kaasa teatud kulud. Räägime andmete paralleelse juurdepääsu sünkroonimisest, andmete järjepidevuse tagamisest; kõik see nõuab hoolikat kaalumist, milliseid andmete juurdepääsupatente kasutada. On vaja paigaldada, jälgida ja konfigureerida täiendavaid programme, rääkimata lisatööst arendamisel.

Konteineri andmesalvestuse liides

Konteineri andmesalvestuse liides (CSI) on suurepäraselt aidanud rakendada Kubernetes'e mahu taset, edastades selle osaliselt kolmandate osapoolte andmesalvestuse teenustele, kuid samas on see kogemata toetanud arusaama, et konteineripõhine lähenemine andmete säilitamisele on soovitatav meetod andmete salvestamiseks Kubernetes'es.

CSI on välja töötatud kui standard, mis pakub pärandrakendustele juhuslike plokk- ja failisalvestussüsteemide toe Kubernetes'es töötades. Ja nagu on näidatud käesolevas artiklis, on ainus olukord, kus konteineripõhine lähenemine andmete säilitamisele (ja CSI oma praegusel kujul) on mõistlik, siis kui rakendus ise on pärandisüsteem, kus API objekti andmesalvestuse toe lisamine on võimatu.

Oluline on mõista, et kasutades CSI-d oma praeguses vormis, st mälumahtude mountimist modernsetes rakendustes, seisame silmitsi enam-vähem samade probleemidega, mis esinesid süsteemides, kus andmesalvestus oli korraldatud POSIX stiilis.

Kvaliteetsem lähenemine

Sel juhul on oluline mõista, et enamik rakendusi ei ole oma olemuselt kohandatud töötama kas oleku salvestamise või salvestamata olekuga. Selline käitumine sõltub süsteemi üldisest arhitektuurist ja valitud valikutest projekteerimise käigus. Räägime veidi rakendustest, mis salvestavad olekut.

Põhimõtteliselt saab kõik rakenduste andmed jagada mitmeks laiapinnaliseks tüübiks:

• Logi andmed
• Ajatempli andmed
• Tehingu andmed
• Metaandmed
• Konteinerite pildid
• Blob-andmed (suured binaarobjektid)

Kõiki neid andmetüüpe toetatakse väga hästi kaasaegsetes andmesalvestusplatvormides ning on olemas mitmeid pilvepõhiseid platforme, mis on kohandatud andmete tarnimiseks igasugustes spetsiifilistes formaatides. Näiteks võivad tehingu andmed ja metaandmed asuda kaasaegses pilvepõhises andmebaasis nagu CockroachDB, YugaByte jne. Konteinerite pildid või blob-andmed võivad olla salvestatud MinIO-l põhinevas docker-rekis. Ajatempli andmed võivad olla salvestatud ajarease andmebaasis, näiteks InfluxDB jne. Siin ei hakka me igasuguste andmete ja vastavate rakenduste detaile lahkama, kuid põhimõte on vältida püsivalt salvestatud andmete hoidmist, mis põhinevad kohalikul ketaste mountimisel.

Lisaks on tihti tõhus pakkuda ajutise vahemälu taset, mis toimib rakenduste jaoks omamoodi ajutiste failide ladustamisena, kuid rakendused ei tohiks sellest tasemest sõltuda tõe allikana.

Oleku salvestava rakenduse ladustamine

Kuigi enamikul juhtudel on kasulik hoida rakendusi ilma olekuta, peavad need rakendused, mis on ette nähtud andmete salvestamiseks – näiteks andmebaasid, objektide ladustamisüsteemid, võtme-väärtuse ladustamised – salvestama oleku. Vaatame, miks need rakendused käivitatakse Kuberneteses. Näiteks toome MinIO, kuid sarnased põhimõtted kehtivad ka mistahes muude suurte pilvepõhiste andmesalvestussüsteemide kohta.

Pilvepõhised rakendused on projekteeritud maksimaalse paindlikkuse tõhusaks kasutamiseks, mis on iseloomulik konteineritele. See tähendab, et need ei eelda mingit spetsiifilist keskkonda, kus neid kasutatakse. Näiteks MinIO kasutab sisemist üleliigse kodeerimise mehhanismi (erasure coding), mis tagab süsteemi piisava vastupidavuse, et see jääks toimivaks, isegi kui pooled kettad peaksid tõrkuma. Samuti hooldab MinIO andmete terviklikkust ja turvalisust, rakendades oma serveripoolset hajutamist ja krüptimist.

Selliste pilvepõhiste rakenduste jaoks on parimaks varukoopiateks kohalikud püsivad mahud (PV). Kohalik PV võimaldab salvestada tooreid andmeid, samas kui nende PV-de peal töötavad rakendused koguvad ise teavet, mis võimaldab andmete skaleerimist ja haldamist kasvavate andmepäringute jaoks.

See lähenemine on palju lihtsam ja oluliselt paremini skaleeritav võrreldes CSI-põhiste PV-dega, mis toovad süsteemi oma andmete haldamise ja üleliigsete tasemed; probleem on selles, et need tasemed konfliktsivad tavaliselt rakendustega, mis on projekteeritud olekut säilitama.

Kindel liikumine andmete eraldamiseks arvutustest

Selles artiklis arutasime, kuidas rakendused suunavad oma töö uuele suundumusele, kus andmete salvestamine on lahutatud nende kohalsetest arvutustest. Lõpetuseks vaatame mõned reaalsed näited selle trendi kohta.

Spark, kuulus andmeanalüüsi platvorm, on traditsiooniliselt kasutatud olekut säilitades ja kasutades HDFS-i failisüsteemi. Kuid Spark on üha enam liikumas pilvepõhisesse maailma, kus seda platvormi kasutatakse järjest rohkem olekuta, kasutades `s3a`. Spark rakendab s3a, et edastada olekut teistele süsteemidele, samas kui Spark konteinerid töötavad täielikult ilma olekuta. Teised suured ettevõtted suurandmete analüüsivaldkonnas, eelkõige Vertica, Teradata, Greenplum liiguvad samuti andmete salvestamise ja arvutuste eraldamise suunas.

Sarnased mustrid on samuti jälgitavad teistel suurtel analüüsiplatvormidel, sealhulgas Presto, Tensorflow to R, Jupyter. Kui eksportida olek kaugseadmestatud andmetesse, on teie rakenduse haldamine ja selle skaleerimine palju lihtsam. Lisaks sellele suurendab see rakenduse portatiivsust erinevates keskkondades.

Allikas: habr.com