Denkfehler beim Thema SSD Cache Pools?

[Kabelgewirr]

Hallo zusammen,

 

könnt Ihr mir bitte nochmal helfen, ich glaube in meiner Systemauslegung hat sich noch mindestens ein Denkfehler versteckt.

 

Ich hatte für mein neues System eigentlich 2 x 2TB SSDs als Cache Pools geplant. Einen File/ Write Cache, einen Docker/ VM Cache.

 

Die Idee für den File/ Write Cache war, hier häufig benötigte Dateien *dauerhaft* für einen schnellen Zugriff vorzuhalten, die aber auch regelmäßig ins Array gesichert werden. Mittlerweile glaube ich aber verstanden zu haben, dass Unraid nur entweder Cache oder Array unterstützt (Mover). Müsste ich hier, analog zum Backup des Docker/ VM Cache Pools (appdata backup) selber ein geeignetes Backup aufsetzen? 

 

Oder ist die Vorgehensweise generell nicht sinnvoll? Wie habt ihr das gelöst, auch im Sinne von redundanten Backups?

 

Und noch eine Frage zur Größe der SSDs, ich dachte an 2 x 2TB, weil ich das hier häufiger so gesehen haben und viel hilft viel... Mittlerweile beschleicht mich aber der Verdacht, dass das für meine Anforderungen kapital überdimensioniert ist. Insbesondere wenn ich den File/ Write Cache tatsächlich nur als temporären Zwischenspeicher nutzen kann/ sollte und der Mover einmal täglich läuft, wüsste ich nicht, wie ich die 2TB jemals ausnutzen sollte. Aber vielleicht habe ich hier auch noch einen Denkfehler?

 

Und analog für den Docker/ VM Cache Pool. Bei mir werden maximal 2 VMs gleichzeitig laufen (1xLinux, 1x Windows) und dazu höchstens ein Dutzend Docker (das "übliche": Jellyfin, Nextcloud, Paperless, AdGuard, *arr...). Welchen Platz werde ich dafür etwa brauchen, gefühlt komme ich auch hier nicht mal in die Nähe von 2TB? 

 

Und eine letzte Frage, separate Cache Pools wie oben beschrieben vs. einen Raid1 Cache Pool. Es scheint, dass die meisten User Variante 1 bevorzugen - ist der Unterschied in der Performance tatsächlich so groß, dass er den Nachteil bzgl. der Datensicherheit aufwiegt? Auch wenn bei täglichem Run des Movers der potentielle Datenverlust relativ gering ist, fallen SSDs in der Regel aber doch spontan und vollständig aus.

 

Ich wäre euch dankbar wenn ihr meine Gedanken etwas entknoten könntet...!

[saber1]

Nicht der Cache selbst ist per se "entweder Cache oder Array", sondern die jeweiligen Shares.

Pro Share kannst Du einstellen, ob Cache oder Array.

 

Du kannst auch sagen, das ein Share dauerhaft auf dem Cache bleibt. Dann landet halt nichts im Array.

In so einem Fall wäre es dann gut, ein Backup-Lösung parat zu haben.

 

EDIT:

Du kannst also mehrere Shares mit unterschiedlichen Einstellungen auf einem einzigen Cache haben.

Edited June 18 by saber1

[_alo_]

2 hours ago, Kabelgewirr said:

Und eine letzte Frage, separate Cache Pools wie oben beschrieben vs. einen Raid1 Cache Pool. Es scheint, dass die meisten User Variante 1 bevorzugen - ist der Unterschied in der Performance tatsächlich so groß, dass er den Nachteil bzgl. der Datensicherheit aufwiegt? Auch wenn bei täglichem Run des Movers der potentielle Datenverlust relativ gering ist, fallen SSDs in der Regel aber doch spontan und vollständig aus.

ich habe einen RAID1 Cachepool aus 2x 1TB NVMes. Ich bin aber auch schon am überlegen auf 2x 2TB oder sogar mehr aufzurüsten, warum?

 

Aktuell habe ich nur eine VM (Homeassistant, belegt aber schon 25GB) und dazu aktuell 17 docker Container. Der Cache ist damit nur zu 11% belegt.

Ich kopiere jedoch teilweise recht große Datenmengen auf den Server, die aus Geschwindigkeitsgründen über den Cache laufen und per Mover später auf dem Array landen. Parallel möchte ich aber auch einige Daten bzw Shares permanent auf dem Cache-Pool liegen haben, aus Geschwindigkeits- (z.B. "Lancache") und Stromspargründen (das Array soll für die Zugriffe nicht immer anlaufen). Dann werden 1TB irgendwann schon knapp...

Um über den Tag zu kommen ist ein RAID1 hierbei für mich unerlässlich! nächtliche Backups schön und gut, aber wenn Dir der nichtredundante Schreibcache tagsüber nach ein paar (hundert) verschobenen GB stirbt....🤨

 

P.S.: 

aktuell hab ich noch alte rumliegende SATA-SSDs zusätzliche zum Cache verbaut und als "normalen" Pool für solche Shares konfiguriert, für die das Array nicht anlaufen soll. So kann man cache und Pool natürlich auch trennen, macht aber wenig Sinn, ich hätte lieber einen, größeren cache

[Kabelgewirr]

Danke euch für den schnellen Input!

 

3 hours ago, saber1 said:

Du kannst auch sagen, das ein Share dauerhaft auf dem Cache bleibt. Dann landet halt nichts im Array.

In so einem Fall wäre es dann gut, ein Backup-Lösung parat zu haben.

Ja, das hatte ich auch so verstanden, ist in Fall des Docker/ VM Cache Pools ja auch so. Aber es geht mit Hausmitteln (Mover) eben nur Cache ODER Array, kein UND. Im UND Szenario muss ich selber dafür sorgen, dass die Daten auch ins Array kopiert werden (LuckyBackup o.ä.), korrekt? Das wunderte mich nur, da ich das für einen gängigen Anwendungsfall gehalten habe.

 

2 hours ago, _alo_ said:

Aktuell habe ich nur eine VM (Homeassistant, belegt aber schon 25GB) und dazu aktuell 17 docker Container. Der Cache ist damit nur zu 11% belegt.

Ok, perfekt - damit habe ich ja schon einen guten Anhaltspunkt, gerade mal ~100GB für all die Docker plus VM. Und trotzdem Platzangst 

 

2 hours ago, _alo_ said:

Um über den Tag zu kommen ist ein RAID1 hierbei für mich unerlässlich!

Ehrlich gesagt wäre mir für einen gesunden Schlaf ein Raid1 auch lieber. Aber wie sieht es mit der Performance aus, bei dir laufen eine Menge Docker und es fließen viele Daten auf dem gleichen Cache Pool, kein signifikanter Nachteil?

 

Und wie hast du das Thema Backup bei den permanent auf dem Cache Pool liegenden Shares gelöst? Ein LuckyBackup Docker?

[_alo_]

1 minute ago, Kabelgewirr said:

Ok, perfekt - damit habe ich ja schon einen guten Anhaltspunkt, gerade mal ~100GB für all die Docker plus VM. Und trotzdem Platzangst 

naja Platzangst eben wegen der zusätzlichen Sachen die im Cache (vorübergehend) liegen sollen, nicht wegen der Container

 

1 minute ago, Kabelgewirr said:

Ehrlich gesagt wäre mir für einen gesunden Schlaf ein Raid1 auch lieber. Aber wie sieht es mit der Performance aus, bei dir laufen eine Menge Docker und es fließen viele Daten auf dem gleichen Cache Pool, kein signifikanter Nachteil?

 

Und wie hast du das Thema Backup bei den permanent auf dem Cache Pool liegenden Shares gelöst? Ein LuckyBackup Docker?

ich wüsste nicht, wo da bei einer Spiegelung ein Nachteil sein soll. Dieses Software-Raid zieht doch heutzutage keine spürbare Performance mehr.

Backup?

• die VM sichere ich per luckybackup-cronjob
• appdata der docker Container dann über das "backup/restore appdata"-Plugin.

[Kabelgewirr]

16 minutes ago, _alo_ said:

ich wüsste nicht, wo da bei einer Spiegelung ein Nachteil sein soll. Dieses Software-Raid zieht doch heutzutage keine spürbare Performance mehr.

Der Performancenachteil kommt nicht durch das Raid, sondern dadurch dass die Docker/ VMs sich die Schreib-/ Lesezugriffe mit den nebenbei laufenden Dateioperationen teilen (Fileserver, Downloads etc.). Daher wird auch hier im Forum in der Regel empfohlen, die Cache Pools für Docker/ VM und andere Dateioperationen zu trennen. Mich hat interesseiert wie stark dieser Performancenachteil zu spüren ist.

 

25 minutes ago, _alo_ said:

Backup?

• die VM sichere ich per luckybackup-cronjob
• appdata der docker Container dann über das "backup/restore appdata"-Plugin.

Du hattest geschrieben: "Parallel möchte ich aber auch einige Daten bzw Shares permanent auf dem Cache-Pool liegen haben" - ich bin davon ausgegangen, dass es sich dabei nicht um Docker/ VM Daten handelt, sondern um klassische Fileserverdaten (Dokumente). Wenn dem so ist, sicherst du die auch mit LuckyBackup ins Array? 

[_alo_]

25 minutes ago, Kabelgewirr said:

Mich hat interesseiert wie stark dieser Performancenachteil zu spüren ist.

da merke ich bei meinen NVMes nichts von, hab davon auch noch nichts gelesen. Bei HDDs könnte ich mir den Nachteil gut vorstellen, aber bei SSDs 🤔 zumal bei den meisten docker containern eh nicht viel Dateioperationen passieren...

25 minutes ago, Kabelgewirr said:

Du hattest geschrieben: "Parallel möchte ich aber auch einige Daten bzw Shares permanent auf dem Cache-Pool liegen haben" - ich bin davon ausgegangen, dass es sich dabei nicht um Docker/ VM Daten handelt, sondern um klassische Fileserverdaten (Dokumente). Wenn dem so ist, sicherst du die auch mit LuckyBackup ins Array? 

ja ok, abseits von docker/VM dann entweder auch per luckybackup oder eben bei Unwichtigerem ganz ohne (Lancache, TimeMachine,... da reicht mir der Spiegel)

 

Der Mover ist ja nur ein Helfer für einen möglichen(!) Schreibcache, d.h. Du schreibst auf schnellen, kleinen Cache und später werden die Daten auf's große, langsame Array verschoben. Da hat man dann auch erstmal kein Backup (außer man richtet sich das ein auf ein backup NAS, USB-Platten, ...).

Ich lasse halt bestimmte Shares komplett auf dem Cache-Pool 🤷‍♂️  die kann ich dann wie die Daten des Arrays über luckybackup oder mgutts RSYNC-Skript o.ä. irgendwohin (Array, USB, NAS) sichern oder auch nicht

 

Edited June 18 by _alo_

[Kabelgewirr]

49 minutes ago, _alo_ said:

da merke ich bei meinen NVMes nichts von, hab davon auch noch nichts gelesen. Bei HDDs könnte ich mir den Nachteil gut vorstellen, aber bei SSDs 🤔 zumal bei den meisten docker containern eh nicht viel Dateioperationen passieren...

Ok, ich denke eben auch, dass das bei meinem Einsatzszenario nicht wirklich spürbar ist und erst bei signifikant höherer Last oder höheren Anforderungen relevant wird. Dann werde ich auch erst mal mit einem Raid1 Cache Pool ins Rennen gehen und mich etwas mehr mit den verschiedenen Backupoptionen beschäftigen.

 

Vielen Dank für die Unterstützung!

[DataCollector]

2 hours ago, Kabelgewirr said:

Im UND Szenario muss ich selber dafür sorgen, dass die Daten auch ins Array kopiert werden (LuckyBackup o.ä.), korrekt? Das wunderte mich nur, da ich das für einen gängigen Anwendungsfall gehalten habe.

 

Info: Man kann für das, was Du vor hast (Daten Im Cache haben und ab und zu wo anders hin backuppen) zwar auch extra Apps nutzen die im namen "Backup" oder so stehen haben, aber ein simples Script, welches zeitabhängig einfach von x nach y kopiert sollte auch schon reichen,. Wenn man bei y die alten Daten auch entfernen will, nimmt man rsync oder so.

[DataCollector]

1 hour ago, _alo_ said:

da merke ich bei meinen NVMes nichts von, hab davon auch noch nichts gelesen. Bei HDDs könnte ich mir den Nachteil gut vorstellen, aber bei SSDs 🤔 zumal bei den meisten docker containern eh nicht viel Dateioperationen passieren...

 

Das hängt eben stark von der Nutzung und Fähigkeiten/Qualität der NVMe SSD ab.

 

Wenn ich mit 10GBlan einige TB am Stück in eine 'normal performante' SSD rein schieße, kommt die (SLC -Cache auslastend und erwärmungsbedingt etc...) schnell in den Bereich. in dem sie von ihrem 'ach so tollen xxxxTB/s Papierwerten' eher auf einmal unter 1GByte/s einbricht. Dann muss sich das System entscheiden ob es die Operationen der einlaufenden Dateien vom 10GBlan bevorzugt oder parallel laufende VM/Docker. Mir stocken meine VM zu sehr.

 

Das ist der Hauptgrund warum ich dann für den Dateicache doch etwas größere NVMe SSDs (4TB) als Cache für Nutzdaten installiert habe und Docker/VM nebenher auf extra NVMe SSD liegen.

Wobei die SSD für VM/Docker nicht so groß sein muß. Eine VM mit 80GB und ein Dockercontainer kleiner 80GB und man kann dafür wunderbar eine alte 250GB SSD vom Grabbeltisch nehmen.

 

Aber da eben nicht jede Person unbedingt mit MultiGB Lan am Stück so große Datenmengen in sein System rein preßt ist es eben (wie gesagt) abhängig von der Nutzung. Mein Maximum war schon einmal rund 3,5TB am Stück in mein großes unraidsystem zu schieben.

 

[_alo_]

9 hours ago, DataCollector said:

Das ist der Hauptgrund warum ich dann für den Dateicache doch etwas größere NVMe SSDs (4TB) als Cache für Nutzdaten installiert habe und Docker/VM nebenher auf extra NVMe SSD liegen.

Wobei die SSD für VM/Docker nicht so groß sein muß. Eine VM mit 80GB und ein Dockercontainer kleiner 80GB und man kann dafür wunderbar eine alte 250GB SSD vom Grabbeltisch nehmen.

 

Aber da eben nicht jede Person unbedingt mit MultiGB Lan am Stück so große Datenmengen in sein System rein preßt ist es eben (wie gesagt) abhängig von der Nutzung. Mein Maximum war schon einmal rund 3,5TB am Stück in mein großes unraidsystem zu schieben.

 

OK, also quasi so wie ich das derzeit mangels großer SSDs handhabe: 2 Pools (s.o.).

VM/Docker nur auf eine einzelne SSD halte ich für riskant, wenn doch schon das Stocken der VMs ein Problem darstellt - ich würde das dann spiegeln, kostet bei 250gb ja auch nix. Nur eben die SATA Ports, aber das ist eh das Problem, wenn man auf mehrere (kleinere) Platten aufteilt...

 

Natürlich ist das vom Nutzungsverhalten abhängig, aber ich bin davon ausgegangen, das der TE eher von normalem Hausgebrauch ausgeht.

Wenn 20 Personen gleichzeitig drauf zugreifen ist es sicherlich auch was anders, da hätte ich vielleicht drauf eingehen sollen: meinen Server nutze ich primär noch alleine und er ist nur mit 2,5GE angebunden.

Als ich beim Wechsel von Synology die ca. 20TB per Rsync draufgeschoben habe, hab ich übrigens den Schreibcache einfach temporär deaktiviert um die SSDs zu schonen und bin direkt auf's Array gegangen. Jetzt hab ich für die entsprechenden Shares wieder tiered storage aktiviert.

 

[DataCollector]

3 hours ago, _alo_ said:

OK, also quasi so wie ich das derzeit mangels großer SSDs handhabe: 2 Pools (s.o.).

VM/Docker nur auf eine einzelne SSD halte ich für riskant, wenn doch schon das Stocken der VMs ein Problem darstellt - ich würde das dann spiegeln, kostet bei 250gb ja auch nix.

Das Problem ist eher, daß man dafür 2x NVMe Anschlüsse frei haben muß.

Ich brauche das für meine Docker/VM eigentlich nicht. ich mache ab und zu von der SSD Backups und lege die im array ab.

Aber das kann jeder ja gerne individuell handhaben.

 

3 hours ago, _alo_ said:

Nur eben die SATA Ports,

Ging es oben nicht um NVMe?

 

3 hours ago, _alo_ said:

Als ich beim Wechsel von Synology die ca. 20TB per Rsync draufgeschoben habe, hab ich übrigens den Schreibcache einfach temporär deaktiviert

 

Habe ich bei meinem großen System auch aktuell, da ich momentan >300TB an Daten neu aufschreibe. Die SSD wäre dann sowieso zwischen "kaum hilfreich" und "schon signifikant verschlissen".

Wenn das alles fertig kopiert, verteilt  (und die neue Parity gebildet íst) werde ich den 4TB NVMe Cache wieder zuschalten.

 

[Kabelgewirr]

19 hours ago, DataCollector said:

Info: Man kann für das, was Du vor hast (Daten Im Cache haben und ab und zu wo anders hin backuppen) zwar auch extra Apps nutzen die im namen "Backup" oder so stehen haben, aber ein simples Script, welches zeitabhängig einfach von x nach y kopiert sollte auch schon reichen,. Wenn man bei y die alten Daten auch entfernen will, nimmt man rsync oder so.

Ja, so werde ich das dann wohl auch machen. Mich wunderte wie gesagt nur, dass das scheinbar kein üblicher Usecase ist - Arbeitsdokumente dauerhaft im schnellen Cache, gleichzeitig regelmäßig ins Array gesichert (kopiert). Dazu kommt, dass die verschiedenen Backupoperationen nachts auch möglichst effizient abgearbeitet werden sollten. Wenn das jetzt mehrere Prozesse übernehmen müssen (Mover, LuckyBackup, Appdata Backup, rsync etc.) die alle gleichzeitig z.B. um 2 Uhr starten, kommen die sich beim Schreiben ins Array ja auch wieder gegenseitig in die Quere.

 

19 hours ago, DataCollector said:

Das hängt eben stark von der Nutzung und Fähigkeiten/Qualität der NVMe SSD ab.

9 hours ago, _alo_ said:

Natürlich ist das vom Nutzungsverhalten abhängig, aber ich bin davon ausgegangen, das der TE eher von normalem Hausgebrauch ausgeht.

 

Normaler Hausgebrauch ist richtig, wobei darunter vermutlich auch jeder etwas anderes versteht, Aber auf die oben beschriebenen Datenvolumen werde ich nicht kommen. Insofern passt der Raid1 Ansatz für mich erst mal, auftrennen kann ich den Pool dann immer noch, sollte sich die Notwendigkeit ergeben. Auch wenn das nicht mal eben so gemacht ist, wenn ich das richtig verstanden habe...

 

6 hours ago, DataCollector said:

Ging es oben nicht um NVMe?

Ja, korrekt. In einer idealen Welt wären mehrere Raid1 Cache Pools sicher optimal, aber das scheitert schon an der Hardware/ Ports und auch an der Lizenz. Insofern habe ich nur die beiden Optionen 2 separate Cache Pools ungesichert oder 1 Cache Pool mit Raid1 gesichert. 

 

Allerdings geht es bei dieser Frage ja nicht nur um den verfügbaren Platz und die Datensicherheit (und die Kosten), sondern auch um die Langlebigkeit der Hardware, korrekt? Bei getrennten Cache Pools würde die Hardware eines Docker/ VM Cache Pools sicher länger leben, als ein Cache Pool der jeden Tag tonnenweise Daten schaufeln muss...

[DataCollector]

3 hours ago, Kabelgewirr said:

Allerdings geht es bei dieser Frage ja nicht nur um den verfügbaren Platz und die Datensicherheit (und die Kosten), sondern auch um die Langlebigkeit der Hardware, korrekt? Bei getrennten Cache Pools würde die Hardware eines Docker/ VM Cache Pools sicher länger leben, als ein Cache Pool der jeden Tag tonnenweise Daten schaufeln muss...

 

Sofern die SSD für beide Pools identisch sind: ja.

Ich gehe zumindest in meinem Fall davon aus: 

a) mein Datencache für das Array ist der groß, was den TBW gegenüber einer sehr kleinen SSD ähnlicher Qualität sehr erhöht.

b) mein Datencache wurde brandneu eingesetzt, wodurch er noch nicht 'angebrochen'/verschlisen ist.

c) In meinem Datencache sind eben wirklich nur temporäre Daten. Sollte diese SSd wirklich im betrieb versterben fällt das sehr schnell auf und da ich nie in mein urnaid verschiebe, sondern immer kopiere verliere ich keine Daten, da sie an der Quelle auch noch eine gewisse Zeit (Tage/Wochen/Monate) vorhanden sind.

d) meine Docker/VM SSD ist alt und dagegen erheblich kleiner klein.

e) meine Docker/VM SSD wird ab und zu gesichert, da meine Docker und VM nichts wirklich tagesaktuell kritisches enthalten

 

Für mich passt es und ich brauche keine Absicherung durch ein Raid1.

Ich will aber nicht verschweigen, ich habe einen flotten Datenlagerungspool bestehend aus 3x8TB SATA SSD im raid5, weil ich dort Sachen lagere, welche wirklich verschoben wurden und ich mehr als nur 4 oder 8TB Nutzkapazität haben will. Somit sind die ca. 16TB Platz bei dieser Konstellation in Verbindung mit der Raid5 Parität an der Stelle für mich sinnvoll.

 

 

[Kabelgewirr]

8 minutes ago, DataCollector said:

Ich will aber nicht verschweigen, ich habe einen flotten Datenlagerungspool bestehend aus 3x8TB SATA SSD im raid5

Ein kleines aber nicht unbedeutendes Detail, in dem Fall würde ich das auch anders aufsetzen    

 

Danke für all den Input!

[DataCollector]

2 minutes ago, Kabelgewirr said:

Ein kleines aber nicht unbedeutendes Detail, in dem Fall würde ich das auch anders aufsetzen    

 

Damit es nicht falsch verstanden wird.

Ich habe in dem System (1st System Tessa, siehe Signatur) eine 4TB NVMe SSD für Datencache des Array, eine 2TB NVme SSD für Docker und VM  und dann eben noch einige zusätzliche Pools, welche komplett alleinstehend sind um dort eben Daten zu lagern. Einer der Pools ist eben das erwähnet Raid5 SSD Konstrukt.

 

In meinem anderen urnaidsystem (2nd System Shipon, siehe ebenfalls Signatur) sind es nur eine 4TB NVME SSD für Datencache des Array und eine alte 250GB NVme SSD für Docker/VM.