Große Arrays als Raid5 laufen lassen?

[popel1988]

Also habe mir auch mal ein paar gedanken dazu gemacht! (vorrausgesetzt ich habe es richtig verstanden) Und von daher finde ich diese 100% verlust beim rebuild einfach schlecht gerechnet!
Wenn ich nun beispielsweise so einen 2TB Festplatte habe die nun alle 12TB einen unkorrigierbaren Fehler ausgibt, würde ich folgende Rechnung machen: (Ich gehe jetzt davon aus das alle 12TB ein fehler kommt: also 100%)
Ich habe ein Raid 5 aus 8*2TB. Nun geht eine Festplatte kaputt und ich baue eine neue ein, starte Rebuild.
Während des Rebuilds werden von jeder Festplatte 2TB gelesen (richtig?) also ist die chance das ein fehler auftritt 2/12 = 16,7%

Nun wird ja von jeder der 7 Festplatten 2TB gelesen also trifft diese Wahrscheinlichkeit auf jede zu. Berechnen wir also die chance dafür das nix passiert

für eine Festplatte 1- 0,167 = 0,833

für alle sieben fesplatten 0,833^7 = 0,28 = 28%
die wahrscheinlichkeit das nun also so ein Fehler während des Rebuilds auftritt ist nun 72%

Was nun der Controller damit macht, also ob das Raid komplett im A**** ist oder nicht, weiß ich nun nicht nur wäre ein Raid 6 mit gleichem verfügbarem Speicher (1Festplatte mehr) nun auch nicht das gelbe vom EI.

denn beim ersten Rebuild etwas schiefgeht bei 77% (bricht er dann das rebuilden ab?) und dann beim zweiten versuch, ohne parität, nochmal 72%. Also würde da etwa zu 56% das Raid kaputt gehen!

Wie gesagt die Rechnung lässt andere Faktoren, die ich nicht kenne, außer Acht. Dennoch halte ich die Aussage das Wenn eine Fesplatte raus ist, das Raid verloren ist für unsinnig denn dann würde wirklich nirgends noch jemand auf Raid5 setzen.

 

[bogomil22]

...Sollte ein Sektor nicht wiederhergestellt werden können nach der max. erlaubten Zeit (1,x Sekunden - näheres steht im richtigen Datenblatt mit Angabe in ms) wird dieser als fehlerhaft gemeldet. Einige Raidcontroller haben darauf hin die ganze HDD als defekt markiert und ein Raid deswegen oft degraded.

Gerade bin ich verwirrt. Also dieser Fehler beim Rebuilt (im Raid5) ist ja ein Lese-Fehler der Festplatte, sodass kurzfristig keine Daten/Datei gelesen werden kann.
Das was du jetzt anspricht --> dass ein Sektor nicht wiederhergestellt werden kann und die Platte länger als 1,x Sek. braucht um diesen Fehler an den Kontroller weitergeben zukönnen, sodass die Raid-Controller (evtl.) die platte als Defekt markiert und degraded , ist doch nun zusätzlich noch ein andere Fehler, der bei Desktop-Platten auftreten kann, oder sind diese beiden Fehler ein und das selbe?

Weil ich dachte, dass das Problem mit dem Rebuilt im Raid 5 (URE-Fehlern), die bei Desktop-platten bei 10^14 liegen und bei Enterprise platten bei 10^15. --> Würde bedeuten, dass dieser Fehler theoretisch im RAID5 irgendwann, egal ob Desktop oder Enterprise-Platten, auftreten wird.
Und der Fehler mit dem Wiederhergestellten Sektor (egal welches Raid-Array), wo die Enterprise-Platten das sofort an den Kontroller weitergeben und die Desktop-Platten evtl. nicht, ist doch vermeidbar indem man halt Enterprise-Platten kauft, oder?
--> Sprich, das sind doch 2 verschiedene Fehler die auftreten können oder?

 

[andichen]

naja, was willst du denn genau? dass die Hersteller bei Desktop-Festplatten einfach mal alles auf 1 in 10[SUP]15[/SUP] Bit ändern/umstellen?

Das wäre eine Möglichkeit. Die Schere zwischen Festplattengröße und Fehleranfälligkeit hat sich immer weiter geöffnet. Es ist vergleichbar mit einem Porsche auf Smart-Reifen, die (Antriebs-)Leistung ist da, sie kann nur nur schlecht auf die Straße gebracht werden. Die Fehleranfälligkeit sollte sich meiner Meinung nach der Festplattengröße mindestens anpassen. Natürlich ist Raid6 eine mögliche Lösung, nur leider auch nicht zum Nulltarif zu bekommen. Es geht ja auch nicht um "Qualitätsware" oder nicht, ich finde nur, dass der Aufpreis zur "Mehrleistung" unverhältnismäßig ist.

popel88: Diese ganze Rechnerei basiert sowieso nur auf Annahmen, da kann man sich viel besonders schön rechnen... BWLer tun das sogar beruflich. *duck* Daher hatte ich ja auch gefragt, woher dv2130n die ganzen Formeln hat. Glaube auch kaum, dass man das irgendwie nachweisen kann, ob das Fehlerbit wirklich im Toleranzbereich aufgetreten ist, wenn es denn aufgetreten sein sollte. Du hast insofern Recht, dass pro Platte natürlich nicht mehr als deren Gesamtkapazität ausgelesen wird. Das Problem ist aber, dass du nicht weißt, wann genau dieser Lesefehler auftritt, du weißt nur, dass er irgendwann zwischen dem 1. und 10[SUP]14[/SUP]. gelesenen Bit einmalig auftritt, sofern die Angabe stimmt und es auch so eintritt. Leider ist es aber so, dass die Wahrscheinlichkeit, dass dieser Lesefehler auftritt, bei gleicher Fehleranfälligkeit mit der Plattengröße und Anzahl auszulesener Platten steigt, wobei die Anzahl noch der "gefährlichere Faktor" ist. Es reicht aus, wenn eine Platte der Gesamtheit der auszulesenen Platten einen solchen Fehler meldet, wenn bei einem Raid5 eine Platte ausgefallen ist, damit das Raid den Bach runter geht. Wie der Raidcontroller eine solche Situation handhabt bzw. ob man mit ggf. einer beschädigten Datei den Wiederherstellungsprozess weiterlaufen lassen kann, steht leider in den Sternen bzw. müsste mal angefragt werden...

bogomil22: Es ist alles nicht ganz so einfach zu verstehen, stimmt schon. Musste das auch einige Male im Kopf bewegen... Es geht die ganze Zeit um die Problematik, dass bei der Wiederherstellung eines Raid5 ein solcher "URE" auftreten kann. Ein Raid5 muss ja nur dann wiederhergestellt werden, wenn eine Festplatte ausgefallen ist. Wenn das Raid5 aber intakt ist, kann es problemlos die auftretenden "UREs" durch die Parität ausgleichen. Es nur um den Ernstfall, also wenn eine Festplatte ausgefallen ist und zum Wiederherstellen der Parität alle Daten von den übrigen Festplatten des Raidverbunds gelesen werden müssen. Bei einem Raid6 kann das eben nicht so leicht passieren, weil bei einer ausgefallenen Platte immernoch ein aufgetretener "URE" durch die bestehende Parität ausgeglichen werden kann. Damit ein Raid6 in die Binsen geht, müssen entweder zwei Festplatten ausfallen und bei der Wiederherstellung ein "URE" auftreten oder bei einer ausgefallenen Festplatte im Raidverbund mind. zwei "UREs" an derselben Stelle auftreten, was aber höchst unwahrscheinlich ist.

 

[iamunknown]

Das wäre eine Möglichkeit. Die Schere zwischen Festplattengröße und Fehleranfälligkeit hat sich immer weiter geöffnet. Es ist vergleichbar mit einem Porsche auf Smart-Reifen, die (Antriebs-)Leistung ist da, sie kann nur nur schlecht auf die Straße gebracht werden. Die Fehleranfälligkeit sollte sich meiner Meinung nach der Festplattengröße mindestens anpassen. Natürlich ist Raid6 eine mögliche Lösung, nur leider auch nicht zum Nulltarif zu bekommen. Es geht ja auch nicht um "Qualitätsware" oder nicht, ich finde nur, dass der Aufpreis zur "Mehrleistung" unverhältnismäßig ist.

Schlechter Vergleich. Die Leistung bringt die Platte ja. Du benötigst kein RAID6, sondern eine Platte mit im Schnitt einem URE bei 10^15 gelesenen Bits. Welcher Mehraufwand hier dahinter steckt kann von uns wohl keiner Beantworten, dass es ab einem Bestimmten Punkt teuer werden kann ist allerdings bei vielen Dingen so sollte der Aufwand enorm ansteigen.

Die Definition von "Anpassen" finde ich hier schwierig, immerhin tritt der Fehler im Durchschnitt bei 100 Billionen durchgeführten Messungen (etwas anderes ist die Verwendete Technik - GMR - nicht) nur ein einziges mal auf. Eine 2TB-Platte selbst hat aber "nur" rund 10 Billionen Bits. Bei den 10^15-Bit zertifizierten Platten tritt der Fehler dann sogar nur alle 1 Billiarde(!) Messungen auf...

popel88: Diese ganze Rechnerei basiert sowieso nur auf Annahmen, da kann man sich viel besonders schön rechnen... BWLer tun das sogar beruflich. *duck* Daher hatte ich ja auch gefragt, woher dv2130n die ganzen Formeln hat. Glaube auch kaum, dass man das irgendwie nachweisen kann, ob das Fehlerbit wirklich im Toleranzbereich aufgetreten ist, wenn es denn aufgetreten sein sollte. Du hast insofern Recht, dass pro Platte natürlich nicht mehr als deren Gesamtkapazität ausgelesen wird. Das Problem ist aber, dass du nicht weißt, wann genau dieser Lesefehler auftritt, du weißt nur, dass er irgendwann zwischen dem 1. und 10[SUP]14[/SUP]. gelesenen Bit einmalig auftritt, sofern die Angabe stimmt und es auch so eintritt. Leider ist es aber so, dass die Wahrscheinlichkeit, dass dieser Lesefehler auftritt, bei gleicher Fehleranfälligkeit mit der Plattengröße und Anzahl auszulesener Platten steigt, wobei die Anzahl noch der "gefährlichere Faktor" ist. Es reicht aus, wenn eine Platte der Gesamtheit der auszulesenen Platten einen solchen Fehler meldet, wenn bei einem Raid5 eine Platte ausgefallen ist, damit das Raid den Bach runter geht. Wie der Raidcontroller eine solche Situation handhabt bzw. ob man mit ggf. einer beschädigten Datei den Wiederherstellungsprozess weiterlaufen lassen kann, steht leider in den Sternen bzw. müsste mal angefragt werden...

Der Fall tritt im Schnitt einmal bei 10^14 gelesenen Bits auf. Eine Vorhersage ist hier immer eine Schätzung. Eine Datei wird durch den RAID-Controller auch nicht beschädigt, da er nur Bits kennt. Ihm ist auch das verwendete Dateisystem im RAID egal.

RAID ist kein Backup. Von daher empfinde ich die Problematik ehrlich gesagt nicht als so schlimm...

 

[andichen]

Schlechter Vergleich. Die Leistung bringt die Platte ja. Du benötigst kein RAID6, sondern eine Platte mit im Schnitt einem URE bei 10^15 gelesenen Bits. Welcher Mehraufwand hier dahinter steckt kann von uns wohl keiner Beantworten, dass es ab einem Bestimmten Punkt teuer werden kann ist allerdings bei vielen Dingen so sollte der Aufwand enorm ansteigen. Die Definition von "Anpassen" finde ich hier schwierig, immerhin tritt der Fehler im Durchschnitt bei 100 Billionen durchgeführten Messungen (etwas anderes ist die Verwendete Technik - GMR - nicht) nur ein einziges mal auf. Eine 2TB-Platte selbst hat aber "nur" rund 10 Billionen Bits. Bei den 10^15-Bit zertifizierten Platten tritt der Fehler dann sogar nur alle 1 Billiarde(!) Messungen auf...

Also ich find schon, dass der Vergleich zutrifft. Hätte vielleicht statt des Smart- einen Trabi-Reifen nennen sollen, aber das wäre zu "weit weg". Die Entwicklung bzw. Wachstum der Eigenschaften ist eben sehr einseitig bzw. als Gesamtpaket nicht mehr stimmig und wenn Seagate das schon vor mehreren Jahren aufgefallen ist, frage ich mich, warum nicht gegengelenkt worden ist. Es kann auch nur deshalb der eventuelle Mehraufwand nicht abgeschätzt werden, weil mMn keine bzw. zu wenig Aufklärung betrieben wird, weshalb eine RE-Platte das ~3-fache einer Nicht-RE-Platte kosten soll. Auch gibt es kaum Abstufungen. Es gibt nur das Eine oder das Andere, wo ist die Produktvielfalt? Einzig Hitachi hat die 24x7-Freigabe bei geringer Last, allerdings hat sich auch dort nichts bei der Fehleranfälligkeit getan. Das hat ja auch der Autor des ersten Artikels bemängelt, dass, sollte es so weitergehen, nicht mal Raid6 eine Alternative ist... An der Herstellergarantiezeit kann man den Unterschied auch kaum festmachen.
Es ist wirklich die Frage, womit diese Fehleranfälligkeit zusammenhängt. Wenn es u.a. mit den Fertigungstoleranzen zusammenhängen sollte, so kann es schon sein, dass daher dieser Preisunterschied entsteht. Wenn es aber rein elektronisch sein sollte, so kann ich das nicht nachvollziehen...

Der Fall tritt im Schnitt einmal bei 10^14 gelesenen Bits auf. Eine Vorhersage ist hier immer eine Schätzung. Eine Datei wird durch den RAID-Controller auch nicht beschädigt, da er nur Bits kennt. Ihm ist auch das verwendete Dateisystem im RAID egal.

Schon klar, aber mich/uns interessieren ja die Dateien und nicht die Bits...

RAID ist kein Backup. Von daher empfinde ich die Problematik ehrlich gesagt nicht als so schlimm...

Das klingt ja schon fast so: "Wozu braucht man ein Raid, wenn man ein Backup hat?" Sicherlich ist es kein Backup in dem Sinne, aber bei den Kosten der Controller kann man schon etwas erwarten... Für das Geld, das auf den Controller entfällt, kann man sich nämlich ungefähr noch mal so viele Festplatten kaufen, wie man dort insgesamt anschließen kann. Natürlich gilt das für Nicht-RE-Platten und die Zeit vor dem Hochwasser...

 

[nobody27182]

Ein paar Überlegungen

1. Bei angenommener Bitfehlerwsk. von 10[SUP]-14[/SUP] ist die ZV X "Ein Fehler tritt während des Lesens von x TB auf" exponentialverteilt mit µ=[SUP]1[/SUP]/[SUB]12,5[/SUB]=0,08. Es gilt also z.B.:
   • F[SUB]X[/SUB](12,5) ≈ 0,63. Das unterscheidet sich um einiges von der im oben verlinkten Artikel behaupteten Wsk. von ≈1,0.
   • F[SUB]X[/SUB](2) ≈ 0,15
   • F[SUB]X[/SUB](8,6) = 0,5 (Beim Lesen von 8,6 TB steht es "fifty-fifty", ob ein Fehler auftritt oder nicht)
2. Die ZV Y "Anzahl der Fehler beim Lesen von z TB" ist dann poissonverteilt mit λ=[SUP]z[/SUP]/[SUB]12,5[/SUB]. Z.B. mit z = 12,5:
   • P(Y≥2) = 1-F[SUB]Y[/SUB](1) ≈ 0,26 (Wsk. für mehr als einen Fehler beim Lesen von 12,5TB)
   Aber das dürfte von geringerem praktischen Interesse sein.

 

[soulreaver]

Theorie schön und gut, aber es kann auch passieren, dass die Platte nach dem Initialisieren und 100MB schreiben schon den Geist aufgibt, davor ist keiner sicher, sowas kann auch mit Enterprise-Platten passieren.

RAID6 zum einen, zusätzliches Backup zum zweiten und man kann relativ sorglos durchs leben gehen.

 

[bluesunset]

Die Entwicklung bzw. Wachstum der Eigenschaften ist eben sehr einseitig bzw. als Gesamtpaket nicht mehr stimmig und wenn Seagate das schon vor mehreren Jahren aufgefallen ist, frage ich mich, warum nicht gegengelenkt worden ist. Es kann auch nur deshalb der eventuelle Mehraufwand nicht abgeschätzt werden, weil mMn keine bzw. zu wenig Aufklärung betrieben wird, weshalb eine RE-Platte das ~3-fache einer Nicht-RE-Platte kosten soll. Auch gibt es kaum Abstufungen. Es gibt nur das Eine oder das Andere, wo ist die Produktvielfalt? Einzig Hitachi hat die 24x7-Freigabe bei geringer Last, allerdings hat sich auch dort nichts bei der Fehleranfälligkeit getan. Das hat ja auch der Autor des ersten Artikels bemängelt, dass, sollte es so weitergehen, nicht mal Raid6 eine Alternative ist... An der Herstellergarantiezeit kann man den Unterschied auch kaum festmachen.
Es ist wirklich die Frage, womit diese Fehleranfälligkeit zusammenhängt. Wenn es u.a. mit den Fertigungstoleranzen zusammenhängen sollte, so kann es schon sein, dass daher dieser Preisunterschied entsteht. Wenn es aber rein elektronisch sein sollte, so kann ich das nicht nachvollziehen...

Es gibt seit mindestens 2008 normale SATA Festplatten mit 10^15 UER. Neben der höheren Fehlertoleranz wurden damals auch noch die ECC Daten auf den Magnetscheiben anders abgespeichert. Müsste da bei meinen Mails nachschauen, da hierzu nichts im Datenblatt stand. Hrm. war sogar 2007 schon so. Lange ists her:

Festplatteninformationen - ECC
Donnerstag, 12. April, 2007 12:35 Uhr
Von:
"Euro_TechSupport/Seagate@seagate.com" <Euro_TechSupport/Seagate@seagate.com>
An:
xxx@xxx

Sehr xxx xxx,


Die ECC Funktion gibt es bei Enterprise Festplatten - Seagate
Barracuda ES und Maxtor Maxline Festplatten. Mehr detallierte
Informationen dazu haben wir nicht verfuegbar, aber Sie koennen
sich das Datenblatt fuer diese Festplatten unter folgendem Link
anschauen:

http://www.seagate.com/docs/pdf/datasheet/disc/ds_barracuda_es.pdf

Im Datenblatt stand auch nichts über das geänderte schreiben der ECC Daten drinnen.

Seagate und alle anderen Hersteller wussten es damals schon. Die Präsentationen sind unter SNIA.org frei als PDF verfügbar gewesen für alle anderen interessierten - die nicht Mitglied sind.
Die Nearline/Enterprise ready SATA Laufwerke mit 10^15 haben übrigens so gut wie immer die letzten vier Jahre über ca. das doppelte bei gleicher Speichermenge gekostet als die günstigeren Desktoplaufwerke mit 10^14.
Und Produktvielfalt gabs schon immer. Preise vor der Überflutung: Desktopplatten ~ 3-5 Cent/GByte. "Nearline" Platten ~ 10 Cent/Gbyte, 10k und 15k rpm SAS Platten mit 10^16 ~ 60 Cent/Gbyte. SCSI U320 Platten lagen noch bei 1,20 Euro/Gbyte, da es schon lange keine neuen Modelle mehr gibt. Ist wie bei den Arbeitsspeicher preisen, wenn nix neues mehr raus kommt, bleibt der Preis für die alte Technik stehen.
Wie es schon oft heißt: You get what you pay for.
Produktivdaten mit gewissem Wert fürs Unternehmen: SAS 10/15k rpm. Backup oder Tier2 Storage für weniger genutzte Daten: SAS 7200rpm oder SATA 7200 Nearline Laufwerke. Disk to Disk Backup: SATA Nearline oder "24/7" Modelle. Disk2Disk2Tape: LTO4/5 Laufwerke.

Preis - jetzt nur bezogen auf das Laufwerk/Band:
60 Cent/Gbyte, 10 Cent/Gbyte, 5 Cent/Gbyte und beim Band (45 Euro LTO5 für 1500GByte) 3 Cent/Gbyte.

---------- Post added at 15:11 ---------- Previous post was at 14:47 ----------

Gerade bin ich verwirrt. Also dieser Fehler beim Rebuilt (im Raid5) ist ja ein Lese-Fehler der Festplatte, sodass kurzfristig keine Daten/Datei gelesen werden kann.
Das was du jetzt anspricht --> dass ein Sektor nicht wiederhergestellt werden kann und die Platte länger als 1,x Sek. braucht um diesen Fehler an den Kontroller weitergeben zukönnen, sodass die Raid-Controller (evtl.) die platte als Defekt markiert und degraded , ist doch nun zusätzlich noch ein andere Fehler, der bei Desktop-Platten auftreten kann, oder sind diese beiden Fehler ein und das selbe?

Weil ich dachte, dass das Problem mit dem Rebuilt im Raid 5 (URE-Fehlern), die bei Desktop-platten bei 10^14 liegen und bei Enterprise platten bei 10^15. --> Würde bedeuten, dass dieser Fehler theoretisch im RAID5 irgendwann, egal ob Desktop oder Enterprise-Platten, auftreten wird.
Und der Fehler mit dem Wiederhergestellten Sektor (egal welches Raid-Array), wo die Enterprise-Platten das sofort an den Kontroller weitergeben und die Desktop-Platten evtl. nicht, ist doch vermeidbar indem man halt Enterprise-Platten kauft, oder?
--> Sprich, das sind doch 2 verschiedene Fehler die auftreten können oder?

Es ist ein und der selbe Fehler. Wenn der Sektor nicht als lesbar gilt, wird er an den Controller entsprechend auch als nicht lesbarer Sektor weitergegeben.

Hierzu mal der Auszug eines Datenblattes vom August 2007 Revision D 100293075.pdf für eine Savvio SCSI ST973401LC und ST936701LC - ja es gab 2.5" SCSI Platten mit 36 und 74GByte (Einsatzzweck waren die frühen Bladesysteme).
Seite 37/38 7.0 Defect and error management - 7.2 Drive error recovery procedures

If the RC bit is set, the drive
will transfer the unrecovered data with no error indication and continue to execute the remaining command. If
the RC bit is not set, the drive will stop data transfer with the last good LBA, and report a “Check Condition,
Unrecovered Read Error.”

Read retry count [1]	Maximum recovery time per LBA (cumulative, msec)
0	77,7
1	89,7
2	305
3	353
4	401
5	419
6	466
7	586
8	676
9	724
10	777
11 (default)	1,591

[1] These values are subject to change.

Fürs schreiben sind deutlich geringere Werte vorgesehen von 0 = 35,9 ms bis hin zu 5 = 221,3ms (default). Was auch logisch ist, warum sollte man lange Versuchen in einen schlechten Sektor etwas hinein zu schreiben, nur um ihn dann später nicht mehr lesen zu können. Normale SATA Platten dürften nicht die Möglichkeit haben, diese Werte als normaler Endanwender ändern zu können.

(Das RC bit ist die Möglichkeit der Festplatte mitzuteilen, dass man alle Sektoren vom Speichermedium haben möchte, auch wenn diese ggf. Fehlerhaft sind. Quasi ein dd_rescue ohne das spätere neu einlesen der fehlerhaften Sektoren.)

 

[Winni81]

Endlich mal wieder eine gute Diskussion hier. Lustigerweise "kenne" ich einige Leute, weil sie ein 343B haben oder hatten Raidsystem brauchen einfach Platz
Ich hatte mich Ende letzten Jahres in das Thema eingelesen. Es gibt auch Consumer-Platten, welche eine BER von 10^15 aufweisen. Die HD204UI wäre solch ein Modell. Allerdings sind 50000 Start-/Stoppzyklen wieder nicht so berauschend. Hinzu kommt, dass es eben keine 7200rpm und eine 4K emulierte Platte ist. Daher habe ich mich für die 7K3000 & Raid 6 entschieden, welche leider nur eine BER von 10^14 hat. Dafür ist sie 24/7 zugelassen und 300000 Start-/Stoppzyklen soll sie angeblich auch schaffen. Außerdem gibt es bei Hitachi wenigstens anständige Datenblätter: Hitachi 7K3000

Daher verkaufe ich gerade auch meinen Perc 5/i und 6x WD 500GB RE2 (welche übrigens eine sehr gute BER von 10^15 haben). Bei dieser Größe und BER 10^15 ist gegen Raid 5 nichts einzuwenden. Aber was hilft es, wenn der Platz ausgeht. Der Perc 5/i ist wirklich ein absolut schneller und "guter" Controller.

Zurück zum Thema, hier gibt es eine sehr schöne Beschreibung des Problems: Raid Mathematik für Admins

 

[orpheus88]

Für mich war das genannte Problem der Grund meine 14*2 ins RAID6 zu hängen, läuft.^^
Bei 3ware muss man vor dem Rebuild explizit den Haken setzen, das Fehler übersprungen werden sollen, wenn man den nicht setzt, bricht er das Rebuild im Fehlerfall ab (kann man aber neustarten, sollte dabei aber natürlich den Haken setzen).

 

[Schlingel_INV]

ohne jetzt nochmal neu nachzuschauen: Diese Diskussion gab es schonmal vor einiger Zeit. Ich hatte extra bei WD nachgeschaut. Die Greens hatten 10^14, ebenso wie meine ersten WD Black 640GB. Die 1TBer hatten jedoch schon 10^15. Ich gehe eh davon aus, dass WD diese aus der RE-Serie nimmt nur halt ohne TLER-Feature. Mit ein Grund warum ich auf eben jene setze - derzeit im R6. Bei der nächsten Erweiterung werd ich ebenfalls auf die 2TB Black setzen oder ggf. direkt zur RE-GP-Serie greifen.

Das R5 aus 5x500GB RE4 lüppt jedenfalls absolut unaufällig und zuverlässig.

 

[Freak574]

Raid5 bei 16TB auf ultra lahmarschigen SATA Platten? Und Ihr denkt über Gerüchte von irgendwelchen berechenbaren Fehlern wg. TB Grenzen nach?


Allein die Rebuild Time bei so einem Raid5 an einem beschränkt performanten Raid Controller ist ein absolutes no go... wenn bei uns im Storage ne Platte ausfällt krieg ich schon Schüttelkrämpfe wenn das ganze für 24h an der 2. Parity Platte im RAID6 baumelt..

 

[Snipa]

Freak574:
also ich weiss ja nicht wo du dich im Forum rumgetrieben hast, als der Thread hier entstanden ist, aber es ging ursprünglich um 8x 2TB WD Black @ Raid 5 am LSI 9260-8i. das sind also weder ultra lahmarschige SATA-Platten, noch ein beschränkt performanter Controller.

da wird ein Rebuild vielleicht 6h dauern und nicht 24h oder ne ganze Woche?

 

[dv2130n]

16 TB array, davon werden beim Rebuild 16 TB / n * (n - 1) gelesen und 16 TB / n geschrieben,
beim rebuild werden also jedenfalls volle 16 TB bearbeitet, ausserdem wird das xor berechnet
16 TB, das sind rund 16.000.000 MB
angenommen die Platten haben eine dauerhafte Media Rate von 130 MB/s,
dann braucht das lesen bzw. schreiben von zusammen 16 TB rund 123077 sekunden, das sind schon mehr als 34 Stunden für den Rebuilt

doch meines Wissens nach legt man für die Rebuild Time nicht die volle Media Rate der verwendeten Platten zugrunde,
sondern nur 1/3 davon, so dass man auf die dreifache Zeit käme, in dem Fall wären das 34 * 3 = 102 h, also mehr als 4 volle Tage


MTTR setzt sich zusammen aus der Zeit t1 zum Feststellen eines Plattenausfalls und deren Ersetzen (im Hotspare-Fall ist diese Zeit = 0)
sowie der Zeit für den Rebuild, demnach
MTTR = t1 + array-grösse [in MB] * 3 / datenrate [in MB/s]

selbst wenn der controller die media rate von n - 1 parallel lesenden Platten verarbeiten und das xor innerhalb der Zeit, die eine Rotation braucht, schafft,
sind also 6 h für ein 16TB rebuild sehr optimistisch

 

[Freak574]

Freak574:
also ich weiss ja nicht wo du dich im Forum rumgetrieben hast, als der Thread hier entstanden ist, aber es ging ursprünglich um 8x 2TB WD Black @ Raid 5 am LSI 9260-8i. das sind also weder ultra lahmarschige SATA-Platten, noch ein beschränkt performanter Controller.

da wird ein Rebuild vielleicht 6h dauern und nicht 24h oder ne ganze Woche?

ich kann meinem Vorposter nur beipflichten... vor allem mit solchen kleinen Raidcontrollern.. auf unseren STorages ( IBM DS3400 ist auch schon in die Jahre gekommen ) mit SAS läuft ein Rebuild von 22 Platten schon wenigstens 1,5 Tage.. und da hat ein Raid auch "nur 5TB" + 50% Rebuild Priorität. Und SAS Platten sind bei solchen Aktionen wie Rebuild + Nutzlast wesentlich laststabiler als SATA HDDs..

 

[Snipa]

naja, ich kenne es halt nur von meinem 3ware 9650SE 16ML. wenn da ein RAID 5-Rebuild gemacht wird, braucht das Ganze nur bissl mehr Zeit als es braucht, um eine einzelne Platte zu füllen. egal wieviele Platten im RAID sind. wie wenns halt gleichzeitig von allen Platten liest und auf die zu rebuildende Platte schreibt. deshalb konnte ich die Rechnung von dv2130n nicht nachvollziehen, da es nach seiner Rechnung nicht bei allen Platten gleichzeitig liest, sondern wie wenn nur eine auf einmal arbeiten würde und dass es dadurch länger dauert, je mehr Platten im RAID sind.

ausserdem sind wir nicht im Server/Workstation-Unterforum oder deren Profi-Bereiche, sondern im Festplatten und Storage. in diesem Bereich hier würde ich schon garnicht erst von SAS-Platten reden, wie von Nutzlast während eines Rebuilds. wenn auf meinem Storage zuhause ein Verify oder Rebuild usw gemacht wird, dann lasse ich die Kiste schön laufen und belaste das RAID doch nicht im grossen Stil, um Rebuild/Verify auszubremsen. hallo?

 

[Freak574]

dann hast du nachwievor nicht verstanden worum es geht.

Ein SATA Raid aus 16TB kann einfach nicht "in Stunden" gebuildet sein, schon gar nicht mit SoHo bzw. low Budget Hardware.

Mein 9590se und 4x147GB Raptor hat auch gemütliche 90-120 Minuten gebraucht um nen Raid5 zu builden und da reden wir von weit weniger Kapazität..

 

[Lebedev]

als der Thread hier entstanden ist, aber es ging ursprünglich um 8x 2TB WD Black @ Raid 5 am LSI 9260-8i.

Also nur um nochmal die Ursprüngliche Diskussion abzuschliessen; die Western Digital Black die ich verbaut habe, haben eine Error Rate von 10^15, ich brauche mir also keine Sorgen machen wenn ich meine 16TB in einem Raid 5 betreibe. Mal ganz abgesehen davon denke ich das die Error Rate die ja der Hersteller angibt ein Durchschnittswert ist, 100% sicher ist diese Angabe denke ich daher nicht. Nichtsdestotrotz läuft mein Raid jetzt im Raid 6, zumindest solange der Speicher nicht voll ist^^

 

[andichen]

Also nur um nochmal die Ursprüngliche Diskussion abzuschliessen; die Western Digital Black die ich verbaut habe, haben eine Error Rate von 10^15, ich brauche mir also keine Sorgen machen wenn ich meine 16TB in einem Raid 5 betreibe.

Dann musst du ein anderes Datenblatt haben oder die 4 mit der 5 verwechselt haben, wo ich eben geschaut haben, haben sämtliche WD Blacks auch nur 1 in 10[SUP]14[/SUP]...

Habe jetzt mal bei Samsung bzw. Seagate gestöbert. Leider fehlen die Datenblätter für die F3- und F4-Platten, habe sie nur für die F2-Serie finden können. Allerdings haben sogar schon die F2-Platten die 1 in 10[SUP]15[/SUP], zumindest lt. Datenblatt, weshalb es sehr nahe liegt, dass es auch auf die neueren Platten zutrifft. Danke für den Tipp, Winni81, die Unsportlichkeit in deinem Angebotsthread sei dir damit verziehen...

Tja...somit bestätigt es sich doch, dass dieses "Feature" kein Kostenfaktor sein kann. Die Samsung-Platten standen bei Preis-/Leistung sogar fast immer ganz oben. Daher frage ich mich, weshalb es die übrigen Hersteller nicht zu vergleichbaren Preisen anbieten... Schade, dass die F3 schon "weg vom Fenster" ist, ansonsten wäre dies die Platte, die so ziemlich alle für Raidbetrieb positiven Eigenschaften in sich vereint. Na mal schauen, vielleicht gibts ja mal irgendwann einen größeren Restposten, sollte sich bis dahin nicht irgendwas anderes getan haben...

 

[Schlingel_INV]

http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-701276.pdf

so wie es ausseiht 10^14. ich bin mir aber absolut sicher, dass es eine version des datenblatts mit 10^15 für alle Disks über 1TB gab. Sehr wahrscheinlich Marketing. So greift der Kunde lieber eher zu den REs

Raid6 und gut ist

 

[bluesunset]

Bei Samsung kann es durchaus dran liegen, dass sie keine Platten mit 10k oder 15k rpm bzw. mit SAS oder FC Interface anbieten.
Zumindest WD hat die Raptor Platten. Seagate, Hitachi und Fujitsu hatten schon lange Zeit SCSI/SAS Platten und konnten wohl auch durch ihren Ruf einen entsprechend Preis verlangen.

 

[Lebedev]

10^15 für alle Disks über 1TB

hab ich auch gelesen...

 

[qiller]

Wer Angst um seine Daten hat, der verwendet eine ganz andere Storage-Strategie:
1. Single-Drive only
2. Standard Sata-Controller
3. Backup wieder auf ein Single-Drive System (idealerweise 1:1, also ungepackt).

Warum? Ganz einfach:

-Controller-Ausfall ist egal, die Platten sind an jedem anderen Controller sofort wieder verfügbar und lesbar
-Platten-Ausfall ist egal, solang nicht genau dieselbe Platte im Backup-System kaputt geht (sehr unwahrscheinlich, wenn das Backup-System unabhängig und größtensteils offline betrieben wird)
-Selbst wenn es zu so einem "Doppelausfall" kommen sollte, fallen nur die Daten auf dieser Platte aus, nicht ein komplettes 10TB Raid o.Ä.
-der viel wahrscheinlichere Fall des Sektor-Ausfalls bei Festplatten führt zu keinem Degrated RAID, in welchem auch alle anderen Daten im RAID "gefährdet" sind. In der Regel sind die meisten Daten, wenn nicht sogar alle, komplett lesbar. Defekte Dateien können notfalls aus dem Backup einzeln restored werden, was gegenüber einem Rebuild deutlich schneller vonstatten geht.
-besserere Zugriffszeiten, vor allem beim Schreiben und parallelen Zugriffen übers Netzwerk bei vernünftiger Aufteilung der Daten über die Platten (RAID5 4Write-IOs vs. Single 1Write-IO)
-durch das 1:1 Kopieren der Daten beim Backup geht nicht ein komplettes Backup oder .rar-Archiv verloren, wenn es Lese-Fehler auf einer Backup-Platte gibt.
-deutlich kostengünstiger!

Die Strategie ist klar: So wenig wie möglich "Verschachteln", "Zerhacken" und "Gruppieren" der Daten. Je einfacher, je weniger kann kaputt gehen. RAIDs, Archive oder Containerdateien von Backup-Programmen erhöhen die mögliche verlorene Datenmenge drastisch bei einzelnen Sektor-Fehlern von involvierten Festplatten.

Wenn man mal ganz nüchtern betrachtet, wodurch man seine Daten verlieren kann und die Fehler in Relation setzt, muss ich zumindest für mich ganz klar sagen: Ein RAID5+ hilft mir hier kein Stück weiter, im Falle von RAID5 verschlimmert es die Situation sogar (in Bezug auf die Daten-Verlustmenge).

Das einzige was man dann nicht mehr hat, sind dann irgendwelche R0xx0r 500MB/s+ Datenraten, wo ich mich vor allem bei GB angebundenen Servern oder NAS frage, wozu die gut sein sollen. Aber naja, anscheinend hat jeder so seine Strategie, die einen stecken Kohle ohne Ende in ihr System und machen es dadurch immer komplizierter und der andere versucht es hingegen so einfach zu halten wie möglich .

mfg Oli

 

[Snipa]

mal davon abgesehen, dass du bissl Off-Topic bist (siehe Threadtitel):
-die Thematik ist doch schon relativ ausdiskutiert und man ist der Meinung, dass bei grossen Arrays RAID6 RAID5 vorzuziehen ist?
-hast du den Thread überhaupt durchgelesen oder wolltest du nur deinen Senf dazugeben?
-machts den Eindruck, als hättest du nur soviel Daten, dass du nur theoretisch redest, ohne Bezug zur Praxis?
-wenn man verschiedene Datenarchive hat, die einzeln jeweils viele TB gross sind, kommt man bei einzelnen HDDs und "kleinen" Partitionen gar nicht drumherum, alles zu zerhacken und zu verschachteln, bzw hat nie alles im Überblick, wie es in grossen Partitionen aus grossen RAIDs der Fall ist?
-ich kenne einen, der alles auf einzelnen Festplatten hat, sowie die Platten vom Server auch noch als Netzlaufwerk verbunden hat. er hat das Problem, dass er im Alphabet zuwenig Buchstaben hat
-und warum sollten alle Server oder NAS nur mit 1xGbit angebunden sein? ich hab 2 PCs mit je 2xGbit. ich kenne Leute mit Mainboards mit 4xGbit und solche, die Netzwerkkarten mit 4xGbit verbauen. dann gibts noch die mit 10Gbit ...

 

[bluesunset]

Oder die mit 4Gbit FC HBAs 2 und 4 Port Modelle

 

[chris_te]

Eine bescheidene Frage:

Wo speichert ihr ein Backup mit 16TB ab???

 

[bluesunset]

Auf anderen Raid Arrays oder wie in meinem Fall auf LTO Bändern.

 

[chris_te]

Da hast aber dann ein paar mehr LTOs...

 

[bluesunset]

LTO 1 speichert 100GByte unkomprimiert. LTO 3 speichert 400GByte und LTO5 1500GByte. Von Generation zu Generation wurde die Speicherkapazität verdoppelt. Bei LTO5 wärens gerade mal 10 Bänder - bei Festplatten ist immer ein Teil vom Dateisystem reserviert und nicht direkt nutzbar.

 

[chris_te]

Ich weiß wie viel LTO sichert ^^

Wenn man bedenkt, dass ein Band 40-50€ kostet und du 10 Stück brauchst, dann nenn ich das "ein paar mehr LTOs"