Bin ich der einzige, der ein 16TB R5 bedenklich findet?
+ Antworten
Ergebnis 1 bis 25 von 68
- 07.02.12, 11:23 #1
Große Arrays als Raid5 laufen lassen?
- 07.02.12, 11:55 #2
- 07.02.12, 11:56 #3Stabsgefreiter
- Registriert seit
- 16.08.2008
- Beiträge
- 309
Habe ich auch seit über einem halben jahr ohne ein Problem am laufen
Pc: AMD 1090T - Asrock Extreme 3 890GX - 16Gb Teamgroup Elite - XFX 5750
Server: Intel sandy 2100 - msi p67 gd53 - 8Gb Teamgroup Elite - Areca 1880-ix-16 - 8*Samsung F4 2TB Raid5 - 2*WD Caviar Green 2TB Raid 1
Mein Verkauf - Mini SAS Kabel (8087) - SFF 8086
- 07.02.12, 13:01 #4
Also die Kapazität ist doch unwichtig (vor ein paar Jahren hat man das selbe wohl über 250GB Festplatten (250GB, verdammt ist das viel!) auch gesagt), vielmehr zählt die Anzahl der HDDs. Es sind ja netto auch "nur" 14TB, und das ist ja nicht komplett ausgelastet. Zudem mache ich von den wichtigen Daten (ca. 1TB) immer ein Backup, und wenn eine HD kaputt geht kann ich die sofort auswechseln. Mal ganz davon abgesehen (meine persöhnliche Meinung) würde ich ein R6 oder vergleichbar erst ab 10 Festplatten aufwärts einsetzen. Ich sehe das immer so das nicht eine Festplatte kaputt gehen darf, sondern das zwei zeitgleich kaputt gehen müssen damit das Raid futsch ist, und das halte ich einfach für unwahrscheinlich bei weniger als 10 HDDs. Man muss auch mal daran denken das tausende Menschen Weltweit nur eine Festplatte im Rechner haben, und diese Rechner laufen zig Jahre^^
Ich kann mich irren, aber ich glaube das defekte Festplatten weniger oft die Ursache für ein defektes Raid sind als viele denken.
- 07.02.12, 13:24 #5
Das Problem dass du hast, sind URE. Es gibt im Netz einen schönen Artikel, "why R5 is dead in 2009" oder so. Da wird das beschrieben. Um es grob zusammenzufassen:
Deine Platten haben alle ~12TB einen nichtkorrigierbaren Lesefehler. aktuelle Controller fangen mit dem Rebuild des Arrays afaik schon an, wenn eine Platte so einen URE zeigt, und nicht wenn dir eine ganze Platte abraucht. Das Problem bei einem R5: bei einem Rebuild hast du keinerlei Schutz gegenüber erneuten Ausfällen. Und wenn du den Inhalt von 7 Platten neu auslesen musst (~14TB ), hast du mit einer rechnerischen Wahrscheinlichkeit von 100% wieder einen URE.
- 07.02.12, 13:44 #6
Hier ist der selbe artikel in deutsch: Warum 2009 RAID 5 nicht mehr sicher genug ist
der artikel ist total beschränkt, allein schon deswegen weil der autor schreibt das in 2009 2TB HDDs alltag sind (ist es nichtmal heute) und weil er zum einen davon ausgeht dass das ganze raid voll ist, und zum anderen müsste das nicht lesbare byte auch noch paritätsdaten enthalten. zudem würde das bedeuten das man mit steigender kapazität immer mehr paritätslaufwerke braucht.
ich hatte irgendwo mal ne seite gfunden wo die ausfallwahrscheinlichkeit wie hoch bei wieviel festplatten ist, finde sie aber leider grade nicht wieder.
- 07.02.12, 14:07 #7
OT: das hat ja bekanntermaßen andere Gründe.
Festplatten werden knapp | c't
Grüße
- 07.02.12, 14:14 #8
- 07.02.12, 14:31 #9
Wie es mir scheint hast du den Artikel nicht verstanden.
Es geht nicht darum, dass 2TB Platten Alltag sind, sondern dass die Größe eines Arrays die Anzahl der korrekt ausgelesenen Sektoren übersteigt. Ja Sektoren. Die Platte kann den gesamten Sektor nicht wiederherstellen, nicht nur 1 Byte.
Ein Rebuild umfasst das gesamte RAID. Wie voll das Laufwerk ist, weiß nur das Dateisystem, nicht der Controller, der eine Stufe tiefer agiert.
Der unlesbare Sektor muss mitnichten Paritätsdaten enthalten. Wenn der Fehler in einem gesunden R5 auftritt, wird er aus Paritätsdaten wiederhergestellt, bzw. die Paritätsdaten werden neu geschrieben. Wieviel Daten dafür von den Platten neu eingelesen werden müssen, hängt vom Controller ab. Fällt dir eine Platte aus, UND beim Rebuild tritt ein URE auf (die rechnerische Wahrscheinlichket liegt bei 7 Platten à 2TB bei 100%), dann ist es scheiß egal, ob der Sektor Paritätsdaten oder Nutzdaten enthält, dann hast du ein Problem. Manche Controller setzen das Rebuild fort (und markieren den Sektor anschliessen als "bad"), manche brechen ab.
- 07.02.12, 14:49 #10
Meine Aussage "der artikel ist total beschränkt, allein schon deswegen weil der autor schreibt das in 2009 2TB HDDs alltag sind (ist es nichtmal heute)" war natürlich nur beiläufig und sollte bloß klarmachen das die Ansicht die der Autor vertritt, nämlich das 2TB Platten 2009 Alltag sind, und deswegen Raid 5 ab 2009 nicht mehr sicher ist, beschränkt ist, da andere leute anhand solcher Artikel planen.
Völlig wurscht, erklär mal warum ein Raidcontroller Daten von einem defekten Sektor wiederherstellen soll mit dem gar nicht gearbeitet wird, weil einfach keine Daten drauf liegen.
Ich will damit nur sagen das man keinen Datenverlust wegen defekten Sektoren hat wenn auf diesen Sektoren gar keine Daten liegen.
- 07.02.12, 16:34 #11
- 07.02.12, 17:00 #12
Der Autor hat rechnerisch bewiesen, dass ab einer bestimmten Kapazität RAID 5 nicht mehr sicher ist. Ist Mathematik nun beschränkt
?
Weil der RAID-Controller nicht weiß, ob da was drinnen steht oder nicht. Der schreibt einfach nur Blöcke, die er vom OS geliefert bekommt zusammen mit Paritätsdaten auf die Laufwerke. Was da drinnen ist interessiert ihn überhaupt nicht. Wurde aber schon erwähnt...
Es hat schon seinen Grund, warum Sun ZFS entwickelt hat - mit dem Merkmal, dass einer Festplatte nicht zu vertrauen ist.
Die Diskussion passt allerdings nicht in den Bilderthread und die Mods werden das hier nicht gerne sehen...
- 07.02.12, 17:51 #13
Der Controller (jedenfalls die LSIs) schreibt beim Rebuild jeden Block auf die neue HDD. Das bedeutet im Falle von R5, dass mit 100% Wahrscheinlichkeit bei dem hier besprochenem R5 ein URE auftreten wird. Es kann sein, dass der Controller weitermacht, es kann jedoch sein, dass er Dir den Rebuild abbricht. Die Folge ist ein Fehler auf dem Array der sich nicht mehr beheben lässt.
R6 ist genau deswegen der Nachfolger. Der Vorteil, dass sogar zwei HDDs ausfallen können ist eher nen Nebengimmik bzw im "Notfall" hat man dann auch Fehler jedoch ist nicht alles fricke. Es ist im Grunde bei 2TB-Disks und R6 ebenfalls nur eine HDD ist, wenn man keine korrupten Daten haben möchte.
Das Ganze lässt sich nochmal abrunden wenn man auf R60 geht (wenn es viele Disks sind) so beschränkt man die wiederherzustellende "Menge" an Daten.
Wenn man sich das Problem mal vor Augen führen möchte lasse man einfach einige Zeit Patrol Read laufen. Wenn "Unexpected Sense on PD... blabla) auftritt hat man UREs dabei, die sich aber durch nen Consistency Check beheben lassen. Fällt jeodoch ne Platte aus war es das mit der Behebemöglichkeit.
- 07.02.12, 18:05 #14Oberbootsmann
- Registriert seit
- 02.09.2009
- Beiträge
- 899
- 07.02.12, 19:51 #15
aus nem anderen Forum:
Original von Snipa
noch ne generelle Frage zum Topic: "Error rate (non-recoverable, bits read) 1 in 10^14" <-- wegen dem sagen manche, dass man bei RAIDs von >10TB nicht auf RAID5, sondern RAID6 setzen sollte. was meint ihr dazu? ist das Humbug?Original von PERSON A
Ja das ist Humbug, da die Fehler sogenannte "silent corruption" auslösen, der Raid-Controller erkennt solche Lese/Schreibfehler gar nicht, da er die CRC Summe nicht überprüft sondern einfach schön seine Bits verteilt. Wenn er meint das er 1 geschrieben hat und alle 1x10^-14 Bits tritt eine 0 auf dann ist da halt eine 0, da hilft nur die Fehlerkorrektur des Dateisystems die in 99,99% diesen Fehler erkennt und repariert wenn darauf zugegriffen wird. Eine andere Lösung wär Raid-Z mit ZFS zu verwenden, das ist jedoch eine Softwarelösung die die CRC Summe zurückliest um zu überprüfen ob die Daten richtig geschrieben wurden.Original von PERSON B
Nö, ist es nicht. Alle grossen Storage Hersteller Empfehlen RAID6 mit SATA, schon nur wegen der TTR (mean time to recover). Den Fehler hättest du mit RAID6 ebenfalls, aber wie gesagt, die Empfehlung kommt nicht wegen dem.
Hast du irgendwo im grossen Stil RAIDZ mt ZFS im Einsatz?Game-PC: S1366 i7 920, ASUS P6T6 WS Revolution, 6GB 1600 DDR3, EVGA GTX285 FTW-Edition, 2x80GB Postville, 3ware 9650SE 16Port, HighPoint RocketRAID 2680 8Port, Enermax 85+ Revolution, Lian Li PC-A71-FB
Backup: S775 QX9650, ASUS P5Q-E, 8GB GEIL 1066 DDR2, nV 8400GS passive, HighPoint RocketRAID 2680 8Port, Corsair VX 450W, Lian Li PC-A71-FB
- 07.02.12, 20:58 #16
@Snipa: Das was Person A da behauptet, trifft nur zu, wenn die Platte bei einem URE einfach ein "falsches" Bit zurückgibt. Dem ist aber NICHT so.
- 07.02.12, 21:40 #17
Genau die Gedanken hab ich auch gehabt (und den Bericht dort gelesen), deswegen werkeln bei mir nun 2x RAID6 die ich (unregelmässig) nochmal extern sichere (zumindest das "wichtige").
- 07.02.12, 22:25 #18Stabsgefreiter
- Registriert seit
- 17.11.2010
- Beiträge
- 357
die Chance für Datenverlust durch einen einzigen Sektor-Fehlers im raid-5 array mit n Platten nach einem Plattenausfall liegt bei
(n - 1) * Diskkapazität[in Bit] / Bit Error Rate [der verwendeten Platten]
sei ein raid-5 array aus 10 Platten á 1TB mit einer BER von 10^14, mit welcher Wahrscheinlichkeit tritt dann ein Lesefehler während eines Rebuild (nach dem Ausfall einer ersten Platte) ein?
1TB = 8 * 2^40 bits, ausgedrückt in Potenzen zur Basis 10 sind das 8,79 * 10^12 bits
da für einen Rebuild sämtliche Sektoren aller verbliebenen 9 Platten gelesen werden müssen, ergibt das eine Menge von 79,16*10^12 oder 7,9*10^13 zu lesenden Bits
beträgt nun die Lesefehlerrate (wie bei low end platten üblich) 10^14, dann ergibt sich 7,9*10^13/10^14 also 79% Chance, dass während des raid-5 rebuild durch Lesefehler Daten oder das ganze array verloren gehen
für 2TB Consumer Platten mit 10^14 BER sieht es wie folgt aus
2TB in 10er Potenzen ausgedrückt sind 17,59*10^12
10^14/17,59*10^12 = 5,7; i.e. bei Verwendung von 5,7 Platten dieses Typs tritt nahezu zwingend ein Lesefehler während des Rebuilds ein
bei Nearline Platten á 2TB mit 10^15 BER tritt, wie man nun leicht selbst überprüfen kann, mit an Sicherheit grenzender Wahrscheinlichkeit erst bei Verwendung von 56 Platten dieses Typs ein Fehler dieser Art ein
was also kann man tun, 4 Dinge, würde ich sagen:
* für aktuelle Backups sorgen
* anständige Festplatten verwenden mit besseren BER, bei grösseren Platten im Sata-Bereich sind das die sog. Nearline Platten, zb. Constellation ES
* in der Formel oben an dem Parameter n drehen, um die Wahrscheinlichkeit für nicht korrigierbare Fehler während des rebuild eines raid-5 zu reduzieren;
das ist es nämlich, was raid-50 tut, und dennoch grössere Datenmengen handeln kann als ein raid-5 allein
für raid-50 bleibt allerdings immer noch das Problem eines möglichen zweiten Plattenausfalls, besonders bei low end platten
die Gesamt-Verlässlichkeit, bzw. umgekehrt die Chance auf Datenverlust eines solchen Arrays bestimmt sich bekanntlich aus den drei Grössen MTTR, MTBF und BER
für die Verlässlichkeit eines raid-5 gilt: MTBF^2 / (n * (n - 1) * MTTR), wobei n Anzahl der Platten
eine seriöse, und insoweit vorsichtige rechnerische Annäherung an die Problematik berücksichtigt aber natürlich die in der Praxis zu beobachtende Neigung von arrays nach einem ersten Plattenausfall im Rebuild gleich noch einen zweiten Ausfall nachzuschieben; ein raid-5 und ein raid-50 sind dann tot. Solche sogenannten korrelierten, nämlich von den Umständen abhängigen Plattenausfälle, deren Eintrittswahrscheinlichkeit eben nicht mehr entlang der statistischen Ausfallwahrscheinlichkeit der einzelnen Platte verläuft, werden dergestalt berücksichtigt, dass für eine weitere (zweite) eine 10mal höhere Wahrscheinlichkeit und für eine weitere (dritte) Platte eine 100mal höhere Ausfallwahrscheinlichkeit zugrunde gelegt wird
es ergibt sich so folgendes:
-raid-5 = MTBF * MTBF/10 / n * (n - 1) * MTTR
-raid-6 = MTBF * MTBF/10 * MTBF/100 / n * (n - 1) * (n - 2) * MTTR^2
* raid-6 verwenden, damit erschlägt man gleich mehrere Probleme,
ein Lesefehler im Rebuild macht nämlich einem raid-6 gar nichts, die Daten sind wegen der zweiten Paritätsschicht allemal rekonstruierbar
und auch ein zweiter Plattenausfall führt nicht zu irgendeinem DatenverlustServer never sleep
- 08.02.12, 08:19 #19
Und genau deshalb bin ich z.B. von einem Perc5i (toller Controller nach wie vor) jetzt bei einem Areca1261ML mit 14Tb brutto und 10Tb netto im R6.Die wichtigsten Daten sind auch noch sep. gesichert.
Die Constellation ES ist klasse, alledings schon heftig teuer, aber gut der Areca hat auch keine 4,50Euro gekostet
Wär Fälör fintöd tarff sih bähaldn
Verkaufe: nix
- 08.02.12, 09:25 #20
@dv2130n: sehr schön beschrieben.
Genau das ist der Grund warum man ab 1TB auf R6 gehen sollte. Ggf mit vielen Platten vielleicht sogar auf R60 (wobei wer betreibt hier als privater User mehr mehr als 8 HHDs in einem Array!?). Ich hab im Umkehrschluss auch am verbleibenden Perc 5i nur 500GBer RE4s mit 10^15 als R5 laufen. So läuft das Rebuild (dank Hotspare) ebenfalls schnell über die Bühne und UREs sollten ein kleineres Problem sein.
Wenn die HDDs im mom nedd so teuer wären würd ich aktuell auch auf 2TB@R6 aufrüsten. Meine Favs sind derzeit die FAEX (ich tippe auf RE4 nur mit anderem Label und FW) oder RE4s.
Wer sich damals an die Diskussion erinnert: Dort stand bei den meisten HDDs noch 10^4. Plötzlich über Nacht quasi wurde 10^5 draus. Ich wäre deshalb etwas vorsichtig! Ob diese Angeben wirklich überprüfbar sind? Aus der Praxis geh ich eigentlich von öfteren Lesefehlern (siehe Unexpected Sense) aus - insbesondere wenn es Consumer-Platten sind.
- 08.02.12, 10:06 #21
naja, wobei R60 schon etwas overkill ist, oder, auch wie Du sagst vom reinen HW Einsatz....
Ich bin der Meinung R6 und dann eine ColdSpare im Schrank reichen für uns "normalerweise" aus. R6 + HS + CS ist schon irgendwie Paranoia
Wär Fälör fintöd tarff sih bähaldn
Verkaufe: nix
- 08.02.12, 12:30 #22
bei mir laufen 2x RAID 6 mit jeweils 6x Hitachi 7K3000 bisher ohne weitere Probleme.
Gesichert wird über Infiniband 10GB auf einen 2. Server (wird von Strom und Netzwerk getrennt nach Sicherungen), der auf 2x RAID5 läuft (10TB Arrays). Eine Coldspare im Schrank hab ich bisher nicht, wenn auf dem RAID6 mal was ausfällt, wird halt kurzfristig Ersatz besorgt, die Daten sollten also soweit halbwegs sicher sein.
Und mehr Aufwand als Homeuser wird dann doch übertrieben (ist es eigentlich jetzt schon
)
- 08.02.12, 20:47 #23Stabsgefreiter
- Registriert seit
- 16.08.2008
- Beiträge
- 309
nicht gleich hauen wenn ich es jetzt falsch verstehe, auf was ist diese "unrecoverable read error rate" bezogen? Auf das komplette Raid oder pro festplatte? Und dieser Fehler kann vorkommen muss aber nicht? Wenn es nun pro Festplatte diese Rate gibt, dann dürfte es doch eig kein problem sein, denn pro platte werden doch beim rebuild max 2TB gelesen oder irre ich da jetzt?
Ggf kann ja mal jemand aufklären und verbessern falls ich falsch liege!Pc: AMD 1090T - Asrock Extreme 3 890GX - 16Gb Teamgroup Elite - XFX 5750
Server: Intel sandy 2100 - msi p67 gd53 - 8Gb Teamgroup Elite - Areca 1880-ix-16 - 8*Samsung F4 2TB Raid5 - 2*WD Caviar Green 2TB Raid 1
Mein Verkauf - Mini SAS Kabel (8087) - SFF 8086
- 08.02.12, 22:00 #24
@popel88:
Also ich habe das so verstanden, dass es pro Platte ist. Und je nachdem welche Error-rate deine platten haben geschieht das halt öfter oder nicht.
Error Rate
10^14 bits --> 12.5TB
10^15 bits --> 125TB
10^16 bits --> 1.25PB
LINK ZUR TABELLE. D.h. also bei einer "schlechten" platte passiert so ein fehler von 1 bis 10^14 Bits (also im Schnitt bei 12,5TB gelesenen Daten)
und bei einer "guten" platte erst bei ~125TB oder sogar 1.25PB.
-----------------------
Ich habe aber mal eine andere Frage:
Wie auch auf diesem Link zu sehen, steht dort, dass manche Raid-Controller diesen Fehler wärend eines Rebuilts einfach "überspringen" , was dann (NUR) zum Datenverlust dieser Datei führen würde, oder halt den Rebuilt abbrechen, weil der Raid-Controller dann denkt, dass noch eine Platte kaputt ist und den Rebuilt-Prozess abbricht.
Jetzt meine Frage: Wisst ihr was die LSI Megaraid-Controller an dieser Stelle machen? ( Ich hab den Megraid 9260-4i, obwohl das ja egal sein müsste, welcher MegaRaid von der 9xx-Serie).
Brechen die LSI-Kontroller den Rebuilt-Vorgang ab oder markieren sie diese Datei einfach als Fehlerhaft?
(Ich hab nämlich 3x3TB WD-Platten als Raid5
) Geändert von bogomil22 (08.02.12 um 22:18 Uhr)
- 08.02.12, 22:04 #25
Hrhr...jetzt kommen wohl einige ins Schwitzen, die eine ähnliche Konfiguration haben...
Mal schauen, ob ich das richtig verstanden habe: So ein "URE" tritt pro Platte alle 1014 Bits (normale Platten) bzw. alle ~12TB gelesener Daten bei dieser Platte auf. Dieser "URE" kann von der Platte selbst nicht korrigiert werden und muss durch die Parität des Raids ausgeglichen werden. Wenn dies nicht möglich ist, geht das Raid "hops". Das hieße also, wenn beim Raid5 eine Platte ausgefallen ist und ein "URE" bei der Wiederherstellung auftritt ist das Raid futsch. Es spielt auch keine Rolle, ob das betreffende Bit beim "URE" Informationen enthält oder nicht, da bei einem Rebuild die komplette Platte "abgelesen" wird. Soweit richtig..?
Wenn das so stimmt, täte mich an dieser Stelle interessieren, ob man das irgendwie so beeinflussen kann, dass man diesen "kritschen Punkt", sollte es einer sein, "überspringt". Es dauert zwar eine Weile, bis man 12TB gelesen hat, aber in einem Festplattenleben, gerade bei den großen Platten jetzt, kommt das sicherlich einige Male vor. Als nächstes ist es doch so, dass bei einem Raid5/6 die Festplatten alle gleichmäßig gefüllt werden. Das heiße ja also auch, dass man, wenn man ein Raid5/6 mit nagelneuen Platten erstellt, alle Platten nahezu dieselbe Datenmenge lesen/schreiben. Da ist es ja eigentlich so gesehen schon vorprogrammiert, dass sie alle zur selben Zeit an diesen Punkt kommen und wenn dann eben zufälligerweise beim Raid5 noch eine Festplatte ausfällt... Da wäre das Raid6 auch nur noch durch die zweite Paritätsfestplatte im Vorteil...
dv2130n: Hast du für die Formeln mal die Quelle da, würde das gerne noch mal "unvorbelastet" nachvollziehen wollen, gerade was das Abwägen von Raid5/6 betrifft...Meine Marktplatzangebote: KAGO Heizkamin 9kW, Siemens HN52023 Ceran-Herd, Miele Primavera HG01 Geschirrspüler, 2x4=8GB DDR2-800 Kit Kingston, Etasis EFN-560 (Semi-Passiv-NT, 560W), dLAN-Set, LSI MegaRaid iBBU07, Deckel f. Lian Li 343B, MSI Fuzzy CN700, Audigy 2 NX USB, Holux GPSlim GR-240, Telegärtner 24er Patchpanel Cat6.A (modular), PicoPSU-WI 60


LinkBack URL
About LinkBacks
Zitieren





