SSD Performance im Array

[mgutt]

Da mich das Thema interessierte, habe ich ein paar SSDs genommen und ein paar Benchmarks im Array gemacht.

 

Das verwendete Script, das ich für jede Disk ausgeführt habe:

#!/bin/bash

for n in {1..380}; do
  head -c 10000000000 /dev/zero | openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt  > /mnt/disk1/file$( printf %03d "$n" ).bin
done

 

Im ersten Test habe ich auf allen SSDs gleichzeitig geschrieben, was im Alltag eher unrealistisch sein dürfte, aber zeigt wie wichtig die Performance der Parität ist:

 

Danach habe ich alles gelöscht und den Test wiederholt. Hier kommt nun der Nachteil zum Tragen, dass Unraid keinen TRIM im Array ausführt und dass man die Parität auch gar nicht trimmen kann (da die Parität zu 100% mit RAW Daten und keinen Dateien beschrieben wird):

Die Parität bremst nun also das komplette Array. Diesen negativen Effekt hat man bei sehr guten SSDs, wie zB aus dem Enterprise Bereich, weniger, da diese einen (großen) Over-Provisioning Bereich besitzen, der für den Nutzer nicht sichtbar ist und auf dem beim Durchlauf der Garbage Collection Daten zwischengespeichert und aufgeräumt wird. Wartet man diese Garbage Collection ab (der SSD Controller macht dies automatisch in Leerlaufphasen, lässt sich nicht manuell anstoßen), dann werden die SSDs tatsächlich wieder schneller:

 

 

Gar keinen Leitungseinbruch gibt es erwartungsgemäß beim Lesen von einer SSD mit dem folgenden Kommando:

dd if=/mnt/disk1/file001.bin of=/dev/null bs=128k iflag=count_bytes count=10G

 

Dann habe ich aber auch mal nur auf eine SSD geschrieben, so dass nicht parallel mehrere Paritäten berechnet werden, sondern nur eine, aber trotzdem limitiert hier das parallele Lesen und Schreiben:

 

Hier wären NVMes natürlich viel schneller. Es gibt Modelle, die fast 2000 MB/s beim parallelen Lesen und Schreiben erreichen:

https://www.computerbase.de/2021-04/wd-black-sn850-blue-sn550-test/2/#:~:text=Kopieren auf der SSD

 

Allerdings kann man paralleles Lesen und Schreiben, solange man nur auf eine SSD im Array schreibt, vermeiden, in dem man in den Disk Settings "Reconstruct Write" aktiviert, was man bei SSDs auch machen sollte, da diese im Gegensatz zu HDDs im Millisekundenbereich in den Standby wechseln. Die Performance ist nun deutlich besser, da die Parität jetzt nur noch beschrieben wird:

 

Sie kann aber noch besser sein, wenn man keine langsame SSD im Array hat, denn das schwächste Glied im Array bestimmt bei Reconstruct Write die Performance:

 

 

Da ein TRIM die Parität zerstören kann, ist der TRIM bei Array-Disks übrigens deaktiviert:

root@Tower:~# /sbin/fstrim -v /mnt/disk1
fstrim: /mnt/disk1: the discard operation is not supported
root@Tower:~# /sbin/fstrim -v /mnt/disk2
fstrim: /mnt/disk2: the discard operation is not supported

 

 

In meinen Fall wäre es zB sehr schlecht TRIM auszuführen, denn meine SSDs würde nach einem TRIM alle Sektoren mit Nullen beschreiben, so dass die Parität, die sich ja aus den Sektoren aller beteiligten Disks ergibt, direkt kaputt gehen würde:

hdparm -I /dev/sde | grep TRIM
           *    Data Set Management TRIM supported (limit 8 blocks)
           *    Deterministic read ZEROs after TRIM

 

"Deterministic read ZEROs after TRIM" nennt man RZAT. Man bräuchte stattdessen DRAT "Deterministic read data after TRIM". Dann würde die SSD nach dem TRIM weiterhin die selben Daten zurückgeben und die Parität bliebe valide.

 

Wobei man natürlich auch überlegen könnte, dass man nach einem RZAT TRIM einen Paritätscheck mit Reparatur ausführt, aber in den Stunden ist dann natürlich die Gefahr gegeben, dass man keine Ausfallsicherheit hat.

 

Aktuell versuche ich herauszufinden, wie man trotzdem einen TRIM ausführt (ohne jetzt das Array stoppen zu müssen und manuell zu mounten). Ich reiche dann auch davon einen Screenshot nach. Auch würde ich dann gerne testen was passiert, wenn man die Sektoren von gelöschten Dateien vorher mit Nullen beschreibt. Dann müsste ja theoretisch die Parität ganz bleiben. Vielleicht hat da jemand einen Tipp für mich.

[mgutt]

Und damit man das auch mal gesehen hat: Schreiben einer Datei auf einen SSD RAID5 Pool:

 

Schreiben von drei Dateien parallel:

 

Und Lesen von einer Datei:

 

In Sachen Performance ist ein klassisches RAID erwartungsgemäß schneller als das Unraid Array.

[doesntaffect]

Werden SSDs als Array disk offiziell unterstützt? Ich hatte mal gelesen, dass dies nicht so ist. Hat sich daran mittlerweile geändert? 

[mgutt]

35 minutes ago, doesntaffect said:

Werden SSDs als Array disk offiziell unterstützt?

Nein und daran wird sich erstmal auch nichts ändern, da denke ich eine Testprozedur entwickelt werden muss, die eine ungeeignete SSD erkennt. Bis dahin muss man es selbst ausprobieren. Also Array mit Parity, Dateien löschen, Garbage Collection abwarten und einen Parity Check machen. Wenn keine Fehler auftreten, ist die SSD geeignet.

 

Wenn man auf Nummer sicher gehen will, nimmt man Enterprise SSDs wie Samsung SM883 oder PM897. Gegen "normale" Samsung spricht aber meiner Ansicht nach auch nichts.

[RiDDiX]

Ich würde auch SSDs nicht als Parity verwenden, klar wäre das wesentlich schneller, aber die Belastung (Lese- / Schreib-Zyklen) wären ja enorm. Auch gibt es für mich keine bezahlbaren 16-20TB SSDs.

Ich hab zum Beispiel in einem dritt Server mal Unraid als Testversion laufen gehabt mit Standard Samsung Pro 850 Sata SSD 2TB als Array 2x und Parity 2x WD Blue 4TB. Das lief schön schnell. Dennoch liebe ich bei Unraid einfach die Cache-Option und mit den bei dir im Test verwendeten SanDisk 4TB SSDs, welche ich ebenfalls besitze habe ich keinen Schmerz was die Datenübertragung angeht. 10GB Netzwerk ist aktuell im Aufbau nur relativ Kosten- und Zeit-Intensiv, bevor das nicht abgeschlossen ist habe ich kaum Vorteile gegenüber normalen HDDs, da selbst bei 1GB max 110MB/s erreicht werden beim übertragen auf die Array HDDs direkt. Einzig mein HauptPC ist direkt per 10GB an den Server per 10GB verbunden, da merkt man den Cache schon mit bis zu 800MB/s

Mich würde es ja interessieren ob z.B. die NVMe WD Blues so viel "schlechter" sind als deren RED SSDs für NAS-Systeme. Dazu habe ich noch kaum bis fast keine erschlussreichen Vergleich gefunden..

[saber1]

1 hour ago, RiDDiX said:

Mich würde es ja interessieren ob z.B. die NVMe WD Blues so viel "schlechter" sind als deren RED SSDs für NAS-Systeme. Dazu habe ich noch kaum bis fast keine erschlussreichen Vergleich gefunden..

Ich habe ne Blue NVMe seit Ende 2020 im Einsatz und kann nichts negatives Berichten. Wobei ich sie lediglich als Disk für VMs nutze.

[RiDDiX]

1 hour ago, saber1 said:

Ich habe ne Blue NVMe seit Ende 2020 im Einsatz und kann nichts negatives Berichten. Wobei ich sie lediglich als Disk für VMs nutze.

 

Mich interessiert das eigentlich noch / hauptsächlich im Bereich Cache. Da ich mein Unraid oft extrem missbrauche was Read-Write-Performance angeht. Ich werde aber bald mir eine andere SSD besorgen. Es gibt im Enterprise-Bereich einige 4-8TB NVMe SSDs mit beachtlichen Lesen und Schreibwerten.

[Revan335]

Haben die Blues auch ne TBW/Gesamtschreibleistung im PB Bereich? Das war ein Punkt der für die WD RED SN700 statt den Samsung EVO Plus sprach. Die hatten nur TB statt PB gehabt.

[mgutt]

7 hours ago, Revan335 said:

Die hatten nur TB statt PB gehabt.

Wie willst du diese Schreibleistung erreichen? Wie rechtfertigt das den Aufpreis? Selbst wenn die Blue kaputt geht, kaufst du dir mach X Jahren einfach eine neue. Kommst du immernoch auf den selben Preis. Geht sie nicht kaputt, hast du massig Geld gespart.

[Revan335]

Dachte das dies beim Cache im Laufe der Zeit möglich sein könnte.

[mgutt]

4 minutes ago, Revan335 said:

Dachte das dies beim Cache im Laufe der Zeit möglich sein könnte.

Ich habe meine jetzt knapp 6 Monate verbaut und immer noch keine 10TB geknackt. Nur wenn man sie als Parität im Array nutzt könnte man darauf achten, aber selbst dann würde ich immer über den Preis nachdenken. Die Garantie wird dadurch ja nicht länger.

[h0schi]

Interessanter Post - dank dir für die ganzen Details @mgutt 👍

 

Mich würds mal interessieren wie sich das ganze Array aus Consumer-SSDs im Ernstfall wie einem "harter" Systemabsturz (Stromausfall, Netzteil-Defekt, usw.) verhält.

Selbst eine USV, kann mir in so einen Fall das evtl. entstehende Problem nicht wegpuffern.

Denke gerade in so einem Fall würden sich halt gerade Enterprise-/Consumer SSDs mit Power-Loss Protection besser eignen.

 

[jj1987]

16 minutes ago, h0schi said:

Selbst eine USV, kann mir in so einen Fall das evtl. entstehende Problem nicht wegpuffern.

Na wenn die das nicht schafft, was soll denn dann

 

17 minutes ago, h0schi said:

Enterprise-/Consumer SSDs mit Power-Loss Protection besser eignen.

helfen?

Die Kondensatoren dafür dürften deutlich kleiner dimensioniert sein. Einzig die PLP-optimierte Firmware mag einen Hauch mehr Sicherheit bringen.

Aber ne USV sollte ja idR wenigstens 20 Minuten durchhalten. Gepaart mit NUT sollte man da eigentlich einen sicheren shutdown hinbekommen?!

[h0schi]

Ich spreche nicht von einem regulären Stromausfall, welche eine USV wegpuffern kann, sondern von einem Netzteil-Defekt oder hartem Systemausfall auf Software-Ebene.

[jj1987]

OK, ja Netzteil Fehler ist natürlich eine Sache wo die USV nicht hilft. Sorry das Beispiel hatte ich wohl überlesen.

Hatte ich jetzt aber in all den Jahren nur einmal und das war direkt beim einschalten.

Und Stromausfall kommt bei mir auch äußerst selten vor (zumindest ausgehend von der Notwendigkeit Radiowecker etc neu stellen zu müssen). Das scheint aber in manchen Gegenden in Deutschland anders auszusehen?!

[h0schi]

Kein Thema

Von Stromausfällen in unserer Region sind wir eigentlich soweit auch verschont und wenn puffert es die USV gut weg.

 

Hatte bis jetzt einmal das Szenario, dass ich bei der Erst-Einrichtung einmal den Server hart neu starten musste und sich das Datei-System auf meinen damaligen Cache-SSDs (RAID-1) komplett zerpflückt hat - ob es jetzt mein eigener Fehler oder ggf. ein Software-Fehler handelte, kann ich schlecht sagen.

Setz seit dem nur SSDs mit Power-Loss Protection als Cache-Drives ein und schlaf einfach besser mit dem Gedanken etwas mehr "Sicherheit" zu haben 😄

 

 

[mgutt]

Wegen einem Absturz meines Testservers wurde nun ein Parity Check angestoßen. Sind leider "nur" 320 MB/s lesend:

 

 

Das wundert mich, weil die QVO sollte rein lesend eigentlich 550 MB/s schaffen und der Chipsatz, wo die ganzen SSDs dran angeschlossen sind, ist ja mit DMI 3.0, also mit 3.93 GB/s angebunden. Daran sollte es also auch nicht scheitern. Ich denke ich werde da die Tage noch mal einzeln testen. Vielleicht bremst hier ja die Parity, weil es eine RAW Partition ist?!

 

 

[JorgeB]

1 hour ago, mgutt said:

Das wundert mich, weil die QVO sollte rein lesend eigentlich 550 MB/s schaffen und der Chipsatz, wo die ganzen SSDs dran angeschlossen sind, ist ja mit DMI 3.0, also mit 3.93 GB/s angebunden.

 

Is this an Intel chipset? I found that the Intel SATA controller is limited to roughly 2GB/s, at least up to the 11th gen, didn't test with Alder Lake yet.

[mgutt]

51 minutes ago, JorgeB said:

Is this an Intel chipset? I found that the Intel SATA controller is limited to roughly 2GB/s

Yes (10th gen W480 chipset) and sad to hear that. This means using all 8 ports will limit it to 250 MB/s per disk. Funnily I'm facing the same problem with my production server (8th/9th gen C246 chipset) and never realized it (because those disk have a maximum of 270 MB/s and reach only 245 MB/s) 😅

 

 

[mgutt]

Ok, here is the "proof". After the 4TB SSD has finished the check, the rest of the SSDs accelerated to 380 MB/s (to reach the maximum of ~ 2GB/s)

 

 

[bastl]

Servus zusammen,

 

ich pack mal meine Frage hier rein, vielleicht kann mir jemand den ein oder anderen Tipp geben. Folgendes habe ich vor. Auf meinem Hauptsystem mit Unraid laufen diverse Dienste wie Nextcloud, Unifi, Bitwarden etc. Da ich den Threadripper auf die Dauer nicht ständig laufen haben will, kam mir die Idee, ich könnt die meisten Dienste ja auf einen low-power MiniPC auslagern. Dort sollte dann ebenfalls Unraid drauf, da mir die Verwaltung über die GUI recht gut zusagt.

 

Nun das Problem. Der MiniPC hat eine 500GB NVME und 2x1TB SSD. Weitere Festplatten passen nicht rein bzw. sind alle Anschlüsse belegt, außer natürlich USB Geräte. Jetzt stellt sich mir die Frage, Docker+VMs laufen nur mit gestartetem Array. In das Array sollte man allerdings keine SSDs packen, da TRIM nicht unterstützt wird bzw. die Parität dadurch geschrottet werden kann. Ich würde bei der Kiste auch ohne Array Disks auskommen, das scheint allerdings nicht zu funktionieren. Besteht die Möglichkeit einen einfachen USB Stick (quasi als Dummy) als einziges Array Device zu nutzen, damit das Array überhaupt gestartet wird? Die NVME würde ich für 1-2 VMs nutzen und die 2x1TB als gespiegelten Pool für die Services und paar Daten die anfallen. Shares nur auf den Pools und absolut nix auf dem Array, geht das? Oder macht es Sinn die NVME als Array zu nehmen? Dann dürfte doch Trim nutzbar sein ohne Parität, oder?

 

Gibt es etwas, was ich dabei übersehe? Irgendwelche Tipps?

[mgutt]

32 minutes ago, bastl said:

Möglichkeit einen einfachen USB Stick (quasi als Dummy) als einziges Array Device zu nutzen, damit das Array überhaupt gestartet wird?

Ja

 

Wegen TRIM: Ist grundsätzlich im Array deaktiviert. Denke mal auch ohne Parität.

 

 

[bastl]

On 6/21/2022 at 3:50 PM, mgutt said:

Ja

Perfekt. Gerade getestet mit nem alten Stick. Funzt! Nen neuer Stick fürs OS ist bestellt. Am Wochenende wird dann umgestellt. 👍

 

[fired]

On 11/11/2021 at 11:13 PM, mgutt said:

Nein und daran wird sich erstmal auch nichts ändern, da denke ich eine Testprozedur entwickelt werden muss, die eine ungeeignete SSD erkennt. Bis dahin muss man es selbst ausprobieren. Also Array mit Parity, Dateien löschen, Garbage Collection abwarten und einen Parity Check machen. Wenn keine Fehler auftreten, ist die SSD geeignet.

 

Gibt es denn irgendwo eine inoffizielle Liste mit SSDs im Array die bei Usern problemlos liefen?

Ich habe hauptsächlich WD Blue 1 / 2 TB als Sata und NVME verfügbar und will beim Server Umzug auf SSD only array umsteigen.

[DataCollector]

44 minutes ago, fired said:

Gibt es denn irgendwo eine inoffizielle Liste mit SSDs im Array die bei Usern problemlos liefen?

Ich habe hauptsächlich WD Blue 1 / 2 TB als Sata und NVME verfügbar und will beim Server Umzug auf SSD only array umsteigen.

 

Mir ist keine solche Liste bekannt.

Da es auch von der jeweiligen Firmware mit abhängt wäre eine reine Typenliste wenig hilfreich.

Entweder Ausprobieren oder eben SSD nicht im Array nutzen.

 

Beachte, daß Probleme, die beim internen Umsortieren, durch den SSD eigenen Kontroller, entstehen können schnell auffallen,

Performanceeinbußen aber erst nach einiger Nutzungszeit/intensität auftauchen (Wochen, Monate...).

 

mgutt hatte mal etwas von einem auf Samsung 860 oder 870 QVO 8TB (SATA) basierenden Array gezeigt.