È molto comune vedere database distribuiti in più posizioni geografiche. Uno scenario per eseguire questo tipo di configurazione è il ripristino di emergenza, in cui il data center di standby si trova in una posizione separata rispetto al data center principale. Potrebbe anche essere necessario in modo che i database si trovino più vicino agli utenti.
La sfida principale per ottenere questa configurazione consiste nel progettare il database in modo da ridurre la possibilità di problemi relativi al partizionamento della rete.
MariaDB Cluster può essere una buona scelta per creare un tale ambiente per diversi motivi. Vorremmo discuterne qui e anche parlare un po' di come potrebbe essere un tale ambiente.
Perché utilizzare MariaDB Cluster per ambienti geo-distribuiti?
Il primo motivo è che MariaDB Cluster può supportare più writer. Ciò semplifica la progettazione del routing di scrittura:scrivi semplicemente sui nodi MariaDB locali. Ovviamente, data la replica sincrona, la latenza influisce sulle prestazioni di scrittura e potresti notare che le tue scritture diventano più lente se diffondi il tuo cluster troppo geograficamente. Dopotutto, non puoi ignorare le leggi della fisica e dicono, almeno per ora, che anche la velocità della luce nelle connessioni in fibra è limitata. Eventuali router aggiunti in aggiunta aumenteranno anche la latenza, anche se solo di un paio di millisecondi.
In secondo luogo, la gestione del ritardo nel cluster MariaDB. La replica asincrona è soggetta a ritardi di replica:gli slave potrebbero non essere aggiornati con i dati se hanno difficoltà ad applicare tutte le modifiche nel tempo. In MariaDB Cluster questo è diverso:il controllo del flusso è un meccanismo che ha lo scopo di mantenere sincronizzato il cluster. Bene, quasi - in alcuni casi limite puoi ancora osservare il ritardo. Stiamo parlando, in genere, di millisecondi, un paio di secondi al massimo mentre nel cielo della replica asincrona è il limite.
Terzo, segmenti. Per impostazione predefinita, MariaDB CLuster utilizza tutte le comunicazioni e ogni writeset viene inviato dal nodo a tutti gli altri nodi del cluster. Questo comportamento può essere modificato utilizzando i segmenti. I segmenti consentono agli utenti di dividere i cluster MariaDB in più parti. Ogni segmento può contenere più nodi e ne elegge uno come nodo di inoltro. Tali nodi ricevono i set di scrittura da altri segmenti e li ridistribuiscono sui nodi MariaDB locali al segmento. Di conseguenza, come puoi vedere nel diagramma sopra, è possibile ridurre il traffico di replica su WAN tre volte - solo due "replica" del flusso di replica vengono inviate su WAN:una per datacenter rispetto a una per slave nella replica asincrona.
Infine, dove MariaDB Cluster brilla davvero è la gestione del partizionamento di rete. MariaDB Cluster monitora costantemente lo stato dei nodi nel cluster. Ogni nodo tenta di connettersi con i suoi peer e scambiare lo stato del cluster. Se un sottoinsieme di nodi non è raggiungibile, MariaDB tenta di inoltrare la comunicazione, quindi se c'è un modo per raggiungere quei nodi, verranno raggiunti.
Un esempio può essere visto nel diagramma sopra:DC 1 ha perso la connettività con DC2 ma DC2 e DC3 possono connettersi. In questo caso uno dei nodi in DC3 verrà utilizzato per trasmettere i dati da DC1 a DC2 assicurando che la comunicazione intra-cluster possa essere mantenuta.
MariaDB è in grado di eseguire azioni in base allo stato del cluster. Implementa il quorum:la maggior parte dei nodi deve essere disponibile affinché il cluster possa funzionare. Se il nodo viene disconnesso dal cluster e non riesce a raggiungere nessun altro nodo, cesserà di funzionare.
Come si può vedere nel diagramma sopra, c'è una perdita parziale della comunicazione di rete in DC1 e il nodo interessato viene rimosso dal cluster, assicurando che l'applicazione non acceda a dati obsoleti.
Questo vale anche su scala più ampia. Il DC1 ha interrotto tutte le comunicazioni. Di conseguenza, l'intero data center è stato rimosso dal cluster e nessuno dei suoi nodi servirà il traffico. Il resto del cluster ha mantenuto la maggioranza (sono disponibili 6 nodi su 9) e si è riconfigurato per mantenere la connessione tra DC 2 e DC3. Nel diagramma sopra abbiamo ipotizzato che il writer raggiunga il nodo in DC2, ma tieni presente che MariaDB è in grado di funzionare con più writer.
Progettazione del cluster MariaDB distribuito geograficamente
Abbiamo esaminato alcune delle funzionalità che rendono MariaDB Cluster una buona soluzione per ambienti geo-distribuiti, concentriamoci ora un po' sul design. All'inizio, spieghiamo con quale ambiente stiamo lavorando. Utilizzeremo tre data center remoti, collegati tramite Wide Area Network (WAN). Ciascun centro dati riceverà le scritture dai server delle applicazioni locali. Anche le letture saranno solo locali. Questo ha lo scopo di evitare il traffico non necessario che attraversa la WAN.
Per rendere questo blog meno complicato, non entreremo nei dettagli di come dovrebbe essere la connettività. Assumiamo una sorta di connessione sicura e configurata correttamente in tutti i data center. VPN o altri strumenti possono essere utilizzati per implementarlo.
Utilizzeremo MaxScale come loadbalancer. MaxScale verrà distribuito localmente in ogni data center. Indirizzerà anche il traffico solo ai nodi locali. I nodi remoti possono sempre essere aggiunti manualmente e spiegheremo i casi in cui questa potrebbe essere una buona soluzione. Le applicazioni possono essere configurate per connettersi a uno dei nodi MaxScale locali utilizzando un algoritmo round-robin. Possiamo anche utilizzare Keepalived e Virtual IP per instradare il traffico verso il singolo nodo MaxScale, purché un singolo nodo MaxScale sia in grado di gestire tutto il traffico.
Un'altra possibile soluzione consiste nel collocare MaxScale con i nodi dell'applicazione e configurare l'applicazione per la connessione al proxy sull'host locale. Questo approccio funziona abbastanza bene partendo dal presupposto che è improbabile che MaxScale non sia disponibile ma l'applicazione funzionerebbe correttamente sullo stesso nodo. In genere ciò che vediamo è un errore del nodo o un errore di rete, che interesserebbe sia MaxScale che l'applicazione contemporaneamente.
Il diagramma sopra mostra la versione dell'ambiente, in cui MaxScale forma proxy farm - tutti i nodi proxy con la stessa configurazione, carico bilanciato utilizzando Keepalived o semplicemente round robin dall'applicazione su tutti i nodi MaxScale. MaxScale è configurato per distribuire il carico di lavoro su tutti i nodi MariaDB nel data center locale. Uno di questi nodi verrebbe selezionato come nodo a cui inviare le scritture mentre SELECT verrebbe distribuito su tutti i nodi. Avere un nodo writer dedicato in un data center aiuta a ridurre il numero di possibili conflitti di certificazione, portando, in genere, a prestazioni migliori. Per ridurre ulteriormente questo problema, dovremmo iniziare a inviare il traffico tramite la connessione WAN, il che non è l'ideale in quanto l'utilizzo della larghezza di banda aumenterebbe in modo significativo. Al momento, con i segmenti in atto, vengono inviate solo due copie del set di scritture tra i data center, una per controller di dominio.
Conclusione
Come puoi vedere, MariaDB Cluster può essere facilmente utilizzato per creare cluster geo-distribuiti che possono funzionare anche in tutto il mondo. Il fattore limitante sarà la latenza di rete. Se è troppo alto, potresti dover considerare l'utilizzo di cluster MariaDB separati connessi tramite la replica asincrona.
