I vores tidligere blog har vi diskuteret ClusterControl CMON HA for Distributed Database High Availability skrevet af Krzysztof Ksiazek i to separate indlæg. I denne blog vil vi dække distributionen af noder via on-prem og på en offentlig sky (ved hjælp af Google Cloud Platform (GCP)).
Grunden til, at vi skrev denne blog, er, fordi vi har modtaget spørgsmål om, hvordan man implementerer en instans med høj tilgængelighed af ClusterControl, hvor CMON-node(r) kører on-prem og en anden CMON-node(r) kører på en andet datacenter (såsom en offentlig sky). I vores tidligere blog ClusterControl CMON HA for Distributed Database High Availability brugte vi Galera Cluster noder, men denne gang vil vi bruge MySQL Replication ved hjælp af Percona Server 5.7. En ideel opsætning til dette er altid at indkapsle kommunikationen af noder fra din on-prem og dine noder, der ligger i en offentlig sky via VPN eller en sikker kanal.
ClusterControl CMON HA er på de tidlige stadier, som vi mener, at den endnu ikke er moden nok til. Alligevel er vores CMON HA i stand til at give dig følelsen af funktionalitet til at implementere en ClusterControl for at gøre den yderst tilgængelig. Lad os fortsætte med, hvordan du kan implementere og konfigurere distribution af noderne via on-prem gennem den offentlige sky.
Hvad er en CMON?
Før vi går til hovedemnet, lad os præsentere dig for, hvad CMON er. CMON står for ClusterControl Controller, som er den "primære hjerne" i ClusterControl. En backend-tjeneste, der udfører automatisering, styring, overvågning af planlægningsopgaver og også tilgængeligheden af HA. Data, der indsamles, gemmes i CMON-databasen, som vi bruger MySQL-kompatible databaser til som datalager.
Den arkitektoniske opsætning
Nogle af jer har måske ikke kendt ClusterControls muligheder, som den kan udføre og konfigureres til høj tilgængelighed. Hvis du har flere ClusterControl (eller CMON) noder kørende, er det muligt uden omkostninger. Du kan muligvis køre tonsvis af ClusterControl-noder, når du har brug for det.
Til denne opsætning har vi ClusterControl-noder oven på en ClusterControl for at oprette eller implementere databasenoderne og administrere en automatisk failover, når der f.eks. opstår en fejl. Selvom du kan bruge MHA, Orchestrator eller Maxscale til at styre auto-failoveren, men for effektivitet og hastighed vil jeg bruge ClusterControl til at gøre de specielle ting, som andre værktøjer, jeg har nævnt, ikke har.
Så lad os se på diagrammet for denne opsætning:
Opsætningen baseret på dette diagram viser, at oven på tre-node CMON , en kørende CMON (ClusterControl) er oven på dem, som vil overvåge den automatiske failover. Derefter vil HAProxy være i stand til at indlæse balance mellem de overvågede tre CMON-noder, hvor en node er placeret i en separat region, der hostes i GCP for denne blog. Du bemærker måske, at vi ikke inkluderede Keepalived, det er fordi vi ikke kan placere en VIP under GCP, da den er på et andet netværk.
Som du måske har bemærket, placerer vi i alt tre noder. CMON HA kræver, at vi har brug for mindst 3 noder for at fortsætte en afstemningsproces eller såkaldt beslutningsdygtighed. Så for denne opsætning kræver vi, at du har mindst 3 noder for at have højere tilgængelighed.
Installation af en lokal ClusterControl-noder
I dette afsnit forventer vi, at du allerede har konfigureret eller installeret din ClusterControl-brugergrænseflade, som vi vil bruge til at implementere en MySQL-replikeringsklynge med tre knudepunkter ved hjælp af Percona Server.
Lad os først oprette klyngen ved at implementere en ny MySQL-replikering som vist nedenfor.
Bemærk, at jeg bruger Percona Server 5.7 her, som er standard opsætning af ClusterControl fungerer effektivt.
Definer derefter værtsnavnet eller IP-adressen for dine noder,
På dette tidspunkt forventer vi, at du allerede har opsat en to-node Master/Slave-replikering, som hostes eller kører lokalt. Skærmbilledet nedenfor skulle vise, hvordan dine noder vil se ud:
Opsæt og installer ClusterControl og aktiver CMON HA på den første node
Fra denne tidligere blog ClusterControl CMON HA for Distributed Database High Availability har vi kort givet trinene til, hvordan du gør dette. Lad os gå ned igen og udføre trinene som angivet, bortset fra denne særlige Master/Slave-replikeringsopsætning.
Først ting du skal gøre, skal du vælge en node, du vil have den første ClusterControl skal installeres (på denne opsætning ender jeg med at installere først på 192.168.70.80 node) og udfør trinene nedenfor.
Trin 1
Installer ClusterControl
$ wget http://www.severalnines.com/downloads/CMON/install-cc
$ chmod +x install-cc
$ sudo ./install-cc # omit sudo if you run as rootBemærk, at når du bliver bedt om, at en aktuel mysql-instans er fundet, skal du lade ClusterControl bruge den eksisterende mysqld, der kører, da det er et af vores mål her for CMON HA, og for at denne opsætning skal bruge allerede opsat MySQL.
Trin to
Bind CMON ikke kun for at tillade via localhost, men også på den specifikke IP-adresse (da vi vil aktivere 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"Trin tre
Genstart derefter CMON,
service CMON restartTrin fire
Installer s9s CLI-værktøjer
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ chmod 755 install-s9s-tools.sh
$ ./install-s9s-tools.shUnder denne installation vil s9s-værktøjet opsætte en admin-bruger, som du kan bruge til, når du håndterer s9s-kommando, ligesom at aktivere CMON HA.
Trin fem
Aktiver CMON HA
$ s9s controller --enable-CMON-haTrin seks
Til sidst skal du ændre /etc/my.cnf og tilføje,
slave-skip-errors = 1062under [mysqld]-sektionen. Når først tilføjet, glem ikke at genstarte mysql as,
service mysql restarteller
systemctl restart mysqlI øjeblikket er dette den begrænsning, vi står over for med CMON HA, da den forsøger at indsætte logposter til slaven, men det kan være fint lige nu.
Opsætning, installer ClusterControl og aktiver CMON HA på den anden node
Simpelt som det for den første node. Nu, på den 2. node (192.168.70.70), skal vi udføre de samme trin, men i stedet skal vi lave nogle justeringer i trinene for at gøre denne HA mulig.
Trin 1
Kopiér konfigurationen til den anden node (192.168.70.70) fra første node (192.168.70.80)
$ scp -r /etc/CMON* 192.168.70.70:/etc/Trin to
I den 2. node, rediger /etc/CMON.cnf og sørg for, at værten er korrekt konfigureret. f.eks.
vi /etc/CMON.cnfTildel derefter hostname param som,
værtsnavn=192.168.70.70
Trin tre
Installer ClusterControl,
$ wget http://www.severalnines.com/downloads/CMON/install-cc
$ chmod +x install-cc
$ sudo ./install-cc # omit sudo if you run as rootSpring dog installationen af CMON (eller ClusterControl Controller), når du støder på denne linje,
=> An existing Controller installation detected!
=> A re-installation of the Controller will overwrite the /etc/CMON.cnf file
=> Install the Controller? (y/N):Resten, bare gør som det du har gjort på den første node, såsom at opsætte værtsnavnet, brug den eksisterende mysqld-kørende instans, angiv MySQL-adgangskoden og adgangskoden til din CMON, som skal være begge har samme adgangskode med den første node.
Trin fire
Installer s9s CLI-værktøjer
$ wget http://repo.severalnines.com/s9s-tools/install-s9s-tools.sh
$ chmod 755 install-s9s-tools.sh
$ ./install-s9s-tools.shTrin fem
Kopiér den resterende konfiguration fra 1. node til 2. node.
$ 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/Trin seks
Installer clustercontrol-controller-pakken,
For Ubuntu/Debian,
$ apt install -y clustercontrol-controllerFor RHEL/CentOS/Fedora,
$ yum install -y clustercontrol-controllerTrin syv
Kopiér filen /etc/default/CMON, og rediger IP-adressen for RPC-bindingsadressen
scp /etc/default/CMON 192.168.70.70:/etc/default
RPC_BIND_ADDRESSES="127.0.0.1,10.0.0.103"Genstart derefter CMON som følger,
service CMON restartTrin otte
Rediger /etc/my.cnf og tilføj,
slave-skip-errors = 1062under [mysqld]-sektionen. Når først tilføjet, glem ikke at genstarte mysql as,
service mysql restarteller
systemctl restart mysqlI øjeblikket er dette den begrænsning, vi står over for med CMON HA, da den forsøger at indsætte logposter til slaven, men det kan være fint lige nu.
Trin ni
Tjek endelig, hvordan CMON HA-knuderne ser ud,
[[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)Deployering af din ClusterControl-node i skyen
Som vi har nævnt tidligere, er den ideelle opsætning til kommunikation at indkapsle pakkerne over VPN eller andre former for sikker kanal. Hvis du har bekymringer om, hvordan du gør dette, så tjek vores tidligere blog Multi-DC PostgreSQL:Opsætning af en standby node på en anden geo-placering over en VPN, som vi har behandlet, hvordan du kan oprette en simpel VPN-opsætning ved hjælp af OpenVPN.
Så i dette afsnit forventer vi, at du allerede har konfigureret VPN-forbindelsen. Nu, hvad vi skal gøre, er at tilføje en slave, som vi skal distribuere tilgængeligheden af CMON til Google Cloud Platform. For at gøre dette skal du blot gå til Tilføj replikeringsslave, som kan findes ved at klikke på klyngeikonet nær højre hjørne. Se, hvordan det ser ud nedenfor:
Nu, sådan ender vi med:
Nu, da vi har tilføjet en ny slave, som hostes under GCP, Det kan være nødvendigt at følge med igen på, hvad vi gjorde tidligere på den 2. knude. Jeg vil videregive dig til at følge disse trin og følge instruktionerne om, hvordan vi gjorde på den anden knude.
Når du har det korrekt, ender du med følgende 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.hvor i noder
- 192.168.70.80 - (node8) og er bosat i min lokale
- 192.168.70.70 - (node7) og er bosat i min lokale
- 10.142.0.39 - (gnode1) er hostet i GCP og i en anden region
CMON HA i aktion
Min kollega Krzysztof Ksiazek leverede allerede opsætningen til HA ved hjælp af HAProxy her på denne blog. ClusterControl CMON HA for Distributed Database High Availability - Part Two (GUI Access Setup).
For at følge proceduren angivet i bloggen skal du sikre dig, at du har xinetd og pathlib-pakker. Du kan installere xinetd og pathlib som følger,
$ sudo yum install -y xinetd python-pathlib.noarchSørg også for, at du har CMONhachk defineret i /etc/services ligesom nedenfor:
[[email protected] ~]# grep 'CMONhachk' /etc/services
CMONhachk 9201/tcpog sørg for ændringer og genstart xinetd,
service xinetd restartJeg springer Keepalived- og HAProxy-proceduren over og forventer, at du har sat op i overensstemmelse hermed. En ting du skal overveje i forbindelse med denne opsætning er, at brugen af Keepalived ikke kan anvendes, hvis du spreder VIP'en fra on-prem til det offentlige cloud-netværk, fordi de er et helt andet netværk.
Lad os nu se, hvordan CMON HA reagerer, hvis noderne er nede. Som vist tidligere fungerede node 192.168.70.80 (node8) som en leder ligesom som vist nedenfor:
Hvor masterknudedatabasen også viser node8 er masteren fra ClusterControl topologivisning . Lad os prøve at dræbe node8 og se, hvordan CMON HA skrider frem,
Som du kan se, tager gnode1 (GCP-node) over som leder som node8 går ned. Kontrollerer HAProxy-resultaterne til følgende,
og vores ClusterControl noder viser, at node8 er nede, mens GCP node tager over som mester,
Til sidst, adgang til min HAProxy node, som kører på vært 192.168.10.100 kl. port 81 viser følgende brugergrænseflade,
Konklusion
Vores ClusterControl CMON HA har eksisteret siden version 1.7.2, men det har også været en udfordring for os siden forskellige spørgsmål og præferencer om, hvordan man implementerer dette, såsom at bruge MySQL Replication over Galera Cluster.
Vores CMON HA er ikke moden endnu, men den er nu klar til at imødekomme dine høje tilgængelighedsbehov. Forskellige tilgange kan være anvendelige, så længe dine checks vil bestemme den rigtige node, der er oppe og køre.
Vi opfordrer dig til at konfigurere og implementere ved hjælp af CMON HA og fortælle os, hvor godt det passer til dine behov, eller hvis problemet fortsætter, så lad os venligst vide, hvordan vi kan hjælpe dig med at imødekomme dine høje tilgængelighedsbehov.