Re: Raid 1 - Voraussetzungen

From: Andreas Braukmann <braukmann(at)tse-online.de>
Date: Sat, 2 Feb 2002 23:50:14 +0100

On Sat, Feb 02, 2002 at 10:31:10PM +0100, Bernd Walter wrote:
> On Sat, Feb 02, 2002 at 09:47:32PM +0100, Andreas Braukmann wrote:
> > Wenn man soetwas ernst meint, wird man wohl (IMHO) eher
> > zu einem "echten" IDE-RAID-Controller greifen; und dann
> > tatsaechlich *auch* den Swap spiegeln.
>
> Wenn du swap spiegelst willst du das die Maschine bei einem
> Plattenausfall durchläuft.

So ist es.

> Dafür ist IDE aber nicht geeignet.

Ok. Ich nehme das ersteinmal so hin, weil es im verallgemeinerten
Fall auch gilt. (Nicht umsonst hab ich bisher von IDE recht weiten
Abstand gehalten (von dataless FreeBSD und Windows clients mal ab-
gesehen).

> Mir ist ein Software SCSI Raid1 lieber als eine egal wie geartete
> IDE Lösung.

Das Problem ist weniger Software gegen Hardware-Raid als die Frage,
wie teuer soll zuverlaessiger Massenspeicher sein. :-/
Ich habe aber das Problem, dass ich in naechster Zeit relativ viel
Plattenplatz benoetige. Die Rahmenbedingungen fuehren (leider) zu
folgendem Anforderungsprofil: gross (mind. 80 GB); leise; kuehl;
geringe Stromaufnahme; "moeglichst" preiswert; "hinreichend" zuver-
laessig. Diese Punkte fuehrten mich fast zwangslaeufig zu einer IDE-
RAID-Loesung. Eine "bezahlbare" SCSI-Loesung, die in dieses Profil
passt, waere mir allemal lieber. Auch im SCSI-Fall waere eine RAID-
Loesung unverzichtbar, weil der Rechner dazu in der Lage sein muss,
auch mit einer ausgefallenen Platte eine gewisse Zeit weiterzulaufen.

> In der Regel sind "echte" IDE Raid Controller ja nicht mal
> statefull - das kannst man mit Vinum sogar als Software besser.
[...]
> In einer anderen Mail habe ich bereits erklährt, warum IDE Raid
> nicht zuverlässig funktionieren kann.

Mit "statefull" meinst Du die in einer anderen Mail beschriebenen
Maengel hinsichtlich zuverlaessiger Rueckmeldung der IDE-Platten
ueber ihre Befindlichkeiten? Hmmm. Dann muss man halt sehr vorsich-
tig bei der Ausfall der eingesetzten Platten sein. Die aktuellen
IBM-Platten (sowohl die qualitativ missratene letzte Serie als auch
die IC35*) liefern (meiner eigenen Erfahrung nach) sehr wohl Infos
ueber Lese-/Schreib-/CRC-Fehler. Auch der Schreibcache laesst sich
zuverlaessig abschalten.
(Und auch im SCSI-Umfeld gab und gibt es hinreichend viele "kaputte"
Produkten, vor denen man sich hueten musste.)

Der gewaehlte 3Ware-Controller verkraftet sterbende Platten auf den
einzelnen IDE-Kanaelen so, wie man es von einem (einfachen) RAID-
Controller erwartet; gleiches gilt fuer defekte IDE-Kabel.

> > > denn es könnte dazu verführen, sonstige Sicherheitsmaßnahmen (z.B.
> > > regelmäßiges Backup) zu vernachlässigen.
> >
> > Jeman, der seine Daten einem RAID-1 anvertraut und des-
> > halb sein Backup vernachlaessigt, wuerde sein Backup auf
> > einem RAID-0 ebenso vernachlaessigen.

Hmm. Mir ging es um die "menschliche" Komponente des besprochenen
Themen-Komplexes "Backup".

> Nicht zwangsweise.
> Ein SCSI Raid1 + UFS Snapshots ist eigendlich recht sicher.

> Es schützt vor Hardwareausfällen, als auch vor Anwendungs oder
> Anwenderfehlern.

Hmmm. Snapshots sind IMHO ein zu Backups und RAID orthogonales Konzept.
Ausserdem gibt es in -stable ja auch noch keine Snapshots. (Leider.)

> Backup braucht man dann nur noch um sich vor FS Fehlern oder
> Überspannung zu schützen.

Hmm. Dennoch wird man die Backups genauso regelmaessig machen wie
sonst auch. Es sinkt einzig und allein die relative Haeufigkeit
eines restores von den Backup-Medien.

> Alles eine Frage wie hoch die Risiken sind.
> Das beste Backup ist jenes das man nie braucht.

Ja.

-Andreas

-- 
no sig.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sat 02 Feb 2002 - 23:50:18 CET

search this site