Flex-RAID anstatt RAID5?

[Unlimited]

Generell enstand im Privatbereich halt der Irrglaube, dass RAID für Sicherung der Daten eingeführt wurde ... was Quatsch ist, seit jeher war der Anspruch unterbrechungsfreie Verfügbarkeit und mit etwas Abstand an zweiter Stelle die Performance. Die Verwendung in Backupstrategien beschränkt sich dann auf getrennte Systeme, die sich dem Workload und Zugriff der Nutzer entziehen.

Ja, wobei die Absicherung gegen Hardwaredefekt einer Platte auch nicht unwichtig ist.
Jeder definiert seine Ansprüche halt anders.
Bei mir wars damals im RAID5 folgende Reihenfolge, so wie wohl bei der Mehrheit der Nutzer:

1. Absicherung gegen Defekt
2. Performance
dann erst mit gaaanz großem Abstand:
3. unterbrechungsfreie Verfügbarkeit

Klar, oder?
3. ist in Produktivumgebungen wichtig, nicht aber bei Privatnutzern.

Wirkliche Performance gabs damals ja eigentlich auch nur via RAID0.
Das MatrixRAID war an dieser Front richtig innovativ, denn es hatte ein geniales Alleinstellungsmerkmal: es konnte RAID5 und RAID0 auf dem selben RAID-Verbund fahren.
War genial i.d. Theorie:
Mit 4 Platten ein RAID5 erstellen und auf jeder Platte die 20 schnellsten GB fürs RAID0 abzwacken, ergab 80GB Systemspeicher mit für damalige Verhältnisse superschnellen 300-400MB/s, ohne dass man dafür nochmals 4 Platten anschaffen und den Großteil des Platzes verschwenden musste.

Für die Performance brauche ich heute aber kein RAID5 mehr, weil es lächerlich ist im Vergleich zu meinem SSD-Cache.
Also bleibt nur Punkt 1, der fürs RAID5 spricht.

Backup wurde/wird natürlich extern gemacht, wobei ich mir den Luxus erlaube die Backupfrequenz sehr stark herunter zu fahren.

 

[yourgreatestfear]

jetzt musst mir in Deiner Logik nur noch erklären, wieso Deine Absicherung gegen Defekt nicht gleichbedeutend mit dem Anspruch an unterbrechungsfreier Verfügbarkeit ist.

 

[Unlimited]

jetzt musst mir in Deiner Logik nur noch erklären, wieso Deine Absicherung gegen Defekt nicht gleichbedeutend mit dem Anspruch an unterbrechungsfreier Verfügbarkeit ist.

Unterbrechungsfreie Verfügbarkeit ist mir völlig wurscht, damals gabs halt Absicherung gegen ein HDD-Defekt im RAID5 nur in Kombi mit unterbrechungsfreier Verfügbarkeit.

Aus heutiger Sicht (SSDs) und aus der Sicht eines Homeusers kann man sagen:
"Unterbrechungsfreie Verfügbarkeit" auf die Art, wie RAID5 sie bieten kann, bringt sehr viele Nachteile mit sich und ist im RAID5 dadurch leider ein notweniges Übel.
"Performance" auf die Art, wie RAID5 sie bieten kann, bringt sehr viele Nachteile mit sich und ist im RAID5 dadurch leider ein notwendiges Übel.

Heute geht es zum Glück auch wieder ohne die mit "unterbrechungsfreier Verfügbarkeit" und "Performance" einhergehenden Nachteile, und ich bevorzuge dies.
Heute bekomme ich nur das was ich will: Absicherung gegen Defekt eines Laufwerks.
Die Lösung nennt sich SnapshotRAID, verstehe es endlich...

Die Vorteile von SnapshotRAIDs FÜR HOMEUSER!!! ggü. Mirrors und RAID5 allgemein sind dramatisch...

Abgesehen davon, Privatnutzer brauchen einfach keine unterbrechungsfreie Verfügbarkeit.
Punkt.
Unterbrechungsfreie Verfügbarkeit führt im RAID5 zu um mindestens den Faktor 300% erhöhter Ausfallwahrscheinlichkeit durch Abnutzung der Platten, Stromverbrauch, Lärm, Wärme im PC, alle Platten müssen permanent zugleich laufen, Platzverschwendung, hohe Investkosten durch Anschaffung vieler großer Platten zugleich, deren Speicher man erst später benötigt, wenn er billiger zu kaufen wäre, RAID5 bringt selber zusätzliche erhebliche systemimmanente Risiken ins System, RAID5 ist sein größter Feind selber, sprich statistisch gehen im RAID5 die meisten Daten verloren wegen Problemen, die erst durch RAID5 geschaffen wurden, blablabla, etc. steht alles weiter vorne.

Alle Nachteile von RAID5 das sind zugleich die Vorteile von SnapRAID!

Daraus folgt logisch, dass ich SnapRAID bevorzuge ggü. RAID5... zugleich geht aus deiner Frage hervor, dass du eben die deiner Ansicht nach "geringen" Vorteile von SnapshotRAID irgendwie doch nicht verstanden hast, weil sonst würdest du obige Frage gar nicht erst fragen.

Denn SnapshotRAID ist eben nichts anderes, als "Absicherung gegen Defekt"
ohne "unterbrechungsfreie Verfügbarkeit" mit deren Nachteilen und als Bonus auch noch
ohne "Performance" mit deren Nachteilen.

Somit widersprichst du dir selber und beantwortest du es ja indirekt selber so, dass du SnapshotRAID als bessere Alternative für Privatanwender siehst mit folgendem Satz:
"Generell enstand im Privatbereich halt der Irrglaube, dass RAID für Sicherung der Daten eingeführt wurde ... was Quatsch ist, seit jeher war der Anspruch unterbrechungsfreie Verfügbarkeit und mit etwas Abstand an zweiter Stelle die Performance."

Und da stimme ich dir auch zu!
SnapshotRAID wurde hauptsächlich zur Sicherung der Daten vor dem Ausfall eines Laufwerks eingeführt.
Indem man die Daten "vor dem Ausfall eines Laufwerks" schützt, hat man jedoch bereits die mit Abstand schlimmste nicht-menschliche Datenverlustwahrscheinlichkeit aus dem System genommen und kann sich tatsächlich bzgl. Backups eher zurücklehnen, als ohne SnapshotRAID.

 

[JKuehl]

jup, ZFS verwendet bewusst striping und kennt kein JBODartiges verwenden von Plattenverbünden... Redundanz durch einen Spiegel oder eine Parität ist halt genug, wenn nicht wendet man höhere Level an. Die Paranoia gegenüber multiplen Plattenversagen ist nicht mehr ganz vernünftig in der heutigen Zeit, vor allem im Privatbereich und mit regulären Backupstrategien.

Das ist so nicht richtig, denn genau der Otto-Normalverbraucher hat alles auf einem Array und eben KEINE Backupstrategie.

Ich habe das vernünftig durchdacht und eine Backupstrategie nach Wichtigkeit der Daten bei mir implementiert. Auf den Festplatten befinden sich nur Daten der untersten Stufe sowie zusätzliche Backups der darüberliegenden Schichten.

Ich habe festgestellt dass mit abnehmender Wichtigkeit die Datenmengen auch immer größer werden (z.B. wichtigste Dokumente rund 100 MB, nächste Stufe sind wichtige Daten mit rund 2GB, danach folgen RAW-Fotos und der ganze Rest mit 1.5 TB)

Auf der letzten Stufe sind dann rund 10 TB Daten, die ich nicht separat sichern werde weil es einfach zu teuer ist - bei denen es dennoch schade wäre sie zu verlieren. Alle Daten hier sind wiederbeschaffbar, aber eben mit einem zeitlichen Aufwand. Um diesen zu begrenzen, und weil eine separate Sicherung zu teuer wäre setze ich auf snapraid.

Spinup / Spindown ist übrigens kein Problem. Rund 10.000 in 3 Jahren sind bei allen eingesetzten Platten kein Problem (alle mit mindestens 200.000 spezifiziert).

Der Stromverbrauch ist dann auch noch ausschlaggebend.

 

[Unlimited]

Das ist so nicht richtig, denn genau der Otto-Normalverbraucher hat alles auf einem Array und eben KEINE Backupstrategie.

Ich habe das vernünftig durchdacht und eine Backupstrategie nach Wichtigkeit der Daten bei mir implementiert. Auf den Festplatten befinden sich nur Daten der untersten Stufe sowie zusätzliche Backups der darüberliegenden Schichten.

Ich habe festgestellt dass mit abnehmender Wichtigkeit die Datenmengen auch immer größer werden (z.B. wichtigste Dokumente rund 100 MB, nächste Stufe sind wichtige Daten mit rund 2GB, danach folgen RAW-Fotos und der ganze Rest mit 1.5 TB)

Auf der letzten Stufe sind dann rund 10 TB Daten, die ich nicht separat sichern werde weil es einfach zu teuer ist - bei denen es dennoch schade wäre sie zu verlieren. Alle Daten hier sind wiederbeschaffbar, aber eben mit einem zeitlichen Aufwand. Um diesen zu begrenzen, und weil eine separate Sicherung zu teuer wäre setze ich auf snapraid.

Spinup / Spindown ist übrigens kein Problem. Rund 10.000 in 3 Jahren sind bei allen eingesetzten Platten kein Problem (alle mit mindestens 200.000 spezifiziert).

Der Stromverbrauch ist dann auch noch ausschlaggebend.

Alles sehr gut und richtig, wobei das alles auch bereits auf den Seiten vorher ausführlich erläutert wird.

Ich meine es wirklich nicht böse, aber es wäre gut, wenn der Herr ygf sichs halt einfach mal durchlesen und verstehen würde, anstatt hier dauernd in aggressivem / provokantem Ton überflüssige Fragen und Einwände zu spammen, die längst beantwortet sind.
So wird der ganze Thread nur unnötig verwässert durch Wiederholungen.
Fragen von ygf bitte künftig gerne auch per BM direkt an mich.

 

[ghostadmin]

Ich sag immer so, wenn man kein Backup macht dann sind die Daten auch nicht wichtig.

Und wenn Otto Normalverbraucher kein Backup macht dann meistens weil er denkt das RAID dies ersetzt.

 

[Unlimited]

Ich sag immer so, wenn man kein Backup macht dann sind die Daten auch nicht wichtig.

Und wenn Otto Normalverbraucher kein Backup macht dann meistens weil er denkt das RAID dies ersetzt.

Ja es ist oft einfach nur das Unwissen... leider... so wars bei mir auch vor vielen jahren, doch aus Schaden wird man manchmal klug

 

[ghostadmin]

Hab ich gestern erst wieder bei einer Schule gesehen. Da werden Enterprise Produkte wie Vmware ESX eingesetzt aber es gibt keinerlei Backup.

 

[Holt]

so wars bei mir auch vor vielen jahren, doch aus Schaden wird man manchmal klug

Das erklärt dann einiges

Trotzdem gilt auch für SnapRAID, dass RAIDs keine Backups ersetzen! Eben weil sie gegen viele Risiko denen Daten ausgesetzt sind nicht schützen können, ja ich weiß das nur andere User dumme Fehler machen die sie ihre Daten kosten und man eben doch noch Lotto spielt welche Daten es im Zweifel trifft, sollte es zu dem Ausfall von einer Platte zu viel kommen, bevor die zuvor ausgefallenen ersetzt wurden, was ja auch zuerst das Erkennen des Ausfalls bedingt.

 

[ghostadmin]

Wenn der Controller spinnt oder die HDDs wegen Überspannung sterben bringt FlexRAID auch herzlich wenig.
Bei ersterem sollte ZFS aber nicht so empfindlich sein bei vorhandenen Daten.

 

[Holt]

ZFS ist sehr empfindlich auf RAM Fehler, denn es hält viele und große Metadatenstrukturen lange im RAM und ist damit entsprechenden Risiken ausgesetzt, zumal es seine Datenstrukturen im RAM anders als auf den Platten eben nicht selbst mit Prüfsummen schützt. Aber das ist ja auch für den Servereinsatz entwickelt worden und da gibt es immer ECC, die HW schützt also vor RAM Fehlern.

 

[tomturbo]

Das ist in der Tat der größte Nachteil von ZFS.
Daher ist auch meiner Meinung nach ein Block RAID auf solchen Maschinen sinnvoller, da es einfach unempfindlicher im Betrieb ist.
Scrubbing ist allerdings auch dort zu empfehlen.

 

[yourgreatestfear]

ZFS ist sehr empfindlich auf RAM Fehler, denn es hält viele und große Metadatenstrukturen lange im RAM und ist damit entsprechenden Risiken ausgesetzt, zumal es seine Datenstrukturen im RAM anders als auf den Platten eben nicht selbst mit Prüfsummen schützt. Aber das ist ja auch für den Servereinsatz entwickelt worden und da gibt es immer ECC, die HW schützt also vor RAM Fehlern.

Und schon wieder so ein Gerücht was sich ohne Rückhalt in der Realität verbreitet hat und jeglicher Logik widerspricht!

Lest euch mal das durch hier LINK und kloppt endlich mal diese irrealistischen Schnappsideen in den Abfalleimer!

prinzipiell verlangt ZFS etwas mehr RAM, weils ARC nutzt. Das hat aber keine Relevanz für die Datenintegrität, sondern nur für die Performance der Lese-/Schreibvorgänge. Dazu müsste man aber halt verstehen was ARC macht und wieso Fehler darin nicht zu Datenkorruption führen können.

PS: Manche hier sollten generell mal ihre Vorstellungen zu den verschiedenen RAID/FS-Implementierungen von Altlasten der Vergangenheit und rückhaltlosen Vermutungen befreien.

PS2: Auch falsch, dass die Cacheinhalte nicht durch Prüfsummen geschützt sind, Read/write in ARC caches sind äquivalent zu Direktzugriffen bzgl. der Datenintegrität ... wers nicht glaubt kann sich Suns Analytics zu den verschiedenen Storagesystemen mal durchblättern und wird mitbekommen wie ZFS auf Cachefehler, identifiziert durch checksums oder I/Oerrors, reagiert und das es dann immer zum Fallback kommt.

bsp für so ne storage analyse: http://docs.oracle.com/cd/E22471_01/html/820-4167/ch6.html

 

[ghostadmin]

Wenn der RAM spinnt ist jedes Dateisystem in Gefahr

Und die Checksums sind ja grade das gute an ZFS weil es die Files sieht und nicht nur Blocks.

 

[Holt]

Und schon wieder so ein Gerücht was sich ohne Rückhalt in der Realität verbreitet hat und jeglicher Logik widerspricht!

Und verbreitest das Gegengerücht ohne zu verstehen wo das Problem liegt.

Lest euch mal das durch hier LINK und kloppt endlich mal diese irrealistischen Schnappsideen in den Abfalleimer!

Denn auch hier wurde nicht verstanden, wo wirklich das Problem ist, denn da geht es um die Korruption der Nutzdaten, die schützt ZFS ja mit seinen Prüfsummen. Es geht aber um die Korruption der Metadaten des Filesystems und die schützt ZFS eben gerade nicht, weil es sich da auf die Serverhardware verlässt, für die es ja entwickelt wurde. Da es auch besonders umfangreich seine Metadaten ins RAM lagert, ist die Gefahr eben auch höher als bei anderen Filesystemen und dann verliert man auch mal den ganze Pool.

Auch falsch, dass die Cacheinhalte nicht durch Prüfsummen geschützt sind

Um die geht es auch nicht, das sind nicht die Metadaten des Filesystems und Du solltest erst einmal verstehen, was denn Metadaten eines Filesystems sind, bevor Du hier weiter Unsinn schreibst weil Du alles verwechselst. Suche mal selbst nach einem Beleg wo angegeben wird, ob ZFS seine Metadaten im RAM schützt, dann solltest Du mehr lernen als wenn ich Dir ein paar Links vorlege.

 

[yourgreatestfear]

Hast Du überhaupt mal nen Blick in die Sundokumente geworfen, Die Fehleranalyse betrifft explizit auch die Metadaten ...

Ab lesen, dann klugscheissen!

 

[ghostadmin]

https://blogs.oracle.com/bonwick/en_US/entry/raid_z

But far more important, going through the metadata means that ZFS can validate every block against its 256-bit checksum as it goes. Traditional RAID products can't do this; they simply XOR the data together blindly.

Which brings us to the coolest thing about RAID-Z: self-healing data. In addition to handling whole-disk failure, RAID-Z can also detect and correct silent data corruption. Whenever you read a RAID-Z block, ZFS compares it against its checksum. If the data disks didn't return the right answer, ZFS reads the parity and then does combinatorial reconstruction to figure out which disk returned bad data. It then repairs the damaged disk and returns good data to the application.

 

[Holt]

Meinst Du dieses Dokument? Wo steht da was über RAM Fehler, wenn es sich auf professtionelle Sun Storage der Serien 7310, 7320, 7410, 7420 und 7720 bezieht, die alle Xeon CPUs und reg. ECC RAM haben?

Bezeichnend für Leute die ECC bei ZFS für überflüssig halten ist eine selektive Wahrnehmung wie sie auch Jim Salter in dem Link aus Deinem letzten Post gezeigt hat, als er den aus Matthew Ahrens Beitrag zitierte:

There’s nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem.

. Dabei war seine Aussage aber:

There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.

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

Demnach ist man mit allen Filesystem gleich gefährdet, wobei der aber wegen der intensiveren RAM Nutzung von ZFS so nicht stimmt, denn je mehr RAM Daten belegen, umso wahrscheinlicher sind sie dann von RAM Fehler (egal ob soft- oder hard Errors) betroffen, aber der Vater wird sein Kind nicht schlechter als andere darstellen wollen. Dazu wurde dann auch sein klarer Hinweis das wer seine Daten liebt ECC RAM verwenden sollte, einfach von Jim Salter unter den Tisch fallen lassen, weil sie den Kontext gestört hätte.

Aber das muss jeder selbst wissen, mir ist es egal, es sind nicht meine Daten, mein Heimserver hat ECC RAM. Der einzige Vorteil von Nicht-ECC RAM ist der Preis, aber da auch weniger der des RAMs als der für die Plattform. Wobei da AMD im Vorteil ist, weil die ganzen AM3(+) CPUs und Chipsätze ECC RAM unterstützen und zumindest einige Boards von ASUS und Gigabyte. Bei Intel muss man dagegen auf ein teures Board mit Xeon Chipsatz und einen Celeron, Pentium, i3 oder Xeon ausweichen (oder einen der SoC die ECC unterstützen, aber das sind auch nicht die billigsten) und angeblich soll ECC RAM sogar beim AM1 mit dem Asus AM1M-A gehen.

Aber das muss eben jeder selbst entscheiden, darüber wird ja auch genug im Netz gestritten, hier geht es nicht um ZFS sollte das Thema damit hier durch sein, für mich ist es das jedenfalls.

--- Update ---

https://blogs.oracle.com/bonwick/en_US/entry/raid_z

But far more important, going through the metadata means that ZFS can validate every block against its 256-bit checksum as it goes. Traditional RAID products can't do this; they simply XOR the data together blindly.

Das bezieht sich auf die Nutzerdaten, nicht auf die Metadaten, die haben keine eigene 256bit ECC, wozu auch bei einem Filesystem welches für Server-HW geschrieben wurde, die die RAM Inhalte eben immer mit ECC RAM selbst vor Korruption schützt und welches sowieso schon viel RAM und CPU braucht.

Which brings us to the coolest thing about RAID-Z: self-healing data.

Auch das ist alles auf die Nutzdaten bezogen, wären die Metadaten im RAM so gut geschützt, könnte es keine Fälle von zerstörten Pools gehen, aber die gibt es eben und RAM Fehler spielen da eben eine Rolle. Außerdem gibt es kein Recovery-Tool für die gecrashten Pools, das ist dann ein Totalverlust.

 

[ghostadmin]

Die Metadaten werden afaik erst dann verwendet wenn es auch notwendig ist d.h. wenn die Checksum eines Files nicht stimmt oder wenn eine Disk ausfällt.
Und ich habe schon gelesen das jemand den Pool recovern konnte mit korrupten Metadaten.
Regelmäßige Scrubs sollte man auch durchführen.

 

[yourgreatestfear]

Schön gegoogelt nur leider nicht gelesen scheinbar. Die Quotes sind zum temporären WriteCache (die Debugflag ist für Scrubbing vorm Write, also zusätzliche Fehlercontrolle für den extrem flüchtigen Moment zwischen Queue und tatsächlichem Schreiben auf Platte), welcher in etwa wie bei jedem anderen transactional FS arbeitet. Daher hat ZFS hier die gleichen Risiken wie jedes andere FS, wenn man es ohne die Flag nutzt.

Der ARC hat mit dem WriteCache aber nix zu tun und ist eine Read-Extension dessen was auf der Disk passiert. Für den Inhalt arbeitet ZFS wohlverständlich und logischerweise mit den gleichen READ/WRITE-Algorithmen wie beim Direktzugriff auf Laufwerke, wobei aber ein Checksum- oder I/O-error zu einem Fallback aufs Laufwerk führt, statt zu einem Scrub. Die Dokumente, ordentlich studiert, zeigen Dir das für Daten wie auch Metadaten Fehler im ARC gleichartig zum Direktzugriff auf Laufwerken abgefangen werden und die Sicherungskette für die Datenintegrität weiterkickt in den Levels. Die einzige Sonderbehandlung für Metadaten im ARC besteht darin in welche Register er bei Fehlern weitermacht. Ein gekipptes Bit in den Metadaten würde unweigerlich zum Miss führen und den Zugriff auf L2ARC bzw. den Pool einleiten.

Es ist und bleibt nunmal so, das für die Datenintegrität der ARC keine zusätzliche Fehlerquelle ist, egal ob ECC oder nicht hier greift die ZFS-Fehlerkorrektur und Robustheit bzgl der Integrität. .. so bescheuert das Ding fehleranfälliger zu designen als den Direktzugriff auf Meta- und Blockdaten wäre kein Entwickler.
relevant wird ECC-RAM für den WriteCache des Transaktionssystems, und hier gibt es keine relevanten Besonderheiten im Vergleich zu anderen FS.


PS

hier geht es nicht um ZFS sollte das Thema damit hier durch sein, für mich ist es das jedenfalls.

Solange ihr in euren Argumenten Falschaussagen macht zu anderen FS/RAID-implementationen, ist es unumgänglich so ein leidseliges OffTopic zu betreiben. Wenn es euch nicht passt, dann lasst einfach derartiges Hörensagen und die Vermutungen bleiben. Man kann nicht alles wissen, gerade deswegen wäre ich vorsichtig mit dem weiterverbreiten irgendwelcher Weisheiten die man mal in einem Forum gelesen hat.

 

[ghostadmin]

definiere "ihr"