Re: Vinum, RAID-5, 3HDs

From: Bernd Walter <ticso(at)cicely8.cicely.de>
Date: Mon, 30 Dec 2002 00:53:23 +0100

On Mon, Dec 30, 2002 at 09:34:10AM +1030, Greg 'groggy' Lehey wrote:
> On Sunday, 29 December 2002 at 21:10:20 +0100, Bernd Walter wrote:
> > On Sun, Dec 29, 2002 at 07:55:45PM +0100, Andreas Braukmann wrote:
> >> On Sun, Dec 29, 2002 at 03:43:00PM +0100, Oskar Eyb wrote:
> >>> Beim Lesen über Vinum taten sich einige Unklarheiten auf. Es werden
> >>> 5 Platten für RAID-5 empfohlen,
> >>
> >> Bei 5 und 7 Spindeln liegen (wenn ich mich recht erinnere)
> >> "Sweet-Spots" im Verhaeltnis zwischen Performance, Verschnitt
> >> und Ausfallsicherheit.
> >
> > Da Problem mit R5 ist, daß es beim schreiben wesentlich langsammer
> > ist, als ein Mirror.
> > Mit 3 Platten wiegt der Preisvorteil das nur bedingt wieder auf.
> > Für 160G Nutzkapazität kannst du z.B. 3 80G Platten oder 5 40G
> > Platten nehmen.
> > Die 5 Platten mögen durchaus günstiger und in der Summe schneller sein.
>
> Ich glaube, das stimmt nicht mehr. Die drei 80er dürften billiger
> sein, mindestens hierzulande.

War auch nur ein Beispiel.
Wie sich das mit dem Preis verhält muß jeder im jeweiligen Fall selber
ausrechnen.

> >> Der Verschnitt ist bei einem "stripped mirror" oder einem
> >> "mirror of stripes" aber genauso hoch wie bei einem einfachem
> >> Spiegel.
> >
> > Nicht zuletzt besteht ein einfach gespiegeltes R1 aus einer geraden
> > Anzahl Plexe - da muß man dann unabhängige Datenbereiche auf die
> > gleichen Spindeln legen.
>
> Die Anzahl braucht nicht gerade zu sein, nur mehr als eins.

Ich bezog mich auf ein einfach gespiegeltes System.
Natürlich kann man ein 80'er Plex und ein concat mit 2x40 Plex nehmen.
Aber im Falle von gleich großen Platten kann ich mir keine Sinnvolle
Variante mit Raid1 vorstellen.

> > Performancemäßig geht das schnell nach hinten los.
>
> Nur beim Schreiben. Beim Lesen wird's besser.

Das bezog sich auf die Vorstellbaren RAID1/0 Kombinationen mit 3 gleich
großen Platten.

> > Außerdem darf sich kein Plex die gleiche Spindel mit einem anderen
> > Teilen, weil bei Ausfall der Platte dann beide Plexe weg wären.
>
> Nein, stimmt nicht. Es sind nicht die Plexes sondern die Subdisks,
> die "weg"gehen. Man kann sie über Kreuz anlegen, solange der
> Adressraum der Subdisks sich auf unterschiedlichen Spindeln befindet.

Wommöglich habe ich da was falsch in Erinnerung.
Was passiert mit einem Volume, wenn von den beiden einzigen Plexen
jeweils eine Subdisk aus einem nicht überlappenden Bereich ausfällt?
Soweit ich das in Erinnerung habe fällt das Volume aus, man hat aber
noch den vollständigen aktuellen Datenbestand, da die verbleibenden
Subdisks aus einem Plex weiterhin syncron gehalten werden.

> > Die Daten kann man dann zwar noch restaurieren, wenn unabhängige
> > Daten- bereiche betroffen sind, aber das System steht erst mal mit
> > Bedarf nach einiger Handarbeit.
>
> Nein, nicht nötig. Das ist der Fall, den ich beschrieben habe.

Ich denke das Ergibt sich aus der obigen Frage.

> On Sunday, 29 December 2002 at 23:39:37 +0100, Andreas Braukmann wrote:
> > On Sun, Dec 29, 2002 at 09:10:20PM +0100, Bernd Walter wrote:
> >
> > Wenn man eh schon mit IDE herumast, wuerde ich immer ein RAID 1+0
> > bevorzugen. Das "Sparen" auf Kosten der Schreib-Performance und
> > mit Vorteilen hinsichtlich der Kapazitaet, lohnt sich eigentlich
> > nur bei hohen Kapazitaetsbedarf in Verbindung mit SCSI-Platten.
>
> Wieso lohnt sich das? Du kaufst eine schnelle, teuere Platte und
> machst die dann wider langsam. Da bist Du mit einer billigen und doch
> gar nicht so langsamen Platte besser bedient.

Ohne Kontrolle über den Medieninhalt der Parität ist R5 mehr ein
Glücksspiel als Datensicherheit.
Das geht nur mit abgeschaltetem Schreibcache oder Tagged Command
Queueing.
In erstem Fall ist die IDE Platte -extrem- viel langsamer und für
den zweiten Fall gibt es recht wenig Marktauswahl.

Stelle dir mal vor es passiert folgendes:
Du schreibst Daten und die Platte fällt Kurzzeitig aus.
Die ausstehenden Schreibtransaktionen sind weg, aber beim nächsten
Zugriff ist die Platte wieder da und du wirst niemals feststellen,
das Schreibvorgänge unter den Tisch gefallen sind.
Mit TCQ hingegen ist bekannt welche Transaktionen noch nicht auf dem
Medium sind und wenn die Platte sich nicht mehr zurückmelded, dann
wird die Platte resetet und die Transaktionen werden die neu ausgeführt.

Natürlich ist das nicht nur ein Problem von R5, aber einen Paritäts-
fehler wirst du ohne Regelmässige Überprüfung niemals feststellen.
Erst ein Ausfall bringt der Parität eine Bedeutung zu - dann verlierst
du trotz Raid Daten - zudem noch Daten in Dateien, die lange nicht
mehr geschrieben wurden, bloß weil die sich die Parität mit oft
geschrieben Daten geteilt haben.
Ein mirror hingegen hat ein solcher Fehler keine Auswirkungen mehr,
sobald der Block neu beschrieben wurde und es sind nur neue Daten
betroffen.
Außerdem gibt es eine gewisse Chance, daß der Fehler auffällt, bevor
es zu einem Geräteausfall kommt.
Ich will das Risiko bei R1 nicht runterspielen, aber zu einem R1 habe
ich mit IDE denoch etwas mehr vertrauen als mit einem R5.
Genaugenommen habe ich allerdings zu IDE überhaupt kein Vertrauen.
Für Qualitätsmangel gibt es einfach keinen guten Workaround.

Wer denoch mit IDE R5 machen will sollte zumindestens ab und an die
Parität prüfen - ein Fehler hier kann einen unerkannten Hardwarefehler
aufdecken.

-- 
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
Received on Mon 30 Dec 2002 - 00:53:34 CET

search this site