Viime vuoden lopussa tapahtui toinen suora lähetys venäläisestä PostgreSQL-yhteisöstä , jonka aikana sen toinen perustaja Nikolai Samokhvalov puhui Flantin teknisen johtajan Dmitri Stolyarovin kanssa tästä DBMS:stä Kubernetesin yhteydessä.
Julkaisemme tämän keskustelun pääosan kopiot klo Koko video julkaistu:
Tietokannat ja Kubernetes
NS: Emme puhu tänään tyhjiöstä ja TARKISTUSPISTEITÄ. Haluamme puhua Kubernetesista. Tiedän, että sinulla on monen vuoden kokemus. Katsoin videosi ja jopa katselin niitä uudelleen... Mennään suoraan asiaan: miksi Postgres tai MySQL ylipäätään K8s:ssa?
DS: Tähän kysymykseen ei ole eikä voi olla varmaa vastausta. Mutta yleisesti ottaen tämä on yksinkertaisuus ja mukavuus... potentiaalia. Kaikki haluavat hallittuja palveluita.
NS: Miten , vain kotona?
DS: Kyllä: kuten RDS, missä tahansa.
NS: "Missä tahansa" on hyvä pointti. Suurissa yrityksissä kaikki sijaitsee eri paikoissa. Miksi sitten, jos kyseessä on suuri yritys, ei oteta valmiita ratkaisuja? Esimerkiksi Nutanixilla on omat kehitystyönsä, muilla yrityksillä (VMware...) on sama "RDS, vain kotona".
DS: Puhumme kuitenkin erillisestä toteutuksesta, joka toimii vain tietyissä olosuhteissa. Ja jos puhumme Kubernetesista, siellä on valtava valikoima infrastruktuuria (joka voi olla K8:ssa). Pohjimmiltaan tämä on standardi sovellusliittymille pilveen...
NS: Se on myös ilmainen!
DS: Se ei ole niin tärkeää. Freeness on tärkeää ei kovin suurelle segmentille markkinoita. Jokin muu on tärkeää... Muistat varmaan raportin ""?
NS: Joo.
DS: Ymmärsin, että se otettiin hyvin epäselvästi vastaan. Jotkut luulivat minun sanovan: "Kaverit, laitetaan kaikki tietokannat Kubernetesiin!", kun taas toiset päättivät, että nämä olivat kaikki kauheita polkupyöriä. Mutta halusin sanoa jotain aivan muuta: "Katso mitä tapahtuu, mitä ongelmia siellä on ja miten ne voidaan ratkaista. Pitäisikö meidän nyt käyttää Kubernetes-tietokantoja? Tuotanto? No, vain jos haluat... tehdä tiettyjä asioita. Mutta kehittäjälle voin sanoa, että suosittelen sitä. Kehittäjälle ympäristöjen luomisen/poistamisen dynaamisuus on erittäin tärkeää."
NS: Tarkoitatko kehittäjillä kaikkia ympäristöjä, jotka eivät ole tuotannollisia? Lavastus, laadunvarmistus…
DS: Jos puhumme perf-telineistä, niin luultavasti ei, koska siellä on erityisiä vaatimuksia. Jos puhumme erikoistapauksista, joissa lavastukseen tarvitaan erittäin suuri tietokanta, niin luultavasti ei... Jos tämä on staattinen, pitkäikäinen ympäristö, niin mitä hyötyä on siitä, että tietokanta sijaitsee K8:ssa?
NS: Ei mitään. Mutta missä näemme staattiset ympäristöt? Staattinen ympäristö vanhenee huomenna.
DS: Lavastus voi olla staattista. Meillä on asiakkaita...
NS: Kyllä, minullakin on sellainen. Se on iso ongelma, jos sinulla on 10 Tt tietokanta ja 200 Gt lavastus...
DS: Minulla on erittäin hieno tapaus! Lavastusvaiheessa on tuotetietokanta, johon tehdään muutoksia. Ja siellä on painike: "rullaa tuotantoon". Nämä muutokset - deltat - lisätään (näyttää siltä, että ne on vain synkronoitu API:n kautta) tuotannossa. Tämä on erittäin eksoottinen vaihtoehto.
NS: Olen nähnyt laaksossa startuppeja, jotka istuvat RDS:ssä tai jopa Herokussa - nämä ovat tarinoita 2-3 vuoden takaa - ja he lataavat kaatopaikan kannettavalle tietokoneelleen. Koska tietokanta on edelleen vain 80 Gt, ja kannettavassa tietokoneessa on tilaa. Sitten he ostavat lisälevyjä kaikille, jotta heillä on 3 tietokantaa erilaisten kehitysten toteuttamista varten. Näin myös tapahtuu. Huomasin myös, että he eivät pelkää kopioida tuotantoa lavastukseen - se riippuu paljon yrityksestä. Mutta huomasin myös, että he pelkäävät kovasti ja että heillä ei useinkaan ole tarpeeksi aikaa ja käsiä. Mutta ennen kuin siirrymme tähän aiheeseen, haluan kuulla Kubernetesista. Ymmärsinkö oikein, että kukaan ei ole vielä prodissa?
DS: Meillä on pienet tietokannat tuotannossa. Puhumme kymmenien gigatavujen määristä ja ei-kriittisistä palveluista, joille olimme liian laiskoja tekemään kopioita (eikä sellaista tarvetta ole). Ja edellyttäen, että Kubernetesin alla on normaalia tallennustilaa. Tämä tietokanta toimi virtuaalikoneessa - ehdollisesti VMwaressa, tallennusjärjestelmän päällä. Laitoimme sen sisään ja nyt voimme siirtää sen koneelta koneelle.
NS: Tämän kokoiset, jopa 100 Gt:n tietokannat voidaan ottaa käyttöön muutamassa minuutissa hyvillä levyillä ja hyvässä verkossa, eikö niin? Nopeus 1 Gt sekunnissa ei ole enää eksoottinen.
DS: Kyllä, lineaarisessa käytössä tämä ei ole ongelma.
NS: Okei, meidän täytyy vain ajatella tuotantoa. Ja jos harkitsemme Kubernetesia muihin kuin tuotantoympäristöihin, mitä meidän pitäisi tehdä? Näin Zalandossa , Crunchyssa , on muitakin vaihtoehtoja. Ja siellä on - Tämä on hyvä ystävämme Alvaro Espanjasta: se, mitä he tekevät, ei ole pohjimmiltaan vain ja koko jakelu (), johon itse Postgresin lisäksi päätettiin laittaa varmuuskopio, Envoy-välityspalvelin...
DS: lähettiläs mitä varten? Tasapainotetaanko erityisesti Postgres-liikennettä?
NS: Joo. Toisin sanoen he näkevät sen seuraavasti: jos otat Linux-jakelun ja ytimen, niin tavallinen PostgreSQL on ydin, ja he haluavat tehdä jakelun, joka on pilviystävällinen ja toimii Kubernetesissa. He kokoavat komponentteja (varmuuskopiot jne.) ja korjaavat ne, jotta ne toimivat hyvin.
DS: Todella siistiä! Pohjimmiltaan tämä on ohjelmisto, jolla voit luoda oman hallitun Postgresin.
NS: Linux-jakeluissa on ikuisia ongelmia: kuinka tehdä ohjaimia niin, että kaikki laitteistot ovat tuettuja. Ja heillä on ajatus, että he työskentelevät Kubernetesissa. Tiedän, että Zalando-operaattorilla näimme äskettäin yhteyden AWS:ään, ja tämä ei ole enää kovin hyvä. Tiettyyn infrastruktuuriin ei pitäisi liittyä – mitä järkeä sitten on?
DS: En tiedä tarkalleen, mihin tilanteeseen Zalando joutui, mutta Kubernetesissa tallennus on nyt tehty niin, että levyn varmuuskopiointi ei ole mahdollista geneerisellä menetelmällä. Äskettäin vakiona - uusimmassa versiossa — teimme tilannekuvia mahdollisiksi, mutta missä se toteutetaan? Rehellisesti sanottuna kaikki on vielä niin raakaa... Kokeilemme CSI:tä AWS:n, GCE:n, Azuren, vSpheren päälle, mutta heti kun aloitat sen käytön, huomaat, että se ei ole vielä valmis.
NS: Siksi meidän on joskus turvauduttava infrastruktuuriin. Luulen, että tämä on vielä alkuvaihe - kasvukivut. Kysymys: Mitä neuvoja antaisit aloittelijoille, jotka haluavat kokeilla PgSQL:ää K8:ssa? Mikä operaattori ehkä?
DS: Ongelma on, että Postgres on meille 3 %. Meillä on myös erittäin laaja luettelo eri ohjelmistoista Kubernetesissa, en edes luettele kaikkea. Esimerkiksi Elasticsearch. Toimijoita on paljon: toiset kehittyvät aktiivisesti, toiset eivät. Olemme laatineet itsellemme vaatimukset, mitä operaattorissa pitäisi olla, jotta otamme sen vakavasti. Erityisesti Kubernetesille tarkoitetussa operaattorissa - ei "operaattorissa, joka tekee jotain Amazonin olosuhteissa"... Itse asiassa käytämme melko laajalti (= melkein kaikki asiakkaat) yhtä operaattoria - (Julkaisemme hänestä artikkelin pian).
NS: Eikä myöskään MySQL:lle? Tiedän, että Percona... koska he työskentelevät nyt MySQL:n, MongoDB:n ja Postgresin parissa, heidän on luotava jonkinlainen universaali ratkaisu: kaikille tietokannoille, kaikille pilvipalveluntarjoajille.
DS: Meillä ei ollut aikaa tarkastella MySQL:n operaattoreita. Tämä ei ole pääpainopisteemme tällä hetkellä. MySQL toimii hyvin itsenäisenä. Miksi käyttää operaattoria, jos voit käynnistää vain tietokannan... Voit käynnistää Docker-kontin Postrgesin avulla tai käynnistää sen yksinkertaisella tavalla.
NS: Tästäkin oli kysymys. Ei operaattoria ollenkaan?
DS: Kyllä, 100 %:lla meistä PostgreSQL on käynnissä ilman operaattoria. Toistaiseksi niin. Käytämme aktiivisesti operaattoria Prometheukselle ja Redikselle. Suunnittelemme Elasticsearchille operaattorin löytämistä - se on se, joka on eniten "palossa", koska haluamme asentaa sen Kubernetesiin 100% tapauksista. Aivan kuten haluamme varmistaa, että myös MongoDB on aina asennettu Kubernetesiin. Täällä ilmestyvät tietyt toiveet - on tunne, että näissä tapauksissa voidaan tehdä jotain. Emmekä edes katsoneet Postgresia. Tietenkin tiedämme, että on olemassa erilaisia vaihtoehtoja, mutta itse asiassa meillä on erillinen.
DB testattavaksi Kubernetesissa
NS: Jatketaan testauksen aiheeseen. Muutosten käyttöönotto tietokantaan - DevOps-näkökulmasta. On mikropalveluita, monia tietokantoja, jotain muuttuu jossain koko ajan. Kuinka varmistaa normaali CI/CD, jotta kaikki on kunnossa DBMS:n näkökulmasta. Mikä on lähestymistapasi?
DS: Ei voi olla yhtä vastausta. Vaihtoehtoja on useita. Ensimmäinen on pohjan koko, jonka haluamme rullata. Mainitsit itse, että yrityksillä on erilaisia asenteita prod-tietokannan kopioimiseen kehitystyössä ja lavalla.
NS: Ja GDPR:n olosuhteissa uskon, että he ovat yhä varovaisempia... Voin sanoa, että Euroopassa on jo alettu määrätä sakkoja.
DS: Mutta usein voit kirjoittaa ohjelmistoja, jotka poistavat tuotannon ja hämärtävät sen. Tuotantotiedot saadaan (snapshot, dump, binary copy...), mutta ne anonymisoidaan. Sen sijaan voi olla sukupolven komentosarjoja: ne voivat olla kiinnikkeitä tai vain komentosarja, joka luo suuren tietokannan. Ongelmana on: kuinka kauan peruskuvan luominen kestää? Ja kuinka kauan kestää ottaa se käyttöön halutussa ympäristössä?
Pääsimme kaavaan: jos asiakkaalla on kiinteä tietojoukko (tietokannan minimiversio), käytämme niitä oletuksena. Jos puhumme tarkistusympäristöistä, kun loimme haaran, otimme käyttöön sovelluksen esiintymän - otamme siellä käyttöön pienen tietokannan. Mutta hyvin siitä tuli , kun otamme kaatopaikan tuotannosta kerran päivässä (yöllä) ja rakennamme Docker-kontin PostgreSQL:llä ja MySQL:llä näillä sen perusteella ladatuilla tiedoilla. Jos sinun on laajennettava tietokantaa 50 kertaa tästä kuvasta, se tehdään melko yksinkertaisesti ja nopeasti.
NS: Yksinkertaisella kopioinnilla?
DS: Tiedot tallennetaan suoraan Docker-kuvaan. Nuo. Meillä on valmis kuva, vaikkakin 100 Gt. Dockerin tasojen ansiosta voimme nopeasti ottaa tämän kuvan käyttöön niin monta kertaa kuin tarvitsemme. Menetelmä on typerä, mutta se toimii hyvin.
NS: Sitten kun testaat, se muuttuu aivan Dockerin sisällä, eikö niin? Kopioi ja kirjoita Dockerin sisällä - heitä se pois ja mene uudelleen, kaikki on kunnossa. Luokka! Ja käytätkö sitä jo täysillä?
DS: Pitkään aikaan.
NS: Teemme hyvin samanlaisia asioita. Emme vain käytä Dockerin kopiointia, vaan jotain muuta.
DS: Se ei ole yleinen. Ja Docker toimii kaikkialla.
NS: Teoriassa kyllä. Mutta meillä on siellä myös moduuleja, voit tehdä erilaisia moduuleja ja työskennellä eri tiedostojärjestelmien kanssa. Mikä hetki tässä. Postgresin puolelta katsomme kaiken tämän eri tavalla. Nyt katsoin Dockerin puolelta ja näin, että kaikki toimii sinulle. Mutta jos tietokanta on valtava, esim. 1 TB, niin tämä kaikki kestää kauan: operaatiot yöllä ja kaiken pakkaaminen Dockeriin... Ja jos 5 TB laitetaan Dockeriin... Vai onko kaikki hyvin?
DS: Mitä eroa on: nämä ovat blobeja, vain bittejä ja tavuja.
NS: Ero on tämä: teetkö sen dump and palautuksen kautta?
DS: Ei ollenkaan tarpeellista. Tämän kuvan luontimenetelmät voivat olla erilaisia.
NS: Joillekin asiakkaille olemme tehneet niin, että sen sijaan, että luomme säännöllisesti peruskuvaa, pidämme sen jatkuvasti ajan tasalla. Se on pohjimmiltaan kopio, mutta se ei vastaanota tietoja suoraan isännältä, vaan arkiston kautta. Binaariarkisto, johon WAL-tiedostoja ladataan joka päivä, johon otetaan varmuuskopiot... Nämä WAL-tiedostot saavuttavat peruskuvan pienellä viiveellä (kirjaimellisesti 1-2 sekuntia). Kloonaamme siitä millä tahansa tavalla - nyt meillä on oletuksena ZFS.
DS: Mutta ZFS:ssä olet rajoitettu yhteen solmuun.
NS: Joo. Mutta ZFS:llä on myös maaginen : sen avulla voit lähettää tilannekuvan ja jopa (en ole vielä varsinaisesti testannut tätä, mutta...) voit lähettää delta kahden välillä PGDATA. Itse asiassa meillä on toinen työkalu, jota emme ole todella harkinneet tällaisiin tehtäviin. PostgreSQL:llä on , joka toimii kuin "älykäs" rsync, ohittaen paljon siitä, mitä sinun ei tarvitse katsoa, koska mikään ei ole muuttunut siellä. Voimme tehdä nopean synkronoinnin kahden palvelimen välillä ja kelata taaksepäin samalla tavalla.
Joten tältä, enemmän DBA-puolelta, yritämme luoda työkalun, jonka avulla voimme tehdä saman, mitä sanoit: meillä on yksi tietokanta, mutta haluamme testata jotain 50 kertaa, melkein samanaikaisesti.
DS: 50 kertaa tarkoittaa, että sinun on tilattava 50 Spot-instanssia.
NS: Ei, teemme kaiken yhdellä koneella.
DS: Mutta kuinka aiot laajentaa 50 kertaa, jos tämä yksi tietokanta on esimerkiksi teratavu. Todennäköisesti hän tarvitsee ehdollisen 256 Gt RAM-muistia?
NS: Kyllä, joskus tarvitset paljon muistia - se on normaalia. Mutta tämä on esimerkki elämästä. Tuotantokoneessa on 96 ydintä ja 600 Gt. Samaan aikaan tietokannassa käytetään 32 ydintä (jopa 16 ydintä nyt joskus) ja 100-120 Gt muistia.
DS: Ja 50 kopiota mahtuu sinne?
NS: On siis vain yksi kopio, sitten kopiointi-kirjoitus (ZFS) toimii... Kerron sinulle tarkemmin.
Meillä on esimerkiksi 10 TB:n tietokanta. He tekivät sille levyn, ZFS myös pakkasi sen kokoa 30-40 prosenttia. Koska emme tee kuormitustestausta, tarkka vasteaika ei ole meille tärkeä: olkoon se jopa 2 kertaa hitaampi - se on okei.
Annamme mahdollisuuden ohjelmoijille, QA:lle, DBA:lle jne. testaa 1-2 säiettä. He voivat esimerkiksi suorittaa jonkinlaista siirtoa. Se ei vaadi 10 ydintä kerralla - se tarvitsee 1 Postgres-taustajärjestelmän, 1 ytimen. Muuttoliike alkaa - ehkä käynnistyy edelleen, sitten käytetään toista ydintä. Meillä on varattu 16-32 ydintä, joten 10 henkilöä voi työskennellä samaan aikaan, ei hätää.
Koska fyysisesti PGDATA Samoin käy ilmi, että me itse asiassa huijaamme Postgresia. Temppu on tämä: esimerkiksi 10 Postgrea käynnistetään samanaikaisesti. Mikä on yleensä ongelma? He laittoivat , oletetaan 25 %. Vastaavasti tämä on 200 Gt. Et voi käynnistää enempää kuin kolmea näistä, koska muisti loppuu.
Mutta jossain vaiheessa ymmärsimme, että tämä ei ollut välttämätöntä: asetimme share_buffers 2 Gt:ksi. PostgreSQL:llä on , ja todellisuudessa se on ainoa, joka vaikuttaa . Asetamme sen arvoon 0,5 TB. Eikä sillä ole edes väliä, ettei niitä todellisuudessa ole olemassa: hän tekee suunnitelmia ikään kuin ne olisivat olemassa.
Vastaavasti kun testaamme jonkinlaista migraatiota, voimme kerätä kaikki suunnitelmat - katsotaan kuinka se tapahtuu tuotannossa. Siellä olevat sekunnit ovat erilaisia (hitaampia), mutta tosiasiallisesti lukemamme tiedot ja itse suunnitelmat (mitä JOINeja siellä on jne.) osoittautuvat täsmälleen samaksi kuin tuotannossa. Ja voit suorittaa useita tällaisia tarkastuksia rinnakkain yhdellä koneella.
DS: Etkö usko, että tässä on joitain ongelmia? Ensimmäinen on ratkaisu, joka toimii vain PostgreSQL:ssä. Tämä lähestymistapa on hyvin yksityinen, se ei ole yleinen. Toinen on se, että Kubernetes (ja kaikki, mitä pilviteknologiat nyt tekevät) sisältää monia solmuja, ja nämä solmut ovat lyhytaikaisia. Ja sinun tapauksessasi se on tilallinen, pysyvä solmu. Nämä asiat saavat minut ristiriitaiseksi.
NS: Ensinnäkin, olen samaa mieltä, tämä on puhtaasti Postgresin tarina. Luulen, että jos meillä on jonkinlainen suora IO ja puskurivarasto melkein koko muistille, tämä lähestymistapa ei toimi - suunnitelmat ovat erilaisia. Mutta toistaiseksi työskentelemme vain Postgresin kanssa, emme ajattele muita.
Tietoja Kubernetesista. Itse kerrot meille kaikkialla, että meillä on pysyvä tietokanta. Jos ilmentymä epäonnistuu, tärkeintä on tallentaa levy. Täällä meillä on myös koko alusta Kubernetesissa, ja Postgres-komponentti on erillinen (vaikka se on siellä jonain päivänä). Siksi kaikki on näin: ilmentymä putosi, mutta me tallensimme sen PV:n ja yksinkertaisesti liitimme sen toiseen (uuteen) ilmentymään, ikään kuin mitään ei olisi tapahtunut.
DS: Minun näkökulmastani luomme paloja Kubernetesissa. K8s - elastinen: solmut tilataan tarpeen mukaan. Tehtävänä on yksinkertaisesti luoda pod ja sanoa, että se tarvitsee X määrän resursseja, ja sitten K8s selvittää sen itse. Mutta tallennustuki Kubernetesissa on edelleen epävakaa: Sisään (tämä julkaisu julkaistiin недели sitten) näistä ominaisuuksista tulee vain beta.
Kuudesta kuukaudesta vuoteen kuluu - siitä tulee enemmän tai vähemmän vakaa, tai ainakin se julistetaan sellaiseksi. Sitten tilannekuvien ja koon muuttamisen mahdollisuus ratkaisee ongelmasi kokonaan. Koska sinulla on tukikohta. Kyllä, se ei ehkä ole kovin nopea, mutta nopeus riippuu siitä, mikä on "konepellin alla", koska jotkut toteutukset voivat kopioida ja kopioida kirjoitettaessa levyalijärjestelmätasolla.
NS: On myös välttämätöntä, että kaikki moottorit (Amazon, Google...) alkavat tukea tätä versiota - tämäkin kestää jonkin aikaa.
DS: Emme käytä niitä vielä. Käytämme omaamme.
Paikallinen kehitys Kubernetesille
NS: Oletko törmännyt sellaiseen toiveeseen, kun sinun täytyy asentaa kaikki kotelot yhteen koneeseen ja tehdä niin pieni testi. Saat nopeasti todisteen konseptista varmistamalla, että sovellus toimii Kubernetesissa ilman, että sille on varattu joukkoa koneita. Siellä on Minikube, eikö?
DS: Minusta näyttää siltä, että tämä tapaus - sijoitettuna yhteen solmuun - koskee yksinomaan paikallista kehitystä. Tai jotkin tällaisen mallin ilmentymät. Syödä siellä , . Olemme siirtymässä Kubernetes IN Dockerin käyttöön. Nyt aloimme työskennellä sen kanssa testejä varten.
NS: Ajattelin ennen, että tämä oli yritys kääriä kaikki podit yhteen Docker-kuvaan. Mutta kävi ilmi, että tässä on kyse jostain aivan muusta. Joka tapauksessa, siellä on erilliset säiliöt, erilliset kotelot - vain Dockerissa.
DS: Joo. Ja siitä on tehty melko hassu jäljitelmä, mutta tarkoitus on tämä... Meillä on apuohjelma käyttöönottoa varten - . Haluamme tehdä siitä ehdollisen tilan werf up: "Hae minulle paikallinen Kubernetes." Ja sitten suorita ehto siellä werf follow. Sitten kehittäjä voi muokata IDE:tä, ja järjestelmässä käynnistetään prosessi, joka näkee muutokset ja rakentaa kuvat uudelleen ja sijoittaa ne uudelleen paikallisiin K8-laitteisiin. Tällä tavalla haluamme yrittää ratkaista paikallisen kehityksen ongelman.
Tilannekuvat ja tietokantojen kloonaus K8s-todellisuudessa
NS: Jos palaamme kopiointi-kirjoitus-tilaan. Huomasin, että pilvissä on myös tilannekuvia. Ne toimivat eri tavalla. Esimerkiksi GCP:ssä: sinulla on usean teratavun ilmentymä Yhdysvaltojen itärannikolla. Otat tilannekuvia ajoittain. Otat kopion levystä länsirannikolta tilannekuvasta - muutamassa minuutissa kaikki on valmis, se toimii erittäin nopeasti, vain välimuisti on täytettävä muistiin. Mutta nämä kloonit (snapshots) ovat uuden osan "varmistamiseksi". Tämä on siistiä, kun sinun on luotava paljon esiintymiä.
Mutta testejä varten minusta näyttää siltä, että tilannekuvat, joista puhut Dockerissa tai minä puhun ZFS:ssä, btrfs:ssä ja jopa LVM:ssä... - niiden avulla ei voi luoda todella uutta dataa yhdelle koneelle. Pilvessä maksat niistä silti joka kerta etkä odota sekunteja, vaan minuutteja (ja siinä tapauksessa , mahdollisesti kello).
Sen sijaan voit saada nämä tiedot sekunnissa tai kahdessa, suorittaa testin ja heittää ne pois. Nämä tilannekuvat ratkaisevat erilaisia ongelmia. Ensimmäisessä tapauksessa - skaalaamaan ja hankkimaan uusia kopioita, ja toisessa - testejä varten.
DS: En ole samaa mieltä. Volyymikloonauksen saaminen toimimaan oikein on pilven tehtävä. En ole katsonut niiden toteutusta, mutta tiedän kuinka teemme sen laitteistolla. Meillä on Ceph, se mahdollistaa minkä tahansa fyysisen äänenvoimakkuuden () sanoa klooni ja saat toisen tilavuuden samoilla ominaisuuksilla kymmenissä millisekunneissa, 'ami jne. Sinun on ymmärrettävä, että sisällä on hankala kopiointi-kirjoitus. Miksei pilvi tekisi samoin? Olen varma, että he yrittävät tehdä tämän tavalla tai toisella.
NS: Mutta heiltä kestää silti sekunteja, kymmeniä sekunteja instanssin nostamiseen, Dockerin tuomiseen sinne jne.
DS: Miksi on tarpeen nostaa kokonainen esiintymä? Meillä on instanssi, jossa on 32 ydintä, 16... ja se mahtuu siihen - esimerkiksi neljä. Kun tilaamme viidennen, ilmentymä nostetaan jo ylös ja sitten se poistetaan.
NS: Kyllä, mielenkiintoista, Kubernetes osoittautuu eri tarinaksi. Tietokantamme ei ole K8s:ssa, ja meillä on yksi esiintymä. Mutta usean teratavun tietokannan kloonaus kestää enintään kaksi sekuntia.
DS: Tämä on suurenmoista. Mutta ensimmäinen pointtini on, että tämä ei ole yleinen ratkaisu. Kyllä, se on siistiä, mutta se sopii vain Postgresille ja vain yhteen solmuun.
NS: Se ei sovellu vain Postgresille: nämä suunnitelmat, kuten kuvailin, toimivat vain siinä. Mutta jos emme välitä suunnitelmista, vaan tarvitsemme vain kaikki tiedot toiminnallista testausta varten, tämä sopii mihin tahansa DBMS:ään.
DS: Monta vuotta sitten teimme jotain vastaavaa LVM-snapshot-kuvissa. Tämä on klassikko. Tätä lähestymistapaa käytettiin erittäin aktiivisesti. Tilalliset solmut ovat vain tuskaa. Koska niitä ei pidä pudottaa, sinun tulee aina muistaa ne...
NS: Näetkö tässä mitään mahdollisuutta hybridille? Oletetaan, että stateful on jonkinlainen pod, se toimii useille ihmisille (monille testaajille). Meillä on yksi taltio, mutta tiedostojärjestelmän ansiosta kloonit ovat paikallisia. Jos pod putoaa, mutta levy jää, pod nousee, laskee tiedot kaikista klooneista, poimii kaiken uudelleen ja sanoo: "Tässä ovat kloonisi, jotka toimivat näissä porteissa, jatka työskentelyä niiden kanssa."
DS: Teknisesti tämä tarkoittaa, että Kubernetesissa se on yksi pod, jossa käytämme monia Postgres.
NS: Joo. Hänellä on raja: Oletetaan, että hänen kanssaan työskentelee enintään 10 henkilöä samanaikaisesti. Jos tarvitset 20, lanseeraamme toisen sellaisen kotelon. Kloonaamme sen kokonaan, saatuaan toisen täyden osan, siinä on samat 10 "ohutta" kloonia. Etkö näe tätä mahdollisuutta?
DS: Meidän on lisättävä tähän turvallisuusongelmia. Tämän tyyppinen organisaatio tarkoittaa, että tällä podilla on korkeat oikeudet (ominaisuudet), koska se voi suorittaa epästandardeja toimintoja tiedostojärjestelmässä... Mutta toistan: uskon, että keskipitkällä aikavälillä ne korjaavat Kubernetesin tallennustilan ja pilvet he korjaavat koko tarinan volyymeillä - kaikki "vain toimii". Tulee kokoa, kloonausta... On volyymi - sanomme: "Luo uusi sen perusteella", ja puolentoista sekunnin kuluttua saamme tarvitsemamme.
NS: En usko puoleentoista sekuntiin monen teratavun kohdalla. Cephilla teet sen itse, mutta puhut pilvista. Mene pilveen, tee klooni usean teratavun EBS-taltiosta EC2:ssa ja katso, millainen suorituskyky on. Se ei vie muutamaa sekuntia. Olen erittäin kiinnostunut, milloin he saavuttavat tämän tason. Ymmärrän mitä tarkoitat, mutta olen eri mieltä.
DS: Ok, mutta sanoin keskipitkällä aikavälillä, en lyhyellä aikavälillä. Useita vuosia.
Tietoja Zalandon PostgreSQL-operaattorista
Keskellä tätä tapaamista myös Zalandon entinen kehittäjä Alexey Klyukin liittyi mukaan ja puhui PostgreSQL-operaattorin historiasta:
On hienoa, että tätä aihetta käsitellään yleisesti: sekä Postgres että Kubernetes. Kun aloimme tehdä sitä Zalandossa vuonna 2017, se oli aihe, jota kaikki halusivat tehdä, mutta kukaan ei tehnyt sitä. Kaikilla oli jo Kubernetes, mutta kun he kysyivät mitä tehdä tietokannoilla, jopa ihmiset pitävät , joka saarnasi K8:sta, sanoi jotain näin:
"Siirry hallinnoituihin palveluihin ja käytä niitä, älä käytä tietokantaa Kubernetesissa. Muuten K8:si päättää esimerkiksi tehdä päivityksen, sammuttaa kaikki solmut, ja tietosi lentävät kauas, kauas."
Päätimme tehdä operaattorin, joka tämän neuvon vastaisesti käynnistää Postgres-tietokannan Kubernetesissa. Ja meillä oli hyvä syy - . Tämä on PostgreSQL:n automaattinen vikasieto, joka on tehty oikein, ts. käyttämällä etcd:tä, consulia tai ZooKeeperiä klusterin tietojen tallennusvälineenä. Sellainen arkisto, joka antaa jokaiselle, joka esimerkiksi kysyy, mikä on nykyinen johtaja, samat tiedot - huolimatta siitä, että meillä on kaikki jaettu - jotta aivot eivät jakautuisi. Lisäksi meillä oli hänelle.
Yleisesti ottaen yrityksen automaattisen vikasietoisuuden tarve ilmeni siirtymisen jälkeen sisäisestä laitteiston datakeskuksesta pilveen. Pilvi perustui patentoituun PaaS-ratkaisuun (Platform-as-a-Service). Se on avoin lähdekoodi, mutta sen saaminen käyttöön vaati paljon työtä. Sitä kutsuttiin .
Aluksi Kubernetesia ei ollut. Tarkemmin sanottuna, kun oma ratkaisumme otettiin käyttöön, K8s oli jo olemassa, mutta se oli niin raakaa, että se ei sovellu tuotantoon. Se oli mielestäni 2015 tai 2016. Vuoteen 2017 mennessä Kubernetes oli tullut enemmän tai vähemmän kypsäksi – sinne oli pakko muuttaa.
Ja meillä oli jo Docker-kontti. Siellä oli PaaS, joka käytti Dockeria. Mikset kokeilisi K8:aa? Mikset kirjoittaisi omaa operaattoria? Murat Kabilov, joka tuli meille Avitosta, aloitti tämän projektina omasta aloitteestaan - "pelaamaan" - ja projekti "lähti vauhtiin".
Mutta yleisesti ottaen halusin puhua AWS:stä. Miksi siellä oli historiallista AWS-koodia...
Kun ajat jotain Kubernetesissa, sinun on ymmärrettävä, että K8s on sellainen työn alla. Se kehittyy jatkuvasti, paranee ja jopa hajoaa aika ajoin. Sinun on seurattava tarkasti kaikkia Kubernetesin muutoksia, sinun on oltava valmis sukeltamaan siihen, jos jotain tapahtuu, ja oppia kuinka se toimii yksityiskohtaisesti - ehkä enemmän kuin haluaisit. Tämä koskee periaatteessa kaikkia alustoja, joilla käytät tietokantojasi...
Joten, kun teimme lausunnon, meillä oli Postgres käynnissä ulkoisella levyllä (tässä tapauksessa EBS, koska työskentelimme AWS: n parissa). Tietokanta kasvoi, jossain vaiheessa sen kokoa oli pakko muuttaa: esimerkiksi EBS:n alkuperäinen koko oli 100 TB, tietokanta kasvoi siihen, nyt haluamme tehdä EBS:stä 200 TB. Miten? Oletetaan, että voit tehdä tyhjennyksen/palautuksen uudelle ilmentymälle, mutta tämä kestää kauan ja sisältää seisokkeja.
Siksi halusin koon muutoksen, joka suurentaisi EBS-osion ja käski sitten tiedostojärjestelmää käyttämään uutta tilaa. Ja teimme sen, mutta Kubernetesilla ei tuolloin ollut API:a koonmuutosoperaatiolle. Koska työskentelimme AWS:n parissa, kirjoitimme koodin sen API:lle.
Kukaan ei estä sinua tekemästä samaa muille alustoille. Lausunnossa ei ole vihjettä, että sitä voidaan käyttää vain AWS:ssä, eikä se toimi kaikessa muussa. Yleisesti ottaen tämä on avoimen lähdekoodin projekti: jos joku haluaa nopeuttaa uuden APIn käyttöä, olet tervetullut. Syödä , vedä pyyntöjä - Zalando-tiimi yrittää vastata niihin melko nopeasti ja mainostaa operaattoria. Sikäli kuin tiedän, projekti Google Summer of Codessa ja joissakin muissa vastaavissa aloitteissa. Zalando työskentelee sen eteen erittäin aktiivisesti.
PS Bonus!
Jos olet kiinnostunut aiheesta PostgreSQL ja Kubernetes, niin huomioi myös, että seuraava Postgres-tiistai pidettiin viime viikolla, jossa puhuin Nikolain kanssa Alexander Kukushkin Zalandosta. Video siitä on saatavilla .
PPS
Lue myös blogistamme:
- «";
- «";
- «";
- «'.
Lähde: will.com