Eelmise aasta lõpus toimus järjekordne otseülekanne Venemaa PostgreSQL-i kogukonnast , mille käigus selle kaasasutaja Nikolai Samokhvalov rääkis Flanti tehnilise direktori Dmitri Stoljaroviga sellest DBMS-ist Kubernetese kontekstis.
Avaldame selle arutelu põhiosa ärakirja ja kl Täielik video postitatud:
Andmebaasid ja Kubernetes
НС: VAKUUMIST ja KONTROLLPUNKTIDEST me täna ei räägi. Me tahame rääkida Kubernetesest. Ma tean, et teil on paljude aastate kogemus. Vaatasin teie videoid ja isegi vaatasin mõnda neist uuesti... Asume otse asja juurde: miks Postgres või MySQL K8s üldse?
DS: Sellele küsimusele ei ole ega saagi olla kindlat vastust. Aga üldiselt on see lihtsus ja mugavus... potentsiaal. Kõik tahavad hallatud teenuseid.
НС: Kuidas , ainult kodus?
DS: Jah: nagu RDS, kõikjal.
НС: "Igal pool" on hea mõte. Suurtes ettevõtetes asub kõik erinevates kohtades. Miks siis, kui tegemist on suure ettevõttega, mitte võtta valmislahendust? Näiteks Nutanixil on oma arendused, teistel ettevõtetel (VMware...) on sama “RDS, ainult kodus”.
DS: Kuid me räägime eraldi rakendusest, mis töötab ainult teatud tingimustel. Ja kui me räägime Kubernetesest, siis seal on tohutult palju erinevaid taristuid (mis võib olla K8-des). Põhimõtteliselt on see pilve API-de standard...
НС: See on ka tasuta!
DS: See pole nii oluline. Vabadus on oluline mitte väga suure turusegmendi jaoks. Tähtis on veel midagi... Ilmselt mäletate aruannet “"?
НС: Jah.
DS: Sain aru, et see võeti väga kahemõtteliselt vastu. Mõned arvasid, et ma ütlen: "Poisid, toome kõik andmebaasid Kubernetesse!", teised aga leidsid, et need on kõik kohutavad jalgrattad. Tahtsin aga öelda hoopis midagi muud: “Vaadake, mis toimub, millised probleemid on ja kuidas neid saab lahendada. Kas peaksime nüüd kasutama Kubernetese andmebaase? Tootmine? Noh, ainult siis, kui sulle meeldib...teatud asju teha. Kuid arendajale võin öelda, et soovitan seda. Arendaja jaoks on keskkondade loomise/kustutamise dünaamilisus väga oluline.
NS: Kas arendaja all mõtlete kõiki keskkondi, mis ei ole toodetud? Lavastus, QA…
DS: Kui me räägime perf-stendidest, siis ilmselt mitte, sest seal on nõuded konkreetsed. Kui me räägime erijuhtudest, kus lavastamiseks on vaja väga suurt andmebaasi, siis ilmselt mitte... Kui tegemist on staatilise pikaealise keskkonnaga, siis mis kasu on sellest, et andmebaas asub K8s?
НС: Mitte ühtegi. Aga kus me näeme staatilisi keskkondi? Staatiline keskkond aegub homme.
DS: Lavastus võib olla staatiline. Meil on kliente...
НС: Jah, mul on ka üks. See on suur probleem, kui teil on 10 TB andmebaas ja 200 GB lavastus...
DS: Mul on väga lahe juhtum! Lavastusel on toodete andmebaas, milles tehakse muudatusi. Ja seal on nupp: "rulli tootmisse". Need muudatused - deltad - lisatakse (tundub, et need on lihtsalt API kaudu sünkroonitud) tootmises. See on väga eksootiline variant.
НС: Olen näinud orus idufirmasid, kes istuvad RDS-is või isegi Herokus – need on 2–3 aasta tagused lood – ja nad laadivad prügikasti oma sülearvutisse. Sest andmebaasi on endiselt ainult 80 GB ja sülearvutis on ruumi. Siis ostetakse igaühele juurde kettaid, et oleks 3 andmebaasi erinevate arenduste läbiviimiseks. Ka see juhtub nii. Vaatasin ka, et nad ei karda tootmist lavastusse kopeerida – see oleneb väga palju ettevõttest. Aga ma nägin ka, et nad kardavad väga ning neil pole sageli piisavalt aega ja käsi. Aga enne kui selle teema juurde läheme, tahan kuulda Kubernetesest. Kas ma saan õigesti aru, et keegi pole veel prod?
DS: Meil on väikesed andmebaasid tootmises. Räägime kümnete gigabaitide mahust ja mittekriitilistest teenustest, mille jaoks olime liiga laisad, et koopiaid teha (ja seda vajadust pole). Ja eeldusel, et Kubernetese all on normaalne salvestusruum. See andmebaas töötas virtuaalses masinas - tingimuslikult VMware'is, salvestussüsteemi peal. Panime selle sisse ja nüüd saame selle masinast masinasse üle kanda.
НС: Sellise suurusega, kuni 100 GB andmebaase saab mõne minutiga headele ketastele ja heale võrgule välja rullida, eks? Kiirus 1 GB sekundis pole enam eksootiline.
DS: Jah, lineaarse töö puhul pole see probleem.
НС: Olgu, me peame lihtsalt mõtlema tootele. Ja kui kaalume Kubernetese kasutamist mittetoodetud keskkondade jaoks, mida peaksime tegema? Ma näen seda Zalandos , in Crunchy , on ka teisi võimalusi. Ja on olemas - see on meie hea sõber Alvaro Hispaaniast: see, mida nad teevad, pole sisuliselt ainult ja kogu jaotus (), millesse otsustati lisaks Postgresile endale toppida ka varukoopia, Envoy proxy...
DS: Milleks saadik? Kas tasakaalustada spetsiaalselt Postgresi liiklust?
НС: Jah. See tähendab, et nad näevad seda järgmiselt: kui võtate Linuxi distributsiooni ja kerneli, on kerneliks tavaline PostgreSQL ja nad tahavad teha distributsiooni, mis oleks pilvesõbralik ja töötaks Kubernetesis. Nad panevad komponendid kokku (varukoopiad jne) ja siluvad, et need hästi töötaksid.
DS: Väga lahe! Põhimõtteliselt on see tarkvara oma hallatava Postgresi loomiseks.
НС: Linuxi distributsioonidel on igavesed probleemid: kuidas teha draivereid nii, et kogu riistvara oleks toetatud. Ja neil on idee, et nad töötavad Kubernetes. Tean, et Zalando operaatoris nägime hiljuti ühendust AWS-iga ja see pole enam väga hea. Konkreetse infrastruktuuriga ei tohiks olla seost – mis mõtet siis on?
DS: Ma ei tea täpselt, millisesse olukorda Zalando sattus, kuid Kubernetese salvestus on nüüd tehtud nii, et ketta varukoopiat pole võimalik teha üldise meetodiga. Hiljuti standardses - uusimas versioonis — tegime hetktõmmised võimalikuks, aga kus seda rakendatakse? Ausalt öeldes on kõik veel nii toores... Proovime CSI-d AWS, GCE, Azure, vSphere peal, aga kohe kui kasutama hakkad, on näha, et see pole veel valmis.
НС: Seetõttu peame mõnikord toetuma infrastruktuurile. Arvan, et see on veel varane staadium – kasvuvalud. Küsimus: Millist nõu annaksite algajatele, kes soovivad PgSQL-i K8-s proovida? Mis operaator võib-olla?
DS: Probleem on selles, et Postgres on meie jaoks 3%. Meil on Kubernetesis ka väga suur nimekiri erinevatest tarkvaradest, ma isegi ei hakka kõike loetlema. Näiteks Elasticsearch. Operaatoreid on palju: ühed arenevad aktiivselt, teised mitte. Oleme enda jaoks koostanud nõuded, mis peaks operaatoris olema, et me seda tõsiselt võtaksime. Spetsiaalselt Kubernetesele mõeldud operaatoris - mitte "operaatoris, mis teeb midagi Amazoni tingimustes"... Tegelikult kasutame me üsna laialdaselt (= peaaegu kõik kliendid) ühte operaatorit - (varsti avaldame temast artikli).
НС: Ja mitte ka MySQL-i jaoks? Ma tean, et Percona... kuna nad töötavad nüüd MySQL, MongoDB ja Postgres kallal, peavad nad looma mingi universaalse lahenduse: kõikide andmebaaside ja pilveteenuse pakkujate jaoks.
DS: Meil ei olnud aega MySQL-i operaatoreid vaadata. See ei ole praegu meie põhifookus. MySQL töötab eraldiseisvana hästi. Miks kasutada operaatorit, kui saate lihtsalt käivitada andmebaasi... Dockeri konteineri saate käivitada Postrges-iga või käivitada lihtsal viisil.
НС: Selle kohta oli ka küsimus. Kas pole üldse operaatorit?
DS: Jah, 100% meist töötab PostgreSQL ilma operaatorita. Siiani nii. Kasutame operaatorit aktiivselt Prometheuse ja Redise jaoks. Meil on plaanis leida Elasticsearchile operaator - see on see, kes on kõige rohkem põlemas, sest tahame selle 100% juhtudest Kubernetesesse installida. Nii nagu tahame tagada, et MongoDB oleks alati Kubernetesesse installitud. Siin ilmnevad teatud soovid – tekib tunne, et nendel juhtudel saab midagi ära teha. Ja me isegi ei vaadanud Postgresi. Muidugi teame, et on erinevaid võimalusi, kuid tegelikult on meil eraldiseisev.
DB Kubernetesis testimiseks
НС: Liigume edasi testimise teema juurde. Kuidas andmebaasis muudatusi juurutada – DevOpsi vaatenurgast. Seal on mikroteenused, palju andmebaase, kogu aeg kuskil midagi muutub. Kuidas tagada normaalne CI/CD, et DBMS-i vaatenurgast oleks kõik korras. Milline on teie lähenemine?
DS: Ei saa olla ühte vastust. Võimalusi on mitu. Esimene on aluse suurus, mida tahame välja rullida. Te ise mainisite, et ettevõtted suhtuvad tooteandmebaasi koopiasse arendamisel ja etapil erinevalt.
НС: Ja GDPR tingimustes ollakse minu meelest järjest ettevaatlikumad... Võin öelda, et Euroopas on juba trahve hakatud tegema.
DS: Kuid sageli saate kirjutada tarkvara, mis võtab tootmisest tühjaks ja muudab selle häguseks. Tootmisandmed saadakse (hetktõmmis, dump, binaarkoopia...), kuid need muudetakse anonüümseks. Selle asemel võivad olla genereerimisskriptid: need võivad olla kinnitused või lihtsalt skript, mis loob suure andmebaasi. Probleem on selles: kui kaua kulub aluspildi loomiseks? Ja kui kaua kulub selle juurutamiseks soovitud keskkonnas?
Jõudsime skeemini: kui kliendil on fikseeritud andmekogum (andmebaasi minimaalne versioon), siis kasutame neid vaikimisi. Kui me räägime ülevaatekeskkondadest, siis haru loomisel juurutasime rakenduse eksemplari – juurutasime seal väikese andmebaasi. Aga see tuli hästi välja , kui võtame üks kord päevas (öösel) tootmisest prügimäe ja ehitame selle põhjal nende laaditud andmetega Dockeri konteineri PostgreSQL-i ja MySQL-iga. Kui teil on sellel pildil vaja andmebaasi 50 korda laiendada, tehakse seda üsna lihtsalt ja kiiresti.
НС: Lihtsa kopeerimisega?
DS: andmed salvestatakse otse Dockeri kujutisele. Need. Meil on valmis pilt, kuigi 100 GB. Tänu Dockeri kihtidele saame selle pildi kiiresti juurutada nii mitu korda kui vaja. Meetod on rumal, kuid töötab hästi.
НС: Siis, kui testite, muutub see otse Dockeri sees, eks? Dockeri sees kopeerimine-kirjutamine – viska minema ja mine uuesti, kõik on korras. Klass! Ja kas kasutate seda juba täiel rinnal?
DS: Pikka aega.
НС: Teeme väga sarnaseid asju. Ainult me ei kasuta Dockeri kopeerimist kirjutamisel, vaid mõnda muud.
DS: See ei ole üldine. Ja Docker töötab kõikjal.
НС: Teoreetiliselt jah. Aga meil on seal ka moodulid, saab teha erinevaid mooduleid ja töötada erinevate failisüsteemidega. Milline hetk siin. Postgresi poolelt vaatame seda kõike erinevalt. Nüüd vaatasin Dockeri poolelt ja nägin, et kõik töötab teie jaoks. Aga kui andmebaas on hiiglaslik, nt 1 TB, siis see kõik võtab kaua aega: öösiti toimingud ja kõike Dockerisse toppimine... Ja kui Dockerisse toppida 5 TB... Või on kõik korras?
DS: Mis vahet on: need on plekid, vaid bitid ja baidid.
НС: Erinevus on järgmine: kas teete seda prügi ja taastamise kaudu?
DS: Pole üldse vajalik. Selle pildi loomise meetodid võivad olla erinevad.
НС: Mõne kliendi puhul oleme teinud nii, et regulaarse baaspildi genereerimise asemel hoiame seda pidevalt kursis. See on sisuliselt koopia, kuid see ei saa andmeid otse põhiseadmelt, vaid arhiivi kaudu. Binaararhiiv, kuhu WAL-e iga päev alla laaditakse, kus varukoopiaid tehakse... Need WAL-id jõuavad siis põhipildini väikese viivitusega (sõna otseses mõttes 1-2 sekundit). Kloonime sellest igal viisil - nüüd on meil vaikimisi ZFS.
DS: Kuid ZFS-iga piirdute ühe sõlmega.
НС: Jah. Kuid ZFS-il on ka maagiline : sellega saate saata hetktõmmise ja isegi (ma pole seda veel päris testinud, aga...) saate saata kahe vahel delta PGDATA. Tegelikult on meil veel üks tööriist, mida me selliste ülesannete jaoks pole mõelnud. PostgreSQL-il on , mis töötab nagu "nutikas" rsync, jättes vahele palju seda, mida te ei pea vaatama, sest seal pole midagi muutunud. Saame teha kiire sünkroonimise kahe serveri vahel ja samamoodi tagasi kerida.
Sellest, rohkem DBA-st lähtudes, püüame luua tööriista, mis võimaldab meil teha sama, mida sa ütlesid: meil on üks andmebaas, kuid me tahame midagi testida 50 korda, peaaegu samaaegselt.
DS: 50 korda tähendab, et peate tellima 50 Spot eksemplari.
НС: Ei, me teeme kõike ühe masinaga.
DS: Aga kuidas sa laiendad 50 korda, kui see üks andmebaas on näiteks terabait. Tõenäoliselt vajab ta tingimuslikku 256 GB muutmälu?
НС: Jah, mõnikord on teil vaja palju mälu – see on normaalne. Aga see on näide elust. Tootmismasinal on 96 tuuma ja 600 GB. Samas kasutatakse andmebaasi jaoks 32 tuuma (nüüd isegi 16 tuuma) ja 100-120 GB mälu.
DS: Ja sinna mahub 50 eksemplari?
НС: Seega on ainult üks eksemplar, siis kopeerimine-kirjutus (ZFS) töötab... Ma räägin teile täpsemalt.
Näiteks on meil 10 TB andmebaas. Nad tegid selle jaoks ketta, ZFS tihendas ka selle suurust 30-40 protsenti. Kuna me koormusteste ei tee, pole täpne reageerimisaeg meie jaoks oluline: olgu see kuni 2 korda aeglasem – see on okei.
Anname võimaluse programmeerijatele, QA, DBA jne. testida 1-2 lõimega. Näiteks võivad nad käivitada mingisuguse migratsiooni. See ei nõua 10 tuuma korraga – selleks on vaja 1 Postgresi taustaprogrammi, 1 tuuma. Ränne algab – võib-olla ikka käivitub, siis kasutatakse teist südamikku. Meil on eraldatud 16-32 tuuma, seega saab korraga töötada 10 inimest, pole probleemi.
Sest füüsiliselt PGDATA sama, selgub, et me tegelikult petame Postgresi. Trikk on järgmine: näiteks käivitatakse korraga 10 Postgret. Milles probleem tavaliselt on? Nad panevad , oletame, et 25%. Seega on see 200 GB. Üle kolme neist ei saa käivitada, sest mälu saab otsa.
Kuid mingil hetkel saime aru, et see pole vajalik: määrasime jagatud puhvrite suuruseks 2 GB. PostgreSQL-il on , ja tegelikult on see ainus, mis mõjutab . Seadsime selle 0,5 TB-le. Ja pole isegi oluline, et neid tegelikult pole: ta teeb plaane, nagu need oleksid olemas.
Seega, kui testime mingit migratsiooni, saame kõik plaanid kokku koguda - näeme, kuidas see tootmises juhtub. Sealsed sekundid on erinevad (aeglasemad), kuid andmed, mida me tegelikult loeme, ja plaanid ise (mis seal on JOIN-id jne) osutuvad täpselt samadeks, mis tootmises. Ja saate ühes masinas paralleelselt käivitada palju selliseid kontrolle.
DS: Kas sa ei arva, et siin on mõned probleemid? Esimene on lahendus, mis töötab ainult PostgreSQL-is. See lähenemisviis on väga privaatne, see ei ole üldine. Teine on see, et Kubernetes (ja kõik, mida pilvtehnoloogiad praegu kasutavad) hõlmab paljusid sõlmi ja need sõlmed on lühiajalised. Ja teie puhul on see olekupõhine, püsiv sõlm. Need asjad ajavad mind vastuollu.
НС: Esiteks, ma olen nõus, see on puhtalt Postgresi lugu. Ma arvan, et kui meil on peaaegu kogu mälu jaoks mingi otsene IO ja puhverkogum, siis see lähenemine ei toimi – plaanid on teised. Kuid praegu töötame ainult Postgresiga, me ei mõtle teistele.
Kubernetese kohta. Te ise ütlete meile kõikjal, et meil on püsiv andmebaas. Kui eksemplar ebaõnnestub, on peamine asi ketta salvestamine. Siin on meil ka kogu platvorm Kubernetesis ja Postgresiga komponent on eraldi (kuigi see on kunagi olemas). Seetõttu on kõik nii: eksemplar kukkus, kuid me salvestasime selle PV ja ühendasime selle lihtsalt teise (uue) eksemplariga, nagu poleks midagi juhtunud.
DS: Minu seisukohast loome kaunad Kubernetesis. K8s - elastne: sõlmed tellitakse vastavalt vajadusele. Ülesanne on lihtsalt luua pod ja öelda, et see vajab X kogust ressursse ja siis K8s mõtleb selle ise välja. Kuid Kubernetese salvestustugi on endiselt ebastabiilne: Sisse (see väljaanne avaldati недели tagasi) muutuvad need funktsioonid ainult beetaversiooniks.
Möödub kuus kuud kuni aasta – see muutub enam-vähem stabiilseks või vähemalt deklareeritakse selliseks. Seejärel lahendab hetktõmmiste ja suuruse muutmise võimalus teie probleemi täielikult. Sest teil on alus. Jah, see ei pruugi olla väga kiire, kuid kiirus sõltub sellest, mis on "kapoti all", sest mõned rakendused saavad kopeerida ja kopeerida kirjutamisel ketta alamsüsteemi tasemel.
НС: Samuti on vaja, et kõik mootorid (Amazon, Google...) hakkaksid seda versiooni toetama – ka see võtab omajagu aega.
DS: Me ei kasuta neid veel. Me kasutame oma.
Kubernetese kohalik areng
НС: Kas olete sellise sooviga kokku puutunud, kui teil on vaja paigaldada kõik podid ühele masinale ja teha selline väike test. Kontseptsiooni kiireks tõendi saamiseks veenduge, et rakendus töötab Kubernetesis, ilma et oleks vaja sellele palju masinaid pühendada. Seal on Minikube, eks?
DS: Mulle tundub, et see juhtum – mis on paigutatud ühte sõlme – puudutab eranditult kohalikku arengut. Või mingid sellise mustri ilmingud. Sööma , seal on , . Liigume Kubernetes IN Dockeri kasutamise poole. Nüüd alustasime sellega testide jaoks tööd.
НС: Varem arvasin, et see on katse mähkida kõik kaunad ühte Dockeri kujutisse. Kuid selgus, et see on midagi täiesti erinevat. Igatahes on eraldi konteinerid, eraldi kaunad - just Dockeris.
DS: Jah. Ja seal on tehtud üsna naljakas imitatsioon, aga tähendus on selline... Meil on kasutuselevõtuks utiliit - . Tahame muuta selle tingimuslikuks režiimiks werf up: "Tooge mulle kohalik Kubernetes." Ja siis käivita seal tingimuslik werf follow. Seejärel saab arendaja IDE-d redigeerida ja süsteemis käivitatakse protsess, mis näeb muudatusi ja loob pildid ümber, paigutades need ümber kohalikesse K8-desse. Nii tahame proovida lahendada kohaliku arengu probleemi.
Snapshots ja andmebaasi kloonimine K8s reaalsuses
НС: Kui pöördume tagasi kopeerimise-kirjutamise juurde. Märkasin, et pilvedel on ka hetktõmmised. Nad töötavad erinevalt. Näiteks GCP-s: teil on mitme terabaidine eksemplar Ameerika Ühendriikide idarannikul. Teete perioodiliselt pilte. Võtad snapshotist läänerannikul oleva ketta koopia - mõne minutiga on kõik valmis, toimib väga kiiresti, ainult vahemälu tuleb mällu täita. Kuid need kloonid (hetktõmmised) on mõeldud uue helitugevuse "varumiseks". See on lahe, kui peate looma palju eksemplare.
Kuid testide jaoks tundub mulle, et snapshots, millest sa räägid Dockeris või ma räägin ZFS-is, btrfs-is ja isegi LVM-is... - need võimaldavad sul mitte luua ühes masinas päris uusi andmeid. Pilves maksate nende eest ikkagi iga kord ja ootate mitte sekundeid, vaid minuteid (ja juhul , võib-olla ka kell).
Selle asemel saate need andmed sekundi või paariga hankida, testi käivitada ja minema visata. Need hetktõmmised lahendavad erinevaid probleeme. Esimesel juhul - suurendamiseks ja uute koopiate saamiseks ning teisel - testide jaoks.
DS: Ma ei ole nõus. Helitugevuse kloonimine on pilve ülesanne. Ma pole nende rakendamist vaadanud, kuid tean, kuidas me seda riistvaraga teeme. Meil on Ceph, see võimaldab mis tahes füüsilist helitugevust () öelda kloonida ja saate kümnete millisekundite jooksul samade omadustega teise helitugevuse, 'ami jne. Peate mõistma, et sees on keeruline kopeerimine-kirjutamine. Miks ei võiks pilv sama teha? Olen kindel, et nad üritavad seda ühel või teisel viisil teha.
НС: Aga eksemplari tõstmiseks, Dockeri toomiseks jne kulub neil ikkagi sekundeid, kümneid sekundeid.
DS: Miks on vaja tõstatada terve eksemplar? Meil on eksemplar 32 tuumaga, 16... ja sinna mahub ära - näiteks neli. Kui tellime viienda, tõstetakse eksemplar juba üles ja siis see kustutatakse.
НС: Jah, huvitav, Kubernetes on hoopis teine lugu. Meie andmebaas ei ole K8s ja meil on üks eksemplar. Kuid mitme terabaidise andmebaasi kloonimine ei kesta rohkem kui kaks sekundit.
DS: See on hea. Kuid minu esimene seisukoht on, et see ei ole üldine lahendus. Jah, see on lahe, kuid see sobib ainult Postgresi jaoks ja ainult ühes sõlmes.
НС: See sobib mitte ainult Postgresile: need plaanid, nagu ma kirjeldasin, töötavad ainult selles. Aga kui me ei muretse plaanide pärast ja vajame lihtsalt kõiki andmeid funktsionaalseks testimiseks, siis sobib see igale DBMS-ile.
DS: Aastaid tagasi tegime midagi sarnast LVM-i hetktõmmistes. See on klassika. Seda lähenemist kasutati väga aktiivselt. Olulised sõlmed on lihtsalt piin. Kuna te ei tohiks neid maha visata, peaksite neid alati meeles pidama...
НС: Kas näete siin mingit hübriidi võimalust? Oletame, et stateful on mingi pod, see töötab mitme inimese jaoks (paljud testijad). Meil on üks köide, aga tänu failisüsteemile on kloonid kohalikud. Kui tasku kukub, kuid ketas jääb alles, tõuseb pod, loendab kõigi kloonide kohta teavet, korjab kõik uuesti üles ja ütleb: "Siin on teie kloonid, mis töötavad nendes portides, jätkake nendega töötamist."
DS: Tehniliselt tähendab see, et Kubernetesis on see üks kaustik, mille sees käitame palju Postgresid.
НС: Jah. Tal on piirang: oletame, et temaga ei tööta korraga rohkem kui 10 inimest. Kui teil on vaja 20, laseme turule teise sellise paketi. Kloonime selle täielikult, pärast teise täisköite saamist on sellel samad 10 “õhukest” klooni. Kas te ei näe seda võimalust?
DS: Peame siia lisama turvaprobleemid. Seda tüüpi organisatsioon eeldab, et sellel taskul on kõrged privileegid (võimalused), kuna see suudab failisüsteemis teha mittestandardseid toiminguid... Kuid kordan: usun, et keskpikas perspektiivis parandavad nad Kubernetes salvestusruumi ja pilved parandavad nad kogu loo helitugevustega - kõik "lihtsalt töötab". Toimub suuruse muutmine, kloonimine... Helitugevus on olemas - me ütleme: "Looge selle põhjal uus" ja pooleteise sekundi pärast saame, mida vajame.
НС: Ma ei usu poolteist sekundit paljude terabaitide puhul. Cephil teete seda ise, kuid räägite pilvedest. Minge pilve, tehke EC2-s mitme terabaidise EBS-köite kloon ja vaadake, milline on jõudlus. See ei võta paar sekundit. Mind huvitab väga, millal nad sellele tasemele jõuavad. Ma saan aru, mida sa ütled, kuid ma palun eriarvamust.
DS: Ok, aga ma ütlesin keskpikas, mitte lühiajalises perspektiivis. Juba mitu aastat.
Teave Zalando PostgreSQL-i operaatori kohta
Selle kohtumise keskel ühines ka Zalando endine arendaja Aleksei Klyukin, kes rääkis PostgreSQL-i operaatori ajaloost:
Tore, et seda teemat üldiselt puudutatakse: nii Postgres kui ka Kubernetes. Kui me 2017. aastal Zalandos sellega tegelema hakkasime, oli see teema, mida kõik tahtsid teha, aga keegi ei tahtnud. Kubernetes oli juba kõigil olemas, aga kui küsiti, mida andmebaasidega teha, siis isegi inimestele meeldib , kes jutlustas K8-sid, ütles midagi sellist:
"Minge hallatavatesse teenustesse ja kasutage neid, ärge käivitage andmebaasi Kubernetesis. Vastasel juhul otsustavad teie K8-d teha näiteks uuenduse, lülitavad kõik sõlmed välja ja teie andmed lendavad kaugele-kaugele.
Otsustasime teha operaatori, kes vastupidiselt sellele nõuandele käivitab Kubernetesis Postgresi andmebaasi. Ja meil oli hea põhjus - . See on PostgreSQL-i automaatne tõrkevahetus, mis on tehtud õigesti, st. kasutades etcd, consul või ZooKeeper klastri kohta teabe salvestamiseks. Selline hoidla, mis annab kõigile, kes küsivad näiteks, milline on praegune juht, sama info – vaatamata sellele, et meil on kõik laiali –, et ei tekiks aju lõhenemist. Lisaks oli meil tema jaoks.
Üldiselt ilmnes ettevõtte vajadus automaatse tõrkesiirde järele pärast sisemisest riistvaralisest andmekeskusest pilve siirdumist. Pilv põhines patenteeritud PaaS (Platform-as-a-Service) lahendusel. See on avatud lähtekoodiga, kuid selle käivitamiseks ja käivitamiseks kulus palju tööd. Seda kutsuti .
Esialgu Kubernetes ei olnud. Täpsemalt, kui meie oma lahendus kasutusele võeti, olid K8-d juba olemas, kuid see oli nii toores, et ei sobinud tootmiseks. Minu arvates oli see 2015 või 2016. 2017. aastaks oli Kubernetes enam-vähem küpseks saanud – sinna oli vaja rännata.
Ja meil oli juba Dockeri konteiner. Seal oli PaaS, mis kasutas Dockerit. Miks mitte proovida K8-sid? Miks mitte kirjutada oma operaator? Murat Kabilov, kes tuli meile Avitost, alustas seda projektina omal algatusel - "mängida" - ja projekt "tõus hoo sisse".
Aga üldiselt tahtsin ma AWS-ist rääkida. Miks oli ajalooline AWS-iga seotud kood...
Kuberneteses midagi käivitades peate mõistma, et K8s on selline töö. See areneb pidevalt, paraneb ja aeg-ajalt isegi laguneb. Peate hoolikalt jälgima kõiki Kubernetese muudatusi, olema valmis sellesse sukelduma, kui midagi juhtub, ja õppima üksikasjalikult, kuidas see töötab - võib-olla rohkem, kui soovite. See kehtib põhimõtteliselt iga platvormi kohta, millel oma andmebaase käitate...
Nii et kui me avalduse tegime, töötas meil Postgres välisel köitel (antud juhul EBS, kuna töötasime AWS-iga). Andmebaas kasvas, mingil hetkel oli vaja selle suurust muuta: näiteks EBS-i algne suurus oli 100 TB, andmebaas kasvas selleni, nüüd tahame teha EBS-i 200 TB. Kuidas? Oletame, et saate teha uue eksemplari tühjendamise/taastamise, kuid see võtab kaua aega ja hõlmab seisakuid.
Seetõttu soovisin suurust, mis suurendaks EBS-i partitsiooni ja käskis failisüsteemil uut ruumi kasutada. Ja me tegime seda, kuid sel ajal polnud Kubernetesil suuruse muutmise toimingu jaoks API-t. Kuna töötasime AWS-iga, kirjutasime selle API jaoks koodi.
Keegi ei takista teil sama tegemast teiste platvormide puhul. Avalduses pole vihjet, et seda saab kasutada ainult AWS-is ja kõige muuga see ei tööta. Üldiselt on tegu avatud lähtekoodiga projektiga: kui keegi soovib uue API kasutuse tekkimist kiirendada, siis olete teretulnud. Sööma , tõmba päringuid – Zalando meeskond püüab neile üsna kiiresti vastata ja operaatorit reklaamida. Minu teada projekt Google Summer of Code'is ja mõnes muus sarnases algatuses. Zalando töötab selle kallal väga aktiivselt.
PS boonus!
Kui olete huvitatud PostgreSQL-i ja Kubernetese teemast, siis pange tähele ka seda, et eelmisel nädalal toimus järgmine Postgresi teisipäev, kus rääkisin Nikolaiga Aleksander Kukuškin Zalandost. Video sellest on saadaval .
PPS
Loe ka meie blogist:
- «";
- «";
- «";
- «'.
Allikas: www.habr.com