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.
...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.
