La distribuzione di un cluster di database non è scienza missilistica:ci sono molte istruzioni su come farlo. Ma come fai a sapere che ciò che hai appena distribuito è pronto per la produzione? Anche le distribuzioni manuali possono essere noiose e ripetitive. A seconda del numero di nodi nel cluster, i passaggi di distribuzione potrebbero richiedere molto tempo e soggetti a errori. Gli strumenti di gestione della configurazione come Puppet, Chef e Ansible sono popolari nella distribuzione dell'infrastruttura, ma per i cluster di database con stato è necessario eseguire script significativi per gestire la distribuzione dell'intero stack HA del database. Inoltre, il modello/modulo/ricettario/ruolo scelto deve essere testato meticolosamente prima che tu possa considerarlo affidabile come parte dell'automazione della tua infrastruttura. Le modifiche alla versione richiedono l'aggiornamento e il test di nuovo degli script.
La buona notizia è che ClusterControl automatizza le implementazioni dell'intero stack, e anche gratuitamente! Abbiamo distribuito migliaia di cluster di produzione e adottato una serie di precauzioni per assicurarci che siano pronti per la produzione Sono supportate diverse topologie, dalla replica master-slave al cluster Galera, NDB e InnoDB, con diversi proxy di database in cima.
Uno stack ad alta disponibilità, distribuito tramite ClusterControl, è costituito da tre livelli:
- Livello database (ad es. Galera Cluster)
- Livello proxy inverso (ad es. HAProxy o ProxySQL)
- Livello Keepalived, che, con l'uso di Virtual IP, garantisce un'elevata disponibilità del livello proxy
In questo blog, ti mostreremo come distribuire un cluster Galera di livello produttivo completo di bilanciatori del carico per la configurazione ad alta disponibilità. La configurazione completa è composta da 6 host:
- 1 host - ClusterControl (distribuzione, monitoraggio, server di gestione)
- 3 host - MySQL Galera Cluster
- 2 host:i proxy inversi agiscono come bilanciatori di carico davanti al cluster.
Il diagramma seguente illustra il nostro risultato finale una volta completata la distribuzione:
Prerequisiti
ClusterControl deve risiedere su un nodo indipendente che non fa parte del cluster. Scarica ClusterControl e la pagina genererà una licenza univoca per te e mostrerà i passaggi per installare ClusterControl:
$ wget -O install-cc https://severalnines.com/scripts/install-cc
$ chmod +x install-cc
$ ./install-cc # as root or sudo userSegui le istruzioni in cui verrai guidato con la configurazione del server MySQL, la password root MySQL sul nodo ClusterControl, la password cmon per l'utilizzo di ClusterControl e così via. Dovresti ottenere la seguente riga una volta completata l'installazione:
Determining network interfaces. This may take a couple of minutes. Do NOT press any key.
Public/external IP => http://{public_IP}/clustercontrol
Installation successful. If you want to uninstall ClusterControl then run install-cc --uninstall.Quindi, sul server ClusterControl, generare una chiave SSH che utilizzeremo per configurare l'SSH senza password in seguito. Puoi utilizzare qualsiasi utente nel sistema, ma deve avere la capacità di eseguire operazioni da superutente (sudoer). In questo esempio, abbiamo selezionato l'utente root:
$ whoami
root
$ ssh-keygen -t rsaConfigura SSH senza password su tutti i nodi che desideri monitorare/gestire tramite ClusterControl. In questo caso, lo configureremo su tutti i nodi nello stack (incluso il nodo ClusterControl stesso). Sul nodo ClusterControl, eseguire i seguenti comandi e specificare la password di root quando richiesto:
$ ssh-copy-id [email protected] # clustercontrol
$ ssh-copy-id [email protected] # galera1
$ ssh-copy-id [email protected] # galera2
$ ssh-copy-id [email protected] # galera3
$ ssh-copy-id [email protected] # proxy1
$ ssh-copy-id [email protected] # proxy2È quindi possibile verificare se funziona eseguendo il comando seguente sul nodo ClusterControl:
$ ssh [email protected] "ls /root"Assicurati di poter vedere il risultato del comando sopra senza la necessità di inserire la password.
Distribuzione del cluster
ClusterControl supporta tutti i fornitori per Galera Cluster (Codership, Percona e MariaDB). Ci sono alcune piccole differenze che possono influenzare la tua decisione di scegliere il fornitore. Se desideri conoscere le differenze tra loro, dai un'occhiata al nostro precedente post sul blog - Galera Cluster Comparison - Codership vs Percona vs MariaDB.
Per la distribuzione in produzione, un cluster Galera a tre nodi è il minimo che dovresti avere. Puoi sempre ridimensionarlo in un secondo momento, una volta distribuito il cluster, manualmente o tramite ClusterControl. Apriremo la nostra interfaccia utente ClusterControl all'indirizzo https://192.168.55.160/clustercontrol e creeremo il primo utente amministratore. Quindi, vai al menu in alto e fai clic su Distribuisci -> MySQL Galera e ti verrà presentata la seguente finestra di dialogo:
Ci sono due passaggi, il primo è "Impostazioni generali e SSH". Qui è necessario configurare l'utente SSH che ClusterControl deve utilizzare per connettersi ai nodi del database, insieme al percorso della chiave SSH (generata nella sezione Prerequisiti) e alla porta SSH dei nodi del database. ClusterControl presuppone che tutti i nodi del database siano configurati con lo stesso utente, chiave e porta SSH. Quindi, dai un nome al cluster, in questo caso useremo "MySQL Galera Cluster 5.7". Questo valore può essere modificato in seguito. Quindi selezionare le opzioni per indicare a ClusterControl di installare il software richiesto, disabilitare il firewall e disabilitare anche il modulo di miglioramento della sicurezza sulla particolare distribuzione Linux. Si consiglia di attivare tutti questi elementi per massimizzare il potenziale di un'implementazione di successo.
Fai clic su Continua e ti verrà presentata la seguente finestra di dialogo:
Nel passaggio successivo, dobbiamo configurare i server di database - fornitore, versione, datadir, porta, ecc. - che sono abbastanza autoesplicativi. "Modello di configurazione" è il nome del file del modello in /usr/share/cmon/templates del nodo ClusterControl. "Repository" è il modo in cui ClusterControl deve configurare il repository sul nodo del database. Per impostazione predefinita, utilizzerà il repository del fornitore e installerà l'ultima versione fornita dal repository. Tuttavia, in alcuni casi, l'utente potrebbe avere un repository preesistente di cui è stato eseguito il mirroring dal repository originale a causa di una restrizione della politica di sicurezza. Tuttavia, ClusterControl ne supporta la maggior parte, come descritto nella guida per l'utente, in Repository.
Infine, aggiungi l'indirizzo IP o il nome host (deve essere un FQDN valido) dei nodi del database. Vedrai un'icona di spunta verde sulla sinistra del nodo, a indicare che ClusterControl è stato in grado di connettersi al nodo tramite SSH senza password. Ora sei a posto. Fare clic su Distribuisci per avviare la distribuzione. Il completamento dell'operazione potrebbe richiedere da 15 a 20 minuti. Puoi monitorare l'avanzamento della distribuzione in Attività (menu in alto) -> Lavori -> Crea cluster :
Una volta completata la distribuzione, a questo punto, la nostra architettura può essere illustrata come di seguito:
Distribuzione dei bilanciatori di carico
In Galera Cluster, tutti i nodi sono uguali:ogni nodo ha lo stesso ruolo e lo stesso set di dati. Pertanto, non è presente alcun failover all'interno del cluster in caso di errore di un nodo. Solo il lato applicazione richiede il failover, per ignorare i nodi non operativi mentre il cluster è partizionato. Pertanto, si consiglia vivamente di posizionare i bilanciatori del carico sopra un cluster Galera per:
- Unifica più endpoint del database in un unico endpoint (host del servizio di bilanciamento del carico o indirizzo IP virtuale come endpoint).
- Bilancia le connessioni al database tra i server del database back-end.
- Esegui controlli di integrità e inoltra le connessioni al database solo a nodi integri.
- Reindirizzare/riscrivere/bloccare le query (scritte in modo errato) prima che raggiungano i server del database.
Esistono tre scelte principali di proxy inverso per Galera Cluster - HAProxy, MariaDB MaxScale o ProxySQL - tutti possono essere installati e configurati automaticamente da ClusterControl. In questa distribuzione, abbiamo scelto ProxySQL perché controlla tutto quanto sopra e comprende il protocollo MySQL dei server back-end.
In questa architettura, vogliamo utilizzare due server ProxySQL per eliminare qualsiasi singolo punto di errore (SPOF) al livello di database, che sarà collegato insieme utilizzando un indirizzo IP virtuale mobile. Lo spiegheremo nella prossima sezione. Un nodo fungerà da proxy attivo e l'altro da hot-standby. Qualunque nodo che detiene l'indirizzo IP virtuale in un dato momento è il nodo attivo.
Per distribuire il primo server ProxySQL, vai semplicemente al menu delle azioni del cluster (a destra della barra di riepilogo) e fai clic su Aggiungi Load Balancer -> ProxySQL -> Deploy ProxySQL e vedrai quanto segue:
Anche in questo caso, la maggior parte dei campi si spiega da sé. Nella sezione "Utente database", ProxySQL funge da gateway attraverso il quale l'applicazione si connette al database. L'applicazione si autentica su ProxySQL, quindi devi aggiungere tutti gli utenti da tutti i nodi MySQL di back-end, insieme alle loro password, in ProxySQL. Da ClusterControl, puoi creare un nuovo utente che sarà utilizzato dall'applicazione:puoi decidere il suo nome, la password, l'accesso a quali database sono concessi e quali privilegi MySQL avrà quell'utente. Tale utente verrà creato sia sul lato MySQL che ProxySQL. La seconda opzione, più adatta alle infrastrutture esistenti, consiste nell'utilizzare gli utenti del database esistenti. Devi passare nome utente e password e tale utente verrà creato solo su ProxySQL.
L'ultima sezione, "Transazione implicita", ClusterControl configurerà ProxySQL per inviare tutto il traffico al master se abbiamo avviato la transazione con SET autocommit=0. In caso contrario, se si utilizza BEGIN o START TRANSACTION per creare una transazione, ClusterControl configurerà la suddivisione in lettura/scrittura nelle regole di query. Questo per garantire che ProxySQL gestisca correttamente le transazioni. Se non hai idea di come la tua applicazione riesca a farlo, puoi scegliere quest'ultima.
Ripetere la stessa configurazione per il secondo nodo ProxySQL, ad eccezione del valore "Indirizzo server" che è 192.168.55.182. Una volta terminato, entrambi i nodi verranno elencati nella scheda "Nodi" -> ProxySQL dove puoi monitorarli e gestirli direttamente dall'interfaccia utente:
A questo punto, la nostra architettura si presenta così:
Se desideri saperne di più su ProxySQL, dai un'occhiata a questo tutorial - Bilanciamento del carico del database per MySQL e MariaDB con ProxySQL - Tutorial.
Distribuzione dell'indirizzo IP virtuale
La parte finale è l'indirizzo IP virtuale. Senza di esso, i nostri sistemi di bilanciamento del carico (proxy inversi) sarebbero l'anello debole in quanto sarebbero un singolo punto di errore, a meno che l'applicazione non abbia la capacità di reindirizzare automaticamente le connessioni al database non riuscite a un altro sistema di bilanciamento del carico. Tuttavia, è buona norma unificarli entrambi utilizzando l'indirizzo IP virtuale e semplificare l'endpoint di connessione al livello del database.
Da Interfaccia utente di ClusterControl -> Aggiungi Load Balancer -> Keepalived -> Distribuisci Keepalived e seleziona i due host ProxySQL che abbiamo distribuito:
Specificare inoltre l'indirizzo IP virtuale e l'interfaccia di rete per associare l'indirizzo IP. L'interfaccia di rete deve esistere su entrambi i nodi ProxySQL. Una volta distribuito, dovresti vedere i seguenti segni di spunta verdi nella barra di riepilogo del cluster:
A questo punto, la nostra architettura può essere illustrata come di seguito:
Il nostro cluster di database è ora pronto per l'utilizzo in produzione. Puoi importare il tuo database esistente in esso o creare un nuovo database nuovo. Puoi utilizzare la funzionalità Gestione schemi e utenti se la licenza di prova non è scaduta.
Per capire come ClusterControl configura Keepalived, dai un'occhiata a questo post del blog, Come ClusterControl configura l'IP virtuale e cosa aspettarsi durante il failover.
Connessione al cluster di database
Dal punto di vista dell'applicazione e del client, devono connettersi a 192.168.55.180 sulla porta 6033 che è l'indirizzo IP virtuale mobile sopra i sistemi di bilanciamento del carico. Ad esempio, la configurazione del database di Wordpress sarà simile a questa:
/** The name of the database for WordPress */
define( 'DB_NAME', 'wp_myblog' );
/** MySQL database username */
define( 'DB_USER', 'wp_myblog' );
/** MySQL database password */
define( 'DB_PASSWORD', 'mysecr3t' );
/** MySQL hostname - virtual IP address with ProxySQL load-balanced port*/
define( 'DB_HOST', '192.168.55.180:6033' );Se desideri accedere direttamente al cluster di database, bypassando il sistema di bilanciamento del carico, puoi semplicemente connetterti alla porta 3306 degli host del database. Questo è solitamente richiesto dal personale DBA per l'amministrazione, la gestione e la risoluzione dei problemi. Con ClusterControl, la maggior parte di queste operazioni può essere eseguita direttamente dall'interfaccia utente.
Pensieri finali
Come mostrato sopra, la distribuzione di un cluster di database non è più un compito difficile. Una volta implementato, è disponibile una suite completa di funzionalità di monitoraggio gratuite, nonché funzionalità commerciali per la gestione del backup, il failover/ripristino e altro. La rapida distribuzione di diversi tipi di topologie di cluster/replica può essere utile quando si valutano soluzioni di database ad alta disponibilità e come si adattano al proprio ambiente particolare.
