Re: Fehlerredundante Fileserver

On Sun, 1 Jun 2003, Matthias Teege wrote:

> Ich nehme an Du meinst eine Art von Umschaltung auf einen parallel
> laufenden Server, der die gleichen Daten hält, wenn etwas anderes als
> die Platte ausfällt.

Ja.
 
> > Wenn Du wirklich die Daten von vor einer Minute sicher haben willst,
> > reicht Backup nicht.
>
> Ja, Du meinst aber nicht Datensicherheit sondern Verfügbarkeit. In
> einem halbwegs normalen Szenario setzt man einen Server mit einem
> RAID System und redundanten Netzteilen ein. Sicherheitshalber hat
> man noch ein Cold-Standby System in der Besenkammer.
>
> Sind die Anforderungen an die Verfügbarkeit höher, kommt PC Hardware
> nicht mehr in Frage.

Ich habe in den letzten Jahren zwei Beispiele, wo ich froh gewesen waere,
etwas wie einen NFS-Proxy zu haben.

In einem Fall wurde ein Bilder-Server in einen anderen Gebaeudeteil
gespiegelt, da es zu den Anforderungen von Kunden gehoerte, auch im Falle
eines abgebrannten Serverraums noch weiterproduzieren zu koennen.. Dagegen
ist auch nichts einzuwenden.

Die Spiegelung erfolgte nachts, wenn uns gegen fuenf nachmittags der
"Master" abgeraucht waere, waere es schon eng geworden - die Arbeit eines
Tages ist 'ne Menge wert, wenn man taeglich aktuelle Daten produzieren
muss (das Fernsehprogramm fuer die Tageszeitungen)

Das Budget gab definitiv nicht mehr her als "gewoehnliche" Suns und die
Glasfaserleitung.

Im anderen Fall waren die Server einen Kontinent weiter, womit
"gewoehnliche" Alternativen wie der Rechner an der Seite, Baender etc.
etwas schwierig zu handhaben waren.

Die Remotesteuerung fuer den Schraubenzieher war gaanz langsam (es hat mal
21h gebraucht, bis ein "spinnender" Router ausgetauscht wurde:-(

Die Daten wurden vom Fileserver ebenfalls alle 24h gespiegelt, ein
Ausfall waere eine empfindliche Stoerung gewesen.

Dann bedenke vielleicht noch, dass in beiden Faellen die Administration
eine One-Man-Show war. Es gehoert zu den groessten Vergnuegen,
/dev/c0t0d0s0 an einem Urlaubsmorgen uebers Mobile zu buchstabieren.

In beiden Faellen kann ich sagen, dass das Budget keinen DECcluster
hergab, ein redundantes Schreiben auf mehr als einer Maschine schon nicht
schlecht gewesen waere.

> Alternativ wäre ein Speicherkonzept wie es Plan9 verwendet. Dort
> ist der primäre Massenspeicher ein WORM Medium. Festplatten/RAIDs
> dienen dort nur als schneller Zwischenspeicher bis die Daten auf
> WORM geschrieben sind.

Plan 9 ist doch ein Tod in Schoenheit gestorben?
 
> Ja, man muß solche Ideen wirklich aus ästhetischen Gesichtspunkten
> betrachten. Ich mag mir gar nicht vorzustellen, wie sich ein
> derartiger NFS Proxy verhält wenn ein Node ausfällt. Wie löst man
> bspw. die Resynchronisation?
>
> Wenn ich sowas realisieren sollte, würde ich wohl eher bei Vinum
> ansetzten und eine Art RAID über mehrere Server bauen wollen.

Ja, das dachte ich auch. Nicht um sonst hat mich Gregs Einwurf vorgestern
animiert, den Stein zu werfen;-)

Allerdings ist es schon etwas anderes, ob man Daten auf lokale Geraete
oder uebers Netz schickt. Mit den dort auftretenden Problemen hat man sich
bei NFS Gedanken gemacht - und bei BSD besonders:-)

NFS-Proxy = NFS + vinum ;-)

> > AFS siehe oben. CODA arbeitet mit ACLs, die Umsetzung des
> > Unix-Permission-Konzepts ist nicht einfach.
>
> Das mag sein aber damit kann man sicher leben. Als ich CODA das
> letzte mal in den Händen hatte, lief es, in Anbetracht des Standes,
> stabil. Es gab nur Probleme bei der Erzeugnung vieler kleiner
> Dateien in kurzer Zeit, wie es bei einem checkout von ports vorkommt.
> Das brachte den Cluster aus der Synchronisation.
>
> Aber wie gesagt, ich habe mir abgewöhnt, mit solchen Sachen meine
> Zeit zu verschwenden. Je weniger Aufwand, desto stabiler das System.
> Es ist einfach zuviel schlechter Code im Umlauf. Der beste Fall
> ist der Verzicht auf NFS obwohl ich mit dem von FreeBSD ganz gut
> zurechtkomme.

Siehe auch die anderen Mails - daie FreeBSD-Implementation ist nicht
schlecht (Bernd erwaehnt ja auch die Archillesferse lockd, aber es sieht
wohl derzeit ganz hoffnungsvoll aus?)

Mit Solaris-NFS konnte ich ueber die Jahre hinweg gutleben.

Es ist prinzipiell nicht einfach, Performance und Sauberkeit beim
Schreiben im Netzwerk hinzubekommen.

NFS ist nach meinem Empfinden im Laufe der Jahre auf Grund schlechter
Implementierung etwas ungerechterweise in Verruf gekommen. Speziell bei
Linux habe ich im letzten Jahr so manches Mal geschaudert. Aber auch
Uralt-Erfahrungen mit Nextstep z.B. waren nicht besonders ermutigend. (Wie
schafft man es, einen Nextstep 3.3 NFS-Server abzuschiessen? Man setze
rsize auf 8192)

Ich kann derzeit nicht genuegend Erfahrungen vorweisen Coda z.B.
betreffend. Aber ob da ein MacOS-X-Client problemlos mit einem Linuxserver
arbeitet? Wie ich hier lese, hat FreeBSD wohl im Bereich AFS derzeit
Defizite.

Ich denke, auf NFS zurueckzugreifen ist insofern sinnvoll. dass es unter
den Netzwerk-Filesystemen das mit der groessten Verbreitung ist (der
Vorsprung duerfte m.E. Zehnerpotenzen betragen) und daher auch dort
sicherlich die groesste Erfahrung eingeflossen ist.

Hat ausser mir wirklich noch niemand den Wunsch gehabt, auf mehreren
Rechnern gleichzeitig zu schreiben? Wenn das so ist, ist meine Idee
wirklich ueberfluessig..

Vielleicht abschliessend eine Bemerkung zu Thema "Wenn man anders designt
haette, z.B. auf Applikationsebene.." - als Admin hat man nicht immer
darauf Einfluss. Ich zumindest habe nicht immer den Luxus gehabt, mit
einem grossen Wurf etwas auf die gruene Wiese zu zaubern..

"Dafuer gibt es kommerzielle Loesungen" - naja, unter dem
Gesichtspunkt hat sogar MS recht, wenn es Linux "einen Clon eines uralten
Betriebssystems" nennt. Wozu gibt es Linux? Und wozu FreeBSD?

Waere schoen, wenn sich hier nochmal jemand zu Sinn und Unsinn und
Implementierungsansaetzen aeussert.

Ich bin mir im Moment nicht so recht im Klaren, ob es der Muehe wert ist..
 
Es gruesst
Peter

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Mon 02 Jun 2003 - 15:11:43 CEST