Nach einem heftigen LAN Ausfall war ein ESX Cluster in einem nicht administrierbaren Zustand und musste neu gestartet werden. Einige der VMs blieben jedoch unerreichbar. Bei näherer Betrachtung konnte man sehen, daß eine Storage LUN nicht mehr vorhanden war.

Die Umgebung

VMware vSphere 5.1 U1
Storage: Datacore SANsymphony-V 9 mit Frontend, Backend und Mirror über Fibrechannel

Fehlersuche

Der erste Blick gilt in so einem Fall natürlich der Storage, aber dort waren keine Auffälligkeiten zu erkennen. Das Storagesystem (Datacore SANsymphony-V 9) zeigte keinerlei Fehlermeldungen und die fehlende LUN (gespiegelt) war im Status “sync”.

Rescan Datastore

Man müsste also annehmen, daß alle ESXi Server diese LUN wieder erkennen und mounten können. Nach einem Rescan wurde die verlorene LUN angezeigt, jedoch nicht als VMFS Volume erkannt. Statt dessen wurde sie als neue LUN angeboten mit der Option zur Formatierung – was ich natürlich dankend ablehnte. 🙂

An dieser Stelle ist persönlicher Ehrgeiz und Stolz fehlplatziert. Daher sollte man spätestens jetzt Kontakt zum VMware Support aufnehmen. Obwohl ich das Problem als “nicht kritisch” eingestuft hatte – schliesslich war ein aktuelles Backup der betroffenen VMs vorhanden – kam die Reaktion des Supports recht schnell. Ich beschreibe hier die Schritte, die ich gemeinsam mit dem Supportmitarbeiter von VMware durchging, um das Problem einzugrenzen und schließlich zu lösen.

Device ID ermitteln

Jedes Devive verfügt über eine eindeutige Device-ID. Diese beginnt mit der Bezeichnung “naa.”, gefolgt von einer 32 Stelligen Hexadezimalnummer wie im Beispiel unten dargestellt.

naa.60030d90db8065026c898809239630ba

Dies ist die Referenz für alle kommenden Aktionen.

Pfade auflisten

Gibt es aktive Pfade zur LUN und wenn ja, wieviele?

esxcfg-mpath –l listet LUNs und die dazu gehörigen Pfade. Mit grep wird die Ausgabe auf das gesuchte Device reduziert. Es genügt hierfür auch ein Teilstring der Device ID.

esxcfg-mpath -l | grep "c898809239630ba"

fc.20000000c9ab610f:10000000c9ab610f-fc.20000090fa1b1bee:10000090fa1b1bee-naa.60030d90db8065026c898809239630ba
Device: naa.60030d90db8065026c898809239630ba
Device Display Name: DataCore Fibre Channel Disk (naa.60030d90db8065026c898809239630ba)
fc.20000000c9ab610f:10000000c9ab610f-fc.20000090fa1b1ea0:10000090fa1b1ea0-naa.60030d90db8065026c898809239630ba
Device: naa.60030d90db8065026c898809239630ba
Device Display Name: DataCore Fibre Channel Disk (naa.60030d90db8065026c898809239630ba)
fc.20000000c9ab610e:10000000c9ab610e-fc.20000090fa1b1de8:10000090fa1b1de8-naa.60030d90db8065026c898809239630ba
Device: naa.60030d90db8065026c898809239630ba
Device Display Name: DataCore Fibre Channel Disk (naa.60030d90db8065026c898809239630ba)
fc.20000000c9ab610e:10000000c9ab610e-fc.20000090fa1b1b0c:10000090fa1b1b0c-naa.60030d90db8065026c898809239630ba
Device: naa.60030d90db8065026c898809239630ba
Device Display Name: DataCore Fibre Channel Disk (naa.60030d90db8065026c898809239630ba)

Die Ausgabe zeigt, daß die LUN vom ESXi Server über vier FC-Pfade erreichbar ist. Das ist genau die erwartete Anzahl.

Kernel Log

cd /var/log
grep "<device ID>" vmkernel.log

In der Ausgabe des Kernel.log fanden sich mehrere Einträge wie unten dargestellt:

Partition: 414: Failed read for “naa.60030d90db8065026c898809239630ba”: I/O error

Es scheint, als könne vom eingebundenen Device nicht gelesen werden. Ein Hexdump sollte klären ob überhaupt irgendwelche Daten vom Device erreichbar sind.

cd /vmfs/devices/disks/
ls -als
hexdump -C <device ID> | less

Diese Anfrage lieferte keine Ergebnisse.

Der folgende Befehl mach ein Rescan auf allen Adaptern und liefert gleichzeitig die neuesten Einträge im Kernel Log (Tail).

vmkfstools -V
tail -f /var/log/vmkernel.log

Auch hier wieder kein Lesezugriff auf das Device.

Partition: 414: Failed read for “naa.60030…

Prüfung der Partition-Table

partedUtil getptbl /vmfs/devices/disks/<device ID>

Auch hier keine Reaktion auf den Befehl bis zum Timeout.

Datacore Server unpresent / present vDisk

Alle bisherigen Ergebnisse deuten darauf hin, dass die LUN von der Storage gesperrt wurde. Daher sollte die Presentation der vDisk (Datacore Bezeichnung einer LUN) in Datacore beendet und erneut gestartet werden. Danach wurde erneut ein Rescan auf allen HBA initiiert und die Meldungen im Kernel Log aufgezeichnet.

vmkfstools -V
tail -f /var/log/vmkernel.log

Die LUN war wieder für Lese- und Schreibvorgänge bereit und wurde vollständig von den ESX Servern erkannt.

Was war passiert?

Möglicherweise gab es bei dem Absturz wiedersprüchliche IO-Anfragen seitens der ESX Server, was die Datacore Server offensichtlich dazu veranlasste, den Zugriff komplett zu sperren. Was auf den ersten Blick wie ein Fehler aussieht, ist in Wirklichkeit ein Schutzmechanismus des Storage-Layers. Besser kein Zugriff, als Datenkorruption. Dadurch konnte nach Beseitigung der ESX Störung ein unbeschadetes Volume wieder seine Arbeit aufnehmen.

Troubleshooting: LUN nach crash verloren