Questa architettura di riferimento fornisce un framework concettuale per il deployment e il funzionamento di database MySQL 8.4 ad alta affidabilità gestiti dal cliente su Google Distributed Cloud (GDC) con air gap. Consente ai clienti aziendali e con accesso in anteprima di mantenere in modo affidabile i workload di database critici utilizzando una configurazione di macchine virtuali (VM) multizona affidabile.
Poiché GDC con air gap non supporta i cluster estesi di Kubernetes 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 errore di zona completo senza perdita di dati.
Caratteristiche e funzionalità
- Resilienza multizona: una configurazione a 3 nodi altamente resiliente di cui viene eseguito il deployment in tre zone di disponibilità distinte per proteggere dai guasti di una singola zona dell'infrastruttura.
- Alta affidabilità e consenso automatizzati: utilizza la replica di gruppo per il clustering di consenso basato su Paxos, fornendo rilevamento automatico degli errori, accordo tra i nodi e sincronizzazione globale dei dati senza scenari di split-brain.
- Routing del traffico intelligente: 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 principale 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 di GDC integrato per fornire un IP virtuale (VIP) singolo e stabile per le applicazioni client, astraendo la topologia dei nodi sottostante.
Principi di architettura
- Consenso basato su quorum: dà priorità alla coerenza rigorosa dei dati. La replica di gruppo applica un modello basato su Paxos che richiede l'accordo della maggioranza, eliminando il rischio di perdita di dati o di 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 (router MySQL), semplificando al contempo la gestione del ciclo di vita del cluster utilizzando MySQL Shell.
- Ottimizzazione dell'infrastruttura: progettata specificamente per ambienti con air gap, utilizza 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 di computing dedicate, ciascuna di cui è stato eseguito il deployment in una zona di disponibilità separata per formare i confini del dominio in errore.
- Bilanciatore del carico L4 globale di GDC: un costrutto di networking gestito dalla piattaforma che espone un VIP interno stabile, valutando automaticamente i controlli di integrità del router MySQL 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.
- Router MySQL: 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 di GDC.
- Il bilanciatore del carico funge da proxy per la connessione a un'istanza MySQL Router integra su una delle VM.
- In base alla porta richiesta, MySQL Router inoltra il traffico in modo dinamico: la porta 6446 ha come target esclusivo il nodo attivo per le scritture, mentre la porta 6447 esegue cicli di lettura nel cluster.
Considerazioni
- Compromessi tra prestazioni e coerenza: poiché la replica di gruppo impone il consenso, le transazioni richiedono la conferma 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 sottragga risorse ai processi MySQL principali.
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 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 errore totale della zona.
- Cluster InnoDB rispetto a Orchestrator e ProxySQL: un'architettura tradizionale principale/secondaria abbinata a ProxySQL e Orchestrator è stata valutata come un'alternativa fattibile. Tuttavia, è stato scelto il cluster InnoDB integrato (replica dei gruppi + router MySQL + 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 all'interno di 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 control plane GDC, mantenendo il punto di ingresso resiliente e semplificando la distribuzione del traffico tra zone.
Ipotesi e limitazioni
Ipotesi
- Disponibilità dell'infrastruttura: i clienti hanno una quota di progetto sufficiente per eseguire il provisioning di VM dedicate e di dimensioni adeguate e di bilanciatori del carico globali distribuiti in modo uniforme in tre zone di disponibilità.
- Rete sicura: vengono stabiliti l'accesso basato su chiavi e ProjectNetworkPolicies (PNP) appropriate per consentire la sincronizzazione della replica dei gruppi all'interno del cluster e il traffico del router MySQL.
Limitazioni
- Kubernetes non supportato: i clienti che cercano esclusivamente soluzioni containerizzate/basate su Kubernetes non possono ottenere l'alta affidabilità multizona finché i cluster estesi non saranno completamente supportati dalla piattaforma.
- Upgrade manuali richiesti: a differenza dei servizi gestiti, questa soluzione attribuisce interamente al cliente la responsabilità dell'applicazione di patch di routine a livello di sistema operativo e degli 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 con air gap 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 multizona ad alta affidabilità in GDC con air gap