Re: Peripherie für Server

From: Bernd Walter <ticso(at)cicely12.cicely.de>
Date: Sat, 9 Apr 2005 12:29:04 +0200

On Sat, Apr 09, 2005 at 08:52:22AM +0200, Stefan Huerter wrote:
> Bernd Walter wrote:
> >>- sprich Wechselrahmenmechanik muß robust sein für tägliches Austauschen.
> >Natürlich, aber selbst einige billige Rahmen verwenden VG Leisten,
> >weilche für VME schon seit jahrzehnten in der Industrie ihre
> >Tauglichkeit bewiesen haben.
>
> Es kommt mir da weniger auf die Mechanik der Führung an, mehr auf die
> Kontaktschnittstellen - wenn da ein Pinchen quer liegt kann man anfang
> zu suchen...

VG Leisten sind Steckübergänge nach DIN 41612.

> >Ich habe mit 8mm Exabyte Laufwerken absolut positive Erfahrungen
> >gemacht.
>
> Habe ich bei "Privatpersonen" schon öfters gehört, in betrieblichen
> Umgebungen aber nur Probleme gehabt, zB bei unsere 2 SUNs mit ExaByte,
> in den letzten 3.5 Jahren 4 Austausch-LW...
> und bei ComputaCenter und davor ähnliches...

Die Streamer machen hier durchaus ihre 50-80 Stunden pro Woche und
das seit zig jahren.
Aber es sind halt betagte 8500'er - modernere mögen da anders sein.
Meine Erfahrungen mit alten Tandberg Laufwerken und mordernen SLR
sagt auch, dass das was anderes ist.

> >Ich habe inzwischen schon zu viele DLT Streamer mit defekten Einzügen
> >gesehen.
>
> so unterschiedlich sind die Erfahrungen... ;)

Offensichtlich.

> >Gerne wird auch vergessen, dass Klimaanlagen in Rechenzentren bei
> >großen Wechslern zu justieren sind.
>
> Einen Wechsler betraf das nicht.
> Wir haben 2 L20 im Einsatz - SUN.
> (2xDLT8000, 1xDLT7000, je 20Cartridges; seit 3 Jahren, keine Probs;
> klimatisiertes RZ)

Glück gehabt oder darum gekümmert.

> >Luft der Klimaanlage sorgt dann gerne für viel Kondensationsfeuchtig-
>
> -> schlechte Klimatisierung?!

Sag ich doch - die Klimaleistung wurde nicht auf die geringe Abwärme
des Racks angepasst und Streamer sind empfindlicher auf Kondensations-
feuchtigkeit als alles andere, was man so üblicherweise ins Rack schraubt.
Wird halt gerne vergessen das zu berücksichtigen.

> >Und denoch kannst du nur maximal 40, bzw. 80G am Stück sichern, ohne ein
> >Band wechseln zu müssen.
> >In der Realität bedeutet das, dass man mit dem Wechseln lebt, oder für
> >einen automatischen Wechsler, bzw. weitere Laufwerke sorgt.
>
> <Besuch beim Kunden>
> K: Tun Sie die Bänder einfach in den Tresor und schließen Sie die Tür
> Ich: Nicht abschließen?
> K: Nein, das sind unsere Produktionsdaten, der Betrieb darf abfackeln,
> die Daten nicht.

Durchaus verständlich.

> >Ich frage mich aber wo die 10MB/s zum streamen herkommen sollen - übers
> >Ethernet wird es jedenfalls bei üblichen 100MBit/s eng.
>
> Legato-Networker oder ADSM (IBM) unterstützen "parallel-streaming" -
> mehrere Clients liefern gleichzeitig die Daten...

Auch in diesem Fall müssen die Daten übers Ethernet rein kommen.
Und die Nachteile liegen auch auf der Hand - das Spielchen funktioniert
durch verschachteltes schreiben und als Ergebniss dauerd auch eine
Rücksicherung länger, sowie benutzt mehrere Medien.
Alternativ kann man man Bufferplatten einsetzen, aber da meinte ich ja,
das es weiteren Handlungsbedarf gibt.

> >Du musst da schon auch in Richtung Bufferplatte, Gigabit Ethernet oder
> >sonstwie weiter denken, ansonsten bricht die Performance ein, während
> >eine Festplatte keine Probleme mit variabler Versorgung hat.
> >Man kann auch über IDE-Platten denken was man will - am Buffer-RAM
> >sparen die Hersteller kaum.
>
> naja, wenn ich da so ne IDE-Platte nehme, wie Du sagst:
> bonnie sagt mir bei meiner >30MB/s.
> lasse ich 2 IO-Tasks darauf laufen, sind es 2x 2-4MB/s.
> (Im Vergleich dazu meine alte Seagate-Barracuda: 1x7MB oder 2x3MB).

Unsinnige Messung, weil misst was komplet anderes.
raw-Backup = streamen - das ist immer linear.
Der Punkt ist ob man Pausen macht oder nicht.

-- 
B.Walter                   BWCT                http://www.bwct.de
bernd(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
Received on Sat 09 Apr 2005 - 12:30:09 CEST

search this site