Iazko urte amaieran, Errusiako PostgreSQL komunitatearen zuzeneko beste emankizun bat egin zen , bere sortzailekide Nikolai Samokhvalov Flanteko zuzendari tekniko Dmitry Stolyarov-ekin hitz egin zuen DBMS honi buruz Kubernetesen testuinguruan.
Eztabaida honen zati nagusiaren transkripzioa argitaratzen ari gara, eta helbidean Bideo osoa argitaratua:
Datu-baseak eta Kubernetes
NS: Gaur ez dugu HURTSIAN eta CHECKPOINTez hitz egingo. Kubernetes buruz hitz egin nahi dugu. Badakit urte askotako esperientzia duzula. Zure bideoak ikusi ditut eta horietako batzuk ere berriro ikusi ditut... Goazen zuzenean puntura: zergatik Postgres edo MySQL K8s-en?
DS: Galdera honen erantzun zehatzik ez dago eta ezin da egon. Baina, oro har, hau sinpletasuna eta erosotasuna... potentziala da. Guztiek nahi dituzte kudeatutako zerbitzuak.
NS: Nola , etxean bakarrik?
DS: Bai: RDS bezala, edonon.
NS: "Edonon" puntu ona da. Enpresa handietan, dena leku ezberdinetan kokatzen da. Zergatik, orduan, enpresa handia bada, ez duzu prest egindako irtenbiderik hartzen? Adibidez, Nutanixek bere garapenak ditu, beste konpainia batzuek (VMware...) "RDS, etxean bakarrik" berdina dute.
DS: Baina baldintza jakin batzuetan bakarrik funtzionatuko duen inplementazio bereiziaz ari gara. Eta Kubernetesez ari bagara, orduan azpiegitura ugari dago (K8etan egon daitezkeenak). Funtsean, hau hodeiko APIentzako estandar bat da...
NS: Doan ere bada!
DS: Ez da hain garrantzitsua. Doakotasuna garrantzitsua da merkatuaren segmentu handi batentzat. Beste zerbait garrantzitsua da... Ziurrenik erreportajea gogoratuko duzu “"?
NS: Bai.
DS: oso anbiguoki jaso zela konturatu nintzen. Batzuek pentsatu zuten nik esaten ari nintzela: “Mutilak, sar ditzagun datu-base guztiak Kubernetes-en!”, eta beste batzuek bizikleta izugarriak zirela erabaki zuten. Baina guztiz bestelakoa esan nahi nuen: “Begira zer gertatzen den, zer arazo dauden eta nola konpondu daitezkeen. Kubernetes datu-baseak erabili behar al ditugu orain? Ekoizpena? Tira, bakarrik gustatzen bazaizu... gauza batzuk egitea. Baina garatzaile batentzat, gomendatzen dudala esan dezaket. Garatzaile batentzat, inguruneak sortzeko/ezabatzeko dinamismoa oso garrantzitsua da”.
NS: Garatzailearekin, produktuak ez diren ingurune guztiak esan nahi dituzu? Eszenaratzea, QA...
DS: Perf standei buruz ari bagara, seguruenik ez, hor dauden eskakizunak zehatzak direlako. Eszenaratzeko datu-base oso handia behar den kasu bereziez ari bagara, seguruenik ez... Ingurune estatiko eta iraupen handikoa bada, zer onura du datu-basea K8s-en kokatuta egoteak?
NS: bat ere ez. Baina non ikusten ditugu ingurune estatikoak? Ingurune estatiko bat zaharkituko da bihar.
DS: Eszenaratzea estatikoa izan daiteke. Bezeroak ditugu...
NS: Bai, nik ere badut bat. Arazo handia da 10 TBko datu-basea eta 200 GBko eszenaratzea baduzu...
DS: Oso kasu polita daukat! Eszenaratzean produktuen datu-base bat dago zeinetan aldaketak egiten diren. Eta botoi bat dago: “produkziora atera”. Aldaketa hauek -deltak- gehitzen dira (badirudi APIaren bidez sinkronizatzen direla besterik gabe) ekoizpenean. Hau oso aukera exotikoa da.
NS: Haraneko startup-ak ikusi ditut RDSn edo Heroku-n eserita daudenak - duela 2-3 urteko istorioak dira - eta zabortegia euren ordenagailu eramangarrira deskargatzen dute. Datu-baseak 80 GB baino ez dituelako oraindik, eta ordenagailu eramangarrian lekua dagoelako. Ondoren, guztientzako disko osagarriak erosten dituzte, garapen desberdinak egiteko 3 datu-base izan ditzaten. Horrela gertatzen da ere. Ikusi nuen, gainera, ez dutela beldurrik prod eszenaratzean kopiatzeko - oso konpainiaren araberakoa da. Baina ikusi nuen ere beldur handia dutela, eta askotan ez dutela denbora eta esku nahikorik. Baina gai honi ekin baino lehen, Kubernetesen berri izan nahi dut. Ondo ulertzen al dut oraindik inor ez dagoela prod?
DS: Datu-base txikiak ditugu prod. Hamarnaka gigabyte-ko bolumenez eta zerbitzu ez-kritikoez ari gara, erreplikak egiteko alferrak ginen (eta ez dago halako beharrik). Eta beti ere Kubernetesen biltegiratze normala badago. Datu-base honek makina birtualean funtzionatzen zuen - VMware-n baldintzatuta, biltegiratze sistemaren gainean. Bertan jarri genuen eta orain makinaz makinara transferi dezakegu.
NS: Tamaina honetako datu-baseak, 100 GB artekoak, minutu gutxitan zabaldu daitezke disko onetan eta sare on batean, ezta? 1 GB segundoko abiadura ez da jada exotikoa.
DS: Bai, funtzionamendu linealerako ez da arazo bat.
NS: Ados, produktuari buruz pentsatu behar dugu. Eta produktuak ez diren inguruneetarako Kubernetes kontuan hartzen badugu, zer egin beharko genuke? Hori ikusten dut Zalandon , Kurruskarian , beste aukera batzuk daude. Eta badago - hau da gure lagun ona Alvaro Espainiarra: egiten dutena funtsean ez da justua , eta banaketa osoa (), bertan, Postgres beraz gain, segurtasun kopia bat, Envoy proxy-a... betetzea ere erabaki zuten.
DS: Zertarako mandataria? Postgres trafikoa orekatzea zehazki?
NS: Bai. Hau da, honela ikusten dute: Linux banaketa eta nukleoa hartzen badituzu, PostgreSQL arrunta da nukleoa, eta hodeian errespetatuko den eta Kubernetesen exekutatzeko banaketa bat egin nahi dute. Osagaiak elkartu (backups, etab.) eta arazketa egiten dute, ondo funtziona dezaten.
DS: Oso polita! Funtsean, zure kudeatutako Postgres propioa sortzeko softwarea da.
NS: Linux banaketak betiko arazoak dituzte: nola egin kontrolatzaileak hardware guztia onartzen da. Eta Kubernetesen lan egingo dutela ideia dute. Badakit Zalando operadorean duela gutxi AWS-rekin konexioa ikusi dugula eta hau jada ez da oso ona. Ez luke loturarik egon behar azpiegitura zehatz batekin - zer da orduan?
DS: Ez dakit zehatz-mehatz zein egoeratan sartu zen Zalando, baina Kubernetes-en biltegiratzean modu generiko baten bidez diskoaren babeskopia egitea ezinezkoa da orain. Duela gutxi estandarrean - azken bertsioan — argazkiak posible egin ditugu, baina non gauzatzen da? Egia esan, dena hain gordina dago oraindik... AWS, GCE, Azure, vSphere-en gainean CSI saiatzen ari gara, baina erabiltzen hasi bezain pronto, oraindik prest ez dagoela ikusten duzu.
NS: Horregatik batzuetan azpiegituretan oinarritu behar dugu. Uste dut oraindik hasierako fasea dela - hazten diren minak. Galdera: Zer aholku emango zenieke PgSQL K8s-en probatu nahi duten berriei? Zein operadore agian?
DS: Arazoa da Postgres %3 dela guretzat. Kubernetesen ere software ezberdinen zerrenda oso handia dugu, ez dut guztia zerrendatuko. Adibidez, Elasticsearch. Operadore asko daude: batzuk aktiboki garatzen ari dira, beste batzuk ez. Operadore batek izan beharko lukeenaren inguruko eskakizunak zehaztu ditugu guretzat serio hartzeko. Kubernetesentzako bereziki operadore batean - ez "Amazonen baldintzetan zerbait egiteko operadore batean"... Izan ere, nahiko zabalduta (= ia bezero guztiek) erabiltzen dugu operadore bakarra - (laster berari buruzko artikulu bat argitaratuko dugu).
NS: Eta ez MySQLrako ere? Badakit Percona... orain MySQL, MongoDB eta Postgres-en lan egiten ari direnez, nolabaiteko irtenbide unibertsala sortu beharko dute: datu-base guztietarako, hodeiko hornitzaile guztientzako.
DS: Ez genuen denborarik izan MySQL-ren operadoreak aztertzeko. Hau ez da gure ardatz nagusia orain. MySQL-ek autonomoan ondo funtzionatzen du. Zergatik erabili operadore bat datu-base bat abiarazi besterik ez baduzu... Docker edukiontzi bat abiarazi dezakezu Postrges-ekin, edo modu erraz batean abiarazi dezakezu.
NS: Galdera bat zegoen honi buruz ere. Operadorerik ez?
DS: Bai, % 100ek PostgreSQL dugu operadorerik gabe martxan. Orain arte. Erabiltzailea aktiboki erabiltzen dugu Prometheus eta Redis-entzat. Elasticsearch-erako operadore bat aurkitzeko asmoa dugu - gehien "sutan" dagoena da, kasuen %100ean Kubernetesen instalatu nahi dugulako. MongoDB Kubernetesen beti instalatuta dagoela ziurtatu nahi dugun bezala. Hemen zenbait desio agertzen dira - kasu hauetan zerbait egin daitekeenaren sentsazioa dago. Eta Postgres-i ez genion begiratu ere egin. Jakina, badakigu aukera desberdinak daudela, baina, egia esan, autonomo bat daukagu.
Kubernetes-en probak egiteko DB
NS: Goazen probaren gaira. Nola zabaldu datu-basean aldaketak - DevOps ikuspegitik. Mikrozerbitzuak daude, datu-base asko, zerbait aldatzen ari da nonbait denbora guztian. Nola ziurtatu CI/CD normala, DBMS ikuspegitik dena ondo egon dadin. Zein da zure planteamendua?
DS: Ezin da erantzun bat egon. Hainbat aukera daude. Lehenengoa zabaldu nahi dugun oinarriaren tamaina da. Zuk zeuk aipatu duzu enpresek jarrera desberdinak dituztela produktuen datu-basearen kopia garapenean eta eszenatokian edukitzeko.
NS: Eta GDPRren baldintzetan, uste dut gero eta kontu handiagoarekin ari direla... Esan dezaket Europan dagoeneko hasi direla isunak jartzen.
DS: Baina sarritan produkziotik zabortegi bat hartu eta lausotzen duen softwarea idatz dezakezu. Produkzioaren datuak lortzen dira (snapshot, dump, kopia bitarra...), baina anonimizatu egiten dira. Horren ordez, sor daitezkeen script-ak egon daitezke: instalazioak izan daitezke edo datu-base handi bat sortzen duen script bat besterik ez. Arazoa da: zenbat denbora behar da oinarrizko irudi bat sortzeko? Eta zenbat denbora behar da nahi den ingurunean zabaltzeko?
Eskema batera iritsi ginen: bezeroak datu-multzo finko bat badu (datu-basearen bertsio minimoa), lehenespenez erabiltzen ditugu. Berrikuspen-inguruneei buruz ari bagara, adar bat sortzen dugunean, aplikazioaren instantzia bat zabaldu dugu - datu-base txiki bat zabaltzen dugu bertan. Baina ondo atera zen , egunean behin (gauez) produkziotik zabortegi bat hartzen dugunean eta PostgreSQL eta MySQL-ekin Docker edukiontzi bat eraikitzen dugunean kargatutako datu hauekin. Irudi honetatik datu-basea 50 aldiz zabaldu behar baduzu, nahiko erraz eta azkar egiten da.
NS: Kopiatu soilez?
DS: Datuak zuzenean Docker irudian gordetzen dira. Horiek. Prest egindako irudia dugu, 100 GB-koa bada ere. Docker-eko geruzei esker, irudi hau behar adina aldiz zabaldu dezakegu azkar. Metodoa astakeria da, baina ondo funtzionatzen du.
NS: Orduan, proba egiten duzunean, Dockerren barruan aldatzen da, ezta? Docker barruan kopiatu eta idatzi - bota ezazu eta joan berriro, dena ondo dago. Klasea! Eta dagoeneko erabiltzen ari al zara bete-betean?
DS: Denbora luzez.
NS: Oso antzeko gauzak egiten ditugu. Guk ez dugu Dockerren kopia-idazketarik erabiltzen, besteren bat baizik.
DS: Ez da generikoa. Eta Docker-ek nonahi funtzionatzen du.
NS: Teorian, bai. Baina moduluak ere baditugu bertan, modulu desberdinak egin ditzakezu eta fitxategi sistema ezberdinekin lan egin dezakezu. A ze momentua hemen. Postgres aldetik, hau guztia ezberdin ikusten dugu. Orain Docker aldean begiratu eta dena funtzionatzen dizula ikusi dut. Baina datu-basea izugarria bada, adibidez, 1 TB, orduan honek guztiak denbora asko behar du: gauez eragiketak, eta dena Docker-en sartu... Eta 5 TB Docker-en sartzen badira... Edo dena ondo dago?
DS: Zein da aldea: hauek blobak dira, bit eta byte besterik ez.
NS: Ezberdintasuna hau da: dump bidez egiten duzu eta leheneratu?
DS: Ez da batere beharrezkoa. Irudi hau sortzeko metodoak desberdinak izan daitezke.
NS: Bezero batzuentzat, oinarrizko irudi bat aldizka sortu beharrean, etengabe eguneratuta edukitzea lortu dugu. Funtsean erreplika bat da, baina ez ditu datuak zuzenean maisutik jasotzen, artxibo baten bidez baizik. Egunero WALak deskargatzen diren artxibo bitar bat, non babeskopiak egiten diren... WAL hauek, ondoren, atzerapen apur batekin iristen dira oinarrizko irudira (literalki 1-2 segundo). Bertatik klonatzen dugu edozein modutan - orain ZFS dugu lehenespenez.
DS: Baina ZFS-rekin nodo batera mugatzen zara.
NS: Bai. Baina ZFSk ere badu magiko bat : berarekin argazki bat bidal dezakezu eta baita (oraindik ez dut hau probatu, baina...) biren arteko delta bat bidal dezakezu PGDATA. Izan ere, badugu horrelako zereginetarako benetan kontuan hartu ez dugun beste tresna bat. PostgreSQL-k dauka , rsync "inteligente" bat bezala funtzionatzen duena, ikusi behar ez duzuna asko saltatuta, ez baita ezer aldatu han. Bi zerbitzarien arteko sinkronizazio azkarra egin eta modu berean atzera egin dezakegu.
Beraz, honetatik, DBA aldetik gehiago, zuk esan duzun gauza bera egiteko aukera emango digun tresna bat sortzen saiatzen ari gara: datu-base bat dugu, baina zerbait 50 aldiz probatu nahi dugu, ia aldi berean.
DS: 50 aldiz esan nahi du 50 Spot instantzia eskatu behar dituzula.
NS: Ez, dena makina batean egiten dugu.
DS: Baina nola zabalduko zara 50 aldiz datu-base hau, esate baterako, terabytekoa bada. Litekeena da 256 GB RAM baldintzatua behar izatea?
NS: Bai, batzuetan memoria asko behar duzu - hori normala da. Baina hau bizitzako adibide bat da. Ekoizpen makinak 96 nukleo eta 600 GB ditu. Aldi berean, 32 nukleo (baita 16 nukleo ere orain batzuetan) eta 100-120 GB memoria erabiltzen dira datu-baserako.
DS: Eta hor sartzen dira 50 ale?
NS: Beraz, kopia bakarra dago, ondoren kopia-idazketa (ZFS) funtzionatzen du... Xehetasun gehiagorekin esango dizut.
Adibidez, 10 TBko datu-basea dugu. Disko bat egin zuten horretarako, ZFS-k ere ehuneko 30-40 konprimitu zuen bere tamaina. Karga-probak egiten ez ditugunez, erantzun-denbora zehatza ez da garrantzitsua guretzat: utz ezazu bi aldiz motelagoa izan, hori bai.
Programatzaileei, QA, DBA eta abarrei aukera ematen diegu. egin probak 1-2 haritan. Esaterako, baliteke migrazio motaren bat egitea. Ez ditu 10 nukleo behar aldi berean - Postgres backend 1 behar du, nukleo 1. Migrazioa hasiko da, agian oraindik hasiko da, orduan bigarren nukleoa erabiliko da. 16-32 nukleo esleituta ditugu, beraz, 10 lagunek aldi berean lan egin dezakete, arazorik gabe.
Zeren fisikoki PGDATA berdin, egia esan Postgres engainatzen ari garela ematen du. Trikimailua hau da: adibidez, 10 Postgres aldi berean abiarazten dira. Zein da normalean arazoa? Jarri zuten , demagun %25. Horren arabera, hau 200 GB da. Ezin izango dituzu hiru baino gehiago abiarazi, memoria agortu egingo delako.
Baina noizbait konturatu ginen hori ez zela beharrezkoa: shared_buffers 2 GB-ra ezarri genuen. PostgreSQL-k dauka , eta errealitatean eragiten duen bakarra da . 0,5 TB ezarri dugu. Eta berdin dio benetan existitzen ez direnik: planak baleude bezala egiten ditu.
Horren arabera, nolabaiteko migrazioa probatzen dugunean, plan guztiak bildu ditzakegu, ekoizpenean nola gertatuko den ikusiko dugu. Bertan dauden segundoak desberdinak izango dira (motelagoak), baina benetan irakurtzen ditugun datuak eta planak beraiek (zer JOIN dauden, etab.) ekoizpenean bezalaxe ateratzen dira. Eta horrelako egiaztapen asko exekutatu ditzakezu paraleloan makina batean.
DS: Ez al duzu uste hemen arazo batzuk daudela? Lehenengoa PostgreSQL-en soilik funtzionatzen duen irtenbide bat da. Ikuspegi hau oso pribatua da, ez da generikoa. Bigarrena, Kubernetes-ek (eta hodeiko teknologiek orain egingo duten guztia) nodo asko inplikatzen dituela da, eta nodo horiek iragankorrak dira. Eta zure kasuan nodo iraunkor eta iraunkorra da. Gauza hauek gatazkan jartzen naute.
NS: Lehenik eta behin, ados nago, hau Postgres istorio hutsa da. Uste dut zuzeneko IO motaren bat eta ia memoria guztientzako buffer pool bat baldin badugu, ikuspegi honek ez du funtzionatuko - planak desberdinak izango dira. Baina oraingoz Postgresekin bakarrik lan egiten dugu, ez dugu besteetan pentsatzen.
Kubernetesi buruz. Zuk zeuk esaten diguzu nonahi datu-base iraunkor bat dugula. Instantziak huts egiten badu, gauza nagusia diskoa gordetzea da. Hemen ere Kubernetes-en dugu plataforma osoa, eta Postgres-en osagaia bereizita dago (nahiz eta egunen batean egongo den). Hori dela eta, dena honela dago: instantzia erori egin zen, baina bere PV gorde genuen eta besterik gabe, beste instantzia (berri) batera konektatu genuen, ezer gertatu ez balitz bezala.
DS: Nire ikuspuntutik, Kubernetesen lekak sortzen ditugu. K8s - elastikoa: korapiloak behar bezala ordenatzen dira. Zeregin bat besterik ez da pod bat sortzea eta X baliabide kopuru behar duela esatea, eta orduan K8s-ek bere kabuz asmatuko du. Baina Kubernetes-en biltegiratzeko laguntza ezegonkorra da oraindik: in (argitalpen hau kaleratu zen astean duela) ezaugarri hauek beta baino ez dira bihurtzen.
Sei hilabetetik urtera igaroko dira - egonkorrago edo gutxiago egongo da, edo, gutxienez, horrela deklaratuko da. Orduan, argazkiak eta tamaina aldatzeko aukerak zure arazoa guztiz konpontzen du. Oinarria duzulako. Bai, agian ez da oso azkarra izango, baina abiadura "kanpaiaren azpian" dagoenaren araberakoa da, inplementazio batzuek disko azpisistema mailan kopiatu eta kopiatu dezaketelako.
NS: Motor guztiek (Amazon, Google...) bertsio hau onartzen hastea ere beharrezkoa da - honek ere denbora pixka bat behar du.
DS: Ez ditugu oraindik erabiltzen. Gurea erabiltzen dugu.
Tokiko garapena Kubernetesentzat
NS: Halako desiorik topatu al duzu makina batean leka guztiak instalatu eta proba txiki bat egin behar duzunean. Kontzeptuaren froga azkar lortzeko, ikusi aplikazioa Kubernetesen exekutatzen dela, horretarako makina mordoa eskaini gabe. Minikube dago, ezta?
DS: Kasu hau, nodo batean zabalduta, tokiko garapenari buruzkoa dela iruditzen zait. Edo eredu horren adierazpen batzuk. Jan , ez dago , . Kubernetes IN Docker erabiltzera goaz. Orain probak egiteko lanean hasi gara.
NS: Pentsatzen nuen hau pod guztiak Docker irudi batean biltzeko saiakera bat zela. Baina konturatu zen guztiz bestelakoa dela. Dena den, ontzi bereiziak daude, ontzi bereiziak - Docker-en besterik ez.
DS: Bai. Eta imitazio dibertigarri samarra dago, baina esanahia hau da... Inplementatzeko erabilgarritasun bat dugu - . Modu baldintzatua egin nahi dugu werf up: "Ekar diezadazu tokiko Kubernetes." Eta gero exekutatu baldintza hor werf follow. Ondoren, garatzaileak IDEa editatu ahal izango du, eta sisteman aldaketak ikusi eta irudiak berreraikitzen dituen prozesu bat abiaraziko da, tokiko K8-etara berriro zabalduz. Horrela saiatu nahi dugu tokiko garapenaren arazoa konpontzen.
Argazkiak eta datu-baseen klonazioa K8s errealitatean
NS: Copy-on-writera itzultzen bagara. Hodeiek ere argazkiak badituztela ohartu nintzen. Ezberdin lan egiten dute. Adibidez, GCPn: terabyte anitzeko instantzia bat duzu Estatu Batuetako ekialdeko kostaldean. Aldian-aldian argazkiak ateratzen dituzu. Diskoaren kopia bat jasotzen duzu mendebaldeko kostaldean argazki batetik - minutu gutxiren buruan dena prest dago, oso azkar funtzionatzen du, cachea bakarrik memorian bete behar da. Baina klon hauek (instantanea) bolumen berri bat "hornitzeko" dira. Hau polita da instantzia asko sortu behar dituzunean.
Baina probetarako, iruditu zait argazkiek, Docker-en edo nik ZFS-n, btrfs eta baita LVM-n hitz egiten dudana... - makina batean datu benetan berriak sortzeko aukera ematen dutela. Hodeian, oraindik ordainduko dituzu aldi bakoitzean eta itxaron ez segundoak, minutuak baizik (eta kasuan , agian erloju bat).
Horren ordez, datu hauek segundo batean edo bitan lor ditzakezu, proba egin eta bota. Argazki hauek hainbat arazo konpontzen dituzte. Lehenengo kasuan - eskalatzeko eta erreplika berriak lortzeko, eta bigarrenean - probak egiteko.
DS: Ez nago ados. Bolumenaren klonazioa behar bezala funtzionatzea da hodeiaren zeregina. Ez dut haien ezarpena aztertu, baina badakit nola egiten dugun hardwarean. Ceph dugu, edozein bolumen fisiko ahalbidetzen du () esan klonatu eta lortu ezaugarri berdinak dituen bigarren bolumena hamar milisegundotan, 'ami, etab. Barruan kopia-idazketa zaila dagoela ulertu behar duzu. Zergatik ez luke hodeiak gauza bera egin behar? Ziur nago modu batera edo bestera egiten saiatzen ari direla.
NS: Baina hala ere segundoak, hamarnaka segundo beharko dituzte instantzia bat planteatzeko, Docker bertara ekartzeko, etab.
DS: Zergatik da beharrezkoa instantzia oso bat planteatzea? 32 nukleo dituen instantzia bat dugu, 16... eta bertan sartu daiteke -adibidez, lau-. Bosgarrena agintzen dugunean, instantzia dagoeneko planteatuko da, eta gero ezabatu egingo da.
NS: Bai, interesgarria, Kubernetes beste istorio bat bihurtzen da. Gure datu-basea ez dago K8etan, eta instantzia bat dugu. Baina terabyte anitzeko datu-base bat klonatzea ez da bi segundo baino gehiago behar.
DS: Hau ona da. Baina nire hasierako puntua da hau ez dela irtenbide generikoa. Bai, polita da, baina Postgres-erako bakarrik egokia da eta nodo batean bakarrik.
NS: Postgresentzat ez da egokia: plan hauek, deskribatu dudan bezala, bertan bakarrik funtzionatuko dute. Baina ez bagara planak kezkatzen, eta proba funtzionaletarako datu guztiak behar baditugu, orduan hau egokia da edozein DBMSrako.
DS: Duela urte asko antzeko zerbait egin genuen LVM argazkietan. Hau klasiko bat da. Ikuspegi hau oso aktiboki erabili zen. Stateful nodoak mina bat besterik ez dira. Ez dituzulako utzi behar, beti gogoratu behar dituzu...
NS: Hemen hibrido bat izateko aukerarik ikusten al duzu? Demagun stateful pod moduko bat dela, hainbat pertsonarentzat (probatzaile askorentzat) funtzionatzen duela. Bolumen bat dugu, baina fitxategi-sistemari esker, klonak lokalak dira. Poda erortzen bada, baina diskoa geratzen bada, poda altxatuko da, klon guztiei buruzko informazioa zenbatuko da, berriro jaso dena eta esan: "Hona hemen zure klonak exekutatzen ari diren ataka hauetan, jarraitu haiekin lanean".
DS: Teknikoki horrek esan nahi du Kubernetesen barruan Postgres asko exekutatzen ditugun pod bat dela.
NS: Bai. Muga bat du: demagun 10 lagun baino gehiago ez lan egiten berarekin aldi berean. 20 behar badituzu, horrelako bigarren pod bat jarriko dugu martxan. Erabat klonatuko dugu, bigarren liburuki osoa jasota, 10 klon "mehe" berdinak izango ditu. Ez al duzu aukera hau ikusten?
DS: hemen segurtasun arazoak gehitu behar ditugu. Antolakuntza mota honek esan nahi du pod honek pribilegio (gaitasun) handiak dituela, fitxategi-sisteman estandarrak ez diren eragiketak egin ditzakeelako... Baina errepikatzen dut: uste dut epe ertainera Kubernetesen biltegiratzea konponduko dutela, eta hodeiek istorio osoa bolumenekin konponduko dute - dena "funtzionatuko da". Tamaina aldatzea, klonatzea... Bolumen bat dago - esaten dugu: “Sortu berri bat horretan oinarrituta”, eta segundo eta erdiren buruan behar duguna lortzen dugu.
NS: Ez dut segundo eta erdian sinesten terabyte askotarako. Ceph-en zuk zeuk egiten duzu, baina hodeiei buruz hitz egiten duzu. Joan hodera, egin terabyte anitzeko EBS bolumen baten klon bat EC2-n eta ikusi zein izango den errendimendua. Ez du segundo batzuk beharko. Asko interesatzen zait noiz iritsiko diren maila honetara. Ulertzen dut esaten ari zarena, baina alde egitea eskatzen dut.
DS: Ados, baina epe ertainean esan dut, ez epe laburrean. Hainbat urtez.
Zalandoko PostgreSQL-ren operadoreari buruz
Bilera honen erdian, Alexey Klyukin, Zalandoko garatzaile ohia ere batu zen eta PostgreSQL operadorearen historiari buruz hitz egin zuen:
Oso ondo dago gai hau orokorrean ukitzea: bai Postgres bai Kubernetes. 2017an Zalandon egiten hasi ginenean, denek nahi zuten gaia zen, baina inork ez zuen egin. Guztiek jada bazeukan Kubernetes, baina datu-baseekin zer egin galdetzen zutenean, jendeari ere gustatzen zitzaion , K8s predikatzen zuenak, honelako zerbait esan zuen:
“Joan kudeatutako zerbitzuetara eta erabili itzazu, ez exekutatu datu-basea Kubernetes-en. Bestela, zure K8ek erabakiko dute, adibidez, berritze bat egitea, nodo guztiak itzaltzea eta zure datuak urrun, oso urrun joango dira».
Aholku honen aurka, Kubernetesen Postgres datu-base bat martxan jarriko duen operadore bat egitea erabaki dugu. Eta arrazoi ona genuen - . Hau PostgreSQL-ren hutsegite automatikoa da, behar bezala egina, hau da. etcd, consul edo ZooKeeper erabiliz klusterraren inguruko informazio biltegiratze gisa. Horrelako biltegi bat, galdetzen duten guztiei, adibidez, egungo buruzagia zein den, informazio bera emango diena -dena banatuta dugun arren-, garun zatiturik egon ez dadin. Gainera bagenuen harentzat.
Oro har, konpainiaren hutsegite automatikoaren beharra agertu zen barne hardwareko datu-zentro batetik hodeira migratu ondoren. Hodeia PaaS (Platform-as-a-Service) soluzio jabedun batean oinarritzen zen. Kode irekia da, baina lan handia behar izan du martxan jartzeko. Deitzen zen .
Hasieran, ez zegoen Kubernetes. Zehatzago esanda, gure soluzio propioa zabaldu zenean, K8ak jada existitzen ziren, baina hain zen gordina ez zen ekoizpenerako egokia. Nire ustez, 2015 edo 2016koa zen. 2017rako, Kubernetes helduago edo gutxiago heldu zen —horra migratu beharra zegoen—.
Eta dagoeneko bagenuen Docker edukiontzi bat. Docker erabiltzen zuen PaaS bat zegoen. Zergatik ez probatu K8ak? Zergatik ez idatzi zure operadorea? Murat Kabilov, Avitotik etorri zitzaigun, proiektu bat bezala hasi zen bere ekimenez - "jolastu" - eta proiektua "hartu zen".
Baina, oro har, AWSri buruz hitz egin nahi nuen. Zergatik zegoen AWS erlazionatutako kode historikoa...
Kubernetes-en zerbait exekutatzen duzunean, ulertu behar duzu K8s abian dela. Etengabe garatzen, hobetzen eta noizean behin apurtzen ari da. Kubernetesen aldaketa guztiak gertutik jarraitu behar dituzu, zerbait gertatzen bada horretan murgiltzeko prest egon behar duzu eta nola funtzionatzen duen zehatz-mehatz ikasi behar duzu, agian nahi baino gehiago. Hau, printzipioz, zure datu-baseak exekutatzen dituzun plataforma guztietan aplikatzen da...
Beraz, adierazpena egin genuenean, Postgres kanpoko bolumen batean exekutatzen genuen (EBS kasu honetan, AWS-n lanean ari ginenez). Datu-basea hazi egin zen, noizbait tamaina aldatzea beharrezkoa izan zen: adibidez, EBSren hasierako tamaina 100 TBkoa zen, datu-basea hazten joan zen, orain EBS 200 TB egin nahi dugu. Nola? Demagun instantzia berri batean iraulketa/berreskuratu bat egin dezakezula, baina honek denbora luzea beharko du eta geldialdi-denbora ekarriko du.
Hori dela eta, EBS partizioa handitu eta gero fitxategi-sistemari espazio berria erabiltzeko esango zion tamaina aldatzea nahi nuen. Eta egin genuen, baina garai hartan Kubernetes-ek ez zuen tamaina aldatzeko eragiketa egiteko APIrik. AWS-en lan egin genuenez, bere APIrako kodea idatzi genuen.
Inork ez zaitu eragozten beste plataformetan gauza bera egitea. Adierazpenean ez dago AWS-n soilik exekutatu daitekeela eta ez du beste guztian funtzionatuko. Oro har, Open Source proiektu bat da: norbaitek API berriaren erabileraren agerpena azkartu nahi badu, ongi etorria zarete. Jan , tira eskaerak - Zalando taldea azkar nahiko azkar erantzuten eta operadorea sustatzen saiatzen da. Nik dakidala, proiektua Google Summer of Code-n eta antzeko beste ekimen batzuetan. Zalando oso aktiboki ari da lanean.
PS Bonua!
PostgreSQL eta Kubernetes gaia interesatzen bazaizu, mesedez, kontuan izan hurrengo Postgres asteartea joan den astean izan zela, non Nikolairekin hitz egin nuen. Zalandoko Alexander Kukushkin. Bertako bideoa eskuragarri dago .
PPS
Irakurri ere gure blogean:
- «»;
- «»;
- «»;
- «'.
Iturria: www.habr.com