Re: high availability FreeBSD

On Thu, Nov 15, 2001 at 02:54:15PM +0100, universe wrote:
> Bernd Walter wrote:
> > Ein Mirror auf Device Ebene weiss nichts vom Journaling und weiss
> > deshalb auch nicht was zu syncronisieren ist.
> > Das Journaling-FS weiss wiederrum nichts vom Mirror und weiss nicht
> > das was überhaupt was zu syncronisieren ist.
> > Vom Verlust der Incoredaten mal ganz abgesehen.
> >
> > Du hast zuerst geschrieben, das DRBD auf Device Ebene syncronisiert,
> > also ohne Einbeziehung des Filesystems.
> > Das ist eindeutig was anderes als du als Eigenschaften beschreibst!
>
> ich glaube, du hast meine erste mail nicht richtig gelesen. oder ich
> hab mich undeutlich ausgedrueckt. nochmal:
>
> "auf live wurde die DRBD-device (/dev/nbX) wie ein gewoehnliches
> filesystem gemountet." soll heissen: ich entscheide mich z.b. dafuer,

Ein Device ist aber nun mal kein Filesystem.

> alle daten die spaeter auch auf backup zugaenglich sein sollen, in
> /failover abzuspeichern. also mounte ich /dev/nbX nach /failover und
> lege dort meine daten ab. DRBD sorgt dafuer, dass saemtliche daten die
> in /failover gespeichert werden, automatisch auch auf der festplatte
> der backup node abgelegt werden.

Du musst allerdings nicht nur die Daten, sodnern auch die
Differenzdaten speichern.
Da du in dem Fall das Filesystem nicht kennst kann das nicht in der
Partition selber erfolgen.
Worst-case hast du die Spiegelkapazität gleich 4 mal vorzuhalten.

Ich habe mal mit einer Software angefangen die unter anderem ähnliches
machen sollte - allerdings nur für eine Quelle von Schreibdaten.
Daten für Remotepartitionen können auf einen mehr oder weniger großen
Pool von Pufferpartionen als Log gespeichert werden.
Die Schreibbestätigung erfolgt bereits mit erfolgtem Schreiben auf
der Logorientierten Pufferpartition.
Wenn die Logpartitionen alle voll sind wird gewartet bis Platz ist,
es sei denn die Zielpartition gilt als down - dann würde die Partition
als komplett dirty markiert werden.
Das beschleunigt Schreibvorgänge imens, weil nicht mehr auf
verteilte Sekoren und Netzwerklaufzeiten gewartet werden muß und
man kann kurze Ausfälle von Netzwerken überbrücken, ohne gleich
komplett syncronisieren zu müssen oder Performanceeinbußen zu haben.
Damit kann man auch performante und redundante Speichersysteme für
Diskless Maschinen betreiben.
Das ist deshalb attraktiv, weil man mal eben jeder Maschine einen
Plattenanteil ohne Reboot eines Systems zuweisen oder wegnehmen kann.
So ist z.B. denkbar ein 3HE Eurokartenträgergehäuse mit 21 Rechner
zu betreiben, welche 12 Festplatten in zwei 2HE Storageserver
mit veränderbaren Anteilen und Spiegelung teilen.
Über Backplaneresourcen macht man Netzwerk und Managementversorgung.
Man hätte dann 21 Teilredundante Maschinen auf nur 7 HE.
Der zweite Storageserver kann sogar ohne Performanceeinbußen in einem
anderen Land stehen - evtl sogar mit noch mal einem 3HE System als
Kaltreserve.
Wegen wegbrechens der Rückfinanzierung musste ich die Idee leider auf
Eis legen.

> es ist also ziemlich egal ob ich ein gewoehnliches oder ein journaling
> filesystem einsetze. bei einem gewoehnlichen, z.b. ext2, wuerde vor
> dem mounten von /dev/nbX fsck'ed, bei einem journaling fs nicht - nur
> darin besteht der unterschied beim einsatz von DRBD.

OK - das ist jetzt klar.

> die heartbeat-software erledigt den rest.

Und was passiert, wenn beide Maschinen online sind, aber getrennt
wurden.
Jetzt gehen beide Maschinen davon aus einen operativen Betrieb
aufnehmen zu müssen.
Da das syncronhalten der Daten ohne Beachtung des Filesystems passiert,
könnten jetzt beide Maschinen getrennte Differenzen bilden.
Auf Filesystemebene lässt sich ein solches Ereigniss noch automatisch
beheben, beim Devicemirror ist das entweder eine grösserer
Datenverlust, oder Handarbeit.

Es bleibt auch immer noch der Verlust von incore Daten beim Wechsel
der operativen Maschine.
Im Gegensatz zu einem normalen Ausfall und Neustart jedoch gleich
zweimal - es sei denn die hast keine bevorzugte Mastermaschine.

-- 
B.Walter              COSMO-Project         http://www.cosmo-project.de
ticso(at)cicely.de         Usergroup           info(at)cosmo-project.de
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message