Performance Problem mit SSDs im RAID 5

Es handelt sich um einen Server, der hier mal die eierlegende
Wollmilchsau abgeben soll. Mit integriertem virtuellem DC, virtuellem
Fileserer, einigen RDS-Servern, einem MySQL-Server etc....

Betriebssystem: Windows 2012R2 Datacenter als Hyper-V-Server
RAM: 128 GB
Mainboard: Supermicro X10DRi-LN4+
Gehäuse: Supermicro SC213A-R740LPB
CPU: 2 x XEON E5-2640v3
RAID-Controller:
Zuerst Adaptec 71605 ungepuffert
Aktuell Adaptec 81605Z gepuffert
SSDs:
Raid 5 mit 9 x Samsung 850 Pro 1TB
Raid 1 mit 2 x Samsung 850 Pro 256GB

Ich weiß, ich weiß,.... Consumer-SSD's. Geld spielt eben immer eine Rolle.

Aufgesetzt habe ich den vor ca. 1 1/2 Jahren. Der lief seit mindestens
einem Jahr mit DC und einigen 2012er RDS- und 2003er Terminalservern
im Echtbetrieb. Zuletzt ging auch der Fileserver in Betrieb. Spürbare
Performance-Probleme gab es nie.

Abgesichert war der Server mit zwei parallelen USV's. Eine pro Netzteil.

Stromausfälle gab es schon. Da gab es nie ein Problem. Nun trat der
unwahrscheinliche Fall der Fälle ein. Ein sehr langer Stromausfall, den
die USV's nicht mehr überbrücken konnten. Um die Server zu schützen
fing ich nach einigen Minuten ohne Strom an, (auch) den Server
herunterzufahren. Er schaffte es aber nicht mehr, bevor die USV
abgeschaltet hat. Da hätte ich ihn wahrscheinlich besser völlig
ohne Last (aus)laufen lassen. Hätte, hätte,....

Seitdem habe ich das Drama hier. Das hat sich zunächst darin geäußert,
daß nach dem Reboot des Servers mehrere virtuelle Server nicht mehr
gebootet haben. Im Protokoll des Hyper-V-Servers fanden sich im
Sekundentakt "disk"-Fehler. Die VM's, die liefen, brachten ebenfalls
E/A-Fehler. Chkdsk sowohl auf den VM's als auch dem Hyper-V brachte
reichlich Fehler, die er angeblich korrigiert habe. Das hat nur nichts geholfen.
Die VM's waren hinüber. Ziemlich schlecht, aber noch keine Katastrophe.
Daten hatten wir ja keine verloren. Zudem haben wir zwei aktive Virtualisierungsserver.
Der andere (XEN mit HDDs) hat bei der Aktion nichts abbekommen.

Es ging jedoch weiter. Über das Wochenende hatte sich eine SSD aus dem
RAID 5 verabschiedet, das RAID 5 war degraded. Allerdings haben die
SSDs laut S.M.A.R.T. noch 99% der TBW. Also habe ich die angebliche fehlerhafte
SSD gezogen und wieder gesteckt. Das RAID hat anstandslos auf der angeblich
defekten SSD das Rebuild vollzogen. An den Fehlermeldungen in Windows
hat das leider nicht geändert. Hinzugekommen ist jedoch noch ein immer
wiederkehrender Eintrag im Protokoll des Controllers für das RAID5: "Bad Stripe".
Na danke. Sämtliche VMS bringen bei Chkdsk Fehler, die offensichtlich nicht
korrigiert werden können. Das war's dann für das RAID. Zurück auf Los. Sicherungen
der einzelnen Server hatte ich nicht. Nur von den Daten. Noch ein böser Fehler,
der mir nicht mehr passieren wird.

Also mache ich das RAID 5 platt und fange von vorne an. Das RAID 5 ist schnell
neu aufgesetzt. Es wird ein kompletter Verify gemacht. Die Platten und das RAID
sollten demnach wohl fehlerfrei sein. Das lief allerdings einige Stunden. Für meinen
Geschmack für ein RAID aus SSD's viel zu lange.

Dann habe ich Windows wieder neu installiert und erstmal mit sämtlichen Updates
versehen. Wenn schon, denn schon: Der RAID-Controller bekam die neueste Firmware,
die Windows-Treiber wurden ebenfalls auf den neuesten Stand gebracht. Für meine
Begriffe optimale Voraussetzungen für eine ordentliche Performance. Denkste!

Habe ein paar einfache Kopierversuche mit ein paar GB an großen Dateien innerhalb des
RAID 5 gemacht und bin fast vom Stuhl gefallen. Die ersten ein oder zwei Sekunden
gingen noch zügig, dann brach die Leistung massivst ein. Die Schreibrate ging runter
bis nahezu auf 0 und schwankte dann zwischen max. ca. 100MB/s und einem
einstelligen Wert hin und her.

Da beim Build mit Verify (!) des neuen Arrays keine Fehler angezeigt wurden, konnte
ich mir einen Defekt an den SSDs einfach nicht vorstellen. Der nächste Verdächtige
war daher der Controller. Den habe ich dann gegen den obenstehenden, nagelneuen
Controller getauscht, natürlich einschließlich den dazu passenden, neuesten Treibern.

Wohlbemerkt: Bei beiden Controllern ist Write-Cache disabled!

Das grausige Ergebnis trotz des neuen Controllers seht ihr hier. Das ist ein neu
aufgesetztes RAID5 aus 9 identischen Samsung 850Pro SSDs!!!

Der Server friert während dieser Messung oder bei o.g. Kopieraktion förmlich ein.
Es ist kaum mehr möglich, z.B. auch nur das Eregnisprotokoll zu starten. Auch wenn
ich vom allten Zustand leider keine solche Messungen habe, war DAS vorher ganz
sicher nie so. Alle VMs darauf liefen problemlos und ohne jeden Hänger. Selbst mit
parallel aktivem Fileserver auf der gleichen Hardware.

Die beiden separaten kleineren Platten im RAID1 sind auch ganz weit weg von "normal".
Auch das Ergebnis sehr ihr hier:

Und nun stehe ich richtig auf dem Schlauch. Mir ist bewußt, daß RAID 5 immer ein
Kompromiss aus Kosten und insbesondere Schreibleistung darstellt. Aber sowas???

Mittlerweile habe ich so einiges gegoogelt zum Thema Stomausfall und SSDs. Das
kann demnach tatsächlich zu einer breiten Spanne von Defekten bis hin zum
Totalausfall der SSD führen. Das wußte ich vorher nicht. Da so ein Vorfall nicht
vorgesehen war, verfügte auch weder der RAID-Controller über eine Pufferbatterie
/-kondensator noch waren die SSDs "power-loss-proteced".

Mangels besserer Ideen habe ich nach dem Tausch des Controllers gegen eine
mit Puffer nun auch noch einen Satz von 5 x Samsung PM863 (Enterprise-Ware,
power-loss-protected) bestellt, die die 9 x 1TB's ersetzen sollen. Allerdings bin ich
alles andere als sicher, daß das die Lösung des Problems ist. Falls doch, würde
das wohl bedeuten, daß die "alten" SSDs tatsächlich was abbekommen haben.

Zum Vergleich habe ich hier noch die gleiche Messung von meinem Laptop dran
gehängt. Da werkelt eine Samsung 850 EVO mit 1TB drin:


Sorry, war ein langer Vortrag. Aber ich denke, so sind viele Rückfragen schonmal im
Voraus geklärt.

Hat hier jemand hilfreiche Ideen dazu?
Oder auch Messwerte aus einer ähnlichen Konfiguration?

Bin für jede Hilfe dankbar!