MySQL-clustring for høy tilgjengelighet
Introduksjon
MySQL går for å være verdens mest populære open source database og da spesielt i forhold til innhold som er publisert på web. Dersom man tar en kikk på dynamiske webapplikasjoner som er skrevet - forum, CMS, e-læringssystemer, gjestebøker og småscript - ser man at bortimot samtlige på en eller annen måte støtter MySQL og har denne databasetypen som hovedmotor.
Selve databasemotoren går for å være relativt enkel, men dette har også vært MySQL sin styrke siden mindre kompleksitet har ført til raske spørringer og relativt lite feil. Med MySQL 5 ble det imidlertid innført mye mer funksjonalitet, blant annet en del finesser som tidligere har vært forbeholdt til store, kommersielle databasene som Oracle, MS SQL og DB2.
På mange måter kan man si at MySQL har vokst side om side med internett og utviklet seg til å bli den mest populære webdatabasen. Mange av disse nettløsningene har utviklet seg fra relativt enkle til å bli store og virksomhetskritiske pengemaskiner der nedetid får økonomiske konsekvenser fra første stund. Det er her terminologien "høy tilgjengelighet" kommer inn - noe som de senere årene også er tatt høyde for i MySQL - både gjennom egen databasemotor, men også ved hjelp av tredjeparts leverandører.
Voksesmerter i praksis
I minst 90 prosent av tilfellene settes gjerne webløsningene opp med en så enkel og billig databaseløsning som mulig. I praksis betyr dette kanskje en delt MySQL-database eller kanskje kjørende på én enkelt Linux-server. Mot databasen kjøres det kanskje en ferdigutviklet, helkommersiell applikasjon, men mange ganger gjør man også lokale tilpasninger eller utvikler sin egen webapplikasjon.
Etterhvert som brukerne øker i antall og nettløsningen får mer trafikk, vil også lasten øke på databaseserveren - i tillegg til at kravene til oppetid stiger.
Følgende er gjerne årsaker til voksesmerter på databasenivå:
- For liten feiltoleranse
- For dårlig ytelse
- For liten lagring
I denne artikkelen er det punkt 1 vi skal fokusere på siden de andre krever en noe annen arkitekturmessig fremgangsmåte.
Når man har kommet til det tidspunktet at nedetid får betydelige økonomiske konsekvenser for selskapet bak løsningen, bør se på muligheten for å bygge ut til et cluster med "høy tilgjengelighet". Denne oppgraderingen trenger ikke være veldig komplisert i seg selv. Utfordringen kommer vanligvis fordi man har webapplikasjoner som benytter lokal disklagring istedet for databaselagring. Dersom dette er tilfellet må man enten inn med filclustering av respektive filer eller bygge om applikasjonene slik at all lagring foregår i databasen.
Dersom all lagring skal foregå i databasen, kan dette vanligvis føre til ytelsesmessige utfordringer, men dette er uansett den beste og minst kompliserte måten å få høyest mulig tilgjengelighet på databaselaget. Skulle dette bli en flaskehals for ytelsen, må man enten skalere opp maskinvaren eller se på en noe mer komplisert arkitektur der man skiller ut deler av systemet på høytytende systemer - eks. spesielle disksystemer.
Løsninger for høy tilgjengelighet
Det finnes flere løsninger for å få høy tilgjenglighet med MySQL og her skal vi nå liste opp noen av disse:
MySQL Cluster
Dette er MySQLs egen clustermetode som er gratis tilgjengelig siden versjon 4.1. Man må bruke en egen tabelltype som heter NDB, men man skal være klar over at det finnes en del begrensninger. Blant annet er det visse datatyper som passer dårlig inn i denne modellen - i tillegg til at at hele databasen må kunne lagres i minnet på hver server. De formelle kravene til NDB er at hver server må ha dobbelt så mye minne som størrelsen på databasen. Dersom databasen er på 4 GB, må man dermed ha 8 GB minne på hver maskin - siden databasen lagres i minne på hver eneste node.
En oversikt over begrensninger i MySQL Cluster for versjon 5.1 finner du her: Known limitations of MySQL Cluster
Continuent Uni/cluster
Denne løsningen finnes både som gratis nedlastbar open source-løsning, men også som et helkommersiell med full support. Den baserer seg i stor grad på JDBC-drivere og gir høy tilgjengelighet uten at man trenger å installere noen egen versjon av MySQL.Clusterløsningen er altså et eget applikasjonslag som gjerne kan skilles ut på egne servere og som kan oppgraderes uavhengig av MySQL-versjoner.
Som de fleste andre cluster-løsninger, må man også i dette tilfellet sertifisere applikasjonen for clusteret, men Uni/cluster er allikevel godt tilpasset et generelt bruksområde.
Mer informasjon om open source Uni/cluster finner på http://www.continuent.org/, mens den kommersielle versjonen er tilgjengelig på http://www.continuent.com.
Løsningen finnes også for andre databasetyper, deriblant PostgreSQL.
Dolphin
Dolphin tilbyr både software- og hardwarebaserte cluster-løsning for MySQL. Dette inkluderer løsninger både for høy tilgjengelighet og høy ytelse. Dolphin SuperSockets baserer seg blant annet på et kort som man setter i PCI Express-sporet på serveren og støtter opptil 100 noder.
Foreløpig er systemet støttet for Linux på x86 (Intel, AMD) og Power (IBM System P). I skrivende stund holder man på med en beta-versjon for Microsoft Windows og vil etterhvert også støtte Linux for Itanium samt Solaris.
Dette er en helkommersiell løsning som også fungerer med en del andre applikasjoner, eksempelvis NFS og Oracle 10g.
Mer informasjon finner du her: http://www.dolphinics.com/
SteelEye
SteelEye Technology er en kjent leverandør som også tilbyr høy tilgjenglighetsclustering for MySQL. Løsningen er bygget på selskapets LifeKeeper-produkt, som kjører på Linux, Windows og Solaris. Dette er en noe mer generell løsning som også går langt utover det å støtte én enkelt database, men legger til høy tilgjenglighet for blant annet Exchange, SQL Server, IBM Director, virtuelle server, osv.
Mer informasjon om LifeKeeper for Linux finner du her: LifeKeeper for Linux
SteelEye får gode anbefalinger der man ønsker å clustre flere deler av virksomheten med én og samme clusterteknologi - fra database til web og e-post.
Bygg ditt eget cluster
Dersom du har fullstendig kontroll på applikasjonen, kan du faktisk sette opp et høy tilgjenglighetscluster så enkelt som å bygge inn egne regler til å bruke flere databaseservere. Avhengig av om dataene skal ligge sentral på ett enkelt sted med høy tilgjengelighet eller på hver enkelt node, må du være forsiktig med samtidighetsproblematikk og eventuelt ta nodene ut og inn av clusteret.
Dersom du kun kjører "selects" og ingen oppdateringer eller legger inn nye data på clusteret, trenger du kun sette opp X antall databaseservere og sørge for at dataene er synkrone på nodene samt gjøre en sjekk på om serveren du forespør faktisk er oppe. Det kan naturligvis være en fordel å kjøre jevnlige sjekker på at dataene virkelig er synkrone.
Andre clustermodeller
Det finnes også andre modeller på å få høy tilgjengelighet på MySQL. En mulighet er å bevege seg over på andre deler i "stacken" - eksempelvis filsystemclustering kombinert med virtuelle maskiner (Xen) og såkalt Heartbeat. Novell er en av Linux-leverandørene som det siste året har demonstrert dette på sine "roadshows" med høy tilgjenglighet på hele LAMP-stacken og OCFS i bunn.
Til ettertanke
Mange bedrifter ønsker seg høy tilgjengelighet på databasen, uten å se de reelle konsekvensene av å innføre dette. Clustering av MySQL må planlegges både drifts- og utviklingsmessig - for ikke å snakke om økte kostnader. Ved å skille tabellstrukturer og evt. data på forskjellige noder er det mer komplisert å rulle ut ny funksjonalitet ettersom man ved strukturelle endringer gjerne må ta ned hele clusteret. I tillegg krever et cluster mer driftskompetanse og tid å administrere enn én enkelt server. Til syvende og sist medfører disse ulempene en del økte kostander: hardware, lisenser, kompetanse, tid og trolig tregere "time to market" med ny funksjonalitet.
"Live" databasereplikering kan være et godt alternativ til HA-clustering siden man uten problemer kan være oppe igjen i løpet av få minutter - enten via manuelle rutiner eller automatisk "failover" - dersom hovedsystemet skulle feil pga. maskinvarefeil. Replikering er en betydelig billigere og mindre komplisert måte å sikre oppetiden på, men 99,999% oppetid kan man ikke garantere.
Avhengig om du kjører mange "selects" eller "inserts" finnes det forskjellige måter å sette opp høy tilgjengelighet på. Dette er også viktig når man skal planlegge langsiktig drift av clusteret og selve systemarkitekturen (eks. disksystemer).
Dersom nedetid på MySQL-databasen får øyeblikkelig betydelige økonomiske konsekvenser, bør man altså se på HA-løsninger. Videre er det viktig å få både fordeler og ulemper med HA-løsningen på bordet, for alle relevante ledd - fra utviklingsavd. til ledelse, før det settes i drift.
Flere av selskapene som leverer de nevnte clusterløsningene kjører egne kurs for bruk av produktene. Eventuelt finnes det også muligheter for "outsourcing" av driften gjennom sertifiserte partnere.
