In Sitimobil utilizziamo il database MySQL come principale repository di dati permanenti. Abbiamo diversi cluster di database per vari servizi e obiettivi.

La disponibilità continua 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 downtime del sistema. In questo articolo esaminerò lo schema per garantire l'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 cosa rappresenta il nostro sistema di archiviazione dei dati.

Utilizziamo uno schema di replica classico con un master disponibile in scrittura e molteplici repliche utilizzate solo in lettura. Il cluster può contenere un master intermedio, un nodo che è sia una replica che un master per altri. I client accedono alle repliche tramite HAProxy, che consente di distribuire uniformemente il carico e di scalare facilmente. L'uso di HAProxy è motivato da ragioni storiche, e ora siamo in fase di migrazione verso ProxySQL.

La replica avviene in modalità semisincrona basata su GTID. Ciò significa che almeno una replica deve registrare la transazione nel log prima che venga considerata completata. Questa modalità di replica assicura un equilibrio ottimale tra prestazioni e integrità dei dati in caso di guasto del nodo principale. Fondamentalmente, 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 ricevute e, in caso di problemi, può avviare la procedura di ripristino automatico. La responsabilità per la procedura stessa ricade sullo sviluppatore, poiché può essere implementata in vari modi: utilizzando VIP, DNS, servizi di discovery, o meccanismi personalizzati.

Uno dei metodi semplici per ripristinare il master in caso di guasto è l'uso di indirizzi VIP flottanti.

Ecco cosa bisogna sapere su questa soluzione prima di procedere:

• Un VIP è un indirizzo IP non legato a una specifica interfaccia di rete fisica. Quando un nodo si guasta o durante la manutenzione programmata, possiamo trasferire il VIP su una risorsa diversa 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 è necessario avere accesso al server via SSH, oppure utilizzare strumenti specifici, come keepalived.

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

Connessione di rete persa con il master, oppure si è verificato un problema hardware e il server non è accessibile.

1. L'orchestratore sta aggiornando la topologia del cluster, ogni replica segnala l'inaccessibilità del master. L'orchestratore avvia il processo di selezione di una replica adatta a diventare il nuovo master e inizia il ripristino.
2. Tentiamo di rimuovere il VIP dal vecchio master, senza successo.
3. La replica passa al ruolo di master. La topologia viene ristrutturata.
4. Aggiungiamo una nuova interfaccia di rete con VIP. Poiché non siamo riusciti a rimuovere il VIP, avviamo in background l'invio periodico di una richiesta. gratuitous ARP. Questo tipo di richiesta/risposta consente di aggiornare la tabella di corrispondenza degli indirizzi IP e MAC sui switch collegati, notificando così il trasferimento del nostro VIP. Questo minimizza la probabilità di split brain al ritorno del vecchio master.
5. T tutte le nuove connessioni vengono immediatamente reindirizzate al nuovo master. Le vecchie connessioni falliscono, vengono effettuati tentativi ripetuti al DB a livello di applicazione.

Il server è operativo 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, rilasciamo con successo il VIP dal vecchio master, lo trasferiamo sul nuovo e inviamo alcune richieste ARP. Il possibile ritorno del vecchio master non dovrebbe influire sul cluster ricostruito e sul funzionamento dell'applicazione.

Altri problemi

Guasti delle repliche o dei master intermedi non porta a azioni automatiche e richiede intervento manuale.

L'interfaccia di rete virtuale viene sempre aggiunta temporaneamente, cioè 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 in scrittura e prova a impostare sola lettura sul vecchio master. Queste azioni mirano a ridurre la probabilità split brain.

Nel processo di ripristino possono sorgere problemi, che dovrebbero essere notificati tramite l'interfaccia utente dell'orchestratore oltre ai normali strumenti di monitoraggio. Abbiamo ampliato il REST API, aggiungendo tale possibilità (PR è attualmente in fase di revisione).

Lo schema generale della soluzione HA è mostrato di seguito.

Selezione del nuovo master

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

• ritardo della replica rispetto al master;
• versione di MySQL del master e della replica;
• tipo di replicazione (RBR, SBR o mixed);
• posizione nello stesso o in diversi data center;
• presenza GTID errante — transazioni eseguite sulla replica e assenti nel master;
• sono anch'essi considerati regole di selezione utente.

Non ogni replica è un candidato ideale per diventare master. Ad esempio, una replica potrebbe essere utilizzata per il backup dei dati, oppure il server ha una configurazione hardware meno potente. L'orchestratore supporta regole manuali, che possono essere usate per configurare le proprie preferenze di selezione dei candidati, dalla più preferita a quella ignorata.

Tempo di risposta e recupero

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 il quale la replica attende l'arrivo di nuovi dati o di un segnale heartbeat dal master, prima che la connessione venga considerata persa e venga eseguita una riconnessione. Minore è il valore, più rapidamente la replica potrà rilevare che il collegamento con il master è stato interrotto. 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à una riconnessione rapida e prevenirà l'avvio del processo di ripristino del cluster. Il valore consigliato è di 1 secondo.
• MASTER_RETRY_COUNT — il numero massimo di tentativi di riconnessione.
• MASTER_HEARTBEAT_PERIOD — intervallo in secondi dopo il quale il master invia un segnale heartbeat. Di default è pari alla metà del valore slave_net_timeout.

Parametri dell'orchestratore:

• DelayMasterPromotionIfSQLThreadNotUpToDate — se è uguale a true, la funzione master non verrà applicata alla replica candidata fino a quando il thread SQL della replica non avrà applicato tutte le transazioni non applicate dal Relay Log. Utilizziamo questa opzione per non perdere transazioni in condizioni di ritardo di tutte le repliche candidate.
• InstancePollSeconds — frequenza di costruzione e aggiornamento della topologia.
• RecoveryPollSeconds — frequenza di analisi della topologia. In caso di problemi, si avvia il ripristino della topologia. Questo è una costante, pari a 1 secondo.

Ogni nodo del cluster viene interrogato dall'orchestratore una volta ogni InstancePollSeconds secondi. In caso di problemi, lo stato del cluster viene forzatamente aggiornato, e poi si prende una decisione finale sul ripristino. Sperimentando con diversi parametri del DB e dell'orchestratore, siamo riusciti a ridurre il tempo di risposta e ripristino a 30 secondi.

Banchi di prova

Abbiamo avviato il test della configurazione HA sviluppando un banco di prova e successivamente implementandolo negli ambienti di test e di produzione. Il banco di prova locale è completamente automatizzato usando 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 emulazione del problema: abbattere immediatamente il master con kill -9, terminare delicatamente il processo e fermare il server (docker-compose stop), simulare problemi di rete usando 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 meno di 10 secondi;
• si avvierà automaticamente la procedura di recupero: la configurazione di rete cambierà, il ruolo di master passerà a una replica, la topologia verrà ricostruita;
• il nuovo master sarà disponibile per la scrittura, le repliche attive non andranno perse durante la ricostruzione;
• i dati inizieranno a essere scritti nel nuovo master e a essere replicati;
• il tempo totale di recupero sarà di non più di 30 secondi.

Come sapete, il sistema può comportarsi in modo diverso nell'ambiente di test e in produzione a causa della diversa configurazione dell'hardware e della rete, delle differenze nel carico sintetico e reale, ecc. Pertanto, periodicamente conduciamo esercitazioni in condizioni reali, verificando come si comporta il sistema in caso di perdita di connettività di rete o degrado di singole parti. In futuro vogliamo costruire un'infrastruttura completamente identica per entrambi gli ambienti e automatizzare il suo test.

Conclusioni

La funzionalità del nodo principale del sistema di archiviazione dati è una delle priorità per il team SRE e per l'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 DB;
• risposta automatica e rapida agli incidenti relativi al master, riducendo così il tempo di inattività del sistema.

Tuttavia, la soluzione presenta alcune limitazioni e svantaggi:

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

Per evitare split brain, è possibile utilizzare il metodo STONITH («Spara L'altro Nodo Nella Testa»), che isola completamente o disabilita il nodo problematico. Esistono anche altre modalità per implementare l'alta disponibilità del cluster: una combinazione di VIP e DNS, rilevamento dei servizi e servizi proxy, replica sincrona e altri metodi, ciascuno con i propri vantaggi e svantaggi.

Ho parlato del nostro approccio alla creazione di un cluster MySQL tollerante ai guasti. È semplice da implementare e offre un livello accettabile di affidabilità nelle condizioni attuali. Man mano che l'intero sistema e l'infrastruttura in particolare si evolvono, questo approccio, senza dubbio, si svilupperà.

Fonte: habr.com