SSD-Cache - Erfahrungen und Fragen

  • Ab sofort steht euch hier im Forum die neue Add-on Verwaltung zur Verfügung – eine zentrale Plattform für alles rund um Erweiterungen und Add-ons für den DSM.

    Damit haben wir einen Ort, an dem Lösungen von Nutzern mit der Community geteilt werden können. Über die Team Funktion können Projekte auch gemeinsam gepflegt werden.

    Was die Add-on Verwaltung kann und wie es funktioniert findet Ihr hier

    Hier geht es zu den Add-ons

x4N70pHyLL

Benutzer
Registriert
17. Jan. 2018
Beiträge
41
Reaktionspunkte
6
Punkte
8
Hallo zusammen,

nachdem ich (mal wieder) die diversen Threads zum SSD-Cache durch habe, wollte ich hier auch meine Erfahrungen teilen und Eure Einschätzung zu meiner Situation bekommen.

Ich hatte mich trotz des allgemeinen Tenors hier für einen SSD-Cache entschieden, habe seit ca. 2 Jahren einen 2x500GB M2 Schreib-/Lesecache aktiv mit Crucial P3 SSDs.

Seit letzter Woche bekomme ich bei einer der SSD die EoL-Meldung (TBW überschritten), ich vermute die zweite baugleiche wird demnächst auch kommen. Mittlerweile sind auch dafür optimierte SSDs (WD RED) bezahlbar, die deutlich (!) höhere TBW-Werte haben, als meine aktuellen (ca. 110TBW vs. 500 bzw 1000TBW je nach Größe).

Während dieser 2 Jahre lief der Cache ohne Beanstandungen oder Auffälligkeiten. SSD-Cache-Trefferquote liegt dauerhaft bei 98-100%. So weit zum Erfahrungsbericht.

Daher stehe ich gerade vor der Entscheidung, den Cache zu erneuern oder ganz zu deaktivieren.

Noch einige Sätze zu meiner Situation:

Ich nutze vor allem Home Assistant als Container, dort eine vergleichsweise große/aufwändige Installation. Ansonsten ein paar Container und eine VM, jeweils nur Verwaltungszeug (AdBlocker, Unifi-Controller usw.).

Meine DS920+ hat 20GB RAM bekommen und eben den SDD-Cache. Ich hatte mir davon vor allem auch Entlastung der HDDs (3x8TB) versprochen, da speziell Home Assistant ja schon dauerhaft I/O hat. Ich überlege daher, ob die 20GB RAM alleine (davon sind ca 13GB "Zwischengespeichert" laut System Monitor) dafür ausreichen, dass I/O-intensive Dinge einfach im RAM gehalten werden und ich mir mit dem SSD-Cache nur sinnlos die SSDs totschreibe, oder ob ich damit eben außerhalb der NAS-Funktion alle Container/VM-Geschichten abfedern kann.

Ich hatte mich explizit gegen M2 als zusätzliches Volume entschieden, da es einen deutlich höheren Konfigurationsaufwand bedeutet (speziell für Container und VMs) und nicht offiziell unterstützt wird (zukünftig also potentiell mal nicht mehr funktioniert und ich es dann rückbauen müsste).

Ich bin auf Eure Einschätzungen gespannt!
 
Ich nutze seit über 3 Jahren 2 x 1 TB NVME SSDs als Speicherpool/Volume für Docker und VM. Bin absolut zufrieden und finde es wesentlich sinnvoller die Docker direkt auf dem Volume laufen zu lassen, als den Cache totzuschreiben.
 
Ich nutze das genau wie @ctrlaltdelete und fahre damit auch schon sehr lange gut.
 
die diversen Threads zum SSD-Cache durch habe
Eure Einschätzung zu meiner Situation bekommen.
Was hast du denn darauf geschlussfolgert? Im Regelfall setzen sehr viel, die auch die Applikationen nutzen, wie du sie hast, auf das NVME Volumen statt auf den Cache.

a) erfordert der Anwendungsfall keinen Cache
b) und die NVMEs halten länger
c) bringt es, auch wenn die "Trefferquote" stimmt, dir wirklich Vorteile???
d) wenn der Cache mal abstürzt, hast du wahrscheinlich dann auch Probleme mit dem Volume wegen Inkonsistenz


Aber natürlich bleibt die Entscheidung natürlich bei dir. 😉
 
  • Like
Reaktionen: ctrlaltdelete
Das sind schon die entscheidenden Punkte, über die ich mir auch Gedanken mache...

a) Leistungsmäßig erfordert es das nicht, das denke ich auch, da müsste schon viel I/O zusammenkommen
b) fair Point, habe ich aber keine Zahlen dazu (und auch keine gelesen bisher)
c) ich gehe davon aus, dass die Zugriffszeiten durch den btrfs-Metadaten-Cache schon besser sind (z.B. Suchen in Ordnern mit 500+ Dateien etc.), ist aber nicht mein Hauptanwendungsfall, nehme ich aber gerne mit
d) so wie ich die Doku verstehe, geht Schreib-/Lesecache nur in Kombi mit 2 SSDs (daher hatte ich das Setup auch so gewählt), die in einem RAID1 zusammengefasst werden

Vermutlich ist mein größtes Thema, dass ich relativ viel umziehen muss auf das neue Volume und das dann auch sehr tief im System. Und bei Updates ja immer unklar ist, ob das weiterhin so läuft oder nicht. Dafür hängt mir zu viel an der Funktion (HA steuert bei mir von Wärmepumpe über E-Auto laden und Rollläden ziemlich viel, so dass nicht-Verfügbarkeit in deutliche Einschränkungen / Mehraufwände resultiert)

Ist das bei Euch ebenfalls so?

Habt ihr Erfahrungswerte, wie stark sich die Synology aus dem RAM bedient, sofern ausreichend vorhanden ist? Im Prinzip sollten die relevanten Container inkl. Nutzdaten in den RAM passen.
 
Zuletzt bearbeitet von einem Moderator:
DSM ist leider nicht wie ZFS, welches den RAM noch besser nutzt. Die Docker Container nutzen den RAM direkt. Bei mir laufen alle Pakete und Docker auf dem NVME Volume, keine größeren Probleme bisher.
 
Das heißt das Setup wie in den Links deiner Signatur, SSDs einbauen, HDD_db-Skript bei jedem boot schedulen und mit dem App-Mover möglichst viele (vor allem Container Manager) Pakete auf die SSDs bewegen?

Ich habe noch folgende Fragen:
  • Habe keine Kompatibilitätsmatrix oder ähnliches gefunden, mein 920+ kann mit demHDD-db-Skript das Volume "ganz normal" erstellen im Speicher-Manager?
  • Ich mache dann typischerweise ein RAID1 mit 2 SSDs?
  • Muss ich mit den gemovten Paketen irgendwas beachten?
    • Beispiel: Ich möchte ja den Docker-Ordner mit den persistierten Files der Container auch auf dem neuen Volumen haben (aber die Images vermutlich nicht?)
    • Oder: Wie läuft das mit Versionierung und Hyper Backup? Ersteres habe ich für die persistierten Containerfiles aktives, letztes für nahezu alles (ich habe bisher immer nur mit einem Volume gearbeitet auf allen NAS)
    • ...?
 
Zuletzt bearbeitet von einem Moderator:
@x4N70pHyLL : Vielleicht mal, ist ja bald Black Friday und wenn auch noch Interesse da ist, was neues zu lernen, mit Proxmox beschäftigen. Da kannst du alle VMs und Docker auf Proxmox auslagern und die DS zum Datengrab degradieren. Bringt mehr und du brauchst kein Cache mehr. All das was du hast:

- Adguard
- Unifi Controller
- HA

und noch mehr (Windows 11 VM), Jellyfin, MariaDB, Kimai2 habe ich auf Proxmox laufen und es ist noch viel Luft nach oben. 😉
 
Zuletzt bearbeitet:
Ja, I know, ich habe einige Proxmox-Jünger in meiner Bubble :-D Hatte mich damals aus Gründen entschieden, die Synology aufzubohren und das Setup soll noch ein paar Jahre (gescheit) halten und dann wird's in die Richtung gehen.

Daher eben die Frage ob SSD Cache (oder dann Volume) oder "nur" HDDs und den Invest sparen.
 
Zuletzt bearbeitet von einem Moderator:
1. ja, mit dem HDD Script kannst du den Speicherpool und das Volume im Speichermanager erstellen
2. ja, RAID1 mit BTRFS
2. Pakete mit appmover problemlos
3. Zur Sicherheit würde ich für Docker alle Container exportieren mit Daten, geht im Container Manager, pro Container
Nach dem verschieben von Docker musst du in den Containern oder Stacks die Pfade auf das neue Volume anpassen!
Edit: Und verschiebe den Docker Ordner auch auf das Volume, weil da laufen die ganzen DBs drinnen, die profitieren ordentlich.
Edit2: Screenshot SMART Werte NVME SSDs. Laufen seit knapp 5 Jahren, mit hoher Dauerbelastung und sind erst bei 68% Nutzungsdauer angelangt. Da liefen teilweise bis zu 40 Container und sogar teilweise eine Kameraüberwachung drauf mit Aufzeichnung!
 

Anhänge

  • 1763123640857.png
    1763123640857.png
    182,3 KB · Aufrufe: 11
  • 1763123676506.png
    1763123676506.png
    118,7 KB · Aufrufe: 11
  • 1763123893101.png
    1763123893101.png
    28,4 KB · Aufrufe: 11
Zuletzt bearbeitet:
  • Like
Reaktionen: Benie
3. Zur Sicherheit würde ich für Docker alle Container exportieren mit Daten, geht im Container Manager, pro Container
Nach dem verschieben von Docker musst du in den Containern oder Stacks die Pfade auf das neue Volume anpassen!
Edit: Und verschiebe den Docker Ordner auch auf das Volume, weil da laufen die ganzen DBs drinnen, die profitieren ordentlich.
Vielen Dank für Deine Ausführungen!
Zusammen mit den verlinkten Anleitungen ergibt sich langsam ein Bild in meinem Kopf.

Nochmal zwei Fragen dazu

  • Das hört sich so an, als müsste ich schon jeden Container neu anlegen? "Pfade auf das neue Volume anpassen" -> das geht ja nur wenn ich mir den Container neu zusammenklicke, oder? Mit "Pfaden" meinst du konkret das mapping, wo jeder Container seine persistierten Daten ablegt, oder?
  • "Und verschiebe den Docker Ordner auf das neue Volume" -> Heißt, der Ordner /docker der bei Installation des Container Manager angelegt wird und auch auf oberster Ebene im File Manager sichtbar ist? Da sind (wenn ich mich recht erinnere) vermutlich die Images in einem versteckten Unterordner drin, außerdem habe ich da rein meine ganzen persistierten Daten gelegt (einen Unterordner pro Container). Wie mache ich das konkret? Ich bin davon ausgegangen, dass das als "Abhängigkeit" des Container Manager läuft und daher durch den Appmover mit verschoben wird? Wenn ich das von Hand mache fehlen mir ja vermutlich irgendwelche Referenzen?
Jetzt stellt sich für mich die Frage, ob ich das angehe oder alternativ den SSD Cache mit neuen SSDs anlege. Nach meiner Rechnung (110TBW in 2 Jahren vs. dann 500-1000TBW Nutzungsdauer) sollte mir das ja für 5+ Jahre locker reichen. Da Frage ich mich, welche Nachteile ich noch habe durch den Cache (außer den SSD-Fraß, den ich ja jetzt halbwegs gut ermitteln kann). Vorteil wäre bei gleichen Kosten die einfachere Einrichtung.

Aus Deinem Beitrag listest du ja diese Vorteile:
  1. Weiterer Speicherplatz --> nicht relevant in meinem Fall
  2. Die VMs und Docker laufen wesentlich flüssiger (SSDs haben eine wesentlich höhere IOPS als eine HDD), ich habe sogar eine Win10 (abgespeckte Version, alles auf Leistung getrimmt) benutzbar darauf laufen.
    Edit[20240313] mittlerweile umgestellt auf Win2022Server, der verbraucht viel weniger Ressourcen (CPU)
    --> Unterschied zu SSD Cache?
  3. Entlastung des HDD Speicherpool, weniger Lese- und Schreibvorgänge, somit mehr Leistung für andere Vorgänge. --> Unterschied zu SSD Cache?
  4. Thema Haltbarkeit, mein NVME-Volume läuft jetzt seit 2,7 Jahren und die SSDs weisen einen Verschleiß (Percentage_used) von 24% aus, dies würde bedeuten sie laufen ca. 11,25 Jahre, bis dahin werde ich sicher ein Upgrade auf größere NVME-SSDs vorgenommen haben. :cool: --> weniger relevant in meinem Fall
  5. Thema DSM Updates, mein Speicherpool hat bisher alle Updates überlebt, es kommt manchmal vor, dass der Speicherpool nach einem Update nicht verfügbar ist, dann einfach Script syno_hdd_db.sh nochmal laufen lassen und neu starten, fertig. --> nicht relevant in meinem Fall, hier sehe ich eher einen Vorteil, da offiziell unterstützt
  6. Thema Temperatur: Es wurden bisher hier im Forum keinerlei Temperaturprobleme berichtet, bei dauerhafter Kopierbelastung habe ich es mal auf 50° geschafft, kein Problem. --> vermutlich ebenfalls kein Unterschied

Habe ich was übersehen oder falsch verstanden?
 
Du musst den Pfad des Ordners docker in der Systemsteuerung unter freigebene Ordner machen.
Ja, du musst die Container neu erstellen. Wenn du das händisch in der UI gemacht hast, dann musst du das alles nochmal neu machen. Oder du stellst auf Docker-Compose um und nutzt evtl für die Verwaltung der Container in Zukunft Portainer. Aber anderes Thema.
Der SSD-Cache wird in vielen Fällen nicht genutzt, obwohl er da ist. Bzw. kann es sein, dass dort nicht immer die Daten liegen, die du brauchst (VM-Disk zum Beispiel oder Docker Images). Bei einem Volume auf den SSDs könntest du selbst entscheiden, was dort liegen soll und dann auch davon ausgehen, dass du dauerhaft die SSD-Performance hast. Der SSD-Cache will ja irgendwann auch zurückgeschrieben werden und macht dabei die HDDs deutlich langsamer.
Außerdem kann dir bei einem Fehler im SSD-Schreibcache das gesamte Volume inkl. HDD-Pool crashen
 
  • Like
Reaktionen: maxblank
@x4N70pHyLL wie hast du denn die Container angelegt und nein du musst nicht alle neu anlegen, dass ist nur als Backup gedacht.
 
  • Like
Reaktionen: maxblank
@x4N70pHyLL wie hast du denn die Container angelegt
Die meisten über die UI des Container Manager, ein paar speziellere wie Watchtower, Portainer oder Uptime Kuma, Die für ihre Arbeit Zugriff auf andere Container benötigen mittels Skript, dass sie entsprechende Rechte bekommen.

Ich muss sie nicht neu anlegen heißt, wenn ich mit dem Appmover Container Manager verschiebe, kommen die Container (also das was im Container Manager "drin" ist) mit, ich muss dann aber die zugewiesenen persistenten Pfade auf den manuell umzuziehenden "/docker..."-Ordner ändern in jedem Container?

Hier ein Beispiel - das würde ja nach meinem Verständnis schon heißen, jeden neu anlegen:
1763208250355.png
 
Über wie viele Container reden wir?
Und ich würde generell auf Docker Compose umstellen und Portainer nutzen.
Ich würde hiermit alle Container als Yaml exportieren, Achtung die Container müssen laufen:
https://github.com/007revad/Docker_Autocompose
Und dann mit Portainer neu deployen, dabei kannst du in der Yaml sofort die Pfade ändern, vorher die Docker Ordner umziehen und mit appmover den Container Manager verschieben.
Edit: Hast du gar keine Stacks?
 
Wir reden nicht von sehr vielen, vermutlich 10 Container.
Ich habe keine Stacks.
Das mit dem Autocompose ist ein super Tipp, das hätte mir vor einigen Wochen vermutlich 2 Stunden Arbeit gespart - werde ich bei Gelegenheit umstellen.
Ich schrecke tatsächlich vor dem Skript zurück, von dem ich ja dann funktionstechnisch abhängig bin, da es bei jedem Start laufen muss. Den Rest konntest du mir super erläutern und hat mich überzeugt, großes Dankeschön dafür.

Die anderen Vorteile verstehe, stehen aber für mich in meinem konkreten Fall nicht im Verhältnis zum Aufwand/Risiko-Nutzen. Daher wird es wohl der "normale" Cache werden.

Zwei Fragen eher aus Interesse habe ich noch:
  • @plang.pl hat erwähnt, dass bei Lese/Schreibcache-Crash das gesamte Volume crashen kann --> woran liegt das? Ich habe ja ein RAID1, sprich, wenn eine SSD crasht, schreibt die zweite noch zurück. Ich decke also den ersten Fehler ab, ebenso wie beim Volume selbst (in dem Fall RAID5, aber wäre ja bei RAID1 dasselbe)
  • Bei 100% Trefferquote des Caches (teilweise auch 89/99, aber quasi nie darunter) heißt das schon, dass alles was gelesen und geschrieben wird, über den Cache geht bzw. dort vorgehalten wird, oder? Dazu Detailfrage: Wir hatten es vom RAM, ich habe 20GB verbaut, kennt ihr die Logik? Also alles was geht im RAM halten (das ist ja schon mal nicht soo wenig) und danach alles im SSD-Cache und nur was in beides nicht passt geht direkt auf die Platten?

Nochmals Danke für Eure Hinweise, die Community hier ist wirklich super, da sieht es (leider) in anderen Foren anders aus.
 
https://www.synology-forum.de/threads/probleme-mit-dem-speicherpool.132677/post-1155181

https://www.synology-forum.de/threads/status-volume-1-abnormal-nach-cache-absturz.120373/

Einfach mal ein bisschen quer lesen. Ich glaube, man kann gar nicht richtig festlegen oder sehen, wann die Synology die Daten vom Cache auf die Platten schiebt. Also bleibt der Cache, für mich jedenfalls, genauso ein Risiko wie das Script selbst. Marketing ≠ Realität.

Welches Risiko du bei welchem Nutzen eingehst, kannst natürlich nur du einschätzen. Viele haben hier schon ihre Erfahrungen mit dem SSD Cache gemacht und einige davon diese auch hier geteilt. Alles weitere liegt natürlich bei dir. 😉
 
Ich habe seit über 4 Jahren einen SSD-Cache im RAID1 in einer RS820RP+ und dort gehen stündlich 20-30 GB an Backup-Daten drüber. Am Tag sind es über 1 TB mit den abendlichen Backups und es gab bisher keinerlei Probleme. Ich würde allerdings NVMEs mit Powerloss-Protection und eine USV empfehlen. Auch rate ich dringend von Consumer-NVMEs als Cache ab, sonder rate zu Enterprise NVMEs.

1763471150906.png

1763471599846.png

1763471192825.png
 
Zuletzt bearbeitet:
  • Like
Reaktionen: ctrlaltdelete
Welches SSD Model?
 
Bei mir sollen es die WD Red werden, Powerloss hab ich da jetzt nicht gesehen. Das NAS hängt bei mir an der Hausbatterie und damit im Prinzip an einer "großen USV".
Wie Eingangs geschrieben habe ich in knapp 2 Jahren die 110TBW meiner aktuellen Consumer SSDs "verbraucht", damit sollte ich mit den 1000TBW der WD Red ja gut hinkommen.
 

Additional post fields

 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat