Re: Fehlerredundante Fileserver

On Mon, Jun 02, 2003 at 11:08:49PM +1000, Peter Ross wrote:
> 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.

vinum + fibrechannel - damit können Platten ein paar Kilometer weiter
entfernt rotieren.
Absolut Solide und bewährte Technik - zudem ausbaufähig.
Die Hardware kostet ein bischen mehr und man braucht eine dedizierte
Glasfaser ins andere Gebäude, aber man schläft man viel ruhiger.
NFS ist nun wirklich nicht das rechte Mittel für die Aufgabe.

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

Da fragt man sich ernsthaft, wieviel der Firma die Daten wert sind,
daß man die mit einer Bastellösung absichert.
Evtl hätte man für den Preis der Suns tatsächlich FreeBSD PCs mit
obiger Fibrechannel Lösung bezahlt bekommen.

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

Ob mans glaubt oder nicht - auch das kann Fibrechannel überwinden.
Wem die extra Kosten für die Leitung zu viel sind, der mag sich mit
I-SCSI Konverter beschäftigen.

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

In dem Fall wäre einfach eine Spiegelhälfte ausgefallen und man hätte
die später erneut syncronisiert.
Wenn man jetzt 3fach spiegelt, dann braucht man eigendlich niemals von
ganz weit weg zu lesen, solange nicht wirklich das Primäre Gebäude
abbrennt.

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

Schon mal über rsync/cvsup nachgedacht?
Lokales 2 fach Mirror und per rsync/cvsup eine 24h verzögerte remote
Sicherung.
Ernsthaft - wie oft glaubst du wirst du die externe Sicherung anwenden?

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

Und dann ist auch noch falsch, weil unmvollständig (dsk/rdsk).

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

Aber das Budget gibt die nötige Manpower her, um das Flickwerk zu
warten?

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

Man kann es seit einiger Zeit kostenlos downloaden.

> > 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 ;-)

NFS hat für die Aufgabe ein ganze Menge an Problemen.
- es kann nicht anständig gecached werden.
- Fehler auf Plattenebene werden erst zig ebenen höher behandelt
- es ist unüblich und damit wenig getestet.
- NFS ist ein komplexes Protokoll und die »normale« Implementierung
  fällt den meisten schon schwer.
- NFS ist nicht für den Proxybetrieb gedacht - FreeBSD exporiert
  deshalb nur lokale Filesysteme.

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

Wenn man lockd braucht - ich habe den bislang noch nicht vermisst.

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

Ja, aber es ist ein Filesystem - mit den obigen Problemstellen.
Es ist einfach nicht sonderlich gut dafür geeignet - zudem gibt es
bereits geeignete Lösungen.

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

Natürlich, deshalb gibt es haufenweise Lösungen - auf Plattenebene :)

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