Flex-RAID anstatt RAID5?
- Ersteller Unlimited
- Erstellt am
PuckPoltergeist
Grand Admiral Special
Hoho, sachte! Das kommt ganz auf den Anwendungsfall an. In einem Video oder Audio mag das nicht auffallen, aber bei Verschlüsselung hast du mit 1-Bit-Fehlern schon Datenverlust (im schlimmsten Fall alle Daten).
tomturbo
Technische Administration, Dinosaurier
Die "check" Funktion ist scrubbing bei md-raid.
Wenn da ein Datenblock nicht ok ist wird der 1. und/oder der 2. (raid5 oder raid6) Redundanzblock zur Wiederherstellung genommen. Es wird sozusagen ein resync gemacht ohne dass Daten fehlen und die Ergebnisse des resync mit den Paritätsdaten verglichen.
Damit erkennt man Blockdatenfehler und korrigiert sie.
Auch bei Dateichecksums wird "irgend" eine Paritätsinformation zur Wiederherstellung genommen ohne Gewähr dass diese stimmt. Es ist im Prinzip also kein Unterschied vorhanden. Wenn die Wiederherstellungsdaten korrupt sind hilft das in beiden Fällen nicht.
Kaputt ist dann kaputt.
Ich wehre mich nicht prinzipiell gegen Dateichecksum's ich finde sie nur nicht notwendig, weil ja auf Blockebene die Integrität schon sichergestellt wird (einigermaßen).
Das ist sozusagen doppelt gemoppelt und das kostet Performance.
lg
__tom
PuckPoltergeist
Grand Admiral Special
Das geht nicht.
Beispiel RAID1:
Auf einer Platte werden Daten verfälscht, sei es absichtlich oder durch Hard-/Softwarefehler. MD-RAID macht ein Scrubb und stellt fest, dass die Daten nicht synchron sind. Von welcher Platte synct es auf welche? Es kann nicht feststellen, welche Daten die korrekten sind.
Beispiel RAID5:
Die Daten werden auf einem Stripe verändert. Damit stimmt die Checksumme nicht mehr. Wie soll jetzt errechnet werden, welche Daten korrupt sind und neu berechnet werden müssen? Geht nicht, die Daten sind futsch.
Stimmt eben nicht. Die einzelnen Datenblöcke werden zusätzlich zur Redundanz mit einer Checksumme abgesichert. Werden jetzt Daten verfälscht, fällt das auf, weil die Checksumme nicht mehr passt. Dann werden die redundanten Daten genommen, bei denen die Checksumme noch passt. Und sie werden über die fehlerhaften Daten gesynct.
Eben nicht, ZFS macht das (ebenso wie btrfs) nicht auf Datei-, sondern auch auf Blockebene. Aber halt durchgehend, nicht nur für die Metadaten. Und dass MD die Integrität nicht sicher stellt, habe ich gerade ausgeführt.
ghostadmin
Grand Admiral Special
Stimmt, da wär ja Truecrypt ne ganz heisse Sache
tomturbo
Technische Administration, Dinosaurier
Das kann er natürlich schon.
Bei Raid1 ist es zwar Harakiri bei Raid 5 nicht.
Prinzipiell geht man davon aus, dass wenn ein Block gelesen werden kann ist er in Ordnung.
Kann ein Block nicht gelesen werden dann wird der andere zur Wiederherstellung genommen.
Indem die Paritätsinformation neu ausgerechnet und verglichen wird fallen Fehler auf.
Es wird der Datenblock mit dem Ergebnis der Redundanz verglichen kann der Datenblock nicht gelesen werden wird die Redundanz genommen und geschrieben.
Bei Raid 6 ist das natürlich besser weil beide Redundanzen neu ausgerechnet und verglichen werden können. Stimmen beide Redundanzen und der Datenblock nicht wird dort ebenso ausgetauscht.
Die werden sich das ja nicht aus den Fingern gesaugt haben:
http://www.centos.org/docs/5/html/5.4/technical-notes/mdadm.html
Selbst HP's EVA oder die Hardware Raid's von easyRaid machen das so beim scrubben.
lg
__tom
Bei Raid1 ist es zwar Harakiri bei Raid 5 nicht.
Prinzipiell geht man davon aus, dass wenn ein Block gelesen werden kann ist er in Ordnung.
Kann ein Block nicht gelesen werden dann wird der andere zur Wiederherstellung genommen.
Indem die Paritätsinformation neu ausgerechnet und verglichen wird fallen Fehler auf.
Es wird der Datenblock mit dem Ergebnis der Redundanz verglichen kann der Datenblock nicht gelesen werden wird die Redundanz genommen und geschrieben.
Bei Raid 6 ist das natürlich besser weil beide Redundanzen neu ausgerechnet und verglichen werden können. Stimmen beide Redundanzen und der Datenblock nicht wird dort ebenso ausgetauscht.
Die werden sich das ja nicht aus den Fingern gesaugt haben:
http://www.centos.org/docs/5/html/5.4/technical-notes/mdadm.html
Selbst HP's EVA oder die Hardware Raid's von easyRaid machen das so beim scrubben.
lg
__tom
PuckPoltergeist
Grand Admiral Special
Das deckt aber halt nur den Fall des kompletten Ausfalls ab. Silent data corruption wird damit nicht erschlagen. Und genau dafür sind die checksums da. Die sind nicht redundant zum vorhanden RAID, die decken einen weiteren Fehlerfall ab. Wie wichtig die sein können, habe ich bei btrfs selbst schon erlebt. Da hat ein Fehler im Code zu Datenkorruption geführt, was die checksum aufgedeckt hatten. Scrubbing des RAIDs hätte das nicht finden können. Und auch wenn das in diesem Fall dem Entwicklungsstand von btrfs zuzuschreiben war, kann so ein Fehler immer passieren. Das muss nicht das Dateisystem sein, was Schrott baut, das kann so ziemlich alles im Kernel bis hin zur Hardware sein. Und je größer die Datenhalde, desto wahrscheinlicher so ein klitzekleiner Fehler.
Zuletzt bearbeitet:
tomturbo
Technische Administration, Dinosaurier
Klar das Hineinschreiben von korrupten Daten kann scrubbing nicht erkennen.
Da bleibt der Diskblock ja in Ordnung.
Aber beim Hineinschreiben werden doch auch die checksums aktualisiert.
Da nutzt einem doch das vorige vorhanden sein nichts, oder?
lg
__tom
Da bleibt der Diskblock ja in Ordnung.
Aber beim Hineinschreiben werden doch auch die checksums aktualisiert.
Da nutzt einem doch das vorige vorhanden sein nichts, oder?
lg
__tom
PuckPoltergeist
Grand Admiral Special
Es kommt darauf an, an welcher Stelle die Datenkorruption stattfindet. Die Checksummen werden beim rausschreiben der Daten berechnet, ganz zum Schluss. Findet die Datenkorruption schon vorher statt, z.B durch Speicherfehler, bringen Checksummen nix, weil sie auf den fehlerhaften Daten berechnet werden. Werden die Daten hinterher beschädigt, durch den Controller beim Schreiben z.B. oder weil ein fehlerhafter Treiber auf die falsche Stelle der Disk schreibt, stimmen Daten und Checksumme nicht mehr überein. Das wird dann beim Lesen festgestellt und kann behoben werden, sofern Redundanz vorhanden ist.
PS: Wobei die Sicherung der Daten im RAM gar nicht das Ziel von ZFS/btrfs ist. Die Absicherung zielt auf das Storage ab, wo die Daten liegen. Und dafür sind die genutzten Checksummen ein ziemlich gutes Mittel. RAID schützt vor Datenverlust durch Hardwareausfall. Die zusätzlichen Checksummen schützen vor Datenkorruption durch Hard- und Softwarefehler. Der Link von ghostadmin zu Robin Harris zeigt ja auch, dass das Problem nicht nur akademischer Natur ist.
Zuletzt bearbeitet:
tomturbo
Technische Administration, Dinosaurier
Ich kenn das
Ich habe schon einige raid5en beim resync verloren....
Daher laufen bei mir nurmehr Raid6en.
lg
__tom
PuckPoltergeist
Grand Admiral Special
Im Endeffekt hast du ja mit RAID6 auch eine Form der Checksummen-Absicherung. Ist das einigermaßen intelligent implementiert, lässt sich damit feststellen und beheben, welcher Datenblock verfälscht wurde. Ob das md-raid macht, weiß ich jetzt gar nicht. Würde mich aber überraschen. Denn wie gesagt, Neil Brown sieht die Integritätsabsicherung nicht auf der RAID-Ebene.Ich kenn das
Ich habe schon einige raid5en beim resync verloren....
Daher laufen bei mir nurmehr Raid6en.
lg
__tom
PS: Und mit Checksummen hat man die Absicherung der Daten unabhängig vom RAID, und es dürfte auch deutlich effizienter sein.
tomturbo
Technische Administration, Dinosaurier
Das alleine kann's nicht sein, denn die Checksumme alleine weist mich nur auf den Fehler hin aber beseitigt nichts.
Es muss ein Zusammenspiel zw Raid und Filechecksummen sein.
Da kann dann auch ein korruptes file rekonstruiert werden indem auf Paritätsblöcke des Raid zugegriffen wird.
lg
__tom
PuckPoltergeist
Grand Admiral Special
Natürlich, falls das anders rüber gekommen sein sollte, sei das hiermit richtig gestellt. Wie ich schon sagte, die Checksummen sind eine Ergänzung zum RAID. Alleine können sie Fehler nur feststellen, nicht beheben.
Was ich bezüglich der Performance meinte, RAID6 nutzt normalerweise Reed-Solomon für mind. einen Prüfwert. Der erlaubt ja die Rekonstruktion der Daten, ist aber halt auch aufwändiger als CRC, welches für Checksummen zum Einsatz kommt. Deshalb ist man mit CRC und RAID5 (XOR) performanter als mit RAID6, wenn es Datenkorruption geht. Dass die Hauptaufgabe von RAID6 hier gar nicht liegt, sondern auf der Absicherung gegen den zeitgleichen Ausfall von zwei Platten, was wiederum RAID5+CRC nicht liefern kann, sei mal komplett außen vor gelassen.
yourgreatestfear
Grand Admiral Special
Wer kurzfristig unbedingt Checksummen für alle Daten haben will muss wohl auf ZFS oder btrfs setzen, hat dann aber die anderen bekannten Probleme dieser Lösungen (OS-Abhängigkeiten, Unstable Releases, fehlende RAIDlevel oder andere Features, etc.) I.d.R. ist das aber zuviel des Guten, denn ein 0815 md-RAID kann ich verdammt robust gestalten mit WI-Bitmaps und einem sauber konfiguriertem ext4 inkl. dem robusten Journal. RAID zerhauen wegen Controlleraussetzern, Systemausfällen oder sonstigen Schreibfehlern ist da nicht mehr drin, wer das noch hinbekommt hat zu sehr auf Performance gesetzt statt Datenintegritätsfeatures. Selber schuld in dem Falle .
Einzig die silent data corruption treibt einen zu Exoten wie ZFS, unstable btrfs oder der ultimativen Kanone DIX+T10 DIF (damit hat man ausgesorgt ist aber arm). Muss jeder selber wissen, ob man bereit ist die vielfältigen Kompromisse dieser Lösungen hinzunehmen. Realität ist bisher noch, dass Metadaten auch ohne ZFS/btrfs robust genug sind und 98% der sonstigen Anwenderdaten silent data corruption verkraften, weil sie recht fehlertolerant sind.
Um den Bogen zum Topic also zu schließen: FlexRAID hat nix zu bieten, was man nicht schon lange mit den bekannten Lösungen hinbekommt.
PS: Mal sehen wie lang btrfs noch brauch bis zum Stable inklusive der fehlenden wichtigen Funktionen. Böse Zungen behaupten ja das ZFSonLinux bis dahin schon im Kernel ist (stable funzt schon super mit Lustre und derzeitiger RC bietet auch normal mountfähige Pools) bzw. ganz gehässige würden sogar noch md RAID4C / RAID5C eher stable erwarten
.
.Einzig die silent data corruption treibt einen zu Exoten wie ZFS, unstable btrfs oder der ultimativen Kanone DIX+T10 DIF (damit hat man ausgesorgt ist aber arm). Muss jeder selber wissen, ob man bereit ist die vielfältigen Kompromisse dieser Lösungen hinzunehmen. Realität ist bisher noch, dass Metadaten auch ohne ZFS/btrfs robust genug sind und 98% der sonstigen Anwenderdaten silent data corruption verkraften, weil sie recht fehlertolerant sind.
Um den Bogen zum Topic also zu schließen: FlexRAID hat nix zu bieten, was man nicht schon lange mit den bekannten Lösungen hinbekommt.
PS: Mal sehen wie lang btrfs noch brauch bis zum Stable inklusive der fehlenden wichtigen Funktionen. Böse Zungen behaupten ja das ZFSonLinux bis dahin schon im Kernel ist (stable funzt schon super mit Lustre und derzeitiger RC bietet auch normal mountfähige Pools) bzw. ganz gehässige würden sogar noch md RAID4C / RAID5C eher stable erwarten
.
ghostadmin
Grand Admiral Special
Um ein RAID zu zerschiessen, reicht bereits ein Disconnect auf den Disks für ein paar Sekunden.
yourgreatestfear
Grand Admiral Special
Das reicht definitiv nicht bei WI-Bitmaps, dafür ist der Spaß ja da. Und der Rebuild nach einem Disconnect eines LWs dauert auch nur ein paar Sekunden. Selbst mehrfach getestet. Wäre ja auch bescheuert für größere Storagelösungen, wenn solche einfachen Fehler zu so riesigen Problemen führen würden.
Natürlich sollte man eine externe Bitmap nutzen wegen der Performance. Wie gesagt, wenn einem die Daten wichtig sind, sollte man mal die manpages lesen.
Natürlich sollte man eine externe Bitmap nutzen wegen der Performance
. Wie gesagt, wenn einem die Daten wichtig sind, sollte man mal die manpages lesen.
PuckPoltergeist
Grand Admiral Special
Die Bitmaps sind nur dafür da, im Fehlerfall nicht das komplette RAID zu rebuilden. Sie sorgen nicht für Datenintegrität.
yourgreatestfear
Grand Admiral Special
Die verhindern, dass es Dir wie von anderen beschrieben das RAID irreparabel zerschiesst und garantieren dass der Schreibvorgang erfolgreich beendet wurde oder nicht gilt, unbeachtete Schreibfehler (die bei Metadaten schon heftige Auswirkungen haben können) werden verhindert. Wenn das kein Punkt für Datenintegrität ist, dann hat Deinerein eine merkwürdige Vorstellung von dem Begriff.
Der kurze Rebuild im Fehlerfall ist ein gerngesehener Bonus.
Der kurze Rebuild im Fehlerfall ist ein gerngesehener Bonus.
PuckPoltergeist
Grand Admiral Special
Du solltest vielleicht selbe mal lesen (man-pages, Code etc.). Die bitmaps tracken auch nur, welche Blöcke out-of-sync sind. Sie vermeiden ein scrubb damit aber sie können nicht sagen, welcher Block der korrekte ist.
yourgreatestfear
Grand Admiral Special
close, but no
Was nicht durch die Bitmap wieder unflagged wird nach dem Schreiben, wird verworfen anstatt das ein Algorithmus versucht was draus zu machen. Ohne Bitmap versucht der Rebuild sich aus dem Datensalat einen Reim zu machen und er versucht nach bestem Wissen wieder etwas zusammenzukleben bis es wieder im sync ist. Mit Bitmap ist dem Rebuild klar was korrekte bzw. was fehlerhafte Blöcke sind und handelt entsprechend korrekt. >> Folge ist eine höhere Datenintegrität
Ich kenne den Unterschied vor allem bei Bilddatenbanken aus der Praxis. Da produziert ein Rebuild ohne Bitmaps durchaus Bildfehler/Artefakte, die mit einer Bitmap nicht entstehen nach einem Rebuild.
Was nicht durch die Bitmap wieder unflagged wird nach dem Schreiben, wird verworfen anstatt das ein Algorithmus versucht was draus zu machen. Ohne Bitmap versucht der Rebuild sich aus dem Datensalat einen Reim zu machen und er versucht nach bestem Wissen wieder etwas zusammenzukleben bis es wieder im sync ist. Mit Bitmap ist dem Rebuild klar was korrekte bzw. was fehlerhafte Blöcke sind und handelt entsprechend korrekt. >> Folge ist eine höhere Datenintegrität
Ich kenne den Unterschied vor allem bei Bilddatenbanken aus der Praxis. Da produziert ein Rebuild ohne Bitmaps durchaus Bildfehler/Artefakte, die mit einer Bitmap nicht entstehen nach einem Rebuild.
PuckPoltergeist
Grand Admiral Special
Das hilft dir nur, wenn der Schreibvorgang für mdraid sichtbar fehlschlägt. Wird das Zeug rausgeschrieben und der Controller baut Mist, sieht das mdraid nicht, ebenso wenig wenn die Daten nachträglich verändert werden.
PS: Oder um es anders zu sagen, bitmaps sorgen für die Konsistenz des RAID, nicht für Datenintegrität der darauf gespeicherten Daten.
Zuletzt bearbeitet:
yourgreatestfear
Grand Admiral Special
Natürlich gibt es kein Allheilmittel, was aber nicht bedeutet das eine Bitmap nicht zu deutlich höherer Robustheit des Arrays führt und der Datenintegrität dient. Was ja der Punkt in der Argumentation hier sein sollte.
Dein beschriebener Fehler würde Dir auch falsche Checksums bescheren, btrfs Metadaten etc. zerhauen können und irreparable Schäden in jeder Art von Array verursachen. Verstehe also nicht, was Dein Problem ist.
@PS: Keine Ahnung an welcher Hochschule Deinerein studiert hat und welche Erklärung zur Datenintegrität Dir da vermittelt wurde. Aber wenn der Rebuild weiss, was fehlerhafte Blöcke sind, anstatt sich das anhand von Algorithmen aus den Fingern zu saugen, dann garantiert das sehr wohl eine höhere Datenintegrität.
Dein beschriebener Fehler würde Dir auch falsche Checksums bescheren, btrfs Metadaten etc. zerhauen können und irreparable Schäden in jeder Art von Array verursachen. Verstehe also nicht, was Dein Problem ist.
@PS: Keine Ahnung an welcher Hochschule Deinerein studiert hat und welche Erklärung zur Datenintegrität Dir da vermittelt wurde. Aber wenn der Rebuild weiss, was fehlerhafte Blöcke sind, anstatt sich das anhand von Algorithmen aus den Fingern zu saugen, dann garantiert das sehr wohl eine höhere Datenintegrität.
Zuletzt bearbeitet:
PuckPoltergeist
Grand Admiral Special
Die von mir beschriebenen Fehler würde zu falschen Checksummen führen. Dann weiß man, dass die Daten falsch sind oder im Idealfall werden sie aus der Redundanz einfach korrigiert. Hab ich alles oben schon mal geschrieben.
yourgreatestfear
Grand Admiral Special
Deine Korrektur, die auf die unpassende Checksum erfolgt ist aber das Problem. Denn die würde wieder nicht wissen, welche Blöcke die fehlerhaften sind, sondern dies nur errechnen. Wer Bitarithmetik versteht, der weiss was für Müll da raus kommen kann.
Um es mal abzukürzen an der Stelle: Ja, Checksum sind ne tolle Sache, nicht umsonst wird an allen Ecken daraufhinentwickelt. Das macht ein Bitmap aber nicht überflüssig, sondern erweitert die Integrität nur weiter. Streitsucht hilft echt nicht weiter.
Um es mal abzukürzen an der Stelle: Ja, Checksum sind ne tolle Sache, nicht umsonst wird an allen Ecken daraufhinentwickelt. Das macht ein Bitmap aber nicht überflüssig, sondern erweitert die Integrität nur weiter. Streitsucht hilft echt nicht weiter.
Zuletzt bearbeitet:
PuckPoltergeist
Grand Admiral Special
Alle die, wo die errechneten Checksummen nicht zu den gespeicherten passen. Und nein, bitmaps haben damit nichts zu tun.
ghostadmin
Grand Admiral Special
Das reicht definitiv nicht bei WI-Bitmaps, dafür ist der Spaß ja da. Und der Rebuild nach einem Disconnect eines LWs dauert auch nur ein paar Sekunden. Selbst mehrfach getestet. Wäre ja auch bescheuert für größere Storagelösungen, wenn solche einfachen Fehler zu so riesigen Problemen führen würden.
Natürlich sollte man eine externe Bitmap nutzen wegen der Performance
Dann probiers einfach aus
Es war Fibrechannel und auf dem Switch war der Link kurze Zeit weg. Auf dem Disks war ein VMFS auf welchem VMs mit NTFS abgelegt waren und die waren nach ein paar Tagen alle komplett Platt. Das war der Grund warum dann auf NFS umgerüstet wurde, da ist der Link nicht ganz so kritisch.
Und das war ne EMC Storage mit Brocade Switch und Dell Server, also nix billiges.
