Në fund të vitit të kaluar, u zhvillua një tjetër transmetim i drejtpërdrejtë i komunitetit rus PostgreSQL , gjatë së cilës bashkëthemeluesi i saj Nikolai Samokhvalov foli me drejtorin teknik të Flant Dmitry Stolyarov për këtë DBMS në kontekstin e Kubernetes.
Ne po publikojmë një transkript të pjesës kryesore të këtij diskutimi, dhe në Video e plotë e postuar:
Bazat e të dhënave dhe Kubernetes
NS: Sot nuk do të flasim për VAKUUMIN dhe PIKAT E KONTROLLIT. Ne duam të flasim për Kubernetes. E di që keni përvojë shumëvjeçare. I pashë videot tuaja dhe madje i rishikova disa prej tyre... Le të shkojmë drejt e në pikën: pse Postgres ose MySQL në K8 fare?
DS: Nuk ka dhe nuk mund të ketë një përgjigje të caktuar për këtë pyetje. Por në përgjithësi, kjo është thjeshtësi dhe komoditet... potencial. Të gjithë duan shërbime të menaxhuara.
NS: Si , vetem ne shtepi?
DS: Po: si RDS, kudo.
NS: "Kudo" është një pikë e mirë. Në kompanitë e mëdha, gjithçka është e vendosur në vende të ndryshme. Pse atëherë, nëse është një kompani e madhe, të mos marrë një zgjidhje të gatshme? Për shembull, Nutanix ka zhvillimet e veta, kompanitë e tjera (VMware...) kanë të njëjtin “RDS, vetëm në shtëpi”.
DS: Por ne po flasim për një zbatim të veçantë që do të funksionojë vetëm në kushte të caktuara. Dhe nëse po flasim për Kubernetes, atëherë ekziston një larmi e madhe e infrastrukturës (e cila mund të jetë në K8). Në thelb ky është një standard për API-të në re...
NS: Është gjithashtu falas!
DS: Nuk është aq e rëndësishme. Liria është e rëndësishme për një segment jo shumë të madh të tregut. Diçka tjetër është e rëndësishme... Ju ndoshta e mbani mend raportin ""?
NS: Po.
DS: E kuptova që u prit në mënyrë shumë të paqartë. Disa njerëz menduan se unë po thoja: "Djema, le t'i vendosim të gjitha bazat e të dhënave në Kubernetes!", ndërsa të tjerë vendosën që të gjitha këto ishin biçikleta të tmerrshme. Por doja të thosha diçka krejt tjetër: “Shikoni çfarë po ndodh, çfarë problemesh ka dhe si mund të zgjidhen. A duhet të përdorim bazat e të dhënave Kubernetes tani? Prodhimi? Epo, vetëm nëse ju pëlqen të bëni disa gjëra. Por për një dev, mund të them se e rekomandoj. Për një zhvillues, dinamizmi i krijimit/fshirjes së mjediseve është shumë i rëndësishëm.”
NS: Me dev, do të thotë të gjitha mjediset që nuk janë prod? Inskenimi, QA…
DS: Nëse po flasim për stendat perf, atëherë ndoshta jo, sepse kërkesat atje janë specifike. Nëse po flasim për raste të veçanta ku nevojitet një bazë të dhënash shumë e madhe për inskenim, atëherë ndoshta jo... Nëse ky është një mjedis statik, jetëgjatë, atëherë cili është përfitimi i vendosjes së bazës së të dhënave në K8?
NS: Asnje. Por ku i shohim mjediset statike? Një mjedis statik do të bëhet i vjetëruar nesër.
DS: Inskenimi mund të jetë statik. Kemi klientë...
NS: Po, edhe unë kam një të tillë. Është një problem i madh nëse keni një bazë të dhënash 10 TB dhe 200 GB skemë...
DS: Kam një rast shumë të lezetshëm! Në skenë ekziston një bazë të dhënash produkti në të cilën bëhen ndryshime. Dhe ka një buton: "kaloni në prodhim". Këto ndryshime - delta - janë shtuar (duket se thjesht sinkronizohen nëpërmjet API-së) në prodhim. Ky është një opsion shumë ekzotik.
NS: Unë kam parë startup në Luginë që janë ulur në RDS apo edhe në Heroku - këto janë histori nga 2-3 vjet më parë - dhe ata e shkarkojnë deponinë në laptopin e tyre. Sepse baza e të dhënave është ende vetëm 80 GB, dhe ka hapësirë në laptop. Pastaj blejnë disqe shtesë për të gjithë në mënyrë që të kenë 3 baza të të dhënave për të kryer zhvillime të ndryshme. Edhe kështu ndodh. Unë gjithashtu pashë që ata nuk kanë frikë të kopjojnë prod në skenë - kjo varet shumë nga kompania. Por pashë gjithashtu se ata kanë shumë frikë, dhe se shpesh nuk kanë kohë dhe duar të mjaftueshme. Por para se të kalojmë në këtë temë, dua të dëgjoj për Kubernetes. A e kuptoj saktë se askush nuk është ende në prod?
DS: Ne kemi baza të të dhënave të vogla në prod. Ne po flasim për vëllime prej dhjetëra gigabajt dhe shërbime jo kritike për të cilat ne ishim shumë dembel për të bërë kopje (dhe nuk ka nevojë të tillë). Dhe me kusht që të ketë ruajtje normale nën Kubernetes. Kjo bazë të dhënash funksionoi në një makinë virtuale - me kusht në VMware, në krye të sistemit të ruajtjes. E vendosëm brenda dhe tani ne mund ta transferojmë atë nga makina në makinë.
NS: Bazat e të dhënave të kësaj madhësie, deri në 100 GB, mund të hapen brenda pak minutash në disqe të mirë dhe një rrjet të mirë, apo jo? Një shpejtësi prej 1 GB për sekondë nuk është më ekzotike.
DS: Po, për funksionimin linear ky nuk është problem.
NS: Mirë, duhet të mendojmë vetëm për prod. Dhe nëse po shqyrtojmë Kubernetes për mjedise jo-produese, çfarë duhet të bëjmë? E shoh në Zalando , në Crunchy , ka disa opsione të tjera. Dhe ka - Ky është miku ynë i mirë Alvaro nga Spanja: ajo që ata bëjnë nuk është në thelb vetëm , dhe e gjithë shpërndarja (), në të cilin, përveç vetë Postgres, ata vendosën të futnin edhe një kopje rezervë, përfaqësuesin e Envoy...
DS: I dërguari për çfarë? Balancimi i trafikut të Postgres në mënyrë specifike?
NS: Po. Kjo do të thotë, ata e shohin atë si: nëse merrni një shpërndarje Linux dhe kernel, atëherë PostgreSQL i rregullt është kerneli, dhe ata duan të bëjnë një shpërndarje që do të jetë miqësore me renë kompjuterike dhe do të funksionojë në Kubernetes. Ata bashkojnë komponentë (rezervë, etj.) dhe i korrigjojnë ato në mënyrë që të funksionojnë mirë.
DS: Shumë e lezetshme! Në thelb ky është softuer për të krijuar Postgres-in tuaj të menaxhuar.
NS: Shpërndarjet Linux kanë probleme të përjetshme: si të bëni drejtuesit në mënyrë që të mbështetet i gjithë hardueri. Dhe ata kanë idenë se do të punojnë në Kubernetes. E di që në operatorin Zalando kohët e fundit pamë një lidhje me AWS dhe kjo nuk është më shumë e mirë. Nuk duhet të ketë një lidhje me një infrastrukturë specifike - cila është qëllimi atëherë?
DS: Nuk e di saktësisht se në çfarë situate u fut Zalando, por ruajtja në Kubernetes tani është bërë në atë mënyrë që është e pamundur të marrësh një kopje rezervë të diskut duke përdorur një metodë të përgjithshme. Kohët e fundit në standard - në versionin e fundit — Ne bëmë të mundur fotografimin, por ku zbatohet? Sinqerisht, gjithçka është ende kaq e papërpunuar... Ne po provojmë CSI në krye të AWS, GCE, Azure, vSphere, por sapo të filloni ta përdorni, mund të shihni që nuk është ende gati.
NS: Kjo është arsyeja pse ndonjëherë duhet të mbështetemi në infrastrukturë. Unë mendoj se kjo është ende një fazë e hershme - dhimbje në rritje. Pyetje: Çfarë këshille do t'u jepnit fillestarëve që duan të provojnë PgSQL në K8? Cili operator ndoshta?
DS: Problemi është se Postgres është 3% për ne. Ne gjithashtu kemi një listë shumë të madhe të softuerëve të ndryshëm në Kubernetes, madje nuk do të rendis gjithçka. Për shembull, Elasticsearch. Ka shumë operatorë: disa po zhvillohen në mënyrë aktive, të tjerët jo. Ne kemi hartuar kërkesa për veten tonë për atë që një operator duhet të ketë në mënyrë që ne ta marrim atë seriozisht. Në një operator posaçërisht për Kubernetes - jo në një "operator për të bërë diçka në kushtet e Amazon"... Në fakt, ne gjerësisht (= pothuajse të gjithë klientët) përdorim një operator të vetëm - (Së shpejti do të publikojmë një artikull për të).
NS: Dhe jo as për MySQL? E di që Percona... meqenëse tani janë duke punuar në MySQL, MongoDB dhe Postgres, do të duhet të krijojnë një lloj zgjidhjeje universale: për të gjitha bazat e të dhënave, për të gjithë ofruesit e cloud.
DS: Nuk patëm kohë të shikonim operatorët për MySQL. Ky nuk është fokusi ynë kryesor tani. MySQL funksionon mirë në mënyrë të pavarur. Pse të përdorni një operator nëse thjesht mund të hapni një bazë të dhënash... Mund të lëshoni një kontejner Docker me Postrges, ose mund ta nisni në një mënyrë të thjeshtë.
NS: Kishte një pyetje edhe për këtë. Nuk ka operator fare?
DS: Po, 100% prej nesh kanë PostgreSQL që funksionon pa operator. Deri tani kështu. Ne përdorim në mënyrë aktive operatorin për Prometheus dhe Redis. Ne kemi plane për të gjetur një operator për Elasticsearch - është ai që është më "në zjarr", sepse ne duam ta instalojmë në Kubernetes në 100% të rasteve. Ashtu siç duam të sigurojmë që MongoDB të instalohet gjithmonë në Kubernetes. Këtu shfaqen dëshira të caktuara - ekziston një ndjenjë se në këto raste diçka mund të bëhet. Dhe ne as nuk e shikuam Postgresin. Sigurisht, ne e dimë se ka opsione të ndryshme, por në fakt ne kemi një të pavarur.
DB për testim në Kubernetes
NS: Le të kalojmë në temën e testimit. Si të hapni ndryshimet në bazën e të dhënave - nga një këndvështrim DevOps. Ka mikroshërbime, shumë baza të dhënash, diçka po ndryshon diku gjatë gjithë kohës. Si të sigurohet CI/CD normale në mënyrë që gjithçka të jetë në rregull nga perspektiva e DBMS. Cila është qasja juaj?
DS: Nuk mund të ketë një përgjigje. Ka disa opsione. E para është madhësia e bazës që duam të hapim. Ju vetë përmendët se kompanitë kanë qëndrime të ndryshme për të pasur një kopje të bazës së të dhënave prod në dev dhe skenë.
NS: Dhe në kushtet e GDPR, mendoj se po tregohen gjithnjë e më të kujdesshëm... Mund të them që në Europë tashmë kanë filluar të vendosin gjoba.
DS: Por shpesh ju mund të shkruani softuer që heq një hale nga prodhimi dhe e turbullon atë. Të dhënat e prod-it merren (snapshot, dump, kopje binare...), por janë anonimizuar. Në vend të kësaj, mund të ketë skripta gjenerimi: këto mund të jenë instalime ose thjesht një skenar që gjeneron një bazë të dhënash të madhe. Problemi është: sa kohë duhet për të krijuar një imazh bazë? Dhe sa kohë duhet për ta vendosur atë në mjedisin e dëshiruar?
Arritëm në një skemë: nëse klienti ka një grup të dhënash fikse (versioni minimal i bazës së të dhënave), atëherë ne i përdorim ato si parazgjedhje. Nëse po flasim për mjedise rishikimi, kur krijuam një degë, ne vendosëm një shembull të aplikacionit - ne hapim një bazë të dhënash të vogël atje. Por doli mirë , kur marrim një hale nga prodhimi një herë në ditë (natën) dhe ndërtojmë një kontejner Docker me PostgreSQL dhe MySQL me këto të dhëna të ngarkuara bazuar në të. Nëse keni nevojë të zgjeroni bazën e të dhënave 50 herë nga ky imazh, kjo bëhet mjaft thjesht dhe shpejt.
NS: Me kopjim të thjeshtë?
DS: Të dhënat ruhen direkt në imazhin Docker. Ato. Ne kemi një imazh të gatshëm, megjithëse 100 GB. Falë shtresave në Docker, ne mund ta vendosim shpejt këtë imazh sa herë që na nevojitet. Metoda është budalla, por funksionon mirë.
NS: Atëherë, kur testoni, ndryshon menjëherë brenda Docker, apo jo? Kopjo-në-shkruaj brenda Docker - hidhe dhe shko sërish, gjithçka është në rregull. Klasa! Dhe a po e përdorni tashmë në maksimum?
DS: Për një kohë të gjatë.
NS: Ne bëjmë gjëra shumë të ngjashme. Vetëm ne nuk përdorim kopjen në shkrim të Docker, por një tjetër.
DS: Nuk është gjenerike. Dhe Docker punon kudo.
NS: Në teori, po. Por ne kemi edhe module atje, ju mund të bëni module të ndryshme dhe të punoni me sisteme të ndryshme skedarësh. Çfarë momenti këtu. Nga ana e Postgresit, ne e shohim të gjithë këtë ndryshe. Tani shikova nga ana e Docker dhe pashë që gjithçka funksionon për ju. Por nëse baza e të dhënave është e madhe, për shembull, 1 TB, atëherë e gjithë kjo kërkon shumë kohë: operacionet gjatë natës dhe futja e gjithçkaje në Docker... Dhe nëse 5 TB futen në Docker... Apo është gjithçka në rregull?
DS: Cili është ndryshimi: këto janë blobs, vetëm copa dhe bajt.
NS: Dallimi është ky: a e bëni atë përmes dump dhe restore?
DS: Nuk është aspak e nevojshme. Metodat për krijimin e këtij imazhi mund të jenë të ndryshme.
NS: Për disa klientë, ne e kemi bërë atë në mënyrë që në vend që të gjenerojmë rregullisht një imazh bazë, ta mbajmë vazhdimisht të përditësuar. Në thelb është një kopje, por nuk merr të dhëna nga masteri drejtpërdrejt, por përmes një arkivi. Një arkiv binar ku WAL shkarkohen çdo ditë, ku merren kopje rezervë... Këto WAL më pas arrijnë imazhin bazë me një vonesë të vogël (fjalë për fjalë 1-2 sekonda). Ne klonojmë prej tij në çfarëdo mënyre - tani kemi ZFS si parazgjedhje.
DS: Por me ZFS ju jeni të kufizuar në një nyje.
NS: Po. Por ZFS gjithashtu ka një magji : me të mund të dërgoni një fotografi dhe madje (nuk e kam testuar ende këtë, por...) mund të dërgoni një delta midis dy PGDATA. Në fakt, ne kemi një mjet tjetër që nuk e kemi konsideruar vërtet për detyra të tilla. PostgreSQL ka , i cili funksionon si një rsync "i zgjuar", duke anashkaluar shumë nga ato që nuk keni për të parë, sepse asgjë nuk ka ndryshuar atje. Mund të bëjmë një sinkronizim të shpejtë midis dy serverëve dhe të kthejmë prapa në të njëjtën mënyrë.
Pra, nga kjo anë, më shumë DBA, ne po përpiqemi të krijojmë një mjet që na lejon të bëjmë të njëjtën gjë që thatë: ne kemi një bazë të dhënash, por duam të testojmë diçka 50 herë, pothuajse njëkohësisht.
DS: 50 herë do të thotë që ju duhet të porosisni 50 raste Spot.
NS: Jo, ne bëjmë gjithçka në një makinë.
DS: Por si do ta zgjeroni 50 herë nëse kjo bazë e të dhënave është, të themi, terabyte. Ka shumë të ngjarë që ajo ka nevojë për një 256 GB RAM të kushtëzuar?
NS: Po, ndonjëherë ju duhet shumë kujtesë - kjo është normale. Por ky është një shembull nga jeta. Makina e prodhimit ka 96 bërthama dhe 600 GB. Në të njëjtën kohë, 32 bërthama (madje edhe 16 bërthama tani ndonjëherë) dhe 100-120 GB memorie përdoren për bazën e të dhënave.
DS: Dhe 50 kopje futen aty?
NS: Pra ka vetëm një kopje, pastaj funksionon kopjimi në shkrim (ZFS)... Unë do t'ju tregoj më në detaje.
Për shembull, ne kemi një bazë të dhënash 10 TB. Ata bënë një disk për të, ZFS gjithashtu kompresoi madhësinë e tij me 30-40 përqind. Meqenëse nuk bëjmë testimin e ngarkesës, koha e saktë e përgjigjes nuk është e rëndësishme për ne: le të jetë deri në 2 herë më e ngadaltë - kjo është në rregull.
U japim mundësi programuesve, QA, DBA, etj. kryeni testimin në 1-2 fije. Për shembull, ata mund të kryejnë një lloj migrimi. Nuk kërkon 10 bërthama në të njëjtën kohë - ka nevojë për 1 Backend Postgres, 1 bërthamë. Migrimi do të fillojë - ndoshta do të fillojë akoma, atëherë do të përdoret bërthama e dytë. Ne kemi 16-32 bërthama të alokuara, kështu që 10 persona mund të punojnë në të njëjtën kohë, nuk ka problem.
Sepse fizikisht PGDATA e njëjta gjë, rezulton se ne në fakt po mashtrojmë Postgresin. Truku është ky: për shembull, 10 Postgres lëshohen njëkohësisht. Cili është problemi zakonisht? Ata vendosin , le të themi 25%. Prandaj, kjo është 200 GB. Nuk do të mund të lëshoni më shumë se tre prej tyre, sepse kujtesa do të mbarojë.
Por në një moment kuptuam se kjo nuk ishte e nevojshme: vendosëm shared_buffers në 2 GB. PostgreSQL ka , dhe në realitet është i vetmi që ndikon . E vendosëm në 0,5 TB. Dhe nuk ka as rëndësi që ato nuk ekzistojnë në të vërtetë: ai bën plane sikur ato ekzistojnë.
Prandaj, kur testojmë një lloj migrimi, ne mund të mbledhim të gjitha planet - do të shohim se si do të ndodhë në prodhim. Sekondat atje do të jenë të ndryshme (më të ngadalta), por të dhënat që ne në fakt lexojmë dhe vetë planet (çfarë JOIN ka, etj.) dalin saktësisht të njëjta si në prodhim. Dhe ju mund të kryeni shumë kontrolle të tilla paralelisht në një makinë.
DS: A nuk mendoni se ka disa probleme këtu? E para është një zgjidhje që funksionon vetëm në PostgreSQL. Kjo qasje është shumë private, nuk është e përgjithshme. E dyta është se Kubernetes (dhe gjithçka që teknologjitë e resë kompjuterike po shkojnë tani) përfshin shumë nyje, dhe këto nyje janë kalimtare. Dhe në rastin tuaj është një nyje e qëndrueshme, e qëndrueshme. Këto gjëra më bëjnë në konflikt.
NS: Së pari, jam dakord, kjo është një histori thjesht Postgres. Unë mendoj se nëse kemi një lloj IO të drejtpërdrejtë dhe një grup buffer për pothuajse të gjithë memorien, kjo qasje nuk do të funksionojë - planet do të jenë të ndryshme. Por tani për tani ne punojmë vetëm me Postgres, nuk mendojmë për të tjerët.
Rreth Kubernetes. Ju vetë na thoni kudo se ne kemi një bazë të dhënash të vazhdueshme. Nëse shembulli dështon, gjëja kryesore është të ruani diskun. Këtu kemi edhe të gjithë platformën në Kubernetes, dhe komponenti me Postgres është i ndarë (edhe pse do të jetë atje një ditë). Prandaj, gjithçka është kështu: shembulli ra, por ne e ruajtëm PV-në e tij dhe thjesht e lidhëm me një shembull tjetër (të ri), sikur asgjë të mos kishte ndodhur.
DS: Nga këndvështrimi im, ne krijojmë pods në Kubernetes. K8 - elastike: porositen nyjet sipas nevojës. Detyra është që thjesht të krijoni një pod dhe të thoni se ka nevojë për X sasi burimesh, dhe më pas K8s do ta kuptojë vetë. Por mbështetja e ruajtjes në Kubernetes është ende e paqëndrueshme: , në (ky publikim u publikua të javës më parë) këto veçori bëhen vetëm beta.
Do të kalojnë gjashtë muaj deri në një vit - do të bëhet pak a shumë e qëndrueshme, ose të paktën do të deklarohet si e tillë. Pastaj mundësia e fotografive dhe ndryshimi i madhësisë e zgjidh plotësisht problemin tuaj. Sepse ju keni një bazë. Po, mund të mos jetë shumë i shpejtë, por shpejtësia varet nga ajo që është "nën kapuç", sepse disa zbatime mund të kopjojnë dhe kopjojnë-në-shkruajnë në nivelin e nënsistemit të diskut.
NS: Është gjithashtu e nevojshme që të gjithë motorët (Amazon, Google...) të fillojnë të mbështesin këtë version - kjo kërkon gjithashtu pak kohë.
DS: Nuk i përdorim ende. Ne përdorim tonën.
Zhvillimi lokal për Kubernetes
NS: A keni hasur në një dëshirë të tillë kur ju duhet të instaloni të gjitha podet në një makinë dhe të bëni një provë kaq të vogël. Për të marrë shpejt një provë të konceptit, shikoni që aplikacioni funksionon në Kubernetes, pa i kushtuar një mori makinerish për të. Ka Minikube, apo jo?
DS: Më duket se ky rast - i vendosur në një nyje - ka të bëjë ekskluzivisht me zhvillimin lokal. Ose disa manifestime të një modeli të tillë. Hani , Ka , . Ne po shkojmë drejt përdorimit të Kubernetes IN Docker. Tani filluam të punojmë me të për teste.
NS: Më parë mendoja se kjo ishte një përpjekje për të mbështjellë të gjitha pjesët në një imazh Docker. Por doli se bëhet fjalë për diçka krejtësisht të ndryshme. Gjithsesi, ka kontejnerë të veçantë, bishtaja të veçanta - vetëm në Docker.
DS: Po. Dhe është bërë një imitim mjaft qesharak, por kuptimi është ky... Ne kemi një mjet për vendosjen - . Ne duam ta bëjmë atë një mënyrë të kushtëzuar werf up: "Më merrni Kubernetes lokale." Dhe pastaj ekzekutoni kushtëzimin atje werf follow. Më pas zhvilluesi do të jetë në gjendje të modifikojë IDE-në dhe do të nisë një proces në sistem që sheh ndryshimet dhe rindërton imazhet, duke i rishpërndarë ato në K8 lokale. Kështu duam të përpiqemi të zgjidhim problemin e zhvillimit lokal.
Fotot e çastit dhe klonimi i bazës së të dhënave në realitetin K8
NS: Nëse i kthehemi kopjimit-në-shkrim. Vura re se retë kanë edhe fotografi. Ata punojnë ndryshe. Për shembull, në GCP: ju keni një shembull me shumë terabajt në bregun lindor të Shteteve të Bashkuara. Ju bëni fotografi në mënyrë periodike. Ju merrni një kopje të diskut në bregun perëndimor nga një fotografi - brenda pak minutash gjithçka është gati, funksionon shumë shpejt, vetëm cache duhet të mbushet në memorie. Por këto klone (snapshots) janë për të 'siguruar' një vëllim të ri. Kjo është e bukur kur ju duhet të krijoni shumë raste.
Por për teste, më duket se fotografitë, për të cilat ju flisni në Docker ose unë në ZFS, btrfs dhe madje edhe LVM... - ato ju lejojnë të mos krijoni të dhëna vërtet të reja në një makinë. Në re, ju do të paguani për ta çdo herë dhe do të prisni jo sekonda, por minuta (dhe në rast , ndoshta një orë).
Në vend të kësaj, ju mund t'i merrni këto të dhëna brenda një ose dy sekondash, të kryeni testin dhe t'i hidhni ato. Këto fotografi zgjidhin probleme të ndryshme. Në rastin e parë - për të shkallëzuar dhe për të marrë kopje të reja, dhe në të dytën - për teste.
DS: Nuk jam dakord. Bërja e funksionimit të duhur të klonimit të vëllimit është detyrë e resë. Unë nuk e kam parë zbatimin e tyre, por e di se si e bëjmë atë në harduer. Ne kemi Ceph, ai lejon çdo vëllim fizik () thonë klon dhe merrni një vëllim të dytë me të njëjtat karakteristika në dhjetëra milisekonda, 'ami, etj. Ju duhet të kuptoni se brenda ka një kopje të ndërlikuar-në-shkruaj. Pse cloud nuk duhet të bëjë të njëjtën gjë? Unë jam i sigurt se ata po përpiqen ta bëjnë këtë në një mënyrë ose në një tjetër.
NS: Por do t'ju duhen akoma sekonda, dhjetëra sekonda për të ngritur një shembull, për të sjellë Docker atje, etj.
DS: Pse është e nevojshme të ngrihet një shembull i tërë? Ne kemi një shembull me 32 bërthama, 16 ... dhe mund të përshtatet në të - për shembull, katër. Kur të porosisim të pestën, instanca tashmë do të ngrihet dhe më pas do të fshihet.
NS: Po, interesante, Kubernetes rezulton të jetë një histori tjetër. Baza jonë e të dhënave nuk është në K8, dhe ne kemi një shembull. Por klonimi i një baze të dhënash me shumë terabajt zgjat jo më shumë se dy sekonda.
DS: Kjo eshte fantastike. Por pika ime fillestare është se kjo nuk është një zgjidhje e përgjithshme. Po, është mirë, por është i përshtatshëm vetëm për Postgres dhe vetëm në një nyje.
NS: Është i përshtatshëm jo vetëm për Postgres: këto plane, siç përshkrova, do të funksionojnë vetëm në të. Por nëse nuk shqetësohemi për planet, dhe na duhen vetëm të gjitha të dhënat për testimin funksional, atëherë kjo është e përshtatshme për çdo DBMS.
DS: Shumë vite më parë ne bëmë diçka të ngjashme në fotot e LVM. Ky është një klasik. Kjo qasje u përdor në mënyrë shumë aktive. Nyjet shtetërore janë vetëm një dhimbje. Sepse nuk duhet t'i lëshosh, duhet t'i kujtosh gjithmonë...
NS: A shihni ndonjë mundësi për një hibrid këtu? Le të themi se statusi është një lloj pod, ai funksionon për disa njerëz (shumë testues). Ne kemi një vëllim, por falë sistemit të skedarëve, klonet janë lokale. Nëse pod bie, por disku mbetet, pod do të ngrihet, do të numërojë informacione për të gjithë klonet, do të marrë përsëri gjithçka dhe do të thotë: "Këtu janë klonet tuaja që funksionojnë në këto porte, vazhdoni të punoni me ta".
DS: Teknikisht kjo do të thotë që brenda Kubernetes është një pod brenda të cilit ne drejtojmë shumë Postgres.
NS: Po. Ai ka një kufi: le të themi se jo më shumë se 10 persona punojnë me të në të njëjtën kohë. Nëse keni nevojë për 20, ne do të hapim një pod të dytë të tillë. Ne do ta klonojmë plotësisht, pasi të kemi marrë vëllimin e dytë të plotë, do të ketë të njëjtat 10 klone "të hollë". Nuk e shihni këtë mundësi?
DS: Këtu duhet të shtojmë çështje sigurie. Ky lloj organizimi nënkupton që ky pod ka privilegje (aftësi) të larta, sepse mund të kryejë operacione jo standarde në sistemin e skedarëve... Por e përsëris: besoj se në afat të mesëm ata do të rregullojnë ruajtjen në Kubernetes, dhe në retë do ta rregullojnë të gjithë historinë me vëllime - gjithçka "thjesht do të funksionojë". Do të ketë ndryshim përmasash, klonim... Ka një vëllim - ne themi: "Krijoni një të ri bazuar në atë" dhe pas një sekonde e gjysmë marrim atë që na nevojitet.
NS: Nuk besoj në një sekondë e gjysmë për shumë terabajt. Në Ceph e bëni vetë, por flisni për retë. Shkoni në cloud, bëni një klon të një vëllimi EBS me shumë terabajt në EC2 dhe shikoni se si do të jetë performanca. Nuk do të duhen disa sekonda. Më intereson shumë se kur do të arrijnë këtë nivel. E kuptoj se çfarë po thua, por të lutem të ndryshoj.
DS: Ok, por thashë në afat të mesëm, jo afatshkurtër. Për disa vite.
Rreth operatorit për PostgreSQL nga Zalando
Në mes të këtij takimi, Alexey Klyukin, një ish zhvillues nga Zalando, gjithashtu u bashkua dhe foli për historinë e operatorit PostgreSQL:
Është mirë që kjo temë preket në përgjithësi: si Postgres ashtu edhe Kubernetes. Kur filluam ta bënim në Zalando në vitin 2017, ishte një temë që të gjithë donin ta bënin, por askush nuk e bëri. Të gjithë kishin tashmë Kubernetes, por kur pyetën se çfarë të bënin me bazat e të dhënave, madje edhe njerëzve u pëlqen , i cili predikoi K8, tha diçka si kjo:
"Shkoni te shërbimet e menaxhuara dhe përdorni ato, mos e ekzekutoni bazën e të dhënave në Kubernetes. Përndryshe, K8-të tuaja do të vendosin, për shembull, të bëjnë një përmirësim, të fikin të gjitha nyjet dhe të dhënat tuaja do të fluturojnë shumë, shumë larg.”
Ne vendosëm të krijojmë një operator që, në kundërshtim me këtë këshillë, do të nisë një bazë të dhënash Postgres në Kubernetes. Dhe ne kishim një arsye të mirë - . Ky është një dështim automatik për PostgreSQL, i bërë në mënyrë korrekte, d.m.th. duke përdorur etcd, konsullin ose ZooKeeper si një ruajtje informacioni rreth grupit. Një depo e tillë që do t'i japë kujtdo që pyet, për shembull, cili është lideri aktual, të njëjtin informacion - pavarësisht se ne kemi gjithçka të shpërndarë - që të mos ketë tru të ndarë. Plus kishim per atë.
Në përgjithësi, nevoja e kompanisë për dështim automatik u shfaq pas migrimit nga një qendër e brendshme e të dhënave harduerike në cloud. Reja bazohej në një zgjidhje të pronarit PaaS (Platforma-si-shërbim). Është Open Source, por u desh shumë punë për ta vënë në funksion. Quhej .
Fillimisht, nuk kishte Kubernetes. Më saktësisht, kur u vendos zgjidhja jonë, K8 tashmë ekzistonte, por ishte aq i papërpunuar sa nuk ishte i përshtatshëm për prodhim. Ishte, për mendimin tim, 2015 ose 2016. Deri në vitin 2017, Kubernetes ishte bërë pak a shumë i pjekur - kishte nevojë për të migruar atje.
Dhe ne kishim tashmë një kontejner Docker. Kishte një PaaS që përdorte Docker. Pse të mos provoni K8? Pse të mos shkruani operatorin tuaj? Murat Kabilov, i cili erdhi tek ne nga Avito, e filloi këtë si një projekt me iniciativën e tij - "për të luajtur" - dhe projekti "u ngrit".
Por në përgjithësi, doja të flisja për AWS. Pse kishte kod historik të lidhur me AWS...
Kur drejtoni diçka në Kubernetes, duhet të kuptoni se K8s është një punë e tillë në progres. Ai vazhdimisht zhvillohet, përmirësohet dhe madje prishet herë pas here. Duhet të vëzhgoni me vëmendje të gjitha ndryshimet në Kubernetes, duhet të jeni gati të zhyteni në të nëse ndodh diçka dhe të mësoni se si funksionon në detaje - ndoshta më shumë sesa do të dëshironit. Kjo, në parim, vlen për çdo platformë në të cilën ju drejtoni bazat e të dhënave tuaja...
Pra, kur bëmë deklaratën, ne kishim Postgres që funksiononte në një vëllim të jashtëm (EBS në këtë rast, pasi ne po punonim në AWS). Baza e të dhënave u rrit, në një moment ishte e nevojshme ta ndryshonim madhësinë e saj: për shembull, madhësia fillestare e EBS ishte 100 TB, baza e të dhënave u rrit në të, tani ne duam të bëjmë EBS 200 TB. Si? Le të themi se mund të bëni një depon/rivendosje në një shembull të ri, por kjo do të marrë një kohë të gjatë dhe do të përfshijë kohë joproduktive.
Prandaj, doja një ndryshim të madhësisë që do të zmadhonte ndarjen EBS dhe më pas do t'i thoshte sistemit të skedarëve të përdorë hapësirën e re. Dhe ne e bëmë atë, por në atë kohë Kubernetes nuk kishte ndonjë API për operacionin e ndryshimit të madhësisë. Meqenëse kemi punuar në AWS, kemi shkruar kodin për API-në e tij.
Askush nuk po ju ndalon të bëni të njëjtën gjë për platformat e tjera. Nuk ka asnjë aluzion në deklaratën se mund të ekzekutohet vetëm në AWS dhe nuk do të funksionojë për gjithçka tjetër. Në përgjithësi, ky është një projekt me burim të hapur: nëse dikush dëshiron të përshpejtojë shfaqjen e përdorimit të API-së së re, ju jeni të mirëpritur. Hani , tërheq kërkesat - ekipi Zalando përpiqet t'u përgjigjet atyre mjaft shpejt dhe të promovojë operatorin. Me sa di unë, projekti në Google Summer of Code dhe disa iniciativa të tjera të ngjashme. Zalando po punon shumë aktivisht për të.
PS Bonus!
Nëse jeni të interesuar për temën e PostgreSQL dhe Kubernetes, atëherë ju lutemi vini re gjithashtu se e marta tjetër e Postgres u zhvillua javën e kaluar, ku fola me Nikolai Alexander Kukushkin nga Zalando. Video nga ajo është në dispozicion .
PPS
Lexoni edhe në blogun tonë:
- «"?
- «"?
- «"?
- «'.
Burimi: www.habr.com