No Comments

Adakah berbaloi mengatur kedudukan Pangkalan Data atau Storan Data pada Container?

Ajit Gadge | Konsultan Kanan Pangkalan Data, Ashnik
Singapura, 22 Oct 2019
Ajit-FImg

by , , No Comments

22-Oct-2019

Saya telah berbincang soalan cepumas ini dengan begitu ramai DBA, DevOps, pasukan Solusi Arkitek sejak beberapa bulan – apakah manfaat sebenar menjalankan pangkalan data/storan data dalam container?

Saya ingin berkongsi dengan anda mengenai apa yang saya pelajari dari perbincangan ini:

Berskala

Penskalaan Pangkalan Data/Storan Data adalah salah satu cabaran yang dihadapi apabila muatan kerja adalah dinamik. Anda mungkin tahu bahawa penskalaan secara horizontal adalah cara terbaik untuk melakukannya. Namun, kita harus teliti jika sekiranya storan data/pangkalan data itu sendiri berupaya untuk penskalaan secara horizontal.

Kebanyakan storan data mempunyai Keupayaan Penskalaan Membaca, tetapi bagaimana dengan Keupayaan Penskalaan Menulis? Pada hari ini, kebanyakan RDBMS masih belum mempunyai pilihan Keupayaan Penskalaan Menulis. Terdapat beberapa pangkalan data/storan data dengan ciri Sharding bersama dengan peranan menyelaras/load balancer pada pangkalan data, di mana Keupayaan Penskalaan Menulis boleh dilakukan. Oleh itu, dalam kes ini, apabila dijalankan container itu sendiri mempunyai persekitaran yang berasingan sepenuhnya, kita perlu menyemak jika keupayaan penskalaan pada pangkalan data (Layer 7) akan dapat dicapai dengan menjalankan pangkalan data/storan data dalam bentuk container? Walaupun sekiranya kita mempunyai konsep Sharding dalam pangkalan data, data perlulah gigih dan perlu berinteraksi dengan master node atau cluster node yang lain. Container yang sedang menjalankan pangkalan data perlu secara berterusan berinteraksi dengan node yang lain juga. K8 boleh membantu di sini, tetapi ia menjadikan persekitaran tersebut lebih rumit sementara ini dengan mudah boleh dicapai oleh alatan pangkalan data tanpa container.

Mudah dalam Pemasangan dan konfigurasi

“Berapa kerapkah anda benar-benar perlu memasang pangkalan data/storan data pada tetapan pengeluaran dalam satu bulan?” Saya telah berulang kali bertanya soalan ini kepada pasukan DBA dan DevOps dan jawapan yang sering saya dapat adalah sifar atau maksima hanya satu digit sahaja. Setiap persekitaran pengeluaran adalah berlainan kerana muatan kerjanya adalah berlainan, akhirnya anda membina imej baru atau docker menjalankan fail setiap masa walaupun ketika imej asasnya adalah sama. Oleh itu, adakah Container benar-benar berguna dalam kes ini? Jika sekiranya anda benar-benar mempunyai pangkalan data/storan data yang mudah untuk dipasang dan dikonfirgurasikan, bolehkah kita menggunakan skrip automasi seperti Ansible untuk aktiviti yang sama?

Peningkatan susulan dan patching

“Berapa kerapkah anda perlu melakukan patching atau peningkatan pangkalan data anda sejak satu tahun lepas?” Sekali lagi, jawapan yang saya terima ialah samada sifar atau sekali sahaja. Jadi, pangkalan data/storan data bukanlah satu objek dalam tetapan anda yang perlu anda tingkatkan atau patch setiap kali, walaupun anda mendapat ciri-ciri dan manfaat baru untuk aplikasi anda – dan itu bergantung kepada pangkalan data sepenuhnya. Container kebanyakannya digunakan untuk aktiviti-aktiviti di mana anda meningkatkan microservice anda secara harian/mingguan tanpa masa henti. Saya dapati bahawa organisasi mempunyai perancangan semasa mengatur kedudukan tetapi malangnya mereka tidak mempertimbangkan pangkalan data sebagai sebahagian daripada rancangan mereka.

Prestasi

Ianya menjadi perdebatan. Terdapat teori bahawa menjalankan pangkalan data/storan data dalam Container meningkatkan prestasi. Prestasi pangkalan data kebanyakannya datang dari I/O dan Memori. Jika anda memberikan ruang luaran kepada Container untuk storan data, anda mengharapkan kepada kegigihan API storan seperti ceph atau portworkx. Banyak pembekal Pangkalan Data menyarankan SSD setempat untuk prestasi yang lebih baik dan di dalam persekitaran Container, anda akhirnya menggunakan ruang luaran. Jadi, anda mesti menyemak bagaimana prestasi container di dalam pangkalan data pada muatan kerja pengeluaran.

Kos

Saya masih ingat perbincangan serius saya dengan seorang bekas teman sekerja. Kami berdebat jika Container boleh menjimatkan wang. Dia menyebut bahawa ianya boleh menjimatkan, berkaitan lesen pangkalan data dan kos VM apabila anda menggunakan Container dalam pangkalan data.

Sekarang, ayuh lihat jika ianya benar-benar menjimatkan kos –

Banyak pembekal RDBMS/storan data masih tidak mempunyai polisi yang jelas mengenai lesen penggunaan pangkalan data dalam Container. Mereka akhirnya masih mengira berasaskan teras. Justeru itu, saya tidak pasti bagaimana kita mendapat rumusan kukuh bahawa ianya menjimatkan kos.

Anda mungkin menjimatkan kos jika sekiranya anda menggunakan versi berlesen VMware untuk mengatur kedudukan pangkalan data tanpa Container. Tetapi saya dapati ramai pembekal masih menyarankan penggunaan WM dengan Container (open shift, VRealize). Juga, aturan kedudukan pangkalan data gred pengeluaran seringkali lebih menyukai untuk menggunakan kaedah “bare metal” berbanding VW. DBA masih lebih menyukai kaedah ini.

Lesen sumber terbuka juga sama dan tidak akan berubah untuk Container serta penggunaan VM/bare metal.

Sekali lagi, jika anda menggunakan Container pada tahap pengeluaran atau perniagaan, adalah dinasihatkan untuk menggunakan versi Enterprise Docker berbanding komuniti bersama dengan sokongan K8, yang mana sebenarnya akan meningkatkan kos.

Mudah Alih

Satu daripada penggunaan utama Container ialah ciri mudah alihnya. Anda boleh memindahkan Container anda (pada asas imejnya) dengan persekitaran lengkap kepada persekitaran yang lain dengan mudahnya. Sebagai contoh, berpindah ke cloud awam dari bare metal yang dihoskan adalah mudah jika microservice anda dijalankan dalam Container. Tetapi persoalannya masih lagi, berapa kerapkah anda benar-benar mahu memindahkan pangkalan data pengeluaran anda? Malah, jika sekiranya anda menjalankan pangkalan data dalam Container, ianya dipetakan ke ruang luaran. Jadi, selepas memindahkan Container anda, anda perlu memetakan semula (kadang-kadang bina dan peta semula) ruang luaran tersebut di dalam persekitaran baru anda. Adakah anda bersedia untuk mengambil risiko ini dengan data pengeluaran anda?

Cabaran

Terdapat beberapa cabaran utama ketika menjalankan pangkalan data dalam Container seperti storan yang gigih, penyelenggaraan persekitaran DevOps anda bersama dengan penyelenggaraan pangkalan data anda, keselamatan container, kemahiran (anda memerlukan jurutera DevOps serta DBA atau DBA tersebut perlu diberi kemahiran semula) dan banyak lagi. Dengan kata lain, terdapat banyak lagi cabaran-cabaran lain yang perlu diambil kira, tetapi saya akan menulis mengenainya di dalam blog saya yang seterusnya

Walaubagaimanapun, saya boleh melihat terdapat beberapa penggunaan di mana anda boleh menggunakan pangkalan data/storan data dalam Container.

1: Persekitaran Ujian/Dev atau UAT: Syarikat-syarikat dengan persekitaran pembangunan yang besar di mana perlu mengatur kedudukan pangkalan data setiap hari atau setiap minggu dan meringankan tugasan ini daripada DBA atau DevOps adalah penting, justeru menggunakan Container dengan imej asas pangkalan data untuk UAT/Dev adalah masuk akal. Persekitaran ini secara tipikalnya bukanlah dalam bentuk HA dan data tidak memerlukan kegigihan.

2: Pembekal Public Cloud/Aplikasi ISV berasaskan SAS: Jika sekiranya anda mempunyai pelanggan yang mahu menawarkan perkhidmatan cloud kepada umum atau pelanggan mereka atau mungkin mereka mempunyai aplikasi yang mana lebih cenderung untuk menawarkan model berasaskan SAS dengan aturan kedudukan yang tinggi atau dinamik, jadi menjalankan satu pangkalan data dalam Container bersama dengan aplikasi fail Docker-run adalah masuk akal.

0
0

  • Ajit mempunyai lebih 16 tahun pengalaman dalam implimentasi dan perlaksanaan solusi. Beliau telah berjaya menghasilkan solusi pelbagai teknologi pangkalan data termasuklah PostgreSQL, MySQL, SQLServer. Beliau mempunyai kelebihan kerana minatnya yang mendalam pada teknologi pangkalan data dan menyukai penglibatan jualan bersama pelanggan. Ajit telah berjaya melibatkan diri dengan pelanggan dari pelbagai negara di dunia termasuk Asia Tenggara, Amerika Syarikat dan India. Komitmen dan keupayaannya untuk mencari solusi telah menjadikannya seorang yang dihormati oleh pelanggan-pelanggan. Sebelum berkhidmat dengan Ashnik, beliau pernah bekerja dengan EnterpriseDB selama 7 tahun dan membantu perkembangannya di Asia Tenggara dan India.

More From Ajit Gadge | Konsultan Kanan Pangkalan Data, Ashnik :
22-Oct-2019