Questo documento descrive diverse architetture che forniscono alta disponibilità (HA) per i deployment di MySQL su Google Cloud. L'HA misura la resilienza del sistema in risposta al guasto dell'infrastruttura di base. In questo documento, l'alta disponibilità riguarda la disponibilità dei cluster MySQL all'interno di un'unica regione cloud.
Questo documento è rivolto ad amministratori di database, cloud architect e sviluppatori DevOps che vogliono scoprire come aumentare l'affidabilità del livello dati MySQL migliorando il tempo di attività complessivo del sistema. Questo documento è rivolto a te se esegui MySQL su Compute Engine. Se utilizzi Cloud SQL per MySQL, questo documento non è rivolto a te.
Per un sistema o un'applicazione che richiede uno stato permanente per gestire richieste o transazioni, il livello di persistenza dei dati deve essere disponibile per gestire correttamente le richieste di query o mutazioni dei dati. Se l'applicazione deve interagire con il livello di dati per gestire le richieste, qualsiasi tempo di riposo nel livello di dati impedisce all'applicazione di eseguire le attività necessarie.
A seconda degli obiettivi del livello di servizio (SLO) del sistema, potresti necessitare di una topologia dell'architettura che offra un livello di disponibilità più elevato. Esistono più di un modo per ottenere l'alta disponibilità, ma in genere esegui il provisioning di un'infrastruttura ridondante che puoi rendere rapidamente accessibile alla tua applicazione.
Questo documento illustra i seguenti argomenti:
- Definisci i termini per aiutarti a comprendere i concetti del database HA.
- Ti aiuta a comprendere diverse opzioni per le topologie MySQL ad alta disponibilità.
- Fornisci informazioni contestuali per aiutarti a capire cosa prendere in considerazione in ogni opzione.
Terminologia
Esistono diversi termini e concetti standard di settore utili da comprendere per scopi che non rientrano nell'ambito di questo documento.
Replicazione. La procedura mediante la quale le transazioni di scrittura (INSERT, UPDATE o
DELETE) vengono acquisite, registrate e poi applicate in sequenza a tutti
i nodi del database nella topologia.
Nodo di origine. Tutte le scritture del database devono essere indirizzate a un nodo di origine. Il nodo di origine fornisce una lettura con lo stato più aggiornato dei dati persistenti.
Nodo replica. Una copia online del nodo del database di origine. Le modifiche vengono replicate in modo quasi sincrono nei nodi replica dal nodo di origine. Puoi leggere dai nodi replica tenendo presente che i dati potrebbero essere leggermente in ritardo a causa del ritardo della replica.
Ritardo della replica. Una misurazione del tempo che esprime la differenza tra il momento in cui viene applicata una transazione alla replica e il momento in cui viene applicata al nodo di origine.
Uptime. La percentuale di tempo in cui una risorsa è in funzione e in grado di fornire una risposta a una richiesta.
Rilevamento di errori. Il processo di identificazione di un errore dell'infrastruttura.
Failover. La procedura per promuovere l'infrastruttura di backup o di standby (in questo caso, il nodo replica) in modo che diventi l'infrastruttura principale. In altre parole, durante il failover, il nodo replica diventa il nodo di origine.
Recovery Time Objective (RTO). La durata, in tempo reale trascorso, accettabile dal punto di vista aziendale per il completamento del processo di failover del livello di dati.
Riserva. È stata eseguita la procedura per reintegrare l'ex nodo di origine dopo un failover.
Riparazione automatica. La capacità di un sistema di risolvere i problemi senza azioni esterne da parte di un operatore umano.
Partizione di rete. Una condizione in cui due nodi di una topologia, ad esempio i nodi di origine e di replica, non possono comunicare tra loro tramite la rete.
Cerebro diviso. Una condizione che si verifica quando due nodi ritengono contemporaneamente di essere il nodo di origine.
Gruppo di nodi. Un insieme di attività delle risorse di calcolo che forniscono un servizio. Per questo documento, questo servizio è il livello di persistenza dei dati.
Nodo di quorum o di testimone. Una risorsa di calcolo separata che aiuta un gruppo di nodi a determinare cosa fare quando si verifica una condizione di split-brain.
Scelta della sorgente o del leader. La procedura mediante la quale un gruppo di nodi aware-peer, inclusi i nodi di riferimento, determina quale nodo deve essere il nodo di origine.
Gruppo di nodi. Un insieme di attività delle risorse di calcolo che forniscono un servizio. Per questo documento, questo servizio è il livello di persistenza dei dati.
Hot standby. Un nodo che rappresenta una copia esatta di un altro nodo di origine e può diventare il nuovo nodo di origine con un tempo di riposo minimo.
Quando prendere in considerazione un'architettura HA
Le architetture ad alta disponibilità offrono una maggiore protezione contro i tempi di inattività del livello di dati. È fondamentale comprendere la tolleranza al tempo di riposo e i rispettivi compromessi delle varie architetture per scegliere l'opzione più adatta al caso d'uso della tua attività.
Utilizza una topologia HA quando vuoi aumentare l'uptime del livello di dati per soddisfare i requisiti di affidabilità per i tuoi carichi di lavoro e servizi. Per gli ambienti in cui è tollerato un certo tempo di riposo, una topologia HA introduce costi e complessità non necessari. Ad esempio, gli ambienti di sviluppo o di test raramente necessitano di un livello di database ad alta disponibilità.
Considera i tuoi requisiti per l'HA
Il costo è un aspetto importante da considerare, perché devi aspettarti che i costi dell'infrastruttura di calcolo e dello spazio di archiviazione raddoppino almeno per fornire l'HA. Quando valuti le possibili opzioni di HA MySQL, poniti le seguenti domande:
- Quali servizi o clienti si basano sul tuo livello di dati?
- Qual è il tuo budget operativo?
- Qual è il costo per la tua attività in caso di downtime nel livello di persistenza dei dati?
- Quanto deve essere automatizzato il processo?
- Quale livello di disponibilità speri di raggiungere, 99,5%, 99,9% o 99,99%?
- Con quale rapidità devi eseguire il failover? Qual è il tuo RTO?
I seguenti fattori contribuiscono al tempo di recupero e devono essere presi in considerazione quando si determina il RTO:
- Rilevamento dell'interruzione
- Idoneità dell'istanza di macchina virtuale (VM) secondaria
- Failover dello spazio di archiviazione
- Tempo di recupero del database
- Tempo di recupero dell'applicazione
Architetture HA di MySQL
A livello più elementare, l'HA nel livello di dati è costituito da quanto segue:
- Un meccanismo per identificare un errore del nodo di origine.
- Un processo per eseguire un failover in cui il nodo replica viene promosso a nodo di origine.
- Una procedura per modificare l'instradamento delle query in modo che le richieste dell'applicazione raggiungano il nuovo nodo di origine.
- Facoltativamente, un metodo per eseguire il fallback alla topologia originale utilizzando i nodi di origine e di replica.
Questo documento illustra le seguenti tre architetture HA:
Oltre a gestire gli errori dell'infrastruttura, ciascuna di queste architetture può contribuire a minimizzare i tempi di inattività nell'improbabile caso di un'interruzione di servizio zonale. Utilizzi queste architetture con modifiche al DNS (Domain Name System) per fornire HA multi-regione per proteggerti dall'interruzione del servizio a livello regionale, ma questo argomento non rientra nell'ambito di questo documento.
HA con dischi permanenti a livello di regione
L'HA nel livello di dati si basa sempre su un qualche tipo di replica dei dati. La replica più semplice è quella che non devi gestire.
Con l'opzione di archiviazione disco permanente regionale di Compute Engine, puoi eseguire il provisioning di un dispositivo di archiviazione a blocchi che fornisce la replica sincrona dei dati tra due zone in una regione. I dischi permanenti regionali costituiscono un componente di base solido per implementare i servizi ad alta disponibilità in Compute Engine.
Il seguente diagramma illustra l'architettura dell'HA con i dischi permanenti regionali.
Se l'istanza VM del nodo di origine non è disponibile a causa di un errore dell'infrastruttura o di un'interruzione di servizio a livello di zona, puoi forzare il Persistent Disk regionale ad associarsi a un'istanza VM nella zona di backup nella stessa regione.
Per eseguire questa operazione, devi svolgere una delle seguenti operazioni:
- Avvia un'altra istanza VM nella zona di backup in cui è disponibile l'accesso al Persistent Disk regionale condiviso.
- Mantieni un'istanza VM hot standby nella zona di backup. Un'istanza VM in standby caldo è un'istanza VM in esecuzione identica a quella in uso. Dopo aver collegato il Persistent Disk a livello di regione, puoi avviare il motore del database.
Se l'interruzione del servizio dati viene identificata tempestivamente, l'operazione di attacco forzato solitamente si completa in meno di un minuto, il che significa che è possibile ottenere un RTO misurato in minuti.
Se la tua attività può tollerare il tempo di riposo aggiuntivo necessario per rilevare e comunicare un'interruzione e per eseguire il failover manualmente, non è necessario automatizzare il processo.
Se la tolleranza RTO è inferiore, puoi automatizzare il processo di rilevamento e failover. Se automatizzi questa architettura, il sistema è ulteriormente complicato perché esistono diversi casi limite nel processo di failover e fallback che devi prendere in considerazione. Per saperne di più su un'implementazione completamente automatica di questa architettura, consulta la configurazione dell'alta disponibilità di Cloud SQL.
Vantaggi
Esistono diversi vantaggi nell'ottenere l'HA utilizzando i dischi permanenti regionali grazie alle seguenti funzionalità:
- Questa architettura offre protezione simultanea contro diverse modalità di errore: guasto dell'infrastruttura del server della zona principale, degrado dello spazio di archiviazione a blocchi in una singola zona o interruzione dell'intera zona.
- La replica del livello di applicazione o del database non è necessaria perché i dischi permanenti regionali forniscono una replica dei dati a livello di blocco continua e sincrona, gestita completamente da Google Cloud. Un Persistent Disk regionale rileva automaticamente errori e rallentamenti, cambia la modalità di replica ed esegue il recupero dei dati replicati in una sola zona.
- Se si verificano problemi di archiviazione in una zona principale, un Persistent Disk regionale esegue automaticamente letture dalla zona secondaria. Questa operazione può comportare un aumento della latenza di lettura, ma la tua applicazione può continuare a funzionare senza alcuna azione manuale.
Considerazioni
I limiti di questa architettura sono legati alla natura di singola regione di questa topologia e ad alcuni dei seguenti vincoli inerenti dei dischi persistenti regionali:
- Il Persistent Disk regionale può essere montato su un solo database. Anche se l'istanza VM del database di standby è in esecuzione, non può essere utilizzata per eseguire letture del database.
- La tecnologia di base alla base di questa architettura consente solo la replica tra zone nella stessa regione. Di conseguenza, il failover regionale non è un'opzione se utilizzi solo questa architettura.
- La velocità effettiva in scrittura del Persistent Disk regionale è dimezzata rispetto ai dischi permanenti zonali. Assicurati che i limiti di throughput rientrino nella tolleranza richiesta.
- La latenza di scrittura del Persistent Disk regionale è leggermente superiore rispetto al Persistent Disk a livello di zona. Ti consigliamo di testare il tuo carico di lavoro per verificare che le prestazioni di scrittura siano accettabili per i tuoi requisiti.
- Durante un evento di errore e il passaggio di cui è risultato, devi forzare il collegamento del Persistent Disk regionale alla VM della zona di standby. L'operazione di attacco forzato viene in genere eseguita in meno di un minuto, quindi devi tenere conto di questo tempo quando valuti il RTO.
- La stima del RTO deve tenere conto del tempo necessario per il collegamento forzato del Persistent Disk regionale e del rilevamento del file system della VM del disco collegato a caldo.
HA con hot standby e nodo di attestazione
Se vuoi un failover automatico, è necessaria un'architettura diversa. Un'opzione è implementare un gruppo di almeno due nodi di database, configurare la replica asincrona del database e avviare i nodi di attendibilità per contribuire ad assicurare che sia possibile raggiungere un quorum durante l'elezione di un nodo di origine.
Il nodo del database di origine elabora le transazioni di scrittura e serve le query di lettura. Il processo di replica del database trasmette le modifiche al nodo di replica attivo/standby online.
Poiché il nodo di attestazione può essere una piccola macchina virtuale, fornisce un meccanismo a basso costo per garantire che sia disponibile una maggioranza di gruppo per l'elezione di un nodo di origine.
I nodi di gruppo valutano continuamente lo stato degli altri nodi di gruppo. Gli indicatori che vengono consumati da questi controlli dello stato ogni pochi secondi sono chiamati heartbeat perché vengono utilizzati per valutare l'integrità degli altri nodi del gruppo. Una valutazione tempestiva dello stato di salute del nodo del database è importante perché è necessario identificare rapidamente un nodo del database di origine non integro in modo da poter avviare un failover del nodo di standby caldo.
Il quorum del gruppo di nodi è determinato dal numero di elementi di voto che devono far parte dell'appartenenza al cluster attivo affinché il cluster possa avviarsi correttamente o continuare a funzionare. Affinché un gruppo di nodi raggiunga il quorum nell'elezione di un nodo del database di origine, deve partecipare la maggioranza dei nodi del gruppo. Per proteggersi da una condizione di split-brain, il requisito di maggioranza garantisce che, in caso di partizione della rete, due gruppi di voto non possano avere contemporaneamente un numero sufficiente di nodi per votare.
Una maggioranza di gruppo è composta da (n+1)/2 nodi, dove n è il numero totale di nodi nel gruppo. Ad esempio, se in un gruppo sono presenti tre nodi, almeno due devono essere in funzione per l'elezione del nodo di origine. Se in un gruppo sono presenti cinque nodi, sono necessari almeno tre nodi.
I gruppi vengono dimensionati con un numero dispari di nodi nel caso in cui esista una partizione di rete che impedisca la comunicazione tra i sottogruppi del gruppo di nodi. Se il gruppo è pari, è più probabile che entrambi i sottogruppi abbiano meno della maggioranza. Se il gruppo è composto da un numero dispari di membri, è più probabile che uno dei sottogruppi abbia la maggioranza o che nessuno dei gruppi abbia la maggioranza.
Il seguente diagramma confronta un gruppo di nodi funzionante con un gruppo di nodi in degrado.
Il diagramma mostra due gruppi di nodi: un gruppo di nodi funzionante e un gruppo di nodi con prestazioni ridotte. Il gruppo di nodi completamente funzionale e integro ha tre membri. In questo stato, i nodi del database di origine e della replica svolgono la funzione prevista. Il quorum necessario per questo gruppo di nodi è di due nodi.
Il gruppo di nodi in degrado mostra lo stato in cui i heartbeat del nodo di origine non vengono più inviati a causa di un errore dell'infrastruttura. Questo stato potrebbe essere il risultato del fallimento dell'istanza del nodo del database di origine oppure il nodo di origine potrebbe essere ancora in esecuzione. In alternativa, una partizione di rete potrebbe impedire la comunicazione tra il nodo di origine e gli altri nodi del gruppo.
Indipendentemente dalla causa, il risultato è che sia la replica sia il testimone determinano che il nodo di origine non è più integro. A questo punto, la maggioranza del gruppo esegue l'elezione di un nodo di origine, determina che il nodo di standby caldo deve diventare il nodo di origine e avvia un failover.
Il seguente diagramma mostra il flusso di transazioni, replica e heartbeat del database nell'architettura del nodo di attendibilità.
Nel diagramma precedente, questa architettura HA si basa sul nodo della replica hot-standby per iniziare rapidamente a elaborare le scritture di produzione in caso di failover. I meccanismi del failover, ad esempio la promozione del nodo di origine, vengono eseguiti dai nodi del database nel gruppo.
Per implementare questa architettura, prendi in considerazione i seguenti due progetti:
- MySQL Group Replication è un plug-in open source per MySQL che semplifica la creazione di topiarie HA.
- Galera Cluster e Percona XtraDB Cluster sono altre opzioni open source che possono fornire alta disponibilità.
Vantaggi
L'architettura hot standby ha pochi componenti in movimento, è semplice da implementare e offre diversi vantaggi:
- Con un solo nodo di attendibilità aggiuntivo a basso costo, viene fornito un failover completamente automatico.
- Questa architettura può gestire un errore dell'infrastruttura a lungo termine così come un errore transitorio (ad esempio a causa di un riavvio del sistema).
- Con una certa latenza di replica associata, viene fornita l'HA multi-regione.
Considerazioni
Il failover è automatico, ma rimangono le seguenti attività operative:
- Gestisci la replica tra i nodi di origine e di replica.
- Gestisci i nodi di attestazione.
- Devi eseguire il deployment e gestire il routing delle connessioni utilizzando un bilanciatore del carico.
- Senza modifiche alla logica dell'applicazione, che non rientrano nell'ambito di questo documento, non puoi indirizzare le letture al nodo replica.
HA con Orchestrator e ProxySQL
Se combini i componenti open source Orchestrator e ProxySQL, hai un'architettura in grado di rilevare le interruzioni e di eseguire automaticamente il failover del traffico da un nodo di origine interessato a una replica sana appena promossa.
Inoltre, puoi inoltrare in modo trasparente le query ai nodi di lettura o di lettura e scrittura appropriati per migliorare le prestazioni del livello di dati in stato stazionario.
Orchestrator è una soluzione di failover e gestione della topologia di replica MySQL open source. Il software consente di rilevare, eseguire query e eseguire il refactoring di topia di replica complesse e fornisce un rilevamento degli errori, un recupero e un'evoluzione affidabili.
ProxySQL è un proxy consapevole del protocollo di database open source, ad alte prestazioni e altamente disponibile per MySQL. ProxySQL è scalabile fino a milioni di connessioni su centinaia di migliaia di server di backend.
Il seguente diagramma mostra l'architettura combinata di Orchestrator e ProxySQL.
In questa architettura, come illustrato dal diagramma precedente, il traffico associato al database viene instradato da un bilanciatore del carico interno a istanze ProxySQL ridondanti. Queste istanze indirizzano il traffico a un'istanza di database con possibilità di scrittura o lettura in base alla configurazione di ProxySQL.
Orchestrator fornisce i seguenti passaggi per il rilevamento e il recupero degli errori:
- Orchestrator determina che il nodo del database di origine non è disponibile.
- A tutti i nodi replica viene eseguita una query per fornire una seconda opinione sullo stato del nodo di origine.
- Se le repliche forniscono una valutazione coerente che indica che l'origine non è disponibile, il failover procede.
- Come definito dalla topologia, il nodo promosso diventa il nuovo nodo di origine durante il failover.
- Al termine del failover, Orchestrator contribuisce ad assicurare che venga eseguito il provisioning del numero corretto di nuovi nodi di replica in base alla topologia.
La replica continua tra il database di origine nella zona A e le repliche del database nelle zone alternative mantiene le repliche aggiornate con eventuali scritture inviate all'origine. Orchestrator controlla l'integrità dei database di origine e delle repliche inviando continuamente heartbeat. Lo stato dell'applicazione Orchestrator viene mantenuto in un database Cloud SQL separato. Se sono necessarie modifiche alla topologia, Orchestrator può anche inviare comandi ai database.
ProxySQL inoltra il traffico in modo appropriato ai nuovi nodi di origine e replica quando il failover è completato. I servizi continuano ad accedere al livello di dati utilizzando l'indirizzo IP del bilanciatore del carico. L'indirizzo IP virtuale viene trasferito senza problemi dal nodo di origine precedente al nuovo nodo di origine.
Vantaggi
I componenti dell'architettura e l'automazione offrono i seguenti vantaggi:
- Il software utilizzato in questa architettura fornisce varie funzionalità di osservabilità, tra cui grafici della topologia di replica e visibilità del traffico delle query.
- ProxySQL e Orchestrator si coordinano per fornire la promozione e il failover automatici delle repliche.
- Il criterio di promozione della replica è completamente configurabile. A differenza di altre configurazioni di HA, puoi scegliere di promuovere un nodo replica specifico come origine in caso di failover.
- Dopo un failover, il provisioning delle nuove repliche viene eseguito in modo dichiarativo in base alla topologia.
- ProxySQL offre un vantaggio supplementare per il bilanciamento del carico in quanto indirizza in modo trasparente le richieste di lettura e scrittura ai nodi di replica e di origine appropriati in base ai criteri configurati.
Considerazioni
Questa architettura aumenta la responsabilità operativa e comporta costi aggiuntivi per l'hosting per i seguenti motivi:
- Sia Orchestrator che ProxySQL devono essere di cui è stato eseguito il deployment e che devono essere gestiti.
- Orchestrator ha bisogno di un database separato per la gestione dello stato.
- Sia Orchestrator che ProxySQL devono essere configurati per l'HA, quindi la configurazione e il deployment sono più complessi.
Inoltre, Orchestrator non supporta le repliche multi-source, non supporta tutti i tipi di replica parallela e non può essere combinato con software di clustering come Galera o Percona XtraDB. Per ulteriori informazioni sulle limitazioni attuali, consulta le domande frequenti su Orchestrator.
Passaggi successivi
- Scopri di più sulla configurazione dell'alta disponibilità di Cloud SQL.
- Scopri di più sulle opzioni di alta disponibilità che utilizzano i dischi permanenti regionali.
- Consulta la documentazione della Replica dei gruppi di MySQL.
- Scopri di più su Galera Cluster o sul correlato Percona XtraDB Cluster.
- Consulta la documentazione di Orchestrator.
- Scopri di più su ProxySQL.
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.