[DRBD] Netwerk mirroring reeds vanaf boot?

[DieterVDW]

Ik heb hier 2 identieke servers (Tyan S2882).
Het plan is om de ene als primary server te gebruiken,
en de andere als full redundant server die het dus op gelijk welk
moment van de primary kan overnemen als de primary crasht of zo.
Beschikbaarheid is dus van de allerhoogste prioriteit!

M'n eerste idee was om DRBD (www.drbd.org) te gebruiken om de schijven van beide servers in realtime gesynced te houden via een GB netwerklink.
(DRBD fungeert als een soort block device op een andere block device (een hd bvb) die alle write's die je op die block device van een primary node doet via een gewoon TCP netwerk gaat doorsturen naar de secundary node, alwaar de write dan ook op het block device daar uitgevoerd wordt.)

Het probleem is echter dat je drbd dus niet kunt gebruiken om je root dir gesynced te houden, want dan zou je drbd moeten kunnen uitvoeren vóór je root filesysteem gemount wordt, en dat gebeurt ergens bij het begin van het laden van de kernel denk ik...

Wat zijn mijn vragen nu:
1. Bestaat er een manier om een soort mirroring via het netwerk te doen, zodat je daadwerkelijk je hele filesystem kunt gesynced houden tussen twee servers? Dit zou dan in de kernel moeten ingebouwd zitten veronderstel ik...

2. Stel dat het mogelijk is om de schijven van beide servers in realtime gesynced te houden, zal dit dan eigenlijk wel werken? Maw: is het voldoende om de schijf van de secundary server gesynced te houden met de primary om ervoor te zorgen dat de secundary het op elk moment kan overnemen?
Ik veronderstel dat het wel eens nodig zal zijn om alle services te herstarten op de secundary server als 'm het werk daadwerkelijk moet overnemen.
Maar dan nog...
Stel bvb in het geval van MySQL: de /var/mysql directory op de secundary server wordt dan realtime gesynced met dezelfde dir op de primary server.
Stel nu dat de primary server crasht. Is het nu genoeg om MySQL es te herstarten op de secundary server om ervoor te zorgen dat de secundary het werk kan overnemen? (Ik veronderstel dat de netwerkinstellingen natuurlijk ook aangepast worden om ervoor te zorgen dat de secundary server de requests ontvangt.)

3. De beste oplossing die ik voor het moment kan bedenken is deze:
/var en /home bevinden zich op aparte partities die in realtime gesyncd worden tussen beide servers dmv DRBD . De rest van het systeem wordt regelmatig eens gesyncd dmv rsync . Aangezien dit behoorlijk statische informatie is zou dit niet al te veel resources mogen innemen. Als de primary het dan begeeft worden de netwerkinstellingen veranderd zodat de secundary server de verbindingen ontvangt en dan zou alles vlotjes moeten verderwerken, maar dan op de secundary server.
Wat denken jullie daarvan?

Opmerkingen/suggesties zijn zoals altijd welkom!

[remcohn]

1) je kan met een initrd image dingen uitvoeren voordat init geladen word, dus dat zou kunnen

2) op die manier syncen zou alleen werken bij statische content, mysql is idd een goed voorbeeld waar het NIET werk omdat MySQL alle indexen enzo stevig cached

3) voor 'gewoone' files is een rsync elke 10 minuuten een simpele en betrouwbaare oplossing, maar niet echt 'realtime' natuurlijk

remco

[NaliXL]

Wat je punt 2 betreft: het is maar heel beperkt een oplossing. Als de eerste server bijvoorbeeld vastloopt ten gevolge van een hardware-fout, dan zal het prima werken. Maar loopt je eerste server vast ten gevolge van een fout in één van de apllicaties, dan heb je een heleboel kans dat je tweede server precies dezelfde fout overneemt, omdat ze beide precies dezelfde situatie hebben. Dus: schrijft applicatie 1 een verkeerd bestand weg, waardoor 'ie later crasht, dan zal precies hetzelfde ook gebeuren op de backup-server, omdat die precies hetzelfde verkeerde bestand heeft.

[DieterVDW]

remcohn schreef op 13 juli 2004 @ 19:07:
1) je kan met een initrd image dingen uitvoeren voordat init geladen word, dus dat zou kunnen

2) op die manier syncen zou alleen werken bij statische content, mysql is idd een goed voorbeeld waar het NIET werk omdat MySQL alle indexen enzo stevig cached

3) voor 'gewoone' files is een rsync elke 10 minuuten een simpele en betrouwbaare oplossing, maar niet echt 'realtime' natuurlijk

remco

1) Aha daar heb ik iets aan! Ik ga me daar eens in verdiepen...

2) Maar dat zou dan toch opgelost zijn als ik gewoon de services op de secundary pas start als 'm het werk moet overnemen, niet?

3) Mjah, maar jammer genoeg belast rsync het systeem nogal. Telkens je rsync uitvoert scant 'm dan namelijk het hele filesystem op zoek naar files met een timestamp later dan tijdstip x veronderstel ik. Niet meteen de efficïentste oplossing, en zeker niet als je de beide servers in near-realtime gesynced wil houden...

[DieterVDW]

Cherub schreef op 13 juli 2004 @ 19:23:
Wat je punt 2 betreft: het is maar heel beperkt een oplossing. Als de eerste server bijvoorbeeld vastloopt ten gevolge van een hardware-fout, dan zal het prima werken. Maar loopt je eerste server vast ten gevolge van een fout in één van de apllicaties, dan heb je een heleboel kans dat je tweede server precies dezelfde fout overneemt, omdat ze beide precies dezelfde situatie hebben. Dus: schrijft applicatie 1 een verkeerd bestand weg, waardoor 'ie later crasht, dan zal precies hetzelfde ook gebeuren op de backup-server, omdat die precies hetzelfde verkeerde bestand heeft.

Daar ben ik me van bewust, maar ik schat de kans dat zoiets gebeurt eerder laag in...