Poiché l'elevata disponibilità è fondamentale nella realtà aziendale odierna, uno degli scenari più comuni con cui gli utenti devono confrontarsi è come garantire che il database sia sempre disponibile per l'applicazione.
Ogni fornitore di servizi ha un rischio ereditario di interruzione del servizio, pertanto uno dei passaggi che possono essere presi è affidarsi a più fornitori per alleviare il rischio e la ridondanza aggiuntiva.
I fornitori di servizi cloud non sono diversi:possono fallire e dovresti pianificarlo in anticipo. Quali opzioni sono disponibili per MariaDB Cluster? Diamo un'occhiata in questo post del blog.
Gruppo di database MariaDB in ambienti multi-cloud
Se lo SLA proposto da un provider di servizi cloud non è sufficiente, c'è sempre un'opzione per creare un sito di ripristino di emergenza al di fuori di quel provider. Grazie a ciò, ogni volta che uno dei fornitori di servizi cloud subisce un degrado del servizio, puoi sempre passare a un altro fornitore e mantenere il tuo database attivo e disponibile.
Uno dei problemi tipici delle configurazioni multi-cloud è la latenza della rete, inevitabile se si parla di distanze maggiori o, in generale, di più posizioni geograficamente separate. La velocità della luce è piuttosto alta ma è limitata, ogni salto, ogni router aggiunge anche una certa latenza all'infrastruttura di rete.
MariaDB Cluster funziona benissimo su reti a bassa latenza. È un cluster basato su quorum in cui è necessaria una comunicazione rapida tra tutti i nodi per mantenere le operazioni senza intoppi. L'aumento della latenza di rete influirà sulle operazioni del cluster, in particolare sulle prestazioni delle scritture. Ci sono diversi modi in cui questo problema può essere affrontato.
Innanzitutto abbiamo un'opzione per utilizzare cluster separati collegati utilizzando collegamenti di replica asincroni. Questo ci consente quasi di dimenticare la latenza perché la replica asincrona è significativamente più adatta per lavorare in ambienti ad alta latenza.
Un'altra opzione è che, date le reti a bassa latenza tra i data center, potresti comunque essere perfettamente in grado di eseguire un cluster MariaDB che si estende su più data center. Dopotutto, più datacenter non significano sempre grandi distanze dal punto di vista geografico:puoi anche utilizzare più provider situati all'interno della stessa area metropolitana, collegati con reti veloci e a bassa latenza. Quindi parleremo di un aumento della latenza fino a decine di millisecondi al massimo, sicuramente non centinaia. Tutto dipende dall'applicazione, ma un tale aumento potrebbe essere accettabile.
Replica asincrona tra cluster MariaDB
Diamo una rapida occhiata all'approccio asincrono. L'idea è semplice:due cluster collegati tra loro tramite la replica asincrona.
Questo ha diverse limitazioni. Per cominciare, devi decidere se desideri utilizzare il multi-master o invierai tutto il traffico a un solo data center. Consigliamo di evitare di scrivere su entrambi i data center e di utilizzare la replica master-master. Ciò può causare seri problemi se non presti attenzione.
Se decidi di utilizzare l'impostazione attiva - passiva, probabilmente vorrai implementare una sorta di routing basato su DNS per le scritture, per assicurarti che i tuoi server delle applicazioni si connettano sempre a un insieme di proxy situati nel datacenter attivo. Ciò potrebbe essere ottenuto letteralmente tramite una voce DNS che verrebbe modificata quando è richiesto il failover o tramite una sorta di soluzione di rilevamento dei servizi come Consul o ecc.
Il principale svantaggio dell'ambiente creato utilizzando la replica asincrona è la mancanza di capacità di gestire le divisioni di rete tra i datacenter. Questo viene ereditato dalla replica, indipendentemente da cosa si desidera collegare alla replica (nodi singoli, cluster MariaDB), non c'è modo di aggirare il fatto che la replica non è a conoscenza del quorum. Non esiste alcun meccanismo per tenere traccia dello stato dei nodi e comprendere l'immagine di alto livello dell'intera topologia. Di conseguenza, ogni volta che il collegamento tra due data center si interrompe, si ottengono due cluster MariaDB separati che non sono connessi e che sono entrambi pronti ad accettare il traffico. Spetterà all'utente definire cosa fare in questo caso. È possibile implementare strumenti aggiuntivi che monitorerebbero lo stato dei database dall'esterno (cioè dal terzo datacenter) e quindi intraprendere azioni (o non intraprendere azioni) sulla base di tali informazioni. È anche possibile collocare strumenti che condividerebbero l'infrastruttura con i database, ma sarebbero in grado di riconoscere i cluster e potrebbero tracciare lo stato della connettività del datacenter ed essere utilizzati come fonte di verità per gli script che gestirebbero l'ambiente. Ad esempio, ClusterControl può essere distribuito in un cluster a tre nodi, nodo per datacenter, che utilizza il protocollo RAFT per garantire il quorum. Se un nodo perde la connettività con il resto del cluster, si può presumere che il datacenter abbia subito il partizionamento di rete.
Cluster MariaDB multi-DC
Un'alternativa alla replica asincrona potrebbe essere una soluzione Cluster all-MariaDB che si estende su più datacenter.
Come affermato all'inizio di questo blog, MariaDB Cluster, proprio come ogni Il cluster basato su Galera sarà influenzato dall'elevata latenza. Detto questo, è perfettamente accettabile eseguirlo in ambienti con latenza "non così alta" e aspettarsi che si comporti correttamente, offrendo prestazioni accettabili. Tutto dipende dalla velocità effettiva e dal design della rete, dalla distanza tra i data center e dai requisiti dell'applicazione. Un tale approccio funzionerà alla grande soprattutto se utilizziamo i segmenti per differenziare data center separati. Consente a MariaDB Cluster di ottimizzare la connettività all'interno del cluster e di ridurre al minimo il traffico cross-DC.
Il vantaggio principale di questa configurazione è che si basa su MariaDB Cluster per gestire gli errori. Se utilizzi tre data center, sei praticamente coperto dalla situazione del cervello diviso:finché c'è una maggioranza, continuerà a funzionare. Non è necessario disporre di un nodo completo nel terzo datacenter:puoi anche utilizzare Galera Arbitrator, un demone che funge da parte del cluster ma non deve gestire alcuna operazione di database. Si collega ai nodi, partecipa al calcolo del quorum e può essere utilizzato per inoltrare il traffico nel caso in cui la connessione diretta tra i due data center non dovesse funzionare.
In tal caso l'intero processo di failover può essere descritto come:definire tutti i nodi nei sistemi di bilanciamento del carico (tutti se i data center sono vicini tra loro, in altri casi potresti voler aggiungere una priorità per il nodi situati più vicino al sistema di bilanciamento del carico) e questo è praticamente tutto. I nodi MariaDB Cluster che costituiscono la maggioranza saranno raggiungibili tramite qualsiasi proxy.
Distribuzione di un cluster MariaDB multi-cloud utilizzando ClusterControl
Diamo un'occhiata a due opzioni che puoi utilizzare per distribuire cluster MariaDB multi-cloud utilizzando ClusterControl. Tieni presente che ClusterControl richiede la connettività SSH a tutti i nodi che gestirà, quindi spetterà a te garantire la connettività di rete tra più data center o provider di servizi cloud. Finché c'è la connettività, possiamo procedere con due metodi.
Distribuzione di cluster MariaDB utilizzando la replica asincrona
ClusterControl può aiutarti a distribuire due cluster connessi utilizzando la replica asincrona. Quando si dispone di un singolo cluster MariaDB distribuito, si desidera assicurarsi che uno dei nodi abbia i log binari abilitati. Ciò ti consentirà di utilizzare quel nodo come master per il secondo cluster che creeremo a breve.
Una volta abilitato il log binario, possiamo utilizzare il lavoro Crea cluster slave per avviare la procedura guidata di distribuzione.
Possiamo eseguire lo streaming dei dati direttamente dal master oppure puoi utilizzarne uno dei backup per fornire i dati.
Quindi ti viene presentata una procedura guidata di distribuzione del cluster standard in cui devi passare Dettagli sulla connettività SSH.
Ti verrà chiesto di scegliere anche il fornitore e la versione dei database come richiesto per la password per l'utente root.
Infine, ti viene chiesto di definire i nodi che vorresti aggiungere al cluster e sei a posto.
Una volta distribuito, lo vedrai nell'elenco dei cluster nel Interfaccia utente di ClusterControl.
Distribuzione del cluster MariaDB multi-cloud
Come accennato in precedenza, un'altra opzione per distribuire MariaDB Cluster sarebbe quella di utilizzare segmenti separati quando si aggiungono nodi al cluster. Nell'interfaccia utente di ClusterControl troverai un'opzione per "Aggiungi nodo":
Quando lo usi, ti verrà presentata la seguente schermata:
Il segmento predefinito è 0, quindi vuoi cambiarlo con un valore diverso .
Dopo che i nodi sono stati aggiunti, puoi controllare in quale segmento si trovano guardando la scheda Panoramica:
Conclusione
Ci auguriamo che questo breve blog ti abbia fornito una migliore comprensione delle opzioni disponibili per le distribuzioni multi-cloud MariaDB Cluster e di come possono essere utilizzate per garantire un'elevata disponibilità della tua infrastruttura di database.
