Re: NFS-Replica

Hallo,

On Sun, 29 Dec 2002, Bernd Walter wrote:

> 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?

Nicht wirklich. Aber ich habe frei und bis jetzt hat sich noch kein
unterbeschaeftigter Hacker an meine wackligen Server geschlichen;-)
 
> > 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.

Wenn ich dem Stevens glaube, muesste sich ein NFS-Filehandle aus Major-
und Minorcode des Devices, auf dem das Filesystem liegt, Inode und
Inode Generation No zusammensetzen. Da muesste ein Cache aufgebaut werden,
der bei jeder Rueckgabe eines neuen Filehandles an den Client sich merkt,
was der Replica fuer eines fuer das selbe File benutzt und die Filehandle
dann vor Weitergabe eines Requests an den Replica austauscht.

> 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.

Vielleicht nicht gleich die eierlegende Wollmilchsau, sondern ein fuer den
Client verborgener Replica. Was der treibt, bekommt nur der Server zu
wissen, um im Zweifelsfalle z.B. Alarm auszuloesen.

Natuerlich waere schon ein vom Client nicht bemerkter Uebergang zum
Replica toll, aber es wuerde sicher schon eine ganze Menge bringen, wenn
man wuesste, das die Daten der letzten Stunden nicht weg sind, wenn der
Server abschmiert.

Bei mir wird zum Beispiel taeglich per rsync gemirrort und 23h
Datenverlust wuerden nicht unbedingt grosse Begeisterung ausloesen.

> Ganz strenggenommen müssen sogar Lesezugriffe über beide Server gehen,
> da davon ja die atime abhängt.

Na ja, kann man sicher machen. Wer verwendet wo schon die atime? Einmal
nur zum File geguckt und schon ist die alte weg;-)
 
> > 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.

Nun, das koennte NFS ja ganz elegant erledigen - wenn ich vom Server als
Client an den Replica gehe, passiert der Zugriff irgendwann - wenn der
Replica wieder da ist. Mit geeigneten Mountoptionen sollte man nur dafuer
sorgen, dass die echte Server-Maschine nicht haengt.
 
> 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.

Ja, der "NFS-Master-Server" koennte die Requests annehmen, an Hand des
Filehandles feststellen, was denn da bearbeitet werden soll, das in ein
Logfile schreiben, das Paket an den "normalen" NFS-Server schicken, sowie
einen gleichlautenden Request generieren, den der gleichlautende
NFS-Client an den Replica schickt. Die ausgehenden Antworten des lokalen
NFS-Servers werden an den "Master-Server" umgeleitet, der dann im Log
abhakt. Das gleiche tut er, wenn der Replica den NFS-Request ordentlich
bearbeitet hat.

Damit wuerde man die Intelligenz, die NFS besitzt, ja mitnutzen, so dass
die Ausfaelle recht gut ueberstanden werden koennten. Die beiden
"normalen" Server kriegen ihre Pakete nur vom "Master-Server" und der
arbeitet, wenn eine Maschine ausgefallen ist, das Logfile ab.

So sollte ich den "NFS-Proxy" taufen.

Sicher, wenn die Servermaschine wirklich ausfaellt, ist das fuer den
Client nicht transparent, der muesste "ummounten", aber man haette alle
Daten, die bis dahin den Replica erreicht haben, sicher.

Und ob Du das okay schickst, wenn der Server fertig ist oder erst, wenn
der Replica auch "okay" sendet, kannst Du konfigurieren.

BTW: So richtig traue ich dem "Okay" eines NFS-Servers nicht. Auf dem Weg
zu einer lokalen Festplatte liegen soviele Caches (NFS, lokales
Filesystem, Harddisk), das ich bei Steckerziehen auf das letzte
geschriebene Bit nicht viel Geld verwetten wuerde.

> 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.

Ja klar, das beruehmte "Stale NFS handle" Zur Loesung eben ein Cache der
Filehandle, siehe oben.
 
> > 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.
>
>
Danke fuer den Tip, ich werde mal hingucken.

Einen guten Rutsch
wuenscht
Peter

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-chat" in the body of the message
Received on Mon 30 Dec 2002 - 12:04:00 CET