Performanceprobleme Datenbankserver in VMware ESXi 5.1 Umgebung
Hallo allerseits,
Wir haben unsere Serverlandschaft weitestgehend virtualisiert, was soweit stabil und weitestgehend performant läuft. Sorgen bereiten lediglich die Server, auf denen MS SQL Server laufen. Unser Systemhaus, welches die virtuelle Umgebung eingerichtet hat meinte von Anbeginn, dass zwar mit Performanceeinbußen bei Virtualisierung zu rechnen sei (was auch logisch erscheint), dass diese aber aber kaum merklich wären und nicht ins Gewicht fallen und durchaus auch Datenbankserver virtualisiert werden könnten. Grundsätzlich würde ich dem zustimmen, bei den SQL Servern zeigen sich aber schon deutliche Abweichungen. Das betrifft im Wesentlichen Zugriffsgeschwindigkeit und Datendurchsatz für den SQL Server. Getestet wurde mit SQLIO von Microsoft. Das Ergebnis für den SQL Server schaut in etwa so aus (die Werte für lesenden und schreibenden Zugriff sind nahezu identisch):
Unsere virtuelle Infrastruktur besteht aus drei VMware-Hosts mit VMware ESXi 5.1.0
2 x 6 Core Opteron 2,4 GHz mit 48 GB RAM
2 x 6 Core Opteron 2,2 GHz mit 44 GB RAM
2 x 12 Core Opteron 2,6 GHz mit 128 GB RAM
und einem HP StorageWorks P4300 mit 10 GBit Anbindung
Insgesamt laufen 24 VMs auf dem System, einige Win Server 2k3, die meisten Win Server 2k8R2 (auch die SQL Server).
Die VMs liegen komplett auf dem Storage und das Storage ist relativ voll.
Meine Frage ist folgende: Sind der derartige Leistungswerte in einer virtuellen Umgebung wie o.g. nachvollziehbar und würde es Sinn machen die SQL Server wieder zu pysischen Maschinen zurück zu migrieren? Oder läuft vielleicht irgend etwas was nicht rund und die Performance sollte schon höher sein?
Es soll in diesem Jahr das Storage erweitert werden. Unter diesen Umständen stellt sich für mich allerdings eher die Frage, ob wir nicht die DB-Server statt dessen wieder auf "richtige" Hardware packen.
Hoffe die Fragen lassen sich so allgemein beantworten. Vielen Dank schon mal.
VG. mhard666
Wir haben unsere Serverlandschaft weitestgehend virtualisiert, was soweit stabil und weitestgehend performant läuft. Sorgen bereiten lediglich die Server, auf denen MS SQL Server laufen. Unser Systemhaus, welches die virtuelle Umgebung eingerichtet hat meinte von Anbeginn, dass zwar mit Performanceeinbußen bei Virtualisierung zu rechnen sei (was auch logisch erscheint), dass diese aber aber kaum merklich wären und nicht ins Gewicht fallen und durchaus auch Datenbankserver virtualisiert werden könnten. Grundsätzlich würde ich dem zustimmen, bei den SQL Servern zeigen sich aber schon deutliche Abweichungen. Das betrifft im Wesentlichen Zugriffsgeschwindigkeit und Datendurchsatz für den SQL Server. Getestet wurde mit SQLIO von Microsoft. Das Ergebnis für den SQL Server schaut in etwa so aus (die Werte für lesenden und schreibenden Zugriff sind nahezu identisch):
E:\SQLIO>sqlio -kR -dE
sqlio v1.5.SG
1 thread reading for 30 secs from file E:testfile.dat
using 2KB IOs over 128KB stripes with 64 IOs per run
initialization done
CUMULATIVE DATA:
throughput metrics:
IOs/sec: 1168.07
MBs/sec: 2.28
2 x 6 Core Opteron 2,4 GHz mit 48 GB RAM
2 x 6 Core Opteron 2,2 GHz mit 44 GB RAM
2 x 12 Core Opteron 2,6 GHz mit 128 GB RAM
und einem HP StorageWorks P4300 mit 10 GBit Anbindung
Insgesamt laufen 24 VMs auf dem System, einige Win Server 2k3, die meisten Win Server 2k8R2 (auch die SQL Server).
Die VMs liegen komplett auf dem Storage und das Storage ist relativ voll.
Meine Frage ist folgende: Sind der derartige Leistungswerte in einer virtuellen Umgebung wie o.g. nachvollziehbar und würde es Sinn machen die SQL Server wieder zu pysischen Maschinen zurück zu migrieren? Oder läuft vielleicht irgend etwas was nicht rund und die Performance sollte schon höher sein?
Es soll in diesem Jahr das Storage erweitert werden. Unter diesen Umständen stellt sich für mich allerdings eher die Frage, ob wir nicht die DB-Server statt dessen wieder auf "richtige" Hardware packen.
Hoffe die Fragen lassen sich so allgemein beantworten. Vielen Dank schon mal.
VG. mhard666
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 233074
Url: https://administrator.de/contentid/233074
Ausgedruckt am: 25.11.2024 um 00:11 Uhr
6 Kommentare
Neuester Kommentar
Hallo m,
prinzipiell kommt es auf die Auslastung und die Leistungsdaten an. Wenn ihr mit den DBs (übertrieben) 20.0000 IOPS macht bringt es nichts, wenn ihr auf Blech zurück kehrt und dort auch nur dediziert 1.000 IOPS anbieten könnt. Ich würde darauf tippen, dass da irgendwas nicht richtig durch geplant wurde (oder der Puffer zu niedrig angesetzt wurde). Das kann man aber aufgrund der o.g Werte nicht klar sagen.
Beste Grüße,
Christian
prinzipiell kommt es auf die Auslastung und die Leistungsdaten an. Wenn ihr mit den DBs (übertrieben) 20.0000 IOPS macht bringt es nichts, wenn ihr auf Blech zurück kehrt und dort auch nur dediziert 1.000 IOPS anbieten könnt. Ich würde darauf tippen, dass da irgendwas nicht richtig durch geplant wurde (oder der Puffer zu niedrig angesetzt wurde). Das kann man aber aufgrund der o.g Werte nicht klar sagen.
Beste Grüße,
Christian
Hallo,
also wenn da 24 VM auf dem selben Physikalischen-Datenträgerverbund werkeln sollte klar sein warum der virtuelle Datenbankserver langsamer ist als der alte Hardwareserver.
Sorge dafür, das die Datenbankserver einen dedizierten HDD-Verbund haben und schick.
Die Frage ist auch wie die Anbindung von Hypervisor und Plattenspeicher ist. Gbit Las oder was richtig schnelles?
Ein Hardwareserver mit eigenem RAID wird immer schneller sein (wenn der Rest gleich ist), als eine VM die den Stor über Langsame Verbindungen herstellen muss.
Gruß
Chonta
PS: Wie waren den die Werte vor der Virtualisierung?
also wenn da 24 VM auf dem selben Physikalischen-Datenträgerverbund werkeln sollte klar sein warum der virtuelle Datenbankserver langsamer ist als der alte Hardwareserver.
Sorge dafür, das die Datenbankserver einen dedizierten HDD-Verbund haben und schick.
Die Frage ist auch wie die Anbindung von Hypervisor und Plattenspeicher ist. Gbit Las oder was richtig schnelles?
Ein Hardwareserver mit eigenem RAID wird immer schneller sein (wenn der Rest gleich ist), als eine VM die den Stor über Langsame Verbindungen herstellen muss.
Gruß
Chonta
PS: Wie waren den die Werte vor der Virtualisierung?
Hallo,
Und vor allem, was erwartest du von dein System an IO/sec und MB/sec? Wir kennen deine dort evtl bremsende Hardware und dessen Anbindung nicht und wissen auch nicht was diese leisten soll kann.... daher, Nett
Dies http://www.mssqltips.com/sqlservertip/2127/benchmarking-sql-server-io-w ... und auch dies http://www.mssqltips.com/sqlservertip/2119/partition-offset-and-allocat ... hast du bestimmt schon beachtet?
Gruß,
Peter
Zitat von @mhard666:
nahezu identisch):
Nett, aber ist Laufwerk E: deine Datenpartition, deine LOG Partition oder was? Sind es seperate Partitionen auf der gleichen Spindel oder jeweils auf seperate Spindeln? Wie groß ist deine Testdatei? Wie sind deine Spindeln denn angebunden? Gibt es Fehler bei deiner Storageanbindung? Gibt es Fehler auf dein Storage LAN?nahezu identisch):
> 1 thread reading for 30 secs from file E:testfile.dat
> using 2KB IOs over 128KB stripes with 64 IOs per run
> IOs/sec: 1168.07
> MBs/sec: 2.28
>
Und vor allem, was erwartest du von dein System an IO/sec und MB/sec? Wir kennen deine dort evtl bremsende Hardware und dessen Anbindung nicht und wissen auch nicht was diese leisten soll kann.... daher, Nett
2 x 6 Core Opteron 2,4 GHz mit 48 GB RAM
2 x 6 Core Opteron 2,2 GHz mit 44 GB RAM
2 x 12 Core Opteron 2,6 GHz mit 128 GB RAM
und einem HP StorageWorks P4300 mit 10 GBit Anbindung
Alles für deinen einen SQL Server? 2 x 6 Core Opteron 2,2 GHz mit 44 GB RAM
2 x 12 Core Opteron 2,6 GHz mit 128 GB RAM
und einem HP StorageWorks P4300 mit 10 GBit Anbindung
Die VMs liegen komplett auf dem Storage und das Storage ist relativ voll.
Warum hat dein SQL keinen eigenen Storage?Dies http://www.mssqltips.com/sqlservertip/2127/benchmarking-sql-server-io-w ... und auch dies http://www.mssqltips.com/sqlservertip/2119/partition-offset-and-allocat ... hast du bestimmt schon beachtet?
Gruß,
Peter
Hallo,
was für eine Anwendung und was für Probleme?
Wenn das Store voll ist, wird es zeit für ein dedeziertes Stor für die Datenbankserver und gleich mit 10GBit oder schneller.
Nur so, Du hast 3 Hypervisor die alle mit 10GBit an den selben Festplattenverbund angeschlossen sind und dieser stellt die Daten für 24VM bereit.
Ist das Stor mit jedem Server über 10GBit verbunden oder einmal 10GBit für alle Server?
Eine Rolle spielt auch wwieviele Platten (und was für Platten) verbaut sind und ob es verschiedee RAIDs gibt oder nur einen RAIDX.
Jeh nachdem musst Du dann mal die Datenraten gegen den Reinen Hardwareserver gegenrechnen der ein RAID?? über SATA/SAS mit ??GB/s hat.
Gruß
Chonta
was für eine Anwendung und was für Probleme?
Wenn das Store voll ist, wird es zeit für ein dedeziertes Stor für die Datenbankserver und gleich mit 10GBit oder schneller.
Nur so, Du hast 3 Hypervisor die alle mit 10GBit an den selben Festplattenverbund angeschlossen sind und dieser stellt die Daten für 24VM bereit.
Ist das Stor mit jedem Server über 10GBit verbunden oder einmal 10GBit für alle Server?
Eine Rolle spielt auch wwieviele Platten (und was für Platten) verbaut sind und ob es verschiedee RAIDs gibt oder nur einen RAIDX.
Jeh nachdem musst Du dann mal die Datenraten gegen den Reinen Hardwareserver gegenrechnen der ein RAID?? über SATA/SAS mit ??GB/s hat.
Gruß
Chonta
Hallo,
für die Leistung des Storagesystems ist nicht nur die Anbindung ausschlaggebend, sondern auch die Ausstattung und Konfiguration des Systems (Anzahl und Typ der Festplatten, Raid-Level, usw.). Die 10GBit nutzen dir nichts, wenn dein Datastore ein RAID 6 mit 5,4k SATA-Platten ist, da die IOPS unterirdisch sind.
Rechne mal die IOPS für dein Storage aus (gibts Online-Rechner im Netz) und schau dir die reellen IOPS im vSphere-Client an, dann bekommst du vielleicht Ansatzpunkte, wo der Flaschenhals für deine DB-Systeme ist.
Aber wenn eh eine Erneuerung des Storage ansteht, lass dir das gleich von einem Systemhaus nachvollziehbar für deine Umgebung durchkalkulieren damit du für zukünftige Anforderungen gerüstet bist.
mfg
für die Leistung des Storagesystems ist nicht nur die Anbindung ausschlaggebend, sondern auch die Ausstattung und Konfiguration des Systems (Anzahl und Typ der Festplatten, Raid-Level, usw.). Die 10GBit nutzen dir nichts, wenn dein Datastore ein RAID 6 mit 5,4k SATA-Platten ist, da die IOPS unterirdisch sind.
Rechne mal die IOPS für dein Storage aus (gibts Online-Rechner im Netz) und schau dir die reellen IOPS im vSphere-Client an, dann bekommst du vielleicht Ansatzpunkte, wo der Flaschenhals für deine DB-Systeme ist.
Aber wenn eh eine Erneuerung des Storage ansteht, lass dir das gleich von einem Systemhaus nachvollziehbar für deine Umgebung durchkalkulieren damit du für zukünftige Anforderungen gerüstet bist.
mfg