In SitiMobil utilizziamo il database MySQL come principale archivio di dati permanenti. Abbiamo diversi cluster di database per vari servizi e scopi.

La disponibilità costante del master è un indicatore critico della funzionalità dell'intero sistema e delle sue singole parti. Il ripristino automatico del cluster in caso di guasto del master riduce notevolmente il tempo di risposta agli incidenti e il tempo di inattività del sistema. In questo articolo esaminerò lo schema di alta disponibilità (HA) del cluster MySQL basato su MySQL Orchestrator e indirizzi IP virtuali (VIP).

Soluzione HA basata su VIP

Inizierò con una breve descrizione di come è strutturato il nostro sistema di archiviazione dei dati.

Utilizziamo uno schema di replica classico con un master disponibile per la scrittura e molteplici repliche che vengono utilizzate solo per lettura. Il cluster può contenere un master intermedio, un nodo che è sia una replica sia un master per altri. I clienti accedono alle repliche tramite HAProxy, il che consente di distribuire equamente il carico e di scalare facilmente. L'uso di HAProxy è dovuto a motivi storici, e attualmente siamo in fase di migrazione a ProxySQL.

La replica avviene in modalità semi-sincrona sulla base di GTID. Questo significa che almeno una replica deve registrare una transazione nel log prima che sia considerata riuscita. Questa modalità di replica garantisce un equilibrio ottimale tra prestazioni e integrità dei dati in caso di guasto del nodo principale. In generale, tutte le modifiche vengono trasferite dal master alle repliche tramite Row Based Replication (RBR), ma alcuni nodi possono avere mixed binlog format.

L'orchestratore aggiorna periodicamente lo stato della topologia del cluster, analizza le informazioni raccolte e, in caso di problemi, può avviare la procedura di ripristino automatico. La responsabilità della procedura ricade sullo sviluppatore, poiché può essere implementata in vari modi: utilizzando VIP, DNS, servizi di discovery delle risorse (service discovery) o meccanismi custom.

Uno dei modi semplici per ripristinare il master in caso di guasto è l'utilizzo di indirizzi VIP galleggianti.

Cosa è necessario sapere su questa soluzione prima di procedere:

• Il VIP è un indirizzo IP che non è legato a un'interfaccia di rete fisica specifica. In caso di guasto di un nodo o durante lavori programmati, possiamo trasferire il VIP su un'altra risorsa con un tempo di inattività minimo.
• Il rilascio e l'assegnazione di un indirizzo IP virtuale sono operazioni economiche e rapide.
• Per lavorare con il VIP è necessaria l'accesso al server tramite SSH, oppure l'uso di utilità speciali, per esempio, keepalived.

Esaminiamo i possibili problemi con il nostro master e immaginiamo come dovrebbe funzionare il meccanismo di ripristino automatico.

È stata persa la connettività di rete con il master, oppure si è verificato un problema a livello di "hardware" e il server è inaccessibile.

1. L'orchestratore aggiorna la topologia del cluster, ogni replica segnala l'indisponibilità del master. L'orchestratore avvia il processo di selezione di una replica adatta al ruolo di nuovo master e inizia il ripristino.
2. Stiamo tentando di rimuovere il VIP dal vecchio master — senza successo.
3. La replica si sta spostando nel ruolo di master. La topologia viene ricostruita.
4. Aggiungiamo una nuova interfaccia di rete con VIP. Poiché non siamo riusciti a rimuovere il VIP, in background avviamo un'invio periodica di richieste gratuitous ARP. Questo tipo di richiesta/risposta consente di aggiornare sui switch connessi la tabella di corrispondenza degli indirizzi IP e MAC, informando così del trasferimento del nostro VIP. Ciò minimizza la probabilità di split brain quando il vecchio master ritorna.
5. Tutte le nuove connessioni vengono immediatamente reindirizzate al nuovo master. Le vecchie connessioni terminano con un errore, vengono effettuate nuove chiamate al database a livello di applicazione.

Il server funziona normalmente, si è verificato un guasto a livello di DBMS.

L'algoritmo è simile al caso precedente: aggiornamento della topologia e avvio del processo di ripristino. Poiché il server è disponibile, riusciamo a liberare con successo il VIP dal vecchio master, trasferirlo al nuovo e inviare alcune richieste ARP. Un eventuale ritorno del vecchio master non dovrebbe influenzare il cluster ricostruito e il funzionamento dell'applicazione.

Altri problemi

Guasti delle repliche o dei master intermedi non portano a azioni automatiche e richiedono un intervento manuale.

L'interfaccia di rete virtuale viene sempre aggiunta temporaneamente, ovvero dopo il riavvio del server, il VIP non viene automaticamente assegnato. Ogni istanza del DB viene avviata per impostazione predefinita in modalità di sola lettura, l'orchestratore commuta automaticamente il nuovo master su scrittura e cerca di stabilire sola lettura sul vecchio master. Queste azioni sono mirate a ridurre la probabilità split brain.

Durante il processo di ripristino potrebbero sorgere problemi, dei quali è anche opportuno avvisare tramite l'interfaccia utente dell'orchestratore oltre ai normali strumenti di monitoraggio. Abbiamo ampliato l'API REST, aggiungendo questa possibilità (PR è attualmente in revisione).

Il diagramma generale della soluzione HA è riportato di seguito.

Scelta del nuovo master

L'orchestratore è abbastanza intelligente e cerca di selezionare la replica più adatta come nuovo master secondo i seguenti criteri:

• ritardo della replica rispetto al master;
• versione MySQL del master e della replica;
• tipo di replicazione (RBR, SBR o mista);
• posizione in uno o più data center;
• presenza di GTID erranti — transazioni che sono state eseguite sulla replica e che mancano sul master;
• sono considerati anche le regole di selezione personalizzate.

Non ogni replica è un candidato ideale per il ruolo di master. Ad esempio, la replica può essere utilizzata per il backup dei dati, oppure il server può avere una configurazione hardware più debole. L'orchestratore supporta regole manuali, che consentono di configurare le proprie preferenze di selezione dei candidati, da quelle più preferite a quelle ignorate.

Tempo di risposta e ripristino

In caso di incidente, è importante ridurre al minimo il tempo di inattività del sistema, quindi consideriamo i parametri MySQL che influenzano la costruzione e l'aggiornamento della topologia del cluster da parte dell'orchestratore:

• slave_net_timeout — il numero di secondi durante i quali la replica attende l'arrivo di nuovi dati o un segnale heartbeat dal master, prima che la connessione venga considerata persa e venga eseguita la riconnessione. Più basso è il valore, più rapidamente la replica sarà in grado di determinare che la connessione con il master è stata interrotta. Impostiamo questo valore a 5 secondi.
• MASTER_CONNECT_RETRY — il numero di secondi tra i tentativi di riconnessione. In caso di problemi di rete, un valore basso di questo parametro consentirà di riconnettersi rapidamente e prevenire l'avvio del processo di recupero del cluster. Il valore raccomandato è di 1 secondo.
• MASTER_RETRY_COUNT — il numero massimo di tentativi di riconnessione.
• MASTER_HEARTBEAT_PERIOD — l'intervallo in secondi dopo il quale il master invia un segnale di heartbeat. Di default è pari alla metà del valore slave_net_timeout.

Parametri dell'orchestratore:

• DelayMasterPromotionIfSQLThreadNotUpToDate — se è uguale a true, il ruolo di master non sarà applicato al replica candidato fino a quando il thread SQL del replica non avrà eseguito tutte le transazioni non applicate dal Relay Log. Utilizziamo questa opzione per non perdere transazioni in caso di ritardo di tutti i replica candidati.
• InstancePollSeconds — la frequenza con cui viene costruita e aggiornata la topologia.
• RecoveryPollSeconds — la frequenza con cui viene analizzata la topologia. In caso venga rilevato un problema, viene avviato il recupero della topologia. Questa è una costante, pari a 1 secondo.

Ogni nodo del cluster viene interrogato dall'orchestratore una volta in InstancePollSeconds secondi. In caso di problemi rilevati, lo stato del cluster viene forzatamente aggiornato, e poi viene presa una decisione finale sull'esecuzione del recupero. Sperimentando con vari parametri del database e dell'orchestratore, siamo riusciti a ridurre il tempo di reazione e recupero a 30 secondi.

Banchina di test

Abbiamo iniziato a testare lo schema HA sviluppando un banco di prova locale e successivamente implementandolo in ambienti di test e produzione. Il banco di prova locale è completamente automatizzato sulla base di Docker e consente di sperimentare con la configurazione dell'orchestratore e della rete, scalando il cluster da 2-3 server a diverse decine e conducendo esercitazioni in un ambiente sicuro.

Durante le esercitazioni scegliamo uno dei metodi di simulazione del problema: interrompere immediatamente il master utilizzando kill -9, chiudere delicatamente il processo e fermare il server (docker-compose stop), simulare problemi di rete utilizzando iptables -j REJECT o iptables -j DROP. Ci aspettiamo i seguenti risultati:

• l'orchestratore rileverà i problemi con il master e aggiornerà la topologia in non più di 10 secondi;
• la procedura di recupero verrà avviata automaticamente: cambierà la configurazione di rete, il ruolo di master passerà al replica, la topologia verrà ricostruita;
• il nuovo master sarà disponibile per la registrazione, le repliche live non andranno perdute durante il processo di ricostruzione;
• i dati inizieranno a essere registrati nel nuovo master e a essere replicati;
• il tempo totale di ripristino non supererà i 30 secondi.

Come sapete, il sistema può comportarsi in modo diverso negli ambienti di test e di produzione a causa di diverse configurazioni dell'hardware e della rete, delle differenze nei carichi sintetici e reali, e così via. Pertanto, periodicamente conduciamo esercitazioni in condizioni reali per verificare come si comporta il sistema in caso di perdita di connettività di rete o di degrado di singole parti. In futuro, vogliamo costruire un'infrastruttura completamente identica per entrambi gli ambienti e automatizzarne il testing.

Conclusioni

Il funzionamento del nodo principale del sistema di archiviazione dei dati è uno degli obiettivi principali del team SRE e dell'operatività. L'implementazione di un orchestratore e di una soluzione HA basata su VIP ha portato ai seguenti risultati:

• rilevamento affidabile dei problemi con la topologia del cluster del DB;
• risposta automatica e rapida agli incidenti legati al master, che riduce i tempi di inattività del sistema.

Tuttavia, la soluzione ha le sue limitazioni e svantaggi:

• la scalabilità dello schema HA su più DC richiederà una rete L2 unica tra di loro;
• prima di assegnare il VIP al nuovo master, dobbiamo liberarlo da quello vecchio. Il processo è sequenziale, il che aumenta il tempo di ripristino;
• liberare il VIP richiede accesso SSH al server, o qualsiasi altro metodo per chiamare procedure remote. Poiché il server o il DB stanno affrontando problemi che causano il processo di ripristino, non possiamo essere certi che la rimozione del VIP avrà successo. Questo potrebbe portare alla creazione di due server con lo stesso indirizzo IP virtuale e alla problematica di split brain.

Per evitare split brain, si può utilizzare il metodo STONITH («Shoot The Other Node In The Head»), che isola o disattiva completamente il nodo problematico. Ci sono anche altri metodi per implementare l'alta disponibilità del cluster: combinazione di VIP e DNS, rilevamento dei servizi e proxy, replica sincrona e altri metodi, ognuno dei quali ha i propri svantaggi e vantaggi.

Ho parlato del nostro approccio alla creazione di un cluster MySQL ad alta disponibilità. È semplice da implementare e garantisce un livello accettabile di affidabilità nelle attuali condizioni. Con lo sviluppo dell'intero sistema e dell'infrastruttura, questo approccio, senza dubbio, evolverà.

Fonte: habr.com