[MySQL] Internationaal uitrollen (cluster)

[Verwijderd]

Omdat ons bedrijf uit gaat breiden naar Singapore is het noodzakelijk dat onze web-applicatie ook daar komt te draaien. Hier in Nederland draaien we op onze eigen infrastructuur bij EvoSwitch in Haarlem. Belangrijk hierbij is dat er geen single point of failures mogelijk zijn.

Nu hebben we tests gedaan met Amazon S2. We hebben in Asie een webserver opgezet en deze laten connecten naar onze eigen MySQL database in Haarlem. Door de ping van 300 miliseconden duurt het meer dan 10 seconden om een pagina op te halen. Geen interessante oplossing dus.

Ooit hebben we eerder tests gedaan met mysql replicatie. Alleen heb je dan altijd de master / replica configuratie, waarbij er dus een single point of fauilure ontstaat.

We zijn verder gaan kijken, en kwamen bij Mysql Cluster. Het was ons niet helemaal duidelijk of mysql cluster de oplossing is om tussen verschillende datacenters een mysql cluster te bouwen.

Zijn er mensen die ervaring hebben met het uitrollen van een Mysql omgeving naar het buitenland?
En zijn er mensen die dit gedaan hebben met een Mysql Cluster?

[Boss]

Als het een web-applicatie is hoeft er toch helemaal niets in Singapore te draaien? Dan kunnen ze daarvandaan toch gewoon de app die hier (of waar dan ook ter wereld) staat benaderen? Dan heb je altijd een snelle verbinding tussen de webserver en je database. Lijkt me sterk dat vervolgens een normale page-request vanuit Singapore +10sec zal duren. Dan is er iets mis met je verbinding.

[ Voor 35% gewijzigd door Boss op 28-03-2011 09:08 ]

[B-Man]

Boss schreef op maandag 28 maart 2011 @ 09:07:
Als het een web-applicatie is hoeft er toch helemaal niets in Singapore te draaien? Dan kunnen ze daarvandaan toch gewoon de app die hier (of waar dan ook ter wereld) staat benaderen? Dan heb je altijd een snelle verbinding tussen de webserver en je database. Lijkt me sterk dat vervolgens een normale page-request vanuit Singapore +10sec zal duren. Dan is er iets mis met je verbinding.

Het klinkt alsof de TS de webserver in singapore draait en de db hier. Dan krijg je per query een roundtrip en dat kan hard oplopen vanwege de latency.

TS: Als je zowel de database- als de webservers in nl laat draaien zit je waarschijnlijk met minder roundtrips.

[foobar79]

Mysql Cluster is hier TOTAAL niet geschikt voor.
Mysql Cluster heeft extreem korte latency nodig tussen de verschillende nodes.
Bovendien heeft de NDB database van Mysql Cluster beperkte functionaliteit.
NDB wordt ingezet wanneer 1 Fysieke Mysql database niet snel genoeg meer is.

Wat je zou kunnen doen is Mysql master - master replicatie opzetten.

[Verwijderd]

De ping tussen onze Amazon VPS in singapore en onze fysieke server bij evoswitch is 600 miliseconde.
Wat we hadden gedaan was de VPS naar de fysieke DB in NL laten connecten. Aangezien er een stuk of 15 queries in de pagina zaten. Duurde het dus 15*600 miliseconde = 9 seconden. Vandaar dat we bij mysql cluster kwamen, omdat ik dacht dat replicatie altijd in een master slave configuratie was.

@Foobar, heb je ervaring met het opzetten van een master master replica bij internationale omgevingen? Hier ben ik wel benieuwd naar.

[Verwijderd]

@foobar79, bedankt voor je reactie, het heeft ons aan het denken gezet.

We zijn nu aan het testen met master-master replicatie.

Alsnog ben ik wel benieuwd naar de ervaringen met mysql cluster.

[foobar79]

Mysql replicatie is asynchroon dus latency is daarbij geen issue.
Let wel op dat je de replicatie in een monitoring omgeving zet!
Mysql replicatie wil nog wel eens stuk gaan.

Mijn ervaringen met Mysql cluster zijn negatief.
Het draait zolang het draait maar als het stuk gaat is er te weinig documentatie beschikbaar om te achterhalen wat er nou precies mis gaat.
Wat mij betreft is de software te complex en alleen in hele specifieke gevallen toepasbaar.

Ik heb er verder ook nog niemand over gehoord die erg positief was in mijn "netwerk".
Zoals ik al zei moet je super lage latency hebben aangezien bij lees/schrijf acties de andere nodes bevraagt moeten worden. Totaal niet geschikt dus in deze situatie.

[Davio]

Ik snap niet waarom jullie alles dubbel doen.

Waarom kiezen jullie niet voor een gecentraliseerde omgeving die voor beide locaties werkt? Dan hou je db-server en web-server bij elkaar en maak je een aparte kapstok waar je beide locaties onderhangt.

Hier zijn echter wellicht ontwikkelingskosten aan verbonden die jullie niet willen maken, dat zou kunnen.

Maar je merkt zelf ook al op dat het verplaatsen van alleen de webserver niet genoeg is, omdat de db-server nog in Nederland staat. Zou je de db-server dan ook niet gewoon copy-pasten?

Dan krijg je 2 gescheiden omgevingen, 1 voor Nederland en 1 voor Singapore met elk hun eigen snelheid. Ik weet niet of dit voor jullie een optimale oplossing is, maar ik weet de details van jullie probleem dan ook niet.

Het is in ieder geval iets om over na te denken in de trant van: waarom moeilijk doen als het makkelijk kan?

[foobar79]

De topicstarter gaf aan dat ze geen SPOF wilden hebben.
Het voordeel van "1 omgeving" is dat die makkelijk als backup locatie kan dienen.
Verder is mysql master-master binnen een paar tellen ingericht...

Verder zou je nog een content distributie netwerk kunnen overwegen als je wilt centraliseren (zoals b.v. akamai of zelf iets bouwen met een reverse proxy zoals varnish) maar is afhankelijk van de inhoud van de pagina.
Ofwel: een statische pagina cachen gaat prima maar met unieke content lukt natuurlijk niet.