• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

ZFS Installation jetzt mit RAID10 möglich

cabriofahrer

Well-Known Member
Themenstarter #1
Ich hatte noch nie ZFS wirklich auspobiert, doch ich hatte immer gehört, dass zumindest bei einer Installation RAID10 nicht möglich sei. Korrigiert mich bitte, wenn ich falsch liege. Doch heute habe ich erfreulicherweise festgestellt, dass bsdinstall nun doch diese Option anbietet. Finde ich gut! Hier der Screenshot:
 

Anhänge

medV2

Well-Known Member
#2
Möglich war das defintiv schon immer, aber vielleicht musste man den ZPool selbst in der Console anlegen, und nicht bequem über den installer.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#4
RAID-Z ist auch möglich. Wenn man von größeren Pools booten will, muss nur das BIOS alle Platten sehen. Und gerade ältere BIOSe aus der Vor-UEFI-Zeit begrenzen oft auf die ersten 8 Festplatten. Wenn das BIOS noch Floppycontroller sieht, sind es meist sogar nur 6.
 

cabriofahrer

Well-Known Member
Themenstarter #5
Das war doch schon immer möglich, damit meine ich, seit dem die Installation von ZFS mittels bsdinstall möglich ist. "Neu", d.h. wie sich hier ergeben hat, mindestens seit Ende 2017 ist die Möglichkeit von RAID 10.

Wo wir schon bei dem Thema sind: (Ab) wann und für welche Fälle empfieht sich RAID 10 gegenüber anderen RAID-Z, z.B. RAID-Z1(RAID5)? Vor und Nachteile?
 

gadean

Well-Known Member
#6
RAID-Z1/2 (RAID5/6) sollte man meiner Meinung nach meiden, klar ist RAID10 teurer, aber bietet dafür mehr Sicherheit und Performance im Vergleich.
 

gadean

Well-Known Member
#8
Warum sollte die Größe der Platten eine Rolle spielen? Wenn ich ein System erstelle, kaufe ich mir min. 4x die gleiche Platte.
 

marmorkuchen

Well-Known Member
#9
Warum sollte die Größe der Platten eine Rolle spielen? Wenn ich ein System erstelle, kaufe ich mir min. 4x die gleiche Platte.
Weil das Resilvern längert dauert je größer die Platten bzw. Datenmenge wird. Kannst ja mal nachrechnen wie lange es dauert eine 4 TB Platte zu beschreiben und fällt in der Zeit eine weitere Platte ungünstig aus, war es das mit dem Pool. Sprich komplett neu aufbauen und Backup wieder einspielen...
 

gadean

Well-Known Member
#10
Das Problem hast du bei RAID-Z doch ebenfalls, klar bei Z2 können zwei DIsks ausfallen, aber dafür brauch es länger beim resilvern (und jede zusätzliche Disk im VDEV verschlechtert die Zeit erheblich).
 

marmorkuchen

Well-Known Member
#11
Ab 4 TB nehme ich aus besagten Gründen immer RAIDZ2 oder RAID6. Es hat schon seinen Grund warum z.B. NetApp intern seine RAID-Groups mit RAID6 abfrühstückt.
 

gadean

Well-Known Member
#12
Kannst du ja gerne machen, ich sag nur das ICH es meiden würde und die Aussage "Firma XY benutzt das" würde ich nicht als Argument nehmen.
 

marmorkuchen

Well-Known Member
#13
Kannst du ja gerne machen, ich sag nur das ICH es meiden würde und die Aussage "Firma XY benutzt das" würde ich nicht als Argument nehmen.
Bleibt Dir natürlich überlassen. :-) NetApp hab ich nur als Beispiel angeführt, warum sollte man nicht von den Fehlern der "Alten" lernen? Wir stehen doch auf den Schultern von Riesen. Genug abgeschweift. :-)
 

gadean

Well-Known Member
#15
Ich bin mir nicht ganz sicher, aber ich meine schon, darüber mache ich mir aber nicht wirklich Gedanken.
Mein Server hängt an einer USV und selbst wenn etwas passieren sollte, ist nicht das ganze RAID, sondern nur die letzten geschriebenen Daten betroffen (nach meinem Verständnis).
 

mr44er

moderater Moderator
Mitarbeiter
#16
Ist dann eine RAID-Z1-Lösung alleine deswegen nicht schon wesentlich besser/sicherer?
Es ging nicht um das write hole. Es ging um Festplattengröße / rebuild vs. Zeitfenster wenn währenddessen eine zweite Platte verglüht.

Anschauliches Beispiel:
Früher™ waren Festplatten viel teurer und die Kapazitätssprünge nicht so doll. raid5/raidz1 braucht nun mindestens 3 Platten. Der Einfachheit halber nehmen wir 3 Platten mit je 100GB. Brutto also 300GB und netto durch Parität 200GB nutzbar. Das hat man früher zähneknirschend eben hingenommen.
Wir schieben nun unsere Linux-ISOs und Urlaubsvideos aufs RAID, es passt zufällig genau drauf. Die 200GB sind also nun voll belegt.
Eine dieser Platten geht nun kaputt, zum Glück sind die Daten noch verfügbar, raid schützt ja vor allem! :rolleyes:
Coole Nerds zaubern sofort eine neue 100GB aus dem Ärmel, bauen die kaputte ein und starten den rebuild. Nach 10 Minuten ist das raid wieder gesund, es mussten ja nur 100GB geschrieben werden und ein bisschen Parität berechnet werden.

Nehmen wir nun das gleiche Beispiel mit 3x1000GB-Platten. 2000GB sind belegt, eine Festplatte ist kaputt. Wir starten sofort den rebuild, nachdem wir den Defekt bemerken und haben nun ein Zeitfenster von 100 Minuten. Naja ärgerlich, aber RAID schützt ja vor allem! Ohje, nach 93 Minuten stirbt die zweite Festplatte. Game over, raid kaputt.

Nicht jeder hat sofort eine Ersatzplatte parat, das Zeitfenster mit Schweiß auf der Stirn beginnt nämlich ab Defekt einer Platte und nicht ab rebuild. Die verbleibenden zwei gesunden Platten haben nun auch schon drei Jahre Laufzeit auf dem Buckel, ab und an Zugriffe erfahren, wenn mal ein Urlaubsvideo abgespielt wird. Nach 48 Stunden wird die Ersatzplatte geliefert, wir tauschen aus und starten den rebuild. Ein rebuild erfordert Vollgas auf den Platten, waren sie bisher nicht gewohnt. Somit steigt die Wahrscheinlichkeit des Totalausfalls nochmal. Ohje, wir erfahren das direkt. Nach 24 Minuten stirbt die zweite Festplatte. Game over, raid kaputt.

Clevere Sparfüchse haben sogar raid5 mit 8 oder mehr Platten gebaut, weil da ist der 'Verlust' der Kapazität einer Platte ja nicht so schlimm (8x100GB = 700GB netto nutzbar). Problem1 bei der Sache ist, dass von 8 Platten eher eine stirbt, als bei 3. Problem2 bei der Sache ist, dass wenn eine defekt ist und man den rebuild startet, von 7 Platten eher eine stirbt als bei 2.
Dazu kommt das verlängerte Zeitfenster je 'breiter' (mehr Platten=breiter) das raid ist, umso langsamer. Gerade hinsichtlich der Paritätsberechnung.

Du kannst frische, neue Platten mit 14TB-Kapazität haben. Wenn du damit raid5/raidz1 fährst und eine stirbt direkt am Anfang durch z.B. Produktionsfehler, hast du alleine schon durch die Kapazität ein ewig langes Zeitfenster.
Daher wirkt man mit raidz2 der Ausfallwahrscheinlichkeit entgegen. Dh. es können entweder zwei Platten auf einmal sterben oder es darf innerhalb des rebuild-Zeitfensters eine sterben.
raidz3 entsprechend dann mehr.

Wie immer: Backup, Backup, Backup! ;)
 

marmorkuchen

Well-Known Member
#17
Interessanter ist eher: Restore, Restore, Restore :-)
zumal ich bei den Datenmengen stark selektieren muss. Wichtige Daten werden gespiegelt und/oder auf LTO3 geschrieben. Die ganzen MKVs dagegen müsste ich dann wieder neu Rippen...
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#20
Wobei die langen Scrub- und Resilver-Zeiten sich mit dem neuen Scrub-Code ab ich meine FreeBSD 12.0 für RAID-Z auch sehr relativiert haben.
 

Kamikaze

Warrior of Sunlight
#21
Eine Hot-Spare sollte schon drin sein
Dann lieber das Z erhöhen. Dann ist das "Spare" beim Ausfall schon beschrieben.

Bei meinem RaidZ2 ist kürzlich auch eine Platte ausgefallen. Ich hatte immer noch eine Platte Redundanz ohne, dass ein Spare resilvered werden musste und konnte mir ruhig eine neue Platte bestellen. Raid-Z2 ist wie Raid-5 mit Hot spare nur dass die Spare nicht resilvered werden muss. Wenn Du RaidZ2 + Hot spare machen willst, fährst Du mit Raid-Z3 besser.
 

medV2

Well-Known Member
#22
Diese Angst, dass beim resilver eine weitere Platte stirbt... Alle Platten die man als normalsterblicher so bekommt sind auf Lesezyklen optimiert. Ihr habt ja auch keine Angst bei einem Scrub oder einem Full-Backup - beides Dinge die auch alles einlesen.

Natürlich ist es etwas "stressig" wenn die Redundanz weg ist. Aber der Angstfaktor ist da ähnlich eines Bitfehlers trotz ECC Rams oder Hashkollisionen bei sha256 Dedup. Ja, es kann nicht ausgeschlossen werden, aber dafür gibts ein Backup und man kann sich nicht um jede Unwahrscheinlichkeit kümmern.
Und nein, anektotische Evidenz ist kein Beweiß, dass das ja garnicht so unwahrscheinlich ist..
 

Kamikaze

Warrior of Sunlight
#23
Diese Angst, dass beim resilver eine weitere Platte stirbt...
Spare hat halt 0 Vorteile gegenüber Z+1. Braucht die gleiche Menge Platten und Z+1 hat weniger Risiken. Dass das unwahrscheinliche Risiken sind mag sein (wenn Du die Fehlerrate von Festplatten auf die Datenmengen hochrechnest ist das übrigens gar nicht sooo unwahrscheinlich). Aber so oder so kannst Du diese Risiken mit Z+1 gegenüber Hot spare verringern.
 

medV2

Well-Known Member
#24
Spare hat halt 0 Vorteile gegenüber Z+1. Braucht die gleiche Menge Platten und Z+1 hat weniger Risiken. Dass das unwahrscheinliche Risiken sind mag sein (wenn Du die Fehlerrate von Festplatten auf die Datenmengen hochrechnest ist das übrigens gar nicht sooo unwahrscheinlich). Aber so oder so kannst Du diese Risiken mit Z+1 gegenüber Hot spare verringern.
Es war nicht unbedingt auf deinen Post sondern allgemein auf das hier geschriebene. Ich weiß nicht wie es im Detail bei ZFS umgesetzt ist, vielleicht weiß ja @Yamagi hier Details, aber in der Theorie sollte RaidZ1 deutlich ressourcenschonender sein als RaidZ2/3. Für letztere brauche ich Reed/Solomon, für erstes sollte ein einfaches XOR genügen. Im Normalfall gebe ich dir aber recht, ein ZX+1 sollte sinnvoller sein als Z1 + Spare.
 

marmorkuchen

Well-Known Member
#25
Es war nicht unbedingt auf deinen Post sondern allgemein auf das hier geschriebene. Ich weiß nicht wie es im Detail bei ZFS umgesetzt ist, vielleicht weiß ja @Yamagi hier Details, aber in der Theorie sollte RaidZ1 deutlich ressourcenschonender sein als RaidZ2/3. Für letztere brauche ich Reed/Solomon, für erstes sollte ein einfaches XOR genügen. Im Normalfall gebe ich dir aber recht, ein ZX+1 sollte sinnvoller sein als Z1 + Spare.
Diese Angst, dass beim resilver eine weitere Platte stirbt... Alle Platten die man als normalsterblicher so bekommt sind auf Lesezyklen optimiert. Ihr habt ja auch keine Angst bei einem Scrub oder einem Full-Backup - beides Dinge die auch alles einlesen.

Natürlich ist es etwas "stressig" wenn die Redundanz weg ist. Aber der Angstfaktor ist da ähnlich eines Bitfehlers trotz ECC Rams oder Hashkollisionen bei sha256 Dedup. Ja, es kann nicht ausgeschlossen werden, aber dafür gibts ein Backup und man kann sich nicht um jede Unwahrscheinlichkeit kümmern.
Und nein, anektotische Evidenz ist kein Beweiß, dass das ja garnicht so unwahrscheinlich ist..