Storagefehler im VMkernel

[m.mart1n]

Hallo zusammen,

wir hatten letzte Nacht das zweite mal diese Woche einen Produktionsausfall weil sich alle 3 Hosts eines Clusters verabschiedet haben. Ich habe zwar beim VMware Support angefragt aber die Tippen eher auf den Storage.

Jetzt wollte ich euch mal Fragen ob jemand derartige Fehlermeldungen bekannt sind?

LUN 0
2013-04-16T07:12:18.676Z cpu8:2056)NMP: nmp_ThrottleLogForDevice:2318: Cmd 0x28 (0x41244037c0c0, 6410) to dev "naa.60080e500024cd74000002594ee90f55" on path "vmhba1:C0:T0:L0" Failed: H:0x2 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0. Act:EVAL
2013-04-16T07:12:18.677Z cpu8:2056)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237:NMP device "naa.60080e500024cd74000002594ee90f55" state in doubt; requested fast path state update...
2013-04-16T07:12:18.677Z cpu8:2056)ScsiDeviceIO: 2309: Cmd(0x41244037c0c0) 0x28, CmdSN 0x80000079 from world 6410 to dev "naa.60080e500024cd74000002594ee90f55" failed H:0x2 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0.

LUN 2
2013-04-16T06:58:31.253Z cpu4:2052)NMP: nmp_ThrottleLogForDevice:2318: Cmd 0x28 (0x4124003b9a80, 6451) to dev "naa.60080e500024cd740000025c4ee90f7d" on path "vmhba1:C0:T
0:L2" Failed: H:0x2 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0. Act:EVAL
2013-04-16T06:58:31.253Z cpu4:2052)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237:NMP device "naa.60080e500024cd740000025c4ee90f7d" state in doubt; requested fast path state update...
2013-04-16T06:58:31.253Z cpu4:2052)ScsiDeviceIO: 2309: Cmd(0x4124003b9a80) 0x28, CmdSN 0x80000038 from world 6451 to dev "naa.60080e500024cd740000025c4ee90f7d" failed H:
0x2 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0.
2013-04-16T06:58:31.954Z cpu7:2055)WARNING: NMP: nmp_DeviceRequestFastDeviceProbe:237:NMP device "naa.60080e500024cd740000025c4ee90f7d" state in doubt; requested fast path state update...
2013-04-16T06:58:31.954Z cpu7:2055)ScsiDeviceIO: 2309: Cmd(0x4124011293c0) 0x28, CmdSN 0x800000eb from world 6451 to dev "naa.60080e500024cd740000025c4ee90f7d" failed H:0x2 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0.


Ich weiß langsam nicht mehr weiter

Viele Grüße
Martin

[Dayworker]

Was hast du für ein Storage?
Worüber ist es angebunden?

[m.mart1n]

Es ist eine IBM DS3512 die über FC angebunden ist. Vor zwei Wochen haben wir eine Erweiterung angeschlossen und seit dem gibt es massig probleme.

[m.mart1n]

Das Problem für mich ist momentan einfach das ich nicht weiß ob es jetzt ein Fehler von VMware ist (evtl. Fehlkonfiguration meinerseits) oder ob bei dem Storage irgendwas defekt ist oder ob beim Zoning irgendwas nicht stimmen kann.

[bla!zilla]

Du hast ein Problem mit deinem Storagesystem, nicht mit der VMware Umgebung. Die NAA ID repräsentiert eine LUN. Möglicherweise ist nur eine LUN betroffen.

Wie haben sich deine ESXer "verabschiedet"? Hingen die, waren nicht mehr managebar? Welche Version von vSphere setzt ihr ein?

[stahly]

Ich vermute auch, dass es an der neuen LUN liegt. Falsche ID vergeben??

Kannst Du diese LUN wieder abhängen?

[m.mart1n]

Hallo,

vor zwei Tagen war es so das ich einen ESX auf der Console nicht mehr bedienen konnte. Heißt ich kommt F2 drücken um das root Passwort einzugeben aber dann war keine Eingabe mehr möglich. Lediglich die Logs konnte ich mir mit ALT Fx anzeigen lassen aber das Passwort ließ sich nicht eingeben.

Heute Nacht war es der Fall das 2 Hosts nicht mehr pingbar waren. Der dritte war auch kurz offline im VCenter hat sich aber dann wieder automatisch verbunden. Der erste war gleich nach dem reboot wieder da und der zweite war auch nicht verbunden nach dem reboot. Lies sich auch erst nicht mit Rechtsklick auf den Host nicht verbinden. Zwei Stunden später ging es dann.

[bla!zilla]

LUN Missmatch würde anders aussehen. Evtl. zickt die Backendverkabelung des neuen Enclosures. In jedem Fall ein Fall für den IBM Support.

Was wurde konkret gemacht?

[m.mart1n]

Ich vermute auch, dass es an der neuen LUN liegt. Falsche ID vergeben??

Kannst Du diese LUN wieder abhängen?

Die neuen LUNs werden den ESX aber nicht präsentiert. Die sind ausschließlich für ein Linux Cluster was daneben steht aber nichts mit dem VMware Cluster zu tun hat. Heißt die Hosts sehen die neuen LUNs nicht.

[m.mart1n]

Ich habe mal schnell zwei Bilder gemalt um es zu verdeutlichen:

Alte Umgebung:



Neue Umgebung:



Geändert wurden folgende Sachen:

Raum 1 ( 3 Hosts )

- Upgrade von ESX4 auf ESXi 5.0 U1 (mehr wird nicht supportet von Backup Exec)

Raum 2 ( 2 Hosts )

- ESX wurde entfernt und ein Oracle Linux installiert
- diese beiden Server haben Zugriff auf LUN 4,5,6

VMware greift auf LUN 1,2,3 zu und diese sind gespiegelt.

Vielleicht hilft es ja irgendwie weiter...

[bla!zilla]

Hol dir den IBM Support ran. Die sollen sich die DS ansehen. Ich tippe da auf ein Problem.

Wenn nur das zusätzliche Enclosure hinzugekommen ist, dann muss es etwas damit zu tun haben. Habt ihr großartig was am Zoning geändert? Wie zont ihr?

[m.mart1n]

Zoning ist leider nicht so sehr mein Thema.

Geändert wurde das die beiden ESX aus dem zweiten Raum nicht mehr auf die ersten 3 LUNs zugreifen können aber dafür auf die 3 neuen LUNs von der EXP. Natürlich auf mehreren Switchen da ja alles redundant ausgelegt ist und einige LUNs gespiegelt sind. Das war es aber dann auch schon.

[bla!zilla]

Wer hat das denn eingerichtet?

[m.mart1n]

Wir arbeiten in solchen Sachen mit einem der größten Systemhäuser zusammen von denen man eigentlich denken sollte sie wissen was sie tun.

Ich selber hab "erst" 6 Monate Erfahrung mit Virtualisierung usw.. daher trau ich mich gar nicht so tiefgreifende Änderungen zu machen aber steh natürlich relativ schnell auf dem Schlauch wenn irgendwas ist

[stahly]

Call bei IBM eröffnet?

[m.mart1n]

Jap ist offen. Hab auch gleich mit eine Data Collection vom Storage mitgeschickt. Diese ist laut IBM in Ordnung und kein Fehler drin.

Mit den Fehlern konnte der Mitarbeiter erstmal nichts anfangen und musste sie an einen anderen Kollegen weiterleiten.

Seither warte ich auf Rückruf...

[Martin]

Soweit mir bekannt ist die DS3500 als FC direct attached garnicht supported?

[m.mart1n]

Jetzt versetz mich nicht in schrecken

Sie wird schon unterstüzt, einfach ds3500 eingeben:

http://www.vmware.com/resources/compati ... tegory=san

[Martin]

Da steht unter "Test Configuration" aber auch nur "FC Switch"

[m.mart1n]

???

Was soll das bedeuten?

[m.mart1n]

Sorry, jetzt weiß ich was ihr meint.

Meine "Zeichnung" ist dahingehend nicht ganz vollständig. Es sind schon in jedem Raum 2 FC Switche vorhanden, also ins Gesamt 4 Stück für die beiden Räume.

Der Storage ist nicht direkt angebunden.

Daher sollte es kein Problem sein, oder?

[Martin]

Dann sieht das ganze wieder von der SAN Struktur her "ganz normal" und supported aus

[m.mart1n]

So, nächste Aussage von VMware:

Sehr geehrter Mauksch,

wie soeben besprochen die Auswertung der Log Files:

Unser Host versucht auf den Bus zu schreiben und bekommt Busy Meldungen zurueck, sprich der Bus ist belegt sodass der Host den Storage nicht erreichen kann.

# The error message "Cmd xxx to dev xxx Failed" has been reported 123 times within that period. Manual check for time stamps is encouraged!
# The following LUNs were reported in combination with above SCSI error codes, sorted by vmhba, first column counts the amount of errors
naa.60080e500024c9fc000002584ee90fb5
1 vmhba1:C0:T0:L1 H:0x2 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0 --> Act:EVAL
naa.60080e500024cd74000002594ee90f55
1 vmhba1:C0:T0:L0 H:0x2 D:0x0 P:0x0 Possible sense data: 0x5 0x25 0x0 --> Act:EVAL
64 vmhba1:C0:T0:L0 H:0x2 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0 --> Act:EVAL
naa.60080e500024cd740000025c4ee90f7d
57 vmhba1:C0:T0:L2 H:0x2 D:0x0 P:0x0 Possible sense data: 0x0 0x0 0x0 --> Act:EVAL
# The SCSI error codes in the vmkernel logs have been observed during 4/4 different days (display max 10), sort by amount
Date Amount
------ ------
2013-04-15 97
2013-04-16 169
2013-04-14 343
2013-04-13 378

# The following SCSI commands were reported to have failed, sort by amount
SCSI Code SCSI Code Decoded Amount
--------- ----------------- ------
0x16 RESERVE(6) 2
0x2a WRITE(10) 25
0x28 READ(10) 96

VMK_SCSI_DEVICE_QUEUE_FULL (TASK SET FULL) = 0x28


Sagt mir jetzt ehrlich gesagt nicht sooo viel..

[bla!zilla]

Irgendwas zwischen VMkerne und den Platten hat ein Problem:

- HBA
- Fabric
- Controller der DS
- Backend
- Platten

Schau dir mal die FC-Fabric an, speziell Port Counter. Check auch noch mal die DS.

[m.mart1n]

Ok, dann versuchen wir mal auszuschließen.

HBA - Könnte sein

Fabric - Könnte sein (Damit kennt sich leider niemand von uns aus)

Controller der DS - Glaube ich nicht, der hat in den letzten Wochen weder einen Pfadschwenk noch einen reboot gemacht (Supportdaten der DS sind laut IBM sauber)

Backend - Wie definierst du das?

Platten - Kann ich mir nicht vorstellen, da ich (wenn es die Last zulässt) so konfiguriere das auf ESX 1 nur VMs von der LUN1 sind und auf ESX 2 nur VMs von der LUN2 usw...

Könnte man eventuell noch etwas ausschließen wenn man davon ausgeht, das die Probleme erst seit dem dazukommen neuer Hardware vorhanden sind?