At implementere en databaseklynge er ikke raketvidenskab - der er mange vejledninger til, hvordan man gør det. Men hvordan ved du, at det, du lige har installeret, er produktionsklar? Manuelle implementeringer kan også være kedelige og gentagne. Afhængigt af antallet af noder i klyngen kan implementeringstrinnene være tidskrævende og fejludsatte. Konfigurationsstyringsværktøjer som Puppet, Chef og Ansible er populære til implementering af infrastruktur, men for stateful databaseklynger skal du udføre betydelig scripting for at håndtere implementeringen af hele databasen HA-stakken. Desuden skal den valgte skabelon/modul/kogebog/rolle testes grundigt, før du kan stole på den som en del af din infrastrukturautomatisering. Versionsændringer kræver, at scripts opdateres og testes igen.
Den gode nyhed er, at ClusterControl automatiserer implementeringer af hele stakken - og det er gratis! Vi har implementeret tusindvis af produktionsklynger og tager en række forholdsregler for at sikre, at de er produktionsklare. Forskellige topologier understøttes, fra master-slave-replikering til Galera, NDB og InnoDB-klynge, med forskellige databaseproxyer på toppen.
En høj tilgængelig stak, implementeret gennem ClusterControl, består af tre lag:
- Databaselag (f.eks. Galera Cluster)
- Omvendt proxy-lag (f.eks. HAProxy eller ProxySQL)
- Keepalived lag, som ved brug af Virtual IP sikrer høj tilgængelighed af proxylaget
I denne blog vil vi vise dig, hvordan du implementerer en Galera-klynge i produktionskvalitet komplet med belastningsbalancere til opsætning af høj tilgængelighed. Den komplette opsætning består af 6 værter:
- 1 vært - ClusterControl (implementering, overvågning, administrationsserver)
- 3 værter - MySQL Galera Cluster
- 2 værter – omvendte proxyer fungerer som belastningsbalancer foran klyngen.
Følgende diagram illustrerer vores slutresultat, når implementeringen er fuldført:
Forudsætninger
ClusterControl skal ligge på en uafhængig node, som ikke er en del af klyngen. Download ClusterControl, og siden genererer en unik licens for dig og viser trinene til at installere ClusterControl:
$ wget -O install-cc https://severalnines.com/scripts/install-cc
$ chmod +x install-cc
$ ./install-cc # as root or sudo userFølg instruktionerne, hvor du vil blive guidet med opsætning af MySQL-server, MySQL root-adgangskode på ClusterControl-noden, cmon-adgangskode til ClusterControl-brug og så videre. Du bør få følgende linje, når installationen er fuldført:
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.Derefter genererer du en SSH-nøgle på ClusterControl-serveren, som vi vil bruge til at konfigurere den adgangskodeløse SSH senere. Du kan bruge enhver bruger i systemet, men det skal have evnen til at udføre superbrugeroperationer (sudoer). I dette eksempel valgte vi root-brugeren:
$ whoami
root
$ ssh-keygen -t rsaOpsæt adgangskodefri SSH til alle noder, som du gerne vil overvåge/administrere via ClusterControl. I dette tilfælde vil vi sætte dette op på alle noder i stakken (inklusive selve ClusterControl noden). På ClusterControl node, kør følgende kommandoer og angiv root-adgangskoden, når du bliver bedt om det:
$ 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] # proxy2Du kan derefter kontrollere, om det virker ved at køre følgende kommando på ClusterControl node:
$ ssh [email protected] "ls /root"Sørg for, at du er i stand til at se resultatet af kommandoen ovenfor uden at skulle indtaste adgangskode.
Implementering af klyngen
ClusterControl understøtter alle leverandører til Galera Cluster (Codership, Percona og MariaDB). Der er nogle mindre forskelle, som kan påvirke din beslutning om at vælge leverandør. Hvis du gerne vil lære om forskellene mellem dem, så tjek vores tidligere blogindlæg - Galera Cluster Comparison - Codership vs Percona vs MariaDB.
Til produktionsimplementering er en Galera-klynge med tre knudepunkter det minimum, du bør have. Du kan altid skalere det ud senere, når klyngen er implementeret, manuelt eller via ClusterControl. Vi åbner vores ClusterControl UI på https://192.168.55.160/clustercontrol og opretter den første admin-bruger. Gå derefter til topmenuen og klik på Deploy -> MySQL Galera og du vil blive præsenteret for følgende dialogboks:
Der er to trin, det første er "Generelle &SSH-indstillinger". Her skal vi konfigurere den SSH-bruger, som ClusterControl skal bruge til at forbinde til databasenoderne, sammen med stien til SSH-nøglen (som genereret under Forudsætningssektionen) samt SSH-porten for databasenoderne. ClusterControl antager, at alle databasenoder er konfigureret med den samme SSH-bruger, nøgle og port. Giv derefter klyngen et navn, i dette tilfælde vil vi bruge "MySQL Galera Cluster 5.7". Denne værdi kan ændres senere. Vælg derefter mulighederne for at instruere ClusterControl om at installere den nødvendige software, deaktivere firewallen og også deaktivere sikkerhedsforbedringsmodulet på den bestemte Linux-distribution. Alle disse anbefales at slås til for at maksimere potentialet for vellykket implementering.
Klik på Fortsæt, og du vil blive præsenteret for følgende dialogboks:
I det næste trin skal vi konfigurere databaseserverne - leverandør, version, datadir, port osv. - som er ret selvforklarende. "Configuration Template" er skabelonfilnavnet under /usr/share/cmon/templates i ClusterControl-noden. "Repository" er, hvordan ClusterControl skal konfigurere depotet på databasenoden. Som standard vil den bruge leverandørens lager og installere den seneste version fra lageret. Men i nogle tilfælde kan brugeren have et allerede eksisterende lager spejlet fra det originale lager på grund af sikkerhedspolitikrestriktioner. Ikke desto mindre understøtter ClusterControl de fleste af dem, som beskrevet i brugervejledningen under Repository.
Til sidst skal du tilføje IP-adressen eller værtsnavnet (skal være et gyldigt FQDN) for databasenoderne. Du vil se et grønt flueben til venstre for noden, hvilket indikerer, at ClusterControl var i stand til at oprette forbindelse til noden via adgangskodefri SSH. Du er nu god til at gå. Klik på Implementer for at starte implementeringen. Dette kan tage 15 til 20 minutter at fuldføre. Du kan overvåge implementeringsprocessen under Aktivitet (øverste menu) -> Jobs -> Opret klynge :
Når implementeringen er afsluttet, kan vores arkitektur på dette tidspunkt illustreres som nedenfor:
Implementering af Load Balancers
I Galera Cluster er alle noder ens - hver node har den samme rolle og samme datasæt. Derfor er der ingen failover i klyngen, hvis en node fejler. Kun applikationssiden kræver failover for at springe de inoperative noder over, mens klyngen er partitioneret. Derfor anbefales det stærkt at placere load balancers oven på en Galera Cluster for at:
- Sæt de flere databaseslutpunkter til et enkelt slutpunkt (load balancer-vært eller virtuel IP-adresse som slutpunkt).
- Balancer databaseforbindelserne mellem backend-databaseserverne.
- Udfør sundhedstjek og videresend kun databaseforbindelserne til sunde noder.
- Omdiriger/omskriv/bloker stødende (dårligt skrevne) forespørgsler, før de rammer databaseserverne.
Der er tre hovedvalg af omvendte proxyer til Galera Cluster - HAProxy, MariaDB MaxScale eller ProxySQL - alle kan installeres og konfigureres automatisk af ClusterControl. I denne udrulning valgte vi ProxySQL, fordi den kontrollerer alt ovenstående, og den forstår MySQL-protokollen for backend-serverne.
I denne arkitektur ønsker vi at bruge to ProxySQL-servere til at eliminere ethvert single-point-of-failure (SPOF) til databaselaget, som vil blive bundet sammen ved hjælp af en flydende virtuel IP-adresse. Vi forklarer dette i næste afsnit. Den ene node vil fungere som den aktive proxy og den anden som hot-standby. Uanset hvilken node, der har den virtuelle IP-adresse på et givet tidspunkt, er den aktive node.
For at implementere den første ProxySQL-server skal du blot gå til klyngehandlingsmenuen (højre side af oversigtslinjen) og klikke på Tilføj Load Balancer -> ProxySQL -> Implementer ProxySQL og du vil se følgende:
Igen er de fleste af felterne selvforklarende. I afsnittet "Databasebruger" fungerer ProxySQL som en gateway, hvorigennem din applikation opretter forbindelse til databasen. Applikationen autentificerer mod ProxySQL, derfor skal du tilføje alle brugere fra alle backend MySQL-noder sammen med deres adgangskoder til ProxySQL. Fra ClusterControl kan du enten oprette en ny bruger, der skal bruges af applikationen - du kan bestemme over dens navn, adgangskode, adgang til hvilke databaser der tildeles og hvilke MySQL-privilegier den bruger skal have. En sådan bruger vil blive oprettet på både MySQL- og ProxySQL-siden. Anden mulighed, mere velegnet til eksisterende infrastrukturer, er at bruge de eksisterende databasebrugere. Du skal videregive brugernavn og adgangskode, og en sådan bruger oprettes kun på ProxySQL.
Det sidste afsnit, "Implicit Transaction", ClusterControl vil konfigurere ProxySQL til at sende al trafikken til masteren, hvis vi startede transaktionen med SET autocommit=0. Ellers, hvis du bruger BEGIN eller START TRANSACTION til at oprette en transaktion, konfigurerer ClusterControl læse/skriveopdeling i forespørgselsreglerne. Dette er for at sikre, at ProxySQL håndterer transaktioner korrekt. Hvis du ikke aner, hvordan din ansøgning gør dette, kan du vælge det sidste.
Gentag den samme konfiguration for den anden ProxySQL-node, undtagen "Server Address"-værdien, som er 192.168.55.182. Når det er gjort, vil begge noder blive vist under fanen "Noder" -> ProxySQL, hvor du kan overvåge og administrere dem direkte fra brugergrænsefladen:
På dette tidspunkt ser vores arkitektur nu sådan ud:
Hvis du gerne vil lære mere om ProxySQL, så tjek denne vejledning - Database Load Balancing for MySQL og MariaDB med ProxySQL - Tutorial.
Implementering af den virtuelle IP-adresse
Den sidste del er den virtuelle IP-adresse. Uden det ville vores load balancers (omvendte proxyer) være det svage led, da de ville være et enkelt fejlpunkt – medmindre applikationen har mulighed for automatisk at omdirigere fejlede databaseforbindelser til en anden load balancer. Ikke desto mindre er det god praksis at forene dem både ved hjælp af virtuel IP-adresse og forenkle forbindelsesendepunktet til databaselaget.
Fra ClusterControl UI -> Tilføj Load Balancer -> Keepalived -> Implementer Keepalived og vælg de to ProxySQL-værter, som vi har installeret:
Angiv også den virtuelle IP-adresse og netværksgrænsefladen for at binde IP-adressen. Netværksgrænsefladen skal eksistere på begge ProxySQL-noder. Når den er installeret, bør du se følgende grønne markeringer i oversigtslinjen i klyngen:
På dette tidspunkt kan vores arkitektur illustreres som nedenfor:
Vores databaseklynge er nu klar til produktionsbrug. Du kan importere din eksisterende database til den eller oprette en frisk ny database. Du kan bruge funktionen Schemas and Users Management, hvis prøvelicensen ikke er udløbet.
For at forstå, hvordan ClusterControl konfigurerer Keepalived, kan du tjekke dette blogindlæg, How ClusterControl Configures Virtual IP and What to Expect Under Failover.
Opretter forbindelse til databaseklyngen
Fra applikationens og klientens synspunkt skal de oprette forbindelse til 192.168.55.180 på port 6033, som er den virtuelle IP-adresse, der flyder oven på belastningsbalancerne. For eksempel vil Wordpress-databasekonfigurationen være sådan her:
/** 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' );Hvis du gerne vil have adgang til databaseklyngen direkte, uden om load balanceren, kan du bare oprette forbindelse til port 3306 på databaseværterne. Dette kræves normalt af DBA's personale til administration, ledelse og fejlfinding. Med ClusterControl kan de fleste af disse handlinger udføres direkte fra brugergrænsefladen.
Sidste tanker
Som vist ovenfor er det ikke længere en vanskelig opgave at implementere en databaseklynge. Når først de er implementeret, er der en komplet suite af gratis overvågningsfunktioner såvel som kommercielle funktioner til backupstyring, failover/gendannelse og andre. Hurtig udrulning af forskellige typer klynge-/replikeringstopologier kan være nyttig, når man skal evaluere databaseløsninger med høj tilgængelighed, og hvordan de passer til netop dit miljø.