Dina ahir taun ka tukang, siaran langsung séjén komunitas PostgreSQL Rusia lumangsung , salila na ko-pangadeg Nikolai Samokhvalov spoke kalawan diréktur teknis Flant Dmitry Stolyarov ngeunaan DBMS ieu dina konteks Kubernetes.
Kami medarkeun transkrip tina bagian utama sawala ieu, sarta di Video lengkep dipasang:
Basis data sareng Kubernetes
NS: Urang moal ngobrol ngeunaan VACUUM jeung CHECKPOINTs kiwari. Simkuring hoyong ngobrol ngeunaan Kubernetes. Kuring terang anjeun gaduh pangalaman mangtaun-taun. Kuring diawaskeun video Anjeun komo deui diawaskeun sababaraha di antarana ... Hayu urang meunang langsung ka titik: naha Postgres atanapi MySQL di K8s pisan?
ДС: Henteu aya sareng teu tiasa janten jawaban anu pasti pikeun patarosan ieu. Tapi sacara umum, ieu kesederhanaan sareng genah ... poténsial. Sadayana hoyong jasa anu diurus.
NS: Kumaha , ngan di imah?
ДС: Sumuhun: kawas RDS, ngan mana.
NS: "Dimana wae" mangrupakeun titik alus. Di perusahaan ageung, sadayana aya di tempat anu béda. Naha teras, upami perusahaan ageung, henteu nyandak solusi anu siap-siap? Contona, Nutanix boga kamajuan sorangan, pausahaan séjén (VMware ...) boga sarua "RDS, ngan di imah."
ДС: Tapi urang ngobrol ngeunaan hiji palaksanaan misah nu ngan bakal bisa dipaké dina kaayaan nu tangtu. Tur upami urang ngobrol ngeunaan Kubernetes, aya rupa-rupa badag infrastruktur (anu tiasa di K8s). Intina ieu standar pikeun API kana awan ...
NS: Éta ogé gratis!
ДС: Henteu penting pisan. Kabébasan penting pikeun sanés bagéan pasar anu ageung. Lain hal anu penting ... Anjeun meureun apal kana laporan ""?
NS: Enya.
ДС: Kuring sadar yén éta narima pisan ambiguously. Sababaraha urang ngira yén kuring nyebutkeun: "Guys, hayu urang meunang sagala database kana Kubernetes!", bari batur mutuskeun yén ieu téh kabéh sapédah dahsyat. Tapi kuring hoyong nyarios anu béda-béda: "Tingali naon anu kajantenan, masalah naon anu aya sareng kumaha aranjeunna tiasa direngsekeun. Naha urang kedah nganggo database Kubernetes ayeuna? Produksi? Nya, ngan upami anjeun resep ... ngalakukeun hal-hal anu tangtu. Tapi pikeun dev a, abdi tiasa disebutkeun yen kuring nyarankeun eta. Pikeun pamekar, dinamisme nyiptakeun/ngahapus lingkungan penting pisan.
NS: Ku dev, maksud anjeun sadaya lingkungan nu teu prod? Panggung, QA…
ДС: Lamun urang ngobrol ngeunaan stand perf, lajeng meureun moal, sabab sarat aya husus. Lamun urang ngobrol ngeunaan kasus husus dimana database anu kacida gedéna diperlukeun pikeun pementasan, teras meureun moal ... Lamun ieu téh statik, lingkungan lila-cicing, teras naon mangpaatna ngabogaan database lokasina di K8s?
NS: Euweuh. Tapi dimana urang ningali lingkungan statik? Lingkungan statik bakal leungit isukan.
ДС: Pementasan tiasa statik. Kami ngagaduhan klien ...
NS: Sumuhun, abdi gaduh hiji oge. Éta masalah ageung upami anjeun gaduh database 10 TB sareng pementasan 200 GB ...
ДС: Abdi gaduh kasus anu saé pisan! Dina pementasan aya database produk nu parobahan dijieun. Tur aya tombol: "gulung kaluar ka produksi". Parobahan ieu - delta - ditambahkeun (sigana aranjeunna saukur nyingkronkeun via API) dina produksi. Ieu pilihan pisan aheng.
NS: Kuring geus katempo startups di lebak nu linggih di RDS atawa malah di Heroku - ieu carita ti 2-3 sababaraha taun ka pengker - sarta aranjeunna ngundeur dump kana laptop maranéhanana. Kusabab database masih ngan 80 GB, tur aya spasi dina laptop. Teras aranjeunna mésér disk tambahan pikeun sadayana supados aranjeunna gaduh 3 pangkalan data pikeun ngalaksanakeun pamekaran anu béda. Ieu kumaha kajadian ogé. Kuring ogé ningali yén aranjeunna henteu sieun nyalin prod kana pementasan - éta gumantung pisan kana perusahaan. Tapi kuring ogé nempo yén maranéhna pisan sieun, sarta yén maranéhna mindeng teu boga cukup waktu jeung leungeun. Tapi sateuacan urang ngaléngkah ka topik ieu, kuring hoyong ngadangu ngeunaan Kubernetes. Naha kuring ngartos leres yén teu aya anu di prod?
ДС: Urang boga database leutik di prod. Kami nyarioskeun ngeunaan volume puluhan gigabyte sareng jasa non-kritis anu kami puguh teuing ngadamel réplika (sareng teu aya kabutuhan sapertos kitu). Sareng upami aya panyimpenan normal dina Kubernetes. database ieu digawé dina mesin virtual - conditionally di VMware, luhureun sistem gudang. Kami nempatkeun éta sareng ayeuna urang tiasa nransferkeunana tina mesin ka mesin.
NS: Basis data ukuran ieu, nepi ka 100 GB, bisa digulung kaluar dina sababaraha menit dina disk alus tur jaringan alus, katuhu? Laju 1 GB per detik henteu aheng deui.
ДС: Sumuhun, pikeun operasi linier ieu teu masalah.
NS: Oké, urang ngan kudu mikir ngeunaan prod. Sareng upami urang nganggap Kubernetes pikeun lingkungan non-prod, naon anu kedah urang laksanakeun? Kuring ningali éta di Zalando , di Crunchy , Aya sababaraha pilihan séjén. Sareng aya - ieu sobat alus urang Alvaro ti Spanyol: naon maranéhna ngalakukeun dasarna teu ngan , jeung sakabéh distribusi (), dimana, salian ti Postgres sorangan, aranjeunna ogé mutuskeun pikeun nyimpen cadangan, proxy Utusan ...
ДС: Utusan keur naon? Balancing lalulintas Postgres husus?
NS: Enya. Nyaéta, aranjeunna ningali éta: upami anjeun nyandak distribusi Linux sareng kernel, maka PostgreSQL biasa mangrupikeun kernel, sareng aranjeunna hoyong ngadamel distribusi anu bakal ramah-awan sareng dijalankeun dina Kubernetes. Aranjeunna ngahijikeun komponén (cadangan, jsb) sareng debug aranjeunna supados tiasa dianggo saé.
ДС: Geulis pisan! Intina ieu mangrupikeun parangkat lunak pikeun nyiptakeun Postgres anu diurus sorangan.
NS: Distribusi Linux ngagaduhan masalah anu langgeng: kumaha carana ngadamel supir supados sadaya hardware dirojong. Sareng aranjeunna gaduh ide yén aranjeunna bakal damel di Kubernetes. Kuring terang yén dina operator Zalando kami nembe ningali sambungan kana AWS sareng ieu henteu langkung saé. Henteu kedah aya ikatan kana infrastruktur khusus - naon gunana?
ДС: Kuring henteu weruh persis naon kaayaan Zalando ngagaduhan kana, tapi dina gudang Kubernetes ayeuna dijieun dina cara sapertos nu teu mungkin pikeun nyandak cadangan disk ngagunakeun métode generik. Nembe dina standar - dina versi panganyarna - urang nyieun snapshots mungkin, tapi dimana eta dilaksanakeun? Jujur, sagalana masih jadi atah ... Urang nyobian CSI on luhureun AWS, GCE, Azure, vSphere, tapi pas Anjeun mimiti make eta, Anjeun bisa nempo yén éta teu acan siap.
NS: Éta sababna urang sakapeung kudu ngandelkeun infrastruktur. Jigana ieu masih tahap awal - tumuwuh nyeri. Patarosan: Naséhat naon anu anjeun badé masihan ka pemula anu hoyong nyobian PgSQL di K8s? operator naon meureun?
ДС: Masalahna nyaeta Postgres nyaeta 3% keur urang. Urang ogé boga daptar pisan badag tina software béda dina Kubernetes, Kuring malah moal daptar sagalana. Contona, Elasticsearch. Aya seueur operator: sababaraha aktip ngembangkeun, anu sanés henteu. Kami parantos nyusun syarat pikeun diri urang sorangan ngeunaan naon anu kedah dipiboga ku operator supados urang tiasa nyandak sacara serius. Dina operator husus pikeun Kubernetes - henteu dina "operator pikeun ngalakukeun hiji hal dina kaayaan Amazon urang"... Kanyataanna, urang rada lega (= ampir kabéh klien) ngagunakeun operator tunggal - (urang bakal nyebarkeun artikel ngeunaan anjeunna pas).
NS: Sareng sanés pikeun MySQL ogé? Kuring nyaho yén Percona ... saprak aranjeunna ayeuna dipake dina MySQL, MongoDB, sarta Postgres, maranéhna kudu nyieun sababaraha jenis solusi universal: pikeun sakabéh database, pikeun sakabéh panyadia awan.
ДС: Urang teu boga waktu pikeun nempo operator pikeun MySQL. Ieu sanés fokus utama urang ayeuna. MySQL tiasa dianggo sacara mandiri. Naha make operator lamun ngan bisa ngajalankeun database a ... Anjeun tiasa ngajalankeun wadahna Docker kalawan Postrges, atawa anjeun bisa ngajalankeun eta dina cara basajan.
NS: Aya patarosan ngeunaan ieu ogé. Taya operator pisan?
ДС: Leres, 100% urang gaduh PostgreSQL jalan tanpa operator. Sajauh kitu. Urang aktip ngagunakeun operator pikeun Prometheus na Redis. Kami gaduh rencana pikeun milarian operator pikeun Elasticsearch - éta mangrupikeun anu paling "kahuruan", sabab kami hoyong pasang di Kubernetes dina 100% kasus. Sapertos urang hoyong mastikeun yén MongoDB ogé sok dipasang di Kubernetes. Di dieu kahayang tangtu muncul - aya rarasaan yén dina kasus ieu hal bisa dipigawé. Sarta kami malah teu kasampak di Postgres. Tangtosna, urang terang yén aya pilihan anu béda, tapi kanyataanna urang gaduh mandiri.
DB pikeun nguji dina Kubernetes
NS: Hayu urang ngaléngkah ka topik tés. Kumaha gulung kaluar parobihan kana pangkalan data - tina sudut pandang DevOps. Aya microservices, loba database, hal anu ngarobah wae sadaya waktu. Kumaha mastikeun CI / CD normal supados sadayana aya dina urutan tina sudut pandang DBMS. Naon pendekatan anjeun?
ДС: Teu aya hiji jawaban. Aya sababaraha pilihan. Anu kahiji nyaéta ukuran dasar anu urang hoyong gulung. Anjeun nyalira nyarios yén perusahaan gaduh sikap anu béda pikeun gaduh salinan database prod dina dev sareng panggung.
NS: Sareng dina kaayaan GDPR, kuring nyangka aranjeunna langkung ati-ati ... Abdi tiasa nyebatkeun yén di Éropa aranjeunna parantos mimiti maksakeun denda.
ДС: Tapi mindeng anjeun bisa nulis software nu nyokot dump tina produksi jeung obfuscates eta. Data Prod dicandak (snapshot, dump, salinan binér ...), tapi ieu anonim. Sabalikna, tiasa aya skrip generasi: ieu tiasa janten fixtures atanapi ngan ukur naskah anu ngahasilkeun database ageung. Masalahna nyaeta: sabaraha lila waktu nu diperlukeun pikeun nyieun gambar dasar? Sareng sabaraha lami pikeun nyebarkeunana di lingkungan anu dipikahoyong?
Kami sumping ka skéma: upami klien gaduh set data tetep (versi minimal tina pangkalan data), maka kami nganggo éta sacara standar. Lamun urang ngobrol ngeunaan review lingkungan, nalika urang nyieun cabang, urang deployed hiji conto aplikasi - urang gulung kaluar database leutik dinya. Tapi tétéla ogé , Nalika urang nyandak dump tina produksi sakali sapoé (peuting) jeung ngawangun wadah Docker kalawan PostgreSQL na MySQL kalawan data dimuat ieu dumasar kana eta. Lamun perlu dilegakeun database 50 kali tina gambar ieu, ieu dipigawé cukup basajan tur gancang.
NS: Ku niron basajan?
ДС: Data disimpen langsung dina gambar Docker. Jelema. Simkuring boga gambar siap-dijieun, sanajan 100 GB. Hatur nuhun kana lapisan dina Docker, urang tiasa gancang nyebarkeun gambar ieu sababaraha kali sakumaha anu urang peryogikeun. Metoda ieu bodo, tapi gawéna ogé.
NS: Teras, nalika anjeun nguji, éta robih di jero Docker, leres? Salinan-tulis di jero Docker - buang sareng angkat deui, sadayana henteu kunanaon. Kelas! Sareng anjeun parantos ngagunakeunana sacara maksimal?
ДС: Kanggo waktos anu lami.
NS: Urang ngalakukeun hal nu sarupa pisan. Ngan urang henteu nganggo copy-on-write Docker, tapi anu sanés.
ДС: Éta henteu umum. Sareng Docker damel di mana waé.
NS: Sacara teori, enya. Tapi urang ogé boga modul aya, anjeun tiasa ngadamel modul béda jeung karya kalawan sistem file béda. Naon moment di dieu. Ti sisi Postgres, urang tingali sadayana ieu béda. Ayeuna kuring ningali ti sisi Docker sareng ningali yén sadayana tiasa dianggo pikeun anjeun. Tapi lamun database badag, contona, 1 TB, lajeng sadayana ieu butuh waktu lila: operasi peuting, sarta isina sagalana kana Docker ... Jeung lamun 5 TB anu boneka kana Docker ... Atawa sagalana rupa?
ДС: Naon bédana: ieu blobs, ngan bit jeung bait.
NS: Bedana ieu: anjeun ngalakukeun eta ngaliwatan dump tur malikkeun?
ДС: Teu perlu pisan. Métode pikeun ngahasilkeun gambar ieu tiasa béda.
NS: Kanggo sababaraha klien, kami geus dijieun jadi tinimbang rutin ngahasilkeun gambar dasar, urang terus-terusan tetep nepi ka tanggal. Éta dasarna réplika, tapi nampi data henteu langsung ti master, tapi ngalangkungan arsip. Arsip binér dimana WAL diunduh unggal dinten, dimana cadanganna dicandak... WAL ieu teras ngahontal gambar dasar kalayan sakedik reureuh (sacara harfiah 1-2 detik). Urang clone ti dinya sagala cara - ayeuna urang boga ZFS sacara standar.
ДС: Tapi kalawan ZFS anjeun dugi ka hiji titik.
NS: Enya. Tapi ZFS ogé ngabogaan magis : kalawan eta anjeun bisa ngirim snapshot a komo (Kuring teu acan bener diuji ieu, tapi...) Anjeun bisa ngirim délta antara dua PGDATA. Nyatana, urang gaduh alat sanés anu teu acan kami pertimbangkeun pikeun tugas sapertos kitu. PostgreSQL boga , nu gawéna kawas rsync "pinter", skipping loba naon anjeun teu kudu lalajo, sabab euweuh geus robah aya. Urang tiasa ngalakukeun sinkronisasi gancang antara dua server sareng mundur dina cara anu sami.
Janten, ti ieu, langkung seueur sisi DBA, urang nyobian nyiptakeun alat anu ngamungkinkeun urang ngalakukeun hal anu sami anu anjeun nyarios: urang gaduh hiji database, tapi urang hoyong nguji hal 50 kali, ampir sakaligus.
ДС: 50 kali hartina anjeun kudu mesen 50 instansi Spot.
NS: Henteu, urang ngalakukeun sagalana dina hiji mesin.
ДС: Tapi kumaha anjeun bakal dilegakeun 50 kali lamun hiji database ieu, sebutkeun, terabyte. Paling dipikaresep manehna perlu kondisional 256 GB RAM?
NS: Leres, sakapeung anjeun peryogi seueur mémori - éta normal. Tapi ieu conto tina kahirupan. Mesin produksi boga 96 cores na 600 GB. Dina waktu nu sarua, 32 cores (malah 16 cores ayeuna kadang) jeung 100-120 GB memori dipaké pikeun database.
ДС: Sareng 50 eksemplar pas di dinya?
NS: Jadi ngan aya hiji salinan, lajeng copy-on-write (ZFS) jalan ... Kuring gé ngabejaan Anjeun leuwih jéntré.
Contona, urang boga database 10 TB. Aranjeunna ngadamel disk pikeun éta, ZFS ogé dikomprés ukuranana ku 30-40 persen. Kusabab kami henteu ngalakukeun tés beban, waktos réspon anu pasti henteu penting pikeun kami: hayu dugi ka 2 kali langkung laun - éta henteu kunanaon.
Urang masihan kasempetan ka programer, QA, DBA, jsb. ngalakukeun tés dina 1-2 threads. Salaku conto, aranjeunna tiasa ngajalankeun sababaraha jinis migrasi. Teu merlukeun 10 cores sakaligus - perlu 1 Postgres backend, 1 inti. Migrasi bakal ngamimitian - meureun masih bakal ngamimitian, teras inti kadua bakal dipaké. Simkuring gaduh 16-32 cores disadiakeun, jadi 10 urang tiasa dianggo dina waktos anu sareng, euweuh masalah.
Sabab sacara fisik PGDATA sami, tétéla yén kami sabenerna deceiving Postgres. Trik ieu: contona, 10 Postgres diluncurkeun sakaligus. Naon masalahna biasana? Aranjeunna nempatkeun , hayu urang nyebutkeun 25%. Sasuai, ieu 200 GB. Anjeun moal tiasa ngajalankeun langkung ti tilu ieu, sabab mémori bakal béak.
Tapi dina sababaraha waktos urang sadar yén ieu henteu diperyogikeun: urang nyetél shared_buffers ka 2 GB. PostgreSQL boga , sarta dina kanyataanana éta ngan hiji pangaruh . Urang disetel ka 0,5 TB. Sareng henteu masalah yén aranjeunna henteu leres-leres aya: anjeunna ngadamel rencana saolah-olah aya.
Sasuai, nalika urang nguji sababaraha jenis migrasi, urang bisa ngumpulkeun sakabeh rencana - urang bakal ningali kumaha eta bakal kajadian dina produksi. Detik bakal béda (laun), tapi data nu sabenerna urang baca, sarta rencana sorangan (naon ngagabung aya, jsb) Tétéla persis sarua jeung dina produksi. Sareng anjeun tiasa ngajalankeun seueur cek sapertos paralel dina hiji mesin.
ДС: Naha anjeun teu nyangka aya sababaraha masalah di dieu? Anu kahiji nyaéta solusi anu ngan ukur tiasa dianggo dina PostgreSQL. pendekatan ieu pisan swasta, teu generik. Anu kadua nyaéta yén Kubernetes (sareng sadayana anu bakal dilaksanakeun ku téknologi awan) ngalibatkeun seueur titik, sareng titik ieu ephemeral. Jeung bisi anjeun téh stateful, titik pengkuh. hal ieu ngajadikeun kuring conflicted.
NS: Kahiji, kuring satuju, ieu carita murni Postgres. Jigana lamun urang boga sababaraha jenis langsung IO sarta kolam renang panyangga pikeun ampir sakabéh memori, pendekatan ieu moal jalan - rencana bakal béda. Tapi pikeun ayeuna urang ngan ukur damel sareng Postgres, urang henteu mikirkeun batur.
Ngeunaan Kubernetes. Anjeun sorangan ngabejaan urang madhab yén urang boga database pengkuh. Upami instance gagal, hal utama nyaéta nyimpen disk. Di dieu urang ogé boga sakabéh platform di Kubernetes, sarta komponén kalawan Postgres misah (sanajan bakal aya hiji poé). Ku alatan éta, sagalana kawas kieu: instance murag, tapi urang disimpen PV na ngan saukur nyambungkeun ka conto sejen (anyar), saolah-olah euweuh kajadian.
ДС: Ti sudut pandang kuring, urang nyieun pods di Kubernetes. K8s - elastis: knots anu maréntahkeun sakumaha diperlukeun. tugas téh saukur nyieun pod sarta nyebutkeun yén éta perlu jumlah X sumberdaya, lajeng K8s bakal angka eta kaluar sorangan. Tapi dukungan panyimpenan di Kubernetes masih teu stabil: di (pelepasan ieu dirilis недели katukang) fitur ieu janten ukur béta.
Genep bulan nepi ka sataun bakal kaliwat - eta bakal jadi leuwih atawa kirang stabil, atawa sahenteuna bakal dinyatakeun salaku misalna. Lajeng kamungkinan snapshots sarta ukuranana solves masalah anjeun sagemblengna. Kusabab anjeun boga dasar. Sumuhun, éta bisa jadi teu pisan gancang, tapi speed gumantung kana naon "dina tiung", sabab sababaraha palaksanaan bisa nyalin jeung nyalin-on-tulis di tingkat subsistem disk.
NS: Éta ogé diperlukeun pikeun sakabéh mesin (Amazon, Google ...) pikeun ngamimitian ngarojong versi ieu - ieu ogé butuh sababaraha waktu.
ДС: Kami henteu acan nganggo aranjeunna. Urang make milik urang.
Pangwangunan lokal pikeun Kubernetes
NS: Dupi anjeun datang di sakuliah kahayang saperti mun anjeun kudu masang sakabeh pods dina hiji mesin sarta ngalakukeun hiji test leutik. Pikeun gancang meunangkeun bukti konsép, tingali yén aplikasi dijalankeun dina Kubernetes, tanpa dedicating kebat mesin pikeun eta. Aya Minikube, kan?
ДС: Sigana mah kasus ieu - deployed on hiji titik - éksklusif ngeunaan ngembangkeun lokal. Atawa sababaraha manifestasi tina pola kitu. Dahar , Aya , . Kami nuju nganggo Kubernetes IN Docker. Ayeuna urang ngamimitian damel sareng éta pikeun tés.
NS: Kuring biasa mikir yén ieu usaha pikeun mungkus sadayana pods dina hiji gambar Docker. Tapi tétéla yén ieu ngeunaan hal lengkep beda. Atoh, aya wadah anu misah, pods anu misah - ngan di Docker.
ДС: Enya. Tur aya tiruan rada lucu dijieun, tapi hartina ieu ... Simkuring boga utiliti pikeun deployment - . Urang rék nyieun mode kondisional werf up: "Kéngingkeun abdi Kubernetes lokal." Lajeng ngajalankeun kondisional dinya werf follow. Lajeng pamekar bakal tiasa ngédit IDE, sarta prosés bakal dibuka dina sistem nu ningali parobahan na rebuilds gambar, redeploying ka K8s lokal. Ieu kumaha urang rék nyoba ngajawab masalah pangwangunan lokal.
Snapshots sarta kloning database dina K8s kanyataanana
NS: Lamun urang balik deui ka copy-on-write. Kuring noticed nu awan ogé boga snapshots. Aranjeunna dianggo béda. Contona, dina GCP: Anjeun gaduh instance multi-terabyte di basisir wétan Amérika Serikat. Anjeun nyandak snapshots périodik. Anjeun nyokot salinan disk di basisir kulon ti snapshot a - dina sababaraha menit sagalana geus siap, gawéna pisan gancang, ngan cache nu kudu dieusian dina mémori. Tapi klon ieu (snapshots) dina raraga 'nyediakeun' volume anyar. Ieu saé nalika anjeun kedah nyiptakeun seueur instansi.
Tapi pikeun tés, sigana mah snapshots, nu ngobrol ngeunaan di Docker atanapi I ngobrol ngeunaan ZFS, btrfs komo LVM ... - aranjeunna ngidinan Anjeun teu nyieun data bener anyar dina hiji mesin. Dina awan, anjeun masih bakal mayar aranjeunna unggal waktos sareng antosan sanés detik, tapi menit (sareng dina kasus , jigana jam tangan).
Gantina, Anjeun bisa meunangkeun data ieu dina atawa dua detik, ngajalankeun test jeung buang eta jauh. snapshots ieu ngajawab masalah béda. Dina kasus nu pertama - pikeun skala up tur meunangkeun réplika anyar, sarta dina kadua - pikeun tés.
ДС: Abdi henteu satuju. Ngadamel kloning volume leres mangrupikeun tugas awan. Kuring geus teu nempo palaksanaan maranéhna, tapi kuring nyaho kumaha urang ngalakukeun eta dina hardware. Kami gaduh Ceph, éta ngamungkinkeun volume fisik naon waé () nyebutkeun clone sareng kéngingkeun volume kadua kalayan karakteristik anu sami dina puluhan milidetik, 'ami, jsb. Anjeun kedah ngartos yén aya copy-on-write tricky di jero. Naha awan teu kedah sami? Kuring yakin aranjeunna nyobian ngalakukeun ieu salah sahiji cara atanapi anu sanés.
NS: Tapi tetep bakal nyandak aranjeunna detik, puluhan detik pikeun ngangkat hiji conto, mawa Docker aya, jsb.
ДС: Naha perlu ngangkat hiji conto? Simkuring gaduh hiji conto kalawan 32 cores, 16 ... tur éta bisa nyocogkeun kana eta - contona, opat. Nalika kami mesen anu kalima, contona bakal diangkat, teras éta bakal dihapus.
NS: Enya, menarik, Kubernetes tétéla béda carita. database kami henteu di K8s, sarta kami boga hiji conto. Tapi kloning database multi-terabyte nyokot teu leuwih ti dua detik.
ДС: Ieu hébat. Tapi titik awal kuring nyaéta yén ieu sanés solusi umum. Leres, éta saé, tapi ngan ukur cocog pikeun Postgres sareng ngan ukur dina hiji titik.
NS: Ieu cocog henteu ngan pikeun Postgres: rencana ieu, sakumaha kuring dijelaskeun, ngan bakal dianggo dina eta. Tapi upami urang henteu ngaganggu rencana, sareng urang ngan ukur peryogi sadaya data pikeun uji fungsional, maka ieu cocog pikeun DBMS naon waé.
ДС: Loba sababaraha taun ka pengker urang ngalakukeun hal sarupa dina snapshots LVM. Ieu klasik. Pendekatan ieu dianggo pisan aktip. Titik stateful ngan nyeri. Kusabab anjeun teu kedah leupaskeun aranjeunna, anjeun kedah salawasna inget aranjeunna ...
NS: Naha anjeun ningali kamungkinan hibrida di dieu? Hayu urang nyebutkeun stateful sababaraha jenis pod, gawéna pikeun sababaraha urang (loba testers). Kami gaduh hiji volume, tapi hatur nuhun kana sistem file, klonna lokal. Upami pod ragrag, tapi disk tetep, pod bakal naek, ngitung inpormasi ngeunaan sadaya klon, angkat sadayana deui sareng ucapkeun: "Ieu klon anjeun dijalankeun dina palabuhan ieu, teraskeun damel sareng aranjeunna."
ДС: Téhnisna ieu ngandung harti yén dina Kubernetes éta hiji pod di mana urang ngajalankeun loba Postgres.
NS: Enya. Anjeunna boga wates: hayu urang nyebutkeun teu leuwih ti 10 urang gawé bareng anjeunna dina waktos anu sareng. Upami anjeun peryogi 20, kami bakal ngaluncurkeun pod sapertos anu kadua. Urang bakal pinuh clone eta, sanggeus narima volume pinuh kadua, eta bakal sarua 10 clones "ipis". Naha anjeun henteu ningali kasempetan ieu?
ДС: Urang kedah nambihan masalah kaamanan di dieu. jenis ieu organisasi ngakibatkeun yen pod ieu boga hak husus luhur (kamampuhan), sabab bisa ngalakukeun operasi non-standar dina sistem file ... Tapi kuring ngulang: Kuring yakin yén dina istilah sedeng maranéhna bakal ngalereskeun gudang di Kubernetes, sarta dina awan maranéhna bakal ngalereskeun sakabeh carita kalawan volume - sagalana bakal "ngan jalan". Bakal aya ukuranana, kloning... Aya volume - urang nyebutkeun: "Jieun nu anyar dumasar kana éta," sarta sanggeus satengah detik urang meunang naon urang kudu.
NS: Kuring teu percanten ka hiji satengah detik keur loba terabytes. Dina Ceph anjeun ngalakukeun eta diri, tapi anjeun ngobrol ngeunaan awan. Pindah ka awan, jieun clone tina volume EBS multi-terabyte dina EC2 sareng tingali kumaha kinerjana. Éta moal nyandak sababaraha detik. Abdi resep pisan nalika aranjeunna bakal ngahontal tingkat ieu. Abdi ngartos naon anu anjeun carioskeun, tapi kuring menta béda.
ДС: Ok, tapi ceuk kuring dina jangka sedeng, teu jangka pondok. Pikeun sababaraha taun.
Ngeunaan operator pikeun PostgreSQL ti Zalando
Di tengah rapat ieu, Alexey Klyukin, urut pamekar ti Zalando, ogé ngagabung sareng nyarios ngeunaan sajarah operator PostgreSQL:
Ieu hébat yén topik ieu keuna kana sacara umum: duanana Postgres na Kubernetes. Nalika urang ngamimitian ngalakukeun éta di Zalando di 2017, éta mangrupikeun topik anu sadayana hoyong laksanakeun, tapi teu aya anu ngalakukeun. Sarerea geus boga Kubernetes, tapi lamun maranéhna nanya naon nu kudu jeung database, malah jalma resep , anu ngahutbah K8s, nyarios sapertos kieu:
"Pindah ka jasa anu diurus sareng dianggo, ulah ngajalankeun pangkalan data dina Kubernetes. Upami teu kitu, K8 anjeun bakal mutuskeun, contona, pikeun ningkatkeun, mareuman sadaya titik, sareng data anjeun bakal ngapung jauh, jauh.
Kami mutuskeun pikeun ngadamel operator anu, sabalikna tina naséhat ieu, bakal ngaluncurkeun database Postgres di Kubernetes. Sareng kami ngagaduhan alesan anu saé - . Ieu mangrupa failover otomatis pikeun PostgreSQL, dipigawé leres, i.e. ngagunakeun etcd, konsul atanapi ZooKeeper salaku neundeun informasi ngeunaan klaster. Repository sapertos anu bakal masihan saha waé anu naroskeun, contona, naon pamimpin ayeuna, inpormasi anu sami - sanaos kanyataan yén urang gaduh sadayana disebarkeun - supados henteu aya otak pamisah. Ditambah urang tadi pikeun anjeunna.
Sacara umum, kabutuhan perusahaan pikeun failover otomatis muncul saatos migrasi ti pusat data hardware internal ka awan. Awan ieu dumasar kana solusi PaaS (Platform-as-a-Service) proprietary. Ieu Open Source, tapi butuh loba gawé pikeun meunangkeun eta nepi na ngajalankeun. Ieu disebut .
Mimitina, teu aya Kubernetes. Leuwih tepat, nalika solusi urang sorangan ieu deployed, K8s geus eksis, tapi éta jadi atah nu teu cocog pikeun produksi. Éta, dina pamanggih kuring, 2015 atanapi 2016. Taun 2017, Kubernetes parantos janten langkung dewasa-aya peryogi migrasi ka dinya.
Sareng kami parantos ngagaduhan wadah Docker. Aya PaaS anu nganggo Docker. Naha henteu coba K8s? Naha henteu nyerat operator anjeun nyalira? Murat Kabilov, anu sumping ka kami ti Avito, dimimitian ieu salaku proyék on prakarsa sorangan - "maén" - sarta proyék "nyeepkeun".
Tapi sacara umum, kuring hoyong ngobrol ngeunaan AWS. Naha aya kode sajarah AWS patali ...
Lamun anjeun ngajalankeun hiji hal di Kubernetes, anjeun kudu ngarti yén K8s mangrupa karya sapertos lumangsung. Éta terus-terusan ngembang, ningkatkeun sareng bahkan ngarecah ti jaman ka jaman. Anjeun kedah ngawaskeun sadaya parobihan dina Kubernetes, anjeun kedah siap nyilem kana éta upami aya kajadian sareng diajar kumaha jalanna sacara rinci - sigana langkung seueur tibatan anu anjeun pikahoyong. Ieu, prinsipna, manglaku ka platform naon waé anu anjeun ngajalankeun database anjeun ...
Janten, nalika kami ngalakukeun pernyataan éta, kami ngagaduhan Postgres dina volume éksternal (EBS dina hal ieu, sabab kami damel di AWS). Basis data naék, dina sababaraha waktos éta kedah ngarobih ukuranana: contona, ukuran awal EBS nyaéta 100 TB, pangkalan data naék kana éta, ayeuna urang badé ngadamel EBS 200 TB. Kumaha? Hayu urang nyebutkeun anjeun tiasa ngalakukeun dump a / balikkeun on conto anyar, tapi ieu bakal butuh waktu lila tur ngalibetkeun downtime.
Ku alatan éta, kuring miharep hiji ukuran nu bakal ngagedekeun partisi EBS lajeng ngabejaan sistem file ngagunakeun spasi anyar. Sareng urang ngalakukeun éta, tapi dina waktos éta Kubernetes henteu ngagaduhan API pikeun operasi ukuranana. Kusabab urang dikeureuyeuh AWS, urang nulis kode pikeun API na.
Teu aya anu ngahalangan anjeun ngalakukeun hal anu sami pikeun platform anu sanés. Henteu aya petunjuk dina pernyataan yén éta ngan ukur tiasa dijalankeun dina AWS, sareng éta moal tiasa dianggo dina sadayana anu sanés. Sacara umum, ieu mangrupa proyék Open Source: lamun saha hayang nyepetkeun mecenghulna pamakéan API anyar, anjeun wilujeng sumping. Dahar , Tarik requests - tim Zalando nyoba ngabales aranjeunna rada gancang tur ngamajukeun operator. Sajauh kuring terang, proyék di Google Summer of Code sareng sababaraha inisiatif anu sami. Zalando damel pisan aktip dina éta.
Bonus PS!
Upami anjeun resep kana topik PostgreSQL sareng Kubernetes, maka punten ogé perhatikeun yén Postgres Salasa salajengna lumangsung minggu kamari, dimana kuring ngobrol sareng Nikolai. Alexander Kukushkin ti Zalando. Video ti éta sayogi .
PPS
Baca ogé dina blog urang:
- «";
- «";
- «";
- «".
sumber: www.habr.com