Architettura per MySQL a disponibilità elevata con failover automatico in posizioni fisicamente diverse

Ho cercato soluzioni ad alta disponibilità (HA) per MySQL tra i data center.

Per i server situati nello stesso ambiente fisico, ho preferito il doppio master con heartbeat (VIP flottante) utilizzando un approccio passivo attivo. Il battito cardiaco riguarda sia una connessione seriale che una connessione ethernet.

In definitiva, il mio obiettivo è mantenere questo stesso livello di disponibilità ma tra i data center. Voglio eseguire il failover dinamico tra i due data center senza intervento manuale e mantenere comunque l'integrità dei dati.

Ci sarebbe BGP in cima. Cluster Web in entrambe le posizioni, che potrebbero potenzialmente instradare verso i database tra le due parti. Se la connessione Internet si interrompesse sul sito 1, i client instraderebbero attraverso il sito 2, al cluster Web e quindi al database nel sito 1 se il collegamento tra entrambi i siti è ancora attivo.

Con questo scenario, a causa della mancanza di collegamento fisico (seriale), vi sono maggiori probabilità di dividere il cervello. Se la WAN scendesse tra i due siti, il VIP finirebbe su entrambi i siti, dove una varietà di scenari spiacevoli potrebbe introdurre desincronizzazione.

Un altro potenziale problema che vedo è la difficoltà di ridimensionare questa infrastruttura in un terzo data center in futuro.

Il livello di rete non è al centro dell'attenzione. L'architettura è flessibile in questa fase. Ancora una volta, il mio focus è una soluzione per mantenere l'integrità dei dati e il failover automatico con i database MySQL. Probabilmente progetterei il resto attorno a questo.

Puoi consigliare una soluzione comprovata per MySQL HA tra due siti fisicamente diversi?

Grazie per aver dedicato del tempo a leggere questo. Non vedo l'ora di leggere i tuoi consigli.

Dovrai affrontare il problema del teorema "CAP". Non è possibile avere coerenza, disponibilità e tolleranza della partizione contemporaneamente.

DRBD / MySQL HA si basa sulla replica sincrona a livello di dispositivo a blocchi. Questo va bene mentre sono disponibili entrambi i nodi, o se si soffre di un errore temporaneo, si riavvia ecc., Quindi ritorna. I problemi iniziano quando si ottiene una partizione di rete.

Le partizioni di rete sono estremamente probabili quando si esegue in due data center. In sostanza, nessuna delle parti può distinguere una partizione dall'altro nodo in errore. Il nodo secondario non sa se dovrebbe subentrare (il primario è fallito) oppure no (il collegamento è sparito).

Mentre le macchine si trovano nella stessa posizione, è possibile aggiungere un canale di comunicazione secondario (in genere un cavo seriale o Ethernet crossover) per aggirare questo problema, in modo che il secondario sappia quando il primario è GENUINAMENTE inattivo e non è una partizione di rete .

Il prossimo problema sono le prestazioni. Mentre DRBD può offrire prestazioni decenti ** quando le tue macchine hanno una connessione a bassa latenza (ad es. Gigabit Ethernet - ma alcune persone usano reti dedicate ad alta velocità), maggiore è la latenza della rete, maggiore è il tempo necessario per eseguire una transazione *** . Questo perché deve attendere che il server secondario (quando è online) riconosca tutte le scritture prima di dire "OK" all'app per garantire la durata delle scritture.

Se lo fai in diversi data center, in genere hai una latenza di molti millisecondi, anche se si trovano nelle vicinanze.

** Ancora molto più lento di un IO Controller locale decente

*** Non è possibile utilizzare MyISAM per un sistema DRBD ad alta disponibilità perché non si ripristina correttamente / automaticamente da un arresto impuro, necessario durante un failover.

Che ne dici di usare una VLAN per collegare tutti i server nei due (o più) data center insieme. È quindi possibile utilizzare CARP per il failover automatico. Utilizzare la replica del database per mantenere tutto sincronizzato.

Se sei proprietario dei data center, puoi assicurarti che ogni data center abbia più uplink WAN.

Il tuo primo passo dovrebbe essere quello di aggiornare la tua attuale soluzione HA a una che utilizza OpenAIS come livello di appartenenza al Cluster: questo ti darà molta flessibilità e, dato che i collegamenti a bassa latenza tra i siti, potrebbero essere in grado di raggiungere. PaceMaker e RHEL Clustering supportano questo.

Per il failover automatico del data center, è davvero necessario un terzo sito che funga da tie-break, altrimenti i siti non saranno in grado di distinguere tra problemi di routing tra siti e guasti del sito remoto. Microsoft ha alcuni web cast sorprendentemente buoni che coprono l'area:

Clustering multi-sito di Windows Server 2008

Ovviamente la tecnologia esatta non si associa al dominio Linux, ma i concetti sono gli stessi.

Mi dispiace che questa sia un'altra rete a parte, ma un pensiero per la strada ...

Per lo scenario del cervello diviso che hai citato, potresti avere collegamenti ridondanti tra due siti e ridurre la possibilità che ciò accada.

Si noti che probabilmente non è possibile utilizzare BGP, poiché il blocco instradabile più piccolo è 4k, a / 22, buona fortuna ottenerne uno. Probabilmente è necessaria una soluzione basata su DNS.

Dare una risposta corretta potrebbe essere difficile a seconda della quantità di dati che hai, della quantità di server in cui vuoi adattarti, ecc. Detto questo, la mia risposta potrebbe non essere una, o almeno quella che stai cercando.

Non esiste una soluzione comprovata per più siti con MySQL. Ma c'è una soluzione che funziona. Come alcuni hanno sottolineato, sì DRDB funziona bene ma ha il suo limite o possibile problema a seconda della configurazione.

Avrai mai bisogno di un terzo sito (un altro datacenter)? In tal caso, quanto tempo e denaro dovrai fare?

Considerando ogni volta che aggiungi un server master / slave / dns, i backup, ... ti aggiungi un server da gestire, qual è la tua capacità di gestione in termini di numero di server? Se puoi definire questo numero, potresti dover buttare via alcune possibili soluzioni e lavorare verso quelle che si adatteranno ai tuoi numeri in modo che la gestione non diventi un collo di bottiglia.

Considerando che i datacenter non si arrestano spesso, più siti significano bilanciamento del carico e un po 'di hacking DNS, questo sarà nello stesso datacenter? In tal caso, se un datacenter si interrompe per qualsiasi motivo, si verificherà un problema poiché buona parte del DNS e del bilanciamento del carico si troveranno in questo datacenter.

Quindi potresti dover pianificare quella situazione del cervello diviso. Per ogni possibile installazione di almsot, il modo di risolvere una situazione cerebrale allo spiedo è diverso. Inoltre, ogni soluzione richiede X quantità di tempo.
Potrebbe anche essere molto più semplice pianificare l'utilizzo di 3 datacenter dall'inizio. Non sono un esperto di MySQL ma ho sentito che in produzione era più facile avere 3 Master che 2 se mai avessi problemi.

Una cosa che può aiutarti è il servizio di bilanciamento del carico offerto da alcuni fornitori di reti come Zeus, dai un'occhiata qui Probabilmente ce ne sono molte altre che offrono questo tipo di servizio. Sono sicuro che ha un prezzo, ma a volte ti consente di ridurre alcune altre cose.

In bocca al lupo!

DRBD non è una soluzione consigliata per data center remoti, poiché richiede larghezza di banda che può influire sulla velocità del database e della replica. La soluzione consigliata è Master - Master Replication. L'unico problema è che i campi di incremento automatico devono essere sfalsati.

Se hai bisogno di una soluzione veramente HA per MySQL, dovresti scegliere MySQL Cluster perché DRBD non può darti integrità dei dati in caso di guasti.

Ho trovato post sul blog sulle opzioni disponibili in MySQL e sui suoi pro e contro. http://mysqlha.blogspot.com/2010/04/consistency-across-wan.html

Superare la mancanza di un cavo seriale è in realtà molto semplice, si usa una cosa dei tempi bui chiamata modem: ne hai uno a ciascuna estremità e quindi esegui Heartbeat sul collegamento PPP. Puoi anche usare il frame relay. Entrambi i metodi risolveranno tutte le preoccupazioni che hai con i percorsi ridondanti layer1 / 2.

Tuttavia, detto questo - DRBD che corre su qualsiasi collegamento con una latenza molto superiore a circa 300µs (nota che è 0,3ms) diventa ridicolo molto rapidamente.

Saresti meglio servito usando la replica standard di MySQL e LinuxHA su PPP ed eth per fare i failover.

Almeno questo è quello che ho fatto per i clienti in passato.