2016-06-08

SQL clustering med Galera - Jagten på den bedste clusterløsning til SQL

Clustering med transaktionelle databaser har altid været en udfordring. 

Oftest er løsningerne meget komplekse i opbygning, dyre i både licenser og hardware og besværlige at drifte (f.eks. MySQL Cluster eller Oracle RAC) - andre gange kræver løsningerne manuelt arbejde (f.eks. Master-Slave replikering eller Dataguard) eller clustering software som igen indfører kompleksibilitet (f.eks. Heartbeat/Pacemaker).

Oftest skal man også gå efter de dyre løsninger for at få en vis form for skalérbarhed.

Så hvad gør man, hvis NoSQL ikke er en option?

Galera er et add-on til MySQL varianterne MySQL, MariaDB eller Percona extraDB, som i bund og grund “blot” sørger for at alle noder er i sync - altid. 
Det lyder til at være en simpel og lovende løsning. Hos Netic har vi derfor valgt at se nærmere på MariaDB med Galera igennem nogle tests. 

Performance

Det første spørgsmål man tænker på når man læser om et plugin der sørger for at alle noder er i sync, er: “Hvad med performance?” 

Man skal tænke på en Galera node som værende en selvstændig database server. Dvs at hvis man sammenligner en enkeltstående Galera node med en standard MySQL vil man næppe bemærke nogen forskel i performance. 

Forskellen bliver først synlig når man tilføjer flere noder til Galera. 

I kraft af at alle noder er i sync, har man nu mulighed for at læse fra flere noder på samme tid uden at noderne er afhængige af hinanden.

Ved skrivninger vinder galera også når der er flere noder, fordi en galera node ikke har behov for at lave flush/sync mod den lokale disk da der jo nu er minimum 2 andre noder der gemmer på de samme data. Ud over det kan man vælge at skrive til flere noder på samme tid og dermed til en vis grad fordele belastningen. Galeras måde at holde de andre noder i sync på, har i vores tests vist sig at være hurtigere end, at en sammenlignelig standard MySQL server kan nå at lave flush/sync mod den lokale disk.

Hvordan kan Galera være så hurtigt til at synkronisere data på tværs af noderne?

Når en galera node modtager en skrivning/commit fra klienten, sender noden indtil videre kun metadataene for den igangværende skrivning videre til de andre noder. Hvis alle andre noder “accepterer” de metadata (dvs at skrivningen ikke vil komme til at fejle pga. duplicate key eller fordi en anden transaktion på samme række allerede er i gang), bliver en commit accepteret over for klienten. Selve skrivningen på de andre noder sker så først efterfølgende med en kort forsinkelse - dog uden at påvirke klienten. Galera skjuler dermed på en elegant og sikker måde de performance udfordringer der er ved at holde flere selvstændige noder 100% i sync. 

Skalerbarhed

Det siger sig selv at skalerbarheden har sine grænser når man skal holde flere noder i sync med skrivninger. Vores tests har faktisk vist at performance under skrivning daler med et voksende antal noder i et galera cluster. Men på den anden side performer et galera cluster på 5 noder stadig bedre en enkelt mysql server.

Omvendt får man næsten lineær skalerbarhed når man ser på læsninger. Noderne ikke er afhængige af hinanden når der læses fra dem - dog belastes CPU på den enkelte node yderligere for hver node der tilføjes. 

Yderligere har man muligheden for at påvirke skriveperformance positivt ved at optimere på CPU og netværkskommunikationen. 


Ovenstående graf viser en sammenligning af skrivninger (update, delete og insert) per sekund på en enkelt mariaDB node i forhold til et cluster på 3 galera noder. Hver node er en virtuel server med 8 cores. Vi brugte hertil sysbench udført fra 7 client servere med i alt 140 tråde til at udføre 850.000 skrivninger og 980.000 læsninger. Bemærk at sync/flush på den enkelte mariaDB node i testen ikke er slået til. Hvis den var det, ville dens write-performance have været endnu værre.
Graferne stopper hver især efter sysbench har afsluttet testen. Den opmærksomme læser vil bemærke at der i følge grafen kun bliver fortaget 500.000 skrivninger på galeraclusteret, hvor i mod den enkelte node har registreret alle 850.000 skrivninger. Årsagen hertil er at Galera allerede har returneret til klienten at skrivningen er afsluttet, selv om skrivningen ikke er nået igennem til innodb og dermed heller ikke er blevet fanget af målingen. Skrivningerne ligger i så fald i Galera's interne buffer - det ændrer dog ikke på at en select ville have vist de korrekte data med alle skrivninger.

Datasikkerhed

I kraft af at man har flere noder der gemmer på samme data, er man som udgangspunkt allerede dækket godt ind. 

I vores tests har vi fordelt noderne på tværs af flere datacentre med dedikeret fiber og lav latency uden at opleve degraderet performance. Dvs at man også kan beskytte sig mod større katastrofer på et datacenter. 

For at undgå split-brain bruger galera "quorum princippet" by design. Dvs at hvis en node mod forventning, har mistet flertallet af clusteret, nægter galera noden at modtage queries. Når noden bliver del af clusteret igen er noden i stand til at re-sync'e sig selv. Først når noden er 100% i sync igen, accepterer noden queries fra klienter. 

Galera tillader "shared-nothing architecture" og er dermed ikke afhængig af centrale komponenter som f.eks. SAN eller management servere. Hver galera node kan til nød køre som en selvstændig node, hvis behovet skulle opstå.  

Architektur og Hardware

Der er ikke specifikke hardwarekrav til noderne. Dog har det i vores tests vist sig at CPU og Netværk er essentielt for Galera.

Med baggrund i quorum princippet skal man minimum have 3 noder og for at opnå den bedst tænkelige oppetid er det en god ide at fordele dem over 3 datacentre med direkt link til hinanden. 

Man bestemmer selv hvordan man fordeler belastningen på sine galera noder. Man kan vælge at bruge en almindelig loadbalancer, MariaDB’s MaxScale eller en cluster-aware klient.

Hos Netic anbefaler vi at bruge MariaDB, som tilbyder en kombineret softwarepakke der indeholder både Galera og MariaDB. Dermed har man også mulighed for at købe sig til Enterprise Support igennem MariaDB.  

Begrænsninger

Der er naturligvis nogle ting som man skal være opmærksom på inden man går i gang med at bruge galera.
Bl.a. er "auto_increments" ikke nødvendigvis tidsmæssigt længere og når man har mange galera noder der skal håndtere skrivninger til samme tabel kan man hurtigt komme ud i deadlocks. 
Man skal også være opmærksom på at Galera kun understøtter "InnoDB" og tranaktionslevel “Serializable” ikke er supporteret. 

Konklusion

Alt i alt er Galera indtil videre den bedste clusterløsning til transaktionelle databaser som Netic har set. 
Simplicity is key - og selv om tingene dybt inde i maven på Galera med sikkerhed er meget advanceret, så har Codership formået at holde overfladen og grundprincippet simpelt og nemt at forstå for de fleste. 
Med den rigtige arkitektur får man høj oppetid, god performance og en rimelig skalérbarhed.
Når ens data er gemt på 3 forskellige servere, der er fysisk adskilt fra hinanden, kan man også sove trygt om natten. 


Hvis du vil vide mere, skal du være velkommen til at kontakte os. 

Ingen kommentarer:

Send en kommentar