Re: Einfacher SAS Controller

From: Bernd Walter <ticso(at)cicely7.cicely.de>
Date: Sat, 7 May 2011 12:38:06 +0200

On Fri, May 06, 2011 at 11:33:21PM +0200, Gerd Truschinski wrote:
> Am 06.05.2011 19:29, schrieb Oliver Fromme:
> >Gerd Truschinski wrote:
> > > Am Wochenende werde ich das Ganze zusammenbauen. Ich will erst einmal
> > > 5x500GB Platten anschließen (4 x Daten plus eine Parity). Die liegen
> > > noch rum. Wenn das einigermaßen Durchsatz ergibt sollen 7x2TB Platten
> > rein.
> > > Hat jemand einen Vorschlag für eine gute Platte? Die WD20EARS sollen
> > ja
> > > wg. der Sektorgröße lügen...
> >
> >Nein, die lügt nicht. Sie verwendet am Host-Interface eine
> >Sektorgröße von 512 Bytes, und genau das meldet sie auch.
> >Intern werden Sektoren mit 4KB Nutzdaten verwendet, aber
> >das ist ja etwas anderes. Das hat nichts mit Lügen zu tun.
> >
> Ich finde jetzt nicht die entsprechende Mail, aber im Sommer wurde auf
> der Hackers-Mailinglist darauf hingewiesen, daß die WD bei der
> physikalischen Sektor Größe auch 512Byte statt 4096Byte angibt. Irgend
> was mit "camcontrol ...". Konsens war, daß die Platte nicht nur
> schummelt sonder lügt. Die hatten damit erhebliche Probleme.
> >Ich würde von der EARS dennoch abraten, denn die ist sehr
> >langsam. Wenn Du schon ein fettes SAS-RAID aufbaust und
> >einen guten Durchsatz haben möchtest, solltest Du nicht zur
> >langsamsten 2TB-Festplatte greifen, die existiert. ;-)
> >
> Nee, das will ich ja gerade nicht! Ich will, daß ihr mir 5 Stunden
> Recherche auf dem Internet erspart und sagt: Die Platte XXX wird bei uns
> mit Erfolg eingesetzt :-)
> >Übrigens, bei sieben Platten sollte man sich überlegen, ob
> >man nicht besser schon zweimal Parity (RAID6) oder, je nach
> >Gusto, einmal Parity und eine Spare-Platte (RAID5) anlegt.
> >Sieben ist eigentlich die Schmerzgrenze für ein RAID5.
> Das ist neu für mich. Bisher hatte ich immer 4 Platten, 2x Daten, 1x
> Parity, 1x Spare.
>
> Jetzt habe ich 8 Kanäle. Also 6x Daten und 2x Parity. Spare schenke ich
> mir dann, da es nur 2 Nutzer gibt und meine Freundin den Fileserver
> sowieso nur als zweiten Backup-Server nutzt. Wenn eine Platte abraucht,
> habe ich alle Zeit der Welt, die auszutauschen. Ansonsten ist das mehr
> ein Spiel.
> Und eigentlich sollen die Platten unter ZFS laufen. Gibt es da auch ein
> Problem mit vielen Platten? Also lieber RAID-Z2 statt RAID-Z? Außerdem
> habe ich noch eine 80GB SSD. Da gab es doch eine Möglichkeit die als
> Zwischenspeicher einzusetzen. Mein Ziel ist es eine GB-Ethernetleitung
> auszulasten. Dann muß ich mir beim Abwracken eines Testsystems keine
> Gedanken machen ob auch alle Daten brav auf dem Fileserver liegen. Ich
> glaube, die nächsten Wochen werden spannend...

RAIDZ ist nicht RAID5, vor allem bei vielen Platten.

Grundsätzlich gibt es in einem RAID Verbund das Problem der
Ausfallwahrscheinlichkeit.
Je mehr Platten je wahrscheinlicher ist ein Ausfall.
Da man zumeist baugleiche Platten mit genau der gleichen Betriebszeit
im Einsatz hat sind auch die Verschleissdaten bei allen Platten sehr
ähnlich und damit auch zeitnahe Ausfälle wahrscheinlicher.
Das ist ein Problem, was jegliches RAID, auch RAIDZ hat.

Bei RAID3 kommt noch hinzu, dass immer von allen gelesen (alle minus 1)
und geschrieben wird, d.h. je mehr Platten je mehr Last aufs IO.
Zudem erhöht sich die logische Sektorgröße bei RAID3 mit der Plattenanzahl.

Bei RAID4 und RAID5 wird die logische Sektorgröße nicht erhöht, weswegen
differentielle Paritätsupdates notwendig sind - hierbei kann auch schon mal
was schiefgehen, was mangels Prüfsumme auch erst dann auffällt, wenn man
nach einem Ausfall kaputte Daten (ohne Fehlermeldung) liest.
Je mehr Platten man hat je ungünstiger ist das Problem, zumal man immer
die meiste Last auf der Parität hat - RAID5 rotiert im Gegensatz zu RAID4
zwar die Parität, aber zumeist hat man denoch Peaklasten auf der Parität
und die steigt mit zunehmender Plattenanzahl.
Bei syncronen Schreibvorgängen hat man zudem noch das Problem, dass
man durch das lesen und syncrone schreiben der gleichen Daten immer
eine Umdrehung warten muss.

RAIDZ arbeitet (meines Wissens) nicht nach einem festen Schema.
D.h. man hat zwar 1-Platte pro Datenblock Redundanz, aber keineswegs
immer mit der gleichen Anzahl Datenblöcke.
Beispiel: Ein 5-Platten RAID3 mit 512-Byte Blöcken schreibt mit logischen
2k-Bloken auf 4 Platten je 512 Byte Daten und auf einer Platte die Parität.
Ein RAID4/5 hat den Vorteil, dass es auch 512 Byte schreiben kann, aber
erkauft sich das durch eine differentiellen Paritätsupdate mit riskantem
read-modify-write.
Eine RAIDZ hingegen schreibt genauso wie ein RAID3 immer Daten und
zugehörige Parität in einem, aber mit einer variablen Anzahl Datenplatten,
da auch die Blockgröße variable ist.
D.h. aber auch, dass man bei einer Konstellation mit 7 Platten nicht
zwangsläufig 6 Platten Nutzkapazität hat, sondern eventuell weniger.
Für das Problem beim Ausfall von 2 Platten ist das immer noch doof, weil
trotzdem noch viel zu viele Daten auf 6 funktionsfähige Platten angewiesen
sind, aber man fummelt nicht an bereits geschriebenen Daten rum und hat
nicht die massiven Performancenachteile der großen read-modify-write
Abhängigkeiten.
Man muss dabei aber anmerken, dass Akkugepufferte Controller durchaus
dank ihres Caches mittels delay beim schreiben mehrere read-modify-write
verknüpfen können, sodass hier der Nachteil deutlich abgeschwächt wird,
aber die Wahrscheinlichkeit für Treffer wird mit zunehmeder Plattenanzahl
geringer.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Sat 07 May 2011 - 12:50:05 CEST

search this site