RAID Hardware oder Software
- Thread starter andrej75
- Start date
Musst du Vorteile/Nachteile von Software vs Hardware Raid für deinen Anwendungsfall abwägen. Und ob du ZFS Features wie Snapshots, Replikation, Bit Rot Protection, Blocklevel Kompression etc brauchst.
Außerdem nicht vergessen, dass man ZFS am besten nur mit Raid Controllern benutzt, wo sich das Raid komplett deaktivieren lässt, was nicht bei allen Controllern der Fall ist (und kA wie es bei deinem Modell ist). Siehe hier:
https://openzfs.github.io/openzfs-docs/Performance and Tuning/Hardware.html#hardware-raid-controllers
Außerdem nicht vergessen, dass man ZFS am besten nur mit Raid Controllern benutzt, wo sich das Raid komplett deaktivieren lässt, was nicht bei allen Controllern der Fall ist (und kA wie es bei deinem Modell ist). Siehe hier:
https://openzfs.github.io/openzfs-docs/Performance and Tuning/Hardware.html#hardware-raid-controllers
Last edited:
Tri-Mode ist ja ganz nett, aber der 9440 hat keinen Flash Backed Write Cache?? Ohne den ist das Controller-RAID nicht garantiert konsistent.
Und was nützt das, wenn das OS an der Stelle schon tot ist?
Ein Controller mit FBWC übernimmt die Daten vom OS und meldet sofort Erfolg. Dann schreibt er die Daten auf die Member des RAIDs, und erst wenn die alle Erfolg gemeldet haben (Daten im Write Cache bei SSDs mit PLP, sonst tatsächlich geschrieben) wird der Cache-Eintrag wieder gelöscht. Damit bleiben die Daten im Cache und werden ins Flash geschrieben, falls der Strom ausfällt während noch nicht alle bestätigt haben. Wenn der Strom dann wieder da ist, wird der Schreibvorgang automatisch fortgesetzt, damit sind die Laufwerke wieder konsistent - das Array als Ganzes ist immer konsistent, solange nicht der Controller selbst abraucht, während noch Daten drin sind.
Wenn Du keinen gepufferten Schreibcache hast und Dir nach dem Schreiben auf einen Teil der RAID-Member der Saft ausgeht, hast Du nach dem Wiedereinschalten ein inkonsistentes RAID, weil der Controller nicht mehr weiß, was er auf die übrigen Laufwerke schreiben wollte. PLP auf den einzelnen Laufwerken nützt Dir dabei nur insofern was, daß das "data in transit"-Zeitfenster verkürzt wird, kann aber keine Daten retten, die auf diesem Laufwerk noch gar nicht angekommen sind.
Deswegen sollte man Hardware-RAID immer nur mit gepuffertem Schreibcache verwenden. Sonst kann man auch gleich Softraid nehmen.
zfs behilft sich, indem es die Daten einfach mehrmals schreibt, aber double-buffering belastet die SSD und die Performance.
Genau das was du beschreibst soll ein Controller ja verhindern. Ich arbeite seit mehr als 20 Jahren mit RAID Controllern und inkonsistente Daten gab es nur wenn HDDs schleichend kaputt gegangen sind und Daten nicht mehr lesbar sind.
Auch wenn eine oder mehrere Komponenten kaputt gehen, stört das nicht, weil ein Write nur abgeschlossen ist wenn alle Disks OK sagen oder der BatterieCache. Deshalb darf man auch nie den Cache auf den Disks aktivieren. Das ist immer tödlich, auch bei ZFS.
Der BatterieCache ist aber immer zu empfehlen, da das RAID damit um ein vielfaches schneller wird.
Und was bedeutet ein nicht abgeschlossener Write? In diesem Fall, daß ein Teil der Disks schon die neuen Daten hat und ein Teil noch die alten. Also ein nicht konsistentes RAID. Dieses Problem ist nur behebbar, wenn die Instanz, die die Daten auf die Disks aufteilt, selbst persistenten Speicher hat und ein Replay machen kann, wenn Power wieder da ist. Wenn der Controller keinen gesicherten Speicher hat, GEHT das nicht, weil der Host nicht weiß, wo der Controller gerade hingeschrieben hat.
Nicht mit PLP. Dafür ist das ja da, um zu garantieren, daß alles, was im Cache der Disks angekommen ist, auch im permanenten storage landet.
Du denkst zu weit und Cache orientiert.
Wenn im Write das System crasht, haben eventuell ein paar Disks schon mehr Bytes als andere geschrieben, aber diese Blöcke sind einfach Garbage und werden überschrieben weil das RAID den Write nicht abgeschlossen hatte und somit auch kein Ack an das schreibende OS gesendet wurde.
Die Daten gibt es quasi nicht. Deshalb ist das ohne Cache auch so langsam.
PLP gibts aber nur bei SSDs. Viele Leute nutzen RAID Controller aber für HDDs.
Du denkst nicht weit genug.
Und woher soll das RAID bei der crash recovery wissen, daß die Blöcke Müll sind und nicht wichtig, wenn das OS an der Stelle schon tot war und nicht mehr überschreiben kann? Der ganze Block ist dann kaputt. Selbst wenn das RAID eine dirty map hat, ist da immer noch das Problem, daß in dem Block schon teilweise Daten gestanden haben können, weil das fs nur Lücken aufgefüllt hat. Die sind dann weg. (Nebenbei auch der Grund, warum tail merging so gefährlich ist ...)
Ja, aber die Aussage "nie" bzw. "immer tödlich" war mir da etwas zu allgemein. Sowas führt dann dazu, daß Leute den Cache wirklich immer abschalten, auch wenn sie das gar nicht müßten, und damit die SSD tatsächlich noch mehr belasten, weil die dann die Zugriffe nicht optimieren kann.
Dann lese dich mal in die RAID Grundlagen ein, früher als ich mit sowas angefangen habe gab es keinen Cache.
Und woher soll das RAID das wissen? Das RAID weiß nur welche Full Stripes komplett geschrieben sind. Wenn da irgendwelche Daten auf den Disks rumschlummern ist nicht wild. Die werden ja überschrieben, da es die ja eigentlich nicht gibt und auch keine Zuordnung dazu. Falls jemand diesen Stripe liest, ohne das es eine Zuordnung gibt, passt die Checksumme nicht und somit erhältst du auch keine verwertbaren Daten.
PS ein RAID Controller schreibt immer den kompletten Full Stripe, auch wenn nur 1 Byte geändert wurde.
Ok, da gehe ich mit.