I vår tidigare blogg har vi diskuterat ClusterControl CMON HA för Distribuerad Databas High Availability skriven av Krzysztof Ksiazek i två separata inlägg. I den här bloggen kommer vi att täcka distributionen av noder via lokalt och på ett offentligt moln (med hjälp av Google Cloud Platform (GCP)).
Anledningen till att vi skrev den här bloggen är för att vi har fått frågor om hur man implementerar en högtillgänglighetsinstans av ClusterControl med CMON-nod(er) som körs på plats och en annan CMON-nod(er) körs på en olika datacenter (som ett offentligt moln). I vår tidigare blogg ClusterControl CMON HA för Distributed Database High Availability använde vi Galera Cluster-noder, men den här gången kommer vi att använda MySQL-replikering med Percona Server 5.7. En idealisk inställning för detta är att alltid kapsla in kommunikationen av noder från din on-prem och dina noder som finns i ett offentligt moln via VPN eller en säker kanal.
ClusterControl CMON HA befinner sig i ett tidigt skede som vi tror att det ännu inte är tillräckligt mogen för. Ändå kan vår CMON HA ge dig känslan av funktionalitet för att distribuera en ClusterControl för att göra den mycket tillgänglig. Låt oss gå vidare med hur du kan distribuera och konfigurera distribution av noderna via lokalt via det offentliga molnet.
Vad är en CMON?
Innan vi går till huvudämnet, låt oss presentera för dig vad CMON är. CMON står för ClusterControl Controller, som är den "primära hjärnan" i ClusterControl. En backend-tjänst som utför automatisering, hantering, övervakning av schemaläggningsuppgifter och även HA-tillgängligheten. Data som samlas in lagras i CMON-databasen, för vilken vi använder MySQL-kompatibla databaser som datalager.
Arkitekturinställningen
En del av er kanske inte kände till ClusterControls funktioner som den kan utföra och ställas in för hög tillgänglighet. Om du har flera ClusterControl-noder (eller CMON) igång, är det möjligt utan kostnad. Du kanske kan köra massor av ClusterControl-noder när du behöver.
För den här inställningen kommer vi att ha ClusterControl-noder ovanpå en ClusterControl för att skapa eller distribuera databasnoderna och hantera en automatisk failover närhelst ett fel inträffar, till exempel. Även om du kan använda MHA, Orchestrator eller Maxscale för att hantera auto-failoveren, men för effektivitet och hastighet kommer jag att använda ClusterControl för att göra de speciella saker som andra verktyg som jag har nämnt inte har.
Så låt oss ta en titt på diagrammet för denna inställning:
Inställningen baserad på det diagrammet visar att ovanpå trenods CMON , en körande CMON (ClusterControl) finns ovanpå dem som kommer att övervaka den automatiska failover. Sedan kommer HAProxy att kunna ladda balans mellan de tre övervakade CMON-noderna, där en nod är belägen i en separat region som är värd i GCP för den här bloggen. Du kanske märker att vi inte inkluderade Keepalived, det beror på att vi inte kan placera en VIP under GCP eftersom den är på ett annat nätverk.
Som du kanske har märkt placerar vi totalt tre noder. CMON HA kräver att vi behöver minst 3 noder för att kunna fortsätta en omröstningsprocess eller så kallat quorum. Så för den här inställningen kräver vi att du har minst 3 noder för att ha högre tillgänglighet.
Distribuera en lokal ClusterControl-noder
I det här avsnittet förväntar vi oss att du redan har konfigurerat eller installerat ditt ClusterControl-gränssnitt som vi kommer att använda för att distribuera ett MySQL-replikeringskluster med tre noder med Percona Server.
Låt oss först skapa klustret genom att distribuera en ny MySQL-replikering som visas nedan.
Observera att jag använder Percona Server 5.7 här, för vilken är standard installationen av ClusterControl fungerar effektivt.
Definiera sedan värdnamnet eller IP-adressen för dina noder,
Vid denna tidpunkt förväntar vi oss att du redan har ställt in en tvånod Master/Slav-replikering som är värd eller körs på plats. Skärmdumpen nedan bör visa hur dina noder kommer att se ut:
Konfigurera och installera ClusterControl och aktivera CMON HA på den första noden
Från den här tidigare bloggen ClusterControl CMON HA för Distributed Database High Availability har vi kortfattat tillhandahållit stegen för hur du gör detta. Låt oss gå ner igen och göra stegen som nämnts utom för just denna Master/Slav-replikeringsinställning.
Första sak att göra, välj en nod som du vill att den första ClusterControl ska installeras (i den här installationen installerar jag först på noden 192.168.70.80) och gör stegen nedan.
Steg ett
Installera ClusterControl
$ wget http://www.severalnines.com/downloads/CMON/install-cc
$ chmod +x install-cc
$ sudo ./install-cc # omit sudo if you run as rootObservera att när du tillfrågas om att en aktuell mysql-instans upptäcks, måste du låta ClusterControl använda den befintliga mysqld som körs eftersom det är ett av våra mål här för CMON HA och för att denna inställning ska använda har redan ställt in MySQL.
Steg två
Bind CMON inte bara för att tillåta via localhost, utan även på den specifika IP-adressen (eftersom vi kommer att aktivera 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"Steg tre
Starta sedan om CMON,
service CMON restartSteg fyra
Installera s9s CLI-verktyg
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ chmod 755 install-s9s-tools.sh
$ ./install-s9s-tools.shUnder den här installationen kommer s9s-verktyget att ställa in en administratörsanvändare som du kan använda för när du hanterar s9s-kommandot, precis som att aktivera CMON HA.
Steg fem
Aktivera CMON HA
$ s9s controller --enable-CMON-haSteg sex
Ändra slutligen /etc/my.cnf och lägg till,
slave-skip-errors = 1062under avsnittet [mysqld]. När du har lagt till, glöm inte att starta om mysql as,
service mysql restarteller
systemctl restart mysqlFör närvarande är detta begränsningen vi står inför med CMON HA eftersom den försöker infoga loggposter till slaven men det här kan vara bra för nu.
Konfigurera, installera ClusterControl och aktivera CMON HA på den andra noden
Enkelt som det för den första noden. Nu, på den andra noden (192.168.70.70), måste vi göra samma steg men istället måste vi göra några justeringar i stegen för att göra denna HA möjlig.
Steg ett
Kopiera konfigurationen till den andra noden (192.168.70.70) från den första noden (192.168.70.80)
$ scp -r /etc/CMON* 192.168.70.70:/etc/Steg två
I den andra noden, redigera /etc/CMON.cnf och se till att värden är korrekt konfigurerad. t.ex.
vi /etc/CMON.cnfTilldela sedan värdnamnet param som,
värdnamn=192.168.70.70
Steg tre
Installera ClusterControl,
$ wget http://www.severalnines.com/downloads/CMON/install-cc
$ chmod +x install-cc
$ sudo ./install-cc # omit sudo if you run as rootHoppa dock över installationen av CMON (eller ClusterControl Controller) när du stöter på den här raden,
=> An existing Controller installation detected!
=> A re-installation of the Controller will overwrite the /etc/CMON.cnf file
=> Install the Controller? (y/N):Resten, gör bara som du har gjort på den första noden som att ställa in värdnamnet, använd den befintliga mysqld-körningsinstansen, ange MySQL-lösenordet och lösenordet för din CMON som måste vara båda har samma lösenord som den första noden.
Steg fyra
Installera s9s CLI-verktyg
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ chmod 755 install-s9s-tools.sh
$ ./install-s9s-tools.shSteg fem
Kopiera den återstående konfigurationen från den första noden till den andra noden.
$ 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/Steg sex
Installera klusterkontroll-kontrollerpaket,
För Ubuntu/Debian,
$ apt install -y clustercontrol-controllerFör RHEL/CentOS/Fedora,
$ yum install -y clustercontrol-controllerSteg sju
Kopiera /etc/default/CMON-filen och ändra IP-adressen för RPC-bindningsadressen
scp /etc/default/CMON 192.168.70.70:/etc/default
RPC_BIND_ADDRESSES="127.0.0.1,10.0.0.103"Starta sedan om CMON enligt följande,
service CMON restartSteg åtta
Ändra /etc/my.cnf och lägg till,
slave-skip-errors = 1062under avsnittet [mysqld]. När du har lagt till, glöm inte att starta om mysql as,
service mysql restarteller
systemctl restart mysqlFör närvarande är detta begränsningen vi står inför med CMON HA eftersom den försöker infoga loggposter till slaven men det här kan vara bra för nu.
Steg nio
Slutligen, kolla hur CMON HA-noderna ser ut,
[[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)Distribuera din ClusterControl-nod i molnet
Som vi har nämnt tidigare är den idealiska inställningen för kommunikation att kapsla in paketen över VPN eller andra sätt för säker kanal. Om du har funderingar på hur du gör detta, kolla in vår tidigare blogg Multi-DC PostgreSQL:Setting Up a Standby Node at a Different Geo-Location Over a VPN som vi har tagit itu med hur du kan skapa en enkel VPN-inställning med OpenVPN.
Så i det här avsnittet förväntar vi oss att du redan har konfigurerat VPN-anslutningen. Vad vi nu ska göra är att lägga till en slav som vi ska distribuera tillgängligheten för CMON till Google Cloud Platform. För att göra detta, gå bara till Lägg till replikeringsslav som kan hittas genom att klicka på klusterikonen nära det högra hörnet. Se hur det ser ut nedan:
Nu är det så här vi kommer att sluta med:
Nu, eftersom vi har lagt till en ny slav som är värd under GCP, du kan behöva följa igen vad vi gjorde tidigare på den andra noden. Jag kommer att förmedla dig att följa dessa steg och följa instruktionerna om hur vi gjorde på den andra noden.
När du har det korrekt kommer du att få följande resultat:
[[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.var i noder
- 192.168.70.80 - (nod8) och finns på min plats
- 192.168.70.70 - (nod7) och är bosatt på min lokala plats
- 10.142.0.39 - (gnode1) är värd i GCP och i olika regioner
CMON HA i aktion
Min kollega Krzysztof Ksiazek har redan tillhandahållit installationen för HA med HAProxy här på den här bloggen ClusterControl CMON HA för hög tillgänglighet för distribuerad databas - del två (GUI Access Setup).
För att följa proceduren som anges i bloggen, se till att du har paketen xinetd och pathlib. Du kan installera xinetd och pathlib enligt följande,
$ sudo yum install -y xinetd python-pathlib.noarchSe också till att du har CMONhachk definierad i /etc/services precis som nedan:
[[email protected] ~]# grep 'CMONhachk' /etc/services
CMONhachk 9201/tcpoch se till ändringar och starta om xinetd,
service xinetd restartJag hoppar över Keepalived och HAProxy-proceduren och förväntar mig att du har ställt in i enlighet med detta. En sak som du måste tänka på i den här installationen är att användningen av Keepalived inte kan vara tillämplig om du sprider VIP från on-prem till det offentliga molnnätverket eftersom de är ett helt annat nätverk.
Låt oss nu se hur CMON HA reagerar om noderna är nere. Som visats tidigare, fungerade nod 192.168.70.80 (nod8), som en ledare precis som visas nedan:
Där masternodsdatabasen också visar node8 är mastern från ClusterControl-topologivyn . Låt oss försöka döda node8 och se hur CMON HA fortsätter,
Som du ser tar gnode1 (GCP-nod) över som ledare när nod8 går ner. Kontrollerar HAProxy-resultaten till följande,
och våra ClusterControl-noder visar att nod8 är nere, medan GCP-noden tar över som mästare,
Sistligen, åtkomst till min HAProxy-nod som körs på värd 192.168.10.100 på port 81 visar följande användargränssnitt,
Slutsats
Vår ClusterControl CMON HA har funnits sedan version 1.7.2 men det har också varit en utmaning för oss sedan olika frågor och preferenser om hur man distribuerar detta, som att använda MySQL-replikering över Galera Cluster.
Vår CMON HA är inte mogen än men den är nu redo att tillgodose dina höga tillgänglighetsbehov. Olika tillvägagångssätt kan vara tillämpliga så länge dina kontroller avgör vilken nod som är igång.
Vi uppmuntrar dig att konfigurera och distribuera med CMON HA och låt oss veta hur väl passar dina behov eller om problemet kvarstår, vänligen låt oss veta hur vi kan hjälpa dig att tillgodose dina behov av hög tillgänglighet.