[Sammelthread] ZFS Stammtisch

Hey ich grüße dich.
Ja gerne würde ich die vorhandenen Platten nutzen, die sind noch recht neu, und habe viele davon kostenlos erhalten bei meinem AG, weil es sich um eine Falschlieferung handelte.
Performance, joa, also am allerliebsten würde ich natürlich eine 10GBit Leitung ausnutzen wollen. Habe weiterhin ein 512GB NVMe ZLOG, und 512GB NVMe Cache Device.
Mit den ZFS RAIDs kenne ich mich noch nicht so wirklich aus. In meinem 2. Server habe ich einen Verbund aus 16x 73,8GB 15k Festplatten in einem RAID 45, und das Ding ist robust bis zum abwinken, da kann mir gefühlt der halbe Array wegfliegen, und das läuft immernoch.
Also mein RAID 10 approach, als mirrored + striped vdev ist glaube ich nicht wirklich zielführend im Falle von ZFS, daher bin ich offen für weitere Optionen, bzw. andere RAID-Z Vorschläge. Ich denke ein RAID-Z1 wäre bei der Anzahl der Platten im Falle von einem Rebuild auch zu wenig.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Also mein RAID 10 approach, als mirrored + striped vdev ist glaube ich nicht wirklich zielführend im Falle von ZFS,
Doch, eigentlich ist das die empfohlene Variante - schneller resilver, da kein RAIDZ, (damit weniger Gefahr eines weiteren Ausfalls beim resilver - Hauptargument gegen RAIDZ5) viele IOPS da viele vdevs, leicht erweiterbar (einfach mirror-pärchen tauschen).

Hast Du evtl zuwenig RAM? Oder vor allem Zugriffe auf kleine Dateien, dann wäre ein SSD Special vdev wohl besser?

Das Betriebssystem (Linux? OmniOS? TrueNAS? ...?) hast Du schon auf 10G optimiert? Auch da kann der Performance Engpunkt liegen.

gerne würde ich die vorhandenen Platten nutzen, die sind noch recht neu, und habe viele davon kostenlos erhalten bei meinem AG
Das sind Emotionen, aber kein Grund gegen Verkauf und Anschaffung von Hardware, _die Deine Bedürfnisse besser erfüllt_. Was immer die nun sein mögen.
 
Habe 12x 4TB Festplatten + 1x 4TB Hot Spare. Aktuell läuft da ein Mirrored + Striped vdev aka. RAID 10. Das ganze bringt jedoch nicht die Performance die ich erwartet habe.
Was wird erwartet?

Workload/ Filearten, Performance sequentiell, random, read oder write - mit oder ohne sync zu schlecht?
Falls OmniOS und napp-it das Ergebnis von Pool > Benchmark posten (testet alle obigen Fragen), sonst z.B. dd o.ä. mit und ohne sync

OS, wieviel RAM und welcher Pool Füllgrad, Slog, CPU und HBA?
 
Zuletzt bearbeitet:
Ehrlich gesagt kenne ich meine Anforderung nicht genau, da ich den Pool die allermeiste Zeit als reines Datengrab verwende.
Verfügbarkeit ist dennoch sehr wichtig. Es sind meistens riesen Dateien die ich drauf speichere, meistens Festplattenimages die mal 4TB haben, die bleiben dann aber auch ewig drauf und werden nicht angerührt, bzw. meist wird davon nur gelesen.
Dokumente speicher ich dort auch ab, da handelt es sich aber um wenige hundert MB.
Weiterhin schreibt Zoneminder noch auf die HDD, schön gemächlich, daher Hochverfügbarkeit wichtig. 2 NVMe Platten hätte ich noch da welche irgendwie als Cache oder ähnlich genutzt werden können. Ich nutze FreeNAS 11.3 mit 128GB ECC RAM.
Ich werde mal den Pool Benchmarken.
Falls etwas I/O lastiges geplant wäre, würde ich eine 4TB SATA SSD einbauen.
HBA ist ein LSI 9211 8i mit LSI SAS Expander.
Der Pool ist aktuell 80% gefüllt.
CPU ist ein Ryzen 2700X.
 
Zuletzt bearbeitet:
Eine SSD/NVMe kann zusätzlich zum RAM als Readcache L2Arc genutzt werden (max 5x RAM).
Bei 128 GB RAM wird ein L2Arc praktisch garnicht genutzt werden.

Eine SSD/NVMe kann als Slog genutzt werden.
Das ist eine schnelle Absicherung des rambasierten Schreibcaches. Braucht man für Datenbanken oder VM Storage. Bei einem reinen Filer nicht nötig. Sync write bremst da unnötigerweise die Performance. Ein Slog muss mindestens 10GB groß sein, dauerhaft hohe write iops liefern, niedrige Latenz haben und powerloss protection haben. Desktop NVMe sind kontraproduktiv - bringen es nicht.

Eine SSD/NVMe kann nicht als Schreibcache genutzt werden.
Das gibt es bei ZFS nicht. Schreibcache ist RAM (10% RAM, max 4 GB bei Open-ZFS, bei Solaris ein paar Sekunden)

Performance ist abhängig von der Fillrate. Bei 80% ist bereits ein deutlicher Performanceverlust.

Tuningoptionen:
geringere Fillrate
schnellere, neuere Platten
Ein NVMe Mirror als special vdev für Metadaten, kleine io oder ausgewählte Dateiysteme. Powerloss Protection angeraten.
 
Zuletzt bearbeitet:
Hey danke dir. Ja ich werde mal schauen, ich denke das Caching macht bei dieser Art von Storage Pool tatsächlich dann kaum Sinn.
Einen NVMe Mirror, bzw. eine einzelne NVMe welche replicated wird, würde ich dann für kleine Dateien nutzen.
Dann noch die Frage welcher RAID Verbund, ob 10 oder "RAID 7", oder was ganz anderes. Würde mich interessieren ob es eventuell Wahrscheinlichkeiten gibt, für einen erfolgreichen Rebuild in beiden Szenarien.
RAID-Z3 würde mich natürlich deutlich mehr ansprechen von der Speichernutzung her, hat aber andere Nachteile. Meinen mirrored striped Verbund hat es damals mal zerfetzt, nachdem bei einer Spannungsschwankung im Stromnetz 3 HDDs offline gegangen sind, und sofort wieder zurück waren, aber vom Pool rausgeworfen worden sind beim Schreiben. Dannach war der Pool kaputt. Wäre super wenn es da vielleicht belastbare Daten zu gibt, sowohl R/W Performance, als auch Rebulddauer und Wahrscheinlichkeiten.
Sonst ist ein gesundes Mittelding vielleicht ein RAID60 zusammengebaut aus mehreren RAID-Z2 Arrays + Striping? Vermutlich dauert der Rebuild aber dann ne Woche, was von der Dauer her nicht schlimm ist, aber eventuell fällt bei dem Load dann mehr aus.
 
Hey danke dir. Ja ich werde mal schauen, ich denke das Caching macht bei dieser Art von Storage Pool tatsächlich dann kaum Sinn.
Einen NVMe Mirror, bzw. eine einzelne NVMe welche replicated wird, würde ich dann für kleine Dateien nutzen.
Dann noch die Frage welcher RAID Verbund, ob 10 oder "RAID 7", oder was ganz anderes. Würde mich interessieren ob es eventuell Wahrscheinlichkeiten gibt, für einen erfolgreichen Rebuild in beiden Szenarien.
RAID-Z3 würde mich natürlich deutlich mehr ansprechen von der Speichernutzung her, hat aber andere Nachteile. Meinen mirrored striped Verbund hat es damals mal zerfetzt, nachdem bei einer Spannungsschwankung im Stromnetz 3 HDDs offline gegangen sind, und sofort wieder zurück waren, aber vom Pool rausgeworfen worden sind beim Schreiben. Dannach war der Pool kaputt. Wäre super wenn es da vielleicht belastbare Daten zu gibt, sowohl R/W Performance, als auch Rebulddauer und Wahrscheinlichkeiten.
Sonst ist ein gesundes Mittelding vielleicht ein RAID60 zusammengebaut aus mehreren RAID-Z2 Arrays + Striping? Vermutlich dauert der Rebuild aber dann ne Woche, was von der Dauer her nicht schlimm ist, aber eventuell fällt bei dem Load dann mehr aus.

Raid-1/10: Bringt sequ. write Performance und iops von n * Anzahl Mirrors, Readperformance ist bei parallelem Lesen doppelt so groß.
Raid-Z[n]: bringt sequ. read/write Performance von n * Anzahl Datenplatten. iops ist Anzahl Raid-Z vdevs * iops einer Platte - bei einem vdev also so niedrig wie bei einer einzelnen Platte

Raid-Z [1,2] ist von der Parität und Platz wie Raid [5/6] allerdings ohne Write Hole Problem http://www.raid-recovery-guide.com/raid5-write-hole.aspx. Auch führt ein Lesefehler im degraded state nur zu einer defekten Datei nicht zu einem Array lost wie bei Raid 5/6. Auch bei einem Mirror bei den beide Hälften ungleich sind, kann ZFS ermitteln welcher Mirrorteil gut oder schlecht ist (Prüfsummen aud Daten/Metadaten)

Raid-7 ?? ZFS kann Basic, Mirror und Raid-Z[n]

Stromausfall
ZFS ist Copy on Write. Ein atomarer Schreibvorgang wird ganz ausgeführt oder verworfen (kein defektes Raid oder Dateisystem nach Crash beim Schreiben). Fällt eine Platte aus dem Raid und wird für ZFS später wieder sichtbar, ist das Raid wieder verfügbar. Ein traditionelles Raid bleibt defekt da mangels Prüfsummen die Konsistenz nicht gewährleistet ist.

Rebuild
Modernes ZFS (Solaris und Open-ZFS wie OmniOS) können sehr schnelles sorted/sequentielles Resilvering. Dazu ist die Rebuilddauer von der Poolbelegung abhängig. Ein leerer Pool resilvered in ein paar Sekunden, ein voller Pool braucht je nach Pool iops vielleicht 1-2 Tage.
 
Zuletzt bearbeitet:
Vielen Dank dir! Ja, ich denke ich werde mal einfach meinen Pool destroyen, und ein paar Varianten ausprobieren, dann schaue ich mal was am besten passt.
Mit RAID 7 meinte ich im Grunde nur das Raid-z3 mit dreifacher Redundanz. Weiterhin werde ich schauen ob es möglich ist, beispielsweise 4x RAID 6 aus jeweils 4 Platten aufzubauen, und die 4 RAID-Z2 dann als striped vdev zu betreiben.
 
Raid-7 ist ein spezielles Verfahren mit Cache (registered Trademark). Sollte man nicht eigenmächtig umdefinieren.

Auch ist ZFS Z2 NICHT Raid-6. Sollte man auch nicht so benennen.
 
kurze frage - was ist die beste blocksize / ashift für micron 5210 ION ssds? bin mir nicht sicher ob 12 oder 13... smartctl reported block size 4096 bytes, aber ob das stimmt...?
 
Ich tendiere dazu, dass die schnellste Einstellung die ist die der Hersteller vorgibt, hier also 4k/ashift=12.
Der weiß ja am Besten wie er die SSD samt Firmware konzipiert hat.

Ein anderer Aspekt ist Disk Replace und Vdev Remove. Beides geht nur bei gleichen ashift Einstellungen. Generell 4k/ashift=12 zu nutzen ist dann alles andere als verkehrt sondern oft die einzig sinnvolle Option.
 
Hallo Freunde.
Ich probiere aktuell diese Topologie hier aus.
Bin mal gespannt ob das ein gesundes Mittelmaß aus Rebuildzeit, Redundanz, und Performance ist.
Es können aufjedenfall 2 beliebige wegbrechen.

Code:
root@freenas[/]# zpool status data
  pool: data
 state: ONLINE
  scan: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    data        ONLINE       0     0     0
      raidz2-0  ONLINE       0     0     0
        da0     ONLINE       0     0     0
        da1     ONLINE       0     0     0
        da2     ONLINE       0     0     0
        da3     ONLINE       0     0     0
      raidz2-1  ONLINE       0     0     0
        da4     ONLINE       0     0     0
        da5     ONLINE       0     0     0
        da6     ONLINE       0     0     0
        da7     ONLINE       0     0     0
      raidz2-2  ONLINE       0     0     0
        da8     ONLINE       0     0     0
        da9     ONLINE       0     0     0
        da10    ONLINE       0     0     0
        da11    ONLINE       0     0     0
 
Da wäre ein Pool aus 2x Raidz2 aus jeweils 6 HDDs der sinnvollere Weg, so geht 50% der Kapazität für die Redundanz drauf, genau wie bei 6x Mirror VDEV
Stimmt, daran hätte ich denken müssen danke dir.
Werde ich direkt mal umbauen

EDIT: Das klappt super, und die Performance ist auch echt gut! Wenn es jemand interessiert kann ich mal die Ergebnisse dazu hier posten.
Wie bencht ihr eigentlich euren Pool? Vielleicht kann ich das bei mir auch mal machen.
Die CPU Last kesselt aber schon ordentlich bei einem reinen Filer und FTP Transfer (ohne Encryption).
Screenshot from 2021-10-20 12-57-31.png
 
Zuletzt bearbeitet:
Wenn man einen Pool benchen will, sollte man einen Mix aus sequentiellen Test und random Tests mit read und write machen. Bei write dann mit und ohne sync. Wenn man Verschlüssellung nutzen möchte, das gleiche mit und ohne Verschlüssellung. Ich nehme dazu immer filebench weil man da use cases einstellen kann. Für eine erste Einschätzung geht aber auch dd oder bonnie mit und ohne sync. Bei einem Plattenpool dazu optional mit einem guten Slog.

Wenn man hauptsächlich SMB nutzt, kann man die SMB Performance z.B. SAMBA oder Solaris SMB mit dem NAS Performance Tester einfach benchen. Etwas besser ist der AJA Speed Test. Da werden Videostreams aus Einzelbildern getestet. Mann kann dann 4k wählen (große Dateien) oder SD (kleine Dateien)

Vergleichswerte z.B.

etwas älter
 
Zuletzt bearbeitet:
Vielen Dank dir! Das werde ich mal ausprobieren.
Ich habe bisher mal dieses iozone laufen lassen wenn das bekannt ist, habe eine .xls als Ergebnis bekommen. Weiß einer hier wie ich die genau auswerte?
Werde wie von gea empfohlen jedoch auch mal andere Benchmarks machen.
 

Anhänge

  • iozone-MY_FILE_SERVER-local-size-64g.zip
    20,9 KB · Aufrufe: 66
Danke dir, das ist nicht das Problem, sondern eher wie ich das darstellen soll, bzw. was ich hieraus erkennen soll.
Habe eine 16G Testfile erstellt aus /dev/urandom via FTP übertragen, da komm ich auf ca. 550MB/s maximal. Bei SSH bzw. SCP irgendwie nur 74MB/s.
Screenshot from 2021-10-21 11-40-22.png
 
Iozone ist nicht da um einen schnellen Überblick zu erhalten. Man kann damit ein System für eine bestimmte Anwendung z.B. Datenbank optimieren (bestimmte Filesize, Recordsize und Datenblockgröße).

SCP/SSH arbeitet mit Verschlüssellung und ist daher langsam.

Insgesamt sollte man für eine Komplettübersicht zuerst den Pool lokal testen, dann das Netzwerk (iperf) und dann die Services wie NFS, SMB oder SCP. Dabei den use case im Blick haben (große oder kleine Dateien, Anzahl paralleler Nutzer, Sync Write nötig)
 
Zuletzt bearbeitet:
Code:
robin@RYZEN-5950X:/tank/benchmark-test$ dd if=/dev/zero of=./test bs=1M count=3000
3000+0 records in
3000+0 records out
3145728000 bytes (3.1 GB, 2.9 GiB) copied, 2.41108 s, 1.3 GB/s
robin@RYZEN-5950X:/tank/benchmark-test$ sudo zfs get all tank | grep sync
tank  sync                  always                 local

Optane is schon ne geile Geschichte :d
 
Hat jemand hier eigentlich Deduplication am laufen? :d Das Video hierzu fand ich durchaus interessant. Scheinbar wurde ne Optane für den Dedup-Table eingesetzt, ohne merklichen Performance-Verlust.
 
ESXi ist auf einer separaten SATA SSD. An napp-it reichen wir einen LSI 2008 durch, da dran hängt zum anfangen eine SM883 und eine WD Gold.

Was mir nicht ganz klar ist:

  • Wie richte ich die Optane ein? 16GB für napp-it und 30GB für SLOG, jeweils eine VMDK ok? Für napp-it würde ich erst mal 24GB RAM zuweisen
  • Ist SLOG und L2ARC in dem Fall das gleiche/auf der gleichen vDisk?
  • soll ich den Platz auf der Optane allokieren?
Verbesserungsvorschläge?

Gruss

Prinzipiell kann man die Optane an OmniOS durchreichen und als Slog nutzen. Möchte man auch zusätzlich ein L2Arc könnte man die Optane unter OmniOS partitionieren. Einfacher wäre es dann aber die Optane unter ESXi als datastore zu nutzen um darauf vdisks für slog (min 10GB, besser etwas mehr) und l2arc (max 5 x Ram) anzulegen. Das L2Arc wird bei 24GB RAM für OmniOS nicht soviel bringen, eventuell etwas wenn man read ahead darauf aktiviert.

Wenn man für VM Storage eine SM 883 nutzt braucht man nicht unbedingt ein Slog da die SM selbst schon ganz gut ist. Eine Optane kann nur noch etwas bringen.

Hi

Ich habe jetzt das Storage am laufen. napp-it läuft auf einer eigenen SSD, es ist ein LSI 2008i durchgereicht. Da dran hängen wie gesagt eine SM883 und 2 WD Gold.

Ich habe jetzt 32 GB RAM zugewiesen. Ausserdem habe ich eine Optane 800P 58 GB stecken. Da würden wir gerne zumindest slog einrichten, wenn es Sinn macht auch l2arc. Ich würde diese normal per ESXi Datastore einbinden. Ich mache also 20GB für slog und 30 GB für l2arc VMDKs, und hänge die an napp-it an. So zumindest der Plan. Macht das Sinn so? Alternativ könnte ich die Optane auch per IOMMU durchreichen.

Wenn ich das gemacht habe, wie konfiguriere ich das in napp-it? Konnte dazu nichts finden im Manual und auf der Weboberfläche.

Gruss und danke.
 
Nachdem man in den ESXi Einstellungen der napp-it VM die beiden vdisk eingerichtet hat, kann man die im Menü Pool > Erweitern dem Pool als Log und Cache hinzufügen.
 
Hmm, ok danke. Ich hatte erst 2 Pools mit den 2 Platten. Dann habe ich überlegt, mache ich auf der Optane je 2 slog und 2 larc. Jetzt habe ich aber mal einen Pool angelegt mit basic vdevs. Was passiert dann, wenn eine Platte Hopps geht? Wir haben auch kein RAID oder so, es sollen beide Platten unabhängig genutzt werden können.

  • In dem Moment wäre schon die Lösung mit 4 vmdk auf der Optane angesagt?
  • Wie siehst Du das?
Beitrag automatisch zusammengeführt:


Ich habe es jetzt mit 2 Pools und 4 VMDK auf der Optane gelöst. Hoffe, das war ok so, sonst kann man es noch ändern.

Noch eine Frage, sry:

Ich habe napp-it LTS mit einem einzelnen Adapter in einem Adminnetz, welches keinen Zugang zum Internet hat. Das habe ich bei mir zuhause auch so. Ist das ein Problem? Kommen die folgenden Fehler daher?:

napp-it.PNG


Beitrag automatisch zusammengeführt:


Sry, ich nochmal: wieso ist das so brutal schnell? So schnell kann man ja gar nicht lesen von SATA 3, bzw. der SM883?

Optane.PNG
 
Zuletzt bearbeitet:
Dyndns Meldung
Das ist kein OmniOS Systemdienst. Da müsste man die Dyndns Einstellungen überprüfen

keine Redundanz (Raid-0 oder basic vdevs)
So unwichtig dass man das möchte, können Daten gar nicht sein.
Bei einem Plattenausfall sind alle Daten weg. Selbst ein einfacher Datenfehler kann zwar erkannt aber nicht repariert werden.

Vdisks
4 vdisks ist ok (Slog ab 10GB) aber
Slog ist keine Performance Option sondern eine Sicherheitsoption. Selbst mit Optane (derzeit schnellstes Slog) ist der Pool mit aktiviertem Sync viel langsamer als mit sync=disabled. Da ein ZFS Pool auch ohne Slog bei einem Absturz beim Schreiben wegen Copy on Write konsistent bleibt, braucht man sync nur wenn man den Inhalt des RAM Schreibcaches sichern muss wie bei VM Storage oder transaktionalen Datenbanken. Sonst läßt man das Slog besser weg und deaktiviert sync. Mit ausreichend RAM bringt auch ein L2Arc so gut wie nichts - ist eventuell gar schädlich weil es RAM verbraucht.

Performance
Da bräuchte ich Informationen zu Controller und Platten. Mit 6G SAS/Sata geht ca 500 MB/s, mit 12G Dualpath SAS bis ca 2000 MB/s. Kurzfristig beschleunigt der RAM Schreib/Lese-Cache.
 
Zuletzt bearbeitet:
Die vmdk-Datei dürfte in großen Teilen ein Sparse-File oder mit Nullen gefüllt sein. Da wirkt dann natürlich die Komprimierung z.b. mit LZ4 massiv, Die Menge der Daten die das OS dann meint zu schaufeln ist eine viel größere als ZFS tatsächlich von/zur Platte/SSD bewegt. Der Ram-Cache spielt natürlich auch eine Rolle. Dementsprechend zeigen dann Tools höhere Werte an, als physikalisch möglich.
Ganz normal, kein Grund zur Besorgnis.
 
Wer mpio SAS nutzt (wegen besserer Performance oder in einem HA Cluster):

Es gibt einen Bug in mpathadm in OmniOS 151038lts (Multipath admin tool).
Ein Fix ist verfügbar, Topicbox
 
Sagt mal, wenn ich mir ein ZFS mit ein paar Platten aufbaue und die Platten gehen in den Spindown:
Was passiert bei einem Zugriff? Fahren die Platten sequentiell oder alle auf einmal hoch? Ich finde da irgendwie widersprüchliche Aussagen.
 
Kommt nicht auf ZFS sondern dein Betriebssystem an.

Illumos/OmniOS: Gleichzeitig. "Staggered spinup" gibt es da mW nicht. Zudem dauert das hochfahren länger als der Zugriff per SMB wartet (so jdfs bei meinem veeam).

FreeBSD/FreeNAS: keine Ahnung, vermutlich gleichzeitig

Linux: keine Ahnung, evtl staggered
 
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