TrueNAS Festplattenkonfiguration Empfehlung

[riff-raff]

Ich hab mir einen ProLiant Gen 10 Plus mit Xeon 2224 und 64 GB ECC hingestellt und eine QM2-2P10G1TB ergänzt.

Ich habe nun also 2x NVMe SSD-Ports sowie 4x 3,5" SATA Einschübe frei.

Anwendung ist Storage, ein Dutzend Docker-Container sowie eine VM mit moderater Leistungsanforderung an CPU, RAM und Platte, alles für das private Umfeld. Das NAS ist via 10 Gbit an einen Switch angebunden, Endgeräte an diesen via 2,5 Gbit.
Ich würde gern auf dem Pool Fotos stacken und Video in RAW mit kleinen Auflösungen schneiden. (Anwendungsgebiet Astrofotografie)

mögliche Konfigurationen:

1. 256 GB 2,5" SSD (OS), 3x 20 TB RaidZ Pool + 2x NVMe SSD Größe XX als Write-Cache

2. 256 GB 2,5" SSD (OS), 3x 20 TB RaidZ Pool + 2x NVMe SSD 4 TB Mirror-Pool

3. 256 GB NVMe SSD (OS), 4x 20 TB RaidZ Pool + 1x NVMe SSD 4 TB "Zwischenlager"

4. 256 GB NVMe SSD (OS), 4x 20 TB RaidZ2 Pool + 1x NVMe SSD 4 TB "Zwischenlager"

Oder vielleicht doch noch was anderes?

Bringt der Cache etwas oder ist der Pool immer noch schnell genug um 2,5 und vielleicht doch mal volle 10 Gbit Netzwerk besonders im Write auszulasten? (simultane Anfragen halten sich in Grenzen) Wie groß dimensioniert man die Cache-SSDs? (hohe IOPS und TBW sind klar)
3x 20 TB RaidZ könnte ein Risiko sein beim Rebuild, weshalb mein Herz momentan Richtung Lösung 4 tendiert.

Welche Konfiguration würdet ihr nutzen oder empfehlen?

Beste Grüße, Ralf

 

[DFFVB]

Tom von Lawrence Systems, hat da mal gute Videos zum Cache gemacht, wenn ich das recht erinnere ist das meistens relativ überbewertet...

 

[Hopsekäse]

Hallo,

du solltest dich nochmal genauer mit dem Thema Cache bei ZFS befassen.
Es gibt verschiedene Caches mit jeweils sehr spezifischen Funktionen.
"Die Cache-SSD" auswählen und dimensionieren, ist zu allgemein.

 

[Dig.Minimalist]

Wenn dein Speicherpool schnell sein soll: HDDs mit NVME als special vDev

Bin auch gerade dabei und werde auf striped mirror mit 4x 12-18TB gehen (50% nutzbarer Platz) mit Mirror 2x 1TB NVME als special vDev.
Aktuell teste ich mit 4x4TB.

Für die VMs & Apps habe ich einen separaten NVME pool mit 2x1TB Mirror

 

[madmax2010]

10 gbit/s bekommst du schon mit sata ssds sehr schnell ans Limit.
Aber, nvme blockiert dir keine sata ports.
Nimm Kingston 3000, kioxia g2, crucial p5 oder Samsung 970 evo.
Die sind ordentlich.

 

[riff-raff]

Cache war zu unpräzise, sorry.

Das Video schaue ich mir heute Abend mal an.

ARC im RAM, da ist genug da
L2ARC würde ich lassen, sehe da nicht den Bedarf für Read-Cache
SLOG wäre tatsächlich interessant, zieht aber eben auch nur bei asynchron und davon dürfte ich vergleichsweise wenig haben.

special vDev heißt nur Metadaten ... brauch ich da Größenordnung von 1TB überhaupt?
Warum stripped mirror und kein RaidZ2? Write-Speed? Das hat doch dann aber auch das Rebuild-Problem des RaidZ1-Pools?

Ein RaidZ1 mit 2 NVME-SSDs macht ja keinen Sinn, wäre da nicht Mirror besser?

Bei SSDs fand ich die WD Red 2 und 4 TB von den Specs recht ansprechend

 

[Dig.Minimalist]

Ein RaidZ1 mit 2 NVME-SSDs macht ja keinen Sinn, wäre da nicht Mirror besser?

Natürlich Mirror…

Striped Mirror für den Pool - habe mich mal daran orientiert:
https://www.truenas.com/community/t...d-mirror-raid10-performance-comparison.93598/

Ich habe ein Asrock Rack X470D4U und nutze eine ASUS Hyper M.2 mit 4x 1TB Micron 7300 PLP SSDs, OS auf einer SSD auf Mainboard. Die 1TB fuer vDev sind natuerlich sehr viel, aber ich wollte PLP SSDs.

Wenn der vDev Mirror hops geht ist auch der Pool im A... daher mindestens gleiches Sicherheitslevel wie Hauptpool.

 

[riff-raff]

Gleiche Redundanz wie die Spinners hieße ja

4x20TB RaidZ2 + 3x1TB SSD mirror special vDev ...

3 SSDs ontop bekomme ich nicht unter. Dimensionierung ist hier auch nicht leicht einzuschätzen. Hier liest man 0,3%, jedoch wievel kleine Dateien will ich zusätzlich zu den Metadaten vielleicht auch noch mit rüber ziehen? Bei 40 TB Pool zwei 128 bzw. 256 GB SSDs einzusetzen ist ja bald schon albern.

Wie schaut das bei einem Umzug aus? Wie weise ich dem Pool wieder die Metadaten zu wenn der gesamte Pool auf neue Hardware wandert?

Einfache Redundanz der rotierenden Platten scheint mir kritischer zu sein als einfache Redundanz der SSDs.
Oder ist das blauäugig die statistische Fehlerrate der Platten den Kapazätäten entgegenzustellen und das bei den SSDs zu ignorieren?

 

[Dig.Minimalist]

Mir sind bereits einige HDDs hops gegangen, aber noch keine SSD…
Mirrored Enterprise SSD ist ausreichend sicher für mich.

 

[riff-raff]

Nun ist es ein RaidZ2 mit 4x20TB in den Bays und 2x2TB SN700 NVMe auf der QM2-2P10G1TB geworden.
Eigentlich wollte ich Micron 7450 Max mit 960 GB verbauen, aber die sind momentan nicht zu haben. PLP wäre nett gewesen, die Kehrseite ist die Abwärme der Micron SSDs. Bei den SN700 doch nur 2TB je für die einseitige Bestückung und damit Kühlung am QM2-2P10G1TB.

OS läuft auf einer M.2 2242 NVMe in einem USB-A Gehäuse am internen USB2.0 Port. Ich hatte anfangs Bedenken seitens der Performance, völlig zu Unrecht, läuft wie geschmiert.

Special vdev hab ich mir etwas genauer angeschaut, klingt verlockend. Kann ich hierfür nur ganze Drives verwenden oder auch, wie der Name suggeriert vdevs? Dann würde ich 500 GB (~1% des Volumens, reicht das?) als special vdev definieren und den Rest des Drives als Mirror Pool für eine Datenbank (non-kritisch, niedriger Workload) und für Spielereien. Die Blocksize auf 512 und kleine Dateien mit auf dem "Cache" vorhalten sollte ganz nett sein. (Hier könnte auch ein größeres Special nötig sein)

 

[andy_m4]

Kann ich hierfür nur ganze Drives verwenden oder auch, wie der Name suggeriert vdevs?

vdevs

Die Blocksize auf 512 und kleine Dateien mit auf dem "Cache" vorhalten sollte ganz nett sein.

Die Blocksize sollte idealerweise der nativen Blocksize des darunter liegenden physischen Gerätes entsprechend. Oder redest Du von Recordsize ?

 

[riff-raff]

Natürlich Recordsize! Irgendwie hat sich da im Hinterkopf Blocksize manifestiert.

 

[andy_m4]

Recordsize ist jetzt aber keine Eigenschaft von "Special vdevs", sondern von (normalen) Datasets. Vielleicht hab ich jetzt aber auch nur Deine Ausführungen nicht verstanden.

 

[riff-raff]

Wenn ich für das Dataset eine etwas größere Recordsize, die leicht über der Small Block size liegt sollten doch alle kleinen Daten direkt mit den Metadaten auf dem Special landen und damit zügiger verfügbar als von den spinning drives. (Quelle)

 

[andy_m4]

Ja. Im Prinzip sollte das so sein. Man muss aber aufpassen. ZFS arbeitet mit variablen Zuordnungsgrößen, angepasst auf das, was da gespeichert wird. Insofern hat die Recordsize jetzt kein absolut definierenden Charakter, sondern ist eher eine Empfehlung.

Generell gilt: ZFS versucht viel selbst zu optimieren. Man sollte da nur eingreifen, wenns wirklich ein Problem gibt und wenn man weiß, was man tut.

 

[riff-raff]

Ein ZVOL Datenset auf den SSDs dem RaidZ2 als Metadaten zuweisen geht wohl offensichtlich nicht ...

Kann ich überhaupt die beiden SSDs im "Dual Use", also ein Teil für Special und den Rest als Pool oder als vollständiger Pool mit einem Teil für Special verwenden?

2x2TB als Special Vdev wären schon sehr üppig, jedoch waren sie nicht viel teuter als die 1 TB

 

[andy_m4]

Ein ZVOL Datenset auf den SSDs dem RaidZ2 als Metadaten zuweisen geht wohl offensichtlich nicht ...

Ein zvol ist was anderes als ein Dataset. Und es war auch weder von zvol die Rede noch von Dataset, sondern von vdevs.

Kann ich überhaupt die beiden SSDs im "Dual Use", also ein Teil für Special und den Rest als Pool oder als vollständiger Pool mit einem Teil für Special verwenden?

Klar. In dem Du entsprechend partitionierst (Partitionen sind valide vdevs).
Was halt nicht geht, ist ein Pool anlegen und darin ein zvol was wiederum als Special vdev für den Pool dient.
Denn Special vdevs sind Teil des Pools und wenn das auf dem Pool (zu dem es gehört) selbst liegen würde, wäre das halt so ne Katze-beißt-sich-in-den-Schwanz-Geschichte.

2x2TB als Special Vdev wären schon sehr üppig

Ja. Wäre es.
Ich muss zugeben, ich hab jetzt ein bisschen den Überblick darüber verloren, was als Laufwerke da ist und wie die verwendet werden sollen.

 

[riff-raff]

Pool1: 4x20TB spinning drives RaidZ2
Pool2: 2x2TB NVMe Mirror

Die SSDs sollen special für den Pool 1 werden. Wenn möglich aber nicht die volle Kapazität sondern etwa 500 GB (Grobe Schätzung des Bedarfs für Metadaten + Klein-Files)
Der Rest des Pool2 gern für was anderes (DB, Bastelei, ggf. VM)

Partitionen sind valide vdevs? Interessant, bisher hab ich die nativen Laufwerke in TrueNAS (Scale) eingebunden. Ich hatte es so verstanden, dass ich im Pool2 ein ZVOL als Blockdevice anlegen kann und dieses dann als Special für Pool1. Das würde ja das Katze-Beißt-Sich-In-Den-Allerwertesten-Problem erledigen.

Sollte der Special 75% voll laufen landet das Kleinzeug eh wieder auf Pool1.
Da ich den Special auch wieder entfernen kann (Meta geht zurück auf Pool1) und neu, größer anlegen kann bin ich was die Größe angeht wohl recht flexibel.

 

[andy_m4]

Die SSDs sollen special für den Pool 1 werden. Wenn möglich aber nicht die volle Kapazität sondern etwa 500 GB

Ok

Partitionen sind valide vdevs?

Ja.
Ist ist sogar insbesondere bei RAID anzuraten eher Partitionen zu nehmen als "whole-disks". Weil Plattenhersteller haben gerne mal ne unterschiedliche Vorstellung davon, wieviel 2TB wirklich sind. Wenn Du da also irgendwie ein RAID-Pool aus drei 2TB Platten hast und eine fällt aus und Du willst die durch ne andere 2TB ersetzen kann sein, das das fehlschlägt, weil da irgendwie 100MB fehlen.
Daher empfiehlt sich sich via Partitionen da Speicherplatz abzuknapsen damit man nicht irgendwann mal in eine solche Bredouille kommt.

dass ich im Pool2 ein ZVOL als Blockdevice anlegen kann und dieses dann als Special für Pool1. Das würde ja das Katze-Beißt-Sich-In-Den-Allerwertesten-Problem erledigen.

Müsste man im Prinzip machen können.

Da ich den Special auch wieder entfernen kann (Meta geht zurück auf Pool1) und neu, größer anlegen kann bin ich was die Größe angeht wohl recht flexibel.

Eben. Von daher braucht man vom Start weg nicht unbedingt eine 100% Lösung. Lediglich bei Dingen, wo Du partitionierst musst Du gucken.