Arsitektur referensi ini menyediakan framework konseptual untuk men-deploy dan mengoperasikan database MySQL 8.4 dengan tingkat ketersediaan tinggi dan dikelola pelanggan di Google Distributed Cloud (GDC) dengan air gap. Dengan layanan ini, pelanggan perusahaan dan akses awal dapat mempertahankan workload database penting dengan andal menggunakan penyiapan virtual machine (VM) multi-zona yang tangguh.
Karena GDC dengan air gap tidak mendukung cluster stretch Kubernetes lintas zona, arsitektur ini sangat bergantung pada VM khusus yang di-deploy di tiga domain ketersediaan untuk memastikan operasi yang berkelanjutan dan bertahan dari kegagalan zona penuh tanpa kehilangan data.
Fitur dan kemampuan
- Ketahanan multi-zona: Konfigurasi 3 node yang sangat tangguh yang di-deploy di tiga zona ketersediaan yang berbeda untuk melindungi dari kegagalan zona infrastruktur tunggal.
- Ketersediaan tinggi dan konsensus otomatis: Menggunakan Replikasi Grup untuk pengelompokan konsensus berbasis Paxos, yang menyediakan deteksi kegagalan otomatis, persetujuan node, dan sinkronisasi data global tanpa skenario split-brain.
- Pemilihan rute traffic yang cerdas: Instance Router MySQL yang ditempatkan bersama mengelola pemilihan rute koneksi. Router mengarahkan operasi tulis (misalnya, port 6446) hanya ke node utama yang aktif dan menyeimbangkan beban operasi baca (misalnya, port 6447) di seluruh replika yang disinkronkan.
- Load balancing global: Terintegrasi dengan Load Balancer L4 Global GDC bawaan untuk menyediakan Virtual IP (VIP) tunggal yang stabil bagi aplikasi klien, yang mengabstraksi topologi node yang mendasarinya.
Prinsip arsitektur
- Konsensus berbasis kuorum: Memprioritaskan konsistensi data yang ketat. Replikasi Grup menerapkan model berbasis Paxos yang memerlukan persetujuan mayoritas, sehingga menghilangkan risiko kehilangan data atau split-brain selama partisi jaringan.
- Pemisahan fokus: Memisahkan mesin database dan lapisan konsensus (Group Replication) dari lapisan pemilihan rute traffic klien (MySQL Router), sekaligus menyederhanakan pengelolaan siklus proses cluster menggunakan MySQL Shell.
- Pengoptimalan infrastruktur: Dirancang khusus untuk lingkungan air-gap, menggunakan VM yang tangguh untuk mengatasi batasan jaringan Kubernetes saat ini.
Arsitektur
Konsep dan teknologi
Bagian ini menjelaskan komponen fungsional dan tanggung jawab spesifiknya dalam arsitektur multi-zona.
Infrastruktur dan platform
- Virtual Machine (VM): Tiga instance komputasi khusus, masing-masing di-deploy ke zona ketersediaan terpisah untuk membentuk batas domain kegagalan.
- Load Balancer L4 Global GDC: Konstruksi jaringan yang dikelola platform yang mengekspos VIP internal yang stabil, yang secara otomatis mengevaluasi health check Router MySQL untuk mengalihkan traffic masuk.
Layanan dan logika
- MySQL 8.4: Mesin database relasional inti.
- Group Replication/InnoDB Cluster: Framework pengelompokan bawaan yang bertanggung jawab atas replikasi multi-master dan memverifikasi kuorum node menggunakan Paxos.
- MySQL Shell: Antarmuka command line terpadu yang digunakan khusus untuk mengonfigurasi, menyediakan, dan mengelola instance cluster InnoDB.
- Router MySQL: Bertindak sebagai router traffic di setiap VM. Dikonfigurasi secara dinamis untuk memproses metadata cluster dan meneruskan traffic: aktif/cadangan untuk penulisan dan round-robin untuk pembacaan.
Aliran data dan antarmuka
- Aplikasi mengirim permintaan database ke VIP Load Balancer L4 Global GDC.
- Load Balancer mem-proxy koneksi ke instance MySQL Router yang responsif di salah satu VM.
- Berdasarkan port yang diminta, Router MySQL meneruskan traffic secara dinamis: Port 6446 secara ketat menargetkan node aktif untuk penulisan, sedangkan Port 6447 mengalihkan pembacaan di seluruh cluster.
Pertimbangan
- Kompromi antara performa dan konsistensi: Karena Replikasi Grup menerapkan konsensus, transaksi memerlukan konfirmasi dari peer cluster. Performa berkorelasi langsung dengan latensi jaringan antar-zona dalam lingkungan GDC.
- Pengelolaan resource: Men-deploy MySQL Router langsung di VM database akan mengoptimalkan pemanfaatan hardware, tetapi memerlukan penyesuaian resource yang cermat untuk mencegah overhead penggabungan koneksi menghabiskan proses MySQL inti.
Keputusan desain
- Virtual machine melalui Kubernetes: GDC dengan air gap tidak mendukung cluster Kubernetes yang mencakup beberapa zona fisik. Pendekatan berbasis VM dipilih secara ketat karena men-deploy VM khusus di berbagai zona terpisah adalah satu-satunya metode yang layak untuk mencapai ketersediaan tinggi multi-zona yang sebenarnya dan bertahan dari kegagalan zona total.
- InnoDB Cluster vs. Orchestrator dan ProxySQL: Arsitektur utama/sekunder tradisional yang dipasangkan dengan ProxySQL dan Orchestrator dievaluasi sebagai alternatif yang layak. Namun, InnoDB Cluster bawaan (Group Replication + MySQL Router + MySQL Shell) dipilih karena menghilangkan ketergantungan pada overlay perutean pihak ketiga dan secara drastis menyederhanakan kompleksitas operasional seputar failover dengan menjaga konsensus langsung di dalam MySQL.
- Load balancing global bawaan platform: Memanfaatkan Load Balancer L4 Global GDC bawaan memastikan bahwa VIP dikontrol oleh bidang kontrol GDC, sehingga menjaga titik entri tetap tangguh dan menyederhanakan pengiriman traffic lintas zona.
Asumsi dan batasan
Asumsi
- Ketersediaan infrastruktur: Pelanggan memiliki kuota project yang cukup untuk menyediakan VM khusus dengan ukuran yang tepat dan Load Balancer Global yang didistribusikan secara merata di tiga zona ketersediaan.
- Jaringan yang aman: Akses berbasis kunci dan ProjectNetworkPolicies (PNP) yang tepat dibuat untuk mengizinkan sinkronisasi Group Replication intra-cluster dan traffic Router MySQL.
Batasan
- Kubernetes tidak didukung: Pelanggan yang hanya mencari solusi berbasis container/Kubernetes tidak dapat mencapai HA multi-zona hingga cluster stretch didukung sepenuhnya oleh platform.
- Perlu upgrade manual: Tidak seperti layanan terkelola, solusi ini menempatkan tanggung jawab atas penerapan patch level OS rutin dan upgrade versi minor database sepenuhnya pada pelanggan.
- Sensitivitas latensi jaringan: Replikasi memerlukan jaringan yang stabil dan berkualitas tinggi. Jitter jaringan atau lonjakan latensi antara zona air-gapped akan menunda operasi tulis secara proporsional di seluruh cluster MySQL.
Materi tambahan
- Implementasi Referensi Solusi (SRI): Implementasi Referensi Solusi untuk MySQL 8 Multi-Zona dengan Ketersediaan Tinggi di GDC dengan air gap