Dauernder Redundanter Fibre-Pfadausfall

[Andi91]

Hallo Leute,

Wir haben in unserer vSphere-Umgebung folgendes Problem.

Folgende Konstellation:

4 ESX-Server (Zwei Test, Zwei Echtbetrieb)
2 Brocade Switches 5100
Jeder Server ist mittels einer Qlogic HBA QLE2562 (2 Port Karte) jeweils auf einem Switch angebunden.
2 SANs (Eurostor A16F-R2221 und A16F-R2431) - Je SAN CH0 auf Switch 1 angebunden und CH1 auf Switch 2 angebunden.

Das Problem fällt auf Zwei Servern auf. (Das Problem tritt immer Richtung selben SAN auf):

Interresant sind die Ausfallzeiten des Redundanten Pfades. Diese passieren meistens zur selben Zeit:

07.05.2011 05:49:51
13.05.2011 01:59:53
14.05.2011 01:59:54
15.05.2011 01:59:54
15.05.2011 09:04:54
15.05.2011 21:59:54
16.05.2011 01:59:54
16.05.2011 23:59:55
17.05.2011 23:59:55
18.05.2011 23:59:55
19.05.2011 01:59:55
19.05.2011 23:59:56

Folgende Fehlermeldung wird ausgegeben:

Pfadredundanz zu Speichergerät
naa.600d023100009a30000000006fdb0160
unterbrochen. Pfad vmhba0:C0:T4:L0 ist nicht bereit.
Betroffene Datenspeicher:
"SAN5_Partition0".
Warnung
27.05.2011 02:00:16
10.*.*.* (IP-Adresse)

Verwendet wird ESX 4.1.0 Echtsystem und Testsystem ESXi 4.1.0
Das Problem tritt beim ESX und ESXi auf. Ebenfalls auf unterschiedliche Partitionen und auf unterschiedliche FibrechannelSwitches.

Als Multipathrule habe ich zuerst Zulezt verwendet aktiviert gehabt.
Mit der PATH-Regel VMW_PSP_FIXED_AP funktionierte es ohne irgendwelche Fehlermeldungen.
Mit der Fixed Regel leider nicht.

An was kann das Problem jetzt noch liegen?
Zoning wurde überprüft (Kann ja gar nicht an dem liegen,...)
BIOS und FW aller Server und Komponenten sind ident und auf dem neuesten Stand.

[Tschoergez]

Hi!
Welche PSP einstellung schlägt der Storage-Hersteller denn vor?

Gibt es irgendwelche bestimmten aktionen, die um die Uhrzeiten anlaufen (backups o.ä.)?
Betrifft das Problem immer den gleichen ESX oder mehrere gleichzeitig?

Path-Trashing?

edit: schau mal ins vmkernel.log des betreffenden ESX, da sollte mehr drin stehen (inkl. der SCSI-Fehlercodes)
http://vmprofessional.com/index.php?content=resources

Viele Grüße,
Jörg

[Andi91]

Hallo Tschoergez,

Laut der Hardware Compatibility Guide von VmWare wird die VMW_PSP_FIXED Einstellung für das betroffene Storage empfohlen.

Ja, auffälig ist dass um ca 00:00 Uhr Tagessicherungen laufen, jedoch tritt der Fehler auch bei ESX-Servern auf, bei denen keine Sicherung läuft.

Das Problem tritt auf zwei von 4 ESX Servern auf. Auf einem ESX 4.1.0 und einem ESXi 4.1.0. Ebenfalls sind auch verschiedene LUNs zum Storage betroffen und unterschiedliche Ports bei der HBA.

Auf dem ESXi in dem messages-Log File /var/log/messages wird folgende Fehlermeldung ausgegeben.

May 30 23:59:12 vmkernel: 28:15:14:51.604 cpu3:3469485)ScsiDeviceIO: 1672: Command 0x2a to device "naa.600d023100009a30000000006fdb0160" failed H:0x0 D:0x28 P:0x0 Possible sense data: 0x0 0x0 0x0.
May 30 23:59:14 vmkernel: 28:15:14:53.242 cpu3:4099)NMP: nmp_CompleteCommandForPath: Command 0x2a (0x41027f3f2c40) to NMP device "naa.600d023100009a30000000006fdb0160" failed on physical path "vmhba3:C0:T4:L0" H:0x0 D:0x28 P:0x0 Possible sense data:
May 30 23:59:14 0x0 0x0 0x0.

Diese Fehlermeldung wird alle paar Sekunden mehrmals ausgegebn bis ca. 00:00:06 Uhr.
Die Fehlermeldung im vSphere Client war dann um 00:00:18 sichtbar

Ebenfalls sind in der obengenannten Zeit solche Fehlermeldungen dabei:

May 31 00:00:06 vmkernel: 28:15:15:45.345 cpu3:4099)NMP: nmp_CompleteCommandForPath: Command 0x2a (0x41027f39c140) to NMP device "naa.600d023100009a30000000006fdb0160" failed on physical path "vmhba3:C0:T4:L0" H:0x0 D:0x28 P:0x0 Possible sense data:
May 31 00:00:06 0x0 0x0 0x0.

Leider konnte ich keinen Fehlercode aus den Meldungen herausfinden und anschließend mit deiner Website auswerten.

Mit der VMW_PSP_FIXED_AP Einstellung hatte ich bis jetzt noch keine Probleme. Aber ist dadurch das Problem wirklich gelöst?

Path-Trashing wäre natürlich möglich, aber was könnte die Ursache für dies sein.

Jetztschonmal Danke für deine Hilfe.

Gruß Andi

[Andi91]

Habe mich jetzt nochmals genauer über PATH-Trashing informiert.

Pfad Trashing kann man ausschließen da wir die selbenLUNS über CH0 und CH1 rausmappen. Deshalb fungiert unser SAN als AKtiv/Aktiv Storage. Laut vmware kann dies nur bei einem Aktiv/Passiv Storage und meist nur bei der Fixed Pathrules auftreten.

Deshalb gehe ich mal davon aus das hier kein Pfad-Trashing vorkommt.
Des weiteren habe ich alle Laufzeitnamen der Pfade überprüft und konnte keinen Zugriff auf unterschiedliche Speicherprozessoren entdecken.

Gruß Andi