Ich habe 3 4TB HD's zu einem Software Raid verbunden, jetzt geht aber so langsam der Platz aus. Als ich vor 2 Jahren das OMV aufgebaut hatte nahm ich an, das hält für ewig.
Aber wenn Platz da ist will jeder aus der Familie seine Daten da ablegen. Daher beabsichtige ich ein Vergrößerung.
Nun gibt es 2 Optionen,
- eine (oder mehr) neue 4TB dazupacken, oder
- separat auf jetzt erhältliche 12TB gehen.
Aus der Erfahrung würde ich Variante eins eher nicht nutzen wollen.
Geht das im OMV, dass man separat ein weiteres RAID aufsetzt und dann z.B. 2 oder 3 HD's zu einem RAID-Verbund zusammenfasst?
Wenn JA, dan kann ich mir ja was zu Weihnachten schenken.
sind 2 verschiedene Raids möglich
-
- OMV 3.x
- Moonraker
-
Geht das im OMV, dass man separat ein weiteres RAID aufsetzt und dann z.B. 2 oder 3 HD's zu einem RAID-Verbund zusammenfasst?
Wenn es so gemeint war, dass du ein separates Raid-System aufsetzen willst und dann 2 oder 3 Raids zu einem Raid-Verbund zusammenfassen möchtest, dann sollte das mit MergerFS on top eigentlich machbar sein. Damit werden üblicherweise einzelne Disks zusammengefasst. Warum dann nicht auch mit Raids? Hab´s aber selbst nicht probiert.
Es gibt aber noch einen anderen Ansatz, dass zweite RAiD per symbolischen Link in einen Ordner im ersten Raid einzubinden. Dazu gibt es hier schon verschiedene Threads z.b. dieser:How to share your data across Drives with symlinks and no pooling
Ob das aber grundsätzlich sind macht? Bei 12 TB Platten würde ich heutzutage nur noch ein System verwenden, welches per Checksum die Integrietät der Daten auf Fileebene und nicht nur auf Blockebene überwachen kann (ZFS oder BTRFS), weil sich die Fehlerwahrscheinlichkeiten im Gegensatz zu der Größenzunahme nicht in gleichem Maße verbessert haben.
-
Re,
Geht das im OMV, dass man separat ein weiteres RAID aufsetzt und dann z.B. 2 oder 3 HD's zu einem RAID-Verbund zusammenfasst?
Das ist etwas schwer verständlich - aber unter Linux geht prinzipiell so gut wie Alles (sogar ZFS!).
Wichtig ist, das du dir ein Konzept überlegst - einfach nur Platten kaufen und dann hinterher i'wie zusammenschustern ist etwas ... platt.
Aus der Erfahrung würde ich Variante eins eher nicht nutzen wollen.
Welche Erfahrungen? Variante 1 wäre immerhin der native Weg ... und recht einfach zu bewerkstelligen.
Wenn du etwas für die Zukunft möchtest, wäre mit Sicherheit ZFS auf neuen 12TB-Platten der beste/bessere Weg!
@tkaiser: kann man von ZFS-Z1 auf ZFS-Z2 "hochleveln" (inline, wie man das von RAID-Lvl5 auf Lvl6 kann) ?
Sc0rp
-
kann man von ZFS-Z1 auf ZFS-Z2 "hochleveln" (inline, wie man das von RAID-Lvl5 auf Lvl6 kann) ?
Nö.
Macht aber auch nix weil warum wollte man daheim zwei Platten unsinnig für Verfügbarkeit opfern? RAIDZ krankt ja im Gegensatz zu klassischem RAID nicht daran, das ganze Array in die Tonne treten zu müssen, wenn beim Resilver auf den verbleibenden Platten der erste Lesefehler auftritt. Im schlimmsten Fall sind nur die Dateien betroffen, die in dann evtl auftretenden kaputten Sektoren stecken. Holt man dann halt aus dem Backup zurück, und wenn man kein Backup hat, braucht man eh keinen Verfügbarkeitsquatsch
RAID-Z2 würd ich für Nearline-Storage einsetzen wenn Downtimes weh tun könnten. Aber daheim braucht das niemand (außer man setzt auch auf Snapshots und will sich Backup sparen -- dann sieht es wieder völlig anders aus)
-
Der einzige Vorteil wäre, dass ein Defekt finanziell deutlich
weniger schmerzhaft wäre, als bei einer 12 TBNa, ein paar weitere Vorteile gibt es schon noch. Z.B. dauert der Rebuild bei einer 12 TB Platte wahrscheinlich ewig bei klassischem Raid, da hier auf Blockbasis die gesamte Platte und nicht nur der aktuelle Dateninhalt wiederhergestellt wird. Zudem werden in dieser Zeit die anderen Platten umso mehr gestresst.
Aber bei einer MTBF von 2.5 Mio. Stunden ist das Risiko überschaubar.
Problematischer als die MTBF ist hier eher die "Non-recoverable read errors per bits read "-Rate.
Dieser Thread hier ist dazu recht informativ: Statistics on real-world Unrecoverable Read Error rate numbers (not the lies told by vendors on their spec sheets)
Das Thema wird darin kontrovers diskutiert und es ist letztlich eine Frage von Wahrscheinlichkeiten. Je größer die Platte ist, desto wahrscheinlicher ist eben ein Lesefehler über die Zeit.
Deswegen sollte man bei diesen großen Platten Konstrukte wählen, die die Konsistenz der Daten überprüfen können. -
Re,
Deswegen sollte man bei diesen großen Platten Konstrukte wählen, die die Konsistenz der Daten überprüfen können.
Fully agreed!
Sc0rp
-
Re,
RAID-Z2 würd ich für Nearline-Storage einsetzen wenn Downtimes weh tun könnten. Aber daheim braucht das niemand (außer man setzt auch auf Snapshots und will sich Backup sparen -- dann sieht es wieder völlig anders aus)
Ich mache das ehr an der Anzahl der Platten im Verbund abhängig - hier würde ich gefühlsmäßig schon ab 6 HDDs ein Z2 nehmen, die Wahrscheinlichkeiten von Fehlern steigen ja nicht nur mit der Basisgröße EINES Datenträgers, sondern auch mit der Anzahl an verbundener Platten ... aber ich bin (noch) kein ZFS-Profi.
Sc0rp
-
Ich mache das ehr an der Anzahl der Platten im Verbund abhängig - hier würde ich gefühlsmäßig schon ab 6 HDDs ein Z2 nehmen, die Wahrscheinlichkeiten von Fehlern steigen ja nicht nur mit der Basisgröße EINES Datenträgers, sondern auch mit der Anzahl an verbundener Platten ... aber ich bin (noch) kein ZFS-Profi.
Und wegen letzter Aussage und auch relativ losgelöst von diesem Thread 'ne Antwort: Ich würde halt zuerst mal definieren, warum man welche Storage-Topologie wählt. Und weder RAID-Z1 noch Z2 oder Z3 würde man heute mehr für 'Hot Data' nehmen, dafür sind random IO zu mau, viel zu hoher Plattenstreß beim Resilvern, wenn mal was passiert und die Performance geht auch noch in den Keller. Für 'Hot Data' lieber mirrored vdevs in einem fetten zpool, das bisschen mehr Verschnitt ist relativ wurscht wenn man die Vorteile im Auge behält (speziell die 1a Performance in allen Lebens- und Array-Lagen).
Daher RAID-Z2 allenfalls noch für Nearline Storage, wo man keine Top-Performance braucht aber es auch ein wenig weh tun würde, wenn einem ein dickes Array zerbröselt und man alles von Band holen muß.
Aber daheim? Das sind doch überall nur digitale Müllhalden. Heutzutage hortet man Daten eigentlich nur weil man kann und Platten zu billig geworden sind. Der 'Wert' von dem gehorteten Zeugs (TV-Serien und sowas) ist doch weder Redundanz noch Backup wert. Ich würd für sowas keine einzige Platte zu viel opfern sondern mit null Redundanz arbeiten (also nicht ein zpool aus lauter Platten, denn der ist weg, sobald das erste vdev weg ist sondern eher sowas wie btrfs/linear: wenn da mal 'ne Platte stirbt, läßt man sich vom drauffolgenden scrub mitteilen, was alles an Dateien futsch ist und holt das entweder aus dem Backup oder anderen Quellen falls vorhanden oder lebt halt mit dem Datenverlust)
Nach meinem Verständnis sind in btrfs Verzeichnis- und sonstige Dateisystemstrukturen nicht Daten sondern Metadaten, btrfs erlaubt unterschiedliche 'Multi Device'-Repräsentationen für Daten und Metadaten, d.h. wenn man sich ein btrfs-Setup aufbaut, bei dem die Daten dem 'linear' Schema folgen aber die Metadaten mit Redundanz gespeichert werden und dann eine Platte später stirbt oder man sie einfach stromlos setzt, dann hat man kein kaputtes Dateisystem hinterher sondern einfach nur Dateien, die ganz oder teilweise fehlen (das ist ja das Schöne an diesen modernen Ansätzen) und die man allesamt beim Namen kennt, weil einem das ein Scrub mitteilt. Disclaimer: Nie wirklich getestet von mir weil immer noch irgendwas Besseres zu tun gehabt, wenn man ein Test-Setup aufgebaut war.
Persönlich tendier ich ja zur Vermeidung solcher unstrukturierter Datengräber und speziell alles, was fetter als 10TB ist, löst eh Würgereiz aus, einfach weil Wiederherstellungszeiten, wenn mal was platzt, so häßlich lang werden. Mein Ansatz ist Datenseparation: der ganze Medienquatsch, der eh wertlos ist oder mit vertretbarem Aufwand wiederhergestellt werden kann, kriegt weder Redundanz noch Backup spendiert und liegt auf anderen Systemen als das wichtige Zeug.
Im Prinzip genau derselbe Ansatz bei Kunden bloß halt das Pferd andersrum aufgezäumt: Datenklassifizierung beinhaltet immer auch Definition von Verfügbarkeitszeitfenstern (also 'Wie lange könnt Ihr als Firma überleben, wenn diese Daten hier 24/48/72/n Std. nicht verfügbar sind') und daran orientiert sich dann alles Weitere, was zum Teil auch in unkonventionellen Lösungen enden kann (bspw. Verlag, der paarmal im Jahr häßlich kleine Datenverfügbarkeitszeitfenster hat, kein Storage-/Backup-Upgrade angedreht sondern ihnen Vertragsklausel für ihre Druckdienstleister empfohlen, die die Daten eh auch haben und jetzt über eine simple Schnittstelle jederzeit verfügbar machen)
PS: Ja, mir ist grad langweilig -- warte auf den Ausgang eines Storage-Benchmarks auf einem sündteuren EMC-Kasten, der für lange Gesichter sorgen wird...
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!