6
Datenbankserver auf virtuellem Stripeset Volume
Hallo zusammen,
folgendes Szenario für einen Microsoft SQL Server:
Virtueller Windows Server 2016 auf ESXi-Umgebung, VMDKs auf Netapp Storage, Datenträger im RAID4
Ich habe als Datenspeicher in der Virtuellen Maschine folgende Konfiguration gebaut:
A = virtueller SCSI-Controller
B = virtueller SCSI-Controller
C = virtueller SCSI-Controller
An jedem Controller zwei virtuelle Datenträger
A:0 , A:1
B:0 , B:1
C:0 , C:1
In der Windows Datenträgerveraltung folgende Volumes erstellt
D:\ = Stripeset über A:0, B:0, C:0 (Volume für Datenbank)
L:\ = Stripeset über A:1, B:1, C:1 (Volume für Logfiles)
Mit IOMeter habe ich in dieser Konfiguration durchschnittlich etwa 70.000 IOPS gemessen.
Wenn ich alternativ für D:\ und L:\ jeweils einen Basisdatenträger mit jeweils einem virtuellen Datenträger auf einem separaten SCSI-Controller erstelle, komme ich auf knapp 6000 IOPS
Fragen dazu:
Ein Stripeset unter Windows ist an sich nicht fehlertolerant. Wird dieser Nachteil durch das physische RAID im Hintergrund aufgehoben?
Welche anderen Nachteile ergeben sich dadurch?
Erreiche ich durch die Stripesets in der Praxis mit einem SQL Server tatsächlich diesen enormen Performancegewinn oder ist das nur mit solchen Benchmarks messbar?
Hat jemand Erfahrung mit solchen Setups gemacht?
Schonmal vorab vielen Dank für Euren Input
Grüßle
folgendes Szenario für einen Microsoft SQL Server:
Virtueller Windows Server 2016 auf ESXi-Umgebung, VMDKs auf Netapp Storage, Datenträger im RAID4
Ich habe als Datenspeicher in der Virtuellen Maschine folgende Konfiguration gebaut:
A = virtueller SCSI-Controller
B = virtueller SCSI-Controller
C = virtueller SCSI-Controller
An jedem Controller zwei virtuelle Datenträger
A:0 , A:1
B:0 , B:1
C:0 , C:1
In der Windows Datenträgerveraltung folgende Volumes erstellt
D:\ = Stripeset über A:0, B:0, C:0 (Volume für Datenbank)
L:\ = Stripeset über A:1, B:1, C:1 (Volume für Logfiles)
Mit IOMeter habe ich in dieser Konfiguration durchschnittlich etwa 70.000 IOPS gemessen.
Wenn ich alternativ für D:\ und L:\ jeweils einen Basisdatenträger mit jeweils einem virtuellen Datenträger auf einem separaten SCSI-Controller erstelle, komme ich auf knapp 6000 IOPS
Fragen dazu:
Ein Stripeset unter Windows ist an sich nicht fehlertolerant. Wird dieser Nachteil durch das physische RAID im Hintergrund aufgehoben?
Welche anderen Nachteile ergeben sich dadurch?
Erreiche ich durch die Stripesets in der Praxis mit einem SQL Server tatsächlich diesen enormen Performancegewinn oder ist das nur mit solchen Benchmarks messbar?
Hat jemand Erfahrung mit solchen Setups gemacht?
Schonmal vorab vielen Dank für Euren Input
Grüßle
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: 556148
Url: https://administrator.de/contentid/556148
Printed on: April 20, 2024 at 06:04 o'clock
6 Comments
Latest comment
Moin,
wirklich ein RAID _4_ ? Macht man das bei Netapps so?
Ansonsten bin ich folgender Meinung:
- Solange immer das gleiche LUN "unter" den VMDKs liegt, kannst du die echten IOPs nicht wirklich durch die VM Konfiguration im positiven beeinflussen.
- Wenn du separate LUNs hast, die aus autarken RAID Verbünden bestehen hast, sieht die Sache anders aus. (Aber das geht aus deinem Post nicht hervor)
lg,
Slainte
wirklich ein RAID _4_ ? Macht man das bei Netapps so?
Ansonsten bin ich folgender Meinung:
- Solange immer das gleiche LUN "unter" den VMDKs liegt, kannst du die echten IOPs nicht wirklich durch die VM Konfiguration im positiven beeinflussen.
- Wenn du separate LUNs hast, die aus autarken RAID Verbünden bestehen hast, sieht die Sache anders aus. (Aber das geht aus deinem Post nicht hervor)
lg,
Slainte
Hi,
Dadurch habe ich schon so manche VM schneller bekommen, obwohl die Datenblöcke im Endeffekt auf der selben Physik lagen.
Ich kann es jetzt nicht belegen, aber aus Erfahrung weiß ich, dass das SCSI-Protokoll an sich gewissermaßen auch einen Flaschenhals darstellt. Dem zur Folge kann man mit mehreren parallelen Queues u.U. einen höheren Datendurchsatz erzielen.
E.
Zitat von @SlainteMhath:
- Solange immer das gleiche LUN "unter" den VMDKs liegt, kannst du die echten IOPs nicht wirklich durch die VM Konfiguration im positiven beeinflussen.
Doch, das geht schon. Jedes Laufwerk (VMDK) bedeutet im Gast-OS eine eigene SCSI-Queue. Jeder virtuelle SCSI-Controller sowieso.- Solange immer das gleiche LUN "unter" den VMDKs liegt, kannst du die echten IOPs nicht wirklich durch die VM Konfiguration im positiven beeinflussen.
Dadurch habe ich schon so manche VM schneller bekommen, obwohl die Datenblöcke im Endeffekt auf der selben Physik lagen.
Ich kann es jetzt nicht belegen, aber aus Erfahrung weiß ich, dass das SCSI-Protokoll an sich gewissermaßen auch einen Flaschenhals darstellt. Dem zur Folge kann man mit mehreren parallelen Queues u.U. einen höheren Datendurchsatz erzielen.
E.
Hi,
Zitat von @feadin:
Ein Stripeset unter Windows ist an sich nicht fehlertolerant. Wird dieser Nachteil durch das physische RAID im Hintergrund aufgehoben?
Nein. Nur gegen physischen Ausfall. Nicht gegen logischen.Ein Stripeset unter Windows ist an sich nicht fehlertolerant. Wird dieser Nachteil durch das physische RAID im Hintergrund aufgehoben?
Welche anderen Nachteile ergeben sich dadurch?
Wodurch? Ich meine, außer der Nicht-Absicherung gegen logischen Ausfälle.Erreiche ich durch die Stripesets in der Praxis mit einem SQL Server tatsächlich diesen enormen Performancegewinn oder ist das nur mit solchen Benchmarks messbar?
Hat jemand Erfahrung mit solchen Setups gemacht?
Siehe meine Antwort an @SlainteMhathHat jemand Erfahrung mit solchen Setups gemacht?
eine eigene SCSI-Queue
Spielt das immer noch so ein große Rolle? Ok wieder was gelernt 
Hallo ihr beiden, vielen Dank für Euere Beiträge
@SlainteMhath:
Das mit dem RAID4 ist eine NetApp-Eigenheit. Das wird da standardmäßig für Metrocluster verwendet. Warum weiß ich auch nicht.
@emeriks
Danke für die Erklärung, das mit dem verschiedenen SCSI-Queues leuchtet ein. Aber dass das gleich so einen Effekt hat scheint mir unvorstellbar.
Es stehen quasi 2 VMDKs an zwei SCSI-Controllern gegen 6 VMDKs an drei SCSI-Controllern. Dass dabei gleich der 10fache Durchsatz zustande kommt erscheint mir doch etwas zu viel. So schnell kann das RAID4 im hintergrund garnicht sein, oder?
Es stimmt jedenfalls, dass das iSCSI-Protokoll einen Flaschenhals bildet, da an jede Transaktion im Protokollheader gekapselt wird.
Das sehe ich in meinem Fall aber nicht als großes Problem an.
hm... ja das stimmt. Wenn es mir aus irgendeinem Grund die vmdk oder die Windowspartition fetzt, schau ich in die Röhre.
Da hilft dann wohl nur noch ein gutes Backup...
@SlainteMhath:
Das mit dem RAID4 ist eine NetApp-Eigenheit. Das wird da standardmäßig für Metrocluster verwendet. Warum weiß ich auch nicht.
@emeriks
Danke für die Erklärung, das mit dem verschiedenen SCSI-Queues leuchtet ein. Aber dass das gleich so einen Effekt hat scheint mir unvorstellbar.
Es stehen quasi 2 VMDKs an zwei SCSI-Controllern gegen 6 VMDKs an drei SCSI-Controllern. Dass dabei gleich der 10fache Durchsatz zustande kommt erscheint mir doch etwas zu viel. So schnell kann das RAID4 im hintergrund garnicht sein, oder?
Es stimmt jedenfalls, dass das iSCSI-Protokoll einen Flaschenhals bildet, da an jede Transaktion im Protokollheader gekapselt wird.
Das sehe ich in meinem Fall aber nicht als großes Problem an.
hm... ja das stimmt. Wenn es mir aus irgendeinem Grund die vmdk oder die Windowspartition fetzt, schau ich in die Röhre.
Da hilft dann wohl nur noch ein gutes Backup...
Ich hab jetzt noch eine Konfigurationsmöglichkeit getestet:
A = virtueller SCSI-Controller
B = virtueller SCSI-Controller
C = virtueller SCSI-Controller
9 VMDKs
A:0 , A:1 , A:2
B:0 , B:1 , B:2
C:0 , C:1 , C:2
Alle 9 VMDKs unter Windows Server 2016 in einen Storagepool gepackt, damit wiederum 4 gespiegelte virtuelle Disks mit je 105 GB erstellt:
Database 1
Database 2
Logs 1
Logs 2
Damit dann in der Datenträgerverwaltung über Database 1 und 2, sowie über Logs 1 und 2 jeweils ein Stripeset erstellt.
Auf diese Weise habe ich eine Art Software RAID10 mit Windows Bordmitteln gebaut, mit dem ich den Ausfall einer VMDK kompensieren kann. Habe das im laufenden Testbetrieb mal ausprobiert, indem ich eine vmdk aus der VM gelöscht habe.
Der IOPs-Benchmark lief fast unbeirrt weiter, nur die Performance ging naturgemäß zurück und der Storagepool und die Virtual Disks in Windows standen auf Fehler (was auch klar ist), in den Stripesets war alles OK, Daten waren verfügbar.
Ich hab dann, ebenfalls im laufenden Betrieb eine neue VMDK mit gleicher Größe an die VM angefügt und dem Storagepool hinzugefügt,
danach die "fehlerhafte" Festplatte aus dem Pool entfernt und Windows begann eigenständig mit der Reparatur des Storagepools und der gespiegelten Virtual Disks - anschließend alles wieder fehlerfrei, Daten nach wie vor verfügbar.
Performancemäßig bin ich nicht ganz so schnell, wie bei den reinen Stripesets, aber immernoch zwischen 48.000 und 55.000 IOPS.
Was natürlich sein kann ist, dass die Netapp bestimmte Daten cached und dadurch das ergebnis der Benchmarks verfälscht.
Im Endeffekt bekomm ich nur verlässliche Anhaltspunkte, wenn ich mal einen SQL-Server aufsetze,
einen Dump der Datenbank einspiele und vergleichbare Abfragen auf beiden Test-Systemen laufen lasse.
Das wäre demnach auch mein nächster Schritt.
@emeriks
Was hälst Du von dieser Konfig mit dem Storagepool, den gespiegelten Virtualdisks und darüber ein Stripeset?
Wenn es mir eine VMDK zerschiesst, kann ich das so abfangen. Bleibt hald noch das Stripeset selbst als Fehlerquelle...
A = virtueller SCSI-Controller
B = virtueller SCSI-Controller
C = virtueller SCSI-Controller
9 VMDKs
A:0 , A:1 , A:2
B:0 , B:1 , B:2
C:0 , C:1 , C:2
Alle 9 VMDKs unter Windows Server 2016 in einen Storagepool gepackt, damit wiederum 4 gespiegelte virtuelle Disks mit je 105 GB erstellt:
Database 1
Database 2
Logs 1
Logs 2
Damit dann in der Datenträgerverwaltung über Database 1 und 2, sowie über Logs 1 und 2 jeweils ein Stripeset erstellt.
Auf diese Weise habe ich eine Art Software RAID10 mit Windows Bordmitteln gebaut, mit dem ich den Ausfall einer VMDK kompensieren kann. Habe das im laufenden Testbetrieb mal ausprobiert, indem ich eine vmdk aus der VM gelöscht habe.
Der IOPs-Benchmark lief fast unbeirrt weiter, nur die Performance ging naturgemäß zurück und der Storagepool und die Virtual Disks in Windows standen auf Fehler (was auch klar ist), in den Stripesets war alles OK, Daten waren verfügbar.
Ich hab dann, ebenfalls im laufenden Betrieb eine neue VMDK mit gleicher Größe an die VM angefügt und dem Storagepool hinzugefügt,
danach die "fehlerhafte" Festplatte aus dem Pool entfernt und Windows begann eigenständig mit der Reparatur des Storagepools und der gespiegelten Virtual Disks - anschließend alles wieder fehlerfrei, Daten nach wie vor verfügbar.
Performancemäßig bin ich nicht ganz so schnell, wie bei den reinen Stripesets, aber immernoch zwischen 48.000 und 55.000 IOPS.
Was natürlich sein kann ist, dass die Netapp bestimmte Daten cached und dadurch das ergebnis der Benchmarks verfälscht.
Im Endeffekt bekomm ich nur verlässliche Anhaltspunkte, wenn ich mal einen SQL-Server aufsetze,
einen Dump der Datenbank einspiele und vergleichbare Abfragen auf beiden Test-Systemen laufen lasse.
Das wäre demnach auch mein nächster Schritt.
@emeriks
Was hälst Du von dieser Konfig mit dem Storagepool, den gespiegelten Virtualdisks und darüber ein Stripeset?
Wenn es mir eine VMDK zerschiesst, kann ich das so abfangen. Bleibt hald noch das Stripeset selbst als Fehlerquelle...
