4
Clustershared Volume auf anderem Besitzerknoten sehr langsam auf Host
Guten Morgen Gemeinde,
ich komme mit einem mir echt nciht erklärbarem Problem und ich kann eifnach keinen Anhaltspunkt für das Verhalten finden.
Ausgangssituation:
Wir betreiben einen SQl-Server mit einer Datenbank (26TB) virtuell auf Windwos 2012 HyperV und mit SQL-Enterprise.
Für die Bereitstellung der Datenbank nutzen wir das sog. Clustershared Volume, also die Datenträger selbst sind geclustert und können zwischen 4 Benutzerknoten auswählen. Das Cluster Shared Volume liegt auf einer DELL EMC mit reinen SSD Platten im Raid5 Verbund.
Der SQL Server selbst ist nicht (noch nciht) geclustert und liegt immer auf ein und demselben HyperV.
So und jetzt zu meinem eigentlichen Problem, was bei einer Mitarbeiteranzahl von mehr als 400 enorm ätzend für den User ist.
Wenn die virtuellen datenträger alle dem Besitzerknoten zugeordnet sind auf welchem auch der SQL-Server zugehörig ist, habe ich nach mehreren Tests eine Datenrate auf den virtuellen Datenträgern von mehr als 3500MB/s. Das ist recht ordentlich und zufriedenstellend.
Sobald aber, durch welchen Auslöser auch immer sich der Besitzerknoten eines oder mehrerer Laufwerke im Zuge des Clusterings ändert und somit die virtuelle Platte einem anderen Besitzer zugeordnet ist, habe ich auf diesem Datenträger vom SQL-Server aus eine miserable und cniht haltbare Datenrate von gerade mal um die 50 bis 90MB/s.
Damit kommt so gut wie alles auf dem SQL-Server und vor allem für die User zum Erliegen.
Ich kann es mir einfach nicht erklären und weiß nciht woran das liegt.
Habt ihr eventuell ähnliche Erfahrungen oder könnt mich vielleicht mit der Nase drauf stoßen wo ich ggf. was falsch gemacht haben könnte?
Also kurz die Rahmendaten zusammengefasst:
SQL-Server -> alleiniger Besitzer HyperV-5 (nicht geclustert)
Datenträger1 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
Datenträger2 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
Datenträger3 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
Datenträger4 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
Datenträger5 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
.
.
.
In beiliegenden Messergebnissen sehr gut zu veranschaulichen:
Ich krieg hier die volle Breitseite der Kollegen und Mitarbeiter ab.
Es stellt sich für mcih auch die Frage ob ich nciht im laufenden Betreib einfach die Besitzerzuordnung der betroffenen lahmen Datenträger migrieren kann.
Vielen Dank schonmal an alle, die sich damit auseinandersetzen.
LG
ich komme mit einem mir echt nciht erklärbarem Problem und ich kann eifnach keinen Anhaltspunkt für das Verhalten finden.
Ausgangssituation:
Wir betreiben einen SQl-Server mit einer Datenbank (26TB) virtuell auf Windwos 2012 HyperV und mit SQL-Enterprise.
Für die Bereitstellung der Datenbank nutzen wir das sog. Clustershared Volume, also die Datenträger selbst sind geclustert und können zwischen 4 Benutzerknoten auswählen. Das Cluster Shared Volume liegt auf einer DELL EMC mit reinen SSD Platten im Raid5 Verbund.
Der SQL Server selbst ist nicht (noch nciht) geclustert und liegt immer auf ein und demselben HyperV.
So und jetzt zu meinem eigentlichen Problem, was bei einer Mitarbeiteranzahl von mehr als 400 enorm ätzend für den User ist.
Wenn die virtuellen datenträger alle dem Besitzerknoten zugeordnet sind auf welchem auch der SQL-Server zugehörig ist, habe ich nach mehreren Tests eine Datenrate auf den virtuellen Datenträgern von mehr als 3500MB/s. Das ist recht ordentlich und zufriedenstellend.
Sobald aber, durch welchen Auslöser auch immer sich der Besitzerknoten eines oder mehrerer Laufwerke im Zuge des Clusterings ändert und somit die virtuelle Platte einem anderen Besitzer zugeordnet ist, habe ich auf diesem Datenträger vom SQL-Server aus eine miserable und cniht haltbare Datenrate von gerade mal um die 50 bis 90MB/s.
Damit kommt so gut wie alles auf dem SQL-Server und vor allem für die User zum Erliegen.
Ich kann es mir einfach nicht erklären und weiß nciht woran das liegt.
Habt ihr eventuell ähnliche Erfahrungen oder könnt mich vielleicht mit der Nase drauf stoßen wo ich ggf. was falsch gemacht haben könnte?
Also kurz die Rahmendaten zusammengefasst:
SQL-Server -> alleiniger Besitzer HyperV-5 (nicht geclustert)
Datenträger1 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
Datenträger2 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
Datenträger3 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
Datenträger4 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
Datenträger5 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
.
.
.
In beiliegenden Messergebnissen sehr gut zu veranschaulichen:
Ich krieg hier die volle Breitseite der Kollegen und Mitarbeiter ab.
Es stellt sich für mcih auch die Frage ob ich nciht im laufenden Betreib einfach die Besitzerzuordnung der betroffenen lahmen Datenträger migrieren kann.
Vielen Dank schonmal an alle, die sich damit auseinandersetzen.
LG
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: 2098592646
Url: https://administrator.de/contentid/2098592646
Ausgedruckt am: 26.11.2024 um 07:11 Uhr
4 Kommentare
Neuester Kommentar
meine weiteren Forschungen lassen mich vermuten, dass sämtlicher Datentransfer zum Storage beim Wechsel des Besitzers über den Heartbeat läuft und nicht über die FC Karten der Clusterserver.
Also ich vermute, dass der Traffic zum Hosteigner (also da wo der SQL-Server als Maschine liegt) über 1GB die ganzen Daten der angeschlossenen Volumes holt. Aber der Heartbeat sollte ja keinen Traffic erzeugen sondern lediglich prüfen ob die 4 Clusterserver noch ansprechbar sind. Und das sollte meines Erachtens ja via einfachster PINGS ablaufen.
Wenn ich mir die Karte aber anschaue so habe ich permanente Belastung von 950MB/s da drauf.
Also ich vermute, dass der Traffic zum Hosteigner (also da wo der SQL-Server als Maschine liegt) über 1GB die ganzen Daten der angeschlossenen Volumes holt. Aber der Heartbeat sollte ja keinen Traffic erzeugen sondern lediglich prüfen ob die 4 Clusterserver noch ansprechbar sind. Und das sollte meines Erachtens ja via einfachster PINGS ablaufen.
Wenn ich mir die Karte aber anschaue so habe ich permanente Belastung von 950MB/s da drauf.
Zitat von @eb1980:
Für die Bereitstellung der Datenbank nutzen wir das sog. Clustershared Volume, also die Datenträger selbst sind geclustert und können zwischen 4 Benutzerknoten auswählen. Das Cluster Shared Volume liegt auf einer DELL EMC mit reinen SSD Platten im Raid5 Verbund.
Der SQL Server selbst ist nicht (noch nciht) geclustert und liegt immer auf ein und demselben HyperV.
So und jetzt zu meinem eigentlichen Problem, was bei einer Mitarbeiteranzahl von mehr als 400 enorm ätzend für den User ist.
Wenn die virtuellen datenträger alle dem Besitzerknoten zugeordnet sind auf welchem auch der SQL-Server zugehörig ist, habe ich nach mehreren Tests eine Datenrate auf den virtuellen Datenträgern von mehr als 3500MB/s. Das ist recht ordentlich und zufriedenstellend.
Sobald aber, durch welchen Auslöser auch immer sich der Besitzerknoten eines oder mehrerer Laufwerke im Zuge des Clusterings ändert und somit die virtuelle Platte einem anderen Besitzer zugeordnet ist, habe ich auf diesem Datenträger vom SQL-Server aus eine miserable und cniht haltbare Datenrate von gerade mal um die 50 bis 90MB/s.
Der SQL Server selbst ist nicht (noch nciht) geclustert und liegt immer auf ein und demselben HyperV.
So und jetzt zu meinem eigentlichen Problem, was bei einer Mitarbeiteranzahl von mehr als 400 enorm ätzend für den User ist.
Wenn die virtuellen datenträger alle dem Besitzerknoten zugeordnet sind auf welchem auch der SQL-Server zugehörig ist, habe ich nach mehreren Tests eine Datenrate auf den virtuellen Datenträgern von mehr als 3500MB/s. Das ist recht ordentlich und zufriedenstellend.
Sobald aber, durch welchen Auslöser auch immer sich der Besitzerknoten eines oder mehrerer Laufwerke im Zuge des Clusterings ändert und somit die virtuelle Platte einem anderen Besitzer zugeordnet ist, habe ich auf diesem Datenträger vom SQL-Server aus eine miserable und cniht haltbare Datenrate von gerade mal um die 50 bis 90MB/s.
Da ist nicht zufällig ReFS mit im Spiel?
Hi, nein ist reines NTFS
Moin eb1980,
🤔, ich habe da eine Vermutung, poste mal bitte die Ausgabe von
Beste Grüsse aus BaWü
Alex
ich komme mit einem mir echt nciht erklärbarem Problem und ich kann eifnach keinen Anhaltspunkt für das Verhalten finden.
Ausgangssituation:
Wir betreiben einen SQl-Server mit einer Datenbank (26TB) virtuell auf Windwos 2012 HyperV und mit SQL-Enterprise.
Für die Bereitstellung der Datenbank nutzen wir das sog. Clustershared Volume, also die Datenträger selbst sind geclustert und können zwischen 4 Benutzerknoten auswählen. Das Cluster Shared Volume liegt auf einer DELL EMC mit reinen SSD Platten im Raid5 Verbund.
Der SQL Server selbst ist nicht (noch nciht) geclustert und liegt immer auf ein und demselben HyperV.
So und jetzt zu meinem eigentlichen Problem, was bei einer Mitarbeiteranzahl von mehr als 400 enorm ätzend für den User ist.
Wenn die virtuellen datenträger alle dem Besitzerknoten zugeordnet sind auf welchem auch der SQL-Server zugehörig ist, habe ich nach mehreren Tests eine Datenrate auf den virtuellen Datenträgern von mehr als 3500MB/s. Das ist recht ordentlich und zufriedenstellend.
Sobald aber, durch welchen Auslöser auch immer sich der Besitzerknoten eines oder mehrerer Laufwerke im Zuge des Clusterings ändert und somit die virtuelle Platte einem anderen Besitzer zugeordnet ist, habe ich auf diesem Datenträger vom SQL-Server aus eine miserable und cniht haltbare Datenrate von gerade mal um die 50 bis 90MB/s.
Damit kommt so gut wie alles auf dem SQL-Server und vor allem für die User zum Erliegen.
Ich kann es mir einfach nicht erklären und weiß nciht woran das liegt.
Habt ihr eventuell ähnliche Erfahrungen oder könnt mich vielleicht mit der Nase drauf stoßen wo ich ggf. was falsch gemacht haben könnte?
Also kurz die Rahmendaten zusammengefasst:
SQL-Server -> alleiniger Besitzer HyperV-5 (nicht geclustert)
Datenträger1 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
Datenträger2 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
Datenträger3 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
Datenträger4 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
Datenträger5 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
.
.
.
In beiliegenden Messergebnissen sehr gut zu veranschaulichen:
Ich krieg hier die volle Breitseite der Kollegen und Mitarbeiter ab.
Es stellt sich für mcih auch die Frage ob ich nciht im laufenden Betreib einfach die Besitzerzuordnung der betroffenen lahmen Datenträger migrieren kann.
Ausgangssituation:
Wir betreiben einen SQl-Server mit einer Datenbank (26TB) virtuell auf Windwos 2012 HyperV und mit SQL-Enterprise.
Für die Bereitstellung der Datenbank nutzen wir das sog. Clustershared Volume, also die Datenträger selbst sind geclustert und können zwischen 4 Benutzerknoten auswählen. Das Cluster Shared Volume liegt auf einer DELL EMC mit reinen SSD Platten im Raid5 Verbund.
Der SQL Server selbst ist nicht (noch nciht) geclustert und liegt immer auf ein und demselben HyperV.
So und jetzt zu meinem eigentlichen Problem, was bei einer Mitarbeiteranzahl von mehr als 400 enorm ätzend für den User ist.
Wenn die virtuellen datenträger alle dem Besitzerknoten zugeordnet sind auf welchem auch der SQL-Server zugehörig ist, habe ich nach mehreren Tests eine Datenrate auf den virtuellen Datenträgern von mehr als 3500MB/s. Das ist recht ordentlich und zufriedenstellend.
Sobald aber, durch welchen Auslöser auch immer sich der Besitzerknoten eines oder mehrerer Laufwerke im Zuge des Clusterings ändert und somit die virtuelle Platte einem anderen Besitzer zugeordnet ist, habe ich auf diesem Datenträger vom SQL-Server aus eine miserable und cniht haltbare Datenrate von gerade mal um die 50 bis 90MB/s.
Damit kommt so gut wie alles auf dem SQL-Server und vor allem für die User zum Erliegen.
Ich kann es mir einfach nicht erklären und weiß nciht woran das liegt.
Habt ihr eventuell ähnliche Erfahrungen oder könnt mich vielleicht mit der Nase drauf stoßen wo ich ggf. was falsch gemacht haben könnte?
Also kurz die Rahmendaten zusammengefasst:
SQL-Server -> alleiniger Besitzer HyperV-5 (nicht geclustert)
Datenträger1 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
Datenträger2 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
Datenträger3 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
Datenträger4 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
Datenträger5 -> geclustert (Besitzer kann zwischen HyperV-1 bis HyperV-5 wechseln)
.
.
.
In beiliegenden Messergebnissen sehr gut zu veranschaulichen:
Ich krieg hier die volle Breitseite der Kollegen und Mitarbeiter ab.
Es stellt sich für mcih auch die Frage ob ich nciht im laufenden Betreib einfach die Besitzerzuordnung der betroffenen lahmen Datenträger migrieren kann.
🤔, ich habe da eine Vermutung, poste mal bitte die Ausgabe von
Get-ClusterSharedVolumeStateBeste Grüsse aus BaWü
Alex
