VPLEX: Festplatte als Hardware aufgrund der SCSI-Prüfbedingung 3/11/0 vom Storage-Array gekennzeichnet

Dieses Ereignis wird ausgelöst, wenn VPLEX eine Leseanforderung an die zugrunde liegende Speicherarray-LUN ausführt und das Array keine I/O-Vorgänge auf diesem LUN-Block bedienen kann, was die 3/11/0-Prüfbedingung auslöst (fehlerhafter Block auf dem Array).

Dies tritt häufig in Situationen mit hohem Lese-I/O auf, wie z. B.:

• Migration von VPLEX-Extents/Geräten
• Backupvorgänge
• Datenbankintegritätsprüfungen

Das VPLEX-Speicher-Volume ist als "hardware-dead" gekennzeichnet, wird aber auf der Storage-Array-Schnittstelle als fehlerfrei angezeigt.

Beispielausgabe des CLI-Befehls ll /clusters/cluster-2/storage-elements/storage-volumes/storage-volume name>
 

Die Migration von VPLEX-Gerät/Extent (Mobilitätsjob) bleibt bei einem bestimmten Prozentsatz hängen.

Beispielausgabe des CLI-Befehls ll data-migrations/device-migrations/<device_migration_name>
 

Der Host sieht, dass der VPLEX-Speicher offline geht oder als inaktiv markiert wird, und das VPLEX-Speicher-Volume wird ebenfalls als kritischer Fehler oder Hardware-tot markiert.

Beispieldaten, wie im Firmware-Protokoll notiert,
amf/45 disk VPD83T3:xxxxxxxxxxxxxxx: read failure: marking this in-use disk dead

VPLEX-Firmwareprotokolle zeigen Streaming- oder zeitweilige SCSI/27 (Prüfbedingung) mit SCSI-Erkennungscodeeinträgen für 3/11/0, was übersetzt "Medium Error - unrecovered read error"

Beispielausgabe, wie während des Vorfalls im Firmwareprotokoll notiert,

2016/06/09 02:46:23.67: scsi/27 tgt VPD83T3:6006016011663200b058c25a984de511 cmd 0x28 status 0x2 valid 0 resp 0x70 seg 0x0 bits 0x0 key 0x3 info 0x0 alen 10 csi 0x0 asc 0x11 ascq 0x0 fru 0x0 sks 0x0
2016/06/09 02:46:23.68: scsi/27 tgt VPD83T3:6006016011663200b058c25a984de511 cmd 0x28 status 0x2 valid 0 resp 0x70 seg 0x0 bits 0x0 key 0x3 info 0x0 alen 10 csi 0x0 asc 0x11 ascq 0x0 fru 0x0 sks 0x0
2016/06/09 02:46:23.69: scsi/27 tgt VPD83T3:6006016011663200b058c25a984de511 cmd 0x28 status 0x2 valid 0 resp 0x70 seg 0x0 bits 0x0 key 0x3 info 0x0 alen 10 csi 0x0 asc 0x11 ascq 0x0 fru 0x0 sks 0x0

Um dieses Problem zu bestätigen, gilt immer Folgendes:
key   = 0x3
asc   =  0x11
ascq = 0x0

Wenn VPLEX eine I/O-Leseanforderung (0x28) an das Speicherarray sendet, kann das Array die I/O-Anforderung nicht erfolgreich bedienen und antwortet mit der Prüfbedingung 3/11/0 für "unentdeckter Lesefehler".

VPLEX versucht, Lesevorgänge aus einem fehlerhaften Block auf dem Storage-Array durchzuführen. Da das Storage-Array diesen I/O nicht bedienen kann, markiert VPLEX den Storage als inaktiv.

Dies ist nicht array- oder arraycodespezifisch.

Die Ursache hierfür liegt außerhalb von VPLEX und ist ein Problem auf dem Speicherarray mit LUN.

Das Storage-Array, das die SCSI-Prüfbedingung 3/11/0 an VPLEX sendet, muss vom entsprechenden Arrayanbieter untersucht werden. Dieses Problem wird dadurch ausgelöst, dass das Array die Lese-I/O-Anforderung aufgrund eines "nicht wiedererkannten Lese"-Problems auf dem Storage-Array nicht bedienen kann.

Der VNX-Support muss aktiviert sein.

Der folgende CLI-Befehl kann auf dem VPLEX Managementserver ausgeführt werden, um eine Liste der 50 logischen Einheiten abzurufen, die am stärksten von den 3/11/0-Prüfbedingungen betroffen sind:

grep "key 0x3 " /var/log/VPlex/cli/firmware.log_* | awk '{print $3,$5,$18,$19,$26,$27,$28,$29}' | sort | uniq -c | sort -nr | head -50


Beispiel:

Dies ist ein Problem der Blockschicht auf dem Storage-Array und kann nur durch Maßnahmen auf dem Storage-Array selbst behoben werden.

Dies ist kein VPLEX-Problem, sondern die VPLEX meldet ein Symptom, das vom Back-end-Array aus gesehen wird.

Die Verwendung von "storage-volume resurrect --force" ist hier nicht gültig.
Dieser Befehl erzwingt, dass das inaktive Speicher-Volume in VPLEX als "alive" angezeigt wird, unabhängig von seinem aktuellen IO-Status oder Problemen auf dem zugrunde liegenden Storage-Array.
Dieser Befehl erzwingt, dass das Storage-Volume wieder online geschaltet wird, bis die nächste IO für das zugrunde liegende Storage-Array fehlschlägt.
Wenn der Host denselben Datenblock anfordert, der das Problem 3/11/0 auf dem zugrunde liegenden Storage-Array aufweist, wird das Storage-Volume erneut als tot markiert.
Dies ist erwartetes Verhalten und kein Hinweis auf ein VPLEX-Problem.


Wenn das problematische Speicher-Volume direkt vom Speicherarray auf dem Host bereitgestellt wird (unter Umgehung von VPLEX), kann der Host einige der Daten verwenden. Diese Aktion stellt dem Host jedoch direkt eine mögliche Datenbeschädigung dar. Der Host hat weiterhin Probleme beim Lesen der spezifischen Blöcke mit der 3/11/0-Prüfbedingung.