Scelta della topologia HA
Esistono vari modi per mantenere la disponibilità elevata con i database. Puoi utilizzare IP virtuali (VRRP) per gestire la disponibilità degli host, puoi utilizzare gestori di risorse come Zookeeper ed Etcd per (ri)configurare le tue applicazioni o utilizzare bilanciatori di carico/proxy per distribuire il carico di lavoro su tutti gli host disponibili.
Gli IP virtuali necessitano di un'applicazione per gestirli (MHA, Orchestrator), di alcuni script (Keepalived, Pacemaker/Corosync) o di un tecnico per eseguire il failover manuale e il processo decisionale può diventare complesso. Il failover dell'IP virtuale è un processo semplice e diretto che rimuove l'indirizzo IP da un host, assegnalo a un altro e utilizza arping per inviare una risposta ARP gratuita. In teoria un IP virtuale può essere spostato in un secondo, ma ci vorranno alcuni secondi prima che l'applicazione di gestione del failover sia sicura che l'host abbia fallito e agisca di conseguenza. In realtà questo dovrebbe essere compreso tra 10 e 30 secondi. Un'altra limitazione degli IP virtuali è che alcuni provider cloud non consentono di gestire i propri IP virtuali o di assegnarli affatto. Ad esempio, Google non ti consente di farlo sui loro nodi di calcolo.
I gestori delle risorse come Zookeeper ed Etcd possono monitorare i tuoi database e (ri)configurare le tue applicazioni una volta che un host si guasta o uno slave viene promosso a master. In generale questa è una buona idea, ma implementare i tuoi controlli con Zookeeper ed Etcd è un compito complesso.
Un servizio di bilanciamento del carico o un proxy si posizionerà tra l'applicazione e l'host del database e funzionerà in modo trasparente come se il client si connettesse direttamente all'host del database. Proprio come con l'IP virtuale e i gestori di risorse, anche i sistemi di bilanciamento del carico e i proxy devono monitorare gli host e reindirizzare il traffico se un host è inattivo. ClusterControl supporta due proxy:HAProxy e ProxySQL ed entrambi sono supportati per la replica MySQL master-slave e il cluster Galera. HAProxy e ProxySQL hanno entrambi i propri casi d'uso, li descriveremo anche in questo post.
Perché hai bisogno di un bilanciatore di carico?
In teoria non hai bisogno di un bilanciatore di carico ma in pratica ne preferirai uno. Ti spieghiamo perché.
Se hai configurato IP virtuali, tutto ciò che devi fare è indirizzare la tua applicazione all'indirizzo IP (virtuale) corretto e tutto dovrebbe andare bene per quanto riguarda la connessione. Ma supponiamo che tu abbia ridimensionato il numero di repliche di lettura, potresti voler fornire IP virtuali anche per ciascuna di queste repliche di lettura per motivi di manutenzione o disponibilità. Questo potrebbe diventare un pool molto ampio di IP virtuali che devi gestire. Se una di queste repliche di lettura ha avuto un errore, è necessario riassegnare l'IP virtuale a un altro host, altrimenti l'applicazione si connetterà a un host inattivo o, nel peggiore dei casi, a un server in ritardo con dati non aggiornati. È quindi necessario mantenere lo stato di replica all'applicazione che gestisce gli IP virtuali.
Anche per Galera c'è una sfida simile:in teoria puoi aggiungere tutti gli host che vuoi alla configurazione della tua applicazione e sceglierne uno a caso. Lo stesso problema si verifica quando questo host è inattivo:potresti finire per connetterti a un host non disponibile. Inoltre, l'utilizzo di tutti gli host sia per le letture che per le scritture potrebbe anche causare rollback a causa del blocco ottimistico in Galera. Se due connessioni tentano di scrivere sulla stessa riga contemporaneamente, una di esse riceverà un rollback. Nel caso in cui il carico di lavoro abbia tali aggiornamenti simultanei, si consiglia di utilizzare solo un nodo in Galera su cui scrivere. Quindi vuoi un manager che tenga traccia dello stato interno del tuo cluster di database.
Sia HAProxy che ProxySQL ti offriranno la funzionalità per monitorare gli host del database MySQL/MariaDB e mantenere lo stato del tuo cluster e della sua topologia. Per le impostazioni di replica, nel caso in cui una replica slave non sia attiva, sia HAProxy che ProxySQL possono ridistribuire le connessioni a un altro host. Ma se un master di replica è inattivo, HAProxy negherà la connessione e ProxySQL restituirà un errore corretto al client. Per le configurazioni di Galera, entrambi i sistemi di bilanciamento del carico possono eleggere un nodo master dal cluster Galera e inviare le operazioni di scrittura solo a quel nodo specifico.
A prima vista HAProxy e ProxySQL possono sembrare soluzioni simili, ma differiscono molto nelle funzionalità e nel modo in cui distribuiscono connessioni e query. HAProxy supporta una serie di algoritmi di bilanciamento come connessioni minime, sorgente, random e round robin mentre ProxySQL distribuisce le connessioni utilizzando l'algoritmo round robin basato sul peso (peso uguale significa distribuzione uguale). Poiché ProxySQL è un proxy intelligente, è a conoscenza del database ed è anche in grado di analizzare le tue query. ProxySQL è in grado di eseguire la suddivisione in lettura/scrittura in base a regole di query in cui è possibile inoltrare le query agli slave o master designati nel cluster. ProxySQL include funzionalità aggiuntive come la riscrittura delle query, la memorizzazione nella cache e il firewall delle query con generazione di statistiche approfondite in tempo reale sul carico di lavoro.
Dovrebbero essere sufficienti informazioni di base su questo argomento, quindi vediamo come distribuire sia i bilanciatori di carico per la replica MySQL che le topologie Galera.
Distribuzione di HAProxy
Utilizzare ClusterControl per distribuire HAProxy su un cluster Galera è facile:vai al cluster pertinente e seleziona "Aggiungi Load Balancer":
E sarai in grado di distribuire un'istanza HAProxy aggiungendo l'indirizzo host e selezionando le istanze del server che desideri includere nella configurazione:
Per impostazione predefinita, l'istanza HAProxy sarà configurata per inviare connessioni alle istanze del server che ricevono il minor numero di connessioni, ma è possibile modificare tale politica in round robin o source.
Nelle impostazioni avanzate puoi impostare timeout, numero massimo di connessioni e persino proteggere il proxy inserendo nella whitelist un intervallo IP per le connessioni.
Nella scheda nodi di quel cluster, apparirà il nodo HAProxy:
Ora il tuo cluster Galera è disponibile anche tramite il nodo HAProxy appena distribuito sulla porta 3307. Non dimenticare di CONCEDERE l'accesso alla tua applicazione dall'IP HAProxy, poiché ora il traffico arriverà dal proxy anziché dagli host dell'applicazione. Inoltre, ricorda di puntare la connessione dell'applicazione al nodo HAProxy.
Supponiamo ora che un'istanza del server si interrompa, HAProxy lo noterà entro pochi secondi e interromperà l'invio del traffico a questa istanza:
Gli altri due nodi stanno ancora bene e continueranno a ricevere traffico. Ciò mantiene il cluster altamente disponibile senza che il client si accorga della differenza.
Distribuzione di un nodo HAProxy secondario
Ora che abbiamo spostato la responsabilità di mantenere l'elevata disponibilità sulle connessioni del database dal client ad HAProxy, cosa succede se il nodo proxy si interrompe? La risposta è creare un'altra istanza HAProxy e utilizzare un IP virtuale controllato da Keepalived come mostrato in questo diagramma:
Il vantaggio rispetto all'utilizzo di IP virtuali sui nodi del database è che la logica per MySQL è a livello di proxy e il failover per i proxy è semplice.
Quindi distribuiamo un nodo HAProxy secondario:
Dopo aver distribuito un nodo HAProxy secondario, è necessario aggiungere Keepalived:
E dopo che Keepalived è stato aggiunto, la panoramica dei tuoi nodi sarà simile a questa:
Quindi ora, invece di puntare le connessioni dell'applicazione direttamente al nodo HAProxy, devi invece puntarle all'IP virtuale.
Nell'esempio qui, abbiamo utilizzato host separati su cui eseguire HAProxy, ma è possibile aggiungerli facilmente anche alle istanze del server esistenti. HAProxy non comporta molto sovraccarico, anche se dovresti tenere presente che in caso di guasto del server, perderai sia il nodo del database che il proxy.
Distribuzione di ProxySQL
La distribuzione di ProxySQL al cluster avviene in modo simile a HAProxy:"Aggiungi Load Balancer" nell'elenco dei cluster nella scheda ProxySQL.
Nella procedura guidata di distribuzione, specificare dove verrà installato ProxySQL, l'utente/password di amministrazione, l'utente/password di monitoraggio per connettersi ai backend MySQL. Da ClusterControl è possibile creare un nuovo utente da utilizzare dall'applicazione (l'utente verrà creato sia su MySQL che su ProxySQL) o utilizzare gli utenti del database esistenti (l'utente verrà creato solo su ProxySQL). Imposta se stai utilizzando transazioni implicite o meno. Fondamentalmente, se non usi SET autocommit=0 per creare una nuova transazione, ClusterControl configurerà la suddivisione in lettura/scrittura.
Dopo che ProxySQL è stato distribuito, sarà disponibile nella scheda Nodi:
L'apertura della panoramica del nodo ProxySQL ti presenterà l'interfaccia di monitoraggio e gestione di ProxySQL, quindi non c'è più motivo di accedere a ProxySQL sul nodo. ClusterControl copre la maggior parte delle statistiche importanti di ProxySQL come l'utilizzo della memoria, la cache delle query, il processore di query e così via, nonché altre metriche come i gruppi host, i server back-end, i risultati delle regole di query, le query principali e le variabili ProxySQL. Nell'aspetto di gestione di ProxySQL, puoi gestire le regole di query, i server back-end, gli utenti, la configurazione e lo scheduler direttamente dall'interfaccia utente.
Dai un'occhiata alla nostra pagina del tutorial su ProxySQL che copre ampiamente come eseguire il bilanciamento del carico del database per MySQL e MariaDB con ProxySQL.
Distribuzione di Garbd
Galera implementa un algoritmo basato sul quorum per selezionare un componente primario attraverso il quale impone la coerenza. Il componente principale deve avere la maggioranza dei voti (50% + 1 nodo), quindi in un sistema a 2 nodi non ci sarebbe la maggioranza con conseguente divisione del cervello. Fortunatamente, è possibile aggiungere un garbd (Galera Arbitrator Daemon), che è un demone stateless leggero che può fungere da nodo dispari. Il vantaggio aggiuntivo dell'aggiunta di Galera Arbitrator è che ora puoi fare solo con due nodi nel tuo cluster.
Se ClusterControl rileva che il tuo cluster Galera è costituito da un numero pari di nodi, ClusterControl ti darà l'avviso/consiglio di estendere il cluster a un numero dispari di nodi:
Scegli saggiamente l'host su cui distribuire garbd, poiché riceverà tutti i dati replicati. Assicurati che la rete sia in grado di gestire il traffico e sia sufficientemente sicura. Puoi scegliere uno degli host HAProxy o ProxySQL su cui distribuire garbd, come nell'esempio seguente:
Tieni presente che a partire da ClusterControl 1.5.1, garbd non può essere installato sullo stesso host di ClusterControl a causa del rischio di conflitti di pacchetti.
Dopo aver installato garbd, lo vedrai apparire accanto ai tuoi due nodi Galera:
Pensieri finali
Ti abbiamo mostrato come rendere più robuste le configurazioni del tuo cluster MySQL master-slave e Galera e mantenere un'elevata disponibilità utilizzando HAProxy e ProxySQL. Inoltre garbd è un bel demone che può salvare il terzo nodo in più nel tuo cluster Galera.
Questo finalizza il lato di distribuzione di ClusterControl. Nel prossimo blog ti mostreremo come integrare ClusterControl all'interno della tua organizzazione utilizzando gruppi e assegnando determinati ruoli agli utenti.
