Re: NFS-Replica

On Sun, Dec 29, 2002 at 10:34:02PM +1100, Peter Ross wrote:
> Hi,
>
> wie das so unterbeschaeftigten Admins um Weihnachten so geht - man kommt
> auf eine Menge Schnapsideen;-)

unterbeschäftigte Admins? - Aua - sowas gibt es?

> Mich aergert die Schwierigkeit, Daten live zu spiegeln.

Ist ja auch ein Schwieriges Thema.

> Wie erfolgreich kann es sein, NFS "aufzubohren", um einen Replica zu
> ermoeglichen?
>
> Eine Prinzipskizze:
>
> Man nehme ankommende NFS-Pakete, "verdoppele" sie, wenn es sich um
> Schreibzugriffe handelt, mit Hilfe von ipfw oder ipfilter und schicke sie
> an den Mirror. Eventuell schreibt man sie vorher in ein Log, welches der
> Replica lesen kann, falls er mal ausfaellt.
>
> Geht das? Wo liegen die Probleme?

Die zweite Maschine kann die Packlete nicht verstehen, da zum einen die
mountd Token nicht gültig sind und zum anderen die Inodenummern nicht
passen, die in den NFS Packeten eincodiert sind um die Datei zu
identifizieren.

Das zweite Problem ist, daß der Client auf eine Zugriffsbestätigung
wartet - Strenggenommen darf er die aber erst bekommen, wenn beide
Server den Zugriff bestätigt haben.
Ganz strenggenommen müssen sogar Lesezugriffe über beide Server gehen,
da davon ja die atime abhängt.

> Das erste, das ich sehe: Wenn den der Replica ausfaellt - wie sicher
> stellen, dass er wirklich konsistent den Master spiegelt?

In erster Linie mußt du den Ausfall bemerken, damit du nicht mehr auf
die Bestätigungen der ausgefallenen Maschine wartest.
Dann mußt du dafür sorgen, daß die Kenntniss des Zustandes auch einen
Stromausfall überlebt - ansonsten kommen beide hoch und du hast keine
Ahnung davon, daß die nicht mehr syncron sind.

Dann mußt du dir alle Zugriffe merken, damit du beim hochfahren weißt,
was alles zu syncronisieren ist.
Jetzt mußt du feststellen, daß der ausgefallene Rechner wieder online
ist.
Beim Syncronisierenmußt du wissen, welche Files Syncron laufen und
welche nicht, weil der Service ja während des syncronisierens witer-
laufen soll.

> Eventuell erste Loesung - in dem Fall nur informieren und stoppen sowie
> Replikation mit rsync anwerfen, um wieder in sync zu sein. Sicher nicht
> das Tollste, aber man hofft ja, das solche Ausfaelle nicht der Alltag sind
> und Rom ist ja auch nicht in einem Tag erbaut worden..
>
> Eventuell Teil der Loesung koennte ein gleichzeitiges Laufen eines
> NFS-Clients sein, zu dem die Pakete "umgelenkt" werden, um dessen Logik
> bei Ausfaellen des Replicas nutzen zu koennen.

Wie schon oben erwähnt: NFS Packete haben nur für den Server eine
Gültigkeit, für den die Gedacht waren.
Mache dir mal den Spaß und tauschen einen NF Server gegen einen anderen
mit gleicher Konfiguration aus.
Der Client wird sofort Probleme bekommen, obwohl der neue Server ja
die gleichen Files anbietet.

> Ausserdem koennte man ja eventuell die Antwort "erfolgreich" erst
> schicken, wenn Master und Replica erfolgreich waren. Am schoensten
> natuerlich, wenn es konfigurierbar waere.

>
> Ich gebe ja zu, dass ich wahrscheinlich nicht genuegend Zeit und Energie
> haben werde, um das erfolgreich zu implementieren, aber wer weiss. Vorher
> wuerde ich gern ein paar Meinungen hoeren, wie erfolgversprechend Ihr das
> empfindet.
>
> Ich vermute irgendwie, dass es zu kompliziert ist, sonst gebe es das schon
> lang - oder?

Schau dir mal folgendes an:
ftp://shekel.mcl.cs.columbia.edu/pub/fist/
FiST ist ein Layer, der stackable Filesysteme Platformunabhängig zum
laufen bekommt.
IIRC ist auch ein Replica Typ implementiert worden - zumindest würde
es die Entwicklung eines solchen einfacher machen.
Die native Stackable Technology unter FreeBSD ist ja doch recht buggy,
von daher ist der Einsatz von FiST zu empfehlen.
Soweit ich weiß setzt es auf der native Technology mit Workarounds auf.

-- 
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-chat" in the body of the message