Questo documento descrive diverse architetture che forniscono alta disponibilità (HA) per i deployment MySQL su Google Cloud. L'alta disponibilità è la misura della resilienza del sistema in risposta a un errore dell'infrastruttura sottostante. In questo documento, l'alta disponibilità si riferisce alla disponibilità dei cluster MySQL all'interno di una singola regione cloud.
Questo documento è rivolto ad amministratori di database, architetti cloud e ingegneri DevOps che vogliono imparare ad aumentare l'affidabilità del livello dati MySQL migliorando l'uptime complessivo del sistema. Questo documento è destinato a te se esegui MySQL su Compute Engine. Se utilizzi Cloud SQL per MySQL, questo documento non è destinato a te.
Per un sistema o un'applicazione che richiede uno stato persistente per gestire le richieste o le 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 dati per gestire le richieste, qualsiasi tempo di inattività nel livello dati impedisce all'applicazione di eseguire le attività necessarie.
A seconda degli obiettivi del livello di servizio (SLO) del sistema, potresti richiedere una topologia architetturale che fornisca un livello di disponibilità più elevato. Esiste più di un modo per ottenere l'alta disponibilità, ma in generale si esegue il provisioning di un'infrastruttura ridondante a cui è possibile accedere rapidamente dall'applicazione.
Questo documento tratta i seguenti argomenti:
- Definisci i termini per aiutarti a comprendere i concetti del database HA.
- Aiutarti a comprendere diverse opzioni per le topologie MySQL HA.
- Fornisci informazioni contestuali per aiutarti a capire cosa considerare in ogni opzione.
Terminologia
Esistono diversi termini e concetti standard del settore utili da comprendere per scopi che vanno oltre l'ambito di questo documento.
Replica. Il processo mediante il quale le transazioni di scrittura (INSERT, UPDATE o
DELETE) vengono acquisite, registrate e poi applicate in serie a tutti
i nodi del database nella topologia.
Replica sincrona. Un metodo di replica dei dati che garantisce la coerenza dei dati in tempo reale scrivendo contemporaneamente nei database primario e di replica.
Replica semi-sincrona. Un metodo di replica dei dati che garantisce un grado limitato di coerenza dei dati scrivendo contemporaneamente sia nel database principale sia in almeno un altro database di replica.
Replica asincrona. Un metodo di replica dei dati che consente un ritardo tra gli aggiornamenti principali e delle repliche, dando la priorità alle prestazioni rispetto alla coerenza immediata.
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 di replica. Una copia online del nodo del database di origine. Le modifiche vengono replicate in modo quasi sincrono nei nodi di replica dal nodo di origine. Puoi leggere dai nodi di replica sapendo 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 una transazione viene applicata alla replica e il momento in cui viene applicata al nodo di origine.
Uptime. La percentuale di tempo in cui una risorsa funziona ed è in grado di fornire una risposta a una richiesta.
Rilevamento errori. Il processo di identificazione del verificarsi di un errore dell'infrastruttura.
Failover. Il processo per promuovere l'infrastruttura di standby (in questo caso, il nodo di replica) a infrastruttura principale (il nodo di origine).
Recovery Time Objective (RTO). La durata, in tempo reale trascorso, accettabile dal punto di vista aziendale per la disattivazione del livello di dati fino al completamento della procedura di failover.
Recovery Point Objective (RPO). La durata, in tempo reale trascorso, accettabile dal punto di vista aziendale per la perdita di dati fino al completamento della procedura di failover.
Fallback. Il processo per reintegrare il nodo di origine precedente dopo un failover.
Riparazione automatica. La capacità di un sistema di risolvere i problemi senza interventi esterni da parte di un operatore umano.
Partizione di rete. Una condizione in cui due nodi in una topologia, ad esempio i nodi di origine e replica, non possono comunicare tra loro tramite la rete.
Cervello 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, il servizio è il livello di persistenza dei dati.
Nodo testimone o quorum. Una risorsa di calcolo separata che aiuta un gruppo di nodi a determinare cosa fare quando si verifica una condizione di split-brain.
Elezione dell'origine o del leader. Il processo mediante il quale un gruppo di nodi peer-aware, inclusi i nodi testimone, 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, il servizio è il livello di persistenza dei dati.
Hot standby. Un nodo che rappresenta una copia esatta di un altro nodo di origine e che può diventare il nuovo nodo di origine con tempi di inattività minimi.
Quando prendere in considerazione un'architettura HA
Le architetture ad alta disponibilità offrono una maggiore protezione contro i tempi di inattività del livello dati. Comprendere la tua tolleranza ai tempi di inattività e i rispettivi compromessi delle varie architetture è fondamentale per scegliere l'opzione più adatta al tuo caso d'uso aziendale.
Utilizza una topologia HA quando vuoi aumentare l'uptime del livello dati per soddisfare i requisiti di affidabilità per i tuoi carichi di lavoro e servizi. Per gli ambienti in cui è tollerata una certa quantità di tempi di inattività, una topologia HA introduce costi e complessità non necessari. Ad esempio, gli ambienti di sviluppo o di test raramente hanno bisogno di un'alta disponibilità del livello di database.
Considera i tuoi requisiti per l'alta disponibilità
Il costo è un aspetto importante da considerare, perché devi aspettarti che i costi dell'infrastruttura di calcolo e dello spazio di archiviazione almeno raddoppino per fornire l'alta disponibilità. È importante valutare attentamente questo costo rispetto al potenziale impatto finanziario del tempo di inattività. Quando valuti le possibili opzioni di alta disponibilità di MySQL, considera 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 e il tuo RPO?
I seguenti fattori contribuiscono al tempo di ripristino e devono essere presi in considerazione quando stabilisci RTO e RPO:
- Rilevamento dell'interruzione
- Disponibilità dell'istanza di macchina virtuale (VM) secondaria
- Tipo di replica e frequenza del backup
- Failover dello spazio di archiviazione
- Tempo di ripristino del database
- Tempo di recupero dell'applicazione
Architetture HA di MySQL
Al livello più elementare, l'alta disponibilità nel livello dati consiste in quanto segue:
- Un meccanismo per identificare che si è verificato un errore del nodo di origine.
- Una procedura per eseguire un failover in cui il nodo di replica viene promosso a nodo di origine.
- Una procedura per modificare il routing delle query in modo che le richieste dell'applicazione raggiungano il nuovo nodo di origine.
- (Facoltativo) Un metodo per eseguire il failback alla topologia originale utilizzando i nodi di origine e replica.
Questo documento descrive le seguenti tre architetture HA:
Oltre al guasto dell'infrastruttura, ciascuna di queste architetture può contribuire a ridurre al minimo i tempi di inattività nell'improbabile evento di un'interruzione a livello di zona. Utilizzi queste architetture con modifiche al Domain Name System (DNS) per fornire HA multiregionale per proteggerti da interruzioni del servizio a livello regionale, ma questo documento tratta interruzioni a livello di zona.
HA con dischi permanenti regionali
L'alta disponibilità nel livello 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 forniscono un solido componente di base per l'implementazione di servizi HA in Compute Engine.
Il seguente diagramma illustra l'architettura di HA con dischi permanenti regionali.
Se l'istanza VM del nodo di origine non è più disponibile a causa di un errore dell'infrastruttura o di un'interruzione a livello di zona, puoi forzare l'associazione del Persistent Disk regionale a un'istanza VM nella zona di backup della stessa regione.
Per eseguire questa attività, devi effettuare 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 di standby attivo è un'istanza VM in esecuzione identica a quella che stai utilizzando. Dopo aver collegato il Persistent Disk regionale, puoi avviare il motore del database.
Se l'interruzione del servizio di dati viene identificata tempestivamente, l'operazione di forzatura dell'allegato viene completata in genere in meno di un minuto, il che significa che è possibile ottenere un RTO misurato in minuti, con un RPO pari a zero.
Se la tua attività può tollerare i tempi di inattività aggiuntivi necessari per rilevare e comunicare un'interruzione e per eseguire manualmente il failover, allora non è necessario automatizzare la procedura.
Se la tolleranza RTO è inferiore, puoi automatizzare il processo di rilevamento e failover. Se automatizzi questa architettura, il sistema diventa ancora più complesso perché ci sono diversi casi limite nel processo di failover e fallback che devi prendere in considerazione. Per ulteriori informazioni su un'implementazione completamente automatizzata di questa architettura, consulta la configurazione dell'alta disponibilità di Cloud SQL.
Vantaggi
Il raggiungimento dell'alta disponibilità utilizzando dischi permanenti regionali offre diversi vantaggi grazie alle seguenti funzionalità:
Questa architettura fornisce protezione simultanea contro diverse modalità di errore: errore dell'infrastruttura di zona del server di origine, degrado dell'archiviazione a blocchi a zona singola o interruzione completa della zona.
La replica del livello di applicazione o di database non è necessaria perché i dischi permanenti regionali forniscono una replica dei dati a livello di blocco continua e sincrona, completamente gestita 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 primaria, un Persistent Diske regionale esegue automaticamente le letture dalla zona secondaria. Questa operazione può comportare una maggiore latenza di lettura, ma la tua applicazione può continuare a funzionare senza alcuna azione manuale.
Considerazioni
I limiti di questa architettura sono correlati alla natura a singola regione di questa topologia e ad alcuni dei seguenti vincoli intrinseci dei dischi permanenti regionali:
- Il Persistent Disk regionale può essere montato solo su un database. Anche se l'istanza VM del database di standby è in esecuzione, non può essere utilizzata per gestire le letture del database. Tuttavia, con Google Cloud Hyperdisk bilanciato ad alta affidabilità in modalità multi-writer, più istanze possono leggere e scrivere sullo stesso disco. Per saperne di più su Hyperdisk, consulta Informazioni su Hyperdisk.
- La tecnologia di base alla base di questa architettura consente solo la replica tra le zone della stessa regione. Di conseguenza, il failover regionale non è un'opzione quando viene utilizzata solo questa architettura.
- La velocità effettiva di 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 zonale. 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 cutover risultante, devi forzare il collegamento delPersistent Diske regionale alla VM della zona di standby. L'operazione di forzatura dell'allegato viene in genere eseguita in meno di un minuto, quindi devi tenere conto di questo tempo quando valuti il tuo RTO.
- La stima dell'RTO deve tenere conto del tempo necessario per l'attacco forzato del Persistent Disk regionale e per il rilevamento del disco collegato a caldo da parte del file system della VM.
HA con hot standby e nodo di controllo
Se vuoi un failover automatizzato, è necessaria un'architettura diversa. Un'opzione è distribuire un gruppo di almeno due nodi di database, configurare la replica asincrona del database e avviare i nodi di testimonianza per garantire che sia possibile raggiungere un quorum durante l'elezione del nodo di origine.
Il nodo del database di origine elabora le transazioni di scrittura e gestisce le query di lettura. Il processo di replica del database trasmette le modifiche al nodo di replica hot standby online.
Poiché il nodo di controllo può essere una piccola macchina virtuale, fornisce un meccanismo a basso costo per garantire che una maggioranza del gruppo sia disponibile per l'elezione di un nodo di origine.
I nodi del gruppo valutano continuamente lo stato degli altri nodi del gruppo. I segnali che questi controlli dello stato consumano ogni pochi secondi vengono chiamati heartbeat perché vengono utilizzati per valutare l'integrità degli altri nodi del gruppo. Una valutazione tempestiva dell'integrità del nodo del database è importante perché un nodo del database di origine non integro deve essere identificato rapidamente in modo da poter avviare un failover dello standby attivo.
Il quorum del gruppo di nodi è determinato dal numero di elementi di voto che devono far parte dell'appartenenza attiva al cluster affinché il cluster venga avviato correttamente o continui a essere eseguito. Affinché un gruppo di nodi raggiunga il quorum in un'elezione del nodo del database di origine, deve partecipare la maggior parte dei nodi del gruppo. Per evitare una condizione di split brain, il requisito della maggioranza garantisce che, in caso di partizione di rete, due gruppi di voto non possano avere contemporaneamente un numero sufficiente di nodi per votare.
La maggioranza di un gruppo è costituita da (n+1)/2 nodi, dove n è il numero totale di nodi nel gruppo. Ad esempio, se un gruppo contiene tre nodi, almeno due nodi devono essere operativi per l'elezione di un nodo di origine. Se in un gruppo ci sono cinque nodi, ne sono necessari almeno tre.
I gruppi hanno un numero dispari di nodi nel caso in cui ci sia una partizione di rete che impedisce la comunicazione tra i sottogruppi del gruppo di nodi. Se il gruppo è pari, è più probabile che entrambi i sottogruppi abbiano meno della maggioranza. Se la dimensione del gruppo è dispari, è più probabile che uno dei sottogruppi abbia la maggioranza o che nessuno dei due gruppi abbia la maggioranza.
Il seguente diagramma confronta un gruppo di nodi integro con un gruppo di nodi degradato.
Il diagramma mostra due gruppi di nodi: un gruppo di nodi funzionale e un gruppo di nodi degradato. Il gruppo di nodi completamente funzionale e integro ha tre membri del gruppo. In questo stato, i nodi del database di origine e di replica svolgono la loro funzione prevista. Il quorum necessario per questo gruppo di nodi è di due nodi.
Il gruppo di nodi degradato mostra lo stato in cui i battiti del nodo di origine non vengono più inviati a causa di un errore dell'infrastruttura. Questo stato potrebbe essere il risultato di un errore 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 che il testimone determinano che il nodo di origine non è più integro. A questo punto, la maggioranza del gruppo esegue una selezione del nodo di origine, determina che il nodo di standby attivo deve diventare il nodo di origine e avvia un failover.
Il seguente diagramma mostra il flusso di transazioni, repliche e heartbeat del database nell'architettura del nodo di controllo.
Nel diagramma precedente, questa architettura HA si basa sul nodo di replica hot standby per iniziare rapidamente a elaborare le scritture di produzione in caso di failover. Il meccanismo di failover, ad esempio la promozione del nodo di origine, viene eseguito dai nodi del database nel gruppo.
Per implementare questa architettura, considera i seguenti due progetti:
- MySQL Group Replication è un plug-in open source per MySQL che facilita la creazione di topologie HA.
- Galera Cluster e Percona XtraDB Cluster sono altre opzioni open source che possono fornire alta disponibilità.
Vantaggi
L'architettura hot standby ha poche parti mobili, è semplice da implementare e offre diversi vantaggi:
- Con un solo nodo di testimonianza aggiuntivo a basso costo, viene fornito il failover completamente automatizzato.
- Questa architettura può risolvere efficacemente i guasti dell'infrastruttura a lungo termine e quelli temporanei (ad esempio, a causa del riavvio del sistema).
- Viene fornita l'alta disponibilità multiregionale con una latenza di replica associata.
Considerazioni
Il failover è automatico, tuttavia rimangono le seguenti attività operative:
- Gestisci la replica tra i nodi di origine e di replica.
- Gestisci i nodi testimone.
- Devi eseguire il deployment e gestire il routing della connessione 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 di 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 integra appena promossa.
Inoltre, puoi indirizzare in modo trasparente le query ai nodi di lettura o di lettura e scrittura appropriati per migliorare il rendimento del livello di dati in stato stazionario.
Orchestrator è un gestore di topologie di replica MySQL open source e una soluzione di failover. Il software consente di rilevare, interrogare e refactoring di topologie di replica complesse e fornisce rilevamento affidabile degli errori, ripristino intelligente e promozione.
ProxySQL è un proxy open source, ad alte prestazioni e ad alta disponibilità per MySQL che riconosce il protocollo di database. ProxySQL è scalabile 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 nel 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 in grado di scrivere o leggere in base alla configurazione di ProxySQL.
Orchestrator fornisce i seguenti passaggi di rilevamento e ripristino degli errori:
- Orchestrator determina che il nodo del database di origine non è disponibile.
- Viene eseguita una query su tutti i nodi di replica per fornire un secondo parere sullo stato del nodo di origine.
- Se le repliche forniscono una valutazione coerente secondo cui 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 a garantire 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 tutte le scritture indirizzate all'origine. Orchestrator controlla lo stato dei database di origine e di replica 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 indirizza il traffico in modo appropriato ai nuovi nodi di origine e di replica al termine del failover. I servizi continuano ad accedere al livello 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 architetturali 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 automatica della replica e il failover.
- Il criterio di promozione della replica è completamente configurabile. A differenza di altre configurazioni HA, puoi scegliere di promuovere un nodo di replica specifico a origine in caso di failover.
- Dopo un failover, vengono eseguito il provisioning di nuove repliche in modo dichiarativo in base alla topologia.
- ProxySQL offre un vantaggio aggiuntivo di bilanciamento del carico in quanto instrada 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 di hosting aggiuntivi a causa delle seguenti considerazioni:
- Orchestrator e ProxySQL devono essere implementati e gestiti.
- Orchestrator ha bisogno di un database separato per mantenere lo stato.
- Sia Orchestrator che ProxySQL devono essere configurati per l'alta disponibilità, pertanto la configurazione e l'implementazione sono più complesse.
Inoltre, Orchestrator non supporta le repliche multiorigine, 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 di Orchestrator.
Passaggi successivi
- Scopri di più sulla configurazione dell'alta disponibilità di Cloud SQL.
- Scopri di più sulle opzioni di alta disponibilità utilizzando dischi permanenti regionali.
- Consulta la documentazione MySQL Group Replication.
- Scopri di più su Galera Cluster o sul relativo Percona XtraDB Cluster.
- Consulta la documentazione di Orchestrator.
- Scopri di più su ProxySQL.
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.