Pada akhir tahun lalu, siaran langsung lainnya dari komunitas PostgreSQL Rusia berlangsung , di mana salah satu pendirinya Nikolai Samokhvalov berbicara dengan direktur teknis Flant Dmitry Stolyarov tentang DBMS ini dalam konteks Kubernetes.
Kami menerbitkan transkrip bagian utama diskusi ini, dan di Video lengkap diposting:
Database dan Kubernetes
NS: Kita tidak akan membicarakan VAKUM dan TITIK PERIKSA hari ini. Kami ingin berbicara tentang Kubernetes. Saya tahu Anda memiliki pengalaman bertahun-tahun. Saya menonton video Anda dan bahkan menonton ulang beberapa di antaranya... Langsung saja ke intinya: mengapa Postgres atau MySQL ada di K8s?
DS: Tidak ada dan tidak mungkin ada jawaban pasti untuk pertanyaan ini. Namun secara umum, ini adalah kesederhanaan dan kenyamanan... potensi. Semua orang menginginkan layanan terkelola.
NS: Untuk bagaimana , hanya di rumah?
DS: Ya: seperti RDS, di mana saja.
NS: “Di mana saja” adalah poin yang bagus. Di perusahaan besar, semuanya berlokasi di tempat yang berbeda. Lalu mengapa, jika ini adalah perusahaan besar, tidak mengambil solusi yang sudah jadi? Misalnya, Nutanix memiliki pengembangannya sendiri, perusahaan lain (VMware...) memiliki “RDS, hanya di rumah” yang sama.
DS: Namun kita berbicara tentang implementasi terpisah yang hanya akan berfungsi dalam kondisi tertentu. Dan jika kita berbicara tentang Kubernetes, maka terdapat banyak variasi infrastruktur (yang mungkin ada di K8). Pada dasarnya ini adalah standar untuk API ke cloud...
NS: Ini juga gratis!
DS: Itu tidak begitu penting. Freeness penting untuk segmen pasar yang tidak terlalu besar. Ada hal lain yang penting... Anda mungkin ingat laporannya “»?
NS: Ya.
DS: Saya menyadari bahwa hal itu diterima dengan sangat ambigu. Beberapa orang mengira saya sedang berkata: “Teman-teman, ayo masukkan semua database ke Kubernetes!”, sementara yang lain berpendapat bahwa ini semua adalah sepeda yang buruk. Namun saya ingin mengatakan sesuatu yang sama sekali berbeda: “Lihat apa yang terjadi, masalah apa yang ada dan bagaimana cara mengatasinya. Haruskah kita menggunakan database Kubernetes sekarang? Produksi? Ya, hanya jika Anda suka...melakukan hal-hal tertentu. Namun bagi seorang dev, saya dapat mengatakan bahwa saya merekomendasikannya. Bagi seorang pengembang, dinamisme dalam membuat/menghapus lingkungan sangatlah penting.”
NS: Yang dimaksud dengan dev adalah semua lingkungan yang bukan prod? Pementasan, QA…
DS: Jika kita berbicara tentang perf stand, mungkin tidak, karena persyaratannya spesifik. Jika kita berbicara tentang kasus khusus di mana database yang sangat besar diperlukan untuk pementasan, mungkin tidak... Jika ini adalah lingkungan statis dan berumur panjang, lalu apa manfaat memiliki database yang berlokasi di K8s?
NS: Tidak ada. Namun di mana kita melihat lingkungan statis? Lingkungan statis akan menjadi usang besok.
DS: Pementasan bisa bersifat statis. Kami memiliki klien...
NS: Ya, saya juga punya. Ini masalah besar jika Anda memiliki database 10 TB dan pementasan 200 GB...
DS: Saya punya kasus yang sangat keren! Pada pementasan ada database produk tempat perubahan dilakukan. Dan ada tombol: “luncurkan ke produksi”. Perubahan ini - delta - ditambahkan (tampaknya hanya disinkronkan melalui API) dalam produksi. Ini adalah pilihan yang sangat eksotis.
NS: Saya telah melihat startup di Valley yang duduk di RDS atau bahkan di Heroku - ini adalah cerita dari 2-3 tahun yang lalu - dan mereka mengunduh dump tersebut ke laptop mereka. Karena databasenya masih hanya 80 GB, dan masih ada ruang di laptop. Kemudian mereka membeli disk tambahan untuk setiap orang sehingga mereka memiliki 3 database untuk melakukan pengembangan yang berbeda. Hal ini juga terjadi. Saya juga melihat bahwa mereka tidak takut untuk menyalin produk ke dalam pementasan - itu sangat bergantung pada perusahaannya. Namun saya juga melihat bahwa mereka sangat takut, dan sering kali mereka tidak mempunyai cukup waktu dan tenaga. Namun sebelum kita beralih ke topik ini, saya ingin mendengar tentang Kubernetes. Apakah saya memahami dengan benar bahwa belum ada seorang pun yang melakukan produksi?
DS: Kami memiliki database kecil di prod. Kita berbicara tentang volume puluhan gigabyte dan layanan non-kritis yang kami terlalu malas untuk membuat replikanya (dan hal itu tidak diperlukan). Dan asalkan ada penyimpanan normal di bawah Kubernetes. Basis data ini berfungsi di mesin virtual - secara kondisional di VMware, di atas sistem penyimpanan. Kami menempatkannya dan sekarang kita dapat mentransfernya dari mesin ke mesin.
NS: Basis data sebesar ini, hingga 100 GB, dapat diluncurkan dalam beberapa menit pada disk yang bagus dan jaringan yang bagus, bukan? Kecepatan 1 GB per detik sudah tidak asing lagi.
DS: Ya, untuk operasi linier hal ini tidak menjadi masalah.
NS: Oke, kita hanya perlu memikirkan prod. Dan jika kita mempertimbangkan Kubernetes untuk lingkungan non-prod, apa yang harus kita lakukan? Saya melihatnya di Zalando , di Renyah , ada beberapa opsi lain. Dan memang ada - ini teman baik kita Alvaro dari Spanyol: apa yang mereka lakukan pada dasarnya tidak adil , dan seluruh distribusi (), di mana, selain Postgres itu sendiri, mereka juga memutuskan untuk memasukkan cadangan, proxy Utusan...
DS: Utusan untuk apa? Menyeimbangkan lalu lintas Postgres secara khusus?
NS: Ya. Artinya, mereka melihatnya sebagai berikut: jika Anda menggunakan distribusi dan kernel Linux, maka PostgreSQL biasa adalah kernelnya, dan mereka ingin membuat distribusi yang ramah cloud dan berjalan di Kubernetes. Mereka mengumpulkan komponen (cadangan, dll.) dan melakukan debug agar berfungsi dengan baik.
DS: Sangat keren! Pada dasarnya ini adalah perangkat lunak untuk membuat Postgres terkelola Anda sendiri.
NS: Distribusi Linux memiliki masalah abadi: bagaimana membuat driver agar semua perangkat keras didukung. Dan mereka mempunyai gagasan bahwa mereka akan bekerja di Kubernetes. Saya tahu bahwa di operator Zalando kami baru-baru ini melihat koneksi ke AWS dan ini tidak lagi bagus. Tidak boleh ada keterkaitan dengan infrastruktur tertentu - lalu apa gunanya?
DS: Saya tidak tahu persis situasi apa yang dialami Zalando, tetapi penyimpanan di Kubernetes sekarang dibuat sedemikian rupa sehingga tidak mungkin untuk mengambil cadangan disk menggunakan metode umum. Baru-baru ini dalam standar - dalam versi terbaru — kami membuat snapshot menjadi mungkin, namun di mana penerapannya? Sejujurnya, semuanya masih mentah... Kami mencoba CSI di atas AWS, GCE, Azure, vSphere, tetapi segera setelah Anda mulai menggunakannya, Anda dapat melihat bahwa itu belum siap.
NS: Itu sebabnya kita terkadang harus bergantung pada infrastruktur. Saya pikir ini masih tahap awal - pertumbuhan yang menyakitkan. Pertanyaan: Saran apa yang akan Anda berikan kepada pemula yang ingin mencoba PgSQL di K8s? Operator apa mungkin?
DS: Masalahnya Postgres 3% untuk kami. Kami juga memiliki banyak sekali daftar perangkat lunak berbeda di Kubernetes, saya bahkan tidak akan mencantumkan semuanya. Misalnya, Pencarian Elastis. Ada banyak operator: ada yang aktif berkembang, ada yang tidak. Kami sudah menyusun sendiri persyaratannya, apa saja yang harus ada pada operator agar kami tanggapi dengan serius. Di operator khusus untuk Kubernetes - bukan di "operator untuk melakukan sesuatu dalam kondisi Amazon"... Faktanya, kami cukup luas (= hampir semua klien) menggunakan satu operator - (kami akan segera menerbitkan artikel tentang dia).
NS: Dan bukan untuk MySQL juga? Saya tahu Percona... karena mereka sekarang mengerjakan MySQL, MongoDB, dan Postgres, mereka harus membuat semacam solusi universal: untuk semua database, untuk semua penyedia cloud.
DS: Kami tidak punya waktu untuk melihat operator MySQL. Ini bukan fokus utama kami saat ini. MySQL berfungsi dengan baik secara mandiri. Mengapa menggunakan operator jika Anda bisa meluncurkan database... Anda dapat meluncurkan container Docker dengan Postrges, atau Anda dapat meluncurkannya dengan cara yang sederhana.
NS: Ada pertanyaan tentang ini juga. Tidak ada operator sama sekali?
DS: Ya, 100% dari kita menjalankan PostgreSQL tanpa operator. Sejauh ini. Kami secara aktif menggunakan operator untuk Prometheus dan Redis. Kami memiliki rencana untuk mencari operator untuk Elasticsearch - operator inilah yang paling “on fire”, karena kami ingin menginstalnya di Kubernetes dalam 100% kasus. Sama seperti kami ingin memastikan bahwa MongoDB juga selalu terinstal di Kubernetes. Di sini muncul keinginan tertentu - ada perasaan bahwa dalam kasus ini sesuatu dapat dilakukan. Dan kami bahkan tidak melihat Postgres. Tentu saja, kami tahu bahwa ada opsi yang berbeda, tetapi sebenarnya kami memiliki opsi yang berdiri sendiri.
DB untuk pengujian di Kubernetes
NS: Mari beralih ke topik pengujian. Cara menerapkan perubahan pada database - dari perspektif DevOps. Ada layanan mikro, banyak database, ada sesuatu yang berubah sepanjang waktu. Bagaimana memastikan CI/CD normal sehingga semuanya beres dari perspektif DBMS. Apa pendekatan Anda?
DS: Tidak mungkin ada satu jawaban. Ada beberapa pilihan. Yang pertama adalah ukuran alas yang ingin kita gulung. Anda sendiri menyebutkan bahwa perusahaan memiliki sikap berbeda terhadap salinan database produk pada tahap pengembangan dan tahap.
NS: Dan berdasarkan ketentuan GDPR, menurut saya mereka semakin berhati-hati... Saya dapat mengatakan bahwa di Eropa mereka sudah mulai mengenakan denda.
DS: Namun sering kali Anda dapat menulis perangkat lunak yang mengambil dump dari produksi dan mengaburkannya. Data produksi diperoleh (snapshot, dump, salinan biner...), tetapi dianonimkan. Sebaliknya, mungkin ada skrip pembangkitan: ini bisa berupa perlengkapan atau hanya skrip yang menghasilkan database besar. Masalahnya: berapa lama waktu yang dibutuhkan untuk membuat gambar dasar? Dan berapa lama waktu yang dibutuhkan untuk menerapkannya di lingkungan yang diinginkan?
Kami sampai pada sebuah skema: jika klien memiliki kumpulan data tetap (versi minimal database), maka kami menggunakannya secara default. Jika kita berbicara tentang lingkungan peninjauan, saat kami membuat cabang, kami menyebarkan sebuah instance aplikasi - kami meluncurkan database kecil di sana. Tapi ternyata hasilnya bagus , ketika kita mengambil dump dari produksi sekali sehari (di malam hari) dan membangun container Docker dengan PostgreSQL dan MySQL dengan data yang dimuat berdasarkan itu. Jika Anda perlu memperluas database 50 kali dari gambar ini, ini dilakukan dengan cukup sederhana dan cepat.
NS: Dengan menyalin sederhana?
DS: Data disimpan langsung di image Docker. Itu. Kami memiliki gambar yang sudah jadi, meskipun 100 GB. Berkat lapisan di Docker, kami dapat dengan cepat menyebarkan image ini sebanyak yang kami perlukan. Metodenya bodoh, tapi berhasil dengan baik.
NS: Lalu, saat Anda mengujinya, itu berubah langsung di dalam Docker, bukan? Copy-on-write di dalam Docker - buang dan jalankan lagi, semuanya baik-baik saja. Kelas! Dan apakah Anda sudah menggunakannya secara maksimal?
DS: Untuk waktu yang lama.
NS: Kami melakukan hal yang sangat mirip. Hanya saja kami tidak menggunakan copy-on-write Docker, tetapi yang lain.
DS: Ini tidak umum. Dan Docker bekerja di mana saja.
NS: Secara teori, ya. Namun kami juga memiliki modul di sana, Anda dapat membuat modul berbeda dan bekerja dengan sistem file berbeda. Momen yang luar biasa di sini. Dari sisi Postgres, kami memandang semua ini secara berbeda. Sekarang saya melihat dari sisi Docker dan melihat bahwa semuanya berfungsi untuk Anda. Tetapi jika databasenya sangat besar, misalnya 1 TB, maka semua ini membutuhkan waktu lama: pengoperasian di malam hari, dan memasukkan semuanya ke Docker... Dan jika 5 TB dimasukkan ke Docker... Atau semuanya baik-baik saja?
DS: Apa bedanya: ini adalah gumpalan, hanya bit dan byte.
NS: Bedanya begini: apakah dilakukan melalui dump dan recovery?
DS: Sama sekali tidak perlu. Metode untuk menghasilkan gambar ini bisa berbeda-beda.
NS: Untuk beberapa klien, kami telah membuatnya sehingga alih-alih membuat gambar dasar secara rutin, kami terus memperbaruinya. Ini pada dasarnya adalah replika, tetapi menerima data bukan dari master secara langsung, tetapi melalui arsip. Arsip biner tempat WAL diunduh setiap hari, tempat pencadangan dilakukan... WAL ini kemudian mencapai gambar dasar dengan sedikit penundaan (secara harfiah 1-2 detik). Kami mengkloningnya dengan cara apa pun - sekarang kami memiliki ZFS secara default.
DS: Namun dengan ZFS Anda dibatasi pada satu node.
NS: Ya. Namun ZFS juga memiliki keajaiban : dengan itu Anda dapat mengirim snapshot dan bahkan (saya belum benar-benar mengujinya, tapi...) Anda dapat mengirim delta di antara dua PGDATA. Faktanya, kami memiliki alat lain yang belum kami pertimbangkan untuk tugas-tugas tersebut. PostgreSQL punya , yang berfungsi seperti rsync "pintar", melewatkan banyak hal yang tidak perlu Anda tonton, karena tidak ada yang berubah di sana. Kita dapat melakukan sinkronisasi cepat antara kedua server dan memundurkannya dengan cara yang sama.
Jadi, dari sisi DBA ini, kami mencoba membuat alat yang memungkinkan kami melakukan hal yang sama seperti yang Anda katakan: kami memiliki satu database, tetapi kami ingin menguji sesuatu sebanyak 50 kali, hampir bersamaan.
DS: 50 kali berarti Anda perlu memesan 50 instans Spot.
NS: Tidak, kami melakukan semuanya di satu mesin.
DS: Tapi bagaimana Anda bisa memperluas 50 kali lipat jika database yang satu ini berukuran, katakanlah, terabyte. Kemungkinan besar dia membutuhkan RAM bersyarat 256 GB?
NS: Ya, terkadang Anda membutuhkan banyak memori - itu normal. Tapi ini adalah contoh dari kehidupan. Mesin produksi memiliki 96 core dan 600 GB. Pada saat yang sama, 32 core (bahkan terkadang 16 core) dan memori 100-120 GB digunakan untuk database.
DS: Dan 50 eksemplar muat di sana?
NS: Jadi hanya ada satu salinan, lalu copy-on-write (ZFS) berfungsi... Saya akan ceritakan lebih detail.
Misalnya, kami memiliki database 10 TB. Mereka membuat disk untuk itu, ZFS juga mengompresi ukurannya sebesar 30-40 persen. Karena kami tidak melakukan pengujian beban, waktu respons yang tepat tidak penting bagi kami: biarkan hingga 2 kali lebih lambat - tidak apa-apa.
Kami memberikan kesempatan kepada programmer, QA, DBA, dll. melakukan pengujian di 1-2 thread. Misalnya, mereka mungkin melakukan semacam migrasi. Itu tidak memerlukan 10 core sekaligus - dibutuhkan 1 backend Postgres, 1 core. Migrasi akan dimulai - mungkin masih akan mulai, maka inti kedua akan digunakan. Kami memiliki alokasi 16-32 core, sehingga 10 orang dapat bekerja pada saat yang sama, tidak masalah.
Karena secara fisik PGDATA sama saja, ternyata kita sebenarnya menipu Postgres. Caranya begini: misalnya 10 Postgres diluncurkan secara bersamaan. Biasanya masalahnya apa? Mereka menaruh , katakanlah 25%. Oleh karena itu, ini adalah 200 GB. Anda tidak akan dapat meluncurkan lebih dari tiga, karena memori akan habis.
Namun pada titik tertentu kami menyadari bahwa ini tidak perlu: kami menyetel shared_buffers ke 2 GB. PostgreSQL punya , dan kenyataannya hanya itu yang mempengaruhi . Kami menyetelnya ke 0,5 TB. Dan tidak masalah jika rencana itu tidak benar-benar ada: dia membuat rencana seolah-olah rencana itu ada.
Oleh karena itu, saat kami menguji beberapa jenis migrasi, kami dapat mengumpulkan semua rencana - kami akan melihat bagaimana hal itu akan terjadi dalam produksi. Detiknya akan berbeda (lebih lambat), tetapi data yang sebenarnya kita baca, dan rencana itu sendiri (bergabung apa yang ada di sana, dll.) ternyata sama persis dengan di produksi. Dan Anda dapat menjalankan banyak pemeriksaan seperti itu secara paralel di satu mesin.
DS: Tidakkah menurut Anda ada beberapa masalah di sini? Yang pertama adalah solusi yang hanya berfungsi di PostgreSQL. Pendekatan ini bersifat sangat pribadi dan tidak umum. Yang kedua adalah Kubernetes (dan segala sesuatu yang terjadi pada teknologi cloud saat ini) melibatkan banyak node, dan node ini bersifat sementara. Dan dalam kasus Anda, ini adalah node yang stateful dan persisten. Hal-hal ini membuat saya berkonflik.
NS: Pertama, saya setuju, ini murni cerita Postgres. Saya pikir jika kita memiliki semacam IO langsung dan kumpulan buffer untuk hampir seluruh memori, pendekatan ini tidak akan berhasil - rencananya akan berbeda. Namun untuk saat ini kami hanya bekerja dengan Postgres, kami tidak memikirkan yang lain.
Tentang Kubernet. Anda sendiri memberi tahu kami di mana pun bahwa kami memiliki database yang persisten. Jika instance gagal, hal utama adalah menyimpan disk. Di sini kami juga memiliki seluruh platform di Kubernetes, dan komponen dengan Postgres terpisah (walaupun suatu hari nanti akan ada di sana). Oleh karena itu, semuanya seperti ini: instance tersebut terjatuh, tetapi kami menyimpan PV-nya dan menghubungkannya ke instance (baru) lainnya, seolah-olah tidak terjadi apa-apa.
DS: Dari sudut pandang saya, kami membuat pod di Kubernetes. K8s - elastis: simpul dipesan sesuai kebutuhan. Tugasnya hanyalah membuat sebuah pod dan mengatakan bahwa ia memerlukan sumber daya sebanyak X, lalu K8 akan menyelesaikannya sendiri. Namun dukungan penyimpanan di Kubernetes masih tidak stabil: Di (rilis ini dirilis недели lalu) fitur ini hanya menjadi beta.
Enam bulan hingga satu tahun akan berlalu - ini akan menjadi lebih atau kurang stabil, atau setidaknya akan dinyatakan seperti itu. Maka kemungkinan mengambil snapshot dan mengubah ukuran menyelesaikan masalah Anda sepenuhnya. Karena Anda punya basis. Ya, ini mungkin tidak terlalu cepat, tetapi kecepatannya bergantung pada apa yang ada “di balik terpal”, karena beberapa implementasi dapat menyalin dan menyalin-saat-menulis pada tingkat subsistem disk.
NS: Semua mesin (Amazon, Google...) juga perlu mulai mendukung versi ini - ini juga memerlukan waktu.
DS: Kami belum menggunakannya. Kami menggunakan milik kami.
Pengembangan lokal untuk Kubernetes
NS: Pernahkah Anda menemukan keinginan seperti itu ketika Anda perlu menginstal semua pod pada satu mesin dan melakukan tes kecil. Untuk mendapatkan bukti konsep dengan cepat, lihat apakah aplikasi berjalan di Kubernetes, tanpa mendedikasikan banyak mesin untuk aplikasi tersebut. Ada Minikube, kan?
DS: Menurut saya kasus ini - yang diterapkan pada satu node - secara eksklusif tentang pembangunan lokal. Atau beberapa manifestasi dari pola seperti itu. Makan di sana , . Kami beralih menggunakan Kubernetes IN Docker. Sekarang kami mulai mengerjakannya untuk pengujian.
NS: Dulu saya berpikir ini adalah upaya untuk menggabungkan semua pod dalam satu image Docker. Namun ternyata ini adalah sesuatu yang sama sekali berbeda. Bagaimanapun, ada wadah terpisah, pod terpisah - hanya di Docker.
DS: Ya. Dan ada tiruan yang agak lucu dibuat, tapi artinya begini... Kami memiliki utilitas untuk penerapan - . Kami ingin menjadikannya mode bersyarat werf up: “Dapatkan saya Kubernetes lokal.” Dan kemudian jalankan kondisi di sana werf follow. Kemudian pengembang akan dapat mengedit IDE, dan proses akan diluncurkan di sistem yang melihat perubahan dan membangun kembali gambar, memindahkannya ke K8 lokal. Inilah cara kami mencoba memecahkan masalah pembangunan lokal.
Snapshot dan kloning database dalam realitas K8
NS: Jika kita kembali ke copy-on-write. Saya perhatikan bahwa awan juga memiliki potret. Mereka bekerja secara berbeda. Misalnya, di GCP: Anda memiliki instance multi-terabyte di wilayah pantai timur Amerika Serikat. Anda mengambil snapshot secara berkala. Anda mengambil salinan disk di pantai barat dari snapshot - dalam beberapa menit semuanya sudah siap, ini bekerja sangat cepat, hanya cache yang perlu diisi ke dalam memori. Tapi klon (snapshot) ini adalah untuk 'menyediakan' volume baru. Ini keren ketika Anda perlu membuat banyak instance.
Namun untuk pengujian, menurut saya snapshot, yang Anda bicarakan di Docker atau yang saya bicarakan di ZFS, btrfs, dan bahkan LVM... - snapshot tersebut memungkinkan Anda untuk tidak membuat data yang benar-benar baru di satu mesin. Di cloud, Anda masih akan membayarnya setiap saat dan menunggu bukan dalam hitungan detik, tetapi dalam hitungan menit (dan dalam kasus ini , mungkin jam tangan).
Sebaliknya, Anda bisa mendapatkan data ini dalam satu atau dua detik, menjalankan pengujian, dan membuangnya. Cuplikan ini memecahkan berbagai masalah. Dalam kasus pertama - untuk meningkatkan dan mendapatkan replika baru, dan yang kedua - untuk pengujian.
DS: Saya tidak setuju. Membuat kloning volume berfungsi dengan baik adalah tugas cloud. Saya belum melihat implementasinya, tapi saya tahu bagaimana kami melakukannya pada perangkat keras. Kami memiliki Ceph, ini memungkinkan volume fisik apa pun () mengatakan clone dan dapatkan volume kedua dengan karakteristik yang sama dalam waktu puluhan milidetik, 'ami, dll. Anda perlu memahami bahwa ada copy-on-write yang rumit di dalamnya. Mengapa cloud tidak melakukan hal yang sama? Saya yakin mereka mencoba melakukan ini dengan satu atau lain cara.
NS: Namun masih memerlukan waktu beberapa detik, puluhan detik untuk memunculkan sebuah instance, membawa Docker ke sana, dll.
DS: Mengapa perlu memunculkan seluruh instance? Kami memiliki sebuah instance dengan 32 core, 16... dan dapat ditampung di dalamnya - misalnya, empat. Saat kita memesan yang kelima, instance sudah dimunculkan, lalu akan dihapus.
NS: Iya menarik, Kubernetes ternyata lain ceritanya. Basis data kami tidak ada di K8, dan kami memiliki satu contoh. Namun mengkloning database multi-terabyte tidak lebih dari dua detik.
DS: Ini bagus. Namun poin awal saya adalah ini bukanlah solusi umum. Ya keren, tapi hanya cocok untuk Postgres dan hanya di satu node.
NS: Cocok tidak hanya untuk Postgres: rencana ini, seperti yang saya jelaskan, hanya akan berfungsi di dalamnya. Namun jika kita tidak peduli dengan rencana, dan kita hanya memerlukan semua data untuk pengujian fungsional, maka ini cocok untuk DBMS apa pun.
DS: Bertahun-tahun yang lalu kami melakukan hal serupa pada snapshot LVM. Ini klasik. Pendekatan ini digunakan dengan sangat aktif. Node stateful hanya menyusahkan. Karena Anda tidak boleh membuangnya, Anda harus selalu mengingatnya...
NS: Apakah Anda melihat kemungkinan adanya hibrida di sini? Katakanlah stateful adalah sejenis pod, yang berfungsi untuk beberapa orang (banyak penguji). Kami memiliki satu volume, tetapi berkat sistem file, klonnya bersifat lokal. Jika pod jatuh, tetapi disk tetap ada, pod akan naik, hitung informasi tentang semua klon, ambil semuanya lagi dan katakan: "Ini klon Anda yang berjalan di port ini, lanjutkan bekerja dengan mereka."
DS: Secara teknis ini berarti bahwa di dalam Kubernetes terdapat satu pod tempat kita menjalankan banyak Postgres.
NS: Ya. Dia punya batasan: katakanlah tidak lebih dari 10 orang yang bekerja dengannya pada waktu yang sama. Jika Anda membutuhkan 20, kami akan meluncurkan pod kedua. Kami akan mengkloningnya sepenuhnya, setelah menerima volume penuh kedua, itu akan memiliki 10 klon “tipis” yang sama. Tidakkah Anda melihat peluang ini?
DS: Kita perlu menambahkan masalah keamanan di sini. Jenis organisasi ini menyiratkan bahwa pod ini memiliki hak (kemampuan) yang tinggi, karena dapat melakukan operasi non-standar pada sistem file... Tapi saya ulangi: Saya yakin bahwa dalam jangka menengah mereka akan memperbaiki penyimpanan di Kubernetes, dan di awan mereka akan memperbaiki keseluruhan cerita dengan volume - semuanya akan "berfungsi". Akan ada pengubahan ukuran, kloning... Ada volume - kami berkata: "Buat yang baru berdasarkan itu," dan setelah satu setengah detik kami mendapatkan apa yang kami butuhkan.
NS: Saya tidak percaya pada satu setengah detik untuk banyak terabyte. Di Ceph Anda melakukannya sendiri, tetapi Anda berbicara tentang awan. Buka cloud, buat tiruan volume EBS multi-terabyte di EC2 dan lihat seperti apa kinerjanya. Ini tidak akan memakan waktu beberapa detik. Saya sangat tertarik kapan mereka akan mencapai level ini. Saya mengerti apa yang Anda katakan, tapi saya mohon berbeda.
DS: Oke, tapi saya bilang jangka menengah, bukan jangka pendek. Selama beberapa tahun.
Tentang operator PostgreSQL dari Zalando
Di tengah pertemuan ini, Alexei Klyukin, mantan developer dari Zalando, juga ikut bergabung dan berbicara tentang sejarah operator PostgreSQL:
Sangat menyenangkan bahwa topik ini disinggung secara umum: baik Postgres maupun Kubernetes. Saat kami mulai melakukannya di Zalando pada tahun 2017, itu adalah topik yang ingin dilakukan semua orang, namun tidak ada yang melakukannya. Semua orang sudah memiliki Kubernetes, tetapi ketika mereka bertanya apa yang harus dilakukan dengan database, orang pun menyukainya , yang memberitakan K8, mengatakan sesuatu seperti ini:
“Buka layanan terkelola dan gunakan, jangan jalankan database di Kubernetes. Jika tidak, K8 Anda akan memutuskan, misalnya, untuk melakukan peningkatan, mematikan semua node, dan data Anda akan terbang jauh, sangat jauh.”
Kami memutuskan untuk membuat operator yang, bertentangan dengan saran ini, akan meluncurkan database Postgres di Kubernetes. Dan kami punya alasan bagus - . Ini adalah failover otomatis untuk PostgreSQL, dilakukan dengan benar, mis. menggunakan etcd, consul atau ZooKeeper sebagai penyimpan informasi tentang cluster. Tempat penyimpanan yang akan memberikan setiap orang yang bertanya, misalnya, siapa pemimpin saat ini, informasi yang sama - terlepas dari kenyataan bahwa kami telah mendistribusikan semuanya - sehingga tidak ada otak yang terpecah. Ditambah lagi kami punya untuk dia.
Secara umum, kebutuhan perusahaan akan auto failover muncul setelah migrasi dari pusat data perangkat keras internal ke cloud. Cloud didasarkan pada solusi PaaS (Platform-as-a-Service) yang dipatenkan. Ini Open Source, tapi butuh banyak usaha untuk mengaktifkan dan menjalankannya. Dulunya disebut .
Awalnya, tidak ada Kubernetes. Lebih tepatnya, ketika solusi kami diterapkan, K8 sudah ada, tetapi sangat kasar sehingga tidak cocok untuk produksi. Menurut saya, itu tahun 2015 atau 2016. Pada tahun 2017, Kubernetes telah menjadi lebih atau kurang matang—ada kebutuhan untuk bermigrasi ke sana.
Dan kami sudah memiliki container Docker. Ada PaaS yang menggunakan Docker. Mengapa tidak mencoba K8? Mengapa tidak menulis operator Anda sendiri? Murat Kabilov, yang datang kepada kami dari Avito, memulai ini sebagai proyek atas inisiatifnya sendiri - “bermain” - dan proyek tersebut “lepas landas”.
Namun secara umum, saya ingin berbicara tentang AWS. Mengapa ada kode terkait AWS historis...
Saat Anda menjalankan sesuatu di Kubernetes, Anda perlu memahami bahwa K8 masih dalam proses. Ia terus berkembang, membaik dan bahkan rusak dari waktu ke waktu. Anda harus terus memperhatikan semua perubahan di Kubernetes, Anda harus siap menyelaminya jika terjadi sesuatu dan mempelajari cara kerjanya secara mendetail - mungkin lebih dari yang Anda inginkan. Hal ini, pada prinsipnya, berlaku untuk platform apa pun tempat Anda menjalankan database...
Jadi, ketika kami melakukan pernyataan tersebut, Postgres kami berjalan pada volume eksternal (dalam hal ini EBS, karena kami bekerja di AWS). Basis datanya bertambah, suatu saat perlu diubah ukurannya: misalnya ukuran awal EBS adalah 100 TB, basis datanya bertambah besar, sekarang kami ingin membuat EBS 200 TB. Bagaimana? Katakanlah Anda dapat melakukan dump/pemulihan pada instance baru, namun hal ini akan memakan waktu lama dan melibatkan waktu henti.
Oleh karena itu, saya menginginkan perubahan ukuran yang akan memperbesar partisi EBS dan kemudian memberitahu sistem file untuk menggunakan ruang baru. Dan kami melakukannya, tetapi pada saat itu Kubernetes tidak memiliki API apa pun untuk operasi pengubahan ukuran. Sejak kami bekerja di AWS, kami menulis kode untuk API-nya.
Tidak ada yang menghentikan Anda melakukan hal yang sama untuk platform lain. Tidak ada petunjuk dalam pernyataan bahwa ini hanya dapat dijalankan di AWS, dan tidak akan berfungsi pada yang lainnya. Secara umum, ini adalah proyek Open Source: jika ada yang ingin mempercepat munculnya penggunaan API baru, silakan. Makan , tarik permintaan - tim Zalando mencoba meresponsnya dengan cukup cepat dan mempromosikan operator. Sejauh yang saya tahu, proyek tersebut di Google Summer of Code dan beberapa inisiatif serupa lainnya. Zalando bekerja sangat aktif untuk itu.
Bonus PS!
Jika Anda tertarik dengan topik PostgreSQL dan Kubernetes, harap perhatikan juga bahwa Postgres Tuesday berikutnya diadakan minggu lalu, di mana saya berbicara dengan Nikolai Alexander Kukushkin dari Zalando. Video darinya tersedia .
PPS
Baca juga di blog kami:
- «»;
- «»;
- «»;
- «'.
Sumber: www.habr.com