A Citymobil utilizziamo un database MySQL come principale archivio dati persistente. Disponiamo di diversi cluster di database per vari servizi e scopi.

La costante disponibilità del master è un indicatore critico delle prestazioni dell'intero sistema e delle sue singole parti. Il ripristino automatico del cluster in caso di guasto del master riduce notevolmente i tempi di risposta agli incidenti e i tempi di inattività del sistema. In questo articolo esaminerò un progetto ad alta disponibilità (HA) per un cluster MySQL basato su Orchestratore MySQL e indirizzi IP virtuali (VIP).

Soluzione HA basata su VIP

Per prima cosa ti racconto brevemente qual è il nostro sistema di archiviazione dei dati.

Utilizziamo uno schema di replica classico con un master accessibile in scrittura e più repliche di sola lettura. Un 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 una distribuzione uniforme del carico e un facile ridimensionamento. L'utilizzo di HAProxy è dovuto a ragioni storiche e attualmente stiamo effettuando la migrazione a ProxySQL.

La replica viene eseguita in modalità semisincrona in base a GTID. Ciò significa che almeno una replica deve registrare una transazione prima che venga considerata riuscita. Questa modalità di replica fornisce un equilibrio ottimale tra prestazioni e sicurezza dei dati in caso di guasto del nodo master. Fondamentalmente tutte le modifiche vengono trasferite dal master alle repliche utilizzando Row Based Replication (RBR), ma alcuni nodi potrebbero 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 una procedura di ripristino automatico. Lo sviluppatore è responsabile della procedura stessa, poiché può essere implementata in diversi modi: sulla base di VIP, DNS, utilizzando servizi di rilevamento dei servizi o meccanismi autoprodotti.

Un modo semplice per ripristinare un master in caso di errore è utilizzare indirizzi VIP mobili.

Cosa devi sapere su questa soluzione prima di andare avanti:

• Un VIP è un indirizzo IP non associato a un'interfaccia di rete fisica specifica. Se un nodo si guasta o durante la manutenzione programmata, possiamo spostare il VIP su un'altra risorsa con tempi di inattività minimi.
• Liberare e rilasciare un indirizzo IP virtuale è un'operazione economica e veloce.
• Per lavorare con VIP, è necessario accedere al server tramite SSH o utilizzare utilità speciali, ad esempio keepalived.

Diamo un'occhiata ai possibili problemi con la nostra procedura guidata e immaginiamo come dovrebbe funzionare il meccanismo di ripristino automatico.

La connettività di rete al master è scomparsa oppure si è verificato un problema a livello hardware e il server non è disponibile

1. L'orchestratore aggiorna la topologia del cluster, ogni replica segnala che il master non è disponibile. L'orchestratore avvia il processo di selezione di una replica adatta al ruolo del nuovo master e inizia il ripristino.
2. Stiamo cercando di rimuovere il VIP dal vecchio maestro, senza successo.
3. La replica passa al ruolo di master. La topologia è in fase di ricostruzione.
4. Aggiunta di una nuova interfaccia di rete con VIP. Poiché non è stato possibile rimuovere il VIP, iniziamo periodicamente a inviare una richiesta in background ARP gratuito. Questo tipo di richiesta/risposta permette di aggiornare la tabella di mappatura degli indirizzi IP e MAC sugli switch collegati, avvisandovi così che il nostro VIP si è spostato. Ciò riduce al minimo la probabilità split brain quando restituisci il vecchio maestro.
5. Tutte le nuove connessioni vengono immediatamente reindirizzate al nuovo master. Le vecchie connessioni falliscono e le chiamate ripetute al database vengono effettuate a livello di applicazione.

Il server funziona in modalità normale, si è verificato un errore a livello 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 sul vecchio master, lo trasferiamo su quello nuovo e inviamo diverse richieste ARP. L'eventuale restituzione del vecchio master non dovrebbe pregiudicare il cluster ricostruito e il funzionamento dell'applicazione.

Altri problemi

Guasto delle repliche o dei master intermedi non conduce ad azioni automatiche e richiede un intervento manuale.

Un'interfaccia di rete virtuale viene sempre aggiunta temporaneamente, ovvero dopo il riavvio del server il VIP non viene assegnato automaticamente. Per impostazione predefinita, ogni istanza del database viene avviata in modalità di sola lettura, l'orchestratore passa automaticamente alla scrittura il nuovo master e tenta l'installazione read only sul vecchio maestro. Queste azioni hanno lo scopo di ridurre la probabilità split brain.

Durante il processo di ripristino potrebbero verificarsi problemi, che dovrebbero essere notificati anche tramite l'interfaccia utente dell'agente di orchestrazione oltre agli strumenti di monitoraggio standard. Abbiamo ampliato l'API REST aggiungendo questa funzionalità (PR attualmente in fase di revisione).

Di seguito è presentato lo schema generale della soluzione HA.

La scelta di un nuovo maestro

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

• la replica resta indietro rispetto al master;
• Versione MySQL di master e replica;
• tipo di replica (RBR, SBR o mista);
• ubicazione nello stesso o in diversi data center;
• наличие errant GTID — transazioni eseguite sulla replica e non sul master;
• vengono prese in considerazione anche le regole di selezione personalizzata.

Non tutti gli spunti sono candidati ideali per un maestro. Ad esempio, è possibile utilizzare una replica per eseguire il backup dei dati oppure il server ha una configurazione hardware più debole. Orchestratore поддерживает regole manuali con le quali puoi personalizzare le tue preferenze di selezione dei candidati dal più preferito all'ignorato.

Tempi di risposta e recupero

In caso di incidente è importante ridurre al minimo i tempi di inattività del sistema, consideriamo quindi i parametri MySQL che influenzano la creazione 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 di un segnale heartbeat dal master prima che la connessione venga riconosciuta come persa e ristabilita. Più basso è il valore, più velocemente la replica può determinare che la comunicazione con il master è interrotta. Impostiamo questo valore su 5 secondi.
• MASTER_CONNECT_RETRY — numero di secondi tra i tentativi di riconnessione. In caso di problemi di rete, un valore basso per questo parametro consentirà una rapida riconnessione e impedirà l'avvio del processo di ripristino del cluster. Il valore consigliato è 1 secondo.
• MASTER_RETRY_COUNT — numero massimo di tentativi di riconnessione.
• MASTER_HEARTBEAT_PERIOD — intervallo in secondi dopo il quale il master invia un segnale di heartbeat. Il valore predefinito è la metà slave_net_timeout.

Parametri dell'orchestratore:

• DelayMasterPromotionIfSQLThreadNotUpToDate - se uguale true, il ruolo master non verrà applicato alla replica candidata finché il thread SQL della replica non avrà completato tutte le transazioni non applicate dal log di inoltro. Utilizziamo questa opzione per evitare di perdere transazioni quando tutte le repliche candidate restano indietro.
• InstancePollSeconds — frequenza di costruzione e aggiornamento della topologia.
• RecoveryPollSeconds — frequenza dell'analisi della topologia. Se viene rilevato un problema, viene avviato il ripristino della topologia. Questo costante, pari a 1 secondo.

Ogni nodo del cluster viene sottoposto a polling dall'orchestratore una volta InstancePollSeconds secondi Quando viene rilevato un problema, lo stato del cluster viene forzato aggiornato, quindi viene presa la decisione finale di eseguire il ripristino. Sperimentando diversi parametri di database e orchestratore, siamo riusciti a ridurre i tempi di risposta e ripristino a 30 secondi.

banco di prova

Abbiamo iniziato a testare lo schema HA con lo sviluppo di un local banco di prova e ulteriore implementazione in ambienti di test e produzione. Lo stand locale è completamente automatizzato basato su Docker e consente di sperimentare la configurazione dell'orchestratore e della rete, scalare il cluster da 2-3 server a diverse dozzine e condurre esercitazioni in un ambiente sicuro.

Durante gli esercizi, scegliamo uno dei metodi di emulazione del problema: spariamo istantaneamente al maestro usando kill -9, termina dolcemente il processo e arresta 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;
• automaticamente si avvierà la procedura di ripristino: cambierà la configurazione della rete, il ruolo del master passerà alla replica, la topologia verrà ricostruita;
• il nuovo master diventerà scrivibile, le repliche live non andranno perse durante il processo di ricostruzione;
• i dati inizieranno ad essere scritti sul nuovo master e replicati;
• Il tempo di recupero totale non sarà superiore a 30 secondi.

Come sapete, il sistema potrebbe comportarsi diversamente negli ambienti di test e di produzione a causa delle diverse configurazioni hardware e di rete, delle differenze nel carico sintetico e reale, ecc. Pertanto, periodicamente conduciamo esercizi in condizioni reali, controllando come si comporta il sistema quando viene persa la connettività di rete o le sue singole parti vengono degradate. In futuro, vogliamo costruire un'infrastruttura completamente identica per entrambi gli ambienti e automatizzarne i test.

risultati

Lo stato di salute del nodo del sistema di storage principale è uno dei compiti principali del team SRE e operativo. L'implementazione dell'orchestrator e della soluzione HA basata su VIP ha permesso di ottenere i seguenti risultati:

• rilevamento affidabile di problemi con la topologia del cluster di database;
• risposta automatica e rapida agli incidenti relativi al master, riducendo i tempi di inattività del sistema.

Tuttavia, la soluzione ha i suoi limiti e svantaggi:

• la scalabilità dello schema HA su diversi data center richiederà un'unica rete L2 tra di loro;
• Prima di assegnare il VIP sul nuovo master, dobbiamo rilasciarlo su quello vecchio. Il processo è sequenziale, il che aumenta i tempi di recupero;
• il rilascio del VIP richiede l'accesso SSH al server o qualsiasi altro metodo per chiamare procedure remote. Poiché il server o il database stanno riscontrando problemi che hanno causato il processo di ripristino, non possiamo essere sicuri che la rimozione del VIP venga completata con successo. E questo può portare alla comparsa di due server con lo stesso indirizzo IP virtuale e ad un problema split brain.

Evitare split brain, puoi usare il metodo STONITO ("Spara in testa all'altro nodo"), che isola o disabilita completamente il nodo problematico. Esistono altri modi per implementare l'elevata disponibilità del cluster: una combinazione di VIP e DNS, servizi di rilevamento e proxy, replica sincrona e altri metodi che presentano vantaggi e svantaggi.

Ho parlato del nostro approccio alla creazione di un cluster di failover MySQL. È facile da implementare e fornisce un livello accettabile di affidabilità nelle condizioni attuali. Man mano che l’intero sistema in generale e le infrastrutture in particolare si svilupperanno, questo approccio evolverà senza dubbio.

Fonte: habr.com