UnRAID: NVMe als Cache UND für VMs?

[Fladdy]

Mahlzeit an alle,

ich plane nun meinen neuen unRAID-Server, welcher neben Backups auch ein paar VMs (1-2x Win, 2x Linux) beherbergen soll.
Kann ich eine größere NVMe nehmen und auf dieser die VMs ablegen UND zugleich auch als Cache-Drive nutzen - Also es geht, aber ich wollte v.a. nach Erfahrungen dabei fragen?

Eine NVMe sollte ja ausreichend R/W-Performance haben, sodass beide "Aufgaben" auf einer NVMe laufen kann. Und ich würde mir noch einen Slot für weitere HDDs etc. sparen.


Beste Grüße und Dank im Voraus

 

[v3nom]

Ja geht. R/W ist aber bei unterschiedliche Tasks aber nur sekundär wichtig. Eher wichtig sind IOPs.
Einfach eine "gute" NVME nehmen und keine Sorgen machen

 

[Fladdy]

Das nochmal nen guter Hinweis. Also lieber 400k statt 250k IOPS. Das macht ja nun beim Neukauf nicht die Welt aus.

 

[v3nom]

Richtig robust wäre eine Intel Optane SSD die auch als Datenträger alleine genutzt werden können und nicht für die Beschleunigung von HDDs gedacht sind.

 

[Brokk]

Bei UR ist das Cache Array aber nur Write Only nicht Read Again. Also wenn du Daten auf das UR Schreibst wird's schneller, sobald die Daten aber vom Moover auf das HDD Array geschrieben werden (und nicht mehr im Cache sind) dann bekommst du nur die Performance einer einzelnen HDD nicht die des Caches oder aller HDDs

 

[HisN]

Du kannst dem Mover ja verbieten das Verzeichnis der VMs anzufassen (Cache: Prefer, Exclude: All Disk).

 

[hominidae]

...ein einfaches "Cache only" tut es auch. Dein Beispiel wirkt nur durch das "Exclude: all".

Use cache (for new files/directories): Only - Mover takes no action
Specify whether new files and directories written on the share can be written onto the Cache disk/pool if present.
This setting also affects mover behavior.
No prohibits new files and subdirectories from being written onto the Cache disk/pool.
Mover will take no action so any existing files for this share that are on the cache are left there.
Yes indicates that all new files and subdirectories should be written to the Cache disk/pool, provided enough free space exists on the Cache disk/pool.
If there is insufficient space on the Cache disk/pool, then new files and directories are created on the array.
When the mover is invoked, files and subdirectories are transferred off the Cache disk/pool and onto the array.
Only indicates that all new files and subdirectories must be writen to the Cache disk/pool.
If there is insufficient free space on the Cache disk/pool, create operations will fail with out of space status.
Mover will take no action so any existing files for this share that are on the array are left there.
Prefer indicates that all new files and subdirectories should be written to the Cache disk/pool, provided enough free space exists on the Cache disk/pool.
If there is insufficient space on the Cache disk/pool, then new files and directories are created on the array.
When the mover is invoked, files and subdirectories are transferred off the array and onto the Cache disk/pool.
NOTE: Mover will never move any files that are currently in use.
This means if you want to move files associated with system services such as Docker or VMs then you need to disable these services while mover is running

 

[HisN]

Ich hatte das gesterne erst offen, und kein "Only" gesehen. Eventuell kommt es daher. Schau ich mir glatt nochmal an.

 

[hominidae]

...wenn das share neu angelegt wird, ist "only" die Wahl.
Wenn das share schon existiert und schon Daten auf dem Pool sind, dann erst "prefer", dann den mover laufen lassen, dann auf "only" stellen.

Edit: die Einstellung betrifft immer "neue" Daten und Ordner, seit der Änderung der Einstellung. Der Mover bewegt auch keine Daten, die von einer App geöffnet sind, Bei VMs und Docker also vorher den Service ausschalten, damit alles eindeutig ist.

 

[Fladdy]

Besten Dank für eure Antworten.
Ich bin nun mittlerweile etwas weiter und mein unRAID-Server läuft auch schon und transferiert nun fleissig Daten von der alten NAS. Nur mit den VMs / Docker-Containern warte ich noch.

Aber nun ist die Nutzung auch etwas klarer, daher frage ich nochmal genauer nach euern Erfahrungen (Google und Co waren nicht so ergiebig).

Vorabinformation zur Nutzung:
- Array: etwa 20TB BackupStorage für Fotos und Backups
- VMs und Container:
** 1x Win10: für paar ältere Spiele ab und an (C&C Red Alert 2 etc.) - läuft nur bei Bedarf
** 1x Win10: für Windows-Software die es nicht anderweitig gibt (Tobit Software E-Mail Server)
** Dockercontainer: ioBroker für Hausautomation, Pi-Hole DNS-Server, 2x Codeserver Instanz, ownCloud-Client zur Sicherung, Cloudberry BackupManager, 2x OctoPrint Interface für 3D-Drucker

Es ist also nichts sonderlich IO-lastiges dabei, sprich keine größeren DBs etc.

Fragen / Meinungen von / an euch:
1. Brauche ich wirklich ne Cache-SSD/NVMe ? Die Schreibvorgänge auf das Array sind alle nicht zeitkritisch, da es nicht mein Datenspeicher aktiv ist, sondern lediglich Backup-Storage. Die Backups werden
a) von den Systemen ins Share geschrieben (Acronis Images, ZIP-Files)
b) per Script via sFTP/rsync gezogen

Ich hätte wohl noch ne 250GB Samsung 860 Pro ausm alten Homeserver, die erst 6 Monate hinter sich hat und dafür verwendet werden könnte. Beleg halt nur leider nen sATA-Port und nimmt auch wieder paar W.


2. Für die VMs / Dockerimages würde ich gerne ne SSD/NVMe dazunehmen, auch um den Stromverbrauch nicht unnötig durch Laufen des Arrays zu erhöhen.
Wobei ich da mittlerweile denke, dass es auch "nichts besonderes" sein muss, sondern ggf. auch einfach ne Crucial P1 langt, die einfach von der P/L nen augenscheinlich guter Deal ist (1TB für 84€ gerade im Angebot). Die VMs werden natürlich regelmäßig gesichert aufs Array.

Würde mich über Rückmeldungen SEHR freuen, gerade was so euer Eindruck ist, was wirklich sinnvoll ist.

 

[Brokk]

Also VMs ohne Cache Array ist nicht besonders angenehm .... Deswegen würde ich ein Pärchen in UR einbauen. Weil das Cache Array zumindest RAID1 ist. UR macht kein Backup vom Cache und das ist auch nicht mit dem Parity Drive abgesichert.

Ich hab halt alle meine alten SSDs (250 GB SATA x8 als Cache Array@R1) in meinen Server eingebaut. Sicher nicht optimal aber was solls...

Das was im Cache bleiben soll ist vom Mover ausgeschlossen, ansonsten bewegt dieser alles auf das HDD Array

VMs nutze ich auf UR nicht da ich das ganze virtualisiert habe. VMs laufen bei mir nativ auf dem ESXi auf NVMEs.

Die VMs sichere ich mit Veeam direkt vom ESXi auf das UR und da hilft der Schreibcache schon gewaltig

 

[Fladdy]

Besten Dank für deine Antwort. Die VMs und Docker Container sollen eh gesondert auf einer NVMe liegen, daher bringt denen ein Cache Drive nichts.
Vielleicht muss ich die Übertragungsraten mal in der aktuellen Variante testen. Wenn ich das richtig sehe, dann müsste ja das Cache Drive auch sehr groß sein, wenn man mal nen Full Image sichert (300-400GB), da das ja dann erst auf auf auf die Cache SSD geht und dann verschoben wird? Was passiert denn, wenn die Cache SSD voll ist? Also sagen wir mal, dass ich ne 250GB SSD als Cache drive einbaue und dann aber ne 300GB Datei auf ein Share schiebe. Was passiert dann? Oder wenn ich 3x100 GB nacheinander kopiere?

irgendwie ist mir das nicht so ganz klar :/

Viele Grüße

 

[Ceiber3]

Dann bricht der Speed ein.

 

[Brokk]

Ich weiß nicht ob man in UR eine einzelne Festplatte so einfach als Single Laufwerk einrichten kann. Sollte gehen bare da musst du suchen...

Normalerweise hat man ein HDD Array und ein Cache Array. Man kann auch einzelne HDDs mounten, hab ich aber noch nicht genutzt.

Das Cache Array ist normalerweise für die VMs, Docker und den Cache gedacht. Die VMs und Docker sind vom Mover ausgeschlossen.
Beide Dienste und deren Daten liegen auf dem Cache Array (alle VM Files!)

Also pass dein Cache Array entsprechend den Anforderungen an (VMs + Docker + Cache)

Speed oder Große Dateien:
Genau dann bricht der Speed der Übertragung ein aber es wird weiterhin geschrieben (dann eben auf die HDDs). Danach räumt der Mover im Hintergrund auf, je nachdem wie man den eingestellt hat.

Wie oft machst du ne Vollsicherung? Bei mir kümmert sich Veeam um die Sicherungen und bisher ist damit nichts kaputt gegangen, es sei dem ich hab selbst dran rum gefummelt :P (Forever Incremental + Synthetic Full Backups)

 

[Fladdy]

"Eigentlich" geht das mit nem single-Laufwerk Array, auf dem dann "nur" die VMs/Container liegen.
Ah okay, dann also besser ne 1TB NVMe (neu würde ich ne NVMe kaufen statt SSD, da mir das nen SATA-Port spart und es preislich keinen großen Unterschied macht) für Cache + VMs/Docker, damit ausreichend Platz als Cache bleibt (bzw. mehr oder flexibler oder was auch immer).

Wie oft machst du ne Vollsicherung? Bei mir kümmert sich Veeam um die Sicherungen und bisher ist damit nichts kaputt gegangen, es sei dem ich hab selbst dran rum gefummelt :P (Forever Incremental + Synthetic Full Backups)

Ich mache nicht "forever incremental", sondern glaube pro Quartal nen FULL. Über die Sinnhaftigkeit können wir aber anderswo diskutieren :P Laufen auch noch andere Routinen, welche relativ große Backupdateien erzeigen (sogenannte Strongbox-Images, die so um die 100GB/Datei haben).

 

[hominidae]

Was passiert denn, wenn die Cache SSD voll ist? Also sagen wir mal, dass ich ne 250GB SSD als Cache drive einbaue und dann aber ne 300GB Datei auf ein Share schiebe. Was passiert dann? Oder wenn ich 3x100 GB nacheinander kopiere?

Es kommt darauf an, wie das zugehörige share in Bezug auf die Verwendung vom Cache konfiguriert ist, wie sich der mover dabei verhält und wie oft er angeschubst wird.

Specify whether new files and directories written on the share can be written onto the Cache disk/pool if present.
This setting also affects mover behavior.

No prohibits new files and subdirectories from being written onto the Cache disk/pool.
Mover will take no action so any existing files for this share that are on the cache are left there.

Yes indicates that all new files and subdirectories should be written to the Cache disk/pool, provided enough free space exists on the Cache disk/pool.
If there is insufficient space on the Cache disk/pool, then new files and directories are created on the array.
When the mover is invoked, files and subdirectories are transferred off the Cache disk/pool and onto the array.

Only indicates that all new files and subdirectories must be writen to the Cache disk/pool.
If there is insufficient free space on the Cache disk/pool, create operations will fail with out of space status.
Mover will take no action so any existing files for this share that are on the array are left there.

Prefer indicates that all new files and subdirectories should be written to the Cache disk/pool, provided enough free space exists on the Cache disk/pool.
If there is insufficient space on the Cache disk/pool, then new files and directories are created on the array.
When the mover is invoked, files and subdirectories are transferred off the array and onto the Cache disk/pool.

NOTE: Mover will never move any files that are currently in use.
This means if you want to move files associated with system services such as Docker or VMs then you need to disable these services while mover is running.

 

[Fladdy]

Ehm ja. Schön, dass du gerade das zitierst, da YES und PREFER in der Beschreibung IDENTISCH sind

 

[Ceiber3]

Du kannst nur ein Speicher Array und ein Cache Array erstellen. Das wollen sie aber scheinbar ändern. Spielt aber auch keine Rolle. Du kannst bei jeden Share sagen welche Festplatte/SSD verwenden werden sollen. Alle oder nur bestimmte. Wenn die NVME als Beispiel im Array die Vierte Festplatte ist, legst du halt ein Share an wo du sagst, nur die Vierte Festplatte/SSD verwenden.

 

[hominidae]

nope,,,die Richtung in welcher der mover die Daten behandelt ist umgekehrt!

prefer: off the array and onto the cache
yes: off the cache and onto the array

Beitrag automatisch zusammengeführt: 30.08.2020

Du kannst nur ein Speicher Array und ein Cache Array erstellen. Das wollen sie aber scheinbar ändern. Spielt aber auch keine Rolle. Du kannst bei jeden Share sagen welche Festplatte/SSD verwenden werden sollen. Alle oder nur bestimmte.

genau, in der 6.9beta schon zu sehen.
Aber grundsätzlich nicht vergessen, dass es nicht viel Sinn macht eine NVMe ins Array als Daten-Disk zu packen, wenn Parity nicht auch eine NVMe ist ;-)

 

[Brokk]

Haben die das endlich verbessert? Vor SSDs im Array wurde doch immer abgeraten? Irgendwas mit Parity, TRIM und Garbagecollection ...

Weil.... sinwirmalehrlich..... ein SSD only Array wäre sowasvoncool

 

[Ceiber3]

Nea ich sehe da kein Problem. Normale SSD's als Array und eine schnelle gute NVMe als Parity.

 

[hominidae]

Haben die das endlich verbessert? Vor SSDs im Array wurde doch immer abgeraten? Irgendwas mit Parity, TRIM und Garbagecollection ...

Weil.... sinwirmalehrlich..... ein SSD only Array wäre sowasvoncool

Weiss ich nicht, ist auch noch mein Stand,
Meine Anmerkung war eher zur Vorsicht gedacht, wenn man sagt, dass man ja auch eine Array-Disk exklusiv für ein Share bestimmen kann.

In der 6.9beta kann man ja einen extra Pool ohne Parity bauen.

 

[Fladdy]

Ehm ja, wir driften etwas ab (ich stimme aber zu, dass es ideal wäre, wenn die Parity der schnellst Speicher ist, aber das nen anderes Thema).

Zurück zum Thema und für mich zur Klarheit:
- Ich packe da ne 1TB NVMe als Cache rein und dann
1. Nutze ich die für die einzelnen Shares diese NVMe als Cache im Modus "YES" (sprich Daten werden zuerst darauf geschrieben und dann vom Mover z.B. morgens früh auf das Array verschoben; wenn Cache voll, dann geht es gleich langsam in Array)
2. Darauf können außerdem die Docker-Container (Ordnerpfade der Container entsprechend angeben), VMs (Ordner domains) und andere unRAID-Daten (Ordner appdata & system) liegen (nicht gesichert, i know - das würde ich manuell per Script tun) => Dies wäre für die Ordner/Shares einfach die Einstellung "Cache: Only"?

Korrekt?

PS: Ja ich weiß, dass natürlich nen Cache/System-Array als Raid1 besser/sicherer/schöner wäre, aber das kann man ja noch nachholen
PS2: Wie "wichtig" ist die Qualität der NVMe in meinem Szenario? Wie gesagt liegt da nix dramatisches drauf und selbst wenn die abschmiert und der Mover die Daten noch nicht verschieben konnte, dann wäre das auch nicht dramatisch). Würdet ihr sagen, dass man da ruhig zu etwas mit gutem P/L (wie ne P1 NVMe) greifen kann? Oder lieber was besseres? Habt ihr da ne "vertretbare" Empfehlung?
Mir ist bei sowas schon klar, dass mehr ausgeben auch (im Idealfall) mehr Sicherheit in Hinblick auf langlebiger bedeutet (bzw. eher bedeuten KANN). Aber letztlich isses auch nur nen Storage und meine Synology 1815+ kam nun auch 5 Jahre so klar =)

@Ceiber3: Ich sehe in deiner Signatur in etwa so ne Konfiguration, wie ich es zuerst dachte. Also nen HDD Array als Storage und dann eine NVMe als Cache und eine NVMe für System und VMs. Hast du dafür die "System"-NVMe im Array aufgenommen und dann bei den Shares diese überall ausgeschlossen?

 

[hominidae]

..korrekt.
Die "Ordner" appdata, domains und system sind auch "shares".
Bevor Du über "Settings -> Docker bzw VMS" den Service aktivierst, stellst Du diese drei shares auf Cache-"only".
Wenn Du aber schon "gespielt" hast und schon Daten auf dem Array sind - Docker/VM Service stopen, Shares auf "prefer", den mover manuell starten, wenn der durch ist, shares auf Cache-"only" und dann erst wieder die Docker/VMS-Services starten...voila.

 

[Fladdy]

Top! Habe extra noch keine VMs und Container eingerichtet, da ich diese "Thematik" hier erst final beantwortet und eingerichtet haben wollte
PS: ist nun eine SN750 1TB geworden

 

[Brokk]

Wie sicher ist neine einzelne Festplatte? Mir sind grade simultan 3 NVMEs (Samsung!) zeitgleich verstorben. Man muss dazu sagen die waren in mittelschwerem Gebrauch und vor allem randvoll. Zuhause sieht das anders aus da läuft das seit nem Jahr stabil

Sagen wir einfach, so sicher wie deine Sicherungsstrategie

 

[Fladdy]

Jo klar. Wobei die VMs nicht so super kritisch sind und ich von ebendiesen auch noch Sicherungen aufs Array und ne andere NAS mache. Könnte natürlich passieren, dass der Cache mal verloren geht, aber alles gut.
Denke eher darüber nach noch ne zweite Parity einzubinden

 

[Brokk]

Das bringt nicht so viel wie man meint das es bringt ... Ich würde eher Geld in eine USV und ne 2. NVME als R1 investieren.

Das mal der Strom ausfällt kann vorkommen, ist bei mir schon 2x passiert.

Consumer Hardware hat keine Power Loss Protection. Schreibst du was aufs Array und ziehst den Stecker, dann ist alles putt. Kann gut gehen muss aber nicht :/

Dann noch ein robustes Backup und du brauchst keine 2. Parity HDD.

 

[Fladdy]

Ja hängt eh an einer großen USV im Schrank. Und Sicherung auf ne zweite NAS einiger Daten ist auch da.
Meinst wirklich noch das Cache Laufwerk absichern? Hmmm

 

[Ceiber3]

Deswegen ist bei Cache benutzung eigentlich eine USV Pflicht.