RAID6 vs. RAIDZ2 - Vorteile/Nachteile

[Dwayne_Johnson]

Was sind die Vor- und Nachteile von RAID6 und RAIDZ2?

 

[Holt]

Wie soll man das so pauschal beantworten? Ein RAID 6 kann mit jedem Filesystem kombiniert werden und i.d.R. kann man weitere Platten voll itegrieren. ZFS vereint RAID und Filesystem, bietet auch Featurtes wie z.B. Prüfsummen und Snapshots, aber kein Recoverytool und man kann weitere Platten nur wie bei einem JBOD anhängen, aber nicht voll ins RAID integrieren.

 

[Dwayne_Johnson]

Schade, dass es bei gewöhnlichem RAID keine Checksummenbildung gibt.

 

[Holt]

Nutze ECC RAM (mit dem passenden System), dann ist das Risiko von Silent-Data-Corruption schon wirklich minimal.

 

[Dwayne_Johnson]

Mein Areca hat auch ECC-Ram - kann nicht verkehrt sein

Wie muss ich mir das bei RAIDZ vorstellen? Wird da eine Liste mit Checksummen für jede Datei abgelegt?

 

[Holt]

Das der RAID Controller ECC-RAM hat ist ja schön und gut, es soll eben eine Datenkorruption im Cache RAM verhindern, aber danach landen die Daten im Hauptspeicher bzw. sie kommen vorher daher und daher muss auch der Hauptspeicher des Rechner ECC-RAM sein und der Rechner das natürlich unterstützen. Sonst brauchst Du Dir über Datenkorruption und Prüfsummen keine Gedanken zu machen und ZFS würde ich ohne ECC RAM gar nicht erst in Erwägung ziehen.

 

[Jo2x253]

Nutze ECC RAM (mit dem passenden System), dann ist das Risiko von Silent-Data-Corruption schon wirklich minimal.

Müßte dann bei Raid6 auf "zwei" Platten im gleichen Bereich (Byte bzw. in einem Zugriff gelesenem Bereich) jeweils min. 1 Bit kippen?

 

[Holt]

Bei Platten kippen Bits allenfalls auf den internen Datenpfaden, da haben nur Enterpriseplatten einen Schutz davor. Hinter jedem physikalischen Sektor steht ja eine ECC und wenn die Daten nicht zur ECC passen und die Fehler auch korrigiert werden können, dann gibt die Platte einen Lesefehler aber keine inkorrekten Daten aus und hat dann einen schwebenden Sektor, was bei 1:10^14 oder 1:10^15 gelesen Bits mal passieren kann. Unerkannte Fehler, wo also falsche Daten doch zur ECC passen, sind noch mal um mindestens diese Größenordnung unwahrscheinlicher.

Die Übertragung ist bei SATA pro FIS (mit maximal 8192 Byte Nutzdaten) mit einer CRC32 gesichert, da wird statisch erst bei mehr also 10^40 fehlerhaften Übertragungen ein Fehler nicht erkannt, was einem Datenvolumen entspricht, welches weit über der Kapazität aller je gebauen HDDs liegt. Da kommt es also auch nie ein Fehler unerkannt durch, zumal man bei Übertragungsfehlern ja den Performanceeinbruch wegen der Wiederholungen der Übertragungen bemerkt und diese auch anhand der S.M.A.R.T. Werte erkennt und beheben sollte, in aller Regel ist es ja ein Problem des SATA Datenkabels.

Es bleibt als die FW der Platte oder des Host Controllers als möglichliche Fehlerursache bei der Prüfsummen wie bei ZFS helfen können, aber RAM Fehler können immer zuschlagen wenn man kein ECC-RAM hat, auch schon bevor das Filesystem die Daten erstmalig liest und dann hat man schon korrupte Daten mit einer dazu passenden Prüfsumme und merkt es erst, wenn diese wieder eingelesen werden, weil sie Prüfsumme ja zu den schon falschen Daten passt. Außerdem können Bitfehler wenn die Metadaten betroffen werden, jedes Filesystem korrupt machen, da sollte man sich nichts vormachen. Aber wenn man ein Filesystem mit Prüfsummen und Fehlerkorrektur nimmt, kommt noch ein Problem hinzu: Diese Filsesysteme sind für Server-HW und Petabyte Storages entwickelt, setzen als ECC-RAM vorraus und gehen bei jedem Inkonsistanz von einem Fehler der Platten aus, korrigieren die Daten dann also entsprechend, nur wenn es ein RAM Fehler war der die Inkonsistanz bewirkt hat, werden die Daten kaputtkorrigiert!

Bei einem normalen md-RAID passiert das nicht, da das RAID vom Filesystem keine Ahnung hat und es prüft auch nicht einmal beim Lesen anhand der Parity ob die Daten korrekt sind, was die Performance verbessert. Die Parity brauchen und nutzen sie nur, wenn eine Platte beim Lesen einen Lesefehler statt der Daten liefert und beim Scrubbing. Stimmt dann aber was nicht, z.B. wegen eines RAM Fehlers, dann wird nur die Parity angepasst, also in dem Fall dann korrumpiert und nur wenn dann in dem Bereich ein Platten einen Lesefehler bekommt, dann werden auch deswegen die Daten korrupt, sonst bleibt das ohne Folgen und wenn beim nächsten Srubbing kein RAM Fehler auftritt, wird die Parity wieder korrigiert. Das Riaiko ist da also geringer aufgrund von RAM Fehlern korrupte Daten zu bekommen.

 

[Dwayne_Johnson]

Würde es reichen, wenn ich neben dem Areca ein MB mit ECC-RAM nutze oder brauche ich zusätzlich noch das richtige OS bzw. Filesystem?

Und kann trotz ECC-RAM ein billiges MB richtige Daten vom ECC-RAM falsch zum Controller weiterleiten? Oder sollten alle ECC-fähigen MBs fehlerfrei arbeiten?

 

[Holt]

Nur ECC RAM Riegel einzubauen bringt gar nichts, die sind ja auch nicht anderes als normale Riegel, nur haben die eben 72 Bit (9/18 Chips) statt 64 Bit (8/16 Chip) Datenbreite. Um die ECC-RAM Funktion zu haben, müssen neben dem ECC-RAM auch das Board und die CPU (dort sitzt ja heutzutage der RAM-Controller) dies unterstützen. Wenn das OS es auch unterstützt, kann man zusätzlich die Anzahl der erkannten Fehler auslesen und auf die nicht korrigierbaren Fehler reagieren. Bei kritischen Servern löst man dann i.d.R. eine Kernel Panik aus um zu verhindern das aufgrund der RAM Fehler falsche Ergebnise ausgegeben werden.

 

[gea]

Was sind die Vor- und Nachteile von RAID6 und RAIDZ2?

Da man auch ZFS auch mit Raid-6 machen könnte, will ich kurz auf die Vorteile eingehen, die sich bei Raid mit ZFS ergeben

Der wichtigste Unterschied liegt zunächst nicht im Raid sondern im Dateisystem.
Bei Raid-6 kann man beliebige Dateisysteme nehmen, ZFS inclusive. Das ist aber da wenig sinnnvoll da dann die Reparatur defekter Daten bei Prüfsummenfehlern nicht mehr möglich ist.


Der wichtigste Vorteil von ZFS ist aber das CopyOnWrite Dateisystem.
Dadurch werden bei Änderungen alle Datenblöcke neu erstellt. Passiert dabei etwas (Stromausfall) bleibt der alte Stand aktiv. Es gibt daher von der Konzeption des Dateisystems kein korruptes Dateisystem und daher auch kein "Reparaturtool" wie fschk wie bei älteren Dateisystemen. Wobei das ja lustig ist. Da die keine Prüfsummen haben, gibt es keine echte Reparatur mangels Kenntnis ob Daten korrupt sind oder nicht. Da werden keine Daten repariert sondern lediglich die Dateisystruktur untersucht.

Dies hat bei Raid die Auswirkung. dass es kein Write-Hole-Problem gibt. Ein ZFS Raid Stripe (oder mirrorblock bei einem Spiegelsatz) wird entweder komplett auf das Raid (= alle Platten) geschrieben oder die Änderung wird verworfen. Damit auch kein korruptes Dateisystem oder inkonsistentes Raid bei Stromausfall. ( "Write hole" phenomenon in RAID5, RAID6, RAID1, and other arrays. ) wie bei einem normalen Mirror oder Raid 5/6.

Schöner Nebeneffekt von CopyOnWrite sind die Snapshots (Dateiversionierung). Da wird nach Änderungen der alte Dateistand nicht zum Überschreiben eingefroren sondern geschützt.


Der zweite Vorteil sind die Prüfsummen die man bei ZFS jedem Datenblock oder Metadatensatz geben kann. Damit lssen sich die Daten auf der Platte überprüfen und bei Änderungen (Silent Data errors, Datenrost) aus dem ZFS Raid reparieren (ZFS Scrubbing). Ohne ZFS Raid, also z.B. ZFS auf Raid-6 wird der Fehler nur erkannt kann aber nicht repariert werden da ZFS da keinen Zugriff auf die einzelnen Platten hat.

Ansonsten sind die Unterschiede zwischen Raid-6 und Z2 gering.
Manche Raid-6 Systeme erlauben das Erweitern des Raid-6 Arrays um einzelne Platten. Das ist bei ZFS nicht vorgesehen. Da erweitert man den Pool normalerweise komplett um weitere Raid-Arrays. (Der Heimwunsch von 4 auf 5 Platten war bei Sun nicht im Pflichtenheft, eher von 6 auf 12 Platten und wie komme ich auf mehrere Petabyte)


ECC hat damit zunächst nichts zu tun.
ECC Speicherfehler können immer zu Datenverlust führen. ECC ist daher immer sinnvoll. Die Häufigkeit der Probleme ist aber gering und steigt mit der Menge an RAM.

Die Betonung von ECC bei ZFS liegt entweder daran, dass da man da sovel Sicherheitsaspekte eingebaut hat, dass man auch ECC nehmen sollte um das nicht auszuhebeln. Oft dient das Argument aber eher dazu, einen vermeintlichen Vorteil in der Art von "bei ext4/ntfs braucht man im Gegensatz zu ZFS kein ECC...." zu suggerieren. Ist natürlich Unfug. Entweder man will sicheren RAM oder man nicht das Restrisiko genauso in Kauf wie bei anderen Komponenten die nicht dem höchsten professionellen Niveau entsprechen.

 

[Holt]

Durch RAM Fehler kann aber auch ZFS korrupt werden und dann fehlt das fschk eben doch, meist fällt es aber eben erst auf, wenn der Pool hin ist, aber RAIDs ersetzen ja bekanntlich keine Backups! Matt Ahren, Mitentwickler des ZFS-Dateisystems, schreibt:

I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.

Man beachte die Reihenfolge, zuerst empfiehlt er ECC RAM und dann erst oben drauf ein Filesystem mit Prüfsummen wie ZFS zu verwenden, wenn man seine Daten liebt und vor Korruption schützen möchte!

 

[Dwayne_Johnson]

Dass man ZFS nicht um einzelne HDDs erweitern kann ist schade, aber nicht zu ändern.
Ich nehme an, dass man auch keine Stripesize "online" ändern kann - also ohne Datenverlust und vollen Zugriff auf alle Daten während die Änderung geschrieben wird.
Ok, nachträglich die Stripesize ändern macht man natürlich recht selten. Und wenn man weiß, was für Daten benutzt werden, dann weiß man die Stripesize schon beim erstellen des Arrays.

Aber ein Array um einzelne HDDs erweitern bräuchte ich schon.


Btw:
Fasst mal bitte kurz zusammen, was ich alles für ein ideales ZFS-Array bräuchte (Hardware, software)
Kann man die günstigsten "reg" ECC-RAMs + das günstigste ECC-fähige MB nehmen oder was würdet ihr nehmen?

 

[Holt]

Für einen Storage Server würde ich niemals auf ECC-RAM verzichten und bei ZFS schon gar nicht. Dann braucht man bei Linux md-SW-RAID oder ZFS auch keinen HW-RAID Controller, ein HBA reicht, denn das RAID wird ja in beiden Fällen durch SW realisiert und fast jede halbwegs aktuelle x86er CPU ist ungleich performanter als CPU Kerne der RAID Controller, schau Dir mal an was da i.d.R. für Kerne drin stecken und mit welchem Takt die laufen.

Registered (reg) ECC RAm läuft nur auf besseren Plattformen, bei Intel z.B. bei den Xeon E5 des großen Sockels 2011(-3), aber nicht auf den kleinen S. 155x Xeon E3 und bringt nur den Vorteil damit größere RAM Ausbauten realisieren zu können. Wenn Du günstiges reg ECC RAM nehmen willst, prüfe also vorher ob die Plattform dieses auch wirklich unterstützt!