Konec lanskega leta je potekal še en prenos v živo ruske skupnosti PostgreSQL , med katerim je njen soustanovitelj Nikolai Samokhvalov govoril s tehničnim direktorjem Flanta Dmitrijem Stolyarovim o tej DBMS v kontekstu Kubernetesa.
Objavljamo transkript osrednjega dela te razprave in pri Objavljen celoten video:
Baze podatkov in Kubernetes
НС: Danes ne bomo govorili o VAKUUMU in KONTROLNIH TOČKAH. Želimo govoriti o Kubernetesu. Vem, da imate dolgoletne izkušnje. Gledal sem vaše videoposnetke in celo ponovno pogledal nekatere od njih ... Preidimo takoj k bistvu: zakaj sploh Postgres ali MySQL v K8s?
DS: Na to vprašanje ni in ne more biti enoznačnega odgovora. Toda na splošno je to preprostost in udobje ... potencial. Vsi želijo upravljane storitve.
НС: Kako , samo doma?
DS: Da: kot RDS, kjer koli.
НС: »Kjerkoli« je dobra točka. V velikih podjetjih je vse na različnih mestih. Zakaj potem, če gre za veliko podjetje, ne bi vzeli že pripravljene rešitve? Na primer, Nutanix ima svoj razvoj, druga podjetja (VMware ...) imajo enak "RDS, samo doma."
DS: Vendar govorimo o ločeni izvedbi, ki bo delovala le pod določenimi pogoji. In če govorimo o Kubernetesu, potem obstaja ogromno različnih infrastruktur (ki so lahko v K8s). V bistvu je to standard za API-je v oblaku ...
НС: Prav tako je brezplačno!
DS: Ni tako pomembno. Brezplačnost je pomembna za ne zelo velik segment trga. Še nekaj je pomembno ... Verjetno se spomnite poročila “"?
НС: Da.
DS: Ugotovil sem, da je bilo sprejeto zelo dvoumno. Nekateri so mislili, da pravim: »Fantje, dajmo vse baze podatkov v Kubernetes!«, drugi pa so se odločili, da so to vsa grozna kolesa. Hotel pa sem povedati nekaj povsem drugega: »Poglejte, kaj se dogaja, kakšni so problemi in kako jih je mogoče rešiti. Ali naj zdaj uporabljamo baze podatkov Kubernetes? Proizvodnja? No, samo če rad počneš določene stvari. Za razvijalca pa lahko rečem, da ga priporočam. Za razvijalca je zelo pomembna dinamičnost ustvarjanja/brisanja okolij.«
NS: Ali z razvojem mislite na vsa okolja, ki niso proizvodna? Uprizoritev, QA…
DS: Če govorimo o perf stojalih, potem verjetno ne, ker so tam zahteve specifične. Če govorimo o posebnih primerih, kjer je potrebna zelo velika baza podatkov za uprizarjanje, potem verjetno ne... Če je to statično, dolgoživo okolje, kakšna je potem prednost, da se baza podatkov nahaja v K8s?
НС: Brez. Kje pa vidimo statična okolja? Statično okolje bo jutri zastarelo.
DS: Uprizoritev je lahko statična. Imamo stranke...
НС: Ja, tudi jaz imam enega. Velik problem je, če imate bazo podatkov 10 TB in 200 GB staging ...
DS: Imam zelo kul primer! Pri uprizarjanju je baza podatkov o izdelkih, v kateri se izvajajo spremembe. In tam je gumb: "uvedi v proizvodnjo". Te spremembe - delte - so dodane (zgleda, da so preprosto sinhronizirane prek API-ja) v proizvodnji. To je zelo eksotična možnost.
НС: Videl sem startupe v dolini, ki sedijo v RDS ali celo v Heroku - to so zgodbe izpred 2-3 let - in prenesejo dump na svoj prenosnik. Ker je baza še vedno samo 80 GB, na prenosniku pa je prostora. Nato vsem kupijo dodatne diske, da imajo 3 baze podatkov za izvajanje različnih razvojev. Tudi tako se zgodi. Videl sem tudi, da se ne bojijo kopirati prod v uprizoritev - zelo je odvisno od podjetja. Videla pa sem tudi, da jih je zelo strah in da pogosto nimajo dovolj časa in rok. Toda preden preidemo na to temo, želim slišati o Kubernetesu. Ali prav razumem, da še nihče ni v proizvodnji?
DS: Imamo majhne baze podatkov v izdelku. Govorimo o količinah na desetine gigabajtov in nekritičnih storitvah, za katere smo bili preleni, da bi naredili replike (in te potrebe ni). In pod pogojem, da je pod Kubernetesom normalno shranjevanje. Ta zbirka podatkov je delovala v virtualnem stroju - pogojno v VMware, na vrhu sistema za shranjevanje. Postavili smo ga noter in zdaj ga lahko prenašamo iz stroja v stroj.
НС: Podatkovne baze te velikosti, do 100 GB, je mogoče razviti v nekaj minutah na dobrih diskih in dobrem omrežju, kajne? Hitrost 1 GB na sekundo ni več eksotika.
DS: Da, za linearno delovanje to ni problem.
НС: V redu, misliti moramo samo na produkt. In če razmišljamo o Kubernetesu za neproizvodna okolja, kaj naj naredimo? To vidim v Zalandu , v Crunchyju , obstaja še nekaj drugih možnosti. In obstaja - to je naš dober prijatelj Alvaro iz Španije: to, kar počnejo, v bistvu ni samo in celotna distribucija (), v katerega so se poleg samega Postgresa odločili stlačiti tudi rezervno kopijo, proxy Envoy...
DS: Odposlanec za kaj? Posebej za uravnoteženje prometa Postgres?
НС: Da. To pomeni, da to vidijo takole: če vzamete distribucijo in jedro Linuxa, potem je jedro običajni PostgreSQL in želijo narediti distribucijo, ki bo prijazna do oblakov in bo delovala na Kubernetesu. Sestavijo komponente (varnostne kopije itd.) in jih razhroščijo, da dobro delujejo.
DS: Zelo kul! V bistvu je to programska oprema za ustvarjanje lastnega upravljanega Postgresa.
НС: Distribucije Linuxa imajo večne težave: kako narediti gonilnike, da bo podprta vsa strojna oprema. In imajo idejo, da bodo delali v Kubernetesu. Vem, da smo pri operaterju Zalando pred kratkim videli povezavo z AWS in to ni več zelo dobro. Ne bi smelo biti vezave na določeno infrastrukturo – kaj je potem smisel?
DS: Ne vem točno v kakšno situacijo je prišel Zalando, ampak v Kubernetesu je shramba sedaj narejena tako, da je nemogoče narediti backup diska z generično metodo. Nedavno v standardni - v najnovejši različici — omogočili smo posnetke, kje pa je implementiran? Iskreno povedano, vse je še tako surovo ... Preizkušamo CSI na vrhu AWS, GCE, Azure, vSphere, vendar takoj, ko ga začnete uporabljati, vidite, da še ni pripravljen.
НС: Zato se moramo včasih zanesti na infrastrukturo. Mislim, da je to še zgodnja faza - rastne bolečine. Vprašanje: Kaj bi svetovali novincem, ki želijo preizkusiti PgSQL v K8s? Kateri operater morda?
DS: Problem je, da je Postgres za nas 3 %. Tudi v Kubernetesu imamo zelo velik seznam različne programske opreme, ne bom vsega našteval. Na primer Elasticsearch. Operaterjev je veliko: nekateri se aktivno razvijajo, drugi ne. Zase smo sestavili zahteve, kaj mora biti v operaterju, da ga jemljemo resno. V operaterju posebej za Kubernetes - ne v "operaterju, ki bi naredil nekaj v Amazonovih pogojih" ... Pravzaprav precej široko (= skoraj vsi odjemalci) uporabljamo en sam operater - (o njem bomo kmalu objavili članek).
НС: In tudi ne za MySQL? Vem, da Percona ... ker zdaj delajo na MySQL, MongoDB in Postgres, bodo morali ustvariti neko univerzalno rešitev: za vse baze podatkov, za vse ponudnike oblakov.
DS: Nismo imeli časa pogledati operaterjev za MySQL. To trenutno ni naš glavni fokus. MySQL dobro deluje samostojno. Zakaj bi uporabljali operaterja, če lahko preprosto zaženete zbirko podatkov ... Vsebnik Docker lahko zaženete s Postrgesom ali pa ga zaženete na preprost način.
НС: Tudi o tem je bilo vprašanje. Sploh brez operaterja?
DS: Da, 100 % nas uporablja PostgreSQL, ki deluje brez operaterja. Zaenkrat tako. Aktivno uporabljamo operaterja za Prometheus in Redis. V načrtu imamo najti operaterja za Elasticsearch - ta je tisti, ki najbolj "gori", saj ga želimo v 100% primerih namestiti v Kubernetes. Tako kot želimo zagotoviti, da je tudi MongoDB vedno nameščen v Kubernetesu. Tu se pojavijo določene želje – obstaja občutek, da se v teh primerih da nekaj narediti. In sploh nismo pogledali Postgresa. Seveda vemo, da obstajajo različne možnosti, a dejansko imamo samostojno.
DB za testiranje v Kubernetesu
НС: Preidimo na temo testiranja. Kako uvesti spremembe v bazo podatkov – z vidika DevOps. Obstajajo mikrostoritve, veliko baz podatkov, ves čas se nekje nekaj spreminja. Kako zagotoviti normalno CI/CD, da bo vse v redu z vidika DBMS. Kakšen je vaš pristop?
DS: Ne more biti en odgovor. Možnosti je več. Prvi je velikost podlage, ki jo želimo razvaljati. Sami ste omenili, da imajo podjetja različen odnos do tega, da imajo kopijo podatkovne baze izdelkov na razvijalcu in stopnji.
НС: In glede na pogoje GDPR, se mi zdi, da so vse bolj previdni ... Lahko rečem, da so v Evropi že začeli nalagati globe.
DS: Toda pogosto lahko napišete programsko opremo, ki vzame izpis iz proizvodnje in ga zamegli. Prod podatki se pridobijo (snapshot, dump, binary copy ...), vendar so anonimizirani. Namesto tega so lahko skripti za generiranje: to so lahko stalnice ali samo skript, ki generira veliko bazo podatkov. Težava je: koliko časa traja ustvarjanje osnovne slike? In koliko časa traja, da ga umestimo v želeno okolje?
Prišli smo do sheme: če ima odjemalec fiksen nabor podatkov (minimalna različica baze podatkov), potem jih privzeto uporabimo. Če govorimo o okoljih za pregledovanje, ko smo ustvarili vejo, smo razmestili primerek aplikacije - tam uvedemo majhno bazo podatkov. Ampak se je dobro izkazalo , ko enkrat na dan (ponoči) vzamemo dump iz proizvodnje in zgradimo vsebnik Docker s PostgreSQL in MySQL s temi naloženimi podatki na njegovi podlagi. Če morate bazo podatkov razširiti 50-krat s te slike, je to narejeno preprosto in hitro.
НС: Z enostavnim kopiranjem?
DS: Podatki so shranjeni neposredno v sliki Docker. Tisti. Imamo že pripravljeno sliko, čeprav 100 GB. Zahvaljujoč slojem v Dockerju lahko to sliko hitro namestimo tolikokrat, kot jo potrebujemo. Metoda je neumna, vendar dobro deluje.
НС: Potem, ko testirate, se spremeni kar znotraj Dockerja, kajne? Copy-on-write znotraj Dockerja - zavrzite ga in pojdite znova, vse je v redu. Razred! In ga že izkoriščate do konca?
DS: Za dolgo časa.
НС: Delamo zelo podobne stvari. Samo mi ne uporabljamo Dockerjevega copy-on-write, ampak katerega drugega.
DS: Ni generično. In Docker deluje povsod.
НС: V teoriji ja. Toda tam imamo tudi module, lahko naredite različne module in delate z različnimi datotečnimi sistemi. Kakšen trenutek tukaj. S strani Postgresa gledamo na vse to drugače. Zdaj sem pogledal s strani Dockerja in videl, da ti vse deluje. Če pa je baza ogromna, na primer 1 TB, potem vse to traja dolgo: operacije ponoči, pa nabijanje vsega v Docker ... In če je 5 TB nabito v Docker ... Ali je vse v redu?
DS: Kakšna je razlika: to so blobi, samo biti in bajti.
НС: Razlika je v tem: ali to naredite prek dumpa in obnovitve?
DS: Sploh ni potrebno. Metode za ustvarjanje te slike so lahko različne.
НС: Za nekatere stranke smo naredili tako, da namesto rednega generiranja osnovne slike le-to nenehno posodabljamo. V bistvu je replika, vendar podatkov ne prejema neposredno od masterja, ampak prek arhiva. Binarni arhiv, kjer se WAL-ji prenašajo vsak dan, kjer se delajo varnostne kopije... Ti WAL-i potem z majhno zamudo (dobesedno 1-2 sekundi) dosežejo osnovno sliko. Iz njega kloniramo na kakršen koli način - zdaj imamo privzeto ZFS.
DS: Toda z ZFS ste omejeni na eno vozlišče.
НС: Da. Toda ZFS ima tudi čarobno : z njim lahko pošljete posnetek in celo (tega res še nisem preizkusil, ampak ...) lahko pošljete delto med dvema PGDATA. Pravzaprav imamo še eno orodje, ki ga za takšne naloge nismo zares upoštevali. PostgreSQL ima , ki deluje kot »pametni« rsync in preskoči veliko tistega, kar vam ni treba gledati, ker se tam ni nič spremenilo. Naredimo lahko hitro sinhronizacijo med obema strežnikoma in na enak način previjemo nazaj.
Torej, s te, bolj DBA strani, poskušamo ustvariti orodje, ki nam omogoča, da naredimo isto stvar, kot ste rekli: imamo eno bazo podatkov, vendar želimo nekaj testirati 50-krat, skoraj istočasno.
DS: 50-krat pomeni, da morate naročiti 50 primerkov Spot.
НС: Ne, vse delamo na enem stroju.
DS: Kako se boš pa 50-krat razširil, če je ta ena baza recimo terabajtna. Najverjetneje potrebuje pogojnih 256 GB RAM-a?
НС: Ja, včasih potrebuješ veliko pomnilnika - to je normalno. Ampak to je primer iz življenja. Proizvodni stroj ima 96 jeder in 600 GB. Hkrati se za bazo uporablja 32 jeder (zdaj včasih tudi 16 jeder) in 100-120 GB pomnilnika.
DS: In 50 izvodov se prilega noter?
НС: Torej obstaja samo ena kopija, potem deluje kopiranje na pisanje (ZFS) ... Povedal vam bom podrobneje.
Na primer, imamo bazo podatkov 10 TB. Zanj so naredili disk, ZFS mu je tudi velikost stisnil za 30-40 odstotkov. Ker ne izvajamo obremenitvenega testiranja, nam točen odzivni čas ni pomemben: naj bo do 2-krat počasnejši - to je v redu.
Dajemo priložnost programerjem, QA, DBA itd. izvedite testiranje v 1-2 nitih. Na primer, lahko izvajajo neke vrste migracijo. Ne potrebuje 10 jeder hkrati - potrebuje 1 zaledje Postgres, 1 jedro. Migracija se bo začela - morda se bo še vedno zagnal, potem bo uporabljeno drugo jedro. Dodeljenih imamo 16–32 jeder, tako da lahko hkrati dela 10 ljudi, ni problema.
Ker fizično PGDATA enako se izkaže, da pravzaprav zavajamo Postgres. Trik je v tem: na primer, hkrati se zažene 10 Postgresov. V čem je običajno težava? Postavili so , recimo 25%. V skladu s tem je to 200 GB. Ne boste mogli zagnati več kot treh od teh, ker bo zmanjkalo pomnilnika.
Toda na neki točki smo ugotovili, da to ni potrebno: shared_buffers smo nastavili na 2 GB. PostgreSQL ima , v resnici pa je edini, ki vpliva . Nastavili smo ga na 0,5 TB. In sploh ni pomembno, da dejansko ne obstajajo: načrtuje, kot da obstajajo.
Skladno s tem, ko testiramo kakšno migracijo, lahko zberemo vse načrte - bomo videli, kako bo v proizvodnji. Sekunde tam bodo drugačne (počasnejše), vendar podatki, ki jih dejansko beremo, in sami načrti (kateri JOIN-i so tam itd.) se izkažejo popolnoma enako kot v produkciji. Na enem računalniku lahko izvajate veliko takih preverjanj vzporedno.
DS: Se vam ne zdi, da je tukaj nekaj težav? Prva je rešitev, ki deluje samo na PostgreSQL. Ta pristop je zelo zaseben, ni splošen. Drugi je ta, da Kubernetes (in vse, kar bodo tehnologije v oblaku zdaj dosegle) vključuje veliko vozlišč in ta vozlišča so kratkotrajna. In v vašem primeru je to vztrajno vozlišče s stanjem. Zaradi teh stvari sem v konfliktu.
НС: Prvič, strinjam se, to je povsem zgodba o Postgresu. Mislim, da če imamo nekakšen neposredni IO in medpomnilniški bazen za skoraj ves pomnilnik, ta pristop ne bo deloval - načrti bodo drugačni. Ampak za zdaj delamo samo s Postgresom, o drugih ne razmišljamo.
O Kubernetesu. Sami nam povsod govorite, da imamo trajno bazo podatkov. Če primer ne uspe, je glavna stvar shraniti disk. Tukaj imamo tudi celotno platformo v Kubernetesu, komponenta s Postgresom pa je ločena (čeprav bo nekoč tam). Torej je vse tako: primerek je padel, vendar smo shranili njegov PV in ga preprosto povezali z drugim (novim) primerkom, kot da se ni nič zgodilo.
DS: Z mojega vidika ustvarjamo pode v Kubernetesu. K8s - elastika: vozli se naročajo po potrebi. Naloga je preprosto ustvariti pod in povedati, da potrebuje X količino virov, nato pa bo K8s to ugotovil sam. Toda podpora za shranjevanje v Kubernetesu je še vedno nestabilna: V (ta izdaja je bila izdana tedna pred) te funkcije postanejo le beta.
Šest mesecev do enega leta bo minilo - postalo bo bolj ali manj stabilno ali pa bo vsaj razglašeno za tako. Potem možnost posnetkov in spreminjanja velikosti popolnoma reši vašo težavo. Ker imaš bazo. Da, morda ni zelo hitro, vendar je hitrost odvisna od tega, kaj je "pod pokrovom", ker lahko nekatere implementacije kopirajo in kopirajo na pisanje na ravni diskovnega podsistema.
НС: Prav tako je potrebno, da vsi motorji (Amazon, Google...) začnejo podpirati to različico - tudi to traja nekaj časa.
DS: Ne uporabljamo jih še. Mi uporabljamo svoje.
Lokalni razvoj za Kubernetes
НС: Ali ste naleteli na takšno željo, ko morate namestiti vse pode na en stroj in narediti tako majhen test? Če želite hitro pridobiti dokaz koncepta, preverite, ali se aplikacija izvaja v Kubernetesu, ne da bi zanjo namenili kup strojev. Tukaj je Minikube, kajne?
DS: Zdi se mi, da gre pri tem primeru – razporejenem na enem vozlišču – izključno za lokalni razvoj. Ali nekatere manifestacije takega vzorca. Jejte tam , . Približujemo se uporabi Kubernetes IN Docker. Zdaj smo začeli delati z njim za teste.
НС: Včasih sem mislil, da je to poskus zavijanja vseh podov v eno Dockerjevo sliko. A izkazalo se je, da gre tu za nekaj povsem drugega. Kakorkoli že, obstajajo ločeni vsebniki, ločeni podi - samo v Dockerju.
DS: Da. In narejena je precej smešna imitacija, toda pomen je naslednji ... Imamo pripomoček za uvajanje - . Želimo, da bi bil pogojni način werf up: "Nabavite mi lokalni Kubernetes." In nato tam zaženite pogojnik werf follow. Nato bo razvijalec lahko uredil IDE in v sistemu se bo zagnal proces, ki bo videl spremembe in znova zgradil slike ter jih znova razporedil v lokalne K8. Tako želimo poskušati rešiti problem lokalnega razvoja.
Posnetki in kloniranje baze podatkov v realnosti K8s
НС: Če se vrnemo k kopiranju ob pisanju. Opazil sem, da imajo tudi oblaki posnetke. Delujejo drugače. Na primer, v GCP: imate večterabajtni primerek na vzhodni obali Združenih držav. Občasno posnamete posnetke. Iz posnetka pobereš kopijo diska na zahodni obali - v nekaj minutah je vse pripravljeno, deluje zelo hitro, samo predpomnilnik je treba napolniti v pomnilniku. Toda ti kloni (posnetki) so namenjeni 'oskrbi' novega nosilca. To je kul, ko morate ustvariti veliko primerkov.
Za teste pa se mi zdi, da posnetki, o katerih ti govoriš v Dockerju ali jaz v ZFS, btrfs in celo LVM... - omogočajo, da ne ustvariš res novih podatkov na enem stroju. V oblaku jih boste še vedno vsakič plačali in čakali ne sekunde, ampak minute (in v primeru , morda uro).
Namesto tega lahko te podatke pridobite v sekundi ali dveh, izvedete test in jih zavržete. Ti posnetki rešujejo različne težave. V prvem primeru - za povečanje in pridobivanje novih replik, v drugem pa za teste.
DS: Ne strinjam se. Naloga oblaka je zagotoviti pravilno delovanje kloniranja nosilca. Nisem si ogledal njihove izvedbe, vendar vem, kako to počnemo na strojni opremi. Imamo Ceph, omogoča poljubno fizično glasnost () povej klon in pridobite drugo glasnost z enakimi značilnostmi v desetinah milisekund, 'ami itd. Morate razumeti, da je notri zapleteno kopiranje ob pisanju. Zakaj ne bi oblak počel enako? Prepričan sem, da to poskušajo narediti tako ali drugače.
НС: Vendar bodo še vedno potrebovali sekunde, desetine sekund, da dvignejo primerek, pripeljejo Docker tja itd.
DS: Zakaj je treba dvigniti celotno instanco? Imamo primerek z 32 jedri, 16... in se da vanj - na primer štiri. Ko naročimo peto, bo instanca že dvignjena, nato pa bo izbrisana.
НС: Ja, zanimivo, Kubernetes se izkaže za drugačno zgodbo. Naša baza podatkov ni v K8s in imamo en primerek. Toda kloniranje večterabajtne baze podatkov ne traja več kot dve sekundi.
DS: To je odlično. Toda moja izhodiščna točka je, da to ni generična rešitev. Da, kul je, vendar je primeren samo za Postgres in samo na enem vozlišču.
НС: Primeren ni samo za Postgres: ti načrti, kot sem opisal, bodo delovali samo v njem. Če pa se ne obremenjujemo z načrti in potrebujemo vse podatke samo za funkcionalno testiranje, potem je to primerno za vsak DBMS.
DS: Pred mnogimi leti smo naredili nekaj podobnega na posnetkih LVM. To je klasika. Ta pristop je bil zelo aktivno uporabljen. Stalna vozlišča so samo bolečina. Ker jih ne smete izpustiti iz rok, vedno se jih morate spomniti ...
НС: Vidite tukaj kakšno možnost hibrida? Recimo, da je stateful nekakšen pod, deluje za več ljudi (veliko testerjev). Imamo en nosilec, a zahvaljujoč datotečnemu sistemu so kloni lokalni. Če podstavek pade, a disk ostane, se podstavek dvigne, prešteje podatke o vseh klonih, vse znova pobere in reče: "Tu so vaši kloni, ki tečejo na teh vratih, nadaljujte z delom z njimi."
DS: Tehnično to pomeni, da je znotraj Kubernetesa en pod, znotraj katerega izvajamo številne Postgres.
НС: Da. Ima omejitev: z njim recimo ne dela več kot 10 ljudi hkrati. Če jih potrebujete 20, bomo lansirali drugo takšno enoto. V celoti ga bomo klonirali, ko bomo prejeli drugi polni zvezek, bo imel enakih 10 "tankih" klonov. Ali ne vidite te priložnosti?
DS: Tukaj moramo dodati varnostna vprašanja. Ta vrsta organizacije pomeni, da ima ta pod visoke privilegije (zmogljivosti), ker lahko izvaja nestandardne operacije na datotečnem sistemu ... Vendar ponavljam: verjamem, da bodo srednjeročno uredili shranjevanje v Kubernetesu in v oblaki bodo popravili celotno zgodbo z volumni - vse bo “samo delalo”. Prišlo bo do spreminjanja velikosti, kloniranja ... Obstaja glasnost - rečemo: "Ustvari novo na podlagi tega," in po sekundi in pol dobimo, kar potrebujemo.
НС: Ne verjamem v sekundo in pol za veliko terabajtov. Na Cephu to narediš sam, govoriš pa o oblakih. Pojdite v oblak, naredite klon večterabajtnega nosilca EBS na EC2 in poglejte, kakšna bo zmogljivost. Ne bo trajalo nekaj sekund. Zelo me zanima, kdaj bodo dosegli to raven. Razumem, kaj govorite, vendar se ne strinjam.
DS: Ok, ampak rekel sem srednjeročno, ne kratkoročno. Že nekaj let.
O operaterju za PostgreSQL podjetja Zalando
Sredi tega srečanja se je pridružil tudi Alexey Klyukin, nekdanji razvijalec iz Zalanda, in spregovoril o zgodovini operaterja PostgreSQL:
Super je, da se te teme dotakne na splošno: tako Postgres kot Kubernetes. Ko smo leta 2017 na Zalandu začeli s tem, je bila to tema, ki so jo vsi želeli narediti, a je ni nihče naredil. Vsi so že imeli Kubernetes, a ko so vprašali, kaj storiti z bazami podatkov, je celo ljudem všeč , ki je pridigal K8s, je rekel nekaj takega:
»Pojdite na upravljane storitve in jih uporabite, ne izvajajte baze podatkov v Kubernetesu. V nasprotnem primeru se bodo vaši K8 odločili na primer za nadgradnjo, izklopili vsa vozlišča in vaši podatki bodo odleteli daleč, daleč stran.”
Odločili smo se narediti operaterja, ki bo v nasprotju s tem nasvetom zagnal Postgresovo bazo v Kubernetesu. In imeli smo dober razlog - . To je samodejni preklop za PostgreSQL, izveden pravilno, tj. uporaba etcd, consul ali ZooKeeper kot shranjevanja informacij o gruči. Takšen repozitorij, ki bo vsem, ki bodo na primer vprašali, kaj je trenutni vodja, dal enake informacije – kljub temu, da imamo vse razdeljeno –, da ne bo razcepljenih možganov. Poleg tega smo imeli zanj.
Na splošno se je potreba podjetja po samodejnem preklopu pojavila po selitvi iz notranjega podatkovnega centra strojne opreme v oblak. Oblak je temeljil na lastniški rešitvi PaaS (Platforma-as-a-Service). Je odprtokoden, vendar je bilo potrebno veliko dela, da je začel delovati. Imenoval se je .
Na začetku ni bilo Kubernetesa. Natančneje, ko je bila uvedena lastna rešitev, je K8 že obstajal, vendar je bil tako surov, da ni bil primeren za proizvodnjo. Bilo je po mojem 2015 ali 2016. Do leta 2017 je Kubernetes postal bolj ali manj zrel - pojavila se je potreba po selitvi tja.
In Docker posodo smo že imeli. Obstajal je PaaS, ki je uporabljal Docker. Zakaj ne bi preizkusili K8s? Zakaj ne bi napisal svojega operaterja? Murat Kabilov, ki je prišel k nam iz Avita, je to začel kot projekt na lastno pobudo - »igrati« - in projekt je »vzletel«.
Toda na splošno sem želel govoriti o AWS. Zakaj je obstajala zgodovinska koda, povezana z AWS ...
Ko izvajate nekaj v Kubernetesu, morate razumeti, da je K8s tako delo v teku. Nenehno se razvija, izboljšuje in občasno celo pokvari. Pozorno morate spremljati vse spremembe v Kubernetesu, biti morate pripravljeni, da se poglobite vanj, če se kaj zgodi, in se podrobno naučite, kako deluje – morda več, kot bi si želeli. To načeloma velja za vsako platformo, na kateri poganjate svoje baze podatkov...
Torej, ko smo naredili izjavo, smo imeli Postgres, ki je deloval na zunanjem nosilcu (v tem primeru EBS, ker smo delali na AWS). Podatkovna baza je rasla, na neki točki jo je bilo treba spremeniti: na primer, prvotna velikost EBS je bila 100 TB, baza podatkov je zrasla do tega, zdaj želimo EBS narediti 200 TB. kako Recimo, da lahko naredite izpis/obnovitev na novem primerku, vendar bo to trajalo dolgo in vključevalo izpade.
Zato sem želel spremembo velikosti, ki bi povečala particijo EBS in nato sporočila datotečnemu sistemu, naj uporabi nov prostor. In uspelo nam je, vendar Kubernetes takrat ni imel API-ja za operacijo spreminjanja velikosti. Ker smo delali na AWS, smo napisali kodo za njegov API.
Nihče vam ne brani, da storite enako za druge platforme. V izjavi ni nobenega namiga, da ga je mogoče izvajati samo na AWS in da ne bo deloval na vseh ostalih. Na splošno je to odprtokodni projekt: če kdo želi pospešiti nastanek uporabe novega API-ja, je dobrodošel. Jejte , zahteve po vleku - ekipa Zalando se trudi nanje odgovoriti precej hitro in promovirati operaterja. Kolikor vem, projekt na Google Summer of Code in nekaterih drugih podobnih pobudah. Zalando zelo aktivno dela na tem.
PS bonus!
Če vas zanima tema PostgreSQL in Kubernetes, potem upoštevajte tudi, da je prejšnji teden potekal naslednji Postgres torek, kjer sem govoril z Nikolajem Aleksander Kukuškin iz Zalanda. Video z njega je na voljo .
PPS
Preberite tudi na našem blogu:
- «»;
- «»;
- «»;
- «".
Vir: www.habr.com