Sa pagtatapos ng nakaraang taon, isa pang live na broadcast ng Russian PostgreSQL community ang naganap , kung saan ang co-founder nitong si Nikolai Samokhvalov ay nakipag-usap kay Flant technical director Dmitry Stolyarov tungkol sa DBMS na ito sa konteksto ng Kubernetes.
Kami ay naglalathala ng isang transcript ng pangunahing bahagi ng talakayang ito, at sa Na-post ang buong video:
Mga Database at Kubernetes
NS: Hindi natin pag-uusapan ang VACUUM at CHECKPOINT ngayon. Gusto naming pag-usapan ang tungkol sa Kubernetes. Alam kong mayroon kang maraming taon ng karanasan. Napanood ko ang iyong mga video at kahit na muling pinanood ang ilan sa mga ito... Dumiretso tayo sa punto: bakit Postgres o MySQL sa K8s talaga?
DS: Wala at hindi maaaring maging isang tiyak na sagot sa tanong na ito. Ngunit sa pangkalahatan, ito ay pagiging simple at kaginhawahan... potensyal. Gusto ng lahat ng pinamamahalaang serbisyo.
NS: Paano , sa bahay lang?
DS: Oo: parang RDS, kahit saan lang.
NS: "Kahit saan" ay isang magandang punto. Sa malalaking kumpanya, lahat ay matatagpuan sa iba't ibang lugar. Bakit kung ito ay isang malaking kumpanya, hindi kumuha ng isang handa na solusyon? Halimbawa, may sariling development ang Nutanix, ang ibang kumpanya (VMware...) ay may parehong “RDS, sa bahay lang.”
DS: Ngunit pinag-uusapan natin ang tungkol sa isang hiwalay na pagpapatupad na gagana lamang sa ilalim ng ilang mga kundisyon. At kung pinag-uusapan natin ang tungkol sa Kubernetes, kung gayon mayroong isang malaking iba't ibang mga imprastraktura (na maaaring nasa K8s). Sa pangkalahatan, ito ay isang pamantayan para sa mga API sa cloud...
NS: Libre din!
DS: Hindi gaanong mahalaga. Ang kalayaan ay mahalaga para sa hindi isang napakalaking bahagi ng merkado. May ibang bagay na mahalaga... Malamang naaalala mo ang ulat "»?
NS: Oo.
DS: Napagtanto ko na ito ay natanggap nang malabo. Ang ilang mga tao ay nag-isip na sinasabi ko: "Guys, let's get all the databases into Kubernetes!", habang ang iba ay nagpasya na ang mga ito ay lahat ng mga kakila-kilabot na bisikleta. Ngunit nais kong sabihin ang isang bagay na ganap na naiiba: "Tingnan kung ano ang nangyayari, kung anong mga problema ang mayroon at kung paano ito malulutas. Dapat ba nating gamitin ang mga database ng Kubernetes ngayon? Produksyon? Well, kung gusto mo lang...gumawa ng ilang bagay. Ngunit para sa isang dev, masasabi kong inirerekomenda ko ito. Para sa isang dev, ang dynamism ng paggawa/pagtanggal ng mga environment ay napakahalaga."
NS: By dev, ibig mo bang sabihin lahat ng environment na hindi prod? Pagtatanghal, QA…
DS: Kung pinag-uusapan natin ang tungkol sa mga perf stand, malamang na hindi, dahil tiyak ang mga kinakailangan doon. Kung pinag-uusapan natin ang tungkol sa mga espesyal na kaso kung saan ang isang napakalaking database ay kinakailangan para sa pagtatanghal ng dula, kung gayon malamang na hindi... Kung ito ay isang static, pangmatagalang kapaligiran, kung gayon ano ang pakinabang ng pagkakaroon ng database na matatagpuan sa K8s?
NS: Wala. Ngunit saan natin nakikita ang mga static na kapaligiran? Ang isang static na kapaligiran ay magiging lipas na bukas.
DS: Ang pagtatanghal ay maaaring static. May mga kliyente kami...
NS: Oo, meron din ako. Malaking problema kung mayroon kang 10 TB database at 200 GB na staging...
DS: Mayroon akong isang napaka-cool na kaso! Sa pagtatanghal ng dula mayroong isang database ng produkto kung saan ginawa ang mga pagbabago. At mayroong isang pindutan: "ilunsad sa produksyon". Ang mga pagbabagong ito - deltas - ay idinagdag (tila ang mga ito ay naka-synchronize lamang sa pamamagitan ng API) sa produksyon. Ito ay isang napaka-exotic na opsyon.
NS: Nakakita ako ng mga startup sa Valley na nakaupo sa RDS o kahit sa Heroku - ito ay mga kwento mula 2-3 taon na ang nakakaraan - at dina-download nila ang dump sa kanilang laptop. Dahil ang database ay 80 GB lamang, at may espasyo sa laptop. Pagkatapos ay bumili sila ng karagdagang mga disk para sa lahat upang magkaroon sila ng 3 database upang magsagawa ng iba't ibang mga pag-unlad. Ganito rin ang nangyayari. Nakita ko rin na hindi sila natatakot na kopyahin ang prod sa pagtatanghal - depende ito sa kumpanya. Ngunit nakita ko rin na sila ay labis na natatakot, at na sila ay madalas na walang sapat na oras at mga kamay. Ngunit bago tayo magpatuloy sa paksang ito, gusto kong marinig ang tungkol sa Kubernetes. Tama ba ang pagkakaintindi ko na wala pang nasa prod?
DS: Mayroon kaming maliliit na database sa produksyon. Pinag-uusapan natin ang tungkol sa dami ng sampu-sampung gigabytes at hindi kritikal na mga serbisyo kung saan tinatamad kaming gumawa ng mga replika (at walang ganoong pangangailangan). At sa kondisyon na mayroong normal na storage sa ilalim ng Kubernetes. Ang database na ito ay nagtrabaho sa isang virtual machine - may kondisyon sa VMware, sa ibabaw ng storage system. Inilagay namin ito at ngayon ay maaari na nating ilipat ito mula sa makina patungo sa makina.
NS: Ang mga database na ganito ang laki, hanggang 100 GB, ay maaaring ilunsad sa loob ng ilang minuto sa magagandang disk at magandang network, tama ba? Ang bilis na 1 GB bawat segundo ay hindi na kakaiba.
DS: Oo, para sa linear na operasyon hindi ito isang problema.
NS: Okay, kailangan lang nating isipin ang tungkol sa prod. At kung isasaalang-alang natin ang Kubernetes para sa mga non-prod environment, ano ang dapat nating gawin? Nakikita ko yan sa Zalando , sa Crunchy , may ilang iba pang mga opsyon. At mayroong - ito ang ating matalik na kaibigan na si Alvaro mula sa Espanya: ang kanilang ginagawa ay hindi lamang basta-basta , at ang buong pamamahagi (), kung saan, bilang karagdagan sa mga Postgres mismo, nagpasya din silang maglagay ng backup, ang Envoy proxy...
DS: Sugo para saan? Partikular na binabalanse ang trapiko ng Postgres?
NS: Oo. Ibig sabihin, nakikita nila ito bilang: kung kukuha ka ng Linux distribution at kernel, ang regular na PostgreSQL ay ang kernel, at gusto nilang gumawa ng distribution na magiging cloud-friendly at tatakbo sa Kubernetes. Pinagsasama-sama nila ang mga bahagi (mga backup, atbp.) at i-debug ang mga ito upang gumana nang maayos ang mga ito.
DS: Napakagaling! Mahalaga ito ay software upang lumikha ng iyong sariling pinamamahalaang Postgres.
NS: Ang mga pamamahagi ng Linux ay may walang hanggang mga problema: kung paano gumawa ng mga driver upang ang lahat ng hardware ay suportado. At may ideya sila na magtatrabaho sila sa Kubernetes. Alam ko na sa operator ng Zalando kamakailan ay nakakita kami ng koneksyon sa AWS at hindi na ito napakahusay. Hindi dapat magkaroon ng ugnayan sa isang partikular na imprastraktura - ano ang punto kung gayon?
DS: Hindi ko alam kung anong eksaktong sitwasyon ang napunta kay Zalando, ngunit sa Kubernetes storage ay ginawa na ngayon sa paraang imposibleng kumuha ng disk backup gamit ang generic na paraan. Kamakailan sa pamantayan - sa pinakabagong bersyon — ginawa naming posible ang mga snapshot, ngunit saan ito ipinapatupad? Sa totoo lang, hilaw pa rin ang lahat... Sinusubukan namin ang CSI sa itaas ng AWS, GCE, Azure, vSphere, ngunit sa sandaling simulan mo itong gamitin, makikita mo na hindi pa ito handa.
NS: Kaya minsan kailangan nating umasa sa imprastraktura. Sa tingin ko ito ay isang maagang yugto pa rin - lumalaking sakit. Tanong: Anong payo ang ibibigay mo sa mga baguhan na gustong subukan ang PgSQL sa K8s? Anong operator siguro?
DS: Ang problema ay ang Postgres ay 3% para sa amin. Mayroon din kaming napakalaking listahan ng iba't ibang software sa Kubernetes, hindi ko na ilista ang lahat. Halimbawa, Elasticsearch. Mayroong maraming mga operator: ang ilan ay aktibong umuunlad, ang iba ay hindi. Gumawa kami ng mga kinakailangan para sa aming sarili, kung ano ang dapat na nasa operator upang seryosohin namin ito. Sa isang operator na partikular para sa Kubernetes - hindi sa isang "operator na gumawa ng isang bagay sa mga kondisyon ng Amazon"... Sa katunayan, kami ay malawak (= halos lahat ng mga kliyente) ay gumagamit ng isang solong operator - (maglalathala kami ng artikulo tungkol sa kanya sa lalong madaling panahon).
NS: At hindi rin para sa MySQL? Alam ko na ang Percona... dahil nagtatrabaho na sila ngayon sa MySQL, MongoDB, at Postgres, kakailanganin nilang lumikha ng ilang uri ng unibersal na solusyon: para sa lahat ng database, para sa lahat ng cloud provider.
DS: Wala kaming oras upang tingnan ang mga operator para sa MySQL. Hindi ito ang pangunahing pokus natin ngayon. Ang MySQL ay gumagana nang maayos sa standalone. Bakit gagamit ng operator kung makakapaglunsad ka lang ng database... Maaari kang maglunsad ng container ng Docker na may Postrges, o maaari mo itong ilunsad sa simpleng paraan.
NS: May tanong din tungkol dito. Walang operator?
DS: Oo, 100% sa amin ay may PostgreSQL na tumatakbo nang walang operator. Sa ngayon kaya. Aktibong ginagamit namin ang operator para sa Prometheus at Redis. May mga plano kaming maghanap ng operator para sa Elasticsearch - ito ang pinaka "nasusunog", dahil gusto naming i-install ito sa Kubernetes sa 100% ng mga kaso. Tulad ng gusto naming tiyakin na ang MongoDB ay palaging naka-install sa Kubernetes. Dito lumilitaw ang ilang mga kagustuhan - may pakiramdam na sa mga kasong ito ay may magagawa. At hindi man lang kami tumingin sa Postgres. Siyempre, alam namin na mayroong iba't ibang mga pagpipilian, ngunit sa katunayan mayroon kaming isang standalone.
DB para sa pagsubok sa Kubernetes
NS: Lumipat tayo sa paksa ng pagsubok. Paano ilunsad ang mga pagbabago sa database - mula sa pananaw ng DevOps. May mga microservice, maraming database, may nagbabago sa isang lugar sa lahat ng oras. Paano masisiguro ang normal na CI/CD upang ang lahat ay maayos mula sa pananaw ng DBMS. Ano ang iyong diskarte?
DS: Walang maaaring maging isang sagot. Mayroong ilang mga pagpipilian. Ang una ay ang laki ng base na gusto nating ilunsad. Ikaw mismo ang nagbanggit na ang mga kumpanya ay may iba't ibang saloobin sa pagkakaroon ng kopya ng prod database sa dev at stage.
NS: And under the conditions of the GDPR, I think they are more and more careful... I can say na sa Europe ay nagsimula na silang magpataw ng multa.
DS: Ngunit kadalasan maaari kang sumulat ng software na kumukuha ng isang dump mula sa produksyon at pinalalabo ito. Ang data ng prod ay nakuha (snapshot, dump, binary copy...), ngunit ito ay hindi nagpapakilala. Sa halip, maaaring mayroong mga generation script: ang mga ito ay maaaring mga fixture o isang script lamang na bumubuo ng isang malaking database. Ang problema ay: gaano katagal bago gumawa ng batayang imahe? At gaano katagal bago i-deploy ito sa nais na kapaligiran?
Dumating kami sa isang scheme: kung ang kliyente ay may nakapirming set ng data (minimal na bersyon ng database), pagkatapos ay ginagamit namin ang mga ito bilang default. Kung pinag-uusapan natin ang tungkol sa mga kapaligiran ng pagsusuri, noong lumikha kami ng isang sangay, nag-deploy kami ng isang halimbawa ng application - naglunsad kami ng isang maliit na database doon. Pero naging maayos naman , kapag kumuha kami ng isang dump mula sa produksyon isang beses sa isang araw (sa gabi) at bumuo ng isang Docker container na may PostgreSQL at MySQL gamit ang naka-load na data na ito batay dito. Kung kailangan mong palawakin ang database ng 50 beses mula sa larawang ito, ito ay ginagawa nang simple at mabilis.
NS: Sa simpleng pagkopya?
DS: Direktang iniimbak ang data sa imahe ng Docker. Yung. Mayroon kaming handa na imahe, kahit na 100 GB. Salamat sa mga layer sa Docker, mabilis naming mai-deploy ang larawang ito nang maraming beses hangga't kailangan namin. Ang pamamaraan ay hangal, ngunit ito ay gumagana nang maayos.
NS: Pagkatapos, kapag sinubukan mo, nagbabago ito sa loob mismo ng Docker, tama ba? Copy-on-write sa loob ng Docker - itapon ito at pumunta muli, maayos ang lahat. Klase! At ginagamit mo na ba ito ng lubos?
DS: Sa mahabang panahon.
NS: Gumagawa kami ng magkatulad na mga bagay. Tanging hindi namin ginagamit ang copy-on-write ng Docker, ngunit iba pa.
DS: Hindi ito generic. At gumagana ang Docker sa lahat ng dako.
NS: Sa teorya, oo. Ngunit mayroon din kaming mga module doon, maaari kang gumawa ng iba't ibang mga module at gumana sa iba't ibang mga file system. Anong sandali dito. Mula sa panig ng Postgres, iba ang pagtingin natin sa lahat ng ito. Ngayon ay tumingin ako mula sa panig ng Docker at nakita kong gumagana ang lahat para sa iyo. Ngunit kung ang database ay napakalaki, halimbawa, 1 TB, kung gayon ang lahat ng ito ay tumatagal ng mahabang panahon: mga operasyon sa gabi, at pagpupuno ng lahat sa Docker... At kung ang 5 TB ay pinalamanan sa Docker... O maayos ba ang lahat?
DS: Ano ang pagkakaiba: ito ay mga blobs, mga bit at byte lang.
NS: Ang pagkakaiba ay ito: ginagawa mo ba ito sa pamamagitan ng dump and restore?
DS: Hindi naman kailangan. Ang mga pamamaraan para sa pagbuo ng larawang ito ay maaaring iba.
NS: Para sa ilang mga kliyente, ginawa namin ito upang sa halip na regular na bumuo ng isang batayang imahe, palagi naming pinapanatili itong napapanahon. Ito ay mahalagang isang replica, ngunit tumatanggap ito ng data hindi mula sa master nang direkta, ngunit sa pamamagitan ng isang archive. Isang binary archive kung saan dina-download ang mga WAL araw-araw, kung saan kinukuha ang mga backup... Ang mga WAL na ito ay maaabot ang base na larawan nang may bahagyang pagkaantala (literal na 1-2 segundo). Kino-clone namin ito sa anumang paraan - mayroon na kaming ZFS bilang default.
DS: Ngunit sa ZFS ikaw ay limitado sa isang node.
NS: Oo. Ngunit ang ZFS ay mayroon ding isang mahiwagang : kasama nito maaari kang magpadala ng isang snapshot at kahit na (hindi ko pa talaga nasubok ito, ngunit...) maaari kang magpadala ng delta sa pagitan ng dalawa PGDATA. Sa katunayan, mayroon kaming isa pang tool na hindi namin talaga isinasaalang-alang para sa mga ganoong gawain. Ang PostgreSQL ay may , na gumagana tulad ng isang "matalinong" rsync, na nilaktawan ang marami sa hindi mo kailangang panoorin, dahil walang nagbago doon. Magagawa natin ang mabilis na pag-synchronize sa pagitan ng dalawang server at i-rewind sa parehong paraan.
Kaya, mula dito, higit pang bahagi ng DBA, sinusubukan naming lumikha ng isang tool na nagpapahintulot sa amin na gawin ang parehong bagay na sinabi mo: mayroon kaming isang database, ngunit gusto naming subukan ang isang bagay nang 50 beses, halos sabay-sabay.
DS: Ang ibig sabihin ng 50 beses ay kailangan mong mag-order ng 50 Spot instances.
NS: Hindi, ginagawa namin ang lahat sa isang makina.
DS: Ngunit paano ka magpapalawak ng 50 beses kung ang isang database na ito ay, sabihin nating, terabyte. Malamang kailangan niya ng conditional na 256 GB ng RAM?
NS: Oo, kung minsan kailangan mo ng maraming memorya - normal iyon. Ngunit ito ay isang halimbawa mula sa buhay. Ang makina ng produksyon ay may 96 na mga core at 600 GB. Kasabay nito, 32 core (kahit 16 na core ngayon minsan) at 100-120 GB ng memorya ang ginagamit para sa database.
DS: At 50 copies ang kasya doon?
NS: Kaya isa lang ang kopya, tapos gumagana ang copy-on-write (ZFS)... I'll tell you in more detail.
Halimbawa, mayroon kaming 10 TB database. Gumawa sila ng isang disk para dito, na-compress din ng ZFS ang laki nito ng 30-40 porsyento. Dahil hindi kami nagsasagawa ng pagsubok sa pag-load, hindi mahalaga sa amin ang eksaktong oras ng pagtugon: hayaan itong maging 2 beses na mas mabagal - okay lang.
Binibigyan namin ng pagkakataon ang mga programmer, QA, DBA, atbp. magsagawa ng pagsubok sa 1-2 thread. Halimbawa, maaari silang magpatakbo ng ilang uri ng paglipat. Hindi ito nangangailangan ng 10 core nang sabay-sabay - kailangan nito ng 1 Postgres backend, 1 core. Magsisimula ang migrasyon - marahil magsisimula pa rin, pagkatapos ay gagamitin ang pangalawang core. Mayroon kaming 16-32 core na inilaan, kaya 10 tao ang maaaring magtrabaho nang sabay-sabay, walang problema.
Dahil sa pisikal PGDATA the same, lumalabas na niloloko talaga natin ang mga Postgres. Ang trick ay ito: halimbawa, 10 Postgres ay inilunsad nang sabay-sabay. Ano ang kadalasang problema? Nilagay nila , sabihin nating 25%. Alinsunod dito, ito ay 200 GB. Hindi ka makakapaglunsad ng higit sa tatlo sa mga ito, dahil mauubos ang memorya.
Ngunit sa isang punto napagtanto namin na hindi ito kinakailangan: itinakda namin ang shared_buffers sa 2 GB. Ang PostgreSQL ay may , at sa totoo lang ito lang ang nakakaimpluwensya . Itinakda namin ito sa 0,5 TB. At hindi mahalaga na hindi sila aktwal na umiiral: gumagawa siya ng mga plano na parang umiiral ang mga ito.
Alinsunod dito, kapag sinubukan namin ang ilang uri ng paglipat, maaari naming kolektahin ang lahat ng mga plano - makikita namin kung paano ito mangyayari sa produksyon. Ang mga segundo doon ay magkakaiba (mas mabagal), ngunit ang data na aktwal naming nabasa, at ang mga plano mismo (kung ano ang mga SUMALI doon, atbp.) ay eksaktong kapareho ng sa produksyon. At maaari kang magpatakbo ng maraming gayong mga tseke nang magkatulad sa isang makina.
DS: Hindi mo ba iniisip na may kaunting problema dito? Ang una ay isang solusyon na gumagana lamang sa PostgreSQL. Ang diskarte na ito ay napaka-pribado, hindi ito generic. Ang pangalawa ay ang Kubernetes (at lahat ng bagay na pupuntahan ngayon ng mga teknolohiya ng cloud) ay nagsasangkot ng maraming node, at ang mga node na ito ay panandalian. At sa iyong kaso ito ay isang stateful, persistent node. Ang mga bagay na ito ay nagpapagulo sa akin.
NS: Una, sumasang-ayon ako, ito ay isang purong Postgres na kuwento. Sa palagay ko kung mayroon kaming isang uri ng direktang IO at isang buffer pool para sa halos lahat ng memorya, ang diskarte na ito ay hindi gagana - ang mga plano ay magkakaiba. Ngunit sa ngayon kami ay nagtatrabaho lamang sa mga Postgres, hindi namin iniisip ang tungkol sa iba.
Tungkol sa Kubernetes. Ikaw mismo ang nagsasabi sa amin sa lahat ng dako na mayroon kaming patuloy na database. Kung nabigo ang halimbawa, ang pangunahing bagay ay i-save ang disk. Narito din namin ang buong platform sa Kubernetes, at ang bahagi na may Postgres ay hiwalay (bagaman ito ay naroroon balang araw). Samakatuwid, ang lahat ay ganito: nahulog ang halimbawa, ngunit na-save namin ang PV nito at ikinonekta lamang ito sa isa pang (bagong) halimbawa, na parang walang nangyari.
DS: Mula sa aking pananaw, gumagawa kami ng mga pod sa Kubernetes. K8s - nababanat: ang mga buhol ay iniutos kung kinakailangan. Ang gawain ay lumikha lamang ng isang pod at sabihin na kailangan nito ng X halaga ng mga mapagkukunan, at pagkatapos ay malalaman ito ng K8s sa sarili nitong. Ngunit hindi pa rin matatag ang suporta sa storage sa Kubernetes: sa (inilabas ang release na ito недели nakaraan) ang mga tampok na ito ay nagiging beta lamang.
Anim na buwan hanggang isang taon ang lilipas - ito ay magiging mas o hindi gaanong matatag, o hindi bababa sa ito ay idineklara bilang ganoon. Pagkatapos ay lubusang malulutas ng posibilidad ng mga snapshot at resize ang iyong problema. Dahil may basehan ka. Oo, maaaring hindi ito masyadong mabilis, ngunit ang bilis ay depende sa kung ano ang "sa ilalim ng hood", dahil ang ilang mga pagpapatupad ay maaaring kopyahin at kopyahin-sa-isulat sa antas ng disk subsystem.
NS: Kinakailangan din para sa lahat ng mga makina (Amazon, Google...) upang simulan ang pagsuporta sa bersyong ito - ito ay tumatagal din ng ilang oras.
DS: Hindi pa namin ginagamit ang mga ito. Ginagamit natin ang atin.
Lokal na pag-unlad para sa Kubernetes
NS: Nakaranas ka na ba ng ganoong hiling kapag kailangan mong i-install ang lahat ng pods sa isang makina at gawin ang ganoong maliit na pagsubok. Upang mabilis na makakuha ng patunay ng konsepto, tingnan na ang application ay tumatakbo sa Kubernetes, nang hindi naglalaan ng isang grupo ng mga makina para dito. May Minikube diba?
DS: Para sa akin, ang kasong ito - na na-deploy sa isang node - ay eksklusibo tungkol sa lokal na pag-unlad. O ilang mga pagpapakita ng gayong pattern. Kumain doon , . Sumusulong kami patungo sa paggamit ng Kubernetes SA Docker. Ngayon nagsimula kaming magtrabaho kasama ito para sa mga pagsubok.
NS: Akala ko noon, ito ay isang pagtatangka na balutin ang lahat ng mga pod sa isang imahe ng Docker. Ngunit ito ay naka-out na ito ay tungkol sa isang bagay na ganap na naiiba. Anyway, may mga hiwalay na lalagyan, hiwalay na pod - sa Docker lang.
DS: Oo. At mayroong isang medyo nakakatawang imitasyon na ginawa, ngunit ang kahulugan ay ito... Mayroon kaming isang utility para sa pag-deploy - . Gusto naming gawin itong conditional mode werf up: “Kunin mo ako ng mga lokal na Kubernete.” At pagkatapos ay patakbuhin ang kondisyon doon werf follow. Pagkatapos ay magagawa ng developer na i-edit ang IDE, at isang proseso ang ilulunsad sa system na makikita ang mga pagbabago at muling itatayo ang mga larawan, muling i-deploy ang mga ito sa mga lokal na K8. Ito ay kung paano namin nais na subukan upang malutas ang problema ng lokal na pag-unlad.
Mga snapshot at database cloning sa K8s reality
NS: Kung babalik tayo sa copy-on-write. Napansin kong may mga snapshot din ang mga ulap. Iba ang trabaho nila. Halimbawa, sa GCP: mayroon kang multi-terabyte na instance sa silangang baybayin ng United States. Pana-panahon kang kumukuha ng mga snapshot. Kumuha ka ng isang kopya ng disk sa kanlurang baybayin mula sa isang snapshot - sa ilang minuto ang lahat ay handa na, ito ay gumagana nang napakabilis, ang cache lamang ang kailangang mapunan sa memorya. Ngunit ang mga clone na ito (mga snapshot) ay para sa pagbibigay ng bagong volume. Ito ay cool kapag kailangan mong lumikha ng maraming mga pagkakataon.
Ngunit para sa mga pagsubok, tila sa akin ang mga snapshot, na pinag-uusapan mo sa Docker o pinag-uusapan ko sa ZFS, btrfs at maging sa LVM... - pinapayagan ka nitong huwag gumawa ng talagang bagong data sa isang makina. Sa cloud, babayaran mo pa rin sila sa bawat oras at maghintay hindi ng mga segundo, ngunit minuto (at sa kaso , posibleng isang relo).
Sa halip, maaari mong makuha ang data na ito sa isang segundo o dalawa, patakbuhin ang pagsubok at itapon ito. Nilulutas ng mga snapshot na ito ang iba't ibang problema. Sa unang kaso - upang palakihin at makakuha ng mga bagong replika, at sa pangalawa - para sa mga pagsubok.
DS: Hindi ako sang-ayon. Ang paggawa ng volume cloning ay gumagana nang maayos ay ang gawain ng cloud. Hindi ko tiningnan ang kanilang pagpapatupad, ngunit alam ko kung paano namin ito ginagawa sa hardware. Mayroon kaming Ceph, pinapayagan nito ang anumang pisikal na volume () sabi clone at makakuha ng pangalawang volume na may parehong mga katangian sa sampu-sampung millisecond, 'ami, atbp. Kailangan mong maunawaan na mayroong nakakalito na copy-on-write sa loob. Bakit hindi dapat gawin ng ulap ang parehong? Sigurado akong sinusubukan nilang gawin ito sa isang paraan o iba pa.
NS: Ngunit aabutin pa rin sila ng ilang segundo, sampu-sampung segundo upang itaas ang isang instance, dalhin doon ang Docker, atbp.
DS: Bakit kailangang itaas ang isang buong instance? Mayroon kaming isang instance na may 32 core, 16... at maaari itong magkasya dito - halimbawa, apat. Kapag nag-order kami ng panglima, itataas na ang instance, at pagkatapos ay tatanggalin ito.
NS: Oo, kawili-wili, ang Kubernetes ay lumalabas na ibang kuwento. Ang aming database ay wala sa K8s, at mayroon kaming isang pagkakataon. Ngunit ang pag-clone ng multi-terabyte database ay tumatagal ng hindi hihigit sa dalawang segundo.
DS: Ito ay kahanga-hanga. Ngunit ang aking paunang punto ay hindi ito isang pangkaraniwang solusyon. Oo, ito ay cool, ngunit ito ay angkop lamang para sa Postgres at lamang sa isang node.
NS: Ito ay angkop hindi lamang para sa mga Postgres: ang mga planong ito, tulad ng inilarawan ko, ay gagana lamang dito. Ngunit kung hindi kami mag-abala tungkol sa mga plano, at kailangan lang namin ang lahat ng data para sa functional na pagsubok, kung gayon ito ay angkop para sa anumang DBMS.
DS: Maraming taon na ang nakalipas gumawa kami ng katulad sa mga snapshot ng LVM. Ito ay isang klasiko. Ang pamamaraang ito ay napaka-aktibong ginamit. Ang mga stateful node ay isang sakit lamang. Dahil hindi mo sila dapat iwan, dapat palagi mo silang tandaan...
NS: May nakikita ka bang posibilidad ng hybrid dito? Sabihin nating ang stateful ay isang uri ng pod, gumagana ito para sa ilang tao (maraming tester). Mayroon kaming isang volume, ngunit salamat sa file system, ang mga clone ay lokal. Kung bumagsak ang pod, ngunit mananatili ang disk, tataas ang pod, magbibilang ng impormasyon tungkol sa lahat ng mga clone, kunin muli ang lahat at sabihin: "Narito ang iyong mga clone na tumatakbo sa mga port na ito, magpatuloy sa pagtatrabaho sa kanila."
DS: Sa teknikal, nangangahulugan ito na sa loob ng Kubernetes ito ay isang pod kung saan kami ay nagpapatakbo ng maraming Postgres.
NS: Oo. May limitasyon siya: sabihin nating hindi hihigit sa 10 tao ang nagtatrabaho sa kanya nang sabay. Kung kailangan mo ng 20, maglulunsad kami ng pangalawang ganoong pod. I-clone namin ito nang buo, nang matanggap ang pangalawang buong volume, magkakaroon ito ng parehong 10 "manipis" na mga clone. Hindi mo ba nakikita ang pagkakataong ito?
DS: Kailangan nating magdagdag ng mga isyu sa seguridad dito. Ang ganitong uri ng organisasyon ay nagpapahiwatig na ang pod na ito ay may mataas na mga pribilehiyo (mga kakayahan), dahil maaari itong magsagawa ng hindi karaniwang mga operasyon sa file system... Ngunit inuulit ko: Naniniwala ako na sa katamtamang termino ay aayusin nila ang storage sa Kubernetes, at sa ang mga ulap ay aayusin nila ang buong kuwento na may mga volume - lahat ay "gagagana lamang". Magkakaroon ng pagbabago sa laki, pag-clone... Mayroong dami - sinasabi namin: "Gumawa ng bago batay doon," at pagkatapos ng isang segundo at kalahati makuha namin ang kailangan namin.
NS: Hindi ako naniniwala sa isa at kalahating segundo para sa maraming terabytes. Sa Ceph ikaw mismo ang gumagawa nito, ngunit pinag-uusapan mo ang mga ulap. Pumunta sa cloud, gumawa ng clone ng multi-terabyte na volume ng EBS sa EC2 at tingnan kung ano ang magiging performance. Hindi ito tatagal ng ilang segundo. Interesado ako kung kailan sila aabot sa antas na ito. Naiintindihan ko ang sinasabi mo, ngunit nakikiusap ako na mag-iba.
DS: Ok, pero sabi ko sa medium term, hindi short term. Sa loob ng ilang taon.
Tungkol sa operator para sa PostgreSQL mula sa Zalando
Sa gitna ng pulong na ito, si Alexey Klyukin, isang dating developer mula sa Zalando, ay sumali din at nagsalita tungkol sa kasaysayan ng operator ng PostgreSQL:
Napakaganda na ang paksang ito ay naaantig sa pangkalahatan: parehong Postgres at Kubernetes. Noong sinimulan naming gawin ito sa Zalando noong 2017, ito ay isang paksa na gustong gawin ng lahat, ngunit walang gumawa. Ang lahat ay mayroon nang Kubernetes, ngunit nang tanungin nila kung ano ang gagawin sa mga database, kahit na ang mga tao ay gusto , na nangaral ng mga K8, ay nagsabi ng ganito:
“Pumunta sa mga pinamamahalaang serbisyo at gamitin ang mga ito, huwag patakbuhin ang database sa Kubernetes. Kung hindi, ang iyong mga K8 ay magpapasya, halimbawa, na mag-upgrade, i-off ang lahat ng mga node, at ang iyong data ay lilipad nang malayo, malayo."
Nagpasya kaming gumawa ng operator na, salungat sa payong ito, ay maglulunsad ng database ng Postgres sa Kubernetes. At mayroon kaming magandang dahilan - . Ito ay isang awtomatikong failover para sa PostgreSQL, tapos nang tama, i.e. gamit ang etcd, consul o ZooKeeper bilang imbakan ng impormasyon tungkol sa cluster. Ang ganitong repositoryo na magbibigay sa lahat ng nagtatanong, halimbawa, kung ano ang kasalukuyang pinuno, ng parehong impormasyon - sa kabila ng katotohanan na naipamahagi na natin ang lahat - upang walang hating utak. Plus nagkaroon kami para sa kanya.
Sa pangkalahatan, lumitaw ang pangangailangan ng kumpanya para sa auto failover pagkatapos lumipat sa cloud mula sa isang internal na hardware data center. Ang ulap ay batay sa isang pagmamay-ari na solusyon ng PaaS (Platform-as-a-Service). Ito ay Open Source, ngunit kinailangan ng maraming trabaho upang maitayo ito at tumakbo. Tinawag ito .
Noong una, walang Kubernetes. Mas tiyak, nang ang sarili nating solusyon ay na-deploy, ang mga K8 ay umiral na, ngunit ito ay sobrang krudo na hindi ito angkop para sa produksyon. Ito ay, sa aking palagay, 2015 o 2016. Pagsapit ng 2017, ang Kubernetes ay naging mas matanda na—may pangangailangan na lumipat doon.
At mayroon na kaming lalagyan ng Docker. Nagkaroon ng PaaS na gumamit ng Docker. Bakit hindi subukan ang K8s? Bakit hindi sumulat ng iyong sariling operator? Si Murat Kabilov, na dumating sa amin mula sa Avito, ay sinimulan ito bilang isang proyekto sa kanyang sariling inisyatiba - "upang maglaro" - at ang proyekto ay "nagsimula."
Ngunit sa pangkalahatan, gusto kong pag-usapan ang tungkol sa AWS. Bakit nagkaroon ng makasaysayang code na nauugnay sa AWS...
Kapag nagpatakbo ka ng isang bagay sa Kubernetes, kailangan mong maunawaan na ang K8s ay isang gawaing kasalukuyang isinasagawa. Ito ay patuloy na umuunlad, bumubuti at kahit na nasira paminsan-minsan. Kailangan mong bantayang mabuti ang lahat ng pagbabago sa Kubernetes, kailangan mong maging handa na sumisid dito kung may mangyari at alamin kung paano ito gumagana nang detalyado - marahil higit pa sa gusto mo. Ito, sa prinsipyo, ay nalalapat sa anumang platform kung saan mo pinapatakbo ang iyong mga database...
Kaya, noong ginawa namin ang pahayag, mayroon kaming mga Postgres na tumatakbo sa isang panlabas na dami (EBS sa kasong ito, dahil nagtatrabaho kami sa AWS). Ang database ay lumago, sa ilang mga punto ito ay kinakailangan upang baguhin ang laki nito: halimbawa, ang unang laki ng EBS ay 100 TB, ang database ay lumago dito, ngayon gusto naming gumawa ng EBS 200 TB. Paano? Sabihin nating maaari kang gumawa ng dump/restore sa isang bagong instance, ngunit ito ay magtatagal at may kasamang downtime.
Samakatuwid, gusto ko ang isang resize na magpapataas ng EBS partition at pagkatapos ay sasabihin sa file system na gamitin ang bagong espasyo. At ginawa namin ito, ngunit sa oras na iyon ang Kubernetes ay walang anumang API para sa pagpapalit ng laki ng operasyon. Dahil nagtrabaho kami sa AWS, nagsulat kami ng code para sa API nito.
Walang pumipigil sa iyo na gawin ang parehong para sa iba pang mga platform. Walang pahiwatig sa pahayag na maaari lamang itong patakbuhin sa AWS, at hindi ito gagana sa lahat ng iba pa. Sa pangkalahatan, ito ay isang Open Source na proyekto: kung sinuman ang gustong pabilisin ang paglitaw ng paggamit ng bagong API, malugod kang tinatanggap. Kumain , pull request - sinusubukan ng Zalando team na tumugon sa kanila nang mabilis at i-promote ang operator. Sa pagkakaalam ko, yung project sa Google Summer of Code at ilang iba pang katulad na mga hakbangin. Si Zalando ay aktibong nagtatrabaho dito.
P.S. Bonus!
Kung interesado ka sa paksa ng PostgreSQL at Kubernetes, mangyaring tandaan din na ang susunod na Postgres Martes ay naganap noong nakaraang linggo, kung saan nakipag-usap ako kay Nikolai Alexander Kukushkin mula sa Zalando. Available ang video mula dito .
Pps
Basahin din sa aming blog:
- «";
- «";
- «";
- «'.
Pinagmulan: www.habr.com