sind 2 verschiedene Raids möglich

    • OMV 3.x
    • sind 2 verschiedene Raids möglich

      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.
    • Moonraker wrote:

      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.
      OMV 3.0.90 (Gray style)
      ASRock Rack C2550D4I - 16GB ECC - 6x WD RED 3TB (ZFS 2x3 Striped RaidZ1)- Fractal Design Node 304
    • Re,

      Moonraker wrote:

      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. :D

      Moonraker wrote:

      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
    • Sc0rp wrote:

      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)
    • Danke für die mittlerweile schon reichlichen Antworten.

      Mit ZFS kenne ich mich bisher nicht aus, werde aber mal Informationen sammeln.
      Ein Link ist natürlich eine elegante Sache, das hatte ich auch schon im Hinterkopf, aber wenn
      man Backups macht, führt das dazu, dass das Backup platzt. Sagt man, dass beim Backups keine
      Links verfolgt werden, bleiben andere auf der Strecke, die man nicht missen möchte.

      Außerdem muss man demnächst Backups schon aufsplitten, da Platten gar nicht so groß sind.

      Ich denke ich werde mich mal schlau machen über ZFS.
    • Noch was,
      Sc0rp fragte, "welche Erfahrung". Die Erfahrung, dass jetzt 4 TB-HD's schon Platten sind, die an der
      unteren Kapazitätsgrenze von NAS-HD's sind.
      Da möchte ich ungern investieren. Der einzige Vorteil wäre, dass ein Defekt finanziell deutlich
      weniger schmerzhaft wäre, als bei einer 12 TB.
      Aber bei einer MTBF von 2.5 Mio. Stunden ist das Risiko überschaubar.

      Danke noch einmal.
    • Moonraker wrote:

      Der einzige Vorteil wäre, dass ein Defekt finanziell deutlich
      weniger schmerzhaft wäre, als bei einer 12 TB
      Na, 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.

      Moonraker wrote:

      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.
      OMV 3.0.90 (Gray style)
      ASRock Rack C2550D4I - 16GB ECC - 6x WD RED 3TB (ZFS 2x3 Striped RaidZ1)- Fractal Design Node 304

      The post was edited 1 time, last by cabrio_leo ().

    • Re,

      tkaiser wrote:

      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
    • Sc0rp wrote:

      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...
    • Users Online 1

      1 Guest