Hohe Latzenzen und Fehlermeldungen

[AlexanderMueller]

Hallo,

hoffe ihr könnt helfen.

Kurz zum Netzwerk.
16 Dell R640 Server (Esxi 7.0.2, 18538813 und 6.7.0, 17700523), angeschlossen über 2x16G FC an SanSwitch und diese 4x16GB FC an PureStorage (AllFlash)

Unser problem ist, das Schreib/Lese intensive VMs (FileServer, Exchange und SQL) hohe Latenzen haben auf die Festplatten, teilweise setzen die Lese-/Schreibvorgönge aus, weil diese mehr als 15Sekunden brauchen.

Dazu haben diese Windows Server in den Ereignislogs

-Der E/A-Vorgang an der logischen Blockadresse "0x2ea99d80" für den Datenträger "1" (PDO-Name: \Device\0000002a) wurde wiederholt.
-Ein Zurücksetzen auf Gerät "\Device\RaidPort2" wurde ausgegeben.

teilweise in minuten/Sekunden takt.

Laut auswertung der PureStorage langweilt sich diese und hat schreib und Lese Latenzen von unter 1ms, auch sind die jeweiligen LUNs nicht ausgelastet und die Bandwidth nicht ausgelastet

Unsere SanSwitche Cisco MDS9000Serie wurden schon auf die aktuelle Verion upgedatet und auch die Dell Server haben die aktuellen Firmware bekommen

Zusäztlich sehe ich auf den Exsi Host in der Shell diese Meldungen
2021-10-01T09:47:58.745Z cpu30:2098327)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.624a93703c53e6c19e504d2a00012b60" state in doubt; requested fast path state update...
2021-10-01T09:30:52.841Z cpu16:2098327)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237: NMP device "naa.624a93703c53e6c19e504d2a0009b8e1" state in doubt; requested fast path state update...

Pure sieht bei der Storage keine Probleme oder Fehler
Cisco sieht in den SanSwitchen keine Fehler oder Drops
VmWare hat sich noch nicht gemeldet

Mir gehen die Ideen aus

Grüße und Danke

[Dayworker]

Die LUN mit der "naa.624a93703c53e6c19e504d2a00012b60" hat ein Problem.

Mir ist jetzt nicht klar, weshalb du eine Meldung mit "Gerät "\Device\RaidPort2" im Windows-Server erhältst.

[irix]

Weil die Auswirkungen des Problems auch im GuestOS sichtbar und spuerbar sind.

Gruss
Joerg

[Dayworker]

Trotzdem dürfte im Gast-OS keine Meldung zu einem Raid-Port auftauchen oder werden Raid-Organisationsdaten einfach durchgereicht?

[irix]

Ah.. ich hatte nur \Device\0000002a gelesen. Gute Frage. Aber wuerde ich erstmal ignorieren da vmkernel.log die erste Anlaufstelle ist.

Der OP ist in einer sehr unschoenen Lage. Mein Loesungsansatz ist dann immer der das ich die Anzahl der Variablen minimiere und gucke das ich das Setup vereinfache, sprich nur ein Host mit einer Problem VM auf einer LUN und wenn es das Storage erlaubt direkt Attached.

Der wilde mix von Herstellern ist natuerlich eine Huerde aber nach 13 Jahren in dem Umfeld kann ich sagen selbst wenn alles von einem kommen wuerde ist man vor solchen Problemen nicht 100% gefeit. Das generelle Problem ist das man keinen findet welcher 2 oder mehr der Themengebiete kennt. Gibt zwar durchaus Supportlevel welche das wiederrum minimieren.

Gruss
Joerg

[kastlr]

Hallo zusammen,

such im vobd.log mal nach Performance, da dürftest du Einträge finden, falls die Performance Probleme durch die LUNs verursacht werden.

Dann solltest du mal mit esxtop die Antwortzeiten DAVG deiner LUNS überprüfen und dabei gleich feststellen mit welcher Queue Tiefe ihr arbeitet.
DQLEN gibt an wie groß die Queue ist, ACTV zeigt an wie sie ausgelastet ist.
Der Wert unter ACTV sollte daher immer deutlich unter DQLEN liegen.
Wenn QUED ungleich 0 ist bedeutet dies dass sich die IOs im Host vor dem HBA stauen.

Falls also die Antwortzeiten niedrig sind aber unter QUED ständig ein Wert größer 0 angezeigt wird reicht euer HBA nicht genügend IOs an die LUN durch.

Ein weiterer Punkt ist die Verwendung der vom Array Hersteller empfohlene NMP Policy und ihrer korrekten Parametrisierung.

Nur auf die SAN Switch Stats zu schauen reicht nicht immer aus, da z.B. ein Switch nicht mitbekommt, wenn ein von ihm fehlerfrei gesendetes Packet beim Empfänger fehlerhaft ankommt.
Von daher sollte man noch die HBA Stats überprüfen, ob dort z.B. CRC Fehler oder ähnliches gemeldet werden.

Sofern eine gewisse IO Grundlast vorliegt (so ab 200 IOPS) kann man den Ort des Problems relativ einfach bestimmen.
Bei hohen Antwortzeiten liegt das Problem im SAN, bei niedrigen im Host oder der VM.

Aber meiner persönlichen Erfahrung nach ist das meistens kein Storage sondern ein Design Problem.

Ihr solltet für diese VMs folgendes überprüfen bzw. anpassen,

• Verwendet die VM mindestens einen pvSCSI Controller zur Anbindung der vmdks?
• Wurden die vmdks auf mehrere pvSCSI Controller zur Lastverteilung verteilt?
• Wurde im Windows Disk Management der Write Cache deaktiviert?
• Verwendet Ihr dynamic Disks, um für höhere Performance ein striped Volume über mehrere vmdks aufzubauen?
• Wurde das Filesystem aligned?

Schlechte Werte bei File Copy Aktivitäten mit dem Windows (File) Explorer sind bei shared Storage Systemen keine Seltenheit.
Der Explorer arbeitet nämlich nicht mit outständig IO, sondern sendet immer nur brav einen einzelnen Write ans Array und wartet auf das ACK.
Erst wenn es den vorangegangenen Write bestätigt bekommen hat wird der nächste gesendet.

Beim Kopieren großer Files auf der selben vmdk kommen dann meistens noch unterschiedliche IO Größen für Read & Write IOs zum Tragen.
Wenn ich mich recht erinnere verwendet Windows dann 2 MB Write IOs, diese muss das Array dann in kleinere Häppchen aufteilen.

Gibt also einige Möglichkeiten das Problem anzugehen.

Nur mal aus Neugier, über wieviel IOPS reden wir denn hier pro VM oder LUN?

[AlexanderMueller]

Hallo,

höchst wahrschneinlich haben wir das problem gefunden,
in den Logs konnten wir direkt nix finden, aber in den BIOS einstellungen eines Ports der FC karte haben wir viele CRC Fehler und Timeoute gefunden,
als wir das Kabel des betroffenen Ports gezogen haben, haben die Probleme aufgehört und auch keine Fehlermeldungen mehr.

Entweder liegt es an der Karte,Kabel oder sonst irgendwo.

Nur intressant war, das in den logs keine direkten fehler, nur im Bios der FC karte sichtbar

[aweichenhain]

Moin!

wir haben im Zusammenhang Pure - Qlogic -DELL R640 /R650 ein ähnliches Problem
Bei uns ist es allerdings so, dass wenn wir auf den PURE LUNs QoS bzw. Limits für IOPS und MB/s aktivieren, massenhaft state in doubt FEhler kommen und die Performance der LUNs in den Keller geht. Wenn deaktiviert, dann gibt es keine Probleme.

Bei Hosts mit Emulex Adaptern tritt das Problem nicht auf.
Kabel und Switche haben wir bisher auch ausgeschlossen.

Kurios ist: Das Problem trat EXAKT in dem Moment auf, als auf der Pure die Firmware von 5.3.13 auf 6.1.6 angehoben wurde.

PURE hält sich seit Juni (!) bedeckt und kann das Problem nicht nachstellen, VMware kann zwar die Fehler in den Logs sehen, aber keine wirkliche Ursache wie Treiber oder Firmware der HBAs als Quelle ausmachen und sagt, wir sollen uns nun an DELL wenden.

Das Problem tritt aber nicht nur bei DELL, sondern auch HP auf.
Immer wenn der Host einen Qlogic Adapter hat. Und da auch egal welches Modell, welche Firmware, welcher Treiber und welches ESXi Build auch immer (6.5, 6.7, 7.0 und diverse Zwischenstufen)

[Dayworker]

Wie immer in solchen Fällen stellt sich die Frage, welche FW-Version(en) für welche Treiber-Version(en) freigegeben sind und welche Treiber nachher real im Einsatz sind.
Habt ihr direkt auf die 6.1.6 angehoben oder hattet ihr Zwischenschritte eingelegt?