Questa architettura di riferimento fornisce un framework concettuale per il deployment e l'utilizzo di database MySQL 8.4 ad alta disponibilità e gestiti dal cliente su Google Distributed Cloud (GDC) air-gapped. Consente ai clienti aziendali e con accesso anticipato di mantenere in modo affidabile i carichi di lavoro di database critici utilizzando una configurazione di macchine virtuali (VM) robusta e multizona.
Poiché GDC con air gap non supporta i cluster Kubernetes stretch tra zone, questa architettura si basa rigorosamente su VM dedicate di cui è stato eseguito il deployment in tre domini di disponibilità per garantire operazioni continue e resistere a un guasto completo della zona senza perdita di dati.
Caratteristiche e funzionalità
- Resilienza multizona: una configurazione a 3 nodi ad alta resilienza di cui è stato eseguito il deployment in tre zone di disponibilità distinte per proteggere dai guasti di una singola zona di infrastruttura.
- Alta affidabilità e consenso automatizzati: utilizza la replica dei gruppi per il clustering di consenso basato su Paxos, fornendo il rilevamento automatico dei guasti, l'accordo dei nodi e la sincronizzazione globale dei dati senza scenari di split-brain.
- Routing intelligente del traffico: le istanze MySQL Router collocate gestiscono il routing delle connessioni. Il router indirizza le operazioni di scrittura (ad esempio, la porta 6446) rigorosamente a un nodo primario attivo e bilancia il carico delle operazioni di lettura (ad esempio, la porta 6447) tra le repliche sincronizzate.
- Bilanciamento del carico globale: si integra con il bilanciatore del carico L4 globale GDC integrato per fornire un singolo IP virtuale (VIP) stabile per le applicazioni client, astratto dalla topologia dei nodi sottostante.
Principi architetturali
- Consenso basato sul quorum: dà la priorità alla coerenza rigorosa dei dati. La replica dei gruppi applica un modello basato su Paxos che richiede l'accordo della maggioranza, eliminando il rischio di perdita di dati o split-brain durante le partizioni di rete.
- Separazione delle responsabilità: disaccoppia il motore del database e il livello di consenso (replica dei gruppi) dal livello di routing del traffico client (MySQL Router), semplificando al contempo la gestione del ciclo di vita del cluster utilizzando MySQL Shell.
- Ottimizzazione dell'infrastruttura: progettata specificamente per gli ambienti air-gapped, utilizzando VM robuste per aggirare le attuali limitazioni di networking di Kubernetes.
Architettura
Concetti e tecnologie
Questa sezione descrive in dettaglio i componenti funzionali e le loro responsabilità specifiche all'interno dell'architettura multizona.
Infrastruttura e piattaforma
- Macchine virtuali (VM): tre istanze Compute dedicate, ognuna di cui è stato eseguito il deployment in una zona di disponibilità separata per formare i limiti del dominio in errore.
- Bilanciatore del carico L4 globale GDC: un costrutto di networking gestito dalla piattaforma che espone un VIP interno stabile, valutando automaticamente i controlli di integrità di MySQL Router per reindirizzare il traffico in entrata.
Servizi e logica
- MySQL 8.4: il motore del database relazionale principale.
- Replica dei gruppi / cluster InnoDB: il framework di clustering integrato responsabile della replica multi-master e della verifica del quorum dei nodi utilizzando Paxos.
- MySQL Shell: l'interfaccia a riga di comando unificata utilizzata specificamente per configurare, eseguire il provisioning e amministrare le istanze del cluster InnoDB.
- MySQL Router: funge da router del traffico su ogni VM. Configurato dinamicamente per ascoltare i metadati del cluster e inoltrare il traffico: attivo/backup per le scritture e round robin per le letture.
Flusso di dati e interfacce
- Le applicazioni inviano richieste di database al VIP del bilanciatore del carico L4 globale GDC.
- Il bilanciatore del carico invia tramite proxy la connessione a un'istanza MySQL Router integra su una delle VM.
- In base alla porta richiesta, MySQL Router inoltra dinamicamente il traffico: la porta 6446 indirizza rigorosamente il nodo attivo per le scritture, mentre la porta 6447 esegue il ciclo delle letture nel cluster.
Considerazioni
- Compromessi tra prestazioni e coerenza: poiché la replica dei gruppi applica il consenso, le transazioni richiedono il riconoscimento da parte dei peer del cluster. Le prestazioni sono direttamente correlate alla latenza di rete tra zone all'interno dell'ambiente GDC.
- Gestione delle risorse: il deployment di MySQL Router direttamente sulle VM del database ottimizza l'utilizzo dell'hardware, ma richiede un'attenta ottimizzazione delle risorse per evitare che l'overhead del pool di connessioni privi i processi MySQL principali delle risorse.
Decisione di progettazione
- Macchine virtuali su Kubernetes: GDC con air gap non supporta i cluster Kubernetes che si estendono su più zone fisiche. È stato scelto rigorosamente un approccio basato su VM perché il deployment di VM dedicate in zone separate è l'unico metodo praticabile per ottenere una vera alta affidabilità multizona e sopravvivere a un guasto totale della zona.
- Cluster InnoDB rispetto a Orchestrator e ProxySQL: è stata valutata un'architettura primaria/secondaria tradizionale abbinata a ProxySQL e Orchestrator come alternativa fattibile. Tuttavia, è stato selezionato il cluster InnoDB integrato (replica dei gruppi + MySQL Router + MySQL Shell) perché elimina la dipendenza da overlay di routing di terze parti e semplifica drasticamente la complessità operativa dei failover mantenendo il consenso direttamente in MySQL.
- Bilanciamento del carico globale integrato nella piattaforma: l'utilizzo del bilanciatore del carico L4 globale GDC integrato garantisce che il VIP sia controllato dal piano di controllo GDC, mantenendo il punto di ingresso resiliente e semplificando la distribuzione del traffico tra zone.
Ipotesi e limitazioni
Ipotesi
- Disponibilità dell'infrastruttura: i clienti dispongono di una quota di progetto sufficiente per eseguire il provisioning di VM dedicate e di dimensioni appropriate e di bilanciatori del carico globali distribuiti uniformemente in tre zone di disponibilità.
- Networking sicuro: sono stabiliti l'accesso basato su chiavi e ProjectNetworkPolicies (PNP) appropriati per consentire la sincronizzazione della replica dei gruppi intra-cluster e il traffico di MySQL Router.
Limitazioni
- Kubernetes non supportato: i clienti che cercano rigorosamente soluzioni basate su container/Kubernetes non possono ottenere l'alta disponibilità multizona finché i cluster stretch non sono completamente supportati dalla piattaforma.
- Aggiornamenti manuali richiesti: a differenza dei servizi gestiti, questa soluzione affida interamente al cliente la responsabilità di applicare patch di routine a livello di sistema operativo e di eseguire l'upgrade delle versioni secondarie del database.
- Sensibilità alla latenza di rete: la replica richiede una rete stabile e di alta qualità. Il jitter di rete o i picchi di latenza tra le zone air-gapped ritarderanno proporzionalmente le operazioni di scrittura nel cluster MySQL.
Materiali aggiuntivi
- Implementazione di riferimento della soluzione (SRI): Implementazione di riferimento della soluzione per MySQL 8 a elevata affidabilità e multizona in GDC con air gap