Hardware-based database load balancing/clustering

[B-Man]

Ik draai op het moment een zware database server, die op het moment een SPOF vormt. Nu kan ik er een tweede machine naastzetten die middels replication een schaduwkopie draait, of zelfs

Master --> Slave
Slave <-- Master

(Multi master replication dus).

Momenteel draai ik op MySQL, en mogelijk in de toekomst PostgreSQL of een andere database.

Nu weet ik dat je voor bijvoorbeeld webservers (om een voorbeeld te noemen) loadbalancers kunt gebruiken, zoals de One4Net B-100's die tweakers draait. Nu ben ik echter benieuwd of zoiets ook voor een x aantal database servers te hangen is.

Mogelijk is er in de toekomst budget voor een oplossing als die van Emicnetworks (komt neer op EUR 4.000 per server, nu maal 2), of een database die dit out-of-the-box ondersteunt.
Interessante factoren aan MySQL en PostgreSQL zijn echter het gemak qua onderhoud en de lage kosten van implementatie en onderhoud.

Als ik de database (die een onderdeel uitmaakt van een clustered applicatie) HA/load balanced wil maken, zijn er volgens mij drie oplossingen:

- Database replication + failover in client app
- Database replication + failover in DB software
- Database replication + hardware oplossing/load balancer?

failover in de client App heb ik liever niet, waarom het wiel opnieuw uitvinden? Failover in de DB software is met het huidige budget niet aan de orde denk ik. (Ik ben op de hoogte van MySQL Cluster, maar dat is 100% memory-based: niet leuk met een database die 'groot' is (4-10GB).

Wat is nu wijsheid? Ik denk erover in eerste instantie de 'failover' functionaliteit uit de MySQL JDBC driver in te gaan zetten, i.c.m. een simpele applicatie op iedere database server, die pas weer verbindingen toestaat zodra de database up-to-date is. Dit is echter een houtje-touwtje oplossing

Wie heeft hier ervaring mee, en kan me vertellen wat (mogelijk) wijsheid is, nu (met beperkt budget) en met in het vooruitzicht middelen om het wat groter aan te pakken (groeipad)?

[Verwijderd]

Als je je DB via JDBC benaderd kun je eens kijken naar C-JDBC. Dat is een soort JDBC proxy driver die transparant clustering aan je DB toevoegd. DBs in het cluster kunnen dan zelfs van verschillende types zijn.

Wij zien hier zelf ook in geintereseerd en bekijken momenteel de mogelijkheden hiervan. Ik hoop dus ook dat je veel reacties krijgt (voor mij vooral inzake C-JDBC) omdat ik daar dus zelf ook naar op zoek ben.

Wij gebruiken overigens postgresql 7.4.

[B-Man]

leeko: ik ben al een paar keer tegen C-JDBC aangelopen, en ga daar zeker eens mee testen.

Ik neig echter toch naar een oplossing die het helemaal in de software zelf oplost (native), zoals de software van Emic Networks.

Het is namelijk zo dat de database server naast Java/JDBC clients ook PHP clients heeft, en die wil ik niet via JDBC laten verbinden (onhandig, want dan zal ik PHP in en servlet container moeten gaan draaien).

Of wat ik nu ook zelf kan implementeren (nog steeds houtje-touwtje ) is toch simpele failover in de client apps: lijstje met servers bijhouden, en als 1 niet werkt, probeer dan 2. En vervolgens een simpele daemon draaien op iedere database server, die kijkt of de andere servers in het cluster bereikbaar zijn.
Regels waarop gehandeld wordt kunnen dan zijn:

- Bij starten server poort 3306 op firewall dicht, gaat pas open als de replication slave up-to-date is.
- Bij het onbereikbaar zijn van de algemene netwerkverbinding: poort 3306 dicht, als de netwerkverbinding weer 'up' is, bepalen welke server het meest actueel is, en daar poort 3306 open zetten
- Bij het onbereikbaar zijn van de andere server: poort 3306 open laten, en verder geen actie ondernemen. Eventueel terugkoppelen aan systeembeheerder per e-mail/SMS, en/of signaleren aan client app.

Hmmm, klinkt zo gek nog niet eens.
Ik draai inmiddels al meer dan twee jaar de MySQL replication mogelijkheden, en ben daar wel over te spreken.

[Verwijderd]

B-Man: Ik zou het anders oplossen: met een heartbeat kijken of de master/slave nog leeft. Zo niet dan moet de backup middels een scriptje gewoon het ip overnemen van de master. Klaar ben je, dit kun je evt via een consolekabel doen en via je ethernet verbinding. Hoef je je clients ook niet om te gaan schrijven en je kan de twee systemen verder gelijk houden wat makkelijk is met het beheer.

[B-Man]

Verwijderd schreef op 06 november 2004 @ 00:17:
B-Man: Ik zou het anders oplossen: met een heartbeat kijken of de master/slave nog leeft. Zo niet dan moet de backup middels een scriptje gewoon het ip overnemen van de master. Klaar ben je, dit kun je evt via een consolekabel doen en via je ethernet verbinding. Hoef je je clients ook niet om te gaan schrijven en je kan de twee systemen verder gelijk houden wat makkelijk is met het beheer.

Probleem is echter dat ik geen public en private net heb voor de servers, en er ook geen seriele kabel tussen kan hangen. Takeover is dan nog geen probleem, het is echter wel een probleem als de hoofdserver na een crash weer online zou komen.
Mijn 'serverpark' draait nu bij 1und1 in duitsland, een hele serie rootservers. Ik heb vandaag eens uitgezocht wat het zou gaan kosten als ik zelf ergens een half rack huur, en dat vol hang met dell spul (wat poweredge servers, switches, enz), en dat is in de nabije toekomst misschien ook een optie.
Het is een beetje zoeken naar balans tussen wat nodig is en wat het kost. As usual.

[Verwijderd]

B-Man schreef op 05 november 2004 @ 16:38:
leeko: ik ben al een paar keer tegen C-JDBC aangelopen, en ga daar zeker eens mee testen. [...]
Het is namelijk zo dat de database server naast Java/JDBC clients ook PHP clients heeft, en die wil ik niet via JDBC laten verbinden (onhandig, want dan zal ik PHP in en servlet container moeten gaan draaien).

Je kunt C-JDBC ook aanspreken via een ODBC-JDBC bridge.

[hennink]

Waarom niet de volgende oplossing.

Je maakt voor elke db een readonly account.
Hiermee doe je , software matig verdelen, naar rato beiden machines belasten.
Kan opzich natuurlijk snel met een klein stukje code met daarin ook nog een check of de connectie uberhaupt bestaat.
Zou je verbinding dan gewoon met een functie als getDatabaseConnection ophalen, zie je in je code zelf verder niet meer hoe het zit.

Het updaten van de content kan je dan via een read/write acount die de , op dat moment actieve master, pakt.

Voor het updaten houd je dan wel het probleem dat je erachter moet komen wie de master is, maar volgens mij is dit vanaf MysQL 4.1X zo geregeld dat ze dit onderling wel kunnen uitvechten en kan je dus heel lomp naar een van de bakken wegschrijven. MySQL regelt het zelf vervolgens hoe dit verdeelt wordt (maar weet dit niet heel zeker)
Voordeel is dat je wel beide machines kan belasten wat betreft read acties en je kan het makkelijk uitbreiden met extra db-servers.

[B-Man]

hennink: Ik wil niet teveel in mijn applicatie inbouwen, maar liever gescheiden onderdelen hebben.
MySQL 'roept' al tijden dat er fatsoenlijke multi-master support gaat komen, of anders gezegd: automatische (werkende) failover. Dit zou eerst in 4.1 zitten, maar ik zag het toevallig een paar dagen geleden op de roadmap staan voor 5.1; Dat schiet niet op dus

[killercow]

kan je niks met mysql cluster?
http://www.mysql.com/products/cluster/
Dat doet volgens mij precies wat jij wilt, wat de kosten zijn weet ik niet, maar je hebt zo te zien een budget,
En anders kunt je eventueel een multimaster setup doen en dan net als wikipedia.com de boel naar elkaar laten repliceren.

[B-Man]

killercow schreef op 08 november 2004 @ 20:42:
kan je niks met mysql cluster?
http://www.mysql.com/products/cluster/
Dat doet volgens mij precies wat jij wilt, wat de kosten zijn weet ik niet, maar je hebt zo te zien een budget,
En anders kunt je eventueel een multimaster setup doen en dan net als wikipedia.com de boel naar elkaar laten repliceren.

MySQL Cluster is een 100% in memory oplossing, met andere woorden: de hele database in het geheugen. Geen succes dus. Meldde dat trouwens ook al in mijn openingspost:

(Ik ben op de hoogte van MySQL Cluster, maar dat is 100% memory-based: niet leuk met een database die 'groot' is (4-10GB)

multimaster met tweeweg replication draai ik nu ook al, waar het om gaat is het failover mechanisme en loadbalancing, buiten de applicatie om. Dus ofwel direct in MySQL, ofwel m.b.v. middleware of een extra daemon.

[Acmosa]

Misschien kan je eens naar een Stratus server kijken. Als ik me niet vergis is dit een echte hardware oplossing.
http://www.stratus.com/products/index.htm

[B-Man]

Pinky schreef op 09 november 2004 @ 10:38:
Misschien kan je eens naar een Stratus server kijken. Als ik me niet vergis is dit een echte hardware oplossing.
http://www.stratus.com/products/index.htm

Klinkt zeer zeker interessant, maar ik mis de volgende zaken:
- wat kost het om een fault tolerant linux-based systeem neer te zetten? (T series)
- hoe werkt het systeem? Kan ik mijn applicaties gewoon draaien, en handelt het systeem alle details af omtrent failover en load balancing?

Ik kan nergens een exacte prijs vinden. Wel een indicatie voor de W-series 2300 (maar dat is een windows oplossing): "In volume it will be priced below $10,000" (bron)

Grappig trouwens, als ik zoek op 'stratus t series' met google, verschijnt er onder sponsored links een linkje naar IBM

[Acmosa]

Bel ze zou ik zeggen.

http://www.nl.stratus.com/contact/index.htm


Google rulez

[nielsj]

Ik zou kiezen: "Database replication + hardware oplossing/load balancer".

als de performance het toe laat zou ik kiezen voor een heartbeat oplossing, (de bijde database servers hebben een machine ip adress , en hearbeat failt het service ip adress over). Voordeel hiervan is dat je queries altijd op de actieve master uit komen, en je geen rare problemen krijgt door dat er geen replicatie delay is.

als je ook opzoek bent naar loadbalancing kan je een tcp loadbalancer gebruiken (de meeste loadbalancer kunnen/zijn dat). dit is dan niet echt een loadbalancer op querie nivo, maar meer op tcp nivo, dus moet je applicatie wel meer dan 1 connectie naar de database hebben. ook moet de applicatie er tegen kunnen als een database connectie dood gaat.

op m'n werk gebruiken we hier keepalived voor. we balancen de met keepalived over een groep van 6 slaves die allemaal in replicatie lopen. werkt prima

wat mij betreft maakt het niet veel uit of je kiest voor een hardware loadbalancer, of een software loadbalancer, functioneel zijn ze aardig gelijkwaardig tegenwoordig . voor het loadbalancen van databases is een software loadbalancer misshcien wel makkelijker, omdat je wat meer mogelijkheden hebt om de gezondheid van de realservers te testen

[Verwijderd]

NielsJ schreef op 10 november 2004 @ 00:01:
Ik zou kiezen: "Database replication + hardware oplossing/load balancer".

als de performance het toe laat zou ik kiezen voor een heartbeat oplossing, (de bijde database servers hebben een machine ip adress , en hearbeat failt het service ip adress over). Voordeel hiervan is dat je queries altijd op de actieve master uit komen, en je geen rare problemen krijgt door dat er geen replicatie delay is.

Hoe zorg je met deze oplossing ervoor dat je DBs in sync met elkaar zijn?
Hoe handel je je inserts/updates af?

[nielsj]

Verwijderd schreef op 10 november 2004 @ 13:41:
[...]
Hoe zorg je met deze oplossing ervoor dat je DBs in sync met elkaar zijn?
Hoe handel je je inserts/updates af?

op m'n werk gebruiken we hiervoor mysql replicatie tussen de database nodes. We zorgen er voor dat de queries alleen op het failover adress aan komen, zodat alle queries alleen op de actieve node komen. (zo heb je ook geen last van queries die in de verkeerde volgorde kunnen aankomen)

je kan kiezen voor een dubbel replicatie van systeem A replicatie naar B en van B replicatie naar A. Ik zou de nice failback optie in je ha software gebruiken, waardoor je na een failover geen klapperend geheel krijgt.