Frage Unraid

HerrRossi

Urgestein
Mitglied seit
Jul 25, 2018
Beiträge
6.771
Bewertungspunkte
2.236
Punkte
113
Hi!

Kennt sich hier jemand mit Unraid aus? Ich hab da drei kurze Fragen:
  1. Läuft das auch als VM unter ESXi?
  2. Was passiert, wenn ein Laufwerk ausfällt? Man kann Unraid mit einer oder mehreren Parity Platten ausrüsten, reicht es dann, einfach die Platte auszutauschen und neu syncen zu lassen? Als Filesystem käme XFS zum Einsatz.
  3. Gibt es andere gleichwertige Lösungen, vllt. sogar Open Source?
Danke vorab!
 
Doch. Ich kratze ja nur an der Oberfläche bzw. so tief mit Google wie ich muss, damit’s läuft. ;)

Haben wohl schon ein paar erfolgreich Ryzen 3000 mit ESXi zum Laufen gebracht. Ich kann da aber nichts aus eigener Erfahrung zu beitragen.
 
Mal eine Frage zur Konfiguration eines ZPools von ZFS bei OMV oder FreeNAS.

Ich habe drei 4 TB Laufwerke, davon sind zwei Seagate Ironstore NAS und eine Seagate Barracuda Compute. Bei Unraid hatte ich mir das so gedacht, dass die Daten auf den zwei NAS-Platten liegen und die Barracuda als Parity Drive mitläuft.

Ich könnte jetzt einen Zpool mit den beiden NAS-Platten machen und die Barracuda läuft als Spare mit. Oder soll ich das Risiko eingehen und die Barracuda mit in ein RaidZ1 aufnehmen und nachträglich eine Spare in den Pool einzubauen?

Oder ist es möglich, die Barracuda aus dem Pool rauszunehmen, sie durch eine weitere NAS-Platte zu ersetzen und sie dann als Spare zu nehmen?
 
Alles grds. möglich. Würde jetzt die einfach wie die anderen zwei einbauen - ohne Spare. Backup ist eh Pflicht.

Bei Solaris kannst Du später einfach eine neue einbauen und die simpel im laufenden Betrieb ersetzen, wenn Dir das zu heiß wird. Müsste bei FreeNAS im Zweifel auch gehen: http://blog.henrikandersen.se/2013/03/13/replacing-a-harddrive-in-a-zfs-pool-on-freenas/ (heute vielleicht auch über GUI).

Oder aber direkt eine gescheite 3. holen und die Barracuda in die Vitrine stellen. ;)
 
Danke.

Wenn ich jetzt ein Stripe über zwei Platten mache ist es nachträglich aber nicht mehr möglich, das in ein RaidZ1 umzuwandeln, oder?
 
Jain.

Pools funktionieren anders als Raids. Ein Pool besteht aus sog. vdevs (virtuellen Devices). Auf Ebene dieser Vdevs legst du die Basis fest, die man sonst Raidlevel nennt. Du kannst einem Pool quasi beliebige vdevs hinzufügen, wobei aber 1. primär neue Daten auch über die neuen vdevs verteilt werden, und alte Daten erst bei Veränderungen, 2. vdevs verhalten sich untereinander wie „Raid0“, und 3. die Verfügbarkeit hängt wegen 2. eben vom „schwächsten“ vdev ab, also der Pool (bzw. Daten) ist verloren, wenn ein vdev komplett ausfällt. Deswegen macht es halt wenig Sinn, Single-Drives als vdev oder no-Parity vdevs mit vdevs mit Parity/mirror zu kombinieren.

Beipiel: du kannst z.B. einen Pool mit einem einzelnen mirror-vdev starten und dann ein 2. vdev als mirror dazuhängen, was quasi Raid10 entspräche. Oder eben als 2. vdev auch ein RaidZ (Raid5).

Glaub je nach OS geht sogar die Erweiterung von vdevs... hab das aber bisher nicht gebraucht & daher nicht im Detail verfolgt, siehe z.B.: https://www.ixsystems.com/community/threads/raidz-expansion-its-happening.58575/

Die „Umwandlung“ des vdev-Typs geht meines Wissens aber nicht.

Nachtrag: man darf halt nicht vergessen, wo ZFS herkommt. Nämlich absoluter Enterprise und Datensicherheits- und -verfügbarkeitsfokus. Da geht man davon aus, dass über den Wert der Daten und deren Verfügbarkeit vor der Einrichtung Klarheit besteht und die Umsetzung der dafür „richtigen“ Konfiguration nicht an dem Preis einer Platte scheitert. ;) Daher kommt die Grundprämisse „lieber richtig und zur Not weniger Kapazität starten, als umgekehrt oder gar nicht“.

So wie aus performancegründen legt man dann halt entsprechend lieber unterschiedliche Pools an - mit Redundanz oder nicht, stripe oder nicht, flash vs. HDD und Cache nach Gusto...

Ich hab daher momentan auch mehrere Pools, z.B. ein SSD RaidZ, ein SSD „Raid0“, HDD RaidZ1 und HDD RaidZ2.
 
Zuletzt bearbeitet :
An der Kohle scheitert es nicht, ich will nur langsam in die Pötte kommen und hier in meiner Umgebung ist im Moment keine NAS-Platte verfügbar. Wenn ich jetzt was bestelle, dauert das locker bis Mittwoch, ehe ich die bekomme :(
Und wenn ich was kaufe wäre es wohl auch besser, direkt eine 8TB-Platte zu nehmen, die kann dann als Backup dienen, da hab ich auch noch keine Lösung.
 
@Besterino Hast du Erfahrungen, wie lange NAS-Platten durchschnittlich durchhalten oder weißt du eine website, die sowas testet? Die Hersteller werben ja mit utopischen MTBF-Zeiten von 1 Mio Stunden etc. aber ich kann mir nicht vorstellen, dass die Dinger so lange durchhalten.

Ich habe mich entschieden, den Server mit OpenMediaVault aufzusetzen, dazu laufen jetzt zwei Ironwolf 4TB formatiert mit XFS in einem Verbund mit dem UnionFS, abgesichert wird das ganze mit Snapraid auf einer weiteren 4TB Platte, damit sollte ich halbwegs sicher sein. Für das richtige Backup habe ich mir jetzt noch eine Western Digital WD Red 8TB bestellt, Datenverlust ist damit dann wohl hoffentlich kein Thema.

Mit dem Server kann ich jetzt erstmal ein bisschen rumspielen, ein paar VM aufsetzen und gucken, was so geht.

Das nächste Projekt ist dann die Virtualisierung des Haupt-PCs. Ich merke immer wieder, dass es Probleme gibt, die man mit einer VM in der Form nicht hat (vllt. handelt man sich dafür aber andere Probleme ein, mal sehen), zB. im Moment habe ich das Problem, dass ich mein Linux im Dual Boot wegen dieses rdrand-Bugs nicht nutzen kann, das ist sehr ärgerlich, mit einer VM hätte ich das Problem nicht.

Das wird aber wohl ein Projekt für den nächsten Urlaub, eigentlich wollte ich auch noch ein bisschen zocken :cool:
 
Mal von hinten nach vorne... ;)

Vorsicht: wenn eine CPU einen Fehler hat, hast Du den im Zweifel auch in der VM... jedenfalls besser vorher testen...

Aber gerade beim Systemwechsel hilft das natürlich ungemein: einfach schnell den Hypervisor installieren und einrichten (<10 Min), VM importieren, fertig und weiter Daddeln. :D Man kann halt die komplette Installation einfach auf die neue Hardware mitnehmen.

HDD Tests sind m.E. eher schwierig, da hängt wohl alles von Details ab. Backblaze veröffentlicht m.W. Statistiken nur mit Consumer Disks. https://www.backblaze.com/blog/backblaze-hard-drive-stats-q1-2019/

Wichtiger als die 1Mio ist bei HDDs die UBER: größer als 4TB würde ich für wichtige Daten nur welche mit einer UBER von 1 in 10^15 nehmen (Achtung: manche tricksen und geben 10 in 10^15 an). Wenn Dir nämlich beim Resilvern ein unrecoverable read error auf den verbleibenden Disks begegnet, war’s das dann ggf. Und dann eben die Garantiezeit.
 
Danke dir. Wo finde ich diese UBER Angabe? Google nervt mich, jetzt kommen Millionen Ergebnisse, die "über" enthalten. Was soll der Scheiß? Als wäre man zu doof, die Suchworte richtig einzutippen. Bevormundung durch Maschinen, tolle Zukunft:alien::poop:

Bei Seagate finde ich auch nix dazu, weder auf der website noch im Datenblatt noch im Handbuch.
 
Zuletzt bearbeitet :
Wenn dann in den Spec Sheets. Wurde leider nicht einheitlich bezeichnet, aber jetzt gibt's ja eh nur noch 2,5 Hersteller. :p

Bei WD und Seagate heißt das z.B. "non-recoverable errors per bits read": WD Red Spec Sheet bzw. Ironwolf Pro Spec Sheet
Toshiba: "Unrecoverable error rate" zumindest hier im Spec Sheet

WD versucht da wiedermal sich rauszuwinden... 1 in 10^15 trauen sie sich nicht, 1 in 10^14 ist kacke also versuchen sie's jetzt mit "kleiner 1" in 10^14... Experten.

Im allgemeinen Sprachgebrauch hat sich trotzdem irgendwie UBER eingebürgert... sorry, dachte damit sei alles gesagt. :)

Wichtig: 1 in 10^14 heißt halt statistisch ein nicht-korrigierbarer Lesefehler in 12,5TB, d.h. bei einer 8TB-Platte ist die Wahrscheinlichkeit schon >50%! Das willst Du bei einem Raid-Resbuild wo ALLE Daten von einer Disk (bzw. allen Disks) gelesen werden, also eher nicht... zumindest wenn man noch bissi Stochastik aus der Schule im Hinterkopf hat und wie sich das dann mit zunehmender Anzahl von Datenträgern im Raidverbund verhält...

1 in 10^15 sind dann übersetzt schon 125TB - das lässt schon deutlich entspannter schlafen.

Nachtrag: ich hab aber selbst noch 4x4TB WD Red (im RaidZ) mit 10^14 im Einsatz... und eine Seagate Archive 8TB (Backup, kein Raid), bei der Single-Archive ist dann aber eben schlimmstenfalls eine Datei fratze und ein Error reisst im worst case (Rebuild/Resilver) nicht gleich einen ganzen Pool in den Tod. Alle neueren Spindles haben bei mir aber 10^15 (=Seagate).
 
Zuletzt bearbeitet :
Ich glaube bei dem Thema gilt, dass viel zu wissen eher nicht zur Beruhigung beiträgt. Ob ich die WD Red jetzt wieder stornieren und eine Seagate nehmen soll? Die non-pro Ironwolf hat auch 10^15...
Allerdings werden meine Platten nicht wirklich gestresst.
 
Es geht ja nicht ums stressen sondern das es statistisch wahrscheinlich ist ein falsches Bit zu lesen. Das kann schnell passieren wenn man ein RAID wieder aufbaut.
 
Ja, das ist klar, aber ich habe ja kein RAID, sondern sowas in der Art wie Unraid es auch macht.
 
@v3nom: alles eine Frage des Einsatzzwecks... aber meiner Meinung nach für den Einsatz im Keller-NAS ganz klares JA bei Kapazitäten jenseits der 4TB. Zumal die Ironwölfe dann ab 6TB mit 7200 RPM drehen. Im Wohnzimmer-NAS wäre wohl was mit ~5400 RPM angenehmer...

@HerrRossi: Bei 4TB tun die sich aber nix und da hat die non-Pro Ironwolf auch nur 1 in 10^14: https://www.seagate.com/www-content/datasheets/pdfs/ironwolf-16tb-DS1904-13-1905DE-de_DE.pdf 10^15 gibt's auch erst ab 6TB. Der Teufel steckt im Modell. ;)

Nachtrag: da ich keine Ahnung hab, was Unraid im Fall eines nicht-behebbaren Lesefehlers treibt, kann ich dazu nichts sagen. Im besten Fall ist eine Datei verloren, im Normalfall ein Filesystem-Block (ZFS) und im Worstcase der Pool/Raidverbund oder wie auch immer Unraid das nennt.
 
@Besterino Ja, ich meinte ja wegen meiner 8TB Backupplatte, die 4TB Dinger habe ich ja schon länger, die kann ich nicht mehr stornieren ;)
 
Ah ok. Wird schon nicht auf Live- und Backup-Disk(s) gleichzeitig einen Lesefehler ausspucken. Bei Verwendung als Single-Laufwerk sollte da auch Unraid nicht die ganze Platte bei einem Lesefehler wegwerfen. ;)

Schlimmstenfalls ist da normalerweise nur eine Datei betroffen/kaputt, die kann man dann bisweilen trotzdem noch retten (z.B. mit Lesefehler kopieren) und je nach Datei kann der Fehler auch mal völlig egal sein (Video / Bild / Musik o.ä.).

Ich hab zum Beispiel u.a. zwei 4TB WD "My Passport" als offline Backup-Disks, auf die ich abwechselnd (und zugegeben in unregelmäßigen Abständen) meine wichtigsten Daten repliziere. Eine davon liegt dann auch außerhalb meiner 4 Wände. Aber diese Dinger glänzen jetzt auch nicht durch besondere Zuverlässigkeit, Widerstandskraft, Performance oder sonstige Tugenden außer "billich" und "USB-Interface". :D Sind halt "last line of defense", wenn z.B. einer das gesamte Equipment aus dem Keller klaut oder die Hütte abfackelt...

Und ansonsten @HerrRossi: Unwissenheit schützt nicht vor Strafe ...äh... Datenverlust. ;) IT ist so scheiß-komplex, wenn man es richtig machen will. :( Man merkt dann schnell, warum im Enterprise andere Regeln/Produkte/Preise gelten und was die alles so können/machen, bringt einen (mich jedenfalls ;) ) bisweilen schon zum Staunen & Nachdenken.
 
Ich denke trotzdem, dass ich die Backup-HDD storniere und die Ironwolf nehme.

Noch eine Frage zu XFS: ist das richtig, dass kleine Dateien enorm viel Platz brauchen? 1MB scheint die kleinste Größe zu sein, das summiert sich dann natürlich gewaltig bei vielen Dateien. Was kann man dagegen tun?
 
Keine Ahnung. :(
 
1MB schein unrealistisch, die Blocksize bei XFS sollte irgendwo zwischen 512 Byte und 64 KByte liegen, und kann von dir während der Partitionserstellung eingestellt werden. Die Stripesize des RAID-Arrays sollte nicht zu Platzverschwendung führen, aber eine kleinere Stripe Unit kann zu kürzeren Zugriffszeiten führen, wenn viele kleine Dateien vorhanden sind, und häufig in zufälliger Folge gelesen werden.
 
Oben Unten