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?
Please also mark the comments that contributed to the solution of the article
Content-ID: 667950
Url: https://administrator.de/contentid/667950
Printed on: October 13, 2024 at 11:10 o'clock
35 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.
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 1
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
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
Zitat 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
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)
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
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
Moin @Avoton,
du hast absolut Recht!
Das Szenario habe ich wohl theoretisch nicht ganz zu ende gedacht und praktisch musste ich es bisher zum Glück auch noch nicht anwenden.
Aber, das mit dem Booten des bestehenden OS und zurücksetzen des Administratorkennworts klappt auf jeden Fall, selbst bei einem DC. ๐
Und mit einem Backdoor und z.B. gesnifften Zugangsdaten, kann man die Daten auch ganz gemütlich Remote abziehen, vor allen bei Servern, die normalerweise eh 24/7 durchlaufen. ๐
Ausserdem frisst BitLocker einen Haufen zusätzlicher Ressourcen und wenn man dann noch in Richtung BIOS/ME Updates weiterdenkt, kann es ganz schnell noch viel gruseliger werden. ๐ฌ
https://www.dell.com/support/kbdoc/de-de/000134415/updating-the-bios-on- ...
https://support.lenovo.com/de/de/solutions/ht506425-unexpected-bitlocker ...
Na ja, genaugenommen benötigt es zum "Abschiessen" des Bitlocker noch nicht mal ein BIOS/ME Update, denn wie Microsoft es erst jüngst bewiesen hat, geht das auch per Windows-Update ...
https://www.golem.de/news/update-panne-bei-microsoft-windows-update-erfo ...
... ๐ญ
Und genau wegen sowas, habe ich bisher einen riesigen Bogen um BitLocker gemacht und werde es auch in Zukunft so machen.
Ach ja, Falls mir jetzt irgend ein DSBler den Sonntag mit so Sachen wie ... "Lieber Alex, laut Artikel 32 der DSGVO bist du in vielen Fällen zur Verschlüsselung verpflichtet" kommen möchte ... so ist das keine gute Idee.
Denn ich kenne den Artikel 32 der DSGVO auch, vor allem nicht nur 1.a, sondern auch 1.b und 1.c, sprich ...
... und genau das spricht wiederum gegen den Einsatz von Bitlocker oder ähnlichem 0815-Verschlüsselungs-Schnickschnack.
Und ja liebe DSBler, ich habe 1.a mit Absicht ausgelassen, denn diesen kennen die meisten von euch, im Gegensatz zu 1.b und 1.c, eh schon viel zu gut. ๐คช
Ausserdem gibt es in Deutschland einen Haufen Gesetze, die ein Unternehmen dazu verpflichten, z.B. alle steuerlich relevanten Unterlagen, jederzeit und über einen Zeitraum von bis zu 10, respektive, im Medizinischen Bereich sogar bis zu 30 Jahren aufzubewahren und zwar so, dass man diese auch jederzeit wieder auslesen kann.
https://www.gesetze-im-internet.de/ao_1977/__147.html
Sprich, ja man muss zwar auf der einen Seite z.B. durch Verschlüsselung sicherstellen, dass keine Unberechtigten/Fremden an den Inhalt von vor allem sensiblen Daten kommen, aber, dadurch darf man auf keinen Fall den Zugriff der Berechtigten auf diese Daten jemals gefährden! ๐
Gruss Alex
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.
Erst die Woche noch bei einem Surface gehabt.
du hast absolut Recht!
Das Szenario habe ich wohl theoretisch nicht ganz zu ende gedacht und praktisch musste ich es bisher zum Glück auch noch nicht anwenden.
Aber, das mit dem Booten des bestehenden OS und zurücksetzen des Administratorkennworts klappt auf jeden Fall, selbst bei einem DC. ๐
Und mit einem Backdoor und z.B. gesnifften Zugangsdaten, kann man die Daten auch ganz gemütlich Remote abziehen, vor allen bei Servern, die normalerweise eh 24/7 durchlaufen. ๐
Ausserdem frisst BitLocker einen Haufen zusätzlicher Ressourcen und wenn man dann noch in Richtung BIOS/ME Updates weiterdenkt, kann es ganz schnell noch viel gruseliger werden. ๐ฌ
https://www.dell.com/support/kbdoc/de-de/000134415/updating-the-bios-on- ...
https://support.lenovo.com/de/de/solutions/ht506425-unexpected-bitlocker ...
Na ja, genaugenommen benötigt es zum "Abschiessen" des Bitlocker noch nicht mal ein BIOS/ME Update, denn wie Microsoft es erst jüngst bewiesen hat, geht das auch per Windows-Update ...
https://www.golem.de/news/update-panne-bei-microsoft-windows-update-erfo ...
... ๐ญ
Und genau wegen sowas, habe ich bisher einen riesigen Bogen um BitLocker gemacht und werde es auch in Zukunft so machen.
Ach ja, Falls mir jetzt irgend ein DSBler den Sonntag mit so Sachen wie ... "Lieber Alex, laut Artikel 32 der DSGVO bist du in vielen Fällen zur Verschlüsselung verpflichtet" kommen möchte ... so ist das keine gute Idee.
Denn ich kenne den Artikel 32 der DSGVO auch, vor allem nicht nur 1.a, sondern auch 1.b und 1.c, sprich ...
Unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen treffen der Verantwortliche und der Auftragsverarbeiter geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten; diese Maßnahmen schließen gegebenenfalls unter anderem Folgendes ein:
b) die Fähigkeit, die Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der Systeme und Dienste im Zusammenhang mit der Verarbeitung auf Dauer sicherzustellen;
c) die Fähigkeit, die Verfügbarkeit der personenbezogenen Daten und den Zugang zu ihnen bei einem physischen oder technischen Zwischenfall rasch wiederherzustellen;
... und genau das spricht wiederum gegen den Einsatz von Bitlocker oder ähnlichem 0815-Verschlüsselungs-Schnickschnack.
Und ja liebe DSBler, ich habe 1.a mit Absicht ausgelassen, denn diesen kennen die meisten von euch, im Gegensatz zu 1.b und 1.c, eh schon viel zu gut. ๐คช
Ausserdem gibt es in Deutschland einen Haufen Gesetze, die ein Unternehmen dazu verpflichten, z.B. alle steuerlich relevanten Unterlagen, jederzeit und über einen Zeitraum von bis zu 10, respektive, im Medizinischen Bereich sogar bis zu 30 Jahren aufzubewahren und zwar so, dass man diese auch jederzeit wieder auslesen kann.
https://www.gesetze-im-internet.de/ao_1977/__147.html
Sprich, ja man muss zwar auf der einen Seite z.B. durch Verschlüsselung sicherstellen, dass keine Unberechtigten/Fremden an den Inhalt von vor allem sensiblen Daten kommen, aber, dadurch darf man auf keinen Fall den Zugriff der Berechtigten auf diese Daten jemals gefährden! ๐
Gruss Alex
Moin @Lochkartenstanzer,
Na ja, die meisten RAID's die man z.B. über das BIOS des Mainboards konfigurieren kann, sind in meinen Augen auch nur Soft-RAID's, weil die für die Storage-Bereitstellung nicht eine eigene CPU/ASIC haben, sondern diese über die "normalen" CPU des Rechners/Workstation/Servers ineffizient abwerkeln, zumindest im Vergleich zu einem HW-RAID, mit eigener ASIC und eigenem RAM.
Ja, Intel RST funktioniert schon relativ zuverlässig, jedoch kommt auch dieses nicht wirklich an ein richtiges HW-RAID heran und HW-RAID-Controller gibt es von Intel zumindest auch keine mehr, denn die wurden so wie es aussieht ...
https://ark.intel.com/content/www/us/en/ark/products/series/2092/intel-r ...
... mit den Servern wohl mit beerdigt. ๐ญ
Na ja, waren eh schon sehr lange nur noch umgelabelte LSI, respektive Broadcom's. ๐
Ich habe noch mit keinem Soft-RAID eine gute Erfahrung gemacht, zumindest nicht aus Performance Sicht.
Wir verwenden bei HW-RAID's nur Enterprise SSD's von meist Kioxia (ehem. HGST) und die sind schon von Haus aus mit mehr als ausreichend Reservekapazität ausgestattet, die man übrigens mit der Wahl der WPD auch selbst ein Stückweit bestimmen kann. ๐
Ausserdem habe ich erst dem Letzt, eine über 6 Jahre altes AllFlash-SAN eines unserer Kunden (Infortrend DS4000), welches Kapazitätstechnisch zu über 90% ausgenudelt ist, im Zuge eines Vergleichs gegen eine Nigel Nagel neue HPE Alletra MP 16C rennen lassen. Und neben der Tatsache, dass die 6 Jahre alte Infortrend DS4000 die neue HPE Alletra MP ordentlich angepinkelt hat, hat sich auch herausgestellt, dass die DS4000, über die 6 Jahre Betriebszeit, nicht ein bisschen ihrer Leistung eingebüsst hat und zwar mit 0% zusätzlichem Overprovisioning. ๐
Dabei beträgt die Haltbarkeit der SSD's, stand jetzt noch über 90%, sprich, bei einer ähnlichen Belastung wie bisher, würden die jetzt schon über 6 Jahre alten SSD's, theoretisch noch über 50 Jahre halten. ๐คช
Gruss Alex
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.
Na ja, die meisten RAID's die man z.B. über das BIOS des Mainboards konfigurieren kann, sind in meinen Augen auch nur Soft-RAID's, weil die für die Storage-Bereitstellung nicht eine eigene CPU/ASIC haben, sondern diese über die "normalen" CPU des Rechners/Workstation/Servers ineffizient abwerkeln, zumindest im Vergleich zu einem HW-RAID, mit eigener ASIC und eigenem RAM.
Unter Windows ist es eher davon abhängig. Welches softraid man wählt Intel RST funktioniert relativ zuverlässig.
Ja, Intel RST funktioniert schon relativ zuverlässig, jedoch kommt auch dieses nicht wirklich an ein richtiges HW-RAID heran und HW-RAID-Controller gibt es von Intel zumindest auch keine mehr, denn die wurden so wie es aussieht ...
https://ark.intel.com/content/www/us/en/ark/products/series/2092/intel-r ...
... mit den Servern wohl mit beerdigt. ๐ญ
Na ja, waren eh schon sehr lange nur noch umgelabelte LSI, respektive Broadcom's. ๐
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.
Ich habe noch mit keinem Soft-RAID eine gute Erfahrung gemacht, zumindest nicht aus Performance Sicht.
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..
Wir verwenden bei HW-RAID's nur Enterprise SSD's von meist Kioxia (ehem. HGST) und die sind schon von Haus aus mit mehr als ausreichend Reservekapazität ausgestattet, die man übrigens mit der Wahl der WPD auch selbst ein Stückweit bestimmen kann. ๐
Ausserdem habe ich erst dem Letzt, eine über 6 Jahre altes AllFlash-SAN eines unserer Kunden (Infortrend DS4000), welches Kapazitätstechnisch zu über 90% ausgenudelt ist, im Zuge eines Vergleichs gegen eine Nigel Nagel neue HPE Alletra MP 16C rennen lassen. Und neben der Tatsache, dass die 6 Jahre alte Infortrend DS4000 die neue HPE Alletra MP ordentlich angepinkelt hat, hat sich auch herausgestellt, dass die DS4000, über die 6 Jahre Betriebszeit, nicht ein bisschen ihrer Leistung eingebüsst hat und zwar mit 0% zusätzlichem Overprovisioning. ๐
Dabei beträgt die Haltbarkeit der SSD's, stand jetzt noch über 90%, sprich, bei einer ähnlichen Belastung wie bisher, würden die jetzt schon über 6 Jahre alten SSD's, theoretisch noch über 50 Jahre halten. ๐คช
Gruss Alex
Moin @Lochkartenstanzer,
folgend noch eine Ergänzung zu Intel RST und TRIM im RAID Betrieb.
https://www.intel.com/content/www/us/en/support/articles/000058208/techn ...
Wie du sehen kannst, wird der TRIM Befehl bei Intel RST nur bei RAID 0 an die SSD's weitergegeben, aber nicht bei RAID 1 oder 5.
Gruss Alex
folgend noch eine Ergänzung zu Intel RST und TRIM im RAID Betrieb.
https://www.intel.com/content/www/us/en/support/articles/000058208/techn ...
Wie du sehen kannst, wird der TRIM Befehl bei Intel RST nur bei RAID 0 an die SSD's weitergegeben, aber nicht bei RAID 1 oder 5.
Gruss Alex
Zitat von @MysticFoxDE:
Moin @Lochkartenstanzer,
folgend noch eine Ergänzung zu Intel RST und TRIM im RAID Betrieb.
https://www.intel.com/content/www/us/en/support/articles/000058208/techn ...
Wie du sehen kannst, wird der TRIM Befehl bei Intel RST nur bei RAID 0 an die SSD's weitergegeben, aber nicht bei RAID 1 oder 5.
Moin @Lochkartenstanzer,
folgend noch eine Ergänzung zu Intel RST und TRIM im RAID Betrieb.
https://www.intel.com/content/www/us/en/support/articles/000058208/techn ...
Wie du sehen kannst, wird der TRIM Befehl bei Intel RST nur bei RAID 0 an die SSD's weitergegeben, aber nicht bei RAID 1 oder 5.
Den kannte ich noch nicht. Aber ich meine TRIM mit RAID1 funktioniert trotzdem. Zumidenst bei den ersten Experimenten vor einigen Jahren. Muß ich mal bei Gelegenheit prüfen. (Unter Windows setze ich i.d.R. keine Softraids ein. ) Nur bei einigen wenigen Kunden (keine Handvoll) die sparen wollten. da ich aber bei SSDS immer grundsätzlich 20-25% der SSD "frei" lasse, merkt man das selbst im Falle, daß TRIM nicht funktionieren sollte nicht.
lks
IntelRST, das waren noch Zeiten!
Zuverlässiges Software-RAID, MDC Prüfung als Systemdienst, set-it-and-forget-it.
Bei IntelVROC sieht dies leider anders aus.
Ich gehe davon aus, dass der Kollege das RAID auf IntelVROC Basis gebaut hat.
Hier habe ich auch Probleme mit vielen EventIDs 4156 & 4155.
Intel ist leider offensichtlich "kaputt-Controlled" worden:
Alleine meine Anfrage zum Software Support im Intel Forum verlief grausam und OHNE Ergebnis.
Es geht hier um die Prüflesung, MDC, welche früher unter IntelRST geplant ausgeführt werden konnte.
Dieses gibt es nur noch bei ANGEMELDETER Admin Konsole, Taskplanung gibt es nicht mehr.
https://community.intel.com/t5/Software-Storage-Technologies/Intel-VROC- ...
Da hier ein Terra-Mini-G4 werkelt, habe ich diesbezüglich Wortmann angeschrieben. Nette Kommunikation, leider ergebnislos in Bezug auf IntelVROC. Wortmann weiß schon, warum die den einzigen PCI-E Slot des MoBos mit einem Hardware-RAID Controller ausgestattet haben. Da ich diesen jedoch für eine Enterprise-SSD brauche, musste ich auf VROC setzen.
Es gibt eine Einstellung im BIOS, welche ich bei Einrichtung des Servers auf "legacy" gestellt habe, siehe Bild:
im Nachhinein lässt sich dies nicht mehr anpassen, ohne das BS neu aufzusetzen. Windows Server 2022 bleibt einfach im Boot Loop.
Da die Produktiv Daten auf anderem Speicher laufen habe ich bislang keine Rechtfertigung, diese Einstellung verbunden mit einem Recovery/sysprep des BS umzusetzen, um anschließend zu sehen, ob die Leistung besser wird.
hat jemand hierzu bereits Erfahrung gemacht?
Ich habe einen Thread auf stackxchng gefunden, der die Unterschiede detailliert erklärt, jedoch noch keine Zeit genommen das zu studieren:
https://electronics.stackexchange.com/questions/76867/what-do-the-differ ...
IMHO Suma Sumarum:
Grundsätzlich keine Fehleinschätzung der grundsätzlichen Leistungsfähigkeit eines Software-RAID sondern einfach fehlende Qualitätssicherung des Herstellers.
Zuverlässiges Software-RAID, MDC Prüfung als Systemdienst, set-it-and-forget-it.
Bei IntelVROC sieht dies leider anders aus.
Ich gehe davon aus, dass der Kollege das RAID auf IntelVROC Basis gebaut hat.
Hier habe ich auch Probleme mit vielen EventIDs 4156 & 4155.
Intel ist leider offensichtlich "kaputt-Controlled" worden:
Alleine meine Anfrage zum Software Support im Intel Forum verlief grausam und OHNE Ergebnis.
Es geht hier um die Prüflesung, MDC, welche früher unter IntelRST geplant ausgeführt werden konnte.
Dieses gibt es nur noch bei ANGEMELDETER Admin Konsole, Taskplanung gibt es nicht mehr.
https://community.intel.com/t5/Software-Storage-Technologies/Intel-VROC- ...
Da hier ein Terra-Mini-G4 werkelt, habe ich diesbezüglich Wortmann angeschrieben. Nette Kommunikation, leider ergebnislos in Bezug auf IntelVROC. Wortmann weiß schon, warum die den einzigen PCI-E Slot des MoBos mit einem Hardware-RAID Controller ausgestattet haben. Da ich diesen jedoch für eine Enterprise-SSD brauche, musste ich auf VROC setzen.
Es gibt eine Einstellung im BIOS, welche ich bei Einrichtung des Servers auf "legacy" gestellt habe, siehe Bild:
im Nachhinein lässt sich dies nicht mehr anpassen, ohne das BS neu aufzusetzen. Windows Server 2022 bleibt einfach im Boot Loop.
Da die Produktiv Daten auf anderem Speicher laufen habe ich bislang keine Rechtfertigung, diese Einstellung verbunden mit einem Recovery/sysprep des BS umzusetzen, um anschließend zu sehen, ob die Leistung besser wird.
hat jemand hierzu bereits Erfahrung gemacht?
Ich habe einen Thread auf stackxchng gefunden, der die Unterschiede detailliert erklärt, jedoch noch keine Zeit genommen das zu studieren:
https://electronics.stackexchange.com/questions/76867/what-do-the-differ ...
IMHO Suma Sumarum:
Grundsätzlich keine Fehleinschätzung der grundsätzlichen Leistungsfähigkeit eines Software-RAID sondern einfach fehlende Qualitätssicherung des Herstellers.
Moin @improver,
warum waren, das ist und wird auf Intel Systemen auch weiterhin verfügbar sein.
Das glaube ich eher nicht.
Das war alles andere als eine gute Idee, den dadurch wird die Hardware interrupttechnich absolut suboptimal angesprochen und die Interrupts werden wenn ich das noch richtig im Kopf habe, auch nur über Core 0 abgearbeitet. ๐ฌ
Du hättest die Einstellung auf MSI-X belassen sollen.
Das geht schon, nur musst du bevor du im BIOS die Interrupt Selection wieder auf MSI-X umstellst, im Betriebssystem die MSI-X fähigen RST Treiber Installieren, dann sollte es kein Problem sein.
Das sieht mir übrigens eher nach einer RST, als nach einer VROC Konfiguration aus.
Gruss Alex
IntelRST, das waren noch Zeiten!
warum waren, das ist und wird auf Intel Systemen auch weiterhin verfügbar sein.
Ich gehe davon aus, dass der Kollege das RAID auf IntelVROC Basis gebaut hat.
Das glaube ich eher nicht.
Es gibt eine Einstellung im BIOS, welche ich bei Einrichtung des Servers auf "legacy" gestellt habe, siehe Bild:
Das war alles andere als eine gute Idee, den dadurch wird die Hardware interrupttechnich absolut suboptimal angesprochen und die Interrupts werden wenn ich das noch richtig im Kopf habe, auch nur über Core 0 abgearbeitet. ๐ฌ
Du hättest die Einstellung auf MSI-X belassen sollen.
im Nachhinein lässt sich dies nicht mehr anpassen, ohne das BS neu aufzusetzen. Windows Server 2022 bleibt einfach im Boot Loop.
Das geht schon, nur musst du bevor du im BIOS die Interrupt Selection wieder auf MSI-X umstellst, im Betriebssystem die MSI-X fähigen RST Treiber Installieren, dann sollte es kein Problem sein.
Das sieht mir übrigens eher nach einer RST, als nach einer VROC Konfiguration aus.
Gruss Alex
Danke für die Hinweise, Alex!
Doch zu intelRST muss ich, bzw. Intel , zumindest im Serverbereich, widersprechen:
Konsolidierung IntelRSTe IntelVROC
Ob die Consumer-Boards weiterhin IntelRST behalten habe ich nicht recherchiert.
Zum Treiber Support für VROC , letzte Aktualisierung seitens intel 26.04.2023:
https://www.intel.com/content/www/us/en/download/777584/intel-virtual-ra ...
Es gibt nmK keine separaten Treiber als von Intel bzw. OEMs angeboten,
doch ich wäre sehr dankbar für einen Link zu den entsprechenden "MSI-X" unterstützenden Treibern
oder einen Hinweis, worauf ich hier zu achten habe.
Vielleicht übersehe ich einfach etwas.
Doch zu intelRST muss ich, bzw. Intel , zumindest im Serverbereich, widersprechen:
Konsolidierung IntelRSTe IntelVROC
Ob die Consumer-Boards weiterhin IntelRST behalten habe ich nicht recherchiert.
Zum Treiber Support für VROC , letzte Aktualisierung seitens intel 26.04.2023:
https://www.intel.com/content/www/us/en/download/777584/intel-virtual-ra ...
Es gibt nmK keine separaten Treiber als von Intel bzw. OEMs angeboten,
MSI-X fähigen RST Treiber Installieren,
doch ich wäre sehr dankbar für einen Link zu den entsprechenden "MSI-X" unterstützenden Treibern
oder einen Hinweis, worauf ich hier zu achten habe.
Vielleicht übersehe ich einfach etwas.
Moin @improver,
sehr gerne.
OK und ebenfalls Danke für diesen Hinweise, da ist mir wohl etwas entgangen.
Ich denke schon, dass das auch bei den Consumer-Boards, erstmal so beibehalten bleibt.
Der MXI-X fähige Treiber ist in den normalen Paketen bereits schon enthalten.
Respektive, damit der Treiber im MSI-X Mode läuft, müssten eigentlich nur ein Paar Registry-Werte hinzugefügt werden.
Welche das genau sind, kann ich dir jetzt auf die Schnelle zumindest nicht sagen, dazu müsste ich die entsprechende inf Datei etwas genauer anschauen und am Besten auch mal ein Auge auf die entsprechende Maschine werfen.
Gruss Alex
Danke für die Hinweise, Alex!
sehr gerne.
Doch zu intelRST muss ich, bzw. Intel , zumindest im Serverbereich, widersprechen:
Konsolidierung IntelRSTe IntelVROC
Konsolidierung IntelRSTe IntelVROC
OK und ebenfalls Danke für diesen Hinweise, da ist mir wohl etwas entgangen.
Ob die Consumer-Boards weiterhin IntelRST behalten habe ich nicht recherchiert.
Ich denke schon, dass das auch bei den Consumer-Boards, erstmal so beibehalten bleibt.
Zum Treiber Support für VROC , letzte Aktualisierung seitens intel 26.04.2023:
https://www.intel.com/content/www/us/en/download/777584/intel-virtual-ra ...
Es gibt nmK keine separaten Treiber als von Intel bzw. OEMs angeboten,
https://www.intel.com/content/www/us/en/download/777584/intel-virtual-ra ...
Es gibt nmK keine separaten Treiber als von Intel bzw. OEMs angeboten,
Der MXI-X fähige Treiber ist in den normalen Paketen bereits schon enthalten.
Respektive, damit der Treiber im MSI-X Mode läuft, müssten eigentlich nur ein Paar Registry-Werte hinzugefügt werden.
Welche das genau sind, kann ich dir jetzt auf die Schnelle zumindest nicht sagen, dazu müsste ich die entsprechende inf Datei etwas genauer anschauen und am Besten auch mal ein Auge auf die entsprechende Maschine werfen.
Gruss Alex
Interessant ist, das Thomas Krenn angibt,
legacy anstelle von MSI-X
bei der Konfig eines SuperMicro Servers zu wählen:
Onboard_RAID_auf_Supermicro_X12_Mainboards
legacy anstelle von MSI-X
bei der Konfig eines SuperMicro Servers zu wählen:
Onboard_RAID_auf_Supermicro_X12_Mainboards
Moin @improver,
na ja, wahrscheinlich hat der Tim diese Anleitung, gemäss den Angaben von Supermicro und oder Broadcom gemacht, sprich, deren Fehler nur 1:1 abgekupfert. ๐
Und da er bei TK noch ein AZUBI ist, kann ich ihm diesen Fehler auch nicht wirklich übel nehmen.
Habe ihm soeben per Mail ne Info geschickt, dass diese Konfigurationsempfehlung nicht wirklich gut ist.
Mal schauen was nun passiert. So wie ich TK jedoch kennen, ist die Doku ratz fatz korrigiert.
Zu dem Thema MSI MSI-X habe ich noch die folgenden, meiner Ansicht nach sehr interessanten Beiträge ausgegraben.
https://electronics.stackexchange.com/questions/76867/what-do-the-differ ...
https://community.checkpoint.com/t5/Management/New-R80-x-Performance-Tun ...
Und ja, der letzte Artikel ist eigentlich über PCIe Netzwerkkarten, aber auch diese verursachen einen Haufen Interrupts, daher betrifft der Inhalt dieses Beitrags, zumindest was das Interrupt-Handling angeht, auch fast 1:1 einen PCIe Raid-Controller oder auch andere PCIe Geräte. ๐
Gruss Alex
Interessant ist, das Thomas Krenn angibt,
legacy anstelle von MSI-X
bei der Konfig eines SuperMicro Servers zu wählen:
Onboard_RAID_auf_Supermicro_X12_Mainboards
legacy anstelle von MSI-X
bei der Konfig eines SuperMicro Servers zu wählen:
Onboard_RAID_auf_Supermicro_X12_Mainboards
na ja, wahrscheinlich hat der Tim diese Anleitung, gemäss den Angaben von Supermicro und oder Broadcom gemacht, sprich, deren Fehler nur 1:1 abgekupfert. ๐
Und da er bei TK noch ein AZUBI ist, kann ich ihm diesen Fehler auch nicht wirklich übel nehmen.
Habe ihm soeben per Mail ne Info geschickt, dass diese Konfigurationsempfehlung nicht wirklich gut ist.
Mal schauen was nun passiert. So wie ich TK jedoch kennen, ist die Doku ratz fatz korrigiert.
Zu dem Thema MSI MSI-X habe ich noch die folgenden, meiner Ansicht nach sehr interessanten Beiträge ausgegraben.
https://electronics.stackexchange.com/questions/76867/what-do-the-differ ...
https://community.checkpoint.com/t5/Management/New-R80-x-Performance-Tun ...
Und ja, der letzte Artikel ist eigentlich über PCIe Netzwerkkarten, aber auch diese verursachen einen Haufen Interrupts, daher betrifft der Inhalt dieses Beitrags, zumindest was das Interrupt-Handling angeht, auch fast 1:1 einen PCIe Raid-Controller oder auch andere PCIe Geräte. ๐
Gruss Alex
Moin @improver,
ja, das gleiche Problem hast man bei den HW-RAID's aber auch. ๐ญ
Ich habe erst gestern einem Techniker eines befreundeten Systemhauses bei einem Problem mit einem einem Lenovo Server geholfen, in dem ein Broadcom 9350-8i RAID-Controller verbaut war, der zwei SSD RAID-Volumes bediente.
Das RAID war eigentlich nach Vorgaben des Herstellers konfiguriert, sprich mit Direct-IO, deaktivierter Drive-Cache und lauter solcher Scherze. ๐
Wir haben dann gemeinsam einige Korrekturen vorgenommen und schon ging die DB Latenz einer wichtigen Anwendung des entsprechenden Kunden, von > 4ms auf <0,5ms runter. ๐
Gruss Alex
Grundsätzlich keine Fehleinschätzung der grundsätzlichen Leistungsfähigkeit eines Software-RAID sondern einfach fehlende Qualitätssicherung des Herstellers.
ja, das gleiche Problem hast man bei den HW-RAID's aber auch. ๐ญ
Ich habe erst gestern einem Techniker eines befreundeten Systemhauses bei einem Problem mit einem einem Lenovo Server geholfen, in dem ein Broadcom 9350-8i RAID-Controller verbaut war, der zwei SSD RAID-Volumes bediente.
Das RAID war eigentlich nach Vorgaben des Herstellers konfiguriert, sprich mit Direct-IO, deaktivierter Drive-Cache und lauter solcher Scherze. ๐
Wir haben dann gemeinsam einige Korrekturen vorgenommen und schon ging die DB Latenz einer wichtigen Anwendung des entsprechenden Kunden, von > 4ms auf <0,5ms runter. ๐
Gruss Alex
Moin @improver,
kleiner Nachtrag, diese etwas "suboptimale" Empfehlung gehört der Geschichte an,
der Tim hat den Beitrag bereits korrigiert. ๐
@ Tim Biebel (@ Thomas Krenn)
๐๐๐ ... ich bin absolut begeistert. ๐๐๐
Bei Microsoft hätte eine ähnliche Korrektur wahrscheinlich mindestens 2 Jahre gedauert und auch noch unzählige Nerven gekostet.
Gruss Alex
Interessant ist, das Thomas Krenn angibt,
legacy anstelle von MSI-X
bei der Konfig eines SuperMicro Servers zu wählen:
Onboard_RAID_auf_Supermicro_X12_Mainboards
legacy anstelle von MSI-X
bei der Konfig eines SuperMicro Servers zu wählen:
Onboard_RAID_auf_Supermicro_X12_Mainboards
kleiner Nachtrag, diese etwas "suboptimale" Empfehlung gehört der Geschichte an,
der Tim hat den Beitrag bereits korrigiert. ๐
@ Tim Biebel (@ Thomas Krenn)
๐๐๐ ... ich bin absolut begeistert. ๐๐๐
Bei Microsoft hätte eine ähnliche Korrektur wahrscheinlich mindestens 2 Jahre gedauert und auch noch unzählige Nerven gekostet.
Gruss Alex
Naja, er hat sich den Eintrag zum Interrupt einfach gespart X|
Doch Chapeau, direkter Einfluss auf die Redaktion!
Den Beitrag auf stackxchng hatte ich ja schon verlinkt
Die Theorie ist immer schön, besonders im Detail, doch die Anwendung dieser Theorie ist im Fall von VROC doch zäh.
Interessant ist auch, dass Intel bereits über VROC Version 9 schreibt, es gibt jedoch keine Treiber zu finden.
Quelle
Doch Chapeau, direkter Einfluss auf die Redaktion!
Den Beitrag auf stackxchng hatte ich ja schon verlinkt
..Zeit genommen das zu studieren:
https://electronics.stackexchange.com/questions/76867/what-do-the-differ ...
IMHO Suma Sumarum:..
https://electronics.stackexchange.com/questions/76867/what-do-the-differ ...
IMHO Suma Sumarum:..
Die Theorie ist immer schön, besonders im Detail, doch die Anwendung dieser Theorie ist im Fall von VROC doch zäh.
Interessant ist auch, dass Intel bereits über VROC Version 9 schreibt, es gibt jedoch keine Treiber zu finden.
Quelle
Moin @improver,
wenn der Wert per Default auf MSI-X steht, dann ist das auch richtig so.
Denn Einstellungen die bei einer Konfiguration nicht verändert werden, werden in einer Anleitung normalerweise auch nicht extra beschrieben.
> Die Theorie ist immer schön, besonders im Detail, doch die Anwendung dieser Theorie ist im Fall von VROC doch zäh.
Was meinst du mit zäh, VROC unterstützt doch schon sehr lange MSI-X.
In der folgenden Dokus steht dazu auch etwas mehr geschrieben.
https://www.intel.com/content/dam/support/us/en/documents/memory-and-sto ...
Und frag mich jetzt bitte nicht, warum dasselbe auch nicht in den Dokus für Windows drinsteht, denn das weiss nur Intel. ๐
Übrigens, schau mal was ich noch gefunden habe ...
https://www.intel.com/content/dam/support/us/en/documents/memory-and-sto ...
๐
Doch Treiber sind bereits verfügbar ...
https://www.intel.de/content/www/de/de/products/sku/128254/intel-virtual ...
... bisher warum auch immer aber nur für ESXi. ๐
Gruss Alex
Naja, er hat sich den Eintrag zum Interrupt einfach gespart X|
wenn der Wert per Default auf MSI-X steht, dann ist das auch richtig so.
Denn Einstellungen die bei einer Konfiguration nicht verändert werden, werden in einer Anleitung normalerweise auch nicht extra beschrieben.
> Die Theorie ist immer schön, besonders im Detail, doch die Anwendung dieser Theorie ist im Fall von VROC doch zäh.
Was meinst du mit zäh, VROC unterstützt doch schon sehr lange MSI-X.
In der folgenden Dokus steht dazu auch etwas mehr geschrieben.
https://www.intel.com/content/dam/support/us/en/documents/memory-and-sto ...
Und frag mich jetzt bitte nicht, warum dasselbe auch nicht in den Dokus für Windows drinsteht, denn das weiss nur Intel. ๐
Übrigens, schau mal was ich noch gefunden habe ...
https://www.intel.com/content/dam/support/us/en/documents/memory-and-sto ...
๐
Interessant ist auch, dass Intel bereits über VROC Version 9 schreibt, es gibt jedoch keine Treiber zu finden.
Quelle
Quelle
Doch Treiber sind bereits verfügbar ...
https://www.intel.de/content/www/de/de/products/sku/128254/intel-virtual ...
... bisher warum auch immer aber nur für ESXi. ๐
Gruss Alex
Stark Alex! Danke!
Auf die Idee im Linux Bereich zu forschen bin ich nicht gekommen.
Weshalb Intel die Windows Welt so schlecht supported könnte daran liegen, dass sie offiziell sagen, VROC würde von den OEMs implementiert und man solle sich an diese mit dem VROC Problem wenden. Zumindest ist das die Aussage, die ich im Intel Forum offiziell von Intel erhalten habe.
Dies meine ich auch mit zäh. Wenn du dir die Diskussion im Intel Forum anschaust, musste ich den Intel Mitarbeiter an die Hand nehmen, damit das Problem erkannt, verstanden und nach einer Lösung gesucht wird um schlussendlich nach 3 Monaten zu lesen zu bekommen:
"sorry, we will forward your question to dev. Check out your OEMs Support"
Es scheint dass die Funktionalität auch davon abhängt, ob ein System im UEFI oder legacy (CSM) Modus läuft. Anscheinend bietet nur UEFI die volle Unterstützung:
Auf die Idee im Linux Bereich zu forschen bin ich nicht gekommen.
Weshalb Intel die Windows Welt so schlecht supported könnte daran liegen, dass sie offiziell sagen, VROC würde von den OEMs implementiert und man solle sich an diese mit dem VROC Problem wenden. Zumindest ist das die Aussage, die ich im Intel Forum offiziell von Intel erhalten habe.
Dies meine ich auch mit zäh. Wenn du dir die Diskussion im Intel Forum anschaust, musste ich den Intel Mitarbeiter an die Hand nehmen, damit das Problem erkannt, verstanden und nach einer Lösung gesucht wird um schlussendlich nach 3 Monaten zu lesen zu bekommen:
"sorry, we will forward your question to dev. Check out your OEMs Support"
Es scheint dass die Funktionalität auch davon abhängt, ob ein System im UEFI oder legacy (CSM) Modus läuft. Anscheinend bietet nur UEFI die volle Unterstützung:
Moin @improver,
es gibt von Intel noch viel detailliertere Dokus, diese sind jedoch ausschliesslich für Partner/Developer gedacht und dürfen auch nicht veröffentlicht werden. ๐
Ja, diese Krankheit, also die eigenen Probleme auf die OEM's abzuschieben, hat sich Intel wahrscheinlich von Microsoft abgeschaut. ๐ญ
Den 1st Level Support, kannst du bei Intel mittlerweile glaube ich auch so gut wie knicken.
Ja, so ist das, aber auch diese Info, ist leider nicht einfach zu finden.
https://www.intel.de/content/www/de/de/support/articles/000005877/server ...
๐
Gruss Alex
Auf die Idee im Linux Bereich zu forschen bin ich nicht gekommen.
es gibt von Intel noch viel detailliertere Dokus, diese sind jedoch ausschliesslich für Partner/Developer gedacht und dürfen auch nicht veröffentlicht werden. ๐
Weshalb Intel die Windows Welt so schlecht supported könnte daran liegen, dass sie offiziell sagen, VROC würde von den OEMs implementiert und man solle sich an diese mit dem VROC Problem wenden. Zumindest ist das die Aussage, die ich im Intel Forum offiziell von Intel erhalten habe.
Ja, diese Krankheit, also die eigenen Probleme auf die OEM's abzuschieben, hat sich Intel wahrscheinlich von Microsoft abgeschaut. ๐ญ
Dies meine ich auch mit zäh. Wenn du dir die Diskussion im Intel Forum anschaust, musste ich den Intel Mitarbeiter an die Hand nehmen, damit das Problem erkannt, verstanden und nach einer Lösung gesucht wird um schlussendlich nach 3 Monaten zu lesen zu bekommen:
"sorry, we will forward your question to dev. Check out your OEMs Support"
"sorry, we will forward your question to dev. Check out your OEMs Support"
Den 1st Level Support, kannst du bei Intel mittlerweile glaube ich auch so gut wie knicken.
Es scheint dass die Funktionalität auch davon abhängt, ob ein System im UEFI oder legacy (CSM) Modus läuft. Anscheinend bietet nur UEFI die volle Unterstützung:
Ja, so ist das, aber auch diese Info, ist leider nicht einfach zu finden.
https://www.intel.de/content/www/de/de/support/articles/000005877/server ...
๐
Gruss Alex
Wow, tolle Info!
Ich habe ja wirklich viel Zeit in die Recherche gesteckt, doch diesen Link nicht gefunden:
Vielen Dank dafür!
Umso mehr nochmals herzlichen Dank für deinen Support!
Beim nächsten VROC kann ich die config besser setzen!
Wenn mal Zeit ist, wird auch die alte config angepasst. Jetzt gibt es ja auch einen Hinweis von Intel.
Leider hat Asus/Wortmann dazu überhaupt keine Hinweise gegeben. In dem Wortmann Terra Server werkelt ein
P11C-I
und hier gibt es Intels offiziellen Hinweis zum Treiber Support:
please consult your OEM
Cheers
Ich habe ja wirklich viel Zeit in die Recherche gesteckt, doch diesen Link nicht gefunden:
Ja, so ist das, aber auch diese Info, ist leider nicht einfach zu finden.
https://www.intel.de/content/www/de/de/support/articles/000005877/server ...
https://www.intel.de/content/www/de/de/support/articles/000005877/server ...
Vielen Dank dafür!
Den 1st Level Support, kannst du bei Intel mittlerweile glaube ich auch so gut wie knicken.
Umso mehr nochmals herzlichen Dank für deinen Support!
Beim nächsten VROC kann ich die config besser setzen!
Wenn mal Zeit ist, wird auch die alte config angepasst. Jetzt gibt es ja auch einen Hinweis von Intel.
Leider hat Asus/Wortmann dazu überhaupt keine Hinweise gegeben. In dem Wortmann Terra Server werkelt ein
P11C-I
und hier gibt es Intels offiziellen Hinweis zum Treiber Support:
please consult your OEM
Cheers
Moin @improver,
sehr gerne.
Ich hatte während meiner IT-Laufbahn, das Glück Intel noch von seiner besseren Seite kennen zu lernen und vor allem hatten mir viele Intel-Mitarbeiter und zwar in Deutschland sitzende, sehr weitergeholfen, meistens sogar absolut unbürokratisch. Der erste IMS mit einer AllFlash-Bestückung geht z.B. auf mein Konto. ๐
Oh man, das waren noch spannende, aber auch sehr lustige Zeiten.
In letzter Zeit bin ich von Intel jedoch eher enttäuscht worden.
Die Flash Sparte wurde abverkauft oder eingestampft (OPTAIN). ๐ญ (dümmste Idee ever)
Die Serversparte auch. ๐คฎ (zweit dümmste Idee)
Die NUC's nun ebenfalls. ๐ (dritt dümmste Idee)
...
Und für so einen Schwachsinn, bekommt der Pat Gelsinger auch noch über 160 Millionen/Jahr.
Ich verabscheue und hasse mittlerweile diesen, meiner Ansicht nach absolut unfähigen Menschen!
Schaut mal bitte dir selber an, was von den Unternehmen die der Pat in seiner Laufbahn geleitet hat, heute noch übrig geblieben ist. Ich sage nur EMC, VMware. ๐๐ญ
Und nun plant er auch noch die Netzwerkkarten Sparte zu verkaufen. ๐ก
Upps ... das ist ja noch gar nicht offiziell ... ๐ฌ ... ja, sorry Pat, ist mir jetzt dennoch irgendwie rausgerutscht.
Na ja, wenn ich schon dabei bin.
@ Pat Gelsinger
Meiner Ansicht nach hat Intel nur noch eine Möglichkeit seinen Hintern zu retten und zwar indem sie deinen, so schnell wie möglich vor die Tür setzen!
Gruss Alex
Wow, tolle Info!
Ich habe ja wirklich viel Zeit in die Recherche gesteckt, doch diesen Link nicht gefunden:
Vielen Dank dafür!
Umso mehr nochmals herzlichen Dank für deinen Support!
Ich habe ja wirklich viel Zeit in die Recherche gesteckt, doch diesen Link nicht gefunden:
Ja, so ist das, aber auch diese Info, ist leider nicht einfach zu finden.
https://www.intel.de/content/www/de/de/support/articles/000005877/server ...
https://www.intel.de/content/www/de/de/support/articles/000005877/server ...
Vielen Dank dafür!
Den 1st Level Support, kannst du bei Intel mittlerweile glaube ich auch so gut wie knicken.
Umso mehr nochmals herzlichen Dank für deinen Support!
sehr gerne.
Ich hatte während meiner IT-Laufbahn, das Glück Intel noch von seiner besseren Seite kennen zu lernen und vor allem hatten mir viele Intel-Mitarbeiter und zwar in Deutschland sitzende, sehr weitergeholfen, meistens sogar absolut unbürokratisch. Der erste IMS mit einer AllFlash-Bestückung geht z.B. auf mein Konto. ๐
Oh man, das waren noch spannende, aber auch sehr lustige Zeiten.
In letzter Zeit bin ich von Intel jedoch eher enttäuscht worden.
Die Flash Sparte wurde abverkauft oder eingestampft (OPTAIN). ๐ญ (dümmste Idee ever)
Die Serversparte auch. ๐คฎ (zweit dümmste Idee)
Die NUC's nun ebenfalls. ๐ (dritt dümmste Idee)
...
Und für so einen Schwachsinn, bekommt der Pat Gelsinger auch noch über 160 Millionen/Jahr.
Ich verabscheue und hasse mittlerweile diesen, meiner Ansicht nach absolut unfähigen Menschen!
Schaut mal bitte dir selber an, was von den Unternehmen die der Pat in seiner Laufbahn geleitet hat, heute noch übrig geblieben ist. Ich sage nur EMC, VMware. ๐๐ญ
Und nun plant er auch noch die Netzwerkkarten Sparte zu verkaufen. ๐ก
Upps ... das ist ja noch gar nicht offiziell ... ๐ฌ ... ja, sorry Pat, ist mir jetzt dennoch irgendwie rausgerutscht.
Na ja, wenn ich schon dabei bin.
@ Pat Gelsinger
Meiner Ansicht nach hat Intel nur noch eine Möglichkeit seinen Hintern zu retten und zwar indem sie deinen, so schnell wie möglich vor die Tür setzen!
Gruss Alex
Danke für die Benennung des Verantwortlichen. Insbesondere was VMWare anbetrifft könnte ich auch weinen.
Der Kerl ist einfach zu stark etabliert. Wenn du den englischen Wikipedia-Artikel zu ihm liest, ist es schon krass, dass er selbst auf Regierungsebene als Berater aufgetreten ist. Das ist natürlich eine Reputation, die es schwer macht, so eine Ratte aus dem Nest zu kriegen.
Interessanter Weise hat der Typ ein Buch zur Worklife Balance verfasst. ๐ง
schönes Wochenende!
Der Kerl ist einfach zu stark etabliert. Wenn du den englischen Wikipedia-Artikel zu ihm liest, ist es schon krass, dass er selbst auf Regierungsebene als Berater aufgetreten ist. Das ist natürlich eine Reputation, die es schwer macht, so eine Ratte aus dem Nest zu kriegen.
Interessanter Weise hat der Typ ein Buch zur Worklife Balance verfasst. ๐ง
schönes Wochenende!
Moin @improver,
Es ist leider nicht nur eine Ratte, sondern ein ganzes Nest.
Und in welche Richtung Satya Microsoft in den letzten Jahren weitergebracht hat, wissen und spüren wir glaube ich auch alle, vor allem im Geldbeutel. ๐
By the way.
๐ญ ... ๐คฎ๐คฎ๐คฎ
Gruss Alex
Der Kerl ist einfach zu stark etabliert. Wenn du den englischen Wikipedia-Artikel zu ihm liest, ist es schon krass, dass er selbst auf Regierungsebene als Berater aufgetreten ist. Das ist natürlich eine Reputation, die es schwer macht, so eine Ratte aus dem Nest zu kriegen.
Es ist leider nicht nur eine Ratte, sondern ein ganzes Nest.
Und in welche Richtung Satya Microsoft in den letzten Jahren weitergebracht hat, wissen und spüren wir glaube ich auch alle, vor allem im Geldbeutel. ๐
By the way.
๐ญ ... ๐คฎ๐คฎ๐คฎ
Gruss Alex