Menjalankan MySQL Galera Cluster (baik versi Percona, MariaDB, atau Codership), sayangnya, tidak didukung (atau bagian dari) database yang didukung oleh Amazon RDS. Sebagian besar database yang didukung oleh RDS menggunakan replikasi asinkron, sedangkan Galera Cluster adalah solusi replikasi multi-master sinkron. Galera juga membutuhkan InnoDB sebagai mesin penyimpanannya agar berfungsi dengan baik, dan meskipun Anda dapat menggunakan mesin penyimpanan lain seperti MyISAM, Anda tidak disarankan untuk menggunakan mesin penyimpanan ini karena kurangnya penanganan transaksi.
Karena kurangnya dukungan secara native di RDS, blog ini akan fokus pada penawaran yang tersedia saat memilih dan menghosting klaster berbasis Galera Anda menggunakan lingkungan AWS.
Tentu saja ada banyak alasan mengapa Anda memilih atau tidak memilih platform cloud AWS, tetapi untuk topik khusus ini kita akan membahas keuntungan dan manfaat dari apa yang dapat Anda manfaatkan daripada mengapa Anda akan memilih Platform AWS.
Server Virtual (Instance Komputasi Elastis)
Seperti yang disebutkan sebelumnya, MySQL Galera bukan bagian dari RDS dan InnoDB adalah mesin penyimpanan transaksional yang membutuhkan sumber daya yang tepat untuk kebutuhan aplikasi Anda. Itu harus memiliki kapasitas untuk melayani permintaan lalu lintas permintaan klien Anda. Pada saat artikel ini dibuat, satu-satunya pilihan Anda untuk menjalankan Galera Cluster adalah dengan menggunakan EC2, penawaran cloud instans komputasi Amazon.
Karena Anda memiliki keuntungan menjalankan sistem Anda pada sejumlah node pada instans EC2, menjalankan Galera Cluster pada ayat EC2 di tempat tidak jauh berbeda. Anda dapat mengakses server dari jarak jauh melalui SSH, menginstal paket perangkat lunak yang Anda inginkan, dan memilih jenis build Galera Cluster yang ingin Anda gunakan.
Selain itu, dengan EC2, penawaran ini lebih elastis dan fleksibel, memungkinkan Anda untuk memberikan dan menawarkan penyiapan granular yang lebih sederhana. Anda dapat memanfaatkan layanan web untuk mengotomatisasi atau membangun sejumlah node jika Anda perlu meningkatkan skala lingkungan Anda, atau misalnya, mengotomatiskan pembangunan staging atau lingkungan pengembangan Anda. Ini juga memberi Anda keunggulan untuk dengan cepat membangun lingkungan yang Anda inginkan, memilih dan mengatur OS yang Anda inginkan, dan mengambil sumber daya komputasi yang tepat yang sesuai dengan kebutuhan Anda (seperti CPU, memori, dan penyimpanan disk.) EC2 menghilangkan waktu untuk menunggu perangkat keras , karena Anda dapat melakukannya dengan cepat. Anda juga dapat memanfaatkan alat AWS CLI mereka untuk mengotomatiskan penyiapan klaster Galera Anda.
Harga untuk Instans Amazon EC2
EC2 menawarkan sejumlah pilihan yang sangat fleksibel bagi konsumen yang ingin menghosting lingkungan Galera Cluster mereka di node komputasi AWS. AWS Tingkat Gratis mencakup 750 jam instans t2.micro Linux dan Windows, setiap bulan, selama satu tahun. Anda dapat tetap berada dalam Tingkat Gratis dengan hanya menggunakan instans EC2 Micro, tetapi ini mungkin bukan yang terbaik untuk penggunaan produksi.
Ada beberapa jenis instans EC2 yang dapat Anda terapkan saat menyediakan node Galera Anda. Idealnya, keluarga r4/r5/x1 ini (memori dioptimalkan) dan keluarga c4/c5 (mengoptimalkan komputasi) adalah pilihan yang ideal, dan harga ini berbeda tergantung pada seberapa besar kebutuhan sumber daya server Anda dan jenis OS.
Ini adalah jenis instans berbayar yang dapat Anda pilih...
Sesuai Permintaan
Bayar berdasarkan kapasitas komputasi (per-jam atau per-detik), bergantung pada jenis instans yang Anda jalankan. Misalnya, harga mungkin berbeda saat menyediakan instans Ubuntu vs instans RHEL selain dari jenis instans. Ini tidak memiliki komitmen jangka panjang atau pembayaran di muka yang diperlukan. Ini juga memiliki fleksibilitas untuk menambah atau mengurangi kapasitas komputasi Anda. Instans ini direkomendasikan untuk kebutuhan lingkungan yang fleksibel dan berbiaya rendah seperti aplikasi dengan beban kerja jangka pendek, runcing, atau tidak dapat diprediksi yang tidak dapat diganggu, atau aplikasi yang sedang dikembangkan atau diuji di Amazon EC2 untuk pertama kalinya. Lihat di sini untuk info lebih lanjut.
Host Khusus
Jika Anda mencari persyaratan kepatuhan dan peraturan seperti kebutuhan untuk memperoleh server khusus yang berjalan pada perangkat keras khusus untuk digunakan, jenis penawaran ini sesuai dengan kebutuhan Anda. Host Khusus dapat membantu Anda mengatasi persyaratan kepatuhan dan mengurangi biaya dengan mengizinkan Anda menggunakan lisensi perangkat lunak terikat server yang ada, termasuk Windows Server, SQL Server, SUSE Linux Enterprise Server, Red Hat Enterprise Linux, atau lisensi perangkat lunak lain yang terikat pada VM , soket, atau inti fisik, tunduk pada persyaratan lisensi Anda. Itu dapat dibeli Sesuai Permintaan (setiap jam) atau sebagai Reservasi hingga 70% dari harga Sesuai Permintaan. Lihat di sini untuk info lebih lanjut.
Instance Spot
Instans ini memungkinkan Anda untuk meminta kapasitas komputasi Amazon EC2 cadangan hingga 90% dari harga Sesuai Permintaan. Ini direkomendasikan untuk aplikasi yang memiliki waktu mulai dan akhir yang fleksibel, aplikasi yang hanya layak dengan harga komputasi yang sangat rendah, atau pengguna dengan kebutuhan komputasi yang mendesak untuk kapasitas tambahan dalam jumlah besar. Lihat di sini untuk info lebih lanjut.
Instans yang Dicadangkan
Jenis penawaran pembayaran ini memberi Anda pilihan untuk mendapatkan diskon hingga 75% dan, tergantung pada contoh mana yang ingin Anda pesan, Anda dapat memperoleh reservasi kapasitas yang memberi Anda keyakinan tambahan pada kemampuan Anda untuk meluncurkan instans saat Anda membutuhkannya. Ini direkomendasikan jika aplikasi Anda memiliki penggunaan yang stabil atau dapat diprediksi, aplikasi yang mungkin memerlukan kapasitas yang dicadangkan, atau pelanggan yang dapat berkomitmen untuk menggunakan EC2 selama jangka waktu 1 atau 3 tahun untuk mengurangi total biaya komputasi mereka. Lihat di sini untuk info lebih lanjut.
Catatan Harga
Satu hal terakhir dengan EC2, mereka juga menawarkan tagihan per detik yang juga mengambil biaya menit dan detik yang tidak terpakai dalam satu jam dari tagihan. Ini menguntungkan jika Anda melakukan scaling-out untuk waktu yang minimal, hanya untuk menangani permintaan lalu lintas dari node Galera atau jika Anda ingin mencoba dan menguji pada node tertentu hanya untuk penggunaan waktu yang terbatas.
Enkripsi Basis Data di AWS
Jika Anda khawatir tentang kerahasiaan data Anda, atau mematuhi undang-undang yang diperlukan untuk kepatuhan dan peraturan keamanan Anda, AWS menawarkan enkripsi data-at-rest. Jika Anda menggunakan MariaDB Cluster versi 10.2+, mereka memiliki dukungan plugin bawaan untuk berinteraksi dengan API Layanan Manajemen Kunci (KMS) Amazon Web Services (AWS). Hal ini memungkinkan Anda memanfaatkan layanan manajemen kunci AWS-KMS untuk memfasilitasi pemisahan tanggung jawab dan pencatatan jarak jauh &audit permintaan akses kunci. Daripada menyimpan kunci enkripsi dalam file lokal, plugin ini menyimpan kunci master di AWS KMS.
Saat pertama kali memulai MariaDB, plugin AWS KMS akan terhubung ke AWS Key Management Service dan memintanya untuk membuat kunci baru. MariaDB akan menyimpan kunci itu di disk dalam bentuk terenkripsi. Kunci yang disimpan di disk tidak dapat digunakan untuk mendekripsi data; alih-alih, pada setiap startup, MariaDB terhubung ke AWS KMS dan meminta layanan mendekripsi kunci yang disimpan secara lokal. Kunci yang didekripsi disimpan dalam memori selama proses server MariaDB berjalan, dan kunci yang didekripsi dalam memori tersebut digunakan untuk mengenkripsi data lokal.
Atau, saat menerapkan instans EC2, Anda dapat mengenkripsi volume penyimpanan data dengan EBS (Elastic Block Storage) atau mengenkripsi instans itu sendiri. Enkripsi untuk volume tipe EBS semuanya didukung, meskipun mungkin berdampak tetapi latensinya sangat minim atau bahkan tidak terlihat oleh pengguna akhir. Untuk enkripsi tipe instans EC2, sebagian besar instans besar didukung. Jadi, jika Anda menggunakan node komputasi atau memori yang dioptimalkan, Anda dapat memanfaatkan enkripsinya.
Berikut adalah daftar jenis instans yang didukung...
- Tujuan umum:A1, M3, M4, M5, M5a, M5ad, M5d, T2, T3, dan T3a
- Komputasi dioptimalkan:C3, C4, C5, C5d, dan C5n
- Memori dioptimalkan:cr1.8xlarge, R3, R4, R5, R5a, R5ad, R5d, u-6tb1.metal, u-9tb1.metal, u-12tb1.metal, X1, X1e, dan z1d
- Penyimpanan yang dioptimalkan:D2, h1.2xlarge, h1.4xlarge, I2, dan I3
- Komputasi yang dipercepat:F1, G2, G3, P2, dan P3
Anda dapat mengatur akun AWS Anda untuk selalu mengaktifkan enkripsi setelah penerapan instans tipe EC2 Anda. Ini berarti bahwa AWS akan mengenkripsi volume EBS baru saat peluncuran dan mengenkripsi salinan baru dari snapshot yang tidak terenkripsi.
Penerapan Multi-AZ/Multi-Wilayah/Multi-Cloud
Sayangnya, pada saat tulisan ini dibuat, tidak ada dukungan langsung seperti itu di AWS Console (atau AWS API mereka) yang mendukung penerapan Multi-AZ/-Region/-Cloud untuk kluster node Galera.
Ketersediaan, Skalabilitas, dan Redundansi Tinggi
Untuk mencapai penerapan multi-AZ, sebaiknya Anda menyediakan node galera di zona ketersediaan yang berbeda. Ini mencegah cluster dari turun atau kerusakan cluster karena kurangnya kuorum.
Anda juga dapat menyiapkan AWS Auto Scaling dan membuat grup penskalaan otomatis untuk memantau dan melakukan pemeriksaan status sehingga cluster Anda akan selalu memiliki redundansi, skalabel, dan ketersediaan tinggi. Penskalaan Otomatis akan menyelesaikan masalah Anda jika node Anda turun karena alasan yang tidak diketahui.
Untuk penerapan multi-wilayah atau multi-cloud, Galera memiliki parameternya sendiri yang disebut gmcast.segment yang dapat Anda atur saat server mulai. Parameter ini dirancang untuk mengoptimalkan komunikasi antara node Galera dan meminimalkan jumlah lalu lintas yang dikirim antara segmen jaringan termasuk relaying writeset dan pemilihan donor IST dan SST.
Jenis penyiapan ini memungkinkan Anda menerapkan beberapa node di berbagai wilayah untuk Cluster Galera Anda. Selain itu, Anda juga dapat menerapkan node Galera Anda di vendor yang berbeda, misalnya, jika dihosting di Google Cloud dan Anda ingin redundansi di Microsoft Azure.
Saya akan merekomendasikan Anda untuk memeriksa blog kami Beberapa Pengaturan Pusat Data Menggunakan Galera Cluster untuk MySQL atau MariaDB dan Zero Downtime Network Migration Dengan MySQL Galera Cluster Menggunakan Relay Node untuk mengumpulkan informasi lebih lanjut tentang cara menerapkan jenis ini penerapan.
Kinerja Basis Data di AWS
Tergantung pada permintaan aplikasi Anda, jika memori kueri Anda menggunakan instans memori yang dioptimalkan adalah pilihan ideal Anda. Jika aplikasi Anda memiliki transaksi lebih tinggi yang memerlukan kinerja tinggi untuk server web atau pemrosesan batch, pilih instans komputasi yang dioptimalkan. Jika Anda ingin mempelajari lebih lanjut tentang mengoptimalkan Galera Cluster Anda, Anda dapat melihat blog ini Cara Meningkatkan Kinerja Galera Cluster untuk MySQL atau MariaDB.
Cadangan Basis Data di AWS
Membuat cadangan bisa jadi sulit karena tidak ada dukungan langsung dalam AWS yang khusus untuk teknologi MySQL Galera. Namun, AWS memberi Anda solusi bencana dan pemulihan menggunakan EBS Snapshots. Anda dapat mengambil snapshot volume EBS yang dilampirkan ke instans Anda, lalu mengambil cadangan menurut jadwal menggunakan CloudWatch atau dengan menggunakan Amazon Data Lifecycle Manager (Amazon DLM) untuk mengotomatiskan snapshot.
Perhatikan bahwa snapshot yang diambil adalah cadangan tambahan, yang berarti bahwa hanya blok di perangkat yang telah diubah setelah snapshot terbaru Anda yang disimpan. Anda dapat menyimpan snapshot ini ke AWS S3 untuk menghemat biaya penyimpanan. Atau, Anda dapat menggunakan alat eksternal seperti Percona Xtrabackup, dan Mydumper (untuk pencadangan logis) dan menyimpannya ke AWS EFS -> AWS S3 -> AWS Glacier.
Anda juga dapat mengatur Manajemen Siklus Hidup di AWS jika Anda memerlukan data cadangan untuk disimpan dengan cara yang lebih hemat biaya. Jika Anda memiliki file besar dan akan menggunakan AWS EFS, Anda dapat memanfaatkan solusi AWS Backup mereka karena ini juga merupakan solusi sederhana namun hemat biaya.
Di sisi lain, Anda juga dapat menggunakan layanan eksternal (juga seperti ClusterControl) yang memberi Anda solusi pemantauan dan pencadangan. Lihat ini jika Anda ingin tahu lebih banyak.
Pemantauan Basis Data di AWS
AWS menawarkan health check dan beberapa status check untuk memberikan visibilitas ke node Galera Anda. Ini dilakukan melalui CloudWatch dan CloudTrail.
CloudTrail memungkinkan Anda mengaktifkan dan memeriksa log dan melakukan audit berdasarkan tindakan dan pelacakan yang telah dilakukan.
CloudWatch memungkinkan Anda mengumpulkan dan melacak metrik, mengumpulkan dan memantau file log, serta menyetel alarm khusus. Anda dapat mengaturnya sesuai dengan kebutuhan khusus Anda dan mendapatkan visibilitas seluruh sistem ke dalam pemanfaatan sumber daya, kinerja aplikasi, dan kesehatan operasional. CloudWatch hadir dengan tingkat gratis selama Anda masih berada dalam batasnya (Lihat tangkapan layar di bawah.)
CloudWatch juga hadir dengan harga tergantung pada volume metrik yang didistribusikan. Checkout harga saat ini dengan memeriksa di sini.
Perhatikan:ada kerugian menggunakan CloudWatch. Itu tidak dirancang untuk memenuhi kesehatan database, terutama untuk memantau node cluster MySQL Galera. Atau, Anda dapat menggunakan alat eksternal yang menawarkan grafik atau bagan resolusi tinggi yang berguna dalam pelaporan dan lebih mudah dianalisis saat mendiagnosis node yang bermasalah.
Untuk ini, Anda dapat menggunakan PMM oleh Percona, DataDog, Idera, VividCortex, atau ClusterControl kami sendiri (karena pemantauan GRATIS dengan Komunitas ClusterControl.) Saya sarankan Anda menggunakan alat pemantauan yang sesuai dengan kebutuhan Anda kebutuhan berdasarkan kebutuhan aplikasi individu Anda. Sangat penting bahwa alat pemantau Anda dapat memberi tahu Anda secara agresif atau memberi Anda integrasi untuk sistem pesan instan seperti Slack, PagerDuty, atau bahkan mengirimi Anda SMS saat meningkatkan status kesehatan yang parah.
Keamanan Basis Data di AWS
Mengamankan instans EC2 Anda adalah salah satu bagian terpenting dalam menerapkan database Anda ke cloud publik. Anda dapat menyiapkan subnet pribadi dan menyiapkan grup keamanan yang diperlukan yang hanya disukai untuk mengizinkan port atau IP sumber bergantung pada penyiapan Anda. Anda dapat mengatur node database Anda dengan akses non-remote dan hanya mengatur host melompat atau Gateway Internet, jika node memerlukan akses internet untuk mengakses atau memperbarui paket perangkat lunak. Anda dapat membaca blog kami sebelumnya Menyebarkan Replikasi MySQL Multicloud Aman di AWS dan GCP dengan VPN tentang cara kami menyiapkannya.
Selain itu, Anda dapat mengamankan data dalam perjalanan dengan menggunakan koneksi TLS/SSL atau mengenkripsi data Anda saat tidak digunakan. Jika Anda menggunakan ClusterControl, menerapkan data aman dalam perjalanan itu sederhana dan mudah. Anda dapat melihat blog kami Manajemen Kunci SSL dan Enkripsi Data MySQL dalam Transit jika Anda ingin mencobanya. Untuk data at-rest, penyimpanan data Anda melalui S3 dapat dienkripsi menggunakan AWS Server-Side Encryption atau menggunakan AWS-KMS yang telah saya bahas sebelumnya. Lihat blog eksternal ini tentang cara menyiapkan dan memanfaatkan Cluster MariaDB menggunakan AWS-KMS sehingga Anda dapat menyimpan data Anda dengan aman saat tidak digunakan.
Pemecahan Masalah Klaster Galera di AWS
AWS CloudWatch dapat membantu terutama saat menyelidiki dan memeriksa metrik sistem. Anda dapat memeriksa jaringan, CPU, memori, disk, dan instance-nya atau menghitung penggunaan dan keseimbangan. Namun, ini mungkin tidak memenuhi persyaratan Anda saat menggali kasus tertentu.
CloudTrail dapat melakukan jejak tindakan yang solid yang telah diatur berdasarkan akun AWS spesifik Anda. Ini akan membantu Anda menentukan apakah kejadian tersebut tidak berasal dari MySQL Galera, tetapi mungkin ada beberapa bug atau masalah dalam lingkungan AWS (seperti Hyper-V mengalami masalah dalam mesin host tempat instans Anda, sebagai tamu, sedang dihosting.)
Jika Anda menggunakan ClusterControl, masuk ke Log -> System Logs, Anda akan dapat menelusuri log kesalahan yang diambil dari node MySQL Galera itu sendiri. Selain itu, ClusterControl menyediakan pemantauan waktu nyata yang akan memperkuat alarm dan sistem notifikasi Anda jika terjadi keadaan darurat atau jika node MySQL Galera Anda rusak.
Kesimpulan
AWS tidak memiliki dukungan murni untuk penyiapan Cluster Galera MySQL, tidak seperti AWS RDS yang memiliki kompatibilitas MySQL. Karena itu, sebagian besar rekomendasi atau opini menjalankan Galera Cluster untuk penggunaan produksi dalam lingkungan AWS didasarkan pada lingkungan yang berpengalaman dan teruji dengan baik yang telah berjalan untuk waktu yang sangat lama.
Cluster MariaDB hadir dengan produktivitas yang luar biasa, karena mereka terus-menerus memberikan dukungan ringkas untuk solusi tumpukan teknologi AWS. Dalam rilis versi MariaDB 10.5 yang akan datang, mereka akan menawarkan dukungan untuk S3 Storage Engine, yang mungkin pantas untuk ditunggu.
Alat eksternal dapat membantu Anda mengelola dan mengontrol MySQL Galera Cluster yang berjalan di AWS Cloud, jadi tidak masalah jika Anda memiliki beberapa dilema dan FUD tentang mengapa Anda harus menjalankan atau beralih ke AWS Cloud Platform.
AWS mungkin bukan solusi satu ukuran untuk semua dalam beberapa kasus, tetapi AWS menyediakan beragam solusi yang dapat Anda sesuaikan dan sesuaikan dengan kebutuhan Anda.
Di bagian selanjutnya dari blog kita, kita akan melihat platform cloud publik lainnya, khususnya Google Cloud dan melihat bagaimana kita dapat memanfaatkannya jika kita memilih untuk menjalankan Galera Cluster kita ke platform mereka.
