PDA

Bekijk Volledige Versie : Twee server synchroniseren?



BDigitinternetdiensten
15/05/09, 09:23
Ik heb hier twee dell sc1425 liggen en deze wil ik met elkaar laten werken, dus als de ene uitvalt dat dat andere het direct overneemt. Hierbij wil ik graag een beheerpaneel zoals directadmin op draaien, welke oplossingen heb ik hiervoor? Heb hier namelijk nog nooit me gewerkt en wil me er graag in verdiepen. Dit even uitgaand dat ze beide in hetzelfde netwerk staan

Alvast bedankt!

Wido
15/05/09, 11:12
Met DRBD, Xen en heartbeat kan je zoiets prima realiseren.

Tim.Bracquez
15/05/09, 11:25
Wat wido zegt, of zonder virtualisatie en op de machines zelf maar dan goed opletten wat of hoe.

Jorem
15/05/09, 12:55
Een wat oudere how-to, maar misschien wel handig om te zien hoe je het kan doen: http://www.howtoforge.com/vm_replication_failover_vmware_debian_etch

BDigitinternetdiensten
15/05/09, 13:12
Wido, Heb je misschien een link met een uitleg? Tips en trucks?
Zover ik het nu begrijp zet ik dus bijv op beide servers xen? en dan kan ik het realiseren? Heb er in ieder geval nog nooit mee gewerkt.

Bakker ICT
15/05/09, 14:03
Met DRBD syncroniseer je dus je storage, waarvandaan je je VPS draait, of dit nou Xen of iets anders is maakt niet zo heel erg veel uit. Met heartbeat kan je dus controle doen of je een failover moet doen in case of een storing.

dicktump
15/05/09, 18:34
Je kunt dit met Ganeti doen. Die beheert dan de DRBD en Xen voor je. Ganeti ondersteunt alleen geen automatische failover (wel handmatige failover), dus dan zou je zelf even een klein scriptje daarvoor moeten schrijven.

Op de Xen node draai je dan gewoon een instance met een of andere Linux distributie, waar je dan weer DirectAdmin op installeert.

Tim.Bracquez
16/05/09, 23:53
Even een aanvulling naar aanleiding van een succesvolle "Resource Group Takeover".
* Je kan het virtueel gaan doen zoals hierboven vermeld. Waarbij je dus van de disk een RDBD disk maakt (RAID-1 netwerk disk) en met Heartbeat(of met eigen scripts) bijvoorbeeld een Active-Passive setup maken waarbij de machine 1 draait en als die er uit ligt de machine 2 boot en het overneemt.
=> Hierover had Wido een kleine How To geschreven als ik me niet vergis (of toch hoe heartbeat en drbd gebruikt kunnen worden voor een HA-iSCSI target te maken)

* Niet virtueel installeer je het OS op beide machines (of in een VPS) je gaat dan een DRBD disk maken waarop je dan je /home /tmp /etc's ... gaat zetten (goed over nadenken zodat je lekker kan blijven doorshoppen / surfen als er bijvoorbeeld een webshop opstaat etc...). Het leuke hierbij is dat je niet afhangt van 1 software zoals Xen maar dit gewoon tussen Xen & Vmware gaat doen(multibrand strategy). Waarbij dan ook nog eens de timout enorm laag is bij het overnemen van de active naar de pasive node.

Hierin kan je uiteraard zo ver in gaan als je zelf wilt.

PS: probeer dit niet zomaar op meerdere locaties zomaar op te zetten want dan moet je netwerk gericht ook gaan kijken...

BDigitinternetdiensten
17/05/09, 17:41
Bedankt voor alle tips etc, ik ga binnenkort ff het 1 en ander uitproberen!

maxnet
17/05/09, 19:35
Houd er wel rekening mee dat DRBD geen alles omvattende oplossing voor dit probleem is.

Deze synchroniseert alleen op harddisk blok niveau, en komt dus pas in actie op het moment dat er naar schijf geschreven wordt.
Database software zoals MySQL schrijft wijzigingen echter niet meteen weg, en daar zul je dus een aparte oplossing voor moeten zoeken.


Los dat DRBD alleen goed werkt als de servers op dezelfde lokatie staan. Probleem is dat hij bij schrijfbewerkingen blijft wachten tot de andere server de data ook weggeschreven heeft. (ja, er is een asynchrone optie, maar ook die blijft wachten op het moment dat zijn buffer vol zit).

Wido
17/05/09, 19:48
Houd er wel rekening mee dat DRBD geen alles omvattende oplossing voor dit probleem is.

Deze synchroniseert alleen op harddisk blok niveau, en komt dus pas in actie op het moment dat er naar schijf geschreven wordt.
Database software zoals MySQL schrijft wijzigingen echter niet meteen weg, en daar zul je dus een aparte oplossing voor moeten zoeken.


Los dat DRBD alleen goed werkt als de servers op dezelfde lokatie staan. Probleem is dat hij bij schrijfbewerkingen blijft wachten tot de andere server de data ook weggeschreven heeft. (ja, er is een asynchrone optie, maar ook die blijft wachten op het moment dat zijn buffer vol zit).Je kan ook altijd je filesystem sync mounten, neemt wel een stuk performance weg, maar dat is te overzien.

Al moet je bij een failover altijd rekenen op een mysqlcheck :)

Tim.Bracquez
17/05/09, 20:30
Al moet je bij een failover altijd rekenen op een mysqlcheck :)
Klopt, of een master - master setup maar dan gaat die het niet direct over nemen bij fouten. Het is maar hoe je het wilt hebben.

Bakker ICT
17/05/09, 20:33
Mjah daarom is een VPS beter die automatische failover heeft, en gedraait wordt vanaf een drdbd strorage aangezien TS er ook DirectAdmin op wilt draaien.

Tim.Bracquez
17/05/09, 20:41
Mjah daarom is een VPS beter die automatische failover heeft, en gedraait wordt vanaf een drdbd strorage aangezien TS er ook DirectAdmin op wilt draaien.
Hangt af hoe je dat aanpakt, zit je toch met een grotere downtime...? tenzij je de nodige HA ESX / XEN licenties koopt.

En die mysqlcheck ga je dan nog moeten uitvoeren... een mysql server die ineens stop kan fouten bevatten...

maxnet
17/05/09, 20:53
Je kan ook altijd je filesystem sync mounten, neemt wel een stuk performance weg, maar dat is te overzien.

Daarmee schakel je de write caching van het besturingssysteem uit, maar meen dat MySQL zelf ook cached.
Of is er ook een optie waarmee je dat kan uitschakelen? Weet dat dit bij bijv. PostgreSQL wel instelbaar is.


Waar het mij omgaat is dat de TS zich ook moet realiseren dat er aan failover oplossingen niet alleen voordelen, maar ook nadelen kunnen zitten. Zeker als de overschakeling automatisch plaatsvindt.

En hoe complexer je setup, hoe makkelijker er mensenlijke fouten gemaakt worden.
Niet alleen met instellen, maar ook met kleine stomme dingen.

Trek je per ongeluk de verkeerde netwerkkabel uit de switch, dan levert je dat bij een normale opstelling 5 minuten downtime op.
Trek je per ongeluk de netwerkkabel van een server in een automatische failover configuratie eruit, en schakelt het systeem over, dan kan dataverlies het gevolg zijn.

Mysqlcheck verwijdert corrupte gegevens. Als je geluk hebt is dat een stukje index dat opnieuw gegenereerd kan worden, maar het kan net zo goed data zijn, die je niet meer terug krijgt.

Wido
17/05/09, 21:12
Daarmee schakel je de write caching van het besturingssysteem uit, maar meen dat MySQL zelf ook cached.
Of is er ook een optie waarmee je dat kan uitschakelen? Weet dat dit bij bijv. PostgreSQL wel instelbaar is.Ik weet niet zeker of MySQL writes cached. Ik heb iig meerdere DRBD setups met MySQL er bovenop draaien en heb in de praktijk al meerdere failovers mee gemaakt.

Een mysqlcheck is altijd nodig, maar data ben ik nog nooit kwijt geraakt.


Waar het mij omgaat is dat de TS zich ook moet realiseren dat er aan failover oplossingen niet alleen voordelen, maar ook nadelen kunnen zitten. Zeker als de overschakeling automatisch plaatsvindt.

En hoe complexer je setup, hoe makkelijker er mensenlijke fouten gemaakt worden.
Niet alleen met instellen, maar ook met kleine stomme dingen.

Trek je per ongeluk de verkeerde netwerkkabel uit de switch, dan levert je dat bij een normale opstelling 5 minuten downtime op.
Trek je per ongeluk de netwerkkabel van een server in een automatische failover configuratie eruit, en schakelt het systeem over, dan kan dataverlies het gevolg zijn.Niet mee eens, als je een cross-cable gebruikt voor DRBD en daarbij Heartbeat via de cross-link én een null-modem laat checken dan heb je alleen een interruptie tussen DRBD, maar geen failover.

En om de vraag te beantwoorden, waarom virtualisatie? Nou, het is vele malen makkelijk om een DA setup in Xen (of VMWare) te draaien en zijn onderliggende block-device te repliceren dan om een DA setup te repliceren.

Nu heeft DA geen weet van een synchronisatie of een failover, dat gebeurd volledig om zijn weet heen. Ook heb je in het DA OS geen speciale aanpassingen nodig.

Een setup als deze is overigens ook helemaal niet zo moeilijk. Ik draai er hier meerdere van en heb altijd gekozen voor express alleen DRBD en Xen en GEEN automatische failover.

Gemiddelde response-tijd op een SMS is <15 min. Constateer je dat een node dood is? Dan heb je met 2 commando's je VM weer online op de andere node, downtime is dan ongeveer 15 minuten, prima te overzien.

Bakker ICT
17/05/09, 21:18
Yes, helemaal mee eens, hoe vaak komt het tenslotte voor dat een node dood gaat...

maxnet
17/05/09, 22:18
Een mysqlcheck is altijd nodig, maar data ben ik nog nooit kwijt geraakt.


Is inmiddels weer een paar jaar terug, maar heb een keer meegemaakt dat na een stroomstoring en mysqlcheck, Mysql compleet niet meer op wilde starten.
Vermoedelijk omdat hij tevens 1 van de tabellen in de "mysql" systeem database had gerepaireerd, en dat wellicht niet helemaal goed was gegaan.

Maar goed, weet natuurlijk niet of dat de schuld van de check is. Kan ook zijn dat het bestandssysteem zelf corrupt was geraakt of iets dergelijks.



Niet mee eens, als je een cross-cable gebruikt voor DRBD en daarbij Heartbeat via de cross-link én een null-modem laat checken dan heb je alleen een interruptie tussen DRBD, maar geen failover.


Ah, aan de mogelijkheid van een null-modem kabel had ik inderdaad nog niet gedacht.
Hoewel dat wel de afstand tussen de machines beperkt.
Zou die liever in aparte racks met enige afstand ertussen plaatsen.

Wido
17/05/09, 22:55
Is inmiddels weer een paar jaar terug, maar heb een keer meegemaakt dat na een stroomstoring en mysqlcheck, Mysql compleet niet meer op wilde starten.
Vermoedelijk omdat hij tevens 1 van de tabellen in de "mysql" systeem database had gerepaireerd, en dat wellicht niet helemaal goed was gegaan.

Maar goed, weet natuurlijk niet of dat de schuld van de check is. Kan ook zijn dat het bestandssysteem zelf corrupt was geraakt of iets dergelijks.Vaak zijn het daar de disk-caches die nog data bevatten wat de hele boel corrupt maakt. Of bijv RAID controllers zonder BBU.





Ah, aan de mogelijkheid van een null-modem kabel had ik inderdaad nog niet gedacht.
Hoewel dat wel de afstand tussen de machines beperkt.
Zou die liever in aparte racks met enige afstand ertussen plaatsen.Gaat opzich prima, wij hebben null-modem kabels van 10 meter in gebruik.