Forum: PC Hard- und Software Welches RAID für 6 Platten


von Rene K. (xdraconix)


Lesenswert?

Ich habe einen Server mit 6 Platten. Ich bin ja ein Freund von RAID1 - 
einfach und sicher.

Nun möchte ich aber da Mal über den Tellerrand hinaus schauen.

Wie sind eure Erfahrungen mit z.b. RAID10 oder Raid5.

Bei RAID10 würde sich ja ein Setup aus 2x2 + 2 HotSpare anbieten. Aber 
machen zwei HotSpare Platten wirklich Sinn?

Bei RAID5 würde ich dann eher nur auf eine HotSpare setzen und hätte 
dann ja 4D+1P+1HS was ja an Geschwindigkeit und Datenvolumen schon super 
wäre. Allerdings bin ich am Arsch wenn zwei Platten abrauchen. Was 
allerdings in einer ungünstigen Konstellation auch im RAID10 der Fall 
wäre.

Die Größe des Volume ist hier nicht der Ausschlag gebende Punkt. Da dies 
die Systemplatten wären, die Userdaten liegen auf einer externen Fault.

Was sind da so eure Präferenzen?

von Matthias 🟠. (homa)


Lesenswert?

Ein System OS auf 6 Platten?
mach raid 1 für OS und gut ist.
Nutze die anderen 4 für Daten ... Auch hier wieder raid 1 für privat. 
Alles Andere ist meiner Meinung nach im Fall der Fälle zu kompliziert.
Und wenn Du lernen willst dann mach einfach, probe aber auch den 
Ernstfall,soll heißen ziehe Platten als simulierten Ausfall des RAID und 
versuche mal an die Daten ohne Rebuild und einem anderen PC 
dranzukommen...
Ich denke du bist schnell wieder bei RAID 1

von (prx) A. K. (prx)


Lesenswert?

Rene K. schrieb:
> Nun möchte ich aber da Mal über den Tellerrand hinaus schauen.

Wenn schon Neues, dann vielleicht ZFS? Redundanz im Filesystem statt 
separat, Snapshots usw.

: Bearbeitet durch User
von Rene K. (xdraconix)


Lesenswert?

(prx) A. K. schrieb:
> Wenn schon, dann vielleicht ZFS?

Nein, ZFS bin ich aktuell gerade ganz weit weg gekommen. Nach dem 
Verlust einer einzigsten Platte hat sich das ganz Volume verabschiedet 
und lies sich, auch in Teilen, überhaupt gar nicht mehr herstellen. Mir 
sind die Vorteile von ZFS bekannt, aber diese Überwiegen genau diesen 
Nachteil in keinster Weise.

von (prx) A. K. (prx)


Lesenswert?

Rene K. schrieb:
> Allerdings bin ich am Arsch wenn zwei Platten abrauchen.

Dann RAID 6.

von Thomas W. (Gast)


Lesenswert?

Moin, -

meine Frau kocht Suppe mit einem grossen Loeffel. Soll heissen, solange 
Du Deine Requirements nicht aufschreibst kann man nichts empfehlen. Raid 
6 schiebt das Problem mit der Belastung beim Rebuild ein wenig weiter, 
aber prinzipiell ist da kein Unterschied zu Raid 5. Und die Tradeoffs 
Nutzplatte / Plattenplatz vs. Geschwindigkeit sind auch offensichtlich.

Du musst latuernich auch die passende Hardware haben (z.B. Controller 
mit acht Ports) und sinnvoll waere auch ein Monitor-System (nagios, 
Icinga). Und es ist auch wichtig, wie wichtig Dir die Verfuegbarkeit der 
Daten ist.

Gruesse

Th.

P.S.: Heute geht etwas in die Pfanne, nix Suppe.

von Motopick (motopick)


Lesenswert?

Bei sechs Platten wuerde ich genau ein Stripeset ueber alle Platten 
bauen.
Das steigert die Geschwindigkeit naehrungsweise um den Faktor sechs.
Da bekanntermassen einzelne Platten nie kaputt gehen, ist auch
die Zuverlaessigkeit auf eben diesem hohen Niveau. :)

von Gustl B. (gustl_b)


Lesenswert?

Rene K. schrieb:
> Mir sind die Vorteile von ZFS bekannt, aber diese Überwiegen genau
> diesen Nachteil in keinster Weise.

Welche Nachteile? Ich bin gespannt.

von (prx) A. K. (prx)


Lesenswert?

Thomas W. schrieb:
> Raid 6 schiebt das Problem mit der Belastung beim Rebuild ein wenig
> weiter, aber prinzipiell ist da kein Unterschied zu Raid 5.

Es dürfen dann 2 Disks kaputt gehen. Es hilft aber natürlich nicht gegen 
6 annähernd gleichzeitig defekte Disks.

: Bearbeitet durch User
von Thomas W. (Gast)


Lesenswert?

(prx) A. K. schrieb:
> Thomas W. schrieb:
>> Raid 6 schiebt das Problem mit der Belastung beim Rebuild ein wenig
>> weiter, aber prinzipiell ist da kein Unterschied zu Raid 5.
>
> Es dürfen dann 2 Disks kaputt gehen. Es hilft aber natürlich nicht gegen
> 6 annähernd gleichzeitig defekte Disks.

Ja, und haeufig kauft man die sechs Platten in einem Auftrag (wg. Rabatt 
und Gewaehrleistung). Und dann sind sie alle gleich alt, mit gleicher 
Ausfallwahrscheinlichkeit (alt-werden ist Mist).

Gruesse

Th.

von (prx) A. K. (prx)


Lesenswert?

Thomas W. schrieb:
> Ja, und haeufig kauft man die sechs Platten in einem Auftrag

Hey, manche kaufen hunderte Disks in einem Auftrag, alle aus der 
gleichen Quelle. Sollte man die vorsorglich in 49 Parity-Disks und eine 
Date-Disk gruppieren. ;-)

: Bearbeitet durch User
von Gustl B. (-gb-)


Lesenswert?

Da geht es aber um ein anderes Problem.

Nicht Datensicherheit mit Datenverfügbarkeit verwechseln. Ein RAID ist 
eben kein Backup. Aber ein RAID garantiert Verfügbarkeit auch wenn eine 
Platte ausfällt. Dann kommt eine neue Platte rein und es wird wieder die 
Redundanz hergestellt. Und nur während dieser relativ kurzen Phase darf 
keine andere Platte sterben. Und auch das nur um die Verfügbarkeit zu 
garantieren. Stirbt trotzdem eine zweite Platte ist man eben kurz 
offline mit dem RAID und spielt das Backup ein.

von Norbert (der_norbert)


Lesenswert?

Thomas W. schrieb:
> Ja, und haeufig kauft man die sechs Platten in einem Auftrag (wg. Rabatt
> und Gewaehrleistung). Und dann sind sie alle gleich alt, mit gleicher
> Ausfallwahrscheinlichkeit (alt-werden ist Mist).

Da gibt's einen einfachen Trick.
Jeweils nur Eine auspacken, anschließen und sofort hoch laufen lassen.
Mit allen weiteren so verfahren.
So sind sie dann schon vor dem logischen Eingliedern in das RAID 
unterschiedlich stark gealtert. ;-)

: Bearbeitet durch User
von Motopick (motopick)


Lesenswert?

Mit einem passenden (LTO/DLT/...-)Streamer, kann man die sechsfache
Geschwindigkeit des Stripesets fuer sehr schnelle Backups nutzen.

Bei sechs Platten kommt da schon was zusammen...

von Dieter D. (dieter_dosenkohl)


Lesenswert?

Sicher dass du überhaupt ein RAID brauchst? Manche verwechseln RAIDs mit 
Backups. Ein RAID dient der Ausfallsicherheit und ersetzt kein Backup.

von Ich A. (alopecosa)


Lesenswert?

Gustl B. schrieb:
> Dann kommt eine neue Platte rein und es wird wieder die
> Redundanz hergestellt. Und nur während dieser relativ kurzen Phase darf
> keine andere Platte sterben.

Ein Raid5 Rebuild ist selten "relativ kurz" und Erfahrungsgemäß stirbt 
im privat betriebenen Umfeld genau während des Rebuild durch die erhöhte 
Last auf den Platten, die zweite Platte.
Denn meistens ist es nämlich genau so:

Thomas W. schrieb:
> Ja, und haeufig kauft man die sechs Platten in einem Auftrag (wg. Rabatt
> und Gewaehrleistung). Und dann sind sie alle gleich alt, mit gleicher
> Ausfallwahrscheinlichkeit (alt-werden ist Mist).

Unabhängig davon sind aber für eine sinnvolle Beantwortung der 
Ursprungsfrage zu wenig Informationen da.

Ich hab in meinem Server 4 Platten als RAID10 und als "Backup" das 
gleiche nochmal. Aufgebaut auf 2 mittlerweile betagten HP Gen8 
Microservern mit ULP Xeons drin.

Jetzt kann ich natürlich noch anfangen ein Backup vom Backup zu machen 
und mindestens ein Backup dieses Backup in einem komplett anderen 
Gebäude zu lagern usw. Ist eben die Frage wie "wichtig" die Daten sind 
und wieviel Aufwand man betreiben möchte, bzw. wieviel Schaden entsteht 
wenn sie weg sind.

von Rene K. (xdraconix)


Lesenswert?

Gustl B. schrieb:
> Welche Nachteile? Ich bin gespannt.

Die Nicht-Wiederherstellbarkeit bei Verlust auch nur einer Platte aus 
einem LVM Verbund. Das schlimme an diesem Fall ist: Es wurde von jeder 
Platte ein DD Backup gemacht - eine Wiederherstellung, auch nach 
Rückspielung, ging nicht. Ja ich weiß, man hätte statt DD auch Snapshots 
machen können / müssen, aber wenn solch ein System bereits auf 
Hardwareebene versagt, dann ist dies für mich ein no-go.



Es geht nicht um Backup oder Datensicherheit. Es geht mir eher um die 
Verfügbarkeit. Backup und Nutzdaten liegen, wie erwähnt auf einem 
externen Fault.

Bei einem RAID1 war dies bis dato eben völlig simpel und der Ausfall bei 
einem Plattendefekt hat sich gen 0 genähert. Bei RAID5 ist die Belastung 
halt extrem hoch auf die verfügbaren Platten bei der Wiederherstellung 
und bei Platten mit 4TB dauert dies bei dem relativ Leistungsschwachen 
Controller schon einige Zeit. Da wäre der Vorschlag von px mit dem RAID6 
schon besser. Oder eben ein RAID1+0 - bei einem RAID0+1 wäre ja dann 
auch die Belastung wieder hoch, weil ja dann die ganzen Platten aus dem 
0 wieder gespiegelt werden müssten.

Die Platten hängen an einem P420 - ja das ist ein 8-Port Controller.

von Jens M. (schuchkleisser)


Lesenswert?

Rene K. schrieb:
> Bei RAID10 würde sich ja ein Setup aus 2x2 + 2 HotSpare anbieten. Aber
> machen zwei HotSpare Platten wirklich Sinn?

Hotspare macht keinen Sinn, außer die Arbeit des Admins das LW zu 
tauschen dauert zu lange.
Die sind genau so lange am Strom wie die anderen, nur weniger 
Motorstunden. Man tauscht also das Risiko das sie einfach mal an 
Elektronikstunden sterben gegen Verstaubung (Cold Reserve gegen 
Hotspare) oder das Risiko das sie bei einem Rebuild eingesetzt werden 
und eins der anderen Drives stirbt gegen die Alterung im Betrieb 
(Hotspare gegen zus. Paritydrive)

Für 3-5 Drives sollte man R5 nehmen, ab 5-6 kann bzw. sollte es R6 sein.
Dann hat man alle Drives im Einsatz und muss nicht laufen.

Rene K. schrieb:
> Bei RAID5 würde ich dann eher nur auf eine HotSpare setzen und hätte
> dann ja 4D+1P+1HS was ja an Geschwindigkeit und Datenvolumen schon super
> wäre.

R6 erlaubt zwei beliebige Tode im RAID und hat o.G. Vorteile ggü. 
Hotspare.
R5 mit 6 Drives ist höheres Risiko als 5+Coldspare, plus "wo ist das 
Scheißding" im Krisenfall und Rebuildbombe.

Und: soweit mir mal beigebogen wurde ist ein non-Stripe-RAID nicht 
schneller als ein einzelnes Drive, weil ja alle Drives gelesen werden 
müssen um die Sets zu vergleichen, bzw. alle Daten sicher auf die Drives 
geschrieben werden müssen.

von Thomas W. (Gast)


Lesenswert?

Rene K. schrieb:
> Gustl B. schrieb:
>> Welche Nachteile? Ich bin gespannt.
>
> Die Nicht-Wiederherstellbarkeit bei Verlust auch nur einer Platte aus
> einem LVM Verbund. Das schlimme an diesem Fall ist: Es wurde von jeder
> Platte ein DD Backup gemacht - eine Wiederherstellung, auch nach
> Rückspielung, ging nicht. Ja ich weiß, man hätte statt DD auch Snapshots
> machen können / müssen, aber wenn solch ein System bereits auf
> Hardwareebene versagt, dann ist dies für mich ein no-go.

Das ist aber Dein Unvermoegen: Du hast im laufenden System eine 
unkonsistente Kopie gezogen, und das kann klappen oder auch nicht. 
Meistens nicht.

Du brauchst Verstaendnis der eingesetzten Werkzeuge. Gerade ZFS ist 
eigentlich sehr stabil, man muss es nur bedienen koennen (und nicht 
herumbasteln). Es wuerde auch helfen, die Dokumentation zu lesen und 
verstehen.

Gruesse

Th.

von Rene K. (xdraconix)


Lesenswert?

Thomas W. schrieb:
> man muss es nur bedienen koennen

Richtig, und bei einem RAID1 ziehe ich die Defekte Platte und stecke die 
neue ein - Das war's. Da brauche ich weder mit Snapshots arbeiten noch 
sonst etwas.

Aber sei es drum. Ich weiß das es damals mein Fehler / Unverständnis 
über ZFS war.

von Gustl B. (-gb-)


Lesenswert?

Ich A. schrieb:
> Ein Raid5 Rebuild ist selten "relativ kurz" und Erfahrungsgemäß stirbt
> im privat betriebenen Umfeld genau während des Rebuild durch die erhöhte
> Last auf den Platten, die zweite Platte.
> Denn meistens ist es nämlich genau so:
>
> Thomas W. schrieb:
>> Ja, und haeufig kauft man die sechs Platten in einem Auftrag (wg. Rabatt
>> und Gewaehrleistung). Und dann sind sie alle gleich alt, mit gleicher
>> Ausfallwahrscheinlichkeit (alt-werden ist Mist).

Dir ist klar was Ausfallwahrscheinlichkeit bedeutet? Das heißt nicht, 
dass die Platten am gleichen Tag ausfallen.

Ja, beim Rebuild hat man höhere Last, aber man sollta ja sowieso 
regelmäßig Backup machen und gegen Bitrot auch mal einen Scrub (ZFS).

Die paar Stunden müssen die Platten das eben aushalten und das RAID ist 
ja gleichzeitig auch verfügbar. Wenn noch eine Platte stirbt spielt man 
das Backup ein, dafür hat man das, sollte aber nur extrem selten 
benötigt werden.

Ich A. schrieb:
> Aufgebaut auf 2 mittlerweile betagten HP Gen8
> Microservern mit ULP Xeons drin.

Das hab ich auch, funktioniert wunderprächtig.

Rene K. schrieb:
> Die Nicht-Wiederherstellbarkeit bei Verlust auch nur einer Platte aus
> einem LVM Verbund. Das schlimme an diesem Fall ist: Es wurde von jeder
> Platte ein DD Backup gemacht - eine Wiederherstellung, auch nach
> Rückspielung, ging nicht. Ja ich weiß, man hätte statt DD auch Snapshots
> machen können / müssen, aber wenn solch ein System bereits auf
> Hardwareebene versagt, dann ist dies für mich ein no-go.

Ja was ist denn nun kaputtgegangen, der LVM Verbund oder das ZFS RAID?
Backup macht natürlich nur vom ganzen Volume Sinn, du willst ja, dass 
das Backup auch konsistent ist.
Darüber hinaus ist ein Backup nur ein Backup wenn man das auch wieder 
herstellen kann. Das sollte man also ganz dringend testen. Zumindest 
einmalig und immer wenn man was an der Backupmethode geändert hat.

Rene K. schrieb:
> Es geht nicht um Backup oder Datensicherheit. Es geht mir eher um die
> Verfügbarkeit. Backup und Nutzdaten liegen, wie erwähnt auf einem
> externen Fault.

Na dann einfach Backup einspielen fertig.

Bei ZFS gibt es send/receive um das über Netzwerk/SSH zu übertragen, man 
kann aber auch auf der Backupplatte einen zpool anlegen. Dann steckt man 
die Backupplatte an und kann lokal mit z. B. rsync das Backup machen.

von (prx) A. K. (prx)


Lesenswert?

Jens M. schrieb:
> Und: soweit mir mal beigebogen wurde ist ein non-Stripe-RAID nicht
> schneller als ein einzelnes Drive, weil ja alle Drives gelesen werden
> müssen um die Sets zu vergleichen, bzw. alle Daten sicher auf die Drives
> geschrieben werden müssen.

Lesend wird im RAID Layer nichts verglichen. Da liest man von nur einem 
Drive des Mirrors und verlässt sich auf den Check des Drives, oder bei 
manchen modernen Filesystemen auf eine Checksum im FS.

Ab und zu macht man bei RAID allerdings eine Komplettkontrolle im 
Hintergrund.

: Bearbeitet durch User
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Das kommt stark auf den Raid-Controller an. Die professionellen prüfen 
die komplette Integrität der Daten, sprich die Spiegelungen werden 
komplett mitgelesen und alles verglichen. Patrol-Read (in 
Leerlauf-Zeiten wird regelmäßig der komplette Inhalt der Festplatten 
gelesen und getestet, ob dabei Fehler auftreten) machen eigentlich auch 
nur professionelle Controller.

von (prx) A. K. (prx)


Lesenswert?

Ben B. schrieb:
> Patrol-Read (in Leerlauf-Zeiten wird regelmäßig der komplette Inhalt der
> Festplatten gelesen und getestet, ob dabei Fehler auftreten) machen
> eigentlich auch nur professionelle Controller.

Ist ebenso in mdraid, btrfs und ZFS vorgesehen.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Ben B. schrieb:
> Die professionellen prüfen die komplette Integrität der Daten, sprich
> die Spiegelungen werden komplett mitgelesen und alles verglichen.

Welche? Bei RAID 1 wär's ja noch machbar, wenngleich ich das als 
Standardbetrieb bei jedem Lesezugriff  für wenig sinnvoll halte. Machen 
die das dann auch bei einer RAID 6 Gruppe aus 12 Disks bei jedem 
Lesezugriff?

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Frag mich nicht mehr nach genauen Typen, die in den Racks verbaut waren. 
Das ist zu lange her und waren alles SAS Enterprise-Lösungen, mit denen 
man im privaten Bereich nichts zu tun hat, das war alles viel zu teuer.

Soweit ich mich erinnere verteilt Raid 6 die Daten und (doppelte) 
Paritäts-Informationen über alle Platten in einem Array, also müssen 
auch alle Platten gelesen werden wenn man einen Datenblock lesen oder 
testen möchte.

Der Trend geht heute wohl in den meisten Fällen zu Raid 0,1 und 5 oder 
zu Kombinationen aus diesen (Raid 10 und 15), Raid 6 dürfte eine Nische 
sein.

Nachtrag: Aus seinen 6 Platten könnte man z.B. ein sehr schönes Raid 15 
bauen, was den gleichzeitigen Ausfall von drei Platten verkraften würde. 
Bei einer toten Platte pro Raid 5 passiert gar nichts, bei drei Platten 
(oder zwei Platten im gleichen Raid 5) ist eines der Raid 5 tot und das 
Raid 1 rettet, bei vier defekten Platten braucht man Glück, daß es die 
letzte Platte des bereits toten Raid 5 trifft. Bei zwei defekten Platten 
pro Raid 5 war's das.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Ben B. schrieb:
> also müssen
> auch alle Platten gelesen werden wenn man einen Datenblock lesen oder
> testen möchte.

Nein, das läuft bei normalen Lesevorgängen anders. Man verlässt sich 
darauf, dass eine Disk ja nicht einfach jeden Mist durchreicht, sondern 
darauf überprüft, ob der Lesevorgang erfolgreich war. Ein Lesezugriff 
von z.B. 4 KB wird folglich an die eine Disk weitergeleitet, auf der 
diese Daten direkt stehen. Ist dieser Zugriff erfolgreich, ist die Sache 
damit beendet. Es werden keine Daten von anderen Disks gelesen (oder 
allenfalls zwecks Caching möglicherweise folgender Zugriffe).

Erst wenn dieser Disk-Zugriff seitens der Disk mit Fehler quittiert 
wird, wird es erforderlich, die Daten anhand der übrigen Sektoren sowie 
der Parity-Information zu rekonstruieren. Dann, und nur dann, werden 
alle zu dieser Parity gehörenden Daten mitsamt der Parity gelesen, und 
die verlorenen Daten zurückgewonnen. Entsprechend langsamer arbeitet das 
System dann.

Manche Filesysteme wie etwa ZFS und btrfs enthalten unabhängig davon 
Vorkehrungen gegen Fehler, die nicht von der Disk selbst erkannt werden. 
Auch das ist aber kein Datenvergleich, sondern eine separate 
blockbezogene Checksum über die wie beschrieben gewonnenen Daten.

Erst Scrubbing, Patrol Read und wie solche regelmässigen bei schwacher 
Last im Hintergrund laufenden Routinekontrollen jeweils genannt werden, 
lesen alle Inhalte mitsamt Parity und kontrollieren die Konsistenz.

NB: Auch beim Schreiben werden nicht notwendigerweise alle Sektoren 
betrachtet, aus denen sich eine RAID 5 Parity ableitet. Es kann nämlich 
je nach konkret anstehender Transfergrösse ökonomischer sein, den alten 
Sektorinhalt aus der Parity raus- und den neuen reinzurechnen, weil das 
gerade bei kleinen Requests auf grossen RAID Gruppen weit weniger 
Zugriffe beinhaltet.

: Bearbeitet durch User
Beitrag #7427007 wurde vom Autor gelöscht.
von (prx) A. K. (prx)


Lesenswert?

Ben B. schrieb:
> Der Trend geht heute wohl in den meisten Fällen zu Raid 0,1 und 5 oder
> zu Kombinationen aus diesen (Raid 10 und 15), Raid 6 dürfte eine Nische
> sein.

Bei den hier betrachteten 6 Disks passt das, auch wenn manche aus Angst 
vor dem oft in den Medien berichteten (aber vmtl nicht ganz so oft 
selbst erlebten) Fehler bei Wiederherstellung auch dann schon RAID 6 in 
Betracht ziehen könnten. Grössere Gruppen fahre ich mindestens mit RAID 
6, z.B. günstige Storage-Systeme mit 12 HDDs.

Aber da du es warst, der professionelle System anführte: NetApp 
verwendete früher vorzugsweise RAID DP (deren Pendant zu RAID 6) in 
Gruppen von bis zu 28 Disks. Für noch grössere Gruppen wird mittlerweile 
RAID TEC (triple error correction) eingesetzt. Andere RAID Techniken 
findet man dort allenfalls bei den Systemdisks, denn bei nur wenigen 
Disks verwendet man deren Systeme üblicherweise nicht.

: Bearbeitet durch User
von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Lesenswert?

Die professionellen Systeme entwickeln sich natürlich weiter und ich 
habe auch keinen Überblick darüber, was 2023 aktuell überall in 
Verwendung ist. Da gibt's inzwischen so viel verschiedenes und die 
"alten" Lösungen sind ja auch nicht wirklich schlecht, Geschwindigkeit 
wird immer wichtiger...

"Früher Raid 6" - ja das glaube ich. Raid 5 erfordert einen enormen 
Rechenaufwand (XOR-Operationen), die Controller besaßen damals schon 
spezielle ASICs dafür oder wenn es "nicht ganz so Enterprise-Level" war, 
dann z.B. den i960 (32 Bit RISC Prozessor). Da kann es durchaus sein, 
daß man zur Vermeidung dieser hohen Rechenlast eher Raid 6 verwendet 
hat.

Mit Deinem "nicht alle Platten lesen" gehe ich nicht mit, denn wenn ich 
beim Lesen einen Fehler feststelle und mir dann erst bei einer noch 
nicht gelesenen Platte Ersatz-Daten bestellen muss, dann fange ich mir 
eine ziemliche Delle in der Zugriffszeit ein und das will ich definitiv 
nicht. Beim Raid 5 z.B. geht's auch gar nicht anders, da die Daten über 
alle Platten verteilt liegen. Heißt ich muss alle Platten lesen (schon 
alleine um Fehler feststellen zu können, in Daten, die ich nicht lese, 
kann ich auch keinen Fehler feststellen), beim Raid 0 müssen ebenfalls 
alle Platten gelesen werden, weil die Daten nirgendwo anders verfügbar 
sind. Raid 0 ist nur was für Geschwindigkeit und absolut nichts für 
Datensicherheit. Bei 4 Platten Raid 0 hätte ich zwar die vierfache 
Geschwindigkeit einer einzelnen Platte, aber auch eine viermal so hohe 
Ausfallwahrscheinlichkeit.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Ben B. schrieb:
> "Früher Raid 6" - ja das glaube ich. Raid 5 erfordert einen enormen
> Rechenaufwand (XOR-Operationen), die Controller besaßen damals schon
> spezielle ASICs dafür oder wenn es "nicht ganz so Enterprise-Level" war,
> dann z.B. den i960 (32 Bit RISC Prozessor). Da kann es durchaus sein,
> daß man zur Vermeidung dieser hohen Rechenlast eher Raid 6 verwendet
> hat.

Das "früher RAID 6" leitest du vmtl von meiner Aussage "früher RAID DP" 
bei NetApp ab. Allerdings hast du das missverstanden, denn das läuft so:
1
 kleine RAID-Gruppe:   RAID 4   = 1 dedizierte Parity Disk
2
 mittlere RAID-Gruppe: RAID DP  = 2 Parity Disk, linear+diagonal
3
 grosse RAID-Gruppe:   RAID TEC = 3 Parity Disks, linear+diagonal+antidiagonal
Der rechnerische Aufwand steigt mit der Anzahl Parity Disks. RAID TEC 
ist vergleichsweise neu, daher mein "früher".

> Mit Deinem "nicht alle Platten lesen" gehe ich nicht mit, denn wenn ich
> beim Lesen einen Fehler feststelle und mir dann erst bei einer noch
> nicht gelesenen Platte Ersatz-Daten bestellen muss, dann fange ich mir
> eine ziemliche Delle in der Zugriffszeit ein und das will ich definitiv
> nicht.

Ein RAID System hat dabei mehrere Möglichkeiten. Es läuft letztlich auf 
die Frage hinaus, ob die Disk als ausgebucht eingestuft wird, oder als 
teilweise lesbar. Das ist eine Entscheidung der Implementierung.

> Beim Raid 5 z.B. geht's auch gar nicht anders, da die Daten über
> alle Platten verteilt liegen.

Insgesamt betrachtet liegen sie verteilt, im Detail betrachtet hingegen 
nicht unbedingt. Das hängt von der Grösse des Transfers ab. Die Daten 
von Transfers innerhalb eines Stripes von z.B. 256 KB befinden sich auf 
nur einer Disk, werden also nur von dieser Disk gelesen.

Diese Eigenschaft führt dazu, dass die Grösse des Stripes ein 
Optimierungsparameter abhängig von der typischen Nutzung ist. Kleine 
Stripes verteilen die Requests mit zunehmender Grösse auf mehrere Disks, 
zugunsten der Transferrate - aber eben deshalb auch zulasten der 
Zugriffszeit bei vielen parallelen Operationen, weil mehr Disks busy 
sind.

> Heißt ich muss alle Platten lesen (schon
> alleine um Fehler feststellen zu können, in Daten, die ich nicht lese,
> kann ich auch keinen Fehler feststellen),

Es ist nicht der RAID Layer, der Lesefehler erkennt. Das macht die Disk 
selbst. Der RAID Layer reagiert jedoch auf solche Lesefehler. Weiss 
dieser Layer aus voriger leidvoller Erfahrung, dass ein Zugriff auf 
Block 1 Disk 2 nicht funktionieren wird, wird er darauf auch keinen 
Zugriff mehr versuchen. Das kann aber unterschiedlich implementiert 
sein.

Typisches Verhalten bei NetApp: Eine Disk, auf der ein ernster Fehler 
auftrat ohne dabei komplett auszufallen, wird ausgebucht und durch eine 
Spare ersetzt. Anschliessend wird die Disk im Hintergrund auf Herz und 
Nieren geprüft. Übersteht sie das, wird sie wieder als Spare 
freigegeben, ansonsten muss sie ersetzt werden.

HDD-Systeme, die sich dem hinteren Ende der Badewannenkurve nähern, weil 
Richtung 10 Jahre, zeigen deshalb einen gewissen Ping-Pong Effekt. Es 
kann dann einige solche Zyklen dauern, bis eine Disk endgültig als 
failed klassifiziert wird.

> beim Raid 0 müssen ebenfalls
> alle Platten gelesen werden, weil die Daten nirgendwo anders verfügbar
> sind.

Auch für RAID 0 aka Striping gilt das, was ich oben schrieb. Transfers 
innerhalb eines Stripes bleiben auf nur einer Disk.

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.