5
Datenbankserver physisch oder virtuell?
Gute Morgen liebe Admins,
Mich würde euer fachlichen Meinung interessieren. Folgendes Szenario:
Aktuell MSSQL Server mit ca. 200GB großer Datenbank, läuft auf einem 5 Jahre altem Blech mit SAS-SSDs RI. Die SQL Datenbank ist aufgrund der schlechten Programmierung und Datenstruktur nicht sonderlich performant. Leider haben wir auf die Datenbank jedoch keinen Einfluss! D.h. wie so oft, miese Software muss durch Hardwareleistung kompensiert werden. Ca. 30 User arbeiten damit.
Nun stellt sich die Frage, ist es rein aus Performancegründen besser wieder einen physischen DB Server mit NVMe hinzustellen oder soll ich mich trauen den Server virtuell auf einem ESX Cluster mit All-Flash (nicht NVMe) Speicher laufen zu lassen.
Das Sizing durch den Hersteller sagte 66k IOPS für die Storage.
Erfahrungsgemäß ist es ja so, selbst wenn ich eine doppelt so schnelle Hardware habe, bedeutet das nicht dass die Anwendung doppelt so schnell läuft. Weiters ist Papier sehr geduldig und die Angegebenen Leistungsdaten sind zwar nett und als Vergleich zwischen Produkten brauchbar aber wie praxistauglich die sind, traue ich mir nicht zu beurteilen.
Die Themen wie Verfügbarkeit, Ausfallszenarien, Wartung, Backup, Lizenzen usw. sind uns bewusst und stehen hier nicht zur Diskussion.
Hat jemand Erfahrungen, oder auch Ideen um die IOPS der aktuellen Hardware zu ermitteln. Oder ist das für den Betrieb einer SQL DB ohnehin eher untergeordnet. Lässt sich eine halbwegs realistische Aussage - ohne Glaskugel - treffen ob der Performancevorteil tatsächlich beim Benutzer ankommt.
Die restlichen Server auf der VMware sind nicht sonderlich Ressourcenintensiv.
Danke und Lg Jonny
Mich würde euer fachlichen Meinung interessieren. Folgendes Szenario:
Aktuell MSSQL Server mit ca. 200GB großer Datenbank, läuft auf einem 5 Jahre altem Blech mit SAS-SSDs RI. Die SQL Datenbank ist aufgrund der schlechten Programmierung und Datenstruktur nicht sonderlich performant. Leider haben wir auf die Datenbank jedoch keinen Einfluss! D.h. wie so oft, miese Software muss durch Hardwareleistung kompensiert werden. Ca. 30 User arbeiten damit.
Nun stellt sich die Frage, ist es rein aus Performancegründen besser wieder einen physischen DB Server mit NVMe hinzustellen oder soll ich mich trauen den Server virtuell auf einem ESX Cluster mit All-Flash (nicht NVMe) Speicher laufen zu lassen.
Das Sizing durch den Hersteller sagte 66k IOPS für die Storage.
Erfahrungsgemäß ist es ja so, selbst wenn ich eine doppelt so schnelle Hardware habe, bedeutet das nicht dass die Anwendung doppelt so schnell läuft. Weiters ist Papier sehr geduldig und die Angegebenen Leistungsdaten sind zwar nett und als Vergleich zwischen Produkten brauchbar aber wie praxistauglich die sind, traue ich mir nicht zu beurteilen.
Die Themen wie Verfügbarkeit, Ausfallszenarien, Wartung, Backup, Lizenzen usw. sind uns bewusst und stehen hier nicht zur Diskussion.
Hat jemand Erfahrungen, oder auch Ideen um die IOPS der aktuellen Hardware zu ermitteln. Oder ist das für den Betrieb einer SQL DB ohnehin eher untergeordnet. Lässt sich eine halbwegs realistische Aussage - ohne Glaskugel - treffen ob der Performancevorteil tatsächlich beim Benutzer ankommt.
Die restlichen Server auf der VMware sind nicht sonderlich Ressourcenintensiv.
Danke und Lg Jonny
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-Key: 81974319630
Url: https://administrator.de/contentid/81974319630
Printed on: July 24, 2024 at 09:07 o'clock
5 Comments
Latest comment
Hallo,
nun wenn das ganze auf Blech schon lahmt, wird es virtuell nicht schneller, aber virtuell kann man besser Skalieren, sichern, verschieben.
Wenn es etwas in der Richung HANA oder schlimmeres ist, dann hilft nur ein eigenes Rechenzentrum ;)
grüße
nun wenn das ganze auf Blech schon lahmt, wird es virtuell nicht schneller, aber virtuell kann man besser Skalieren, sichern, verschieben.
Wenn es etwas in der Richung HANA oder schlimmeres ist, dann hilft nur ein eigenes Rechenzentrum ;)
grüße
1
Hallo,
ich stand vor 2 Jahren vor einem ähnlichen Problem: neues ERP-System mit SQL-Datenbank.
Mein VMware-Cluster hatte aber "nur" SSD-Cache.
Ich habe mich für "Blech" entschieden (2x Xeon Gold; 192GB RAM; eigenes Laufwerk für Datenbank: NVMe RAID10) Ca. 25 User, davon 10 permanent zeitig.
Performance absolut top, selbst der Hersteller des ERP war bei der Implementierung überrascht.
Jürgen
PS. Die Chefs können also nicht mehr über ein "lahmes" System mosern.
ich stand vor 2 Jahren vor einem ähnlichen Problem: neues ERP-System mit SQL-Datenbank.
Mein VMware-Cluster hatte aber "nur" SSD-Cache.
Ich habe mich für "Blech" entschieden (2x Xeon Gold; 192GB RAM; eigenes Laufwerk für Datenbank: NVMe RAID10) Ca. 25 User, davon 10 permanent zeitig.
Performance absolut top, selbst der Hersteller des ERP war bei der Implementierung überrascht.
Jürgen
PS. Die Chefs können also nicht mehr über ein "lahmes" System mosern.
1
Moin,
aus HA Gründen halte ich ALLES virtuell.
Du wirst du um einen Praxistest nicht rumkommen, ich hatte schon SQLs von HDD auf SSD verschoben, mehr CPU und RAM, das kam beim Endanwender nicht an weil die Software so schlecht programmiert war.
Im anderen Fall hatte ich die Hyper-V Systeme (SQL + Anwendung) auf eine Workstation gelegt, mit ganz anderer Hardware. Man konnte den Performance Sprung sehen und wusste, was die Server haben sollten.
aus HA Gründen halte ich ALLES virtuell.
Du wirst du um einen Praxistest nicht rumkommen, ich hatte schon SQLs von HDD auf SSD verschoben, mehr CPU und RAM, das kam beim Endanwender nicht an weil die Software so schlecht programmiert war.
Im anderen Fall hatte ich die Hyper-V Systeme (SQL + Anwendung) auf eine Workstation gelegt, mit ganz anderer Hardware. Man konnte den Performance Sprung sehen und wusste, was die Server haben sollten.
2
Virtualisierung ist schon ein echter Vorteil in sehr vielen Belangen. Hättest du jetzt z.B. schon einen virtuellen SQL, könntest du diesen einfach auf neue Hardware schieben und testen. Eigentlich will man das nicht missen und nimmt dafür leichte Performance Verluste in Kauf.
Ich weiß jetzt natürlich nicht ob deine Umgebung zu diesem 1% gehört wo wirklich jedes Quantum Performance gefordert wird. Da ihr jetzt aber auf alter Hardware mit einem einzelnen SQL ohne HA Cluster unterwegs seit, kann ich mir das irgendwie nicht vorstellen. In der Liga kenne ich mich nicht aus, ich denke aber das die meisten mit einem virtuellen SQL sehr gut fahren.
Solltet ihr OEM Core Lizenzen ins Auge fassen, da gibt es gravierende Änderungen. Die dürfen nicht virtuell betrieben werden, nur Core Lizenzen mit SA oder OEM Lizenzen auf Server / CAL Basis. Wäre ja sonst auch einfach und ich müsste mich gar nicht ärgern.
Ich weiß jetzt natürlich nicht ob deine Umgebung zu diesem 1% gehört wo wirklich jedes Quantum Performance gefordert wird. Da ihr jetzt aber auf alter Hardware mit einem einzelnen SQL ohne HA Cluster unterwegs seit, kann ich mir das irgendwie nicht vorstellen. In der Liga kenne ich mich nicht aus, ich denke aber das die meisten mit einem virtuellen SQL sehr gut fahren.
Solltet ihr OEM Core Lizenzen ins Auge fassen, da gibt es gravierende Änderungen. Die dürfen nicht virtuell betrieben werden, nur Core Lizenzen mit SA oder OEM Lizenzen auf Server / CAL Basis. Wäre ja sonst auch einfach und ich müsste mich gar nicht ärgern.
Guten Morgen,
Mich würde euer fachlichen Meinung interessieren. Folgendes Szenario:
Aktuell MSSQL Server mit ca. 200GB großer Datenbank, läuft auf einem 5 Jahre altem Blech mit SAS-SSDs RI. Die SQL Datenbank ist aufgrund der schlechten Programmierung und Datenstruktur nicht sonderlich performant. Leider haben wir auf die Datenbank jedoch keinen Einfluss! D.h. wie so oft, miese Software muss durch Hardwareleistung kompensiert werden. Ca. 30 User arbeiten damit.
Was heißt das genau? Kann man evtl. die Anwendung erfahren? Oder zumindest um welches Anwendungsgebiet es sich handelt?
Wo sind die Performanceprobleme? Bitte genauer spezifizieren.
Habt Ihr schon folgende Tests bzgl. der Performanceprobleme durchgeführt?
Ich hatte vor 12 Jahren ein ähnliche Problem, daß die Performance grottig war, trotz absoluter Highendhardware. MS wurde hinzugezogen und konnte nichts fehlerhaftes finden.
Ich hatte damals einen MS SQL Entwickler, welchen ich kontaktieren konnte. Dieser hat sich dann die SQL-Queries genauer angeschaut.
Die Rückfrage daraus ergab,
Gruss Penny.
Mich würde euer fachlichen Meinung interessieren. Folgendes Szenario:
Aktuell MSSQL Server mit ca. 200GB großer Datenbank, läuft auf einem 5 Jahre altem Blech mit SAS-SSDs RI. Die SQL Datenbank ist aufgrund der schlechten Programmierung und Datenstruktur nicht sonderlich performant. Leider haben wir auf die Datenbank jedoch keinen Einfluss! D.h. wie so oft, miese Software muss durch Hardwareleistung kompensiert werden. Ca. 30 User arbeiten damit.
Wo sind die Performanceprobleme? Bitte genauer spezifizieren.
Habt Ihr schon folgende Tests bzgl. der Performanceprobleme durchgeführt?
- SQL DB / Anwendung und Client lokal
- SQL DB / Anwendung auf einem Rechner, Client auf zweitem Rechner. Beide am separaten Switch angeschlossen.
- SQL DB / Anwendung auf einem Rechner, Client auf zweitem Rechner. Beide am gleichen Netzwerkswitch angeschlossen.
- usw.
Ich hatte vor 12 Jahren ein ähnliche Problem, daß die Performance grottig war, trotz absoluter Highendhardware. MS wurde hinzugezogen und konnte nichts fehlerhaftes finden.
Ich hatte damals einen MS SQL Entwickler, welchen ich kontaktieren konnte. Dieser hat sich dann die SQL-Queries genauer angeschaut.
Die Rückfrage daraus ergab,
- Was wollt ihr mit den SQL-Queries erreichen?
- Was soll als Ergebnis geliefert werden?
Nun stellt sich die Frage, ist es rein aus Performancegründen besser wieder einen physischen DB Server mit NVMe hinzustellen oder soll ich mich trauen den Server virtuell auf einem ESX Cluster mit All-Flash (nicht NVMe) Speicher laufen zu lassen.
siehe meine Anmerkungen oben. Wenn die SQL-Queries für die schlechte Performance zuständig sind, nützt das alles nichts.Das Sizing durch den Hersteller sagte 66k IOPS für die Storage.
Ok, vom Storage her ist schonmal Leistung da. Besser geht immer, klaarErfahrungsgemäß ist es ja so, selbst wenn ich eine doppelt so schnelle Hardware habe, bedeutet das nicht dass die Anwendung doppelt so schnell läuft. Weiters ist Papier sehr geduldig und die Angegebenen Leistungsdaten sind zwar nett und als Vergleich zwischen Produkten brauchbar aber wie praxistauglich die sind, traue ich mir nicht zu beurteilen.
Hätte ich unter Umständen auch Schwierigkeiten. Außer man kann Hardware testweise ordern, damit man es testet. Macht aber nicht jeder herstellen.Die Themen wie Verfügbarkeit, Ausfallszenarien, Wartung, Backup, Lizenzen usw. sind uns bewusst und stehen hier nicht zur Diskussion.
Hat jemand Erfahrungen, oder auch Ideen um die IOPS der aktuellen Hardware zu ermitteln. Oder ist das für den Betrieb einer SQL DB ohnehin eher untergeordnet. Lässt sich eine halbwegs realistische Aussage - ohne Glaskugel - treffen ob der Performancevorteil tatsächlich beim Benutzer ankommt.
siehe meine Anmerkungen ganz oben mit den verschiedenen Testszenarien.Hat jemand Erfahrungen, oder auch Ideen um die IOPS der aktuellen Hardware zu ermitteln. Oder ist das für den Betrieb einer SQL DB ohnehin eher untergeordnet. Lässt sich eine halbwegs realistische Aussage - ohne Glaskugel - treffen ob der Performancevorteil tatsächlich beim Benutzer ankommt.
Die restlichen Server auf der VMware sind nicht sonderlich Ressourcenintensiv.
Danke und Lg Jonny
Danke und Lg Jonny
Gruss Penny.