Arsitektur referensi ini menyediakan framework konseptual untuk men-deploy dan mengoperasikan database MySQL 8.4 yang sangat tersedia dan dikelola pelanggan di Google Distributed Cloud (GDC) dengan air gap. Solusi ini memungkinkan pelanggan perusahaan dan pelanggan akses awal untuk mempertahankan workload database penting secara andal menggunakan penyiapan virtual machine (VM) multi-zona yang andal.
Karena GDC dengan air gap tidak mendukung cluster perluasan Kubernetes lintas zona, arsitektur ini sepenuhnya mengandalkan VM khusus yang di-deploy di tiga domain ketersediaan untuk memastikan operasi berkelanjutan dan tahan terhadap kegagalan zona penuh tanpa kehilangan data.
Fitur dan kemampuan
- Ketahanan multi-zona: Konfigurasi 3 node yang sangat tangguh di-deploy di tiga zona ketersediaan yang berbeda untuk melindungi dari kegagalan zona infrastruktur tunggal.
- Ketersediaan tinggi dan konsensus otomatis: Menggunakan Group Replication untuk pengelompokan konsensus berbasis Paxos, yang menyediakan deteksi kegagalan otomatis, kesepakatan node, dan sinkronisasi data global tanpa skenario split-brain.
- Perutean traffic cerdas: Instance MySQL Router yang ditempatkan bersama mengelola perutean koneksi. Router mengarahkan operasi tulis (misalnya, port 6446) khusus ke node utama aktif dan menyeimbangkan beban operasi baca (misalnya, port 6447) di seluruh replika yang disinkronkan.
- Load balancing global: Terintegrasi dengan GDC Global L4 Load Balancer bawaan untuk menyediakan satu IP Virtual (VIP) yang stabil bagi aplikasi klien, sehingga 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 tugas: Memisahkan mesin database dan lapisan konsensus (Group Replication) dari lapisan perutean traffic klien (MySQL Router), sekaligus menyederhanakan pengelolaan siklus proses cluster menggunakan MySQL Shell.
- Pengoptimalan infrastruktur: Dirancang khusus untuk lingkungan air-gapped, menggunakan VM yang andal untuk melewati 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 Compute khusus, yang 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 MySQL Router 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 secara khusus untuk mengonfigurasi, menyediakan, dan mengelola instance cluster InnoDB.
- MySQL Router: Bertindak sebagai perute traffic di setiap VM. Dikonfigurasi secara dinamis untuk memproses metadata cluster dan meneruskan traffic: aktif/cadangan untuk penulisan dan round-robin untuk pembacaan.
Aliran dan antarmuka data
- Aplikasi mengirim permintaan database ke GDC Global L4 Load Balancer VIP.
- Load Balancer memproksi koneksi ke instance MySQL Router yang responsif di salah satu VM.
- Berdasarkan port yang diminta, MySQL Router meneruskan traffic secara dinamis: Port 6446 secara ketat menargetkan node aktif untuk penulisan, sementara Port 6447 melakukan siklus pembacaan di seluruh cluster.
Pertimbangan
- Kompromi antara performa dan konsistensi: Karena Group Replication 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 mengoptimalkan penggunaan hardware, tetapi memerlukan penyesuaian resource yang cermat untuk mencegah overhead penggabungan koneksi mengganggu 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 seluruh zona terpisah adalah satu-satunya metode yang layak untuk mencapai ketersediaan tinggi multi-zona yang sebenarnya dan bertahan dari kegagalan total zona.
- Cluster InnoDB vs. Orchestrator dan ProxySQL: Arsitektur primer/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 menyederhanakan kompleksitas operasional seputar failover secara drastis dengan menjaga konsensus langsung dalam MySQL.
- Load balancing global bawaan platform: Memanfaatkan Load Balancer Global L4 GDC bawaan memastikan bahwa VIP dikontrol oleh bidang kontrol GDC, sehingga menjaga ketahanan titik entri dan menyederhanakan pengiriman traffic lintas zona.
Asumsi dan batasan
Asumsi
- Ketersediaan infrastruktur: Pelanggan memiliki kuota project yang cukup untuk menyediakan VM khusus yang berukuran tepat dan Load Balancer Global yang didistribusikan secara merata di tiga zona ketersediaan.
- Jaringan yang aman: Akses berbasis kunci dan ProjectNetworkPolicies (PNP) yang tepat ditetapkan untuk mengizinkan sinkronisasi Replikasi Grup intra-cluster dan traffic MySQL Router.
Batasan
- Kubernetes tidak didukung: Pelanggan yang secara ketat mencari solusi berbasis Kubernetes/container tidak dapat mencapai HA multi-zona hingga cluster yang diperluas didukung sepenuhnya oleh platform.
- Upgrade manual diperlukan: Tidak seperti layanan terkelola, solusi ini menempatkan tanggung jawab untuk penerapan patch rutin tingkat OS dan upgrade versi minor database sepenuhnya pada pelanggan.
- Sensitivitas latensi jaringan: Replikasi memerlukan jaringan yang stabil dan berkualitas tinggi. Lonjakan latensi atau jitter jaringan antara zona yang terisolasi 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