[Sammelthread] ZFS Stammtisch

Und nach "Murphy's Law" ist die Wahrscheinlichkeit, daß genau die 2. HDD aus dem degradeten Mirror ausfällt ungleich höher, als daß eine Platte aus eiem anderem Mirror ausfällt, Hauptsächlich auf Grund der Belastung beim Resilvern.
Dafür braucht man eigentlich nichtmal einen Statistiker bemühen.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich finde in diesem Zusammenhang ja diesen Artikel lesenswert.

Nach diesem ist die Gefahr, dass ein RaidZ-vdev beim Resilvern gänzlich den Geist aufgibt ungleich grösser, als bei einem Mirror-vdev, da beim Mirror das komplexe und lang dauernde Wiederaufbauen der Parität entfällt. Quote: "Resilvering a mirror is much less stressful than resilvering a RAIDZ." Auch bleibt beim Resilvern das Mirror-Setup weiterhin gut nutzbar.
 
Ich finde in diesem Zusammenhang ja diesen Artikel lesenswert.

Nach diesem ist die Gefahr, dass ein RaidZ-vdev beim Resilvern gänzlich den Geist aufgibt ungleich grösser, als bei einem Mirror-vdev, da beim Mirror das komplexe und lang dauernde Wiederaufbauen der Parität entfällt. Quote: "Resilvering a mirror is much less stressful than resilvering a RAIDZ." Auch bleibt beim Resilvern das Mirror-Setup weiterhin gut nutzbar.
Stress für wen?

Ich würde sagen, daß 99% des erhöhten Streßes auf die CPU gehen, die Platten müssen weiterhin nur lesen und schreiben - trotzdem wird das Resilvern eines Raidzx länger dauern als bei einem Mirror.
Mirror aus 2x2 TB >> HDD1 muß max. 2TB lesen, HDD2 muß max 2 TB schreiben
Raidz1 aus 3x2TB >> HDD1 & 2 müssen jeweils max. 2 TB lesen, HDD 3 muß max. 2TB schreiben
Richtig ist das die gelesene Gesamtdatenmenge bei Raidzx mehrfach höher ist als bei einem Mirror, die geschrieben Datenmenge ist jedoch die gleiche, die Last pro HDD ist identisch...

Ausnahme: 3way/nway Mirror.
Die Gelesene Datenmenge pro Quell HDD reduziert sich durch die Anzahl der Quell HDDs.

Das ist also wieder so ein typisches "Bullshitbingo", das dauert länger, also muß da mehr Last auf den HDDs sein ;)
 
Es ist ja eine Gesamtbewertung aus Speed, Dauer eines Resilvering, Performance während des Resilvering, Flexibilität beim Vergrößern des Pools, Industry Best Practice, I/O Last, etc. ...

Auch wenn es nicht "business critical" ist, habe ich für mein Heim-napp-it die Mirror-Variante gewählt. Ich habe gelinde gesagt die Schnauze voll, auf mein NAS 1,5 Wochen zu warten, wenn ne Platte den Geist aufgibt. Bei der letzten Havarie hat es fast 3 Wochen gedauert, bis ich wieder produktiv sein konnte (Synology - Raid-5).

Aus Gründen der Convenience nehme ich den Kapazitätsverlust hin. Ich werde allerdings erst noch sehen müssen, wie sich das Ganze im Havariefalle in meinem jetzigen Setup verhält ... q.e.d

PS: Ich schreibe explizit nur über die "Verfügbarkeit" des NAS im Heimnetzwerk. Für die Daten selbst habe ich Backups. Ganz so, wie es sich gehört :d
 
@gea
funktioniert der split-Befehl auch wenn es mehrere vdev's sind? Wird dann ein neuer pool gebildet aus je einer HDD von jedem vdev?


Ich habe das gerade mal in meiner Test VM gemacht.

Bei einem Pool wie deinem kommt dann sowas raus
2 way mirror.JPG

Bei einem 2 Way 3 vdevs dann das hier.

3way.JPG

Das Ergebnis ist dann wohl ein Pool über 2 einzelne vdevs - wenn ich das Ergebnis richtig deute.

Code:
zpool split  trinity trinity1 mirror sde sd
Das funktioniert jedenfals nicht - war einfach mal ein gut Glück Versuch.

Machen sollte man es wohl eher nicht.
 
Zuletzt bearbeitet:
Der Stress ist doch da ganz klar erklärt, lesen muss man schon können.

In no case are you re-writing entire stripes, all other vdevs in the pool are completely unaffected, etc.

Each block resilvered on a RAIDZ vdev requires a block to be read from each surviving RAIDZ member; each block written to a resilvering mirror only requires one block to be read from a surviving vdev member. For a six-disk RAIDZ1 vs a six disk pool of mirrors, that’s five times the extra I/O demands required of the surviving disks.

Und ja, bei aktuellen Plattengrößen von bis zu 10TB packt man da echt viel Stress auf die anderen Platten. Im Idealfall dann alle bei der Bestellung aus einer Charge, gleich alt, gleich abgenutzt -> höhere Chance, dass beim resilvern noch eine aussteigt.
 
Und ja, bei aktuellen Plattengrößen von bis zu 10TB packt man da echt viel Stress auf die anderen Platten. Im Idealfall dann alle bei der Bestellung aus einer Charge, gleich alt, gleich abgenutzt -> höhere Chance, dass beim resilvern noch eine aussteigt.

Yepp ... genau das habe ich schon erlebt, mit 5 Jahre alten Platten. Das ist mit Backup zwar kein Totalschaden, aber kostet enorm viel Zeit. Und so bin ich dann bei napp-it und zfs gelandet. Der oben verlinkte Artikel hatte den Ausschlag gegeben, dieses NAS-System zu wählen (plus natürlich dieser Thread und gea's unermüdliche Hilfe hier und anderenorts) :d
 
Zuletzt bearbeitet:
@morph
ich habe nichts anders geschrieben, nur halt auf deutsch!
Du kannst natürlich die Leseanforderungen über alle Platten addieren und sagen, daß das ja eine höhere Last ist, das stimmt aber nur für das Gesamtsystem, nicht aber für die einzelne Platte.
 
Zuletzt bearbeitet:
Dann sind wir uns ja einig ;) Am Schluss ist jeder Poolaufbau abhängig von den Anforderungen. Aktuell bau ich aus kleinen SSDs auch wieder vermehrt RAIDZ1 für VM Knoten. Aber klassischen Storage setz ich lieber auf mirrored vdevs.
 
Grüße an alle,

nach langer Überlegung will ich meinen Media Storage auf ZFS umstellen. Dabei geht es mir ausschließlich um die Datenkonsistenz sowie die RAID-Möglichkeiten.
Zwecks Informationsgewinn habe ich mir so einiges angelesen, altes und neues. Ich weiß, dass ZFS auf Solaris, OmniOS Nexenta sowie FreeBSD und FreeNAS "zuhause" ist. Dann gibt es da noch ZFS on Linux, welches mit Ubuntu ausgeliefert wird.
Auf meinem Media Storage ist Emby Server Pflicht, und den gibt es für Windows, Linux, FreeBSD (in den Ports), FreeNAS (da aber immer hinterhinkend!) sowie als Docker Container. Außerdem hätte ich sehr gerne Hot Spares, die auch automatisch einspringen.
Windows will ich nicht mehr (kann ja auch kein ZFS!), mit FreeBSD kenne ich mich absolut nicht aus und bei FreeNAS muß man immer darauf warten, dass einer ein PBI-Paket erstellt, was auch schon mal dauern kann. Bei den BSD-Systemen weiß ich, dass das mit den Hot Spares funktioniert. Ubuntu kenne ich recht gut, allerdings habe ich recht widersprüchliche Informationen über Hot Spares bei ZoL.
Und daher hoffe ich auf Erleuchtung von euch. Kann ZoL nach aktuellem Stand mit Hot Spares umgehen (ich las was von autoreplace)? Werden meine Hoffnungen erfüllt?!

Vielen Dank im Voraus!
 
Zuletzt bearbeitet:
NAS4Free,
- One Button Installer extension installieren
- via OBI "The Brig" als Jail Manager installieren
- emby im Jail installieren
[EXTENSION] OneButtonInstaller - NAS4Free
[HOWTO] Install TheBrig - one Jail manager for N4F - NAS4Free
Emby Server - NAS4Free

satt FreeBSD könntest du dir auch mal TrueOS | FreeBSD Desktop Operating System with ZFS - TrueOS anschauen - ist ein FreeBSD Fork, der sich aber von vornherein auf ZFS konzentriert (inkl. rpool)

P.S. wen auch Plex ginge, das kann direkt via OBI installiert werden

("but there are two major problems with emby
- no Russian kinopoisk plugin (not a problem for English speaking folks of course)
- server could not work with huge libriaries
I have for testing 2Tb flac library and had feed it to emby. After it was swallowed (long time, but who cares) I had tried use emby. But bot android app and web access becames extermelly slowly. So I had returned to plex")
 
Zuletzt bearbeitet:
Zuerst einmal vielen Dank für die Reaktion.

Mir geht es aber ausschließlich darum, ob Hot Spares bei ZFS on Linux funktionieren. Denn mit Ubuntu kenne ich mich wenigstens aus, mit den ganzen BSDs absolut nicht.
Außerdem werden die Plugins für NAS4Free und FreeNAS nicht offiziell supportet, sie werden von einem einzigen Mitglied erstellt. Und ich will definitiv offiziellen Support haben!

Plex kenne ich, aber ich mag es absolut nicht! ;)
 
Zuletzt bearbeitet:
Bei mir läuft Openmediavault3 mit ZoL und Docker Plugin. Über das Docker Plugin habe ich mir dann unter anderem das Emby Image gezogen. Das habe ich mit anderen Mitgliedern auch im Kodinerds Forum besprochen. Vielleicht hast du den Beitrag gelesen. Das Emby Image wird glaube ich auch von Emby Entwicklern bereitgestellt. Einziger Nachteil Emby im Docker Container zu betreiben ist wohl, dass das Transcoding komplett über die CPU läuft und die GPU dafür nicht genutzt werden kann. Bei mir ist das allerdings egal, da mein Server grundsätzlich performant ist und sowieso keine "vernünftige" GPU verbaut ist.

ZoL läuft bei mir seit knappen 1,5 Jahren stabil. Einziger Bug von dem ich betroffen bin ist, dass ich einen Checksum-Fehler erhalte, wenn ich meine Platten mit ZoL aus dem Standby hochfahre. Der Bug ist bei github dokumentiert. Seither werden die Platten nicht in den Standby gefahren, obwohl es sich nur um einen Schönheitsfehler handelt. ZoL funktioniert trotz der Fehlermeldungen im Syslog einwandfrei.

OMV3 setzt zwar Debian als Basis ein, aber das ist ja vom Handling her dasselbe wie Ubuntu. Vielleicht ist es dir einen Test wert. Inwiefern ZoL Hotspare beherrscht, weiß ich nicht.

Gruß Hoppel
 
Zuletzt bearbeitet:
Autoreplace und Hot Spare sind unterschiedliche Dinge. Mit Autoreplace wird ein Rebuild angesteuert wenn du eine defekte Platte ersetzt. Grundsätzlich ist beides unter ZoL möglich, ich würde dann aber überlegen warum du nicht gleich auf Raidz2 setzt.
 
@VirtuGuy: Ich gehe ja sogar noch ne Ecke weiter und will dann RAID-Z3 einsetzen!

Mir geht es einfach darum, dass das System eine kaputte Platte mit einer solchen Spare-Platte automatisch ersetzt und den Rebuild anstösst! Und noch schöner wäre ein automatisches Copyback, wenn die kaputte Platte durch eine intakte ausgetauscht wurde und damit ja wieder da ist.
 
Autoreplace bedeutet dass im Falle eines Plattenausfalls nach einem Plattenwechsel automatisch ein Rebuild (Disk-Replace) gestartet wird. Das klappt aber nur wenn die neue Platte die gleiche ID hat wie die alte also z.B. c0t0d1 (erster Controller, erste Platte, ITler fangen bei 0 an zu zählen) oder hda. Also im Klartext wenn die Platte anhand des Controller-Ports identifiziert wird.

Das ist - zumindest bei Solarish und aktuellen Plattencontrollern- nicht mehr der Fall. Da nutzt man WWN als ID. Das ist eine Nummer die der Hersteller der Platte in der Platten-Firmware festlegt Selbst wenn man damit einen ZFS Pool in einen anderen Server mit anderen Kontrollern verschiebt, kennt ZFS sofort seine Platten.

Autoreplace ist also bei neuen Systemen obsolet.
Hotspare bedeutet, dass man eine Reserve-Platte bereitstellt die im Falle eines Plattenausfalls diese automatisch ersetzt. Dazu wird ein spezieller Fehler-Service wie Solaris FMD benötigt. Bei Solarish gibt es das seit Anbeginn von ZFS. Bei BSD und ZoL ist das bei neueren Versionen auch möglich.
 
Zuletzt bearbeitet:
@gea: Vielen Dank für die Antworten! Damit kann ich nun frohen Mutes ans Werk gehen! ;)

Ach ja: Beherrscht ZFS bzw. ZoL auch Copyback?
 
Mir geht es einfach darum, dass das System eine kaputte Platte mit einer solchen Spare-Platte automatisch ersetzt und den Rebuild anstösst! Und noch schöner wäre ein automatisches Copyback, wenn die kaputte Platte durch eine intakte ausgetauscht wurde und damit ja wieder da ist.

Das geht wohl etwas durcheinander bzw. ist noch nicht richtig verstanden. Der Rebuild erzeugt am Ende quasi zunächst eine "Kopie" der ausgefallenen Platte, so dass die nach Rebuild eben "wieder da" ist (oder richtiger: die Daten des Arrays wieder komplett und "richtig" über die Platten verteilt vorhanden sind). Man muss aber eben dem Array/OS auch einmal mitteilen, dass eine Platte - die plötzlich durch Einstecken im System erscheint/verfügbar wird - auch für das Array genutzt werden darf. Das macht standardmäßig kein OS von sich aus (außer größere SANs oder sonstige reine Storage-Systeme vielleicht). Ein normales OS wird Festplatten erkennen, sich darüber freuen und es dem Admin überlassen festzulegen, was damit passieren soll.

Daher muss man für jede Platte im System, die für das Array verwendet werden soll, - auch für neue - eben einmal die hardware dem Array zuweisen. Ist aber nicht so schlimm, wenn man die Platte reinsteckt machste das halt mal direkt im Anschluss und kannst Dich dann bis zum nächsten Ausfall beruhigt wieder hinlegen.

Ob man das ZFS auch als Automatismus beibringen kann (jede neue Platte = hotspare für PoolXYZ)? Keine Ahnung, wahrscheinlich durch Scripte irgendwie schon...

Ansonsten könnte man das als einen Mechanismus verstehen, der automatisch einen verwendeten "Spare" (Platte A) wieder freigibt, sobald eine weitere Platte B (als "dauerhafter Ersatz" für die urpsr. ausgefallene Platte 0) dem System hinzugefügt wird. Also das System die 2. neue Platte B dauerhaft nutzt und die hotspare Platte A wieder als Reserve.

Meiner Meinung nach völliger Unsinn, da total unnötig Riesenstress auf dem ganzen Verbund erzeugt wird (2. Resilvern) oder zumindest einmal komplett ein Datenträger gespiegelt/kopiert wird, für null Mehrwert. Warum soll Platte B besser sein als Platte A? Das Ganze macht in meinen Augen überhaupt nur Sinn, wenn die Übergangslösung (Platte A) technisch/volumenmäßig nicht zum Gesamtverbund passt - dann hat man aber bei der Auswahl der Hotspare-Platte (Platte A) bereits etwas falsch gemacht...was man dann nachträglich durch Einbau von Platte B korrigieren muss.

Das macht ZFS schon richtig: hotspare Platte A wird automatisch genutzt (wenn als Hotspare definiert). Steckst Du eine weitere Platte wieder dazu, muss diese neue Platte B eben (nur) ggf. wieder als hotspare definiert werden.
 
Zuletzt bearbeitet:
Er meint damit, dass wenn die defekte HDD ausgetauscht wurde, das System automatisch die Daten von der Hot Spare auf die neue zurück kopiert und die Hot Spare wieder zur Hot Spare wird.
 
Jo, wie das gehen soll, raff' ich aber nicht. Wird wohl selten die ehemals defekte Platte wieder ins System zurück kommen. Allenfalls an den gleichen "Platz" (Controller-Port). Den Sinn versteh' ich aber noch weniger. Zumal man bei ZFS - wenn richtig konfiguriert - die Hotspare-Platte ja einfach nach dem Rebuild in den alten Platz der defekten Platte stecken kann, wenn die physische Lokation denn ein ausschlaggebendes Kriterium ist.
 
Ich schätze, dass ist eher ein optisches Ding zur besseren Sortierung.

Zb.
Reihe 1 = Pool 1
Reihe 2 = Pool 2
Reihe 3 = Hot Spares

oder ähnlich.
Kann ZFS eigentlich globale Hot Spares oder "nur" Pool bezogene ?

Aber wie du schon meintest, die HDD belastung durch solche "späße" sollte man nicht außer Acht lassen.Da steckt man dann doch lieber die HDD um - wenn es wegen der besseren Sortierung etc. ist.
 
Zuletzt bearbeitet:
m.W. nur poolbezogene. Müsste ja sonst auch mindestens von der Größe zu den größten einzel-Devices im System passen. Das wäre dann je nach Ausfall ggf. Perlen vor die Säue.

Ob man auch einen Ausfall im SSD-Pool nun durch einen HDD-Spare flicken will, wage ich auch mal zu bezweifeln...

Das Konzept sollte doch eher sein, vergleichbare Devices alle in einen Pool zu hängen. Dazu hast Du ja die Möglichkeit, mit den vdevs, die Du nach Lust und Laune definieren kannst und dann dem Pool hinzufügen.

Für unterschiedliche Anforderungen, unterschiedliche Pools. Dann macht eben auch ein pool-übergreifendes Spare wenig Sinn.
 
Zuletzt bearbeitet:
Ja gut, das ist wahr - eine SSD durch eine HDD tauschen, ist nun nicht das gelbe vom Ei..

Mein Gedanke war da auch eher, dass man einen Pool aus Hot Spares definieren kann und diesen dann ggf. mehreren aber Festplatten identischen Pools zu Ordnen kann.

Wenn ich zb 3 HDDs übrig habe, muss ich nun entscheiden welche ich welchem Pool als Spare zuweiße - bei dem Pool haben beide Pools zugriff auf 3 Spares - je nachdem wo was ausfällt.
 
Zuletzt bearbeitet:
Wie gesagt, dann lieber aus diesen verschiedenen Pools einen großen bauen, dabei ein zwei Überlegungen zur Parity anstellen (RaidZ2 oder 3?) und dann eben dem Pool alle drei Hotspares zuweisen. Fertig. Wenn Du 3 HDDs über hast, kannste daraus ja auch ein Übergangs-RaidZ-vdev oder Pool für die Migration machen...

Bei mir stecken daher gleiche Platten alle in einem einzigen Pool verteilt auf 3 Pools (4TB, 1TB und SSDs).
 
Wie bereits hier erklärt wurde, ist Copyback das Zurückspielen des Inhaltes der Spare-Platte auf die "originäre" Platte. Hat bei mir u.a. organisatorische Gründe und auch der Übersicht wegen.
Bei meinem Adaptec Controller (und so ziemlich allen mir bekannten HW-RAID-Controllern!) sind das aktivierbare Features und ich habe es stets sehr zu schätzen gewusst. Mag nicht jedem einleuchten, aber bei mir muß alles seinen Platz und seine Ordnung haben! ;)
 
So funktioniert ZFS Raid nicht. Ohne Prüfung, keine Aktion. Ein ZFS Replace ist also niemals das ungeprüfte Duplizieren der Platte.

Wenn eine Platte ersetzt wird, geht ZFS alle Metadaten durch und prüft ob sich Daten auf der entsprechenden Platte befinden. Nur diese Daten werden kopiert. Bei einem fast leeren Pool dauert ein Replace nur Sekunden. Bei einem sehr vollen Pool skaliert das mit der iops Leistung des Pools und der Frage wieviel Daten sich im RAM befinden.

Folgender Blog beschreibt das ganz gut, nicht nur fürs schnelle sequentielle Resilver (Oracle Solaris only)
Sequential Resilvering | Bizarre ! Vous avez dit Bizarre ?

zu Hotspares
Ein Hotspare wird einem Pool zugewiesen. Man könnte die gleiche Platte auch einem anderen als Hotspare zuweisen (globales Hotspare). Sollte man aber nicht machen. Wenn in beiden Pools eine Platte ausfällt, wäre ich mir nicht sicher ob nicht etwas unerwartetes passiert.

Ich würde auch niemals mehr als 1-3 hotspares definieren sondern bei mehreren die nicht zuweisen. Ansonsten passiert z.B. bei einem wackligen Stecker bei dem sich Platten kurz an- und abmelden die abenteuerlichsten Poolzustände mit vielen Resilverings. Kann man alles beheben. Beim erstenmal ist das nicht lustig, wenn viele platten resilvern und alle hotspares aktiv sind.
 
Ich habe ja auch nicht gesagt, dass das ungeprüft geschehen soll. Mir ist halt wichtig, dass die Hot Spares ihre Aufgabe auch nur so lange durchführen, bis die kaputten Platten durch intakte ausgetauscht wurden. Da kann ZFS dann gerne vorher prüfen ob alles in Ordnung ist und dann eben die Spare Disk leer schaufeln!
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh