Í lok síðasta árs fór önnur bein útsending frá rússneska PostgreSQL samfélaginu fram , þar sem annar stofnandi þess, Nikolai Samokhvalov, talaði við tæknistjóra Flant, Dmitry Stolyarov, um þessa DBMS í tengslum við Kubernetes.
Við birtum útskrift af meginhluta þessarar umræðu og kl Fullt myndband birt:
Gagnasöfn og Kubernetes
NS: Við tölum ekki um VACUUM og CHECKPOINTS í dag. Við viljum tala um Kubernetes. Ég veit að þú hefur margra ára reynslu. Ég horfði á myndböndin þín og horfði jafnvel aftur á sum þeirra... Við skulum komast beint að efninu: hvers vegna Postgres eða MySQL í K8s yfirleitt?
DS: Það er ekki til og getur ekki verið ákveðið svar við þessari spurningu. En almennt séð er þetta einfaldleiki og þægindi... möguleiki. Allir vilja stýrða þjónustu.
NS: Að hvernig , bara heima?
DS: Já: eins og RDS, bara hvar sem er.
NS: „Hvar sem er“ er góður punktur. Í stórum fyrirtækjum er allt staðsett á mismunandi stöðum. Af hverju þá, ef það er stórt fyrirtæki, ekki taka tilbúna lausn? Til dæmis, Nutanix hefur sína eigin þróun, önnur fyrirtæki (VMware ...) hafa sama „RDS, aðeins heima.
DS: En við erum að tala um sérstaka útfærslu sem virkar bara við ákveðnar aðstæður. Og ef við erum að tala um Kubernetes, þá er mikið úrval af innviðum (sem getur verið í K8s). Í meginatriðum er þetta staðall fyrir API í skýinu...
NS: Það er líka ókeypis!
DS: Það er ekki svo mikilvægt. Frelsi er mikilvægt fyrir ekki mjög stóran hluta markaðarins. Eitthvað annað er mikilvægt... Þú manst líklega skýrsluna “"?
NS: Já.
DS: Ég áttaði mig á því að það var tekið mjög tvísýnt. Sumir héldu að ég væri að segja: „Strákar, við skulum koma öllum gagnagrunnum inn í Kubernetes!“ á meðan aðrir ákváðu að þetta væru allt hræðileg reiðhjól. En mig langaði að segja allt annað: „Sjáðu hvað er að gerast, hvaða vandamál eru uppi og hvernig er hægt að leysa þau. Eigum við að nota Kubernetes gagnagrunna núna? Framleiðsla? Jæja, bara ef þér líkar...að gera ákveðna hluti. En fyrir þróunaraðila get ég sagt að ég mæli með því. Fyrir þróunaraðila er krafturinn við að búa til/eyða umhverfi mjög mikilvægt.
NS: Með dev, ertu að meina allt umhverfi sem er ekki prod? Sviðsetning, QA…
DS: Ef við erum að tala um perf stands, þá líklega ekki, vegna þess að kröfurnar þar eru sérstakar. Ef við erum að tala um sérstök tilvik þar sem mjög stóran gagnagrunn þarf til sviðsetningar, þá líklega ekki... Ef þetta er kyrrstætt, langlíft umhverfi, hver er þá ávinningurinn af því að hafa gagnagrunninn staðsettan í K8s?
NS: Enginn. En hvar sjáum við kyrrstæða umhverfi? Stöðugt umhverfi verður úrelt á morgun.
DS: Sviðsetning getur verið kyrrstæð. Við erum með viðskiptavini...
NS: Já, ég á líka einn. Það er mikið vandamál ef þú ert með 10 TB gagnagrunn og 200 GB sviðsetningu...
DS: Ég á mjög flott mál! Á sviðsetningu er vörugagnagrunnur sem breytingar eru gerðar á. Og það er hnappur: „rúlla út í framleiðslu“. Þessum breytingum - deltas - er bætt við (það virðist sem þær séu einfaldlega samstilltar í gegnum API) í framleiðslu. Þetta er mjög framandi valkostur.
NS: Ég hef séð sprotafyrirtæki í dalnum sem sitja í RDS eða jafnvel í Heroku - þetta eru sögur frá 2-3 árum síðan - og þeir hlaða niður sorpinu á fartölvuna sína. Vegna þess að gagnagrunnurinn er enn aðeins 80 GB, og það er pláss á fartölvunni. Síðan kaupa þeir aukadiska fyrir alla þannig að þeir hafa 3 gagnagrunna til að sinna mismunandi þróun. Svona gerist þetta líka. Ég sá líka að þeir eru óhræddir við að afrita prod í sviðsetningu - það fer mjög eftir fyrirtækinu. En ég sá líka að þeir eru mjög hræddir og að þeir hafa oft ekki nægan tíma og hendur. En áður en við förum að þessu efni vil ég heyra um Kubernetes. Skil ég rétt að enginn sé í pród ennþá?
DS: Við erum með litla gagnagrunna í framleiðslu. Við erum að tala um rúmmál upp á tugi gígabæta og ekki mikilvæga þjónustu sem við vorum of löt til að búa til eftirlíkingar (og það er engin slík þörf). Og að því gefnu að það sé eðlileg geymsla undir Kubernetes. Þessi gagnagrunnur virkaði í sýndarvél - skilyrt í VMware, ofan á geymslukerfinu. Við settum það inn og nú getum við flutt það frá vél til vél.
NS: Gagnasöfn af þessari stærð, allt að 100 GB, er hægt að rúlla út á nokkrum mínútum á góðum diskum og góðu neti, ekki satt? Hraði 1 GB á sekúndu er ekki lengur framandi.
DS: Já, fyrir línulega aðgerð er þetta ekki vandamál.
NS: Allt í lagi, við verðum bara að hugsa um prod. Og ef við erum að íhuga Kubernetes fyrir umhverfi án framleiðslu, hvað ættum við að gera? Ég sé það í Zalando , í Crunchy , það eru nokkrir aðrir valkostir. Og það er - þetta er góður vinur okkar Alvaro frá Spáni: það sem þeir gera er í rauninni ekki bara , og öll dreifingin (), þar sem þeir, auk Postgres sjálfs, ákváðu einnig að setja öryggisafrit, sendiboðann umboð...
DS: Sendiboði til hvers? Jafnvægi Postgres umferð sérstaklega?
NS: Já. Það er að segja, þeir sjá það sem: ef þú tekur Linux dreifingu og kjarna, þá er venjulegur PostgreSQL kjarninn, og þeir vilja gera dreifingu sem verður skýjavæn og keyrð á Kubernetes. Þeir setja saman íhluti (afrit o.s.frv.) og kemba þá þannig að þeir virki vel.
DS: Mjög flott! Í meginatriðum er þetta hugbúnaður til að búa til þitt eigið stýrða Postgres.
NS: Linux dreifingar hafa eilíf vandamál: hvernig á að búa til rekla þannig að allur vélbúnaður sé studdur. Og þeir hafa þá hugmynd að þeir muni vinna í Kubernetes. Ég veit að í Zalando símafyrirtækinu sáum við nýlega tengingu við AWS og þetta er ekki lengur mjög gott. Það ætti ekki að vera tengsl við ákveðinn innviði - hvað er þá tilgangurinn?
DS: Ég veit ekki nákvæmlega í hvaða aðstæðum Zalando lenti, en í Kubernetes er geymsla núna þannig gerð að það er ómögulegt að taka afrit af diski með almennri aðferð. Nýlega í stöðluðu - í nýjustu útgáfu — við gerðum skyndimyndir mögulegar, en hvar er það útfært? Satt að segja er allt enn svo hrátt... Við erum að prófa CSI ofan á AWS, GCE, Azure, vSphere, en um leið og þú byrjar að nota það geturðu séð að það er ekki tilbúið ennþá.
NS: Þess vegna þurfum við stundum að treysta á innviði. Ég held að þetta sé enn á byrjunarstigi - vaxtarverkir. Spurning: Hvaða ráð myndir þú gefa nýliðum sem vilja prófa PgSQL í K8s? Hvaða rekstraraðili kannski?
DS: Vandamálið er að Postgres er 3% fyrir okkur. Við höfum líka mjög stóran lista yfir mismunandi hugbúnað í Kubernetes, ég mun ekki einu sinni skrá allt. Til dæmis, Elasticsearch. Það eru margir rekstraraðilar: sumir eru virkir í þróun, aðrir ekki. Við höfum samið kröfur fyrir okkur, hvað á að vera í rekstraraðilanum svo við tökum það alvarlega. Í rekstraraðila sérstaklega fyrir Kubernetes - ekki í "rekstraraðila til að gera eitthvað við aðstæður Amazon"... Reyndar notum við nokkuð víða (= næstum allir viðskiptavinir) einn rekstraraðila - (við munum birta grein um hann fljótlega).
NS: Og ekki fyrir MySQL heldur? Ég veit að Percona... þar sem þeir eru núna að vinna að MySQL, MongoDB og Postgres verða þeir að búa til einhvers konar alhliða lausn: fyrir alla gagnagrunna, fyrir alla skýjaveitur.
DS: Við höfðum ekki tíma til að skoða rekstraraðila fyrir MySQL. Þetta er ekki aðaláherslan hjá okkur núna. MySQL virkar fínt í sjálfstæðu. Af hverju að nota rekstraraðila ef þú getur bara ræst gagnagrunn... Þú getur ræst Docker gám með Postrges, eða þú getur ræst hann á einfaldan hátt.
NS: Það var spurning um þetta líka. Enginn rekstraraðili?
DS: Já, 100% okkar eru með PostgreSQL í gangi án símafyrirtækis. Hingað til. Við notum virkan rekstraraðila fyrir Prometheus og Redis. Við höfum áform um að finna rekstraraðila fyrir Elasticsearch - það er sá sem er mest „í eldi“ vegna þess að við viljum setja það upp í Kubernetes í 100% tilvika. Rétt eins og við viljum tryggja að MongoDB sé líka alltaf uppsett í Kubernetes. Hér birtast ákveðnar óskir - það er tilfinning að í þessum tilvikum sé hægt að gera eitthvað. Og við horfðum ekki einu sinni á Postgres. Auðvitað vitum við að það eru mismunandi valkostir, en í raun erum við með sjálfstæða.
DB til að prófa í Kubernetes
NS: Við skulum halda áfram að efni prófunar. Hvernig á að útfæra breytingar á gagnagrunninum - frá DevOps sjónarhorni. Það eru örþjónustur, margir gagnagrunnar, eitthvað er að breytast einhvers staðar allan tímann. Hvernig á að tryggja eðlilegt CI/CD þannig að allt sé í lagi frá DBMS sjónarhorni. Hver er nálgun þín?
DS: Það getur ekki verið eitt svar. Það eru nokkrir valkostir. Sú fyrsta er stærð grunnsins sem við viljum rúlla út. Þú nefndir sjálfur að fyrirtæki hafa mismunandi viðhorf til þess að hafa afrit af prod gagnagrunninum á dev og stage.
NS: Og samkvæmt skilyrðum GDPR held ég að þeir fari meira og meira varlega... Ég get sagt að í Evrópu séu þeir þegar farnir að beita sektum.
DS: En oft er hægt að skrifa hugbúnað sem tekur sorp úr framleiðslu og skýlir því. Prod gögn eru fengin (snapshot, dump, binary copy...), en þau eru nafnlaus. Í staðinn geta verið kynslóðarforskriftir: þetta geta verið innréttingar eða bara handrit sem býr til stóran gagnagrunn. Vandamálið er: hversu langan tíma tekur það að búa til grunnmynd? Og hversu langan tíma tekur það að dreifa því í viðkomandi umhverfi?
Við komum að kerfi: ef viðskiptavinurinn er með fast gagnasett (lágmarksútgáfa af gagnagrunninum), þá notum við þau sjálfgefið. Ef við erum að tala um endurskoðunarumhverfi, þegar við bjuggum til útibú, settum við upp tilvik af forritinu - við rúllum út lítinn gagnagrunn þar. En það kom vel út , þegar við tökum sorp frá framleiðslu einu sinni á dag (á nóttunni) og byggjum Docker gám með PostgreSQL og MySQL með þessum hlaðnu gögnum sem byggjast á því. Ef þú þarft að stækka gagnagrunninn 50 sinnum frá þessari mynd er þetta gert á einfaldan og fljótlegan hátt.
NS: Með einfaldri afritun?
DS: Gögn eru geymd beint í Docker myndinni. Þeir. Við erum með tilbúna mynd, þó 100 GB. Þökk sé lögum í Docker getum við fljótt dreift þessari mynd eins oft og við þurfum. Aðferðin er heimskuleg en virkar vel.
NS: Síðan, þegar þú prófar, breytist það beint inni í Docker, ekki satt? Copy-on-write inni í Docker - hentu því og farðu aftur, allt er í lagi. bekk! Og ertu nú þegar að nota það til hins ýtrasta?
DS: Í langan tíma.
NS: Við gerum mjög svipaða hluti. Aðeins við notum ekki Docker's copy-on-write, heldur aðra.
DS: Það er ekki almennt. Og Docker virkar alls staðar.
NS: Fræðilega séð, já. En við erum líka með einingar þar, þú getur búið til mismunandi einingar og unnið með mismunandi skráarkerfi. Þvílík stund hér. Frá Postgres hliðinni lítum við á þetta allt öðruvísi. Nú leit ég frá Docker hliðinni og sá að allt virkar fyrir þig. En ef gagnagrunnurinn er risastór, td 1 TB, þá tekur þetta allt langan tíma: aðgerðir á nóttunni og að troða öllu inn í Docker... Og ef 5 TB eru troðið í Docker... Eða er allt í lagi?
DS: Hver er munurinn: þetta eru blobbar, bara bitar og bæti.
NS: Munurinn er þessi: gerirðu það í gegnum dump og restore?
DS: Alls ekki nauðsynlegt. Aðferðirnar til að búa til þessa mynd geta verið mismunandi.
NS: Fyrir suma viðskiptavini höfum við gert það þannig að í stað þess að búa til grunnmynd reglulega höldum við henni stöðugt uppfærðum. Það er í meginatriðum eftirmynd, en það tekur við gögnum ekki beint frá skipstjóra heldur í gegnum skjalasafn. Tvöfaldur skjalasafn þar sem WAL er hlaðið niður á hverjum degi, þar sem afrit eru tekin... Þessar WALs ná svo grunnmyndinni með smá seinkun (bókstaflega 1-2 sekúndur). Við klónum úr því á nokkurn hátt - nú höfum við ZFS sjálfgefið.
DS: En með ZFS ertu takmarkaður við einn hnút.
NS: Já. En ZFS hefur líka töfrandi : með því geturðu sent skyndimynd og jafnvel (ég hef reyndar ekki prófað þetta ennþá, en...) þú getur sent delta á milli tveggja PGDATA. Reyndar höfum við annað tól sem við höfum í raun ekki íhugað fyrir slík verkefni. PostgreSQL hefur , sem virkar eins og „snjall“ rsync, sleppir miklu af því sem þú þarft ekki að horfa á, því ekkert hefur breyst þar. Við getum gert hraðvirka samstillingu á milli netþjónanna tveggja og spólað til baka á sama hátt.
Svo, frá þessari, meira DBA hlið, erum við að reyna að búa til tól sem gerir okkur kleift að gera það sama og þú sagðir: við höfum einn gagnagrunn, en við viljum prófa eitthvað 50 sinnum, næstum samtímis.
DS: 50 sinnum þýðir að þú þarft að panta 50 Spot tilvik.
NS: Nei, við gerum allt á einni vél.
DS: En hvernig ætlarðu að stækka 50 sinnum ef þessi gagnagrunnur er td terabæt. Líklegast þarf hún skilyrt 256 GB af vinnsluminni?
NS: Já, stundum þarf mikið minni - það er eðlilegt. En þetta er dæmi úr lífinu. Framleiðsluvélin er með 96 kjarna og 600 GB. Á sama tíma eru notaðir 32 kjarna (jafnvel 16 kjarna nú stundum) og 100-120 GB af minni fyrir gagnagrunninn.
DS: Og 50 eintök passa þarna inn?
NS: Svo það er bara eitt eintak, þá virkar copy-on-write (ZFS)... Ég skal segja þér það nánar.
Til dæmis höfum við 10 TB gagnagrunn. Þeir bjuggu til disk fyrir það, ZFS þjappaði líka stærð hans um 30-40 prósent. Þar sem við gerum ekki hleðslupróf er nákvæmur viðbragðstími ekki mikilvægur fyrir okkur: láttu hann vera allt að 2 sinnum hægari - það er allt í lagi.
Við gefum forriturum, QA, DBA, o.fl. framkvæma próf í 1-2 þræði. Til dæmis gætu þeir rekið einhvers konar fólksflutninga. Það þarf ekki 10 kjarna í einu - það þarf 1 Postgres bakenda, 1 kjarna. Flutningur mun hefjast - kannski mun samt byrja, þá verður annar kjarninn notaður. Við erum með 16-32 kjarna úthlutað, þannig að 10 manns geta unnið á sama tíma, ekkert mál.
Því líkamlega PGDATA sama, það kemur í ljós að við erum í raun og veru að blekkja Postgres. Bragðið er þetta: til dæmis eru 10 Postgres settar af stað samtímis. Hvað er vandamálið venjulega? Þau settu , segjum 25%. Samkvæmt því er þetta 200 GB. Þú munt ekki geta ræst meira en þrjá af þessum, því minnið mun klárast.
En á einhverjum tímapunkti komumst við að því að þetta var ekki nauðsynlegt: við stilltum shared_buffers á 2 GB. PostgreSQL hefur , og í raun er það það eina sem hefur áhrif . Við stillum það á 0,5 TB. Og það skiptir ekki einu sinni máli að þær séu ekki til í raun og veru: hann gerir áætlanir eins og þær séu til.
Í samræmi við það, þegar við prófum einhvers konar fólksflutninga, getum við safnað öllum áætlunum - við munum sjá hvernig það mun gerast í framleiðslu. Sekúndurnar þar verða aðrar (hægari), en gögnin sem við lesum í raun og áætlanirnar sjálfar (hvaða JOIN eru þar o.s.frv.) verða nákvæmlega eins og í framleiðslu. Og þú getur keyrt margar slíkar athuganir samhliða á einni vél.
DS: Ætli það séu ekki nokkur vandamál hér? Sú fyrsta er lausn sem virkar aðeins á PostgreSQL. Þessi nálgun er mjög persónuleg, hún er ekki almenn. Annað er að Kubernetes (og allt sem skýjatæknin er að fara í núna) felur í sér marga hnúta og þessir hnútar eru skammvinnir. Og í þínu tilviki er það staðbundinn, viðvarandi hnút. Þessir hlutir gera mig ósammála.
NS: Í fyrsta lagi er ég sammála, þetta er eingöngu Postgres saga. Ég held að ef við höfum einhvers konar bein IO og biðminni fyrir næstum allt minnið, mun þessi nálgun ekki virka - áætlanirnar verða öðruvísi. En í bili vinnum við bara með Postgres, við hugsum ekki um aðra.
Um Kubernetes. Þú sjálfur segir okkur alls staðar að við höfum viðvarandi gagnagrunn. Ef tilvikið mistekst er aðalatriðið að vista diskinn. Hér erum við líka með allan pallinn í Kubernetes og íhluturinn með Postgres er aðskilinn (þó hann verði þar einn daginn). Þess vegna er allt svona: tilvikið féll, en við vistuðum PV þess og tengdum það einfaldlega við annað (nýtt) tilvik, eins og ekkert hefði í skorist.
DS: Frá mínu sjónarhorni búum við til fræbelg í Kubernetes. K8s - teygjanlegt: hnútum er pantað eftir þörfum. Verkefnið er einfaldlega að búa til belg og segja að það þurfi X magn af auðlindum, og þá munu K8s finna það út á eigin spýtur. En geymslustuðningur í Kubernetes er enn óstöðugur: Í (þessi útgáfa var gefin út á viku síðan) verða þessir eiginleikar aðeins beta.
Sex mánuðir til ár munu líða - það verður meira og minna stöðugt, eða að minnsta kosti verður lýst sem slíku. Þá leysir möguleikinn á skyndimyndum og stærðarbreytingu vandamálið þitt algjörlega. Vegna þess að þú hefur grunn. Já, það er kannski ekki mjög hratt, en hraðinn fer eftir því hvað er „undir hettunni“, vegna þess að sumar útfærslur geta afritað og afritað-á-skrifað á undirkerfisstigi disksins.
NS: Það er líka nauðsynlegt fyrir allar vélar (Amazon, Google...) að byrja að styðja þessa útgáfu - þetta tekur líka smá tíma.
DS: Við notum þau ekki ennþá. Við notum okkar.
Staðbundin þróun fyrir Kubernetes
NS: Hefur þú rekist á svona ósk þegar þú þarft að setja alla belg á eina vél og gera svona smá próf. Til að fá fljótt sönnun á hugmyndinni skaltu sjá að forritið keyrir í Kubernetes, án þess að tileinka fullt af vélum fyrir það. Það er Minikube, ekki satt?
DS: Mér sýnist að þetta mál - sett á einn hnút - snúist eingöngu um staðbundna þróun. Eða einhverjar birtingarmyndir slíks mynsturs. Borða , það er , . Við erum að fara að nota Kubernetes IN Docker. Nú fórum við að vinna með það fyrir próf.
NS: Ég hélt að þetta væri tilraun til að pakka öllum belgjum inn í eina Docker mynd. En það kom í ljós að þetta snýst um eitthvað allt annað. Engu að síður, það eru aðskilin ílát, aðskilin belg - bara í Docker.
DS: Já. Og það er frekar fyndin eftirlíking gerð, en meiningin er þessi... Við erum með tól til að dreifa - . Við viljum gera það að skilyrtum ham werf up: "Fáðu mér staðbundna Kubernetes." Og keyra svo skilyrðið þar werf follow. Þá mun verktaki geta breytt IDE og ferli verður ræst í kerfinu sem sér breytingarnar og endurbyggir myndirnar og endurdreifir þeim á staðbundnar K8. Þannig viljum við reyna að leysa byggðaþróunarvandann.
Skyndimyndir og gagnagrunnsklónun í raunveruleika K8s
NS: Ef við snúum aftur til copy-on-write. Ég tók eftir því að skýin eru líka með skyndimyndir. Þeir vinna öðruvísi. Til dæmis, í GCP: þú ert með margra terabæta dæmi á austurströnd Bandaríkjanna. Þú tekur skyndimyndir reglulega. Þú tekur upp afrit af disknum vestanhafs úr skyndimynd - eftir nokkrar mínútur er allt tilbúið, það virkar mjög hratt, aðeins þarf að fylla skyndiminni í minnið. En þessi klón (skyndimynd) eru til þess að 'útvega' nýtt bindi. Þetta er flott þegar þú þarft að búa til mörg dæmi.
En fyrir próf sýnist mér að skyndimyndir, sem þú talar um í Docker eða ég tala um í ZFS, btrfs og jafnvel LVM... - þær leyfa þér að búa ekki til raunverulega ný gögn á einni vél. Í skýinu muntu samt borga fyrir þá í hvert skipti og bíða ekki í sekúndur, heldur mínútur (og í tilfelli , hugsanlega úr).
Þess í stað geturðu fengið þessi gögn á einni eða tveimur sekúndum, keyrt prófið og hent þeim. Þessar skyndimyndir leysa mismunandi vandamál. Í fyrra tilvikinu - til að stækka og fá nýjar eftirmyndir, og í öðru - fyrir próf.
DS: Ég er ekki sammála. Það er verkefni skýsins að láta klónun bindi virka rétt. Ég hef ekki skoðað útfærslu þeirra, en ég veit hvernig við gerum það á vélbúnaði. Við höfum Ceph, það leyfir hvaða líkamlegu rúmmál sem er () segja klón og fáðu annað bindi með sömu eiginleika á tugum millisekúndna, 'ami osfrv. Þú þarft að skilja að það er erfiður afrita-í-skrifa inni. Af hverju ætti skýið ekki að gera það sama? Ég er viss um að þeir eru að reyna að gera þetta á einn eða annan hátt.
NS: En það mun samt taka þá sekúndur, tugi sekúndna að hækka dæmi, koma Docker þangað o.s.frv.
DS: Hvers vegna þarf að hækka heilt dæmi? Við höfum tilvik með 32 kjarna, 16... og það getur passað inn í það - til dæmis fjóra. Þegar við pöntum það fimmta verður tilvikið þegar hækkað og því verður eytt.
NS: Já, áhugavert, Kubernetes reynist vera önnur saga. Gagnagrunnurinn okkar er ekki í K8s og við höfum eitt tilvik. En klónun margra terabæta gagnagrunns tekur ekki meira en tvær sekúndur.
DS: Þetta er frábært. En upphafspunktur minn er að þetta er ekki almenn lausn. Já, það er flott, en það er aðeins hentugur fyrir Postgres og aðeins á einum hnút.
NS: Það hentar ekki aðeins fyrir Postgres: þessar áætlanir, eins og ég lýsti, munu aðeins virka í því. En ef við nennum ekki áætlanir, og við þurfum bara öll gögnin fyrir hagnýtar prófanir, þá er þetta hentugur fyrir hvaða DBMS sem er.
DS: Fyrir mörgum árum gerðum við eitthvað svipað á LVM skyndimyndum. Þetta er klassík. Þessi aðferð var notuð mjög virkan. Yfirburða hnútar eru bara sársauki. Vegna þess að þú ættir ekki að sleppa þeim, þú ættir alltaf að muna eftir þeim...
NS: Sérðu einhvern möguleika á blendingi hérna? Segjum að stateful sé einhvers konar fræbelgur, hann virkar fyrir marga (marga prófunaraðila). Við erum með eitt bindi, en þökk sé skráarkerfinu eru klónarnir staðbundnir. Ef belgurinn fellur, en diskurinn er eftir, mun belgurinn rísa, telja upplýsingar um öll klónin, taka allt upp aftur og segja: "Hér eru klönin þín í gangi á þessum höfnum, haltu áfram að vinna með þau."
DS: Tæknilega séð þýðir þetta að innan Kubernetes er það einn belg þar sem við keyrum mörg Postgres.
NS: Já. Hann hefur takmörk: segjum að ekki fleiri en 10 manns vinni með honum á sama tíma. Ef þú þarft 20, munum við setja af stað annan slíkan belg. Við munum klóna það að fullu, eftir að hafa fengið annað fulla bindið, mun það hafa sömu 10 „þunna“ klónana. Sérðu ekki þetta tækifæri?
DS: Við þurfum að bæta við öryggismálum hér. Þessi tegund af skipulagningu gefur til kynna að þessi pod hafi mikil réttindi (getu), vegna þess að hann getur framkvæmt óstaðlaðar aðgerðir á skráarkerfinu... En ég endurtek: Ég tel að til meðallangs tíma muni þeir laga geymslu í Kubernetes, og í skýin munu laga alla söguna með bindum - allt mun „bara virka“. Það verður breytt stærð, klónun... Það er rúmmál - við segjum: "Búðu til nýtt byggt á því," og eftir eina og hálfa sekúndu fáum við það sem við þurfum.
NS: Ég trúi ekki á eina og hálfa sekúndu í mörg terabæti. Á Ceph gerirðu það sjálfur, en þú talar um skýin. Farðu í skýið, búðu til klón af margra terabæta EBS bindi á EC2 og sjáðu hver árangurinn verður. Það mun ekki taka nokkrar sekúndur. Ég hef mikinn áhuga á því hvenær þeir ná þessu marki. Ég skil hvað þú ert að segja, en ég bið að vera ágreiningur.
DS: Allt í lagi, en ég sagði til meðallangs tíma, ekki skammtíma. Í nokkur ár.
Um rekstraraðila PostgreSQL frá Zalando
Á miðjum fundinum tók Alexey Klyukin, fyrrverandi verktaki frá Zalando, einnig þátt og talaði um sögu PostgreSQL rekstraraðilans:
Það er frábært að þetta efni sé snert almennt: bæði Postgres og Kubernetes. Þegar við byrjuðum að gera það á Zalando árið 2017 var þetta efni sem allir vildu gera en enginn gerði. Allir voru þegar með Kubernetes, en þegar þeir spurðu hvað ætti að gera við gagnagrunna líkar jafnvel fólki , sem prédikaði K8s, sagði eitthvað á þessa leið:
„Farðu í stýrða þjónustu og notaðu þær, ekki keyra gagnagrunninn í Kubernetes. Annars munu K8s þínir ákveða, til dæmis að gera uppfærslu, slökkva á öllum hnútum, og gögnin þín munu fljúga langt, langt í burtu.
Við ákváðum að búa til rekstraraðila sem, þvert á þessa ráðgjöf, mun opna Postgres gagnagrunn í Kubernetes. Og við höfðum góða ástæðu - . Þetta er sjálfvirk bilun fyrir PostgreSQL, gerð rétt, þ.e. með því að nota etcd, ræðismann eða ZooKeeper sem geymslu upplýsinga um þyrpinguna. Svona geymsla sem mun gefa öllum sem spyrja td hver núverandi leiðtogi sé, sömu upplýsingar - þrátt fyrir að við séum með öllu dreift - þannig að það sé ekki klofinn heili. Auk þess sem við áttum fyrir hann.
Almennt séð birtist þörf fyrirtækisins fyrir sjálfvirka bilun eftir flutning frá innri vélbúnaðargagnaveri yfir í skýið. Skýið var byggt á sér PaaS (Platform-as-a-Service) lausn. Það er Open Source, en það tók mikla vinnu að koma því í gang. Það var kallað .
Upphaflega var enginn Kubernetes. Nánar tiltekið, þegar okkar eigin lausn var sett á laggirnar, voru K8s þegar til, en hún var svo gróf að hún hentaði ekki til framleiðslu. Það var að mínu mati 2015 eða 2016. Árið 2017 var Kubernetes orðið meira og minna þroskað - það var þörf á að flytja þangað.
Og við áttum þegar Docker gám. Það var PaaS sem notaði Docker. Af hverju ekki að prófa K8s? Af hverju ekki að skrifa eigin símafyrirtæki? Murat Kabilov, sem kom til okkar frá Avito, byrjaði þetta sem verkefni að eigin frumkvæði - "að leika" - og verkefnið "fór í gang."
En almennt vildi ég tala um AWS. Af hverju var sögulegur AWS tengdur kóða ...
Þegar þú keyrir eitthvað í Kubernetes þarftu að skilja að K8s er svo mikil vinna í vinnslu. Það er stöðugt að þróast, batna og jafnvel brotna niður af og til. Þú þarft að fylgjast vel með öllum breytingum á Kubernetes, þú þarft að vera tilbúinn að kafa ofan í það ef eitthvað gerist og læra hvernig það virkar í smáatriðum - kannski meira en þú vilt. Þetta á í grundvallaratriðum við um hvaða vettvang sem þú keyrir gagnagrunna þína á...
Svo þegar við gerðum yfirlýsinguna vorum við með Postgres í gangi á ytra bindi (EBS í þessu tilfelli, þar sem við vorum að vinna að AWS). Gagnagrunnurinn stækkaði, á einhverjum tímapunkti var nauðsynlegt að breyta stærð hans: til dæmis var upphafsstærð EBS 100 TB, gagnagrunnurinn stækkaði, nú viljum við gera EBS 200 TB. Hvernig? Segjum að þú getir gert dump/restore á nýju tilviki, en þetta mun taka langan tíma og fela í sér niður í miðbæ.
Þess vegna vildi ég breyta stærð sem myndi stækka EBS skiptinguna og segja síðan skráarkerfinu að nota nýja rýmið. Og við gerðum það, en á þeim tíma var Kubernetes ekki með nein API fyrir stærðarbreytinguna. Þar sem við unnum að AWS skrifuðum við kóða fyrir API þess.
Enginn hindrar þig í að gera slíkt hið sama fyrir aðra vettvang. Það er engin vísbending í yfirlýsingunni að það sé aðeins hægt að keyra það á AWS og það mun ekki virka á öllu öðru. Almennt séð er þetta Open Source verkefni: ef einhver vill flýta fyrir notkun nýja API, þá ertu velkominn. Borða , draga beiðnir - Zalando teymið reynir að bregðast við þeim nokkuð fljótt og kynna rekstraraðilann. Eftir því sem ég best veit er verkefnið á Google Summer of Code og nokkrum öðrum svipuðum verkefnum. Zalando vinnur mjög virkan að því.
PS bónus!
Ef þú hefur áhuga á efni PostgreSQL og Kubernetes, vinsamlegast athugaðu líka að næsti Postgres þriðjudagur fór fram í síðustu viku, þar sem ég talaði við Nikolai Alexander Kukushkin frá Zalando. Myndband frá henni er fáanlegt .
Pps
Lestu líka á blogginu okkar:
- «»;
- «»;
- «»;
- «'.
Heimild: www.habr.com