I den forrige blog i serien diskuterede vi fordele og ulemper ved at bruge Galera Cluster til at skabe geo-distribuerede klynge. I dette indlæg vil vi designe en Galera-baseret geo-distribueret klynge, og vi vil vise, hvordan du kan implementere alle de nødvendige dele ved hjælp af ClusterControl.
Design af en Geo-distribueret Galera-klynge
Vi starter med at forklare det miljø, vi ønsker at bygge. Vi vil bruge tre eksterne datacentre, forbundet via Wide Area Network (WAN). Hvert datacenter vil modtage skrivninger fra lokale applikationsservere. Læsning vil også kun være lokal. Dette er beregnet til at undgå unødvendig trafik, der krydser WAN.
For denne opsætning er forbindelsen på plads og sikret, men vi vil ikke beskrive præcis, hvordan dette kan opnås. Der er adskillige metoder til at sikre forbindelsen fra proprietære hardware- og softwareløsninger gennem OpenVPN og ender i SSH-tunneler.
Vi vil bruge ProxySQL som en loadbalancer. ProxySQL vil blive implementeret lokalt i hvert datacenter. Den dirigerer også kun trafik til de lokale knudepunkter. Fjernnoder kan altid tilføjes manuelt, og vi vil forklare tilfælde, hvor dette kan være en god løsning. Applikationen kan konfigureres til at oprette forbindelse til en af de lokale ProxySQL-noder ved hjælp af round-robin-algoritme. Vi kan lige så godt bruge Keepalved og Virtual IP til at dirigere trafikken mod den enkelte ProxySQL-node, så længe en enkelt ProxySQL-node ville være i stand til at håndtere al trafikken.
En anden mulig løsning er at samle ProxySQL med applikationsknuder og konfigurere applikationen til at oprette forbindelse til proxyen på den lokale vært. Denne tilgang fungerer ret godt under den antagelse, at det er usandsynligt, at ProxySQL ikke vil være tilgængelig, men applikationen ville fungere ok på den samme node. Det, vi typisk ser, er enten nodefejl eller netværksfejl, hvilket vil påvirke både ProxySQL og applikation på samme tid.
Diagrammet ovenfor viser versionen af miljøet, hvor ProxySQL er samlet på samme node som applikationen. ProxySQL er konfigureret til at fordele arbejdsbyrden på tværs af alle Galera-noder i det lokale datacenter. En af disse noder ville blive valgt som en node at sende skrivningerne til, mens SELECT'er ville blive fordelt på tværs af alle noder. At have én dedikeret forfatterknude i et datacenter hjælper med at reducere antallet af mulige certificeringskonflikter, hvilket typisk fører til bedre ydeevne. For at reducere dette yderligere ville vi være nødt til at begynde at sende trafikken over WAN-forbindelsen, hvilket ikke er ideelt, da båndbreddeudnyttelsen ville stige markant. Lige nu, med segmenter på plads, sendes kun to kopier af skrivesættet på tværs af datacentre - en pr. DC.
Den største bekymring med Galera Cluster geo-distribuerede udrulninger er latency. Dette er noget, du altid skal teste, inden du lancerer miljøet. Er jeg ok med forpligtelsestiden? Ved hver commit-certificering skal der ske, så skrivesæt skal sendes og certificeres på alle noder i klyngen, inklusive fjerntliggende. Det kan være, at den høje latenstid vil anse opsætningen for uegnet til din applikation. I så fald kan du finde flere Galera-klynger forbundet via asynkron replikering mere passende. Dette ville dog være et emne for et andet blogindlæg.
Installation af en geo-distribueret Galera Cluster ved hjælp af ClusterControl
For at præcisere tingene vil vi her vise, hvordan en implementering kan se ud. Vi bruger ikke egentlig multi-DC-opsætning, alt vil blive implementeret i et lokalt laboratorium. Vi antager, at latensen er acceptabel, og at hele opsætningen er levedygtig. Det gode ved ClusterControl er, at det er infrastruktur-agnostisk. Det er ligeglad med, om noderne er tæt på hinanden, placeret i samme datacenter, eller om noderne er fordelt på tværs af flere cloud-udbydere. Så længe der er SSH-forbindelse fra ClusterControl-instansen til alle noderne, ser implementeringsprocessen nøjagtig ens ud. Det er derfor, vi kan vise dig det trin for trin ved hjælp af blot lokalt laboratorium.
Installation af ClusterControl
Først skal du installere ClusterControl. Du kan downloade det gratis. Efter registrering skal du gå til siden med guide til at downloade og installere ClusterControl. Det er så simpelt som at køre et shell-script. Når du har ClusterControl installeret, vil du blive præsenteret for en formular til at oprette en administrativ bruger:
Når du har udfyldt det, vil du blive præsenteret for en velkomstskærm og adgang til implementeringsguider:
Vi fortsætter med implementering. Dette åbner en installationsguide:
Vi vælger MySQL Galera. Vi skal videregive SSH-forbindelsesdetaljer - enten root-bruger eller sudo-bruger understøttes. På næste trin skal vi definere servere i klyngen.
Vi skal installere tre noder i et af datacentrene. Så vil vi være i stand til at udvide klyngen ved at konfigurere nye noder i forskellige segmenter. Indtil videre er alt, hvad vi skal gøre, at klikke på "Deploy" og se ClusterControl implementere Galera-klyngen.
Vores første tre noder er oppe at køre, vi kan nu fortsætte med at tilføje yderligere noder i andre datacentre.
Du kan gøre det fra handlingsmenuen, som vist på skærmbilledet ovenfor .
Her kan vi tilføje yderligere noder, én ad gangen. Hvad der er vigtigt, bør du ændre Galera-segmentet til ikke-nul (0 bruges til de første tre noder).
Efter et stykke tid ender vi med alle ni noder, fordelt på tre segmenter.
Nu skal vi implementere proxy-lag. Vi vil bruge ProxySQL til det. Du kan implementere det i ClusterControl via Administrer -> Load Balancer:
Dette åbner et implementeringsfelt:
Først skal vi beslutte, hvor ProxySQL skal installeres. Vi vil bruge eksisterende Galera-noder, men du kan skrive hvad som helst i feltet, så det er perfekt muligt at implementere ProxySQL oven på applikationsknuderne. Derudover skal du videregive adgangsoplysninger til den administrative og overvågende bruger.
Så skal vi enten vælge en af eksisterende brugere i MySQL eller oprette en lige nu. Vi ønsker også at sikre, at ProxySQL er konfigureret til at bruge Galera-noder kun placeret i det samme datacenter.
Når du har en ProxySQL klar i datacenteret, kan du bruge den som kilde til konfigurationen:
Dette skal gentages for hver applikationsserver, du har i alle datacentre . Så skal applikationen konfigureres til at oprette forbindelse til den lokale ProxySQL-instans, ideelt set over Unix-socket. Dette kommer med den bedste ydeevne og den laveste latenstid.
Efter den sidste ProxySQL er implementeret, er vores miljø klar. Applikationsnoder opretter forbindelse til lokal ProxySQL. Hver ProxySQL er konfigureret til at arbejde med Galera-noder i det samme datacenter:
Konklusion
Vi håber, at denne todelte serie hjalp dig med at forstå styrkerne og svaghederne ved geo-distribuerede Galera Clusters, og hvordan ClusterControl gør det meget nemt at implementere og administrere en sådan klynge.