NVMe: Cache oder Array?


Gemuesefraumann
Go to solution Solved by MAM59,

Recommended Posts

Hallo allerseits,

 

ich bin ganz frisch im Unraid-Universum unterwegs und überlege gerade, wie ich mein NAS am besten einrichten sollte. Es geht um folgenden Use Case:

 

- lokaler Netzwerkspeicher für meist kleinere Dateien, ansonsten Bildarchiv

- ein paar Dienste wie Adguard oder SyncThing im Container

- gelegentliche Nutzung einer Linux-VM, langfristig eventuell Sound-Server

- SSD only, da ich keine rauschenden Festplatten mag

- gelegentliches Backup über externe HDD

 

An Hardware arbeite ich mit folgendem Setup:

 

- Ryzen 5600G

- Gigabyte B550I Aorus Pro AX (2.5G LAN)

- 32GB CL16 DDR4 mit 3200 MHz

- 2TB WD NVMe

- 4TB Crucial NVMe

- diverse kleinere, unterschiedlich kleine SATA-SSD auf Halde

 

Mir geht es jetzt um die Frage, wie ich die beiden großen NVMe am besten formatieren und einbinden sollte. Man liest in den Foren, dass ein Array (ohne Parity natürlich) auf Dauer nicht anzuraten sei, da hier kein TRIM unterstützt wird. Hat sich da inzwischen was getan oder sollte man von Arrays weiterhin Abstand nehmen?

 

Aktuell läuft das Testsystem mit beiden NVMe als XFS im Array. Ich überlege aber, auf einen Cache-Pool mit BTRFS (sinnvoll?) umzusteigen. Um das Array noch hochfahren zu können, würde ich dann einfach irgendeine alte SATA-SSD als Dummy einbinden.

 

Kürzlich wurde auch geteasert, dass Unraid in der kommenden Version wohl ZFS-RAID unterstützen wird. Lohnt es sich, darauf zu warten? Hätte das bei meinen zwei (unterschiedlich großen) NVMe irgendwelche Vorteile gegenüber der Einrichtung als BTRFS-Cache-Pool?

 

Ich hoffe, ihr könnt mir ein paar Tipps geben. :)

 

Beste Grüße und vielen Dank für die Unterstützung

Gemüsefraumann

Edited by Gemuesefraumann
Link to comment

Hi,

 

also von SSDs im Array würde ich die Finger lassen. DIe Antwort hattest du dir ja schon selbst gegeben. Ich würde derzeit, falls Daten nicht kritisch und ein gutes Backup Konzept vorhanden ist, die 2x4TB in Raid0 und Anwendungsdaten (vm, appdata etc.) auf 2x 2TB Nvme im Raid1 packen. Also alles BTRF Pool only. Wenn ZFS kommt kannst du auch auf Raidzx setzen. Macht aber nur ab 3 gleichen ssds sinn. Es ist wie immer eine Anforderungs- und Geldfrage.

Ich selbst habe einen kleinen Odroid h3+ mit 2x 8tb samsung qvo als backup im raid1 pool im einsatz

Edited by Dexter84
  • Like 1
Link to comment

Hi,

 

also die Ausfallsicherheit der kritischen Daten ist bei mir bereits dadurch gesichert, dass ich sie ständig per SyncThing auf alle Clients synchronisiere. Dort kann ich per File-Versioning auch defekten Dateien, die überall überschrieben werden, vorbeugen. Der Rest des Datengrabs wird dann von Zeit zu Zeit auf die externe HDD gespiegelt.

 

Da ich in der RAID-Technik ehrlich gesagt überhaupt nicht drin bin, kann ich noch nicht einschätzen, was hier die sinnvollste und am wenigsten wartungsintensive Methode wäre.

 

Wie steht es denn um die Einrichtung als "persistenten" SSD-Cache? Hat das irgendwelche gravierenden Nachteile? 

 

Mehr Geld ausgeben möchte ich eigentlich nicht, so lange keine wirklich handfesten Vorteile in Sicht sind.

 

Freue mich über weitere Einschätzungen. Bin da leider noch nicht so bewandert.

 

Viele Grüße

Gemüsefraumann

Edited by Gemuesefraumann
Link to comment

Die Frage ist halt, reicht dir der Speicherplatz den du jetzt hast.

So wie ich das lese hast du jede SSD nur 1x. Da stellt sich somit keine Raid frage. Du kannst nur zwischen den einzelnen Pools Daten "manuell" hin und her syncen.

Der SSD Cache ist aktuell nur für das Array interessant. Also Cache im Sinne von: da du im Array eine relativ schlechte Schreibperformance hast und den Array Schreibprozess über Mover auf einen anderen Zeitpunkt verlegen kannst.

Mit vielen unterschiedlichen SSDs bekommste du auch nur viele einzelne Pools, wenn du keinen Speicher der größeren SSD verschwenden willst.

Du könntest dir eine 2. 2TB Nvme kaufen -> Raid 1 und deine wichtigen Bewegungsdaten darauf packen (VM, appdata etc)

Die 4Tb SSD bleibt ohne redundanz und wird wie dein Raid1 über deinen Backupprozess periodisch abgesichert.

 

Raid selbst hat keinen Wartungsaufwand. Ggf. nen automatischen Scrub Prozess oder array parity check, das wars aber auch schon.

Edited by Dexter84
  • Like 1
Link to comment
6 minutes ago, Dexter84 said:

Die Frage ist halt, reicht dir der Speicherplatz den du jetzt hast.

Ja, reicht.

 

7 minutes ago, Dexter84 said:

So wie ich das lese hast du jede SSD nur 1x.

Genau.

 

14 minutes ago, Dexter84 said:

Der SSD Cache ist aktuell nur für das Array interessant.

Ok. Ist es denn nicht möglich, den SSD Cache einfach persistent ohne Mover zu nutzen? Im Cache Pool könnte ich jedenfalls nach BTRFS formatieren und hätte dadurch TRIM. Soweit richtig?

Link to comment
7 minutes ago, Gemuesefraumann said:

Ok. Ist es denn nicht möglich, den SSD Cache einfach persistent ohne Mover zu nutzen? Im Cache Pool könnte ich jedenfalls nach BTRFS formatieren und hätte dadurch TRIM. Soweit richtig?

 Doch doch na klar. Das heißt dann zwar noch "Cache". Ist aber ein Pool ohne den Zweck eines Array Caches mit Mover. Also vergiss in dem Fall das Unraid "Hot/Cold Storage" Konzept. Du hast dann TRIM und alles ist fein mit deiner SSD.

  • Like 1
Link to comment
  • Solution

Grundsätzlich gehören keine SSDs / NVMes ins Array, Eben wegen fehlendem Trim. Das Array macht aber auch nur Sinn, wenn es von mindestens einer Paritätsplatte gesichert wird.

Als "Cache" brauchst Du die NVMes auch nicht, denn sie würden ja nix schneller machen.

 

Was Dir bleibt sind eben einfache Pools mit jeweils einer NVMe (nicht beide in einen Pool packen, dann wird da ein RAID Array raus und die Hälfte der grossen NVMe bleibt ungenutzt, Du hast dann nur 2Tb übrig! (jaja, man KANN das dann hinterher wieder korrigieren, aber erstmal ist das Kind in den Brunnen gefallen und der Umbau danach geht nicht ohne Löschen der Platten ab))

 

Eigentlich ist UNRAID gar nix für Dich, alle "guten" Features willst Du nicht bzw. kannst Du nicht gebrauchen.

 

  • Like 1
Link to comment
9 minutes ago, Gemuesefraumann said:

Als Array-Disk würde ich dann einfach irgendeine alte, kleine SSD oder vielleicht irgendeinen USB-Stick mounten

Du brauchst gar kein Array, wie @Dexter84 schon sagte, ein "Cache" ohne Cachefunktion reicht aus (alle Shares auf "Nur Cache" stellen, bzw auf "Nur NameVonAndererNVME"

)

Update: ooops, war gelogen, sorry. Ja, son Dummy muss her, sonst kannst Du auch keine VMs und Docker verwenden....

Edited by MAM59
Link to comment

Gerne. Genau, du kannst einfach irgendwas als "Array" nehmen. Das soll sich irgendwann ändern. Bis dahin braucht man leider noch ein Pseudo Array.

Fallstricke erstmal keine. Schau einfach, dass du mit Speicher und Backup Konzept hinkommst. Ggf. kann man noch etwas nachjustieren.

Edited by Dexter84
  • Like 1
Link to comment
7 minutes ago, MAM59 said:

Eigentlich ist UNRAID gar nix für Dich

Das habe ich schon ein wenig befürchtet. 😅

 

Aber die Alternative wäre halt ein freies Linux-System, bei dem ich vieles händisch pflegen muss. Unraid packt bereits sehr viele Features unter einen Schirm und ist dabei eigentlich sehr leicht bedienbar und zugleich ressourcenschonend.

 

Danke euch jedenfalls für die Informationen! Das hat mir schon sehr weiter geholfen. 👍

 

 

Link to comment
13 minutes ago, Gemuesefraumann said:

Das habe ich schon ein wenig befürchtet. 😅

 

Aber die Alternative wäre halt ein freies Linux-System, bei dem ich vieles händisch pflegen muss. Unraid packt bereits sehr viele Features unter einen Schirm und ist dabei eigentlich sehr leicht bedienbar und zugleich ressourcenschonend.

 

Danke euch jedenfalls für die Informationen! Das hat mir schon sehr weiter geholfen. 👍

 

 

ich sehe das nicht so streng. Unraid ist viel mehr als ein Heiss/Kalt Konzept. Es wurde ja schon offiziell verkündet das Unraid nur noch der Markenname sein soll. Durch die ZFS Integration (wird auch hier kontrovers diskutiert) verabschieded man sich ein wenig von dem ursprünglichen Konzept. Wie @Gemuesefraumann schon richtig gesagt hat, es ist ressourcenschonend, lässt sich per stick booten und bietet einfache NAS Funktionalität mit einer Top Docker und VM Integration. Na klar kann man auch nen OMV oder was "selbstgebasteltes" nehmen, dennoch hat Unraid seine Stärken an die selbst ne Bastellösung nicht so einfach drankommt.

  • Like 1
Link to comment

Achja, eine Frage noch.

Wenn ich die beiden NVMe jetzt zum Cache-Pool hinzufüge, wie sieht es dann mit Docker und den VMs aus? Kann ich die auch auf Cache-Datenträger verschieben bzw. installieren oder muss ich speziell für diese Anwendungen dann immer eine separate Array-Disk nehmen?

 

Edit: Okay. Scheine beim Setup ganz normal den Pfad "/mnt/cache" angeben zu können. Dann müsste das ja gehen.

 

Ich hab die zwei NVMe in separaten Cache-Pools angelegt und nach BTRFS-Encrypted formatiert. Als Array-Device einfach irgendein USB-Stick. Sieht soweit gut aus. Gab anfangs zwar ein paar Probleme beim Mounten und Formatieren. Das lag aber wohl am Unassigned-Devices-Plugin. Jetzt Läuft's.

 

Dann übertrage ich mal die Daten und hoffe, dass so in der Konfiguration alles glatt läuft. :)

Edited by Gemuesefraumann
Link to comment

BTRFS + Encrypted ? hmm, sowohl etwas gefährlich, als auch etwas paranoid :-))) Ich hätte xfs ohne Fisemattenten genommen. BTRFS is etwas "anfällig" und ab der nächsten UNRAID Version gibt es stattdessen (nee, "zusätzlich") noch zfs zur Auswahl. Um in Zukunft zerlegte Dateisysteme zu vermeiden, solltest Du vielleicht nochmal von vorne anfangen und auf BTRFS verzichten...

 

Der erste Pool heißt automatich "cache". Da werden dann auch automatisch Docker und VM Dateien angesiedelt (und verbleiben auch dort).

Du musst also nix tun.

Beim zweiten Pool kannst Du den Namen frei vergeben.

 

Du brauchst auch kein Unassigend Devices Plugin. Das ist nur dafür da, Platten zu verwalten, die weder im Array noch in Pools sind.

 

 

  • Like 1
Link to comment
1 hour ago, MAM59 said:

Ich hätte xfs ohne Fisemattenten genommen.

Da komme ich doch her. 🙄

Dachte, BTRFS würde die bessere TRIM-Kompatibilität bieten.

 

1 hour ago, MAM59 said:

zfs

Wäre das deiner Meinung nach dann die beste Option?

 

1 hour ago, MAM59 said:

etwas gefährlich

In wie fern?

 

1 hour ago, MAM59 said:

Beim zweiten Pool kannst Du den Namen frei vergeben.

Ich hatte jetzt einfach beide umbenannt und beim Setup der Container statt /mnt/user/* dann den umbenannten Cache-Pfad ausgewählt. Scheint bisher zu funktionieren.

 

1 hour ago, MAM59 said:

Das ist nur dafür da, Platten zu verwalten, die weder im Array noch in Pools sind.

Wie z.B. meine externen NTFS-Platten oder USB-Sticks. 🙂

 

Link to comment
36 minutes ago, Gemuesefraumann said:

Da komme ich doch her. 🙄

Dachte, BTRFS würde die bessere TRIM-Kompatibilität bieten.

Dann geh da auch wieder hin 😁

 

TRIM ist eine interne Funktion der Festplatte. Hat gar nix mit dem verwendeten Dateisystem oder OS zu tun (das sagt nur: MACHMA! und sie macht, oder nicht). Im Prinzip ist TRIM eigentlich transparent fürs OS/Filesystem. Es wird der Platte mitgeteilt, welche Sektoren nicht in Verwendung sind. Die Platte entscheidet dann, was damit zu tun ist. Manche werden gelöscht und "dem freien Pool" zugeordnet, manche werden als "zu alt" erkannt und ausgesondert usw. Es kann dabei zu Verschiebungen auf der Platte kommen, die kriegt das OS aber nicht mit. Dabei passiert normalerweise nichts, aber es kann auch vorkommen, dass die Platte sich "defragmentiert". Das würde dann auch Auswirkungen auf die Daten haben, und somit eine Neuberechnung der Parität erfordern. Und da die Platte davon nix sagt, hat UNRAID aus Sicherheitsgründen die TRIM Funktion für Array Platten verboten. Mit defekter Parität wäre keine Datenwiederherstellung im Fehlerfalle möglich.

36 minutes ago, Gemuesefraumann said:

Wäre das deiner Meinung nach dann die beste Option?

Keine Ahnung, noch nie probiert und ich habe auch keinen Bedarf dafür. Das hilft Dir auch nur, wenn Du mehrere Platten in einem Pool betreibst, die dann zusammengefasst werden zu einem RAID Array (bei 2 = Spiegelung, ab 3 dann RAID mit Parität). Ich hab ja UNRAID, damit ich KEIN RAID brauche 😜

Ich bleib bei simplen XFS.

(allerdings hab ich auch ein (derzeit) 54Tb Array mit normalen Platten, bei dem ich problemlos und ohne Umkonfiguration noch 12*18Tb nachwerfen könnte..,

Und dabei kommt das das eigentlich geniale Feature von UNRAID zum Tragen: ich brauch mich um die Datenverteilung nicht zu kümmern. Wird eine Platte voll, macht UNRAID von alleine woanders weiter. Von aussen sieht ein Share aus, als wenn alle Dateien gemeinsam in einem Verzeichnis wären, in Wirklichkeit können sie über viele Platten verteilt sein. Somit gibt es nie den Druck: "meine Filmplatte wird voll, ich muss ne grössere kaufen", sondern man wirft irgendwas nach, was gerade rumliegt oder man kauft irgendwas, was gerade so billig ist.)

36 minutes ago, Gemuesefraumann said:
2 hours ago, MAM59 said:

etwas gefährlich

In wie fern?

BTRFS scheint ab und zu dazu zu neigen, sich selbst zu zerstören. Zumindest gibt es darüber hier reichlich Berichte. Ich brauch son Stress nicht, zumal ich wie erwähnt gar kein RAID in den Pools haben will. Also: play it safe and sleep tight...

36 minutes ago, Gemuesefraumann said:

Ich hatte jetzt einfach beide umbenannt und beim Setup der Container statt /mnt/user/* dann den umbenannten Cache-Pfad ausgewählt. Scheint bisher zu funktionieren.

Jo, damit vermeidest Du eine Umleitung und sparst somit etwas Zeit beim Zugriff. Das ist aber zumindest meist nur ein messtechnischer Gewinn ohne Signifikanz in der Realität.

 

36 minutes ago, Gemuesefraumann said:

Wie z.B. meine externen NTFS-Platten oder USB-Sticks. 🙂

Ja ok, DAFÜR sind die unassigned Devices nötig und gut. Aber von denen hast Du bislang nix gesagt.

 

Edited by MAM59
  • Like 2
Link to comment
5 hours ago, MAM59 said:

Jo, damit vermeidest Du eine Umleitung und sparst somit etwas Zeit beim Zugriff. Das ist aber zumindest meist nur ein messtechnischer Gewinn ohne Signifikanz in der Realität.

Ganz im Gegenteil, denn über mount/User/... Wird das Fuse Dateisystem (halt die Summe aller Festplatten+Cache) angesprochen. Das erzeugt einen nicht nur messbaren Overhead. Sofern man weiß was man tut (!) ist daher die Empfehlung mit mount/cache/... zu arbeiten. Dazu müssen natürlich die fraglichen Daten dauerhaft auf dem Cache sein (womit wir wieder bei "wissen was man tut" wären)

Link to comment
1 hour ago, jj1987 said:

Das erzeugt einen nicht nur messbaren Overhead

Hey, er hat da nur 2 NVMes drin, wie groß mag da der Overhead sein? 0ms fürs "Aufwecken" und 0,0001ms für Suchen in den Directories...

Dein Einwand ist korrekt bei schlafenden, normalen, Festplatten aber bei seinem Aufbau ist da gar nix.

Link to comment

Hi,

 

also ich habe jetzt wieder beide NVMe auf XFS formatiert. Die Daten, die ich manuell drauf geschoben hab, hat er als Überordner automatisch unter Shares erfasst:

 

grafik.thumb.png.b30e355626baee5fea30cbb363ae5341.png

 

Da wäre jetzt meine Frage, wie sich das mit dem Cache-Status verhält. Ich kann ja stattdessen auch ein Share erstellen und den jeweiligen Datenträger im Cache-Pool auswählen:

 

grafik.thumb.png.6fe807f036db78659a002773a20f07aa.png

 

Was von beidem wäre in meiner Konfiguration dann anzuraten? Ein regulärer Share mit Cache-Only als Einstellung oder doch wie oben ein händisch angelegter Ordner auf dem Datenträger, der dann von Unraid unter Shares eingelesen wird?

Macht das überhaupt einen Unterschied? Gibt es hier sonst noch was zu beachten?

 

So sieht das ganze Setup zur Zeit aus:

 

grafik.thumb.png.5c5df285ab851da4832095d99375373f.png

 

An die obige Frage würde ich auch noch anschließen, wie ich jetzt am besten Docker aufsetzen sollte. Die Plugins sollen nur auf die erste NVMe gehen. Ich habe in den Docker-Settings daher erst mal "/mnt/nvme-2tb/system/docker/installed/" als Pfad hinterlegt und beim Installieren des ersten Container einfach ".../user/..." durch ".../nvme-2tb/..." ersetzt. Ist das so in Ordnung oder sollte man da weiterhin mit dem "user"-Pfad arbeiten, den man dann auf den Cache-Pool linkt?

 

Danke für eure Zeit und Hilfe! :)

 

 

 

Link to comment
7 minutes ago, Gemuesefraumann said:

Ordner auf dem Datenträger, der dann von Unraid unter Shares eingelesen wird?

Macht das überhaupt einen Unterschied? Gibt es hier sonst noch was zu beachten?

Nö, ist gehoppst wie gebügelt (also: total togal!)

 

Unraid nimmt einfach JEDES gefundene Verzeichnis und legt dafür automatisch einen Share an.

 

Allerdings hast Du Dir das Leben wieder unnötig schwer gemacht, es wurde doch mehrfach darauf hingewiesen, dass der erste Pool "Cache" heißen sollte.

Nur dann werden Freigaben wie appdata, system usw. automatisch dort erzeugt und die Shares korrekt konfiguriert. Dann wären Docker und VMs jetzt schon bereit...

 

So musse nun alles von Hand machen.

 

Und verzichte auf die ms bei "user", ich hab das damals auch gemacht in gutem Glauben. Erwies sich aber als permanente Stressquelle, denn jeder neue Docker kommt vorkonfiguriert mit user und wenn man dann nicht dran denkt, die Pfade alle von Hand anzupassen (VOR dem ersten Start), dann landet alles auf der falschen Platte und man hat echt Arbeit, alles wieder einzusortieren. Fällt erstmal gar nicht auf, da alles läuft. Nur auf dem Backup fehlen diese Docker dann leider hinterher, weil sie nicht im richtigen Pfad sind...

 

Edited by MAM59
Link to comment
10 minutes ago, MAM59 said:

Jedes gefundene Verzeichnis im Root-Verzeichnis. Ansonsten würde das zu wenig Shares ergeben

 

Ist trotzdem falsch. Es ging im Quote, auf den Du geantwortet hast, um [...]Ordner auf dem Datenträger[...].

 

Jedes Root-Verzeichnis auf einem Datenträger ergibt einen Share. Nicht jedes Verzeichnis wie Du schriebst.

 

Jetzt können wir es lassen.

 

Edited by hawihoney
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.