In questa serie di blog in tre parti, spiegheremo i dettagli e le funzionalità di un framework ad alta disponibilità (HA) per l'hosting MySQL utilizzando la replica semisincrona MySQL e lo stack Corosync plus Pacemaker. Nella parte I, ti guideremo attraverso le basi dell'alta disponibilità, i componenti di un framework HA e poi ti presenteremo il framework HA per MySQL.
Cos'è l'alta disponibilità?
La disponibilità di un sistema informatico è la percentuale di tempo in cui i suoi servizi sono attivi durante un periodo di tempo. È generalmente espresso come una serie di 9. Ad esempio, la tabella seguente mostra la disponibilità e il corrispondente tempo di inattività misurato in un anno.
| % disponibilità | Tempo di inattività all'anno |
| 90% ("uno 9 ") | 36,53 giorni |
| 99% ("due 9 ") | 3,65 giorni |
| 99,9% ("tre 9 ") | 8,77 ore |
| 99,99% ("quattro 9 ") | 52,60 minuti |
| 99,999% ("cinque 9 ") | 5,26 minuti |
| 99,9999% ("sei 9 ") | 31,56 secondi |
Il significato di High Availability varia a seconda dei requisiti della tua applicazione e della tua attività. Ad esempio, se non puoi permetterti un tempo di inattività di più di pochi minuti all'anno nel tuo servizio, diciamo che il servizio deve avere un'elevata disponibilità del 99,999%.
Componenti di un framework HA
L'essenza dell'essere altamente disponibili è la capacità di recuperare istantaneamente da guasti che possono verificarsi in qualsiasi parte di un sistema. Ci sono quattro componenti altamente essenziali in qualsiasi framework HA che devono lavorare insieme in modo automatizzato per consentire questa recuperabilità. Esaminiamo questi componenti in dettaglio:
1. Ridondanza nell'infrastruttura e nei dati
Affinché un servizio sia altamente disponibile, dobbiamo garantire che vi sia una ridondanza nell'hosting dell'infrastruttura, nonché una ridondanza aggiornata copia dei dati che il servizio utilizza o fornisce. Funziona come un servizio di standby pronto a subentrare nel caso in cui il primario sia interessato da errori.
2. Meccanismo di rilevamento e correzione dei guasti
È estremamente importante rilevare immediatamente eventuali guasti in qualsiasi parte del sistema primario che potrebbero influire sulla sua disponibilità. Ciò consentirà al framework di intraprendere azioni correttive sullo stesso sistema principale o di eseguire il failover dei servizi su un sistema in standby.
3. Meccanismo di failover
Questo componente gestisce la responsabilità del failover dei servizi sull'infrastruttura di standby. Tieni presente che nel caso in cui siano disponibili più sistemi ridondanti, questo componente del meccanismo di failover deve identificare il sistema più adatto tra quelli e promuoverlo come servizio principale.
4. Meccanismo di reindirizzamento dell'applicazione/utente
Una volta che i sistemi di standby hanno assunto il ruolo di primario, questo componente assicura che tutte le connessioni dell'applicazione e dell'utente inizino a verificarsi nel nuovo primario.
Spiegazione di MySQL High Availability Framework - Parte IFai clic per twittare
Il Framework HA per MySQL
Sulla base del modello sopra, utilizziamo il seguente framework HA per il nostro hosting MySQL su ScaleGrid:
- Una configurazione master-slave a 3 nodi che utilizza la replica semisincrona MySQL per fornire infrastruttura e ridondanza dei dati.
- Lo stack Corosync più Pacemaker per fornire il meccanismo di rilevamento, correzione e failover degli errori.
- Una mappatura DNS o un componente IP virtuale per fornire il meccanismo di reindirizzamento dell'applicazione e dell'utente.
Controlla il diagramma seguente per visualizzare lo stack software di questa architettura:
Esaminiamo la funzionalità di alcuni dei componenti chiave di questo framework.
-
Corosinc
Corosync fornisce un framework di comunicazione per i nodi con un affidabile scambio di messaggi tra di loro. Forma un anello di nodi del cluster e tiene traccia dei nodi che si uniscono e lasciano il cluster tramite l'appartenenza al cluster. Corosync lavora a stretto contatto con Pacemaker per comunicare la disponibilità del nodo in modo che Pacemaker possa prendere le decisioni appropriate.
-
Pacemaker
Noto anche come Cluster Resource Manager (CRM), Pacemaker garantisce l'elevata disponibilità per MySQL in esecuzione sul cluster e rileva e gestisce gli errori a livello di nodo interfacciandosi con Corosync. Rileva e gestisce anche gli errori di MySQL interfacciandosi con il Resource Agent (RA). Pacemaker configura e gestisce la risorsa MySQL attraverso operazioni di avvio, arresto, monitoraggio, promozione e retrocessione.
-
Agente di risorse
Il Resource Agent funge da interfaccia tra MySQL e Pacemaker. Implementa le operazioni di avvio, arresto, promozione, retrocessione e monitoraggio richiamate dal pacemaker. Esiste un Resource Agent completamente funzionale chiamato Percona Replication Manager (PRM) per MySQL implementato da Percona. Questo è stato migliorato da ScaleGrid ed è disponibile sulla nostra pagina GitHub.
-
Componente mappatura DNS
Il Resource Agent, al completamento di un failover riuscito, invoca questo componente che aggiorna i record DNS del server MySQL master con l'indirizzo IP del nuovo master. Si noti che i client utilizzano sempre un nome DNS master per connettersi al server MySQL e, gestendo la mappatura di questo nome DNS sull'indirizzo IP del master corrente, possiamo garantire che i client non debbano modificare le stringhe di connessione o le proprietà quando c'è un failover.
Nella parte II di questa serie di blog, imparerai a conoscere il componente critico della ridondanza dei dati che si ottiene utilizzando la replica semisincrona di MySQL. Approfondiremo anche i dettagli e le configurazioni della replica semisincrona che utilizziamo per ottenere il nostro supporto per l'alta disponibilità e, infine, esamineremo vari scenari di errore nella Parte III e il modo in cui il framework risponde e si riprende da queste condizioni.
