Hallo miteinander! :) Ich habe zwei Fragen zu RAID6. Vielleicht gibt es ja hier jemanden, der sich mit den technischen Details der Implementierung davon auskennt. :) Es geht um Folgendes: Zu einer bestimmten Anzahl von Sektoren werden ja immer 2 Prüfsummen (im Ggs. zu 1 bei RAID5) gespeichert (über die HDDs verteilt). Wenn ein eine HDD komplett ausfällt, gehen daher keine Daten verloren. Die defekte Platte wird ersetzt und es erfolgt ein Restore. Fällt dabei eine weitere Platte aus, macht das auch nichts, weil ja 2x Parität gespeichert wird. So weit, so gut. Was aber passiert, wenn beim normalen Lesen vom Array die 2-fach gespeicherte Prüfsumme von den gelesenen Daten abweicht? Dies könnte ja vorkommen, wenn auf einer der Platten auch nur ein einziges magnetisch gespeichertes Bit togglet bzw. umkippt. Bei einer 2 oder 3 TB Festplatte könnte ich mir das gut vorstellen, dass da mal das ein oder andere Bit im Lauf der Zeit "schwach wird". :/ So Stichwort "Bit Rot"... Die Folge davon wäre, dass die Parity-IST von der Parity-SOLL (2x-gespeichert) für diesen Array-Bereich abweicht. Meine Fragen dazu sind: 1) Erkennt ein Hardware-RAID-Controller beim Lesen diesen Fall? Oder liefert der einfach die (möglicherweise fehlerhaften!) Sektordaten aus, ohne die Prüfsumme zu vergleichen? D.h. wird die Prüfsumme nur zum "Rebuild" benutzt oder auch im normalen Lese-Betrieb benutzt? 2) Falls ein Controller dazu in der Lage ist, diese Situation zu erkennen, was passiert dann? Kann bei RAID6 ein solcher Fehler abgefangen werden? Dafür bräuchte es vermutlich ja irgendwie sowas wie eine Matrix-Prüfsummenberechnung, also "horizontal" und "vertikal", um zu erkennen, auf welcher HDD der Fehler ist oder? Falls es was zur Sache tut: Der betreffende RAID-Controller ist der "LSI MegaRAID SAS 9280-16i4e". Vielen Dank schon mal im Voraus für alle Hinweise und Tipps! Nick R.
Im normalen Betrieb wird ein solcher Fehler wahrscheinlich überhaupt nicht entdeckt, weil die Parity nicht kontrolliert wird. Das kostet erheblich Performance beim Lesen von kleinen Blöcken. Statt von einer Disk müsste man dazu immer von allen lesen. Gute RAID Controller bieten aber die Möglichkeit, in Zeiten geringer Plattenauslastung nebenbei einen Parity-Check durchzuführen. In RAID 5 kann das nur erkannt werden - es sei denn, der Lesefehler war sporadisch und es kommt bei wiederholtem Lesen zu unterschiedlichen Ergebnissen. In RAID 6 kann der Fehler identifiziert und korrigiert werden.
So ein fehler ist auch sehr unwahrscheinlich. Die Festplatte hat ja selber eine CRC über den Sektoren. Wenn es dort einen Fehler gibt wird der sektor gar nicht sauber gelesen. Außerdem ist die Prüfsumme nicht wirkliche eine Prüfsumme sondern mehr eine parität. Ich glaube bei einem Raid5 kann er gar nicht feststellen ob die Parität falsch ist oder ob die Daten falsch sind. Er kann also auch den fehler nicht beheben. Bei Raid5 wird dann das array ReadOnly geschaltet. Man kann dann eine Festplatte eintfernen und ein Rebuild machen. Aber welche defekt ist muss man dann selber entscheiden.
Unerkannt falsche gelesene Bits laut Datasheets von Seagate: - Desktop Platte: Eines auf 10^14 Bits. - Nearline Storage, also Disks ähnlicher Bauart wie die Desktop-Disks, aber für anspruchsloseren Enterprise-Einsatz: Eines auf 10^15 Bits. - SAS-Disks für Server und Highend Storage: Eines auf 10^16 Bits. 10^14 Bits sind nur 12,5TB.
RAID hat nicht zum Ziel, Fehlerhafte Daten zu erkennen, sondern einen Ausfall einer HD zu überbrücken. Gescheite RAID Controller und Platten überwachen sich selbst und melden Fehler bzw schalten eine Platte offline, bevor sie ganz aussteigt. Will man sich von Datenfehlern schützen, wie Du sie beschreibst, muss sas OS Prüfsummen und Fehlerkorrekturdaten selbst in den Datenstrom einpflegen. Bit können nicht nur auf der Plattenscheibe umfallen, auch auf der Stecke von der CPU zur Plattenoberfläche lauern etliche Stolpersteine für die Bits. Und ja, RAID ist kein Ersatz für ein gewissenhaft durchgeführtes Backup und die Erstellung und Durchexerzierung eines Recoveryplans...
A. K. schrieb: > 10^14 Bits sind nur 12,5TB. richtig, bei 100Mbyte/s Transferrate sind aber 34 Stunden. wenn man jetzt mal von 10^15 ausgeht sind sind wir bei 340 Stunden, ich glaube das muss man auch schon mit fehler in der CPU/RAM/BUS rechnen.
Peter II schrieb: > richtig, bei 100Mbyte/s Transferrate sind aber 34 Stunden. > > wenn man jetzt mal von 10^15 ausgeht sind sind wir bei 340 Stunden, ich > glaube das muss man auch schon mit fehler in der CPU/RAM/BUS rechnen. Kommt drauf an, ob man vor seinem Heim-PC sitzt, oder ob das ein zentrales Speichersystem ist. Disk-Pools, die als Zwischenstation in Backups bei Unternehmenseinsatz dienen, werden mit einem Durchsatz von etlichen hundert MB/s betrieben. Dies aber in Systemen, in denen Caches und "Busse" (die meist keine Busse mehr sind) durchgängig mindestens durch Parity abgesichert sind. Allerdings vermute ich, dass diese Rechnung pro Bit etwas in die Irre führt, da die Absicherung durch CRC m.E. keine Einzelbitfehler möglich macht. Ich nehme daher an, dass man real betrachtet nicht einen Einzelbitfehler pro 125TB kriegt, sondern eine grösseres Bündel falscher Bits pro entsprechend mehr TB.
Danke schon mal für alle Beiträge bis hierhin! A. K. schrieb: > Das kostet erheblich Performance beim Lesen von kleinen Blöcken. > Statt von einer Disk müsste man dazu immer von allen lesen. Ja, stimmt. :/ A. K. schrieb: > Unerkannt falsche gelesene Bits laut Datasheets von Seagate: > > - Desktop Platte: Eines auf 10^14 Bits. > > - Nearline Storage, also Disks ähnlicher Bauart wie die Desktop-Disks, > aber für anspruchsloseren Enterprise-Einsatz: Eines auf 10^15 Bits. > > - SAS-Disks für Server und Highend Storage: Eines auf 10^16 Bits. > > 10^14 Bits sind nur 12,5TB. Ja, genau die Zahlen hatte ich auch gefunden. Das sieht ja erst mal utopisch groß aus, aber bei Datenmengen im TB-Bereich und großen Transfers sind die Quoten ja durchaus in einem erwartbaren Bereich. :/ In dem Fall hier geht es um Nearline-SAS-Festplatten mit einer Rate von 1 zu 10^15 (laut Datenblatt). Es ist übrigens ausschließlich ECC-Server-RAM im Einsatz und die Controller-Baureihe hat auch alle "Schikanen" denke ich mal, aber ich hab keine Ahnung, ob und inwiefern der bei RAID6 auf die Datenintegrität achten kann. http://www.lsi.com/products/storagecomponents/Pages/MegaRAIDSAS9280-16i4e.aspx Ich hatte vorgeschlagen, für den Storage-Bereich auf ZFS umzusteigen, da dies softwareseitig im Filesystem eine Integritätssicherung der Daten beinhaltet (Prüfsummen + Vergleich). Fehlerhaft von der Festplatte gelesene Daten werden so erkannt. Aber das wäre schon ein ziemlicher Systemwechsel. :/ http://de.wikipedia.org/wiki/RAID#RAID-Z_im_Dateisystem_ZFS Mich wundert's auch, dass Microsoft da anscheinend überhaupt noch keine Idee für das Problem hat. Je größer die Storage-Systeme werden, umso eher fallen diese Fehlerquoten ja ins Gewicht. Oracle hat sein ZFS, Linux hat die ältere Open-Source-Version von ZFS oder wahlweise sein eigenes freies btrfs (leider noch experimentell) und MS scheint da bisher noch keine vergleichbare Lösung anzubieten oder täusche ich mich?
DoctorNickR schrieb: > Controller-Baureihe hat auch alle "Schikanen" denke ich mal, aber ich > hab keine Ahnung, ob und inwiefern der bei RAID6 auf die Datenintegrität > achten kann. Bei einem ähnlichen Megaraid lässt sich ein regelmässiger consistency check einstellen.
DoctorNickR schrieb: > Mich wundert's auch, dass Microsoft da anscheinend überhaupt noch keine > Idee für das Problem hat. Die Historie der bei den Microsoft'schen Betriebssystemen gestreuten und dann wieder eingesammelten Gerüchte über grandiosen neuen Umgang mit Daten deuten darauf hin, das sie seit erklecklicher Zeit an etwas arbeiten. Das aber nicht einfach nur ein zwar neues aber strukturell klassisches "me too" Filesystem werden soll, sondern ganz was anderes. Ob daraus allerdings jemals etwas wird steht in den Sternen. Vorrang hat derzeit wohl der Versuch, die von Naturell her eher konservativen Server-Admins von den Vorzügen der Tablet-artigen Windows 8 Oberfläche zu überzeugen.
DoctorNickR schrieb: > Mich wundert's auch, dass Microsoft da anscheinend überhaupt noch keine > Idee für das Problem hat. Je größer die Storage-Systeme werden, umso > eher fallen diese Fehlerquoten ja ins Gewicht. ist es denn die Aufgabe von einem Filesystem? Ich würde sagen nein, es geht einfach davon aus das es richtige Daten bekommt.
Peter II schrieb: > ist es denn die Aufgabe von einem Filesystem? Ich würde sagen nein, es > geht einfach davon aus das es richtige Daten bekommt. Jein, das ist nur der einfachste Ansatz. Wenn man zuverlässige Systeme haben will, dann kann es sinnvoll sein, auf jeder Ebene einen Konsistenzcheck durchzuführen. Allein schon, weil auf jeder Ebene Fehler möglich sind, nicht nur solche der Hardware. Allerdings sollten solche Mechanismen kein Anreiz für Hardwarehersteller sein, es bei der Zuverlässigkeit schleifen zu lassen.
HI Ich weiß ja nicht ob ihr beim begriff Windows 8 schon abschaltet nur wegen des neuen Ui aber unter der Haube gehts ab. http://www.searchstorage.de/themenbereiche/rz-techniken/branchen-mittelstand-enterprise/articles/355244/
...Neben der automatischen Korrektur soll das neue Dateisystem ReFS keine lange Ausfallzeiten mehr verursachen und muss auch nicht zur Reparatur heruntergefahren werden. ... Ob ein Virus oder Fehler auf ein paar MB oder Exabyte zuschlägt wird ihm ziemlich egal sein. Interessant wird hier das KOMPLETTE Backup und die dazugehörige Wiederherstellungszeit! Nur fix ein Snap zurückspielen klappt nicht immer.
> Bei einem ähnlichen Megaraid lässt sich ein regelmässiger consistency > check einstellen. Das passiert auch beim Linux-Soft-RAID (md), da kann kein Sektor länger als ein paar Wochen gammeln. Wobei ich früher eigentlich ein HW-RAID-Freund war, aber mach jetzt nur noch Soft-RAID. Ein gegenüber SW performantes HW-RAID ist inzwischen so unverhältnismässig teuer, dass es sich eigentlich nur in grossem Massstab als NAS (Filer, ...) rentiert, den Kartendreck kann man vergessen. Man hat jetzt eh genügend Cores, da kann einer ruhig nur XORen. Wenn der i86 was schnell kann, dann Speicher auslesen ;) Mal ganz davon abgesehen, dass wir echte RAID-F*ckups beim Kunden nur mit HW-RAIDs gesehen haben. Sehr schön zB. der bei RAID1 bei einer Dell-Kiste (Adaptec?). Eine Platte kaputt, Admin zieht die falsche (=die gehende) raus, RAID völlig im A... Es war dem Controller nicht mehr beizubringen, dass das Array nur degraded ist.
Georg A. schrieb: > Man hat jetzt eh genügend Cores, da Yep, die CPU-Leistung ist nicht das Problem. > kann einer ruhig nur XORen. Wenn der i86 was schnell kann, dann Speicher > auslesen ;) Software RAID muss Write-Thru durchführen, jedenfalls wenn die Daten einigermassen relevant sind. Ein RAID-Controller kann einen Batterie- oder Supercap/Flash-gestützten Write-Cache implementieren. Auf die Latenz von Schreiboperationen, insbesondere bei vielen kleinen, kann das erheblichen Einfluss haben. > mit HW-RAIDs gesehen haben. Sehr schön zB. der bei RAID1 bei einer > Dell-Kiste (Adaptec?). Eine Platte kaputt, Admin zieht die falsche (=die > gehende) raus, RAID völlig im A... Es war dem Controller nicht mehr > beizubringen, dass das Array nur degraded ist. Ähnliches habe ich auch schon erlebt, allerdings vorher beim Test, weshalb der betreffende Hersteller (damals HP) aus der Auswahl flog und ein andere gewann (Dell ;-). Mir ist es lieber, wenn der Controller einem die Möglichkeit bietet, die RAID-Info statt vom Controller auch von der Platte zu verwenden. Das ist auch beim Cloning ganz nützlich.
A. K. schrieb: > Software RAID muss Write-Thru durchführen, jedenfalls wenn die Daten > einigermassen relevant sind. nein, wenn der PC an einer USV hängt kann man genauso mit cache arbeiten. Ich finde es sinnlos wenn die Kontroller eine Backup-battrie als Plicht fordern aber der Servers schon Redundante netzteile und eine bzw. 2 USVs davor hat.
Peter II schrieb: > nein, wenn der PC an einer USV hängt kann man genauso mit cache > arbeiten. Nicht ganz. Wenn das RAM vom PC den Write-Cache darstellt, dann ist ein Crash vom PC auch ein Crash vom Inhalt des Stores. Die Write-Caches von Controllern sind hingegen autark. Ist halt eine Frage, wem man mehr vertraut: dem Write-Cache vom Controller oder dem ganzen PC mit seinem Betriebssystem. An Stelle von Batterien werden mittlerweise gerne auch Supercap/Flash-Module verwendet. Die Caps halten den Strom so lange aufrecht, bis der Kram aus dem Cache ins Flash gewandert ist. Spart den ärgerlichen Batteriewechsel.
Peter II schrieb: >Ich finde es sinnlos wenn die Kontroller >eine Backup-battrie als Plicht fordern Naja -klapprige Kaltgerätestecker fielen auch bei Erschütterung heraus... -ungünstige Nullpunktverschiebung killt auch mehr Netzteile -Controllerbatterien laufen nach Jahren auch aus Man weiß nie genau was zuerst eintritt.
oszi40 schrieb: > -klapprige Kaltgerätestecker fielen auch bei Erschütterung heraus... aus dem Grund hat man 2 stück > -ungünstige Nullpunktverschiebung killt auch mehr Netzteile aber nicht wenn sie beide an einer andere USV hängen. Bzw. eines an der USV eines am normales netzt. Anders macht es sowieso keinen sinn. > -Controllerbatterien laufen nach Jahren auch aus hatte ich noch nicht. > Man weiß nie genau was zuerst eintritt. das was man am wenigsten erwartet.
Peter II schrieb: > aus dem Grund hat man 2 stück Ich habe schon Server mit 2 Netzteilen gesehen, die per Y-Kabel an einer einzigen Steckdose hingen. ;-)
Arduino schrieb: > Gescheite RAID Controller und Platten überwachen sich selbst und melden > Fehler bzw schalten eine Platte offline, bevor sie ganz aussteigt. Aus dem Bauch raus würde ich sagen, dass grob die Hälfte aller erlebten Plattendefekte in Servern die Platte schlagartig komplett aussteigen liess und sie nicht mehr auf Kommandos reagierte. Nur in der anderen Hälfte wird sie überhaupt noch erkannt und ist einfach nur offline. Auf den Fall, dass mich ein Server (oder ein Storage-System) vor einem drohenden Plattenausfall warnt bevor diese offline geht, warte schon seit geraumer Zeit vergeblich. Die letzten Serverplatte, die mich mit steigender Fehlerrate früh genug an einen Ersatz erinnerte, hatte ich vor ~20 Jahren.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.