9
Flashspeicher (SSD) für MS SQL Server?
Moin Zusammen,
ich suche momentan nach Erfahrungsberichten/werten von Administratoren, die bereits einen Wechsel von HDD (SAS) Platten auf SSDs (Flashspeicher, vielleicht sogar NVMe) gemacht haben.
Ich z.B. habe eine VMware Serverlandschaft mit ein paar Exsi Hosts und ein paar Netapp SANS mit SAS Platten. So im Desktop / Notebook Bereich kommt man um SSDs (alleine um die Betriebssystem gut schnell zum Laufen zu bekommen, aber natürlich auch für diverse Programme etc.) gar nicht mehr drum herum.
Ich frage mich wie es da im Serverbereich aussieht? Ich habe selber nur Erfahrungen mit Server Betriebssystemen ab Windows Server 2003 bis 2019... Seit dem wir damals auf Windows Server 2016 gegangen sind, war plötzlich ein starker Performance Verlust zu verzeichnen. Die Boot Up times gingen nach oben aber auch die Programme reagieren immer träger.
Ist Flashspeicher für Database Server wie z.B. ein MS SQL und diversen Datenbanken und Instanzen auch sinnvoll oder vielleicht sogar dringend empfohlen?
Habt ihr Erfahrungen mit Flashspeicher in der Serverlandschaft und wenn ja ist das bereits schon der Standard, auch im Bezug auf kleine bis mittelständige Firmen?
Vielen Dank schon mal
ich suche momentan nach Erfahrungsberichten/werten von Administratoren, die bereits einen Wechsel von HDD (SAS) Platten auf SSDs (Flashspeicher, vielleicht sogar NVMe) gemacht haben.
Ich z.B. habe eine VMware Serverlandschaft mit ein paar Exsi Hosts und ein paar Netapp SANS mit SAS Platten. So im Desktop / Notebook Bereich kommt man um SSDs (alleine um die Betriebssystem gut schnell zum Laufen zu bekommen, aber natürlich auch für diverse Programme etc.) gar nicht mehr drum herum.
Ich frage mich wie es da im Serverbereich aussieht? Ich habe selber nur Erfahrungen mit Server Betriebssystemen ab Windows Server 2003 bis 2019... Seit dem wir damals auf Windows Server 2016 gegangen sind, war plötzlich ein starker Performance Verlust zu verzeichnen. Die Boot Up times gingen nach oben aber auch die Programme reagieren immer träger.
Ist Flashspeicher für Database Server wie z.B. ein MS SQL und diversen Datenbanken und Instanzen auch sinnvoll oder vielleicht sogar dringend empfohlen?
Habt ihr Erfahrungen mit Flashspeicher in der Serverlandschaft und wenn ja ist das bereits schon der Standard, auch im Bezug auf kleine bis mittelständige Firmen?
Vielen Dank schon mal
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 667698
Url: https://administrator.de/forum/flashspeicher-ssd-fuer-ms-sql-server-667698.html
Ausgedruckt am: 22.12.2024 um 07:12 Uhr
9 Kommentare
Neuester Kommentar
Moin,
da ich meine Server selbst baue habe ich schon seit Jahren viele Systeme mit SATA oder gar NVMe SSDs bestückt. Läuft wunderbar. Auf hohe TBW achten (gibt genug Angebote am Markt) und ab dafür.
Wenn du aber auf die OEMs angewiesen bist, sind deren SSDs im Vergleich gefühlt der letzte Schrott. Miese IOPs und Durchsatzraten bei Schreibzugriffe usw.
Da muss halt der RAID-Controller Abhilfe schaffen mit RAID10 o.ä.
Hier ein paar Beispiele:
da ich meine Server selbst baue habe ich schon seit Jahren viele Systeme mit SATA oder gar NVMe SSDs bestückt. Läuft wunderbar. Auf hohe TBW achten (gibt genug Angebote am Markt) und ab dafür.
Wenn du aber auf die OEMs angewiesen bist, sind deren SSDs im Vergleich gefühlt der letzte Schrott. Miese IOPs und Durchsatzraten bei Schreibzugriffe usw.
Da muss halt der RAID-Controller Abhilfe schaffen mit RAID10 o.ä.
Hier ein paar Beispiele:
- Samsung OEM Datacenter SSD PM897
- Corsair Force Series MP600 R2
- Lexar Professional NM800
3
Moin,
Die Speichertypen sind das eine, die Anbindung das andere.
Wenn ihr NVMe-Storages einsetzt, das aber mit 1G iSCSI anbindet, ist das so, als wenn ihr mit dem Porsche Carrera auf einer Landstraße fahrt: viel Bums im Hintern aber nicht voll nutzbar.
Andersherum bringt es auch wenig: ein Trabbi auf einer BAB ohne Limit: du könntest Gas geben, hast aber keine Leistung.
Die Leistung von (SAS) HDDs hat man früher gesteigert, in dem man lieber viele Disks, dafür mit weniger Kapazität genutzt hat. Hier dann gerne als RAID 5 oder 6. Denn Spindeln waren durch nichts zu ersetzen (gut, Cache im RAID- Controller), außer noch mehr Spindeln.
Im Summe musst du also schauen, welche Last deine DB erzeugt/ braucht und dann das Speichersystem wählen. IOPS sind hier ein spannender Wert. Ob eine DB auf NVMes im RAID 1 oder doch eher RAID10 besser ist, kann ich nicht sagen. Unsere DBs laufen auf einem IBM SAN mit FC Anbindung und 12G SAS SSDs. Das reicht für uns…
Die Speichertypen sind das eine, die Anbindung das andere.
Wenn ihr NVMe-Storages einsetzt, das aber mit 1G iSCSI anbindet, ist das so, als wenn ihr mit dem Porsche Carrera auf einer Landstraße fahrt: viel Bums im Hintern aber nicht voll nutzbar.
Andersherum bringt es auch wenig: ein Trabbi auf einer BAB ohne Limit: du könntest Gas geben, hast aber keine Leistung.
Die Leistung von (SAS) HDDs hat man früher gesteigert, in dem man lieber viele Disks, dafür mit weniger Kapazität genutzt hat. Hier dann gerne als RAID 5 oder 6. Denn Spindeln waren durch nichts zu ersetzen (gut, Cache im RAID- Controller), außer noch mehr Spindeln.
Im Summe musst du also schauen, welche Last deine DB erzeugt/ braucht und dann das Speichersystem wählen. IOPS sind hier ein spannender Wert. Ob eine DB auf NVMes im RAID 1 oder doch eher RAID10 besser ist, kann ich nicht sagen. Unsere DBs laufen auf einem IBM SAN mit FC Anbindung und 12G SAS SSDs. Das reicht für uns…
2
Zitat von @em-pie:
Die Speichertypen sind das eine, die Anbindung das andere.
Wenn ihr NVMe-Storages einsetzt, das aber mit 1G iSCSI anbindet, ist das so, als wenn ihr mit dem Porsche Carrera auf einer Landstraße fahrt: viel Bums im Hintern aber nicht voll nutzbar.
Im Summe musst du also schauen, welche Last deine DB erzeugt/ braucht und dann das Speichersystem wählen. IOPS sind hier ein spannender Wert. Ob eine DB auf NVMes im RAID 1 oder doch eher RAID10 besser ist, kann ich nicht sagen. Unsere DBs laufen auf einem IBM SAN mit FC Anbindung und 12G SAS SSDs. Das reicht für uns…
Die Speichertypen sind das eine, die Anbindung das andere.
Wenn ihr NVMe-Storages einsetzt, das aber mit 1G iSCSI anbindet, ist das so, als wenn ihr mit dem Porsche Carrera auf einer Landstraße fahrt: viel Bums im Hintern aber nicht voll nutzbar.
Im Summe musst du also schauen, welche Last deine DB erzeugt/ braucht und dann das Speichersystem wählen. IOPS sind hier ein spannender Wert. Ob eine DB auf NVMes im RAID 1 oder doch eher RAID10 besser ist, kann ich nicht sagen. Unsere DBs laufen auf einem IBM SAN mit FC Anbindung und 12G SAS SSDs. Das reicht für uns…
Genau guter Punkt, dass habe ich auch auf dem Schirm. Ich hab auch eine entsprechende Fiber Anbindung an der SAN.
IOPS des Datenbankservers auch ein gutes Thema.
Wie kann ich das am smartesten Testen, um mir eine Übersicht über den IST Stand zu verschaffen?
Moin,
Selbst SATA SSDs mit ihren ca. 500Mbit sind deutlich flotter an einem "normalen" DAS RAID-Controller.
Bei NVME ist die Anbindung halt das Problem.
8 SATA SSD im RAID 5 kommen auf "nur" 7.5 GBit.
8 NVME SSD im RAID 5 kommen auf 49 Gbit.
RAID-Controller die das können sind schon sehr teuer und brauchen passende Schnittstellen.
Linus Tech Tipps hatten so einen schönes NVME-Storage-Monster. NVME SSD, Dual CPU und 512 GB RAM nur als Storage-System.
SSD: Ja, immer.
Auf die TBWD achten. Ich hatte, je nach Anforderungen, meist Micron Enterprise SATA SSD als Read- oder Write-
optimiert. Dazu meist 1-2 interne NVME SSDs als Cache oder schneller zwischenspeicher.
Ich habe seit ein paar Jahren keine HDDs mehr verbaut (bis auf NAS Datengräber).
Stefan
Selbst SATA SSDs mit ihren ca. 500Mbit sind deutlich flotter an einem "normalen" DAS RAID-Controller.
Bei NVME ist die Anbindung halt das Problem.
8 SATA SSD im RAID 5 kommen auf "nur" 7.5 GBit.
8 NVME SSD im RAID 5 kommen auf 49 Gbit.
RAID-Controller die das können sind schon sehr teuer und brauchen passende Schnittstellen.
Linus Tech Tipps hatten so einen schönes NVME-Storage-Monster. NVME SSD, Dual CPU und 512 GB RAM nur als Storage-System.
SSD: Ja, immer.
Auf die TBWD achten. Ich hatte, je nach Anforderungen, meist Micron Enterprise SATA SSD als Read- oder Write-
optimiert. Dazu meist 1-2 interne NVME SSDs als Cache oder schneller zwischenspeicher.
Ich habe seit ein paar Jahren keine HDDs mehr verbaut (bis auf NAS Datengräber).
Stefan
1
Moin
Abseits dessen musst Du aber auch ganz einfach überlegen, welchen Workload Du überhaupt auf dem Festplattensystem zu erwarten hast und ob ein Stripen in irgendeiner Form überhaupt notwendig ist. Für den genannten SQL-Server ist z.B. eher ordentlich RAM die Lösung und eher nachgeordnet ein hochperformantes Datenträgersystem.
Gruß
Zitat von @StefanKittel:
Ich habe seit ein paar Jahren keine HDDs mehr verbaut (bis auf NAS Datengräber).
+1Ich habe seit ein paar Jahren keine HDDs mehr verbaut (bis auf NAS Datengräber).
Zitat von @Speedfish:
Ist Flashspeicher für Database Server wie z.B. ein MS SQL und diversen Datenbanken und Instanzen auch sinnvoll
Ja. Wobei Du - wie schon oben erwähnt - auf die Qualität der verwendeten Datenträger achten solltest.Ist Flashspeicher für Database Server wie z.B. ein MS SQL und diversen Datenbanken und Instanzen auch sinnvoll
Abseits dessen musst Du aber auch ganz einfach überlegen, welchen Workload Du überhaupt auf dem Festplattensystem zu erwarten hast und ob ein Stripen in irgendeiner Form überhaupt notwendig ist. Für den genannten SQL-Server ist z.B. eher ordentlich RAM die Lösung und eher nachgeordnet ein hochperformantes Datenträgersystem.
Gruß
Zitat von @Hubert.N:
Ja. Wobei Du - wie schon oben erwähnt - auf die Qualität der verwendeten Datenträger achten solltest.
Ein DB-Server mit Read-Optimierten SSD kann diese in 10 Tagen tot-nudeln...Ja. Wobei Du - wie schon oben erwähnt - auf die Qualität der verwendeten Datenträger achten solltest.
Stefan
1
Hallo,
welche Applikationen nutzen denn diese MS SQL DBs?
Sofern die Applikation 99% lesend auf die DB zugreift, wird am Storage kaum was ankommen.
Dann lieber mehr RAM spendieren um den Inhalt schon bereit zu halten.
SSD oder NVMEs SAN Systeme spielen ihre echten Stärken erst bei hohen I/O Queue Tiefen aus.
Vergleichen könntest du das mit entsprechenden Benchmarks. Diese müssen allerdings den echten Workload widerspiegeln und nicht den theoretischen max Durchsatz unter perfekten Bedingungen,
Offtopic:
Ich sitze nun schon fast 2 Jahre an einem solchen Performance Thema einer DB dran.
Man kann diese Engpässe natürlich mit enormer Hardware erschlagen, oder man optimiert einfach die Zugriff / Applikation
Gruß und viel Erfolg
welche Applikationen nutzen denn diese MS SQL DBs?
Sofern die Applikation 99% lesend auf die DB zugreift, wird am Storage kaum was ankommen.
Dann lieber mehr RAM spendieren um den Inhalt schon bereit zu halten.
SSD oder NVMEs SAN Systeme spielen ihre echten Stärken erst bei hohen I/O Queue Tiefen aus.
Vergleichen könntest du das mit entsprechenden Benchmarks. Diese müssen allerdings den echten Workload widerspiegeln und nicht den theoretischen max Durchsatz unter perfekten Bedingungen,
Offtopic:
Ich sitze nun schon fast 2 Jahre an einem solchen Performance Thema einer DB dran.
Man kann diese Engpässe natürlich mit enormer Hardware erschlagen, oder man optimiert einfach die Zugriff / Applikation
Gruß und viel Erfolg
Moin.
Eine pauschale Aussage zur MSSQL ist schlicht nicht möglich - das hängt ja nicht nur vom Server und dessen Performance ab, sondern auch maßgeblich von der "Programmierkunst" der Software-Entwickler, deren Applikation auf den SQL-Server zugreift. Wir sehen trotz schneller SSDs, RAID, mehr als ausreichend RAM etc. im Monitoring immer wieder Alarme, dass sich Sessions gegenseitig blockieren etc. Hier sind die Entwickler gefragt, nicht die Hardware-Abteilung...
Generell beschleunigen SSDs im Vergleich zu drehenden Platten natürlich auch Server und vor allem Virtualisierung enorm. Wir machen das seit sicherlich zehn Jahren gar nicht mehr anders, es kommen nur noch SSDs zum Einsatz und das läuft sehr flott und stabil. Natürlich gilt es auch hier zu differenzieren: Kommt ein SAN zum Einsatz oder sind die SSDs in der Server-Hardware/Backplane verbaut? Wie groß ist die Umgebung? Wird die Unterscheidung zwischen Hot und Cold Storage überhaupt noch benötigt?
Cheers,
jsysde
Eine pauschale Aussage zur MSSQL ist schlicht nicht möglich - das hängt ja nicht nur vom Server und dessen Performance ab, sondern auch maßgeblich von der "Programmierkunst" der Software-Entwickler, deren Applikation auf den SQL-Server zugreift. Wir sehen trotz schneller SSDs, RAID, mehr als ausreichend RAM etc. im Monitoring immer wieder Alarme, dass sich Sessions gegenseitig blockieren etc. Hier sind die Entwickler gefragt, nicht die Hardware-Abteilung...
Generell beschleunigen SSDs im Vergleich zu drehenden Platten natürlich auch Server und vor allem Virtualisierung enorm. Wir machen das seit sicherlich zehn Jahren gar nicht mehr anders, es kommen nur noch SSDs zum Einsatz und das läuft sehr flott und stabil. Natürlich gilt es auch hier zu differenzieren: Kommt ein SAN zum Einsatz oder sind die SSDs in der Server-Hardware/Backplane verbaut? Wie groß ist die Umgebung? Wird die Unterscheidung zwischen Hot und Cold Storage überhaupt noch benötigt?
Cheers,
jsysde
Zitat von @ElmerAcmeee:
Offtopic:
Ich sitze nun schon fast 2 Jahre an einem solchen Performance Thema einer DB dran.
Man kann diese Engpässe natürlich mit enormer Hardware erschlagen, oder man optimiert einfach die Zugriff / Applikation
Offtopic:
Ich sitze nun schon fast 2 Jahre an einem solchen Performance Thema einer DB dran.
Man kann diese Engpässe natürlich mit enormer Hardware erschlagen, oder man optimiert einfach die Zugriff / Applikation
Besonders die Anwendung bieten ein hohes Optimierungspotentional.
In den meisten Fällen sind das fertige Anwendungen, wie z.B. Exchange wo man nichts kann.
Aber wenn, dann kann man da richtig was rausholen.
Softwareentwickler wollen Code der gut lesbar ist und gut funktioniert.
Performance spielt meist keine Rolle. Kann der Kunde ja schnellere Server kaufen.
Ich habe bei einem Kunden mal ein Skript optimiert was Zahlungen zwischen Shop und Onlinebanking abgleicht.
Laufzeit vorher: 57 Minuten
Laufzeit nachher: 17 Sekunden
Stefan
1
