Entah bagaimana, mengikut sejarah, industri IT dibahagikan kepada dua kem bersyarat atas sebarang sebab: mereka yang "untuk" dan mereka yang "menentang". Selain itu, subjek pertikaian boleh menjadi sewenang-wenangnya. OS mana yang lebih baik: Win atau Linux? Pada telefon pintar Android atau iOS? Sekiranya anda menyimpan segala-galanya di awan atau meletakkannya pada storan RAID yang sejuk dan meletakkan skru dalam peti besi? Adakah orang PHP mempunyai hak untuk dipanggil pengaturcara? Pertikaian ini, kadangkala, bersifat eklusif dan tidak mempunyai asas selain kepentingan sukan.
Kebetulan dengan kemunculan kontena dan semua masakan kegemaran ini dengan docker dan k8 bersyarat, perdebatan "untuk" dan "menentang" penggunaan keupayaan baharu dalam pelbagai bidang bahagian belakang bermula. (Mari kita membuat tempahan terlebih dahulu bahawa walaupun Kubernetes paling kerap akan ditunjukkan sebagai orkestra dalam perbincangan ini, pilihan alat khusus ini tidak penting. Sebaliknya, anda boleh menggantikan mana-mana alat lain yang kelihatan paling mudah dan biasa kepada anda .)
Dan, nampaknya, ini akan menjadi pertikaian mudah antara dua belah syiling yang sama. Tidak masuk akal dan tanpa belas kasihan seperti konfrontasi abadi antara Win vs Linux, di mana orang yang mencukupi wujud di suatu tempat di tengah-tengah. Tetapi dalam kes kontena, tidak semuanya begitu mudah. Biasanya dalam pertikaian sedemikian tidak ada sebelah kanan, tetapi dalam kes bekas "menggunakan" atau "tidak menggunakan" untuk menyimpan pangkalan data, semuanya menjadi terbalik. Kerana dalam erti kata tertentu, kedua-dua penyokong dan penentang pendekatan ini adalah betul.
Bahagian yang terang
Hujah The Light Side boleh diterangkan secara ringkas dalam satu frasa: "Hello, 2k19 berada di luar tingkap!" Kedengarannya seperti populisme, sudah tentu, tetapi jika anda menyelidiki situasi secara terperinci, ia mempunyai kelebihannya. Mari kita selesaikan mereka sekarang.
Katakan anda mempunyai projek web yang besar. Ia mungkin pada mulanya dibina berdasarkan pendekatan perkhidmatan mikro, atau pada satu ketika ia datang kepadanya melalui laluan evolusi - ini tidak begitu penting, sebenarnya. Anda menyerakkan projek kami ke dalam perkhidmatan mikro yang berasingan, menyediakan orkestrasi, pengimbangan beban dan penskalaan. Dan kini, dengan hati nurani yang bersih, anda menghirup mojito dalam buaian semasa kesan habra dan bukannya menaikkan pelayan yang jatuh. Tetapi dalam semua tindakan anda mesti konsisten. Selalunya, hanya aplikasi itu sendiriβkodnyaβdibekalkan. Apa lagi yang kita ada selain kod?
Betul, data. Inti bagi mana-mana projek ialah datanya: ini boleh sama ada DBMS biasa - MySQL, Postgre, MongoDB, atau storan yang digunakan untuk carian (ElasticSearch), storan nilai kunci untuk caching - contohnya, redis, dll. Pada masa ini kami tidak kita akan bercakap tentang pilihan pelaksanaan bahagian belakang yang bengkok apabila pangkalan data ranap disebabkan oleh pertanyaan bertulis yang kurang baik, dan sebaliknya kita akan bercakap tentang memastikan toleransi kesalahan pangkalan data ini di bawah beban klien. Lagipun, apabila kami menyimpan aplikasi kami dan membenarkannya berskala bebas untuk memproses sebarang bilangan permintaan masuk, ini secara semula jadi meningkatkan beban pada pangkalan data.
Malah, saluran untuk mengakses pangkalan data dan pelayan di mana ia berjalan menjadi mata jarum di bahagian belakang bekas kami yang cantik. Pada masa yang sama, motif utama virtualisasi kontena ialah mobiliti dan fleksibiliti struktur, yang membolehkan kami mengatur pengagihan beban puncak merentas keseluruhan infrastruktur yang tersedia untuk kami secekap mungkin. Maksudnya, jika kami tidak mengisi kontena dan melancarkan semua elemen sistem sedia ada di seluruh kluster, kami membuat kesilapan yang sangat serius.
Adalah lebih logik untuk mengelompokkan bukan sahaja aplikasi itu sendiri, tetapi juga perkhidmatan yang bertanggungjawab untuk menyimpan data. Dengan mengelompokkan dan menggunakan pelayan web yang berfungsi secara bebas dan mengagihkan beban sesama mereka dalam k8, kami sudah menyelesaikan masalah penyegerakan data - ulasan yang sama pada siaran, jika kami mengambil beberapa media atau platform blog sebagai contoh. Walau apa pun, kami mempunyai perwakilan intra-kluster, malah maya, bagi pangkalan data sebagai ExternalService. Persoalannya ialah pangkalan data itu sendiri belum berkelompok - pelayan web yang digunakan dalam kiub mengambil maklumat tentang perubahan daripada pangkalan data pertempuran statik kami, yang berputar secara berasingan.
Adakah anda merasakan tangkapan? Kami menggunakan k8s atau Swarm untuk mengagihkan beban dan mengelakkan ranap pelayan web utama, tetapi kami tidak melakukan ini untuk pangkalan data. Tetapi jika pangkalan data ranap, maka keseluruhan infrastruktur berkelompok kami tidak masuk akal - apa gunanya halaman web kosong yang mengembalikan ralat akses pangkalan data?
Itulah sebabnya perlu untuk mengelompokkan bukan sahaja pelayan web, seperti yang biasa dilakukan, tetapi juga infrastruktur pangkalan data. Hanya dengan cara ini kita boleh memastikan struktur yang berfungsi sepenuhnya dalam satu pasukan, tetapi pada masa yang sama bebas antara satu sama lain. Lebih-lebih lagi, walaupun separuh daripada bahagian belakang kami "runtuh" ββdi bawah beban, selebihnya akan bertahan, dan sistem penyegerakan pangkalan data antara satu sama lain dalam kelompok dan keupayaan untuk menskala dan menggunakan kluster baharu tanpa henti akan membantu mencapai kapasiti yang diperlukan dengan cepat - sekiranya terdapat rak di pusat data.
Di samping itu, model pangkalan data yang diedarkan dalam kelompok membolehkan anda membawa pangkalan data ini ke tempat yang diperlukan; Jika kita bercakap tentang perkhidmatan global, maka agak tidak logik untuk memutarkan kluster web di suatu tempat di kawasan San Francisco dan pada masa yang sama menghantar paket apabila mengakses pangkalan data di rantau Moscow dan belakang.
Selain itu, kontena pangkalan data membolehkan anda membina semua elemen sistem pada tahap abstraksi yang sama. Yang, seterusnya, memungkinkan untuk menguruskan sistem ini secara langsung daripada kod, oleh pembangun, tanpa penglibatan aktif pentadbir. Pembangun berpendapat bahawa DBMS yang berasingan diperlukan untuk subprojek baharu - mudah! menulis fail yaml, memuat naiknya ke kluster dan anda sudah selesai.
Dan sudah tentu, operasi dalaman sangat dipermudahkan. Beritahu saya, berapa kali anda menutup mata apabila ahli pasukan baharu meletakkan tangannya ke dalam pangkalan data pertempuran untuk bekerja? Yang, sebenarnya, satu-satunya yang anda miliki dan sedang berputar sekarang? Sudah tentu, kita semua adalah orang dewasa di sini, dan di suatu tempat kita mempunyai sandaran baru, dan lebih jauh lagi - di belakang rak dengan timun nenek dan ski lama - sandaran lain, mungkin juga dalam simpanan sejuk, kerana pejabat anda sudah terbakar sekali. Tetapi semua yang sama, setiap pengenalan ahli pasukan baharu dengan akses kepada infrastruktur pertempuran dan, sudah tentu, kepada pangkalan data pertempuran adalah baldi validol untuk semua orang di sekeliling. Nah, siapa yang mengenalinya, seorang pemula, mungkin dia bersilang tangan? Ia menakutkan, anda akan bersetuju.
Pengkontenaan dan, sebenarnya, topologi fizikal yang diedarkan bagi pangkalan data projek anda membantu mengelakkan detik pengesahan sedemikian. Tidak mempercayai pemula? OKEY! Mari beri dia klusternya sendiri untuk bekerja dan putuskan sambungan pangkalan data daripada kluster lain - penyegerakan hanya dengan tolakan manual dan putaran segerak dua kekunci (satu untuk ketua pasukan, satu lagi untuk pentadbir). Dan semua orang gembira.
Dan kini tiba masanya untuk berubah menjadi penentang pengelompokan pangkalan data.
Sisi gelap
Berhujah mengapa ia tidak berbaloi untuk menyimpan pangkalan data dan terus menjalankannya pada satu pelayan pusat, kami tidak akan tunduk kepada retorik ortodoks dan kenyataan seperti "datuk menjalankan pangkalan data pada perkakasan, dan begitu juga kami!" Sebaliknya, mari kita cuba membuat situasi di mana kontena sebenarnya akan membayar dividen yang ketara.
Setuju, projek yang benar-benar memerlukan tapak dalam bekas boleh dikira dengan jari oleh bukan operator mesin pengilangan terbaik. Untuk sebahagian besar, walaupun penggunaan k8s atau Docker Swarm itu sendiri adalah berlebihan - selalunya alat ini digunakan kerana gembar-gembur umum teknologi dan sikap "yang maha kuasa" dalam diri jantina untuk mendorong segala-galanya ke dalam awan dan bekas. Nah, kerana sekarang ia bergaya dan semua orang melakukannya.
Dalam sekurang-kurangnya separuh daripada kes, menggunakan Kubernetis atau hanya Docker pada projek adalah berlebihan. Isunya ialah tidak semua pasukan atau syarikat penyumberan luar yang diupah untuk mengekalkan infrastruktur pelanggan menyedari perkara ini. Lebih teruk apabila kontena dikenakan, kerana ia memerlukan sejumlah syiling kepada pelanggan.
Secara umum, terdapat pendapat bahawa mafia docker/cube secara bodohnya menghancurkan pelanggan yang menyumber luar isu infrastruktur ini. Lagipun, untuk bekerja dengan kluster, kami memerlukan jurutera yang mampu melakukan ini dan secara amnya memahami seni bina penyelesaian yang dilaksanakan. Kami pernah menerangkan kes kami dengan penerbitan Republik - di sana kami melatih pasukan pelanggan untuk bekerja dalam realiti Kubernetis, dan semua orang berpuas hati. Dan ia adalah baik. Selalunya, "pelaksana" k8s mengambil tebusan infrastruktur pelanggan - kerana kini hanya mereka yang memahami cara semuanya berfungsi di sana; tiada pakar di pihak pelanggan.
Sekarang bayangkan bahawa dengan cara ini kami menyumber luar bukan sahaja bahagian pelayan web, tetapi juga penyelenggaraan pangkalan data. Kami mengatakan bahawa BD adalah jantung, dan kehilangan jantung adalah maut bagi mana-mana organisma hidup. Pendek kata, prospek bukanlah yang terbaik. Jadi, bukannya gembar-gembur Kubernetis, banyak projek sepatutnya tidak mengganggu tarif biasa untuk AWS, yang akan menyelesaikan semua masalah dengan beban di tapak/projek mereka. Tetapi AWS tidak lagi bergaya, dan menunjuk-nunjuk lebih bernilai daripada wang - malangnya, dalam persekitaran IT juga.
OKEY. Mungkin projek itu benar-benar memerlukan pengelompokan, tetapi jika semuanya jelas dengan aplikasi tanpa negara, maka bagaimanakah kita boleh mengatur sambungan rangkaian yang baik untuk pangkalan data berkelompok?
Jika kita bercakap tentang penyelesaian kejuruteraan yang lancar, iaitu peralihan kepada k8s, maka sakit kepala utama kami ialah replikasi data dalam pangkalan data berkelompok. Sesetengah DBMS pada mulanya agak setia kepada pengedaran data antara kejadian individu mereka. Ramai lagi yang tidak begitu mengalu-alukan. Dan selalunya hujah utama dalam memilih DBMS untuk projek kami bukanlah keupayaan untuk meniru dengan kos sumber dan kejuruteraan yang minimum. Terutama jika projek itu pada mulanya tidak dirancang sebagai perkhidmatan mikro, tetapi hanya berkembang ke arah ini.
Kami fikir tidak perlu bercakap tentang kelajuan pemacu rangkaian - ia perlahan. Itu. Kami masih tidak mempunyai peluang sebenar, jika sesuatu berlaku, untuk memulakan semula contoh DBMS di tempat yang terdapat lebih banyak, contohnya, kuasa pemproses atau RAM percuma. Kami akan dengan cepat melihat prestasi subsistem cakera maya. Sehubungan itu, DBMS mesti dipaku pada set mesin peribadinya sendiri yang terletak berdekatan. Atau adalah perlu untuk menyejukkan secara berasingan penyegerakan data yang cukup pantas untuk rizab yang sepatutnya.
Meneruskan topik sistem fail maya: Docker Volumes, malangnya, tidak bebas masalah. Secara umum, dalam perkara seperti penyimpanan data jangka panjang yang boleh dipercayai, saya ingin membuat kaitan dengan skim yang paling mudah dari segi teknikal. Dan menambahkan lapisan abstraksi baharu daripada FS bekas kepada FS hos induk adalah risiko itu sendiri. Tetapi apabila pengendalian sistem sokongan kontena juga menghadapi kesukaran dengan menghantar data antara lapisan ini, maka ia benar-benar bencana. Pada masa ini, kebanyakan masalah yang diketahui oleh manusia progresif nampaknya telah dihapuskan. Tetapi anda faham, lebih kompleks mekanisme, lebih mudah ia pecah.
Memandangkan semua "pengembaraan" ini, adalah lebih menguntungkan dan lebih mudah untuk menyimpan pangkalan data di satu tempat, dan walaupun anda perlu menyimpan aplikasi, biarkan ia berjalan sendiri dan melalui gerbang pengedaran menerima komunikasi serentak dengan pangkalan data, yang akan dibaca dan ditulis sekali sahaja dan Di satu tempat. Pendekatan ini mengurangkan kemungkinan ralat dan penyahsegerakan kepada minimum.
Apa yang kita bawa? Selain itu, kontena pangkalan data adalah sesuai di mana terdapat keperluan sebenar untuknya. Anda tidak boleh mengisi pangkalan data aplikasi penuh dan memutarkannya seolah-olah anda mempunyai dua dozen perkhidmatan mikro - ia tidak berfungsi seperti itu. Dan ini mesti difahami dengan jelas.
Daripada output
Jika anda sedang menunggu kesimpulan yang jelas "untuk memayakan pangkalan data atau tidak," maka kami akan mengecewakan anda: ia tidak akan berada di sini. Kerana apabila mencipta sebarang penyelesaian infrastruktur, seseorang mesti dipandu bukan oleh fesyen dan kemajuan, tetapi, pertama sekali, oleh akal sehat.
Terdapat projek yang prinsip dan alatan yang disertakan dengan Kubernetis sesuai dengan sempurna, dan dalam projek sedemikian terdapat keamanan sekurang-kurangnya di kawasan bahagian belakang. Dan terdapat projek yang tidak memerlukan kontena, tetapi infrastruktur pelayan biasa, kerana mereka pada asasnya tidak boleh menskala semula kepada model kluster perkhidmatan mikro, kerana ia akan jatuh.
Sumber: www.habr.com