Det er meget almindeligt at se databaser fordelt på flere geografiske steder. Et scenarie for at udføre denne type opsætning er katastrofegendannelse, hvor dit standby-datacenter er placeret på en anden placering end dit primære datacenter. Det kan lige så godt kræves, at databaserne er placeret tættere på brugerne.
Den største udfordring for at opnå denne opsætning er ved at designe databasen på en måde, der reducerer chancen for problemer relateret til netværksopdelingen.
MariaDB Cluster kan være et godt valg til at bygge et sådant miljø af flere årsager. Dem vil vi gerne diskutere her og også tale lidt om, hvordan sådan et miljø kan se ud.
Hvorfor bruge MariaDB Cluster til geo-distribuerede miljøer?
Første grund er, at MariaDB Cluster kan understøtte flere forfattere. Dette gør skriveruten nemmere at designe - du skriver bare til de lokale MariaDB-noder. Givet synkron replikering påvirker latency selvfølgelig skriveydelsen, og du kan se, at dine skrivninger bliver langsommere, hvis du spreder din klynge for langt geografisk. Du kan trods alt ikke ignorere fysikkens love, og de siger, som nu i hvert fald, at selv lysets hastighed i fiberforbindelser er begrænset. Eventuelle routere, der tilføjes oven i det, vil også øge latensen, selvom det kun er et par millisekunder.
For det andet laghåndtering i MariaDB Cluster. Asynkron replikering er et emne for replikationsforsinkelse - slaver er muligvis ikke opdateret med dataene, hvis de kæmper for at anvende alle ændringerne i tide. I MariaDB Cluster er dette anderledes - flowkontrol er en mekanisme, der er beregnet til at holde klyngen synkroniseret. Nå, næsten - i nogle kanttilfælde kan du stadig observere forsinkelse. Vi taler her typisk om millisekunder, højst et par sekunder, mens der i den asynkrone replikationshimlen er grænsen.
For det tredje, segmenter. Som standard bruger MariaDB Cluster alt til al kommunikation, og hvert skrivesæt sendes af noden til alle andre noder i klyngen. Denne adfærd kan ændres ved hjælp af segmenter. Segmenter giver brugerne mulighed for at opdele MariaDB-klynger i flere dele. Hvert segment kan indeholde flere noder, og det vælger en af dem som en relæknude. Sådanne noder modtager skrivesæt fra andre segmenter og omdistribuerer dem på tværs af MariaDB-noder lokalt for segmentet. Som et resultat, som du kan se på diagrammet ovenfor, er det muligt at reducere replikeringstrafikken, der går over WAN tre gange - kun to "replikaer" af replikeringsstrømmen sendes over WAN:en pr. datacenter sammenlignet med en pr. slave i asynkron replikering.
Endelig, hvor MariaDB Cluster virkelig skinner, er håndteringen af netværkspartitioneringen. MariaDB Cluster overvåger konstant tilstanden af noderne i klyngen. Hver node forsøger at forbinde med sine jævnaldrende og udveksle klyngens tilstand. Hvis et undersæt af noder ikke er tilgængeligt, forsøger MariaDB at videresende kommunikationen, så hvis der er en måde at nå disse noder på, vil de blive nået.
Et eksempel kan ses på diagrammet ovenfor:DC 1 mistede forbindelsen med DC2 men DC2 og DC3 kan forbindes. I dette tilfælde vil en af noderne i DC3 blive brugt til at videresende data fra DC1 til DC2 for at sikre, at intra-cluster-kommunikationen kan opretholdes.
MariaDB er i stand til at udføre handlinger baseret på klyngens tilstand. Den implementerer quorum - størstedelen af noderne skal være tilgængelige, for at klyngen kan fungere. Hvis noden bliver afbrudt fra klyngen og ikke kan nå nogen anden node, vil den ophøre med at fungere.
Som det kan ses på diagrammet ovenfor, er der et delvist tab af netværkskommunikationen i DC1, og den berørte node fjernes fra klyngen, hvilket sikrer, at applikationen ikke får adgang til forældede data.
Dette gælder også i større skala. DC1 fik al sin kommunikation afbrudt. Som et resultat er hele datacentret blevet fjernet fra klyngen, og ingen af dets noder vil betjene trafikken. Resten af klyngen bevarede flertal (6 ud af 9 noder er tilgængelige), og den omkonfigurerede sig selv for at bevare forbindelsen mellem DC 2 og DC3. I diagrammet ovenfor antog vi, at forfatteren rammer noden i DC2, men husk venligst, at MariaDB er i stand til at køre med flere forfattere.
Design af geografisk distribueret MariaDB-klynge
Vi gennemgik nogle af de funktioner, der gør MariaDB Cluster til en god pasform til geo-distribuerede miljøer, lad os nu fokusere lidt på designet. Lad os i begyndelsen forklare, hvilket miljø vi arbejder med. 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 at gøre denne blog mindre kompliceret vil vi ikke gå i detaljer om, hvordan forbindelsen skal se ud. Vi antager en form for korrekt konfigureret, sikker forbindelse på tværs af alle datacentre. VPN eller andre værktøjer kan bruges til at implementere det.
Vi vil bruge MaxScale som en loadbalancer. MaxScale 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. Applikationer kan konfigureres til at oprette forbindelse til en af de lokale MaxScale-noder ved hjælp af en round-robin-algoritme. Vi kan lige så godt bruge Keepalved og Virtual IP til at dirigere trafikken mod den enkelte MaxScale-knude, så længe en enkelt MaxScale-knude ville være i stand til at håndtere al trafikken.
En anden mulig løsning er at samle MaxScale med applikationsknudepunkter 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 MaxScale 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 MaxScale og applikationen på samme tid.
Diagrammet ovenfor viser versionen af miljøet, hvor MaxScale danner proxy-farme - alle proxy noder med den samme konfiguration, belastningsbalanceret ved hjælp af Keepalved, eller bare round robin fra applikationen på tværs af alle MaxScale noder. MaxScale er konfigureret til at fordele arbejdsbyrden på tværs af alle MariaDB-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.
Konklusion
Som du kan se, kan MariaDB Cluster nemt bruges til at skabe geo-distribuerede klynger, der kan fungere selv over hele verden. Den begrænsende faktor vil være netværksforsinkelse. Hvis den er for høj, skal du muligvis overveje at bruge separate MariaDB-klynger, der er forbundet ved hjælp af asynkron replikering.