13
Software-RAID zu leistungsschwach? Windows Ereignis-ID 153
Ich betreue eine Kanzlei mit zwei Mitarbeitern. Dort habe ich nun den alten Server ersetzt. Der neue basiert auf einem Supermicro H13SAE-MF Mainboard mit EPYC 4344P und 32GB ECC-RAM. Das MB beherrscht m.2-NVMe- und SATA-RAID. Installiert ist ein Windows Server 2022 Standard (mit Essentials-Key aktiviert). Lediglich die Dateiserver-Rolle und Advoware (mit Gupta-SQL) laufen darauf. Alle Treiber & Programme sind auf dem aktuellen Stand. BIOS ebenso.
1. Das Systemlaufwerk (c:\) befindet sich auf dem m.2-NVMe-RAID 1. Darauf läuft die Datenbank.
2. Das Datenlaufwerk (d:\) befindet sich auf einem SATA-SSD-RAID 1. Dort liegen neben den Daten auch die Advoware-Programmdateien.
3. Das Backuplaufwerk (e:\) ist als Einzellaufwerk (3,5 Zoll SATA-HDD) für die interne Sicherung eingebunden. Die Sicherung von c:\ und d:\ erfolgt nach Mitternacht.
Installation des BS und Übertragung der Daten verliefen ohne Auffälligkeiten, ebenso die Aktivierung von Bitlocker auf c:\. Stutzig wurde ich, als die Bitlocker-Vorgänge auf d:\ und e:\ immer wieder stockten.
In der Ereignisanzeige fand ich dann auch sehr schnell die disk-Warnungen mit der ID 153 (Der E/A-Vorgang an der logischen Blockadresse … für den Datenträger … wurde wiederholt). Die Warnung betrifft alle Laufwerke; am häufigsten aber das Datenlaufwerk. Ein Neuaufsetzen des SATA-SSD-RAID 1 brachte jedoch keine Besserung.
Während der Arbeitszeit tritt diese Warnung zwischen 4 und 20x pro Stunde auf; während der 1,5 stündigen Sicherung etwas über 100x. Das Systemlaufwerk wird immer erfolgreich gesichert, das Datenlaufwerk nur in 1 von 4 Fällen.
Die Dateisysteme sind alle fehlerfrei; die RAIDs beide konsistent & die SMART-Werte von jedem Datenträger einwandfrei.
Ich frage mich jetzt natürlich, ob ich die Leistungsfähigkeit eines Software-RAIDs falsch eingeschätzt habe. Bei lediglich zwei Benutzern ging ich davon aus, auch ohne Hardware-RAID auszukommen. Oder könnte theoretisch auch die Backplane des Gehäuses (ein Inter-Tech 2U-2404L) für diese Probleme verantwortlich sein?
1. Das Systemlaufwerk (c:\) befindet sich auf dem m.2-NVMe-RAID 1. Darauf läuft die Datenbank.
2. Das Datenlaufwerk (d:\) befindet sich auf einem SATA-SSD-RAID 1. Dort liegen neben den Daten auch die Advoware-Programmdateien.
3. Das Backuplaufwerk (e:\) ist als Einzellaufwerk (3,5 Zoll SATA-HDD) für die interne Sicherung eingebunden. Die Sicherung von c:\ und d:\ erfolgt nach Mitternacht.
Installation des BS und Übertragung der Daten verliefen ohne Auffälligkeiten, ebenso die Aktivierung von Bitlocker auf c:\. Stutzig wurde ich, als die Bitlocker-Vorgänge auf d:\ und e:\ immer wieder stockten.
In der Ereignisanzeige fand ich dann auch sehr schnell die disk-Warnungen mit der ID 153 (Der E/A-Vorgang an der logischen Blockadresse … für den Datenträger … wurde wiederholt). Die Warnung betrifft alle Laufwerke; am häufigsten aber das Datenlaufwerk. Ein Neuaufsetzen des SATA-SSD-RAID 1 brachte jedoch keine Besserung.
Während der Arbeitszeit tritt diese Warnung zwischen 4 und 20x pro Stunde auf; während der 1,5 stündigen Sicherung etwas über 100x. Das Systemlaufwerk wird immer erfolgreich gesichert, das Datenlaufwerk nur in 1 von 4 Fällen.
Die Dateisysteme sind alle fehlerfrei; die RAIDs beide konsistent & die SMART-Werte von jedem Datenträger einwandfrei.
Ich frage mich jetzt natürlich, ob ich die Leistungsfähigkeit eines Software-RAIDs falsch eingeschätzt habe. Bei lediglich zwei Benutzern ging ich davon aus, auch ohne Hardware-RAID auszukommen. Oder könnte theoretisch auch die Backplane des Gehäuses (ein Inter-Tech 2U-2404L) für diese Probleme verantwortlich sein?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-ID: 667950
Url: https://administrator.de/contentid/667950
Printed on: September 8, 2024 at 06:09 o'clock
13 Comments
Latest comment
Moin,
das fühlt sich für mich eher nach einem Mainboard, SSD oder Kabel-Fehler an.
Bei der CPU mit SATA SSD sollte das Software RAID ausreichend schnell sein. Unabhängig von der Last.
Und auch bei Überlast der Anbindung sollte kein 153 Fehler erscheinen.
Ich würde zuerst die Kabel mal tauschen. Einfach weil es einfahc ist.
Wenn das nicht hilft mal, vorher backup machen, jeweils nur mit einer der beiden SSD das System laufen lassen. Ja SMART zeigt viele Fehler an, aber Übertragungsfehler gehören nicht immer zum Bereich von SMART.
Unabhängig von Deinem Problem, Du schreibst nichts zu den Kapazitäten wäre mein Vorschlag nur 1x Enterprise NVME SSD (2/4/8.../32) zu verwenden. Kein RAID.
Und Bitlocker auf dem Server kann man machen. Ich würde es nicht machen. Dazu gibt es aber lange Diskussionen hier und sollte nicht zu Deinem Problem führen.
Stefan
das fühlt sich für mich eher nach einem Mainboard, SSD oder Kabel-Fehler an.
Bei der CPU mit SATA SSD sollte das Software RAID ausreichend schnell sein. Unabhängig von der Last.
Und auch bei Überlast der Anbindung sollte kein 153 Fehler erscheinen.
Ich würde zuerst die Kabel mal tauschen. Einfach weil es einfahc ist.
Wenn das nicht hilft mal, vorher backup machen, jeweils nur mit einer der beiden SSD das System laufen lassen. Ja SMART zeigt viele Fehler an, aber Übertragungsfehler gehören nicht immer zum Bereich von SMART.
Unabhängig von Deinem Problem, Du schreibst nichts zu den Kapazitäten wäre mein Vorschlag nur 1x Enterprise NVME SSD (2/4/8.../32) zu verwenden. Kein RAID.
Und Bitlocker auf dem Server kann man machen. Ich würde es nicht machen. Dazu gibt es aber lange Diskussionen hier und sollte nicht zu Deinem Problem führen.
Stefan
Moin,
Moine Kristallkugel tippt auf full-encryption statt used space bei Bitlocker. Wenn das RAID/die SSD komplett verschlüsselt wird, Dann hat die TRIM-Funktion keine wirkung mehr, weil technischt gesehen die SSD "vollgeschrieben" ist und daher bei jedem neuen Schreibvorgang erstmal die Zellen gelöscht werden müssen und dann frisch beschrieben, statt wie bei getrimmten SSDs und daher deutlich langsamer. Daher testweise mal Bitlocker ausschalten udn schauen, ob das Verhalten sich nach einem Trim verbessert. Wenn ja, dann Bitlocke auf used-Space umstellen. ansonsten weiter nach fehler suchen.
lks
PS: Falls Du Consumer-SSDs statt Enterprise-SSD (egal ob SATA oder NVME) verwendet hast, könnte das der andere mögliche Grund sein. Die haben nämlich i.d.R. einen deutlich kleiner Schreibcache und auch weniger Overprovisioning. Das bremst auch.
Moine Kristallkugel tippt auf full-encryption statt used space bei Bitlocker. Wenn das RAID/die SSD komplett verschlüsselt wird, Dann hat die TRIM-Funktion keine wirkung mehr, weil technischt gesehen die SSD "vollgeschrieben" ist und daher bei jedem neuen Schreibvorgang erstmal die Zellen gelöscht werden müssen und dann frisch beschrieben, statt wie bei getrimmten SSDs und daher deutlich langsamer. Daher testweise mal Bitlocker ausschalten udn schauen, ob das Verhalten sich nach einem Trim verbessert. Wenn ja, dann Bitlocke auf used-Space umstellen. ansonsten weiter nach fehler suchen.
lks
PS: Falls Du Consumer-SSDs statt Enterprise-SSD (egal ob SATA oder NVME) verwendet hast, könnte das der andere mögliche Grund sein. Die haben nämlich i.d.R. einen deutlich kleiner Schreibcache und auch weniger Overprovisioning. Das bremst auch.
2
Neben der Erklärung von @Lochkartenstanzer werfe ich noch folgende Gedanken in den Raum:
Bei SSD's ist es wegen TRIM & Co. sinnvoll, nicht den gesamten möglichen Speicherplatz zu benutzen, sondern rund zehn Prozent weder zu partitionieren noch sonst irgendwie zu nutzen. Denn SSD's haben zwar vom Hersteller her eine gewisse Zusatzreserve an Speicherblöcken, aber so kann es auf ganz lange Sicht keine Engpässe geben, weil die ungenutzt gelassenen Speicherblöcke für TRIM & Co. zusätzlich und völlig frei / vollständig zur Verfügung stehen.
Überdies hat das noch einen weiteren Vorteil, muss eine SSD wegen Ausfall im RAID ersetzt werden, so kann es nicht passieren, dass der RAID-Controller bei einer neuen modellgleichen SSD's plötzlich herumzicken könnte, weil sie nicht ausreichend Speicherplatz habe. Um (nur) das zu vermeiden, muss man natürlich nicht zehn Prozent freilassen, so dass auch deutlich weniger genügen würde.
Die zehn Prozent sind ohnehin ein Fausformel-Wert, den jeder frei gestalten kann.
Wenn das von @Lochkartenstanzer beschriebene Problem zutreffen sollte, spricht zudem alles für einen unnötig erhöhten "Verbrauch" seitens TRIM & Co., so dass sich auch insoweit - gerade bei Datenbankanwendungen, die unter Umständen sehr schreibfreudig sein können - eine zusätzliche Reserve von Schreibblöcken auf längere Sicht als Vorteil erweisen kann. Und wer weiß schon, wie sich Gupta-SQL selbst in einem solch kleinen Anwendungsszenario verhält.
Viele Grüße
HansDampf06
Bei SSD's ist es wegen TRIM & Co. sinnvoll, nicht den gesamten möglichen Speicherplatz zu benutzen, sondern rund zehn Prozent weder zu partitionieren noch sonst irgendwie zu nutzen. Denn SSD's haben zwar vom Hersteller her eine gewisse Zusatzreserve an Speicherblöcken, aber so kann es auf ganz lange Sicht keine Engpässe geben, weil die ungenutzt gelassenen Speicherblöcke für TRIM & Co. zusätzlich und völlig frei / vollständig zur Verfügung stehen.
Überdies hat das noch einen weiteren Vorteil, muss eine SSD wegen Ausfall im RAID ersetzt werden, so kann es nicht passieren, dass der RAID-Controller bei einer neuen modellgleichen SSD's plötzlich herumzicken könnte, weil sie nicht ausreichend Speicherplatz habe. Um (nur) das zu vermeiden, muss man natürlich nicht zehn Prozent freilassen, so dass auch deutlich weniger genügen würde.
Die zehn Prozent sind ohnehin ein Fausformel-Wert, den jeder frei gestalten kann.
Wenn das von @Lochkartenstanzer beschriebene Problem zutreffen sollte, spricht zudem alles für einen unnötig erhöhten "Verbrauch" seitens TRIM & Co., so dass sich auch insoweit - gerade bei Datenbankanwendungen, die unter Umständen sehr schreibfreudig sein können - eine zusätzliche Reserve von Schreibblöcken auf längere Sicht als Vorteil erweisen kann. Und wer weiß schon, wie sich Gupta-SQL selbst in einem solch kleinen Anwendungsszenario verhält.
Viele Grüße
HansDampf06
Moin @Lochkartenstanzer,
der OS seitige TRIM funktioniert bei einem RAID-Volume generell nicht wirklich.
Es ist sogar so, dass in einem solchen Fall, sprich, SSD's hinter einem RAID, ein OS seitig aktivierter TRIM eine sehr negative Auswirkung auf die Performance haben kann. Das merkt man z.B. daran, dass eine Formatierung eines solchen Volumes extrem lange dauern kann, selbst bei einer Qick-Formatierung.
In solchen Fällen sollte man daher die TRIM-Funktion des OS deaktivieren, was bei Windows z.B. mit dem folgenden Befehl möglich ist.
CMD als Administrator:
Ausserdem, im Fall vom TO, sprich, bei der Erstellung der Sicherung, sollte TRIM nicht wirklich eine Rolle spielen, zumindest bei den Quell-Laufwerken, da es beim Lesen vollkommen irrelevant ist.
Gruss Alex
Moine Kristallkugel tippt auf full-encryption statt used space bei Bitlocker. Wenn das RAID/die SSD komplett verschlüsselt wird, Dann hat die TRIM-Funktion keine wirkung mehr, weil technischt gesehen die SSD "vollgeschrieben" ist und daher bei jedem neuen Schreibvorgang erstmal die Zellen gelöscht werden müssen und dann frisch beschrieben, statt wie bei getrimmten SSDs und daher deutlich langsamer.
der OS seitige TRIM funktioniert bei einem RAID-Volume generell nicht wirklich.
Es ist sogar so, dass in einem solchen Fall, sprich, SSD's hinter einem RAID, ein OS seitig aktivierter TRIM eine sehr negative Auswirkung auf die Performance haben kann. Das merkt man z.B. daran, dass eine Formatierung eines solchen Volumes extrem lange dauern kann, selbst bei einer Qick-Formatierung.
In solchen Fällen sollte man daher die TRIM-Funktion des OS deaktivieren, was bei Windows z.B. mit dem folgenden Befehl möglich ist.
CMD als Administrator:
fsutil behavior set disabledeletenotify 1Ausserdem, im Fall vom TO, sprich, bei der Erstellung der Sicherung, sollte TRIM nicht wirklich eine Rolle spielen, zumindest bei den Quell-Laufwerken, da es beim Lesen vollkommen irrelevant ist.
Gruss Alex
Moin @KramerJSEGS,
Software-RAID und Leistung, ähm, ja, der Witz ist auch gut. 🙃
Deine Backplane ist wahrscheinlich OK, das Problem ist eher das ganze Konstrukt.
Denn sowohl das Software-RAID als auch der Bitlocker und wahrscheinlich auch der Defender und oder andere AV Lösung verursachen allesamt einen Haufen zusätzliche CPU Last und genau damit hat dein System zu kämpfen.
Sprich, schalte den Bitlocker aus, der macht auf einem OnPrem-Server eh keinen Sinn, vor allem dann, wenn beim Booten eh kein PIN abgefragt wird. 🙃
(Ohne Boot-PIN, mach der Bitlooker übrigens auch auf einem Client überhaupt keinen Sinn.)
Das sollte schon einiges deiner Schmerzen lindern, wenn du dann jedoch immer noch ähnliche Fehler hast, die ohne Bitlooker jedoch deutlich seltener kommen sollten, dann solltest du dir auf jeden Fall auch Gedanken über ein HW-RAID-Controller machen.
Gruss Alex
Ich frage mich jetzt natürlich, ob ich die Leistungsfähigkeit eines Software-RAIDs falsch eingeschätzt habe.
Software-RAID und Leistung, ähm, ja, der Witz ist auch gut. 🙃
Bei lediglich zwei Benutzern ging ich davon aus, auch ohne Hardware-RAID auszukommen. Oder könnte theoretisch auch die Backplane des Gehäuses (ein Inter-Tech 2U-2404L) für diese Probleme verantwortlich sein?
Deine Backplane ist wahrscheinlich OK, das Problem ist eher das ganze Konstrukt.
Denn sowohl das Software-RAID als auch der Bitlocker und wahrscheinlich auch der Defender und oder andere AV Lösung verursachen allesamt einen Haufen zusätzliche CPU Last und genau damit hat dein System zu kämpfen.
Sprich, schalte den Bitlocker aus, der macht auf einem OnPrem-Server eh keinen Sinn, vor allem dann, wenn beim Booten eh kein PIN abgefragt wird. 🙃
(Ohne Boot-PIN, mach der Bitlooker übrigens auch auf einem Client überhaupt keinen Sinn.)
Das sollte schon einiges deiner Schmerzen lindern, wenn du dann jedoch immer noch ähnliche Fehler hast, die ohne Bitlooker jedoch deutlich seltener kommen sollten, dann solltest du dir auf jeden Fall auch Gedanken über ein HW-RAID-Controller machen.
Gruss Alex
Wir setzen auch nur noch Hardware RAID ein.
Je nach Konfig frisst Sw RAID einfach zu viel CPU, je nach Dateisystem auch viel RAM.
Je nach Konfig frisst Sw RAID einfach zu viel CPU, je nach Dateisystem auch viel RAM.
2Zitat von @MysticFoxDE:
Moin @Lochkartenstanzer,
der OS seitige TRIM funktioniert bei einem RAID-Volume generell nicht wirklich.
Moin @Lochkartenstanzer,
Moine Kristallkugel tippt auf full-encryption statt used space bei Bitlocker. Wenn das RAID/die SSD komplett verschlüsselt wird, Dann hat die TRIM-Funktion keine wirkung mehr, weil technischt gesehen die SSD "vollgeschrieben" ist und daher bei jedem neuen Schreibvorgang erstmal die Zellen gelöscht werden müssen und dann frisch beschrieben, statt wie bei getrimmten SSDs und daher deutlich langsamer.
der OS seitige TRIM funktioniert bei einem RAID-Volume generell nicht wirklich.
Moin
Unter Windows meinst Du. Unter Linux konnte ich da bisher keine Probleme feststellen.
Unter Windows ist es eher davon abhängig. Welches softraid man wählt Intel RST funktioniert relativ zuverlässig. Das Windows-eigene eher nicht.
lks
Ohne Boot-PIN, mach der Bitlooker übrigens auch auf einem Client überhaupt keinen Sinn.
Warum denn das nicht? Klar, wenn der Windows User kein Kennwort hat ist es witzlos, aber sonst kommst du nicht wirklich an die Daten Ran.
Gruß,
Avoton
Zitat von @Avoton:
Ohne Boot-PIN, mach der Bitlooker übrigens auch auf einem Client überhaupt keinen Sinn.
Warum denn das nicht? Klar, wenn der Windows User kein Kennwort hat ist es witzlos, aber sonst kommst du nicht wirklich an die Daten Ran.Na, Jemand nimmt den ganzen Server mit.
Er stellt den bei sich hin und startet ihn. Das OS bootet (der TPM Chip ist ja da).
Jetzt kann die unfreundlichen Person auf verschiedene Areten versuchen sich Zugriff zu verschaffen:
- Kennwort in der Anmeldemaske ausprobieren
- Zugriff via SMB, Web, SSH, FTP, IMAP, etc (Bruteforce-Schutz ist bei Windows standardmäßig deaktiviert)
1
Moin @Avoton,
doch und zwar sehr einfach!
Ganzen Server mitnehmen, Zuhause z.B. mit "Windows 11 to GO" hochfahren und schon hat man deine Daten.
Oder man knackt, respektive überschreibt einfach das lokale Admin Kennwort.
Oder man zieht die Daten noch vor Ort ab.
Oder ...
Usw.
Daher, Bitloker ohne Boot-PIN kann man sich auch gleich wieder sparen.
Ausser, man selbst und auch die User, stehen besonders auf Masochismus, dann kann man es natürlich schon einschalten.
Übrigens, dasselbe was BitLocker macht kannst du auch mit SED's (self-encrypting drive) bewerkstelligen.
Jedoch mit einem riesigen Unterschied, denn die SED's fressen bei Benutzung der CPU keine Haare vom Kopf, BitLocker hingegen schon und auch nicht zu wenig. 🙃
Gruss Alex
Warum denn das nicht? Klar, wenn der Windows User kein Kennwort hat ist es witzlos, aber sonst kommst du nicht wirklich an die Daten Ran.
doch und zwar sehr einfach!
Ganzen Server mitnehmen, Zuhause z.B. mit "Windows 11 to GO" hochfahren und schon hat man deine Daten.
Oder man knackt, respektive überschreibt einfach das lokale Admin Kennwort.
Oder man zieht die Daten noch vor Ort ab.
Oder ...
Usw.
Daher, Bitloker ohne Boot-PIN kann man sich auch gleich wieder sparen.
Ausser, man selbst und auch die User, stehen besonders auf Masochismus, dann kann man es natürlich schon einschalten.
Übrigens, dasselbe was BitLocker macht kannst du auch mit SED's (self-encrypting drive) bewerkstelligen.
Jedoch mit einem riesigen Unterschied, denn die SED's fressen bei Benutzung der CPU keine Haare vom Kopf, BitLocker hingegen schon und auch nicht zu wenig. 🙃
Gruss Alex
Moin @Lochkartenstanzer,
auch bei den Pinguinen funktioniert ein TRIM auf ein RAID-Volume nicht wirklich.
https://www.redhat.com/sysadmin/trim-discard-ssds
😉
Die Thematik betrifft leider so gut wie alle RAID's und zwar auch die von Hardware-RAID-Controllern. 😔
Doch, genau in diesem Fall müsste Windows theoretisch den TRIM Befehl eigentlich "sauberer" an die hinter dem RAID liegenden Laufwerke weitergegeben können, weil es für diese ja quasi auch direkt zuständig ist.
Ob das praktisch aber auch der Fall ist, weis ich stand jetzt nicht wirklich und meine Kristallkugel tendiert schon jetzt eher zu nein.
Gruss Alex
Unter Windows meinst Du. Unter Linux konnte ich da bisher keine Probleme feststellen.
auch bei den Pinguinen funktioniert ein TRIM auf ein RAID-Volume nicht wirklich.
https://www.redhat.com/sysadmin/trim-discard-ssds
😉
Unter Windows ist es eher davon abhängig. Welches softraid man wählt Intel RST funktioniert relativ zuverlässig.
Die Thematik betrifft leider so gut wie alle RAID's und zwar auch die von Hardware-RAID-Controllern. 😔
Das Windows-eigene eher nicht.
Doch, genau in diesem Fall müsste Windows theoretisch den TRIM Befehl eigentlich "sauberer" an die hinter dem RAID liegenden Laufwerke weitergegeben können, weil es für diese ja quasi auch direkt zuständig ist.
Ob das praktisch aber auch der Fall ist, weis ich stand jetzt nicht wirklich und meine Kristallkugel tendiert schon jetzt eher zu nein.
Gruss Alex
Ganzen Server mitnehmen, Zuhause z.B. mit "Windows 11 to GO" hochfahren und schon hat man deine Daten.
Das funktioniert nicht, zumindest nicht in meinen bisherigen Versuchen. Um das Volume dann zu entsperren will er den Recovery Key.
Erst die Woche noch bei einem Surface gehabt.
Gruß,
Aboton
Zitat von @MysticFoxDE:
Moin @Lochkartenstanzer,
auch bei den Pinguinen funktioniert ein TRIM auf ein RAID-Volume nicht wirklich.
https://www.redhat.com/sysadmin/trim-discard-ssds
😉
Moin @Lochkartenstanzer,
Unter Windows meinst Du. Unter Linux konnte ich da bisher keine Probleme feststellen.
auch bei den Pinguinen funktioniert ein TRIM auf ein RAID-Volume nicht wirklich.
https://www.redhat.com/sysadmin/trim-discard-ssds
😉
Wir hatten es von Softraids. Und da nimmt man unter linux per default die md-raids und da sorgt der Treiber und der Kernel dafür, das das Trimkommando bei der SSD ankommt. Ich hatte da nie Probleme. Wenn man hingegen irgendwelche Raidcontroller nimmt und der deren Software (meist als dm-devices durchgereicht) ist man von der Lust und Laune des Controllerherstellers abhängig.
Unter Windows ist es eher davon abhängig. Welches softraid man wählt Intel RST funktioniert relativ zuverlässig.
Die Thematik betrifft leider so gut wie alle RAID's und zwar auch die von Hardware-RAID-Controllern. 😔
Das Windows-eigene eher nicht.
Doch, genau in diesem Fall müsste Windows theoretisch den TRIM Befehl eigentlich "sauberer" an die hinter dem RAID liegenden Laufwerke weitergegeben können, weil es für diese ja quasi auch direkt zuständig ist.
Ob das praktisch aber auch der Fall ist, weis ich stand jetzt nicht wirklich und meine Kristallkugel tendiert schon jetzt eher zu nein.
Ja, windows könnte es machen, macht es aber nicht. Wie gesagt mit Intel rapidstore und den dazugehörigen softrais habe ich gute Erfahrungen. Mit anderen eher nicht.
Und Hardware-Raids sind sowieso ein Kapitel für sich. Da arbeite ich dann mit overprovisioning mit mindestens 25%, was sich deutlich positiv auf die Performance auswirkt..
lks