Re: Vinum, RAID-5, 3HDs

On Mon, Dec 30, 2002 at 07:24:18AM +0100, Oskar Eyb wrote:
> On Sun, Dec 29, 2002 at 07:55:45PM +0100, Andreas Braukmann wrote:
> > Bei 5 und 7 Spindeln liegen (wenn ich mich recht erinnere)
> > "Sweet-Spots" im Verhaeltnis zwischen Performance, Verschnitt
> > und Ausfallsicherheit.
>
> OK, das ist mir dann nochmals 2 Festplatten auch nicht Wert..

Ist klar, wenn du die Platten bereits besitzt.
Oftmals kann man auch nur 4 Platten anklemmen.
Wenn du die Möglichkeit hast die Platten einzeln an IDE Kanäle
anzuklemmen, dann solltest du diese auch nutzen - weniger wegen
Sicherheit, als wegen der Performance - Raid basiert darauf Platten
gleichzeitig zu beschreiben - wenn die Platten dann zuallig am gleichen
Kanal hängen, dann bremst das bei IDE aus.

> > > Code-Komplexität und die Erweiterbarkeit
> > > ist (anscheinend??) bei R5 nicht gegeben, was mir jedoch ziemlich wichtig ist.
> >
> > Was genau meinst Du hier mit Code-Komplexitaet und warum ist
> > Dir das wichtig?
>
> Mit wichtig meinte ich eigendlich die Erweiterbarkeit - ca 75 GB mögen
> jetzt ausreichen, kann aber morgen schon anders sein.
> Das der RAID-5 code erheblich komplexer und damit eventuell
> Fehleranfälliger ist, habe ich mehrmals gelesen, AFAIK sogar hier auf
> der Liste und vom Chief-Entwickler selbst.

Der Vinum R5 Code ist eigendlich recht ausgreift.
Die von mir angesprochenen Fehler können zwar vorkommen, aber je weniger
du schreibst und je öfters du von Vinum die Parität prüfen lässt, je
unwahrscheinlicher wird ein Fehler bzw daraus folgende Probleme.
Nicht zuletzt haben auch die meisten ach so tollen IDE Hardware-Raids
die gleichen Problem, ohne die Möglichkeit neu zu syncronisieren.

Es geht einfach darum wieviele Fehler man sich erlauben kann, damit
man noch Glücklich ist.
Die ganze billige PC Technik funktioniert nicht 100%, aber sicher
genug, damit die meisten Leute zufrieden sind.
So macht DRAM ab und an Bitfehler - PC RAM halt nicht alzu oft.
annähernd 100%ig wird es erst mit ECC.
Genauso mit IDE vs. SCSI - IDE macht einfach Fehler, die dir mit
SCSI nicht passieren können - allerdings selten genug, daß es die
meisten nicht mehr stört.

Erweitern kann man theoretisch auch mit R5, aber es gibt noch keine
Implementierung dafür - außer man geht über einen Zusatzplex.

> > Was natuerlich problemlos(?) gehen mit vinum gehen muesste(?),
> > waere die Definition weiterer RAID-5 Plexes (jeweils aus mind.
> > 3 Subdisks), die man dann zu einem konkateniertem Volumde
> > zusammenfuegen kann.
>
> Dann müssens immer gleich 3 disks sein, was insbesondere bei IDE und
> meinen Geldbeutel schnell unmöglich wird.

Du wirst später vermutlich sowieso größere Platten kaufen.
Das passt aber nicht ins Striping und R5 Konzept.
Weiterhin stellt sich auch die Frage, ob du wirklich das Filesystem
vergrößern willst, oder doch lieber ein zusätzliches Einrichtest.

> > Der Verschnitt ist bei einem "stripped mirror" oder einem
> > "mirror of stripes" aber genauso hoch wie bei einem einfachem
> > Spiegel.
>
>
> Mh, was gäbe es sonst noch für Möglichkeiten, eine Redundanz ohne ~ 50%
> Verschnitt zu haben bei guter Skalierbarkeit?
> Ich sollte noch dazuzusagen, das hier noch einige 20er und 40er Platten
> rumliegen, zudem wie gesagt 3x 80. Vielleicht kann man da was mixen,
> ohne übermäßig an Komplexität zuzulegen.

Die Antwort lässt sich recht einfach Formulieren.
Du willst alle Daten trotz Ausfall einer Platte erhalten.
Also mußt du auch auf die Kapazität einer Festplatte verzichten.
Sprich eine Platte ist Redundant.
Genau das leisten Raid1 und Raid5.
Raid1 für zwei Platten und Raid5 für 3-n Platten.
Ganz extrem Formuliert sogar auch bei einer einzelnen Platte,
allerdings bleibt nach Abzug der Redundanz keine Nutzkapazität mehr
übrig - funktioniert aber - 0 Bytes draufpacken und 0 Byte Verlust bei
Ausfall einer Platte. SCNR.

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