FreeNAS / TrueNAS: RaidZ2 oder mirror?

[hs_warez]

Bin noch am Herumtesten mit meinem "TrueNAS" und auf div. Beiträge/Meinungen zum Pool gestoßen.

Derzeit 3x 6TB Seagate Iron Wolf mit RaidZ1.

Habe jetzt noch eine günstige neue HDD (gleiche wie oben) bekommen und werde den Pool neu aufbauen.

Was ist denn jetzt mit 4 HDD's wirklich besser - RaidZ2, oder Mirror?


Danke!


LG

 

[tolga9009]

Mirror

 

[hs_warez]

Hm, so wie ich das verstanden habe:

RaidZ2 - egal, welche 2 der 4 HDD's ausfallen - es geht weiter - "resilver" ist aber intensiver/aufwändiger und ein möglicher erneuter HDD-Tod wäre möglich.

Mirror - wenn die 2 richtigen HDD's ausfallen, dann ist es vorbei. Falls eine "andere" HDD ausfällt, wäre "resilver" deutlich schonender/schneller als bei RaidZ2.


Habe ich das so richtig verstanden?

Wie sieht es performancemäßig aus - sollte wohl bei einem GBit-Netz egal sein, oder?


LG

 

[oNyX`]

https://www.ixsystems.com/blog/zfs-pool-performance-1/ und

Six Metrics for Measuring ZFS Pool Performance Part 2 | TrueNAS - Open Enterprise Storage

Learn more about why OpenZFS (ZFS) storage pool layouts have such a significant impact on system performance under various types of workloads.

www.ixsystems.com

tl;dr

Mirror fuer IOPS und Speed, RaidZx fuer Streaming Speeds und Kapazität

 

[tolga9009]

Wenn du bspw. 8 oder 12 Festplatten hättest, könnten wir hier schöne Pro- und Contra-Listen aufstellen und wild diskutieren: "ja, das RAIDZ2 hat X% mehr nutzbaren Speicher", "aber das RAID10 hat weniger Stress beim Rebuild". Bei 4 Festplatten ist die Liste an Pro-Argumenten für das RAIDZ2 sehr überschaubar.

In dem Fall von 4 Festplatten und Gegenüberstellung von RAIDZ2 vs Striped Mirror spricht nahezu komplett alles für den Striped Mirror: schnellerer und weniger stressiger Rebuild (1 Festplatte wird kopiert, statt gesamtes Array gestresst), niedrigere Latenz (z.B. Datenbanken, VM Storage), bessere Performance, keine Parity-Berechnungen (niedrigere CPU Last), einfache Erweiterung (2x neue Festplatten im Mirror dazu, fertig vs. 4 Festplatten *auf einmal* im RAIDZ2 ) und du hast trotzdem eine realistische Chance, mehrere Festplattenausfälle zu überleben.

Der einzige Punkt, wo das RAIDZ2 gewinnt, ist die garantierte Ausfallsicherheit von 100% bei 2 defekten Festplatten. Der Striped Mirror würde dich immerhin noch mit 66% vor Datenverlust bei 2 defekten HDDs schützen. 2 zeitgleich (!) defekte Festplatten in einem Array aus 15 Festplatten - das kann schonmal vorkommen. Wenn aber bei einem Array aus 4 Festplatten 2 wegsterben (oder: die Hälfte), dann hast du mit hoher Wahrscheinlichkeit ein größeres Problem und musst sowieso aufs Backup zurückgreifen.

Meiner Meinung nach bessere Diskussion: RAIDZ1 vs RAID10. Da kann man noch schön argumentieren: "18TB vs 12TB Storage", "vielleicht doch lieber 3x 6TB RAIDZ1 statt 4x 6TB RAID10", "garantierter Schutz vor 1 Ausfall vs. 66% Schutz vor 2 Ausfällen" usw.

Ganz egal wie ob nun RAIDZ1, Z2 oder RAID10. RAID ersetzt kein Backup. Das kommt immer noch oben drauf und muss von dir auch berücksichtigt werden. RAID ist nur für Uptime da, sonst nichts.

 

[hs_warez]

Danke für euren Input.

Das Raid ist natürlich keine Backup für mich.

Für die wirklich wichtigen Daten (Dokumente+Fotos) - alles Andere kann man sich wieder besorgen - hätte ich folgende Strategie:

- Regelmäßige Sicherung auf ein NAS in einem anderen Brandabschnitt - oder
- Regelmäßige Sicherung auf eine externe Cloud (Nicht ganz mein Liebling, da die Daten dann "extern" liegen.)

Mal sehen.



Bei Gb-Lan im Haus sollte es ja dann für die Geschwindigkeit völlig egal sein, welches "Raid" man wählt, oder?
Maximal greifen 2 Personen (Daten, oder Video-Stream) gleichzeitig drauf zu.

Werde dann vermutlich auf Mirror gehen.




LG

 

[oNyX`]

Bei gbit machts 0 unterschied, hab persönlich auch nen stripped Mirror (4x 8TB 2x2) + slog und l2arc. Macht bei 10G via Samba ~ 300-350mb/s. Als Raidz1 warens 450mb/s rum, dafuer halt Arschlahm bei IOPS (Speed von einer HDD)

Vorteil Mirror: wie schon erwaehnt, weniger CPU Overhead + Read IOPS von 4 Platten, Write IOPS von 2. Slog und L2arc kommen bei ISCSI und co nochmal on Top. Bei Samba kannst dir das Slog Device sparen, bringt nichts.

 

[hs_warez]

Ok, dachte ich mir schon, dass SSD-Cache bei meinem Anwendungszweck vermutlich nicht viel Sinn machen wird.

Derzeit sind 32 GB-ECC-Ram verbaut - mal sehen wie sich das verhält, wenn das NAS mal produktiv geht - zur Not rüste ich halt dann noch RAM auf.

Danke!


LG

 

[hs_warez]

So, hab jetzt mal begonnen ein paar größere Daten (Filme, Serien,..) ans NAS zu "schicken".
Irgendwie schwanken die Schreibraten immer - grob 80-118MB/s.

Mann kann beobachten, wenn die 32GB-ECC-Ram voll werden, dann bricht kurz die Schreibrate ein, bis wieder etwas vom RAM frei geworden ist.
In der Regel wird es vermutlich nicht so oft vorkommen, dass ich über einen längeren Zeitraum große Datenmenge verschiebe, aber etwas lästig ist dieses Phänomen trotzdem.


Hierfür wäre es ja hilfreich, wenn ich eine SSD als ZIL-Cache in den Pool reinhänge, oder?
Dann sollte die Schreibrate theoretisch dauerhaft bei gut 100MB/s liegen, oder?

Hätte ein paar ungenutzte SSD's (Sata / Intel 180 GB / Samsung 250 GB) herumliegen - die könnte ich ja hierfür nehmen, oder?
Oder wäre es "sinnvoll" eine kleine M2-SSD zu besorgen und zu verbauen? - vermutlich nicht, da die normalen SATA-SSD's ja auch schon deutlich schneller sind als die NAS-HDDS's, oder?

Danke!


LG

Beitrag automatisch zusammengeführt: 31.01.2021

Oder "einfach" RAM nachrüsten?

Ram müsste ich halt kaufen und ist teurer - die SSD's hab ich herumliegen.

Hm...

 

[gea]

So, hab jetzt mal begonnen ein paar größere Daten (Filme, Serien,..) ans NAS zu "schicken".
Irgendwie schwanken die Schreibraten immer - grob 80-118MB/s.

Mann kann beobachten, wenn die 32GB-ECC-Ram voll werden, dann bricht kurz die Schreibrate ein, bis wieder etwas vom RAM frei geworden ist.
In der Regel wird es vermutlich nicht so oft vorkommen, dass ich über einen längeren Zeitraum große Datenmenge verschiebe, aber etwas lästig ist dieses Phänomen trotzdem.


Hierfür wäre es ja hilfreich, wenn ich eine SSD als ZIL-Cache in den Pool reinhänge, oder?
Dann sollte die Schreibrate theoretisch dauerhaft bei gut 100MB/s liegen, oder?

Hätte ein paar ungenutzte SSD's (Sata / Intel 180 GB / Samsung 250 GB) herumliegen - die könnte ich ja hierfür nehmen, oder?
Oder wäre es "sinnvoll" eine kleine M2-SSD zu besorgen und zu verbauen? - vermutlich nicht, da die normalen SATA-SSD's ja auch schon deutlich schneller sind als die NAS-HDDS's, oder?

Hm...

Nein, so funktioniert ZFS nicht.

Beim RAM kann man so über den Daumen folgendes sagen. Ein 64bit OS braucht ca 2 RAM, bleiben also ca 30 GB. ca 10% davon also 3 GB sind RAM Schreibcache, ca 80% vom Rest ist Lesecache (Arc). Bei Free-BSD oder Linux eventuell minimal weniger das ZFS intern die RAM Verwaltung noch Solaris alike ist. Die RAM Auslastung ist also Lesecache. Der arbeitet übrigens nicht sequentiell oder filebasiert sondern read last/read most für kleine Datenblöcke. 80-118 MB/s ist ansonst garnicht so schlecht. Der multithreaded Solaris SMB Server könnte eventuell minimal mehr, ist aber schon ok so

Das "Pumpen" beim ZFS Schreiben liegt daran dass der Inhalt des RAM-Schreibcaches auf Platte geschrieben wird wenn er halb voll ist, so alle paar Sekunden. Währenddessen cacht die andere Hälfte. Da sbringt aber vor allem bei kleinen Dateien etwas da damit vermieden wird dass man kleine Writes hat. Da würde ansonst die Schreibrate gerne mal auf 5-10 MB/s einbrechen.

ZIL Cache
Es gibt keinen ZIL Cache. ZIL ist ein Bereich auf dem Datenpool den man für Protokollieren bestätigter Schreibvorgänge bei aktiviertem sync nutzt. Das ist kein Cache sondern eine Absicherung des RAM Schreibcaches. Slog ist gleiches auf einem eigenen Laufwerk.

Mit 32GB RAM wird die Erweiterung des RAM Lesecaches durch eine im Vergleich dazu langsame SSD (L2Arc) nichts bringen . Will man sicheres Schreiben mir Slog, so taugen die SSD nicht da man dann besondere SSD/NVMe braucht (Inteh DC 3700, WD SS 530, Intel Optane DC 4801) weil nur diese die benötigte Performance und Sicherheit wie plp bieten

 

[hs_warez]

Wenn nur ein kleiner Teil vom Ram als Schreibcache dient, warum ist mein Ram dann ausgelastet?

Das heißt, dieses „Pumpen“ kann ich nicht verringern?

 

[gea]

Der RAM ist ausgelastet weil der halt im Wesentlichen als Lesecache dient.
Das "Pumpen" kommt letztendlich davon dass man einerseits ultraschnell in den RAM schreibt, dann aber wohl warten muss bis der RAM Inhalt auf Platte ist. Verringern kann man das vor allem durch einen schnelleren Pool.

Bei einem 1G Netzwerk und 4 Platten als Raid 10 bzw Z2 sollte aber ein Schwankem 80 MB/s-118 MB/s bei 32 GB RAM nicht passieren, habe ich zumindest unter OmniOS und dem da in ZFS integrierten SMB Server so nicht gesehen.

Was man noch prüfen könnte ist, ob eine der Platten Schwächen zeigt. Jedes Raid ist nur so schnell wie die langsamste Platte.

 

[hs_warez]

Hm, betreibe jetzt 2 fast neue Seagate IronWolf 6TB in „mirror“.

wie/wo/was könnte ich denn prüfen?

 

[gea]

Entweder beim Schreiben z.B. über iostat oder was es bei Free-NAS gibt schauen ob beide Platten gleiche Last, busy, wait Werte haben oder ob eine schwächer ist. Alternativ aus jeder Platte je einen Basic Pool machen und vergleichen. Der Mirror kann dann nicht schneller schreiben als die langsamere der beiden.

Wären das MSR Platten dann wäre die Plattentechnologie schuld. Ironwolf ist das aber nicht.

 

[hs_warez]

Hab mal ein paar Screenshots in TrueNAS gemacht - kann mir da Einer beim Interpretieren helfen?

Ich sehe da keinen großen Fehler!?

Danke!


LG

 

[gea]

Beide Platten schreiben mit ca 95 MB/s. Das ist weniger als 1G Netzwerk, daher das Pumpen.
Mit einem lokalen Benchmarktool könnte man jetzt prüfen ob die Platten selber mehr könnten oder ob eher der SMB Server SAMBA limitiert.

 

[hs_warez]

Wo liest du die 95 MB/s - bin ich blind?
Ich lese "im Mittel 104 MB/s".

D.h. am Besten wäre, Festplatten raus in einen Windows PC rein und dann einen Benchmark starten, oder geht das in TrueNAS auch?
Mit den Daten passiert dann hoffentlich nix, wenn ich auf einem Windows-PC einen Benchmark starte, oder?

Danke!

LG

 

[gea]

Bringt nix da ein Windows Benchmark nicht vergleichbar wäre.

Es gilt halt:
Im Datenblatt steht eventuell sowas wie 250 MB/s sequentiell. Das ist das Fall wenn man die inneren Spuren einer leeren Platte nacheinander füllt. Also eher ein theoretischer Wert oder bei optimierten Benchmarks. Worst case sind kleine Datenblöcke die man random auf die Platte schreibt. ZFS Sync write ist da ein Beispiel. Da landet man bei 5-10 MB/s. Realworld mit normaler Nutzung liegt man dazwischen. Eine gute Platte sollte da im Schnitt bei vielleicht 120 MB/s landen je nach Füllrate und Testsequenz und eher sequentiellem Workload (Video). Bei ZFS ist zu beachten dass man hier nicht echte sequentielle Last hat da die Daten immer recht gleichmäßig auf dem vdev verteilt werden.

Wenn ein lokaler Benchmark aber 120 MB/s oder mehr bringt und über SMB "nur" 80-118 MB/s (stark schwankend) so liegt das sicher nicht an den Platten. Im Zweifel aber dennoch kein so schlechter Wert als dass man sich groß Gedanken machen müsste.

 

[hs_warez]

Das heißt, es liegt dann ev. am SMB-Dienst!?

Das Problem müsste ja dann Jeder haben, oder?
Kann man das irgendwie verbessern/umgehen - die Schwankungen?

LG

Beitrag automatisch zusammengeführt: 01.02.2021

Was mich halt etwas "ärgert":

Hab mir letztes Jahr mal ein gebrauchtes/günstiges Qnap TS-219P+ (für künftiges Backup) gekauft - 2 alte 7200er HDD's reingesteckt und habe problemlos um die 75 MB/s geschrieben.

Jetzt habe ich eine ums x-fache bessere Hardware im "TrueNAS" und es ist nur minimal schneller!?

 

[Trambahner]

Naja, 2 Platten sind halt 2 Platten. Da kann nicht die x-fach bessere Leistung auftreten. Bei ZFS hast Du zusätzlich auch noch mehr Overhead durch die Integritätssicherung und Copy-on-Write,

Was übers Netzwerk dann netto drüber geht, hängt auch an den Dateigrößen. Viele kleine Files => mööööp, langsam . Auch wenn Dein Pool aus SSDs besteht, auch wenn die Quelle eine SSD ist, es wird einfach entsprechend Overhead am Sender und Empfänger erzeugt.
Große Medienfiles => 1Gbit Lan wird gesättigt.

Btw, was Truenas teilw. mit dem Ram macht, hab ich bei meinen Versuchen damit auch nicht verstanden; auch bei der Nutzung von VMs. Allerdings bin ich kein Truenas-Experte.
Ich bin daher bei Xigmanas für die ZFS-Storage geblieben. Klein und schlank, dafür halt keine aufwändige Gui.
Ab FreeBSD12 und Raidz(2/3) muss man nur in der loader.conf nachhelfen und vfs.zfs.zio.dva_throttle_enabled=0 setzen.

 

[hs_warez]

Ich finde es halt irgendwie interessant, dass die Eigenbau-NAS in Verbindung mit TrueNAS eigentlich immer gelobt/beworben werden und dann man aber mit einem günstigen Fertig-NAS eine vergleichbare Leistung!?
Ehrlich gesagt bin ich mit der Leistung (pumpen) bei meiner verbauten Hardware etwas enttäuscht.

Wenn man nur ein paar große Daten verschiebt, dann würde vermutlich noch mehr RAM helfen, oder?

Gäbe es bei dauerhafter Last nicht auch eine Möglichkeit?


Was machen die Leute mit 10GB-Netzwerk – läuft das dann nur mit NVME-SSD’s ordentlich?

LG

 

[Trambahner]

10G? Hab ich. Virtualsiert auf ESXI mit durchgereichtem HBA. Mit 2 Pools: 6xHDD Raidz2 für Media und Backups sowie 6*SSD (in 3 Mirrorpärchen) für VMs und "Arbeitsumfeld".
800 MB/s zwischen Client und Storage kein Problem bei großen Files. Dito bei ZFS send/receive zum Backup-Filer.

Ram hab ich der Storage-VM 24GB zugewiesen und 2 virtuelle CPU-Kerne (vorher E3-1240v5 , jetzt ein 5600X).

 

[hs_warez]

Diese Leistung hast du auf dem SSD-Pool?

Auf den HDD's?

 

[Trambahner]

Bei beiden, solange große Files zwischen Client und Server hin-/herkopiert werden. Bei den HDDs wirds natürlich über Zeit langsamer, wenn die sich mehr füllen und die Fragmentierung zunimmt.
Wie gesagt: bei kleinen Files schauts natürlich anders aus weil dort der Datentransfer noch durch andere Dinge ausgebremst wird.

Allerdings sind meine HDDs Ultrastars 14TB und die SSD sind MLC Datacenter-SSDs (Samsung SM863/SM883). D.h. die HDDs haben für HDDs gute Performance auch für 4k-Blöcke und die SSDs können auch "Dauerfeuer" mit Schreibzugriff ertragen. Sprich storageseitig (auch der HBA) sind mir alles Datacenter-Komponenten.

Beachte: SSD-Pool und HDD-Pool sind dabei wirklich getrennt. Also kein Caching/Tiering zwischen SSD und HDD.

 

[hs_warez]

Hm, bei der Ultrastar gibt's ja einige versch.

Die die ich gefunden habe, ist mit 267MB/s angegeben - meine IronWolf mit 210MB/s.

Wie kann es sein, dass du das Ganze virtuell betreibst und dann mit 10GB auf 800 MB/s kommst, und meine IronWolf mit 1GB-Lan schon an der Grenze sind!?

Eine schnellere Kombi als "mirror" gibt es ja eigentlich bei TrueNAS nicht, oder?


Irgendwie geht es mir nicht so ganz ein, dass das System "so" langsam/unstabil ist!?

 

[Ceiber3]

Das ganze ist schon sehr komisch, normal sollte die locker Gbit machen.
Und 6 Festplatten machen gegen zwei im Mirror schon nen unterschied, mein ZFS Raidz-1 unter Windows mit 4x 10 TB IronWolf und 1x 10 TB White macht rund 500/600 MB's.

 

[hs_warez]

Ja, ich hätte eigentlich auch damit gerechnet, dass ich das GB-Lan damit konstant "auslasten" kann - irgendwo muss da ein Problem/Fehler sein.

Mit dem alten Qnap (Marvell-Chip) und irgenwelchen alten 7200er HDD's habe ich ja auch konstant um die 70 MB/s.
Mit der ums tausendfach besseren "TrueNAS-Hardware" schwanke ich dann immer bei 80-115 MB/s - da kann ja irgendwas nicht passen, oder?

 

[gea]

Ich glaube man muss hier mit einem Missverständnis aufräumen.
ZFS ist nicht das schnellste sondern das sicherste Dateisystem. Sicherheit ist aber ganz und garnicht umsonst.

Als Sun ca 2005 ZFS für Solaris vorstellte, galten die Hardwareanforderungen als gigantisch. Man sollte wenigstens 1 GB RAM haben und dann war das nicht sonderlich schnell und verbrauchte jeden RAM den man anbot dazu umgehend (als Cache). Üblich war da ein Server bei dem es als chick galt wenn von 512MB RAM noch 2/3 frei waren. Sun baute ZFS kompromisslos auf Datenscherheit, nicht darauf resourcenschonend oder schnell zu sein. Jede denkbare technische Ursache für Datenverlust sollte vermieden werden.

Vielleicht als Erinnerung. Ca 2001 oder 2002 ging eines der damals größten Speichersysteme in den Wald (Solaris Speicher bei dem damals größten Web-Dienstleister in DE). 50% aller DE Domains waren über eine Woche Offline. 1&1, der damalige viel kleinere Konkurrent ist seither dominierend. Viele Daten konnten nicht wiederhergestellt werden. Das war meiner Ansicht nach mit Auslöser der ZFS Entwicklung bei Sun. Vielleicht errinnert sich der eine oder andere noch daran.

ZFS verarbeitet wegen der Prüfsummen erheblich mehr Daten als ein ext, fat oder ntfs Dateisystem. Copy on Write ist zwar extrem crashsicher (per Design niemals ein korruptes Dateisystem) aber schlecht wenn es um Fragmentierung geht. Die Organisation des Dateisystems ist auf Petabyte und Hunderte Platten ausgelegt, nicht darauf dass eine einzelne Platte oder Mirror sonderlich schnell ist. ZFS verteilt daher Daten möglichst gleichmäßig über alle vdevs. Bei einer einzelnen Platte/ Mirror ist das eher ungünstig, wenn man 90 Platten in 10 vdevs hat aber ideal.

Ein Linux NAS mit 512MB und ext4 Dateisystem ist daher immer überlegen gegen ZFS mit wenig RAM unter SAMBA. Erst mit viel RAM kann ZFS den Nachteil ausgleichen oder überkompensieren und hat dann immer noch höhere Ansprüche.

Hinzu kommt dass in allen meinen Tests, ein kommerzielles Solaris mit in nativem ZFS eingebautem SMB immer den schnellsten SMB Server abgab. Die Solaris Forks mit dem multithreaded SMB Server waren immer langsamer aber schneller als der singlethreaded SAMBA SMB Server zumindest bei mehreren Benutzern. Unter Free-BSD ist FreeNAS/TrueNAS auch nicht die resourcenschonendste Option sondern die mit dem größten Funktionsumfang und "Schickness"

 

[hs_warez]

Mit 32GB-Ram habe ich - lt. Vorgaben - eigentlich mehr as nötig für einen 6 TB Pool.
Würde es was bringen, wenn ich auf 64GB aufstocke?

Werde jetzt mal zusätzlich eine alte Seagate Constellation ES3 1TB verbauen und sann mit dieser mal Tests machen - mal sehen ...

Warum ist dein System um soviel schneller?

 

[Trambahner]

@hs_warez . Bei Deinem Mirror aus 2 Platten hast Du schreibend >maximal< die Leistung einer einzelnen Platte, abzüglich dem Verwaltungsoverhead.

Bei dem 6xUltrastar Raidz2 gehen 2 Platten ab für Parität, bleibt sequentiell (nicht random I/O ! ) bei großen Blöcken der Durchsatz von 4 Platten abzüglich Verwaltungsoverhead.
D.h. ZFS kann aus dem Speicher bei annähernd leeren Platten bis zu 200-250 MB/s pro Platte wegschreiben.

Noch dazu: die reine maximale Übertragungsrate MB/s sagt alleine gar nichts. Die wird nur bei leeren Platten und großen sequentiellen Zugriffen erreicht.
Die Ultrastars sind Datacenter-Platten und (für Festplatten) sehr sehr schnell bei kleinen Blöcken und Zugriffszeiten, während die 6TB Ironwolf auf Energiesparen und niedrige Lautstärke ausgelegte 5400 rpm-Platten sind mit schlechteren Zugriffszeiten und Random-Iops.
Nicht zu vergleichen. D.h. Zwischenzugriffe, um z.B. Prüfsummen zu speichern oder auf andere Metadaten zuzugreifen, fallen bei den Ultrastars weit weit weniger ins Gewicht als bei Deinen Ironwolfs. Damit wird der