Forums Neueste Beiträge
 

RAID5 und non-volatile cache

11/07/2011 - 10:24 von Karl Weber | Report spam
Hallo zusammen,

ich habe im Heise-Forum einen Thread [1] verfolgt, in dem dringend vom
md-RAID5 abgeraten wird, weil ein non-volatile cache fehlt.
Das hat mich etwas nachdenklich gemacht, leider spuckt Google dazu wenig
bis gar nichts aus.
Lediglich [2] behauptet "Software Raid in Linux, via mdadm, also offer
[...] Bitmap Caching (similar to having battery backed up cache)."
Leider finde ich auch dazu wenig bis gar nichts - lediglich einen
anderen Post, der wiederum dieses Zitat als Referenz angibt.

Was ist nun dran, drin und überhaupt? Die ECC-Problematik betrifft mich
nicht so sehr, ich hatte sowieso an einen stàrkeren Prozessor gedacht,
um AES-NI zu haben und würde dann ggf. wohl einen Xeon E3-1220L wàhlen.

Grüße
Karl



[1]
http://www.heise.de/newsticker/fore...5534/read/
[2] http://bfish.xaedalus.net/2006/11/s...ith-mdadm/
 

Lesen sie die antworten

#1 Marcus Jodorf
11/07/2011 - 18:01 | Warnen spam
Karl Weber schrieb:

ich habe im Heise-Forum einen Thread [1] verfolgt, in dem dringend vom
md-RAID5 abgeraten wird, weil ein non-volatile cache fehlt.



Das ist so pauschal gesagt Quatsch. Genauso könnte man sagen, der
Nachteil von Hardwareraidcontrollern mit battery backed up cache ist
ebendieser Cache - nàmlich in dem Falle, daß die Kiste gecrashed ist
und der Controller getauscht werden muß. Dann rupft man die letzten
Daten gleich mit dem Controller aus dem Rechner und dafür, daß die da
noch unerreichbar im RAM stecken, kann man sich ein Eis backen.
Oder einfach Stromausfall und die Cache Batterie macht schlapp
- dann hat man das selbe Problem.

Das hat mich etwas nachdenklich gemacht, leider spuckt Google dazu
wenig bis gar nichts aus. Lediglich [2] behauptet "Software Raid in
Linux, via mdadm, also offer [...] Bitmap Caching (similar to having
battery backed up cache)."



Du kannst unter Linux einen Bitmap Cache anknipsen. Das als
battery backed up Cacheersatz zu bezeichnen ist alledings leicht
euphemistisch, um nicht zu sagen wirr. Es cached nicht die Daten.
Das sorgt im Grunde nur dafür, daß nach einem Powerfehler (oder
Systemabflug) nicht das ganze Raid ein Resync/check durchlaufen muß,
sondern nur der Teil, der seit dem letzten vermerkten clean state
in Arbeit war.

Es spart also nur nach einem Crash resync-Zeit und es erlaubt das
kurzzeitige Entfernen und Wiedereinsetzen eines Laufwerks, ohne daß das
zwangsweise einen kompletten Rebuild von vorne bis hinten durchlaufen
muß.
Bedeutet z.B.: Du drückst versehentlich den Auswurfknopf der falschen
Platte, bemerkst den Fehler und drückst sie sofort wieder rein und dann
spart Dir das 20 Stunden Komplettresync mit glühenden Platten.

Stell es Dir ungefàhr wie ein Metadaten Journal eines Filesystems vor.
Das sorgt letztlich auch nur für ein konsistentes Filesystem und spart
stundenlangen fsck aber sorgt nicht dafür, daß die zuletzt geschriebenen
Daten auch wirklich auf der Platte sind (was sie meist nicht sind).

Da der Zugewinn an Datensicherheit daher überschaubar ist aber es
Performance kostet, hat man write intent bitmaps normal eher
ausgeknipst und schaltet sie eher nur bedarfsweise zu. Beispielsweise
wenn man ein Raid erweitert oder logisch umbaut.

Was ist nun dran, drin und überhaupt? Die ECC-Problematik betrifft mich
nicht so sehr, ich hatte sowieso an einen stàrkeren Prozessor gedacht,
um AES-NI zu haben und würde dann ggf. wohl einen Xeon E3-1220L wàhlen.



Soft- und Hardwareraid haben beide ihre spezifischen Vor- und Nachteile.
Von daher ist das eher erst mal eine prinzipielle Entscheidung.
Softwareraid fehlt etwa ein battery backed up cache. Gute Raidcontroller
haben zwar sowas aber sind dafür selber ein single point of failure, so
daß man sich dann normal auch immer Ersatzcontroller als spare
bereitlegen muß.
Der Hauptvorteil ist aber: Geht was schief und die Daten sind futsch,
kann man die Schuld auf den Controllerhersteller schieben.

Weitgehend entschàrfen kann man die Problematik eines Cache ohne battery
back up auch einfach, indem man das quasi nachrüstet - sprich man benutzt
eine gute USV. Damit hat man dann wenn man so will ein battery back up
für den Cache bei Softwareraid, nàmlich das gesamte RAM der Maschine.

Bei einem einigermaßen wichtigen Produktivstem brauchst Du ohnehin eine
USV und da nivelliert sich diese spezielle Problematik mit dem Cache in
weiten Teilen ganz von selbst.


Gruß,

Marcus

Ähnliche fragen