Menerapkan Replikasi MySQL Multicloud Aman di AWS dan GCP dengan VPN

Mengapa Memilih Replikasi MySQL?

Beberapa dasar pertama tentang teknologi replikasi. Replikasi MySQL tidak rumit! Sangat mudah untuk diterapkan, dipantau, dan disetel karena ada berbagai sumber daya yang dapat Anda manfaatkan - google menjadi salah satunya. Replikasi MySQL tidak mengandung banyak variabel konfigurasi untuk disetel. Kesalahan logis SQL_THREAD dan IO_THREAD tidak terlalu sulit untuk dipahami dan diperbaiki. Replikasi MySQL sangat populer saat ini dan menawarkan cara sederhana untuk mengimplementasikan database High Availability. Fitur canggih seperti GTID (Global Transaction Identifier) ​​alih-alih posisi log biner kuno, atau Replikasi Semi-Sinkron tanpa kehilangan membuatnya lebih kuat.

Seperti yang kita lihat di posting sebelumnya, latensi jaringan merupakan tantangan besar saat memilih solusi ketersediaan tinggi. Menggunakan Replikasi MySQL menawarkan keuntungan karena tidak terlalu sensitif terhadap latensi. Itu tidak menerapkan replikasi berbasis sertifikasi apa pun, tidak seperti Galera Cluster yang menggunakan komunikasi grup dan teknik pemesanan transaksi untuk mencapai replikasi sinkron. Dengan demikian, tidak ada persyaratan bahwa semua node harus mensertifikasi sebuah writeset, dan tidak perlu menunggu sebelum melakukan commit pada slave atau replika lainnya.

Memilih Replikasi MySQL tradisional dengan pendekatan Primer-Sekunder asinkron memberi Anda kecepatan dalam menangani transaksi dari dalam master Anda; tidak perlu menunggu budak untuk menyinkronkan atau melakukan transaksi. Setup biasanya memiliki primer (master) dan satu atau lebih sekunder (slave). Oleh karena itu, ini adalah sistem shared-nothing, di mana semua server memiliki salinan lengkap data secara default. Tentu saja ada kekurangannya. Integritas data dapat menjadi masalah jika slave Anda gagal mereplikasi karena kesalahan utas SQL dan I/O, atau macet. Atau, untuk mengatasi masalah integritas data, Anda dapat memilih untuk mengimplementasikan Replikasi MySQL menjadi semi-sinkron (atau disebut replikasi semi-sinkronisasi lossless di MySQL 5.7). Cara kerjanya adalah, master harus menunggu hingga replika mengakui semua peristiwa transaksi. Ini berarti bahwa ia harus menyelesaikan penulisannya ke log relai dan menyiram ke disk sebelum mengirim kembali ke master dengan respons ACK. Dengan replikasi semi-sinkron diaktifkan, utas atau sesi di master harus menunggu pengakuan dari replika. Setelah mendapat respons ACK dari replika, ia kemudian dapat melakukan transaksi. Ilustrasi di bawah ini menunjukkan bagaimana MySQL menangani replikasi semi-sinkron.

Dengan implementasi ini, semua transaksi yang dilakukan sudah direplikasi ke setidaknya satu slave jika terjadi master crash. Meskipun semi-sinkron tidak mewakili dengan sendirinya solusi ketersediaan tinggi, tetapi ini adalah komponen untuk solusi Anda. Sebaiknya Anda mengetahui kebutuhan Anda dan menyesuaikan penerapan semi-sinkronisasi Anda. Oleh karena itu, jika beberapa kehilangan data dapat diterima, Anda dapat menggunakan replikasi asinkron tradisional.

Replikasi berbasis GTID sangat membantu DBA karena menyederhanakan tugas untuk melakukan failover, terutama ketika seorang budak diarahkan ke master lain atau master baru. Ini berarti bahwa dengan MASTER_AUTO_POSITION=1 sederhana setelah menyetel host yang benar dan kredensial replikasi, ia akan mulai mereplikasi dari master tanpa perlu menemukan dan menentukan posisi x &y log biner yang benar. Menambahkan dukungan replikasi paralel juga meningkatkan utas replikasi karena menambah kecepatan untuk memproses peristiwa dari log relai.

Dengan demikian, Replikasi MySQL adalah komponen pilihan yang bagus dibandingkan solusi HA lainnya jika sesuai dengan kebutuhan Anda.

Topologi untuk Replikasi MySQL

Menerapkan Replikasi MySQL di lingkungan multicloud dengan GCP (Google Cloud Platform) dan AWS masih merupakan pendekatan yang sama jika Anda harus mereplikasi secara lokal.

Ada berbagai topologi yang dapat Anda siapkan dan terapkan.

Master dengan Replikasi Budak (Replikasi Tunggal)

Ini adalah topologi replikasi MySQL yang paling mudah. Satu master menerima penulisan, satu atau lebih slave mereplikasi dari master yang sama melalui replikasi asinkron atau semisinkron. Jika master yang ditunjuk turun, budak yang paling mutakhir harus dipromosikan sebagai master baru. Budak yang tersisa melanjutkan replikasi dari master baru.

Master dengan Relay Slave (Replikasi Rantai)

Pengaturan ini menggunakan master perantara untuk bertindak sebagai relai ke budak lain dalam rantai replikasi. Ketika ada banyak budak yang terhubung ke master, antarmuka jaringan master bisa kelebihan beban. Topologi ini memungkinkan replika baca untuk menarik aliran replikasi dari server relai untuk membongkar server master. Pada server slave relay, logging biner dan log_slave_updates harus diaktifkan, di mana update yang diterima oleh server slave dari server master dicatat ke log biner milik slave.

Menggunakan relai budak memiliki masalah:

• log_slave_updates memiliki beberapa penalti kinerja.
• Keterlambatan replikasi pada server relai budak akan menghasilkan penundaan pada semua budaknya.
• Transaksi jahat di server relai budak akan menginfeksi semua budaknya.
• Jika server relai budak gagal dan Anda tidak menggunakan GTID, semua budaknya berhenti mereplikasi dan mereka perlu diinisialisasi ulang.

Master dengan Master Aktif (Replikasi Melingkar)

Juga dikenal sebagai topologi ring, pengaturan ini membutuhkan dua atau lebih server MySQL yang bertindak sebagai master. Semua master menerima penulisan dan menghasilkan binlog dengan beberapa peringatan:

• Anda perlu menyetel offset kenaikan otomatis di setiap server untuk menghindari tabrakan kunci utama.
• Tidak ada resolusi konflik.
• Replikasi MySQL saat ini tidak mendukung protokol penguncian apa pun antara master dan slave untuk menjamin atomisitas pembaruan terdistribusi di dua server berbeda.
• Praktik umum adalah hanya menulis ke satu master dan master lainnya bertindak sebagai node siaga-panas. Namun, jika Anda memiliki budak di bawah tingkat itu, Anda harus beralih ke master baru secara manual jika master yang ditunjuk gagal.
• ClusterControl mendukung topologi ini (kami tidak menyarankan banyak penulis dalam pengaturan replikasi). Lihat blog sebelumnya tentang cara menerapkan dengan ClusterControl.

Master dengan Master Cadangan (Beberapa Replikasi)

Master mendorong perubahan ke master cadangan dan ke satu atau lebih budak. Replikasi semi-sinkron digunakan antara master dan master cadangan. Master mengirimkan pembaruan ke master cadangan dan menunggu dengan komit transaksi. Master cadangan mendapat pembaruan, menulis ke log relai, dan mem-flush ke disk. Master cadangan kemudian mengakui penerimaan transaksi ke master, dan melanjutkan dengan komitmen transaksi. Replikasi semisinkron memiliki dampak kinerja, tetapi risiko kehilangan data diminimalkan.

Topologi ini bekerja dengan baik saat melakukan master failover jika master down. Master cadangan bertindak sebagai server siaga hangat karena memiliki kemungkinan tertinggi untuk memiliki data terbaru jika dibandingkan dengan slave lainnya.

Beberapa Master ke Single Slave (Replikasi Multi-Sumber)

Replikasi Multi-Sumber memungkinkan slave replikasi untuk menerima transaksi dari berbagai sumber secara bersamaan. Replikasi multi-sumber dapat digunakan untuk mencadangkan beberapa server ke satu server, untuk menggabungkan pecahan tabel, dan mengkonsolidasikan data dari beberapa server ke satu server.

MySQL dan MariaDB memiliki implementasi replikasi multi-sumber yang berbeda, di mana MariaDB harus memiliki GTID dengan gtid-domain-id yang dikonfigurasi untuk membedakan transaksi asal, sedangkan MySQL menggunakan saluran replikasi terpisah untuk setiap master dari mana slave mereplikasi. Di MySQL, master dalam topologi replikasi multi-sumber dapat dikonfigurasi untuk menggunakan replikasi berbasis pengidentifikasi transaksi global (GTID), atau replikasi berbasis posisi log biner.

Lebih lanjut tentang replikasi multi sumber MariaDB dapat ditemukan di posting blog ini. Untuk MySQL, silakan merujuk ke dokumentasi MySQL.

Galera dengan Replication Slave (Hybrid Replication)

Replikasi hibrida adalah kombinasi dari replikasi asinkron MySQL dan replikasi hampir sinkron yang disediakan oleh Galera. Penerapan sekarang disederhanakan dengan penerapan GTID dalam replikasi MySQL, di mana pengaturan dan pelaksanaan master failover telah menjadi proses yang mudah di sisi slave.

Kinerja cluster Galera secepat node paling lambat. Memiliki slave replikasi asinkron dapat meminimalkan dampak pada cluster jika Anda mengirim kueri jenis pelaporan/OLAP yang berjalan lama ke slave, atau jika Anda melakukan pekerjaan berat yang memerlukan kunci seperti mysqldump. Slave juga dapat berfungsi sebagai cadangan langsung untuk pemulihan bencana di lokasi dan di luar lokasi.

Replikasi hibrid didukung oleh ClusterControl dan Anda dapat menerapkannya langsung dari UI ClusterControl. Untuk informasi lebih lanjut tentang cara melakukannya, silakan baca posting blog - Replikasi hybrid dengan MySQL 5.6 dan Replikasi hybrid dengan MariaDB 10.x.

Menyiapkan GCP dan Platform AWS

Masalah "dunia nyata"

Di blog ini, kami akan mendemonstrasikan dan menggunakan topologi "Multiple Replication" di mana instance pada dua platform cloud publik yang berbeda akan berkomunikasi menggunakan Replikasi MySQL di wilayah yang berbeda dan pada zona ketersediaan yang berbeda. Skenario ini didasarkan pada masalah dunia nyata di mana sebuah organisasi ingin merancang infrastruktur mereka di berbagai platform cloud untuk skalabilitas, redundansi, ketahanan/toleransi kesalahan. Konsep serupa akan berlaku untuk MongoDB atau PostgreSQL.

Mari kita pertimbangkan sebuah organisasi AS, dengan cabang luar negeri di Asia Tenggara. Lalu lintas kami tinggi di kawasan yang berbasis di Asia. Latensi harus rendah saat melayani penulisan dan pembacaan, tetapi pada saat yang sama wilayah yang berbasis di AS juga dapat menarik catatan yang berasal dari lalu lintas berbasis Asia.

Alur Arsitektur Cloud

Pada bagian ini, saya akan membahas desain arsitektur. Pertama, kami ingin menawarkan lapisan yang sangat aman di mana node Google Compute dan AWS EC2 kami dapat berkomunikasi, memperbarui, atau menginstal paket dari internet, aman, sangat tersedia jika AZ (Availability Zone) turun, dapat mereplikasi dan berkomunikasi ke platform cloud lain melalui lapisan aman. Lihat gambar di bawah untuk ilustrasi:

Berdasarkan ilustrasi di atas, di bawah platform AWS, semua node berjalan di zona ketersediaan yang berbeda. Ini memiliki subnet pribadi dan publik di mana semua node komputasi berada di subnet pribadi. Oleh karena itu, ia dapat keluar dari internet untuk menarik dan memperbarui paket sistemnya bila diperlukan. Ini memiliki gateway VPN yang harus berinteraksi dengan GCP di saluran itu, melewati Internet tetapi melalui saluran yang aman dan pribadi. Sama seperti GCP, semua node komputasi berada di zona ketersediaan yang berbeda, gunakan NAT Gateway untuk memperbarui paket sistem bila diperlukan dan gunakan koneksi VPN untuk berinteraksi dengan node AWS yang dihosting di wilayah berbeda, yaitu Asia Pasifik (Singapura). Di sisi lain, wilayah yang berbasis di AS dihosting di bawah us-east1. Untuk mengakses node, satu node dalam arsitektur berfungsi sebagai bastion-node yang akan kita gunakan sebagai host lompat dan menginstal ClusterControl. Ini akan dibahas nanti di blog ini.

Menyiapkan Lingkungan GCP dan AWS

Saat mendaftarkan akun GCP pertama Anda, Google menyediakan akun VPC (Virtual Private Cloud) default. Oleh karena itu, sebaiknya buat VPC terpisah dari default dan sesuaikan sesuai kebutuhan Anda.

Tujuan kami di sini adalah untuk menempatkan node komputasi di subnet pribadi atau node tidak akan diatur dengan IPv4 publik. Oleh karena itu, kedua cloud publik harus dapat berbicara satu sama lain. Node komputasi AWS dan GCP beroperasi dengan CIDR yang berbeda seperti yang disebutkan sebelumnya. Berikut adalah CIDR berikut:

AWS Compute Nodes: 172.21.0.0/16
Node Komputasi GCP: 10.142.0.0/20

Dalam pengaturan AWS ini, kami mengalokasikan tiga subnet yang tidak memiliki Gateway Internet tetapi Gateway NAT; dan satu subnet yang memiliki Internet Gateway. Masing-masing subnet ini dihosting satu per satu di Availability Zone (AZ) yang berbeda.

ap-southeast-1a =172.21.1.0/24
ap-southeast-1b =172.21.8.0/24
ap-southeast-1c =172.21.24.0/24

Sementara di GCP, digunakan subnet default yang dibuat di VPC di bawah us-east1 yaitu 10.142.0.0/20 CIDR. Oleh karena itu, berikut adalah langkah-langkah yang dapat Anda ikuti untuk menyiapkan platform cloud multi-publik Anda.

• Untuk latihan ini, saya membuat VPC di region us-east1 dengan subnet 10.142.0.0/20 berikut. Lihat di bawah:

  

• Cadangan IP Statis. Ini adalah IP yang akan kami siapkan sebagai Gateway Pelanggan di AWS

  

• Karena kami memiliki subnet (disediakan sebagai subnet-us-east1 ), buka GCP -> Jaringan VPC -> Jaringan VPC dan pilih VPC yang Anda buat dan buka Aturan Firewall . Di bagian ini, tambahkan aturan dengan menentukan masuk dan keluar Anda. Pada dasarnya, ini adalah aturan masuk/keluar di AWS atau firewall Anda untuk koneksi masuk dan keluar. Dalam penyiapan ini, saya membuka semua protokol TCP dari rentang CIDR yang ditetapkan di AWS dan GCP VPC saya untuk mempermudah tujuan blog ini. Oleh karena itu, ini bukan cara yang optimal untuk keamanan. Lihat gambar di bawah ini:

  

  Firewall-ssh di sini akan digunakan untuk mengizinkan koneksi masuk ssh, HTTP, dan HTTPS.

• Sekarang beralih ke AWS dan buat VPC. Untuk blog ini, saya menggunakan CIDR (Classless Inter-Domain Routing) 172.21.0.0/16

• Buat subnet yang harus Anda tetapkan di setiap AZ (Availability Zone); dan setidaknya memesan satu subnet untuk subnet publik yang akan menangani Gateway NAT, dan sisanya untuk node EC2.

  

• Selanjutnya, buat Tabel Rute Anda dan pastikan "Tujuan" dan "Target" diatur dengan benar. Untuk blog ini, saya membuat 2 tabel rute. Salah satu yang akan menangani 3 AZ yang node komputasi saya akan ditugaskan secara individual dan akan ditetapkan tanpa Gateway Internet karena tidak akan memiliki IP publik. Kemudian yang lain akan menangani NAT Gateway dan akan memiliki Internet Gateway yang akan berada di subnet publik. Lihat gambar di bawah ini:

  

  dan seperti yang disebutkan, contoh tujuan saya untuk rute pribadi yang menangani 3 subnet menunjukkan memiliki target Gateway NAT ditambah target Gateway Virtual yang akan saya sebutkan nanti di langkah selanjutnya.

  

• Selanjutnya, buat "Gateway Internet" dan tetapkan ke VPC yang sebelumnya dibuat di bagian AWS VPC. Gateway Internet ini hanya akan ditetapkan sebagai tujuan ke subnet publik karena akan menjadi layanan yang harus terhubung ke internet. Jelas, namanya adalah singkatan dari layanan gateway internet.

• Selanjutnya, buat "Gateway NAT". Saat membuat "Gateway NAT", pastikan Anda telah menetapkan NAT Anda ke subnet yang menghadap publik. Gateway NAT adalah saluran Anda untuk mengakses internet dari subnet pribadi atau node EC2 Anda yang tidak memiliki IPv4 publik yang ditetapkan. Kemudian buat atau tetapkan EIP (Elastic IP) karena, di AWS, hanya node komputasi yang memiliki IPv4 publik yang dapat terhubung ke internet secara langsung.

• Sekarang, di bawah VPC -> Keamanan -> Grup Keamanan (SG) , VPC yang Anda buat akan memiliki SG default. Untuk penyiapan ini, saya membuat "Aturan Masuk" dengan sumber yang ditetapkan untuk setiap CIDR yaitu 10.142.0.0/20 di GCP dan 172.21.0.0/16 di AWS. Lihat di bawah:

  

  Untuk "Aturan Keluar", Anda dapat membiarkannya apa adanya karena menetapkan aturan ke "Aturan Masuk" bersifat bilateral, yang berarti akan terbuka juga untuk "Aturan Keluar". Perhatikan bahwa ini bukan cara optimal untuk mengatur Grup Keamanan Anda; tetapi untuk mempermudah pengaturan ini, saya telah membuat cakupan port dan sumber yang lebih luas juga. Juga bahwa protokol tersebut khusus untuk koneksi TCP saja karena kita tidak akan berurusan dengan UDP untuk blog ini.
  Selain itu, Anda dapat meninggalkan VPC -> Keamanan -> ACL Jaringan tidak tersentuh selama tidak MENYANGKAL koneksi tcp apa pun dari CIDR yang disebutkan dalam sumber Anda.

• Selanjutnya, kita akan mengatur konfigurasi VPN yang akan di-host di bawah platform AWS. Di bawah VPC -> Gateway Pelanggan , buat gateway menggunakan alamat IP statis yang dibuat sebelumnya di langkah sebelumnya. Perhatikan gambar di bawah ini:

  

• Selanjutnya, buat Virtual Private Gateway dan lampirkan ini ke VPC saat ini yang kita buat sebelumnya di langkah sebelumnya. Lihat gambar di bawah ini:

  

• Sekarang, buat koneksi VPN yang akan digunakan untuk koneksi situs-ke-situs antara AWS dan GCP. Saat membuat koneksi VPN, pastikan Anda telah memilih Virtual Private Gateway dan Customer Gateway yang kita buat di langkah sebelumnya. Lihat gambar di bawah ini:

  

  Ini mungkin memakan waktu beberapa saat saat AWS membuat koneksi VPN Anda. Ketika koneksi VPN Anda kemudian disediakan, Anda mungkin bertanya-tanya mengapa di bawah tab Tunnel (setelah Anda memilih koneksi VPN Anda), itu akan menunjukkan bahwa Alamat IP Luar sedang turun. Ini normal karena belum ada koneksi yang dibuat dari klien. Perhatikan contoh gambar di bawah ini:

  

  Setelah koneksi VPN siap, pilih koneksi VPN yang Anda buat dan unduh konfigurasinya. Ini berisi kredensial Anda yang diperlukan untuk langkah-langkah berikut untuk membuat koneksi VPN situs-ke-situs dengan klien.

  Catatan: Jika Anda telah mengatur VPN Anda di mana IPSEC UP tapi Status sedang BAWAH seperti gambar di bawah

  

  ini kemungkinan karena nilai yang salah disetel ke parameter tertentu saat menyiapkan sesi BGP atau router cloud Anda. Lihat di sini untuk memecahkan masalah VPN Anda.

• Karena kita memiliki koneksi VPN yang siap dihosting di AWS, mari buat koneksi VPN di GCP. Sekarang, mari kembali ke GCP dan siapkan koneksi klien di sana. Di GCP, buka GCP -> Konektivitas Hibrida -> VPN . Pastikan Anda memilih wilayah yang benar, yang ada di blog ini, kami menggunakan us-east1 . Kemudian pilih alamat IP statis yang dibuat pada langkah sebelumnya. Lihat gambar di bawah ini:

  

  Kemudian di Terowongan Di bagian ini, Anda harus menyiapkan berdasarkan kredensial yang diunduh dari koneksi AWS VPN yang Anda buat sebelumnya. Saya sarankan untuk melihat panduan bermanfaat ini dari Google. Misalnya, salah satu terowongan yang sedang disiapkan ditunjukkan pada gambar di bawah ini:

  

  Pada dasarnya, hal terpenting di sini adalah sebagai berikut:

  • Remote Peer Gateway:Alamat IP - Ini adalah IP server VPN yang dinyatakan di bawah Detail Tunnel -> Alamat IP Luar . Ini berbeda dengan IP statis yang kami buat di bawah GCP. Itu adalah Gerbang VPN Cloud -> alamat IP sekalipun.
  • Router cloud ASN - Secara default, AWS menggunakan 65000. Namun kemungkinan besar, Anda akan mendapatkan informasi ini dari file konfigurasi yang diunduh.
  • Router rekan ASN - Ini adalah Gerbang Pribadi Virtual ASN yang ditemukan di file konfigurasi yang diunduh.
  • Alamat IP BGP Cloud Router - Ini adalah Gerbang Pelanggan ditemukan di file konfigurasi yang diunduh.
  • Alamat IP peer BGP - Ini adalah Gerbang Pribadi Virtual ditemukan di file konfigurasi yang diunduh.

• Lihatlah contoh file konfigurasi yang saya miliki di bawah ini:

  

  untuk itu Anda harus mencocokkan ini selama menambahkan Tunnel Anda di bawah GCP -> Konektivitas Hibrida -> VPN pengaturan konektivitas. Lihat gambar di bawah tempat saya membuat router cloud dan sesi BGP selama membuat terowongan sampel:

  

  Kemudian sesi BGP sebagai,

  

  Catatan: File konfigurasi yang diunduh berisi terowongan konfigurasi IPSec di mana AWS juga berisi dua (2) server VPN yang siap untuk koneksi Anda. Anda harus mengatur keduanya sehingga Anda akan memiliki pengaturan yang tersedia tinggi. Setelah disiapkan untuk kedua tunnel dengan benar, koneksi AWS VPN di bawah tab Tunnels akan menunjukkan bahwa keduanya Alamat IP Luar sudah bangun. Lihat gambar di bawah ini:

  

• Terakhir, karena kita telah membuat Gateway Internet dan Gateway NAT, isi subnet publik dan pribadi dengan benar dengan Tujuan yang benar dan Target seperti yang terlihat pada tangkapan layar dari langkah sebelumnya. Ini dapat disiapkan dengan membuka Layanan -> Jaringan &Pengiriman Konten -> VPC -> Tabel Rute dan pilih tabel rute yang dibuat yang disebutkan dari langkah sebelumnya. Lihat gambar di bawah ini:

  

  Seperti yang Anda perhatikan, igw-01faa6d83da5df964 adalah Gateway Internet yang kami buat dan digunakan oleh rute publik. Sementara, tabel rute pribadi memiliki tujuan dan target yang disetel ke nat-07eb7a54e90dab61f dan keduanya memiliki Tujuan set ke 0.0.0.0/0 karena akan memungkinkan dari koneksi IPv4 yang berbeda. Juga jangan lupa untuk mengatur Rute Propagation benar untuk Virtual Gateway seperti yang terlihat pada screenshot yang memiliki target vgw-0238040a5fd061515 . Cukup klik Route Propagation dan atur ke Yes seperti pada screenshot di bawah ini:

  

  Ini sangat penting agar koneksi dari koneksi GCP eksternal akan dirutekan ke tabel rute di AWS dan tidak diperlukan pekerjaan manual lebih lanjut. Jika tidak, GCP Anda tidak dapat membuat koneksi ke AWS.

Sekarang setelah VPN kami aktif, kami akan melanjutkan penyiapan node pribadi kami termasuk bastion host.

Menyiapkan Node Compute Engine

Menyiapkan node Compute Engine/EC2 akan cepat dan mudah karena semua penyiapan sudah disiapkan. Saya tidak akan membahas detailnya, tetapi lihat tangkapan layar di bawah ini untuk menjelaskan penyiapannya.

Node AWS EC2 :

Node Komputasi GCP :

Pada dasarnya, pada pengaturan ini. Tuan rumah clustercontrol akan menjadi bastion atau jump host dan untuk itu ClusterControl akan diinstal. Jelas, semua node di sini tidak dapat diakses internet. Mereka tidak memiliki IPv4 Eksternal yang ditetapkan dan node berkomunikasi melalui saluran yang sangat aman menggunakan VPN.

Terakhir, semua node dari AWS hingga GCP ini disiapkan dengan satu pengguna sistem yang seragam dengan akses sudo, yang diperlukan di bagian berikutnya. Lihat bagaimana ClusterControl dapat membuat hidup Anda lebih mudah saat berada di multicloud dan multi-region.

Kontrol Cluster Untuk Menyelamatkan!!!

Menangani banyak node dan pada platform cloud publik yang berbeda, ditambah pada "Wilayah" yang berbeda dapat menjadi tugas yang "benar-benar menyakitkan dan menakutkan". Bagaimana Anda memantau itu secara efektif? ClusterControl tidak hanya bertindak sebagai pisau swiss Anda, tetapi juga sebagai DBA Virtual Anda. Sekarang, mari kita lihat bagaimana ClusterControl dapat membuat hidup Anda lebih mudah.

Membuat Cluster Multi-Replikasi menggunakan ClusterControl

Sekarang mari kita coba membuat cluster replikasi master-slave MariaDB dengan mengikuti topologi "Multiple Replication".

Menekan Terapkan tombol akan menginstal paket dan mengatur node yang sesuai. Oleh karena itu, pandangan logis tentang bagaimana topologi akan terlihat seperti:

Node 172.21.0.0/16 IP rentang mereplikasi dari masternya yang berjalan di GCP.

Sekarang, bagaimana kalau kita mencoba memuat beberapa tulisan di master? Masalah apa pun dengan konektivitas atau latensi mungkin menghasilkan lag budak, Anda akan dapat menemukannya dengan ClusterControl. Lihat tangkapan layar di bawah ini:

dan seperti yang Anda lihat di sudut kanan atas tangkapan layar, itu berubah menjadi merah karena menunjukkan masalah terdeteksi. Oleh karena itu, alarm dikirim saat masalah ini terdeteksi. Lihat di bawah:

Kita perlu menggali ini. Untuk pemantauan mendetail, kami telah mengaktifkan agen pada instans database. Mari kita lihat Dasbor.

Ini menawarkan pengalaman super mulus dalam hal memantau node Anda.

Ini memberitahu kita bahwa utilisasi tinggi atau host tidak merespons. Meskipun ini hanya ping kegagalan respons, Anda dapat mengabaikan peringatan untuk menghentikan Anda membombardirnya. Oleh karena itu, Anda dapat 'un-ignore' jika diperlukan dengan masuk ke Cluster -> Alarms di Clustercontrol. Lihat di bawah:

Mengelola Kegagalan dan Melakukan Failover

Katakanlah master node us-east1 gagal, atau memerlukan perbaikan besar-besaran karena peningkatan sistem atau perangkat keras. Katakanlah ini adalah topologi sekarang (lihat gambar di bawah):

Mari kita coba shutdown host 10.142.0.7 yang merupakan master di bawah region us-east1. Lihat tangkapan layar di bawah bagaimana ClusterControl bereaksi terhadap ini:

ClusterControl mengirimkan alarm setelah mendeteksi anomali di cluster. Kemudian mencoba melakukan failover ke master baru dengan memilih kandidat yang tepat (lihat gambar di bawah):

Kemudian, ia menyisihkan master yang gagal yang telah dikeluarkan dari cluster (lihat gambar di bawah):

Ini hanya sekilas tentang apa yang dapat dilakukan ClusterControl, ada fitur hebat lainnya seperti pencadangan, pemantauan kueri, penerapan/pengelolaan penyeimbang beban, dan banyak lagi!

Kesimpulan

Mengelola pengaturan Replikasi MySQL Anda di multicloud bisa jadi rumit. Harus sangat berhati-hati untuk mengamankan setup kita, jadi semoga blog ini memberikan gambaran tentang bagaimana mendefinisikan subnet dan melindungi node database. Setelah keamanan, ada beberapa hal yang harus dikelola dan di sinilah ClusterControl bisa sangat membantu.

Cobalah sekarang dan beri tahu kami bagaimana kelanjutannya. Anda dapat menghubungi kami di sini kapan saja.