Nel nostro blog precedente, abbiamo discusso di ClusterControl CMON HA for Distributed Database High Availability scritto da Krzysztof Ksiazek in due post separati. In questo blog tratteremo la distribuzione dei nodi tramite locale e su un cloud pubblico (tramite Google Cloud Platform (GCP)).
Il motivo per cui abbiamo scritto questo blog è perché abbiamo ricevuto domande su come implementare un'istanza ad alta disponibilità di ClusterControl con nodi CMON in esecuzione in locale e altri nodi CMON in esecuzione su un data center diverso (come un cloud pubblico). Nel nostro precedente blog ClusterControl CMON HA for Distributed Database High Availability, stavamo utilizzando i nodi Galera Cluster, ma questa volta utilizzeremo la replica MySQL utilizzando Percona Server 5.7. Una configurazione ideale per questo è incapsulare sempre la comunicazione dei nodi dal tuo locale e i tuoi nodi che risiedono in un cloud pubblico tramite VPN o un canale sicuro.
ClusterControl CMON HA è nelle fasi iniziali per cui riteniamo non sia ancora abbastanza maturo. Tuttavia, il nostro CMON HA è in grado di fornire il senso della funzionalità per la distribuzione di ClusterControl per renderlo altamente disponibile. Procediamo su come eseguire il deployment e la configurazione distribuendo i nodi in locale attraverso il cloud pubblico.
Cos'è un CMON?
Prima di passare all'argomento principale, ti presentiamo cos'è CMON. CMON sta per ClusterControl Controller, che è il "cervello primario" di ClusterControl. Un servizio di back-end che esegue l'automazione, la gestione, il monitoraggio delle attività di pianificazione e anche la disponibilità dell'HA. I dati raccolti vengono archiviati nel database CMON, per il quale utilizziamo database compatibili con MySQL come datastore.
La configurazione architettonica
Alcuni di voi potrebbero non conoscere le capacità di ClusterControl che può eseguire ed essere configurato per l'alta disponibilità. Se sono in esecuzione più nodi ClusterControl (o CMON), ciò è possibile senza alcun costo. Potresti essere in grado di eseguire tonnellate di nodi ClusterControl ogni volta che ne hai bisogno.
Per questa configurazione, avremo nodi ClusterControl sopra un ClusterControl per creare o distribuire i nodi del database e gestire un failover automatico ogni volta che si verifica un errore, ad esempio. Anche se puoi usare MHA, Orchestrator o Maxscale per gestire il failover automatico, ma per efficienza e velocità, userò ClusterControl per fare le cose speciali che altri strumenti che ho menzionato non hanno.
Quindi diamo un'occhiata al diagramma per questa configurazione:
L'impostazione basata su quel diagramma mostra che sopra CMON a tre nodi , un CMON (ClusterControl) in esecuzione è sopra di loro che monitorerà il failover automatico. Quindi, HAProxy sarà in grado di bilanciare il carico tra i tre nodi CMON monitorati, in cui un nodo si trova in un'area separata ospitata in GCP per questo blog. Potresti notare che non abbiamo incluso Keepalived, perché non possiamo inserire un VIP in GCP poiché si trova su una rete diversa.
Come avrai notato, posizioniamo un totale di tre nodi. CMON HA richiede che siano necessari almeno 3 nodi per poter procedere a un processo di votazione o cosiddetto quorum. Pertanto, per questa configurazione, è necessario disporre di almeno 3 nodi per avere una maggiore disponibilità.
Distribuzione di un nodo ClusterControl in locale
In questa sezione, ci aspettiamo che tu abbia già configurato o installato la tua interfaccia utente ClusterControl che utilizzeremo per distribuire un cluster di replica MySQL a tre nodi utilizzando Percona Server.
Prima creiamo il cluster distribuendo una nuova replica MySQL come mostrato di seguito.
Tieni presente che sto usando Percona Server 5.7 qui, per il quale l'impostazione predefinita la configurazione di ClusterControl funziona in modo efficiente.
Quindi definisci il nome host o l'IP dei tuoi nodi,
A questo punto, ci aspettiamo che tu abbia già impostato un nodo a due Replica master/slave ospitata o in esecuzione in locale. Lo screenshot qui sotto dovrebbe mostrare come appariranno i tuoi nodi:
Imposta e installa ClusterControl e abilita CMON HA sul primo nodo
Da questo blog precedente ClusterControl CMON HA for Distributed Database High Availability, abbiamo fornito brevemente i passaggi su come eseguire questa operazione. Scendiamo di nuovo ed eseguiamo i passaggi come indicato, ma per questa particolare configurazione di replica Master/Slave.
Prima cosa da fare, scegli un nodo su cui vuoi che venga installato per primo ClusterControl (su questa configurazione, finisco per installare prima il nodo 192.168.70.80) ed esegui i passaggi seguenti.
Fase uno
Installa ClusterControl
$ wget http://www.severalnines.com/downloads/CMON/install-cc
$ chmod +x install-cc
$ sudo ./install-cc # omit sudo if you run as rootTieni presente che una volta che ti viene richiesto che viene rilevata un'istanza mysql corrente, devi consentire a ClusterControl di utilizzare mysqld esistente in esecuzione poiché questo è uno dei nostri obiettivi qui per CMON HA e per questa configurazione utilizzare il già configurato MySQL.
Fase due
Collega CMON non solo per consentire tramite localhost, ma anche sull'indirizzo IP specifico (dal momento che abiliteremo HA)
## edit /etc/default/CMON and modify the line just like below or add the line if it doesn't exist
RPC_BIND_ADDRESSES="127.0.0.1,192.168.70.80"Fase tre
Quindi riavvia CMON,
service CMON restartFase quattro
Installa gli strumenti CLI di s9s
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ chmod 755 install-s9s-tools.sh
$ ./install-s9s-tools.shDurante questa installazione, lo strumento s9s configurerà un utente amministratore per il quale puoi utilizzare quando hai a che fare con il comando s9s, proprio come abilitare CMON HA.
Fase Cinque
Abilita CMON HA
$ s9s controller --enable-CMON-haSesto passo
Infine, modifica /etc/my.cnf e aggiungi,
slave-skip-errors = 1062nella sezione [mysqld]. Una volta aggiunto, non dimenticare di riavviare mysql come,
service mysql restarto
systemctl restart mysqlAttualmente, questa è la limitazione che stiamo affrontando con CMON HA poiché tenta di inserire voci di registro nello slave, ma per ora può andare bene.
Imposta, installa ClusterControl e abilita CMON HA sul secondo nodo
Semplice come quello per il primo nodo. Ora, sul 2° nodo (192.168.70.70), dobbiamo eseguire gli stessi passaggi, ma invece dobbiamo apportare alcune modifiche ai passaggi per rendere possibile questo HA.
Fase uno
Copia la configurazione nel 2° nodo (192.168.70.70) dal primo nodo (192.168.70.80)
$ scp -r /etc/CMON* 192.168.70.70:/etc/Fase due
Nel 2° nodo, modifica /etc/CMON.cnf e assicurati che l'host sia configurato correttamente. es.
vi /etc/CMON.cnfQuindi assegna hostname param as,
nomehost=192.168.70.70
Fase tre
Installa ClusterControl
$ wget http://www.severalnines.com/downloads/CMON/install-cc
$ chmod +x install-cc
$ sudo ./install-cc # omit sudo if you run as rootTuttavia, salta l'installazione di CMON (o ClusterControl Controller) una volta che incontri questa linea,
=> An existing Controller installation detected!
=> A re-installation of the Controller will overwrite the /etc/CMON.cnf file
=> Install the Controller? (y/N):Il resto, fai come hai fatto sul primo nodo come impostare il nome host, usa l'istanza in esecuzione mysqld esistente, fornendo la password MySQL e la password per il tuo CMON che deve essere entrambi hanno la stessa password con il primo nodo.
Fase quattro
Installa gli strumenti CLI di s9s
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ chmod 755 install-s9s-tools.sh
$ ./install-s9s-tools.shFase Cinque
Copia la configurazione rimanente dal 1° nodo al 2° nodo.
$ scp -r ~/.s9s/ 192.168.70.70:/root/
$ scp /etc/s9s.conf 192.168.70.70:/etc/
$ scp /var/www/html/clustercontrol/bootstrap.php 192.168.70.70:/var/www/html/clustercontrol/Sesto passo
Installa il pacchetto clustercontrol-controller,
Per Ubuntu/Debian,
$ apt install -y clustercontrol-controllerPer RHEL/CentOS/Fedora,
$ yum install -y clustercontrol-controllerPasso sette
Copia il file /etc/default/CMON e modifica l'indirizzo IP per l'indirizzo di rilegatura RPC
scp /etc/default/CMON 192.168.70.70:/etc/default
RPC_BIND_ADDRESSES="127.0.0.1,10.0.0.103"Quindi riavvia CMON come segue,
service CMON restartPasso otto
Modifica /etc/my.cnf e aggiungi,
slave-skip-errors = 1062nella sezione [mysqld]. Una volta aggiunto, non dimenticare di riavviare mysql come,
service mysql restarto
systemctl restart mysqlAttualmente, questa è la limitazione che stiamo affrontando con CMON HA poiché tenta di inserire voci di registro nello slave, ma per ora può andare bene.
Fase nove
Infine, controlla come appaiono i nodi CMON HA,
[[email protected] ~]# s9s controller --list --long
S VERSION OWNER GROUP NAME IP PORT COMMENT
l 1.7.5.3735 system admins 192.168.70.80 192.168.70.80 9501 Acting as leader.
f 1.7.5.3735 system admins 192.168.70.70 192.168.70.70 9501 Accepting heartbeats.
Total: 2 controller(s)Distribuzione del nodo ClusterControl nel cloud
Come accennato in precedenza, la configurazione ideale per la comunicazione consiste nell'incapsulare i pacchetti tramite la VPN o altri mezzi di canale sicuro. Se hai dubbi su come farlo, controlla il nostro blog precedente Multi-DC PostgreSQL:configurazione di un nodo di standby in una posizione geografica diversa su una VPN per il quale abbiamo affrontato come creare una semplice configurazione VPN utilizzando OpenVPN.
Quindi, in questa sezione, ci aspettiamo che tu abbia già impostato la connessione VPN. Ora, quello che faremo è aggiungere uno slave che dovremmo distribuire la disponibilità di CMON in Google Cloud Platform. Per fare ciò, vai su Aggiungi slave di replica che può essere trovato facendo clic sull'icona del cluster nell'angolo destro. Guarda come appare di seguito:
Ora, ecco come ci ritroveremo:
Ora, poiché abbiamo aggiunto un nuovo slave che è ospitato sotto GCP, potrebbe essere necessario seguire di nuovo ciò che abbiamo fatto in precedenza sul 2° nodo. Ti indicherò di seguire questi passaggi e seguire le istruzioni su come abbiamo fatto sul 2° nodo.
Una volta che lo avrai correttamente, otterrai il seguente risultato:
[[email protected] ~]# s9s controller --list --long
S VERSION OWNER GROUP NAME IP PORT COMMENT
l 1.7.5.3735 system admins 192.168.70.80 192.168.70.80 9501 Acting as leader.
f 1.7.5.3735 system admins 192.168.70.70 192.168.70.70 9501 Accepting heartbeats.
f 1.7.5.3735 system admins 10.142.0.39 10.142.0.39 9501 Accepting heartbeats.dove nei nodi
- 192.168.70.80 - (node8) e risiede nel mio locale
- 192.168.70.70 - (node7) e risiede nel mio locale
- 10.142.0.39 - (gnode1) è ospitato in GCP e in diverse regioni
CMON HA in azione
Il mio collega Krzysztof Ksiazek ha già fornito la configurazione per HA utilizzando HAProxy qui su questo blog ClusterControl CMON HA per Distributed Database High Availability - Part Two (GUI Access Setup).
Per seguire la procedura indicata nel blog, assicurati di avere i pacchetti xinetd e pathlib. Puoi installare xinetd e pathlib come segue,
$ sudo yum install -y xinetd python-pathlib.noarchAssicurati anche di avere il CMONhachk definito in /etc/services proprio come di seguito:
[[email protected] ~]# grep 'CMONhachk' /etc/services
CMONhachk 9201/tcpe assicurati le modifiche e riavvia xinetd,
service xinetd restartSalto la procedura Keepalived e HAProxy e mi aspetto che tu abbia impostato di conseguenza. Un aspetto che devi considerare su questa configurazione è che l'uso di Keepalived non può essere applicabile se stai disperdendo il VIP dalla rete locale alla rete cloud pubblica perché sono una rete completamente diversa.
Ora, vediamo come reagisce CMON HA se i nodi sono inattivi. Come mostrato in precedenza, il nodo 192.168.70.80 (nodo8), fungeva da leader proprio come mostrato di seguito:
Dove il database del nodo master mostra anche che node8 è il master dalla vista topologia ClusterControl . Proviamo a uccidere node8 e vediamo come procede CMON HA,
Come vedi, gnode1 (nodo GCP) sta assumendo il ruolo di leader quando il nodo 8 va giù. Verifica dei risultati HAProxy a quanto segue,
e i nostri nodi ClusterControl mostrano che node8 è inattivo, mentre il nodo GCP sta prendendo oltre come il maestro,
Infine, accedendo al mio nodo HAProxy in esecuzione sull'host 192.168.10.100 all'indirizzo la porta 81 mostra la seguente interfaccia utente,
Conclusione
Il nostro ClusterControl CMON HA esiste dalla versione 1.7.2, ma è stata anche una sfida per noi a causa di varie domande e preferenze su come implementarlo, come l'utilizzo di MySQL Replication su Galera Cluster.
Il nostro CMON HA non è ancora maturo ma è ora pronto per soddisfare le tue esigenze di alta disponibilità. Approcci diversi possono essere applicabili purché i tuoi controlli determinino il nodo giusto che è attivo e funzionante.
Ti incoraggiamo a configurare e distribuire utilizzando CMON HA e facci sapere se si adatta alle tue esigenze o se il problema persiste, facci sapere come aiutarti a soddisfare le tue esigenze di alta disponibilità.
