Nel blog precedente della serie abbiamo discusso i pro ei contro dell'utilizzo di Galera Cluster per creare cluster geo-distribuiti. In questo post progetteremo un cluster geodistribuito basato su Galera e mostreremo come distribuire tutti i pezzi necessari utilizzando ClusterControl.
Progettazione di un cluster Galera distribuito geograficamente
Inizieremo spiegando l'ambiente che vogliamo creare. 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 questa configurazione la connettività è a posto e protetta, ma non descriveremo esattamente come ciò può essere ottenuto. Esistono numerosi metodi per proteggere la connettività a partire da soluzioni hardware e software proprietarie tramite OpenVPN e finendo sui tunnel SSH.
Utilizzeremo ProxySQL come loadbalancer. ProxySQL 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. L'applicazione può essere configurata per connettersi a uno dei nodi ProxySQL locali utilizzando l'algoritmo round-robin. Possiamo anche utilizzare Keepalived e Virtual IP per instradare il traffico verso il singolo nodo ProxySQL, purché un singolo nodo ProxySQL sia in grado di gestire tutto il traffico.
Un'altra possibile soluzione consiste nel collocare ProxySQL 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 ProxySQL 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 ProxySQL che l'applicazione allo stesso tempo.
Il diagramma sopra mostra la versione dell'ambiente, su cui è collocato ProxySQL lo stesso nodo dell'applicazione. ProxySQL è configurato per distribuire il carico di lavoro su tutti i nodi Galera 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.
Il problema principale con le distribuzioni geodistribuite di Galera Cluster è la latenza. Questo è qualcosa che devi sempre testare prima di avviare l'ambiente. Sono d'accordo con il tempo di commit? Ad ogni commit la certificazione deve avvenire, quindi i set di scrittura devono essere inviati e certificati su tutti i nodi del cluster, compresi quelli remoti. È possibile che l'elevata latenza riterrà la configurazione inadatta alla tua applicazione. In tal caso potresti trovare più adatti cluster Galera collegati tramite replica asincrona. Questo sarebbe comunque un argomento per un altro post sul blog.
Distribuzione di un cluster Galera distribuito geograficamente utilizzando ClusterControl
Per chiarire le cose, mostreremo qui come potrebbe essere una distribuzione. Non utilizzeremo l'effettiva configurazione multi-DC, tutto verrà distribuito in un lab locale. Partiamo dal presupposto che la latenza sia accettabile e che l'intera configurazione sia praticabile. La cosa fantastica di ClusterControl è che è indipendente dall'infrastruttura. Non importa se i nodi sono vicini tra loro, situati nello stesso data center o se i nodi sono distribuiti su più provider cloud. Finché è presente la connettività SSH dall'istanza ClusterControl a tutti i nodi, il processo di distribuzione ha lo stesso aspetto. Ecco perché possiamo mostrartelo passo dopo passo utilizzando solo il laboratorio locale.
Installazione di ClusterControl
Per prima cosa, devi installare ClusterControl. Puoi scaricarlo gratuitamente. Dopo la registrazione è necessario accedere alla pagina con la guida per scaricare e installare ClusterControl. È semplice come eseguire uno script di shell. Una volta installato ClusterControl, ti verrà presentato un modulo per creare un utente amministrativo:
Una volta compilato, ti verrà presentata una schermata di benvenuto e accedi alle procedure guidate di distribuzione:
Andremo con deploy. Si aprirà una procedura guidata di distribuzione:
Sceglieremo MySQL Galera. Dobbiamo passare i dettagli della connettività SSH:sono supportati sia l'utente root che l'utente sudo. Nel passaggio successivo dobbiamo definire i server nel cluster.
Distribuiremo tre nodi in uno dei data center. Quindi potremo estendere il cluster, configurando nuovi nodi in diversi segmenti. Per ora tutto ciò che dobbiamo fare è fare clic su "Distribuisci" e guardare ClusterControl che distribuisce il cluster Galera.
I nostri primi tre nodi sono attivi, ora possiamo procedere all'aggiunta nodi aggiuntivi in altri data center.
Puoi farlo dal menu delle azioni, come mostrato nella schermata sopra .
Qui possiamo aggiungere altri nodi, uno alla volta. Ciò che è importante, dovresti cambiare il segmento Galera in un valore diverso da zero (0 viene utilizzato per i tre nodi iniziali).
Dopo un po' ci ritroviamo con tutti e nove i nodi, distribuiti su tre segmenti.
Ora dobbiamo distribuire il livello proxy. Useremo ProxySQL per questo. Puoi distribuirlo in ClusterControl tramite Gestisci -> Load Balancer:
Si apre un campo di distribuzione:
Per prima cosa, dobbiamo decidere dove distribuire ProxySQL. Utilizzeremo i nodi Galera esistenti ma puoi digitare qualsiasi cosa sul campo, quindi è perfettamente possibile distribuire ProxySQL sopra i nodi dell'applicazione. Inoltre, devi passare le credenziali di accesso per l'utente amministrativo e di monitoraggio.
Allora dobbiamo scegliere uno degli utenti esistenti in MySQL o crearne uno proprio adesso. Vogliamo anche assicurarci che ProxySQL sia configurato per utilizzare i nodi Galera che si trovano solo nello stesso datacenter.
Quando hai un ProxySQL pronto nel datacenter, puoi usarlo come origine della configurazione:
Questo deve essere ripetuto per ogni server delle applicazioni che hai in tutti i data center . Quindi l'applicazione deve essere configurata per connettersi all'istanza ProxySQL locale, idealmente tramite il socket Unix. Questo viene fornito con le migliori prestazioni e la latenza più bassa.
Dopo che l'ultimo ProxySQL è stato distribuito, il nostro ambiente è pronto. I nodi dell'applicazione si connettono al ProxySQL locale. Ogni ProxySQL è configurato per funzionare con i nodi Galera nello stesso datacenter:
Conclusione
Ci auguriamo che questa serie in due parti ti abbia aiutato a comprendere i punti di forza e di debolezza dei cluster Galera distribuiti geograficamente e come ClusterControl renda molto semplice l'implementazione e la gestione di tali cluster.
