Pada akhir tahun lepas, satu lagi siaran langsung komuniti PostgreSQL Rusia telah berlangsung , semasa pengasas bersamanya Nikolai Samokhvalov bercakap dengan pengarah teknikal Flant Dmitry Stolyarov tentang DBMS ini dalam konteks Kubernetes.
Kami sedang menerbitkan transkrip bahagian utama perbincangan ini, dan di Video penuh disiarkan:
Pangkalan Data dan Kubernetes
NS: Kami tidak akan bercakap tentang VACUUM dan CHECKPOINT hari ini. Kami ingin bercakap tentang Kubernetes. Saya tahu anda mempunyai pengalaman bertahun-tahun. Saya telah menonton video anda dan juga menonton semula beberapa daripadanya... Mari kita terus kepada intipati: mengapa Postgres atau MySQL dalam K8s?
DS: Tidak ada dan tidak boleh menjadi jawapan yang pasti untuk soalan ini. Tetapi secara umum, ini adalah kesederhanaan dan kemudahan... potensi. Semua orang mahukan perkhidmatan terurus.
NS: Bagaimana , hanya di rumah?
DS: Ya: seperti RDS, di mana-mana sahaja.
NS: “Di mana-mana sahaja” ialah perkara yang baik. Dalam syarikat besar, semuanya terletak di tempat yang berbeza. Mengapa, jika ia adalah sebuah syarikat besar, tidak mengambil penyelesaian siap sedia? Sebagai contoh, Nutanix mempunyai perkembangannya sendiri, syarikat lain (VMware...) mempunyai "RDS, hanya di rumah" yang sama.
DS: Tetapi kita bercakap tentang pelaksanaan berasingan yang hanya akan berfungsi dalam keadaan tertentu. Dan jika kita bercakap tentang Kubernetes, maka terdapat pelbagai jenis infrastruktur (yang boleh ada dalam K8). Pada asasnya ini adalah standard untuk API ke awan...
NS: Ia juga percuma!
DS: Ia tidak begitu penting. Kebebasan adalah penting untuk bukan segmen pasaran yang sangat besar. Sesuatu lagi penting... Anda mungkin masih ingat laporan itu “"?
NS: Ya.
DS: Saya menyedari bahawa ia diterima dengan sangat samar-samar. Sesetengah orang menyangka bahawa saya berkata: "Kawan-kawan, mari masukkan semua pangkalan data ke dalam Kubernetes!", manakala yang lain memutuskan bahawa ini semua basikal yang dahsyat. Tetapi saya ingin mengatakan sesuatu yang sama sekali berbeza: "Lihat apa yang berlaku, apa masalah yang ada dan bagaimana ia boleh diselesaikan. Patutkah kita menggunakan pangkalan data Kubernetes sekarang? Pengeluaran? Nah, hanya jika anda suka...melakukan perkara tertentu. Tetapi untuk pembangun, saya boleh mengatakan bahawa saya mengesyorkannya. Untuk pembangun, kedinamikan mencipta/memadamkan persekitaran adalah sangat penting.”
NS: Oleh dev, adakah anda maksudkan semua persekitaran yang bukan prod? Pementasan, QA…
DS: Jika kita bercakap tentang pendirian perf, maka mungkin tidak, kerana keperluan di sana adalah khusus. Jika kita bercakap tentang kes khas di mana pangkalan data yang sangat besar diperlukan untuk pementasan, maka mungkin tidak... Jika ini adalah persekitaran yang statik dan tahan lama, maka apakah faedahnya mempunyai pangkalan data yang terletak di K8s?
NS: Tiada. Tetapi di manakah kita melihat persekitaran statik? Persekitaran statik akan menjadi usang esok.
DS: Pementasan boleh menjadi statik. Kami ada pelanggan...
NS: Ya, saya juga ada. Ia adalah masalah besar jika anda mempunyai pangkalan data 10 TB dan pementasan 200 GB...
DS: Saya mempunyai kes yang sangat keren! Pada pementasan terdapat pangkalan data produk yang mana perubahan dibuat. Dan terdapat butang: "melancarkan pengeluaran". Perubahan ini - delta - ditambah (nampaknya ia hanya disegerakkan melalui API) dalam pengeluaran. Ini adalah pilihan yang sangat eksotik.
NS: Saya telah melihat syarikat pemula di Lembah yang duduk di RDS atau bahkan di Heroku - ini adalah cerita dari 2-3 tahun yang lalu - dan mereka memuat turun dump ke komputer riba mereka. Kerana pangkalan data masih hanya 80 GB, dan terdapat ruang pada komputer riba. Kemudian mereka membeli cakera tambahan untuk semua orang supaya mereka mempunyai 3 pangkalan data untuk menjalankan perkembangan yang berbeza. Ini adalah bagaimana ia berlaku juga. Saya juga melihat bahawa mereka tidak takut untuk menyalin prod ke dalam pementasan - ia sangat bergantung kepada syarikat. Tetapi saya juga melihat bahawa mereka sangat takut, dan mereka sering tidak mempunyai masa dan tangan yang cukup. Tetapi sebelum kita beralih kepada topik ini, saya ingin mendengar tentang Kubernetes. Adakah saya faham dengan betul bahawa tiada sesiapa dalam prod lagi?
DS: Kami mempunyai pangkalan data kecil dalam prod. Kami bercakap tentang volum berpuluh-puluh gigabait dan perkhidmatan tidak kritikal yang mana kami terlalu malas untuk membuat replika (dan tidak ada keperluan sedemikian). Dan dengan syarat terdapat storan biasa di bawah Kubernetes. Pangkalan data ini berfungsi dalam mesin maya - secara bersyarat dalam VMware, di atas sistem storan. Kami meletakkannya di dalam dan kini kita boleh memindahkannya dari mesin ke mesin.
NS: Pangkalan data bersaiz ini, sehingga 100 GB, boleh dilancarkan dalam beberapa minit pada cakera yang baik dan rangkaian yang baik, bukan? Kelajuan 1 GB sesaat tidak lagi eksotik.
DS: Ya, untuk operasi linear ini bukan masalah.
NS: Baiklah, kita hanya perlu memikirkan tentang prod. Dan jika kita mempertimbangkan Kubernetes untuk persekitaran bukan produk, apakah yang perlu kita lakukan? Saya melihatnya di Zalando , dalam Crunchy , terdapat beberapa pilihan lain. Dan ada - ini adalah rakan baik kami Alvaro dari Sepanyol: apa yang mereka lakukan pada dasarnya bukan adil , dan keseluruhan pengedaran (), di mana, sebagai tambahan kepada Postgres sendiri, mereka juga memutuskan untuk memasukkan sandaran, proksi Utusan...
DS: Utusan untuk apa? Mengimbangi trafik Postgres secara khusus?
NS: Ya. Iaitu, mereka melihatnya sebagai: jika anda mengambil pengedaran dan kernel Linux, maka PostgreSQL biasa ialah kernel, dan mereka mahu membuat pengedaran yang akan mesra awan dan dijalankan pada Kubernetes. Mereka menyusun komponen (sandaran, dsb.) dan nyahpepijatnya supaya ia berfungsi dengan baik.
DS: Sangat hebat! Pada asasnya ini adalah perisian untuk mencipta Postgres terurus anda sendiri.
NS: Pengedaran Linux mempunyai masalah kekal: bagaimana untuk membuat pemacu supaya semua perkakasan disokong. Dan mereka mempunyai idea bahawa mereka akan bekerja di Kubernetes. Saya tahu bahawa dalam pengendali Zalando baru-baru ini kami melihat sambungan ke AWS dan ini tidak lagi bagus. Tidak sepatutnya ada ikatan dengan infrastruktur tertentu - apa gunanya?
DS: Saya tidak tahu dengan tepat situasi yang dialami Zalando, tetapi dalam storan Kubernetes kini dibuat sedemikian rupa sehingga mustahil untuk mengambil sandaran cakera menggunakan kaedah generik. Baru-baru ini dalam standard - dalam versi terkini — kami membuat syot kilat mungkin, tetapi di manakah ia dilaksanakan? Sejujurnya, semuanya masih mentah... Kami sedang mencuba CSI selain daripada AWS, GCE, Azure, vSphere, tetapi sebaik sahaja anda mula menggunakannya, anda dapat melihat bahawa ia masih belum bersedia.
NS: Itulah sebabnya kita kadangkala perlu bergantung pada infrastruktur. Saya rasa ini masih peringkat awal - kesakitan yang semakin meningkat. Soalan: Apakah nasihat yang akan anda berikan kepada pemula yang ingin mencuba PgSQL dalam K8s? Pengendali apa mungkin?
DS: Masalahnya ialah Postgres adalah 3% untuk kami. Kami juga mempunyai senarai perisian berbeza yang sangat besar dalam Kubernetes, saya tidak akan menyenaraikan semuanya. Contohnya, Elasticsearch. Terdapat banyak pengendali: ada yang aktif membangun, yang lain tidak. Kami telah menyediakan keperluan untuk diri kami sendiri, apa yang perlu ada dalam pengendali supaya kami mengambilnya dengan serius. Dalam pengendali khusus untuk Kubernetes - bukan dalam "pengendali untuk melakukan sesuatu dalam keadaan Amazon"... Malah, kami secara meluas (= hampir semua pelanggan) menggunakan satu operator - (kami akan menerbitkan artikel tentang beliau tidak lama lagi).
NS: Dan bukan untuk MySQL juga? Saya tahu bahawa Percona... memandangkan mereka kini sedang mengusahakan MySQL, MongoDB dan Postgres, mereka perlu mencipta beberapa jenis penyelesaian universal: untuk semua pangkalan data, untuk semua penyedia awan.
DS: Kami tidak mempunyai masa untuk melihat pengendali untuk MySQL. Ini bukan fokus utama kami sekarang. MySQL berfungsi dengan baik dalam kendiri. Mengapa menggunakan operator jika anda hanya boleh melancarkan pangkalan data... Anda boleh melancarkan bekas Docker dengan Postrges, atau anda boleh melancarkannya dengan cara yang mudah.
NS: Terdapat soalan tentang ini juga. Tiada operator langsung?
DS: Ya, 100% daripada kami menjalankan PostgreSQL tanpa pengendali. Setakat ini. Kami secara aktif menggunakan operator untuk Prometheus dan Redis. Kami mempunyai rancangan untuk mencari operator untuk Elasticsearch - ia adalah yang paling "terbakar", kerana kami mahu memasangnya dalam Kubernetes dalam 100% kes. Sama seperti kami ingin memastikan bahawa MongoDB juga sentiasa dipasang dalam Kubernetes. Di sini keinginan tertentu muncul - ada perasaan bahawa dalam kes ini sesuatu boleh dilakukan. Dan kami tidak melihat Postgres pun. Sudah tentu, kami tahu bahawa terdapat pilihan yang berbeza, tetapi sebenarnya kami mempunyai pilihan tersendiri.
DB untuk ujian dalam Kubernetes
NS: Mari kita beralih kepada topik ujian. Cara untuk melancarkan perubahan pada pangkalan data - dari perspektif DevOps. Terdapat perkhidmatan mikro, banyak pangkalan data, sesuatu berubah di suatu tempat sepanjang masa. Bagaimana untuk memastikan CI/CD biasa supaya semuanya teratur dari perspektif DBMS. Apakah pendekatan anda?
DS: Tidak boleh ada satu jawapan. Terdapat beberapa pilihan. Yang pertama ialah saiz tapak yang kita ingin gulung. Anda sendiri menyebut bahawa syarikat mempunyai sikap yang berbeza terhadap mempunyai salinan pangkalan data prod pada pembangun dan pentas.
NS: Dan di bawah syarat GDPR, saya rasa mereka semakin berhati-hati... Saya boleh katakan di Eropah mereka sudah mula mengenakan denda.
DS: Tetapi selalunya anda boleh menulis perisian yang mengambil pembuangan daripada pengeluaran dan mengaburkannya. Data prod diperolehi (snapshot, dump, salinan binari...), tetapi ia tidak dikenali. Sebaliknya, mungkin terdapat skrip penjanaan: ini boleh menjadi lekapan atau hanya skrip yang menjana pangkalan data yang besar. Masalahnya ialah: berapa lama masa yang diambil untuk mencipta imej asas? Dan berapa lama masa yang diperlukan untuk menggunakan ia dalam persekitaran yang diingini?
Kami datang ke skema: jika pelanggan mempunyai set data tetap (versi minimum pangkalan data), maka kami menggunakannya secara lalai. Jika kita bercakap tentang persekitaran semakan, apabila kami mencipta cawangan, kami menggunakan contoh aplikasi - kami melancarkan pangkalan data kecil di sana. Tetapi ternyata baik , apabila kami mengambil pembuangan daripada pengeluaran sekali sehari (pada waktu malam) dan membina bekas Docker dengan PostgreSQL dan MySQL dengan data dimuatkan ini berdasarkannya. Jika anda perlu mengembangkan pangkalan data 50 kali daripada imej ini, ini dilakukan dengan mudah dan cepat.
NS: Dengan menyalin mudah?
DS: Data disimpan terus dalam imej Docker. Itu. Kami mempunyai imej yang sudah siap, walaupun 100 GB. Terima kasih kepada lapisan dalam Docker, kami boleh menggunakan imej ini dengan cepat seberapa banyak yang kami perlukan. Kaedahnya bodoh, tetapi ia berfungsi dengan baik.
NS: Kemudian, apabila anda menguji, ia berubah betul-betul di dalam Docker, bukan? Salin-tulis di dalam Docker - buang dan pergi lagi, semuanya baik-baik saja. Kelas! Dan adakah anda sudah menggunakannya sepenuhnya?
DS: Untuk masa yang lama.
NS: Kami melakukan perkara yang hampir sama. Cuma kami tidak menggunakan copy-on-write Docker, tetapi yang lain.
DS: Ia bukan generik. Dan Docker berfungsi di mana-mana sahaja.
NS: Secara teori, ya. Tetapi kami juga mempunyai modul di sana, anda boleh membuat modul yang berbeza dan bekerja dengan sistem fail yang berbeza. Apa sekejap di sini. Dari sisi Postgres, kami melihat semua ini secara berbeza. Sekarang saya melihat dari sisi Docker dan melihat bahawa semuanya berfungsi untuk anda. Tetapi jika pangkalan data adalah besar, contohnya, 1 TB, maka semua ini mengambil masa yang lama: operasi pada waktu malam, dan memasukkan segala-galanya ke dalam Docker... Dan jika 5 TB dimasukkan ke dalam Docker... Atau adakah semuanya baik-baik saja?
DS: Apakah perbezaannya: ini adalah gumpalan, hanya bit dan bait.
NS: Perbezaannya ialah: adakah anda melakukannya melalui pembuangan dan pemulihan?
DS: Tidak perlu sama sekali. Kaedah untuk menghasilkan imej ini boleh berbeza.
NS: Bagi sesetengah pelanggan, kami telah membuatnya supaya bukannya menghasilkan imej asas secara kerap, kami sentiasa memastikan ia dikemas kini. Ia pada asasnya adalah replika, tetapi ia menerima data bukan daripada induk secara langsung, tetapi melalui arkib. Arkib binari tempat WAL dimuat turun setiap hari, tempat sandaran diambil... WAL ini kemudiannya mencapai imej asas dengan sedikit kelewatan (secara literal 1-2 saat). Kami mengklon daripadanya dalam apa cara sekalipun - kini kami mempunyai ZFS secara lalai.
DS: Tetapi dengan ZFS anda terhad kepada satu nod.
NS: Ya. Tetapi ZFS juga mempunyai keajaiban : dengan itu anda boleh menghantar syot kilat dan malah (saya belum benar-benar mengujinya lagi, tetapi...) anda boleh menghantar delta antara dua PGDATA. Malah, kami mempunyai alat lain yang belum kami pertimbangkan untuk tugasan sedemikian. PostgreSQL mempunyai , yang berfungsi seperti rsync "pintar", melangkau banyak perkara yang anda tidak perlu tonton, kerana tiada apa yang berubah di sana. Kita boleh melakukan penyegerakan pantas antara kedua-dua pelayan dan putar balik dengan cara yang sama.
Jadi, daripada ini, lebih banyak bahagian DBA, kami cuba mencipta alat yang membolehkan kami melakukan perkara yang sama yang anda katakan: kami mempunyai satu pangkalan data, tetapi kami mahu menguji sesuatu 50 kali, hampir serentak.
DS: 50 kali bermakna anda perlu memesan 50 contoh Spot.
NS: Tidak, kami melakukan segala-galanya pada satu mesin.
DS: Tetapi bagaimana anda akan mengembangkan 50 kali ganda jika pangkalan data ini, katakan, terabait. Kemungkinan besar dia memerlukan 256 GB RAM bersyarat?
NS: Ya, kadangkala anda memerlukan banyak ingatan - itu perkara biasa. Tetapi ini adalah contoh dari kehidupan. Mesin pengeluaran mempunyai 96 teras dan 600 GB. Pada masa yang sama, 32 teras (walaupun 16 teras sekarang kadang-kadang) dan 100-120 GB memori digunakan untuk pangkalan data.
DS: Dan 50 salinan muat di sana?
NS: Jadi hanya ada satu salinan, kemudian copy-on-write (ZFS) berfungsi... Saya akan memberitahu anda dengan lebih terperinci.
Sebagai contoh, kami mempunyai pangkalan data 10 TB. Mereka membuat cakera untuknya, ZFS juga memampatkan saiznya sebanyak 30-40 peratus. Memandangkan kami tidak melakukan ujian beban, masa tindak balas yang tepat tidak penting bagi kami: biarkan sehingga 2 kali lebih perlahan - tidak mengapa.
Kami memberi peluang kepada pengaturcara, QA, DBA, dll. melakukan ujian dalam 1-2 utas. Sebagai contoh, mereka mungkin menjalankan beberapa jenis penghijrahan. Ia tidak memerlukan 10 teras sekaligus - ia memerlukan 1 bahagian belakang Postgres, 1 teras. Penghijrahan akan bermula - mungkin masih akan bermula, maka teras kedua akan digunakan. Kami mempunyai 16-32 teras yang diperuntukkan, jadi 10 orang boleh bekerja pada masa yang sama, tiada masalah.
Kerana secara fizikal PGDATA sama, ternyata kita sebenarnya menipu Postgres. Caranya ialah ini: sebagai contoh, 10 Postgres dilancarkan serentak. Apakah masalah biasanya? Mereka meletakkan , katakan 25%. Oleh itu, ini adalah 200 GB. Anda tidak akan dapat melancarkan lebih daripada tiga daripada ini, kerana memori akan kehabisan.
Tetapi pada satu ketika kami menyedari bahawa ini tidak perlu: kami menetapkan shared_buffers kepada 2 GB. PostgreSQL mempunyai , dan pada hakikatnya ia adalah satu-satunya yang mempengaruhi . Kami menetapkannya kepada 0,5 TB. Dan tidak kira bahawa mereka sebenarnya tidak wujud: dia membuat rancangan seolah-olah ia wujud.
Oleh itu, apabila kami menguji beberapa jenis penghijrahan, kami boleh mengumpul semua rancangan - kami akan melihat bagaimana ia akan berlaku dalam pengeluaran. Detik di sana akan berbeza (lebih perlahan), tetapi data yang sebenarnya kita baca, dan rancangan itu sendiri (apa yang JOIN ada di sana, dll.) ternyata sama seperti dalam pengeluaran. Dan anda boleh menjalankan banyak semakan sedemikian secara selari pada satu mesin.
DS: Adakah anda tidak fikir terdapat sedikit masalah di sini? Yang pertama ialah penyelesaian yang hanya berfungsi pada PostgreSQL. Pendekatan ini sangat peribadi, ia tidak generik. Yang kedua ialah Kubernetes (dan segala-galanya yang akan dilakukan oleh teknologi awan sekarang) melibatkan banyak nod, dan nod ini tidak lama lagi. Dan dalam kes anda, ia adalah nod yang tegas dan berterusan. Perkara-perkara ini membuat saya bercanggah.
NS: Pertama, saya bersetuju, ini adalah cerita Postgres semata-mata. Saya fikir jika kita mempunyai beberapa jenis IO langsung dan kolam penimbal untuk hampir semua memori, pendekatan ini tidak akan berfungsi - rancangannya akan berbeza. Tetapi buat masa ini kami hanya bekerja dengan Postgres, kami tidak memikirkan orang lain.
Mengenai Kubernetes. Anda sendiri memberitahu kami di mana-mana bahawa kami mempunyai pangkalan data yang berterusan. Jika contoh gagal, perkara utama ialah menyimpan cakera. Di sini kami juga mempunyai seluruh platform dalam Kubernetes, dan komponen dengan Postgres adalah berasingan (walaupun ia akan berada di sana suatu hari nanti). Oleh itu, semuanya adalah seperti ini: contoh jatuh, tetapi kami menyimpan PVnya dan hanya menyambungkannya ke contoh lain (baru), seolah-olah tiada apa-apa yang berlaku.
DS: Dari sudut pandangan saya, kami mencipta pod dalam Kubernetes. K8s - elastik: simpulan dipesan mengikut keperluan. Tugasnya adalah untuk mencipta pod dan mengatakan bahawa ia memerlukan jumlah X sumber, dan kemudian K8 akan memikirkannya sendiri. Tetapi sokongan storan dalam Kubernetes masih tidak stabil: Dalam (keluaran ini dikeluarkan minggu ini lalu) ciri ini menjadi beta sahaja.
Enam bulan hingga setahun akan berlalu - ia akan menjadi lebih kurang stabil, atau sekurang-kurangnya ia akan diisytiharkan sedemikian. Kemudian kemungkinan syot kilat dan saiz semula menyelesaikan masalah anda sepenuhnya. Kerana anda mempunyai asas. Ya, ia mungkin tidak begitu pantas, tetapi kelajuan bergantung pada apa yang "di bawah hud", kerana sesetengah pelaksanaan boleh menyalin dan menyalin-atas-tulis pada peringkat subsistem cakera.
NS: Ia juga perlu untuk semua enjin (Amazon, Google...) mula menyokong versi ini - ini juga mengambil sedikit masa.
DS: Kami belum menggunakannya lagi. Kami menggunakan kami.
Pembangunan tempatan untuk Kubernetes
NS: Pernahkah anda menemui keinginan sedemikian apabila anda perlu memasang semua pod pada satu mesin dan melakukan ujian kecil sedemikian. Untuk mendapatkan bukti konsep dengan cepat, lihat bahawa aplikasi berjalan dalam Kubernetes, tanpa mendedikasikan sekumpulan mesin untuknya. Ada Minikube, kan?
DS: Nampaknya kepada saya bahawa kes ini - digunakan pada satu nod - secara eksklusif mengenai pembangunan tempatan. Atau beberapa manifestasi corak sedemikian. makan , terdapat , . Kami bergerak ke arah menggunakan Kubernetes IN Docker. Sekarang kami mula bekerja dengannya untuk ujian.
NS: Saya pernah berfikir bahawa ini adalah percubaan untuk membungkus semua pod dalam satu imej Docker. Tetapi ternyata ini adalah tentang sesuatu yang sama sekali berbeza. Bagaimanapun, terdapat bekas berasingan, pod berasingan - hanya dalam Docker.
DS: Ya. Dan ada tiruan yang agak lucu dibuat, tetapi maksudnya adalah ini... Kami mempunyai utiliti untuk penempatan - . Kami mahu menjadikannya mod bersyarat werf up: “Dapatkan saya Kubernetes tempatan.” Dan kemudian jalankan bersyarat di sana werf follow. Kemudian pembangun akan dapat mengedit IDE, dan proses akan dilancarkan dalam sistem yang melihat perubahan dan membina semula imej, menempatkan semula mereka ke K8 tempatan. Beginilah kita hendak cuba menyelesaikan masalah pembangunan tempatan.
Syot kilat dan pengklonan pangkalan data dalam realiti K8
NS: Jika kita kembali kepada copy-on-write. Saya perhatikan bahawa awan juga mempunyai syot kilat. Mereka bekerja secara berbeza. Contohnya, dalam GCP: anda mempunyai contoh berbilang terabait di pantai timur Amerika Syarikat. Anda mengambil gambar secara berkala. Anda mengambil salinan cakera di pantai barat dari petikan - dalam beberapa minit semuanya sudah siap, ia berfungsi dengan cepat, hanya cache yang perlu diisi dalam ingatan. Tetapi klon ini (gambar) adalah untuk 'memperuntukkan' volum baharu. Ini bagus apabila anda perlu mencipta banyak kejadian.
Tetapi untuk ujian, nampaknya saya syot kilat, yang anda bincangkan dalam Docker atau saya bincangkan dalam ZFS, btrfs dan juga LVM... - ia membenarkan anda untuk tidak mencipta data yang benar-benar baharu pada satu mesin. Dalam awan, anda masih akan membayar untuk mereka setiap kali dan tidak menunggu beberapa saat, tetapi beberapa minit (dan dalam kes itu , mungkin jam tangan).
Sebaliknya, anda boleh mendapatkan data ini dalam satu atau dua saat, jalankan ujian dan buangnya. Syot kilat ini menyelesaikan masalah yang berbeza. Dalam kes pertama - untuk meningkatkan dan mendapatkan replika baharu, dan dalam kes kedua - untuk ujian.
DS: Saya tidak bersetuju. Membuat pengklonan volum berfungsi dengan betul adalah tugas awan. Saya tidak melihat pelaksanaannya, tetapi saya tahu bagaimana kami melakukannya pada perkakasan. Kami mempunyai Ceph, ia membenarkan sebarang volum fizikal () katakan mengklon dan dapatkan volum kedua dengan ciri yang sama dalam berpuluh-puluh milisaat, 'ami, dll. Anda perlu memahami bahawa terdapat salinan-pada-tulis yang rumit di dalamnya. Mengapa awan tidak sepatutnya melakukan perkara yang sama? Saya pasti mereka cuba melakukan ini dengan satu cara atau yang lain.
NS: Tetapi ia masih akan mengambil masa beberapa saat, berpuluh-puluh saat untuk menaikkan contoh, membawa Docker ke sana, dsb.
DS: Mengapakah perlu untuk menaikkan keseluruhan contoh? Kami mempunyai contoh dengan 32 teras, 16... dan ia boleh dimuatkan ke dalamnya - contohnya, empat. Apabila kami memesan yang kelima, contoh itu akan dinaikkan, dan kemudian ia akan dipadamkan.
NS: Ya, menarik, Kubernetes ternyata menjadi cerita yang berbeza. Pangkalan data kami tiada dalam K8, dan kami mempunyai satu contoh. Tetapi pengklonan pangkalan data berbilang terabait mengambil masa tidak lebih daripada dua saat.
DS: Ini bagus. Tetapi perkara awal saya ialah ini bukan penyelesaian generik. Ya, ia bagus, tetapi ia hanya sesuai untuk Postgres dan hanya pada satu nod.
NS: Ia sesuai bukan sahaja untuk Postgres: rancangan ini, seperti yang saya terangkan, hanya akan berfungsi di dalamnya. Tetapi jika kami tidak peduli tentang rancangan, dan kami hanya memerlukan semua data untuk ujian berfungsi, maka ini sesuai untuk mana-mana DBMS.
DS: Bertahun-tahun yang lalu kami melakukan sesuatu yang serupa pada syot kilat LVM. Ini adalah klasik. Pendekatan ini digunakan dengan sangat aktif. Nod stateful hanyalah kesakitan. Kerana anda tidak sepatutnya menjatuhkan mereka, anda harus sentiasa mengingati mereka...
NS: Adakah anda melihat sebarang kemungkinan hibrid di sini? Katakan stateful ialah sejenis pod, ia berfungsi untuk beberapa orang (banyak penguji). Kami mempunyai satu jilid, tetapi terima kasih kepada sistem fail, klon adalah tempatan. Jika pod jatuh, tetapi cakera kekal, pod akan naik, mengira maklumat tentang semua klon, ambil semuanya semula dan katakan: "Ini klon anda berjalan pada port ini, teruskan bekerja dengan mereka."
DS: Secara teknikal ini bermakna dalam Kubernetes ia adalah satu pod di mana kami menjalankan banyak Postgres.
NS: Ya. Dia mempunyai had: katakan tidak lebih daripada 10 orang bekerja dengannya pada masa yang sama. Jika anda memerlukan 20, kami akan melancarkan pod kedua seperti itu. Kami akan mengklon sepenuhnya, setelah menerima volum penuh kedua, ia akan mempunyai 10 klon "nipis" yang sama. Nampak tak peluang ni?
DS: Kami perlu menambah isu keselamatan di sini. Jenis organisasi ini membayangkan bahawa pod ini mempunyai keistimewaan yang tinggi (keupayaan), kerana ia boleh melakukan operasi bukan standard pada sistem fail... Tetapi saya ulangi: Saya percaya bahawa dalam jangka sederhana mereka akan membetulkan storan dalam Kubernetes, dan dalam awan mereka akan membetulkan keseluruhan cerita dengan jilid - semuanya akan "hanya berfungsi". Akan ada ubah saiz, pengklonan... Terdapat kelantangan - kami berkata: "Buat yang baharu berdasarkan itu," dan selepas satu setengah saat kami mendapat apa yang kami perlukan.
NS: Saya tidak percaya dalam satu setengah saat untuk banyak terabait. Pada Ceph anda melakukannya sendiri, tetapi anda bercakap tentang awan. Pergi ke awan, buat klon volum EBS berbilang terabait pada EC2 dan lihat prestasinya. Ia tidak akan mengambil masa beberapa saat. Saya sangat berminat bila mereka akan mencapai tahap ini. Saya faham apa yang anda katakan, tetapi saya mohon untuk berbeza.
DS: Ok, tapi saya cakap dalam jangka masa sederhana, bukan jangka pendek. Untuk beberapa tahun.
Mengenai pengendali untuk PostgreSQL dari Zalando
Di tengah-tengah pertemuan ini, Alexey Klyukin, bekas pemaju dari Zalando, turut menyertai dan bercakap tentang sejarah pengendali PostgreSQL:
Alangkah baiknya topik ini disentuh secara umum: kedua-dua Postgres dan Kubernetes. Apabila kami mula melakukannya di Zalando pada 2017, ia adalah topik yang semua orang mahu lakukan, tetapi tiada siapa yang melakukannya. Semua orang sudah mempunyai Kubernetes, tetapi apabila mereka bertanya apa yang perlu dilakukan dengan pangkalan data, malah orang suka , yang berkhutbah K8, berkata seperti ini:
“Pergi ke perkhidmatan terurus dan gunakannya, jangan jalankan pangkalan data dalam Kubernetes. Jika tidak, K8 anda akan memutuskan, sebagai contoh, untuk membuat peningkatan, mematikan semua nod dan data anda akan terbang jauh, jauh."
Kami memutuskan untuk membuat pengendali yang, bertentangan dengan nasihat ini, akan melancarkan pangkalan data Postgres dalam Kubernetes. Dan kami mempunyai alasan yang kukuh - . Ini adalah failover automatik untuk PostgreSQL, dilakukan dengan betul, i.e. menggunakan etcd, konsul atau ZooKeeper sebagai penyimpanan maklumat tentang kluster. Repositori sedemikian yang akan memberi semua orang yang bertanya, sebagai contoh, apakah pemimpin semasa, maklumat yang sama - walaupun pada hakikatnya kita mempunyai segala-galanya diedarkan - supaya tidak ada otak berpecah. Tambahan pula kami ada untuk dia.
Secara umum, keperluan syarikat untuk auto failover muncul selepas berhijrah dari pusat data perkakasan dalaman ke awan. Awan adalah berdasarkan penyelesaian PaaS (Platform-as-a-Service) proprietari. Ia Sumber Terbuka, tetapi memerlukan banyak usaha untuk menyediakannya dan berjalan. Ia dipanggil .
Pada mulanya, tiada Kubernetes. Lebih tepat lagi, apabila penyelesaian kami sendiri digunakan, K8 telah wujud, tetapi ia sangat kasar sehingga tidak sesuai untuk pengeluaran. Ia, pada pendapat saya, 2015 atau 2016. Menjelang 2017, Kubernetes telah menjadi lebih kurang matang—terdapat keperluan untuk berhijrah ke sana.
Dan kami sudah mempunyai bekas Docker. Terdapat PaaS yang menggunakan Docker. Mengapa tidak mencuba K8s? Mengapa tidak menulis operator anda sendiri? Murat Kabilov, yang datang kepada kami dari Avito, memulakan ini sebagai projek atas inisiatifnya sendiri - "bermain" - dan projek itu "berlepas".
Tetapi secara umum, saya ingin bercakap tentang AWS. Mengapakah terdapat kod berkaitan AWS sejarah...
Apabila anda menjalankan sesuatu dalam Kubernetes, anda perlu memahami bahawa K8 adalah kerja yang sedang dijalankan. Ia sentiasa berkembang, bertambah baik dan juga rosak dari semasa ke semasa. Anda perlu mengawasi semua perubahan dalam Kubernetes dengan teliti, anda perlu bersedia untuk menyelaminya jika sesuatu berlaku dan mempelajari cara ia berfungsi secara terperinci - mungkin lebih daripada yang anda mahukan. Ini, pada dasarnya, terpakai pada mana-mana platform di mana anda menjalankan pangkalan data anda...
Oleh itu, apabila kami melakukan kenyataan itu, kami telah menjalankan Postgres pada volum luaran (EBS dalam kes ini, kerana kami sedang mengusahakan AWS). Pangkalan data berkembang, pada satu ketika adalah perlu untuk mengubah saiznya: contohnya, saiz awal EBS ialah 100 TB, pangkalan data berkembang kepadanya, kini kami mahu membuat EBS 200 TB. Bagaimana? Katakan anda boleh melakukan pembuangan/pemulihan pada kejadian baharu, tetapi ini akan mengambil masa yang lama dan melibatkan masa henti.
Oleh itu, saya mahukan saiz semula yang akan meningkatkan partition EBS dan kemudian memberitahu sistem fail untuk menggunakan ruang baharu. Dan kami melakukannya, tetapi pada masa itu Kubernetes tidak mempunyai sebarang API untuk operasi ubah saiz. Memandangkan kami bekerja pada AWS, kami menulis kod untuk APInya.
Tiada siapa yang menghalang anda daripada melakukan perkara yang sama untuk platform lain. Tiada petunjuk dalam kenyataan bahawa ia hanya boleh dijalankan pada AWS, dan ia tidak akan berfungsi pada semua yang lain. Secara umum, ini adalah projek Sumber Terbuka: jika sesiapa ingin mempercepatkan kemunculan penggunaan API baharu, anda dialu-alukan. makan , permintaan tarik - pasukan Zalando cuba membalasnya dengan agak cepat dan mempromosikan pengendali. Setahu saya, projek itu di Google Summer of Code dan beberapa inisiatif lain yang serupa. Zalando sedang mengusahakannya dengan sangat aktif.
Bonus PS!
Jika anda berminat dengan topik PostgreSQL dan Kubernetes, maka sila ambil perhatian bahawa Postgres Selasa seterusnya berlaku minggu lepas, di mana saya bercakap dengan Nikolai Alexander Kukushkin dari Zalando. Video daripadanya tersedia .
PPS
Baca juga di blog kami:
- «»;
- «»;
- «»;
- «'.
Sumber: www.habr.com