Architetture per l'alta disponibilità dei cluster MySQL su Compute Engine

Last reviewed 2024-02-21 UTC

Questo documento descrive diverse architetture che offrono alta disponibilità per i deployment di 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à riguarda la disponibilità dei cluster MySQL all'interno di una singola regione cloud.

Questo documento è destinato agli amministratori di database, ai Cloud Architect e ai tecnici DevOps che vogliono imparare ad aumentare l'affidabilità del livello dati di 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 permanente per gestire richieste o transazioni, il livello di persistenza dei dati deve essere disponibile per gestire correttamente le richieste di query o mutazioni sui dati. Se l'applicazione deve interagire con il livello dati per le richieste di servizio, 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 dell'architettura che offra un livello di disponibilità più elevato. Esistono diversi modi per ottenere l'alta disponibilità, ma in generale esegui il provisioning di un'infrastruttura ridondante, che puoi rendere rapidamente accessibile alla tua applicazione.

Questo documento tratta i seguenti argomenti:

  • Definisci i termini per comprendere meglio i concetti dei database ad alta disponibilità.
  • Aiuta a comprendere diverse opzioni per le topologie MySQL ad alta disponibilità.
  • Fornisci informazioni contestuali per capire meglio che cosa tenere in considerazione per ciascuna opzione.

Terminologia

Esistono diversi termini e concetti standard di settore che sono utili da comprendere per scopi che esulano dall'ambito di questo documento.

Replica. Il processo mediante il quale le transazioni di scrittura (INSERT, UPDATE o DELETE) vengono acquisite, registrate e quindi applicate in modo affidabile in modo seriale 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 di replica. Una copia online del nodo del database di origine. Le modifiche vengono replicate quasi sincrona nei nodi di replica dal nodo di origine. Puoi leggere dai nodi di replica con la consapevolezza che i dati potrebbero subire un leggero ritardo a causa del ritardo di replica.

Tempo di 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.

Tempo di attività. La percentuale di tempo in cui una risorsa funziona ed è in grado di inviare una risposta a una richiesta.

Rilevamento di errori. Il processo per identificare un guasto dell'infrastruttura.

Failover. Il processo per promuovere l'infrastruttura di backup o standby (in questo caso, il nodo di replica) per diventare l'infrastruttura principale. In altre parole, durante il failover, il nodo di replica diventa il nodo di origine.

RTO (Recovery Time Objective). La durata, in tempo reale trascorso, accettabile dal punto di vista dell'attività per il completamento del processo di failover del livello dati.

Di riserva. Il processo per reintegrare il nodo di origine precedente dopo che si è verificato 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 in una topologia, ad esempio i nodi di origine e di replica, non possono comunicare tra loro sulla rete.

Dividi la mente. Condizione che si verifica quando due nodi contemporaneamente contingono di essere il nodo di origine.

Gruppo di nodi. Un insieme di attività delle risorse di computing che forniscono un servizio. Per questo documento, il servizio rappresenta il livello di persistenza dei dati.

Nodo del testimone o del quorum. Una risorsa di computing separata che aiuta un gruppo di nodi a determinare cosa fare quando si verifica una condizione di suddivisione del cervello.

Elezione di una fonte o di un leader. Il processo mediante il quale un gruppo di nodi con conoscenza dei peer, inclusi i nodi di test, determina quale nodo deve essere il nodo di origine.

Gruppo di nodi. Un insieme di attività delle risorse di computing che forniscono un servizio. Per questo documento, il servizio rappresenta il livello di persistenza dei dati.

Hot standby. Un nodo che rappresenta una copia chiusa di un altro nodo di origine e può diventare il nuovo nodo di origine con tempi di inattività minimi.

Quando considerare un'architettura ad alta disponibilità

Le architetture ad alta disponibilità offrono una maggiore protezione contro i tempi di inattività a livello di dati. Comprendere la tua tolleranza ai tempi di inattività e i rispettivi compromessi delle varie architetture è fondamentale per scegliere l'opzione giusta per il tuo caso d'uso aziendale.

Utilizza una topologia ad alta disponibilità quando vuoi offrire un tempo di attività maggiore del livello dati per soddisfare i requisiti di affidabilità per carichi di lavoro e servizi. Per gli ambienti in cui è tollerato un certo tempo di inattività, la topologia ad alta disponibilità introduce costi e complessità inutili. Ad esempio, gli ambienti di sviluppo o test raramente hanno bisogno di una disponibilità elevata a livello di database.

Considera i tuoi requisiti per l'alta disponibilità

Il costo è un aspetto importante, perché l'infrastruttura di computing e i costi di archiviazione dovrebbero essere almeno raddoppiati per fornire alta disponibilità. Quando valuti le possibili opzioni di MySQL ad alta disponibilità, prendi in considerazione 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 azienda in caso di inattività 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%?
  • Quanto tempo è necessario per eseguire il failover? Qual è il tuo RTO?

Quanto segue contribuisce al tempo di recupero e deve essere preso in considerazione al momento di stabilire l'RTO:

  • Rilevamento dell'interruzione del servizio
  • Preparazione delle istanze di macchine virtuali secondarie (VM)
  • Failover dell'archiviazione
  • Tempo di ripristino del database
  • Tempo di ripristino dell'applicazione

Architetture ad alta disponibilità MySQL

Al livello più basilare, l'alta disponibilità nel livello dati è costituita da quanto segue:

  • Un meccanismo per identificare un errore del nodo di origine.
  • Un processo per eseguire un failover in cui il nodo di replica viene promosso a nodo di origine.
  • Un processo per modificare il routing delle query in modo che le richieste delle applicazioni raggiungano il nuovo nodo di origine.
  • Facoltativamente, un metodo per tornare alla topologia originale utilizzando nodi di origine e di replica.

Questo documento illustra le seguenti tre architetture ad alta disponibilità:

Oltre ai guasti dell'infrastruttura, ciascuna di queste architetture può aiutare a ridurre al minimo i tempi di inattività nell'improbabile caso di un'interruzione di zona. Puoi utilizzare queste architetture con le modifiche al DNS (Domain Name System) per fornire un'alta disponibilità in più regioni per evitare interruzioni del servizio a livello di regione, ma questo argomento non rientra nell'ambito di questo documento.

Alta disponibilità con dischi permanenti a livello di regione

L'alta disponibilità nel livello dati si basa sempre su un qualche tipo di replica dei dati. La replica più semplice è una replica che non devi gestire.

Con l'opzione di archiviazione disco permanente a livello di regione di Compute Engine, puoi eseguire il provisioning di un dispositivo di archiviazione a blocchi che fornisce la replica sincrona dei dati tra due zone di una regione. I dischi permanenti a livello di regione offrono un solido componente di base per implementare i servizi ad alta disponibilità in Compute Engine.

Il seguente diagramma illustra l'architettura dell'alta disponibilità con dischi permanenti a livello di regione.

Architettura per l'utilizzo di dischi permanenti a livello di regione per raggiungere l'alta disponibilità.

Se l'istanza VM del nodo di origine non è più disponibile a causa di un guasto dell'infrastruttura o di un'interruzione a livello di zona, puoi forzare il collegamento del Persistent Disk a livello di regione a un'istanza VM nella zona di backup nella stessa regione.

Per eseguire questa attività, devi eseguire una delle seguenti operazioni:

  • Avviare un'altra istanza VM nella zona di backup in cui è disponibile l'accesso al Persistent Disk a livello di regione condiviso.
  • Mantieni un'istanza VM hot standby nella zona di backup. Un'istanza VM in modalità hot standby è un'istanza VM in esecuzione identica all'istanza 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 associazione forzata viene completata in meno di un minuto, il che significa che è possibile ottenere un RTO misurato in minuti.

Se la tua azienda è in grado di tollerare il tempo di inattività 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 risulta ulteriormente complicato perché esistono diversi casi limite nel processo di failover e di fallback che devi prendere in considerazione. Per ulteriori informazioni su un'implementazione completamente automatica di questa architettura, consulta la pagina dedicata alla configurazione ad alta disponibilità di Cloud SQL.

Vantaggi

L'accesso all'alta disponibilità offre diversi vantaggi grazie all'utilizzo di dischi permanenti a livello di regione, grazie alle seguenti caratteristiche:

  • Questa architettura fornisce protezione simultanea contro diverse modalità di guasto: guasto dell'infrastruttura del server nella zona primaria, riduzione dell'archiviazione a blocchi a zona singola o interruzione dell'intera zona.
  • La replica a livello di applicazione o database non è necessaria perché i dischi permanenti a livello di regione forniscono la replica dei dati continua e sincrona a livello di blocco, completamente gestita da Google Cloud. Un Persistent Disk a livello di regione rileva automaticamente errori e rallentamenti, cambia la modalità di replica ed esegue il recupero dei dati replicati in una sola zona.
  • In caso di problemi di archiviazione in una zona principale, un Persistent Disk a livello di regione esegue automaticamente le letture dalla zona secondaria. Questa operazione può comportare un aumento della latenza di lettura, ma l'applicazione può continuare a funzionare senza alcuna azione manuale.

Considerazioni

I limiti di questa architettura sono correlati alla natura a regione singola di questa topologia e ad alcuni dei seguenti vincoli intrinseci dei dischi permanenti a livello di regione:

  • Il Persistent Disk a livello di regione può essere montato su un solo database. Anche se l'istanza VM del database in standby è in esecuzione, non può essere utilizzata per gestire le letture del database.
  • La tecnologia di base di questa architettura consente solo la replica tra zone nella stessa regione. Di conseguenza, il failover a livello di regione non è un'opzione disponibile se si utilizza esclusivamente questa architettura.
  • La velocità di scrittura del Persistent Disk a livello di regione è dimezzata rispetto ai dischi permanenti a livello di zona. Assicurati che i limiti di velocità effettiva rientrino nella tolleranza richiesta.
  • La latenza di scrittura del Persistent Disk a livello di regione è leggermente superiore a quella del Persistent Disk a livello di zona. Ti consigliamo di testare il 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 del Persistent Disk a livello di regione alla VM della zona in standby. L'operazione force-attach viene generalmente eseguita in meno di un minuto, quindi è necessario considerare questo tempo durante la valutazione dell'RTO.
  • La stima dell'RTO deve tenere conto del tempo necessario per il collegamento forzato del Persistent Disk a livello di regione e per il rilevamento del file system della VM del disco collegato a caldo.

Alta disponibilità con hot standby e nodo di testimonianza

Se vuoi un failover automatico, è necessaria un'architettura diversa. Un'opzione è eseguire il deployment di un gruppo di almeno due nodi di database, configurare la replica asincrona del database e avviare nodi di test per garantire che sia possibile raggiungere un quorum durante l'elezione dei nodi 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 testimone può essere una piccola macchina virtuale, fornisce un meccanismo a basso costo per garantire che la maggioranza del gruppo sia disponibile per l'elezione dei nodi di origine.

I nodi dei gruppi valutano continuamente lo stato degli altri nodi del gruppo. Gli indicatori consumati da questi controlli di stato a intervalli di pochi secondi sono chiamati battiti cardiaci, in quanto vengono utilizzati per valutare l'integrità degli altri nodi del gruppo. Una valutazione tempestiva dell'integrità del nodo di database è importante, perché un nodo di database di origine non integro deve essere identificato rapidamente, in modo da poter avviare un failover dell'hot standby.

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 possa essere avviato correttamente o continuare a essere eseguito. Affinché un gruppo di nodi raggiunga un quorum in un'elezione del nodo del database di origine, deve partecipare la maggior parte dei nodi del gruppo. Per evitare una condizione di divisione del cervello, il requisito di 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 è composta da (n+1)/2 nodi, dove n è il numero totale di nodi nel gruppo. Ad esempio, se un gruppo include tre nodi, devono essere operativi almeno due nodi per l'elezione dei nodi di origine. Se un gruppo include cinque nodi, sono necessari almeno tre nodi.

I gruppi vengono dimensionati con un numero dispari di nodi nel caso in cui sia presente una partizione di rete che impedisce la comunicazione tra i sottogruppi del gruppo di nodi. Se il gruppo è pari, c'è una maggiore probabilità che entrambi i sottogruppi possano averne meno della maggioranza. Se la dimensione del gruppo è dispari, è più probabile che uno dei sottogruppi possa avere la maggioranza o nessuno dei due gruppi ne abbia la maggioranza.

Il seguente diagramma confronta un gruppo di nodi integro con un gruppo di nodi con prestazioni ridotte.

Architettura che confronta un gruppo di nodi integro con un gruppo di nodi ridotto.

Il diagramma mostra due gruppi di nodi: un gruppo di nodi funzionali e un gruppo di nodi ridotto. Il gruppo di nodi completamente funzionante e integro ha tre membri. In questo stato, i nodi del database di origine e di replica forniscono lo scopo previsto. Il quorum necessario per questo gruppo di nodi è due nodi.

Il gruppo di nodi con prestazioni ridotte mostra lo stato in cui gli heartbeat 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 o 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.

A prescindere dalla causa, il risultato è che sia la replica che il test determinano che il nodo di origine non è più integro. A questo punto, la maggioranza del gruppo esegue un'elezione del nodo di origine, determina che il nodo hot standby deve diventare il nodo di origine e avvia un failover.

Il seguente diagramma mostra il flusso della transazione del database, della replica e dell'heartbeat nell'architettura del nodo test.

Architettura che utilizza l'hot standby e il nodo di testimonianza per raggiungere l'alta disponibilità.

Nel diagramma precedente, questa architettura ad alta disponibilità si basa sul nodo della replica a caldo in standby per avviare rapidamente l'elaborazione delle scritture di produzione dopo un failover. I meccanismi del failover, ad esempio la promozione dei nodi di origine, vengono eseguiti dai nodi di database del gruppo.

Per implementare questa architettura, prendi in considerazione i seguenti due progetti:

Vantaggi

L'architettura in modalità hot standby ha poche parti mobili, è facile da implementare e offre diversi vantaggi:

  • Con un solo nodo di analisi aggiuntivo a basso costo, viene fornito il failover completamente automatizzato.
  • Questa architettura può risolvere i guasti a lungo termine dell'infrastruttura con la stessa facilità degli errori temporanei (ad esempio a causa di un riavvio del sistema).
  • Con una latenza di replica associata, viene fornita una disponibilità ad alta disponibilità in più regioni.

Considerazioni

Il failover è automatico, ma rimangono le seguenti attività operative:

  • Sei tu a gestire la replica tra i nodi di origine e quelli di replica.
  • Sei tu a gestire i nodi di test.
  • Devi eseguire il deployment e gestire il routing delle connessioni utilizzando un bilanciatore del carico.
  • Se non vengono apportate modifiche alla logica dell'applicazione, che non rientrano nell'ambito di questo documento, non puoi indirizzare le letture al nodo di replica.

Alta disponibilità con Orchestrator e ProxySQL

Se combini i componenti open source, Orchestrator e ProxySQL, avrai un'architettura in grado di rilevare interruzioni e di eseguire automaticamente il failover del traffico da un nodo di origine interessato a una replica in stato integro appena promossa.

Inoltre, puoi instradare le query in modo trasparente ai nodi di lettura, lettura e scrittura appropriati per migliorare le prestazioni del livello dati in stato stabile.

Orchestrator è una soluzione di failover e di gestione della topologia di replica MySQL open source. Il software consente di rilevare, eseguire query e refactoring di topologie di replica complesse e offrire funzioni affidabili di rilevamento dei guasti, ripristino intelligente e promozione.

ProxySQL è un proxy di database open source, ad alte prestazioni e a disponibilità elevata per MySQL. ProxySQL scala a milioni di connessioni su centinaia di migliaia di server di backend.

Il seguente diagramma mostra l'architettura combinata di Orchestrator e ProxySQL.

Architettura che utilizza Orchestrator e ProxySQL per ottenere l'alta disponibilità.

In questa architettura, come illustrato nel diagramma precedente, il traffico legato al database viene instradato da un bilanciatore del carico interno a istanze ProxySQL ridondanti. Queste istanze instradano il traffico a un'istanza di database con funzionalità di scrittura o lettura in base alla configurazione di ProxySQL.

Orchestrator fornisce i seguenti passaggi per il rilevamento degli errori e il ripristino:

  1. Orchestrator determina che il nodo del database di origine non è disponibile.
  2. A tutti i nodi di replica viene eseguita una query per fornire una seconda opinione sullo stato del nodo di origine.
  3. Se le repliche forniscono una valutazione coerente che indica che l'origine non è disponibile, il failover procede.
  4. Come definito dalla topologia, il nodo promosso diventa il nuovo nodo di origine durante il failover.
  5. Quando il failover è completo, Orchestrator aiuta 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 aggiornate le repliche con qualsiasi scrittura instradata all'origine. Orchestrator verifica l'integrità dei database di origine e di replica inviando continuamente heartbeat. Lo stato dell'applicazione Orchestrator è mantenuto in un database Cloud SQL separato. Se sono necessarie modifiche alla topologia, Orchestrator può anche inviare comandi ai database.

ProxySQL instrada il traffico in modo appropriato ai nuovi nodi di origine e di replica quando il failover è completo. I servizi continuano a gestire il livello dati utilizzando l'indirizzo IP del bilanciatore del carico. L'indirizzo IP virtuale viene trasferito senza interruzioni dal nodo di origine precedente a quello nuovo.

Vantaggi

I componenti architetturali e l'automazione offrono i seguenti vantaggi:

  • Il software utilizzato in questa architettura offre varie funzionalità di osservabilità, tra cui grafici della topologia di replica e visibilità del traffico delle query.
  • ProxySQL e Orchestrator si coordinano per fornire promozione e failover automatici della replica.
  • Il criterio di promozione della replica è completamente configurabile. A differenza di altre configurazioni ad alta disponibilità, puoi scegliere di promuovere un nodo di replica specifico all'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 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 dovuti alle seguenti considerazioni:

  • È necessario eseguire il deployment e la manutenzione di Orchestrator e ProxySQL.
  • Orchestrator ha bisogno di un database separato per il mantenimento dello stato.
  • Sia Orchestrator che ProxySQL devono essere configurati per l'alta disponibilità, in modo da aumentare la configurazione e la complessità del deployment.

Inoltre, Orchestrator non supporta le repliche multi-origine, 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