Raid5 + ECC RAM - Welche spezifischen Vorteile?

[MopedTobias]

Hallo zusammen,

da ich kürzlich einen kleinen Schockmoment bei meinem Heimserver hatte, hab ich mich nebenläufig wieder mit aktuellen Beiträgen zum Thema Raid5 befasst. Nun hat mein Heimserver ein Software-basiertes Raid5 und nutzt ECC RAM. Seinerzeit hab ich beim Kauf drauf geachtet, dass das BIOS/CPU ECC RAM unterstützt, weil der Preis für ECC einfach kaum höher war als bei normalem RAM und es weitläufig für RAID Systeme empfohlen wurde. Schließlich haben auch alle echten Hardware-Raid Controller ECC RAM.

So weit so gut. ECC RAM ist in Bezug auf Zuverlässigkeit in jedem Fall die bessere Wahl. Unabhängig von RAID-Gedöns. Nur, welchen spezifischen Vorteil hat ECC RAM nun genau für RAID 5, denn er nicht auch für I/O-Operationen auf einzelnen Datenträgern hätte?

Beispiel: Habe ich normalen RAM und Speicherfehler, dann ist bei einfachen Datenträgern, wie beim Raid5 eine oder mehrere Dateien futsch.

Ich hoffe ich konnte meine Frage deutlich formulieren.

Regards
MT

 

[_killy_]

afaik: ECC-RAM bemerkt Fehler bei Berechnungen. Daten werden aber nicht über den Umweg über den RAM gespeichert. Somit hat ECC-RAM keine Auswirkung auf die Speicherung der Daten.

ok?

 

[misu]

ECC Ram bringt dir überhaupt nichts. ECC Ram hilft bestimmte Speicherfehler zu erkennen und korrigieren. Da aber die Fehlerrate von normalen Speicher schon sehr gering ist, lohnt sich das ganze nur, wenn man viele Rechner hat (z.b. Rechenzentrum) oder extreme Anforderungen an die Zuverlässigkeit hat (Geschäftsgeheimnisse etc.).

Für dein Raid 5 daheim hat das ganze auch überhaupt keine Vorteil (jenseits der generell geringeren, wenn auch irrelevanten, Fehlerrate), weil es damit einfach überhaupt nichts zu tun hat.

Nachtrag: In deinem Beispiel ist die Datei futsch, ja. Das gleiche kann übrigens auch bei ECC-Speicher passieren, ist nur deutlich weniger wahrscheinlich. In der Regel wird der Fehler aber nur ein paar bits eines Files betreffen, was häufig nicht besonderes schlimm ist. Das Raid hilft erst, wenn die Daten korrekt geschrieben wurden, und dann eine der Platten ausfällt.

 

[Holt]

ECC Ram bringt dir überhaupt nichts. ECC Ram hilft bestimmte Speicherfehler zu erkennen und korrigieren. Da aber die Fehlerrate von normalen Speicher schon sehr gering ist, lohnt sich das ganze nur

So gering wie manche hier immer unterstellen ist die Fehlerrate bei RAM nicht. Wenn das RAM aber fehlerfrei arbeitet, dann bringt ECC in der Tat keine Vorteil, aber es erkennt Fehler im RAM eben sofort.

Wer sein RAM nach dem Erhalt des Rechners oder nach dem Zusammenbau und nach jeder Änderung des RAMs oder von dessen Einstellungen gründlich mit memtest86 testet und keine Fehler findet, der kann hoffen, dass es auch im Alltag i.d.R. fehlerfrei funktioniert. Den memtest zuweilen zu wiederholen, vor allem wenn plötzlich fehlerhafte Dateien auftauchen, kann auch nicht schaden.

Für dein Raid 5 daheim hat das ganze auch überhaupt keine Vorteil (jenseits der generell geringeren, wenn auch irrelevanten, Fehlerrate), weil es damit einfach überhaupt nichts zu tun hat.

Ein RAID 5 erhöht vor allem die Verfügbarkeit, aber auch nur, wenn man dessen Zustand regelmäßig überwacht und defekte Platten umgehend ersetzt. Ein Backup ersetzt es aber niemals.

 

[Bolko]

Nachtrag: In deinem Beispiel ist die Datei futsch, ja. Das gleiche kann übrigens auch bei ECC-Speicher passieren, ist nur deutlich weniger wahrscheinlich. In der Regel wird der Fehler aber nur ein paar bits eines Files betreffen, was häufig nicht besonderes schlimm ist.

Wenn diese Datei aber nun ein TrueCrypt-Container ist, dann ist eventuell alles in diesem Container zerstört.
1 einziges falsches Bit kann den Verlust von tausenden Dateien verursachen.

 

[misu]

Erstens, ein Raid ersetzt niemals ein Backup, wie Holt schon erwähnt hat. Man denke an so Dinge wie Blitzschlag, defektes Netzteil, Cola verschüttet...
Zweitens kann man seinen Truecrypt-Header separat sichern, womit ausgeschlossen sein sollte, dass der von dir geschilderte Fall Eintritt. An dieses Problem haben die Macher von Truecrypt tatsächlich gedacht.

 

[rindfisch]

ein software raid 5 ist aber auch nur SEHR bedingt zu empfehlen, dein cpu muss die ganze zeit die berechnung der paritätsdaten übernehmen....das macht ein roc (raid on chip) deutlich besser und WESENTLICH energie effizienter und schneller und sicherer....evtl bei raid 5 mal drüber nachdenken einen hardware controler zu holen - super dinger bekommst du ab 130€ (lsi 9260 als ibm oem)

 

[misu]

Stimmt nicht, die Paritätsdaten sind bloß XORs. Das macht jeder Rechner mit extrem hoher Effizienz, da würde wahrscheinlich höchstens der Speichercontroller limitieren. Zum Vergleich, man kann schon seit Jahren von praktisch spürbaren Geschwindigkeitsverlust mittels Truecrypt in Software alle Daten verschlüsseln. Das ist um Größenordnungen aufwendiger wie das Raid 5.
Zudem wacht die CPU auch nur auf, wenn tatsächlich Daten geschrieben werde. Bei einem Heimserver wird wohl kaum viel geschrieben (der TE korrigiere mit ggf.), weswegen die CPU wahrscheinlich eh fast immer schläft.

 

[Holt]

Zudem wacht die CPU auch nur auf, wenn tatsächlich Daten geschrieben werde. ...weswegen die CPU wahrscheinlich eh fast immer schläft.

Und beim Lesen werden die XOR Berechnungen nicht gebraucht? Dann könnte das RAID Fehler nicht mehr erkennen, die Berechnungen sind also sowohl beim Lesen wie beim Schreiben nötig.

 

[Ernst@at]

ein software raid 5 ist aber auch nur SEHR bedingt zu empfehlen, dein cpu muss die ganze zeit die berechnung der paritätsdaten übernehmen....

Ach die armen CPUs! Alle, die derart argumentieren, sollten mal zur Strafe ausrechnen müssen, wieviele Millisekunden ein Achtkerner zur Paritätsberechnung von 4x4TB braucht, wofür das Schreiben der zugehörigen Daten auf die Platten dann 7-8 Stunden dauert...

Und beim Lesen werden die XOR Berechnungen nicht gebraucht? Dann könnte das RAID Fehler nicht mehr erkennen, die Berechnungen sind also sowohl beim Lesen wie beim Schreiben nötig.

Nein, beim Lesen im Normalbetrieb braucht das kein Schwein, bloss wenn ein Drive ausgefallen ist.

 

[misu]

@Holt: Das ist völlig uninteressant, weil man erst bei Gigabytes an Daten pro Sekunde auch nur in die Nähe von CPU Auslastung kommt. Das ist nicht viel mehr als eine XOR Instruktion pro Datenwort (was auch der Grund ist, wieso es von der Speicherbandbreite abhängt, wovon wir aber in der Regel um die 10Gb/s haben).

@Ernst@at:
Da bin ich mir jetzt unsicher, ich dachte er berechnet immer, damit er die Fehler überhaupt erkennen kann.

 

[Ernst@at]

"Assumption is the mother of all fuckups"

Warum sollte beim Lesen die Parity geprüft werden?
Beim Initialisieren des Arrays wird die Parity berechnet und draufgeschrieben, bei jeder schreibenden Änderung wird sie aktualisiert. Daher ist das RAID5 in jedem Moment seines Lebens konsistent.

Einzig nach einem Strom/Systemausfall muss eine Überprüfung und eventuelle Richtigstellung vorgenommen werden, da hier nicht alle Schreiboperationen ordnungsgemäß beendet worden sein könnten (was auch die einzige Rechtfertigung der Verwendung einer BBU ist, um sich das zu ersparen). Danach ist das RAID5 wieder konsistent, die Daten müssen es aber nicht sein.

Solange die Originaldaten richtig gelesen werden können, besteht also kein Grund, da was überprüfen zu müssen.
Tritt jedoch ein Lesefehler auf, wird erst dann durch Lesen aller anderen Stripes dieses Sets der Inhalt auf diesem Umweg rekonstruiert; gleiches passiert auch, wenn sich die Platte, auf der die gewünschten Daten im Original abgespeichert sind, nicht mehr im Verband befindet(bei onboard Controllern wird sie beim ersten Lesefehler rausgeschmissen und ein komplettes Rebuild eingeläutet, anstatt den errechneten Inhalt wieder draufzuschreiben und so ein realloc zu forcieren).

 

[misu]

Muss mich korrigieren. Es steht auch im Wikipedia, dass die Paritätsinformation nur bei Fehlern verwendet wird, was aus Performancegründen auch absolut sinnvoll ist.
Also beim Lesen (fast) null Overhead beim Software-Raid.