Praėjusių metų pabaigoje įvyko dar viena tiesioginė Rusijos PostgreSQL bendruomenės transliacija , kurio metu jos įkūrėjas Nikolajus Samokhvalovas kalbėjosi su Flant techniniu direktoriumi Dmitrijumi Stolyarovu apie šią DBVS Kubernetes kontekste.
Skelbiame pagrindinės šios diskusijos dalies stenogramą, o š Visas vaizdo įrašas paskelbtas:
Duomenų bazės ir Kubernetes
NS: Šiandien nekalbėsime apie VAKUUMĄ ir PATIKRINIMUS TAŠKUS. Mes norime pakalbėti apie Kubernetes. Žinau, kad turite ilgametę patirtį. Žiūrėjau jūsų vaizdo įrašus ir net kai kuriuos peržiūrėjau iš naujo... Eikime tiesiai prie reikalo: kodėl išvis Postgres ar MySQL K8?
DS: Nėra ir negali būti konkretaus atsakymo į šį klausimą. Bet apskritai tai yra paprastumas ir patogumas... potencialas. Visi nori valdomų paslaugų.
NS: Kaip , tik namie?
DS: Taip: kaip RDS, bet kur.
NS: „Bet kur“ yra geras dalykas. Didelėse įmonėse viskas yra skirtingose vietose. Kodėl tada, jei tai didelė įmonė, nesiimti paruošto sprendimo? Pavyzdžiui, „Nutanix“ turi savo plėtrą, kitos įmonės (VMware...) turi tą patį „RDS, tik namuose“.
DS: Bet mes kalbame apie atskirą įgyvendinimą, kuris veiks tik esant tam tikroms sąlygoms. O jei mes kalbame apie Kubernetes, tai yra didžiulė infrastruktūros įvairovė (kuri gali būti K8). Iš esmės tai yra debesies API standartas...
NS: Tai taip pat nemokama!
DS: Tai nėra taip svarbu. Laisvumas svarbus ne itin dideliam rinkos segmentui. Dar kai kas svarbu... Tikriausiai prisimenate pranešimą „"?
NS: Taip.
DS: Supratau, kad priimta labai dviprasmiškai. Vieni manė, kad aš sakau: „Vaikinai, įkelkime visas duomenų bazes į Kubernetes!“, o kiti nusprendė, kad tai baisūs dviračiai. Tačiau norėjau pasakyti visai ką kita: „Pažiūrėkite, kas vyksta, kokios problemos ir kaip jas galima išspręsti. Ar dabar turėtume naudoti „Kubernetes“ duomenų bazes? Gamyba? Na, tik jei tau patinka... daryti tam tikrus dalykus. Tačiau kūrėjui galiu pasakyti, kad rekomenduoju. Kūrėjui labai svarbus aplinkos kūrimo / trynimo dinamiškumas.
NS: Sakydami kūrėją turite omenyje visas aplinkas, kurios nėra pagamintos? Inscenizacija, QA…
DS: Jei kalbame apie perf stendus, tai tikriausiai ne, nes ten reikalavimai yra specifiniai. Jei kalbame apie ypatingus atvejus, kai inscenizacijai reikia labai didelės duomenų bazės, tai tikriausiai ne... Jeigu tai statiška, ilgaamžė aplinka, tai kokia nauda, kad duomenų bazė yra K8s?
NS: Nė vienas. Bet kur mes matome statinę aplinką? Statiška aplinka rytoj taps nebereikalinga.
DS: Statymas gali būti statinis. Turime klientų...
NS: Taip, aš irgi turiu. Tai didelė problema, jei turite 10 TB duomenų bazę ir 200 GB sustojimo...
DS: Turiu labai puikų dėklą! Statant yra produktų duomenų bazė, kurioje atliekami pakeitimai. Ir yra mygtukas: „išleisti į gamybą“. Šie pakeitimai – deltai – pridedami (atrodo, tiesiog sinchronizuojami per API) gamyboje. Tai labai egzotiškas variantas.
NS: Slėnyje mačiau startuolių, kurie dirba RDS ar net Heroku – tai istorijos prieš 2–3 metus – ir jie atsisiunčia sąvartyną į savo nešiojamąjį kompiuterį. Nes duomenų bazė vis dar tik 80 GB, o nešiojamajame kompiuteryje yra vietos. Tada jie perka papildomus diskus kiekvienam, kad jie turėtų 3 duomenų bazes įvairiems patobulinimams atlikti. Taip irgi atsitinka. Taip pat mačiau, kad jie nebijo kopijuoti prod į pastatymą – tai labai priklauso nuo įmonės. Bet taip pat mačiau, kad jie labai bijo, dažnai neturi pakankamai laiko ir rankų. Tačiau prieš pereinant prie šios temos, noriu išgirsti apie Kubernetes. Ar teisingai suprantu, kad niekas dar nedirba?
DS: Turime mažas duomenų bazes gamyboje. Kalbame apie dešimčių gigabaitų apimtis ir nekritines paslaugas, kurioms tingėjome daryti kopijas (o tokio poreikio nėra). Ir su sąlyga, kad pagal Kubernetes yra įprasta saugykla. Ši duomenų bazė veikė virtualioje mašinoje – sąlyginai VMware, saugojimo sistemos viršuje. Mes jį įdėjome ir dabar galime perkelti iš mašinos į mašiną.
NS: Tokio dydžio duomenų bazes, iki 100 GB, galima per kelias minutes įdiegti geruose diskuose ir gerame tinkle, tiesa? 1 GB per sekundę greitis nebėra egzotika.
DS: Taip, linijiniam veikimui tai nėra problema.
NS: Gerai, mes tiesiog turime galvoti apie prod. O jei svarstome, kad „Kubernetes“ būtų naudojama ne gaminių aplinkoje, ką turėtume daryti? Aš tai matau Zalande , Crunchy , yra keletas kitų variantų. Ir yra - tai mūsų geras draugas Alvaro iš Ispanijos: tai, ką jie daro, iš esmės nėra tik , ir visas paskirstymas (), į kurį, be paties „Postgres“, jie taip pat nusprendė įdėti atsarginę kopiją, „Envoy proxy“...
DS: Pasiuntinys už ką? Konkrečiai subalansuoti „Postgres“ srautą?
NS: Taip. Tai yra, jie mato tai taip: jei naudojate „Linux“ paskirstymą ir branduolį, tada įprastas „PostgreSQL“ yra branduolys, ir jie nori sukurti paskirstymą, kuris būtų pritaikytas debesims ir veiktų „Kubernetes“. Jie sujungia komponentus (atsargines kopijas ir kt.) ir derina juos, kad jie gerai veiktų.
DS: Labai šaunu! Iš esmės tai yra programinė įranga, skirta sukurti savo valdomus Postgres.
NS: Linux distribucijos turi amžinų problemų: kaip padaryti tvarkykles, kad būtų palaikoma visa aparatinė įranga. Ir jie turi idėją, kad dirbs Kubernetes. Žinau, kad Zalando operatore neseniai matėme ryšį su AWS ir tai nebėra labai gerai. Neturėtų būti susieta su konkrečia infrastruktūra – kokia tada prasmė?
DS: Tiksliai nežinau, į kokią situaciją pateko Zalando, bet Kubernetes saugykla dabar sukurta taip, kad naudojant bendrąjį metodą neįmanoma padaryti atsarginės disko kopijos. Neseniai standartiškai – naujausioje versijoje — padarėme momentines nuotraukas, bet kur tai įgyvendinta? Sąžiningai, viskas dar taip neapdorota... Bandome CSI ant AWS, GCE, Azure, vSphere, bet kai tik pradėsite naudoti, pamatysite, kad jis dar neparengtas.
NS: Štai kodėl kartais tenka pasikliauti infrastruktūra. Manau, kad tai dar ankstyva stadija – augimo skausmai. Klausimas: Ką patartumėte naujokams, norintiems išbandyti PgSQL K8? Gal koks operatorius?
DS: Problema ta, kad „Postgres“ mums yra 3 proc. Taip pat Kubernetes turime labai didelį sąrašą įvairios programinės įrangos, visko net neišvardinsiu. Pavyzdžiui, Elasticsearch. Operatorių daug: vieni aktyviai vystosi, kiti – ne. Mes patys sau sudarėme reikalavimus, ką operatorius turi turėti, kad į tai žiūrėtume rimtai. Operatoriuje specialiai Kubernetes - o ne "operatoriuje, kad ką nors padarytų Amazon sąlygomis"... Tiesą sakant, mes gana plačiai (= beveik visi klientai) naudojame vieną operatorių - (apie jį netrukus paskelbsime straipsnį).
NS: Ir ne MySQL? Aš žinau, kad Percona... kadangi jie dabar dirba su MySQL, MongoDB ir Postgres, turės sukurti kažkokį universalų sprendimą: visoms duomenų bazėms, visiems debesų tiekėjams.
DS: Mes neturėjome laiko pažvelgti į MySQL operatorius. Šiuo metu tai nėra pagrindinis mūsų dėmesys. MySQL puikiai veikia atskirai. Kam naudoti operatorių, jei galite tiesiog paleisti duomenų bazę... Galite paleisti Docker konteinerį naudodami Postrges arba galite jį paleisti paprastu būdu.
NS: Dėl to irgi buvo klausimas. Operatoriaus visai nėra?
DS: Taip, 100% mūsų turi PostgreSQL veikia be operatoriaus. Kol kas taip. Mes aktyviai naudojame operatorių Prometheus ir Redis. Planuojame surasti Elasticsearch operatorių – jis labiausiai „dega“, nes 100% atvejų norime jį įdiegti Kubernetes. Lygiai taip pat norime užtikrinti, kad „MongoDB“ visada būtų įdiegta „Kubernetes“. Čia atsiranda tam tikri norai – atsiranda jausmas, kad tokiais atvejais galima ką nors padaryti. Ir mes net nežiūrėjome į Postgresą. Žinoma, žinome, kad yra įvairių variantų, bet iš tikrųjų turime atskirą.
DB testavimui Kubernetes
NS: Pereikime prie testavimo temos. Kaip įdiegti duomenų bazės pakeitimus – DevOps požiūriu. Yra mikropaslaugos, daug duomenų bazių, nuolat kažkas kažkur keičiasi. Kaip užtikrinti normalų CI/CD, kad viskas būtų tvarkoje iš DBVS perspektyvos. Koks tavo požiūris?
DS: Vieno atsakymo negali būti. Yra keletas variantų. Pirmasis yra pagrindo, kurį norime išvynioti, dydis. Jūs pats minėjote, kad įmonės skirtingai vertina gaminių duomenų bazės kopiją kūrimo ir scenos sistemoje.
NS: O pagal GDPR sąlygas, manau, jie vis atsargesni... Galiu pasakyti, kad Europoje jau pradėjo skirti baudas.
DS: Tačiau dažnai galite rašyti programinę įrangą, kuri iš gamybos iškrauna ir ją užtemdo. Gamybos duomenys gaunami (snapshot, dump, dvejetainė kopija...), tačiau jie anonimizuojami. Vietoj to gali būti generuojami scenarijai: tai gali būti įrenginiai arba tiesiog scenarijus, generuojantis didelę duomenų bazę. Problema tokia: kiek laiko užtrunka sukurti pagrindinį vaizdą? Ir kiek laiko užtrunka jį įdiegti norimoje aplinkoje?
Priėjome schemą: jei klientas turi fiksuotą duomenų rinkinį (minimalią duomenų bazės versiją), tai mes juos naudojame pagal nutylėjimą. Jei kalbame apie peržiūros aplinkas, kurdami filialą, įdiegėme programos egzempliorių - ten įdiegiame nedidelę duomenų bazę. Bet išėjo gerai , kai kartą per dieną (naktį) paimame iš gamybos iškrovimą ir sukuriame Docker konteinerį su PostgreSQL ir MySQL su šiais įkeltais duomenimis. Jei reikia išplėsti duomenų bazę 50 kartų iš šio paveikslėlio, tai daroma gana paprastai ir greitai.
NS: Paprastu kopijavimu?
DS: Duomenys saugomi tiesiogiai „Docker“ vaizde. Tie. Turime paruoštą vaizdą, nors ir 100 GB. „Docker“ sluoksnių dėka šį vaizdą galime greitai įdiegti tiek kartų, kiek reikia. Metodas kvailas, bet veikia gerai.
NS: Tada, kai bandote, jis pasikeičia tiesiai „Docker“ viduje, tiesa? Kopijavimas ant rašymo Docker viduje – išmesk ir vėl eik, viskas gerai. Klasė! O ar jau naudojatės iki galo?
DS: Ilgam laikui.
NS: Mes darome labai panašius dalykus. Tik mes naudojame ne Docker's copy-on-write, o kitą.
DS: Tai nėra bendra. Ir Docker veikia visur.
NS: Teoriškai taip. Bet ten turime ir modulių, galima kurti skirtingus modulius ir dirbti su skirtingomis failų sistemomis. Kokia čia akimirka. Iš Postgres pusės į visa tai žiūrime kitaip. Dabar pažiūrėjau iš Docker pusės ir pamačiau, kad viskas jums tinka. Bet jei duomenų bazė didžiulė, pavyzdžiui, 1 TB, tai visa tai užtrunka ilgai: operacijos naktimis, ir visko kimimas į Docker... O jei į Docker įkiša 5 TB... O gal viskas gerai?
DS: Koks skirtumas: tai yra dėmės, tik bitai ir baitai.
NS: Skirtumas yra toks: ar tai darote išmesdami ir atkurdami?
DS: Visai nebūtina. Šio vaizdo generavimo būdai gali būti skirtingi.
NS: Kai kuriems klientams padarėme taip, kad užuot reguliariai generuodami bazinį vaizdą, nuolat jį atnaujiname. Iš esmės tai yra kopija, bet ji gauna duomenis ne iš pagrindinio kompiuterio tiesiogiai, o per archyvą. Dvejetainis archyvas, kuriame WAL yra atsisiunčiami kiekvieną dieną, kur daromos atsarginės kopijos... Tada šie WAL pasiekia bazinį vaizdą su nedideliu vėlavimu (pažodžiui 1-2 sekundes). Klonuojame iš jo bet kokiu būdu – dabar pagal nutylėjimą turime ZFS.
DS: Bet su ZFS apsiribojate vienu mazgu.
NS: Taip. Tačiau ZFS taip pat turi stebuklingą : su juo galite siųsti momentinį vaizdą ir netgi (dar tikrai neišbandžiau, bet...) galite siųsti delta tarp dviejų PGDATA. Tiesą sakant, turime dar vieną įrankį, kurio tokioms užduotims tikrai nesvarstėme. PostgreSQL turi , kuris veikia kaip „protingas“ rsync, praleidžiantis daug to, ko nereikia žiūrėti, nes ten niekas nepasikeitė. Galime atlikti greitą dviejų serverių sinchronizavimą ir atsukti atgal tuo pačiu būdu.
Taigi, iš šios, daugiau DBA pusės, mes bandome sukurti įrankį, kuris leistų daryti tą patį, ką sakėte: turime vieną duomenų bazę, bet norime ką nors išbandyti 50 kartų, beveik vienu metu.
DS: 50 kartų reiškia, kad reikia užsisakyti 50 „Spot“ egzempliorių.
NS: Ne, viską darome vienoje mašinoje.
DS: Bet kaip jūs išsiplėsite 50 kartų, jei ši viena duomenų bazė yra, tarkime, terabaitų. Greičiausiai jai reikia sąlyginės 256 GB RAM?
NS: Taip, kartais reikia daug atminties – tai normalu. Bet tai pavyzdys iš gyvenimo. Gamybos mašina turi 96 branduolius ir 600 GB. Tuo pačiu metu duomenų bazei naudojami 32 branduoliai (dabar kartais net 16 branduolių) ir 100-120 GB atminties.
DS: Ir ten telpa 50 egzempliorių?
NS: Taigi yra tik vienas egzempliorius, tada kopijavimas ant rašymo (ZFS) veikia... Papasakosiu plačiau.
Pavyzdžiui, turime 10 TB duomenų bazę. Jam padarė diską, ZFS irgi suspaudė jo dydį 30-40 procentų. Kadangi mes neatliekame apkrovos testavimo, tikslus atsakymo laikas mums nėra svarbus: tegul jis būna iki 2 kartų lėtesnis – tai gerai.
Suteikiame galimybę programuotojams, QA, DBA ir kt. atlikti bandymą 1-2 gijomis. Pavyzdžiui, jie gali vykdyti tam tikrą migraciją. Tam nereikia 10 branduolių vienu metu – reikia 1 Postgres backend, 1 branduolio. Prasidės migracija – galbūt vis tiek prasidės, tada bus naudojamas antrasis branduolys. Turime 16-32 branduolius, taigi vienu metu gali dirbti 10 žmonių, jokių problemų.
Nes fiziškai PGDATA taip pat, pasirodo, kad mes iš tikrųjų apgaudinėjame Postgresą. Triukas yra toks: pavyzdžiui, vienu metu paleidžiama 10 „Postgre“. Kas paprastai yra problema? Jie padėjo , tarkime, 25 proc. Atitinkamai, tai yra 200 GB. Negalėsite paleisti daugiau nei trijų iš jų, nes baigsis atmintis.
Bet tam tikru momentu supratome, kad tai nėra būtina: nustatėme share_buffers į 2 GB. PostgreSQL turi , o iš tikrųjų tai yra vienintelis, turintis įtakos . Nustatėme 0,5 TB. Ir net nesvarbu, kad jų iš tikrųjų nėra: jis kuria planus taip, lyg jie būtų.
Atitinkamai, kai išbandysime kažkokią migraciją, galime surinkti visus planus – žiūrėsime, kaip bus gamyboje. Sekundės ten bus skirtingos (lėtesnės), bet duomenys, kuriuos iš tikrųjų skaitome, ir patys planai (kokie ten JOIN ir pan.) pasirodo lygiai tokie patys kaip ir gamyboje. Ir jūs galite atlikti daugybę tokių patikrinimų lygiagrečiai viename kompiuteryje.
DS: Ar nemanote, kad čia yra keletas problemų? Pirmasis yra sprendimas, kuris veikia tik „PostgreSQL“. Šis požiūris yra labai privatus, jis nėra bendras. Antra, „Kubernetes“ (ir viskas, ką dabar daro debesų technologijos) apima daug mazgų, ir šie mazgai yra trumpalaikiai. Ir jūsų atveju tai yra būseną patvirtinantis, nuolatinis mazgas. Šie dalykai verčia mane prieštarauti.
NS: Pirma, sutinku, tai grynai Postgres istorija. Manau, jei turėsime kažkokį tiesioginį IO ir buferinį baseiną beveik visai atminčiai, toks požiūris nepasiteisins – planai bus kitokie. Tačiau kol kas dirbame tik su Postgres, apie kitus negalvojame.
Apie Kubernetes. Jūs pats visur mums sakote, kad turime nuolatinę duomenų bazę. Jei egzempliorius nepavyksta, svarbiausia yra išsaugoti diską. Čia taip pat turime visą platformą Kubernetes, o komponentas su Postgres yra atskiras (nors vieną dieną jis bus). Todėl viskas taip: egzempliorius nukrito, bet mes išsaugojome jo PV ir tiesiog prijungėme prie kitos (naujos) egzemplioriaus, lyg nieko nebūtų nutikę.
DS: Mano požiūriu, ankštis kuriame Kubernetes. K8s - elastingi: mazgai užsakomi pagal poreikį. Užduotis yra tiesiog sukurti podą ir pasakyti, kad jam reikia X išteklių, o tada K8s tai išsiaiškins pats. Tačiau saugyklos palaikymas „Kubernetes“ vis dar nestabilus: Į (šis leidimas buvo išleistas недели prieš) šios funkcijos tampa tik beta versija.
Praeis nuo šešių mėnesių iki metų – jis taps daugmaž stabilus arba bent jau bus deklaruotas. Tada momentinių nuotraukų ir dydžio keitimo galimybė visiškai išspręs jūsų problemą. Nes tu turi bazę. Taip, jis gali būti ne itin greitas, bet greitis priklauso nuo to, kas yra „po gaubtu“, nes kai kurios diegimo programos gali kopijuoti ir kopijuoti rašant disko posistemio lygiu.
NS: Taip pat būtina, kad visi varikliai (Amazon, Google...) pradėtų palaikyti šią versiją – tai taip pat užtrunka.
DS: Mes jų dar nenaudojame. Mes naudojame savo.
Vietinė Kubernetes plėtra
NS: Ar susidūrėte su tokiu noru, kai reikia sumontuoti visas ankštis vienoje mašinoje ir atlikti tokį nedidelį testą. Norėdami greitai gauti koncepcijos įrodymą, įsitikinkite, kad programa veikia Kubernetes, neskirdama jai daugybės įrenginių. Yra Minikube, tiesa?
DS: Man atrodo, kad ši byla – įdiegta viename mazge – yra išskirtinai susijusi su vietine plėtra. Arba kai kurios tokio modelio apraiškos. Valgyk ten , . Mes pereiname prie Kubernetes IN Docker naudojimo. Dabar pradėjome su juo dirbti bandymams.
NS: Anksčiau maniau, kad tai buvo bandymas apvynioti visus blokus į vieną Docker vaizdą. Tačiau paaiškėjo, kad čia kalbama apie visai ką kita. Šiaip yra atskiri konteineriai, atskiros ankštys – tiesiog Dockeryje.
DS: Taip. Ir yra padaryta gana juokinga imitacija, bet prasmė tokia... Turime dislokavimo įrankį - . Norime tai padaryti sąlyginiu režimu werf up: „Atnešk man vietinį Kubernetes“. Ir tada ten paleiskite sąlyginį režimą werf follow. Tada kūrėjas galės redaguoti IDE, o sistemoje bus paleistas procesas, kuris mato pakeitimus ir atkuria vaizdus, perskirstydamas juos į vietinius K8. Taip norime pabandyti išspręsti vietos plėtros problemą.
Momentinės nuotraukos ir duomenų bazių klonavimas K8 realybėje
NS: Jei grįšime prie kopijavimo-rašymo. Pastebėjau, kad debesyse taip pat yra momentinių nuotraukų. Jie veikia skirtingai. Pavyzdžiui, GCP: turite kelių terabaitų egzempliorių rytinėje JAV pakrantėje. Periodiškai darote momentines nuotraukas. Disko kopiją pasiimi vakarinėje pakrantėje iš momentinio vaizdo – per kelias minutes viskas paruošta, veikia labai greitai, tik reikia užpildyti talpyklą atmintyje. Tačiau šie klonai (momentinės nuotraukos) yra tam, kad „pateiktų“ naują tomą. Tai puiku, kai reikia sukurti daug egzempliorių.
Bet testams man atrodo, kad snapshots, apie kuriuos tu kalbi Dockere arba aš kalbu apie ZFS, btrfs ir net LVM... - leidžia nekurti tikrai naujų duomenų viename kompiuteryje. Debesyje vis tiek mokėsite už juos kiekvieną kartą ir lauksite ne sekundes, o minutes (ir tuo atveju , galbūt laikrodis).
Vietoj to, galite gauti šiuos duomenis per sekundę ar dvi, atlikti testą ir išmesti. Šios momentinės nuotraukos išsprendžia įvairias problemas. Pirmuoju atveju - padidinti mastelį ir gauti naujas kopijas, o antruoju - bandymams.
DS: Nesutinku. Užtikrinti, kad klonavimas veiktų tinkamai, yra debesies užduotis. Nežiūrėjau į jų įgyvendinimą, bet žinau, kaip tai darome aparatinėje įrangoje. Mes turime Ceph, jis leidžia bet kokį fizinį garsumą () pasakyti klonuoti ir per kelias dešimtis milisekundžių gaukite antrą tūrį su tomis pačiomis savybėmis, 'ami ir kt. Turite suprasti, kad viduje yra sudėtingas kopijavimas-rašymas. Kodėl debesis neturėtų daryti to paties? Esu tikras, kad jie vienaip ar kitaip bando tai padaryti.
NS: Tačiau jiems vis tiek prireiks sekundžių, dešimčių sekundžių, kad iškeltų egzempliorių, atvestų ten Dockerį ir pan.
DS: Kodėl reikia iškelti visą instanciją? Turime egzempliorių su 32 branduoliais, 16... ir jis gali tilpti į jį - pavyzdžiui, keturis. Kai užsakysime penktą, egzempliorius jau bus pakeltas, o tada jis bus ištrintas.
NS: Taip, įdomu, „Kubernetes“ yra kitokia istorija. Mūsų duomenų bazė nėra K8s ir turime vieną egzempliorių. Tačiau kelių terabaitų duomenų bazės klonavimas trunka ne ilgiau kaip dvi sekundes.
DS: Tai puiku. Tačiau iš pradžių noriu pasakyti, kad tai nėra bendras sprendimas. Taip, tai šaunu, bet tinka tik „Postgres“ ir tik viename mazge.
NS: Tinka ne tik Postgres: šie planai, kaip aprašiau, veiks tik jame. Bet jei mes nesijaudiname dėl planų, o mums tiesiog reikia visų duomenų funkciniams testams, tai tinka bet kuriai DBVS.
DS: Prieš daugelį metų kažką panašaus padarėme LVM momentinėse nuotraukose. Tai klasika. Šis metodas buvo labai aktyviai naudojamas. Būdingi mazgai yra tik skausmas. Nes neturėtumėte jų numesti, visada turėtumėte juos atsiminti...
NS: Ar matote čia hibrido galimybę? Tarkime, statusful yra tam tikras podas, jis veikia keliems žmonėms (daug testuotojų). Turime vieną tomą, bet dėl failų sistemos klonai yra vietiniai. Jei podukas nukrenta, bet diskas lieka, ankštis pakils, suskaičiuos informaciją apie visus klonus, vėl viską paims ir pasakys: „Štai jūsų klonai veikia šiuose prievaduose, dirbkite su jais toliau“.
DS: Techniškai tai reiškia, kad Kubernetes tai yra vienas blokas, kuriame veikia daug Postgres.
NS: Taip. Jis turi ribą: tarkime, su juo vienu metu dirba ne daugiau kaip 10 žmonių. Jei jums reikia 20, mes paleisime antrą tokį paketą. Pilnai klonuosime, gavę antrą pilną tomą, turės tuos pačius 10 „plonų“ klonų. Ar nematote šios galimybės?
DS: Čia turime pridėti saugumo problemų. Tokio tipo organizacija suponuoja, kad šis pods turi aukštas privilegijas (galimybes), nes gali atlikti nestandartines operacijas failų sistemoje... Bet kartoju: tikiu, kad vidutiniu laikotarpiu jie sutvarkys saugyklą Kubernetes, o debesis jie sutvarkys visą istoriją su tomais - viskas „tik veiks“. Bus dydžio keitimas, klonavimas... Yra tomas - sakome: „Pagal tai sukurk naują“, ir po pusantros sekundės gauname tai, ko reikia.
NS: Aš netikiu pusantros sekundės daugeliui terabaitų. Ceph jūs tai darote patys, bet kalbate apie debesis. Eikite į debesį, sukurkite kelių terabaitų EBS tūrio kloną EC2 ir pažiūrėkite, koks bus našumas. Tai neužtruks kelių sekundžių. Man labai įdomu, kada jie pasieks šį lygį. Suprantu, ką tu sakai, bet prašau kitaip.
DS: Gerai, bet aš sakiau vidutiniu laikotarpiu, o ne trumpuoju laikotarpiu. Jau keletą metų.
Apie PostgreSQL operatorių iš Zalando
Šio susitikimo viduryje Aleksejus Klyukinas, buvęs kūrėjas iš Zalando, taip pat prisijungė ir papasakojo apie PostgreSQL operatoriaus istoriją:
Puiku, kad ši tema paliečiama apskritai: ir Postgres, ir Kubernetes. Kai 2017 m. pradėjome tai daryti „Zalando“, tai buvo tema, kurią norėjo daryti visi, bet niekas to nedarė. Visi jau turėjo Kubernetes, bet paklausus, ką daryti su duomenų bazėmis, net žmonės mėgsta , kuris pamokslavo K8s, pasakė maždaug taip:
„Eikite į valdomas paslaugas ir naudokitės jomis, nepaleiskite duomenų bazės Kubernetes. Priešingu atveju jūsų K8 nuspręs, pavyzdžiui, atnaujinti, išjungti visus mazgus ir jūsų duomenys nuskris toli, toli.
Nusprendėme sukurti operatorių, kuris, priešingai nei šis patarimas, paleis Postgres duomenų bazę Kubernetes. Ir mes turėjome gerą priežastį - . Tai automatinis PostgreSQL failover, atliktas teisingai, t.y. naudojant etcd, consul arba ZooKeeper kaip informacijos apie klasterį saugyklą. Tokia saugykla, kuri kiekvienam klausiančiam, pavyzdžiui, koks dabartinis vadovas, duos tą pačią informaciją – nepaisant to, kad viską paskirstome – kad nebūtų suskilusios smegenys. Be to, mes turėjome jam.
Apskritai, įmonės automatinio perjungimo poreikis atsirado po perėjimo iš vidinio aparatinės įrangos duomenų centro į debesį. Debesis buvo pagrįstas patentuotu PaaS (Platform-as-a-Service) sprendimu. Tai atvirasis šaltinis, tačiau reikėjo daug darbo, kad jį būtų galima sukurti ir paleisti. Tai buvo pavadinta .
Iš pradžių Kubernetes nebuvo. Tiksliau, kai buvo įdiegtas mūsų sprendimas, K8 jau egzistavo, tačiau jis buvo toks žalias, kad nebuvo tinkamas gamybai. Mano nuomone, tai buvo 2015 arba 2016 m. Iki 2017 m. Kubernetes tapo daugiau ar mažiau subrendęs - ten reikėjo migruoti.
O konteinerį „Docker“ jau turėjome. Buvo „PaaS“, kuris naudojo „Docker“. Kodėl neišbandžius K8? Kodėl neparašius savo operatoriaus? Muratas Kabilovas, atvykęs pas mus iš „Avito“, savo iniciatyva pradėjo tai kaip projektą „žaisti“ ir projektas „pasirodė“.
Bet apskritai norėjau pakalbėti apie AWS. Kodėl buvo su istoriniu AWS susijęs kodas...
Kai ką nors paleidžiate Kubernetes, turite suprasti, kad K8s yra toks darbas. Jis nuolat tobulėja, tobulėja ir karts nuo karto net sugenda. Turite atidžiai stebėti visus „Kubernetes“ pokyčius, turite būti pasirengę pasinerti į tai, jei kas atsitiks, ir sužinoti, kaip tai veikia išsamiai – galbūt daugiau nei norėtumėte. Tai iš esmės taikoma bet kuriai platformai, kurioje naudojate savo duomenų bazes...
Taigi, kai padarėme pareiškimą, „Postgres“ veikė išoriniame tome (šiuo atveju EBS, nes dirbome su AWS). Duomenų bazė augo, kažkada reikėjo keisti jos dydį: pavyzdžiui, pradinis EBS dydis buvo 100 TB, duomenų bazė išaugo iki jos, dabar norime padaryti EBS 200 TB. Kaip? Tarkime, kad galite atlikti išrašymą / atkūrimą naujame egzemplioriuje, tačiau tai užtruks ilgai ir prastovos.
Todėl norėjau pakeisti dydį, kuris padidintų EBS skaidinį ir nurodytų failų sistemai naudoti naują erdvę. Ir mes tai padarėme, bet tuo metu Kubernetes neturėjo jokios API dydžio keitimo operacijai. Kadangi dirbome su AWS, parašėme kodą jos API.
Niekas netrukdo jums daryti to paties kitoms platformoms. Pareiškime nėra užuominos, kad jis gali būti paleistas tik AWS, ir jis neveiks su visa kita. Apskritai tai yra atvirojo kodo projektas: jei kas nori paspartinti naujosios API naudojimo atsiradimą, laukiame. Valgyk , traukti užklausas – Zalando komanda stengiasi gana greitai į juos atsakyti ir reklamuoti operatorių. Kiek žinau, projektas „Google Summer of Code“ ir kai kuriose kitose panašiose iniciatyvose. Zalando labai aktyviai prie to dirba.
PS premija!
Jei jus domina PostgreSQL ir Kubernetes tema, taip pat atkreipkite dėmesį, kad kitas Postgres antradienis įvyko praėjusią savaitę, kuriame kalbėjausi su Nikolajumi Aleksandras Kukuškinas iš Zalando. Yra vaizdo įrašas iš jo .
PGS
Taip pat skaitykite mūsų tinklaraštyje:
- «»;
- «»;
- «»;
- «".
Šaltinis: www.habr.com