Tere, Habr!
Tuletame meelde, et oleme avaldanud veel ühe äärmiselt huvitava ja kasuliku Kubernetes'e mustrite kohta. Kõik sai alguse "" Brendan Burnsilt ja tegelikult on meie töö selles valdkonnas . Täna pakume teile lugeda MinIO blogi artiklit, kus lühiülevaates kajastatakse andmete hoidmise mustrite trende ja spetsiifikat Kubernetes'es.
Kubernetes on fundamentaalselt muutnud traditsioonilisi rakenduste arendamise ja juurutamise mustreid. Nüüd võib meeskonnal kuluda vaid paar päeva rakenduse arendamiseks, testimiseks ja juurutamiseks - erinevates keskkondades, ja kõik see Kubernetes'e klastrites. Selline töö varasemate põlvkondade tehnoloogiatega võttis tavaliselt terveid nädalad, kui mitte kuid.
See kiirus on võimalik tänu Kubernetes'i poolt pakutud abstraktsioonile — see tähendab, et Kubernetes ise tegeleb füüsiliste või virtuaalmasinate madalama taseme detailidega, võimaldades kasutajatel kuulutada teiste parameetrite seas vajaliku protsessori, vajaliku mälu hulga ja konteinerite eksemplaride arvu. Kuna Kubernetes'e toetamine on suurte kogukondade tegevuse alla kuuluv ning selle rakendamise ulatus pidevalt laieneb, on ta kaugel kõigist konteinerite orkestreerimise platvormidest.
Kuna Kubernetes'e kasutamine laieneb, suureneb ka segadus andmete salvestamise mustrite osas, mida selle sõnumis kasutatakse..
Kuna Kubernetes'e (st andmesalvestuse) jaoks käib üldine konkurents, siis kui jutt käib andmete salvestamisest, kaob signaal tugevas kõrvalhelis.
Kubernetes esindab kaasaegset rakenduste arendamise ja juurutamise ning haldamise mudelit. See kaasaegne mudel eraldab andmete salvestamise arvutustest. Selle eraldamise täielikuks mõistmiseks kontekstis Kubernetes on samuti oluline mõista, mis on olekuga ja olekuta rakendused, ning kuidas need sobituvad andmete salvestamisega. Just siin omab REST API lähenemine, mida rakendab S3, selgemaid eeliseid võrreldes POSIX/CSI lähenemisega, mis on iseloomulik teistele lahendustele.
Selles artiklis arutame Kuberneteses andmete salvestamise mustreid ja käsitleme eraldi vaidlust olekuga ja olekuta rakenduste vahel, et paremini mõista nende vahe ja miks see on oluline. Artikli edaspidises osas vaadatakse rakendusi ning nende juures kasutatavaid andmete salvestamise mustreid konteinerite ja Kubernetesega parimate praktikate valguses.
Olekuta konteinerid
Konteinerid on oma olemuselt kerged ja efemeersed. Neid saab hõlpsasti peatada, kustutada või mõnel teisel sõlmel käivitada – kõik need toimingud võtavad aega vaid sekundeid. Suures konteinerite orchestration süsteemis toimuvad sellised operatsioonid pidevalt ning kasutajad ei pruugi neid muutusi isegi märkama. Kuid liikumised on võimalikud ainult siis, kui konteineril ei ole mingeid sõltuvusi sõlme, millel ta asub. Selliseid konteinereid kirjeldavad nad kui töötavaid ilma olekuta.
Olekuhoidvad konteinerid
Kui konteiner salvestab andmeid kohalikult ühendatud seadmetesse (või plokkseadmestikusse), tuleb andmesalv, millel ta asub, liigutada uuele sõlmele koos konteineriga – tõrke korral. See on oluline, kuna vastasel juhul ei suuda konteineris töötav rakendus korralikult funktsioneerida, kuna tal on vajalik juurdepääs kohalikele salvestusseadmetele salvestatud andmetele. Selliseid konteinereid kirjeldavad nad kui töötavaid olekuhoidvatena.
Puhtalt tehnilisest vaatepunktist vaadatuna on olekuga konteinerid samuti võimalik teisele sõlmele liikuda. Seda tavaliselt toetavad jaotatud failisüsteemid või plokipõhised võrgukettavarud, mis on ühendatud kõikide sõlmedega, kus konteinerid töötavad. Nii saavad konteinerid juurde pääseda mahutitele püsiva andmete salvestamise jaoks ning teave salvestatakse kettale, mis asub kogu võrgus. Seda meetodit nimetaksin "olekuga konteinerite lähenemiseks" ja nimetaksin seda ka edaspidi sama väljendi tõttu.
Tüüpilise olekuga konteinerite lähenemise puhul on kõik rakenduste podid kinnitatud ühele jaotatud failisüsteemile – see loob mingisuguse jagatud salvestuslahenduse, kus kõik rakenduste andmed paiknevad. Kuigi on võimalikud mõned variatsioonid, on see kõrgetasemeline lähenemine.
Nüüd vaatame aga, miks olekuga konteinerite lähenemine pilvepõhisest maailmas on antimuster.
Pilvepõhine rakenduste projekteerimine
Traditsiooniliselt kasutasid rakendused andmete struktureeritud salvestamiseks andmebaase ja kohalikke kettaid või jagatud failisüsteeme, kuhu suunati kõik mittestruktureeritud või isegi osaliselt struktureeritud andmed. Kuid kui mittestruktureeritud andmete mahud kasvasid, tunnustasid arendajad, et POSIX on liiga "lobus" ning kaasneb märkimisväärsete kuludega, takistades lõpuks rakenduse töö efektiivselt tõeliselt suurtes mahtudes.
See peamiselt aitas kaasa uue andmesalvestuse standardsuse loomisele, nimelt pilvepõhiste salvestuste süsteemide ilmumisele, mis töötavad peamiselt REST API põhjal ning vabastavad rakendused kohalikest andmesalvestussüsteemidest. Sellisel juhul töötab rakendus tõeliselt olekuta, kuna olek asub eemal olevas salvestusruumis. Tänapäeva rakendused ehitatakse juba nullist arvesse võttes seda tegurit. Üldiselt on iga kaasaegne rakendus, mis töötleb erinevat tüüpi andmeid (logid, metainfo, blobid jne), üles ehitatud pilvepõhise paradigma kohaselt, kus olek kolitakse spetsiaalselt tema hoidmiseks mõeldud tarkvarasüsteemi.
Konteineripõhine oleku säilitamine toob kõik need paradigmad tagasi täpselt sinna, kus nad algasid!
Kui POSIX-liideseid andmete säilitamiseks kasutatakse, käituvad rakendused samamoodi kui siis, kui nad salvestavad olekud. Selle tõttu kõrvaldatakse kõige olulisemad pilvepõhise kujundamise postulaadid, nagu rakenduse tööprotsesside suuruse muutmine vastavalt sisendikoormusele, üleminek uuele sõlmele, kui praegune sõlm ebaõnnestub, jne.
Sellele olukorrale lähemalt vaatates leiame, et andmehoidla valimisel puutume ikka ja jälle kokku dilemmaga "POSIX vs REST API", kuid lisaks on POSIX-i probleemid süvenenud Kubernetes'i jaotatud keskkondade tõttu. Eriti,
- POSIX on loba: семантика POSIX требует ассоциировать с каждой операцией метаданные и дескрипторы файлов, которые помогают поддерживать состояние операции. Это приводит к значительным издержкам, не имеющим никакой реальной ценности. API для хранения объектов, в частности, S3 API, избавились от этих требований, позволяя приложению сработать, а затем «забыть» о вызове. Отклик системы хранения данных указывает, успешно было выполнено данное действие или нет. В случае неудачи приложение может выполнить повторную попытку.
- Сетевые ограничения: Jaotatud süsteemis eeldatakse, et võib eksisteerida mitmeid rakendusi, mis püüavad salvestada andmeid ühele ja samale kinnitatud andmekandjale. Seetõttu mitte ainult, et rakendused konkureerivad omavahel andmeedastusvõime pärast (et edastada andmeid andmekandjale), vaid ka hoidmisseade ise konkurseerib selle võime üle, jaotades andmeid füüsilistele ketastele. POSIX-i liiga detailne olemus suurendab võrguülesannete arvu mitu korda. Teiselt poolt tagab S3 API selge eristamise võrguülesannete vahel, mis tulevad kliendilt serverisse, ja nende vahel, mis toimuvad serveri sees.
- Ohutus: POSIX-i turvamudel eeldab aktiivset inimeste osalust: administraatorid konfigureerivad iga kasutaja või rühma jaoks konkreetsed juurdepääsuõigused. Selline paradigma on keeruline kohandada pilvepõhisesse maailma. Kaasaegsed rakendused tuginevad turvamudelitele, mis on seotud API-dega, kus juurdepääsuõigused määratakse poliitikate kogumina, eraldatakse teenusekontod, ajutised kasutustunnused jne.
- Haldamine: Olekuv kryptod uus tüpi konteinerid toovad kaasa teatud juhtimis- ja halduskulud. See hõlmab andmete süstemaatilist koordineerimist, mis on vajalik, et tagada andmete järjepidevus; see kõik nõuab hoolikat kaalumist, milliseid andmete juurdepääsukujundeid kasutada. Tuleb paigaldada, juhtida ja konfigureerida täiendavaid programme, rääkimata lisapingutustest, mis on vajalikud arendamiseks.
Andmete salvestamise konteinerliides
Kuigi konteinerite andmesalvestuse liides (CSI) on suurepäraselt aidanud Kubernetes'i mahutite taseme levitamisel, edastades selle osaliselt kolmandate osapoolte andmesalvestuse pakkujatele, on see ka tahtmatult aidanud kinnitada veendumust, et oleku hoidmine konteinerite lähenemine on soovitatav andmesalvestamise meetod Kubernetes'is.
CSI loodi nagu standard, et pakkuda pärandrakendustele juhuslikke plokki- ja failipõhiseid andmete salvestamise süsteeme Kubernetes'i keskkonnas. Nagu selles artiklis näidatud, on ainus olukord, kus konteineripõhine (ja CSI oma praeguses vormis) lahendus on mõttekas, kui rakendus ise on pärandi süsteem, kuhu on keeruline lisada objekti salvestus API tuge.
Oluline on mõista, et kasutades CSI-d selle praeguses vormis, st volüümide mountimisel kaasaegsete rakenduste töö käigus, seisame silmitsi sarnaste probleemidega nagu need, mis olid seotud süsteemidega, kus andmete salvestamine on korraldatud POSIX-stiilis.
Kvaliteetsem lähenemine
Selles kontekstis on oluline mõista, et enamik rakendusi ei ole sisuliselt mõeldud töötama kas staatiliste või staatust mittesäilitavate lahendustega. Selline käitumine sõltub süsteemi üldisest arhitektuurist ja konkreetsest valikust, mis on tehtud projekteerimise käigus. Räägime natuke staatust säilitavatest rakendustest.
Põhimõtteliselt saab kõik rakenduste andmed jagada mitmeks suureks tüübiks:
- Logi andmed
- Ajatempli andmed
- Tehingu andmed
- Metadatas
- Konteineri pildid
- BLOB andmed (suurte binaarobjektide)
Kõiki neid andmete liike toetavad väga hästi kaasaegsed andmehoidlate platvormid ning on olemas mitmeid pilvepõhiseid platvorme, mis on kohandatud andmete tarnimiseks igas nendes spetsiifilistes formaatides. Näiteks tehinguandmed ja metaandmed võivad asuda kaasaegses pilvepõhises andmebaasis nagu CockroachDB, YugaByte jne. Konteineri pildid või BLOB andmed võivad olla salvestatud docker registreerimisse, mis põhineb MinIO-l. Ajaandmed võivad olla salvestatud ajalooliste andmete andmebaasis, näiteks InfluxDB jne. Me ei hakka siin igas andmete tüübi ja vastava rakenduse üksikasjadega süvenema, kuid üldine idee on vältida püsiva andmesalvestuse kasutamist, mis põhineb kohalikul kettamonteerimisel.
Lisaks on sageli tõhus tagada ajutise vahemälu tase, mis toimib rakenduste jaoks kui teatud tüüpi ajutiste failide ladustamine, kuid rakendused ei tohiks selle taseme poole tõe allika poolest sõltuda.
Olemasolevate rakenduste ladustamine
Kuigi enamikul juhtudel on kasulik hoida rakendusi olekuteta, peavad andmeid haldavad rakendused – nagu andmebaasid, objekti kogud, võtmemälu ja väärtuste ladustamise süsteemid – säilitama olekut. Selgitame, miks need rakendused Kuberneteses käivituvad. Näiteks toome välja MinIO, kuid sarnased põhimõtted kehtivad ka teiste suurte pilvepõhiste andmete salvestussüsteemide kohta.
Pilvepõhised rakendused on kavandatud maksimaalse efektiivsuse saavutamiseks konteinerite paindlikkuse kasutamisel. See tähendab, et neid ei ole mingisuguseid eeldusi keskkonna osas, kus need juurutatakse. Näiteks kasutab MinIO sisemist üleliigse kodeerimise mehhanismi (erasure coding), mis tagab süsteemi piisava vastupidavuse, et see jääks funktsionaalseks isegi kaheksanda ketta rikke korral. Samuti haldab MinIO andmete terviklikkust ja turvalisust, kasutades oma serveripoolel hashimist ja krüpteerimist.
Selliste pilvepõhiste rakenduste jaoks on varukohtadeks kõige mugavamad kohalikud püsivad mahud (PV). Kohalik PV pakub võimalust salvestada toorandmeid, samas kui nende PV-de peal töötavad rakendused koguvad iseseisvalt teavet, mis võimaldab andmeid skaleerida ja hallata kasvavaid andmenõudeid.
See lähenemine on palju lihtsam ja paremini skaleeritav võrreldes CSI-põhiste PV-dega, mis toovad süsteemi enda andmehaldus- ja redundantsustasemed; probleem seisneb selles, et need tasemed on sageli konfliktis rakendustega, mis on projekteeritud olekute säilitamise printsiibil.
Kindel samm andmete eraldamise suunas arvutustest
Selles artiklis rääkisime sellest, kuidas rakendused suunavad oma tööd olekuta tegutsemiseks, ehk teisisõnu, andmete hoidmine eraldatakse nende üle teostatud arvutustest. Lõpetuseks vaatame mõned reaalsed näited sellisest trendist.
, tuntud andmeanalüüsiplatvorm, on traditsiooniliselt kasutatud oleku hoidmisega ja HDFS-failisüsteemis juurutamisega. Kuid Spark'i ülemineku ajal pilvepõhisesse maailma, on seda platvormi järjest enam kasutatud olekuta, kasutades `s3a`. Spark kasutab s3a, et edastada olekut teistesse süsteemidesse, samas kui Spark'i konteinerid töötavad täielikult olekuta. Teised suured ettevõtted, kes tegutsevad suurte andmete analüütika valdkonnas, eelkõige, , , kaasatakse andmete ja nende töötlemise lahutamise nüanssidega.
Sarnaseid mustreid võib leida ka teistelt suurematelt analüüsiplatvormidelt, sealhulgas Presto, Tensorflow R-ile, Jupyter. Andmete seisundi salvestamine kaugusesse pilvesalvestussüsteemidesse lihtsustab teie rakenduse haldamist ja selle skaleerimist. Samuti toetab see rakenduse portatiivset majutamist mitmesugustes keskkondades.
Allikas: habr.com
