Hallo zusammen
Wir haben seit etwa einem Jahr Performance Problem in unserem Rechenzentrum und da HP (Hardware Lieferant) und VMware Support uns nicht weiter helfen können wende ich mich an euch in der Hoffnung dem Problem auf die Schliche zu kommen.
Ich gebe mal kurz ein paar Daten zu unserem Setup:
Bladecenter c3000 mit 3 BL460c G1 Blades und OS 5.0 U3 (getestet wurde auch 5.1 U1)
- 12 VM's (Fileserver, Active Directory, Webserver, vCenter, Abacus Tests usw.)
Storage System MSA2024 verbunden über FC Switch und FC Modulen in den Baldes
2 VDISKS
- VDISK 1 = 10x300GB SAS Platten 10k (Produktiv Storage)
- VDISK 2 = 6x500GB SAS Platten 7k (Test Storage)
Falls noch etwas fehlt liefere ich dies gern noch nach. Alle beteiligten Komponenten wurden auf den aktuellsten Stand gebracht (Firmware, Treiber, etc.)
Nun zum Problem. Das Problem ausserst sich in sehr hohen Latenzen zu gewissen Zeiten. Zu jeder Stunde (zwischen 5 und 10 nach) tretten die Latenzen auf und sind dann wieder verschwunden. Man kann dies gut mit ESXTOP beobachten. Die VM's laufen zwar weiter, allerdings werden die Kommandos in den VM's erst nach dem abklingen der Lantenzen ausgeführt. Alles was im Cache des Servers ist wird ausgeführt aber Actionen die Daten vom Storage benötigen werden zurückgestellt.
Auffallend ist auch das Praktisch alle Werte (RAM, CPU, Speicher) zu diesem Zeitpunkt markant ansteigen. Der DAVG Wert ist zu diesem Zeitpunkt zwischen 200 -400 und der VMware Support teilte uns mit das der Storage das Problem seit. HP machte eine Analyse und sagte der Storage sei nicht ausgelastet und nicht das Problem.
Wo könnte das Problem sein das zu dieser Zeit alle VM's/Host dieses Phänomen zeigen? Die VMware Kernel Commands steigen eigentlich nicht über 5, wenn der Fehler auftritt werden die Commands allerdings gequeued weil eine solche Menge auftritt.
Hat jemand eine Idee was wir noch machen können oder wo das Problem liegen könnte?
Vielen Dank für alle Antworten.
Gruss
Rico
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Schlechte Performance virtueller Maschienen
Hallo Dayworker
Danke für die schnelle Antwort. Das dachte ich auch schon. Aufgaben habe ich überprüft, aber zu dem Zeitpunkt sind keine Aktiv. Backup findet nur einmal in der Nacht statt. Das einzigste was mir in den Sinn kommt sind die Definitions Updates vom Kaspersky welche vom Administrationsserver gezogen werden. Das würde aber eine solche Auslastund nicht erklären da die VM's die Updates nicht gleichzeitig ziehen.
Gruss
Rico
Danke für die schnelle Antwort. Das dachte ich auch schon. Aufgaben habe ich überprüft, aber zu dem Zeitpunkt sind keine Aktiv. Backup findet nur einmal in der Nacht statt. Das einzigste was mir in den Sinn kommt sind die Definitions Updates vom Kaspersky welche vom Administrationsserver gezogen werden. Das würde aber eine solche Auslastund nicht erklären da die VM's die Updates nicht gleichzeitig ziehen.
Gruss
Rico
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo Rico,
herzlich willkommen im Forum.
Als Schuß ins Blaue würde ich mal die HP Agenten innerhalb der ESXi Installation deaktivieren.
Deren Tools sammeln ebenfalls in regelmäßigen Abständen Daten der Umgebung ein.
Und es passiert nicht gerade selten, das dabei z.B. SCSI Anfragen an alle SCSI Devices gesendet werden, diese jedoch eigentlich nur für die internen Devices bestimmt sind.
ESXi/ESX 4.1/5.x hpsa driver reports IllegalRequest messages in the VMkernel log
Eventuell kann dein Array nämlich diese Anfragen nicht sauber bearbeiten.
Dann würde ich mal die Error Counter der FC Switche (sowohl der externen als auch die im BladeCenter) zurücksetzen und dann am nächsten Tag mal prüfen, ob die Errorcounter Auffälligkeiten anzeigen.
Falls Ihr 8 GBit in Verbindung mit älteren Brocade Switchen einsetzt solltet Ihr die PortFillword Settings überprüfen.
Eine weitere Option wäre, das extended Logging auf den HBA Treibern zu aktivieren.
Weiterhin könnten folgende Links hilfreich sein.
HP Flex-10 and Flex-Fabric Supportability
March 2014 VMware FW and Software Recipe
Generell solltet Ihr erstmal in den vmkernel Logs nachsehen, was denn überhaupt zu den entsprechenden Zeiten gemeldet wird.
Damit solltet Ihr erst einmal beschäftigt sein.
Viel Erfolg,
Ralf
herzlich willkommen im Forum.
Als Schuß ins Blaue würde ich mal die HP Agenten innerhalb der ESXi Installation deaktivieren.
Deren Tools sammeln ebenfalls in regelmäßigen Abständen Daten der Umgebung ein.
Und es passiert nicht gerade selten, das dabei z.B. SCSI Anfragen an alle SCSI Devices gesendet werden, diese jedoch eigentlich nur für die internen Devices bestimmt sind.
ESXi/ESX 4.1/5.x hpsa driver reports IllegalRequest messages in the VMkernel log
Eventuell kann dein Array nämlich diese Anfragen nicht sauber bearbeiten.
Dann würde ich mal die Error Counter der FC Switche (sowohl der externen als auch die im BladeCenter) zurücksetzen und dann am nächsten Tag mal prüfen, ob die Errorcounter Auffälligkeiten anzeigen.
Falls Ihr 8 GBit in Verbindung mit älteren Brocade Switchen einsetzt solltet Ihr die PortFillword Settings überprüfen.
Eine weitere Option wäre, das extended Logging auf den HBA Treibern zu aktivieren.
Weiterhin könnten folgende Links hilfreich sein.
HP Flex-10 and Flex-Fabric Supportability
March 2014 VMware FW and Software Recipe
Generell solltet Ihr erstmal in den vmkernel Logs nachsehen, was denn überhaupt zu den entsprechenden Zeiten gemeldet wird.
Damit solltet Ihr erst einmal beschäftigt sein.
Viel Erfolg,
Ralf
Hallo Ralf
Danke für deine Ausführungen und Tipps. Am Brocade Switch habe ich den Error Counter einmal zurückgesetzt mit dem Ergebnis das hier keine Fehler angezeigt werden. Da wir nur mit 4 GBit Verbindung fahren kann ich die PortFillword Settings wohl ignorieren. Extended Login werde ich beim nächsten Booten der Server aktivieren da hierfür ein Reboot des Hosts notwendig ist.
Die Log Dateien sagen mir recht wenig. Hab die Logs mal hierhochgeladen.
Gruss
Rico
Danke für deine Ausführungen und Tipps. Am Brocade Switch habe ich den Error Counter einmal zurückgesetzt mit dem Ergebnis das hier keine Fehler angezeigt werden. Da wir nur mit 4 GBit Verbindung fahren kann ich die PortFillword Settings wohl ignorieren. Extended Login werde ich beim nächsten Booten der Server aktivieren da hierfür ein Reboot des Hosts notwendig ist.
Die Log Dateien sagen mir recht wenig. Hab die Logs mal hierhochgeladen.
Gruss
Rico
-
blue_focus
- Member
- Beiträge: 100
- Registriert: 07.11.2011, 15:18
- Wohnort: Salzburg
Ins Blaue geschossen, hätte ich auch mal auf nen Patternstorm vom Antivirus getippt. Bist du dir sicher, dass die nicht alle Gleichzeitig zum Werken anfangen? Unser Symantec macht das nähmlich so, wenn man ihm das nicht explizit verbietet.
Ob das Diskbackend der Storage ordentlich tut lässt sich recht leicht über ein xbeliebiges Benchmarktool ermittlen. AS SSD-Benchmark mag ich recht gerne, da man hier im vergleich zum IO-Meter nichts konfigurieren muss. Die Werte sind nicht für bare Münze zu nehmen, aber man sieht schon mal, ob man es wenigstens schafft den SAN-Bus halbwegs auszunutzen (sequenzielles Schreiben mit großer Blocksize).
Was auch noch sein kann. Wie schaut es sogenannten Quickscans vom AV ausgehend aus. Das machen AVs auch ganz gerne per default Konfig.
Ob das Diskbackend der Storage ordentlich tut lässt sich recht leicht über ein xbeliebiges Benchmarktool ermittlen. AS SSD-Benchmark mag ich recht gerne, da man hier im vergleich zum IO-Meter nichts konfigurieren muss. Die Werte sind nicht für bare Münze zu nehmen, aber man sieht schon mal, ob man es wenigstens schafft den SAN-Bus halbwegs auszunutzen (sequenzielles Schreiben mit großer Blocksize).
Was auch noch sein kann. Wie schaut es sogenannten Quickscans vom AV ausgehend aus. Das machen AVs auch ganz gerne per default Konfig.
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo Rico,
die Logs geben nicht wirklich was her.
Es finden sich zwar zahlreiche Einträge darüber, das sich die IO latency massiv erschlechtert hat, allerdings lassen sich dafür keine Gründe feststellen.
SCSI Fehler finden sich jedenfalls so gut wie keine, und die wenigen Fehler sind auch nicht aussagekräftig.
Ohne einen vm-support wird man wahrscheinlich nicht wirklich was finden können, im Idealfall mit Performance Daten über einen Zeitraum, der das Problem enthält.
Mal ein paar grundsätzliche Fragen.
Hier noch ein paar Artikel, die zu einigen Meldungen in den vmkernel.log passen könnten.
Ralf
die Logs geben nicht wirklich was her.
Es finden sich zwar zahlreiche Einträge darüber, das sich die IO latency massiv erschlechtert hat, allerdings lassen sich dafür keine Gründe feststellen.
SCSI Fehler finden sich jedenfalls so gut wie keine, und die wenigen Fehler sind auch nicht aussagekräftig.
Ohne einen vm-support wird man wahrscheinlich nicht wirklich was finden können, im Idealfall mit Performance Daten über einen Zeitraum, der das Problem enthält.
Mal ein paar grundsätzliche Fragen.
- Wie groß sind die VMFS Datastores, größer als 2TB?
- Wie viele vmdk's liegen denn auf eurem "Produktiv Storage"?
- Welche NMP verwendet Ihr?
- Wie viele Pfade existieren zu dem/den Datastore/s?
- Welche HBA's setzt Ihr mit welcher Queue Depth ein?
- In esxtop, im disk device view, wie sind die Werte für DQLEN, ACTV, QUED, CMDS/s und DAVG wenn das Problem auftritt?
Hier noch ein paar Artikel, die zu einigen Meldungen in den vmkernel.log passen könnten.
- vSphere 5.x hosts are unable to see logical volumes larger than 2TB on some HP RAID controllers
HP Integrated Lights-Out 2 (iLO 2) Featuring iLO Advanced - iLO 2 Becomes Unresponsive After Receiving a Frame with Ethernet Type 0x8874
Ralf
Hallo Ralf
Vielen Dank für deine Hilfe.
Hab hier mal die Antworten zu deinen Fragen:
1. Wie groß sind die VMFS Datastores, größer als 2TB?
Wir haben 2 VMFS Datastores auf der SAN. Beide sind VMFS5 konvertiert. Der Produktiv Datastore ist 3TB gross und der Test Datastore 2TB.
2. Wie viele vmdk's liegen denn auf eurem "Produktiv Storage"?
Mit VMDK's meinst du bestimmt die Anzahl der VM's?! Also es laufen 12 VM's auf dem Storage (RAID5, 11x300GB 10k SAS). Auf dem langsamen Test Storage (RAID5 5x500GB 7k SAS) sind es 4.
3. Welche NMP verwendet Ihr?
Round Robin
4. Wie viele Pfade existieren zu dem/den Datastore/s?
2 Pfade für jeden Host, also 6. Also MSA hat 2 FC Anschlüsse zum FC Switch und von dort je ein FC Kabel pro Host über welchem beide Datastores jeweils gemapped werden.
5.Welche HBA's setzt Ihr mit welcher Queue Depth ein?
Wir haben QLogic QMH2462 4GB FC HBA's. Verwendet wird aber nur ein Port. Queue Depth ist auf 64 im Treiber und im vCenter auf dem Host eingestellt (disk.schednumreqoutstanding).
6. n esxtop, im disk device view, wie sind die Werte für DQLEN, ACTV, QUED, CMDS/s und DAVG wenn das Problem auftritt?
Ist wohl besser wenn ich ein Foto hoch lade. Hiersiehst du die Auslastung.
Das sind die Ansichten von allen 3 Hosts. Zu Spitzenzeiten werden die Anfragen sogar in die QUED verlagert weil es derart viele sind. Im Leistungsdiagramm sieht man zudem das alle Werte sich markant erhöhen (CPU, RAM, HDD)
CMD's sind verhältnismässig wenige vorhanden. Komisch ist auch das der MBRE und MBWR Wert nicht wirklich hoch ist.
Habe noch einen Test mit VMware I/O Analyser gemacht und hier erreiche ich wesentlich höhere IOPS und MBRE und MBWR Werte und habe keine Latenzen.
Kann man irgendwie analysieren wo die hohen ACTV Anfragen zu dem Zeitpunkt her kommen?
Gruss
Rico
Vielen Dank für deine Hilfe.
Hab hier mal die Antworten zu deinen Fragen:
1. Wie groß sind die VMFS Datastores, größer als 2TB?
Wir haben 2 VMFS Datastores auf der SAN. Beide sind VMFS5 konvertiert. Der Produktiv Datastore ist 3TB gross und der Test Datastore 2TB.
2. Wie viele vmdk's liegen denn auf eurem "Produktiv Storage"?
Mit VMDK's meinst du bestimmt die Anzahl der VM's?! Also es laufen 12 VM's auf dem Storage (RAID5, 11x300GB 10k SAS). Auf dem langsamen Test Storage (RAID5 5x500GB 7k SAS) sind es 4.
3. Welche NMP verwendet Ihr?
Round Robin
4. Wie viele Pfade existieren zu dem/den Datastore/s?
2 Pfade für jeden Host, also 6. Also MSA hat 2 FC Anschlüsse zum FC Switch und von dort je ein FC Kabel pro Host über welchem beide Datastores jeweils gemapped werden.
5.Welche HBA's setzt Ihr mit welcher Queue Depth ein?
Wir haben QLogic QMH2462 4GB FC HBA's. Verwendet wird aber nur ein Port. Queue Depth ist auf 64 im Treiber und im vCenter auf dem Host eingestellt (disk.schednumreqoutstanding).
6. n esxtop, im disk device view, wie sind die Werte für DQLEN, ACTV, QUED, CMDS/s und DAVG wenn das Problem auftritt?
Ist wohl besser wenn ich ein Foto hoch lade. Hiersiehst du die Auslastung.
Das sind die Ansichten von allen 3 Hosts. Zu Spitzenzeiten werden die Anfragen sogar in die QUED verlagert weil es derart viele sind. Im Leistungsdiagramm sieht man zudem das alle Werte sich markant erhöhen (CPU, RAM, HDD)
CMD's sind verhältnismässig wenige vorhanden. Komisch ist auch das der MBRE und MBWR Wert nicht wirklich hoch ist.
Habe noch einen Test mit VMware I/O Analyser gemacht und hier erreiche ich wesentlich höhere IOPS und MBRE und MBWR Werte und habe keine Latenzen.
Kann man irgendwie analysieren wo die hohen ACTV Anfragen zu dem Zeitpunkt her kommen?
Gruss
Rico
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo Rico,
Ich kenne die HP MSA2024 nicht und kann Sie auch nicht in der Liste der von VMware supporteten Arrays finden, aber das mal nur am Rande.
VMware Compatibility Guide -Storage/SAN-
Laut deinen Screenshoots ist auf beiden LUN's nicht wirklich was los, allerdings kann ich nicht beurteilen, ob die Screenshots zeitgleich von allen drei ESXi Server erstellt wurden oder nicht.
Die HBA Queue ist auf den Screenshots auch nie vollständig verwendet, es könnten also durchaus noch mehr IO's zeitgleich zum Array gesendet werden.
Laut deiner Aussage erfolgt das ja auch zu Spitzenzeiten, und genau dafür ist eine Queue dann auch da.
Solange sie nicht regelmäßig volläuft (größer 50%) ist das kein Problem.
Ob das Array diese dann entsprechend bedienen könnte steht aber auf einem anderem Blatt.
Was allerdings auffällt ist das der Write Anteil in deinen Screenshots fast immer deutlich höher ist als der Read Anteil.
Je nach Array Konfiguration (Cache, RAID Protection) kann eine hohe Anzahl kleiner Writes ein echtes Problem werden.
Zwar landen die üblicherweise im Cache und werden daher eigentlich extrem schnell bedient, aber das scheint in eurem Fall nicht zuzutreffen.
Kann daran liegen, das eure Cache z.B. 32 oder 64 kB Blöcke bereitstellt, aber kleinere IO's belegen halt trotzdem immer einen Cache Slot.
Somit ist auch ein großer Cache eventuell ganz schnell aus dem Spiel.
Viele kleine IO's erklären auch die niedrigen Transferraten, denn es müssen halt verhältnismäßig wenige Daten transferiert werden.
Du kannst dir die Verursacher der IO's auch in esxtop anzeigen lassen, wechsel einfach in den virtual Disk View.
Und da wirst du dann auch die Anzahl der vmdks sehen können, denn meine Frage bezog sich eben nicht auf die Anzahl der VM's.
Die hattest du ja schon in deinem erstem Thread beantwortet.
Gruß,
Ralf
Ich kenne die HP MSA2024 nicht und kann Sie auch nicht in der Liste der von VMware supporteten Arrays finden, aber das mal nur am Rande.
VMware Compatibility Guide -Storage/SAN-
Laut deinen Screenshoots ist auf beiden LUN's nicht wirklich was los, allerdings kann ich nicht beurteilen, ob die Screenshots zeitgleich von allen drei ESXi Server erstellt wurden oder nicht.
Die HBA Queue ist auf den Screenshots auch nie vollständig verwendet, es könnten also durchaus noch mehr IO's zeitgleich zum Array gesendet werden.
Laut deiner Aussage erfolgt das ja auch zu Spitzenzeiten, und genau dafür ist eine Queue dann auch da.
Solange sie nicht regelmäßig volläuft (größer 50%) ist das kein Problem.
Ob das Array diese dann entsprechend bedienen könnte steht aber auf einem anderem Blatt.
Was allerdings auffällt ist das der Write Anteil in deinen Screenshots fast immer deutlich höher ist als der Read Anteil.
Je nach Array Konfiguration (Cache, RAID Protection) kann eine hohe Anzahl kleiner Writes ein echtes Problem werden.
Zwar landen die üblicherweise im Cache und werden daher eigentlich extrem schnell bedient, aber das scheint in eurem Fall nicht zuzutreffen.
Kann daran liegen, das eure Cache z.B. 32 oder 64 kB Blöcke bereitstellt, aber kleinere IO's belegen halt trotzdem immer einen Cache Slot.
Somit ist auch ein großer Cache eventuell ganz schnell aus dem Spiel.
Viele kleine IO's erklären auch die niedrigen Transferraten, denn es müssen halt verhältnismäßig wenige Daten transferiert werden.
Du kannst dir die Verursacher der IO's auch in esxtop anzeigen lassen, wechsel einfach in den virtual Disk View.
Und da wirst du dann auch die Anzahl der vmdks sehen können, denn meine Frage bezog sich eben nicht auf die Anzahl der VM's.
Die hattest du ja schon in deinem erstem Thread beantwortet.
Gruß,
Ralf
Hallo Ralf
Also MSA2024 ist das Chassis. Es müsste natürlich MSA2324fc heissen. Das ist der Controller und der ist in der VMware supporteten Array Liste zu finden.
Hier noch die Anzahl der VMDK's: 21
Die Blockgrösse auf dem Storage ist auf 64k eingestellt und Cache Einstellung Write Back.
Gruss
Rico
Also MSA2024 ist das Chassis. Es müsste natürlich MSA2324fc heissen. Das ist der Controller und der ist in der VMware supporteten Array Liste zu finden.
Hier noch die Anzahl der VMDK's: 21
Die Blockgrösse auf dem Storage ist auf 64k eingestellt und Cache Einstellung Write Back.
Gruss
Rico
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo Rico,
jetzt muss ich doch mal nachfragen.
Wenn du mit IO Meter testest hast du sicherlich ganz andere Werte, aber dabei tritt das Problem wirklich nicht auf?
Wie haben sich denn die 12 VM's während eurer IO Meter Tests verhalten, waren die durch die zusätzliche Last beeinträchtigt?
Wie genau äußert sich denn euer Problem, sind die 12 VM's in diesen Zeiten extrem langsam oder sind nur diese Meldungen in den Logs?
Gruß,
Ralf
jetzt muss ich doch mal nachfragen.
Wenn du mit IO Meter testest hast du sicherlich ganz andere Werte, aber dabei tritt das Problem wirklich nicht auf?
Wie haben sich denn die 12 VM's während eurer IO Meter Tests verhalten, waren die durch die zusätzliche Last beeinträchtigt?
Wie genau äußert sich denn euer Problem, sind die 12 VM's in diesen Zeiten extrem langsam oder sind nur diese Meldungen in den Logs?
Gruß,
Ralf
Hallo Ralf
Genau, die Werte die ich mit dem IO Analyser erreiche sind bei weitem höher. Ich stelle beim durchführen der Tests auch keine Latenz fest. Alles läuft normal ohne Probleme.
Wenn das Problem auftritt, ist es in allen VM's spürbar. Anmeldevorgänge sind währenddessen nicht möglich (bis zu 5min), wenn man angemeldet ist und auf dem Server arbeitet sind auf einmal keine Aktionen welche auf den Storage zugreifen mehr möglich. Das Öffnen des Arbeitsplatzes dauert allein schon 3 min (jeder Klick eine Minute). Funktionen welche einmal in den Cache des Servers geladen wurden gehen etwas zügiger.
Gruss
Rico
Genau, die Werte die ich mit dem IO Analyser erreiche sind bei weitem höher. Ich stelle beim durchführen der Tests auch keine Latenz fest. Alles läuft normal ohne Probleme.
Wenn das Problem auftritt, ist es in allen VM's spürbar. Anmeldevorgänge sind währenddessen nicht möglich (bis zu 5min), wenn man angemeldet ist und auf dem Server arbeitet sind auf einmal keine Aktionen welche auf den Storage zugreifen mehr möglich. Das Öffnen des Arbeitsplatzes dauert allein schon 3 min (jeder Klick eine Minute). Funktionen welche einmal in den Cache des Servers geladen wurden gehen etwas zügiger.
Gruss
Rico
Sind hier zu viele SCSI reservation denkbar?
http://kb.vmware.com/selfservice/micros ... Id=1002293
Stecke da nicht so drin, aber dazu folgenden Denkanstoss:
Nur 2 Lun (Vidsk), sprich je Controller 1 Lun (Dual Controller angenommen). Auf der einen (Produktiv)Lun laufen alle I/Os.
Edit: Wieviel Volumes sind denn auf der Prod-Vdisk?
Bei Raid-5 kann da ein größerer Schreibprozess alles nach unten ziehen, damit merkst du das dann halt auch in allen VM's.
Lässt die höhere I/O Last nicht einer/meheren VM zuordnen über das Vcenter? Dein Bild von Dir zeigt ja nur die LUN und nicht die VM(s), die den Traffic generiert.
Bei nur 2 LUN's ist das wenig zielführend.
http://kb.vmware.com/selfservice/micros ... Id=1002293
Stecke da nicht so drin, aber dazu folgenden Denkanstoss:
Nur 2 Lun (Vidsk), sprich je Controller 1 Lun (Dual Controller angenommen). Auf der einen (Produktiv)Lun laufen alle I/Os.
Edit: Wieviel Volumes sind denn auf der Prod-Vdisk?
Bei Raid-5 kann da ein größerer Schreibprozess alles nach unten ziehen, damit merkst du das dann halt auch in allen VM's.
Lässt die höhere I/O Last nicht einer/meheren VM zuordnen über das Vcenter? Dein Bild von Dir zeigt ja nur die LUN und nicht die VM(s), die den Traffic generiert.
Bei nur 2 LUN's ist das wenig zielführend.
Ich will den Thread nicht entführen, aber ich habe gerade auch meine liebe Mühe reale Probleme im Storage Bereich mit Iometer nachzustellen.
Bei uns ist es ein Konstrukt aus 2 HP EVAs die über eine EMC VPLEX den Speicher als sync. Spiegel zur Verfügung stellen. Im Tagesbetrieb treten immer wieder Latenzen >30ms auf. Recht einfach nachvollziehen kann ich es über ein Installation einer W2K8 VM, bei uns wird dies über das MS WDT durchgeführt wird. Dabei werden Daten vom Deployment Server auf die Ziel VM kopiert. Das dauert in den meisten Clustern nur 2 Min, in dem EVA/VPLEX Cluster ~10Min. mit max. 200 write IOPS. Vergleiche ich unterschiedliche Iometer Tests (Max Write IOPS, Max seq IO, real world) zwischen EVA mit und ohne VPLEX sind die Ergebnisse praktisch identisch. Teste ich ein Installation, sieht man sofort einen Unterschied von Faktor 4-5 (gleiche VM, gleiche Netzanbindung, nur anderes DS).
Ich kann nicht nachvollziehen welches IO Pattern für diese Unterschiede sorgt.
Bei uns ist es ein Konstrukt aus 2 HP EVAs die über eine EMC VPLEX den Speicher als sync. Spiegel zur Verfügung stellen. Im Tagesbetrieb treten immer wieder Latenzen >30ms auf. Recht einfach nachvollziehen kann ich es über ein Installation einer W2K8 VM, bei uns wird dies über das MS WDT durchgeführt wird. Dabei werden Daten vom Deployment Server auf die Ziel VM kopiert. Das dauert in den meisten Clustern nur 2 Min, in dem EVA/VPLEX Cluster ~10Min. mit max. 200 write IOPS. Vergleiche ich unterschiedliche Iometer Tests (Max Write IOPS, Max seq IO, real world) zwischen EVA mit und ohne VPLEX sind die Ergebnisse praktisch identisch. Teste ich ein Installation, sieht man sofort einen Unterschied von Faktor 4-5 (gleiche VM, gleiche Netzanbindung, nur anderes DS).
Ich kann nicht nachvollziehen welches IO Pattern für diese Unterschiede sorgt.
S0ftt€ch hat geschrieben:Hallo Stefan
Also es sind 2 Lun auf der MSA mit je einem Volume. Lun 1 hat das Produktive Volume und Lun 2 das Test Volume. Beide Volume sind über einen Controller verbunden (haben keine Dual Controller Config).
Gruss
Rico
Also verteilt sich die Last beider Vdisk und nach deiner Aussage in Summe 2 Volumes auf einen Controller? Unglücklich. Wieso nur 1 Controller?
Da heißt aber auch, schauen, was in den Zeiten auf den Testsystem in den Problem-Zeiten gemacht wird.
Ich kann nich sagen, wie der Controller mit 2 R5 parallel skaliert, aber wenn das R5 auf den 7.2K Platten am arbeiten ist, müssen dieso I/Os ja erst mal abgearbeitet worden sein.
Und die vielen Pfade nützen so leider auch nix, da sich alle 3 Blades bei dem Controller anmelden, ihre I/Os abzuarbeiten.
Eine richtige Lastverteilung kann da nur begrenzt stattfinden.
Ebenso spricht wohl noch mehr für die SCSI Reservation Problematik meiner Meinnung nach.
Aber da gibt es sicher besser HP Spezis als mich . (hab ja auch nur Dell im Einsatz
)-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo Rico,
also fassen wir mal zusammen.
Punkt 1 bestätigt die Aussage des HP Supports, dass sich das Array eigentlich langweilt.
Aber trotzdem sind da die Hinweise auf hohe Latenzen.
Setzt Ihr vielleicht
Falls ja, würde ich das zumindest temporär mal deaktivieren, um festzustellen, ob sich das Verhalten ändert.
Gleiches gilt für disk.schednumreqoutstanding, das kann auch Auswirkungen auf des Problem haben.
Ansonsten würde ich mal von allen drei ESXi Servern ein vm-support inklusive Performance Daten ziehen.
Collecting performance data for ESXi5.x hosts via the vSphere client
Natürlich sollte das dann einen Zeitraum abdecken, in der das Problem aufgetreten ist.
Deshalb wirst du wohl die Collection Duration anpassen müssen, dafür brauchst du die vCenter und Client Information nicht zu sammeln.
Allerdings können die Files ziemlich groß werden, also solltest du darauf achten, das dein Ziellaufwerk über ausreichend frei Diskkapazität verfügt.
Gruß,
Ralf
also fassen wir mal zusammen.
- IO Meter Tests zeigen, dass das Array durchaus eine deutlich höhere Last mit geringer Latenz bedienen kann
- wenn das Problem zuschlägt, betrifft es alle VM's auf dem produktivem Storage, egal auf welchem ESXi Server sie gerade betrieben werden
- wenn das Problem auftritt, seht Ihr hohe Latenzen für die IO's und die HBA Queue läuft voll
Punkt 1 bestätigt die Aussage des HP Supports, dass sich das Array eigentlich langweilt.
Aber trotzdem sind da die Hinweise auf hohe Latenzen.
Setzt Ihr vielleicht
- VAAI
- SIOC
- Shares & Reservations oder ähnliches
Falls ja, würde ich das zumindest temporär mal deaktivieren, um festzustellen, ob sich das Verhalten ändert.
Gleiches gilt für disk.schednumreqoutstanding, das kann auch Auswirkungen auf des Problem haben.
Ansonsten würde ich mal von allen drei ESXi Servern ein vm-support inklusive Performance Daten ziehen.
Collecting performance data for ESXi5.x hosts via the vSphere client
Natürlich sollte das dann einen Zeitraum abdecken, in der das Problem aufgetreten ist.
Deshalb wirst du wohl die Collection Duration anpassen müssen, dafür brauchst du die vCenter und Client Information nicht zu sammeln.
Allerdings können die Files ziemlich groß werden, also solltest du darauf achten, das dein Ziellaufwerk über ausreichend frei Diskkapazität verfügt.
Gruß,
Ralf
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo pirx,
meiner Meinung nach ist es sinnvoll, dafür enen neuen Thread zu öffnen.
VPLEX erhöht die Sicherheit, und Sicherheit kostet immer Performance.
Schließlich müssen Writes von der VPLEX an zwei Arrays gesendet werden und erst wenn beide den IO bestätigt haben, erhält der Host sein Acknowledge.
Nichts wird daduch schneller das man es zweimal macht.
Dann kann das SAN Design ebenfalls von Bedeutung sein, setzt Ihr z.B. Cross Site Zoning ein oder nicht.
Wie hoch ist die Distanz zwischen den beiden Standorten?
Welche VMware NMP setzt ihr ein?
Verwendet Ihr Affinity Rules, so das alle VM's auf einem distributed Volume bevorzugt innerhalb eines Standortes betrieben werden?
Aus meiner Sicht viel zu viele Fragen und Möglichkeiten, um diese in einem fremden Thread zu behandeln.
Gruß,
Ralf
meiner Meinung nach ist es sinnvoll, dafür enen neuen Thread zu öffnen.
VPLEX erhöht die Sicherheit, und Sicherheit kostet immer Performance.
Schließlich müssen Writes von der VPLEX an zwei Arrays gesendet werden und erst wenn beide den IO bestätigt haben, erhält der Host sein Acknowledge.
Nichts wird daduch schneller das man es zweimal macht.
Dann kann das SAN Design ebenfalls von Bedeutung sein, setzt Ihr z.B. Cross Site Zoning ein oder nicht.
Wie hoch ist die Distanz zwischen den beiden Standorten?
Welche VMware NMP setzt ihr ein?
Verwendet Ihr Affinity Rules, so das alle VM's auf einem distributed Volume bevorzugt innerhalb eines Standortes betrieben werden?
Aus meiner Sicht viel zu viele Fragen und Möglichkeiten, um diese in einem fremden Thread zu behandeln.
Gruß,
Ralf
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo pirx,
du kannst ja die VM bei der Windows Installation mal mit vscsiStats überwachen lassen.
Das Tool sammelt alle möglichen Informationen bezüglich
Diese Informationen kannst du dann für deine IO Meter Tests verwenden.
Gruß,
Ralf
du kannst ja die VM bei der Windows Installation mal mit vscsiStats überwachen lassen.
Das Tool sammelt alle möglichen Informationen bezüglich
- IO Anzahl
- Anzahl Read IO's
- Anzahl Write IO's
- IO Size
- Random or Sequentiell IO's
- usw
Diese Informationen kannst du dann für deine IO Meter Tests verwenden.
Gruß,
Ralf
Hallo @all
Wir haben letzte Woche noch einige Analysen an den Systemen durchgeführt. Wir konnten dabei feststellen, dass das verwendete AntiVirus (Kaspersky Anti Virus 8 für Server) die hohen Latenzen verursacht.
Danke @blue_focus
Zu dem Zeitpunkt wo der Fehler auftritt aktualisiert der AntiVirus die Datenbanken (parallel auf 7-8 VM's). Zudem ist noch ein Fehler im AntiVirus vorhanden welchen wir noch beheben müssen (der AntiVirus ignoriert die Einstellungen vom Kaspersky Management Server).
Für uns stellen sich nun noch folgende Fragen: Wie können wir diesen Engpass verhindern? Haben wir einen Fehler im Design? Wie können wir die Kennzahlen ermitteln wann unserer Storage System an die Auslastungsgrenze gelangt?
Hast du vielleicht ein paar Tipps dazu wie wir dies Berechnen oder Analysieren können?
Gruss
Rico
Wir haben letzte Woche noch einige Analysen an den Systemen durchgeführt. Wir konnten dabei feststellen, dass das verwendete AntiVirus (Kaspersky Anti Virus 8 für Server) die hohen Latenzen verursacht.
Danke @blue_focus
Zu dem Zeitpunkt wo der Fehler auftritt aktualisiert der AntiVirus die Datenbanken (parallel auf 7-8 VM's). Zudem ist noch ein Fehler im AntiVirus vorhanden welchen wir noch beheben müssen (der AntiVirus ignoriert die Einstellungen vom Kaspersky Management Server).
Für uns stellen sich nun noch folgende Fragen: Wie können wir diesen Engpass verhindern? Haben wir einen Fehler im Design? Wie können wir die Kennzahlen ermitteln wann unserer Storage System an die Auslastungsgrenze gelangt?
Hast du vielleicht ein paar Tipps dazu wie wir dies Berechnen oder Analysieren können?
Gruss
Rico
-
Dayworker
- King of the Hill
- Beiträge: 13657
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Dieses Problem haben wir recht einfach gelöst und den Hersteller gewechselt. Wir hatten damit öfter mal BSODs auf den Clients oder die Signatur-Updates scheiterten ohne ersichtlichen Grund.S0ftt€ch hat geschrieben:Zudem ist noch ein Fehler im AntiVirus vorhanden welchen wir noch beheben müssen (der AntiVirus ignoriert die Einstellungen vom Kaspersky Management Server).
Der Kaspersky (und das Backup) ist glaub nur die Spitze des Problems. Ich habe mal noch vCops installiert und wenn ich mir diese Grafik anschaue, dann liegt das Problem eher bei den Einstellungen des Controllers/Volumes.
Gruss
Rico
Gruss
Rico
-
Dayworker
- King of the Hill
- Beiträge: 13657
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Hmm. Wenn ihr kein Blade samt Storage hättet, würde aufgrund das beim Lesen im Gegensatz zum Schreiben sowohl IO- als auch Durchsatz-technisch kaum Auslastung erreicht wird, entweder der BBU-Cache (so er denn konfigurierbar ist und sich das Cache-Verhältnis zwischen Lesen und Schreiben beeinflussen läßt) ungünstig eingestellt sein oder der BBU-Cache ist aufgrund zu schwacher BBU-Kapazität überhaupt nicht mehr aktiv. Aber wie gesagt, du hast ja ein Blade samt Storage.
Was ist mit den für "kastlr" zu sammelnden Informationen?
Was ist mit den für "kastlr" zu sammelnden Informationen?
Zurück zu „vSphere 5 / ESXi 5 und 5.1“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 16 Gäste